Subject: [Ecrit] Review of draft-ietf-ecrit-service-urn-02

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 5 Apr 2006 10:47:46 -0400

I have reviewed service-urn-02 and have the following comments:

A little concerned about 1-800-LAWYER as an example.  The problem here
is that there is no obvious mechanism to translate the e.164
1-800-LAWYER to the service urn.  I suppose someone could propose an
enumservice for this purpose, but until they do, we might consider
removing this particular example

You need a statement that points out the obvious: since the service urn
is a protocol labeling mechanism, it has no i18n implications.

My biggest problem is the DDDS stuff (section 3).  There is no
discussion of what domain you query the DNS for.  This is an area well
worked over by other emergency stuff, and 'fragile' because what you
normally want is your "local" (as in access network) domain, and it's
not all that easy to determine what that is.  Read the HELD and LCP
documents, and the discussion about this point.  I think this document
needs to handle this.  I think whatever it says is likely to have to be
the same as any other similar mechanism in the milieu (for example, how
you find your LoST server).  We need to decide what this text is, and
copy it into all the relevant documents.  

I am confused by the "Validation Mechanism" in Section 2.  First of all
the word "resource" is used here for the first time.  I am assuming it
has the meaning of 3406 resource.  The real problem is that the section
in 3406 that talks about validity defines it as "is there a valid
service" rather than "is the service available".  Using the DDDS
mechanism would only tell you if a service was available (in the sense
of configured, rather than in the sense of functioning) within a domain.
While I think you could keep most of this text if you qualify it, I
think the actual answer is that the validation mechanism is IANA
assignment.

I think Section 4.2 for the registration of the 3958 Service Tag should
be expanded a bit to more formally match the registration requirements
of 3958.  The document currently calls it a "Service Label" which is
incorrect.  I think you should be more clear that effectively, you are
creating a subregistry under SURN, but the contents of that subregistry
is the same as the registry you create in 4.1

Consider the following issue: there is sos.police.  In most areas of the
world, there are several kinds of police services that are related to
the hierarchy of the jurisdictions.  In North America, you typically
have local police, county police, state police and national police
(FBI).  Some other services have this characteristic.  Do we want to
allow a subservice under police?  An alternative is to allow a query to
a higher level civic address (a LoST query to a1=us, a2=pa for
sos.police gets you the Pennsylvania State Police).  That wouldn't work
for a geo query.

Appendix A starts out badly.  I think this is some kind of copy/paste
problem.  I think you need to start saying "A number of alternatives
were considered in developing this solution.

"sos" SIP reserved user name
  Using a SIP uri of the form "[email-masked]" follows the convention
of RFC 2142[8]

Nits:

Section 1, missing space in "United States),telephone"
Section 1, bad English in "allows to define".  Probably "allows us to
define"
Section 1, English could be better: "Also, such identifiers allow to
delegate routing decisions to third parties and mark certain" could be
"allow delegation of routing decisions to third parties and marking
certain.."

Section 1, bad English: " URN allows to identify services".  Should
probably be "URN identifies services"

In Section 2, the ABNF attempts to limit the top level name to 27
characters by using *25let-dig-hyp

In Section 2, under "Process of Identifier Assignment" the reference to
IANA Considerations needs "in" in front of it (esp look at how the HTML
version reads).  Actually, I note that IANA Considerations is Section 4,
and note how the references in Process of Identifier Assignment is made
vs "Identifier Uniqueness Considerations" above it.

In Section 2 " Identifier persistence considerations" spelling error in 
"The 'service' URN for the same service is expected to be persisent".
Should be persistent.

In Section 2, "Process for Identifier Resolution" references NAPTR
rather than S-NAPTR.  This might be okay (an S-NAPTR is sort of a NAPTR,
right?) but think about it.

In Section 2, "Conformance with URN Syntax" you say there are none, but
Section 4.1 says top level names must be less than 27 characters.  The
ABNF restricts it.

