A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol
RFC 7840

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

(Ben Campbell) Yes

Comment (2016-02-02 for -04)
No email
send info
There is some confusion about whether this draft updates 6881. The headers and section 5 say it does, but the abstract does not. (Since the abstract _does_ mention 5985, I assume the authors intended to follow the convention of mentioning such things in the abstract.)

It would be nice to have a sentence or two on why some countries are reluctant to deploy public LoST servers. (I recognize there may be too many worms in that can, so feel free to ignore.)

- section 5, 2nd paragraph:
I don't understand the 2nd sentence. It seems like this updates 6881 or it doesn't.

Alissa Cooper Yes

(Spencer Dawkins) Yes

Comment (2016-02-02 for -04)
No email
send info
Nit: "funciton" should be "function".

In this text:

   Evolving architectures in Europe to address regulatory requirements,
   such as [M493], couple location and routing information in the access
   network whilst using a softswitch-centric approach to emergency call
   processing.
   
"softswitch-centric" is clearly defined in Section 3, but that's later in the document. Perhaps you could include a forward reference to Section 3 here?

(Jari Arkko) No Objection

Comment (2016-02-03 for -04)
No email
send info
Jouni Korhonen's Gen-ART review raised some comments that are worth looking at.

Deborah Brungard No Objection

(Benoît Claise) No Objection

Comment (2016-02-04 for -04)
No email
send info
A detail but since I spent time writing it while performing my review, here it is.

Sure, I should know about all the references before reading this document, but simply things such as expanding the first acronym occurences facilitates the reading.
	Public Safety Answering Point (PSAP)
	Location-to-Service Translation (LoST)

Ah. Now, I arrive to section 2, where I see those...

(Stephen Farrell) No Objection

Comment (2016-02-04 for -04)
No email
send info
section 4: The optional service URN seems like a thing where
it could be dangerous to be over-general, and where being
specific to emergency calling services would be a good
restriction. I would not like "service=urn:advertising" to be
something that'd work here. (At least not without
consideration of how that could be used for ad blocking:-)
The registry from RFC5031 does however seem to control that
correctly (via standards action or ECRIT WG/IESG review) so I
think it'd be better here to say that the service URN MUST be
in that specific registry. If that is already in the text
that's fine, but I didn't read it as quite having that MUST.

(Brian Haberman) No Objection

Comment (2016-02-03 for -04)
No email
send info
The following is a training review from Suresh Krishnan (incoming INT AD)

* Section 7

Not using documentation address block for examples. Using RFC1918 space instead. IANA has allocated 192.0.2.0/24 for documentation use.

(Joel Jaeggli) No Objection

Comment (2016-02-03 for -04)
No email
send info
ip address examples are no more meaningful/less if documentation prefixes are used...

Barry Leiba No Objection

Comment (2016-02-03 for -04)
No email
send info
I note that the reference to 5687 was moved to informative in -04.  I think the fact that it's used as the reference for privacy and security considerations leads to its being normative, as it originally was.  But, really, I think the right fix for that is to change the phrases in Sections 8 and 9 that say "beyond those already described in [RFC5687]" to instead say "beyond those already described in [RFC5985]".  I think using the security aspects of the base HELD protocol as the basic considerations for this extension is the right thing.  Comments?

(Terry Manderson) No Objection

Alvaro Retana No Objection