Sign in
Version 5.13.0, 2015-03-25
Report a bug

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

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

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

Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.

Jari Arkko

Comment (2008-03-05 for -)

> <path>elelment,


[Dan Romascanu]

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.

[Magnus Westerlund]

Comment (2008-02-20 for -)

Usage of "PSAP" acronym. Please write it out.

[Russ Housley]

Comment (2008-02-19 for -10)

  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."

[Sam Hartman]

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.