Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area
draft-peterson-rai-rfc3427bis-04

[Ballot comment]
Section 5:

3.  Documents that specify Informational headers pass through an
      Expert Review system.

Are these experts already in place or do they need to be nominates as this document is approved?

[Ballot discuss]
I am a supporter of the changes brought recently in RAI and I believe that they have already had a positive impact on having new work examined and approved faster and taking out of limbo a few items that were long stuck in SIP, SIPPING or other. I plan to vote 'yes' on this document but I have concerns about the following two pieces of text:

In Section 2.2 the following seems umbiguous and open to unwanted interpretations:

  While it does not have the traditional deliverables of
  a working group, DISPATCH may at the discretion of its chairs adopt
  milestones such as the production of charter text for a BoF or
  working group, a "-00" problem statement document that explicates a
  proposed work effort, or a document explaining why a particular
  direction for standards development was not pursued.

I am concerned by the 'at the discretion of its chairs' aspect. DISPATCH plays a role of filter and decides to a large extend what is being done or not done in the RAI area. If a certain proposal would fall within the clear realm of another WG best chances would be that adding such work items would be a subject for rechartering. Leaving such decisions completly at the discretion of the chairs seems inapropriate.

Actually I do not see this words aplied in the DISPATCH practice up to now. The charter and list of deliverables was not updated by the chairs or IESG action from the WG approval. On the other hands the WG undertook new items and this is fine - but this is known only to those who followed closely the WG list. I think that the wording here should mention that such decisions belong to the chairs in consultation with the ADs, that they need to be displayed on the WG page, and the IESG informed about new work items.

In Section 3:

  The DISPATCH working group may
  also evaluate and approve proposals for extensions if the
  requirements are judged to be appropriate to SIP, but are not
  sufficiently general for standards track activity.

It is not clear what is approved here. From Section 2.2 I understand that DISPATCH identifies and makes recommendations about new work in the SIP space and identifies the proper venue, but does not undertake the work itself. If a work is 'not sufficiently general for standards track activity' what kind of recommendation is being made?

[Ballot discuss]
I can't begin to express how important I think this work is. i want ot vote "Yes".

But...

In support of the Discusses about the "Updates RFC3696" I would like to point out that this document also updates the IANA policy in RFC 3265 and should be flagged with an "Updates" accordingly.

I think that section 8 needs to be recast from the useful change log that was in place as the I-D was developed (but which the RFC Editor might be tempted to remove) into a description of the changes in the new RFC-to-be compared with RFC 3427. This is just a matter of merging the sections and sorting out the titles. (Hopefully this *is* all the changes.)

[Ballot comment]
I can't begin to express how important I think this work is. i want ot vote "Yes".

But...

In support of the Discusses about the "Updates RFC3696" I would like to point out that this document also updates the IANA policy in RFC 3265 and should be flagged with an "Updates" accordingly.

I think that section 8 needs to be recast from the useful change log that was in place as the I-D was developed (but which the RFC Editor might be tempted to remove) into a description of the changes in the new RFC-to-be compared with RFC 3427. This is just a matter of merging the sections and sorting out the titles. (Hopefully this *is* all the changes.)

[Ballot discuss]
Steve Hanna's secdir review (28 July 2009) raised significant issues regarding the
adequacy of security review under the relaxed IANA registration rules.  Has there
been a response to this review?  I have not seen one...

[Ballot comment]
I am agreeing with Magnus' DISCUSS.

4.1.  SIP Event Packages

[...]

  6.  The proposed package MUST be clearly documented in an
      (Individual) Informational RFC, and registered with IANA.  The
      package MUST document all the package considerations required in
      Section 5 of SIP events [6].

Is it Ok for documenting new even packages in Standard Track or Experimental individual submissions though AD?

[Ballot discuss]
References [3], [4], [6] are not defined (it looks like you've changed the way how you reference documents). You also need to make sure they are listed as Normative/Informative.

RFC 3969 is not listed as a Normative Reference.

[Ballot comment]
I am agreeing with Magnus' DISCUSS.

4.1.  SIP Event Packages

[...]

  6.  The proposed package MUST be clearly documented in an
      (Individual) Informational RFC, and registered with IANA.  The
      package MUST document all the package considerations required in
      Section 5 of SIP events [6].

Is it Ok for documenting new even packages in Standard Track or Experimental individual submissions though AD?

[Ballot discuss]
Section 7.1:

To me this appears to be an update of RFC 3969. The intent is clearly to change the IANA consideration section in RFC 3969, I think this should be made clear with an "Updates" header referencing 3969 and in abstract and introduction.

Document:
Change Process for the Session Initiation Protocol (SIP)
draft-peterson-rai-rfc3427bis-03
(Best Current Practice)


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

Jon Peterson is the document shepherd. I have personally reviewed this
version of the document, and it 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?

The document has been reviewed on the RAI Area mailing list, as well as
received significant meeting-time discussion at two IETF meetings.

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

None.

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

None. No IPR disclosures.

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

Strong consensus for publishing.

    (1.f) Has anyone threatened an appeal or otherwise indicated extreme
          discontent? If so, please summarise 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.)

None.

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

Checked with ID nits 2.11.11: no issues.

    (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].

References are split, and there are no downrefs.

    (1.i) Has the Document Shepherd verified that the document IANA
          consideration 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 [RFC5226]. If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

This document contains substantial considerations for the IANA, including a
clarification of the procedures in RFC3969. No new registries are created,
however. The document requires the appointment of a designated expert; we
proposed that the experts be the chairs of the SIPCORE working group
(currently Adam Roach and Gonzalo Camarillo).

    (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 formal language in the document.

    (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

This memo documents a process intended to apply architectural
discipline to the future development of the Session Initiation
Protocol (SIP).  There have been concerns with regards to new SIP
proposals.  Specifically, that the addition of new SIP features can be
damaging towards security and/or greatly increase the complexity of
the protocol.  The Real-Time Applications and Infrastructure area
directors, in consultation with area participants and working group
chairs, have provided guidance for SIP modifications and extensions.

          Working Group Summary

Although this is not a product of any working group, it received
considerable attention on the RAI Area mailing list, as well as
face time in RAI area meetings. The mailing list supports the
advancement of this specification.

          Document Quality

The document has received extended review on the RAI mailing list.

IANA questions/comments:

- In Section 4.1 part 1, the document mentions a Designated Expert.
In Action 3, however, the document asks for IETF Review.

IESG Note: Expert Reviewer assignment required for Action 2


Action 1:

Upon approval of this document, IANA will make the following
changes in the "Methods and Response Codes" registry at
http://www.iana.org/assignments/sip-parameters

OLD:

RFC publication (section 27.4)

NEW:

Standards Action


Action 2:

Upon approval of this document, IANA will make the following
changes in the "Header Fields" registry at
http://www.iana.org/assignments/sip-parameters

OLD:

RFC publication (section 27.3)

NEW:

RFC Publication or Designated Expert


Action 3:

Upon approval of this document, IANA will make the following
changes in the "Event Packages" registry at
http://www.iana.org/assignments/sip-events

OLD:

Informational RFC approved by the IESG

NEW:

IETF Review


Action 4:

Upon approval of this document, IANA will make the following
changes in the "SIP/SIPS URI Parameters" registry at
http://www.iana.org/assignments/sip-parameters

OLD:

Specification Required

NEW:

Standards Action

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