Subject: Re: [Ecrit] ECRIT WG Status - concern about service-urn-03

From: "James M. Polk" <[email-masked]>
Date: Tue, 11 Jul 2006 12:59:51 -0500

At 03:29 PM 6/30/2006 +0200, Hannes Tschofenig wrote:
>Hi all,
>
>the following three documents are in good shape and passed the WGLC:
>
>- draft-ietf-ecrit-service-urn-03.txt

forgive me for not catching this before, but I have a concern about the 
Service URN doc moving forward.

I think this is a doc that creates and identifies a good namespace or 
identifier for an emergency call "on the wire". However, I think it makes 
an interesting comment in the Intro:

    In this document, we propose a URN namespace that, together
    with resolution protocols beyond the scope of this document,
    allows us to define such global, well-known services, while distributing
    the actual implementation across a large number of service-providing
    entities.

I'm interested in the phrase "beyond the scope of this document", inviting 
magic to happen, because a solution is not available (meaning not written yet).

Later on in the Intro is this:

    The translation of dial strings to service URNs is beyond the scope of
    this document; it is likely to depend on the location of the caller...

I see this "beyond the scope of this document" phrase again referring to 
something no invented yet.

Yet, with all this "location" and "URN" being interdependent to generate a 
robust solution, Section 4 discusses with the reader how using LoST can 
give an answer to this magic, from DNS:

    When a network entity receives a service URN, it uses the S-NAPTR [6]
    mechanism to determine how to map the service URN, possibly using
    other information such as geographic location, to a routable URI.

    example.com.
; order pref flags service regexp
IN NAPTR 50 50 "a" "SURN.sos:LoST"
"" ; replacement
    lost.example.org

IN NAPTR 10 50 "s" "SURN.pizza:PLP" ""
     _plp._tcp.pizzahouse.example.net

Somehow not specified here, something "beyond the scope of this 
document"  was used (presumably an emergency URN and an endpoint's Location 
information) resulting in a LoST server URI being discovered.  Now, I may 
be reading this wrong, but this is the impression.

This document is not short of DNS references (3), or URN references (8) - 
yet none are near any "beyond the scope of this document" comment leading a 
reader to a solution of how a user's location is sent in DNS (in the clear 
presumably) to receive a proper LoST Server URI.

I suggest all text related to DNS, especially the text giving an answer to 
a query, such as a LoST Server URI query, be removed from this document, 
and perhaps moved to another solution/mechanism document discussing that 
idea (using DNS to retreive a LoST URI for a endpoint).

This will leave the Service URN document as an identifier document, which 
is what it should be, based on the charter item listed here from the ECRIT 
website:

http://www.ietf.org/html.charters/ecrit-charter.html

Mar 2006 A Standards Track RFC describing how to identify a session
      set-up request is to an emergency response center

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

---

From: Andrew Newton <[email-masked]>
Date: Tue, 11 Jul 2006 15:51:52 -0400

On Jul 11, 2006, at 1:59 PM, James M. Polk wrote:
> I'm interested in the phrase "beyond the scope of this document",  
> inviting magic to happen, because a solution is not available  
> (meaning not written yet).

Perhaps these phrases could be rephrased to mean that we are talking  
about other documents and the details of those other documents are  
the responsibility of the reader to comprehend.  I don't know.  Maybe  
some genart reviewers would be willing to give us a suggestion...  
they tend to be good at that.

> I suggest all text related to DNS, especially the text giving an  
> answer to a query, such as a LoST Server URI query, be removed from  
> this document, and perhaps moved to another solution/mechanism  
> document discussing that idea (using DNS to retreive a LoST URI for  
> a endpoint).

I do not like this suggestion.  This document is not just talking  
about a generic idea, it is about a specific mechanism.

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 11 Jul 2006 15:27:51 -0500

>about a generic idea, it is about a specific mechanism.

I believe this document is tasked with one specific idea: creating an 
emergency identifier.  But it seems to do more than that, and that "more" 
part is seriously incomplete, hinting at things not even written anywhere 
yet.  If they were written, they would clearly be normatively referenced 
here, but they aren't written, so they can't be.  That's a problem.

The ECRIT milestone is to create a Standards Track doc for an emergency 
identifier.  This doc shouldn't add to this task, IMO.  The identifier is 
good, and it needs to be RFCd.