Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)
draft-ietf-mmusic-qos-identification-03

[Ballot discuss]
I would suggest that the document be clear that it can only deal
with the host capability negotiation, but that the larger problem
of whether the network supports this is not solved by this. Discussion
of some of the implications of this would also be useful.

[Ballot discuss]
Section 3:
1. ABNF error

  attribute              = qos-mech-send-attr
  attribute              = qos-mech-recv-attr

  qos-mech-send-attr    = "qos-mech-send" ":" *(SP qos-mech)
  qos-mech-recv-attr    = "qos-mech-recv" ":" *(SP qos-mech)

  qos-mech              = rsvp / nsis / extension-mech
  extension-mech        = token


To resolve the first double definition one could use the incremental alternative defintion, i.e. "=/" thus making it into:

  attribute              =/ qos-mech-send-attr
  attribute              =/ qos-mech-recv-attr

  qos-mech-send-attr    = "qos-mech-send" ":" *(SP qos-mech)
  qos-mech-recv-attr    = "qos-mech-recv" ":" *(SP qos-mech)

  qos-mech              = "rsvp" / "nsis" / extension-mech
  extension-mech        = token

2. Secondly I think the character spacing rule might be to tight that many will fail to use it correctly. Even the document is managing to break it in the example in the same section:

    m=audio 50000 RTP/AVP 0
    a=qos-mech-send:rsvp nsis
    a=qos-mech-recv:rsvp nsis

Note that there are no space character between the ":" and the identifier "rsvp" in the example which the document requires. I would suggest to loosen the usage of space. However that makes the definition slightly bulkier:

  qos-mech-send-attr    = "qos-mech-send" ":" [[SP] qos-mech *(SP qos-mech)]

This would allow for 0 or 1 space after the : and then only one space between each following identifier.

So either correct the example or change the syntax to allow for both.

3. Using RFC 4080 as a reference to NSIS QoS mechanism is a really poor choice. NSIS is a general signalling framework. Thus you actually need to reference the NSLP that does QoS negotiation: draft-ietf-nsis-qos-nslp-16

There might in the future be a another variant for QoS negotiaton using the NSIS framework. Although I hope not. I think leaving the identifier as nsis is okay while the reference needs to change.

[Ballot comment]
As an implementor of an application on a host acting as a, say, a
SIP phone I do not not understand how these mechanisms are going
to help me at all.

First, how do I know if the underlying OS version supports NSIS,
for instance? And even if I do know that, that says *nothing* about
the support in the one place that truly needs it, namely in the
routers in between. So all this appears to do is negotiation of
mechanisms between two parties who have no clue about what mechanisms
are available.

Are there significant enough RSVP, NSIS, etc. deployments where
specialized applications can actually make use of this?

[Ballot comment]
As an implementor of an application on a host acting as a, say, a
SIP phone I do not not understand how these mechanisms are going
to help me at all.

First, how do I know if the underlying OS version supports NSIS,
for instance? And even if I do know that, that says *nothing* about
the support in the one place that truly needs it, namely in the
routers in between.

[Ballot discuss]
Section 3:
1. ABNF error

  attribute              = qos-mech-send-attr
  attribute              = qos-mech-recv-attr

  qos-mech-send-attr    = "qos-mech-send" ":" *(SP qos-mech)
  qos-mech-recv-attr    = "qos-mech-recv" ":" *(SP qos-mech)

  qos-mech              = rsvp / nsis / extension-mech
  extension-mech        = token


To resolve the first double definition one could use the incremental alternative defintion, i.e. "=/" thus making it into:

  attribute              =/ qos-mech-send-attr
  attribute              =/ qos-mech-recv-attr

  qos-mech-send-attr    = "qos-mech-send" ":" *(SP qos-mech)
  qos-mech-recv-attr    = "qos-mech-recv" ":" *(SP qos-mech)

  qos-mech              = rsvp / nsis / extension-mech
  extension-mech        = token

2. Secondly I think the character spacing rule might be to tight that many will fail to use it correctly. Even the document is managing to break it in the example in the same section:

    m=audio 50000 RTP/AVP 0
    a=qos-mech-send:rsvp nsis
    a=qos-mech-recv:rsvp nsis

Note that there are no space character between the ":" and the identifier "rsvp" in the example which the document requires. I would suggest to loosen the usage of space. However that makes the definition slightly bulkier:

  qos-mech-send-attr    = "qos-mech-send" ":" [[SP] qos-mech *(SP qos-mech)]

This would allow for 0 or 1 space after the : and then only one space between each following identifier.

So either correct the example or change the syntax to allow for both.

3. Using RFC 4080 as a reference to NSIS QoS mechanism is a really poor choice. NSIS is a general signalling framework. Thus you actually need to reference the NSLP that does QoS negotiation: draft-ietf-nsis-qos-nslp-16

There might in the future be a another variant for QoS negotiaton using the NSIS framework. Although I hope not. I think leaving the identifier as nsis is okay while the reference needs to change.

[Ballot comment]
I don't think the following BNF in section 3 is quite right:

  qos-mech              = rsvp / nsis / extension-mech
  extension-mech        = token

since rsvp and nsis are actually tokens according to the
IANA Considerations.  The intent is clear enough, so this
is just a comment...

