RSVP Extensions for Admission Priority
draft-ietf-tsvwg-emergency-rsvp-15

[Ballot discuss]
The applicability statement and the security statements are both dependent on the rahman-rtg-router-alert-considerations and require it to be a normative reference. I would clear this discuss if there was an RFC Ed note to move this to a normative reference.

[Ballot discuss]
The applicability statement and the security statements are both dependent on the rahman-rtg-router-alert-considerations and require it to be a normative reference. I would clear this discuss if there was an RFC Ed note to move this to a normative reference.

[Ballot discuss]
From the email thread, we agree this is for use in a single administrative domain based on the security concerns. Please make a clear applicability statement on this. I suspect that my concerns are a subsets of Tim's and any text that worked for Tim would like cover my concerns.

From email thread we agree    [I-D.rahman-rtg-router-alert-considerations] should be a normative reference. Please make this change.

I think both of these could be resolved with an RFC Ed Note.

Thanks, Cullen

[Ballot discuss]
DISCUSS DISCUSS: Can this be used on the internet or not? I'm having a hard time telling from the draft?

WHen I read this, it seems that I-D.rahman-rtg-router-alert-considerations needs to be a normative reference.

[Ballot discuss]
I support publication of this document, but have a few concerns that I would like to discuss first.

This draft indicates that the extension is "targeted to a single administrative domain" based on
security concerns.  I have no problem with that scoping.  However, it is implicit in the statement
that the extension *could* be used across administrative domains.  That is a problem, since the
draft does not seem to (1) describe what would be required for cross-domain use, (2) state the
security implications of such a deployment in the security considerations, or (3) describe how
one ensures that the extension is limited to a single domain if you wish to avoid (1) and (2). 

(Of course, it is always possible that I am missing something critical since I am not an RSVP
expert - if you can point me to the right sections I would be happy to clear!)

[Ballot discuss]
I support publication of this document, but have a few concerns that I would like to discuss first.

This draft indicates that the extension is "targeted to a single administrative domain" based on security concerns.  I have no problem with that scoping.  However, it is implicit in the statement that the extension *could* be used across administrative domains.  That is a problem, since the draft does not seem to (1) describe what would be required for cross-domain use, (2) state the security implications of such a deployment in the security considerations, or (3) describe how one ensures that the extension is limited to a single domain if you wish to avoid (1) and (2).  (Of course, it is always possible that I am missing something critical since I am not an RSVP expert - if you can point me to the right sections I would be happy to clear!)

[Ballot comment]
AFAICS the only mention of "emergency services" in this I-D is in the file name (and that will disappear when it becomes an RFC). I have no objection to this feature for admission control priority policy becoming an RFC.

[Ballot comment]
4.1.1.  Admission Priority Merging Rules

  This section discusses alternatives for dealing with RSVP admission
  priority in case of merging of reservations.  As merging applies to
  multicast, this section also applies to multicast sessions.

  The rules for merging Admission Priority Policy Elements are defined
  by the value encoded inside the Merge Strategy field in accordance
  with the corresponding IANA registry.  The merge strategies (and
  associated values) defined by the present document are the same as
  those defined in [RFC3181] for merging Preemption Priority Policy
  Elements (see "IANA Considerations" section).

This begs the question: is a separate registry needed?


6.  IANA Considerations

  In section 3.1, the present document defines a Merge Strategy field

This should be section 4.1.

  inside the Admission Priority policy element.  IANA needs to create a
  registry for this field and allocate the following values:


  In section 3.1, the present document defines an Error Code field

This should point to section 4.1 again.

  inside the Admission Priority policy element.  IANA needs to create a
  registry for this field and allocate the following values:


Similar issues with references to the section 3.2 (should be 4.2).


8.2.  Informative References

  [I-D.ietf-nsis-qspec]
              Bader, A., Ash, G., Kappler, C., and D. Oran, "QoS NSLP
              QSPEC Template", draft-ietf-nsis-qspec-22 (work in
              progress), November 2009.

