Re: [Enum] voipeer agenda/charter uploaded

["Peter Williams" <home_pw at msn.com>]

> > 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.


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."
> Christian
>
> Christian de Larrinaga
>
>
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www1.ietf.org/mailman/listinfo/enum



_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum