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

From: "Stastny Richard" <[email-masked]>
Date: Wed, 12 Oct 2005 13:11:18 +0200

Caveat:

ENUM (in general) is NOT for defining transit routes.
Only the end-user (User ENUM) or the carrier serving the
number in question = the destination "network" (Carrier ENUM)
is allowed to enter a domain, NEVER a "transit network".

Richard

> -----Original Message-----
> From: Christian de Larrinaga [mailto:[email-masked]]
> Sent: Wednesday, October 12, 2005 12:22 PM
> To: David Meyer
> Cc: Peter Williams; [email-masked]; Stastny Richard
> Subject: Re: [Enum] voipeer agenda/charter uploaded
> 
> 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:
> 
> 
> >     Peter,
> >
> > On Tue, Oct 11, 2005 at 12:23:14PM -0700, Peter Williams wrote:
> >
> >
> >> 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.
> >>
> >>
> >
> >     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?
> >
> >
> >
> >> We have a good strawman from viopeer; its highly SIP specific,
> >> particularly
> >> 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
> >
> >
> >
> >
> >> 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
> >>>
> >>> 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
> >>
> >>
> > _______________________________________________
> > 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: Christian de Larrinaga <[email-masked]>
Date: Wed, 12 Oct 2005 15:57:35 +0100

Richard

Thanks for the caveat.
I used the word "supporting" very deliberately.

> is allowed to enter a domain, NEVER a "transit network".

Yes indeed.

The charter has been very carefully written and the references to sip  
servers and layer 5 gives a very clear message to both L3 but also to  
L6/L7. But it is a coded message.
Carrier ENUM is just not defined enough to call now but its presence  
is sitting here looming large over this proposed activity like the  
uninvited guest who believes he will take over the party.

I don't propose we add the carrier enum term to the charter as that  
would be entirely wrong, but it  would be useful in the charter to  
add stated support for RFC 2826 (L8) principles to protect against  
the formation of split roots in ENUM and ENUM like services should  
ancillary ENUM like roots come to be formed.

Christian

Christian de Larrinaga

---

From: "Peter Williams" <[email-masked]>
Date: Wed, 12 Oct 2005 09:01:32 -0700

>>The charter has been very carefully written and the references to
>sip  servers and layer 5 gives a very clear message to both L3 but also to  

I tried to read it as carefully at it was written (as it is declared as 
being over written, and words/phrases have special semantics that will catch 
out the average reader).

I think it says, in plain language:

L5 stack session control entities will be supported by ENUM conforming name 
servers, whose collective structure is orthonogal to the structure of the L3 
routing, and the structure of L7 addressing forms and their administration.

I didn't get the L6 reference. Is an ENUM lookup going to supprot SIP 
proxies and influence the selection of codecs, in realtime, so we have 
"codec networks" to worry about? If ENUM is going go evolve into supporting 
registration and online queriying of the functional groups supported by 
layer stack instances at proxies and terminals, then its certainly going to 
need further exploitation of directrory (vs DNS) understanding. DNS is good 
for name translation, but clueless at capability negotiation. RFC 2826 
requires us to layer Directories and DNS, so they converge and work together 
(somehow).

>Carrier ENUM is just not defined enough to call now but its presence  is 
>sitting here looming large over this proposed activity like the  uninvited 
>guest who believes he will take over the party.

This seems advisable, as there is no chartered Carrier ENUM activity in 
IETF, today.

Viopeer can
(a) wait until ENUM has a charter, that it can reference
(b) make vauge allusions, use coded messages, and continue the mess.

>I don't propose we add the carrier enum term to the charter as that  would 
>be entirely wrong, but it  would be useful in the charter to  add stated 
>support for RFC 2826 (L8) principles to protect against  the formation of 
>split roots in ENUM and ENUM like services should  ancillary ENUM like 
>roots come to be formed.

RFC 2826 admits the notion that directories will go beyond the DNS to 
resolve ambiguous names.  It also waffles about the single root of the world 
idea, based in the USA. We used to hear the same in the PKI world, until we 
disposed of it @VeriSign (while keeping effective control in the USA! 
through competitive vs anti-competitive IAB-styled mechanisms)

In architectectural terms, ENUM is half directory, half DNS enhancement. Its 
also a third convergence of number portability from telephony and "number 
portability" a la DNS.  There is no point "protecting" against anything, 
trying to the avoid the dynamics of the directory world, as its our purpose 
(in ENUM WG) to investigate a suitable convergence. Protecting "now" against 
what we learn to be the right convegence strategy is not good standards 
making, though great religion.

"   The DNS type of unique naming and name-mapping system may not be
   ideal for a number of purposes for which it was never designed, such
   a locating information when the user doesn't precisely know the
   correct names.  As the Internet continues to expand, we would expect
   directory systems to evolve which can assist the user in dealing with
   vague or ambiguous references.  To preserve the many important
   features of the DNS and its multiple record types -- including the
   Internet's equivalent of telephone number portability -- we would
   expect the result of directory lookups and identification of the
   correct names for a particular purpose to be unique DNS names that
   are then resolved normally, rather than having directory systems
   "replace" the DNS.

   There is no getting away from the unique root of the public DNS."

---

From: David Meyer <[email-masked]>
Date: Wed, 12 Oct 2005 09:12:20 -0700

> ancillary ENUM like roots come to be formed.

	Christian,

	I'm not sure why one needs stated support for 2826. Asked
	another way, what more (than RFC 2826) needs to be said
	about unique roots? 

	Dave

---

From: Christian de Larrinaga <[email-masked]>
Date: Thu, 13 Oct 2005 12:35:40 +0100

David

It's a framework for clarity in a murky world.
I suspect adding more (than RFC 2826) would only obfuscate rather  
than enlighten at this point. But I'm willing to listen.

Christian

David

Christian