Subject: Re: [Enum] sipping-e164 comments

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 17 Feb 2002 15:17:53 -0800

Co-chairs,

Statements of the form:

> BTW, I felt the need to point out the following statement in <whatever>

have limited utility in this venue. The urgency of the "contributor" is
not a substitute for actual technical contribution.

Please assist the ignorant in finding their fora, where ever _else_ that
may be, no matter who the ignorant actually are.

Eric

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

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 17 Feb 2002 21:28:01 +0100

> may be, no matter who the ignorant actually are.

Eric, sometimes pointing these things out help discussions. Sometimes
ignoring the posting and only interfering if the discussion continues is
better.

In the case of the postings last week from various people on this subject
which is _not_ part of what this mailing list is about I have not found
them being disturbing enough.

But, the people which are interested in discussing the policy of the US
Government or any other government in the world can discuss it either in
the fora that body has created for those discussions, or in ITU-T SG2.

Regarding use of NAPTR for other kind of numbering plans than E.164, note
that I have on my list of clearifications I wanted to know if people agreed
with one item which clearifies how this is to be handled.

I have no comments so far on that point.

   paf

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 17 Feb 2002 17:19:17 -0800

Patrik,

In my sip lab I've zone files for, name servers serving, and resolvers
resolving <plotz>.<fizz> for a sip app (gratuitous plug for VOCAL here).

I personally don't care what strings, in US-ASCII or HIGH-BOGON, are used
for either "plotz" or "fizz".

I'm confused by the language of your (1) and (2) (your note of the 15th),
in (1) "ENUM" refers to a service, in (2) there are "ENUM-like mechanisms".
Having spent most of my life in the OS trade, mechanism is what we do,
service is a fiction we fob off on users. Not to be used interchangably.

	Is the name of the delegation in the e164.arpa domain "ENUM"?
	If so, OK. Delegation is the mechanism, e164.arpa the scope,
	there is a gratuitous syntax restriction on the labels, and
	possibly some other cruft.

	Are delegations in other domains "ENUM-like"?
	If so, is their ENUM-esque essence
		(a) delegation,
		(b) scope,
		(c) label syntax,
		(d) other

Since I'm not responsible for a private numbering plan, or an iso3166 dns
label space, or an ICANN dns label space, this is one area (touching on
several sections) of 2916 that I don't have an _interoperable_implementors_
opinion on. Irresponsible comments by non-implementors are a dime a gross,
as another WG experience shows.

Your (6) is something I suggest isn't "security". A "data collection and
data protection considerations" section could address the properties of
the data, independent of the access and transport mechanism(s).

Eric