Subject: [Ecrit] Fwd: AD review of draft-ietf-ecrit-lost

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 21 Nov 2007 10:52:52 +0100

FYI

-------- Original-Nachricht --------
Datum: Wed, 7 Nov 2007 17:38:37 -0500
Von: "Peterson, Jon" <[email-masked]>
An: [email-masked]
CC: [email-masked]
Betreff: AD review of draft-ietf-ecrit-lost

I have a number of comments on this doc, but overall this mechanism looks sound to me.

First, a question for the chairs: has application/lost+xml gone to the ietf-types list for review yet? I couldn't find it in the ietf-types archive, but that could just be my oversight.

As another comment on the proto writeup, the normative dependency on [11] and [12] is something we'll need to note during the last call; effectively, for these cases we follow the same procedures we would for a downref to an Informational.

Has there been any external Apps Area review for Sections 14 and 16?

Detail comments on the text follow.

First sentence of the Intro, NAPTR could use a citation, and perhaps rather than just saying NAPTR is a "protocol",  one could instead start that sentence with: "NAPTR records served through the DNS and the Service Location Protocol  (SLP)..."

Second sentence, what is the "identity of a service"? Is that just a way of saying "type of service", or does it  mean something specific?

Nit, last sentence of the 1st paragraph of the Intro, "callers location" should be "caller's location".

I would also advise breaking up the first sentence of the 2nd paragraph of the Intro a bit; it is so complex it  seems to have misplaced a leading paranthesis (the one closed right after [11]). Instead of:

   This document describes a protocol for mapping a service identifier
   (service URNs) [9] and location information compatible with PIDF-LO
   [6], namely revised civic location information [10] and a subset of
   the PIDF-LO profile [13] and consequently with the Geo-Shapes [12]
   defined for GML [11]) to one or more service URLs. 

I might recommend: "This document describes a protocol for mapping a service identifier and location information  compatible with PIDF-LO [6] to one or more service URLs. Service identifiers take the form of the service URNs  described in [9]. Location information here includes revised civic location information [10] and a subset of the  PIDL-LO profile [13] which consequently includes the Geo-Shapes [12] defined for GML [11]."

Also, the Introduction in some places suggests that "service URLs" are returned, but in others (like the last  paragraph of the Intro) suggests that URIs are returned. It is somewhat unfortunate that both the input (service  URNs) and output (service URLs) of LoST use that term "service", because of course the term "service URI" could then seem to encompass both the input and the output. But within the Introduction it should be clear whether what is returned by LoST is just a URL or a URI. This confusion persists throughout the document. 5.8, for example, insists they are URLs, but they appear in a <uri> element.

It's important that the Intro be readable, for the benefit of lazy persons such as myself who judge whether or not  they need to read the rest of documents by the Intro alone.

At the start of Section 5, just to give readers a bit of context, it might make sense to discuss which LoST messages the <mapping> element might appear in. As the text reads now, <mapping> is introduced in a bit of a vacuum.

I'm a bit surprised that in 5.2 the reference to cache expiry behavior is the Overview of Operations (Section 3).  That section is not normative, and given that it's the overview it shouldn't be. Is this intended? Also, nit, 5.2  2nd sentence "The contents of this attribute is" should be singular "content"

5.4 - What are the conditions under which a service "approximates" another service? I assume something like "general emergency response" approximates "police" if police is unavailable, but that might not be obvious to all readers.

In 5.6:

   A LoST server may decide, based on local policy, to
   return the service boundary per value or to omit the
   <serviceBoundaryReference> element in the response.

Presumably if it returned the service boundary by value, there would be no need for a <serviceBoundaryReference>  element, so is this "or" supposed to be an "and"? Presumably the server wouldn't want to not return the service  boundary by value and also not include the <serviceBoundaryReference> element in the response, so readers shouldn't understand this as an exclusive "or", right?

I assume 5.7 is a dialstring that will reach a particular service within a particular boundary; I'm surprised this section makes no mention of the geographical scope of such dialstrings.

>From Section 6, I assume that all responses to requests that permit recursion contain a <path> element with at least  one <via> element, even if the authoritative response comes from the server that originally received the request from the client. I gather this because:

   The <via>
   element is inserted logically on receipt of the request,

and,

   The server that answers the request instead of forwarding it, such as
   the authoritative server, copies the <path> element verbatim into the
   response

Do I understand correctly? If, hypothetically, the <via> element were logically inserted upon the forwarding of the  request to another LoST server, then a one-hop response would contain no <via> elements. 

