Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications
RFC 7135

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

(Robert Sparks) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-08-11 for -02)
No email
send info
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.

(Stephen Farrell) (was Discuss) No Objection

Comment (2013-02-11 for -03)
No email
send info
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

(Brian Haberman) No Objection

(Russ Housley) No Objection

Comment (2012-08-12 for -02)
No email
send info
  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

(Barry Leiba) No Objection

Comment (2012-08-10 for -02)
No email
send info
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.

(Pete Resnick) (was Discuss) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2013-02-19 for -04)
No email
send info
Thanks for addressing my concerns.