Re: Last Call: <draft-campbell-art-rfc5727-update-02.txt> (Improving the Organizational Flexibility of the SIP Change Process.) to Best Current Practice
"Ben Campbell" <ben@nostrum.com> Wed, 27 January 2016 23:31 UTC
Return-Path: <ben@nostrum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295341B38D9; Wed, 27 Jan 2016 15:31:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNZTsFOE8yWK; Wed, 27 Jan 2016 15:31:41 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62AF41B38CF; Wed, 27 Jan 2016 15:31:38 -0800 (PST)
Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0RNVanZ009784 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 Jan 2016 17:31:36 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10]
From: Ben Campbell <ben@nostrum.com>
To: ietf@ietf.org
Subject: Re: Last Call: <draft-campbell-art-rfc5727-update-02.txt> (Improving the Organizational Flexibility of the SIP Change Process.) to Best Current Practice
Date: Wed, 27 Jan 2016 17:31:35 -0600
Message-ID: <819174A8-0F9F-4D96-B1FE-139D68821D3D@nostrum.com>
In-Reply-To: <20151208155640.29167.39623.idtracker@ietfa.amsl.com>
References: <20151208155640.29167.39623.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.3r5187)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/lS2O69Xwi3xiWb7QQucMoM4kaxY>
Cc: mary.ietf.barnes@gmail.com, draft-campbell-art-rfc5727-update@ietf.org, IETF-Announce <ietf-announce@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jan 2016 23:31:43 -0000
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@ietf.org mailing lists by 2016-01-05. Exceptionally, comments may > be > sent to iesg@ietf.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.
- Re: Last Call: <draft-campbell-art-rfc5727-update… John Levine
- Re: Last Call: <draft-campbell-art-rfc5727-update… Richard Shockey
- Re: Last Call: <draft-campbell-art-rfc5727-update… Harald Alvestrand
- Re: Last Call: <draft-campbell-art-rfc5727-update… Mary Barnes
- Re: Last Call: <draft-campbell-art-rfc5727-update… Ben Campbell
- Re: Last Call: <draft-campbell-art-rfc5727-update… Ben Campbell
- Re: Last Call: <draft-campbell-art-rfc5727-update… Harald Alvestrand
- Re: Last Call: <draft-campbell-art-rfc5727-update… Ben Campbell
- Re: Last Call: <draft-campbell-art-rfc5727-update… Ben Campbell
- Re: Last Call: <draft-campbell-art-rfc5727-update… Ben Campbell