Section 4.3, which/that confusion in " The generic 'sos' service reaches
a public safety answering point (PSAP), that"

If these problems were addressed, I would think this document could be
WGLC'd

Brian

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 9 Apr 2006 12:38:51 -0400

Brian,

thanks for your extensive comments. Partial responses in-line as I  
work through them; I'll take care of the wording fixes.

> characters by using *25let-dig-hyp

Not sure what you are concerned about here. The definition is

let-dig [ *25let-dig-hyp let-dig ]

In other words, a string starting and ending with a letter or digit  
and no more than 25 other characters in between.

> vs "Identifier Uniqueness Considerations" above it.

I'm not sure I understand. It currently reads (in the TXT version)

The process of identifier
       assignment is described in the IANA Considerations (Section 4).

> right?) but think about it.

I don't know if S-NAPTR is given a separate designation, given that  
it is a DNS NAPTR record, but I'm happy to follow convention. Since  
IANA (see the fancy web page at http://test.icann.org/iana.dev/ 
assignments/s-naptr-parameters.shtml) uses S-NAPTR, I'll follow that  
lead.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 9 Apr 2006 21:22:39 -0400

More responses:

> removing this particular example

Removing lawyers is always a good idea. (The similarity is that  
dialing this number will get you a lawyer anywhere in the US, with  
the law office depending on where you're calling from.) I don't quite  
understand your concern about needing an enum service.

> is a protocol labeling mechanism, it has no i18n implications.

I'll add an I18N section.

> normally want is your "local" (as in access network) domain, and it's

I don't think that's really true in general. Why should my access  
network have better information about these services, particularly if  
it has no interest in VoIP or emergency calls? I suspect that,  
initially, the service lookup will be offered by the VSP. They have  
an interest and obligation to provide the service and can't wait  
until every last ISP has decided to provide a mapping service.

> needs to handle this.  I think whatever it says is likely to have  

I didn't see any description of this in draft-winterbottom-geopriv- 
held-sighting-00. LCP seems to define, besides the usual suspects of  
manual configuration and DHCP, a broadcast request, not specified  
further. (This would be essentially a one-off version of SLP.)

I think there are at least two plausible approaches to find an ISP- 
operated domain name, besides DHCP:

(1) SLP or Bonjour; the practical problem is that SLP is seeing  
limited new deployments and Bonjour seems to be under the cloud of  
being non-IETF-developed (but comparatively widely deployed), with  
the IETF competitor having been sent back to the WG for a do-over  
(somebody might know more about this).

(2) Inverse DNS: Get public IP address (via STUN, say); obtain domain  
name (via the usual reverse DNS lookup); use SRV or NAPTR record for  
that domain. This relies on the user's public IP address having a DNS  
entry. As far as I can tell, this seems to be almost universally true  
for residential broadband. (For enterprise users, I suspect that the  
DHCP solution is easiest.)

I had suggested a version of (2).

> copy it into all the relevant documents.

Actually, you find your LoST server via this mechanism, since it  
performs the translation.

> think the actual answer is that the validation mechanism is IANA

I agree that this doesn't quite fit; I reread 3406 and 3406 defines  
validation thusly:

   Apart from attempting resolution of a URN, a URN namespace may
       provide mechanisms for "validating" a URN -- i.e., determining
       whether a given string is currently a validly-assigned URN.   
[...]

This seems to imply that this mechanism would allow to determine  
whether urn:service:timezone, say, exists or not. This would  
presumably be done by the lookup mechanism.

I'll reword the paragraph to hopefully make the distinction clearer.

(more to follow)

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 9 Apr 2006 21:44:24 -0400

> sos.police gets you the Pennsylvania State Police).  That wouldn't  

An interesting issue.  I suspect that this would be hard to  
categorize easily by hierarchy, as the hierarchy differs across  
countries. (For example, countries such as Germany only have  
essentially two levels - state and border patrol - while centralized  
countries such as France have, I believe, only one national police  
service.)

In the US, this gets even more complicated since you have not just  
the ones you mention, but also campus police on every larger  
university campus, Amtrak police, ATF, capitol police (in DC), Secret  
Service and I'm sure FEMA has its own police force (equipped with  
bows and arrows). Until a few years ago, NYC had separate police  
forces for public housing and transit.

Thus, I suspect you have to try to find designations that are  
geographically-independent, such as
   police. transportation
   police. border
   police. campus
   police. public-housing
   police. terrorism

It is not clear to me that this is practically useful, as most people  
who need to know will be asking for ATF or FBI, rather than trying to  
guess which label applies to which service. Others will only need  
'police' and then be transferred to the right agency. In the US,  
there are likely going to be several competing agencies :-)

Do we want to do this now or wait until the need arises?

Henning

---

From: John Schnizlein <[email-masked]>
Date: Mon, 10 Apr 2006 07:59:05 -0400

On Apr 9, 2006, at 9:22 PM, Henning Schulzrinne wrote:

> I think there are at least two plausible approaches to find an 
> ISP-operated domain name, besides DHCP:
>
> being non-IETF-developed (but comparatively widely deployed), with the 
> IETF competitor having been sent back to the WG for a do-over 
> ...

The most recent comment on reverse DNS:

On Apr 5, 2006, at 2:22 PM, Dean Anderson wrote ( on 
[email-masked]):

> I thought that the title was going to be changed to 
> 'inaddr-encouraged', and I
> thought there were additional issues with the text, but I don't have a 
> list
> right off-hand. Though I recall some particular problems with the 
> notion that
> reverse and foward should or can always match, and particular problems 
> with
> security assumptions promoted in the draft.
>
> I'll see if I can review some of the email on the topic later this 
> week, as well
> as summarize some offlist discussion with a few people that apparently
> misunderstood the text of the draft.
>
> 		--Dean
>
> On Tue, 4 Apr 2006, Andrew Sullivan wrote:
>
>> Dear colleagues,
>>
>> During the Dallas meeting, the topic of 
>> draft-ietf-dnsop-inaddr-required
>> came up.  About five people, including me, indicated interest in the
>> draft, and the Chairs suggested that what was needed was an open
>> issues list.
>>
>> Since I committed to do something about this, I thought I'd propose a
>> summary list of what I take to be open issues.  I don't expect this
>> is a complete or correct list; I'm just proposing it so that we have
>> something to start with (or, perhaps, so you can all point and laugh
>> at what a bad job I've done understanding the discussion this far!).
>> I'm also not proposing text patches now, on the grounds that we
>> perhaps need to agree on a list of what the issues are before we
>> attempt to fix them.  I hope this is helpful.
>>
>> I compiled the following list by looking at the discussions about
>> this draft from last January.  The threads start at
>>
>> <http://darkwing.uoregon.edu/~llynch/dnsop/msg03618.html>
>>
>> and
>>
>> <http://darkwing.uoregon.edu/~llynch/dnsop/msg03619.html>
>>
>> I'm not including mere editorial comments (style, &c.) here, since I
>> doubt that's where the real contention is.
>>
>> The list
>> --------
>>
>> 1.	Update the policy discussion in paragraph 3 of section 2.
>>
>> 2.	Fix informative reference [ARIN] target.
>>
>> 3.	Add informative reference to detailed APNIC policies at
>>         <http://www.apnic.net/services/dns_guide.html>.
>>
>> 4.	Add informative reference [AFRINIC].
>>
>> 5.	The recommendations in section 4 are not strong enough.
>>
>> 6.	The ability of people actually to add PTR records is not
>> 	considered.
>>
>> Also, I noted one issue while I was preparing this, but I'm not sure
>> it's in the discussion from January:
>>
>> 7.	Section 2, paragraph 2, appears to say that [RFC2050]
>> 	requires RIRs to maintain IN-ADDR records on the large blocks
>> 	they issue.  I'm not entirely sure that RFC2050 actually says
>> 	that, even if that's what was intended.
>>
>> Discussion
>> ----------
>>
>> * Issue 1
>> 	
>> 	Some of the policy is out of date, and needs to be adjusted
>> 	to reflect the current policies of the bodies in question.
>>
>> * Issues 2-4
>>
>> 	These are references that need fixing in light of (1).
>>
>> * Issue 5
>>
>>         Some people (I am among them) express uneasiness that the
>>         document seems to suggest both that IN-ADDR is a good thing,
>>         and that one shouldn't use it.  People argue that, therefore,
>>         the recommendation should be stronger.  In particular, some
>>         have argued that the advice in section 4.2 could be made a
>>         little more equivocal, so that operators are urged to be
>>         fully aware of the trade-offs they make in terms of
>>         reliability when relying on IN-ADDR, but that they should not
>> 	be told "never do this".
>>
>> * Issue 6
>>
>>         Some people note that there are plenty of parts of the
>>         Internet where users have a hard time maintaining IN-ADDR.
>>         So, the discussion of the state of affairs in section 2 (or
>>         perhaps 3, if it's renamed) should point out how difficult it
>>         sometimes is for people to do this maintenance (and,
>>         presumably, lament the situation as one that ought to be
>>         fixed).  In addition, any alteration of section 4.2 in
>>         accordance with (5) will need to point out to operators the
>>         potential victims of their decisions to rely on IN-ADDR.
>>
>> *Issue 7
>>
>>         RFC 2050 says, "The regional registries will be responsible
>>         for maintaining IN-ADDR.ARPA records only on the parent
>>         blocks of IP addresses issued directly to the ISPs or those
>>         CIDR blocks of less than /16." That doesn't entail that they
>>         will be responsible for such maintenance.  It rather entails
>>         that, if they are responsible for anything, they're only
>>         responsible as far as the parent block (or the blocks less
>>         than /16).  Perhaps there's another source which makes it
>>         unambiguously clear that they are in fact responsible for
>>         this?

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 Apr 2006 09:30:53 -0400

Thanks for the pointer. I took a quick look and it seems to say "in- 
addr mapping good, do it". Did I miss any caveats?

>> I thought that the title was going to be changed to 'inaddr- 
>> encouraged', and I
>> thought there were additional issues with the text, but I don't  
>> have a list
>> reverse and foward should or can always match, and particular  
>> problems with
>>> During the Dallas meeting, the topic of draft-ietf-dnsop-inaddr- 
>>> required

---

From: John Schnizlein <[email-masked]>
Date: Mon, 10 Apr 2006 09:52:20 -0400

On Apr 10, 2006, at 9:30 AM, Henning Schulzrinne wrote:

> Thanks for the pointer. I took a quick look and it seems to say 
> "in-addr mapping good, do it". Did I miss any caveats?

Yes, I think you missed these three points about 
draft-ietf-dnsop-inaddr-required-07.txt:

1)  Since the -00 draft in August 2000, the biggest decision is that 
in-addr is NOT to be required.

2) The abstract says many sites do not implement it.
"Mapping of addresses to names has been a feature of DNS.  Many sites, 
implement it, many others don't.  "

3) Section 4.2 says explicitly:   "Applications SHOULD NOT rely on 
IN-ADDR for proper operation."

John

---

From: Andrew Newton <[email-masked]>
Date: Mon, 10 Apr 2006 10:18:07 -0400

Henning Schulzrinne wrote:
> 'police' and then be transferred to the right agency. In the US, there 
> are likely going to be several competing agencies :-)

I totally agree.  I also can't imagine the user interface being all that 
helpful in an emergency situation by offering a slew of sub-police 
function categories.

> Do we want to do this now or wait until the need arises?

Wait.

-andy