[Ecrit] Comments on: draft-ietf-ecrit-held-routing-02.txt

["DRAGE, Keith (Keith)" <[e-mail]>]

I did a somewhat belated full review of the entire document and had the following comments. I do not believe any of these comments are particularly controversial, but they do require some revision:

1)	Abstract. The abstract should concentrate on what the document does, rather than the motivation. Therefore the words:

   In many circumstances public LoST servers or a distributed network of
   forest guides linking public LoST servers is not available.  The
   general ECRIT calling models breakdown without publically accessible
   LoST servers.  Sometimes location servers may have access to
   emergency routing information.

Could be deleted from its current location. It would probably be appropriate to a prefix to the remaining 1st sentence that starts, "For cases where location servers have access to emergency routing information,..."

2)	Given that service URNs have certain rules associated with their usage, surely the normative text needs a normative reference to RFC 5031. The appropriate place for this would appear to be in section 4, 2nd paragraph.

3)	Section 4, 2nd paragraph currently states:

   If a service is specified, and the LIS does not
   understand the requested service then URIs for urn:service:sos are
   returned.

And further

   A LIS that understands the routing request element but not the
   specified service URN, returns the routing URIs for the
   urn:service:sos service.

What RFC 5031 states is:

   Declaration of syntactic structure:  The URN consists of a
      hierarchical service identifier, with a sequence of labels
      separated by periods.  The left-most label is the most significant
      one and is called 'top-level service', while names to the right
      are called 'sub-services'.  The set of allowable characters is the
      same as that for domain names [RFC1123] and a subset of the labels
      allowed in [RFC3958].  Labels are case-insensitive, but MUST be
      specified in all lower-case.  For any given service URN, service-
      identifiers can be removed right-to-left; the resulting URN is
      still valid, referring to a more generic service.  In other words,
      if a service 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid
      service URNs.

RFC 5031 is therefore slightly more complex and those rules should be followed. Depending on how the reference proposed in comment 2) is made, that may solve this comment.

4)	Section 4, 5th paragraph. Replace "SHALL" by "MUST". The same applies for the 6th paragraph.

5)	Section 4. There are normative requirements for "support returning URIs for urn:service:sos" but no normative requirements for actually doing so. While I guess what is returned may be dependent on policy of the operator of the LIS, surely something should be stated.

6)	Section 4, last paragraph. 

   The LoST Protocol [RFC5222] defines a <mapping> element that
   describes a service region and associated service URLs.  Reusing this
   element from LoST to provide the routing URIs was considered.
   However, this would have meant that several of the mandatory
   components in the <mapping> element would have had to contain
   ambiguous or misleading values.  Specifically, the "source" attribute
   is required to contain a LoST application unique string for the
   authoritative server.  However, in the situations described in this
   specification there may not be an authoritative LoST server, so any
   value put into this attribute would be misleading.  In addition to
   this, routing information received in the manner described in this
   specification should not be cached by the receiver, so detailing when
   the routing information expires or was last updated is irrelevant.

This is apparently motivation rather than mechanism. It would be better that section 4 is solely for the real requirements and that the motivation is elsewhere.

7)	Section 7, section 8: It is not clear to me why the reference is to RFC 5985 rather than RFC 5687 directly. Could the authors clarify (to the list) what RFC 5985 adds for the security of the addition of this specific element.

It may be that the text requires some additional informational text indicating how these documents apply for security and privacy of this specific element.

Regards

Keith