Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications
draft-polk-local-emergency-rph-namespace-05
Yes
No Objection
Note: This ballot was opened for revision 02 and is now closed.
(Robert Sparks; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
Shouldn't Section 5 repeat (and expand upon) the comment in paragraph 1 of Section 1... This namespace is not envisioned for use on the open public Internet because it can be trivially forged.
(Barry Leiba; former steering group member) No Objection
Substantive comments; non-blocking, but please consider and feel free to chat with me: -- Section 1 -- This will ensure more the important calls are established or retained; therefore the "esnet" namespace is given five priority-levels instead of just one. I can't parse the first part of this sentence, and don't know how it relates to the second part. Can you please re-phrase this? -- Section 5 -- OLD given that this indication is to give preferential treatment of marked traffic great preference within the network verses other traffic. You have the preference stuff in there twice, probably due to an editing glitch. (If you decide to keep "versus", correct its spelling.) NEW given that this indication is to give marked traffic great preference over other traffic within the network. ======== Other comments; no need to respond to these. Take them or modify them as you please: -- Section 1 -- OLD The "esnet" namespace MUST only be used in times of an emergency, where at least one end, setting aside the placement of B2BUAs, of the signaling is within a local emergency organization. Splitting "at least one end of the signaling" is awkward, and makes this hard to read. NEW The "esnet" namespace MUST only be used in times of an emergency, where at least one end of the signaling, setting aside the placement of B2BUAs, is within a local emergency organization.
(Brian Haberman; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) (was Discuss) No Objection
(Ralph Droms; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
Please consider the comments from the Gen-ART Review by David Black, especially ones concerning Section 2. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07663.html
(Sean Turner; former steering group member) (was Discuss) No Objection
Thanks for addressing my concerns.
(Stephen Farrell; former steering group member) (was Discuss) No Objection
Thanks for taking my discuss points and comments into
account.
I have the following non-blocking comments on -03 in
case they're useful:
abstract: "usage to" is an odd phrase
p2, last para: suggest s/reduced to a minimum/reduced to
an acceptable level/
p3, "would need to have a trust relationship" is still
very vague, I think what you need to say is that the ASP
and the rest of the ESInet trust one another to not mess
with this header. That's a very specific aspect of a
trust relationship. ("Directly attached" is also
confusing really, I think you could lose that entire
paragraph.)
- section 2, 2nd para: I think it'd still be good to add
a statement like 'The "esnet" namespace MUST NOT be used
on the public Internet unless the node adding the header
has specific knowledge that the SIP message will
subsequently be processed solely within an ESInet.'
- section 3, 1st para: 45 different types? Seems an odd
thing to say. Maybe I'm missing a reference.
- p6, "the ESInet to emergency authorities calling public
citizens" is very unclear which seems like a bad idea.
- p7, I have no idea what "designated into" means.o
- p7 typo: "incorrect use of namespace"
- p8, I don't get what "usage into" means
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection