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.