Subject: Re: [Enum] voipeer agenda/charter uploaded

From: "Stastny Richard" <[email-masked]>
Date: Tue, 11 Oct 2005 21:13:38 +0200

I do not understand what you want to say?
 
This is the voipeer charter discussion and not
the enum charter discussion
 
BTW, estee,ed enum chairs, is there a enum charter proposal to expect soon.

With soon I mean before Vancouver

Richard

________________________________

Von: [email-masked] im Auftrag von Peter Williams
Gesendet: Di 11.10.2005 21:03
An: [email-masked]
Betreff: RE: [Enum] voipeer agenda/charter uploaded

FROM Proposed VIOPEER Charter:

"Routing fo sessions which are not signaled using SIP. In
    particular, voipeer is constrained to consider only those
    scenarios in which call routing is signaled using the
    SIP protocol and addressed by SIP or SIPS URIs or E.164
    (public telephone number) addresses. By extension, national
    and private formats numbering formats are out of scope for
    voipeer"

ENUM has broader scope, including H.323 URLs.

ENUM Charter needs to be session protocol agnostic, in essence. So its the
architectural support for multiple session/setup protocols thats required,
not any particular love of H.323.

Interaction between ENUM and VIOP peering must be only in the generic areas,
not SIP-specific areas.

I see no reason why ENUM should not be optionally "tuned" for today's SIP,
but not "architected" for SIP. There is little doubt that E.164 and ENUM
will, given their role,  be around far longer than SIP will be.

All private and national number formats (that are conforming to E.164 ) are
within the scope of ENUM.

In essence, ENUM is not just a name server for today's SIP proxies. It has a
bigger role to play in the Internet. At the same time, it should play in
today's adoption space!

>From: David Meyer <[email-masked]>
>To: [email-masked]
>CC: [email-masked], [email-masked], [email-masked],
>[email-masked]
>Subject: [Enum] voipeer agenda/charter uploaded
>Date: Tue, 11 Oct 2005 11:06:44 -0700
>
>
>       Please see
>
>       http://www3.ietf.org/proceedings/05nov/agenda/voipeer.txt
>
>       Note that the bulk of our session will be devoted to
>       hammering out our charter (charter bashing).
>
>       Thanks,
>
>       Dave

><< attach4 >>

>_______________________________________________
>enum mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Peter Williams" <[email-masked]>
Date: Tue, 11 Oct 2005 12:23:14 -0700

IAB required, in a carefully worded policy communciated through a co-chair 
that its acceptance of Carrier ENUM work itmes is contingent on aligning 
voipeer.future and enum.future re-chartering. What this WG and its members 
wants is irrelevant, per the last WG meeting and IAB considerations: all 
that matters is satisfying IAB's mandate, which we must assume to be in our 
interests.

We have a good strawman from viopeer; its highly SIP specific, particularly 
in some ENUM-related areas.

We comment on their charter, BECAUSE we are REQUIRED to align with their 
goals, objectives, methods, timelines, etc  - for good and obivous reasons - 
  if we want Carrier ENUM to be adopted into the standards track.

Remember Carrier ENUM is not formally an IETF standards track activity 
today, and the rules on becoming so have been stated (and restated, word for 
word, indicating its a very sensitive topic).

>From: "Stastny Richard" <[email-masked]>
>To: "Peter Williams" <[email-masked]>,<[email-masked]>
>Subject: Re: [Enum] voipeer agenda/charter uploaded
>Date: Tue, 11 Oct 2005 21:13:38 +0200
>

---

From: David Meyer <[email-masked]>
Date: Tue, 11 Oct 2005 13:52:57 -0700

Peter,

> that matters is satisfying IAB's mandate, which we must assume to be in our 

	Can you describe how you feel the IAB "required" this?
	I'm a little confused as 

	(i).	I'm not sure how that IAB can "require"
		anything; perhaps you mean s/IAB/IESG/ 
		(that would make more sense), and 

	(ii).	I'm not sure what you think was "required" WRT
	        Carrier ENUM alignment; there have been a lot of
		discussions around this, and it would be good to
		get everyone's assumptions on the table, and to
		make sure we're all using the same set.

	Can you (or anyone else) clarify these for us?