Section 7 doesn't really explain why a client might want to include multiple instances of location information, nor  why a server would prefer one to another. I assumed on first reading this must mean civic v. geodetic; only much later did I understand that wasn't allowed.

In 8.2.2, how realistic is it that a <serviceBoundary> will contain a postal code? I ask this not because I doubt  that there are some cases in which a <serviceBoundary> will in fact an encompass a particular postal code or other civic division, but I suspect that it will be totally coincidental, and that the vast majority of <serviceBoundary>s have nothing to do with postal codes. My real question is this: is it really reasonable to express a <serviceBoundary> through civic coordinates, or practically speaking are coordinate systems (and probably complicated polygons) the only way to reflect the actual dimensions of service boundaries to clients? If a client sends a civic address in a request for a mapping (with a 'serviceBoundary' attribute), and the server can't really describe the service boundaries in civic address vocabulary, what gets sent in the response? I didn't really see an applicable error in 13.1.

Nit in 8.3, I assume the <findService> query includes elements and attributes, not just attributes.

8.3.4, given that it is a subsection of 8.3, seems to suggest that <mapping> is an element of the <findService>  request. If you're just using this section to describe the 'serviceBoundary' attribute of <findService>, perhaps I'd say that at the start of this subsection.

In 8.3.5, is 'validateLocation' an attribute of <findService>? The example certainly illustrates that, but the text  in the first paragraph should make it clear.

An example in 8.4.2 might help; I had a bit of trouble envisioning what this would look like.

In Section 10:

   Typically, only top-level
   services are included in the answer, implying support for all sub-
   services.

So if you support any top-level service, that implies support for all possible sub-services? That seems  counterintuitive to me - if you support 'sos', do you necessarily support 'marine' (13.2 would have led me to think  otherwise)? But moreover, I'm really unsure of the applicability of <listServices>. I understand why you would want  to use <listServiceByLocation>, but <listServices> doesn't seem to give you any information that would be useful in  predicting whether or not a query would work, nor what sort of query you should send. If it exists for diagnostic  purposes, what sorts of diagnostics does it enable?

Also, nit, I note that Figure 12 gives <ListService> instead of <listService>, same in Figure 13, 14 and 15.

Nit, first paragraph of Section 11 has no final period.

Last sentence of the first paragraph of 12 suggests there are "three baseline profiles", I think you mean "two".

In 13.1, the first instance of "Relax NG" in the text could probably use a citation.

Section 14 mentions the use of HTTP 3xx messages; what is the applicability of this versus the higher-layer  redirection described in 13.3?

I would recast the Security Consideration (Section 18) a bit. I'd move the last sentence up to the front, and say  that Lost clients and servers MUST implement the security recommendations of [17]. As it stands now, the document  doesn't suggest that support for HTTP-over-TLS is mandatory to implement for LoST clients and servers; I suspect a  security review will insist on that. The rest of the general summary information about threats and authentication is  fine; I think the Sec Cons should just be more defential to [17].

Let me know what you think.

- J

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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 21 Nov 2007 08:29:46 -0800

Here's the response I sent; I kept Jon's original list of recipients, so it didn't
go to the WG.  Sorry for any confusion.  As a side conversation to another matter,
Jon and I talked about this and he agreed that most of these were clarifications
that could be folded into updates after Last Call.  There have already been some
IANA comments that need to be addressed, so I am anticipating a revision
right after last Call and then, hopefully, on to the IESG.  Nothing from either
review (AD or IANA) requires any protocol changes, just new text.  The
two that seemed particularly important in my reading of the conversation
were the clarifications of the "via" header behavior and the serviceBoundary
behavior.  (Again, no changes were being requested--just updated language).
Jon is cc'ed on this message so he can quickly dispel any misunderstandings
from me on his intent here.

			regards,
				Ted

Some of these questions appear to be directed at the chairs, but in
the interest of getting some discussion, I'll respond.  Any corrections welcome.

>First, a question for the chairs: has application/lost+xml gone to the ietf-types list for review yet? I couldn't find it in the ietf-types archive, but that could just be my oversight.

I also didn't see this at a quick glance, so I sent a request for review.  If it has
already been requested, someone will no doubt point it out.

>Has there been any external Apps Area review for Sections 14 and 16?

No formal review, but I have asked for sanity checks on the Internationalization
section from some of the usual suspects.  Asking for a review from the APPS
review team during Last Call would probably be good; either Lisa or Chris
could do so (Eric Burger is the point of contact, if you want to do that directly).