It looks like this should be Normative (due to the text in Section 4.1
in the paragraph talking about 8 bit Admission Priority field.

IANA comments:


QUESTIONS:

- In Action 4 the document specifies that a unique numerical value be
added to each entry but doesn't specify whether to start the numbers
at 0 or 1. IANA has assumed that numbering should start at 0. Is
this correct?

- The IANA Considerations section references Section 3.2, which does
not exist. To what section should this refer? Note that section
3.2 is referenced TWICE in the IANA Considerations Section, once for
the ALRP Namespace and once for the ALRP Priority. It looks like
this should be a reference to section 4.2.


Action 1:

Upon approval of this document, the IANA will make the following assignments
in the "Common Open Policy Service (COPS) Protocol" registry located at
http://www.iana.org/assignments/cops-parameters
sub-registry "P-types"

P-Type Description Reference
------- ---------------------------- ---------
[TBD] ADMISSION_PRI [RFC-tsvwg-emergency-rsvp-14]
[TBD] APP_RESOURCE_PRI [RFC-tsvwg-emergency-rsvp-14]


Action 2:

Upon approval of this document, the IANA will create the following
registry "Merge Strategies" located at http://www.iana.org/assignments/TBD

Allocation Procedures:

Value Policy
----- ------
4-127 IETF Review
128-240 First Come First Served
241-255 Private Use

Initial contents of this registry will be:

Value Description Reference
------- ---------------------------- ---------
0 Reserved [RFC-tsvwg-emergency-rsvp-14]
1 Take priority of highest QoS [RFC-tsvwg-emergency-rsvp-14]
2 Take highest priority [RFC-tsvwg-emergency-rsvp-14]
3 Force Error on heterogeneous merge [RFC-tsvwg-emergency-rsvp-14]


Action 3:

Upon approval of this document, the IANA will create the following
registry "Admission Priority Error Codes" located at
http://www.iana.org/assignments/TBD

Allocation Procedures:

Error Policy
----- ------
3-127 IETF Review
128-240 First Come First Served
241-255 Private Use

Initial contents of this registry will be:

Error Name Description Reference
------- ---------- ----------- ---------
0 NO_ERROR Value used for regular ADMISSION_PRI elements
[RFC-tsvwg-emergency-rsvp-14]
1 Reserved for consistency with [RFC3181] Error Codes
[RFC-tsvwg-emergency-rsvp-14]
2 HETEROGENEOUS This element encountered heterogeneous merge
[RFC-tsvwg-emergency-rsvp-14]


Action 4:

Upon approval of this document, the IANA will make the following
changes in ""Session Initiation Protocol (SIP) Parameters" registry located at
http://www.iana.org/assignments/sip-parameters
sub-registry "Resource-Priority Namespaces"

OLD:

Intended New warn- New resp.
Namespace Levels Algorithm code code Reference
------------ ------ -------------- ---------- --------- ---------
dsn 5 preemption no no [RFC4412]
drsn 6 preemption no no [RFC4412]
q735 5 preemption no no [RFC4412]
ets 5 queue no no [RFC4412]
wps 5 queue no no [RFC4412]
dsn-000000 10 preemption no no [RFC5478]
dsn-000001 10 preemption no no [RFC5478]
dsn-000002 10 preemption no no [RFC5478]
dsn-000003 10 preemption no no [RFC5478]
dsn-000004 10 preemption no no [RFC5478]
dsn-000005 10 preemption no no [RFC5478]
dsn-000006 10 preemption no no [RFC5478]
dsn-000007 10 preemption no no [RFC5478]
dsn-000008 10 preemption no no [RFC5478]
dsn-000009 10 preemption no no [RFC5478]
drsn-000000 10 preemption no no [RFC5478]
drsn-000001 10 preemption no no [RFC5478]
drsn-000002 10 preemption no no [RFC5478]
drsn-000003 10 preemption no no [RFC5478]
drsn-000004 10 preemption no no [RFC5478]
drsn-000005 10 preemption no no [RFC5478]
drsn-000006 10 preemption no no [RFC5478]
drsn-000007 10 preemption no no [RFC5478]
drsn-000008 10 preemption no no [RFC5478]
drsn-000009 10 preemption no no [RFC5478]
rts-000000 10 preemption no no [RFC5478]
rts-000001 10 preemption no no [RFC5478]
rts-000002 10 preemption no no [RFC5478]
rts-000003 10 preemption no no [RFC5478]
rts-000004 10 preemption no no [RFC5478]
rts-000005 10 preemption no no [RFC5478]
rts-000006 10 preemption no no [RFC5478]
rts-000007 10 preemption no no [RFC5478]
rts-000008 10 preemption no no [RFC5478]
rts-000009 10 preemption no no [RFC5478]
crts-000000 10 preemption no no [RFC5478]
crts-000001 10 preemption no no [RFC5478]
crts-000002 10 preemption no no [RFC5478]
crts-000003 10 preemption no no [RFC5478]
crts-000004 10 preemption no no [RFC5478]
crts-000005 10 preemption no no [RFC5478]
crts-000006 10 preemption no no [RFC5478]
crts-000007 10 preemption no no [RFC5478]
crts-000008 10 preemption no no [RFC5478]
crts-000009 10 preemption no no [RFC5478]

NEW:
Namespace
Numerical Intended New warn- New resp.
Namespace Value * Levels Algorithm code code Reference
------------ --------- ------ -------------- ---------- --------- ---------
dsn 0 5 preemption no no [RFC4412]
drsn 1 6 preemption no no [RFC4412]
q735 2 5 preemption no no [RFC4412]
ets 3 5 queue no no [RFC4412]
wps 4 5 queue no no [RFC4412]
dsn-000000 5 10 preemption no no [RFC5478]
dsn-000001 6 10 preemption no no [RFC5478]
dsn-000002 7 10 preemption no no [RFC5478]
dsn-000003 8 10 preemption no no [RFC5478]
dsn-000004 9 10 preemption no no [RFC5478]
dsn-000005 10 10 preemption no no [RFC5478]
dsn-000006 11 10 preemption no no [RFC5478]
dsn-000007 12 10 preemption no no [RFC5478]
dsn-000008 13 10 preemption no no [RFC5478]
dsn-000009 14 10 preemption no no [RFC5478]
drsn-000000 15 10 preemption no no [RFC5478]
drsn-000001 16 10 preemption no no [RFC5478]
drsn-000002 17 10 preemption no no [RFC5478]
drsn-000003 18 10 preemption no no [RFC5478]
drsn-000004 19 10 preemption no no [RFC5478]
drsn-000005 20 10 preemption no no [RFC5478]
drsn-000006 21 10 preemption no no [RFC5478]
drsn-000007 22 10 preemption no no [RFC5478]
drsn-000008 23 10 preemption no no [RFC5478]
drsn-000009 24 10 preemption no no [RFC5478]
rts-000000 25 10 preemption no no [RFC5478]
rts-000001 26 10 preemption no no [RFC5478]
rts-000002 27 10 preemption no no [RFC5478]
rts-000003 28 10 preemption no no [RFC5478]
rts-000004 29 10 preemption no no [RFC5478]
rts-000005 30 10 preemption no no [RFC5478]
rts-000006 31 10 preemption no no [RFC5478]
rts-000007 32 10 preemption no no [RFC5478]
rts-000008 33 10 preemption no no [RFC5478]
rts-000009 34 10 preemption no no [RFC5478]
crts-000000 35 10 preemption no no [RFC5478]
crts-000001 36 10 preemption no no [RFC5478]
crts-000002 37 10 preemption no no [RFC5478]
crts-000003 38 10 preemption no no [RFC5478]
crts-000004 39 10 preemption no no [RFC5478]
crts-000005 40 10 preemption no no [RFC5478]
crts-000006 41 10 preemption no no [RFC5478]
crts-000007 42 10 preemption no no [RFC5478]
crts-000008 43 10 preemption no no [RFC5478]
crts-000009 44 10 preemption no no [RFC5478]


* [RFC-tsvwg-emergency-rsvp-14]

Legend
------
Namespace Numerical Value = the unique numerical value identifying the namespace


Action 5:

Upon approval of this document, the IANA will make the following
changes in ""Session Initiation Protocol (SIP) Parameters" registry located at
http://www.iana.org/assignments/sip-parameters
sub-registry "Resource-Priority Priority-values"

OLD:

Namespace: drsn
Reference: [RFC4412]
Priority-Values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override", "flash-override-override"

Namespace: dsn
Reference: [RFC4412]
Priority-Values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override"

Namespace: q735
Reference: [RFC4412]
Priority values (least to greatest): "4", "3", "2", "1", "0"

Namespace: ets
Reference: [RFC4412]
Priority values (least to greatest): "4", "3", "2", "1", "0"

Namespace: wps
Reference: [RFC4412]
Priority values (least to greatest): "4", "3", "2", "1", "0"

Namespace: dsn-000000
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: dsn-000001
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: dsn-000002
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: dsn-000003
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: dsn-000004
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: dsn-000005
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: dsn-000006
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: dsn-000007
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: dsn-000008
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: dsn-000009
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: drsn-000000
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: drsn-000001
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: drsn-000002
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: drsn-000003
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: drsn-000004
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: drsn-000005
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: drsn-000006
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: drsn-000007
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: drsn-000008
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: drsn-000009
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: rts-000000
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: rts-000001
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: rts-000002
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: rts-000003
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: rts-000004
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: rts-000005
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: rts-000006
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: rts-000007
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: rts-000008
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: rts-000009
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: crts-000000
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: crts-000001
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: crts-000002
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: crts-000003
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: crts-000004
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: crts-000005
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: crts-000006
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: crts-000007
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: crts-000008
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

Namespace: crts-000009
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"

NEW:

Namespace: drsn
Reference: [RFC4412]
Priority-Values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override", "flash-override-override"
Priority Numerical Value *: 5, 4, 3, 2, 1, 0

Namespace: dsn
Reference: [RFC4412]
Priority-Values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override"
Priority Numerical Value *: 4, 3, 2, 1, 0

Namespace: q735
Reference: [RFC4412]
Priority values (least to greatest): "4", "3", "2", "1", "0"
Priority Numerical Value *: 4, 3, 2, 1, 0

Namespace: ets
Reference: [RFC4412]
Priority values (least to greatest): "4", "3", "2", "1", "0"
Priority Numerical Value *: 4, 3, 2, 1, 0

Namespace: wps
Reference: [RFC4412]
Priority values (least to greatest): "4", "3", "2", "1", "0"
Priority Numerical Value *: 4, 3, 2, 1, 0

Namespace: dsn-000000
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: dsn-000001
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: dsn-000002
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: dsn-000003
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: dsn-000004
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: dsn-000005
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: dsn-000006
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: dsn-000007
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: dsn-000008
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: dsn-000009
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: drsn-000000
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: drsn-000001
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: drsn-000002
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: drsn-000003
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: drsn-000004
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: drsn-000005
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: drsn-000006
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: drsn-000007
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: drsn-000008
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: drsn-000009
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: rts-000000
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: rts-000001
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: rts-000002
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: rts-000003
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: rts-000004
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: rts-000005
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: rts-000006
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: rts-000007
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: rts-000008
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: rts-000009
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: crts-000000
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: crts-000001
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: crts-000002
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: crts-000003
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: crts-000004
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: crts-000005
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: crts-000006
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: crts-000007
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: crts-000008
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Namespace: crts-000009
Reference: [RFC5478]
Priority-Values (least to greatest): "0", "1", "2", "3", "4", "5",
"6", "7", "8", "9"
Priority Numerical Value *: 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

* [RFC-tsvwg-emergency-rsvp-14]

Legend
------
Priority Numerical Value = the unique numerical value identifying
the priority within a namespace

We understand the above to be the only IANA Actions for this document.

This is the WG shepherd writeup for draft-ietf-tsvwg-emergency-rsvp for
publication as Proposed Standard:

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Gorry Fairhurst is the shepherd and he thinks it is ready for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Version -07 received review from a reasonably wide community. This
version received substantial IESG feedback that lead to significant
changes to the document, including new language on sessions (08,11),
revised language defining use in controlled environments (09,10) and
restricting intra-domain cases (12), updated security considerations (09).

The current draft (-14) provides significant re-focussing to remove
references to emergency use. Following comments by Ron Bonica during
IESG review, a sentence was added to the abstract stating: "Based on
current security concerns, these extensions are targeting applicability
within a single administrative domain."

The present revision was discussed by the TSVWG (including IETF-75) and
in 2 week WGLC that concluded on 17th October 2009.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

No. The shepherd has no concerns regarding the review.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No concerns with the extension mechanisms.

The authors were proposing "within controlled environments" instead of a
"single administrative domain". This would seem to me to align with
other use-cases for RSVP. It would be useful to check whether Ron still
objects to using this wording.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The latest version has been discussed by the TSVWG and there was consensus
to publish the updated document. v07 was also reviewed by participants
from the NSIS and DIME WGs due to overlap in namespace.
This was resolved jointly. There was WG consensus to publish the updated
rev -12 document as a generic RSVP mechanism.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

Yes, and this document is intended for Proposed standard.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes.

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

Yes, version -07 was also verified and seen to be consistent with documents
from the NSIS and DIME WGs.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Not appropriate.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

Some applications require the ability to provide an elevated
probability of session establishment to specific sessions in times of
network congestion. When supported over the Internet Protocol suite,
this may be facilitated through a network layer admission control
solution that supports prioritized access to resources (e.g.,
bandwidth). These resources may be explicitly set aside for
prioritized sessions, or may be shared with other sessions. This
document specifies extensions to the Resource reSerVation Protocol
(RSVP) that can be used to support such an admission priority
capability at the network layer.

Working Group Summary

There is WG consensus for publishing this document.

Document Quality

This document has been well reviewed by the WG. It now includes changes
after IESG feedback and updates after further discussion in TSVWG.

Personnel

Magnus Westerlund was previously the WG shepherd of an earlier
submission and is now the responsible AD.

[Ballot comment]
This draft is still not going to work for emergency calls that cross domains. It is not limited to a single private domain and I can't see how the links between domains would work. I can't see how it would meet needs for emergency calls.

This document has more than 5 abstains due to the following issues:

- The method does not work for a generalized emergency service on the Internet.
- It has unanswered operational security issues.

[Ballot comment]
This draft is still not going to work for emergency calls that cross domains. It is not limited to a single private domain and I can't see how the links between domains would work. I can't see how it would meet needs for emergency calls.

[Ballot comment]
I had a DISCUSS concerning the fact that this document is not fully in line with the IETF requirements for an ETS as specified in RFC 3689 and RFC 3690.  I am aware that the architecture issues and possible update or 3689/3690 to synchronize with the current thinking of ETS in the IETF and in the industry are out of scope for this document. It would have helped however to add informational references of other documents that may describe requirements and architecture (like GETS that came up during the discussions).

[Ballot comment]
After the IESG discussion on this, I believe the following 3 changes
would make me comfortable with standards track publication.  For
informational status, I believe the first and second items need to
be addressed.

1. Having RAO rate limiting as merely a recommendation is not acceptable.
  I believe RAO rate limiting has to be mandatory-to-implement part of
  this proposal to prevent harm to the Internet from this proposal.
  Assuming this deploys, it's likely additional RAO defense mechanisms
  will be developed by the industry and be helpful, but a mandatory
  baseline is important.

2. It is my understanding there is no way to protect this mechanism
  from denial of service.  A skilled attacker can generate a flood
  of RAO packets in this format that will almost certainly prevent
  valid RAO packets from being processed.  The document needs to make
  this very clear to avoid false expectations.

3. I believe BCP 61 (RFC 3365) applies to this specification, and the
  current specification does not adequately meet that BCP.

I am open to debate as this is not my area of primary expertise.

[Ballot discuss]
In the abstract and introduction, I suggest changing the definitive "thereby" to "potentially" - you don't know for sure if elevating priority of the message over a constrained part of the network will elevate the probability of end to end session establishment.

Also, the Abstract is rather long now (3 paragraphs) - not sure what the RFC Editor will do with that, but I suspect it could be reduced considerably. Perhaps a short sentence warning that this must only be used in a constrained environment is in order for the abstract, and keep the longer paragraph for the Introduction or even its own "warning" section for visibility.

Part of what I am suggesting can be done with an RFC Editor's note:

OLD:
(thereby elevating the end to end session establishment probability).

NEW:
(Potentially elevating the end to end session establishment probability).

[Ballot discuss]
I largely agree with comments by Ron, Chris, David and Mark,
but I'd like to discuss this on the telechat before deciding
whether to go to Abstain or No Objection.

[Ballot comment]
I have read this document, but I'm still confused by the architecture and by the discussions about the architecture.  The security model is "walled garden" as far as I can tell, but the authors have argued that this work is within the IETF's remit as traffic will go on the open Internet. 

I also don't understand the inclusion of multicast merging rules.

[Ballot comment]
I am waiting for more information from Routing ADs on use of RAO in this constrained environment before deciding what position to take. I am happy with the updated document specifying the domain of applicability for the this.

[Ballot comment]
I am not convinced either this proposal or any similar proposal can deploy
in the real world.  Furthermore, it would be harmful to the Internet to
standardize a protocol that claims to provide prioritized traffic for
emergency services when we don't believe it will deploy.  I might be
comfortable supporting an experiment in this area although I'm dubious
such an experiment can actually succeed.

[Ballot comment]
I support Ross's concerns regarding the router alerts and resulting security vulnerabilities.  At a
minimum, this aspect needs to be highlighted in the security considerations.

[Ballot discuss]
I don't understand how the authorization would work outside of a transitive trust walled garden environment. Given the fate of IEPREP, and the discussion about this draft in ECRIT, I don't think the IETF believes this is a reasonable basis on which to build ETS systems for the internet and thus question the IETF consensus on this draft. If it was scoped to GETS like service for private networks, I would not have a problem with it - short of something along thoses lines, I will likely move to abstain. And, I support the routing ADs position on routing.

[Ballot discuss]
I have a couple of closely related concerns with this draft.

My first concern is very similar to Ron's discuss comment: It seems to me that this relies on RSVP signaling, and my understanding is that this relies on the router alert option, which most ISPs don't allow to enter their networks from customer sites. I therefore don't understand how this capability is actually going to be deployed.

My second concern relates to the possibility that if this capability were widely deployed (which I expect it needs to be to be useful), then routers would need to accept router alerts coming from whereever the emergency provider happens to be (ie, anywhere). This would open up the ability for a wide range of systems to send traffic to the router's control plane, which would open up a vector for DOS attack. I personally can't think of any way to protect against this except for essentially universal deployment of rate limits on the incoming router alert messages.

[Ballot discuss]
Section 1 needs some clarifications about the scope and applicability
of this document.

First, given that this document cites RFC 3689 for the overall
requirements, and 3689 says that "In cases where emergency related
flows occur outside of controlled environments, the development of
technologies based on admission control is not recommended as the
foundation of emergency services", a short description about what
kind(s) of controlled environments this is intended for should be added.

Second, it would be a good idea to emphasize that this document
(and RFC 3689/3690) deals with emergency sessions established by
*authorized* users, and say explicitly that emergency services where
anyone can establish a session (like 911 and things ECRIT WG is
working on) are beyond the scope of this document.

[Ballot discuss]
Is this intended to work on the public Internet or on some private network? If the former, how will it in cases where the ISP blocks datagrams containing the IPv4 router alert option?

[Ballot discuss]
The applicability of the extensions defined in this document is not described in terms consistent with other IETF work. From discussions with the authors it looks like this is intentional as the solution in the document describes an authority-to-any type of ETS communications currently not covered explicitly by ETS requirements documents as RFC3689/3690 or other emergency communication work in the IETF, but present in other documents in the industry or government requirements.  It is however necessary that when we define a 'module' i.e.
a piece of solution in an RFC we include references to what requirements or architecture work they are based upon. If the situation is that the requirements in 3689/3690 are at least partially timed out and this proposed RFC is answering a different set of requirements and fitting in different architecture agreed out of the IETF, I believe that those external references should be mentioned and referred to and not (only) the IETF documents as in the current list of references.

IANA Last Call comments:

IANA has questions:

- In Action 3, the Resource-Priority Priority-values registry, you
ask IANA to put specific numbers into the registry for the items
based on decending priority. How is IANA supposed to allocate new
values in a namespace? Based on the current request new values
would necessitate renumbering the whole namespace, which would
invalidate existing protocols.

- In section 3.1, do you want a registry for the Merge Strategy or
Error Code?

Action 1:

Upon approval of this document, the IANA will make the following
assignments in the "Common Open Policy Service (COPS) Protocol"
registry located at
http://www.iana.org/assignments/cops-parameters
sub-registry "P-types"

P-Type Description Reference
------- ---------------------------- ---------
[tbd] Admission Priority Policy [RFC-tsvwg-emergency-rsvp-07]
[tbd] Application-Level Resource Priority Policy [RFC-tsvwg-emergency-rsvp-07]


Action 2:

Upon approval of this document, the IANA will make the following
changes in "Session Initiation Protocol (SIP) Parameters" registry
located at http://www.iana.org/assignments/sip-parameters
sub-registry "Resource-Priority Namespaces"

OLD:

Intended New warn- New resp.
Namespace Levels Algorithm code code Reference
--------- ------ ---------------- --------- --------- ---------
dsn 5 preemption no no [RFC4412]
drsn 6 preemption no no [RFC4412]
q735 5 preemption no no [RFC4412]
ets 5 queue no no [RFC4412]
wps 5 queue no no [RFC4412]

Legend
------
Namespace = the unique string identifying the namespace
Levels = the number of priority-values within the namespace
Algorithm = Intended operational behavior of SIP elements
implementing this namespace
New Warn code = New Warning Codes (warn-codes) introduced by this namespace
New Resp. code = New SIP response codes introduced by this namespace
Reference = IETF document reference for this namespace


NEW:

Namespace
Numerical Intended New warn- New resp.
Namespace Value * Levels Algorithm code code Reference
--------- ----- ------ ---------------- --------- --------- ---------
dsn 1 5 preemption no no [RFC4412]
drsn 2 6 preemption no no [RFC4412]
q735 3 5 preemption no no [RFC4412]
ets 4 5 queue no no [RFC4412]
wps 5 5 queue no no [RFC4412]

Legend
------
Namespace = the unique string identifying the namespace
Namespace Numerical Value = the unique numerical value identifying the namespace
Levels = the number of priority-values within the namespace
Algorithm = Intended operational behavior of SIP elements
implementing this namespace
New Warn code = New Warning Codes (warn-codes) introduced by this namespace
New Resp. code = New SIP response codes introduced by this namespace
Reference = IETF document reference for this namespace

* [RFC-tsvwg-emergency-rsvp-07]


Action 3:

[ SEE IANA QUESTION ]

Upon approval of this document, the IANA will make the following
changes in "Session Initiation Protocol (SIP) Parameters" registry
located at http://www.iana.org/assignments/sip-parameters
sub-registry "Resource-Priority Priority-values"

OLD:

Namespace: drsn
Reference: [RFC4412]
Priority-Values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override", "flash-override-override"

Namespace: dsn
Reference: [RFC4412]
Priority-Values (least to greatest): "routine", "priority",
"immediate", "flash", "flash-override"

Namespace: q735
Reference: [RFC4412]
Priority values (least to greatest): "4", "3", "2", "1", "0"

Namespace: ets
Reference: [RFC4412]
Priority values (least to greatest): "4", "3", "2", "1", "0"

Namespace: wps
Reference: [RFC4412]
Priority values (least to greatest): "4", "3", "2", "1", "0"


NEW:

Namespace: drsn
Reference: [RFC4412]

Priority-Values (least to greatest) Priority Numerical Value *
----------------------------------- --------------------------
"routine" 5
"priority" 4
"immediate" 3
"flash" 2
"flash-override" 1
"flash-override-override" 0

Namespace: dsn
Reference: [RFC4412]

Priority-Values (least to greatest) Priority Numerical Value *
----------------------------------- --------------------------
"routine" 4
"priority" 3
"immediate" 2
"flash" 1
"flash-override" 0

Namespace: q735
Reference: [RFC4412]

Priority-Values (least to greatest) Priority Numerical Value *
----------------------------------- --------------------------
"4" 4
"3" 3
"2" 2
"1" 1
"0" 0

Namespace: ets
Reference: [RFC4412]

Priority-Values (least to greatest) Priority Numerical Value *
----------------------------------- --------------------------
"4" 4
"3" 3
"2" 2
"1" 1
"0" 0

Namespace: wps
Reference: [RFC4412]

Priority-Values (least to greatest) Priority Numerical Value *
----------------------------------- --------------------------
"4" 4
"3" 3
"2" 2
"1" 1
"0" 0


Legend:
------
Namespace Numerical Value = the unique numerical value
identifying the namespace

* [RFC-tsvwg-emergency-rsvp-07]


We understand the above to be the only IANA Actions for this
document.

This is the WG shepherd writeup for draft-ietf-tsvwg-emergecny-rsvp-07 for publication as Proposed Standard:


  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Magnus Westerlund is the shepherd and he thinks it is ready for publication.


  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

It has gotten sufficient review from a reasonably wide community. Shepherd has no concerns regarding the review.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

No.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

It is an okay consensus from a reasonable number of WG participants.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.


Yes, and this document is intended for Proposed standard.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

Yes


  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

Yes, also verified to be consistent with documents from NSIS and DIME WG.


  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

No, such sections.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary

  An Emergency Telecommunications Service (ETS) requires the ability to
  provide an elevated probability of session establishment to an
  authorized user in times of network congestion (typically, during a
  crisis).  When supported over the Internet Protocol suite, this may
  be facilitated through a network layer admission control solution,
  which supports prioritized access to resources (e.g., bandwidth).
  These resources may be explicitly set aside for emergency services,
  or they may be shared with other sessions.

  This document specifies RSVP extensions that can be used to support
  such an admission priority capability at the network layer.  Note
  that these extensions represent one possible solution component in
  satisfying ETS requirements.  Other solution components, or other
  solutions, are outside the scope of this document.

          Working Group Summary
There is a good consensus on publishing this document.

          Document Quality
This document has been well reviewed by the WG and also participants from NSIS and the DIME WG due to overlap in namespace that was resolved jointly.

          Personnel
Magnus Westerlund is both WG shepherd and responsible AD.