Re: [salud] Finishing up

Paul Kyzivat <> Wed, 16 July 2014 18:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 15C431A017F for <>; Wed, 16 Jul 2014 11:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UPrF3oBCRo5L for <>; Wed, 16 Jul 2014 11:45:18 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:212]) by (Postfix) with ESMTP id A1B1E1A0175 for <>; Wed, 16 Jul 2014 11:45:18 -0700 (PDT)
Received: from ([]) by with comcast id T5Qj1o0051swQuc5E6lJcv; Wed, 16 Jul 2014 18:45:18 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id T6lJ1o0013ZTu2S3b6lJyS; Wed, 16 Jul 2014 18:45:18 +0000
Message-ID: <>
Date: Wed, 16 Jul 2014 14:45:17 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1405536318; bh=UHPb1Lx2DxX5hOoc7Q/sxNFUukfAmF/fr8PgEzxHCU8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TMgtBBesqDgEq0D/+KOLjlFiPXtRi2jnth5fepsGL3OgTLSlt5nnNCprSnOgAaOaM FfqyBgXwMR/eVt0XRNfUAdz6dAtkMKzAcx807YewQVbjsq3W1BnpfZUJ4r/nB03VhW Rxl85h/BELXT05UnbpXW0kwoleC//AmMIshTBRogFq3NZcSqkDgT80vEMBxLET2EPu zDVJnmsfnnPSNuTu7kjfp52nn430u1HLHU56S7HjrmYDlluOJMPGnUS5v3yjT8XHtP TkHrktd1WdJNj5Ch/A5CX8gq2Q+Zq10DLJlfePVIUidVeAr6O2k3NC776htAJE8tN0 XiS/ix7S61QNA==
Subject: Re: [salud] Finishing up
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Sip ALerting for User Devices working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Jul 2014 18:45:20 -0000


This sounds like a good plan, in that it is the best that can be done 
under the circumstances. It is unfortunately complicated and drawn out, 
but unavoidably so.

One thing - while I normally wouldn't recommend it, *maybe* we could run 
the WGLC in parallel with the meeting next week since we don't expect 
any surprises there. But I think maybe Richard should make that call.


On 7/16/14 2:35 PM, Dale R. Worley wrote:
> [as chair of Salud]
> I am currently planning how to bring the draft to a rapid conclusion.
> There are a number of steps to be followed, and by IETF procedures,
> they need to be followed in order, and that will take some time.
> However, I believe that with proper planning we can advance quickly to
> the point where we know that the current Salud draft will be accepted,
> even though finishing the procedures will take a few weeks further.
> The purpose of this message is to ask our AD, Richard Barnes, if he
> considers this a reasonable way to proceed, and to notify all
> concerned that this is the proposed plan and request feedback on any
> needed modifications.
> First,
> 1. Establish a -13 draft, so we have a definitive revision of the
>     draft.  I believe that the authors are in consensus about a -13
>     draft.
> After that, we can proceed in parallel with,
> 2. Obtain approval of Christer Holmberg, who is the Document Shepherd
>     and outside technical reviewer.
> 3. Obtain approval of the working group via a WGLC.  We need to allow
>     for at least two weeks for WGLC.  In my opinion, this time should
>     be disjoint of the Toronto IETF meeting, which means that it spans
>     Monday 28 July to Monday 11 August.  Given the recent history of
>     the working group and the fact that all recently active members
>     have been active authors of the draft, I do not expect any
>     objections to be raised.
> 4. Informally verify that the changes in the -13 draft satisfy the
>     IESG objections that have design import or are in some way
>     controversial:
>     - replacing the domain name-based <provider> value with a
>       first-com, first-served registry (Alissa Cooper, Barry Leiba,
>       Brian Haberman, Pete Resnick, Stephen Farrell)
>     - using a uniform policy of Specification Required (which includes
>       Expert Review) for defining additional standard URNs, including
>       providing detailed guidelines for the expert review (Barry Leiba,
>       Brian Haberman, Pete Resnick)
>     - revision of section 13 and its requirement that a UA "MUST
>       produce a reasonable rending" (Gen-Art review, Jari Arkko)
>     - additional security considerations and reorganizing their
>       presentation, including that a "source" indication will almost
>       certainly only be accepted when it is provided by a proxy acting
>       on behalf of the recipient UA (section 16, 8.2.2) (Secdir review,
>       Alissa Cooper, Kathleen Moriarty, Stephen Farrell, Ted Lemon)
> After 1, 2, and 4 are finished, I believe that we can safely predict
> the draft will proceed to an RFC.
> After the second stage, we can proceed with,
> 5. Formally file responses to the IESG's discuss points.
> 6. Get the IESG's approval.
> After that there is,
> 7. Editorial consultation with the RFC Editor.
> Dale
> _______________________________________________
> salud mailing list