>Second sentence, what is the "identity of a service"? Is that just a way of saying "type of service", or does it  mean something specific?

The full sentence is:

   However, for an important class of services the appropriate specific
   service instance depends both on the identity of the service and the
   geographic location of the entity that needs to reach it.

the meaning of "the identity of the service" is the same as a "particular service"
in the sentence above.  In other words, we're highlighting that getting the
right service instance can be important, and that you get that by finding the
service instance(s) serving that location.  I wouldn't switch that to "type of
service", personally.  Maybe now that the URN doc is in the RFC ed queue
we could adjust this to make an explicit reference to that.  At the moment,
though, I hope this explanation suffices.

>It's important that the Intro be readable, for the benefit of lazy persons such as myself who judge whether or not  they need to read the rest of documents by the Intro alone.

Are these editorial changes required before Last Call?  If we can bundle last call
comments with these, so we can move forward, I think it would be good.

>5.4 - What are the conditions under which a service "approximates" another service? I assume something like "general emergency response" approximates "police" if police is unavailable, but that migh…

The full section is:

 If, however, the requested service, identified by the service URN
       [9] in the <service> element in the request, does not exist for
       the location indicated, the server can either return an
       <serviceNotImplemented> (Section 13.1) error or can provide an
       alternate service that approximates the desired service for that
       location.  In the latter case, the server MUST include a
       <service> element with the alternative service URN.  The choice
       of service URN is left to local policy, but the alternate service
       should be able to satisfy the original service request.

So this is explicitly for cases where the requested service is not available.  This
permits a local authority to use a "default" or approximate service for those
cases as a matter of configuration, provided it tells the requester that the substitution
was made.  If you request Mountain Rescue in Holland, for example, they can
return police, provided they tell you it is the police you are getting.

>Presumably if it returned the service boundary by value, there would be no need for a <serviceBoundaryReference>  element, so is this "or" supposed to be an "and"? Presumably the server wouldn't wan…

The context is:

  Since geodetic service boundaries may contain thousands of points and
   can thus be quite large, clients may wish to conserve bandwidth by
   requesting a reference to the service boundary instead of the value
   described in Section 5.5.  The identifier of the service boundary is
   returned as an attribute of the <serviceBoundaryReference> element,
   along with a LoST application unique string (see Section 4)
   identifying the server from where it can be retrieved.  The actual
   value of the service boundary is then retrieved with the
   getServiceBoundary (Section 9) request.

   A reference to a service boundary is requested by the client (using
   the 'serviceBoundary' attribute in the request with the value set to
   "reference").  A LoST server may decide, based on local policy, to
   return the service boundary per value or to omit the
   <serviceBoundaryReference> element in the response.

This basically gives the server some control over what is returned.
If a serviceBoundary with a value of "reference" is requested,
this allows the server to reply with a value instead (marked
as such) or to omit the element which would normally contain the
reply entirely. 

>I assume 5.7 is a dialstring that will reach a particular service within a particular boundary; I'm surprised this section makes no mention of the geographical scope of such dialstrings.

This is entirely within the context of a mapping element, which is entirely
tied to a geographical scope (either of the location provided in the request
or of the serviceBoundary referenced in the response).  Adding another
mention here seems redundant, unless I misunderstand what you mean here.

If you mean that that the dialstring may be valid other places than in
the location request or the serviceBoundary, that's true, but not really
something that needs much discussion here.  Imagine that we're looking
for a time service; I give you my location and get back 767-2676
(popcorn) as a dial string as well as other contact methods.  "Popcorn"
as a dialstring might work in Alabama as well as northern California, but returning
just the northern California serviceBoundary (or skipping the serviceBoundary)
isn't wrong and remains useful.  I could use a serviceBoundary profile that
allowed me to include multiple, additive regions to express both Northern
California and Alabama, but that would depending on the other contact
methods also being valid, which they might not be.

>Do I understand correctly? If, hypothetically, the <via> element were logically inserted upon the forwarding of the  request to another LoST server, then a one-hop response would contain no <via> el…

This is stated explicitly at the start of Section 6:

    To prevent loops and to allow tracing of request and response paths,
   all requests that allow recursion include a <path> element that
   contains one or more <via> elements, each possessing an attribute
   containing a LoST application unique string (see Section 4).  The
   order of <via> elements corresponds to the order of LoST servers,
   i.e., the first <via> element identifies the server that initially
   received the request from the client issuing the request.  The <via>
   element is inserted logically on receipt of the request, so that
   every server in a recursive query operation is included in the <path>
   element.

