Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications
draft-polk-local-emergency-rph-namespace-05

[Ballot comment]
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

[Ballot comment]

Thanks for taking my discuss points and comments into
account.

I have the following non-blocking comments on -04 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

[Ballot discuss]
s3 contains the following:

This namespace will also be
used for communications between emergency authorities, and MAY be
used for emergency authorities calling public citizens.

but Figure 1 shows the user network to UA as being out of scope.  Is it just supposed to be a MAY to the user network?

s7 also contains this:

This document does not indicate this
marking is intended for use by endpoints, yet protections need to be
taken to prevent granting preferential treatment to unauthorized
users not calling for emergency help.

So I'm a little confused about the MAY in s3.

[Ballot comment]
and now for some non-blocking comments:

1) s1:

r/is not envisioned for use/is not for use
r/This new namespace can be included in
  /This new namespace is included in
r/have great controls in place
  /have controls in place    - i could see many but great? ;)
r/The function is to facilitate
  /The function facilitates
r/It can also be imagined that Application Service Providers (ASP)
  directly attached to an ESInet can have a trust
  /Application Service Providers (ASP)
  directly attached to an ESInet need to have a trust
r/function,./function.
r/This will ensure more the
  important calls are established or retained
  /This will ensure that on ESInet the more
  important calls are established or retained

Some might quibble that there's more than one department of national security in the US ;) Is it really national security/defense or is pubic safety, disaster relief, and national security/defense (i.e., guys with 'intelligence' and guns)?

r/federal government's department of national security, such as the US
  Department of Homeland Security
  /national government's department responsible for public safety,
  disaster relied, national security/defense, etc.

2) s2:

r/That is for/That is left for

when repeating a requirement not sure you should use 2119-language.  maybe:
  r/to a registered namespace SHOULD NOT
    /to a registered namespace should not

I think this sentence is really odd:

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.

I think you can really on put the MUST on one end or the other being within an local emergency organization.  And, it kind of goes against what you said in s1 about the document merely creating the namespace and their order. Maybe:

The "esnet" namespace MUST only be used
where at least one end, setting aside the placement of B2BUAs, of
the signaling is within a local emergency organization.

I find this a little odd too:

Individual jurisdictions MAY configure
their SIP entities for preemption treatment. This is OPTIONAL,
subject to local policy decisions.

Obviously, local folks can define the values displayed to the users, but what's the OPTIONAL on about? Also in 4412 it say (note the lower case) about approaches for preferential treatment:

  SIP elements may use the resource priority mechanism to modify a
  variety of behaviors, such ...

Maybe:

SIP entities that support preemption treatment
(see Section 5 of [RFC4412]) can be configured according
to local policy.  Display names for the "esnet" values
displayed can likewise be set according to local policy.

Figure 1: if it's just an example not sure you need the emphasis
r/*WILL*/is

r/is intended for use/is used

I think the point about utilized is whether preemption is enforce right?

maybe:

r/Whether preemption is implemented in the ESInet and the values
  displayed to the ESInet users, is out of scope.

3) s3:

r/namespace SHOULD NOT to be considered generic/namespace is not generic

4) s3.2: This is odd too:

This document does RECOMMEND
the choice within a national jurisdiction be coordinated by all
sub-jurisdictions to maintain uniform SIP behavior throughout an
emergency calling system of that country.

To be effective, the choice within a national jurisdiction needs to be coordinated coordinated by all sub-jurisdictions to maintain uniform SIP behavior throughout an  emergency calling system of that nation.

r/way, defined in RFC 4112/[RFC4412]

If you don't want to recommend it you can use (NOT RECOMMENDED - it's a 2119-keyword):

Though permissible according to this specification, it is NOT RECOMMENDED that a preemption algorithm be used.

Is the MUST in the last para copied?  Maybe just lowercase it.

4) s5: r/this namespace within the field incorrectly
    /this namespace incorrectly

I'm still trying to parse this:

Within a network that is enabled to act on the Resource-Priority
header field within SIP requests, the implications of using this
namespace within the field incorrectly can potentially cause a large
impact on a network, given that this indication is to give
preferential treatment of marked traffic great preference within the
network verses other traffic.

Are you trying to say:

For networks that act on the SIP Resource-Priority header field,
incorrect use of namespace can result in traffic that should have
been given preferential treatment not be given it and vice versa.

[Ballot discuss]
This document is not appropriate for the standards track. As others have commented, it says:

  This namespace is not envisioned for use on the open
  public Internet because it can be trivially forged. 

This simply doesn't pass muster for it to be on the standards track. It should be an Informational document on how this mechanism is used in a closed domain of applicability.

(Note: I understand that the reason this document was put on the standards track was because the registry rules for Resource-Priority namespace and priority-value registries are both "Standards Action" as per RFC 4412. I have spoken to Robert and will propose a small document, updating 4412 by changing the registration rules for the registries to "IETF Review". That will allow this document to be Informational instead of standards track, but will still require IETF consensus to use these registries. "Standards Action" was probably overkill in the first place.)

[Ballot discuss]

Three discuss points, but I hope easily sorted.

(1) I see from the ecrit archive that there appears to have
been more controversy about this than the writeup would
indicate. [1] In particular, how does this fit with, or
maybe even conflict with, RFC 5031? I'd like to understand
if we're specifying two ways to do the same thing, and if
so, why there's no explanation or justification of that in
this document. (Note: as of now, I've no opinion as to
whether or not this and 5031 are the same thing or not, or
if one is better than the other, but they are clearly
related.)

  [1] http://www.ietf.org/mail-archive/web/ecrit/current/msg07651.html

