ietf
[Top] [All Lists]

Re: Last Call: <draft-campbell-art-rfc5727-update-02.txt> (Improving the Organizational Flexibility of the SIP Change Process.) to Best Current Practice

2016-01-27 17:32:03
Here's a summary of the last call feedback I've seen so far, and proposed actions:

*** Substantive comments: ***

- John Levine:
 -- Change title to something more relevant.
 -- Update contents to reflect that the ART merge has already happened.

Ben: Title changed to "DISPATCH-Style Working Groups and the SIP Change Process" in working copy. Updated language to indicate the merge has already occurred.

- Richard Shockey: The ART merge was not a good idea.

Ben: It's probably useful to discuss the success or failure of the ART merge, but I don't think it's in scope for this draft. The draft doesn't execute that merge, the update adapts to the it.

- Harald Alvestrand: The dispatch process has had poor results, and should not be propagated:

Ben: I thought dispatch had worked reasonably well for RAI. As it is, the authors do not have enough specifics to propose actions on this comment.

- Jon Mitchell (OPS-DIR review):
-- Clarify the responsibility for "judgement calls" in section 2:

Ben: I've made the following change in my working copy:

OLD
   Nothing in this list prevents existing working groups from directly
   adopting new work that reasonably fits their charters.  For
   borderline cases, the decision whether new work should start in a
   dispatch-style group, or in an existing group is a judgement call
   among the responsible Area Directors and chairs.  Likewise, in cases
   where an area has multiple dispatch-style groups for different
   purposes or technology clusters, the decision about which group will
   handle a particular proposal is a judgement call.
NEW
   Nothing in this list prevents existing working groups from directly
   adopting new work that reasonably fits their charters.  For
   borderline cases, the decision whether new work should start in a
   dispatch-style group or in an existing group is made by the
   responsible Area Directors and chairs.  Likewise, in cases
   where an area has multiple dispatch-style groups for different
   purposes or technology clusters, deciding which group will handle
   a particular proposal is up to the responsible Area Directors and
   relevant chairs.
END

-- The security considerations are not about security in a technical sense.

Ben: While this is not about protocol or network security, it is about the integrity of the standards process. In my opinion, that's reasonable content for the security considerations.

*** Editorial: ***

Fixed several reported misspellings and typos


Thanks!

Ben.



On 8 Dec 2015, at 9:56, The IESG wrote:

The IESG has received a request from an individual submitter to consider
the following document:
- 'Improving the Organizational Flexibility of the SIP Change Process.'
<draft-campbell-art-rfc5727-update-02.txt> as Best Current Practice

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(_at_)ietf(_dot_)org mailing lists by 2016-01-05. Exceptionally, comments may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


 RFC 5727 defines several processes for the Real-time Applications and
 Infrastructure (RAI) area.  These processes include the evolution of
 the Session Initiation Protocol (SIP) and related protocols, as well
 as the operation of the DISPATCH and SIPCORE working groups.  This
 document updates RFC 5727 to allow flexibility for the area and
 working group structure, while preserving the SIP change processes.
 It also generalizes the DISPATCH working group processes so that they
 can be easily adopted by other working groups.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-campbell-art-rfc5727-update/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-campbell-art-rfc5727-update/ballot/


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