Since the initial <via> element is inserted on receipt, there must always be
at least one <via> element in a path element.  The "inserted logically"
means simply that the receiving header doesn't actually have to fiddle the
bits of the request to put itself in the queue of <via> elements; it is
enough that it do so on next action (forward or reply).

>Section 7 doesn't really explain why a client might want to include multiple instances of location information, nor  why a server would prefer one to another. I assumed on first reading this must me…

As 8.3.1 states:

    The <findService> query communicates location information using one
   or more <location> elements, which MUST conform to a location profile
   (see Section 12).  There MUST NOT be more than one location element
   for each distinct location profile.  The order of location elements
   is significant; the server uses the first location element where it
   understands the location profile.

would a forward reference to 8.3.1 meet the case here?

>In 8.2.2, how realistic is it that a <serviceBoundary> will contain a postal code? I ask this not because I doubt  that there are some cases in which a <serviceBoundary> will in fact an encompass a particular postal code or other civic division, but I suspect that it will be totally coincidental, and that the vast majority of <serviceBoundary>s have nothing to do with postal codes. My real question is this: is it really reasonable to express a <serviceBoundary> through civic coordinates, or practically speaking are coordinate systems (and probably complicated polygons) the only way to reflect the actual dimensions of service boundaries to clients?

It must be possible.  It's up to the jurisdictions to determine whether it is reasonable.
There are service boundaries which are whole states and/or countries, and it is
a heck of a lot easier to say "Valid within Norway" than to come up with the polygons
that match all those fiddly bits in the fjords.

>If a client sends a civic address in a request for a mapping (with a 'serviceBoundary' attribute), and the server can't really describe the service boundaries in civic address vocabulary, what gets sent in the response? I didn't really see an applicable error in 13.1.

That's the case we were discussing above, in reference to 5.6.

>So if you support any top-level service, that implies support for all possible sub-services? That seems  counterintuitive to me - if you support 'sos', do you necessarily support 'marine' (13.2 would have led me to think  otherwise)?

I think you may have missed this statement:

   The query does not
   contain location information, as it simply provides an indication of
   which services the server can look up, not whether a particular
   service is offered for a particular area.

If a top-level service supports sos, it should be able to look up sos.marine.  The answer
may always be "ServiceNotImplemented" (or the alternate default service) when
a geographic location is specified within a jurisdiction that has no marine services.

>But moreover, I'm really unsure of the applicability of <listServices>. I understand why you would want  to use <listServiceByLocation>, but <listServices> doesn't seem to give you any information that would be useful in  predicting whether or not a query would work, nor what sort of query you should send. If it exists for diagnostic  purposes, what sorts of diagnostics does it enable?

If you remember draft-ietf-ecrit-service-urn-07.txt, you'll see that it discusses sub
services for both sos and counseling.  You can use this to discover whether the
LoST server you're talking to works for one, the other, or for some later
registration.

>Section 14 mentions the use of HTTP 3xx messages; what is the applicability of this versus the higher-layer  redirection described in 13.3?

These are an HTTP-layer redirect; they occur before any processing by a
LoST server.  The 13.3 redirect occurs after a LoST server processes the
request; it might not be redirecting all request but those specific to a particular
service (e.g., still acting as authoritative for fire and ambulance services,
but redirecting police service mapping requests to some other authority during
some temporary  event like the Olympics).

>I would recast the Security Consideration (Section 18) a bit. I'd move the last sentence up to the front, and say  that Lost clients and servers MUST implement the security recommendations of [17]. As it stands now, the document  doesn't suggest that support for HTTP-over-TLS is mandatory to implement for LoST clients and servers; I suspect a  security review will insist on that.

Channel security is currently RECOMMENDED, equivalent to SHOULD.  It is certainly
a good idea for any deployment that deals with emergency services.  If a security
review asks that it go from RECOMMENDED to mandatory, we can discuss it further,
but there are likely to be some uses LoST where it will amount to bloat.

>The rest of the general summary information about threats and authentication is  fine; I think the Sec Cons should just be more defential to [17].
>

In general, there are a lot of what appear to be editorial comments or clarification
requests here, and some indications on which ones can be considered concurrently
with Last Call, which ones you considered blocking, etc. would be useful.

thanks,

Ted