[Ballot discuss]
I am concerned by the lack of mention of operational implications related to the QoS negotiations made possible by the mechanism described in this document. There is always a chance that a common mechanism cannot be negotiated, and there is no indication what tools should be made available for such a situation. As a minimum I would suggest that the support for the QoS indication and the sorted lists of mechanisms available on send and received be made available for endpoints to help an operator to debug fault situations.

IANA Last Call comments:

Action #1: (6.1+ 6.2)

Upon approval of this document, the IANA will make the following
assignments in the "att-field (both session and media level)"
registry at
http://www.iana.org/assignments/sdp-parameters

Type SDP Name Reference
---- ------------------ ---------
qos-mech-send [RFC-mmusic-qos-identification-01]
qos-mech-recv [RFC-mmusic-qos-identification-01]


Action #2:
Upon approval of this document, the IANA will create a new
registry at http://www.iana.org/assignments/sdp-parameters

Registry Name: QoS Mechanism Tokens
Registration Procedure: Specification Required

Initial contents of this sub-registry will be:
QoS Mechanism Reference
---------------------------- ---------
rsvp [RFC2205]
nsis [RFC4080]

Requested Publication Status: Proposed Standard
Document Shepherd: Jean-Francois Mule (jf.mule@cablelabs.com)

--------------------------------------------------------------------
--- (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?

Jean-Francois Mule, MMUSIC co-chair (jf.mule@cablelabs.com) is the
Document Shepherd. He has personally reviewed this version of the
Internet-Draft.
Based on the WG discussion, WGLC and Document Shepherd review, I believe
this version is ready for forwarding to the IESG 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?

Yes, no concerns.

--- (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?


I have no particular concerns re: more reviews.


--- (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. 
   
No concerns.

    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.  A search at: https://datatracker.ietf.org/ipr/search/ gave the
following results:
Total number of IPR disclosures found: 0
Total number of documents searched: 1
Search result on draft-ietf-mmusic-qos-identification, "Quality of
Service (QoS) Mechanism Selection in the Session Description Protocol
(SDP)"
No IPR disclosures related to
draft-ietf-mmusic-qos-identification have been submitted



--- (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?

There is solid consensus.

--- (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?


Yes, draft-01 was checked against idnits 2.08.10.
3 errors are found due to outdated references which have no impact on
the technical requirements contained in this document.  These errors can
be addressed during the next steps of the publication process.

http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-mmu
sic-qos-identification-01.txt
idnits 2.08.10

tmp/draft-ietf-mmusic-qos-identification-01.txt:

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC
4748:

------------------------------------------------------------------------
----

    No issues found here.

  Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt:

------------------------------------------------------------------------
----

    No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:

------------------------------------------------------------------------
----

    No issues found here.

  Miscellaneous warnings:

------------------------------------------------------------------------
----

    No issues found here.

  Checking references for intended status: Proposed Standard

------------------------------------------------------------------------
----

    (See RFCs 3967 and 4897 for information about using normative
references
    to lower-maturity documents in RFCs)

  ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)

  ** Downref: Normative reference to an Informational RFC: RFC 4080

  ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234)


    Summary: 3 errors (**), 0 warnings (==), 0 comments (--).

    Run idnits with the --verbose option for more detailed information
about
    the items above.

------------------------------------------------------------------------
--------



--- (1.h)
    Has the document split its references into normative and
    informative? 
Yes.

    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? 
No.

    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.
  ** Downref: Normative reference to an Informational RFC: RFC 4080


--- (1.i)
    Has the Document Shepherd verified that the document's IANA
    Considerations section exists and is consistent with the body
    of the document? 
Yes.

    If the document specifies protocol
    extensions, are reservations requested in appropriate IANA
    registries?
Yes.

    Are the IANA registries clearly identified?
Yes.

    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 ("Specification Required" policy per RFC 2434 and all the required
information is provided).


--- (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?

Yes, checked aBNF with http://www.apps.ietf.org/abnf.html. Results
included undefined and unreferenced rules (to be expected) but no
errors.
unreferenced rule: attribute
undefined rule: rsvp
undefined rule: nsis
undefined rule: token
ABNF validation (version 1.0) completed


--- (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
        Relevant content can frequently be found in the abstract
        and/or introduction of the document.  If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

    Working Group Summary
        Was there anything in the WG process that is worth noting?
        For example, was there controversy about particular points
        or were there decisions where the consensus was
        particularly rough?
    Document Quality
        Are there existing implementations of the protocol?  Have a
        significant number of vendors indicated their plan to
        implement the specification?  Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues?  If
        there was a MIB Doctor, Media Type, or other Expert Review,
        what was its course (briefly)?  In the case of a Media Type
        Review, on what date was the request posted?

    Personnel
        Who is the Document Shepherd for this document?  Who is the
        Responsible Area Director?  If the document requires IANA
        experts(s), insert 'The IANA Expert(s) for the registries
        in this document are .'


Here is the proposed Document Announcement Write-Up:

        Technical Summary
This document defines SDP extensions for endpoints to indicate
explicitly which QoS mechanisms they support end-to-end.
 

          Working Group Summary
The MMUSIC Working Group has consensus to publish this document as a
Proposed Standard.

          Document Quality
The document received reviews from Dave Oran and Flemming Andreasen.
   
      Personnel
The Document Shepherd is Jean-Francois Mule, and the Responsible Area
Director is Cullen Jennings.