Communications Resource Priority for the Session Initiation Protocol (SIP)
draft-ietf-sip-resource-priority-10

[Ballot comment]
doc: draft-ietf-sipping-reason-header-for-preemption-04.txt

  !! Missing citation for Normative reference:
  P018 L028:  [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,

doc: draft-ietf-sip-resource-priority-10.txt

  !! Missing citation for Informative reference:
  P034 L015:    [RFC3324]  Watson, M., "Short Term Requirements for
    Network Asserted

Mmmm...
14.1  Normative References

  [I-D.ietf-sipping-reason-header-for-preemption]
              Polk, J., "Extending the Session Initiation Protocol
              Reason Header for Preemption  Events",
              draft-ietf-sipping-reason-header-for-preemption-02 (work
              in progress), August 2004.

While rev 04 is on this ballot. Oh well.

IANA Comments:
Upon approval of this document the IANA will register/create the following:
2 SIP headers ('Resource-Priority' and 'Accept-Resource-Priority')
1 SIP OPTION tag ('resource-priority')
1 4xx error code (response code 417 - Unknown Resource-Priority)
1 new registry for Resource-Priority namespaces (5 initial registrations)
1 new registry for Resource-Priority and priority-values (5 initial registrations)

[Ballot comment]
Section 9 of draft-ietf-sip-resource-priority-10 says:
  >
  > There should not be a unique namespace for different jurisdictions.
  > This will greatly increase interoperability and reduce development
  > time, and probably reduce future confusion if there is ever a need
  > to map one namespace to another in an interworking function.
  >
  I find this wording misleading.  I propose:
  >
  > There should be a single namespace for all jurisdictions. This will
  > greatly increase interoperability and reduce development time, and
  > probably reduce future confusion if there is ever a need to map one
  > namespace to another in an interworking function.

  Please correct the typo in section 11.4 of
  draft-ietf-sip-resource-priority-10:
  >
  > The authentication may be based on capabilities and noms, ...
 
  Please ensure that "S/MIME" is not split across line breaks.

[Ballot comment]
Section 9 of draft-ietf-sip-resource-priority-10 says:
  >
  > There should not be a unique namespace for different jurisdictions.
  > This will greatly increase interoperability and reduce development
  > time, and probably reduce future confusion if there is ever a need
  > to map one namespace to another in an interworking function.
  >
  I find this wording misleading.  I propose:
  >
  > There should be a single namespace for all jurisdictions. This will
  > greatly increase interoperability and reduce development time, and
  > probably reduce future confusion if there is ever a need to map one
  > namespace to another in an interworking function.

  Please correct the type in section 11.4 of
  draft-ietf-sip-resource-priority-10:
  >
  > The authentication may be based on capabilities and noms, ...
 
  Please ensure that "S/MIME" is not split across line breaks.

[Ballot discuss]
In Section 4.2, draft-ietf-sip-resource-priority-10.txt says:

  1.  If the RP actor recognizes none of the name spaces, treat the
      request as if it had no 'Resource-Priority' header field.

  2.  Ascertain that the request is authorized according to local
      policy to use the priority levels indicated.  If the request is
      not authorized, reject it.  Examples of authorization policies
      are discussed in Security Considerations (Section 11).

I'm wondering about the decision to reject, rather than treat as
if no "Resource-Priority" header field was present.  Reading through
the Security considerations section, the case where there are multiple
namespaces asserted seems to create some odd corner cases.  An originating
RP, for example, might assert priority as foo.1, bar.1.  If it traverses a proxy
that understands neither, it goes forward as normal priority.  If it traverses a
proxy that understands foo.1 (but not bar.1), it goes forward with foo.1 priority
if it shows as authorized, but is rejected if the proxy shows it unauthorized (even
if it would be authorized for bar.1).  If the originating RP asserted only bar.1 and bad actor
inserted foo.1, this is particularly a problem.  That would be mitigated if the error
code indicated which Namespace was checked to cause the rejection, but I did not
see how that would work in the draft (it seemed, in particular, that you might end
up getting back codes that are only valid for namespaces the RP did not understand).

[Note]: 'These docs were much reviewed (by Chairs, WG and me) on architecture and details, in WG.
The reason-header update submitted for publication a long time before its companion,
but waited, and then had updates for it.' added by Allison Mankin

[Note]: 'These documents were much reviewed (by Chairs, WG and me) on architecture and details, in WG.
The reason-header update submitted for publication a long time before its companion,
but waited, and then had updates for it.' added by Allison Mankin

[Note]: 'These documents were much reviewed (by Chairs, WG and me) on architecture and details, in WG.
The document on error codes was submitted for publication a long time before its companion,
but waited, and then had updates for it.' added by Allison Mankin