> in some ENUM-related areas.

	SIP is the Internet-standard signalling protocol, after
	all. And we are talking about the Internet here (IETF and
	all).

	Thanks,

	Dave

> goals, objectives, methods, timelines, etc  - for good and obivous reasons 
> - if we want Carrier ENUM to be adopted into the standards track.
> 
> today, and the rules on becoming so have been stated (and restated, word 
> for word, indicating its a very sensitive topic).
> 
> 
>

---

From: Christian de Larrinaga <[email-masked]>
Date: Wed, 12 Oct 2005 11:21:43 +0100

Carrier ENUM is not mentioned here which is good I think.
But it is implied.
I would support a definition of Carrier ENUM as supporting peering/ 
transit and routing relationships but not for provisioning user  
services.
The VoiPeer charter seems to agree with this view?

If so then it should be taken on board by those working on a carrier  
ENUM plan?

Christian de Larrinaga
[email-masked]
Voex Inc.

On 11 Oct 2005, at 21:52, David Meyer wrote:

>>> Interaction between ENUM and VIOP peering must be only in the  
>>> generic
>>> areas,
>>> not SIP-specific areas.
>>>
>>> In essence, ENUM is not just a name server for today's SIP  
>>> proxies. It has
>>> a

---

From: "Peter Williams" <[email-masked]>
Date: Wed, 12 Oct 2005 07:44:28 -0700

It would be natural to break down the strategic goals of ENUM (rechartered) 
for the Carrier ENUM question, in terms of the following categories::

(If I start using ISO terms and modelling conventions  for all this, becuase 
its all been done before, slap me and remind me we are doing _IETF-styled_ 
reinvention of carrier-based telephony)

There will be multiple Carrier ENUM trees, one of which is public and 
ultimately, ICANN (i.e. US govt.) controlled.

Within an Carrier ENUM tree,

- voice providers will practice uniform and consistent peering

- voice providers will provision name server entries and their contents

- the structure of the tree will reflect the administrative rights of the 
provider under NRA licensing

- the structure of validation entity and security domains is orthogonoal to 
the structure of the tree reflecting the adminsitrative rights of providers 
to create and modify entries in the ENUM name servers serving the tree

- ENUM name servers will reflect number registration, and number porting, 
but will not directly perform registration or NP duties

- An ENUM name server is not intended to be an identity service for Carriers 
of Record, for current entries

- A carrier's obligation to wiretap a subsriber line shall not impact or 
influence the adminsitration of or content of, an entry in an ENUM name 
server.

- The adminsitration of entries, and the schema of services declared within 
an entry, shall be administered by the COR for the E.164 number identifying 
the entry

- Any E.164 number issued pusuant to national regulatory authority license 
may logically identify an entry.

-Entries that declare CORs, NRAs, schema definitions, provider service 
access points and other administrative meta-data are not within the scope of 
Carrier ENUM dliverables, though may be addessed in related ENUM series 
documents.

-------------

The ENUM charter SHOULD NOT focus its text on the above! Rather, it needs to 
characterise Carrier ENUM scheme, to be designed in the next round of WG 
activity. The deliverables that embody the above need to be identified, 
timetabled, and characterized, however, using the architectural principles 
listed above.

If the formulation of the charter is not occuring with the direct 
involvement of the folks who have already written Carrier ENUM drafts, and 
can improve upon the above considerably, there is SOMETHING VERY WRONG WITH 
THE TRANSPARENCY.

Improve the process, co-chairs, and make it transparent and available to 
mailing list participants, per our community norms.

Peter.

>From: Christian de Larrinaga <[email-masked]>
>To: David Meyer <[email-masked]>
>CC: Peter Williams <[email-masked]>, [email-masked], 
>[email-masked]
>Date: Wed, 12 Oct 2005 11:21:43 +0100
>
>I would support a definition of Carrier ENUM as supporting peering/ transit 
>and routing relationships but not for provisioning user  services.
>If so then it should be taken on board by those working on a carrier  ENUM 
>plan?
>
>Christian de Larrinaga
>[email-masked]
>Voex Inc.
>
>
>>>>All private and national number formats (that are conforming to E. 164 ) 
>>>>are
>>>>In essence, ENUM is not just a name server for today's SIP  proxies. It 
>>>>has
>>>>a