LoST: A Location-to-Service Translation Protocol
RFC 5222

Note: This ballot was opened for revision 10 and is now closed.

(Sam Hartman) Discuss

Discuss (2008-03-06 for -)
Section 18 claims that authorization is not generally required.  I
agree that LOST servers do not typically need to authorize clients,
but authentication and authorization of LOST servers by clients seems
critical to the security of the system.
Please clarify the text.
[Ted's proposed clarification is fine]

This spec proposes that RFC 2818 be used to describe how TLS
certificates are validated.  However let's think about how LOST works.
I get some identifier L from a secure source--static configuration of
my domain.  I look up L as a NAPTR record.  I get a URI, and then
apply the rules of RFC 2818 to it.  What secures the translation from
L to the URI?  You could argue dnssec, but I don't think that is a
practical suggestion for today's internet and LOST clients.  So, it
seems that as specified LOST has a very significant attack on server
authentication and authorization.  I think that RFC 2818 is an
inappropriate mapping of how to use TLS for LOST.  The easiest way to
handle this is to require that L (the string configured in DNS) appear
in the TLS certificate.  I'm not sure that doing so is compatible with
the https URI scheme, nor am I sure that most HTTPs stacks will easily
support implementing this.  However I'm sure this problem is very
important to solve.
Note that if dnssec is actually used, then the mechanism as specified is fine.
Comment (2008-03-05 for -)
I'd really like to see some thought applied to RFC 3205 and this
protocol.  Especially given that the security requirements do not seem
to line up well with RFC 2818, I'm not at all convinced that the
requirements of RFC 3205 are met.

(Lisa Dusseault) (was Discuss) Yes

(Jon Peterson) Yes

(Jari Arkko) No Objection

Comment (2008-03-05 for -)
> <path>elelment,


(Ron Bonica) No Objection

(Ross Callon) No Objection

(Pasi Eronen) (was Discuss) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2008-02-19)
  As pointed out by Ben Campbell in his Gen-ART Review, these things
  should probably be reworded as normative statements:
   - Section 5.2, last paragraph: "... it is the responsibility of the
     client to check the 'expires' attribute... "

   - Section 6, paragraph 3: "If a query is answered iteratively, the
     querier includes all servers that it has already contacted."

   - Section 8.3.1: "The order of location elements is significant; the
     server uses the first location element where it understands the
     location profile."

(Cullen Jennings) (was Discuss) No Objection

(Tim Polk) (was No Record, Discuss, No Objection) No Objection

(Dan Romascanu) No Objection

Comment (2008-03-04 for -)
1. second paragraph of Section 1 - PIDF-LO is duplicated

2. second paragraph of Section 1 - please explain what are "2-1-1" and "3-1-1" services. Maybe this is common knowledge in the US, but for a non-American reader they have no significance. Better describe the service for example 'non-emergency municipal services or a citizen community services (e.g. "3-1-1" in the United States', etc. 

3. in section 13.2 - I doubt that the three MAY in the descriptions of the warnings are appropriate. If I am not mistaken if each of the warning conditions is met in particular, including the earning message in the response is not optional. 

4. Reference [21] has a corrupted content at the time I am writing this comment. This makes me wonder wheter a better protected place can be found for the on-line examples quoted in Appendix B.

(Mark Townsley) No Objection

(Magnus Westerlund) No Objection

Comment (2008-02-20 for -)
Usage of "PSAP" acronym. Please write it out.