(2) The intro says this is "not envisioned" for use on the
public Internet because it can be "trivially forged."
Saying "envisioned" is very weak there. Later you say "It
can also be imagined" that an ASP "can have a trust
relationship" allowing use of this. That wins the
vague-statememt-of-the-day competition for me:-) On page 4
you say this "MUST only" be used when one end is within a
local emergency organisation, which appears to allow any UA
to add this if calling anyone within a "local emergency
organisaiton" in "times of emergency." That's again too
vague IMO. The last para of section 2 also mentions the ASP
case again and says an ASP "MAY have a trust relationship"
(improper 2119 there I think). All in all its just unclear
how a UA developer is supposed to know whether or not to
allow this to be turned on and I think it needs to be
clearer.

(3) I think this is inappropriate use of 2119: "This
document does RECOMMEND the choice within a national
jurisdiction be coordinated by all sub-jurisdictions to
maintain uniform SIP behavior throughout an emergency
calling system of that country." You're not talking to an
implementer with that, and those are the readers of RFCs. I
think you ought change that to say "The authors of this
document think..." and not imply the IETF has concensus to
RECOMMEND that national authorities do stuff in any
particular way since we (the IETF a a whole) don't know
enough to say that.

[Ballot comment]


- Thanks for a nice short document!

- It'd be good to know why "esnet" and "ESInet" are both
needed. The difference, if any, wasn't clear to me.

- intro: (total nit:-) not all governments are federal

- I don't get why 5 levels is the Goldilocks number here.

- The last para of the security considerations seems to
embody a fine idea (that might solve my discuss point 2).
Why isn't that behaviour (ignore this unless dest=112 or
similar) a normative part of this spec?

[Ballot comment]

  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

[Ballot comment]
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.

[Ballot comment]
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.

State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead.
James let me know he was working on a revision (some time ago - apologies for not getting that into the tracker in a timely fashion)

Upon approval of this document, IANA understands that there are two IANA
Actions which must be completed.

First, in the Resource-Priority Namespaces registry in the Session
Initiation Protocol (SIP) Parameters registry located at:

http://www.iana.org/assignments/sip-parameters

a new registration will be made as follows:

Intended New warn- New resp.
Namespace Levels Algorithm code code Reference
--------- ------ -------------- --------- --------- ---------
esnet 5 queue no no [ RFC-to-be ]

Second, in the Resource-Priority Priority-values in the Session
Initiation Protocol (SIP) Parameters registry located at:

http://www.iana.org/assignments/sip-parameters

a new registration will be made as follows:

Namespace: esnet
Reference: [ RFC-to-be ]]
Priority-Values Priority
(least to greatest) Numerical Value *
-------------------- -----------------
"4" 4
"3" 3
"2" 2
"1" 1
"0" 0

IANA understands that these are the only actions required to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (IANA Registering a SIP Resource Priority Header Field Namespace for Local Emergency Communications) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'IANA Registering a SIP Resource Priority Header Field Namespace for
  Local Emergency Communications'
  as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-07-13. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document creates the new Session Initiation Protocol (SIP)
  Resource Priority header field namespace "esnet" for local emergency
  usage to a public safety answering point (PSAP), between PSAPs, and
  between a PSAP and first responders and their organizations, and
  places this namespace in the IANA registry.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-polk-local-emergency-rph-namespace/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-polk-local-emergency-rph-namespace/


No IPR declarations have been submitted directly on this I-D.

(1.a) I (Brian Rosen) am the document Document Shepherd.
      I have reviewed the most recent (04) version of
      the document and believe it is ready for publication.

(1.b) This document has been reviewed by the community, primarily within the
      ecrit working group.  I have no concerns about the depth or breadth of these
      reviews.

(1.c) I have no concerns about any broader review needs.  We have had comments from
      the range of community members that are needed to assess the impact of this document
      on other IETF standards, as well as the specific needs of the emergency community to which
      the document is aimed.

(1.d) I have no specific concerns the Responsible AD or IESG should be aware of.
      I firmly believe this document is needed, and the document solves a problem
      the emergency community has.

(1.e) This document has solid consensus among those interested in it, and
      general agreement among a larger community that it is an appropriate solution to
      the problem it addresses.

(1.f) No one to my knowledge has has threatened an appeal or otherwise indicated
      any displeasure with the document.

(1.g) I have reviewed the document for ID nits.  The trust boilerplate is one revision old, but it
      otherwise satisfactory, and the date is old, but in terms of requirements for an RFC, there are
      no issues.  This document does not contain a MIB, does not define a media type and does not
      define a new URI type. 

(1.h) There are two normative references (to RFC2119 and RFC4412) and no informative references.
      There are no downrefs.

(1.i) I have reviewed the IANA considerations section, and find it complete and accurate.
      The document creates one new entry each in two existing registries.

(1.j) This document has no formal language description.

(1.k) The IESG approval announcement includes a Document
      Announcement Write-Up. Please provide such a Document
      Announcement Writeup? Recent examples can be found in the
      "Action" announcements for approved documents. The approval
      announcement contains the following sections:
  Technical Summary
      This document creates the new Session Initiation Protocol (SIP)
      Resource Priority header field namespace "esnet" for local emergency
      usage to a public safety answering point (PSAP), between PSAPs, and
      between a PSAP and first responders and their organizations, and
      places this namespace in the IANA registry.

  Working Group Summary
    This document is an AD sponsored individual submission, but has been
    reviewed by the ecrit working group. 

  Document Quality   
    A number of reviewers, including Janet Gunn have done a thorough review
    of the document, and all concerns raised by reviews have been resolved. 
    Organizations such as NENA have indicated a requirement for this namespace.