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

[James Winterbottom <[e-mail]>]

Thanks Keith.

I will digest these comments on the weekend and respond.

Cheers
James

> On 23 Jun 2015, at 11:59 pm, DRAGE, Keith (Keith) <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit