A Routing Request Extension for the HTTP-Enabled Location Delivery (HELD) Protocol
RFC 7840
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
Alvaro Retana No Objection
(Alissa Cooper; former steering group member) Yes
(Ben Campbell; former steering group member) Yes
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.
(Spencer Dawkins; former steering group member) Yes
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?
(Barry Leiba; former steering group member) No Objection
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?
(Benoît Claise; former steering group member) No Objection
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...
(Brian Haberman; former steering group member) No Objection
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.
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
Jouni Korhonen's Gen-ART review raised some comments that are worth looking at.
(Joel Jaeggli; former steering group member) No Objection
ip address examples are no more meaningful/less if documentation prefixes are used...
(Stephen Farrell; former steering group member) No Objection
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.
(Terry Manderson; former steering group member) No Objection