From lilianrensheng@126.com  Mon Apr  1 06:33:27 2013
Return-Path: <lilianrensheng@126.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB6A21F8B96 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 06:33:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.12
X-Spam-Level: **
X-Spam-Status: No, score=2.12 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_220=2.118]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkqL0xd1zTI8 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 06:33:26 -0700 (PDT)
Received: from m15-33.126.com (m15-33.126.com [220.181.15.33]) by ietfa.amsl.com (Postfix) with ESMTP id EDADB21F867E for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 06:33:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Received:Date:From:To:Subject:Content-Type: MIME-Version:Message-ID; bh=fvEz4ftBhoaxDJzZMFZlPE2cM+rKTUY8N2UZ CfuGA44=; b=SdPz4PLJhtYikFeKyQinb9819T9VH+YgVsNKCYRDkhX7M5sn6aYu MovXu6St3rOfKW8aqZrb5f3249RtpKc6LYTVToWpd7hKEj4D8pSx8yQNJPuc0Tgm 1J0CXJc2p0sCTqfmkiX6CWl4pCIBSyL5/iJfmZfZxMVwV/Buh4Ac/j0=
Received: from lilianrensheng$126.com ( [112.65.223.1] ) by ajax-webmail-wmsvr33 (Coremail) ; Mon, 1 Apr 2013 21:33:18 +0800 (CST)
X-Originating-IP: [112.65.223.1]
Date: Mon, 1 Apr 2013 21:33:18 +0800 (CST)
From: lilianrensheng <lilianrensheng@126.com>
To: apps-discuss@ietf.org
X-Priority: 3
X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20130201(21528.5249.5248) Copyright (c) 2002-2013 www.mailtech.cn 126com
X-CM-CTRLDATA: CW6fcmZvb3Rlcl9odG09NDI1Ojgx
Content-Type: multipart/alternative;  boundary="----=_Part_306973_2022110922.1364823198720"
MIME-Version: 1.0
Message-ID: <7aeb028.144e3.13dc5cd4c00.Coremail.lilianrensheng@126.com>
X-CM-TRANSID: IcqowECJr0KejFlRO90KAA--.1101W
X-CM-SenderInfo: 5oloxtxquh02pkhqwqqrswhudrp/1tbiTQDxKUkZmBIszgACsv
X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU==
Subject: Re: [apps-discuss] The Interconnection and Interoperability of Different Cloud-office Applications (IDCOA) with the HTML File Format
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2013 13:33:27 -0000

------=_Part_306973_2022110922.1364823198720
Content-Type: text/plain; charset=GBK
Content-Transfer-Encoding: 7bit

Dear all,


The interconnection and interoperability of different cloud office application seems to be important for users who wants to share office documents  to friends those register in a different website. I think the job is meaningful and worth for discussing.


--------
Li Wu
------=_Part_306973_2022110922.1364823198720
Content-Type: text/html; charset=GBK
Content-Transfer-Encoding: 7bit

<div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial">Dear all,<div><br></div><div>The interconnection and interoperability of different cloud office application seems to be important for users who wants to share office documents &nbsp;to friends those register in a different website. I think the job is meaningful and worth for discussing.</div><div><br></div><div>--------</div><div>Li Wu</div></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span>
------=_Part_306973_2022110922.1364823198720--


From stephen.farrell@cs.tcd.ie  Mon Apr  1 11:53:49 2013
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75F621E809D for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 11:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8qUWgsApbIT for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 11:53:49 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 02E2821E8051 for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 11:53:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A028EBE4C; Mon,  1 Apr 2013 19:53:26 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Np5ag-JOhGJ; Mon,  1 Apr 2013 19:53:24 +0100 (IST)
Received: from [10.87.48.8] (unknown [86.42.20.231]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 627EEBE35; Mon,  1 Apr 2013 19:53:24 +0100 (IST)
Message-ID: <5159D7A4.4000701@cs.tcd.ie>
Date: Mon, 01 Apr 2013 19:53:24 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Murray S. Kucherawy" <superuser@gmail.com>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com>
In-Reply-To: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2013 18:53:49 -0000

FWIW, I'm concerned about this charter text:

"The strong preference is for the working group to preserve existing
software and procedures. For changes likely to affect the installed
base, the working group will seek review and advice, beyond working
group participants, to include other developers and operators of
DMARC-based mechanisms. "

I don't know how the not-yet-formed WG can have a preference nor
how a formed-wg can seek advice "beyond the working group" with
our processes.

Both of those would seem like charter-show-stoppers to me (and
fairly reek of rubber-stamping to put it pejoratively).

We had to, and did, address similar issues with DKIM/DomainKeys
so I hope that a similar approach will also work here - its
fine for proponents of a technology to prefer no change but
its not fine to constrain an IETF WG to rule out changes, but
I reckon its actually not that hard to write down something
that works, as we eventually did in the DKIM case.

(I've not read the draft yet so this is just a comment on the
charter text, not on the meat of the proposal. I do think this
point deserves to be raised on apps-discuss given that its not
really dmarc-specific.)

Cheers,
S.

On 04/01/2013 06:25 AM, Murray S. Kucherawy wrote:
> At the IETF meeting in Atlanta, Tim Draegen presented a proposal for DMARC,
> which is an email authentication and reporting layer atop SPF and DKIM.
> The externally-developed proposal is now in widespread deployment by a
> number of large-scale providers.  The group that developed it is seeking to
> bring it to the IETF for further development and broad review, and
> development of operational guidance.
> 
> A first draft of a charter can be found linked from
> http://wiki.tools.ietf.org/wg/appsawg/trac/wiki.
> 
> There is a dmarc@ietf.org list available for discussing the technical
> contents of the work and also this draft charter.  Please follow up there
> with any charter contents so we don't innundate this list with that
> discussion.  To subscribe to that list:
> 
> https://www.ietf.org/mailman/listinfo/dmarc
> 
> -MSK
> 
> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 

From superuser@gmail.com  Mon Apr  1 15:16:19 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A0F21F9021 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 15:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmO+4yIm3avS for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 15:16:14 -0700 (PDT)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 70CF521E80B1 for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 15:16:11 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id x43so2191416wey.28 for <apps-discuss@ietf.org>; Mon, 01 Apr 2013 15:16:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CXNg7KHHhv6eIOtbtTswVES+h64BOp9xEqIqWdbu2gQ=; b=Bw4+yNhX9mMOpwGLNLgw4SzVtu6Mwnmcgi5nh5FKxg9nH5PIHdhQHRt0BDBPiMhP2A +by2yiehm6m/Ey1tUNz5QVcwiFvLAZmOfL29qNBFbVQMFdRGDyjBHbA9gFBpr0kLCCHs M6Du1g4G64CvnQ/8/7qtYyf7WJJVd9kup4pu6X/1hx0LMEWr8o7YzMz6RHAn/Apfps9h wrVTZXuHle/NmqxcpI+yQXd8q9Pf3D16rODjWn7acZ7NxVFf6M2hsA+su+epTOuT7box +54NUZHnjsHpR9aXNYCaQvyHEeFSPKmhD+BHXGlxqPs5cfh0Si96GmrI7RdkRUThqr1I 8vpA==
MIME-Version: 1.0
X-Received: by 10.180.94.39 with SMTP id cz7mr12201332wib.21.1364854570763; Mon, 01 Apr 2013 15:16:10 -0700 (PDT)
Received: by 10.180.13.71 with HTTP; Mon, 1 Apr 2013 15:16:10 -0700 (PDT)
In-Reply-To: <5159D7A4.4000701@cs.tcd.ie>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie>
Date: Mon, 1 Apr 2013 15:16:10 -0700
Message-ID: <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary=f46d04426de6dc4e6404d953f763
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2013 22:16:21 -0000

--f46d04426de6dc4e6404d953f763
Content-Type: text/plain; charset=ISO-8859-1

Hi Stephen,

We've already had this very conversation, so we're aware of the issue.  The
text we have was an attempt to re-create the same constraints DKIM had,
preferring no changes, but not completely proscribing it either.  It sounds
like we have a little more text massaging to do to make it clear that's
where were trying to go.

Thanks,
-MSK


On Mon, Apr 1, 2013 at 11:53 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie>wrote:

>
> FWIW, I'm concerned about this charter text:
>
> "The strong preference is for the working group to preserve existing
> software and procedures. For changes likely to affect the installed
> base, the working group will seek review and advice, beyond working
> group participants, to include other developers and operators of
> DMARC-based mechanisms. "
>
> I don't know how the not-yet-formed WG can have a preference nor
> how a formed-wg can seek advice "beyond the working group" with
> our processes.
>
> Both of those would seem like charter-show-stoppers to me (and
> fairly reek of rubber-stamping to put it pejoratively).
>
> We had to, and did, address similar issues with DKIM/DomainKeys
> so I hope that a similar approach will also work here - its
> fine for proponents of a technology to prefer no change but
> its not fine to constrain an IETF WG to rule out changes, but
> I reckon its actually not that hard to write down something
> that works, as we eventually did in the DKIM case.
>
> (I've not read the draft yet so this is just a comment on the
> charter text, not on the meat of the proposal. I do think this
> point deserves to be raised on apps-discuss given that its not
> really dmarc-specific.)
>
> Cheers,
> S.
>
> On 04/01/2013 06:25 AM, Murray S. Kucherawy wrote:
> > At the IETF meeting in Atlanta, Tim Draegen presented a proposal for
> DMARC,
> > which is an email authentication and reporting layer atop SPF and DKIM.
> > The externally-developed proposal is now in widespread deployment by a
> > number of large-scale providers.  The group that developed it is seeking
> to
> > bring it to the IETF for further development and broad review, and
> > development of operational guidance.
> >
> > A first draft of a charter can be found linked from
> > http://wiki.tools.ietf.org/wg/appsawg/trac/wiki.
> >
> > There is a dmarc@ietf.org list available for discussing the technical
> > contents of the work and also this draft charter.  Please follow up there
> > with any charter contents so we don't innundate this list with that
> > discussion.  To subscribe to that list:
> >
> > https://www.ietf.org/mailman/listinfo/dmarc
> >
> > -MSK
> >
> >
> >
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
>

--f46d04426de6dc4e6404d953f763
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Stephen,<br><br>We&#39;ve already had this very co=
nversation, so we&#39;re aware of the issue.=A0 The text we have was an att=
empt to re-create the same constraints DKIM had, preferring no changes, but=
 not completely proscribing it either.=A0 It sounds like we have a little m=
ore text massaging to do to make it clear that&#39;s where were trying to g=
o.<br>
<br>Thanks,<br></div>-MSK<br></div><div class=3D"gmail_extra"><br><br><div =
class=3D"gmail_quote">On Mon, Apr 1, 2013 at 11:53 AM, Stephen Farrell <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:stephen.farrell@cs.tcd.ie" target=3D"_b=
lank">stephen.farrell@cs.tcd.ie</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
FWIW, I&#39;m concerned about this charter text:<br>
<br>
&quot;The strong preference is for the working group to preserve existing<b=
r>
software and procedures. For changes likely to affect the installed<br>
base, the working group will seek review and advice, beyond working<br>
group participants, to include other developers and operators of<br>
DMARC-based mechanisms. &quot;<br>
<br>
I don&#39;t know how the not-yet-formed WG can have a preference nor<br>
how a formed-wg can seek advice &quot;beyond the working group&quot; with<b=
r>
our processes.<br>
<br>
Both of those would seem like charter-show-stoppers to me (and<br>
fairly reek of rubber-stamping to put it pejoratively).<br>
<br>
We had to, and did, address similar issues with DKIM/DomainKeys<br>
so I hope that a similar approach will also work here - its<br>
fine for proponents of a technology to prefer no change but<br>
its not fine to constrain an IETF WG to rule out changes, but<br>
I reckon its actually not that hard to write down something<br>
that works, as we eventually did in the DKIM case.<br>
<br>
(I&#39;ve not read the draft yet so this is just a comment on the<br>
charter text, not on the meat of the proposal. I do think this<br>
point deserves to be raised on apps-discuss given that its not<br>
really dmarc-specific.)<br>
<br>
Cheers,<br>
S.<br>
<div><div class=3D"h5"><br>
On 04/01/2013 06:25 AM, Murray S. Kucherawy wrote:<br>
&gt; At the IETF meeting in Atlanta, Tim Draegen presented a proposal for D=
MARC,<br>
&gt; which is an email authentication and reporting layer atop SPF and DKIM=
.<br>
&gt; The externally-developed proposal is now in widespread deployment by a=
<br>
&gt; number of large-scale providers. =A0The group that developed it is see=
king to<br>
&gt; bring it to the IETF for further development and broad review, and<br>
&gt; development of operational guidance.<br>
&gt;<br>
&gt; A first draft of a charter can be found linked from<br>
&gt; <a href=3D"http://wiki.tools.ietf.org/wg/appsawg/trac/wiki" target=3D"=
_blank">http://wiki.tools.ietf.org/wg/appsawg/trac/wiki</a>.<br>
&gt;<br>
&gt; There is a <a href=3D"mailto:dmarc@ietf.org">dmarc@ietf.org</a> list a=
vailable for discussing the technical<br>
&gt; contents of the work and also this draft charter. =A0Please follow up =
there<br>
&gt; with any charter contents so we don&#39;t innundate this list with tha=
t<br>
&gt; discussion. =A0To subscribe to that list:<br>
&gt;<br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dmarc" target=3D"_bla=
nk">https://www.ietf.org/mailman/listinfo/dmarc</a><br>
&gt;<br>
&gt; -MSK<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div>&gt; _______________________________________________<br>
&gt; apps-discuss mailing list<br>
&gt; <a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=
=3D"_blank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
&gt;<br>
</blockquote></div><br></div>

--f46d04426de6dc4e6404d953f763--

From stephen.farrell@cs.tcd.ie  Mon Apr  1 15:24:10 2013
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE5321F90F1 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 15:24:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRQE-lPMnrjZ for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 15:24:09 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D0F4521F9039 for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 15:23:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 871FDBE29; Mon,  1 Apr 2013 23:22:17 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+s3pPY1rGZ5; Mon,  1 Apr 2013 23:22:14 +0100 (IST)
Received: from [10.87.48.8] (unknown [86.42.20.231]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DCC6DBE25; Mon,  1 Apr 2013 23:22:13 +0100 (IST)
Message-ID: <515A0895.2090209@cs.tcd.ie>
Date: Mon, 01 Apr 2013 23:22:13 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Murray S. Kucherawy" <superuser@gmail.com>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com>
In-Reply-To: <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2013 22:24:10 -0000

On 04/01/2013 11:16 PM, Murray S. Kucherawy wrote:
> Hi Stephen,
> 
> We've already had this very conversation, so we're aware of the issue.  The
> text we have was an attempt to re-create the same constraints DKIM had,
> preferring no changes, but not completely proscribing it either.  It sounds
> like we have a little more text massaging to do to make it clear that's
> where were trying to go.

Right. If the outcome is charter text like we had with DKIM that'd
be fine. FWIW, the initial charter for DKIM said:

"Experimentation has resulted in Internet deployment of these
specifications. Although not encouraged, non-backwards-compatible
changes to these specifications will be acceptable if the DKIM working
group determines that the changes are required to meet the group's
technical objectives."

I don't know if that's something that'd work for dmarc but I
think it does hit the right note, and I think with DKIM that
worked fine. (But I'm biased of course;-)

S

> 
> Thanks,
> -MSK
> 
> 
> On Mon, Apr 1, 2013 at 11:53 AM, Stephen Farrell
> <stephen.farrell@cs.tcd.ie>wrote:
> 
>>
>> FWIW, I'm concerned about this charter text:
>>
>> "The strong preference is for the working group to preserve existing
>> software and procedures. For changes likely to affect the installed
>> base, the working group will seek review and advice, beyond working
>> group participants, to include other developers and operators of
>> DMARC-based mechanisms. "
>>
>> I don't know how the not-yet-formed WG can have a preference nor
>> how a formed-wg can seek advice "beyond the working group" with
>> our processes.
>>
>> Both of those would seem like charter-show-stoppers to me (and
>> fairly reek of rubber-stamping to put it pejoratively).
>>
>> We had to, and did, address similar issues with DKIM/DomainKeys
>> so I hope that a similar approach will also work here - its
>> fine for proponents of a technology to prefer no change but
>> its not fine to constrain an IETF WG to rule out changes, but
>> I reckon its actually not that hard to write down something
>> that works, as we eventually did in the DKIM case.
>>
>> (I've not read the draft yet so this is just a comment on the
>> charter text, not on the meat of the proposal. I do think this
>> point deserves to be raised on apps-discuss given that its not
>> really dmarc-specific.)
>>
>> Cheers,
>> S.
>>
>> On 04/01/2013 06:25 AM, Murray S. Kucherawy wrote:
>>> At the IETF meeting in Atlanta, Tim Draegen presented a proposal for
>> DMARC,
>>> which is an email authentication and reporting layer atop SPF and DKIM.
>>> The externally-developed proposal is now in widespread deployment by a
>>> number of large-scale providers.  The group that developed it is seeking
>> to
>>> bring it to the IETF for further development and broad review, and
>>> development of operational guidance.
>>>
>>> A first draft of a charter can be found linked from
>>> http://wiki.tools.ietf.org/wg/appsawg/trac/wiki.
>>>
>>> There is a dmarc@ietf.org list available for discussing the technical
>>> contents of the work and also this draft charter.  Please follow up there
>>> with any charter contents so we don't innundate this list with that
>>> discussion.  To subscribe to that list:
>>>
>>> https://www.ietf.org/mailman/listinfo/dmarc
>>>
>>> -MSK
>>>
>>>
>>>
>>> _______________________________________________
>>> apps-discuss mailing list
>>> apps-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>
>>
> 

From dhc@dcrocker.net  Mon Apr  1 16:17:30 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AB521E8127 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 16:17:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CP91o-GYB-6Q for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 16:17:29 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B53A421E8122 for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 16:17:29 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r31NHL4S014013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Apr 2013 16:17:22 -0700
Message-ID: <515A1581.9030402@dcrocker.net>
Date: Mon, 01 Apr 2013 16:17:21 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie>
In-Reply-To: <515A0895.2090209@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 01 Apr 2013 16:17:22 -0700 (PDT)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2013 23:17:30 -0000

Stephen,

DKIM had far less installed base on large operational services than 
DMARC now has.

As for not knowing how to consult outside the working group, surely you 
jest.  We do it all the time.

As for:
> I don't know how the not-yet-formed WG can have a preference

I don't know what you mean.


d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From scott@kitterman.com  Mon Apr  1 16:44:35 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C1B21F8F28 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 16:44:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHCPGBBsL7GS for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 16:44:34 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id B62C221F8F0C for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 16:44:34 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id C8D8020E40D5; Mon,  1 Apr 2013 19:44:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364859873; bh=Cm3ItqjzpE/cpewRT/1YSrKQ4XkeFGU8oXQLYikwn0U=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PMFa4fv7SNoWwQFORsj0amaR1aO/gQ0Xb8OR8qPbdcJm3ORMwxVPga5Az/B4QVhIx iPAqtqRDyQtNR04kG2WB1yZRFmKk4BKfPJ99tFbrmAVlWLHFiFaeN4hfuibIZ1iAGs sPPN6hp4ktbqkDZvv6q7AZvgpx6uDdBvzQVIhrOQ=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id AE00120E4090;  Mon,  1 Apr 2013 19:44:33 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Mon, 01 Apr 2013 19:44:32 -0400
Message-ID: <1391800.uByxAVik4Q@scott-latitude-e6320>
User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; )
In-Reply-To: <515A1581.9030402@dcrocker.net>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie> <515A1581.9030402@dcrocker.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2013 23:44:35 -0000

On Monday, April 01, 2013 04:17:21 PM Dave Crocker wrote:
> Stephen,
> 
> DKIM had far less installed base on large operational services than
> DMARC now has.

Right.  DKIM had no installed base.  Just for clarity (I imagine you are), 
you're referring to the DomainKeys installed base?

Scott K



From dhc@dcrocker.net  Mon Apr  1 16:58:52 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F6921E812C for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 16:58:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giziuiVzMOjY for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 16:58:52 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5E221E8108 for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 16:58:52 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r31NwpvH014880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Apr 2013 16:58:51 -0700
Message-ID: <515A1F3B.2050807@dcrocker.net>
Date: Mon, 01 Apr 2013 16:58:51 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Scott Kitterman <scott@kitterman.com>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie> <515A1581.9030402@dcrocker.net> <1391800.uByxAVik4Q@scott-latitude-e6320>
In-Reply-To: <1391800.uByxAVik4Q@scott-latitude-e6320>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 01 Apr 2013 16:58:51 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2013 23:58:52 -0000

On 4/1/2013 4:44 PM, Scott Kitterman wrote:
> On Monday, April 01, 2013 04:17:21 PM Dave Crocker wrote:
>> DKIM had far less installed base on large operational services than
>> DMARC now has.
>
> Right.  DKIM had no installed base.  Just for clarity (I imagine you are),
> you're referring to the DomainKeys installed base?


I mean DKIM, not Domainkeys.  Domainkeys had two rounds of development 
before the ad hoc, private consortium of roughly 12 organizations met 
for a year to integrate it and cisco's Identified Internet Mail.

Some of the consortium participants implemented the original (pre-IETF) 
specification:

    http://dkim.org/Misc/Press%20Release%20July-2005b.txt

but none of that was on the scale of adoption and deployment that dmarc 
has already received.

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From stephen.farrell@cs.tcd.ie  Mon Apr  1 17:21:18 2013
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6324111E8118 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 17:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNxOfcP3Fupv for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 17:21:17 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 99FE911E80E2 for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 17:21:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 62F46BE33; Tue,  2 Apr 2013 01:20:54 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3JgxFtkYHXB; Tue,  2 Apr 2013 01:20:53 +0100 (IST)
Received: from [10.87.48.8] (unknown [86.42.20.231]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 55EDBBE2F; Tue,  2 Apr 2013 01:20:53 +0100 (IST)
Message-ID: <515A2464.8090401@cs.tcd.ie>
Date: Tue, 02 Apr 2013 01:20:52 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: dcrocker@bbiw.net
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie> <515A1581.9030402@dcrocker.net>
In-Reply-To: <515A1581.9030402@dcrocker.net>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 00:21:18 -0000

Hi Dave,

On 04/02/2013 12:17 AM, Dave Crocker wrote:
> Stephen,
> 
> DKIM had far less installed base on large operational services than
> DMARC now has.

Happy to hear that but I don't think it impacts on the
points below. (Its news to me btw, but then its not my area
so that's not surprising.)

And to be clear: I do welcome folks bringing work to the
IETF, esp. where it is or will be widely deployed.

> As for not knowing how to consult outside the working group, surely you
> jest.  We do it all the time.

Not with such vaguely characterised "others" and nor with
giving 'em anti-change-control that I can recall. Feel free
to point me at examples that do those things. If the text
isn't meant to severely constrain IETF change-control then
it needs a re-write 'cause it reads to me like that's the
intent.

If the "others" are actually well-known and are really
dmarc.org members then saying that would seem to be
useful to start with.

But in any case since that dmarc.org group apparently want
to cede change control then I think DKIM-like charter text
is really what'd work best.

If dmarc.org really don't want to cede change control then
the ISE route would seen more appropriate than an IETF WG.

> As for:
>> I don't know how the not-yet-formed WG can have a preference
> 
> I don't know what you mean.

WG-doesn't-exist-yet => WG-can't-have-opinion. That ought be
trivial to fix, but is indicative of a possibly problematic
conflation of the set of folks who drafted this text and the
set of folks that might participate in a future IETF WG, which
will include people who've never seen this draft for example.

S.

> 
> 
> d/

From dret@berkeley.edu  Mon Apr  1 17:35:32 2013
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD6011E80E2 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 17:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPr-qutQGXv3 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 17:35:32 -0700 (PDT)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 0963711E80F8 for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 17:35:32 -0700 (PDT)
Received: from mobile-166-137-187-250.mycingular.net ([166.137.187.250] helo=dretpro.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1UMpCE-0000dI-CU; Mon, 01 Apr 2013 17:35:31 -0700
Message-ID: <515A27D2.4010802@berkeley.edu>
Date: Mon, 01 Apr 2013 17:35:30 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "apps-discuss@ietf.org application-layer protocols" <apps-discuss@ietf.org>, REST-Discuss <rest-discuss@yahoogroups.com>
References: <20130402001435.31532.68575.idtracker@ietfa.amsl.com>
In-Reply-To: <20130402001435.31532.68575.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20130402001435.31532.68575.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: hypermedia-web@googlegroups.com
Subject: [apps-discuss] Fwd: New Version Notification for draft-wilde-home-xml-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 00:35:32 -0000

A new version of I-D, draft-wilde-home-xml-00.txt
has been successfully submitted by Erik Wilde and posted to the
IETF repository.

Filename:	 draft-wilde-home-xml
Revision:	 00
Title:		 Home Documents for HTTP Services: XML Syntax
Creation date:	 2013-04-01
Group:		 Individual Submission
Number of pages: 8
URL: 
http://www.ietf.org/internet-drafts/draft-wilde-home-xml-00.txt
Status:          http://datatracker.ietf.org/doc/draft-wilde-home-xml
Htmlized:        http://tools.ietf.org/html/draft-wilde-home-xml-00


Abstract:
    The current draft for HTTP Home Documents provides a JSON syntax
    only.  This draft provides an XML syntax for the same underlying data
    model, so that the concept of HTTP Home Documents can be consistently
    exposed in both JSON- and XML-based HTTP services.

Note to Readers

    Please discuss this draft on the apps-discuss mailing list [5].
    Online access to all versions and files is available on github [6].

From stpeter@stpeter.im  Mon Apr  1 17:37:44 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DBC21F8F31 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 17:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNSkfWkvb9-m for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 17:37:43 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 65A4B21F844F for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 17:37:43 -0700 (PDT)
Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8965E40D3A; Mon,  1 Apr 2013 18:47:22 -0600 (MDT)
Message-ID: <515A2858.2000907@stpeter.im>
Date: Mon, 01 Apr 2013 18:37:44 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie>
In-Reply-To: <515A0895.2090209@cs.tcd.ie>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 00:37:44 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/1/13 4:22 PM, Stephen Farrell wrote:
> 
> 
> On 04/01/2013 11:16 PM, Murray S. Kucherawy wrote:
>> Hi Stephen,
>> 
>> We've already had this very conversation, so we're aware of the
>> issue.  The text we have was an attempt to re-create the same
>> constraints DKIM had, preferring no changes, but not completely
>> proscribing it either.  It sounds like we have a little more text
>> massaging to do to make it clear that's where were trying to go.
> 
> Right. If the outcome is charter text like we had with DKIM that'd 
> be fine. FWIW, the initial charter for DKIM said:
> 
> "Experimentation has resulted in Internet deployment of these 
> specifications. Although not encouraged, non-backwards-compatible 
> changes to these specifications will be acceptable if the DKIM
> working group determines that the changes are required to meet the
> group's technical objectives."
> 
> I don't know if that's something that'd work for dmarc but I think
> it does hit the right note, and I think with DKIM that worked fine.
> (But I'm biased of course;-)

FWIW, the original XMPP WG (2002) had the following text in its
charter regarding backward compatibility with the existing
implementations and deployments of the Jabber protocols...

   Although not encouraged, non-backwards-compatible changes to the
   basis specifications will be acceptable if the working group
   determines that the changes are required to meet the group's
   technical objectives and the group clearly documents the reasons for
   making them.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRWihYAAoJEOoGpJErxa2pkCUP/ib6dD0n1x6ZkU9Lp2eOYm2j
fVjYu19NAHWsFTn2u1A+aiKntAFJeYv9/GxnPxF6aUja3sKfNE1rQ6fgfuU30Lp5
9fQ0T9X9jc86dhO1gBXNLPhPOTjRTnOh19Si4Yed2go/LJfvbIHDvfJx70CqS5l1
u4LV8HY/wbdiA3pqZFzyzymv9Oa3CfHIXZXK2CQmefPIgIuGt4qfk3QiSt0THi5m
XurUPi8TQg7QH/6xr5E3D3yzWEQHpNd3Bm9tKUYttm3fqVevgzDwfFUCAnsJ3k0y
SDEcS0KhN3ObHkLWW+6Y3pGWJQnFZnu4Ymisbgi0Qg+at5hvVSNCRrJV6qQxG3ZO
ETuFT80Tath5dfmGCz072MxoriSuIuwJPlm3qY7/WB1D2D33JQt3oqZ+xefSLVOp
f7x5mW//YkKAQXcnB7/og2HRxq6CjMR4kggPA9GuDEDDwBdKTdbEPZVLIZyScrvl
5nBX6O+LfLrZ3gp8m7X5Yq50DynXMzq0kfB1FvRE3d1VSUmn3u/6ftmVcs+NU/Sw
KThwr3ollLlRCYhf3AVSFCECcD8/wIiv9uQNvk9Q3ik0npdroRD6JYo3UmUtgghH
yu+mo1Gi+ZixH7A0SIsE5y9XWtcoqBwv0fiVxqgKqHkyGG0fWJnD22GJfTD7o6qu
IiPhoeSb04F+vYw9ECBt
=M72/
-----END PGP SIGNATURE-----

From dhc@dcrocker.net  Mon Apr  1 18:35:51 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C14221F8DB7 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 18:35:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRqhoRgM3l8m for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 18:35:50 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 81E1921F8D35 for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 18:35:50 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r321ZgLw016636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Apr 2013 18:35:43 -0700
Message-ID: <515A35EE.4010503@dcrocker.net>
Date: Mon, 01 Apr 2013 18:35:42 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie> <515A2858.2000907@stpeter.im>
In-Reply-To: <515A2858.2000907@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 01 Apr 2013 18:35:43 -0700 (PDT)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 01:35:51 -0000

On 4/1/2013 5:37 PM, Peter Saint-Andre wrote:
> FWIW, the original XMPP WG (2002) had the following text in its
> charter regarding backward compatibility with the existing
> implementations and deployments of the Jabber protocols...


There are important phases to the development and deployment of a 
specification.  One of those is the period immediately after release of 
a new specification, as has been done with DMARC.  Existing implementers 
have just made a large investment.  New adopters need to assess whether 
they are going to be safe in implementing the existing spec or whether 
they should wait.

Change the spec in ways that force significant -- or worse, incompatible 
-- software changes too quickly, and the adoption of the technology is 
severely disrupted due to market confusion.  The folks that did the 
X.400 email specs learned this the hard way.  Many others have too.

Hence my point about the recent, extensive deployment of DMARC.

A serious bug is one thing; those need to be fixed.  Stray changes that 
are not essential are quite another; those can be deferred.  Working 
groups often show less concern for the distinction than one would like.

The classic charter language ultimately says that a working group can do 
whatever it wants -- and no matter what 'preferences' are expressed in 
the charter text, the ultimate rule that gets specified is 'the working 
group decides whatever it wants'.  It needs a better anchor.

Hence the current draft requires consulting the installed base.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From scott@kitterman.com  Mon Apr  1 18:52:41 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B268D11E80A6 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 18:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVddJW-EKMRd for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 18:52:41 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id F0E4611E80A5 for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 18:52:40 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 74D7820E40D5; Mon,  1 Apr 2013 21:52:40 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1364867560; bh=U7PRFk8xBAcrtd3+aZBa29poRMLriDoticepSjswV20=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WJsfPo7NJknXhnthjKJ4CqYPUup0GtTsid5TKkflRxkqxJB2p3ounTVUST7xeg9I2 T9XPMWM9BtbMx/7iweyDh9s1573G6uVRShFvHIwyDe8uTOp9bPvev+uBV7T2JMM5Hp mYsuK1mnMHZ7cZywaeL35Z3csqactoBqLGzJr08E=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 58D1920E4090;  Mon,  1 Apr 2013 21:52:39 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Mon, 01 Apr 2013 21:52:39 -0400
Message-ID: <1981405.krhrID7K1t@scott-latitude-e6320>
User-Agent: KMail/4.9.5 (Linux/3.5.0-26-generic; KDE/4.9.5; i686; ; )
In-Reply-To: <515A35EE.4010503@dcrocker.net>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <515A2858.2000907@stpeter.im> <515A35EE.4010503@dcrocker.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 01:52:41 -0000

On Monday, April 01, 2013 06:35:42 PM Dave Crocker wrote:
> On 4/1/2013 5:37 PM, Peter Saint-Andre wrote:
> > FWIW, the original XMPP WG (2002) had the following text in its
> > charter regarding backward compatibility with the existing
> > implementations and deployments of the Jabber protocols...
> 
> There are important phases to the development and deployment of a
> specification.  One of those is the period immediately after release of
> a new specification, as has been done with DMARC.  Existing implementers
> have just made a large investment.  New adopters need to assess whether
> they are going to be safe in implementing the existing spec or whether
> they should wait.
> 
> Change the spec in ways that force significant -- or worse, incompatible
> -- software changes too quickly, and the adoption of the technology is
> severely disrupted due to market confusion.  The folks that did the
> X.400 email specs learned this the hard way.  Many others have too.
> 
> Hence my point about the recent, extensive deployment of DMARC.
> 
> A serious bug is one thing; those need to be fixed.  Stray changes that
> are not essential are quite another; those can be deferred.  Working
> groups often show less concern for the distinction than one would like.
> 
> The classic charter language ultimately says that a working group can do
> whatever it wants -- and no matter what 'preferences' are expressed in
> the charter text, the ultimate rule that gets specified is 'the working
> group decides whatever it wants'.  It needs a better anchor.
> 
> Hence the current draft requires consulting the installed base.

If the installed base cares about backward compatibility, then they should 
show up for the working group.  The IETF is a much more open venue than where 
DMARC was incubated.  No matter how painful it is to contemplate, if it's not 
the IETF that has change control and the final say, then it's not IETF work.

I think using the DKIM charter as a model is a reasonable compromise.  I think 
there are enough people who understand deployment momentum and what's been 
done so far that you needn't worry over much about change for change sake 
being dumped on DMARC.

Scott K

From stpeter@stpeter.im  Mon Apr  1 18:56:23 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E822521F8EC8 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 18:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmzPHTfdVvAK for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 18:56:22 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E05B821F8EBE for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 18:56:22 -0700 (PDT)
Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3CA2D40D3A; Mon,  1 Apr 2013 20:06:02 -0600 (MDT)
Message-ID: <515A3AC6.8020504@stpeter.im>
Date: Mon, 01 Apr 2013 19:56:22 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Scott Kitterman <scott@kitterman.com>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <515A2858.2000907@stpeter.im> <515A35EE.4010503@dcrocker.net> <1981405.krhrID7K1t@scott-latitude-e6320>
In-Reply-To: <1981405.krhrID7K1t@scott-latitude-e6320>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 01:56:24 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 4/1/13 7:52 PM, Scott Kitterman wrote:

> If the installed base cares about backward compatibility, then they
> should show up for the working group.

A big +1 to that. It's not a cure-all, but it sure helps to keep a
working group from going astray.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRWjrFAAoJEOoGpJErxa2ptf4P/0+EEuJUcsdoyFUtmyFa6liJ
d5sHAS1E00RKcaXR861E78Y52QiPsQWWgd0smEf6VUKcF8KUH64Whq6Kj3JNMIgg
UDaaPcZ5ppsKzoej6qEhB/oEttbCQ8YKoTkkuH+EaYLFg96NMHBlinM8SXVl1usn
xi0Pd9yCmIKCO/mpNKD6GSmI+yPfG6aXZEEqCI1uAQbkBOmzrc/O/ZUcarZ39WNh
i5szmWZYs9mxbkvIIYOQecNlb4b8xsJemXXPA+LCIGJevXDb+K4lRs1R9u9qyr4j
/DOo2vQb6XAeFNmHHNWqe/6P48Ym3Bh07VccRMfXGlteQgIxFdhykOBKvrG1L/lK
c0ZkV8OjsmkBMoSwNeku4OM4IXv5YGXIE6B3yOk6uw43r1GPsIEck1KueofXp/l5
gwktpWXPDrDRpgwtGhIGSHbv/cDzCi9eJOHQ3CSG16WHS6p/QW2LSbNb4lF5Ygo3
TlrVNHeYVkUN8kEpsDXqFlqKfLFrNZRuiRVHNa2TdR8xHZU32SwVJPnu9bantBw7
+clRu+CGz8/cNwFkNBFiLf6rRHQ1dAgrDoTFhSyth3xcoW6PUmvyT2imIcxRuMnQ
2nx8Rx+xTH6rZBpvctapv59zLNOLTSGmGGbOA67skeRWsc/zXv6OcrrKmaSfMpC4
bDnUz6UEBfH/qyf6cSqU
=YREL
-----END PGP SIGNATURE-----

From susielu25@gmail.com  Mon Apr  1 19:28:15 2013
Return-Path: <susielu25@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA9721E80E4 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 19:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSuwRxMsbfAH for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 19:28:15 -0700 (PDT)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3267E21E804A for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 19:28:15 -0700 (PDT)
Received: by mail-ie0-f182.google.com with SMTP id at1so2998275iec.13 for <apps-discuss@ietf.org>; Mon, 01 Apr 2013 19:28:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=emAqBy85Gx7goBPINGjndsIdSQV0bDKo4IFGNSsrwrg=; b=OWQMfupkr1QlBqQBojJJFHweqhPVEsYM8Op0krDYpX31/nN0AR3QgOuu+rR8cWudtc N65kpT7dXkCC7RTTEVIoYEoDCNeWy+MovbbdaqyxRPpNaCql7n3v2WZONT7CJsmpQKBy Wq3dSsqMSOZb0wC0HOmufzXZVlWF0ZmTFhuL8Zl/kVUDkuR9ZInM6zzoRbqSIDks88nr qXmZkAQ9F5w2Aqi3cGFrLeJ1p8k9U3/RzSC/W94PAfHmn45+ffag9+13yTOidUFBLNBd tywebxcvrL+KwQ++7R8w3lQLIOCuXHwrU3P4SOWK6+hkJpFfOlnsIjnu9N15Sjs9KZLB ROSw==
MIME-Version: 1.0
X-Received: by 10.50.192.138 with SMTP id hg10mr4202571igc.95.1364869694723; Mon, 01 Apr 2013 19:28:14 -0700 (PDT)
Received: by 10.50.112.71 with HTTP; Mon, 1 Apr 2013 19:28:14 -0700 (PDT)
Date: Tue, 2 Apr 2013 10:28:14 +0800
Message-ID: <CADVOzF4rPdyS0rEgd0Xdwn1ZLC_GEjCFCOqWw3csgAR4h-UjiQ@mail.gmail.com>
From: Susie Lu <susielu25@gmail.com>
To: apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=14dae9340717519c7404d9577d6a
Subject: Re: [apps-discuss] The Interconnection and Interoperability of Different Cloud-office Applications (IDCOA) with the HTML File Format draft-guo-idoca-with-the-html-file-format-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 02:28:15 -0000

--14dae9340717519c7404d9577d6a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Zhun=EF=BC=8C
     What are your I-D about? As I know , native office applications based
on XML. Then your draft are about some product ,such as Google Docs,
Microsoft Office 365, IBM Docs ,Zoho,ThinkFree,Cisco
WebEx,Evernote...?Thank you!




Susie

--14dae9340717519c7404d9577d6a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"font-family:arial,sans-serif;font-size:13px=
">Zhun=EF=BC=8C</span><div><span style=3D"font-family:arial,sans-serif;font=
-size:13px">=C2=A0 =C2=A0 =C2=A0What are your I-D about? As I know , native=
 office applications based on XML. Then your draft are about some product ,=
such as Google Docs, Microsoft Office 365, IBM Docs ,Zoho,ThinkFree,Cisco W=
ebEx,Evernote...?Thank you!</span><br>
</div><div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br>=
</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=
x"><br></span></div><div><span style=3D"font-family:arial,sans-serif;font-s=
ize:13px"><br>
</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=
x"><br></span></div><div style><span style=3D"font-family:arial,sans-serif;=
font-size:13px">Susie</span></div></div>

--14dae9340717519c7404d9577d6a--

From dhc@dcrocker.net  Mon Apr  1 19:31:13 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9D921F8EBE for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 19:31:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHUs1pakfsmK for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 19:31:13 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4228F21F8EBD for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 19:31:13 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r322VCVl017428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Apr 2013 19:31:13 -0700
Message-ID: <515A42EF.3010402@dcrocker.net>
Date: Mon, 01 Apr 2013 19:31:11 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <515A2858.2000907@stpeter.im> <515A35EE.4010503@dcrocker.net> <1981405.krhrID7K1t@scott-latitude-e6320> <515A3AC6.8020504@stpeter.im>
In-Reply-To: <515A3AC6.8020504@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 01 Apr 2013 19:31:13 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 02:31:14 -0000

On 4/1/2013 6:56 PM, Peter Saint-Andre wrote:
> A big +1 to that. It's not a cure-all, but it sure helps to keep a
> working group from going astray.


so does a well-written set of constraints in the charter.  that's why 
they are commonly provided.

the current text was written with quite a bit of thought; at this point 
i've no idea how many working group charters i've/we've written, but a 
fair number have been based on importing existing technology. (i didn't 
write the charter, but i happened to be the area director with oversight 
for initially bringing nfs into the ietf.)

no doubt the current draft needs improving.  so please offer 
improvements rather than replacements or explain the inherent 
deficiencies in the current text.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From stephen.farrell@cs.tcd.ie  Mon Apr  1 19:56:18 2013
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6498121E812C for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 19:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slRJfTcLYszC for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 19:56:17 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A389821E804A for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 19:56:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 213BDBE33; Tue,  2 Apr 2013 03:55:52 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQ1GFhpWJ2UT; Tue,  2 Apr 2013 03:55:50 +0100 (IST)
Received: from [10.87.48.8] (unknown [86.42.20.231]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B889BBE29; Tue,  2 Apr 2013 03:55:50 +0100 (IST)
Message-ID: <515A48B6.6080809@cs.tcd.ie>
Date: Tue, 02 Apr 2013 03:55:50 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: dcrocker@bbiw.net
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <515A2858.2000907@stpeter.im> <515A35EE.4010503@dcrocker.net> <1981405.krhrID7K1t@scott-latitude-e6320> <515A3AC6.8020504@stpeter.im> <515A42EF.3010402@dcrocker.net>
In-Reply-To: <515A42EF.3010402@dcrocker.net>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 02:56:18 -0000

On 04/02/2013 03:31 AM, Dave Crocker wrote:
> 
> On 4/1/2013 6:56 PM, Peter Saint-Andre wrote:
>> A big +1 to that. It's not a cure-all, but it sure helps to keep a
>> working group from going astray.
> 
> 
> so does a well-written set of constraints in the charter.  that's why
> they are commonly provided.
> 
> the current text was written with quite a bit of thought; at this point
> i've no idea how many working group charters i've/we've written, but a
> fair number have been based on importing existing technology. (i didn't
> write the charter, but i happened to be the area director with oversight
> for initially bringing nfs into the ietf.)
> 
> no doubt the current draft needs improving.  so please offer
> improvements rather than replacements or explain the inherent
> deficiencies in the current text.

I think improvements that do replace current text have been
offered already (dkim or xmpp style text wrt maintaining
backwards compatibility) and deficiencies in the current text
have been pointed out (not clearly ceding change control)
that do motivate those improvements. Both suggested
improvements are also based on successful cases where
technologies have been brought into the IETF and one of
those (DKIM) is even closely related to dmarc.

Given that you seem to be asking for what's already been
provided, I'd say we must be close to done on this aspect:-)

S.

> 
> d/

From sm@resistor.net  Mon Apr  1 20:12:06 2013
Return-Path: <sm@resistor.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7322F21E814A for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 20:12:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvpRmBmyzp1Z for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 20:12:05 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD1521E8140 for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 20:12:05 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3239LHS027991; Mon, 1 Apr 2013 20:09:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364872167; bh=T1S/+6aW5G71aYpuQe+0tL50deVEssPoej4uK0RRvBI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=o1phm+neLhdS5whfLhVlLO7atQi9tp06UYZCGDI3Ra7m0TvF3Uk5xvoNVBCWn4Mdn 9PfnmYMPNhDi+87TjzIVOmBTsuTO5WiekIxG5cisHP1/5+Ej2O7jgmhfBuBE3fdGZ3 z7kcGuEMAFbQQJPS2z1pP724xTYK2gmJ8iUHKL7s=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1364872167; i=@resistor.net; bh=T1S/+6aW5G71aYpuQe+0tL50deVEssPoej4uK0RRvBI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Z1xH9DOLaepCQhlaJM8h7z/XHUl17dTb5grHBn403A9dBAXuyVwWtoi8/uswM7rHK 3QV8SB6e0qmHIqJ2k63igdHTgbzsxqVbaQa64UWrlYiopS/s6fsHJvLbOk508j8Yd9 NH8dZlJwrUnt31CsGQaO5d2Ws7mtoA/dowhKReHU=
Message-Id: <6.2.5.6.2.20130401193117.0aba0f00@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 01 Apr 2013 20:04:01 -0700
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Murray S. Kucherawy" <superuser@gmail.com>
From: SM <sm@resistor.net>
In-Reply-To: <5159D7A4.4000701@cs.tcd.ie>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 03:12:06 -0000

At 11:53 01-04-2013, Stephen Farrell wrote:
>Both of those would seem like charter-show-stoppers to me (and
>fairly reek of rubber-stamping to put it pejoratively).

Whether it is true or not the perception will be that the proposed 
working group is rubber-stamping a specification.  The wording for 
the proposed charter sounds like the IETF does not have change 
control over the specification it is publishing.  Such an approach 
has been tried with various degrees of success.  Lack of change 
control causes unhappiness; it generates more work for WG Chairs and 
increases the probability of process issues.

It's easier to let a draft that will be used as an input document 
stand on its own merit instead of wordsmithing charter language to 
ensure a particular outcome.

Regards,
-sm


From dhc@dcrocker.net  Mon Apr  1 22:33:09 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880C021F97B1 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 22:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOWGVJsWBHw3 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 22:33:08 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDAD21F984B for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 22:33:08 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r325X1r3020010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Apr 2013 22:33:03 -0700
Message-ID: <515A6D8C.7080404@dcrocker.net>
Date: Mon, 01 Apr 2013 22:33:00 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: SM <sm@resistor.net>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <6.2.5.6.2.20130401193117.0aba0f00@resistor.net>
In-Reply-To: <6.2.5.6.2.20130401193117.0aba0f00@resistor.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 01 Apr 2013 22:33:04 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 05:33:09 -0000

On 4/1/2013 8:04 PM, SM wrote:
> Such an approach has been tried with various degrees of success.  Lack
> of change control causes unhappiness; it generates more work for WG
> Chairs and increases the probability of process issues.

SM,

Please elaborate.  In particular, when has a well-constructed charter 
constraint worked poorly?

As for generating more work for the Chairs, a major selling point behind 
tight charters is to make it easier for chairs to help the working group 
distinguish between work that is in-scope and out of scope.  Again, what 
examples do you have of a well-constructed charter constraint causing 
more work for chairs?

And what process issues do you know of that happened?

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From sm@resistor.net  Mon Apr  1 23:55:45 2013
Return-Path: <sm@resistor.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD7521F9879 for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 23:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vML+6M6Y+Jbb for <apps-discuss@ietfa.amsl.com>; Mon,  1 Apr 2013 23:55:44 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E6721F9878 for <apps-discuss@ietf.org>; Mon,  1 Apr 2013 23:55:44 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r326s5k1015810; Mon, 1 Apr 2013 23:54:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1364885653; bh=iLXeRbp6twXUlv8VdOSnZspRQ/QLRHxGB32DuVLLMjo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cZFFEqio7RjX60+rg6BgCAoJ/9vkBR9/NqTJfCrLlqFk/AduseB3sirnIkgBYSs/I F3SgRyv8MhO7UIa+gqvtfMy8WaarFk7TmdxIeSAz6Pir+gHHSdTmKj1ZnT1Vnt9MA+ eadkm9gobZAEDqCpEWxPPiJmKNTs2gWobKJ68jDQ=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1364885653; i=@resistor.net; bh=iLXeRbp6twXUlv8VdOSnZspRQ/QLRHxGB32DuVLLMjo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dSoP06+QQTHbzemjvBlfKSKTMVDaLiWsvdkqU+CMGZGHJSvA3Q2ALc/qk6Bzgmvio Tq8TtVYiH7iuGDhXa5SQk+UadlSi2XuBugz+bYdzuiGCKRIV+xGsTx6xAb1O3lUo6m YicdefkuE4Bxv+Hc70wc+7JPQVbaVXCVaOmU6I8s=
Message-Id: <6.2.5.6.2.20130401225702.0c152ef8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 01 Apr 2013 23:27:35 -0700
To: dcrocker@bbiw.net
From: SM <sm@resistor.net>
In-Reply-To: <515A6D8C.7080404@dcrocker.net>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <6.2.5.6.2.20130401193117.0aba0f00@resistor.net> <515A6D8C.7080404@dcrocker.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 06:55:45 -0000

Hi Dave,
At 22:33 01-04-2013, Dave Crocker wrote:
>Please elaborate.  In particular, when has a well-constructed 
>charter constraint worked poorly?

I'll try and explain.  It might not answer the above question.  In 
general, if the author is reluctant to give the IETF change control 
it can end up as a problem during the working group work.  The 
constraints are less about what is in the charter and more about how 
to get the group to work together.

I don't know whether the DKIM charter was well-constructed or not (I 
have not looked at it recently).  I know that the question of DKIM 
was raised in one working group.  I am not thinking about whether the 
question has merit or not; in my humble opinion it makes the work 
more difficult.

>As for generating more work for the Chairs, a major selling point 
>behind tight charters is to make it easier for chairs to help the 
>working group distinguish between work that is in-scope and out of 
>scope.  Again, what examples do you have of a well-constructed 
>charter constraint causing more work for chairs?

It is not about well-constructed charters.  The charter of a 
particular working group was tightly scoped.  However, there were 
discussions about the scope.  Scope only works well when there is a 
cohesive group.  If the group is not cohesive there will likely be 
disagreement and that will cause more work for the chairs.

>And what process issues do you know of that happened?

I'll take this off-list.

Regards,
-sm 


From dhc@dcrocker.net  Tue Apr  2 12:14:52 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299A421F8C10 for <apps-discuss@ietfa.amsl.com>; Tue,  2 Apr 2013 12:14:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwOYW8AJ0PHp for <apps-discuss@ietfa.amsl.com>; Tue,  2 Apr 2013 12:14:51 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1D54321F87C3 for <apps-discuss@ietf.org>; Tue,  2 Apr 2013 12:14:51 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r32JEcqZ004050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 Apr 2013 12:14:39 -0700
Message-ID: <515B2E1D.4050102@dcrocker.net>
Date: Tue, 02 Apr 2013 12:14:37 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie> <515A1581.9030402@dcrocker.net> <515A2464.8090401@cs.tcd.ie>
In-Reply-To: <515A2464.8090401@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 02 Apr 2013 12:14:39 -0700 (PDT)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 19:14:52 -0000

Stephen,


On 4/1/2013 5:20 PM, Stephen Farrell wrote:
> On 04/02/2013 12:17 AM, Dave Crocker wrote:
>> DKIM had far less installed base on large operational services than
>> DMARC now has.
>
> Happy to hear that but I don't think it impacts on the
> points below. (Its news to me btw, but then its not my area
> so that's not surprising.)

If affects the chartering issues fundamentally, as I've explained.


> And to be clear: I do welcome folks bringing work to the
> IETF, esp. where it is or will be widely deployed.

Good to hear.  Perhaps you'll therefore consider being less terse, 
precipitous and simplistic in your responses then?

Really, Stephen, the way to encourage folks is to encourage them, not to 
post initial responses that are as dire as you've done.

Being encouraging doesn't mean saying yes to everything, but it does 
mean working to understand what they want to do and why and offering 
specific suggestions that go beyond "do it the way we've done it before 
or go away."


>> As for not knowing how to consult outside the working group, surely you
>> jest.  We do it all the time.
>
> Not with such vaguely characterised "others" and nor with
> giving 'em anti-change-control that I can recall. Feel free
> to point me at examples that do those things. If the text
> isn't meant to severely constrain IETF change-control then
> it needs a re-write 'cause it reads to me like that's the
> intent.

Ahh, so your concern is not what you originally stated, but is more 
nuanced.  Excellent.  That's worthy of discussion.


> If the "others" are actually well-known and are really
> dmarc.org members then saying that would seem to be
> useful to start with.

Clarifying who should be consulted and how could make complete sense.

How is it that the existing draft text "other developers and operators 
of DMARC-based mechanisms" is not sufficient"?  What would you suggest 
as better?


> But in any case since that dmarc.org group apparently want
> to cede change control then I think DKIM-like charter text
> is really what'd work best.

You (and SM) are confusing the difference between handing over change 
control, versus the permissible scope of work for the first effort, that 
is negotiated as part of the hand-over.

This is a balancing act, every time work is brought into the IETF.

It depends upon the maturity of the technology and the nature of its 
deployed based, as well as the list of work the community believes needs 
to be done.

For example, if you or anyone else has specific work to propose, then 
let's talk about it.  As part of the planning for bringing DMARC to the 
IETF, We did this within the dmarc.org group. We knew it's better to 
bring more 'interesting' work items to the initial round of effort in 
the IETF.  Unfortunately, we didn't see technical development tasks for 
the protocol that are needed right now.  Perhaps you or others do?


> If dmarc.org really don't want to cede change control then
> the ISE route would seen more appropriate than an IETF WG.

You appear to think that ceding change control means that the working 
group charter must impose no constraints on the scope of what is 
permitted by the initial working group charter.  That's not the history 
of charters for existing work that's (eventually) brought into the IETF. 
  The permitted types of changes -- and possible disruption to the 
installed base -- are an inherent part of that initial negotiation, each 
time.


>> As for:
>>> I don't know how the not-yet-formed WG can have a preference
>>
>> I don't know what you mean.
>
> WG-doesn't-exist-yet => WG-can't-have-opinion. That ought be
> trivial to fix, but is indicative of a possibly problematic

I do not know what language your are reading that asserts preferences 
for the not-yet-formed WG.


> conflation of the set of folks who drafted this text and the
> set of folks that might participate in a future IETF WG, which
> will include people who've never seen this draft for example.

Huh?  Again, I don't know what you mean, and your terseness about a 
potentially serious point isn't helping.

General request, Stephen:  Rather than tossing off this sort off terse, 
dire assertions, please invest some effort into explaining what you mean 
and what the basis is.



d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From stephen.farrell@cs.tcd.ie  Tue Apr  2 13:31:49 2013
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEBF21F8D2D for <apps-discuss@ietfa.amsl.com>; Tue,  2 Apr 2013 13:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jogH7sQn0TkR for <apps-discuss@ietfa.amsl.com>; Tue,  2 Apr 2013 13:31:49 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id ADD4521F8D3C for <apps-discuss@ietf.org>; Tue,  2 Apr 2013 13:31:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id ED586BE25; Tue,  2 Apr 2013 21:31:25 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si4HFF7CpeHp; Tue,  2 Apr 2013 21:31:24 +0100 (IST)
Received: from [10.87.48.8] (unknown [86.41.49.2]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2F918BE24; Tue,  2 Apr 2013 21:31:24 +0100 (IST)
Message-ID: <515B401B.3070809@cs.tcd.ie>
Date: Tue, 02 Apr 2013 21:31:23 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: dcrocker@bbiw.net
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie> <515A1581.9030402@dcrocker.net> <515A2464.8090401@cs.tcd.ie> <515B2E1D.4050102@dcrocker.net>
In-Reply-To: <515B2E1D.4050102@dcrocker.net>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 20:31:49 -0000

On 04/02/2013 08:14 PM, Dave Crocker wrote:
> Stephen,
> 
> 
> On 4/1/2013 5:20 PM, Stephen Farrell wrote:
>> On 04/02/2013 12:17 AM, Dave Crocker wrote:
>>> DKIM had far less installed base on large operational services than
>>> DMARC now has.
>>
>> Happy to hear that but I don't think it impacts on the
>> points below. (Its news to me btw, but then its not my area
>> so that's not surprising.)
> 
> If affects the chartering issues fundamentally, as I've explained.

Sure. But not these specific issues IMO.

>> And to be clear: I do welcome folks bringing work to the
>> IETF, esp. where it is or will be widely deployed.
> 
> Good to hear.  Perhaps you'll therefore consider being less terse,

Terse is good I've found when dealing with folks who might
misinterpret extraneous words.

> precipitous and simplistic in your responses then?
>
> Really, Stephen, the way to encourage folks is to encourage them, not to
> post initial responses that are as dire as you've done.
> 
> Being encouraging doesn't mean saying yes to everything, but it does
> mean working to understand what they want to do and why and offering
> specific suggestions that go beyond "do it the way we've done it before
> or go away."

Precipitous, simplistic and dire seem to me to be purely
pejorative terms. I don't think they help.

>>> As for not knowing how to consult outside the working group, surely you
>>> jest.  We do it all the time.
>>
>> Not with such vaguely characterised "others" and nor with
>> giving 'em anti-change-control that I can recall. Feel free
>> to point me at examples that do those things. If the text
>> isn't meant to severely constrain IETF change-control then
>> it needs a re-write 'cause it reads to me like that's the
>> intent.
> 
> Ahh, so your concern is not what you originally stated, but is more
> nuanced.  Excellent.  That's worthy of discussion.
> 
>> If the "others" are actually well-known and are really
>> dmarc.org members then saying that would seem to be
>> useful to start with.
> 
> Clarifying who should be consulted and how could make complete sense.
> 
> How is it that the existing draft text "other developers and operators
> of DMARC-based mechanisms" is not sufficient"?  What would you suggest
> as better?

Best is if those who want to influence WG consensus get involved
in the WG. I can buy that not everyone has time though, but not
that some WG participants are allowed get away with "I consulted
with my unspecified friends and they don't like this proposed
change, so the charter says you can't make that change." The
current text seems too close to the latter IMO.

Again, the approach that worked for DKIM and XMPP seems to me
like it'd be fine.

>> But in any case since that dmarc.org group apparently want
>> to cede change control then I think DKIM-like charter text
>> is really what'd work best.
> 
> You (and SM) are confusing the difference between handing over change
> control, versus the permissible scope of work for the first effort, that
> is negotiated as part of the hand-over.
> 
> This is a balancing act, every time work is brought into the IETF.

I agree its a balancing act, and disagree that I'm at all confused.

> It depends upon the maturity of the technology and the nature of its
> deployed based, as well as the list of work the community believes needs
> to be done.

"the community" could mean the existing dmarc.org or the putative
WG. It seems to me that the confusion (if any) is that those
are being conflated - they're clearly closely related but not
the same.

> For example, if you or anyone else has specific work to propose, then
> let's talk about it.  As part of the planning for bringing DMARC to the
> IETF, We did this within the dmarc.org group. We knew it's better to
> bring more 'interesting' work items to the initial round of effort in
> the IETF.  Unfortunately, we didn't see technical development tasks for
> the protocol that are needed right now.  Perhaps you or others do?
> 
> 
>> If dmarc.org really don't want to cede change control then
>> the ISE route would seen more appropriate than an IETF WG.
> 
> You appear to think that ceding change control means that the working
> group charter must impose no constraints on the scope of what is
> permitted by the initial working group charter.  

Nope. The charter can describe any technical constraints and that's
perfectly reasonable, assuming the charter text gets agreed etc.
Doing new process innovations that change how WG consensus is judged
in the charter isn't the same thing. I think the current text seems
too close to the latter.

Yet again, what worked for DKIM and XMPP seems fine to me.

> That's not the history
> of charters for existing work that's (eventually) brought into the IETF.
>  The permitted types of changes -- and possible disruption to the
> installed base -- are an inherent part of that initial negotiation, each
> time.
> 
> 
>>> As for:
>>>> I don't know how the not-yet-formed WG can have a preference
>>>
>>> I don't know what you mean.
>>
>> WG-doesn't-exist-yet => WG-can't-have-opinion. That ought be
>> trivial to fix, but is indicative of a possibly problematic
> 
> I do not know what language your are reading that asserts preferences
> for the not-yet-formed WG.

"The strong preference is for the working group to preserve existing
software and procedures."

>> conflation of the set of folks who drafted this text and the
>> set of folks that might participate in a future IETF WG, which
>> will include people who've never seen this draft for example.
> 
> Huh?  Again, I don't know what you mean, and your terseness about a
> potentially serious point isn't helping.

Sorry.

> General request, Stephen:  Rather than tossing off this sort off terse,
> dire assertions, please invest some effort into explaining what you mean
> and what the basis is.

Terse != dire:-)

S.

> 
> 
> 
> d/

From wwwrun@rfc-editor.org  Tue Apr  2 17:36:59 2013
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1054421E8044; Tue,  2 Apr 2013 17:36:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.7
X-Spam-Level: 
X-Spam-Status: No, score=-101.7 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfj6AKQYaC2S; Tue,  2 Apr 2013 17:36:58 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9D221E8043; Tue,  2 Apr 2013 17:36:56 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 4F0E5B1E003; Tue,  2 Apr 2013 17:36:48 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20130403003648.4F0E5B1E003@rfc-editor.org>
Date: Tue,  2 Apr 2013 17:36:48 -0700 (PDT)
Cc: apps-discuss@ietf.org, rfc-editor@rfc-editor.org
Subject: [apps-discuss] RFC 6901 on JavaScript Object Notation (JSON) Pointer
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2013 00:36:59 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6901

        Title:      JavaScript Object Notation (JSON) Pointer 
        Author:     P. Bryan, Ed.,
                    K. Zyp, 
                    M. Nottingham, Ed.
        Status:     Standards Track
        Stream:     IETF
        Date:       April 2013
        Mailbox:    pbryan@anode.ca, 
                    kris@sitepen.com, 
                    mnot@mnot.net
        Pages:      8
        Characters: 13037
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-appsawg-json-pointer-09.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6901.txt

JSON Pointer defines a string syntax for identifying a specific value
within a JavaScript Object Notation (JSON) document.

This document is a product of the Applications Area Working Group Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From wwwrun@rfc-editor.org  Tue Apr  2 17:37:09 2013
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F9A21E8053; Tue,  2 Apr 2013 17:37:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.733
X-Spam-Level: 
X-Spam-Status: No, score=-101.733 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6cikYYt5xkb; Tue,  2 Apr 2013 17:37:08 -0700 (PDT)
Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9150C21E804D; Tue,  2 Apr 2013 17:37:08 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 439F8B1E00B; Tue,  2 Apr 2013 17:37:00 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20130403003700.439F8B1E00B@rfc-editor.org>
Date: Tue,  2 Apr 2013 17:37:00 -0700 (PDT)
Cc: apps-discuss@ietf.org, rfc-editor@rfc-editor.org
Subject: [apps-discuss] RFC 6902 on JavaScript Object Notation (JSON) Patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2013 00:37:09 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6902

        Title:      JavaScript Object Notation (JSON) Patch 
        Author:     P. Bryan, Ed.,
                    M. Nottingham, Ed.
        Status:     Standards Track
        Stream:     IETF
        Date:       April 2013
        Mailbox:    pbryan@anode.ca, 
                    mnot@mnot.net
        Pages:      18
        Characters: 26405
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-appsawg-json-patch-10.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6902.txt

JSON Patch defines a JSON document structure for expressing a
sequence of operations to apply to a JavaScript Object Notation
(JSON) document; it is suitable for use with the HTTP PATCH method.
The "application/json-patch+json" media type is used to identify such
patch documents.

This document is a product of the Applications Area Working Group Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From dave@cridland.net  Wed Apr  3 03:18:36 2013
Return-Path: <dave@cridland.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA9C21F850F for <apps-discuss@ietfa.amsl.com>; Wed,  3 Apr 2013 03:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ov2cFCIpzFV9 for <apps-discuss@ietfa.amsl.com>; Wed,  3 Apr 2013 03:18:35 -0700 (PDT)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2550521F85C9 for <apps-discuss@ietf.org>; Wed,  3 Apr 2013 03:18:34 -0700 (PDT)
Received: by mail-ob0-f179.google.com with SMTP id vb8so1207446obc.24 for <apps-discuss@ietf.org>; Wed, 03 Apr 2013 03:18:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lXLoqsjuCTOizquUpypuhCvR80ISlhtzGMU30yzZdw8=; b=WrQioIK9tDLfJPnsfZw9OK0puTQgtRPJZHCVlsVUK0v/9bjuoSO1iizeZHiRyNZ+rw 3d6fY+zaKdhF9Epe/Kz5KRemJHP8mE12GddMXJqukhi+nRo7tMAPfh4GWFfRLw9QR5kf IMUVFB5dN/UUAOFroRR3yjbX7NKgI4qmiwQZU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=lXLoqsjuCTOizquUpypuhCvR80ISlhtzGMU30yzZdw8=; b=ZiWeBDYOoDnvilOHcvkoWDwPW1Db1nvjzSrPIA20Ed3WdIxtxGz4gdTHo0W8NMA8fn S+gbPN9H3XIq3sDaBptGgY9aUidwTDnHElblKQPcI1pIUIg7bAV6S1dl12ngpo14PEPj mHaejnvc4O/bWe7o50wtgI9GIUvrgTrvcCD9s3eASYmHzBZo1QFwM1PieO+txnFWNqNL apV6Xm5MQkHOJOABOTUaExZyqwbV6sZVmKHTMWigJWH6C4GkRBPl6YYNp9MzYUsMnh78 2v9D1OnykymxZH2VlSrA6JGWNMaaJRjy6gYiUTZbcyVZyBljfJcAwMxXQdf4DID1gOQQ ZWyw==
MIME-Version: 1.0
X-Received: by 10.182.118.1 with SMTP id ki1mr714539obb.2.1364984313981; Wed, 03 Apr 2013 03:18:33 -0700 (PDT)
Received: by 10.60.22.105 with HTTP; Wed, 3 Apr 2013 03:18:33 -0700 (PDT)
In-Reply-To: <CAL0qLwY=VLkUZ7KMenj_ORQDwLOSdFS=x+q0a3N2KcxaT9q=Gw@mail.gmail.com>
References: <CAL0qLwbgjnt8Msofok3ExKBmChtQPfMEFgrrZBimEzU5CYgSjA@mail.gmail.com> <CAKHUCzxfBtLTt3p3moGgEQx+p5kr=-e2Mn58xaqNvWFGiW=Lpw@mail.gmail.com> <CAL0qLwY=VLkUZ7KMenj_ORQDwLOSdFS=x+q0a3N2KcxaT9q=Gw@mail.gmail.com>
Date: Wed, 3 Apr 2013 11:18:33 +0100
Message-ID: <CAKHUCzw5K3BHaWOk4GivJ-9tLvjo9v8exo=A0i8z3GeWdoQ8GQ@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0447f24028c6b704d9722deb
X-Gm-Message-State: ALoCoQmVjQqBl5RLFczPWr2TrBx5Shf5tPYfTJDtRYFAgMl1T7enFqKJ9yrdgRu3qix3LYAT+qBj
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2013 10:18:36 -0000

--f46d0447f24028c6b704d9722deb
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Murray,

On Fri, Mar 22, 2013 at 7:21 PM, Murray S. Kucherawy <superuser@gmail.com>
wrote:
>
> Hi Dave, thanks for the review.   Comments below.
>

Thanks for the new versions (so many it confused me greatly trying to
review the diffs - slow down!).

>
> On Fri, Mar 15, 2013 at 4:34 AM, Dave Cridland <dave@cridland.net> wrote:
>>
>> For the most part, this document looks fine and solid.
>
>
> Hooray!
>
>>
>>
>> Two items concern me in a major way; one further item has me mildly
nervous.
>>
>> First, the minor one:
>>
>> The header includes definition of a version ABNF production optionally
following the authentication server's identity. It took me some time to
find the note of how to treat this; I didn't see any examples with it
present either.
>
>
> I've updated one of the examples to include a version.
>


This satisfies my comment, FTR.

>>
>>
>> Second, the first major one:
>>
>> The examples tend to imply, for the most part, a canonical form to the
header, which places CFWS is only particular places. In particular, all the
examples are of the form auth-srv-id "; " method "=3D" result, with some
optional properties and/or reason, with one single exception (which
includes a comment in lieu of a reason). It's not immediately apparent to a
comparatively novice reader that the following header field is valid:
>>
>> Authentication-Results: foo.example.net (My mailserver) / (I am number)
1 (You see) ; dkim (Because I like it) /2 (Two yay) =3D (wait for it) pass =
;
policy (And a dot can go here) . (Like that) fruit (which surprised me) =3D
(because I was not expecting it) banana
>>
>>
>> I appreciate it's always nicer to only write pretty examples, but given
the specification, providing a nasty one is probably needed, lest people
expect to take a whitespace delimited token and split it on '=3D'. For some
reason I particularly wasn't expecting the CFWS around the dot. (Maybe
that's because I'm out of practise with header parsing).
>>
>> In any case, highlighting this with an example seems appropriate and
useful.
>
>
>
> Copied to the draft, with some adjustments to make it compliant and fit
the width limit.
>


Likewise, this satisfies my comment.

>>
>>
>> Thirdly, one more major concern:
>>
>> You'll note that I included a version for the method in my example
above. The definition for this, from the comments in the ABNF, suggests
that this relates to the version of RFC 5451 and successors used, but this
seems unlikely - I'm also at a loss as to what a receiving implementation
should do with such a method, since the handling of version seems to be
specified only for the version number after the auth-srv-id.
>>
>> I have a vague suspicion that the correct thing to do here may be to
deprecate the method version entirely, but I might be missing something -
still, it doesn't appear to relate to the method, but the header field.
>>
>>
>
> The method version refers to the method itself, which is specified
elsewhere; the authserv-id version refers to this draft and thus the syntax
of this header field.  The idea is that if you find a version after an
authserv-id that you can't handle, you stop trying to parse right away
because what follows might not be what you expect.  In terms of a method
version, the parser should ignore a method result if the version of the
version is not supported in case the semantics of the result have a
different meaning.  If, for example, DKIM v2 (were such a thing to exist)
yielded a "pass" for different reasons than v1 did, a consumer of this
field might not want the altered semantics to apply.  This is a way to
indicate this and let the consumer decide.
>
> Is your reply to this "You should say that?"  :-)
>


Yes... And I think your =A72.4 "Version Tokens" (new in -03) is good here.

However, you have in -04's ABNF (with much elided):

     authres-header =3D "Authentication-Results:" [CFWS] authserv-id
              [ [CFWS] "/" [CFWS] version ]
              ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF
            ; the special case of "none" is used to indicate that no
            ; message authentication is performed

     version =3D 1*DIGIT [CFWS]
             ; indicates which version of this specification is in use;
             ; this specification is version "1", and the absence of a
             ; version implies this version of the specification

     method =3D Keyword [ [CFWS] "/" [CFWS] version ]
            ; a method indicates which method's result is
            ; represented by "result", and is one of the methods
            ; explicitly defined as valid in this document
            ; or is an extension method as defined below

The conflation of the two different versions into one is (I find)
confusing, though =A72.4 goes a long way to correcting that - perhaps far
enough, but I remain uneasy.

I think your choices are:

a) Rewrite the comment below the version production to point the reader to
=A72.4

b) Introduce two different productions, one for "authres-version" and one
for "method-version", such that:

     authres-header =3D "Authentication-Results:" [CFWS] authserv-id
              [ [CFWS] "/" [CFWS] authres-version ]
              ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF
            ; the special case of "none" is used to indicate that no
            ; message authentication is performed

     authres-version =3D version [CFWS]
             ; indicates which version of this specification is in use;
             ; this specification is version "1", and the absence of a
             ; version implies this version of the specification

     method =3D Keyword [ [CFWS] "/" [CFWS] method-version ]
            ; a method indicates which method's result is
            ; represented by "result", and is one of the methods
            ; explicitly defined as valid in this document
            ; or is an extension method as defined below

     method-version =3D version [CFWS]
             ; indicates which version of the method specification is in
use;
             ; those those methods defined in this specification are
version "1", and the absence
             ; of a method-version implies this specification

     version =3D 1*DIGIT
             ; Version numbers are a simple string of digits; point
versions are not allowed.

c) Or, of course, both.

d) Ignore me.

Using (b) gives you the option of using those terms in =A72.4 (and elsewher=
e
as needed) to clarify which version you mean you mean, too.

Obviously I'd rather you didn't do (d), but I'll accept it if you do. :-)

Dave.

--f46d0447f24028c6b704d9722deb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Murray,<br><br>On Fri, Mar 22, 2013 at 7:21 PM, Murray S. =
Kucherawy &lt;<a href=3D"mailto:superuser@gmail.com">superuser@gmail.com</a=
>&gt; wrote:<br>&gt;<br>&gt; Hi Dave, thanks for the review. =A0 Comments b=
elow.<br>
&gt;<br><br>Thanks for the new versions (so many it confused me greatly try=
ing to review the diffs - slow down!).<br>=A0<br>&gt;<br>&gt; On Fri, Mar 1=
5, 2013 at 4:34 AM, Dave Cridland &lt;<a href=3D"mailto:dave@cridland.net">=
dave@cridland.net</a>&gt; wrote:<br>
&gt;&gt;<br>&gt;&gt; For the most part, this document looks fine and solid.=
<br>&gt;<br>&gt;<br>&gt; Hooray!<br>&gt; =A0<br>&gt;&gt;<br>&gt;&gt;<br>&gt=
;&gt; Two items concern me in a major way; one further item has me mildly n=
ervous.<br>
&gt;&gt;<br>&gt;&gt; First, the minor one:<br>&gt;&gt;<br>&gt;&gt; The head=
er includes definition of a version ABNF production optionally following th=
e authentication server&#39;s identity. It took me some time to find the no=
te of how to treat this; I didn&#39;t see any examples with it present eith=
er.<br>
&gt;<br>&gt;<br>&gt; I&#39;ve updated one of the examples to include a vers=
ion.<br>&gt; =A0<br><br><br>This satisfies my comment, FTR.<br>=A0<br>&gt;&=
gt;<br>&gt;&gt;<br>&gt;&gt; Second, the first major one:<br>&gt;&gt;<br>&gt=
;&gt; The examples tend to imply, for the most part, a canonical form to th=
e header, which places CFWS is only particular places. In particular, all t=
he examples are of the form auth-srv-id &quot;; &quot; method &quot;=3D&quo=
t; result, with some optional properties and/or reason, with one single exc=
eption (which includes a comment in lieu of a reason). It&#39;s not immedia=
tely apparent to a comparatively novice reader that the following header fi=
eld is valid:<br>
&gt;&gt;<br>&gt;&gt; Authentication-Results: <a href=3D"http://foo.example.=
net">foo.example.net</a> (My mailserver) / (I am number) 1 (You see) ; dkim=
 (Because I like it) /2 (Two yay) =3D (wait for it) pass ; policy (And a do=
t can go here) . (Like that) fruit (which surprised me) =3D (because I was =
not expecting it) banana<br>
&gt;&gt;<br>&gt;&gt;<br>&gt;&gt; I appreciate it&#39;s always nicer to only=
 write pretty examples, but given the specification, providing a nasty one =
is probably needed, lest people expect to take a whitespace delimited token=
 and split it on &#39;=3D&#39;. For some reason I particularly wasn&#39;t e=
xpecting the CFWS around the dot. (Maybe that&#39;s because I&#39;m out of =
practise with header parsing).<br>
&gt;&gt;<br>&gt;&gt; In any case, highlighting this with an example seems a=
ppropriate and useful.<br>&gt;<br>&gt;<br>&gt;<br>&gt; Copied to the draft,=
 with some adjustments to make it compliant and fit the width limit.<br>
&gt; =A0<br><br><br>Likewise, this satisfies my comment.<br>=A0<br>&gt;&gt;=
<br>&gt;&gt;<br>&gt;&gt; Thirdly, one more major concern:<br>&gt;&gt;<br>&g=
t;&gt; You&#39;ll note that I included a version for the method in my examp=
le above. The definition for this, from the comments in the ABNF, suggests =
that this relates to the version of RFC 5451 and successors used, but this =
seems unlikely - I&#39;m also at a loss as to what a receiving implementati=
on should do with such a method, since the handling of version seems to be =
specified only for the version number after the auth-srv-id.<br>
&gt;&gt;<br>&gt;&gt; I have a vague suspicion that the correct thing to do =
here may be to deprecate the method version entirely, but I might be missin=
g something - still, it doesn&#39;t appear to relate to the method, but the=
 header field.<br>
&gt;&gt;<br>&gt;&gt;<br>&gt;<br>&gt; The method version refers to the metho=
d itself, which is specified elsewhere; the authserv-id version refers to t=
his draft and thus the syntax of this header field. =A0The idea is that if =
you find a version after an authserv-id that you can&#39;t handle, you stop=
 trying to parse right away because what follows might not be what you expe=
ct. =A0In terms of a method version, the parser should ignore a method resu=
lt if the version of the version is not supported in case the semantics of =
the result have a different meaning. =A0If, for example, DKIM v2 (were such=
 a thing to exist) yielded a &quot;pass&quot; for different reasons than v1=
 did, a consumer of this field might not want the altered semantics to appl=
y. =A0This is a way to indicate this and let the consumer decide.<br>
&gt;<br>&gt; Is your reply to this &quot;You should say that?&quot; =A0:-)<=
br>&gt;<br><br><br>Yes... And I think your =A72.4 &quot;Version Tokens&quot=
; (new in -03) is good here.<br><br>However, you have in -04&#39;s ABNF (wi=
th much elided):<br>
<br>=A0 =A0 =A0authres-header =3D &quot;Authentication-Results:&quot; [CFWS=
] authserv-id<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 [ [CFWS] &quot;/&quot; [CFWS] =
version ]<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 ( [CFWS] &quot;;&quot; [CFWS] &quo=
t;none&quot; / 1*resinfo ) [CFWS] CRLF<br>
=A0 =A0 =A0 =A0 =A0 =A0 ; the special case of &quot;none&quot; is used to i=
ndicate that no<br>=A0 =A0 =A0 =A0 =A0 =A0 ; message authentication is perf=
ormed<br><br>=A0 =A0 =A0version =3D 1*DIGIT [CFWS]<br>=A0 =A0 =A0 =A0 =A0 =
=A0 =A0; indicates which version of this specification is in use;<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0; this specification is version &quot;1&quot;, a=
nd the absence of a<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0; version implies this ve=
rsion of the specification<br><br>=A0 =A0 =A0method =3D Keyword [ [CFWS] &q=
uot;/&quot; [CFWS] version ]<br>
=A0 =A0 =A0 =A0 =A0 =A0 ; a method indicates which method&#39;s result is<b=
r>=A0 =A0 =A0 =A0 =A0 =A0 ; represented by &quot;result&quot;, and is one o=
f the methods<br>=A0 =A0 =A0 =A0 =A0 =A0 ; explicitly defined as valid in t=
his document<br>=A0 =A0 =A0 =A0 =A0 =A0 ; or is an extension method as defi=
ned below<br>
<br>The conflation of the two different versions into one is (I find) confu=
sing, though =A72.4 goes a long way to correcting that - perhaps far enough=
, but I remain uneasy.<br><br>I think your choices are:<br><br>a) Rewrite t=
he comment below the version production to point the reader to =A72.4<br>
<br>b) Introduce two different productions, one for &quot;authres-version&q=
uot; and one for &quot;method-version&quot;, such that:<br><br>=A0 =A0 =A0a=
uthres-header =3D &quot;Authentication-Results:&quot; [CFWS] authserv-id<br=
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 [ [CFWS] &quot;/&quot; [CFWS] authres-version =
]<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 ( [CFWS] &quot;;&quot; [CFWS] &quot;none&quot; =
/ 1*resinfo ) [CFWS] CRLF<br>=A0 =A0 =A0 =A0 =A0 =A0 ; the special case of =
&quot;none&quot; is used to indicate that no<br>=A0 =A0 =A0 =A0 =A0 =A0 ; m=
essage authentication is performed<br>
<br>=A0 =A0 =A0authres-version =3D version [CFWS]<br>=A0 =A0 =A0 =A0 =A0 =
=A0 =A0; indicates which version of this specification is in use;<br>=A0 =
=A0 =A0 =A0 =A0 =A0 =A0; this specification is version &quot;1&quot;, and t=
he absence of a<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0; version implies this versio=
n of the specification<br>
<br>=A0 =A0 =A0method =3D Keyword [ [CFWS] &quot;/&quot; [CFWS] method-vers=
ion ]<br>=A0 =A0 =A0 =A0 =A0 =A0 ; a method indicates which method&#39;s re=
sult is<br>=A0 =A0 =A0 =A0 =A0 =A0 ; represented by &quot;result&quot;, and=
 is one of the methods<br>=A0 =A0 =A0 =A0 =A0 =A0 ; explicitly defined as v=
alid in this document<br>
=A0 =A0 =A0 =A0 =A0 =A0 ; or is an extension method as defined below<br><br=
>=A0 =A0 =A0method-version =3D version [CFWS]<br>=A0 =A0 =A0 =A0 =A0 =A0 =
=A0; indicates which version of the method specification is in use;<br>=A0 =
=A0 =A0 =A0 =A0 =A0 =A0; those those methods defined in this specification =
are version &quot;1&quot;, and the absence<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0; of a method-version implies this specification=
<br><br>=A0 =A0 =A0version =3D 1*DIGIT<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0; Vers=
ion numbers are a simple string of digits; point versions are not allowed.<=
br><br>c) Or, of course, both.<br>
<br>d) Ignore me.<br><br>Using (b) gives you the option of using those term=
s in =A72.4 (and elsewhere as needed) to clarify which version you mean you=
 mean, too.<br><br>Obviously I&#39;d rather you didn&#39;t do (d), but I&#3=
9;ll accept it if you do. :-)<br>
<br>Dave.<br></div>

--f46d0447f24028c6b704d9722deb--

From markus.lanthaler@gmx.net  Wed Apr  3 04:36:41 2013
Return-Path: <markus.lanthaler@gmx.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9126A21F8A6D for <apps-discuss@ietfa.amsl.com>; Wed,  3 Apr 2013 04:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level: 
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0QcleNgNWV0 for <apps-discuss@ietfa.amsl.com>; Wed,  3 Apr 2013 04:36:41 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id B9A2A21F862B for <apps-discuss@ietf.org>; Wed,  3 Apr 2013 04:36:40 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0ME0gb-1UPIsa2v5r-00HQPX for <apps-discuss@ietf.org>; Wed, 03 Apr 2013 13:36:39 +0200
Received: (qmail invoked by alias); 03 Apr 2013 11:36:39 -0000
Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp024) with SMTP; 03 Apr 2013 13:36:39 +0200
X-Authenticated: #419883
X-Provags-ID: V01U2FsdGVkX1+tBscEEqKtMho4IpEqQ/NBkzjTqmBSkyPaaaqSrV pN6itG9dlOwvmb
From: "Markus Lanthaler" <markus.lanthaler@gmx.net>
To: <apps-discuss@ietf.org>, "'Rest List'" <rest-discuss@yahoogroups.com>
Date: Wed, 3 Apr 2013 13:36:34 +0200
Message-ID: <00d501ce305f$8030a0e0$8091e2a0$@lanthaler@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac4wW16+I/rhcTE+S5C7xv/EVKXwXwAA1cQg
Content-Language: de
X-Y-GMX-Trusted: 0
Subject: [apps-discuss] FW: I-D Action: draft-lanthaler-profile-registry-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2013 11:36:41 -0000

I've just submitted my first Internet Draft trying to establish a registry
for profile URIs. Any feedback would be much appreciated.


Cheers,
Markus



------- Original Message ------

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title           : The IETF Profile URI Registry
	Author(s)       : Markus Lanthaler
	Filename        : draft-lanthaler-profile-registry-00.txt
	Pages           : 6
	Date            : 2013-04-03

Abstract:
   This document defines a registry for profile URIs and establishes an
   IETF URN Sub-namespace to be used in specifications standardizing
   profiles.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-lanthaler-profile-registry

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-lanthaler-profile-registry-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/



--
Markus Lanthaler
@markuslanthaler




From dave@cridland.net  Wed Apr  3 06:30:39 2013
Return-Path: <dave@cridland.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C65521F8C03 for <apps-discuss@ietfa.amsl.com>; Wed,  3 Apr 2013 06:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.477
X-Spam-Level: 
X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYgQ51doLCcG for <apps-discuss@ietfa.amsl.com>; Wed,  3 Apr 2013 06:30:38 -0700 (PDT)
Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id F0EE621F8B35 for <apps-discuss@ietf.org>; Wed,  3 Apr 2013 06:30:37 -0700 (PDT)
Received: by mail-oa0-f50.google.com with SMTP id n1so1468522oag.23 for <apps-discuss@ietf.org>; Wed, 03 Apr 2013 06:30:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=z5JCVkgLIZkUALZTOWNMfTCLuGy9ZhEQltpYmT22BIU=; b=ir1CaAMrFkail99oPbEr/t5QD8b14kCUIfc/DnIEr1mZ7q50rZOEp1uqVbLcPxmmn8 /Soi4RWVjSCk3fRbG6Athzp/9nNMjZ1ia9W2a+jTFyALj5yG4JLYBoc3Ss6ExGkf/5fJ ThS+7olKDNEfQBHLZMOrRb5Xel5oE55A/KjVM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=z5JCVkgLIZkUALZTOWNMfTCLuGy9ZhEQltpYmT22BIU=; b=DFHmnKvk+7zKP0ELsJxkKlE5HCW9Mn+7HYzLJGkvbvQcCyapvo7Eoz9idZbJTaKeu8 ruZDMUdKNihmZaLnwxuLWAWYk5ItRUUz5KXReP+s4ibuIp9DOn9RWr7ipTjggh53+vow w1PlqgXZCoUfVyEEXjeKQna6s4jlEzJdpN1/m5M8bcMpXHUcqqntlSNvs/Gkuo/hLdZo 9zxUYtzecAMMz3JVSEf37wMPn8xeLyRmAreBM78SFsraxqsIIlDpQvWFqEHynw177jyI xfQoG0ei6RJG4EEcp99WeJzt879rUwXj16sfMQhh5sGK+nBSaoZw53VWZ7rz/tuBzuUt zTZw==
MIME-Version: 1.0
X-Received: by 10.60.17.132 with SMTP id o4mr1134412oed.12.1364995837348; Wed, 03 Apr 2013 06:30:37 -0700 (PDT)
Received: by 10.60.22.105 with HTTP; Wed, 3 Apr 2013 06:30:37 -0700 (PDT)
In-Reply-To: <515c144c.22e7420a.31eb.3b74SMTPIN_ADDED_BROKEN@mx.google.com>
References: <515c144c.22e7420a.31eb.3b74SMTPIN_ADDED_BROKEN@mx.google.com>
Date: Wed, 3 Apr 2013 14:30:37 +0100
Message-ID: <CAKHUCzz-vbeZ4B5hFpYfR3RbDq4oYJs5pBS-E66gHxWnTe0VqA@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
Content-Type: multipart/alternative; boundary=089e01294d0c01625804d974dc74
X-Gm-Message-State: ALoCoQlzWorpMa5fL0EPEWzFL6cQ1kx5+vQjgRD52yyO5uqsVFz9v72CKe/TEbTLjfdywWLSQs0o
Cc: Rest List <rest-discuss@yahoogroups.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] FW: I-D Action: draft-lanthaler-profile-registry-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2013 13:30:39 -0000

--089e01294d0c01625804d974dc74
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Seems reasonable, though I had to read it twice to appreciate that
non-URNish URIs may also be registered.

It might be reasonable to underline this point by having the example
registration (not the registration of the example, which is different,
though currently the same text) in =A73 register an
http://example.com/profiles/example instead of the
urn:ietf:params:profile:example.

Obviously the =A75.2 registration should stay the same.

--089e01294d0c01625804d974dc74
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Seems reasonable, though I had to read it twice to appreci=
ate that non-URNish URIs may also be registered.<div><br></div><div style>I=
t might be reasonable to underline this point by having the example registr=
ation (not the registration of the example, which is different, though curr=
ently the same text) in =A73 register an <a href=3D"http://example.com/prof=
iles/example">http://example.com/profiles/example</a> instead of the urn:ie=
tf:params:profile:example.</div>
<div style><br></div><div style>Obviously the =A75.2 registration should st=
ay the same.</div><br></div>

--089e01294d0c01625804d974dc74--

From dave@cridland.net  Wed Apr  3 06:32:42 2013
Return-Path: <dave@cridland.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F069021F8D28 for <apps-discuss@ietfa.amsl.com>; Wed,  3 Apr 2013 06:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.726
X-Spam-Level: 
X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=0.250,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9RIWozdSW4b for <apps-discuss@ietfa.amsl.com>; Wed,  3 Apr 2013 06:32:40 -0700 (PDT)
Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 997F821F8B35 for <apps-discuss@ietf.org>; Wed,  3 Apr 2013 06:32:40 -0700 (PDT)
Received: by mail-oa0-f53.google.com with SMTP id m17so1490687oag.26 for <apps-discuss@ietf.org>; Wed, 03 Apr 2013 06:32:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Rl4tY0eAKiV4H3LLhaI8dmPgRWOB+hx20y7uwRqlU2Y=; b=YrbaYk4uc2bTwSPeyMNcHThgoWwDQ/GSAniwp6XR8BEhaaNC9ZsvmhXAKHQ7aTMjPn F10IGWN4ELWh4jfDe2WjWEH7oVZAmn9utj/H5+g350ss4iQ3w2X+GIOfTdn5LRxKOebJ dF4ohbcprl+VapMfFR0Tc9GvzzMu2S3TSUDq8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Rl4tY0eAKiV4H3LLhaI8dmPgRWOB+hx20y7uwRqlU2Y=; b=cYapTJr7H1Umw/PSKkhVOp5gpSwbO5OCPsoYQNw0FF7SnHrRwVNSIQyaiDSYyOK3NK QdPcfom6AamgCFWEpTFZSnYADnIe8bKovWZNSaCbXSCbOTKnKaSBCsDJMi1x/T43xyHQ npIbGizPdKw8XB9gu5biIZYG1uIVI5LVFPm2etPbkdFzEe86xwYEFbTXkUXCfNKp4VSp o+Fw+bn6pNcf9eV3CD7xmQFUw9wS/GCrRBOwXYiGWz0mNRdGPv0CbDgBWSZ4UCellcOk d2XIG3aFp4Di+6Vjg564TGRNFY7cZ10RMtZFeZS0VezttvIkDZKbLEcGfEKrfCons6Ai qlBg==
MIME-Version: 1.0
X-Received: by 10.182.34.165 with SMTP id a5mr1044941obj.70.1364995960194; Wed, 03 Apr 2013 06:32:40 -0700 (PDT)
Received: by 10.60.22.105 with HTTP; Wed, 3 Apr 2013 06:32:40 -0700 (PDT)
In-Reply-To: <CAL0qLwbOrM2k=cfKx+0BW4K+YZJ-ByAms7dFw2EySB0xM_4W_A@mail.gmail.com>
References: <6.2.5.6.2.20130331154836.0a822628@elandnews.com> <20130331232855.87940.qmail@joyce.lan> <CAL0qLwbOrM2k=cfKx+0BW4K+YZJ-ByAms7dFw2EySB0xM_4W_A@mail.gmail.com>
Date: Wed, 3 Apr 2013 14:32:40 +0100
Message-ID: <CAKHUCzwyGX8MWU1C1mUkujCZ4+Uh8+s4TH9ynyuo_3T=ooc1zQ@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2229853dff304d974e366
X-Gm-Message-State: ALoCoQkofDVIZDN8Q+T2FDXiHqQuvK9dQOSyQWKP7xkSwRgjyk6x2Sb+E50UAbyfMTXGBHjMH03B
Cc: John Levine <johnl@taugh.com>, SM <sm+ietf@elandsys.com>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] RFC5451bis processing
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2013 13:32:42 -0000

--001a11c2229853dff304d974e366
Content-Type: text/plain; charset=ISO-8859-1

I actively support putting it through appsawg given it's standards-track
and appears to be aimed at moving along it. The broader community of
appsawg should be of benefit.

Dave.

--001a11c2229853dff304d974e366
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">I actively support putting it through appsawg given it&#39;s standards-track and appears to be aimed at moving along it. The broader community of appsawg should be of benefit.<div><br></div><div style>Dave.</div>
</div>

--001a11c2229853dff304d974e366--

From markus.lanthaler@gmx.net  Wed Apr  3 10:26:39 2013
Return-Path: <markus.lanthaler@gmx.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB8B21F8D63 for <apps-discuss@ietfa.amsl.com>; Wed,  3 Apr 2013 10:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level: 
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhubL7rFkgRv for <apps-discuss@ietfa.amsl.com>; Wed,  3 Apr 2013 10:26:39 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 250A621F8D2E for <apps-discuss@ietf.org>; Wed,  3 Apr 2013 10:26:38 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MdYA6-1Ty60g0JTA-00PMEZ for <apps-discuss@ietf.org>; Wed, 03 Apr 2013 19:26:38 +0200
Received: (qmail invoked by alias); 03 Apr 2013 17:26:37 -0000
Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp002) with SMTP; 03 Apr 2013 19:26:37 +0200
X-Authenticated: #419883
X-Provags-ID: V01U2FsdGVkX18SGBwBUAgSfIFsjgTUHzJgOjFAPjmzfReNqhJ3WF sTsig6rgJWjCbx
From: "Markus Lanthaler" <markus.lanthaler@gmx.net>
To: "'Dave Cridland'" <dave@cridland.net>
References: <515c144c.22e7420a.31eb.3b74SMTPIN_ADDED_BROKEN@mx.google.com> <CAKHUCzz-vbeZ4B5hFpYfR3RbDq4oYJs5pBS-E66gHxWnTe0VqA@mail.gmail.com>
In-Reply-To: <CAKHUCzz-vbeZ4B5hFpYfR3RbDq4oYJs5pBS-E66gHxWnTe0VqA@mail.gmail.com>
Date: Wed, 3 Apr 2013 19:26:13 +0200
Message-ID: <018001ce3090$63e32ee0$2ba98ca0$@lanthaler@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac4wb25Hf3FARrKUTiCa61h70FfZqwAIJLhQ
Content-Language: de
X-Y-GMX-Trusted: 0
Cc: 'Rest List' <rest-discuss@yahoogroups.com>, apps-discuss@ietf.org
Subject: Re: [apps-discuss] FW: I-D Action: draft-lanthaler-profile-registry-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2013 17:26:39 -0000

On Wednesday, April 03, 2013 3:31 PM, Dave Cridland wrote:

> Seems reasonable, though I had to read it twice to
> appreciate that non-URNish URIs may also be registered.
>
> It might be reasonable to underline this point by having
> the example registration (not the registration of the
> example, which is different, though currently the same text)
> in =A73 register an http://example.com/profiles/example
> instead of the urn:ietf:params:profile:example.
>
> Obviously the =A75.2 registration should stay the same.

Thanks a lot for the feedback Dave. I=92ll try to make this clearer in =
the
next version.

Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler






From sm@elandsys.com  Wed Apr  3 11:12:00 2013
Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E1C21F8C6F for <apps-discuss@ietfa.amsl.com>; Wed,  3 Apr 2013 11:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dirvFkITJsrq for <apps-discuss@ietfa.amsl.com>; Wed,  3 Apr 2013 11:12:00 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE55521F8C5D for <apps-discuss@ietf.org>; Wed,  3 Apr 2013 11:11:59 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.226.234.207]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r33IBbtg010576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Apr 2013 11:11:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365012711; bh=cYlHS9DAR/IxzRKUw0NgY2DxNBJt19Q5JeQ4XcGLebM=; h=Date:To:From:Subject:Cc; b=yrDdkR+20DJCJLF9m+Nsr20VsPMPGp/b1kwljlrsILwaEieXE2DYAjD6Y8C3zE88T obX4tLqqOjvfU2Ip03rOkmEdICt7KHXquFKXcObXLspjnN6EexbZkoiFfk4Wfkh5P2 DhuJddQbqi9l+6dtyMET302HJD7JLzFEy/4miu0I=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1365012711; i=@elandsys.com; bh=cYlHS9DAR/IxzRKUw0NgY2DxNBJt19Q5JeQ4XcGLebM=; h=Date:To:From:Subject:Cc; b=OGCWsJRQRdrk5tzY9pAj22fLbyUsHx8+cDMxZxJpDq7wGVjbIBf7OLcfXj2O8eA7E lenC8EJSTcXdcE7ZmwOalHZRNU4vhNOsjsUgLMovARYrqfxU3J8NwLz9r56AiHGQBw 0VUPjg8xtU57ZxlgczmsSbbUvTqOTOY5DEMlgzR4=
Message-Id: <6.2.5.6.2.20130403105837.0ace96d0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 03 Apr 2013 11:09:01 -0700
To: apps-discuss@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [apps-discuss] WG adoption of draft-kucherawy-rfc5451bis-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2013 18:12:00 -0000

Hello,

draft-kucherawy-rfc5451bis-04 was previously discussed on the 
apps-discuss@ietf.org mailing list.  APPSAWG will be adopting 
draft-kucherawy-rfc5451bis-04 as a working group draft.  I am 
shepherding the draft as part of a non-WG chair shepherding 
experiment.  This is being done under the supervision of the Apps ADs.

Regards,
S. Moonesamy (as document shepherd)


From superuser@gmail.com  Wed Apr  3 11:58:52 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B187221F8A6D for <apps-discuss@ietfa.amsl.com>; Wed,  3 Apr 2013 11:58:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZwbrXQq1Yta for <apps-discuss@ietfa.amsl.com>; Wed,  3 Apr 2013 11:58:52 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B532121F8A3F for <apps-discuss@ietf.org>; Wed,  3 Apr 2013 11:58:51 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id u12so1442086wey.19 for <apps-discuss@ietf.org>; Wed, 03 Apr 2013 11:58:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=N2du5pCa2ZtmX351hit5PNg9QV3j3YKaGSZfIb3KXE4=; b=lMYwJ/19vCtsNPhpKyogzodQDbWgtis8CBFNe4jprO0/6v3lvsB05P+XOp+CARBUfT Uzsg8qhw4HF9TDB/M4CGp2mX66NTf9gvjoQfVkx5ZHlXCzm9NSKC7fFyFDKHgy/M+Urm cq/IsHkniI9bepcA/GpYyBYEQIdklDnkDLXSnHeVIMwwFTGVwqtIVmXDSmioZUHeUdq1 yQwIVxaaML/Ca0+w5r0czQCBJe4et2GwdBBiej62aGeHbe2GqHjNWbUAOgKAT3L9Wx7e EzZOYFvsEsp/Qy1BDSH+6aOww1g8/ZEKY5fRGrIep9cEyM2gCiR8Cuy80zLvUYraClMd h4Sw==
MIME-Version: 1.0
X-Received: by 10.180.74.67 with SMTP id r3mr24371941wiv.14.1365015530688; Wed, 03 Apr 2013 11:58:50 -0700 (PDT)
Received: by 10.180.36.176 with HTTP; Wed, 3 Apr 2013 11:58:50 -0700 (PDT)
In-Reply-To: <CAKHUCzw5K3BHaWOk4GivJ-9tLvjo9v8exo=A0i8z3GeWdoQ8GQ@mail.gmail.com>
References: <CAL0qLwbgjnt8Msofok3ExKBmChtQPfMEFgrrZBimEzU5CYgSjA@mail.gmail.com> <CAKHUCzxfBtLTt3p3moGgEQx+p5kr=-e2Mn58xaqNvWFGiW=Lpw@mail.gmail.com> <CAL0qLwY=VLkUZ7KMenj_ORQDwLOSdFS=x+q0a3N2KcxaT9q=Gw@mail.gmail.com> <CAKHUCzw5K3BHaWOk4GivJ-9tLvjo9v8exo=A0i8z3GeWdoQ8GQ@mail.gmail.com>
Date: Wed, 3 Apr 2013 11:58:50 -0700
Message-ID: <CAL0qLwa1Bf6rNbxabjhhBPVUTs2zJPyO+5p--sDagDXbDzfraQ@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Dave Cridland <dave@cridland.net>
Content-Type: multipart/alternative; boundary=f46d0438914dd1d76d04d9797195
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-kucherawy-rfc5451bis
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2013 18:58:52 -0000

--f46d0438914dd1d76d04d9797195
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Submitting draft-ietf-appsawg-rfc5451bis now, with changes in response to
your feedback as follows:

On Wed, Apr 3, 2013 at 3:18 AM, Dave Cridland <dave@cridland.net> wrote:

> However, you have in -04's ABNF (with much elided):
>
>      authres-header =3D "Authentication-Results:" [CFWS] authserv-id
>               [ [CFWS] "/" [CFWS] version ]
>               ( [CFWS] ";" [CFWS] "none" / 1*resinfo ) [CFWS] CRLF
>             ; the special case of "none" is used to indicate that no
>             ; message authentication is performed
>
>      version =3D 1*DIGIT [CFWS]
>              ; indicates which version of this specification is in use;
>              ; this specification is version "1", and the absence of a
>              ; version implies this version of the specification
>
>
>      method =3D Keyword [ [CFWS] "/" [CFWS] version ]
>             ; a method indicates which method's result is
>             ; represented by "result", and is one of the methods
>             ; explicitly defined as valid in this document
>             ; or is an extension method as defined below
>
> The conflation of the two different versions into one is (I find)
> confusing, though =A72.4 goes a long way to correcting that - perhaps far
> enough, but I remain uneasy.
>
> I think your choices are:
> [...]
>
> b) Introduce two different productions, one for "authres-version" and one
> for "method-version", such that:
> [...]
>

> Using (b) gives you the option of using those terms in =A72.4 (and elsewh=
ere
> as needed) to clarify which version you mean you mean, too.
>
> Obviously I'd rather you didn't do (d), but I'll accept it if you do. :-)
>

(b) will appear in the first Working Group version, which I'm about to
post.  Thanks for the suggestion.

-MSK

--f46d0438914dd1d76d04d9797195
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Submitting draft-ietf-appsawg-rfc5451bis now, with changes=
 in response to your feedback as follows:<br><div><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote">On Wed, Apr 3, 2013 at 3:18 AM, Dave Cridl=
and <span dir=3D"ltr">&lt;<a href=3D"mailto:dave@cridland.net" target=3D"_b=
lank">dave@cridland.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">However, you have in -04&#3=
9;s ABNF (with much elided):<br>
<br>=A0 =A0 =A0authres-header =3D &quot;Authentication-Results:&quot; [CFWS=
] authserv-id<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 [ [CFWS] &quot;/&quot; [CFWS] =
version ]<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0 ( [CFWS] &quot;;&quot; [CFWS] &quo=
t;none&quot; / 1*resinfo ) [CFWS] CRLF<br>

=A0 =A0 =A0 =A0 =A0 =A0 ; the special case of &quot;none&quot; is used to i=
ndicate that no<br>=A0 =A0 =A0 =A0 =A0 =A0 ; message authentication is perf=
ormed<br><br>=A0 =A0 =A0version =3D 1*DIGIT [CFWS]<br>=A0 =A0 =A0 =A0 =A0 =
=A0 =A0; indicates which version of this specification is in use;<br>

=A0 =A0 =A0 =A0 =A0 =A0 =A0; this specification is version &quot;1&quot;, a=
nd the absence of a<br>=A0 =A0 =A0 =A0 =A0 =A0 =A0; version implies this ve=
rsion of the specification<div class=3D"im"><br><br>=A0 =A0 =A0method =3D K=
eyword [ [CFWS] &quot;/&quot; [CFWS] version ]<br>
</div>
=A0 =A0 =A0 =A0 =A0 =A0 ; a method indicates which method&#39;s result is<b=
r>=A0 =A0 =A0 =A0 =A0 =A0 ; represented by &quot;result&quot;, and is one o=
f the methods<br>=A0 =A0 =A0 =A0 =A0 =A0 ; explicitly defined as valid in t=
his document<br>=A0 =A0 =A0 =A0 =A0 =A0 ; or is an extension method as defi=
ned below<br>

<br>The conflation of the two different versions into one is (I find) confu=
sing, though =A72.4 goes a long way to correcting that - perhaps far enough=
, but I remain uneasy.<br><br>I think your choices are:<br>[...]<br><br>
b) Introduce two different productions, one for &quot;authres-version&quot;=
 and one for &quot;method-version&quot;, such that:<br>[...]<br></div></blo=
ckquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br>Using (b) gives you the option of using those terms in=
 =A72.4 (and elsewhere as needed) to clarify which version you mean you mea=
n, too.<br><br>Obviously I&#39;d rather you didn&#39;t do (d), but I&#39;ll=
 accept it if you do. :-)<span class=3D"HOEnZb"><font color=3D"#888888"><br=
>
</font></span></div></blockquote><div><br></div><div>(b) will appear in the=
 first Working Group version, which I&#39;m about to post.=A0 Thanks for th=
e suggestion.<br><br></div><div>-MS<font color=3D"#888888">K</font> </div><=
/div>
</div></div></div>

--f46d0438914dd1d76d04d9797195--

From internet-drafts@ietf.org  Wed Apr  3 14:07:37 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F24321F8F29; Wed,  3 Apr 2013 14:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level: 
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53CDqhr2TZsX; Wed,  3 Apr 2013 14:07:36 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BFA21F8F1F; Wed,  3 Apr 2013 14:07:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.43
Message-ID: <20130403210736.31731.42961.idtracker@ietfa.amsl.com>
Date: Wed, 03 Apr 2013 14:07:36 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2013 21:07:37 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Applications Area Working Group Working G=
roup of the IETF.

	Title           : Message Header Field for Indicating Message Authenticati=
on Status
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rfc5451bis-00.txt
	Pages           : 42
	Date            : 2013-04-03

Abstract:
   This document specifies a header field for use with electronic mail
   messages to indicate the results of message authentication efforts.
   Any receiver-side software, such as mail filters or Mail User Agents
   (MUAs), can use this header field to relay that information in a
   convenient and meaningful way to users, or make sorting and filtering
   decisions.

   This document is a candidate for Internet Standard status.  [RFC
   Editor: Please delete this notation, as I imagine it will be
   indicated some other way.]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From superuser@gmail.com  Wed Apr  3 14:09:36 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8683521F8F4A; Wed,  3 Apr 2013 14:09:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFtfFSaCboTU; Wed,  3 Apr 2013 14:09:35 -0700 (PDT)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE6621F8F56; Wed,  3 Apr 2013 14:09:34 -0700 (PDT)
Received: by mail-we0-f177.google.com with SMTP id o45so1523880wer.22 for <multiple recipients>; Wed, 03 Apr 2013 14:09:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pMKSZiJB0U/v1axMxsRvH2MDHuOQksCV2uP0FMxZNa8=; b=I7vWqLkEANXzLjIsbirRzy7hLETeUBllhsX0Yz0xoR1vtaQaGOjMz1/TO8tWBLDcW1 8g/x4fewlZ0a/ODmpnf1FcdXjgFiuz2jc9srHaO3pSTc7HX9l6ql7G/axzXaQ5SwfBbl mA/0cPu0wC1Rmf6QQhyjrcgWvGzymtXwP6OhIS0NCr86QbxYVOM24Eojy/WLcwtDa4zJ fxeKF748khS3zHrWHiQhQx3cmkMd4kyjsbo25pweRhRhXgdJ6k2vN9n4AtbQ7JodV+qx fEOMQG+ITqxYo7RrwkfFd2Erdt9fga6v106iGkZjs6UtBKpwIOnqCFU735VFzafEs+UE JrtQ==
MIME-Version: 1.0
X-Received: by 10.194.93.68 with SMTP id cs4mr5302751wjb.17.1365023374280; Wed, 03 Apr 2013 14:09:34 -0700 (PDT)
Received: by 10.180.36.176 with HTTP; Wed, 3 Apr 2013 14:09:34 -0700 (PDT)
In-Reply-To: <20130403210736.31731.42961.idtracker@ietfa.amsl.com>
References: <20130403210736.31731.42961.idtracker@ietfa.amsl.com>
Date: Wed, 3 Apr 2013 14:09:34 -0700
Message-ID: <CAL0qLwbRi=Q2R-YssRrBbDuWCHyT6jUUaHvAcg-gfM0mfpxe_A@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: internet-drafts@ietf.org
Content-Type: multipart/alternative; boundary=047d7b5d8cff55915804d97b4586
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, i-d-announce@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2013 21:09:36 -0000

--047d7b5d8cff55915804d97b4586
Content-Type: text/plain; charset=ISO-8859-1

This version takes into account Dave Cridland's last suggestion, and a
review SM submitted some time ago that I had forgotten to address.

-MSK


On Wed, Apr 3, 2013 at 2:07 PM, <internet-drafts@ietf.org> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Applications Area Working Group Working
> Group of the IETF.
>
>         Title           : Message Header Field for Indicating Message
> Authentication Status
>         Author(s)       : Murray S. Kucherawy
>         Filename        : draft-ietf-appsawg-rfc5451bis-00.txt
>         Pages           : 42
>         Date            : 2013-04-03
>
> Abstract:
>    This document specifies a header field for use with electronic mail
>    messages to indicate the results of message authentication efforts.
>    Any receiver-side software, such as mail filters or Mail User Agents
>    (MUAs), can use this header field to relay that information in a
>    convenient and meaningful way to users, or make sorting and filtering
>    decisions.
>
>    This document is a candidate for Internet Standard status.  [RFC
>    Editor: Please delete this notation, as I imagine it will be
>    indicated some other way.]
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-00
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--047d7b5d8cff55915804d97b4586
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>This version takes into account Dave Cridland&#39;s l=
ast suggestion, and a review SM submitted some time ago that I had forgotte=
n to address.<br><br></div>-MSK<br></div><div class=3D"gmail_extra"><br><br=
>
<div class=3D"gmail_quote">On Wed, Apr 3, 2013 at 2:07 PM,  <span dir=3D"lt=
r">&lt;<a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">intern=
et-drafts@ietf.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.<br>
=A0This draft is a work item of the Applications Area Working Group Working=
 Group of the IETF.<br>
<br>
=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Message Header Field for Indica=
ting Message Authentication Status<br>
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Murray S. Kucherawy<br>
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-rfc5451bis-00.=
txt<br>
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 42<br>
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-03<br>
<br>
Abstract:<br>
=A0 =A0This document specifies a header field for use with electronic mail<=
br>
=A0 =A0messages to indicate the results of message authentication efforts.<=
br>
=A0 =A0Any receiver-side software, such as mail filters or Mail User Agents=
<br>
=A0 =A0(MUAs), can use this header field to relay that information in a<br>
=A0 =A0convenient and meaningful way to users, or make sorting and filterin=
g<br>
=A0 =A0decisions.<br>
<br>
=A0 =A0This document is a candidate for Internet Standard status. =A0[RFC<b=
r>
=A0 =A0Editor: Please delete this notation, as I imagine it will be<br>
=A0 =A0indicated some other way.]<br>
<br>
<br>
The IETF datatracker status page for this draft is:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis" =
target=3D"_blank">https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc54=
51bis</a><br>
<br>
There&#39;s also a htmlized version available at:<br>
<a href=3D"http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-00" tar=
get=3D"_blank">http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-00<=
/a><br>
<br>
<br>
Internet-Drafts are also available by anonymous FTP at:<br>
<a href=3D"ftp://ftp.ietf.org/internet-drafts/" target=3D"_blank">ftp://ftp=
.ietf.org/internet-drafts/</a><br>
<br>
_______________________________________________<br>
apps-discuss mailing list<br>
<a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
</blockquote></div><br></div>

--047d7b5d8cff55915804d97b4586--

From superuser@gmail.com  Wed Apr  3 14:21:48 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB8221F8FDD for <apps-discuss@ietfa.amsl.com>; Wed,  3 Apr 2013 14:21:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MnybvC1M+ld for <apps-discuss@ietfa.amsl.com>; Wed,  3 Apr 2013 14:21:48 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id C07EC21F8FDF for <apps-discuss@ietf.org>; Wed,  3 Apr 2013 14:21:47 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id c10so1984668wiw.7 for <apps-discuss@ietf.org>; Wed, 03 Apr 2013 14:21:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=CtctWt5SsPMC5Hg2ACxUPmqokMaeWA4fs6PxtrL2f2Y=; b=mtPPono+tWOvR1cVsRniR4SAnGx2kwMqC6aTUeesy+Re7NB0tzUa08mSN7X7CB5osW Nk4U6ZKMm9jLMwGaBwDernPF824fjfiJI/4VhUVQT6YLJmYiRzpg1oII43fC3ofshiNS xlkZqPUJmIaZD+BBrGP5VNLo0/TYvX8gJe11eKHO5Ikvww6m3m7hNdO5pJNiGyzBIBhI 4cc8ikdfUlQUXQv611LrZt1E9UIkpx6GMlelMylC0g06SBVHD2GPEzrgZLc+RnIcHCy8 AVa0SVYriMQ8H/MyZwkcE49ZEiO9SHbvp716yA3lZ04N8DeTSJieytmR5WGqS2i4TYy/ dKuA==
MIME-Version: 1.0
X-Received: by 10.180.92.229 with SMTP id cp5mr24922150wib.20.1365024106771; Wed, 03 Apr 2013 14:21:46 -0700 (PDT)
Received: by 10.180.36.176 with HTTP; Wed, 3 Apr 2013 14:21:46 -0700 (PDT)
In-Reply-To: <6.2.5.6.2.20130403105837.0ace96d0@elandnews.com>
References: <6.2.5.6.2.20130403105837.0ace96d0@elandnews.com>
Date: Wed, 3 Apr 2013 14:21:46 -0700
Message-ID: <CAL0qLwYG162YX7arZPu-XfvK=q_O_zX2O5LSNYria3ByGMt+6A@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: S Moonesamy <sm+ietf@elandsys.com>
Content-Type: multipart/alternative; boundary=f46d043c094efe7c7f04d97b709f
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] WG adoption of draft-kucherawy-rfc5451bis-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2013 21:21:48 -0000

--f46d043c094efe7c7f04d97b709f
Content-Type: text/plain; charset=ISO-8859-1

Also, I will have no co-chair hat on in terms of processing of this
document since I'm the author.  Any chair-level action will be done by
Salvatore or, in a pinch, Barry.

-MSK


On Wed, Apr 3, 2013 at 11:09 AM, S Moonesamy <sm+ietf@elandsys.com> wrote:

> Hello,
>
> draft-kucherawy-rfc5451bis-04 was previously discussed on the
> apps-discuss@ietf.org mailing list.  APPSAWG will be adopting
> draft-kucherawy-rfc5451bis-04 as a working group draft.  I am shepherding
> the draft as part of a non-WG chair shepherding experiment.  This is being
> done under the supervision of the Apps ADs.
>
> Regards,
> S. Moonesamy (as document shepherd)
>
>

--f46d043c094efe7c7f04d97b709f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Also, I will have no co-chair hat on in terms of proc=
essing of this document since I&#39;m the author.=A0 Any chair-level action=
 will be done by Salvatore or, in a pinch, Barry.<br><br></div>-MSK<br></di=
v>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Apr 3=
, 2013 at 11:09 AM, S Moonesamy <span dir=3D"ltr">&lt;<a href=3D"mailto:sm+=
ietf@elandsys.com" target=3D"_blank">sm+ietf@elandsys.com</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hello,<br>
<br>
draft-kucherawy-rfc5451bis-04 was previously discussed on the <a href=3D"ma=
ilto:apps-discuss@ietf.org" target=3D"_blank">apps-discuss@ietf.org</a> mai=
ling list. =A0APPSAWG will be adopting draft-kucherawy-rfc5451bis-04 as a w=
orking group draft. =A0I am shepherding the draft as part of a non-WG chair=
 shepherding experiment. =A0This is being done under the supervision of the=
 Apps ADs.<br>

<br>
Regards,<br>
S. Moonesamy (as document shepherd)<br>
<br>
</blockquote></div><br></div>

--f46d043c094efe7c7f04d97b709f--

From alexey.melnikov@isode.com  Thu Apr  4 05:45:05 2013
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EE521F8444; Thu,  4 Apr 2013 05:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.447
X-Spam-Level: 
X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksTiiSjXNtxD; Thu,  4 Apr 2013 05:45:05 -0700 (PDT)
Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id BFBCE21F842C; Thu,  4 Apr 2013 05:45:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1365079503; d=isode.com; s=selector; i=@isode.com; bh=z/ctoknOlJE8lS+pUhS+n4RonClOaWiFkl5OkKWph8o=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=KBi0JKXJV6yk+SahrMHvTNWMa6qLheD9WxowWwhBr24LdSm5GkVWUAYp4r5pLwuKY3+UZJ nA7GDQ5b8dMkVk3pllTBZGReCkLHDYriP3SeC8+griZAGxfa5L6xxjqPFeyGlQNeaoeRM5 tPpel7d3CVT32B+FEDOILmNWOar4+no=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250])  by waldorf.isode.com (submission channel) via TCP with ESMTPA  id <UV11zQAF4kGl@waldorf.isode.com>; Thu, 4 Apr 2013 13:45:03 +0100
Message-ID: <515D75FE.9070008@isode.com>
Date: Thu, 04 Apr 2013 13:45:50 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: IETF Apps Discuss <apps-discuss@ietf.org>, draft-ietf-core-coap.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "HE, XUAN -HCHBJ" <xhe@hitachi.cn>, The IESG <iesg@ietf.org>, core@ietf.org
Subject: [apps-discuss] AppsDir review of draft-ietf-core-coap-14
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2013 12:45:05 -0000

I have been selected as the Applications Area Directorate (appsdir) 
reviewer for this draft.  (For background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments 
you may receive.  Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-ietf-core-coap-14
Title: Constrained Application Protocol (CoAP)
Reviewer: Xuan He and Alexey Melnikov
Review Date: April 4, 2013
IETF Last Call Date: 27 March 2013
IESG Telechat Date: not known

Summary: This draft is nearly ready for publication as an Standards 
Track RFC.

Major Issues: none.

Minor:

In Section 3, version number field: have you thought about backward 
compatibility rules for future versions (if any) and version negotiation 
rules?

In Section 4.6: is a SHOULD requirement on IP MTU actually valid in this 
document? IMHO, you can't redefine what relevant RFCs say about that.

In 5.10.8, last para: wouldn't it be more correct to say that 
preconditions must be tested after all other verification is performed? 
If not, what is the intent of the MAY?

In 6.4: why is URI's default encoding is UTF-8 and not ASCII? URIs can't 
contain 8bit data. Or did you mean IRIs? (Hopefully you haven't!)

In 6.4: 8/9 - it would be correct to say octet instead of "character" 
when discussing %-decoding. Unicode characters can be represented as 
multiple octets in UTF-8, each octet would be %-encoded separately.


Nits:

In 5.4.6: Strange alignment of figure 10. Should it be center aligned?

In 7.1: the section title is "Service Discovery", but the section is 
talking about "server discovery". These are used as synonyms, but this 
might be confusing to non native English speakers.

In 12.2 Page82: There is a table below Table 6 and without any number.


From cabo@tzi.org  Thu Apr  4 06:58:00 2013
Return-Path: <cabo@tzi.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561C421F8DDD; Thu,  4 Apr 2013 06:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level: 
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwy3hFJabD3f; Thu,  4 Apr 2013 06:57:59 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5973321F8BBC; Thu,  4 Apr 2013 06:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r34DvmO9020317; Thu, 4 Apr 2013 15:57:49 +0200 (CEST)
Received: from [192.168.217.105] (p54893641.dip.t-dialin.net [84.137.54.65]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id F3C54303D; Thu,  4 Apr 2013 15:57:47 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <515D75FE.9070008@isode.com>
Date: Thu, 4 Apr 2013 15:57:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C2FE55F-A4FF-4340-AEBF-C626B42BAA67@tzi.org>
References: <515D75FE.9070008@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: Apple Mail (2.1503)
Cc: "HE, XUAN -HCHBJ" <xhe@hitachi.cn>, core@ietf.org, draft-ietf-core-coap.all@tools.ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [apps-discuss] AppsDir review of draft-ietf-core-coap-14
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2013 13:58:00 -0000

Hi Alexey,

thank you for this review.

> In Section 3, version number field: have you thought about backward =
compatibility rules for future versions (if any) and version negotiation =
rules?

I don't think we discussed this in the WG.
I remember some hallway discussions the gist of which is approximately:
We don't know yet why we would have a version transition, so it is hard =
to plan for it.
Whatever we define now is likely to be wrong when we actually know what =
we need.
Anything that is radical enough that we can't express it in an option is =
likely to change the message layout enough that it's not even clear what =
kind of error response to send back. =20
Sending back something for anything also has its perils.

So the version number is mainly in there as an insurance against unknown =
unknowns.
One other purpose is to allow some multiplexing on the UDP port, =
including to avoid STUN codepoints.


> In Section 4.6: is a SHOULD requirement on IP MTU actually valid in =
this document? IMHO, you can't redefine what relevant RFCs say about =
that.

There is no SHOULD on the MTU, but a SHOULD on what CoAP implementations =
should assume as an MTU.
Most of our users think in terms of IPv6, so 1280 is a good assumption.
For IPv4, 1280 is also a good base assumption.  There is an extensive =
implementation note on that, which qualifies this further.

The upshot really is that you want to limit the payload size to 1KiB =
and, if you use all that, be reasonable about the option size; but for =
constrained applications, these numbers are already high.

> In 5.10.8, last para: wouldn't it be more correct to say that =
preconditions must be tested after all other verification is performed? =
If not, what is the intent of the MAY?

It gives the server some lenience.  It does allow checking for the =
preconditions first, and it does allow for checking them last.  (We =
always try to give the server some lenience to implement things in a way =
that is best for the specific constrained node.)  In other words, the =
client cannot rely on, say, a 4.05 indicating that the preconditions did =
match, or on a 4.12 indicating that the method would have been allowed, =
but the server is free to check things in either order.

> In 6.4: why is URI's default encoding is UTF-8 and not ASCII? URIs =
can't contain 8bit data. Or did you mean IRIs? (Hopefully you haven't!)

We certainly didn't mean IRIs.  Specifying UTF-8 and ASCII should be =
equivalent here.
(Either way is likely to confuse a different part of the audience.)

> In 6.4: 8/9 - it would be correct to say octet instead of "character" =
when discussing %-decoding. Unicode characters can be represented as =
multiple octets in UTF-8, each octet would be %-encoded separately.

We probably just wanted to avoid "octet" because the average age of the =
authors is low enough that we can say byte :-)  Indeed, each byte is =
percent-encoded separately, and decoding each percent-triple generates a =
single byte, the sequences of which are then decoded as UTF-8 =
characters.

We'll try to find better wording for these two items.

> Nits:
>=20
> In 5.4.6: Strange alignment of figure 10. Should it be center aligned?

I don't have a preference either way.  Centered now in SVN [1269].

> In 7.1: the section title is "Service Discovery", but the section is =
talking about "server discovery". These are used as synonyms, but this =
might be confusing to non native English speakers.

Well, the usual terminology here *is* confusing.  A CoAP server offers a =
service.
It's not that interesting to discover the server alone, you want to =
discover the service on that server. (Actually, the software entity that =
offers the service might offer it in the form of multiple endpoints at =
different port numbers, which are by definition different servers, even =
though we colloquially would rather call it a server with multiple =
endpoints.)

Let's see if we can untangle the wording a bit here.
But I think we want to stick with the heading "Service Discovery".

> In 12.2 Page82: There is a table below Table 6 and without any number.

Thanks, captioned "CoAP Option Number Registry Policy" now in SVN =
[1269].

Gr=FC=DFe, Carsten


From barryleiba.mailing.lists@gmail.com  Fri Apr  5 09:15:38 2013
Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3BD21F9828 for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 09:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.877
X-Spam-Level: 
X-Spam-Status: No, score=-102.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVRJ0QJaSbXL for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 09:15:37 -0700 (PDT)
Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id BBE8121F982B for <apps-discuss@ietf.org>; Fri,  5 Apr 2013 09:15:36 -0700 (PDT)
Received: by mail-ve0-f170.google.com with SMTP id 15so3814793vea.29 for <apps-discuss@ietf.org>; Fri, 05 Apr 2013 09:15:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JvpAdSeB3OUdIo0CeQwRAgcWMEEmCHMQupjxWBs16MQ=; b=Hb3wdKVyVvB9jiv0gWKEmauSM2RNSBvwBv387nmNyBPLTBuEIVZOELp1rDEhkjZADT BP8wiYvycCgm9Agz1ODM66GQzitQTJ/kllRusyIrJHUa22p8OvBuYc3E0umR62b1dmB9 ZzYUhccOypQQvyPF99KZGnUtpXsAx+DkQsI/KDPzzI1b1R6UtGDgkX7Q8EABQ2FsOr55 gsVoaUeNaR87BVDyArLEJN7edzfzSZd4QsfRJ5XjZ2KfOSJ9gU9urVOGluZ6caeVSkS7 ibTcLPcHyIEJLpbKRpDOX1DOIU1h7+qPfg+EqOMzBP1LF4SYKGhfbbvRQnNG4HaIJprK 32bQ==
MIME-Version: 1.0
X-Received: by 10.52.155.5 with SMTP id vs5mr7332282vdb.24.1365178536004; Fri, 05 Apr 2013 09:15:36 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Fri, 5 Apr 2013 09:15:35 -0700 (PDT)
In-Reply-To: <515B401B.3070809@cs.tcd.ie>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie> <515A1581.9030402@dcrocker.net> <515A2464.8090401@cs.tcd.ie> <515B2E1D.4050102@dcrocker.net> <515B401B.3070809@cs.tcd.ie>
Date: Fri, 5 Apr 2013 12:15:35 -0400
X-Google-Sender-Auth: 5boXPJUskt3r-pEu6i-sCtS0Kxw
Message-ID: <CAC4RtVASwR=7Qvz9iY5GMzOAkEHnS-TjoROEE1JQpzX_X-JLHA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Apr 2013 16:15:38 -0000

My sense is that this conversation's gotten too heated to shed much
light on things, so I want to try to pull it back into what the issues
are, and away from any sort of attack/defense mode.

I believe that Stephen's issue with the charter involves the
restrictions on what the working group would not be allowed to do with
the proposed DMARC spec.  So let me pick out a few quotes from the
proposed charter (
http://trac.tools.ietf.org/wg/appsawg/trac/wiki/DMARC ) and try to
address that, giving my own opinions on the points:

> DMARC already has achieved significant production deployment. Consequently,
> any changes to the specification that create software or operations incompatibilities
> with the installed base need to be considered carefully.

I think this states a requirement clearly, and it seems to me not to
be very controversial.  It doesn't forbid any types of changes to the
spec.  It does say that some sorts of changes "need to be considered
carefully."  Given that there's significant deployment at this point,
that seems wise.

> The strong preference is for the working group to preserve existing software
> and procedures.

Again, nothing forbidden, but it's clear that we have running code,
and requiring those deployments to roll out new core or new
operational parameters would be disruptive.  It's our *preference* not
to do that, so, again, we need to consider carefully.

> For changes likely to affect the installed base, the working group will seek
> review and advice, beyond working group participants, to include other
> developers and operators of DMARC-based mechanisms.

We have a lot of evidence that comes from development and refinement
of application-layer protocols that, while some implementors and
operators will be here participating, many will not: they have a ship
to run.  They understand that disruptive changes aren't likely, and
they're off doing what pays their bills.

This sentence is saying that if we start seriously considering a
disruptive change, we'll explicitly reach out to such operators, alert
them to what we're considering, and bring them in, asking for their
review and comment.  I think that's an acceptable approach.

> However discussion, debate and resolution of issues that target revision
> of the specification are out of scope for this working group.

This is the only sentence that I have difficulty with, for a couple of reasons:

1. The word "revision" is too broad and vague.  On the surface, it
could mean that *any* change to the specification is out of scope.
There's no point in asking the IETF to work on something for which
that's the case.

2. It puts *discussion* out of scope.  That would arguably include
discussion that could lead to the identification of a major fault or
serious omission in the spec -- a fault or omission that the vast
majority of participants might consider it critical to fix.  If we
can't discuss it, we can't determine whether it's something that rough
consensus is against, something that's a good idea that can be dealt
with later, or a critical problem that needs to be addressed now.

I understand that this is meant to prevent the working group from
becoming bogged down in repeated requests for changes that could and
should be taken up later.  But until we discuss them, we don't know
what category they fall into.  This is why we have chairs, and I would
prefer to trust the chairs to manage the discussion -- and to
appropriately manage people who are bringing issues up for discussion
just to be disruptive.

I strongly suggest changing that sentence so that it gives a more
workable characterization of what's out of scope.


Now, to Stephen:

Again, let's step back and perhaps repeat, but in clearer focus, what
your issue(s) are.  Can you quote specific text from the proposed
charter that you have an issue with, say specifically what your issue
is, and say what you'd like done about it (with specific proposed text
if you can)?

If we state that clearly, and afresh, maybe we'll have a better chance
of moving forward.

Barry

From dhc@dcrocker.net  Fri Apr  5 10:52:33 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E9921F9852 for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 10:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHrG-DYltKjg for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 10:52:32 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id AA66121F9782 for <apps-discuss@ietf.org>; Fri,  5 Apr 2013 10:52:32 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r35HqEe5018087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Apr 2013 10:52:14 -0700
Message-ID: <515F0F49.4090107@dcrocker.net>
Date: Fri, 05 Apr 2013 10:52:09 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie> <515A1581.9030402@dcrocker.net> <515A2464.8090401@cs.tcd.ie> <515B2E1D.4050102@dcrocker.net> <515B401B.3070809@cs.tcd.ie> <CAC4RtVASwR=7Qvz9iY5GMzOAkEHnS-TjoROEE1JQpzX_X-JLHA@mail.gmail.com>
In-Reply-To: <CAC4RtVASwR=7Qvz9iY5GMzOAkEHnS-TjoROEE1JQpzX_X-JLHA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 05 Apr 2013 10:52:19 -0700 (PDT)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Apr 2013 17:52:33 -0000

On 4/5/2013 9:15 AM, Barry Leiba wrote:
> I strongly suggest changing that sentence so that it gives a more
> workable characterization of what's out of scope.


please suggest specific text that you feel would better do the job here.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From barryleiba@gmail.com  Fri Apr  5 11:16:29 2013
Return-Path: <barryleiba@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EF221F98AD for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 11:16:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.022
X-Spam-Level: 
X-Spam-Status: No, score=-102.022 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NujGeP1xSeoW for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 11:16:29 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE6521F98A4 for <apps-discuss@ietf.org>; Fri,  5 Apr 2013 11:16:28 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id ek20so3753751lab.16 for <apps-discuss@ietf.org>; Fri, 05 Apr 2013 11:16:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lLKKGxIdh4szfFqfO3tAosPuITWD1mcqGFCdKLzylmA=; b=M/IZp7fg9+43wKC/bixDsPGgWotTLJrrNjtpeIkVgX4+o8vWWIkzpVgC0fLmpBoIpG nH9GmW3elGsNoUwdzvYt+TnYjCA5yaB0qBhsWe9+rh1+bu6K36MLIKF+Q94OFK/tzZm3 VD8GlPPzuGsuZ05gaMKwqe0Y7iytgNlLaaAeSkIGx6zAtlOIKnllBa9XrAJqrPDDH4u2 MMJHCGrrYhDjWgxmpOgmELvpaTBDQrLGJBC0lDTfhvWfaNZEuoveCkDJyAiLbGwWkomj xeqpYB30aV8vJSZfOV5QSVMhHEYIAXKx++qfZX5Yvl9QAjuIuFXI8tHNxV+FYoit2VXo +89g==
MIME-Version: 1.0
X-Received: by 10.112.6.234 with SMTP id e10mr6760965lba.46.1365185787855; Fri, 05 Apr 2013 11:16:27 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.112.76.98 with HTTP; Fri, 5 Apr 2013 11:16:27 -0700 (PDT)
In-Reply-To: <515F0F49.4090107@dcrocker.net>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie> <515A1581.9030402@dcrocker.net> <515A2464.8090401@cs.tcd.ie> <515B2E1D.4050102@dcrocker.net> <515B401B.3070809@cs.tcd.ie> <CAC4RtVASwR=7Qvz9iY5GMzOAkEHnS-TjoROEE1JQpzX_X-JLHA@mail.gmail.com> <515F0F49.4090107@dcrocker.net>
Date: Fri, 5 Apr 2013 14:16:27 -0400
X-Google-Sender-Auth: pp-CsLmSCIk1ID96I-ZBWdJB6Jk
Message-ID: <CALaySJ+O=cdDLtqB16Rf4HKvA+MO4Z36UTCVE=-3_jP=P2uuog@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Dave Crocker <dcrocker@bbiw.net>
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Apr 2013 18:16:29 -0000

>> I strongly suggest changing that sentence so that it gives a more
>> workable characterization of what's out of scope.
>
> please suggest specific text that you feel would better do the job here.

I gave the parameters and thought you'd prefer to do the text.  But
I'm happy to propose some:

OLD
The working group will capture feedback about the existing DMARC
specification, and provide it for any future revision effort. However
discussion, debate and resolution of issues that target revision of
the specification are out of scope for this working group.
END

My first preference would be to remove that paragraph entirely; I
think the rest of the charter lays out the guidelines sufficiently.

If you really want to keep it, I think this will address my concerns:

NEW
The working group will capture feedback about possible extensions to
the DMARC specification, and provide it for any future effort.  Such
extensions and accommodation of additional use cases are out of scope
for this working group.
END

Barry

From fgaliegue@gmail.com  Fri Apr  5 11:39:56 2013
Return-Path: <fgaliegue@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3752C21F97CF for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 11:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkX53c+qsC1C for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 11:39:55 -0700 (PDT)
Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1B63821F97C3 for <apps-discuss@ietf.org>; Fri,  5 Apr 2013 11:39:54 -0700 (PDT)
Received: by mail-ee0-f41.google.com with SMTP id c1so1545373eek.0 for <apps-discuss@ietf.org>; Fri, 05 Apr 2013 11:39:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=NGgHty2zkTTfQ6dLGcnD3hLhjEdgk36YsyILtKXmhQs=; b=f0+bdPQrgz8q4PJSHykBkfRX4QCp1bDW76W2U741Cjt9kve4H4VUcOEEtKaD/zCMwm 2feHRwNTqlY0yjSk9Rr9ukS7gTAdKy53+w8MD4IZA3djIEyrWXR3/SI15mswHOVcMpH0 ZhAGVA8NzRY8vAPTcJ0JJ2RudsC//vxyhek8S6BIkptBo0PvbpEVTWfyoHCIdh3IA5zl M6H7pWjPynEL2WNzRpKSDAiq4Nk/1CGzL6HDlaWsvt9AhD/9hOcLj+ws9Jm3vtXF+FiX uTFAyiboZ75jeP3fSIKil1X2ZUuKbILc5uIqDzAWEdndiJsXzEBTol66uY+4cdlpdU1e /U5w==
MIME-Version: 1.0
X-Received: by 10.14.183.198 with SMTP id q46mr22150768eem.1.1365187194210; Fri, 05 Apr 2013 11:39:54 -0700 (PDT)
Received: by 10.14.213.4 with HTTP; Fri, 5 Apr 2013 11:39:54 -0700 (PDT)
Date: Fri, 5 Apr 2013 20:39:54 +0200
Message-ID: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com>
From: Francis Galiegue <fgaliegue@gmail.com>
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=UTF-8
Subject: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Apr 2013 18:39:56 -0000

Hello,

Let us say that there is a variable called "list", whose value is an empty list:

list = []

Now let us have this template:

X{.list}

Should the expansion be "X" or "X."? And, more importantly, why?

--
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com

From dcrocker@bbiw.net  Fri Apr  5 12:02:52 2013
Return-Path: <dcrocker@bbiw.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C231E21F98A1 for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 12:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.098
X-Spam-Level: 
X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.501,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4wn8Bdj9qa3 for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 12:02:52 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id AC36D21F98A6 for <apps-discuss@ietf.org>; Fri,  5 Apr 2013 12:02:51 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r35J2eQQ021314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Apr 2013 12:02:41 -0700
Message-ID: <515F1FCA.6030809@bbiw.net>
Date: Fri, 05 Apr 2013 12:02:34 -0700
From: Dave Crocker <dcrocker@bbiw.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie> <515A1581.9030402@dcrocker.net> <515A2464.8090401@cs.tcd.ie> <515B2E1D.4050102@dcrocker.net> <515B401B.3070809@cs.tcd.ie> <CAC4RtVASwR=7Qvz9iY5GMzOAkEHnS-TjoROEE1JQpzX_X-JLHA@mail.gmail.com> <515F0F49.4090107@dcrocker.net> <CALaySJ+O=cdDLtqB16Rf4HKvA+MO4Z36UTCVE=-3_jP=P2uuog@mail.gmail.com>
In-Reply-To: <CALaySJ+O=cdDLtqB16Rf4HKvA+MO4Z36UTCVE=-3_jP=P2uuog@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 05 Apr 2013 12:02:41 -0700 (PDT)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Apr 2013 19:02:52 -0000

On 4/5/2013 11:16 AM, Barry Leiba wrote:
> NEW
> The working group will capture feedback about possible extensions to
> the DMARC specification, and provide it for any future effort.  Such
> extensions and accommodation of additional use cases are out of scope
> for this working group.
> END


Speaking as a voice of one:  wfm.  Thanks!

What do others think of it?

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From stephen.farrell@cs.tcd.ie  Fri Apr  5 16:28:50 2013
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BED221F9754 for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 16:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwHN2OFqc3Xf for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 16:28:49 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EED4221F9719 for <apps-discuss@ietf.org>; Fri,  5 Apr 2013 16:28:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6C96BBE58; Sat,  6 Apr 2013 00:28:26 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGYzLpkaOgby; Sat,  6 Apr 2013 00:28:22 +0100 (IST)
Received: from [10.87.48.5] (unknown [86.41.7.49]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ADF31BE56; Sat,  6 Apr 2013 00:28:22 +0100 (IST)
Message-ID: <515F5E16.9090704@cs.tcd.ie>
Date: Sat, 06 Apr 2013 00:28:22 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie> <515A1581.9030402@dcrocker.net> <515A2464.8090401@cs.tcd.ie> <515B2E1D.4050102@dcrocker.net> <515B401B.3070809@cs.tcd.ie> <CAC4RtVASwR=7Qvz9iY5GMzOAkEHnS-TjoROEE1JQpzX_X-JLHA@mail.gmail.com>
In-Reply-To: <CAC4RtVASwR=7Qvz9iY5GMzOAkEHnS-TjoROEE1JQpzX_X-JLHA@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Apr 2013 23:28:50 -0000

Hiya,

On 04/05/2013 05:15 PM, Barry Leiba wrote:
> My sense is that this conversation's gotten too heated to shed much
> light on things, so I want to try to pull it back into what the issues
> are, and away from any sort of attack/defense mode.
> 
> I believe that Stephen's issue with the charter involves the
> restrictions on what the working group would not be allowed to do with
> the proposed DMARC spec.  

Yep.

> So let me pick out a few quotes from the
> proposed charter (
> http://trac.tools.ietf.org/wg/appsawg/trac/wiki/DMARC ) and try to
> address that, giving my own opinions on the points:
> 
>> DMARC already has achieved significant production deployment. Consequently,
>> any changes to the specification that create software or operations incompatibilities
>> with the installed base need to be considered carefully.
> 
> I think this states a requirement clearly, and it seems to me not to
> be very controversial.  It doesn't forbid any types of changes to the
> spec.  It does say that some sorts of changes "need to be considered
> carefully."  Given that there's significant deployment at this point,
> that seems wise.

Considered carefully seem entirely reasonable. But I think following
the template from dkim/xmpp here would however better characterise
when changes would be ok. To repeat from PSA's mail the xmpp text
was:

   Although not encouraged, non-backwards-compatible changes to the
   basis specifications will be acceptable if the working group
   determines that the changes are required to meet the group's
   technical objectives and the group clearly documents the reasons
   for making them.

Incorporating the above might mean more wordsmiting than a simple
replacement but shouldn't be hard.

>> The strong preference is for the working group to preserve existing software
>> and procedures.
> 
> Again, nothing forbidden, but it's clear that we have running code,
> and requiring those deployments to roll out new core or new
> operational parameters would be disruptive.  It's our *preference* not
> to do that, so, again, we need to consider carefully.

I quibble with the above. There's no working group that exists to
have such a preference and the above text seems to me to indicate
a lack of distinction between the proponents of this draft charter
and an eventual WG which will inevitably involve people that are
not currently involved in dmarc. The text however should be easily
fixed, e.g. replacing the above with something like:

"Preserving existing software and procedures is preferable."

But I think the dkim/xmpp template does that already and better.

However, I could live with the current text if the other changes,
or equivalents, are made and nobody else has a problem with this
part.

>> For changes likely to affect the installed base, the working group will seek
>> review and advice, beyond working group participants, to include other
>> developers and operators of DMARC-based mechanisms.
> 
> We have a lot of evidence that comes from development and refinement
> of application-layer protocols that, while some implementors and
> operators will be here participating, many will not: they have a ship
> to run.  They understand that disruptive changes aren't likely, and
> they're off doing what pays their bills.
> 
> This sentence is saying that if we start seriously considering a
> disruptive change, we'll explicitly reach out to such operators, alert
> them to what we're considering, and bring them in, asking for their
> review and comment.  I think that's an acceptable approach.

I'm uncomfortable with the above text but fine with the sentiment.
The problem with the text is that it seems to allow a WG participant
to say "I've asked someone I know who deploys DMARC but is too busy
to be here and they say you're wrong." Having that as a winning
argument according to the charter seems to me to be problematic.
I'd suggest something like:

"For changes likely to affect the installed base, the working group
need to carefully consider the views of developers and operators of
DMARC-based mechanisms."

But yet again the dkim/xmpp template text seems better to me.

>> However discussion, debate and resolution of issues that target revision
>> of the specification are out of scope for this working group.
> 
> This is the only sentence that I have difficulty with, for a couple of reasons:
> 
> 1. The word "revision" is too broad and vague.  On the surface, it
> could mean that *any* change to the specification is out of scope.
> There's no point in asking the IETF to work on something for which
> that's the case.
> 
> 2. It puts *discussion* out of scope.  That would arguably include
> discussion that could lead to the identification of a major fault or
> serious omission in the spec -- a fault or omission that the vast
> majority of participants might consider it critical to fix.  If we
> can't discuss it, we can't determine whether it's something that rough
> consensus is against, something that's a good idea that can be dealt
> with later, or a critical problem that needs to be addressed now.
> 
> I understand that this is meant to prevent the working group from
> becoming bogged down in repeated requests for changes that could and
> should be taken up later.  But until we discuss them, we don't know
> what category they fall into.  This is why we have chairs, and I would
> prefer to trust the chairs to manage the discussion -- and to
> appropriately manage people who are bringing issues up for discussion
> just to be disruptive.
> 
> I strongly suggest changing that sentence so that it gives a more
> workable characterization of what's out of scope.

I agree with Barry's comments on this part. I think that sentence
would be better deleted with no replacement.

> Now, to Stephen:
> 
> Again, let's step back and perhaps repeat, but in clearer focus, what
> your issue(s) are.  Can you quote specific text from the proposed
> charter that you have an issue with, say specifically what your issue
> is, and say what you'd like done about it (with specific proposed text
> if you can)?
> 
> If we state that clearly, and afresh, maybe we'll have a better chance
> of moving forward.

I hope that that's clear from the above.

S.


> 
> Barry
> 

From dhc@dcrocker.net  Fri Apr  5 16:52:42 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A80721F9908 for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 16:52:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jupCdr795nhB for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 16:52:41 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 59A9B21F9907 for <apps-discuss@ietf.org>; Fri,  5 Apr 2013 16:52:41 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r35NqVn9029060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Apr 2013 16:52:31 -0700
Message-ID: <515F63BA.2090609@dcrocker.net>
Date: Fri, 05 Apr 2013 16:52:26 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie> <515A1581.9030402@dcrocker.net> <515A2464.8090401@cs.tcd.ie> <515B2E1D.4050102@dcrocker.net> <515B401B.3070809@cs.tcd.ie> <CAC4RtVASwR=7Qvz9iY5GMzOAkEHnS-TjoROEE1JQpzX_X-JLHA@mail.gmail.com> <515F5E16.9090704@cs.tcd.ie>
In-Reply-To: <515F5E16.9090704@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 05 Apr 2013 16:52:32 -0700 (PDT)
Cc: Barry Leiba <barryleiba@computer.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Apr 2013 23:52:42 -0000

Stephen,


On 4/5/2013 4:28 PM, Stephen Farrell wrote:
> There's no working group that exists to
> have such a preference

Currently, probably not.

I hope you aren't asserting that it hasn't been done before.


>  and the above text seems to me to indicate
> a lack of distinction between the proponents of this draft charter
> and an eventual WG which will inevitably involve people that are
> not currently involved in dmarc.

Huh?  When have charters ever made such a distinction?


d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From stephen.farrell@cs.tcd.ie  Fri Apr  5 17:06:01 2013
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6EC821F98DF for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 17:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pEZi5oNfv6U for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 17:06:01 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 286E621F98D8 for <apps-discuss@ietf.org>; Fri,  5 Apr 2013 17:06:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6F6F6BE5D; Sat,  6 Apr 2013 01:05:39 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbp-bZRnLh1w; Sat,  6 Apr 2013 01:05:38 +0100 (IST)
Received: from [10.87.48.5] (unknown [86.41.7.49]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7E92FBE5B; Sat,  6 Apr 2013 01:05:38 +0100 (IST)
Message-ID: <515F66D2.3030200@cs.tcd.ie>
Date: Sat, 06 Apr 2013 01:05:38 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: dcrocker@bbiw.net
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie> <515A1581.9030402@dcrocker.net> <515A2464.8090401@cs.tcd.ie> <515B2E1D.4050102@dcrocker.net> <515B401B.3070809@cs.tcd.ie> <CAC4RtVASwR=7Qvz9iY5GMzOAkEHnS-TjoROEE1JQpzX_X-JLHA@mail.gmail.com> <515F5E16.9090704@cs.tcd.ie> <515F63BA.2090609@dcrocker.net>
In-Reply-To: <515F63BA.2090609@dcrocker.net>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, Barry Leiba <barryleiba@computer.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Apr 2013 00:06:02 -0000

Dave,

On 04/06/2013 12:52 AM, Dave Crocker wrote:
> Stephen,
> 
> 
> On 4/5/2013 4:28 PM, Stephen Farrell wrote:
>> There's no working group that exists to
>> have such a preference
> 
> Currently, probably not.

Sigh. You deleted that I said both that this was a quibble
and that I could live with the current text if more
important things are fixed.

To be frank, I interpret that as purely argumentative
and not related to dmarc and hence not worth pursuing
further than this message.

S.

> 
> I hope you aren't asserting that it hasn't been done before.
> 
> 
>>  and the above text seems to me to indicate
>> a lack of distinction between the proponents of this draft charter
>> and an eventual WG which will inevitably involve people that are
>> not currently involved in dmarc.
> 
> Huh?  When have charters ever made such a distinction?


> 
> 
> d/

From dhc@dcrocker.net  Fri Apr  5 17:16:09 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7203421F9919 for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 17:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKI8SECXet1m for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 17:16:08 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CD8CB21F9915 for <apps-discuss@ietf.org>; Fri,  5 Apr 2013 17:16:08 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r360G4Kb029389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Apr 2013 17:16:05 -0700
Message-ID: <515F693F.4080406@dcrocker.net>
Date: Fri, 05 Apr 2013 17:15:59 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie> <515A1581.9030402@dcrocker.net> <515A2464.8090401@cs.tcd.ie> <515B2E1D.4050102@dcrocker.net> <515B401B.3070809@cs.tcd.ie> <CAC4RtVASwR=7Qvz9iY5GMzOAkEHnS-TjoROEE1JQpzX_X-JLHA@mail.gmail.com> <515F5E16.9090704@cs.tcd.ie> <515F63BA.2090609@dcrocker.net> <515F66D2.3030200@cs.tcd.ie>
In-Reply-To: <515F66D2.3030200@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 05 Apr 2013 17:16:05 -0700 (PDT)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Apr 2013 00:16:09 -0000

On 4/5/2013 5:05 PM, Stephen Farrell wrote:
> To be frank, I interpret that as purely argumentative

it wasn't intended that way.


>>>   and the above text seems to me to indicate
>>> a lack of distinction between the proponents of this draft charter
>>> and an eventual WG which will inevitably involve people that are
>>> not currently involved in dmarc.
>>
>> Huh?  When have charters ever made such a distinction?

and you neglected to respond to this, which also was meant as a serious 
question.

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From stephen.farrell@cs.tcd.ie  Fri Apr  5 18:02:33 2013
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D6C21F940B for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 18:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgSp0U89ncfK for <apps-discuss@ietfa.amsl.com>; Fri,  5 Apr 2013 18:02:33 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 86FAD21F9408 for <apps-discuss@ietf.org>; Fri,  5 Apr 2013 18:02:32 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 47DCABE5F; Sat,  6 Apr 2013 02:02:10 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rSr3gYZw4Zc; Sat,  6 Apr 2013 02:02:09 +0100 (IST)
Received: from [10.87.48.5] (unknown [86.41.7.49]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 65152BE5D; Sat,  6 Apr 2013 02:02:09 +0100 (IST)
Message-ID: <515F7411.5010402@cs.tcd.ie>
Date: Sat, 06 Apr 2013 02:02:09 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: dcrocker@bbiw.net
References: <CAL0qLwYc757fw_VhPMHDrgcCimNFak02brDRLAVTq+NR4w34pA@mail.gmail.com> <5159D7A4.4000701@cs.tcd.ie> <CAL0qLwa0JtksC7iE_noz_ZC1L-NQU1EyH1X=dcrkPL-4UWJ-yA@mail.gmail.com> <515A0895.2090209@cs.tcd.ie> <515A1581.9030402@dcrocker.net> <515A2464.8090401@cs.tcd.ie> <515B2E1D.4050102@dcrocker.net> <515B401B.3070809@cs.tcd.ie> <CAC4RtVASwR=7Qvz9iY5GMzOAkEHnS-TjoROEE1JQpzX_X-JLHA@mail.gmail.com> <515F5E16.9090704@cs.tcd.ie> <515F63BA.2090609@dcrocker.net> <515F66D2.3030200@cs.tcd.ie> <515F693F.4080406@dcrocker.net>
In-Reply-To: <515F693F.4080406@dcrocker.net>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Apr 2013 01:02:33 -0000

On 04/06/2013 01:15 AM, Dave Crocker wrote:
> 
> On 4/5/2013 5:05 PM, Stephen Farrell wrote:
>> To be frank, I interpret that as purely argumentative
> 
> it wasn't intended that way.

Well, ok, I guess.

>>>>   and the above text seems to me to indicate
>>>> a lack of distinction between the proponents of this draft charter
>>>> and an eventual WG which will inevitably involve people that are
>>>> not currently involved in dmarc.
>>>
>>> Huh?  When have charters ever made such a distinction?
> 
> and you neglected to respond to this, which also was meant as a serious
> question.

I don't know that charters proposed for new wgs have or have
not included such distinctions, and haven't gone looking. I'd
not be surprised if there were lots of things that have been
proposed as charter text that never made it into any real
charter.

And yet again, I said this point is a quibble. I said I
could live with the current text if the substantive issues
are fixed. I hope that that answers your serious question
about my quibble;-)

S.



From fgaliegue@gmail.com  Sun Apr  7 13:38:55 2013
Return-Path: <fgaliegue@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B84E21F84E7 for <apps-discuss@ietfa.amsl.com>; Sun,  7 Apr 2013 13:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYxzCkz3+v2D for <apps-discuss@ietfa.amsl.com>; Sun,  7 Apr 2013 13:38:54 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E80E21F84B7 for <apps-discuss@ietf.org>; Sun,  7 Apr 2013 13:38:54 -0700 (PDT)
Received: by mail-ee0-f44.google.com with SMTP id c41so1109388eek.31 for <apps-discuss@ietf.org>; Sun, 07 Apr 2013 13:38:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=XleC/SwXxjeJ2j4fed5W+EWOOExD+WlK7GQH2y5ec2k=; b=JZ2alOLwSezlpDd3ivHXNaMkN7iRW9IsIHvdYNKzXKdXQBKGPYRNUGdMlHgjdcIKw9 2e6zTqpBwwHjCXFJ6c+44hGOBN+ZYuIWttgZvsU7bBb97tbYfd1pRQ/Tz305nPYpJ1PU F7bzqzEu9aeYpiLiHZv4erDtfZp62mtRKo5r3XA2ri1Gh4FL/5QBeTpvohD2hDKMcZRj Bs5lAL9eHJc85mpMo9CLSqtqwyLSCk4aFa8NbnTByto+hmRKPnrbLM4eq0rxmKnKeCIK CLeO39V1cpuCX0VuBw92XrxL9cuCwZWssmUNPEAY+G+iV5S68Eh7XCcxwoXX+BzfjMEp lblA==
MIME-Version: 1.0
X-Received: by 10.14.3.136 with SMTP id 8mr16705066eeh.37.1365367133419; Sun, 07 Apr 2013 13:38:53 -0700 (PDT)
Received: by 10.14.213.4 with HTTP; Sun, 7 Apr 2013 13:38:53 -0700 (PDT)
In-Reply-To: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com>
Date: Sun, 7 Apr 2013 22:38:53 +0200
Message-ID: <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com>
From: Francis Galiegue <fgaliegue@gmail.com>
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=UTF-8
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Apr 2013 20:38:55 -0000

On Fri, Apr 5, 2013 at 8:39 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:
> Hello,
>
> Let us say that there is a variable called "list", whose value is an empty list:
>
> list = []
>
> Now let us have this template:
>
> X{.list}
>
> Should the expansion be "X" or "X."? And, more importantly, why?
>

Any insights? I have read the spec by and large (RFC 6570) and still
cannot figure it out...

--
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com

From dret@berkeley.edu  Sun Apr  7 22:41:13 2013
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6680621F91C9 for <apps-discuss@ietfa.amsl.com>; Sun,  7 Apr 2013 22:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOYleRZvhj0W for <apps-discuss@ietfa.amsl.com>; Sun,  7 Apr 2013 22:41:12 -0700 (PDT)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id B198521F91BC for <apps-discuss@ietf.org>; Sun,  7 Apr 2013 22:41:12 -0700 (PDT)
Received: from 99-38-249-227.lightspeed.sntcca.sbcglobal.net ([99.38.249.227] helo=[192.168.1.97]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1UP4pH-0003gu-Ad; Sun, 07 Apr 2013 22:41:12 -0700
Message-ID: <51625870.8000906@berkeley.edu>
Date: Sun, 07 Apr 2013 22:41:04 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com>
In-Reply-To: <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2013 05:41:13 -0000

hello francis.

On 2013-04-07 13:38 , Francis Galiegue wrote:
> On Fri, Apr 5, 2013 at 8:39 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:
>> Let us say that there is a variable called "list", whose value is an empty list:
>> list = []
>> Now let us have this template:
>> X{.list}
>> Should the expansion be "X" or "X."? And, more importantly, why?
> Any insights? I have read the spec by and large (RFC 6570) and still
> cannot figure it out...

https://github.com/dret/uritemplate-test/blob/master/spec-examples-by-section.json 
(line 234) says it's "X", but i am really interested in the "why" 
explanation as well. http://tools.ietf.org/html/rfc6570#section-3.2.5 
says that "for each defined variable in the variable-list, append '.' to 
the result string and then perform variable expansion", and i cannot 
find any text saying that an empty list is considered to be undefined. i 
have read the spec recently and never looked at this particular case, 
but without looking at the test cases i would have said it has to be 
expanded to "X." and not "X".

cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

From superuser@gmail.com  Sun Apr  7 23:55:28 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBA221F91A5 for <apps-discuss@ietfa.amsl.com>; Sun,  7 Apr 2013 23:55:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.765
X-Spam-Level: 
X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-1.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMgTMtOsMyrx for <apps-discuss@ietfa.amsl.com>; Sun,  7 Apr 2013 23:55:27 -0700 (PDT)
Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id 22CC921F91A2 for <apps-discuss@ietf.org>; Sun,  7 Apr 2013 23:55:27 -0700 (PDT)
Received: by mail-pd0-f175.google.com with SMTP id g10so2864296pdj.20 for <apps-discuss@ietf.org>; Sun, 07 Apr 2013 23:55:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ii17lSLB7dBwC3G8mA6qwr+Yak+9XOL5VRoqyWXhsdA=; b=Y5vnP2Fzqd+ws67ujd2CAJ6jRrLU0W52nuYNsGj7rqDQUS+tceVoBn9Q3n/e5mBpGG MYaqnBBbPjIXwkWjSbdQLGPTDpMmLoQ2HdhoB2v/oBQqgEtDtdXNGn5KNuAjaNokblMb Y4eyQcP2Xurl8ePYsGMEWF6CnLgAnkMBosB1upJek4gttRbwlgw4OGl9toJ/pLIq1W4z rH2rrfwcVc8SovrNR4UPkMekpcDs672jbHiiRGR44pjfde/S27uBn3iuASGNK4kanl/K L4bw2u1ix26RuaoxAYNorcNc6pT2houv/kJd06YRXfoVTyRFzPtOmCrQJxH++jKZM0BX zrvQ==
MIME-Version: 1.0
X-Received: by 10.66.149.165 with SMTP id ub5mr34386493pab.87.1365404126483; Sun, 07 Apr 2013 23:55:26 -0700 (PDT)
Received: by 10.66.234.40 with HTTP; Sun, 7 Apr 2013 23:55:26 -0700 (PDT)
In-Reply-To: <51625870.8000906@berkeley.edu>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu>
Date: Sun, 7 Apr 2013 23:55:26 -0700
Message-ID: <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Erik Wilde <dret@berkeley.edu>
Content-Type: multipart/alternative; boundary=047d7b6dbcb4ef1b4f04d9d3eb84
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2013 06:55:28 -0000

--047d7b6dbcb4ef1b4f04d9d3eb84
Content-Type: text/plain; charset=ISO-8859-1

I'm inclined to think it's "X." for the same reason "X{.empty}" is "X.",
which is to say that an empty list, like an empty string, isn't undefined,
but there is indeed nothing to expand.

Either way, there may be grounds for an erratum here.  The RFC does talk
about handling empty strings, but not empty lists.  The closest is Section
3.2.1 which talks about "expansion of a defined, non-empty value", meaning
defined, empty values aren't explicitly covered in the prose as far as I
can see.

-MSK


On Sun, Apr 7, 2013 at 10:41 PM, Erik Wilde <dret@berkeley.edu> wrote:

> hello francis.
>
>
> On 2013-04-07 13:38 , Francis Galiegue wrote:
>
>> On Fri, Apr 5, 2013 at 8:39 PM, Francis Galiegue <fgaliegue@gmail.com>
>> wrote:
>>
>>> Let us say that there is a variable called "list", whose value is an
>>> empty list:
>>> list = []
>>> Now let us have this template:
>>> X{.list}
>>> Should the expansion be "X" or "X."? And, more importantly, why?
>>>
>> Any insights? I have read the spec by and large (RFC 6570) and still
>> cannot figure it out...
>>
>
> https://github.com/dret/**uritemplate-test/blob/master/**
> spec-examples-by-section.json<https://github.com/dret/uritemplate-test/blob/master/spec-examples-by-section.json>(line 234) says it's "X", but i am really interested in the "why"
> explanation as well. http://tools.ietf.org/html/**rfc6570#section-3.2.5<http://tools.ietf.org/html/rfc6570#section-3.2.5>says that "for each defined variable in the variable-list, append '.' to
> the result string and then perform variable expansion", and i cannot find
> any text saying that an empty list is considered to be undefined. i have
> read the spec recently and never looked at this particular case, but
> without looking at the test cases i would have said it has to be expanded
> to "X." and not "X".
>
> cheers,
>
> dret.
>
> --
> erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
>            | UC Berkeley  -  School of Information (ISchool) |
>            | http://dret.net/netdret http://twitter.com/dret |
>
> ______________________________**_________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>

--047d7b6dbcb4ef1b4f04d9d3eb84
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I&#39;m inclined to think it&#39;s &quot;X.&quot; for=
 the same reason &quot;X{.empty}&quot; is &quot;X.&quot;, which is to say t=
hat an empty list, like an empty string, isn&#39;t undefined, but there is =
indeed nothing to expand.<br>
<br></div><div>Either way, there may be grounds for an erratum here.=A0 The=
 RFC does talk about handling empty strings, but not empty lists.=A0 The cl=
osest is Section 3.2.1 which talks about &quot;expansion of a defined, non-=
empty value&quot;, meaning defined, empty values aren&#39;t explicitly cove=
red in the prose as far as I can see.<br>
<br></div><div>-MSK<br></div></div><div class=3D"gmail_extra"><br><br><div =
class=3D"gmail_quote">On Sun, Apr 7, 2013 at 10:41 PM, Erik Wilde <span dir=
=3D"ltr">&lt;<a href=3D"mailto:dret@berkeley.edu" target=3D"_blank">dret@be=
rkeley.edu</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">hello francis.<div class=3D"im"><br>
<br>
On 2013-04-07 13:38 , Francis Galiegue wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"im">
On Fri, Apr 5, 2013 at 8:39 PM, Francis Galiegue &lt;<a href=3D"mailto:fgal=
iegue@gmail.com" target=3D"_blank">fgaliegue@gmail.com</a>&gt; wrote:<br>
</div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Let us say that there is a variable called &quot;list&quot;, whose value is=
 an empty list:<br>
list =3D []<br>
Now let us have this template:<br>
X{.list}<br>
Should the expansion be &quot;X&quot; or &quot;X.&quot;? And, more importan=
tly, why?<br>
</blockquote>
Any insights? I have read the spec by and large (RFC 6570) and still<br>
cannot figure it out...<br>
</div></blockquote>
<br>
<a href=3D"https://github.com/dret/uritemplate-test/blob/master/spec-exampl=
es-by-section.json" target=3D"_blank">https://github.com/dret/<u></u>uritem=
plate-test/blob/master/<u></u>spec-examples-by-section.json</a> (line 234) =
says it&#39;s &quot;X&quot;, but i am really interested in the &quot;why&qu=
ot; explanation as well. <a href=3D"http://tools.ietf.org/html/rfc6570#sect=
ion-3.2.5" target=3D"_blank">http://tools.ietf.org/html/<u></u>rfc6570#sect=
ion-3.2.5</a> says that &quot;for each defined variable in the variable-lis=
t, append &#39;.&#39; to the result string and then perform variable expans=
ion&quot;, and i cannot find any text saying that an empty list is consider=
ed to be undefined. i have read the spec recently and never looked at this =
particular case, but without looking at the test cases i would have said it=
 has to be expanded to &quot;X.&quot; and not &quot;X&quot;.<br>

<br>
cheers,<br>
<br>
dret.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- <br>
erik wilde | mailto:<a href=3D"mailto:dret@berkeley.edu" target=3D"_blank">=
dret@berkeley.edu</a> =A0- =A0tel:<a href=3D"tel:%2B1-510-2061079" value=3D=
"+15102061079" target=3D"_blank">+1-510-2061079</a> |<br>
=A0 =A0 =A0 =A0 =A0 =A0| UC Berkeley =A0- =A0School of Information (ISchool=
) |<br>
=A0 =A0 =A0 =A0 =A0 =A0| <a href=3D"http://dret.net/netdret" target=3D"_bla=
nk">http://dret.net/netdret</a> <a href=3D"http://twitter.com/dret" target=
=3D"_blank">http://twitter.com/dret</a> |</font></span><div class=3D"HOEnZb=
"><div class=3D"h5">
<br>
______________________________<u></u>_________________<br>
apps-discuss mailing list<br>
<a href=3D"mailto:apps-discuss@ietf.org" target=3D"_blank">apps-discuss@iet=
f.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/<u></u>listinfo/apps-discuss</a><br>
</div></div></blockquote></div><br></div>

--047d7b6dbcb4ef1b4f04d9d3eb84--

From jan.algermissen@nordsc.com  Mon Apr  8 04:33:49 2013
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3844621F8916 for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 04:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_ABOUTYOU=0.5, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J4Vpgt0JTYhz for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 04:33:47 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2DA21F8168 for <apps-discuss@ietf.org>; Mon,  8 Apr 2013 04:33:47 -0700 (PDT)
Received: from [10.90.133.67] ([87.253.171.208]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MJVXP-1UR4wO3rsx-002qLe; Mon, 08 Apr 2013 13:33:44 +0200
From: Jan Algermissen <jan.algermissen@nordsc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 8 Apr 2013 13:11:42 +0200
Message-Id: <E30D6548-732B-4996-8363-A699A487B65B@nordsc.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
X-Provags-ID: V02:K0:MDQ8X2pYAaUr6frB282eATj5SdaBhREDwvGmZppVc/0 SXd+ijHAOsi6PaYFOd5aEmhVQgvEe5eHqJ0nLmTdPv9ZpQUpW5 saCs4LvWs+4qlPcnxpyiXA92gddc0szxL5mqy6i7C3+N9dahyT RUxIhSb/Q+sX15Wt8/N0toi6cWas4UT819E/FFBNpdF/fnYZVM VPNvXyDRx1Xx0kWusFd0XnN9H/W0AvOwyW6UBMo8eK4dN0X2Qz EaYTJqdkNZMWVHkYSzzHsHV/y1rttheOWUwIW3o7p83ogDurNR 3oHnv21/BfEb+Bh/O57iGW3tFazNnrtXVo3Pu/i5BfuwzODwGB KQSZrgbSez2VXwSMdq17trjXQpELE6PHTAwkANVAuV+8odWALW RsKhihjyRVaeg==
Cc: Mark Nottingham <mnot@mnot.net>
Subject: [apps-discuss] JSON-Home widget example
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2013 11:33:49 -0000

Hi Mark,

curious about your opinion on the following.

The example you provide in the draft[1] troubles me a bit since a =
real-life, similar case made me look at it from a different angle.

=20
    "http://example.org/rel/widgets": {
         "href": "/widgets/"
       },
       "http://example.org/rel/widget": {
         "href-template": "/widgets/{widget_id}",
         "href-vars": {
           "widget_id": "http://example.org/param/widget"
         },
         ...
       }

What we have here is sort of a standard pattern for making available 'a =
bag of things' via HTTP.

For example, a bunch of orders can be straight forward exposed as

  /orders

and knowing that

  "http://example.org/rel/orders" : { "href" : "/orders" }

pretty much implies something like /orders/{orderId}, including the idea =
that adding an order is likely done with a POST to /orders and that =
editing an order is (maybe) achieved with PUT/PATCH/DELETE.

What troubles me is that JSON Home currently makes it necessary to =
define two link relations to cover a standard (in a sense) use case that =
could be covered with just one link relation. Or, in other words, the =
two link rels somehow semantically overlap, yet demand two =
'specifications'. Think in terms of violating DRY.

Can't think of an improvement that does not introduce the 'pattern' into =
the spec, but I am nevertheless much interested in your view.

Maybe an optional {widget_id} and one rel with appropriate definition =
does the trick already, but hard to seperate the hints. Dunno...

Jan

[1] http://tools.ietf.org/html/draft-nottingham-json-home-02


From fgaliegue@gmail.com  Mon Apr  8 05:54:38 2013
Return-Path: <fgaliegue@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B9621F92B2 for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 05:54:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+W3nz5NEW3Z for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 05:54:37 -0700 (PDT)
Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id 09E8B21F9058 for <apps-discuss@ietf.org>; Mon,  8 Apr 2013 05:54:36 -0700 (PDT)
Received: by mail-ee0-f53.google.com with SMTP id c13so2260571eek.12 for <apps-discuss@ietf.org>; Mon, 08 Apr 2013 05:54:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aO/fquWfDicCJwkYjeSW5mwY/D1kFQjCsX7vcrugLNM=; b=nv6MQ3DWwmv7bn47KJkhNiUNUGSbM5siSQBDLrjMmWFCUx1e6kVf+HZcg3I914vIAm N+kEJBUxWtUBKiVi/7wJD0ZGERY6822glpzKGcnMRpRXOhagIGr0D2izyMUl9A9so3SI cGRXoHh5jdlWIMgtbX2Fwjgr0DedD7ATHEk2B2CLUW6C47pv7C+vQB4B8rKgJb8QfUbc cndca7wfMAdfJhdMjd26XJ+x3xwSFHY2qzXSzjibWpm815+Sb1QTLagDsdljHkVZyatV 4eC6ahXGHSj9JduEzO1jZMm9beIZw9iUjKevwTD1Lmp+Li6FuDe7CqdeFOyzEf+Yx4RP uIyg==
MIME-Version: 1.0
X-Received: by 10.14.179.5 with SMTP id g5mr48757094eem.41.1365425674414; Mon, 08 Apr 2013 05:54:34 -0700 (PDT)
Received: by 10.14.213.4 with HTTP; Mon, 8 Apr 2013 05:54:34 -0700 (PDT)
In-Reply-To: <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com>
Date: Mon, 8 Apr 2013 14:54:34 +0200
Message-ID: <CALcybBCeyJce+m7GB8ak_Wmwfk6+Z=bcaDKs489H0v4vLOgahw@mail.gmail.com>
From: Francis Galiegue <fgaliegue@gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2013 12:54:38 -0000

On Mon, Apr 8, 2013 at 8:55 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
> I'm inclined to think it's "X." for the same reason "X{.empty}" is "X.",
> which is to say that an empty list, like an empty string, isn't undefined,
> but there is indeed nothing to expand.
>
> Either way, there may be grounds for an erratum here.  The RFC does talk
> about handling empty strings, but not empty lists.  The closest is Section
> 3.2.1 which talks about "expansion of a defined, non-empty value", meaning
> defined, empty values aren't explicitly covered in the prose as far as I can
> see.
>

Similarly, it doesn't talk about extending empty maps.

--
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com

From jasnell@gmail.com  Mon Apr  8 06:37:38 2013
Return-Path: <jasnell@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F8621F93FB for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 06:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdWxPOyQc8CU for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 06:37:37 -0700 (PDT)
Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id A85B121F93F3 for <apps-discuss@ietf.org>; Mon,  8 Apr 2013 06:37:37 -0700 (PDT)
Received: by mail-ob0-f181.google.com with SMTP id wo10so1355483obc.26 for <apps-discuss@ietf.org>; Mon, 08 Apr 2013 06:37:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=X87y+w+qBevTRb5/71HIICQItu37i4S/xxIbC4BF06Y=; b=gP/D2zHdKFgUI1e+uglfITUalPBNB7xXc2ipPN41YDP+wEAMP8MkmFXxUD5ukfYVM0 ECB6quBN9NxBtUlZ1fXVvH/iKoeAww0S1tNOhC3TWyDCgy/sTLy9yUkn/5qfAtZ1Qb8X yHYICtCIhJrnxgsfCS2WhkGX/38GHsvAMYin0C0cJzNM2T5/as+FuNpx69Nx2OE6edbZ lTrsD0EIQPN29KKBdpUX0/n0nuX7Jla4mPrNr4opi6BvQ4N9IjLQIDNZnDeJgwQkULRe BlrFOo9eK8MIxev46dJAXezowMMUSOURog3jNCCSanbdcohvQPFvx0LUZGdz/B0b6tEq DK5Q==
MIME-Version: 1.0
X-Received: by 10.60.76.234 with SMTP id n10mr12307666oew.63.1365428257196; Mon, 08 Apr 2013 06:37:37 -0700 (PDT)
Received: by 10.60.132.102 with HTTP; Mon, 8 Apr 2013 06:37:37 -0700 (PDT)
Received: by 10.60.132.102 with HTTP; Mon, 8 Apr 2013 06:37:37 -0700 (PDT)
In-Reply-To: <CALcybBCeyJce+m7GB8ak_Wmwfk6+Z=bcaDKs489H0v4vLOgahw@mail.gmail.com>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com> <CALcybBCeyJce+m7GB8ak_Wmwfk6+Z=bcaDKs489H0v4vLOgahw@mail.gmail.com>
Date: Mon, 8 Apr 2013 06:37:37 -0700
Message-ID: <CABP7RbfLQ5wCTNEJ4ufEs76YoVBePP8JYLQkjgUHJQ-o3=pUeg@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
To: Francis Galiegue <fgaliegue@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b33d4ba3ce1b804d9d98a39
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2013 13:37:38 -0000

--047d7b33d4ba3ce1b804d9d98a39
Content-Type: text/plain; charset=UTF-8

Am I missing something subtle about the question? The examples in Section
3.2.5 show "X{.empty_keys}" where empty keys = [], expands to "X". Given
that the list is empty, there's nothing to expand it into.
 On Apr 8, 2013 5:54 AM, "Francis Galiegue" <fgaliegue@gmail.com> wrote:

> On Mon, Apr 8, 2013 at 8:55 AM, Murray S. Kucherawy <superuser@gmail.com>
> wrote:
> > I'm inclined to think it's "X." for the same reason "X{.empty}" is "X.",
> > which is to say that an empty list, like an empty string, isn't
> undefined,
> > but there is indeed nothing to expand.
> >
> > Either way, there may be grounds for an erratum here.  The RFC does talk
> > about handling empty strings, but not empty lists.  The closest is
> Section
> > 3.2.1 which talks about "expansion of a defined, non-empty value",
> meaning
> > defined, empty values aren't explicitly covered in the prose as far as I
> can
> > see.
> >
>
> Similarly, it doesn't talk about extending empty maps.
>
> --
> Francis Galiegue, fgaliegue@gmail.com
> JSON Schema in Java: http://json-schema-validator.herokuapp.com
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--047d7b33d4ba3ce1b804d9d98a39
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Am I missing something subtle about the question? The exampl=
es in Section 3.2.5 show &quot;X{.empty_keys}&quot; where empty keys =3D []=
, expands to &quot;X&quot;. Given that the list is empty, there&#39;s nothi=
ng to expand it into. <br>

</p>
<div class=3D"gmail_quote">On Apr 8, 2013 5:54 AM, &quot;Francis Galiegue&q=
uot; &lt;<a href=3D"mailto:fgaliegue@gmail.com">fgaliegue@gmail.com</a>&gt;=
 wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Apr 8, 2013 at 8:55 AM, Murray S. Kucherawy &lt;<a href=3D"mailto:s=
uperuser@gmail.com">superuser@gmail.com</a>&gt; wrote:<br>
&gt; I&#39;m inclined to think it&#39;s &quot;X.&quot; for the same reason =
&quot;X{.empty}&quot; is &quot;X.&quot;,<br>
&gt; which is to say that an empty list, like an empty string, isn&#39;t un=
defined,<br>
&gt; but there is indeed nothing to expand.<br>
&gt;<br>
&gt; Either way, there may be grounds for an erratum here. =C2=A0The RFC do=
es talk<br>
&gt; about handling empty strings, but not empty lists. =C2=A0The closest i=
s Section<br>
&gt; 3.2.1 which talks about &quot;expansion of a defined, non-empty value&=
quot;, meaning<br>
&gt; defined, empty values aren&#39;t explicitly covered in the prose as fa=
r as I can<br>
&gt; see.<br>
&gt;<br>
<br>
Similarly, it doesn&#39;t talk about extending empty maps.<br>
<br>
--<br>
Francis Galiegue, <a href=3D"mailto:fgaliegue@gmail.com">fgaliegue@gmail.co=
m</a><br>
JSON Schema in Java: <a href=3D"http://json-schema-validator.herokuapp.com"=
 target=3D"_blank">http://json-schema-validator.herokuapp.com</a><br>
_______________________________________________<br>
apps-discuss mailing list<br>
<a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
</blockquote></div>

--047d7b33d4ba3ce1b804d9d98a39--

From superuser@gmail.com  Mon Apr  8 06:53:54 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C9321F8D52 for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 06:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDsUx146RMUW for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 06:53:52 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E85DB21F8D2C for <apps-discuss@ietf.org>; Mon,  8 Apr 2013 06:53:50 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id z12so5846332wgg.35 for <apps-discuss@ietf.org>; Mon, 08 Apr 2013 06:53:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=yHsUmL+D+HNtYDIFJKhX6hhJGD+6F54p3powI5lIDrE=; b=vCSAOMJDsn+LbXF2zJ+Jg9UtuAl4ZJIWJKCS9vHlOQ4S/AOaP8UeYFJWnHjsPkSlNs LkLgH8l078VQnw06B4a9boktqcJYEJCrW467+DZsLavLlZ3q7DwyrTqsZwl0naodNVwM kHEXrUFNSHVdjX3ufpeZMAh/3SQg0h8i5hS3jW1hDQjXi5dZOvxtNqBV2ZqMXAE2jmTW mzIxr1Sf1biPgG+YfawLX8O8eXKPALA2olckgv5VtmbQ6DvmbN1NWqkjkfxtvB/nd5oV /Gs2Faz0wf+x5Wfo0jQRPMkUhZb3wm8gb9f1lfFyg06/TzX340YASExbEab3HZj/Wk1i 9+7A==
MIME-Version: 1.0
X-Received: by 10.194.109.35 with SMTP id hp3mr31792217wjb.15.1365429229947; Mon, 08 Apr 2013 06:53:49 -0700 (PDT)
Received: by 10.180.36.176 with HTTP; Mon, 8 Apr 2013 06:53:49 -0700 (PDT)
In-Reply-To: <CABP7RbfLQ5wCTNEJ4ufEs76YoVBePP8JYLQkjgUHJQ-o3=pUeg@mail.gmail.com>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com> <CALcybBCeyJce+m7GB8ak_Wmwfk6+Z=bcaDKs489H0v4vLOgahw@mail.gmail.com> <CABP7RbfLQ5wCTNEJ4ufEs76YoVBePP8JYLQkjgUHJQ-o3=pUeg@mail.gmail.com>
Date: Mon, 8 Apr 2013 06:53:49 -0700
Message-ID: <CAL0qLwYsVt63VAtg0yqG=KDO7e1DvmE-8ywXM8CBqrt8mxDZOA@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: James M Snell <jasnell@gmail.com>
Content-Type: multipart/alternative; boundary=089e010d857437974404d9d9c4be
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2013 13:53:55 -0000

--089e010d857437974404d9d9c4be
Content-Type: text/plain; charset=ISO-8859-1

empty_keys (defined in 3.2) is an empty associative array, not an empty
list.  So we have:

- an undefined value produces "X"
- a defined-but-empty string produces "X."
- a defined-but-empty associative array produces "X"

It's not clear to me that there's a pattern here yielding an obvious answer
for which of the two a defined-but-empty list should produce.


On Mon, Apr 8, 2013 at 6:37 AM, James M Snell <jasnell@gmail.com> wrote:

> Am I missing something subtle about the question? The examples in Section
> 3.2.5 show "X{.empty_keys}" where empty keys = [], expands to "X". Given
> that the list is empty, there's nothing to expand it into.
>  On Apr 8, 2013 5:54 AM, "Francis Galiegue" <fgaliegue@gmail.com> wrote:
>
>> On Mon, Apr 8, 2013 at 8:55 AM, Murray S. Kucherawy <superuser@gmail.com>
>> wrote:
>> > I'm inclined to think it's "X." for the same reason "X{.empty}" is "X.",
>> > which is to say that an empty list, like an empty string, isn't
>> undefined,
>> > but there is indeed nothing to expand.
>> >
>> > Either way, there may be grounds for an erratum here.  The RFC does talk
>> > about handling empty strings, but not empty lists.  The closest is
>> Section
>> > 3.2.1 which talks about "expansion of a defined, non-empty value",
>> meaning
>> > defined, empty values aren't explicitly covered in the prose as far as
>> I can
>> > see.
>> >
>>
>> Similarly, it doesn't talk about extending empty maps.
>>
>> --
>> Francis Galiegue, fgaliegue@gmail.com
>> JSON Schema in Java: http://json-schema-validator.herokuapp.com
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
>

--089e010d857437974404d9d9c4be
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div>empty_keys (defined in 3.2) is an empt=
y associative array, not an empty list.=A0 So we have:<br><br></div>- an un=
defined value produces &quot;X&quot;<br></div>- a defined-but-empty string =
produces &quot;X.&quot;<br>
</div>- a defined-but-empty associative array produces &quot;X&quot;<br><br=
></div>It&#39;s not clear to me that there&#39;s a pattern here yielding an=
 obvious answer for which of the two a defined-but-empty list should produc=
e.<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon,=
 Apr 8, 2013 at 6:37 AM, James M Snell <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:jasnell@gmail.com" target=3D"_blank">jasnell@gmail.com</a>&gt;</span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><p dir=3D"ltr">Am I missing something subtle=
 about the question? The examples in Section 3.2.5 show &quot;X{.empty_keys=
}&quot; where empty keys =3D [], expands to &quot;X&quot;. Given that the l=
ist is empty, there&#39;s nothing to expand it into. <br>


</p>
<div class=3D"gmail_quote"><div><div class=3D"h5">On Apr 8, 2013 5:54 AM, &=
quot;Francis Galiegue&quot; &lt;<a href=3D"mailto:fgaliegue@gmail.com" targ=
et=3D"_blank">fgaliegue@gmail.com</a>&gt; wrote:<br type=3D"attribution"></=
div></div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div class=3D"h5">
On Mon, Apr 8, 2013 at 8:55 AM, Murray S. Kucherawy &lt;<a href=3D"mailto:s=
uperuser@gmail.com" target=3D"_blank">superuser@gmail.com</a>&gt; wrote:<br=
>
&gt; I&#39;m inclined to think it&#39;s &quot;X.&quot; for the same reason =
&quot;X{.empty}&quot; is &quot;X.&quot;,<br>
&gt; which is to say that an empty list, like an empty string, isn&#39;t un=
defined,<br>
&gt; but there is indeed nothing to expand.<br>
&gt;<br>
&gt; Either way, there may be grounds for an erratum here. =A0The RFC does =
talk<br>
&gt; about handling empty strings, but not empty lists. =A0The closest is S=
ection<br>
&gt; 3.2.1 which talks about &quot;expansion of a defined, non-empty value&=
quot;, meaning<br>
&gt; defined, empty values aren&#39;t explicitly covered in the prose as fa=
r as I can<br>
&gt; see.<br>
&gt;<br>
<br>
Similarly, it doesn&#39;t talk about extending empty maps.<br>
<br>
--<br>
Francis Galiegue, <a href=3D"mailto:fgaliegue@gmail.com" target=3D"_blank">=
fgaliegue@gmail.com</a><br>
JSON Schema in Java: <a href=3D"http://json-schema-validator.herokuapp.com"=
 target=3D"_blank">http://json-schema-validator.herokuapp.com</a><br></div>=
</div><div class=3D"im">
_______________________________________________<br>
apps-discuss mailing list<br>
<a href=3D"mailto:apps-discuss@ietf.org" target=3D"_blank">apps-discuss@iet=
f.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
</div></blockquote></div>
</blockquote></div><br></div>

--089e010d857437974404d9d9c4be--

From markus.lanthaler@gmx.net  Mon Apr  8 07:02:40 2013
Return-Path: <markus.lanthaler@gmx.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DD121F973E for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 07:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[AWL=-0.250,  BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrTntOUOnAWS for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 07:02:40 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id E17AF21F94CC for <apps-discuss@ietf.org>; Mon,  8 Apr 2013 07:02:39 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MZRZ5-1UB60p0yp3-00LDZg for <apps-discuss@ietf.org>; Mon, 08 Apr 2013 16:02:38 +0200
Received: (qmail invoked by alias); 08 Apr 2013 14:02:38 -0000
Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp010) with SMTP; 08 Apr 2013 16:02:38 +0200
X-Authenticated: #419883
X-Provags-ID: V01U2FsdGVkX18sJpAkdVQsVmAvxXnIYahC6JipIBn7JjL3ME4aTQ 7tu4SYGtsZB/kD
From: "Markus Lanthaler" <markus.lanthaler@gmx.net>
To: "'Erik Wilde'" <dret@berkeley.edu>, <apps-discuss@ietf.org>
References: <20130331020006.30816.30540.idtracker@ietfa.amsl.com> <51579940.3040406@berkeley.edu>
In-Reply-To: <51579940.3040406@berkeley.edu>
Date: Mon, 8 Apr 2013 16:02:35 +0200
Message-ID: <010501ce3461$b995fe10$2cc1fa30$@lanthaler@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac4ts9cCaw3kOXiNSUyEjC7Jp3GQoQGqDmVQ
Content-Language: de
X-Y-GMX-Trusted: 0
Subject: Re: [apps-discuss] Fwd: New Version Notification for	draft-wilde-atom-profile-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2013 14:02:40 -0000

Hi Erik,

I've finally had a chance to read your draft. I have a minor question, why
do you require profile URIs to be percent-encoded? Is this really required?
Other than that, the I-D is very clear and looks good to me.


Here are a few typos I've found:

s/redundacies/redundancies/
s/mprofile/profile/

s/specified in of RFC XXXX (Section 3)/specified in section 3 of RFC XXXX/

There's also the following sentence in the draft which is probably a
leftover of one of your other I-Ds:

"This specification requests the registration of an XML-based media type for
the eXtensible Access Control Markup Language (XACML)."


Cheers,
Markus



--
Markus Lanthaler
@markuslanthaler





> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of Erik Wilde
> Sent: Sunday, March 31, 2013 4:03 AM
> To: apps-discuss@ietf.org application-layer protocols; Atom-Syntax
> Subject: [apps-discuss] Fwd: New Version Notification for draft-wilde-
> atom-profile-00.txt
> 
> A new version of I-D, draft-wilde-atom-profile-00.txt
> has been successfully submitted by Erik Wilde and posted to the
> IETF repository.
> 
> Filename:	 draft-wilde-atom-profile
> Revision:	 00
> Title:		 Profile Support for the Atom Syndication Format
> Creation date:	 2013-03-30
> Group:		 Individual Submission
> Number of pages: 7
> URL:
> http://www.ietf.org/internet-drafts/draft-wilde-atom-profile-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-wilde-atom-
> profile
> Htmlized:        http://tools.ietf.org/html/draft-wilde-atom-profile-00
> 
> 
> Abstract:
>     The Atom syndication format is a generic XML format for
> representing
>     collections.  Profiles are one way how Atom feeds can indicate that
>     they support specific extensions.  To make this support visible on
>     the media type level, this specification re-registers the Atom
> media
>     type, and adds a "profile" media type parameter.  This allows
>     profiles to become visible at the media type level, so that servers
>     as well as clients can indicate support for specific Atom profiles
> in
>     conversations, for example when communicating via HTTP.
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From jasnell@gmail.com  Mon Apr  8 07:51:07 2013
Return-Path: <jasnell@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BF421F9774 for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 07:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8u4e4KMflAzR for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 07:51:06 -0700 (PDT)
Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by ietfa.amsl.com (Postfix) with ESMTP id 05A6021F9758 for <apps-discuss@ietf.org>; Mon,  8 Apr 2013 07:51:05 -0700 (PDT)
Received: by mail-oa0-f43.google.com with SMTP id l10so6237660oag.2 for <apps-discuss@ietf.org>; Mon, 08 Apr 2013 07:51:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=3jM3Xh1cNkWdjxi7PsxrSpS7ZvG0v8olvLSaV7PILrw=; b=K7ZGJoPpEZizhmnbgZLESFzEUlTeAQxxHp5m+F2hIVnMs4rC1Ry2BIY9kqzzbHFu62 rwOO72c/uXQ2WF5ipFW7WYX2dyC6N7kohgJEC9209K1+7B+zi+GtYoG67VoYTRIcZBng 7xL6ciwzzi76uuQ75BJssfxkh1ZbhJHH3MiD9KyRcrLsoKFR44olpyGaWP1PhOirQEo/ 74rzJGJ28je/28Erl4AURo9Mqs5F03Wag5VZavJAb3smP1gzbTACsTorLocuSSZFIfM2 Z1n7U9jjzKcsf8DdTq29Q3K3YPLj3XtpwaV5iXC0XuKnmmqDJ6K+/p9PlIRfeTPgm9dn mTVg==
X-Received: by 10.60.50.102 with SMTP id b6mr15523241oeo.46.1365432665633; Mon, 08 Apr 2013 07:51:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.132.102 with HTTP; Mon, 8 Apr 2013 07:50:45 -0700 (PDT)
In-Reply-To: <CAL0qLwYsVt63VAtg0yqG=KDO7e1DvmE-8ywXM8CBqrt8mxDZOA@mail.gmail.com>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com> <CALcybBCeyJce+m7GB8ak_Wmwfk6+Z=bcaDKs489H0v4vLOgahw@mail.gmail.com> <CABP7RbfLQ5wCTNEJ4ufEs76YoVBePP8JYLQkjgUHJQ-o3=pUeg@mail.gmail.com> <CAL0qLwYsVt63VAtg0yqG=KDO7e1DvmE-8ywXM8CBqrt8mxDZOA@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
Date: Mon, 8 Apr 2013 07:50:45 -0700
Message-ID: <CABP7RbfDOS4pdnx5Z4arwLw8demRfKrT4bE+Jb4uzvcdgzKRfw@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>, Joe Gregorio <joe@bitworking.org>
Content-Type: text/plain; charset=UTF-8
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2013 14:51:07 -0000

"empty_keys" is not defined explicitly as an empty associative array.
The only definition given for "empty_keys" in section 3.2 is
"empty_keys := []" which is semantically and structurally identical to
an empty list. So to amend your rules, we have:

- an undefined value produces "X"
- a defined-but-empty string produces "X."
- a defined-but-empty list/associative-array produces "X"

- James


On Mon, Apr 8, 2013 at 6:53 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
> empty_keys (defined in 3.2) is an empty associative array, not an empty
> list.  So we have:
>
> - an undefined value produces "X"
> - a defined-but-empty string produces "X."
> - a defined-but-empty associative array produces "X"
>
> It's not clear to me that there's a pattern here yielding an obvious answer
> for which of the two a defined-but-empty list should produce.
>
>
> On Mon, Apr 8, 2013 at 6:37 AM, James M Snell <jasnell@gmail.com> wrote:
>>
>> Am I missing something subtle about the question? The examples in Section
>> 3.2.5 show "X{.empty_keys}" where empty keys = [], expands to "X". Given
>> that the list is empty, there's nothing to expand it into.
>>
>> On Apr 8, 2013 5:54 AM, "Francis Galiegue" <fgaliegue@gmail.com> wrote:
>>>
>>> On Mon, Apr 8, 2013 at 8:55 AM, Murray S. Kucherawy <superuser@gmail.com>
>>> wrote:
>>> > I'm inclined to think it's "X." for the same reason "X{.empty}" is
>>> > "X.",
>>> > which is to say that an empty list, like an empty string, isn't
>>> > undefined,
>>> > but there is indeed nothing to expand.
>>> >
>>> > Either way, there may be grounds for an erratum here.  The RFC does
>>> > talk
>>> > about handling empty strings, but not empty lists.  The closest is
>>> > Section
>>> > 3.2.1 which talks about "expansion of a defined, non-empty value",
>>> > meaning
>>> > defined, empty values aren't explicitly covered in the prose as far as
>>> > I can
>>> > see.
>>> >
>>>
>>> Similarly, it doesn't talk about extending empty maps.
>>>
>>> --
>>> Francis Galiegue, fgaliegue@gmail.com
>>> JSON Schema in Java: http://json-schema-validator.herokuapp.com
>>> _______________________________________________
>>> apps-discuss mailing list
>>> apps-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

From dret@berkeley.edu  Mon Apr  8 08:55:23 2013
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297FD21F903B for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 08:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.67
X-Spam-Level: 
X-Spam-Status: No, score=-5.67 tagged_above=-999 required=5 tests=[AWL=-0.929,  BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWIJKQILqQSM for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 08:55:22 -0700 (PDT)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 74FF421F975F for <apps-discuss@ietf.org>; Mon,  8 Apr 2013 08:55:20 -0700 (PDT)
Received: from 99-38-249-227.lightspeed.sntcca.sbcglobal.net ([99.38.249.227] helo=[192.168.1.97]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1UPEPa-0005Kk-Ej; Mon, 08 Apr 2013 08:55:20 -0700
Message-ID: <5162E862.5060807@berkeley.edu>
Date: Mon, 08 Apr 2013 08:55:14 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Jan Algermissen <jan.algermissen@nordsc.com>
References: <E30D6548-732B-4996-8363-A699A487B65B@nordsc.com>
In-Reply-To: <E30D6548-732B-4996-8363-A699A487B65B@nordsc.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Mark Nottingham <mnot@mnot.net>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] JSON-Home widget example
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2013 15:55:23 -0000

hello jan.

On 2013-04-08 04:11 , Jan Algermissen wrote:
> For example, a bunch of orders can be straight forward exposed as
>    /orders
> and knowing that
>    "http://example.org/rel/orders" : { "href" : "/orders" }
> pretty much implies something like /orders/{orderId}, including the idea that adding an order is likely done with a POST to /orders and that editing an order is (maybe) achieved with PUT/PATCH/DELETE.
> What troubles me is that JSON Home currently makes it necessary to define two link relations to cover a standard (in a sense) use case that could be covered with just one link relation. Or, in other words, the two link rels somehow semantically overlap, yet demand two 'specifications'. Think in terms of violating DRY.

Home Documents really don't "make it necessary" to define the link 
relation for the collection. it's simply what the example is using, and 
of course you are free to do it differently. in the end, it is up to the 
service designer to decide which link relations they use/define, and 
which they want to expose in the home document.

our service currently uses "collection" links to link from instances in 
collections to the collection itself, so coming back to your example, 
the only have "widget" links (which are templated), but we don't (yet) 
have a "widgets" link. we're still debating how to best map this to the 
home document we're exposing, and you could make a point that maybe in a 
very rich semantic world, you might be able to say "widget collection", 
indicating that the link points to "a collection of widget things". but 
that, imho, is not really working very well for arbitrary link 
relations, so we are currently leaning towards introducing "widgets" as 
a link relation, because we want to provide such a link to a collection 
in the home document, and we want to be specific about what that 
collection contains.

to repeat myself, i don't think that home documents themselves have a 
lot to say or do here; they simply give you a format for how to expose 
typed links in one place, and what you're exposing there is entirely 
under your control, and your responsibility. hardcoding the "collection 
pattern" into home documents would immediately cause other patterns to 
become candidates as well, and i don't think home documents are the 
right place to start standardizing a couple of ways in which resources 
in HTTP services may be related.

thanks and cheers,

dret.

From dret@berkeley.edu  Mon Apr  8 09:03:23 2013
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3020021F97CA for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 09:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.134
X-Spam-Level: 
X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=0.465,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8V3HmK-xht4 for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 09:03:22 -0700 (PDT)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 814AF21F97C8 for <apps-discuss@ietf.org>; Mon,  8 Apr 2013 09:03:22 -0700 (PDT)
Received: from 99-38-249-227.lightspeed.sntcca.sbcglobal.net ([99.38.249.227] helo=[192.168.1.97]) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1UPEWF-0006Si-KS; Mon, 08 Apr 2013 09:02:19 -0700
Message-ID: <5162EA00.9060006@berkeley.edu>
Date: Mon, 08 Apr 2013 09:02:08 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: James M Snell <jasnell@gmail.com>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com> <CALcybBCeyJce+m7GB8ak_Wmwfk6+Z=bcaDKs489H0v4vLOgahw@mail.gmail.com> <CABP7RbfLQ5wCTNEJ4ufEs76YoVBePP8JYLQkjgUHJQ-o3=pUeg@mail.gmail.com> <CAL0qLwYsVt63VAtg0yqG=KDO7e1DvmE-8ywXM8CBqrt8mxDZOA@mail.gmail.com> <CABP7RbfDOS4pdnx5Z4arwLw8demRfKrT4bE+Jb4uzvcdgzKRfw@mail.gmail.com>
In-Reply-To: <CABP7RbfDOS4pdnx5Z4arwLw8demRfKrT4bE+Jb4uzvcdgzKRfw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, Joe Gregorio <joe@bitworking.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2013 16:03:23 -0000

hello james.

On 2013-04-08 07:50 , James M Snell wrote:
> "empty_keys" is not defined explicitly as an empty associative array.
> The only definition given for "empty_keys" in section 3.2 is
> "empty_keys := []" which is semantically and structurally identical to
> an empty list. So to amend your rules, we have:
> - an undefined value produces "X"
> - a defined-but-empty string produces "X."
> - a defined-but-empty list/associative-array produces "X"

i agree that since JSON doesn't have associative arrays, [] as a value 
has to be read as just being an empty array/list. but i am still 
wondering about francis' "why" question: if we did not have that test 
case and simply had to reason based on the spec test, how would i end up 
with "X" instead of "X."? when i am just reading the text as somebody 
trying to write code implementing it, i read the spec as telling me "X." 
is what should be the result of expansion.

cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

From fgaliegue@gmail.com  Mon Apr  8 09:30:05 2013
Return-Path: <fgaliegue@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E89A21F9786 for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 09:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2EVhcxdHjUZ for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 09:30:04 -0700 (PDT)
Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCCE21F977A for <apps-discuss@ietf.org>; Mon,  8 Apr 2013 09:30:04 -0700 (PDT)
Received: by mail-ea0-f170.google.com with SMTP id a15so2354261eae.1 for <apps-discuss@ietf.org>; Mon, 08 Apr 2013 09:30:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=T4nJabpvGw8JDEejqPAGG0LM1ymtKoFzryERg2ukyvA=; b=E5dYaW3DLsmEm6yyeLWQwBJ2C8eN/odrFpmzN6qRUBT75+khxhFVPfRAPHEYAGN21h u0MVs8Qwtw9zhbrymjqD+IqkryKxG8xblqzJR58tGSxxVOI/4qpEcMIWVwzZzGmTb1eR s9eaSZmxqF51Zb9JOnS2cDPWUcnDyH8PwDL+QxfupCIlo4zw8rrWKNuGILZp0+yXxVOi 2jflnHXj6gMOD7aFdmJ+XE9atS9mYceEb8tbilcYfKc8qFovtTbJayKxwncPyWTssTCV RL6D7occw/ILNdZmKVuQqE+UhRd2y/DYGaSaf39R5Id06R2mkh3qpOBCQoQnwdx5Zxbn KsTA==
MIME-Version: 1.0
X-Received: by 10.14.179.201 with SMTP id h49mr50124095eem.26.1365438602925; Mon, 08 Apr 2013 09:30:02 -0700 (PDT)
Received: by 10.14.213.4 with HTTP; Mon, 8 Apr 2013 09:30:02 -0700 (PDT)
In-Reply-To: <5162EA00.9060006@berkeley.edu>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com> <CALcybBCeyJce+m7GB8ak_Wmwfk6+Z=bcaDKs489H0v4vLOgahw@mail.gmail.com> <CABP7RbfLQ5wCTNEJ4ufEs76YoVBePP8JYLQkjgUHJQ-o3=pUeg@mail.gmail.com> <CAL0qLwYsVt63VAtg0yqG=KDO7e1DvmE-8ywXM8CBqrt8mxDZOA@mail.gmail.com> <CABP7RbfDOS4pdnx5Z4arwLw8demRfKrT4bE+Jb4uzvcdgzKRfw@mail.gmail.com> <5162EA00.9060006@berkeley.edu>
Date: Mon, 8 Apr 2013 18:30:02 +0200
Message-ID: <CALcybBA=19Dk_XWNjT7Cfd0OQAno1YfYUK+mnqsLADgQ+JSofw@mail.gmail.com>
From: Francis Galiegue <fgaliegue@gmail.com>
To: Erik Wilde <dret@berkeley.edu>
Content-Type: text/plain; charset=UTF-8
Cc: Joe Gregorio <joe@bitworking.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2013 16:30:05 -0000

On Mon, Apr 8, 2013 at 6:02 PM, Erik Wilde <dret@berkeley.edu> wrote:
[...]
>
> i agree that since JSON doesn't have associative arrays, [] as a value has
> to be read as just being an empty array/list.

It does have a "limited" form of it, however: consider a JSON object
where member values are primitives, which can be coerced to strings.

> but i am still wondering about
> francis' "why" question: if we did not have that test case and simply had to
> reason based on the spec test, how would i end up with "X" instead of "X."?
> when i am just reading the text as somebody trying to write code
> implementing it, i read the spec as telling me "X." is what should be the
> result of expansion.
>

That was my thought as well. More generally, the text is very complex
to follow :/ I've had the devil's own job trying to figure it out.

--
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com

From jasnell@gmail.com  Mon Apr  8 09:34:06 2013
Return-Path: <jasnell@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D27321F86C0 for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 09:34:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXCJK8WB-sp1 for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 09:34:04 -0700 (PDT)
Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9C69E21F86BB for <apps-discuss@ietf.org>; Mon,  8 Apr 2013 09:34:04 -0700 (PDT)
Received: by mail-ob0-f178.google.com with SMTP id ni5so1372727obc.23 for <apps-discuss@ietf.org>; Mon, 08 Apr 2013 09:34:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=iZuCXqUNkjEeI9YXva0jQf/s3/ubmlgfpLyyuk5YDdM=; b=NUcI0BvXOUNPN31PznRRn9yFkhe1o6G61lF2yIMDFRNw+ZUKCIao8sK0LUyThjm8co aheceULlUzQhX0s1LpTVl2VO8QuEnQAAC+jEWIRPnHN8mFsxs5/EhR585x+Pxd7X4zYY cZ5C8bhxjeZzYEP+aBdHrqCu3FLvtz68pdCmYl0JZbVeH4ZIV0N2U0uJrCvog4jdWOyb +Y0/FYt73p82Nl6PAZY8iXarnajm0pEeryngWmLb4nq+E4Ob4O6cmwwU9Oeg2uc/FdNg tYgNPRkRAGnN7C1XCgFnsZqK1FSG35Y/zv3nVrdCwq0P4tL6eFNkg3rXotK6Eh33qSoW REZQ==
X-Received: by 10.182.245.72 with SMTP id xm8mr15962766obc.1.1365438844167; Mon, 08 Apr 2013 09:34:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.132.102 with HTTP; Mon, 8 Apr 2013 09:33:44 -0700 (PDT)
In-Reply-To: <CALcybBA=19Dk_XWNjT7Cfd0OQAno1YfYUK+mnqsLADgQ+JSofw@mail.gmail.com>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com> <CALcybBCeyJce+m7GB8ak_Wmwfk6+Z=bcaDKs489H0v4vLOgahw@mail.gmail.com> <CABP7RbfLQ5wCTNEJ4ufEs76YoVBePP8JYLQkjgUHJQ-o3=pUeg@mail.gmail.com> <CAL0qLwYsVt63VAtg0yqG=KDO7e1DvmE-8ywXM8CBqrt8mxDZOA@mail.gmail.com> <CABP7RbfDOS4pdnx5Z4arwLw8demRfKrT4bE+Jb4uzvcdgzKRfw@mail.gmail.com> <5162EA00.9060006@berkeley.edu> <CALcybBA=19Dk_XWNjT7Cfd0OQAno1YfYUK+mnqsLADgQ+JSofw@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
Date: Mon, 8 Apr 2013 09:33:44 -0700
Message-ID: <CABP7RbecvKU_6mKLjftXyByr_UGf+Qj-AzVN4G-3i7wh2UznRA@mail.gmail.com>
To: Francis Galiegue <fgaliegue@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Joe Gregorio <joe@bitworking.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2013 16:34:06 -0000

I agree that the text in the spec is certainly not clear in this. In
my implementation, I've had to fall back to recreating the behavior
shown in the examples. So to answer the question "why", I just fall
back to my original answer: That's what the example shows.


On Mon, Apr 8, 2013 at 9:30 AM, Francis Galiegue <fgaliegue@gmail.com> wrote:
> On Mon, Apr 8, 2013 at 6:02 PM, Erik Wilde <dret@berkeley.edu> wrote:
> [...]
>>
>> i agree that since JSON doesn't have associative arrays, [] as a value has
>> to be read as just being an empty array/list.
>
> It does have a "limited" form of it, however: consider a JSON object
> where member values are primitives, which can be coerced to strings.
>
>> but i am still wondering about
>> francis' "why" question: if we did not have that test case and simply had to
>> reason based on the spec test, how would i end up with "X" instead of "X."?
>> when i am just reading the text as somebody trying to write code
>> implementing it, i read the spec as telling me "X." is what should be the
>> result of expansion.
>>
>
> That was my thought as well. More generally, the text is very complex
> to follow :/ I've had the devil's own job trying to figure it out.
>
> --
> Francis Galiegue, fgaliegue@gmail.com
> JSON Schema in Java: http://json-schema-validator.herokuapp.com

From dret@berkeley.edu  Mon Apr  8 09:46:27 2013
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD9B21F934D for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 09:46:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.289
X-Spam-Level: 
X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfyaFi-2NCio for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 09:46:27 -0700 (PDT)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6627B21F91C4 for <apps-discuss@ietf.org>; Mon,  8 Apr 2013 09:46:27 -0700 (PDT)
Received: from 99-38-249-227.lightspeed.sntcca.sbcglobal.net ([99.38.249.227] helo=[192.168.1.97]) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1UPFD8-0007Ko-L0; Mon, 08 Apr 2013 09:46:27 -0700
Message-ID: <5162F45E.5020906@berkeley.edu>
Date: Mon, 08 Apr 2013 09:46:22 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: James M Snell <jasnell@gmail.com>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com> <CALcybBCeyJce+m7GB8ak_Wmwfk6+Z=bcaDKs489H0v4vLOgahw@mail.gmail.com> <CABP7RbfLQ5wCTNEJ4ufEs76YoVBePP8JYLQkjgUHJQ-o3=pUeg@mail.gmail.com> <CAL0qLwYsVt63VAtg0yqG=KDO7e1DvmE-8ywXM8CBqrt8mxDZOA@mail.gmail.com> <CABP7RbfDOS4pdnx5Z4arwLw8demRfKrT4bE+Jb4uzvcdgzKRfw@mail.gmail.com> <5162EA00.9060006@berkeley.edu> <CALcybBA=19Dk_XWNjT7Cfd0OQAno1YfYUK+mnqsLADgQ+JSofw@mail.gmail.com> <CABP7RbecvKU_6mKLjftXyByr_UGf+Qj-AzVN4G-3i7wh2UznRA@mail.gmail.com>
In-Reply-To: <CABP7RbecvKU_6mKLjftXyByr_UGf+Qj-AzVN4G-3i7wh2UznRA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Joe Gregorio <joe@bitworking.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2013 16:46:28 -0000

hello james.

On 2013-04-08 09:33 , James M Snell wrote:
> I agree that the text in the spec is certainly not clear in this. In
> my implementation, I've had to fall back to recreating the behavior
> shown in the examples. So to answer the question "why", I just fall
> back to my original answer: That's what the example shows.

that raises one of the interesting questions in test-driven development: 
if a test fails and you check and still think that you've implemented 
what the spec text asks you to implement, how do you reconcile? 
special-casing just for tests probably isn't the way to go, so how 
exactly did you tweak the code (or your interpretation of the spec 
resulting in code) to satisfy the test?

i am really interested, because i'll be implementing it as well and i am 
pretty sure that i'll run into the exact same issue.

thanks and cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

From vkg@bell-labs.com  Mon Apr  8 10:15:22 2013
Return-Path: <vkg@bell-labs.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9155021F93EE for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 10:15:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.8
X-Spam-Level: 
X-Spam-Status: No, score=-109.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQRncgVcSpdy for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 10:15:21 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 77E5F21F9355 for <apps-discuss@ietf.org>; Mon,  8 Apr 2013 10:15:11 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r38HFA2c020954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Apr 2013 12:15:10 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r38HF9CB000781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 8 Apr 2013 12:15:10 -0500
Received: from shoonya.ih.lucent.com (vkg.lra.lucent.com [135.244.22.26]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r38HF8S1007377; Mon, 8 Apr 2013 12:15:09 -0500 (CDT)
Message-ID: <5162FBD4.7010701@bell-labs.com>
Date: Mon, 08 Apr 2013 12:18:12 -0500
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4
MIME-Version: 1.0
To: draft-ietf-pcp-upnp-igd-interworking.all@tools.ietf.org
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: [apps-discuss] APPSDIR review of draft-ietf-pcp-upnp-igd-interworking-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2013 17:15:22 -0000

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-pcp-upnp-igd-interworking-07
Title: Universal Plug and Play (UPnP) Internet Gateway Device (IGD)-Port
        Control Protocol (PCP) Interworking Function
Reviewer: Vijay K. Gurbani
Review Date: Apr-08-2013
IETF Last Call Date: Not known
IESG Telechat Date: Not known

Summary: This draft is ready for publication as a Proposed Standard.
A few issues that should be looked at before publication are listed
below.

Major Issues: 0
Minor Issues: 1
Nits: 2

Minor:
------
- S1, Figure 1: Where is the IGD in this figure?  Is it co-located
  with the UPnP-PCP IWF?  You may want to be more explicit about
  the location of the IGD since the remaining text depends on this
  context.  Note that it may be clear to you where the IGD is, but it
  may not be so apparent to readers not up to speed with this area.

Nits:
-----
- S1, first and second paragraphs: You may want to expand IGD when it is
  first encountered in the first paragraph.  You do the expansion in the
  second occurrence (paragraph two, bullet one).  Just move it up.

  Additionally, you may want to expand IWF when it first appears below
  Figure 1.

- S5.6.1, in the "Discussion" indentation: Is it "Vuzz" or do you mean
  "Vuze"?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/

From superuser@gmail.com  Mon Apr  8 13:40:16 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2DE21F907E for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 13:40:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdMHGI8SaprL for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 13:40:15 -0700 (PDT)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id E062821F84D9 for <apps-discuss@ietf.org>; Mon,  8 Apr 2013 13:40:14 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id n12so6134225wgh.31 for <apps-discuss@ietf.org>; Mon, 08 Apr 2013 13:40:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vEA72Me9xuE7HLKt7g8XOSXv3jWi6vwe4j4j898CSOc=; b=afsWunrj4MQGuZYoIc5MwQT5E4FijaIv3uBt4FKwjYdolPOQrWQi28F7PNIbpF7QI5 w7Kd1KcXdWcVXQi72jWnVo8MhaHLdgcLUnkw8q3njj8xlekeWISsuF8eFZ4iEbKidEeg Z/3CATR+/+2QKpaNF7q6pW6oUSvDEoUF9E5eioU+nMSNhjcRgSOI/m7YabX0o3/kqnNw R3Owtj5PZVMTS61IhqiCLeHcP6Slqi/+W7fm/lTfP3WNVaIMg7I4pXWKgZP0tIxyydji R1VP8KXSZqvtQYwS+Jodj9kXyFQbmuoLGrXMG5lYz3Da21+XiJYByttQOXRTTrYIAz4Z 8t8A==
MIME-Version: 1.0
X-Received: by 10.180.92.229 with SMTP id cp5mr5448247wib.20.1365453612103; Mon, 08 Apr 2013 13:40:12 -0700 (PDT)
Received: by 10.180.36.176 with HTTP; Mon, 8 Apr 2013 13:40:11 -0700 (PDT)
In-Reply-To: <CABP7RbfDOS4pdnx5Z4arwLw8demRfKrT4bE+Jb4uzvcdgzKRfw@mail.gmail.com>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com> <CALcybBCeyJce+m7GB8ak_Wmwfk6+Z=bcaDKs489H0v4vLOgahw@mail.gmail.com> <CABP7RbfLQ5wCTNEJ4ufEs76YoVBePP8JYLQkjgUHJQ-o3=pUeg@mail.gmail.com> <CAL0qLwYsVt63VAtg0yqG=KDO7e1DvmE-8ywXM8CBqrt8mxDZOA@mail.gmail.com> <CABP7RbfDOS4pdnx5Z4arwLw8demRfKrT4bE+Jb4uzvcdgzKRfw@mail.gmail.com>
Date: Mon, 8 Apr 2013 13:40:11 -0700
Message-ID: <CAL0qLwaoaYbnHiYCuxC050Yn=G3C5skG5m9mkb_SvO0Yhkf8hw@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: James M Snell <jasnell@gmail.com>
Content-Type: multipart/alternative; boundary=f46d043c094e81c00e04d9df71f9
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, Joe Gregorio <joe@bitworking.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2013 20:40:16 -0000

--f46d043c094e81c00e04d9df71f9
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 8, 2013 at 7:50 AM, James M Snell <jasnell@gmail.com> wrote:

> "empty_keys" is not defined explicitly as an empty associative array.
> The only definition given for "empty_keys" in section 3.2 is
> "empty_keys := []" which is semantically and structurally identical to
> an empty list. So to amend your rules, we have:
>
> - an undefined value produces "X"
> - a defined-but-empty string produces "X."
> - a defined-but-empty list/associative-array produces "X"


Everywhere else in the document refers to a list as (value[, value[,
...]]).  So it seems to me "()" is the empty list, while "[]" is not.

--f46d043c094e81c00e04d9df71f9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Apr 8, 2013 at 7:50 AM, James M Snell <span dir=3D=
"ltr">&lt;<a href=3D"mailto:jasnell@gmail.com" target=3D"_blank">jasnell@gm=
ail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">&quot;empty_keys&quot; is not defined explic=
itly as an empty associative array.<br>
The only definition given for &quot;empty_keys&quot; in section 3.2 is<br>
&quot;empty_keys :=3D []&quot; which is semantically and structurally ident=
ical to<br>
an empty list. So to amend your rules, we have:<br>
<div class=3D"im"><br>
- an undefined value produces &quot;X&quot;<br>
- a defined-but-empty string produces &quot;X.&quot;<br>
</div>- a defined-but-empty list/associative-array produces &quot;X&quot;</=
blockquote><div><br></div><div>Everywhere else in the document refers to a =
list as (value[, value[, ...]]).=A0 So it seems to me &quot;()&quot; is the=
 empty list, while &quot;[]&quot; is not.<br>
<br></div></div></div></div>

--f46d043c094e81c00e04d9df71f9--

From yoshiro.yoneya@jprs.co.jp  Mon Apr  8 21:30:07 2013
Return-Path: <yoshiro.yoneya@jprs.co.jp>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5209521F9020; Mon,  8 Apr 2013 21:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wky5MolMg-Q6; Mon,  8 Apr 2013 21:30:01 -0700 (PDT)
Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 80D1C21F8FC7; Mon,  8 Apr 2013 21:30:00 -0700 (PDT)
Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id r394Twtd018484; Tue, 9 Apr 2013 13:29:58 +0900
X-AuditID: ac120820-b7fec6d000005acc-4a-51639945388a
Received: from NOTE338 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 38.FE.23244.54993615; Tue,  9 Apr 2013 13:29:58 +0900 (JST)
Date: Tue, 9 Apr 2013 13:29:55 +0900
From: Yoshiro YONEYA <yoshiro.yoneya@jprs.co.jp>
To: apps-discuss@ietf.org, draft-ietf-dnsext-dnssec-algo-signal.all@tools.ietf.org
Message-Id: <20130409132955.15d4bb2cadcc8261658723c8@jprs.co.jp>
X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32)
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGIsWRmVeSWpSXmKPExsWyRoiFT9dtZnKgwaFTHBarX65gs/jw7jar xYw/E5ktuto2sziweCxZ8pPJ4+/9d6weXy5/ZgtgjuKySUnNySxLLdK3S+DKOHyEv2AtR0XX onWsDYz32boYOTgkBEwkHv7I7WLkBDLFJC7cW88GYgsJHGeU+NCjDmKzCKhIbNnfzwJiswkY SPxa9psJxBYRCJF4cP8LK4jNLCAo0fT+FViNsICTxJfOV4wgNq+Ag8TnS+cYIeZbSFxo6mAH WcsLVP93hzCIySygLrF+nhDEFHmJ5q2zmScw8s5CKJqFUDQLSdECRuZVjDL5aWm6xal5KcW5 6QaGeiWV+XpZBUXFeskgehMjONg4FHYwzjhlcIhRgINRiYe37lFSoBBrYllxZe4hRkkOJiVR 3hfTkwOF+JLyUyozEosz4otKc1KLDzFKcDArifB2GwLleFMSK6tSi/JhUtIcLErivMfP7vAT EkhPLEnNTk0tSC2CycpwcChJ8O4FGSpYlJqeWpGWmVOCkGbi4AQZzgM0/AlIDW9xQWJucWY6 RP4Uo6SUOO9LkIQASCKjNA+u9xWjONALwryHQLI8wMQB1/UKaCAT0ED+C/EgA0sSEVJSDYxC VtybjKfs8PiiGfTt8Iytbxis5eO6xa/9K1NkPK23796MI0cVAmVOMHJEbdHoXKpzMPvHKaYw Z4Ps0h+/7k9ZUc6R2z1BPbki8FjO0dcdXz6ZH4/r91j8OfL65cB9QsYTks07q1QND5iyJ5vy V2dpHdq22eHxbG7OZ7Z+Hnddaq84GnJ8s1FiKc5INNRiLipOBACocks62QIAAA==
Cc: iesg@ietf.org
Subject: [apps-discuss] APPSDIR Review of draft-ietf-dnsext-dnssec-algo-signal-10
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2013 04:30:07 -0000

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see 
​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-ietf-dnsext-dnssec-algo-signal-10
Title: Signaling Cryptographic Algorithm Understanding in DNSSEC
Reviewer: Yoshiro Yoneya
Review Date: 2013-04-09
IETF Last Call Date: 2013-03-20
IESG Telechat Date: not known

Summary: 

  This draft is almost ready for publication as a Standards Track RFC.

Major Issues: 

  none

Minor Issues: 

- Section 2 [Page 4]
  LIST-LENGTH is an integer which can be zero.  Using zero for LIST-LENGTH 
  is meaningless and it must be avoided not to be waste of resources.
  LIST-LENGTH should be specified as one or more explicitly.

Regards,

-- 
Yoshiro YONEYA <yoshiro.yoneya@jprs.co.jp>


From mnot@mnot.net  Mon Apr  8 23:52:10 2013
Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4770821F8F24 for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 23:52:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.016
X-Spam-Level: 
X-Spam-Status: No, score=-105.016 tagged_above=-999 required=5 tests=[AWL=-2.917, BAYES_00=-2.599, GB_ABOUTYOU=0.5, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtL1eclu8ec3 for <apps-discuss@ietfa.amsl.com>; Mon,  8 Apr 2013 23:52:04 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAFC21F8E7B for <apps-discuss@ietf.org>; Mon,  8 Apr 2013 23:52:03 -0700 (PDT)
Received: from [192.168.1.80] (unknown [118.209.42.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 319CF509B5; Tue,  9 Apr 2013 02:52:00 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <E30D6548-732B-4996-8363-A699A487B65B@nordsc.com>
Date: Tue, 9 Apr 2013 16:51:56 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <51DCC678-F1A5-4877-8168-260DE09244E5@mnot.net>
References: <E30D6548-732B-4996-8363-A699A487B65B@nordsc.com>
To: Jan Algermissen <jan.algermissen@nordsc.com>
X-Mailer: Apple Mail (2.1503)
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] JSON-Home widget example
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2013 06:52:15 -0000

Hi Jan,

This isn't really specific to home; it's about collections and link =
relations. It came up some when we were doing 5988, IIRC.

There are a couple of ways of dealing with it.=20

One would be to have a "collection" link relation and then put a =
parameter on it that says what it contains.

E.g., as a HTTP header, it would be:
  Link: </widgets>; rel=3D"collection"; =
contains=3D"http://example.org/rel/widget"

However, in JSON Home, this becomes:

     "collection": {
        "href": "/widgets/",
        "contains": "http://example.org/rel/widget"
      },
      "http://example.org/rel/widget": {
        "href-template": "/widgets/{widget_id}",
        "href-vars": {
          "widget_id": "http://example.org/param/widget"
        },
        ...
      }

which isn't great, because you can then have only one collection type in =
your API! It also means that a *lot* of identifying information is lost =
from the link relation type. If we allowed multiple collection relation =
types to be defined (for example, by making its value an array of =
objects), it would introduce an extra layer of dispatch, which isn't =
great.

If you turn that inside-out, you might end up with something like:

      "http://example.org/rel/widget": {
        "href-template": "/widgets/{widget_id}",
        "href-vars": {
          "widget_id": "http://example.org/param/widget"
        },
        "container": "/widgets/"
      }

This is succinct, but I'm wary, because the container is "hidden" inside =
the widget type, and you now need to *very* precisely define the =
semantics of "container"; if you want to vary from it even a little bit, =
you're out of luck, because there's no space for adorning it with hints, =
etc. This approach also precludes mixing different things in the same =
container (at least obviously).

The way I look at it, what you're asking for here is syntactic sugar. In =
English, we have separate names for "jar" and "candy" because they're =
separate things, even though they're often used together.

While it's tempting to define the primitive "jar of candy", I don't want =
to *start* there, because it'll severely limit the expressiveness of the =
format, and create awkward special/corner cases.

So, I suspect that we'll always need two relation types to accurately =
talk about things vs. containers of things.=20

That's not to say that we don't need something here, of course; IIRC =
there is a TODO in the spec for precisely this. I'm just not quite at =
the point where I know what it looks like. If I had to take a stab now, =
it'd be something like:

     "http://example.org/rel/widget": {
        "href": "/widgets/",
        "contains": "http://example.org/rel/widget"
      },
      "http://example.org/rel/widget": {
        "href-template": "/widgets/{widget_id}",
        "href-vars": {
          "widget_id": "http://example.org/param/widget"
        },
        ...
      }

Does that make sense?=20

Cheers,






On 08/04/2013, at 9:11 PM, Jan Algermissen <jan.algermissen@nordsc.com> =
wrote:

> Hi Mark,
>=20
> curious about your opinion on the following.
>=20
> The example you provide in the draft[1] troubles me a bit since a =
real-life, similar case made me look at it from a different angle.
>=20
>=20
>    "http://example.org/rel/widgets": {
>         "href": "/widgets/"
>       },
>       "http://example.org/rel/widget": {
>         "href-template": "/widgets/{widget_id}",
>         "href-vars": {
>           "widget_id": "http://example.org/param/widget"
>         },
>         ...
>       }
>=20
> What we have here is sort of a standard pattern for making available =
'a bag of things' via HTTP.
>=20
> For example, a bunch of orders can be straight forward exposed as
>=20
>  /orders
>=20
> and knowing that
>=20
>  "http://example.org/rel/orders" : { "href" : "/orders" }
>=20
> pretty much implies something like /orders/{orderId}, including the =
idea that adding an order is likely done with a POST to /orders and that =
editing an order is (maybe) achieved with PUT/PATCH/DELETE.
>=20
> What troubles me is that JSON Home currently makes it necessary to =
define two link relations to cover a standard (in a sense) use case that =
could be covered with just one link relation. Or, in other words, the =
two link rels somehow semantically overlap, yet demand two =
'specifications'. Think in terms of violating DRY.
>=20
> Can't think of an improvement that does not introduce the 'pattern' =
into the spec, but I am nevertheless much interested in your view.
>=20
> Maybe an optional {widget_id} and one rel with appropriate definition =
does the trick already, but hard to seperate the hints. Dunno...
>=20
> Jan
>=20
> [1] http://tools.ietf.org/html/draft-nottingham-json-home-02
>=20

--
Mark Nottingham   http://www.mnot.net/




From sm@elandsys.com  Tue Apr  9 04:06:44 2013
Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670B621F905C; Tue,  9 Apr 2013 04:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.159
X-Spam-Level: 
X-Spam-Status: No, score=-102.159 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O+otzlQdOua; Tue,  9 Apr 2013 04:06:43 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A83BA21F9120; Tue,  9 Apr 2013 04:06:43 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.142.138]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r39B6Tk7023328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Apr 2013 04:06:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365505602; bh=mLe25Y/RtHSyLJFO3nWqVbBIKwcocSGZQYzMXzPPUz0=; h=Date:To:From:Subject:Cc; b=jwND6rKBnOGin3k8M6xY7pnpteOSy8JC70udgzHSOT6+kV6MnLj3ICbyB1IBYvk+V ud3dnlw5TzST/dpt1mm5SF8XkQohqInh2DXYxlVzAI50l/9p2p7BhKLQTMV3x77K/o 6vVVjVgtgWicZz3B0iGf5bBoJqVzd1k7PVDxBk/M=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1365505602; i=@elandsys.com; bh=mLe25Y/RtHSyLJFO3nWqVbBIKwcocSGZQYzMXzPPUz0=; h=Date:To:From:Subject:Cc; b=Zi2c9QyvM8kdvGOmJLRkJ0hTlCZgrViPgcgkuQZXkeRc/Uk9/cNCAN8JMkt8sqwu9 ihfTgM3VsKFJknz2l8hXSNQb/k63GfmfwJjebAup/M01X9EpakvgQuO2d5BnHNJ9GT R3vrSq51husVqnpa3UN5lXXrBW8MyYMfdqhwqBL8=
Message-Id: <6.2.5.6.2.20130409030107.0e720478@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 09 Apr 2013 04:05:42 -0700
To: apps-discuss@ietf.org, draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: iesg@ietf.org
Subject: [apps-discuss] APPSDIR review of draft-ietf-ipfix-flow-selection-tech-14
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2013 11:06:44 -0000

I have been selected as the Applications Area Directorate reviewer 
for this draft (for background on APPSDIR, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft.

Document: draft-ietf-ipfix-flow-selection-tech-14
Title: Flow Selection Techniques
Reviewer: S. Moonesamy
Review Date: April 9, 2013
IETF Last Call Date: March 18, 2013

Summary: This draft is almost ready for publication.

This document describes Intermediate Flow Selection Process 
techniques for network traffic measurements, provides a 
categorization of Intermediate Flow Selection Process techniques and 
describes configuration and reporting parameters for them.  Idid not 
find any applications-related considerations.

Major issues: none

Minor issues:

The intended status of the document is Standards Track.  Some of the 
requirements I could find are:

In Section 1:

   "In order to be compliant with this document, at least the Property
    Match Filtering MUST be implemented."

The above text is repeated in Section 5.1.  I suggest removing this 
sentence as it does not seem related to scope.

My reading of the "MUST" is that it is being used for compliance 
instead of the reasons described in RFC 2119.  I suggest reviewing 
the usage of RFC 2119 key words in Section 5.1.

Why should this document be published on the Standards Track instead 
of Informational?  I am asking this question as I could not suggest 
Standards Track as the intended status.

In Section 8.1.1:

   "The flowSelectorAlgorithm registry is maintained by IANA."

I suggest phasing this as a request to create the registry.

   "The registry can be updated when specifications of the new
    technique(s) and any new Information Elements are provided."

How should this registry be managed?

Regards,
S. Moonesamy


From mohamed.boucadair@orange.com  Tue Apr  9 05:39:44 2013
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 867E021F8EDB for <apps-discuss@ietfa.amsl.com>; Tue,  9 Apr 2013 05:39:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_SUB_RAND_LETTRS4=0.799, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T84RwRv9Sqoj for <apps-discuss@ietfa.amsl.com>; Tue,  9 Apr 2013 05:39:43 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7CADE21F8B9C for <apps-discuss@ietf.org>; Tue,  9 Apr 2013 05:39:43 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 2C8BE22C8F0; Tue,  9 Apr 2013 14:39:42 +0200 (CEST)
Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id F1A3B23806C; Tue,  9 Apr 2013 14:39:41 +0200 (CEST)
Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.7]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 9 Apr 2013 14:39:41 +0200
From: <mohamed.boucadair@orange.com>
To: "Vijay K. Gurbani" <vkg@bell-labs.com>, "draft-ietf-pcp-upnp-igd-interworking.all@tools.ietf.org" <draft-ietf-pcp-upnp-igd-interworking.all@tools.ietf.org>
Date: Tue, 9 Apr 2013 14:39:40 +0200
Thread-Topic: APPSDIR review of draft-ietf-pcp-upnp-igd-interworking-07
Thread-Index: Ac40fK27p8e/nRJmShusWocVtRjXOgAoQ5JA
Message-ID: <94C682931C08B048B7A8645303FDC9F36EC1AE76D5@PUEXCB1B.nanterre.francetelecom.fr>
References: <5162FBD4.7010701@bell-labs.com>
In-Reply-To: <5162FBD4.7010701@bell-labs.com>
Accept-Language: fr-FR
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.3.25.85421
X-Mailman-Approved-At: Tue, 09 Apr 2013 08:29:45 -0700
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-pcp-upnp-igd-interworking-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2013 12:39:44 -0000

RGVhciBWaWpheSwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3Lg0KDQpQbGVhc2Ugc2VlIGlubGlu
ZS4NCkNoZWVycywNCk1lZA0KDQo+LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+RGXCoDog
VmlqYXkgSy4gR3VyYmFuaSBbbWFpbHRvOnZrZ0BiZWxsLWxhYnMuY29tXQ0KPkVudm95w6nCoDog
bHVuZGkgOCBhdnJpbCAyMDEzIDE5OjE4DQo+w4DCoDogZHJhZnQtaWV0Zi1wY3AtdXBucC1pZ2Qt
aW50ZXJ3b3JraW5nLmFsbEB0b29scy5pZXRmLm9yZw0KPkNjwqA6IGFwcHMtZGlzY3Vzc0BpZXRm
Lm9yZw0KPk9iamV0wqA6IEFQUFNESVIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcGNwLXVwbnAtaWdk
LWludGVyd29ya2luZy0wNw0KPg0KPkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBBcHBsaWNh
dGlvbnMgQXJlYSBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3INCj50aGlzIGRyYWZ0IChmb3IgYmFj
a2dyb3VuZCBvbiBhcHBzZGlyLCBwbGVhc2Ugc2VlIA0KPmh0dHA6Ly90cmFjLnRvb2xzLmlldGYu
b3JnL2FyZWEvYXBwL3RyYWMvd2lraS9BcHBsaWNhdGlvbnNBcmVhRGlyZWN0b3JhdGUNCj4pLg0K
Pg0KPlBsZWFzZSByZXNvbHZlIHRoZXNlIGNvbW1lbnRzIGFsb25nIHdpdGggYW55IG90aGVyIExh
c3QgQ2FsbCBjb21tZW50cw0KPnlvdSBtYXkgcmVjZWl2ZS4gUGxlYXNlIHdhaXQgZm9yIGRpcmVj
dGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgc2hlcGhlcmQNCj5vciBBRCBiZWZvcmUgcG9zdGluZyBh
IG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCj4NCj5Eb2N1bWVudDogZHJhZnQtaWV0Zi1wY3At
dXBucC1pZ2QtaW50ZXJ3b3JraW5nLTA3DQo+VGl0bGU6IFVuaXZlcnNhbCBQbHVnIGFuZCBQbGF5
IChVUG5QKSBJbnRlcm5ldCBHYXRld2F5IERldmljZSAoSUdEKS1Qb3J0DQo+ICAgICAgICBDb250
cm9sIFByb3RvY29sIChQQ1ApIEludGVyd29ya2luZyBGdW5jdGlvbg0KPlJldmlld2VyOiBWaWph
eSBLLiBHdXJiYW5pDQo+UmV2aWV3IERhdGU6IEFwci0wOC0yMDEzDQo+SUVURiBMYXN0IENhbGwg
RGF0ZTogTm90IGtub3duDQo+SUVTRyBUZWxlY2hhdCBEYXRlOiBOb3Qga25vd24NCj4NCj5TdW1t
YXJ5OiBUaGlzIGRyYWZ0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiBhcyBhIFByb3Bvc2VkIFN0
YW5kYXJkLg0KPkEgZmV3IGlzc3VlcyB0aGF0IHNob3VsZCBiZSBsb29rZWQgYXQgYmVmb3JlIHB1
YmxpY2F0aW9uIGFyZSBsaXN0ZWQNCj5iZWxvdy4NCj4NCj5NYWpvciBJc3N1ZXM6IDANCj5NaW5v
ciBJc3N1ZXM6IDENCj5OaXRzOiAyDQo+DQo+TWlub3I6DQo+LS0tLS0tDQo+LSBTMSwgRmlndXJl
IDE6IFdoZXJlIGlzIHRoZSBJR0QgaW4gdGhpcyBmaWd1cmU/ICBJcyBpdCBjby1sb2NhdGVkDQo+
ICB3aXRoIHRoZSBVUG5QLVBDUCBJV0Y/ICBZb3UgbWF5IHdhbnQgdG8gYmUgbW9yZSBleHBsaWNp
dCBhYm91dA0KPiAgdGhlIGxvY2F0aW9uIG9mIHRoZSBJR0Qgc2luY2UgdGhlIHJlbWFpbmluZyB0
ZXh0IGRlcGVuZHMgb24gdGhpcw0KPiAgY29udGV4dC4gIE5vdGUgdGhhdCBpdCBtYXkgYmUgY2xl
YXIgdG8geW91IHdoZXJlIHRoZSBJR0QgaXMsIGJ1dCBpdA0KPiAgbWF5IG5vdCBiZSBzbyBhcHBh
cmVudCB0byByZWFkZXJzIG5vdCB1cCB0byBzcGVlZCB3aXRoIHRoaXMgYXJlYS4NCg0KW01lZF0g
RmlndXJlIDEgbG9va3Mgbm93OiANCg0KICAgICAgICAgICAgICAgICAgICAgICAgICBVUG5QIElH
RC1QQ1ANCiAgIFVQblAgQ29udHJvbCAgICAgICAgICAgSW50ZXJ3b3JraW5nDQogICAgICBQb2lu
dCAgICAgICAgICAgICAgICAgRnVuY3Rpb24gICAgICAgICAgICAgICAgICBQQ1AgU2VydmVyDQog
ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICBJR0QgICAgICAgICAgICAgICAgICAgICAgICAg
IHwNCiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfA0KICAgICAgICB8ICgxKSBBZGRQb3J0TWFwcGluZyAgIHwgICAgICAgICAgICAgICAg
ICAgICAgICAgICB8DQogICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHwNCiAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICB8ICAgKDIp
IFBDUCBNQVAgUmVxdWVzdCAgICAgfA0KICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgIHwt
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58DQogICAgICAgIHwgICAgICAgICAgICAgICAgICAg
ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCg0KDQo+Tml0czoNCj4tLS0tLQ0KPi0g
UzEsIGZpcnN0IGFuZCBzZWNvbmQgcGFyYWdyYXBoczogWW91IG1heSB3YW50IHRvIGV4cGFuZCBJ
R0Qgd2hlbiBpdCBpcw0KPiAgZmlyc3QgZW5jb3VudGVyZWQgaW4gdGhlIGZpcnN0IHBhcmFncmFw
aC4gIFlvdSBkbyB0aGUgZXhwYW5zaW9uIGluIHRoZQ0KPiAgc2Vjb25kIG9jY3VycmVuY2UgKHBh
cmFncmFwaCB0d28sIGJ1bGxldCBvbmUpLiAgSnVzdCBtb3ZlIGl0IHVwLg0KDQpbTWVkXSBGaXhl
ZC4gIA0KDQo+DQo+ICBBZGRpdGlvbmFsbHksIHlvdSBtYXkgd2FudCB0byBleHBhbmQgSVdGIHdo
ZW4gaXQgZmlyc3QgYXBwZWFycyBiZWxvdw0KPiAgRmlndXJlIDEuDQoNCltNZWRdIEZpeGVkLg0K
DQo+DQo+LSBTNS42LjEsIGluIHRoZSAiRGlzY3Vzc2lvbiIgaW5kZW50YXRpb246IElzIGl0ICJW
dXp6IiBvciBkbyB5b3UgbWVhbg0KPiAgIlZ1emUiPw0KDQpbTWVkXSBJdCBpcyBWdXplLiBGaXhl
ZC4gVGhhbmtzIGZvciBjYXRjaGluZyB0aGlzLg0KDQo+DQo+VGhhbmtzLA0KPg0KPi0gdmlqYXkN
Cj4tLQ0KPlZpamF5IEsuIEd1cmJhbmksIEJlbGwgTGFib3JhdG9yaWVzLCBBbGNhdGVsLUx1Y2Vu
dA0KPjE5NjAgTHVjZW50IExhbmUsIFJtLiA5Qy01MzMsIE5hcGVydmlsbGUsIElsbGlub2lzIDYw
NTYzIChVU0EpDQo+RW1haWw6IHZrZ0B7YmVsbC1sYWJzLmNvbSxhY20ub3JnfSAvIHZpamF5Lmd1
cmJhbmlAYWxjYXRlbC1sdWNlbnQuY29tDQo+V2ViOiAgIGh0dHA6Ly9lY3QuYmVsbC1sYWJzLmNv
bS93aG8vdmtnLw0K

From superuser@gmail.com  Tue Apr  9 12:44:54 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C555221F9909 for <apps-discuss@ietfa.amsl.com>; Tue,  9 Apr 2013 12:44:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-AjF61wreU2 for <apps-discuss@ietfa.amsl.com>; Tue,  9 Apr 2013 12:44:54 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5E121F9908 for <apps-discuss@ietf.org>; Tue,  9 Apr 2013 12:44:53 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id u12so5583981wey.33 for <apps-discuss@ietf.org>; Tue, 09 Apr 2013 12:44:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=H1giaZy6/aNPE/3BBvGmA1pInaEYaQIEGk95kDX1wfk=; b=wWGfghDH3kADOq0pRi3lrS2vRXAyJvV7Ooh5GDBy2neZo7fKD05mEeHPujI4PcVioU EWzX4b3DV8Vp+ar0jjsQz7mldwvcsBb5tYvxGog9Gqd4PzOZKpT+JqiamOh0JDXeMhPa BBWLGg6i8CEV/70+0ieGxQERSjTstWLnpPAiZe0eTUpx4RjHDBSycnKQ9+wkoFdmmbLW w++Fn5OkYa+JQ6GYqw/CxeUONcwV4wOpE1tm1SgfOwMFxZXz+xfUFSpiw7rtbBgcDNCh iG7AQVKBFCVxIgPQOH9JdU7oy99n5rLwpO6Y1+SYLS85q6fSKXGp4YRneeF3NZMyGPt/ snWw==
MIME-Version: 1.0
X-Received: by 10.180.74.67 with SMTP id r3mr21899028wiv.14.1365536692869; Tue, 09 Apr 2013 12:44:52 -0700 (PDT)
Received: by 10.180.36.176 with HTTP; Tue, 9 Apr 2013 12:44:52 -0700 (PDT)
Date: Tue, 9 Apr 2013 12:44:52 -0700
Message-ID: <CAL0qLwaS+4S=1hr+2vi2N-UR+7DxgDsDm11YuPuR1W8X=guRTw@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary=f46d0438914d81a04004d9f2c90e
Subject: [apps-discuss] draft-ietf-appsawg-malformed-mail
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2013 19:44:54 -0000

--f46d0438914d81a04004d9f2c90e
Content-Type: text/plain; charset=ISO-8859-1

Colleagues,

Since my co-author and I have been unable to solicit any comments or
support for continuing to work on the above document for many months now,
we are going to let it expire at the end of this week absent a sudden surge
of interest in the near future.  If the working group is interested in it
again at some later date, we can ressurect it.

For now I'm going to mark it "parked", leaving Salvatore's docket slightly
lighter.

-MSK

--f46d0438914d81a04004d9f2c90e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Colleagues,<br><br></div><div>Since my co-author and =
I have been unable to solicit any comments or support for continuing to wor=
k on the above document for many months now, we are going to let it expire =
at the end of this week absent a sudden surge of interest in the near futur=
e.=A0 If the working group is interested in it again at some later date, we=
 can ressurect it.<br>
<br></div><div>For now I&#39;m going to mark it &quot;parked&quot;, leaving=
 Salvatore&#39;s docket slightly lighter.<br><br></div><div>-MSK<br></div><=
/div>

--f46d0438914d81a04004d9f2c90e--

From sm@elandsys.com  Tue Apr  9 12:58:53 2013
Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D6421F9814; Tue,  9 Apr 2013 12:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.555
X-Spam-Level: 
X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXSbQPiUEsHE; Tue,  9 Apr 2013 12:58:53 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFA021F97E7; Tue,  9 Apr 2013 12:58:52 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.142.138]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r39JwZkW002050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Apr 2013 12:58:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365537530; bh=XPQhi/UzwEcHf0ucKeHF9M92R7Z52WQ4bu/FZV7/BMw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=T8fEYyhh5nUm7bIAPBb71Ho7uZCpgi/bUStrRgm1XFsI84g07uY2aF6z3aC4e1Pth LSXGHai5g+2+S4AS4LmnermZ2KhdgnNCkFLlMvrin2+BJ13i+xZkeRW/ni/b81rq28 PoNRu7r9xF5cSBc0PNVvKFXSqWeN1ZzptNrSXClY=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1365537530; i=@elandsys.com; bh=XPQhi/UzwEcHf0ucKeHF9M92R7Z52WQ4bu/FZV7/BMw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oSS3jGaLWIPHM0HZ8yurSgzMZMenqJiiPlfhNX9Qxfshv8J3VQSb/p+DrVNrNewHM 4K4NY6VGm+0HIMQskJIiSH476wAUQ0kqGuj5scBlKJHPAzLPo8kVqKPvPxzZJqH4jy H1q90i6aYr8CbuKicuCkyQQPtRtacyzZB7kd/fGA=
Message-Id: <6.2.5.6.2.20130409084702.0c6104b8@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 09 Apr 2013 09:10:18 -0700
To: "Salvatore D'Antonio" <salvatore.dantonio@uniparthenope.it>, draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it>
References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ipfix@ietf.org, iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt> (APPSDIR review)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2013 19:58:54 -0000

Hi Salvatore,
At 08:40 09-04-2013, Salvatore D'Antonio wrote:
>-          The sentence "The registry can be updated when 
>specifications of the new  technique(s) and any new Information 
>Elements are provided." has been removed since it did not clarify 
>how the registry will be managed.

This is a follow-up to the APPSDIR review of 
draft-ietf-ipfix-flow-selection-tech ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09239.html )

 From Section 9.1.1 of draft-ietf-ipfix-flow-selection-tech-15:

   "New assignments for the registry will be administered
    by IANA and are subject to Expert Review [RFC5226]."

draft-ietf-ipfix-flow-selection-tech-15 defines a sub-registry.  It 
does not provide any relevant details about the sub-registry.  What 
documentation is required and which criteria will be used for 
assignments in the new sub-registry?

Regards,
S. Moonesamy 


From tony@att.com  Tue Apr  9 13:24:31 2013
Return-Path: <tony@att.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB3521F982F for <apps-discuss@ietfa.amsl.com>; Tue,  9 Apr 2013 13:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ATUtwWZZKuw for <apps-discuss@ietfa.amsl.com>; Tue,  9 Apr 2013 13:24:31 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9F94A21F93EE for <apps-discuss@ietf.org>; Tue,  9 Apr 2013 13:24:30 -0700 (PDT)
Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id ef874615.0.321857.00-230.901883.nbfkord-smmo05.seg.att.com (envelope-from <tony@att.com>);  Tue, 09 Apr 2013 20:24:30 +0000 (UTC)
X-MXL-Hash: 516478fe51e8eea3-9b8819d2b586a78e35223c0e459ab4f8d8cbad1b
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r39KOUGM029503 for <apps-discuss@ietf.org>; Tue, 9 Apr 2013 16:24:30 -0400
Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r39KOOA4029469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Tue, 9 Apr 2013 16:24:25 -0400
Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for <apps-discuss@ietf.org>; Tue, 9 Apr 2013 21:24:19 +0100
Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r39KOI74025884 for <apps-discuss@ietf.org>; Tue, 9 Apr 2013 16:24:18 -0400
Received: from mailgw1.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r39KOC9e025687 for <apps-discuss@ietf.org>; Tue, 9 Apr 2013 16:24:12 -0400
Received: from [135.70.50.99] (vpn-135-70-50-99.vpn.west.att.com[135.70.50.99]) by maillennium.att.com (mailgw1) with ESMTP id <20130409202222gw1000m5gpe> (Authid: tony); Tue, 9 Apr 2013 20:22:23 +0000
X-Originating-IP: [135.70.50.99]
Message-ID: <516478E8.3090807@att.com>
Date: Tue, 09 Apr 2013 16:24:08 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Murray S. Kucherawy" <superuser@gmail.com>
References: <CAL0qLwaS+4S=1hr+2vi2N-UR+7DxgDsDm11YuPuR1W8X=guRTw@mail.gmail.com>
In-Reply-To: <CAL0qLwaS+4S=1hr+2vi2N-UR+7DxgDsDm11YuPuR1W8X=guRTw@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <tony@att.com>
X-SOURCE-IP: [144.160.20.145]
X-AnalysisOut: [v=2.0 cv=HfejuF48 c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a]
X-AnalysisOut: [=EPwpWi6_Mo4A:10 a=_nfIMGA1H_4A:10 a=SbF1SxizwUEA:10 a=ofM]
X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK]
X-AnalysisOut: [OAAAA:8 a=CHd2X5qwFYwA:10 a=bVie2NgMm5kJ7f8th10A:9 a=wPNLv]
X-AnalysisOut: [fGTeEIA:10]
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-malformed-mail
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2013 20:24:31 -0000

I've provided comments before, and felt that those comments had been
dealt with properly. More comments below.

I think the document should just be published as informational rather
than being parked. If there's interest in the future for working on it
more, that can be an expansion.

    Tony Hansen

On 4/9/2013 3:44 PM, Murray S. Kucherawy wrote:
> Since my co-author and I have been unable to solicit any comments or
> support for continuing to work on the above document for many months
> now, we are going to let it expire at the end of this week absent a
> sudden surge of interest in the near future.  If the working group is
> interested in it again at some later date, we can ressurect it.
>
> For now I'm going to mark it "parked", leaving Salvatore's docket
> slightly lighter.

section 8.7
    This section has a title of eight-bit data, but switches quickly to
the term non-ASCII data.

    But it also has suggestions on how to handle messages with the NUL
character (0x00), which *is* both an ASCII character and is not an
eight-bit character. (Note that the NUL byte (0x00) is spelled NUL in
the ASCII specs, not "null".)

    Should the term "octet" be used instead of "byte"?

    The title should probably reflect its coverage of NUL bytes and
stick with one term, as in

        8.7 NUL Octets and Non-ASCII Data


The document uses 2119 normative language in some places, but not others
where it probably should.


From sm@elandsys.com  Wed Apr 10 01:34:33 2013
Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB0B21F8FE8; Wed, 10 Apr 2013 01:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaTAkEgP2WfG; Wed, 10 Apr 2013 01:34:33 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BECA21F8FDF; Wed, 10 Apr 2013 01:34:32 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.226.234.212]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3A8YIVM021489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Apr 2013 01:34:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365582871; bh=Nu0lSpMWgJhF0PKxIqrPZd7Tgt3yJ7jOUWJ2GIVvCLo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=IyvPfLgxwOkFqCYj4/aaE4I84HObdAODF9baaG0XlBcEDs+c2Tu1+2L32EQjhw6N2 FwR2cUWkqdNAnIohh3b3T07xHAie0ZGXd3q53GpyzvOuKtkQ6hl/U97VTX4UeW6aNv RAGhsb+NKDidnitjrybwD4AiMN2ufSef0DBRpSQs=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1365582871; i=@elandsys.com; bh=Nu0lSpMWgJhF0PKxIqrPZd7Tgt3yJ7jOUWJ2GIVvCLo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1Us48ceKpF22RVeRctjGJ8pJIyyPkxNyXidS10y1OZXVXAQIe6TjDBnAn7AbQlaoh Kz8ikQeiu1r4YpsR8tP2uq3+7RJyYd+7KFZG0vP6B+EUW8uxYWAFJ45yLpY/1Z4l0i 87tQmST4DQVSRizy3c3k5drqPysVAn5IVV9tugdA=
Message-Id: <6.2.5.6.2.20130410010433.0ca8b920@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 10 Apr 2013 01:24:28 -0700
To: "Salvatore D'Antonio" <salvatore.dantonio@uniparthenope.it>, draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <001501ce35be$68c93c00$3a5bb400$@dantonio@uniparthenope.it>
References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> <6.2.5.6.2.20130409084702.0c6104b8@elandnews.com> <001501ce35be$68c93c00$3a5bb400$@dantonio@uniparthenope.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ipfix@ietf.org, iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt> (APPSDIR review)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2013 08:34:34 -0000

Hi Salvatore,
At 00:38 10-04-2013, Salvatore D'Antonio wrote:
>I did not adequately addressed your comment because I thought that the
>guidelines specified in RFC 5226 were sufficient to deal with the issues
>concerning the management of the sub-registry.

Ok.

>I would greatly appreciate if you could provide me with the reference to a
>Draft where documentation and criteria for managing assignments are
>specified so that I may use such Draft as an example.

Section 4.1 of RFC 5226 points to Sections 6 and 7.2 in RFC 3748 as 
an example about Expert Review.  Section 7.1 of RFC 5102 is another 
example.  I suggest discussing the proposed change with the document 
shepherd or the Area Director to see whether it is appropriate.

Regards,
S. Moonesamy  


From stpeter@stpeter.im  Wed Apr 10 05:54:47 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B17621F905C; Wed, 10 Apr 2013 05:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3dD26WSCtlU; Wed, 10 Apr 2013 05:54:44 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB7E21F9733; Wed, 10 Apr 2013 05:54:44 -0700 (PDT)
Received: from [192.168.1.8] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5591940E4B; Wed, 10 Apr 2013 07:04:44 -0600 (MDT)
Message-ID: <5165610C.1020803@stpeter.im>
Date: Wed, 10 Apr 2013 06:54:36 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>,  draft-ietf-tls-multiple-cert-status-extension.all@tools.ietf.org
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: The IESG <iesg@ietf.org>
Subject: [apps-discuss] APPSDIR review of draft-ietf-tls-multiple-cert-status-extension-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2013 12:54:47 -0000

Bert Greevenbosch and I have been selected as the joint Applications
Area Directorate reviewers for this draft (for background on AppsDir,
please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tls-multiple-cert-status-extension-05
Title: The TLS Multiple Certificate Status Request Extension
Reviewers: Bert Greevenbosch and Peter Saint-Andre
Review Date: 10 April 2013
IESG Telechat Date: 2013-04-11
Summary: This draft is almost ready for publication; comments raised
here are for the WG's consideration.

Major Issues:

none

Minor Issues:

(1) Maybe a server can maintain cached OCSP responses, e.g. until after
the "nextUpdate" time has expired. Then the server would be able to use
these cached responses instead of acquiring a new response from the
OCSP-responders. (This mechanism is e.g. defined in [OCSP-MP]). With the
new extension, multiple OCSP-responses from probably different OCSP
servers could be cached. The client needs to verify that each of the
OCSP response is still valid, e.g. that none of the OCSP-responses are
too old.

[OCSP-MP]: OMA Online Certificate Status Protocol (profile of [OCSP]) V
1.0, Open Mobile Alliance, URL:http://www.openmobilealliance.org/

Would some text about cached OCSP responses be appropriate? (Of course
nonces would make caching impossible, as each OCSP responder would need
to sign the new nonce.)

(2) Section 2.2, p.5:

   A zero-length "request_extensions" value means that there are no
   extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not
   valid for the "Extensions" type).

This text was copied from RFC 6066. It seems a bit cryptic, but I
suppose it means that the "request_extensions" field does not exist at
all, e.g. the "OCSPStatusRequest" struct only contains the
"responder_id_list<0..2^16-1>"?

(3) Section 2.2, p.6:

   Note that a server MAY also choose not to send a "CertificateStatus"
   message, even if it has received a "status_request_v2" extension in
   the client hello message and has sent a "status_request_v2" extension
   in the server hello message.

In essence, this says that it is optional for the server to send the
"CertificateStatus" message. What are the types of conditions under
which it is reasonable to not send the "CertificateStatus" message?

(4) Section 2.2, p.7:

   If the client receives a
   "ocsp_response_list" that does not contain a response for one or more
   of the certificates in the completed certificate chain, the client
   SHOULD attempt to validate the certificate using an alternative
   retrieval method, such as downloading the relevant CRL;

Would this allow an attacker to downgrade the security of the
certificate, e.g. by disabling the OCSP response and using a stale CRL?

Maybe a "SHOULD" is not appropriate, but better leave it to the
particular trust model?

(5) Section 3. IANA Considerations. This section mentions a new registry
called "TLS Certificate Status Types", where CertificateStatusType
values should be registered. New values are assigned via IETF Review as
defined in RFC5226.

Should there be specific guidelines/required info for acceptance of new
values for this particular field? If so, state these guidelines/required
info.

Nits:

In Section 2:

   In the OCSPStatusRequest (originally defined by [RFC6066]), the
   "ResponderIDs" provides a list of OCSP responders that the client
   trusts.

- It seems that "ResponderIDs" should be "ResponderID".

Peter & Bert


From dcrocker@bbiw.net  Wed Apr 10 08:00:26 2013
Return-Path: <dcrocker@bbiw.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C8321F983D for <apps-discuss@ietfa.amsl.com>; Wed, 10 Apr 2013 08:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHJ4xNkliwMj for <apps-discuss@ietfa.amsl.com>; Wed, 10 Apr 2013 08:00:23 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2D04821F9844 for <apps-discuss@ietf.org>; Wed, 10 Apr 2013 08:00:23 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3AF0KEC004137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Apr 2013 08:00:20 -0700
Message-ID: <51657E80.8070208@bbiw.net>
Date: Wed, 10 Apr 2013 08:00:16 -0700
From: Dave Crocker <dcrocker@bbiw.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Murray S. Kucherawy" <superuser@gmail.com>, "Gregory N. Shapiro" <gshapiro@sendmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 10 Apr 2013 08:00:21 -0700 (PDT)
Cc: Apps Discuss <apps-discuss@ietf.org>
Subject: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2013 15:00:26 -0000

Review of:    Advice for Safe Handling of Malformed Messages

I-D:          draft-ietf-appsawg-malformed-mail-03

Reviewer:     D. Crocker

Review Date:  10 April 2013


Summary:

       Internet Mail has always been marked by an unfortunate degree of 
regular and permitted non-conformance to its formal specifications.  The 
current draft seeks to categorize and discuss common types of 
non-conformance and to provide some guidance for how it should be 
handled.  The document is explicit in stating that it does not have the 
goal of standardizing this guidance.

      The document is reasonably clear and complete. I believe a 
document like this can provide very helpful guidance for email 
developers and operators.  It would be useful in its current form, but 
could greatly benefit from some modification.

      One major concern, which is easily remedied, is the draft's use of 
normative language.  The document is often unusually careful to use 
qualifying language that precisely limits the scope of the normative 
text to "a module compliant with this memo".  However I think this is 
too subtle for most readers and that the use of normative language 
defeats the stated limitation of not wanting to define a standard. 
Hence I changing all such language and, instead, using language that is 
clearly only modest "advice", such as with:

    *  a common handling is...
    *  it is best to...
    *  it will typically be safe and helpful to...

and so on.



Detailed Comments:


> Abstract
>
>    The email ecosystem has long had a very permissive set of common
>    processing rules in place, despite increasingly rigid standards
>    governing its components, ostensibly to improve the user experience.

      Although Internet mail formats have been precisely defined since 
the 1970s, authoring and handling software often show only mild 
conformance to the specifications.  The distributed and non-interactive 
nature of email has often prompted adjustments to receiving software, to 
handle these variations, rather than trying to gain better conformance 
by senders, since the receiving operator is primarily driven by 
complaining recipient users and has no authority over the sending side 
of the system.


>    The handling of these come at some cost, and various components are

      Processing with such flexibility comes at some cost, since mail 
software is faced with...


>    faced with decisions about whether or not to permit non-conforming
>    messages to continue toward their destinations unaltered, adjust them
>    to conform (possibly at the cost of losing some of the original
>    message), or outright rejecting them.

      A core requirement for interoperability is that both sides to an 
exchange work from the same details and semantics.  By having receivers 
be flexible, beyond the specifications, there can -- and often has been 
-- a good chance that a message will not be fully interoperable.  Worse, 
a well-established pattern of tolerance for variations can sometimes be 
used as an attack vector.


>    This document includes a collection of the best advice available
>    regarding a variety of common malformed mail situations, to be used
>    as implementation guidance.  It must be emphasized, however, that the
>    intent of this document is not to standardize malformations or
>    otherwise encourage their proliferation.  The messages are manifestly
>    malformed, and the code and culture that generates them needs to be
>    fixed.  Therefore, these messages should be rejected outright if at
>    all possible.  Nevertheless, many malformed messages from otherwise
>    legitimate senders are in circulation and will be for some time, and,
>    unfortunately, commercial reality shows that we cannot always simply
>    reject or discard them.  Accordingly, this document presents
>    alternatives for dealing with them in ways that seem to do the least
>    additional harm until the infrastructure is tightened up to match the
>    standards.


>
> 1.  Introduction
>
> 1.1.  The Purpose Of This Work
>
>    The history of email standards, going back to [RFC822] and beyond,

{ here I actually suggest citing RFC 733, since it managed to establish 
the solid foundation, with 822 being a relatively small modification. 
733 was not the first formal standard, but the first had poor adoption. /d}


>    contains a fairly rigid evolution of specifications.  But
>    implementations within that culture have also long had an
>    undercurrent known formally as the robustness principle, but also
>    known informally as Postel's Law: "Be conservative in what you do, be
>    liberal in what you accept from others."

     Jon Postel's directive is often misinterpreted to mean that any 
deviance from a specification is acceptable.  Rather, it was intended 
only to account for legitimate variations in interpretation /within 
specifications, as well as basic transit errors, like bit errors.  Taken 
to its unintended extreme, excessive tolerance would imply that there 
are no limits to the liberties that a sender might take, while presuming 
a burden on a receiver to "correctly" guess at the meaning of any such 
variation.

{BTW, I believe Postel's Law was not the motivating reason for email 
format deviations.  Rather, I think that receiver's were accountable to 
their users -- the recipients -- while having no control over the 
misbehaving senders.  So they/we hacked receiving code when necessary, 
to appease the users. /d }


>    In general, this served the email ecosystem well by allowing a few
>    errors in implementations without obstructing participation in the
>    game.  The proverbial bar was set low.  However, as we have evolved
>    into the current era, some of these lenient stances have begun to
>    expose opportunities that can be exploited by malefactors.  Various
>    email-based applications rely on strong application of these
>    standards for simple security checks, while the very basic building
>    blocks of that infrastructure, intending to be robust, fail utterly
>    to assert those standards.
>
>    This document presents some areas in which the more lenient stances
>    can provide vectors for attack, and then presents the collected
>    wisdom of numerous applications in and around the email ecosystem for
>    dealing with them to mitigate their impact.
>
> 1.2.  Not The Purpose Of This Work
>
>    It is important to understand that this work is not an effort to
>    endorse or standardize certain common malformations.  The code and
>    culture that introduces such messages into the mail stream needs to
>    be repaired, as the security penalty now being paid for this lax
>    processing arguably outweighs the reduction in support costs to end
>    users who are not expected to understand the standards.  However, the
>    reality is that this will not be fixed quickly.
>
>    Given this, it is beneficial to provide implementers with guidance
>    about the safest or most effective way to handle malformed messages
>    when they arrive, taking into consideration the tradeoffs of the
>    choices available especially with respect to how various actors in
>    the email ecosystem respond to such messages in terms of handling,
>    parsing, or rendering to end users.
>
> 1.3.  General Considerations
>
>    Many deviations from message format standards are considered by some
>    receivers to be strong indications that the message is undesirable,
>    i.e., is spam or contains malware.  Such receivers quickly decide
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                 [Page 4]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
>    that the best handling choice is simply to reject or discard the
>    message.  This means malformations caused by innocent
>    misunderstandings or ignorance of proper syntax can cause messages
>    with no ill intent also to fail to be delivered.
>
>    Senders that want to ensure message delivery are best advised to
>    adhere strictly to the relevant standards (including, but not limited
>    to, [MAIL], [MIME], and [DKIM]), as well as observe other industry
>    best practices such as may be published from time to time either by
>    the IETF or independently.
>
> 2.  Document Conventions
>
> 2.1.  Key Words
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [KEYWORDS].  However,
>    they only have that meaning in this document when they are presented
>    entirely in upper case.


{ While the document is clear that its use of normative language is 
meant to apply only to those implementations choosing to conform to this 
document, the document itself says -- appropriately, IMO -- that it is 
not trying to standardize these behaviors.  It's therefore confusing and 
probably counter-productive to use normative language.  I strongly urge 
dropping all such language and, instead, only offering modest "advice" 
with language like:

    *  a common handling is...
    *  it is best to...
    *  it will typically be safe and helpful to...

    and so on.   /d}


> 2.2.  Examples
>
>    Examples of message content include a number within braces at the end
>    of each line.  These are line numbers for use in subsequent
>    discussion, and are not actually part of the message content
>    presented in the example.
>
>    Blank lines are not numbered in the examples.
>
> 3.  Background
>
>    The reader would benefit from reading [EMAIL-ARCH] for some general
>    background about the overall email architecture.  Of particular
>    interest is the Internet Message Format, detailed in [MAIL].
>    Throughout this document, the use of the term "messsage" should be

{ Freud possibly at work for this missspellling? /d}


>    assumed to mean a block of text conforming to the Internet Message
>    Format.
>
> 4.  Internal Representations
>
>    Any agent handling a message could have one or two (or more) distinct

      As an agent parses and processes a message, it might create a 
number of distinct representations for the message.


>    representations of a message it is handling.  One is an internal
>    representation, such as a block of storage used for the header and a
>    block for the body.  These may be sorted, encoded, decoded, etc., as
>    per the needs of that particular module.  The other is the
>    representation that is output to the next agent in the handling
>    chain.  This might be identical to the version that is input to the
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                 [Page 5]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
>    module, or it might have some changes such as added or reordered
>    header fields, body modifications to remove malicious content, etc.
>
>    In some cases, advice is provided only for internal representations.
>    However, there is often occasion to mandate changes to the output as
>    well.

{ What does this last sentence mean?  "Mandate"?  Perhaps what is meant 
is: /d}

      However it is sometimes necessary to make changes between the 
input and output versions, as well.


>
> 5.  Invariate Content

      Invariant {?}


>
>    Experience has shown that it is beneficial to ensure that, from the
>    first analysis agent at ingress into the destination Administrative
>    Management Domain (ADMD; see [EMAIL-ARCH]) to the agent that actually
>    affects delivery to the end user, the message each agent sees is

{ This is an artfully-crafted sentence, but it would be easier to read 
if broken into parts.  Perhaps: /d}

      An especially interesting handling sequence occurs within the 
destination Administrative Management Domain (ADMD; see [EMAIL-ARCH]). 
 From ingress to the ADMD, through the boundary agent, until delivery to 
the end user, it is beneficial to ensure that each agent sees an 
identical form for the message.


>    identical.  Absent this, it can be impossible for different agents in
>    the chain to make assertions about the content that correlate.


      the chain to make consistent assertions about the content.


>    For example, suppose a handling agent records that a message had some
>    specific set of properties at ingress to the ADMD, then permitted it
>    to continue inbound.  Some other agent alters the content for some
>    reason.  The user, on viewing the delivered content, reports the
>    message as abusive.  If the report is based on the set of properties

      message as abuse.  However, report processing often takes place 
at, or close to, the original point of ingress and is likely to be based 
on the set of properties recorded there, rather than at the user's system.


>    recorded at ingress, then the complaint effectively references a
>    message different from what the user saw, which could render the
>    complaint inactionable.  Similarly, a message with properties that a
>    filtering agent might use to reject an abusive message could be
>    allowed to reach the user if an intermediate agent altered the
>    message in a manner that alters one of those properties, thwarting
>    detection of the abuse.

{ awkward sentence structure. d/}


>    Therefore, agents comprising an inbound message processing

      comprising an inbound  -> within an integrated message

{or should this simply say 'within an ADMD'? /d}


>    environment SHOULD ensure that each agent sees the same content, and
>    the message reaches the end user unmodified.  An exception to this is
>    content that is identitfied as certainly harmful, such as some kind
>    of malicious executable software included in the message.

{the 'exception' sentence is far too specific.  There are, no doubt, 
many reasons for deviating from this recommendation.  Simpler, safer and 
non-normative wording would be:  /d}

      environment will simplify operational concerns by ensuring that 
each agent receives the same content -- except for the usual handling 
agent trace information additions -- and that this is what reaches the 
end user, unmodified.  Various policies, such as special handling for 
detected message abuse, will make exceptions appropriate.


> 6.  Mail Submission Agents
>
>    Within the email context, the single most influential component that
>    can reduce the presence of malformed items in the email system is the
>    Mail Submission Agent (MSA).  This is the component that is
>    essentially the interface between end users that create content and
>    the mail stream.

      the Mail Handling Service (MHS) [EMAIL-ARCH]


>    The lax processing described earlier in the document creates a high

{this first sentence is out of place.  the earlier discussion in the 
document established the need for better conformance; it doesn't need to 
be sold here, again. /d}


>    support and security cost overall.  Thus, MSAs MUST evolve to become
>    more strict about enforcement of all relevant email standards,
>    especially [MAIL] and the [MIME] family of documents.
>
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                 [Page 6]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
>    Relay Mail Transport Agents (MTAs) SHOULD also be more strict;

      Relay -> Relaying

{ This pseudo-normative phrasing does nothing helpful, since it isn't 
actually specifying anything.  Modify to something like: /d}

      More strict conformance by relaying MTAs also will be helpful. 
Although


>    although preventing the dissemination of malformed messages is
>    desirable, the rejection of such mail already in transit also has a
>    support cost, namely the creation of a [DSN] that many end users
>    might not understand.
>
> 7.  Line Terminaton
>
>    The only valid line separation sequence in messaging is ASCII 0x0D

      For interoperable Internet Mail messages, the only valid...


>    ("carriage return", or CR) followed by ASCII 0x0A ("line feed", or
>    LF), commonly referred to as CRLF.  Common UNIX user tools, however,
>    typically only use LF for line termination.  This means the protocol
>    has to convert LF to CRLF before transporting a message.

      for internal line termination.  This means that a protocol engine, 
which converts between Unix and Internet Mail formats, has to convert 
between these two end-of-line representations, before transmitting a 
message or after receiving it.


>    Naive implementations can cause messages to be transmitted with a mix

{ These aren't "naive".  They are quite simply broken!  d/}

      Implementations that do not conform to Internet Mail standards 
sometimes cause messages to be transmitted...


>    of line terminations, such as LF everywhere except CRLF only at the
>    end of the message.  According to [SMTP], this means the entire
>    message actually exists on a single line.

{ also RFC 5322! /d}


>    A "naked" CR or LF in a message has no reasonable justification, and

{ this is wrong.  they have legitimate presentation uses, albeit pretty 
archaic at this point.  Better:  /d }

      Within modern Internet Mail it is highly unlikely that an isolated 
CR or LF is valid, in common ASCII text.  Furthermore [MIME]...


>    furthermore [MIME] presents mechanisms for encoding content that
>    actually does need to contain such an unusual character sequence.
>
>    Thus, handling agents MUST treat naked CRs and LFs as CRLFs when
>    interpreting the message.

      Thus, it will typically be safe and helpful to treat a naked CR or 
LF as equivalent to a CRLF, when parsing a message.


> 8.  Header Anomalies
>
>    This section covers common syntactical and semantic anomalies found
>    in headers of messages, and presents preferred mitigations.

      in a message header, and


> 8.1.  Converting Obsolete and Invalid Syntaxes
>
>    There are numerous cases of obsolete header syntaxes that can be
>    applied to confound agents with variable processing.  This section

{ The phrasing of the first sentence sounds as if confounding is a goal. 
  If it's meant that way, say it more clearly.  If it isn't, perhaps:  /d }

      A message using an obsolete header syntax might confound an agent 
that is attempting to be robust in its handling of syntax variations.


>    presents some examples of these.  Messages including them SHOULD be

{ 'of these'?  of which? /d}

{ Why reject this particular set?  What about others, outside these 
examples?  Again, phrase this non-normatively. /d}


>    rejected; where this is not possible, RECOMMENDED internal
>    interpretations are provided.
>
> 8.1.1.  Host-Address Syntax
>
>    The following obsolete syntax:

      The following obsolete syntax that attempts to specify source routing:

{ explain, or perhaps even cite the old ABNF rule for it /d}


>
>        To: <@example.net:fran@example.com>
>
>    should be interpreted as:

      can safely be interpreted as:


>        To: <fran@example.com>
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                 [Page 7]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
> 8.1.2.  Excessive Angle Brackets
>
>    The following over-use of angle brackets, e.g.:
>
>        To: <<<user2@example.org>>>
>
>    should be interpreted as:

      can safely be interpreted as:


>        To: <user2@example.org>
>
> 8.1.3.  Unbalanced Angle Brackets
>
>    The following use of unbalanced angle brackets:
>
>        To: <another@example.net
>        To: second@example.org>
>
>    should be interpreted as:

     can usually be treated as:


>        To: <another@example.net>
>        To: second@example.org
>
> 8.1.4.  Unbalanced Parentheses
>
>    The following use of unbalanced parentheses:
>
>        To: (Testing <fran@example.com>
>        To: Testing) <sam@example.com>
>
>    should be interpreted as:
>
>        To: (Testing) <fran@example.com>
>        To: "Testing)" <sam@example.com>
>
> 8.1.5.  Unbalanced Quotes
>
>    The following use of unbalanced quotation marks:
>
>        To: "Joe <joe@example.com>
>
>    should be interpreted as:
>
>        To: "Joe <joe@example.com>"@example.net

{ WTF??? And why is this a good fixup, especially given concerns about 
display-name attack vectors?  /d}


>    where "example.net" is the domain name or host name of the handling
>    agent making the interpretation.
>
>
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                 [Page 8]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
> 8.2.  Non-Header Lines
>
>    It has been observed that some messages contain a line of text in the

      Some messages contain a line of...


>    header that is not a valid message header field of any kind.  For
>    example:
>
>        From: user@example.com {1}
>        To: userpal@example.net {2}
>        Subject: This is your reminder {3}
>        about the football game tonight {4}
>        Date: Wed, 20 Oct 2010 20:53:35 -0400 {5}
>
>        Don't forget to meet us for the tailgate party! {7}
>
>    The cause of this is typically a bug in a message generator of some
>    kind.  Line {4} was intended to be a continuation of line {3}; it
>    should have been indented by whitespace as set out in Section 2.2.3
>    of [MAIL].
>
>    This anomaly has varying impacts on processing software, depending on
>    the implementation:
>
>    1.  some agents choose to separate the header of the message from the
>        body only at the first empty line (i.e. a CRLF immediately
>        followed by another CRLF);
>
>    2.  some agents assume this anomaly should be interpreted to mean the
>        body starts at line {4}, as the end of the header is assumed by
>        encountering something that is not a valid header field or folded
>        portion thereof;
>
>    3.  some agents assume this should be interpreted as an intended
>        header folding as described above and thus simply append a single
>        space character (ASCII 0x20) and the content of line {4} to that
>        of line {3};
>
>    4.  some agents reject this outright as line {4} is neither a valid
>        header field nor a folded continuation of a header field prior to
>        an empty line.
>
>    This can be exploited if it is known that one message handling agent
>    will take one action while the next agent in the handling chain will
>    take another.  Consider, for example, a message filter that searches
>    message headers for properties indicative of abusive of malicious
>    content that is attached to a Mail Transfer Agent (MTA) implementing
>    option 2 above.  An attacker could craft a message that includes this
>    malformation at a position above the property of interest, knowing
>    the MTA will not consider that content part of the header, and thus
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                 [Page 9]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
>    the MTA will not feed it to the filter, thus avoiding detection.
>    Meanwhile, the Mail User Agent (MUA) which presents the content to an
>    end user, implements option 1 or 3, which has some undesirable
>    effect.
>
>    It should be noted that a few implementations choose option 4 above
>    since any reputable message generation program will get header
>    folding right, and thus anything so blatant as this malformation is
>    likely an error caused by a malefactor.
>
>    The preferred implementation if option 4 above is not employed is to
>    apply the following heuristic when this malformation is detected:
>
>    1.  Search forward for an empty line.  If one is found, then apply
>        option 3 above to the anomalous line, and continue.
>
>    2.  Search forward for another line that appears to be a new header
>        field, i.e., a name followed by a colon.  If one is found, then
>        apply option 3 above to the anomalous line, and continue.
>
> 8.3.  Unusual Spacing
>
>    The following message is valid per [MAIL]:
>
>        From: user@example.com {1}
>        To: userpal@example.net {2}
>        Subject: This is your reminder {3}
>         {4}
>         about the football game tonight {5}
>        Date: Wed, 20 Oct 2010 20:53:35 -0400 {6}
>
>        Don't forget to meet us for the tailgate party! {8}
>
>    Line {4} contains a single whitespace.  The intended result is that
>    lines {3}, {4}, and {5} comprise a single continued header field.
>    However, some agents are aggressive at stripping trailing whitespace,
>    which will cause line {4} to be treated as an empty line, and thus
>    the separator line between header and body.  This can affect header-
>    specific processing algorithms as described in the previous section.
>
>    Ideally, this case simply ought not to be generated.

{This sentence is entirely gratuitous. Replace it with: d/ }

      This example was legal in earlier versions of the Internet Mail 
format standard.

>
>    Message handling agents receiving a message bearing this anomaly MUST
>    behave as if line {4} was not present on the message, and SHOULD emit
>    a version in which line {4} has been removed.

      The best handling of this example is for a message parsing engine 
to behave as if line {4} was not present in the message and for a 
message creation engine to emit the message with line {4} removed,.


>
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                [Page 10]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
> 8.4.  Header Malformations
>
>    There are various malformations that exist.  A common one is

{ The first sentence is pretty obvious: there are always lots of ways to 
screw up. I suggest dropping it and beginning with something like:  /d}

    Among the many possible malformations, a common one is...


>    insertion of whitespace at unusual locations, such as:
>
>        From: user@example.com {1}
>        To: userpal@example.net {2}
>        Subject: This is your reminder {3}
>        MIME-Version : 1.0 {4}
>        Content-Type: text/plain {5}
>        Date: Wed, 20 Oct 2010 20:53:35 -0400 {6}
>
>        Don't forget to meet us for the tailgate party! {8}
>
>    Note the addition of whitespace in line {4} after the header field
>    name but before the colon that separates the name from the value.
>
>    The acceptance grammar of [MAIL] permits that extra whitespace, so it
>    cannot be considered invalid.  However, a consensus of
>    implementations prefers to remove that whitespace.  There is no
>    perceived change to the semantics of the header field being altered
>    as the whitespace is itself semantically meaningless.  Thus, a module
>    compliant with this memo MUST remove all whitespace after the field
>    name but before the colon, and MUST emit that version of that field
>    on output.

      Therefore, it is best to remove all whitespace after the field 
name but before the colon and to emit the field in this modified form.


> 8.5.  Header Field Counts
>
>    Section 3.6 of [MAIL] prescribes specific header field counts for a
>    valid message.  Few agents actually enforce these in the sense that a
>    message whose header contents exceed one or more limits set there are
>    generally allowed to pass; they may add any required fields that are

    ; they typically add any...


>    missing, however.
>
>    Also, few agents that use messages as input, including Mail User
>    Agents (MUAs) that actually display messages to users, verify that
>    the input is valid before proceeding.  Two popular open source
>    filtering programs and two popular Mailing List Management (MLM)

{ I suggest changing 'two' to 'some', since the number might change; 
there's no reason to make this document get out of date for such a minor 
issue. /d }


>    packages examined at the time this document was written select either

{ hence, remove "examined at the time this document was written" /d }


>    the first or last instance of a particular field name, such as From,
>    to decide who sent a message.  Absent enforcement of [MAIL], an

      Absent strict enforcement


>    attacker can craft a message with multiple fields if that attacker
>    knows the filter will make a decision based on one but the user will
>    be shown the other.
>
>    This situation is exacerbated when a claim of message validity is
>    inferred by something like a valid [DKIM] signature.  Such a
>    signature might cover one instance of a constrained field but not
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                [Page 11]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
>    another, and a naive consumer of DKIM's output, not realizing which
>    one was covered by a valid signature, could presume the wrong one was
>    the "good" one.  An MUA, for example could show the first of two From
>    fields as "good" or "safe" while the DKIM signature actually only
>    verified the second.

{ DKIM signatures do not verify addresses outside d=.  While the problem 
you are describing is, of course, real, it's far more complicated than 
you've described here.  Perhaps:  /d }

      when message validity is assessed, such as through enhanced 
authentication methods.  Such methods might cover one instance of a 
constrained field but not another, taking the wrong one as "good" or "safe".


>    Thus, an agent compliant with this specification MUST enact one of
>    the following:

      In attempting to counter this exposure, one of the following can 
be enacted:


>    1.  reject outright or refuse to process further any input message
>        that does not conform to Section 3.6 of [MAIL];
>
>    2.  remove or, in the case of an MUA, refuse to render any instances
>        of a header field whose presence exceeds a limit prescribed in
>        Section 3.6 of [MAIL] when generating its output;
>
>    3.  alter the name of any header field whose presence exceeds a limit
>        prescribed in Section 3.6 of [MAIL] when generating its output so
>        that later agents can produce a consistent result.  Any
>        alteration likely to cause the field to be ignored by downstream
>        agents is acceptable.  A common approach is to prefix the field
>        names with a string such as "BAD-".

{ it would help if there were some rationales or analyses of the 
tradeoffs amongst these kinds of choices, to help the 
implementer/operator decide when to use which.  /d }



> 8.6.  Missing Header Fields
>
>    Similar to the previous section, there are messages seen in the wild
>    that lack certain required header fields.  For example, [MAIL]
>    requires that a From and Date field be present in all messages.

{ I think these aren't 'examples' but constitute the entire list.  If 
there are other required fields that can be classed as 'missing', this 
section should list them.  Also, since Message-ID isn't 'required', the 
phrasing here doesn't quite match what's discussed in the section. Might 
be worth distinguishing "required but missing" vs. "optional but really 
useful and worth synthesizing".  Synthesizing the latter probably isn't 
dangerous.  Synthesizing the former always is... d/}


>
>    When presented with a message lacking these fields, the MTA might
>    perform one of the following:
>
>    1.  Make no changes
>
>    2.  Add an instance of the missing field(s) using synthesized content

      3.  Reject the message


>    Option 2 is RECOMMENDED for handling this case.  Handling agents

{ Wow!  Synthesizing a From: field strikes me as especially dangerous, 
in all cases.  The rationale provided, below, needs to state this and, I 
believe, explain how and why it is worth incurring. The explanation that 
is provided essentially define this hack as an attack vector... /d}


>    SHOULD add these for internal hanlding if they are missing, but MUST
>    NOT add them to the external representation.  The reason for this
>    requirement is that there are some filter modules that would consider
>    the absence of such fields to be a condition warranting special
>    treatment (e.g., rejection), and thus the effectiveness of such
>    modules would be stymied by an upstream filter adding them.
>
>    The synthesized fields SHOULD contain a best guess as to what should
>    have been there; for From, the SMTP MAIL command's address can be
>    used (if not null) or a placeholder address followed by an address
>    literal (e.g., unknown@[192.0.2.1]); for Date, a date extracted from
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                [Page 12]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
>    a Received field is a reasonable choice.
>
>    One other important case to consider is a missing Message-Id field.
>    An MTA that encounters a message missing this field SHOULD synthesize
>    a valid one using techniques described above and add it to the
>    external rpresentation, since many deployed tools use the content of
>    that field as a common unique message reference, so its absence
>    inhibits correlation of message processing.  One possible synthesis
>    would be based on based on an encoding of the current date/time and
>    an internal MTA ID (e.g., queue ID) followed by @ and the fully
>    qualified hostname of the machine synthesizing the header value.  For
>    example:
>
>        tm = gmtime(&now);
>        (void) snprintf(buf, sizeof(buf), "%04d%02d%02d%02d%02d.%s@%s",
>                        tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday,
>                        tm->tm_hour, tm->tm_min, queueID, fqhn);
>
> 8.7.  Eight-Bit Data
>
>    Standards-compliant mail messages do not contain any non-ASCII data
>    without indicating that such content is present by means of published
>    [SMTP] extensions.  Absent that, [MIME] encodings are typically used

Overall, the document sometimes mixes transfer issues with data 
representation (object) issues, in ways that can be confusing.  This 
paragraph is one of those.  It's worth the extra verbosity to label each 
clearly and separately.  So, for example:

      Standards-compliant mail messages that contain non-ASCII data are 
required to self-label this through the use of [MIME].  If the 
representation of the non-ASCII data is in an 8-bit mode (rather than 
special encoding so that it retains a 7-bit base), then this must be 
signaled through the use of [SMTP] extensions.


 >    without indicating that such content is present by means of published
 >    [SMTP] extensions.

>    to convert non-ASCII data to ASCII in a way that can be reversed by
>    other handling agents or end users.
>
>    Non-ASCII data otherwise found in messages can confound code that is
>    used to analyze content.  For example, a null (ASCII 0x00) byte
>    inside a message can cause typical string processing functions to
>    mis-identify the end of a string, which can be exploited to hide
>    malicious content from analysis processes.
>
>    Handling agents MUST reject messages containing null bytes that are
>    not encoded in some standard way, and SHOULD reject other non-ASCII
>    bytes that are similarly not encoded.  If rejection is not done, an
>    ASCII-compatible encoding such as those defined in [MIME] SHOULD be
>    used.

{ Hmmm.  It occurs to me that the document might be helped by an early 
discussion about a/the 'philosophy' that guides choosing whether to 
reject a message versus repair it.  But I don't have any clever text to 
suggest for doing this... /d}


>
> 9.  MIME Anomalies
>
>    [MIME], et seq, define a mechanism of message extensions for

{ perhaps quibbling, but since MIME does a variety of things, including 
this one, I suggest:

      define -> includes


>    providing text in character sets other than ASCII, non-text
>    attachments to messages, multi-part message bodies, and similar
>    facilities.
>
>    Some anomalies with MIME-compliant generation are also common.  This
>    section discusses some of those and presents preferred mitigations.
>
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                [Page 13]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
> 9.1.  Header Field Names
>
>    [MAIL] permits header field names to begin with "--".  This means
>    that a header field name can look like a [MIME] multipart boundary.
>    For example:
>
>      --foo:bar
>
>    This is a legal header field, whose name is "--foo" and whose value
>    is "bar".  Thus, consider this header:
>
>        From: user@example.com {1}
>        To: userpal@example.net {2}
>        Subject: This is your reminder {3}
>        Date: Wed, 20 Oct 2010 20:53:35 -0400 {4}
>        MIME-Version: 1.0 {5}
>        Content-Type: multipart/mixed; boundary="foo:bar" {6}
>        --foo:bar {7}
>        Malicious-Content: muahaha {8}
>
>    One implementation could observe that line {7} announces the
>    beginning of the first MIME part while another considers it a part of
>    the message's header.
>
>    If rejection of such messages cannot be done, agents MUST treat line
>    {7} as part of the message's header block and not a MIME boundary.

{ Under what circumstances can rejection /not/ be done??? And what is 
involved in even detecting that it isn't a mime boundary?  d/ }


>
> 9.2.  Missing MIME-Version Field
>
>    Any message that uses [MIME] constructs is required to have a MIME-
>    Version header field.  Without them, the Content-Type and associated
>    fields have no semantic meaning.

      them -> it


>    It is often observed that a message has complete MIME structure, yet
>    lacks this header field.
>
>    As described at the end of Section 8.2, this is not expected from a

      this -> this omission


>    reputable content generator and is often an indication of mass-
>    produced spam or other undesirable messages.
>
>    Therefore, an agent compliant with this specification MUST internally
>    enact one or more of the following in the absence of a MIME-Version
>    header field:
>
>    1.  Ignore all other MIME-specific fields, even if they are
>        syntactically valid, thus treating the entire message as a
>        single-part message of type text/plain;

{ Offhand, this sounds like a potentially-interesting attack vector.  /d}


>
> Kucherawy & Shapiro      Expires April 12, 2013                [Page 14]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
>    2.  Remove all other MIME-specific fields, even if they are
>        syntactically valid, both internally and when emitting the output
>        version of the message;
>
> 10.  Body Anomalies
>
> 10.1.  Oversized Lines
>
>    A message containing a line of content that exceeds 998 characters
>    plus the line terminator (1000 total) violates Section 2.1.1 of
>    [MAIL].  Some handling agents may not look at content in a single
>    line past the first 998 bytes, providing bad actors an opportunity to
>    hide malicious content.
>
>    There is no specified way to handle such messages, other than to
>    observe that they are non-compliant and reject them, or rewrite the
>    oversized line such that the message is compliant.
>
>    Handling agents MUST take one of the following actions:
>
>    1.  Break such lines into multiple lines at a position that does not
>        change the semantics of the text being thus altered.  For
>        example, breaking an oversized line such that a [URI] then spans
>        two lines could inhibit the proper identification of that URI.
>
>    2.  Rewrite the MIME part (or the entire message if not MIME) that
>        contains the excessively long line using a content encoding that
>        breaks the line in the transmission but would still result in the
>        line being intact on decoding for presentation to the user.  Both
>        of the encodings declared in [MIME] can accomplish this.
>
> 11.  Security Considerations
>
>    The discussions of the anomalies above and their prescribed solutions
>    are themselves security considerations.  The practises enumerated in
>    this memo are generally perceived as attempts to resolve security
>    considerations that already exist rather than introducing new ones.

{ Hmmm.  Whereas I think the document introduces quite a few attack 
vectors that probably aren't discussed in other email specifications. /d}


>
> 12.  IANA Considerations
>
>    This memo contains no actions for IANA.
>
>    [RFC Editor: Please remove this section prior to publication.]
>
> 13.  References
>
>
>
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                [Page 15]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
> 13.1.  Normative References
>
>    [KEYWORDS]    Bradner, S., "Key words for use in RFCs to Indicate
>                  Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>    [MAIL]        Resnick, P., "Internet Message Format", RFC 5322,
>                  October 2008.
>
> 13.2.  Informative References
>
>    [DKIM]        Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
>                  J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
>                  Signatures", RFC 4871, May 2007.
>
>    [DSN]         Moore, K. and G. Vaudreuil, "An Extensible Message
>                  Format for Delivery Status Notifications", RFC 3464,
>                  January 2003.
>
>    [EMAIL-ARCH]  Crocker, D., "Internet Mail Architecture", RFC 5598,
>                  July 2009.
>
>    [MIME]        Freed, N. and N. Borenstein, "Multipurpose Internet
>                  Mail Extensions (MIME) Part One: Format of Internet
>                  Message Bodies", RFC 2045, November 1996.
>
>    [RFC822]      Crocker, D., "Standard for the Format of Internet Text
>                  Messages", RFC 822, August 1982.
>
>    [SMTP]        Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
>                  October 2008.
>
>    [URI]         Berners-Lee, T., Fielding, R., and L. Masinter,
>                  "Uniform Resource Identifier (URI): Generic Syntax",
>                  RFC 3986, January 2005.
>
> Appendix A.  Acknowledgements
>
>    The author wishes to acknowledge the following for their review and
>    constructive criticism of this proposal: Tony Hansen, and Franck
>    Martin
>
> Authors' Addresses
>
>    Murray S. Kucherawy
>
>    EMail: superuser@gmail.com
>
>
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                [Page 16]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
>    Gregory N. Shapiro
>
>    EMail: gshapiro@sendmail.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                [Page 17]
> 

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From dhc@dcrocker.net  Wed Apr 10 08:00:54 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A7021F9819 for <apps-discuss@ietfa.amsl.com>; Wed, 10 Apr 2013 08:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrwnIR65DtdM for <apps-discuss@ietfa.amsl.com>; Wed, 10 Apr 2013 08:00:51 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A79C721F97E5 for <apps-discuss@ietf.org>; Wed, 10 Apr 2013 08:00:51 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3AF0nKm004177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Apr 2013 08:00:49 -0700
Message-ID: <51657E9D.4050900@dcrocker.net>
Date: Wed, 10 Apr 2013 08:00:45 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Murray S. Kucherawy" <superuser@gmail.com>, "Gregory N. Shapiro" <gshapiro@sendmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 10 Apr 2013 08:00:50 -0700 (PDT)
Cc: Apps Discuss <apps-discuss@ietf.org>
Subject: [apps-discuss] Review of: draft-ietf-appsawg-malformed-mail-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2013 15:00:54 -0000

Review of:    Advice for Safe Handling of Malformed Messages

I-D:          draft-ietf-appsawg-malformed-mail-03

Reviewer:     D. Crocker

Review Date:  10 April 2013


Summary:

       Internet Mail has always been marked by an unfortunate degree of 
regular and permitted non-conformance to its formal specifications.  The 
current draft seeks to categorize and discuss common types of 
non-conformance and to provide some guidance for how it should be 
handled.  The document is explicit in stating that it does not have the 
goal of standardizing this guidance.

      The document is reasonably clear and complete. I believe a 
document like this can provide very helpful guidance for email 
developers and operators.  It would be useful in its current form, but 
could greatly benefit from some modification.

      One major concern, which is easily remedied, is the draft's use of 
normative language.  The document is often unusually careful to use 
qualifying language that precisely limits the scope of the normative 
text to "a module compliant with this memo".  However I think this is 
too subtle for most readers and that the use of normative language 
defeats the stated limitation of not wanting to define a standard. Hence 
I changing all such language and, instead, using language that is 
clearly only modest "advice", such as with:

    *  a common handling is...
    *  it is best to...
    *  it will typically be safe and helpful to...

and so on.



Detailed Comments:


> Abstract
>
>    The email ecosystem has long had a very permissive set of common
>    processing rules in place, despite increasingly rigid standards
>    governing its components, ostensibly to improve the user experience.

      Although Internet mail formats have been precisely defined since 
the 1970s, authoring and handling software often show only mild 
conformance to the specifications.  The distributed and non-interactive 
nature of email has often prompted adjustments to receiving software, to 
handle these variations, rather than trying to gain better conformance 
by senders, since the receiving operator is primarily driven by 
complaining recipient users and has no authority over the sending side 
of the system.


>    The handling of these come at some cost, and various components are

      Processing with such flexibility comes at some cost, since mail 
software is faced with...


>    faced with decisions about whether or not to permit non-conforming
>    messages to continue toward their destinations unaltered, adjust them
>    to conform (possibly at the cost of losing some of the original
>    message), or outright rejecting them.

      A core requirement for interoperability is that both sides to an 
exchange work from the same details and semantics.  By having receivers 
be flexible, beyond the specifications, there can -- and often has been 
-- a good chance that a message will not be fully interoperable.  Worse, 
a well-established pattern of tolerance for variations can sometimes be 
used as an attack vector.


>    This document includes a collection of the best advice available
>    regarding a variety of common malformed mail situations, to be used
>    as implementation guidance.  It must be emphasized, however, that the
>    intent of this document is not to standardize malformations or
>    otherwise encourage their proliferation.  The messages are manifestly
>    malformed, and the code and culture that generates them needs to be
>    fixed.  Therefore, these messages should be rejected outright if at
>    all possible.  Nevertheless, many malformed messages from otherwise
>    legitimate senders are in circulation and will be for some time, and,
>    unfortunately, commercial reality shows that we cannot always simply
>    reject or discard them.  Accordingly, this document presents
>    alternatives for dealing with them in ways that seem to do the least
>    additional harm until the infrastructure is tightened up to match the
>    standards.


>
> 1.  Introduction
>
> 1.1.  The Purpose Of This Work
>
>    The history of email standards, going back to [RFC822] and beyond,

{ here I actually suggest citing RFC 733, since it managed to establish 
the solid foundation, with 822 being a relatively small modification. 
733 was not the first formal standard, but the first had poor adoption. /d}


>    contains a fairly rigid evolution of specifications.  But
>    implementations within that culture have also long had an
>    undercurrent known formally as the robustness principle, but also
>    known informally as Postel's Law: "Be conservative in what you do, be
>    liberal in what you accept from others."

     Jon Postel's directive is often misinterpreted to mean that any 
deviance from a specification is acceptable.  Rather, it was intended 
only to account for legitimate variations in interpretation /within 
specifications, as well as basic transit errors, like bit errors.  Taken 
to its unintended extreme, excessive tolerance would imply that there 
are no limits to the liberties that a sender might take, while presuming 
a burden on a receiver to "correctly" guess at the meaning of any such 
variation.

{BTW, I believe Postel's Law was not the motivating reason for email 
format deviations.  Rather, I think that receiver's were accountable to 
their users -- the recipients -- while having no control over the 
misbehaving senders.  So they/we hacked receiving code when necessary, 
to appease the users. /d }


>    In general, this served the email ecosystem well by allowing a few
>    errors in implementations without obstructing participation in the
>    game.  The proverbial bar was set low.  However, as we have evolved
>    into the current era, some of these lenient stances have begun to
>    expose opportunities that can be exploited by malefactors.  Various
>    email-based applications rely on strong application of these
>    standards for simple security checks, while the very basic building
>    blocks of that infrastructure, intending to be robust, fail utterly
>    to assert those standards.
>
>    This document presents some areas in which the more lenient stances
>    can provide vectors for attack, and then presents the collected
>    wisdom of numerous applications in and around the email ecosystem for
>    dealing with them to mitigate their impact.
>
> 1.2.  Not The Purpose Of This Work
>
>    It is important to understand that this work is not an effort to
>    endorse or standardize certain common malformations.  The code and
>    culture that introduces such messages into the mail stream needs to
>    be repaired, as the security penalty now being paid for this lax
>    processing arguably outweighs the reduction in support costs to end
>    users who are not expected to understand the standards.  However, the
>    reality is that this will not be fixed quickly.
>
>    Given this, it is beneficial to provide implementers with guidance
>    about the safest or most effective way to handle malformed messages
>    when they arrive, taking into consideration the tradeoffs of the
>    choices available especially with respect to how various actors in
>    the email ecosystem respond to such messages in terms of handling,
>    parsing, or rendering to end users.
>
> 1.3.  General Considerations
>
>    Many deviations from message format standards are considered by some
>    receivers to be strong indications that the message is undesirable,
>    i.e., is spam or contains malware.  Such receivers quickly decide
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                 [Page 4]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
>    that the best handling choice is simply to reject or discard the
>    message.  This means malformations caused by innocent
>    misunderstandings or ignorance of proper syntax can cause messages
>    with no ill intent also to fail to be delivered.
>
>    Senders that want to ensure message delivery are best advised to
>    adhere strictly to the relevant standards (including, but not limited
>    to, [MAIL], [MIME], and [DKIM]), as well as observe other industry
>    best practices such as may be published from time to time either by
>    the IETF or independently.
>
> 2.  Document Conventions
>
> 2.1.  Key Words
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [KEYWORDS].  However,
>    they only have that meaning in this document when they are presented
>    entirely in upper case.


{ While the document is clear that its use of normative language is 
meant to apply only to those implementations choosing to conform to this 
document, the document itself says -- appropriately, IMO -- that it is 
not trying to standardize these behaviors.  It's therefore confusing and 
probably counter-productive to use normative language.  I strongly urge 
dropping all such language and, instead, only offering modest "advice" 
with language like:

    *  a common handling is...
    *  it is best to...
    *  it will typically be safe and helpful to...

    and so on.   /d}


> 2.2.  Examples
>
>    Examples of message content include a number within braces at the end
>    of each line.  These are line numbers for use in subsequent
>    discussion, and are not actually part of the message content
>    presented in the example.
>
>    Blank lines are not numbered in the examples.
>
> 3.  Background
>
>    The reader would benefit from reading [EMAIL-ARCH] for some general
>    background about the overall email architecture.  Of particular
>    interest is the Internet Message Format, detailed in [MAIL].
>    Throughout this document, the use of the term "messsage" should be

{ Freud possibly at work for this missspellling? /d}


>    assumed to mean a block of text conforming to the Internet Message
>    Format.
>
> 4.  Internal Representations
>
>    Any agent handling a message could have one or two (or more) distinct

      As an agent parses and processes a message, it might create a 
number of distinct representations for the message.


>    representations of a message it is handling.  One is an internal
>    representation, such as a block of storage used for the header and a
>    block for the body.  These may be sorted, encoded, decoded, etc., as
>    per the needs of that particular module.  The other is the
>    representation that is output to the next agent in the handling
>    chain.  This might be identical to the version that is input to the
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                 [Page 5]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
>    module, or it might have some changes such as added or reordered
>    header fields, body modifications to remove malicious content, etc.
>
>    In some cases, advice is provided only for internal representations.
>    However, there is often occasion to mandate changes to the output as
>    well.

{ What does this last sentence mean?  "Mandate"?  Perhaps what is meant 
is: /d}

      However it is sometimes necessary to make changes between the 
input and output versions, as well.


>
> 5.  Invariate Content

      Invariant {?}


>
>    Experience has shown that it is beneficial to ensure that, from the
>    first analysis agent at ingress into the destination Administrative
>    Management Domain (ADMD; see [EMAIL-ARCH]) to the agent that actually
>    affects delivery to the end user, the message each agent sees is

{ This is an artfully-crafted sentence, but it would be easier to read 
if broken into parts.  Perhaps: /d}

      An especially interesting handling sequence occurs within the 
destination Administrative Management Domain (ADMD; see [EMAIL-ARCH]). 
 From ingress to the ADMD, through the boundary agent, until delivery to 
the end user, it is beneficial to ensure that each agent sees an 
identical form for the message.


>    identical.  Absent this, it can be impossible for different agents in
>    the chain to make assertions about the content that correlate.


      the chain to make consistent assertions about the content.


>    For example, suppose a handling agent records that a message had some
>    specific set of properties at ingress to the ADMD, then permitted it
>    to continue inbound.  Some other agent alters the content for some
>    reason.  The user, on viewing the delivered content, reports the
>    message as abusive.  If the report is based on the set of properties

      message as abuse.  However, report processing often takes place 
at, or close to, the original point of ingress and is likely to be based 
on the set of properties recorded there, rather than at the user's system.


>    recorded at ingress, then the complaint effectively references a
>    message different from what the user saw, which could render the
>    complaint inactionable.  Similarly, a message with properties that a
>    filtering agent might use to reject an abusive message could be
>    allowed to reach the user if an intermediate agent altered the
>    message in a manner that alters one of those properties, thwarting
>    detection of the abuse.

{ awkward sentence structure. d/}


>    Therefore, agents comprising an inbound message processing

      comprising an inbound  -> within an integrated message

{or should this simply say 'within an ADMD'? /d}


>    environment SHOULD ensure that each agent sees the same content, and
>    the message reaches the end user unmodified.  An exception to this is
>    content that is identitfied as certainly harmful, such as some kind
>    of malicious executable software included in the message.

{the 'exception' sentence is far too specific.  There are, no doubt, 
many reasons for deviating from this recommendation.  Simpler, safer and 
non-normative wording would be:  /d}

      environment will simplify operational concerns by ensuring that 
each agent receives the same content -- except for the usual handling 
agent trace information additions -- and that this is what reaches the 
end user, unmodified.  Various policies, such as special handling for 
detected message abuse, will make exceptions appropriate.


> 6.  Mail Submission Agents
>
>    Within the email context, the single most influential component that
>    can reduce the presence of malformed items in the email system is the
>    Mail Submission Agent (MSA).  This is the component that is
>    essentially the interface between end users that create content and
>    the mail stream.

      the Mail Handling Service (MHS) [EMAIL-ARCH]


>    The lax processing described earlier in the document creates a high

{this first sentence is out of place.  the earlier discussion in the 
document established the need for better conformance; it doesn't need to 
be sold here, again. /d}


>    support and security cost overall.  Thus, MSAs MUST evolve to become
>    more strict about enforcement of all relevant email standards,
>    especially [MAIL] and the [MIME] family of documents.
>
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                 [Page 6]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
>    Relay Mail Transport Agents (MTAs) SHOULD also be more strict;

      Relay -> Relaying

{ This pseudo-normative phrasing does nothing helpful, since it isn't 
actually specifying anything.  Modify to something like: /d}

      More strict conformance by relaying MTAs also will be helpful. 
Although


>    although preventing the dissemination of malformed messages is
>    desirable, the rejection of such mail already in transit also has a
>    support cost, namely the creation of a [DSN] that many end users
>    might not understand.
>
> 7.  Line Terminaton
>
>    The only valid line separation sequence in messaging is ASCII 0x0D

      For interoperable Internet Mail messages, the only valid...


>    ("carriage return", or CR) followed by ASCII 0x0A ("line feed", or
>    LF), commonly referred to as CRLF.  Common UNIX user tools, however,
>    typically only use LF for line termination.  This means the protocol
>    has to convert LF to CRLF before transporting a message.

      for internal line termination.  This means that a protocol engine, 
which converts between Unix and Internet Mail formats, has to convert 
between these two end-of-line representations, before transmitting a 
message or after receiving it.


>    Naive implementations can cause messages to be transmitted with a mix

{ These aren't "naive".  They are quite simply broken!  d/}

      Implementations that do not conform to Internet Mail standards 
sometimes cause messages to be transmitted...


>    of line terminations, such as LF everywhere except CRLF only at the
>    end of the message.  According to [SMTP], this means the entire
>    message actually exists on a single line.

{ also RFC 5322! /d}


>    A "naked" CR or LF in a message has no reasonable justification, and

{ this is wrong.  they have legitimate presentation uses, albeit pretty 
archaic at this point.  Better:  /d }

      Within modern Internet Mail it is highly unlikely that an isolated 
CR or LF is valid, in common ASCII text.  Furthermore [MIME]...


>    furthermore [MIME] presents mechanisms for encoding content that
>    actually does need to contain such an unusual character sequence.
>
>    Thus, handling agents MUST treat naked CRs and LFs as CRLFs when
>    interpreting the message.

      Thus, it will typically be safe and helpful to treat a naked CR or 
LF as equivalent to a CRLF, when parsing a message.


> 8.  Header Anomalies
>
>    This section covers common syntactical and semantic anomalies found
>    in headers of messages, and presents preferred mitigations.

      in a message header, and


> 8.1.  Converting Obsolete and Invalid Syntaxes
>
>    There are numerous cases of obsolete header syntaxes that can be
>    applied to confound agents with variable processing.  This section

{ The phrasing of the first sentence sounds as if confounding is a goal. 
  If it's meant that way, say it more clearly.  If it isn't, perhaps:  /d }

      A message using an obsolete header syntax might confound an agent 
that is attempting to be robust in its handling of syntax variations.


>    presents some examples of these.  Messages including them SHOULD be

{ 'of these'?  of which? /d}

{ Why reject this particular set?  What about others, outside these 
examples?  Again, phrase this non-normatively. /d}


>    rejected; where this is not possible, RECOMMENDED internal
>    interpretations are provided.
>
> 8.1.1.  Host-Address Syntax
>
>    The following obsolete syntax:

      The following obsolete syntax that attempts to specify source routing:

{ explain, or perhaps even cite the old ABNF rule for it /d}


>
>        To: <@example.net:fran@example.com>
>
>    should be interpreted as:

      can safely be interpreted as:


>        To: <fran@example.com>
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                 [Page 7]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
> 8.1.2.  Excessive Angle Brackets
>
>    The following over-use of angle brackets, e.g.:
>
>        To: <<<user2@example.org>>>
>
>    should be interpreted as:

      can safely be interpreted as:


>        To: <user2@example.org>
>
> 8.1.3.  Unbalanced Angle Brackets
>
>    The following use of unbalanced angle brackets:
>
>        To: <another@example.net
>        To: second@example.org>
>
>    should be interpreted as:

     can usually be treated as:


>        To: <another@example.net>
>        To: second@example.org
>
> 8.1.4.  Unbalanced Parentheses
>
>    The following use of unbalanced parentheses:
>
>        To: (Testing <fran@example.com>
>        To: Testing) <sam@example.com>
>
>    should be interpreted as:
>
>        To: (Testing) <fran@example.com>
>        To: "Testing)" <sam@example.com>
>
> 8.1.5.  Unbalanced Quotes
>
>    The following use of unbalanced quotation marks:
>
>        To: "Joe <joe@example.com>
>
>    should be interpreted as:
>
>        To: "Joe <joe@example.com>"@example.net

{ WTF??? And why is this a good fixup, especially given concerns about 
display-name attack vectors?  /d}


>    where "example.net" is the domain name or host name of the handling
>    agent making the interpretation.
>
>
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                 [Page 8]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
> 8.2.  Non-Header Lines
>
>    It has been observed that some messages contain a line of text in the

      Some messages contain a line of...


>    header that is not a valid message header field of any kind.  For
>    example:
>
>        From: user@example.com {1}
>        To: userpal@example.net {2}
>        Subject: This is your reminder {3}
>        about the football game tonight {4}
>        Date: Wed, 20 Oct 2010 20:53:35 -0400 {5}
>
>        Don't forget to meet us for the tailgate party! {7}
>
>    The cause of this is typically a bug in a message generator of some
>    kind.  Line {4} was intended to be a continuation of line {3}; it
>    should have been indented by whitespace as set out in Section 2.2.3
>    of [MAIL].
>
>    This anomaly has varying impacts on processing software, depending on
>    the implementation:
>
>    1.  some agents choose to separate the header of the message from the
>        body only at the first empty line (i.e. a CRLF immediately
>        followed by another CRLF);
>
>    2.  some agents assume this anomaly should be interpreted to mean the
>        body starts at line {4}, as the end of the header is assumed by
>        encountering something that is not a valid header field or folded
>        portion thereof;
>
>    3.  some agents assume this should be interpreted as an intended
>        header folding as described above and thus simply append a single
>        space character (ASCII 0x20) and the content of line {4} to that
>        of line {3};
>
>    4.  some agents reject this outright as line {4} is neither a valid
>        header field nor a folded continuation of a header field prior to
>        an empty line.
>
>    This can be exploited if it is known that one message handling agent
>    will take one action while the next agent in the handling chain will
>    take another.  Consider, for example, a message filter that searches
>    message headers for properties indicative of abusive of malicious
>    content that is attached to a Mail Transfer Agent (MTA) implementing
>    option 2 above.  An attacker could craft a message that includes this
>    malformation at a position above the property of interest, knowing
>    the MTA will not consider that content part of the header, and thus
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                 [Page 9]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
>    the MTA will not feed it to the filter, thus avoiding detection.
>    Meanwhile, the Mail User Agent (MUA) which presents the content to an
>    end user, implements option 1 or 3, which has some undesirable
>    effect.
>
>    It should be noted that a few implementations choose option 4 above
>    since any reputable message generation program will get header
>    folding right, and thus anything so blatant as this malformation is
>    likely an error caused by a malefactor.
>
>    The preferred implementation if option 4 above is not employed is to
>    apply the following heuristic when this malformation is detected:
>
>    1.  Search forward for an empty line.  If one is found, then apply
>        option 3 above to the anomalous line, and continue.
>
>    2.  Search forward for another line that appears to be a new header
>        field, i.e., a name followed by a colon.  If one is found, then
>        apply option 3 above to the anomalous line, and continue.
>
> 8.3.  Unusual Spacing
>
>    The following message is valid per [MAIL]:
>
>        From: user@example.com {1}
>        To: userpal@example.net {2}
>        Subject: This is your reminder {3}
>         {4}
>         about the football game tonight {5}
>        Date: Wed, 20 Oct 2010 20:53:35 -0400 {6}
>
>        Don't forget to meet us for the tailgate party! {8}
>
>    Line {4} contains a single whitespace.  The intended result is that
>    lines {3}, {4}, and {5} comprise a single continued header field.
>    However, some agents are aggressive at stripping trailing whitespace,
>    which will cause line {4} to be treated as an empty line, and thus
>    the separator line between header and body.  This can affect header-
>    specific processing algorithms as described in the previous section.
>
>    Ideally, this case simply ought not to be generated.

{This sentence is entirely gratuitous. Replace it with: d/ }

      This example was legal in earlier versions of the Internet Mail 
format standard.

>
>    Message handling agents receiving a message bearing this anomaly MUST
>    behave as if line {4} was not present on the message, and SHOULD emit
>    a version in which line {4} has been removed.

      The best handling of this example is for a message parsing engine 
to behave as if line {4} was not present in the message and for a 
message creation engine to emit the message with line {4} removed,.


>
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                [Page 10]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
> 8.4.  Header Malformations
>
>    There are various malformations that exist.  A common one is

{ The first sentence is pretty obvious: there are always lots of ways to 
screw up. I suggest dropping it and beginning with something like:  /d}

    Among the many possible malformations, a common one is...


>    insertion of whitespace at unusual locations, such as:
>
>        From: user@example.com {1}
>        To: userpal@example.net {2}
>        Subject: This is your reminder {3}
>        MIME-Version : 1.0 {4}
>        Content-Type: text/plain {5}
>        Date: Wed, 20 Oct 2010 20:53:35 -0400 {6}
>
>        Don't forget to meet us for the tailgate party! {8}
>
>    Note the addition of whitespace in line {4} after the header field
>    name but before the colon that separates the name from the value.
>
>    The acceptance grammar of [MAIL] permits that extra whitespace, so it
>    cannot be considered invalid.  However, a consensus of
>    implementations prefers to remove that whitespace.  There is no
>    perceived change to the semantics of the header field being altered
>    as the whitespace is itself semantically meaningless.  Thus, a module
>    compliant with this memo MUST remove all whitespace after the field
>    name but before the colon, and MUST emit that version of that field
>    on output.

      Therefore, it is best to remove all whitespace after the field 
name but before the colon and to emit the field in this modified form.


> 8.5.  Header Field Counts
>
>    Section 3.6 of [MAIL] prescribes specific header field counts for a
>    valid message.  Few agents actually enforce these in the sense that a
>    message whose header contents exceed one or more limits set there are
>    generally allowed to pass; they may add any required fields that are

    ; they typically add any...


>    missing, however.
>
>    Also, few agents that use messages as input, including Mail User
>    Agents (MUAs) that actually display messages to users, verify that
>    the input is valid before proceeding.  Two popular open source
>    filtering programs and two popular Mailing List Management (MLM)

{ I suggest changing 'two' to 'some', since the number might change; 
there's no reason to make this document get out of date for such a minor 
issue. /d }


>    packages examined at the time this document was written select either

{ hence, remove "examined at the time this document was written" /d }


>    the first or last instance of a particular field name, such as From,
>    to decide who sent a message.  Absent enforcement of [MAIL], an

      Absent strict enforcement


>    attacker can craft a message with multiple fields if that attacker
>    knows the filter will make a decision based on one but the user will
>    be shown the other.
>
>    This situation is exacerbated when a claim of message validity is
>    inferred by something like a valid [DKIM] signature.  Such a
>    signature might cover one instance of a constrained field but not
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                [Page 11]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
>    another, and a naive consumer of DKIM's output, not realizing which
>    one was covered by a valid signature, could presume the wrong one was
>    the "good" one.  An MUA, for example could show the first of two From
>    fields as "good" or "safe" while the DKIM signature actually only
>    verified the second.

{ DKIM signatures do not verify addresses outside d=.  While the problem 
you are describing is, of course, real, it's far more complicated than 
you've described here.  Perhaps:  /d }

      when message validity is assessed, such as through enhanced 
authentication methods.  Such methods might cover one instance of a 
constrained field but not another, taking the wrong one as "good" or "safe".


>    Thus, an agent compliant with this specification MUST enact one of
>    the following:

      In attempting to counter this exposure, one of the following can 
be enacted:


>    1.  reject outright or refuse to process further any input message
>        that does not conform to Section 3.6 of [MAIL];
>
>    2.  remove or, in the case of an MUA, refuse to render any instances
>        of a header field whose presence exceeds a limit prescribed in
>        Section 3.6 of [MAIL] when generating its output;
>
>    3.  alter the name of any header field whose presence exceeds a limit
>        prescribed in Section 3.6 of [MAIL] when generating its output so
>        that later agents can produce a consistent result.  Any
>        alteration likely to cause the field to be ignored by downstream
>        agents is acceptable.  A common approach is to prefix the field
>        names with a string such as "BAD-".

{ it would help if there were some rationales or analyses of the 
tradeoffs amongst these kinds of choices, to help the 
implementer/operator decide when to use which.  /d }



> 8.6.  Missing Header Fields
>
>    Similar to the previous section, there are messages seen in the wild
>    that lack certain required header fields.  For example, [MAIL]
>    requires that a From and Date field be present in all messages.

{ I think these aren't 'examples' but constitute the entire list.  If 
there are other required fields that can be classed as 'missing', this 
section should list them.  Also, since Message-ID isn't 'required', the 
phrasing here doesn't quite match what's discussed in the section. Might 
be worth distinguishing "required but missing" vs. "optional but really 
useful and worth synthesizing".  Synthesizing the latter probably isn't 
dangerous.  Synthesizing the former always is... d/}


>
>    When presented with a message lacking these fields, the MTA might
>    perform one of the following:
>
>    1.  Make no changes
>
>    2.  Add an instance of the missing field(s) using synthesized content

      3.  Reject the message


>    Option 2 is RECOMMENDED for handling this case.  Handling agents

{ Wow!  Synthesizing a From: field strikes me as especially dangerous, 
in all cases.  The rationale provided, below, needs to state this and, I 
believe, explain how and why it is worth incurring. The explanation that 
is provided essentially define this hack as an attack vector... /d}


>    SHOULD add these for internal hanlding if they are missing, but MUST
>    NOT add them to the external representation.  The reason for this
>    requirement is that there are some filter modules that would consider
>    the absence of such fields to be a condition warranting special
>    treatment (e.g., rejection), and thus the effectiveness of such
>    modules would be stymied by an upstream filter adding them.
>
>    The synthesized fields SHOULD contain a best guess as to what should
>    have been there; for From, the SMTP MAIL command's address can be
>    used (if not null) or a placeholder address followed by an address
>    literal (e.g., unknown@[192.0.2.1]); for Date, a date extracted from
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                [Page 12]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
>    a Received field is a reasonable choice.
>
>    One other important case to consider is a missing Message-Id field.
>    An MTA that encounters a message missing this field SHOULD synthesize
>    a valid one using techniques described above and add it to the
>    external rpresentation, since many deployed tools use the content of
>    that field as a common unique message reference, so its absence
>    inhibits correlation of message processing.  One possible synthesis
>    would be based on based on an encoding of the current date/time and
>    an internal MTA ID (e.g., queue ID) followed by @ and the fully
>    qualified hostname of the machine synthesizing the header value.  For
>    example:
>
>        tm = gmtime(&now);
>        (void) snprintf(buf, sizeof(buf), "%04d%02d%02d%02d%02d.%s@%s",
>                        tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday,
>                        tm->tm_hour, tm->tm_min, queueID, fqhn);
>
> 8.7.  Eight-Bit Data
>
>    Standards-compliant mail messages do not contain any non-ASCII data
>    without indicating that such content is present by means of published
>    [SMTP] extensions.  Absent that, [MIME] encodings are typically used

Overall, the document sometimes mixes transfer issues with data 
representation (object) issues, in ways that can be confusing.  This 
paragraph is one of those.  It's worth the extra verbosity to label each 
clearly and separately.  So, for example:

      Standards-compliant mail messages that contain non-ASCII data are 
required to self-label this through the use of [MIME].  If the 
representation of the non-ASCII data is in an 8-bit mode (rather than 
special encoding so that it retains a 7-bit base), then this must be 
signaled through the use of [SMTP] extensions.


>    without indicating that such content is present by means of published
>    [SMTP] extensions.

>    to convert non-ASCII data to ASCII in a way that can be reversed by
>    other handling agents or end users.
>
>    Non-ASCII data otherwise found in messages can confound code that is
>    used to analyze content.  For example, a null (ASCII 0x00) byte
>    inside a message can cause typical string processing functions to
>    mis-identify the end of a string, which can be exploited to hide
>    malicious content from analysis processes.
>
>    Handling agents MUST reject messages containing null bytes that are
>    not encoded in some standard way, and SHOULD reject other non-ASCII
>    bytes that are similarly not encoded.  If rejection is not done, an
>    ASCII-compatible encoding such as those defined in [MIME] SHOULD be
>    used.

{ Hmmm.  It occurs to me that the document might be helped by an early 
discussion about a/the 'philosophy' that guides choosing whether to 
reject a message versus repair it.  But I don't have any clever text to 
suggest for doing this... /d}


>
> 9.  MIME Anomalies
>
>    [MIME], et seq, define a mechanism of message extensions for

{ perhaps quibbling, but since MIME does a variety of things, including 
this one, I suggest:

      define -> includes


>    providing text in character sets other than ASCII, non-text
>    attachments to messages, multi-part message bodies, and similar
>    facilities.
>
>    Some anomalies with MIME-compliant generation are also common.  This
>    section discusses some of those and presents preferred mitigations.
>
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                [Page 13]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
> 9.1.  Header Field Names
>
>    [MAIL] permits header field names to begin with "--".  This means
>    that a header field name can look like a [MIME] multipart boundary.
>    For example:
>
>      --foo:bar
>
>    This is a legal header field, whose name is "--foo" and whose value
>    is "bar".  Thus, consider this header:
>
>        From: user@example.com {1}
>        To: userpal@example.net {2}
>        Subject: This is your reminder {3}
>        Date: Wed, 20 Oct 2010 20:53:35 -0400 {4}
>        MIME-Version: 1.0 {5}
>        Content-Type: multipart/mixed; boundary="foo:bar" {6}
>        --foo:bar {7}
>        Malicious-Content: muahaha {8}
>
>    One implementation could observe that line {7} announces the
>    beginning of the first MIME part while another considers it a part of
>    the message's header.
>
>    If rejection of such messages cannot be done, agents MUST treat line
>    {7} as part of the message's header block and not a MIME boundary.

{ Under what circumstances can rejection /not/ be done??? And what is 
involved in even detecting that it isn't a mime boundary?  d/ }


>
> 9.2.  Missing MIME-Version Field
>
>    Any message that uses [MIME] constructs is required to have a MIME-
>    Version header field.  Without them, the Content-Type and associated
>    fields have no semantic meaning.

      them -> it


>    It is often observed that a message has complete MIME structure, yet
>    lacks this header field.
>
>    As described at the end of Section 8.2, this is not expected from a

      this -> this omission


>    reputable content generator and is often an indication of mass-
>    produced spam or other undesirable messages.
>
>    Therefore, an agent compliant with this specification MUST internally
>    enact one or more of the following in the absence of a MIME-Version
>    header field:
>
>    1.  Ignore all other MIME-specific fields, even if they are
>        syntactically valid, thus treating the entire message as a
>        single-part message of type text/plain;

{ Offhand, this sounds like a potentially-interesting attack vector.  /d}


>
> Kucherawy & Shapiro      Expires April 12, 2013                [Page 14]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
>    2.  Remove all other MIME-specific fields, even if they are
>        syntactically valid, both internally and when emitting the output
>        version of the message;
>
> 10.  Body Anomalies
>
> 10.1.  Oversized Lines
>
>    A message containing a line of content that exceeds 998 characters
>    plus the line terminator (1000 total) violates Section 2.1.1 of
>    [MAIL].  Some handling agents may not look at content in a single
>    line past the first 998 bytes, providing bad actors an opportunity to
>    hide malicious content.
>
>    There is no specified way to handle such messages, other than to
>    observe that they are non-compliant and reject them, or rewrite the
>    oversized line such that the message is compliant.
>
>    Handling agents MUST take one of the following actions:
>
>    1.  Break such lines into multiple lines at a position that does not
>        change the semantics of the text being thus altered.  For
>        example, breaking an oversized line such that a [URI] then spans
>        two lines could inhibit the proper identification of that URI.
>
>    2.  Rewrite the MIME part (or the entire message if not MIME) that
>        contains the excessively long line using a content encoding that
>        breaks the line in the transmission but would still result in the
>        line being intact on decoding for presentation to the user.  Both
>        of the encodings declared in [MIME] can accomplish this.
>
> 11.  Security Considerations
>
>    The discussions of the anomalies above and their prescribed solutions
>    are themselves security considerations.  The practises enumerated in
>    this memo are generally perceived as attempts to resolve security
>    considerations that already exist rather than introducing new ones.

{ Hmmm.  Whereas I think the document introduces quite a few attack 
vectors that probably aren't discussed in other email specifications. /d}


>
> 12.  IANA Considerations
>
>    This memo contains no actions for IANA.
>
>    [RFC Editor: Please remove this section prior to publication.]
>
> 13.  References
>
>
>
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                [Page 15]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
> 13.1.  Normative References
>
>    [KEYWORDS]    Bradner, S., "Key words for use in RFCs to Indicate
>                  Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>    [MAIL]        Resnick, P., "Internet Message Format", RFC 5322,
>                  October 2008.
>
> 13.2.  Informative References
>
>    [DKIM]        Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
>                  J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
>                  Signatures", RFC 4871, May 2007.
>
>    [DSN]         Moore, K. and G. Vaudreuil, "An Extensible Message
>                  Format for Delivery Status Notifications", RFC 3464,
>                  January 2003.
>
>    [EMAIL-ARCH]  Crocker, D., "Internet Mail Architecture", RFC 5598,
>                  July 2009.
>
>    [MIME]        Freed, N. and N. Borenstein, "Multipurpose Internet
>                  Mail Extensions (MIME) Part One: Format of Internet
>                  Message Bodies", RFC 2045, November 1996.
>
>    [RFC822]      Crocker, D., "Standard for the Format of Internet Text
>                  Messages", RFC 822, August 1982.
>
>    [SMTP]        Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
>                  October 2008.
>
>    [URI]         Berners-Lee, T., Fielding, R., and L. Masinter,
>                  "Uniform Resource Identifier (URI): Generic Syntax",
>                  RFC 3986, January 2005.
>
> Appendix A.  Acknowledgements
>
>    The author wishes to acknowledge the following for their review and
>    constructive criticism of this proposal: Tony Hansen, and Franck
>    Martin
>
> Authors' Addresses
>
>    Murray S. Kucherawy
>
>    EMail: superuser@gmail.com
>
>
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                [Page 16]
> 
> Internet-Draft             Safe Mail Handling               October 2012
>
>
>    Gregory N. Shapiro
>
>    EMail: gshapiro@sendmail.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Kucherawy & Shapiro      Expires April 12, 2013                [Page 17]
> 

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From salvatore.dantonio@uniparthenope.it  Tue Apr  9 08:40:37 2013
Return-Path: <salvatore.dantonio@uniparthenope.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6407621F97A8; Tue,  9 Apr 2013 08:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.127
X-Spam-Level: **
X-Spam-Status: No, score=2.127 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, MSGID_MULTIPLE_AT=1.449]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEnIxUhvZSvT; Tue,  9 Apr 2013 08:40:36 -0700 (PDT)
Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id B09E121F9798; Tue,  9 Apr 2013 08:40:32 -0700 (PDT)
Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id EA27A41711; Tue,  9 Apr 2013 15:40:30 +0000 (UTC)
Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 1d43_cec0a27c_a12b_11e2_9101_001372515a5c; Tue, 09 Apr 2013 17:40:30 +0200
Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id C174CC430A; Tue,  9 Apr 2013 17:40:29 +0200 (CEST)
Received: by spamk.uniparthenope.it (Postfix, from userid 500) id BA7F1C4302; Tue,  9 Apr 2013 17:40:29 +0200 (CEST)
Received: from mail.uniparthenope.it (unknown [192.168.241.109]) by spamk.uniparthenope.it (Postfix) with ESMTP id 593DCC4301; Tue,  9 Apr 2013 17:40:28 +0200 (CEST)
Received: by mail.uniparthenope.it (Postfix, from userid 108) id 452064181E; Tue,  9 Apr 2013 17:40:28 +0200 (CEST)
Received: from saldantoPC (unknown [192.168.162.11]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id 803F841526; Tue,  9 Apr 2013 17:40:18 +0200 (CEST)
From: "Salvatore D'Antonio" <salvatore.dantonio@uniparthenope.it>
To: "'Benoit Claise'" <bclaise@cisco.com>, <draft-ietf-ipfix-flow-selection-tech@tools.ietf.org>
References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com>
In-Reply-To: <5162C44B.5030904@cisco.com>
Date: Tue, 9 Apr 2013 17:40:03 +0200
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac40XDRV3pT1xDzNTsGp6osHVZb3KAA1rsdA
Content-Language: it
Message-ID: <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it>
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01CE3549.52940480"
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20130409 #9883311, check: 20130409 clean
X-Mailman-Approved-At: Wed, 10 Apr 2013 08:26:45 -0700
Cc: rahulp@cisco.com, 'IETF discussion list' <ietf@ietf.org>, apps-discuss@ietf.org, 'General Area Review Team' <gen-art@ietf.org>, 'S Moonesamy' <sm+ietf@elandsys.com>, ipfix-chairs@tools.ietf.org, ipfix@ietf.org, iesg@ietf.org, "'Joel M. Halpern'" <jmh@joelhalpern.com>, "'A. Jean Mahoney'" <mahoney@nostrum.com>
Subject: [apps-discuss] R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2013 15:40:37 -0000

Messaggio multipart in formato MIME.

------=_NextPart_000_0058_01CE3549.52940480
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Dear all,

=20

A new version of the Internet Draft on Flow Selection Techniques has =
been submitted. It contains the following changes:

-          A new section illustrating the difference between =
Intermediate Flow Selection Process and Intermediate Selection Process =
has been added,

-          The sentence "In order to be compliant with this document, at =
least the Property  Match Filtering MUST be implemented." has been =
removed in Section 1,

-          =E2=80=9CMUST=E2=80=9D has been replaced with =
=E2=80=9CSHOULD=E2=80=9D in Section 5.1,

-          =E2=80=9CThe flowSelectorAlgorithm registry is maintained by =
IANA." has been replaced with =E2=80=9CIANA is requested to create the =
flowSelectorAlgorithm registry.=E2=80=9D

-          The sentence "The registry can be updated when specifications =
of the new  technique(s) and any new Information Elements are provided." =
has been removed since it did not clarify how the registry will be =
managed.

-           Section 6.1.1 =E2=80=9CProperty Match Filtering=E2=80=9D has =
been changed by adding some text on how Property Match Filtering can be  =
used by an Intermediate Flow Selection Process in the Metering Process, =
in the  Exporting Process and within an IPFIX Mediator.

=20

Best regards,

=20

Salvatore

=20

Da: Benoit Claise [mailto:bclaise@cisco.com]=20
Inviato: luned=C3=AC 8 aprile 2013 15:21
A: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org
Cc: ipfix-chairs@tools.ietf.org
Oggetto: Fwd: Last Call Expired: =
<draft-ietf-ipfix-flow-selection-tech-14.txt>

=20

Dear authors,

The IETF last call has finished.
Can you please update your draft based on the feedback received.
Then I will progress it.

Regards, Benoit



-------- Original Message --------=20


Subject:=20

Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>


Date:=20

Mon, 01 Apr 2013 00:28:46 -0700


From:=20

DraftTracker Mail System  <mailto:iesg-secretary@ietf.org> =
<iesg-secretary@ietf.org>


To:=20

iesg@ietf.org, ipfix-chairs@tools.ietf.org, =
draft-ietf-ipfix-flow-selection-tech@tools.ietf.org


CC:=20

iesg-secretary@ietf.org

=20

Please DO NOT reply to this email.
=20
I-D: <draft-ietf-ipfix-flow-selection-tech-14.txt>
ID Tracker URL: =
http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/
=20
IETF Last Call has ended, and the state has been changed to
Waiting for AD Go-Ahead.
=20
=20
=20

=20

=20

  _____ =20

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di =
rilascio: 07/04/2013


******************************************************************************=09=0A
IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO=0A
 =0A
Il 5 per mille all'Universita' degli Studi di Napoli "Parthenope" incrementa le borse di studio agli studenti - codice fiscale 80018240632=0A
http://www.uniparthenope.it/index.php/5xmille =0A
 =0A
http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille=0A
 =0A
Questa informativa e' inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente.=0A

------=_NextPart_000_0058_01CE3549.52940480
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"Segoe UI";
	panose-1:2 11 5 2 4 2 4 2 2 3;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"Preformattato HTML Carattere";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
span.PreformattatoHTMLCarattere
	{mso-style-name:"Preformattato HTML Carattere";
	mso-style-priority:99;
	mso-style-link:"Preformattato HTML";
	font-family:Consolas;
	color:black;}
span.StileMessaggioDiPostaElettronica19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 2.0cm 2.0cm 2.0cm;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:217212090;
	mso-list-type:hybrid;
	mso-list-template-ids:308057158 -1513439274 134807555 134807557 =
134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-GB link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Dear all,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>A new version of the Internet Draft on Flow Selection =
Techniques
has been submitted. It contains the following =
changes:<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo1'><![if !supportLists]><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><span
style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>A new section illustrating the difference between =
Intermediate
Flow Selection Process and Intermediate Selection Process has been =
added,<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo1'><![if !supportLists]><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><span
style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The sentence &quot;In order to be compliant with this =
document,
at least the Property =C2=A0Match Filtering MUST be implemented.&quot; =
has been removed
in Section 1,<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo1'><![if !supportLists]><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><span
style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>=E2=80=9CMUST=E2=80=9D has been replaced with =
=E2=80=9CSHOULD=E2=80=9D in Section 5.1,<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo1'><![if !supportLists]><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><span
style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>=E2=80=9CThe flowSelectorAlgorithm registry is maintained =
by IANA.&quot;
has been replaced with =E2=80=9CIANA is requested to create the =
flowSelectorAlgorithm
registry.=E2=80=9D<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo1'><![if !supportLists]><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><span
style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The sentence &quot;The registry can be updated when
specifications of the new=C2=A0 technique(s) and any new Information =
Elements are
provided.&quot; has been removed since it did not clarify how the =
registry will
be managed.<o:p></o:p></span></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo1'><![if !supportLists]><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'><span
style=3D'mso-list:Ignore'>-<span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>=C2=A0Section 6.1.1 =E2=80=9CProperty Match =
Filtering=E2=80=9D has been changed by
adding some text on how Property Match Filtering can be =C2=A0used by an
Intermediate Flow Selection Process in the Metering Process, in the =
=C2=A0Exporting
Process and within an IPFIX Mediator.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Best regards,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Salvatore<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0cm 0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DIT =
style=3D'font-size:10.0pt;font-family:"Segoe UI","sans-serif";
color:windowtext'>Da:</span></b><span lang=3DIT =
style=3D'font-size:10.0pt;
font-family:"Segoe UI","sans-serif";color:windowtext'> Benoit Claise
[mailto:bclaise@cisco.com] <br>
<b>Inviato:</b> luned=C3=AC 8 aprile 2013 15:21<br>
<b>A:</b> draft-ietf-ipfix-flow-selection-tech@tools.ietf.org<br>
<b>Cc:</b> ipfix-chairs@tools.ietf.org<br>
<b>Oggetto:</b> Fwd: Last Call Expired:
&lt;draft-ietf-ipfix-flow-selection-tech-14.txt&gt;<o:p></o:p></span></p>=


</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Dear authors,<br>
<br>
The IETF last call has finished.<br>
Can you please update your draft based on the feedback received.<br>
Then I will progress it.<br>
<br>
Regards, Benoit<o:p></o:p></p>

<div>

<p class=3DMsoNormal><br>
<br>
-------- Original Message -------- <o:p></o:p></p>

<table class=3DMsoNormalTable border=3D0 cellspacing=3D0 =
cellpadding=3D0>
 <tr>
  <td nowrap valign=3Dtop style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal align=3Dright =
style=3D'text-align:right'><b>Subject: <o:p></o:p></b></p>
  </td>
  <td style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal>Last Call Expired:
  &lt;draft-ietf-ipfix-flow-selection-tech-14.txt&gt;<o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td nowrap valign=3Dtop style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><b>Date: =
<o:p></o:p></b></p>
  </td>
  <td style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal>Mon, 01 Apr 2013 00:28:46 -0700<o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td nowrap valign=3Dtop style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><b>From: =
<o:p></o:p></b></p>
  </td>
  <td style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal>DraftTracker Mail System <a
  =
href=3D"mailto:iesg-secretary@ietf.org">&lt;iesg-secretary@ietf.org&gt;</=
a><o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td nowrap valign=3Dtop style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><b>To: =
<o:p></o:p></b></p>
  </td>
  <td style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal><a =
href=3D"mailto:iesg@ietf.org">iesg@ietf.org</a>, <a
  =
href=3D"mailto:ipfix-chairs@tools.ietf.org">ipfix-chairs@tools.ietf.org</=
a>, <a
  =
href=3D"mailto:draft-ietf-ipfix-flow-selection-tech@tools.ietf.org">draft=
-ietf-ipfix-flow-selection-tech@tools.ietf.org</a><o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td nowrap valign=3Dtop style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><b>CC: =
<o:p></o:p></b></p>
  </td>
  <td style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal><a =
href=3D"mailto:iesg-secretary@ietf.org">iesg-secretary@ietf.org</a><o:p><=
/o:p></p>
  </td>
 </tr>
</table>

<p class=3DMsoNormal =
style=3D'margin-bottom:12.0pt'><o:p>&nbsp;</o:p></p>

<pre>Please DO NOT reply to this =
email.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>I-D: =
&lt;draft-ietf-ipfix-flow-selection-tech-14.txt&gt;<o:p></o:p></pre><pre>=
ID Tracker URL: <a
href=3D"http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-t=
ech/">http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tec=
h/</a><o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>IETF Last Call =
has ended, and the state has been changed =
to<o:p></o:p></pre><pre>Waiting for AD =
Go-Ahead.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><o:p>&nbsp;</o=
:p></pre><pre><o:p>&nbsp;</o:p></pre>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

<hr size=3D1 width=3D"100%" noshade style=3D'color:#A0A0A0' =
align=3Dcenter>

</div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Nessun
virus nel messaggio.<br>
Controllato da AVG - <a href=3D"http://www.avg.com">www.avg.com</a><br>
Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di =
rilascio:
07/04/2013<o:p></o:p></p>

</div>


<br>=
<STYLE TYPE=3D"text/css">=0A
=09<!--=0A
=09=09@page { margin-left: 2cm; margin-right: 2cm; margin-top: 2.5cm; margin-bottom: 2cm }=0A
=09=09P { margin-bottom: 0.21cm; direction: ltr; color: #000000; widows: 2; orphans: 2 }=0A
=09=09P.western { font-family: "Times New Roman", serif; font-size: 8pt; so-language: it-IT }=0A
=09=09P.cjk { font-family: "Times New Roman", serif; font-size: 8pt }=0A
=09=09P.ctl { font-family: "Times New Roman", serif; font-size: 8pt; so-language: ar-SA }=0A
=09=09A:link { color: #0000ff }=0A
=09-->=0A
=09</STYLE>=0A
<!--</HEAD></BODY>-->=0A
<P LANG=3D"it-IT" TEXT=3D"#000000" LINK=3D"#0000ff" DIR=3D"LTR">=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><FONT FACE=3D"Arial, sans-serif">*******************************************************************************************************</FONT></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><FONT FACE=3D"Arial, sans-serif">IL=0A
MERITO DEGLI STUDENTI&nbsp;VIENE RICONOSCIUTO</FONT></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm">&nbsp;</P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><FONT COLOR=3D"#000000"><FONT FACE=3D"Arial, sans-serif">Il=0A
5 per mille all'Universit&agrave degli Studi di Napoli &quot;Parthenope&quot;incrementa le borse di studio agli studenti=0A
- codice fiscale </FONT></FONT><FONT COLOR=3D"#000000"><FONT FACE=3D"Arial, sans-serif"><B>80018240632</B></FONT></FONT><FONT COLOR=3D"#000000"><FONT FACE=3D"Arial, sans-serif">=0A
</FONT></FONT>=0A
</P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><A HREF=3D"http://www.uniparthenope.it/index.php/5xmille"><FONT COLOR=3D"#0000ff"><FONT FACE=3D"Arial, sans-serif"><U>http://www.uniparthenope.it/index.php/5xmille</U></FONT></FONT></A><FONT COLOR=3D"#000000"><FONT FACE=3D"Arial, sans-serif">&nbsp;</FONT></FONT></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm">&nbsp;</P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><A HREF=3D"http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille"><FONT COLOR=3D"#0000ff"><FONT FACE=3D"Arial, sans-serif"><U>http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille</U></FONT></FONT></A></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm">&nbsp;<FONT FACE=3D"Arial, sans-serif"><BR>Questa=0A
informativa &egrave inserita in automatico dal sistema al fine esclusivo=0A
della realizzazione dei fini istituzionali dell&#39;ente.</FONT></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><BR>=0A
</P>=0A
<!--</BODY>-->=0A
<!--</HTML>-->=0A
<br>=
</body>

</html>

<br>=
<STYLE TYPE=3D"text/css">=0A
=09<!--=0A
=09=09@page { margin-left: 2cm; margin-right: 2cm; margin-top: 2.5cm; margin-bottom: 2cm }=0A
=09=09P { margin-bottom: 0.21cm; direction: ltr; color: #000000; widows: 2; orphans: 2 }=0A
=09=09P.western { font-family: "Times New Roman", serif; font-size: 8pt; so-language: it-IT }=0A
=09=09P.cjk { font-family: "Times New Roman", serif; font-size: 8pt }=0A
=09=09P.ctl { font-family: "Times New Roman", serif; font-size: 8pt; so-language: ar-SA }=0A
=09=09A:link { color: #0000ff }=0A
=09-->=0A
=09</STYLE>=0A
<!--</HEAD></BODY>-->=0A
<P LANG=3D"it-IT" TEXT=3D"#000000" LINK=3D"#0000ff" DIR=3D"LTR">=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><FONT FACE=3D"Arial, sans-serif">*******************************************************************************************************</FONT></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><FONT FACE=3D"Arial, sans-serif">IL=0A
MERITO DEGLI STUDENTI&nbsp;VIENE RICONOSCIUTO</FONT></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm">&nbsp;</P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><FONT COLOR=3D"#000000"><FONT FACE=3D"Arial, sans-serif">Il=0A
5 per mille all'Universit&agrave degli Studi di Napoli &quot;Parthenope&quot;incrementa le borse di studio agli studenti=0A
- codice fiscale </FONT></FONT><FONT COLOR=3D"#000000"><FONT FACE=3D"Arial, sans-serif"><B>80018240632</B></FONT></FONT><FONT COLOR=3D"#000000"><FONT FACE=3D"Arial, sans-serif">=0A
</FONT></FONT>=0A
</P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><A HREF=3D"http://www.uniparthenope.it/index.php/5xmille"><FONT COLOR=3D"#0000ff"><FONT FACE=3D"Arial, sans-serif"><U>http://www.uniparthenope.it/index.php/5xmille</U></FONT></FONT></A><FONT COLOR=3D"#000000"><FONT FACE=3D"Arial, sans-serif">&nbsp;</FONT></FONT></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm">&nbsp;</P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><A HREF=3D"http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille"><FONT COLOR=3D"#0000ff"><FONT FACE=3D"Arial, sans-serif"><U>http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille</U></FONT></FONT></A></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm">&nbsp;<FONT FACE=3D"Arial, sans-serif"><BR>Questa=0A
informativa &egrave inserita in automatico dal sistema al fine esclusivo=0A
della realizzazione dei fini istituzionali dell&#39;ente.</FONT></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><BR>=0A
</P>=0A
<!--</BODY>-->=0A
<!--</HTML>-->=0A
<br>=
------=_NextPart_000_0058_01CE3549.52940480--

From salvatore.dantonio@uniparthenope.it  Wed Apr 10 00:38:39 2013
Return-Path: <salvatore.dantonio@uniparthenope.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A449D21F8967; Wed, 10 Apr 2013 00:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.034
X-Spam-Level: ****
X-Spam-Status: No, score=4.034 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MIME_QP_LONG_LINE=1.396, MSGID_MULTIPLE_AT=1.449, RCVD_ILLEGAL_IP=1.908]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MycF0rKyAD6i; Wed, 10 Apr 2013 00:38:39 -0700 (PDT)
Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id A1AA221F884A; Wed, 10 Apr 2013 00:38:38 -0700 (PDT)
Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id 6CC9F4212D; Wed, 10 Apr 2013 07:38:37 +0000 (UTC)
Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 4487_a7d795ae_a1b1_11e2_9101_001372515a5c; Wed, 10 Apr 2013 09:38:37 +0200
Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id 16A56C4300; Wed, 10 Apr 2013 09:38:37 +0200 (CEST)
Received: by spamk.uniparthenope.it (Postfix, from userid 500) id 1456BC4307; Wed, 10 Apr 2013 09:38:37 +0200 (CEST)
Received: from mail.uniparthenope.it (unknown [192.168.241.109]) by spamk.uniparthenope.it (Postfix) with ESMTP id F0CA7C4305; Wed, 10 Apr 2013 09:38:35 +0200 (CEST)
Received: by mail.uniparthenope.it (Postfix, from userid 108) id E1E604211A; Wed, 10 Apr 2013 09:38:35 +0200 (CEST)
Received: from saldantoPC (unknown [2.237.123.176]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id 4B33B41F83; Wed, 10 Apr 2013 09:38:35 +0200 (CEST)
From: "Salvatore D'Antonio" <salvatore.dantonio@uniparthenope.it>
To: "'S Moonesamy'" <sm+ietf@elandsys.com>, <draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org>
References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> <6.2.5.6.2.20130409084702.0c6104b8@elandnews.com>
In-Reply-To: <6.2.5.6.2.20130409084702.0c6104b8@elandnews.com>
Date: Wed, 10 Apr 2013 09:38:31 +0200
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac41YQamhJLMI8hqQ2mKGaq6vmybpgAW8Neg
Content-Language: it
Message-ID: <001501ce35be$68c93c00$3a5bb400$@dantonio@uniparthenope.it>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20130410 #9875681, check: 20130410 clean
X-Mailman-Approved-At: Wed, 10 Apr 2013 08:26:58 -0700
Cc: ipfix@ietf.org, iesg@ietf.org, apps-discuss@ietf.org
Subject: [apps-discuss] R: R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt> (APPSDIR review)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2013 07:38:39 -0000

Dear S. Moonesamy,

I did not adequately addressed your comment because I thought that the
guidelines specified in RFC 5226 were sufficient to deal with the issues
concerning the management of the sub-registry.
I would greatly appreciate if you could provide me with the reference to =
a
Draft where documentation and criteria for managing assignments are
specified so that I may use such Draft as an example.

Thanks a lot in advance.

Best regards,


Salvatore  =20

-----Messaggio originale-----
Da: S Moonesamy [mailto:sm+ietf@elandsys.com]=20
Inviato: marted=EC 9 aprile 2013 18:10
A: Salvatore D'Antonio;
draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org
Cc: apps-discuss@ietf.org; iesg@ietf.org; ipfix@ietf.org
Oggetto: Re: R: Last Call Expired:
<draft-ietf-ipfix-flow-selection-tech-14.txt> (APPSDIR review)

Hi Salvatore,
At 08:40 09-04-2013, Salvatore D'Antonio wrote:
>-          The sentence "The registry can be updated when=20
>specifications of the new  technique(s) and any new Information=20
>Elements are provided." has been removed since it did not clarify=20
>how the registry will be managed.

This is a follow-up to the APPSDIR review of=20
draft-ietf-ipfix-flow-selection-tech (=20
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09239.html =
)

 From Section 9.1.1 of draft-ietf-ipfix-flow-selection-tech-15:

   "New assignments for the registry will be administered
    by IANA and are subject to Expert Review [RFC5226]."

draft-ietf-ipfix-flow-selection-tech-15 defines a sub-registry.  It=20
does not provide any relevant details about the sub-registry.  What=20
documentation is required and which criteria will be used for=20
assignments in the new sub-registry?

Regards,
S. Moonesamy=20
-----
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2013.0.3272 / Database dei virus: 3162/6234 -  Data di =
rilascio:
09/04/2013
-----
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2013.0.3272 / Database dei virus: 3162/6234 -  Data di =
rilascio:
09/04/2013

******************************************************************************	
IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO
 
Il 5 per mille all'Universita' degli Studi di Napoli "Parthenope" incrementa le borse di studio agli studenti - codice fiscale 80018240632
http://www.uniparthenope.it/index.php/5xmille 
 
http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille
 
Questa informativa e' inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente.

From yngve@spec-work.net  Wed Apr 10 06:54:06 2013
Return-Path: <yngve@spec-work.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204E721F976F; Wed, 10 Apr 2013 06:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3auLxNRAMR33; Wed, 10 Apr 2013 06:54:05 -0700 (PDT)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0F221F8F27; Wed, 10 Apr 2013 06:54:04 -0700 (PDT)
Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:49495 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <yngve@spec-work.net>) id 1UPvTC-0004Lh-S4; Wed, 10 Apr 2013 15:53:50 +0200
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, draft-ietf-tls-multiple-cert-status-extension.all@tools.ietf.org, "Peter Saint-Andre" <stpeter@stpeter.im>
References: <5165610C.1020803@stpeter.im>
Date: Wed, 10 Apr 2013 15:53:49 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: Quoted-Printable
From: "Yngve N. Pettersen" <yngve@spec-work.net>
Message-ID: <op.wvbvjzd83dfyax@killashandra.invalid.invalid>
In-Reply-To: <5165610C.1020803@stpeter.im>
User-Agent: Opera Mail/12.15 (Win32)
X-Mailman-Approved-At: Wed, 10 Apr 2013 08:27:10 -0700
Cc: The IESG <iesg@ietf.org>
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-tls-multiple-cert-status-extension-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2013 13:54:06 -0000

Hi Peter and Bert,

Thanks for the review.

On Wed, 10 Apr 2013 14:54:36 +0200, Peter Saint-Andre <stpeter@stpeter.i=
m>  =

wrote:

> Bert Greevenbosch and I have been selected as the joint Applications
> Area Directorate reviewers for this draft (for background on AppsDir,
> please see =E2=80=8B
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirector=
ate  =

> ).
>
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd=

> or AD before posting a new version of the draft.
>
> Document: draft-ietf-tls-multiple-cert-status-extension-05
> Title: The TLS Multiple Certificate Status Request Extension
> Reviewers: Bert Greevenbosch and Peter Saint-Andre
> Review Date: 10 April 2013
> IESG Telechat Date: 2013-04-11
> Summary: This draft is almost ready for publication; comments raised
> here are for the WG's consideration.
>
> Major Issues:
>
> none
>
> Minor Issues:
>
> (1) Maybe a server can maintain cached OCSP responses, e.g. until afte=
r
> the "nextUpdate" time has expired. Then the server would be able to us=
e
> these cached responses instead of acquiring a new response from the
> OCSP-responders. (This mechanism is e.g. defined in [OCSP-MP]). With t=
he
> new extension, multiple OCSP-responses from probably different OCSP
> servers could be cached. The client needs to verify that each of the
> OCSP response is still valid, e.g. that none of the OCSP-responses are=

> too old.
>
> [OCSP-MP]: OMA Online Certificate Status Protocol (profile of [OCSP]) =
V
> 1.0, Open Mobile Alliance, URL:http://www.openmobilealliance.org/
>
> Would some text about cached OCSP responses be appropriate? (Of course=

> nonces would make caching impossible, as each OCSP responder would nee=
d
> to sign the new nonce.)

The server would not know if the client have cached the response, and th=
e  =

client would not know if there is a newer response held by the server.

The client could leave the request for certificate status out of the  =

handshake, but that would mean that 1) it would not get any updated  =

responses, and 2) if the serve changed its certificate(s) between the  =

previous handshake and the current handshake, it would also not get the =
 =

new responses, since it did not signal the willingness to receive them.

Resolving of that lack of information would require some kind of signali=
ng  =

mechanism, which I think is outside the scope of this particular documen=
t.

At present, discussion is underway in the TLS WG of adding such a  =

mechanism to the draft-ietf-tls-cached-info  =

<http://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/>. If  =

implemented, that would resolve the signaling mechanism problem, and  =

combine it with a more general mechanism.

> (2) Section 2.2, p.5:
>
>    A zero-length "request_extensions" value means that there are no
>    extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is no=
t
>    valid for the "Extensions" type).
>
> This text was copied from RFC 6066. It seems a bit cryptic, but I
> suppose it means that the "request_extensions" field does not exist at=

> all, e.g. the "OCSPStatusRequest" struct only contains the
> "responder_id_list<0..2^16-1>"?

The record would still contain two zero bytes to indicate the length of =
 =

the request_extensions vector (the length-field of the vector is not par=
t  =

of the content); the zerolength ASN1.1 SEQUENCE would require a  =

non-zero-length request_extensions field since the field would contain a=
  =

<SEQUENCE-indication + 0 byte length field> in ASN.1 DER encoding, which=
  =

would likely be one or two bytes long.

> (3) Section 2.2, p.6:
>
>    Note that a server MAY also choose not to send a "CertificateStatus=
"
>    message, even if it has received a "status_request_v2" extension in=

>    the client hello message and has sent a "status_request_v2" extensi=
on
>    in the server hello message.
>
> In essence, this says that it is optional for the server to send the
> "CertificateStatus" message. What are the types of conditions under
> which it is reasonable to not send the "CertificateStatus" message?

The supporting server might not yet have downloaded an OCSP response. Th=
at  =

is, for example, the case with nginx versions able to use RFC 6066 OCSP =
 =

Stapling. Those servers also have a bug which makes them forward an  =

expired OCSP response while they are fetching the new one, rather than  =

discarding it.

In such cases the server can either wait until it receive the response  =

(which might mean a long wait for the client if the responder is slow), =
or  =

it can leave out the status message in connections it is establishing  =

until it have received the OCSP response.

> (4) Section 2.2, p.7:
>
>    If the client receives a
>    "ocsp_response_list" that does not contain a response for one or mo=
re
>    of the certificates in the completed certificate chain, the client
>    SHOULD attempt to validate the certificate using an alternative
>    retrieval method, such as downloading the relevant CRL;
>
> Would this allow an attacker to downgrade the security of the
> certificate, e.g. by disabling the OCSP response and using a stale CRL=
?
>
> Maybe a "SHOULD" is not appropriate, but better leave it to the
> particular trust model?

This would not reduce the security compared to the current environment.

CRLs (and OCSP) still have a validity period, and replay attacks using  =

unexpired but out of date CRLs and OCSP responses is very much a  =

possibility both via the stapling mechanism and via direct retrieval  =

(require MITM).

IMO a malicious server is actually more likely to use an out of date OCS=
P  =

response while it is valid, than to make the client fall back to the old=
er  =

methods. As I have mentioned elsewhere, this is why I would have preferr=
ed  =

the stapled responses to have a freshness requirement of having to be  =

generated with the last few hours. It is probably too late to do anythin=
g  =

about that in the stapling specs, but CAs could reduce the validity  =

periods to get the same effect.

Additionally, there are currently at least three different schemes used =
by  =

clients: OCSP(site) + CRL (MSIE, Opera), OCSP (Firefox) and Out of band =
 =

CRLsets (Chrome).

> (5) Section 3. IANA Considerations. This section mentions a new regist=
ry
> called "TLS Certificate Status Types", where CertificateStatusType
> values should be registered. New values are assigned via IETF Review a=
s
> defined in RFC5226.
>
> Should there be specific guidelines/required info for acceptance of ne=
w
> values for this particular field? If so, state these guidelines/requir=
ed
> info.

The text and requirements for this is similar to what is specified in RF=
C  =

5246 for the ExtensionType registry

I am not sure how much formal guidelines we really need. I am open to  =

suggestions.

However, the IETF Review do require quite a bit of checks, including  =

AD-shepherding, IESG and WG/expert approval. That ought to reduce the  =

possibility for spurious allocations to get through.

> Nits:
>
> In Section 2:
>
>    In the OCSPStatusRequest (originally defined by [RFC6066]), the
>    "ResponderIDs" provides a list of OCSP responders that the client
>    trusts.
>
> - It seems that "ResponderIDs" should be "ResponderID".

Corrected

-- =

Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

From stpeter@stpeter.im  Wed Apr 10 08:42:50 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6137021F9754; Wed, 10 Apr 2013 08:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE5JGALMFTok; Wed, 10 Apr 2013 08:42:46 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A59DB21F93D6; Wed, 10 Apr 2013 08:42:46 -0700 (PDT)
Received: from [10.129.24.115] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C963A40E4B; Wed, 10 Apr 2013 09:52:50 -0600 (MDT)
Message-ID: <51658870.8070806@stpeter.im>
Date: Wed, 10 Apr 2013 09:42:40 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Yngve N. Pettersen" <yngve@spec-work.net>
References: <5165610C.1020803@stpeter.im> <op.wvbvjzd83dfyax@killashandra.invalid.invalid>
In-Reply-To: <op.wvbvjzd83dfyax@killashandra.invalid.invalid>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: draft-ietf-tls-multiple-cert-status-extension.all@tools.ietf.org, The IESG <iesg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-tls-multiple-cert-status-extension-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2013 15:42:50 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Yngve!

On 4/10/13 7:53 AM, Yngve N. Pettersen wrote:
> Hi Peter and Bert,
> 
> Thanks for the review.
> 
> On Wed, 10 Apr 2013 14:54:36 +0200, Peter Saint-Andre 
> <stpeter@stpeter.im> wrote:
> 
>> Bert Greevenbosch and I have been selected as the joint
>> Applications Area Directorate reviewers for this draft (for
>> background on AppsDir, please see ​ 
>> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
>>
>> 
).
>> 
>> Please resolve these comments along with any other Last Call
>> comments you may receive. Please wait for direction from your
>> document shepherd or AD before posting a new version of the
>> draft.
>> 
>> Document: draft-ietf-tls-multiple-cert-status-extension-05 Title:
>> The TLS Multiple Certificate Status Request Extension Reviewers:
>> Bert Greevenbosch and Peter Saint-Andre Review Date: 10 April
>> 2013 IESG Telechat Date: 2013-04-11 Summary: This draft is almost
>> ready for publication; comments raised here are for the WG's
>> consideration.
>> 
>> Major Issues:
>> 
>> none
>> 
>> Minor Issues:
>> 
>> (1) Maybe a server can maintain cached OCSP responses, e.g. until
>> after the "nextUpdate" time has expired. Then the server would be
>> able to use these cached responses instead of acquiring a new
>> response from the OCSP-responders. (This mechanism is e.g.
>> defined in [OCSP-MP]). With the new extension, multiple
>> OCSP-responses from probably different OCSP servers could be
>> cached. The client needs to verify that each of the OCSP response
>> is still valid, e.g. that none of the OCSP-responses are too
>> old.
>> 
>> [OCSP-MP]: OMA Online Certificate Status Protocol (profile of
>> [OCSP]) V 1.0, Open Mobile Alliance,
>> URL:http://www.openmobilealliance.org/
>> 
>> Would some text about cached OCSP responses be appropriate? (Of
>> course nonces would make caching impossible, as each OCSP
>> responder would need to sign the new nonce.)
> 
> The server would not know if the client have cached the response,
> and the client would not know if there is a newer response held by
> the server.
> 
> The client could leave the request for certificate status out of
> the handshake, but that would mean that 1) it would not get any
> updated responses, and 2) if the serve changed its certificate(s)
> between the previous handshake and the current handshake, it would
> also not get the new responses, since it did not signal the
> willingness to receive them.
> 
> Resolving of that lack of information would require some kind of 
> signaling mechanism, which I think is outside the scope of this 
> particular document.
> 
> At present, discussion is underway in the TLS WG of adding such a 
> mechanism to the draft-ietf-tls-cached-info 
> <http://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/>. If 
> implemented, that would resolve the signaling mechanism problem,
> and combine it with a more general mechanism.

Thanks for the pointer to draft-ietf-tls-cached-info. I suppose that,
if implemented, it might lead to some changes in several TLS-related
specs, including this one. Correct?

>> (2) Section 2.2, p.5:
>> 
>> A zero-length "request_extensions" value means that there are no 
>> extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is
>> not valid for the "Extensions" type).
>> 
>> This text was copied from RFC 6066. It seems a bit cryptic, but
>> I suppose it means that the "request_extensions" field does not
>> exist at all, e.g. the "OCSPStatusRequest" struct only contains
>> the "responder_id_list<0..2^16-1>"?
> 
> The record would still contain two zero bytes to indicate the
> length of the request_extensions vector (the length-field of the
> vector is not part of the content); the zerolength ASN1.1 SEQUENCE
> would require a non-zero-length request_extensions field since the
> field would contain a <SEQUENCE-indication + 0 byte length field>
> in ASN.1 DER encoding, which would likely be one or two bytes
> long.

Thanks for the clarification. Would it make sense to add a small note
to draft-ietf-tls-multiple-cert-status-extension on this point?

>> (3) Section 2.2, p.6:
>> 
>> Note that a server MAY also choose not to send a
>> "CertificateStatus" message, even if it has received a
>> "status_request_v2" extension in the client hello message and has
>> sent a "status_request_v2" extension in the server hello
>> message.
>> 
>> In essence, this says that it is optional for the server to send
>> the "CertificateStatus" message. What are the types of conditions
>> under which it is reasonable to not send the "CertificateStatus"
>> message?
> 
> The supporting server might not yet have downloaded an OCSP
> response. That is, for example, the case with nginx versions able
> to use RFC 6066 OCSP Stapling. Those servers also have a bug which
> makes them forward an expired OCSP response while they are fetching
> the new one, rather than discarding it.
> 
> In such cases the server can either wait until it receive the
> response (which might mean a long wait for the client if the
> responder is slow), or it can leave out the status message in
> connections it is establishing until it have received the OCSP
> response.

That makes sense. Explaining that in the spec might make sense, since
otherwise implementers might think there are other good reasons to not
send the "CertificateStatus" message.

>> (4) Section 2.2, p.7:
>> 
>> If the client receives a "ocsp_response_list" that does not
>> contain a response for one or more of the certificates in the
>> completed certificate chain, the client SHOULD attempt to
>> validate the certificate using an alternative retrieval method,
>> such as downloading the relevant CRL;
>> 
>> Would this allow an attacker to downgrade the security of the 
>> certificate, e.g. by disabling the OCSP response and using a
>> stale CRL?
>> 
>> Maybe a "SHOULD" is not appropriate, but better leave it to the 
>> particular trust model?
> 
> This would not reduce the security compared to the current
> environment.
> 
> CRLs (and OCSP) still have a validity period, and replay attacks
> using unexpired but out of date CRLs and OCSP responses is very
> much a possibility both via the stapling mechanism and via direct
> retrieval (require MITM).
> 
> IMO a malicious server is actually more likely to use an out of
> date OCSP response while it is valid, than to make the client fall
> back to the older methods. As I have mentioned elsewhere, this is
> why I would have preferred the stapled responses to have a
> freshness requirement of having to be generated with the last few
> hours. It is probably too late to do anything about that in the
> stapling specs, but CAs could reduce the validity periods to get
> the same effect.

OK by me. Bert, do you have any comments on this item?

> Additionally, there are currently at least three different schemes
> used by clients: OCSP(site) + CRL (MSIE, Opera), OCSP (Firefox) and
> Out of band CRLsets (Chrome).
> 
>> (5) Section 3. IANA Considerations. This section mentions a new
>> registry called "TLS Certificate Status Types", where
>> CertificateStatusType values should be registered. New values are
>> assigned via IETF Review as defined in RFC5226.
>> 
>> Should there be specific guidelines/required info for acceptance
>> of new values for this particular field? If so, state these
>> guidelines/required info.
> 
> The text and requirements for this is similar to what is specified
> in RFC 5246 for the ExtensionType registry
> 
> I am not sure how much formal guidelines we really need. I am open
> to suggestions.
> 
> However, the IETF Review do require quite a bit of checks,
> including AD-shepherding, IESG and WG/expert approval. That ought
> to reduce the possibility for spurious allocations to get through.

True.

>> Nits:
>> 
>> In Section 2:
>> 
>> In the OCSPStatusRequest (originally defined by [RFC6066]), the 
>> "ResponderIDs" provides a list of OCSP responders that the
>> client trusts.
>> 
>> - It seems that "ResponderIDs" should be "ResponderID".
> 
> Corrected

Thanks!

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRZYhwAAoJEOoGpJErxa2pcvoP/Rl6n9dx9PnTrcp9u7Eji/pB
zeiiz8zMpUjC/Y5nyRoqZ5crXJqoJfRBzV7AClHUrtUW3anDZpCQSPiAh8fBPDQN
s3MmTlo5B5r2eaYCIGFQzfGlPPiKt2SrBOwlXICZG+hoPgQTPTCrrHdmi0g3fVpj
K7JzOsyOezNbOLQE37jw7yvbDvTk//Js/aJEjzzxLzgtB+hR9IzEynqfVlj4E4J7
wv9E73zuH5BpA7ckEstasMD0kYpuwh+lw5LtVYKzAmwdyVhcYPb/atUO04W+6+qc
+xZ8B6lye1Q8JDK50qQcgnbmC+hbLd46tSQnhwbkeN3RgfWvgGVRI59znD5IGrAE
mWLf6yjarqUADzo6s1tzYGItGFj/CASrOZUe9T/136/pdrXhIRmWhyfF1IhykXNb
0biDpBlxokW6WonLFHxnqnJi/Otm+BlQx7AyEWNlwNf29YrkpofrtVRnjfEmMKOJ
h+wj9Tb8Mk9Xzm5We2GZIwClJp8kLVwQ0h+YDejYLYwE1yDlLS7O76btp1fgzvYZ
km78rFh+1i54cPXnd6JzzlLJJxmjDVqonQsFCD6+I6iwYRw8bK3F1AHT6Wne/NJw
q3a9jLzSxYtJM2/lmwTDDRK0AcanmIOPQpi/NzzWF3Z9+clhUi/E08DzGMcB5xnc
qGdCKHN+axpzC6JK3xOZ
=+2Rt
-----END PGP SIGNATURE-----

From sm@elandsys.com  Wed Apr 10 12:10:07 2013
Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF6B21F9330 for <apps-discuss@ietfa.amsl.com>; Wed, 10 Apr 2013 12:10:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpN2Ycgh0MLI for <apps-discuss@ietfa.amsl.com>; Wed, 10 Apr 2013 12:10:06 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A6E21F90CE for <apps-discuss@ietf.org>; Wed, 10 Apr 2013 12:10:05 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.226.234.212]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3AJ9rvH027518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Wed, 10 Apr 2013 12:10:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365621004; bh=mmeKpmvBouvJkkJG2m8z9SWOQSYHvzJiZVcZcuyaZo8=; h=Date:To:From:Subject; b=41KdpNa3cesuCvJlYcCl+0PXA+ou97Z8FwD/VmT+voMyUKK26DloEkPK7x2Hphlio WYdjP7bYmCy+grPi3eaRY8Z+izqOUQygRb1lfM4WKuRoVW3hczk6Wm5lY7i6n3MUqe To35aX0N85nOkow45wjlL3YYj0pFp63LFIztFoK4=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1365621004; i=@elandsys.com; bh=mmeKpmvBouvJkkJG2m8z9SWOQSYHvzJiZVcZcuyaZo8=; h=Date:To:From:Subject; b=D/OsF9g8OF8MSnSdv+qjALqS8z9dFDV0If8zdl0/3tmHA4fLH3MJsrxc4qOwA4hx2 b0mRoQBWlMYoIf6Xm+EXBPqcy/7e9WrKuEtSpccmp92nd59ttwiAVhevZ+mLJWqlDB 5o86Sz8Yq5JMg7InjZ/izI014wYrKFJpNwSmigYs=
Message-Id: <6.2.5.6.2.20130410112935.07207310@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 10 Apr 2013 11:38:17 -0700
To: apps-discuss@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [apps-discuss] Apps Area Directorate report for March 2013
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2013 19:10:07 -0000

The Applications Area Directorate provides semi-formal reviews of 
Internet-Drafts as a way to improve the quality of IETF 
specifications.  The directorate consists of the Working Group Chairs 
of the Applications Area and recognized experts in the Applications Area.

The following reviews were performed in March 2013:

    Reviewer             I-D
  Salvatore Loreto   draft-ietf-intarea-nat-reveal-analysis-06
  Carsten Bormann    draft-ietf-roll-terminology-12
  Murray Kucherawy   draft-saintandre-urn-example
  Murray Kucherawy   draft-saintandre-iana-urn
  Jiankang Yao       draft-ietf-ospf-ipv4-embedded-ipv6-routing-07
  Tim Bray           draft-ietf-tsvwg-byte-pkt-congest-09
  Eliot Lear         draft-ietf-geopriv-held-measurements-06
  S. Moonesamy       draft-merkle-ikev2-ke-brainpool-03
  Enrico Marocco     draft-ietf-xrblock-rtcp-xr-decodability-09
  Tobias Gondrom     draft-schaad-pkix-rfc2875-bis-07
  Eric Burger        draft-ietf-xrblock-rtcp-xr-burst-gap-discard-10
  Dave Cridland      draft-ietf-appsawg-acct-uri-03
  Dave Cridland      draft-ietf-appsawg-webfinger-11
  Ted Hardie         draft-ietf-idr-deprecate-dpa-etal

Regards,
S. Moonesamy
On behalf of the Applications Area Directorate
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate


From martin.thomson@gmail.com  Wed Apr 10 17:00:37 2013
Return-Path: <martin.thomson@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B4321F8733; Wed, 10 Apr 2013 17:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YG3Mv+yjMqC6; Wed, 10 Apr 2013 17:00:36 -0700 (PDT)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1EACC21F8712; Wed, 10 Apr 2013 17:00:35 -0700 (PDT)
Received: by mail-wg0-f45.google.com with SMTP id l18so1046683wgh.0 for <multiple recipients>; Wed, 10 Apr 2013 17:00:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=EfD13dCoJbSVX9/MWa4RapB0uQ2klN0PeC+8SCHVNek=; b=yNejMbb2pA0Ec3FfonOlPGvgAO10zA+aVcOXeSXnkWW5Swr6wsDwWPzTu5DEUwN9x1 1AaaHk15Uj+EZ/7al+iP7I91pC6L/GjO+47JtJDEIyJevVnoKTSNMVxWbHKvFvrfKo6k 6/HR7N8P9a8cEuXHdyc7HoCJsluo0PUsAF9PkReV1h7Punx+DpUZgsNXRkOAMr1RvMHk GfLJcZS5A6ztAG591dIv9CEsvWQJpsmgSCLtvCtGfr3netmu/ygd/ernueKBk6upxGyS 8zCVt4nVgQCnn6Rqmd5JNaQ0oGoe5KVZeDigoTiFt/GoiyFOwrq9bMLWy4jEGxAt3qW6 wQ4A==
MIME-Version: 1.0
X-Received: by 10.180.109.197 with SMTP id hu5mr6394682wib.22.1365638435286; Wed, 10 Apr 2013 17:00:35 -0700 (PDT)
Received: by 10.194.41.35 with HTTP; Wed, 10 Apr 2013 17:00:35 -0700 (PDT)
In-Reply-To: <5151B0B5.2090407@cisco.com>
References: <5151B0B5.2090407@cisco.com>
Date: Wed, 10 Apr 2013 17:00:35 -0700
Message-ID: <CABkgnnWNPMgsNACjOYdxcn3VW20LFOOS5XeFO9Nifxv2hJTwUg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Eliot Lear <lear@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, IESG <iesg@ietf.org>, draft-ietf-geopriv-held-measurements.all@tools.ietf.org
Subject: Re: [apps-discuss] Apps Area Review for draft-ietf-geopriv-held-measurements-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2013 00:00:37 -0000

Hi Eliot,

Thanks for the review.  I think that you caught a few important things here=
.

And now time for my much-belated response (sorry about that).  A draft
revision will follow in due course; hopefully in less time than this
response.

On 26 March 2013 07:29, Eliot Lear <lear@cisco.com> wrote:
> I'd suggest that this draft receive additional review regarding its priva=
cy
> considerations section.  I will comment outside this review regarding tha=
t
> issue, as this is an apps area review.  Also, I've not done schema
> validation.

Hmm, I'd be interested to hear about what you consider to be
problematic with the privacy considerations.  We put a lot of thought
into those.  Obviously, this is potentially highly sensitive, but I
thought we'd hit the important considerations.

> Major issues:
>
> =C2=A7 4.3, page 10: I realize it'd be silly to write a six line RFC for =
this,
> but the semantics of the HELD examples seem normative.  I think it's
> appropriate for them to be so, but then you should make it more explicit.
> Same with your XMPP example.

I don't see how you could infer that the example is normative from
this.  The examples throughout were always intended to be illustrative
only.

I can see how you might want to have a separate document for the
measurement "request", such as it is, but that doesn't fare especially
well outside of the context of the document, so we decided to keep
this together with the measurement definitions.

I didn't get the XMPP comment until I saw your nit on it.  This isn't
actually XMPP, it's a presence document format (PIDF) that is shared
by SIMPLE (SIP), XMPP and geopriv.  PIDF-LO is the location extension,
and protocol agnostic in that sense.

> Minor issues:
>
> =C2=A74.1, 2nd para on page 7.  While surely this is applicable for HELD,=
 there
> are protocols that have size considerations, and so your assertion is a b=
it
> strong, and I would suggest that you scope it to be applicable where XML =
can
> be carried.(*)

That is true, the assertion is a wee bit strong.  I'll add "a request
for location information in any protocol capable of carrying XML",
which includes carrying it by reference, at least in theory ;)

> =C2=A74.4 Page 11, last paragraph.  It's not quite clear how the example =
combines
> information in the LIS.  Maybe it's because I'm not steeped in location
> lore, so perhaps you might point this out to me, if not others?

The first <tuple> element contains a child
       <lmsrc:source>lis device</lmsrc:source>
The second:
       <lmsrc:source>lis</lmsrc:source>

I don't quite know how to make this clearer.  (It would be clearer if
the XML were smaller, but that is the smallest valid PIDF-LO I could
construct :/ )

> =C2=A78.3, Page 44: there has got to be an existing schema one can borrow=
 IP
> addresses from, no?  If not, is this worth splitting off?

I truly wish that there were an existing spec.  I'm not sure that I
can justify the effort involved in making a split.  Especially since
we seem to be moving away from XML schema en masse.  I would still be
supportive of an attempt to do this.

> Finally, see RFC 2026 for proper use of normative references.  You're
> referencing 802.11v as an informative reference when in fact flightTime
> depends on TOD and TOA from that spec.  And you're normatively referencin=
g
> RFC 20 (you were just aching to get that one in there) when the ASCII
> reference is more than sufficient (btw, if you're using xml2rfc you're
> looking for ANSI.X3-4.1986).

Thanks for picking up the 11v reference.

Yeah, someone pinged me on an RFC 20 reference in a different review.
It was the best I could find at the time I originally drafted the
document almost a decade ago.

> I get the following normative:
>
> [ASCII], [RFC3629],  [RFC5985], [RFC2119], [RFC4119], [IEEE.8021AB],
> [RFC3046], [RFC4649], [RFC3993], [RFC4580], [IANA.enterprise], [RFC3986],
> [RFC4291], [IEEE.80211], [RFC5491], [TS.3GPP.23.003], [TIA-2000.5],
> [GPS.ICD], [GALLILEO.ICD], [RFC2865], [IEEE.80211V]
>
> The following are Informative:
>
> [RFC3693], [RFC6155], [ANSI-TIA-1057], [RFC2661], [HARPER], [GPS.SPOOF],
> [RFC5226], [RFC3688], [DSL.TR025], [DSL.TR101]

Thanks for catching 2661.
5226 is normative in the sense that it defines the rules for the
registries that the document establishes.

> N.B.: regarding TRs 25 and 101, if you meant that other parameters could
> somehow be pulled in as responses, then more work needs to be done in the
> draft on this point to specify them.

I believe that TR101 and 25 are informative only.  They describe
deployment architectures.

> Nits:

All done.  Much thanks.

> Page 5, first paragraph, has some extraneous characters (\u002D).

A regression in xml2rfc :)  It no longer converts &mdash; properly.

> idnits indicates that there are 7 instances of lines that are too long, a=
nd

Another damned regression in xml2rfc.  I mentioned this on
tools-discuss a while back.

From martin.thomson@gmail.com  Wed Apr 10 17:01:56 2013
Return-Path: <martin.thomson@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D7B21F863A; Wed, 10 Apr 2013 17:01:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIkSNl+DHdzl; Wed, 10 Apr 2013 17:01:56 -0700 (PDT)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1792B21F8629; Wed, 10 Apr 2013 17:01:55 -0700 (PDT)
Received: by mail-we0-f180.google.com with SMTP id r5so784492wey.11 for <multiple recipients>; Wed, 10 Apr 2013 17:01:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZswgOWFeasg/wfmG5b0lL5ej4GjURc5euxTg5sS+99w=; b=bniN9W9khICxdcKSFBqwMjlb/vpcWEwbIxEFo9Dw700mPtumoWLiAe4nd6SZmxJ85k K7l5oQclUwaoQy+s31T3dSNIv6TqXndYOFq1cwqVvcj372c9sk5jQ73EhavT5nw4eS73 eITbLCIRcOYQnHG8QZmZjz0ODDdpToxbm/BAaY9jRGQKNmhxERp5kI9UWym0LL2p8kyL XFezkLqtTxuZLKfWbR0OR88g6PH3dEWkZRFic4lAPT2BLtEJ5LzT+wLA9wlry41BFgFR Uufgb+L68s36nd92MIYExoPDJM0foi6LyBoHLcMMOvew3NQZlq9JNUt4sJXe8WFKNjuC K/JQ==
MIME-Version: 1.0
X-Received: by 10.180.79.227 with SMTP id m3mr6598844wix.12.1365638515085; Wed, 10 Apr 2013 17:01:55 -0700 (PDT)
Received: by 10.194.41.35 with HTTP; Wed, 10 Apr 2013 17:01:55 -0700 (PDT)
In-Reply-To: <CABkgnnWNPMgsNACjOYdxcn3VW20LFOOS5XeFO9Nifxv2hJTwUg@mail.gmail.com>
References: <5151B0B5.2090407@cisco.com> <CABkgnnWNPMgsNACjOYdxcn3VW20LFOOS5XeFO9Nifxv2hJTwUg@mail.gmail.com>
Date: Wed, 10 Apr 2013 17:01:55 -0700
Message-ID: <CABkgnnXr0LnSbtaLmQwvEyVq3wKzBRBT4s4cV6428oGvd33kWA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Eliot Lear <lear@cisco.com>
Content-Type: text/plain; charset=UTF-8
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, IESG <iesg@ietf.org>, draft-ietf-geopriv-held-measurements.all@tools.ietf.org
Subject: Re: [apps-discuss] Apps Area Review for draft-ietf-geopriv-held-measurements-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2013 00:01:57 -0000

On 10 April 2013 17:00, Martin Thomson <martin.thomson@gmail.com> wrote:
> 5226 is normative in the sense that it defines the rules for the
> registries that the document establishes.

Oops, I was wrong about 5226 and forgot to check before hitting send.
Scratch that comment.

From yngve@spec-work.net  Wed Apr 10 09:09:50 2013
Return-Path: <yngve@spec-work.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693F621F9976; Wed, 10 Apr 2013 09:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlJ7REp7XnLg; Wed, 10 Apr 2013 09:09:49 -0700 (PDT)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id BBFC621F9977; Wed, 10 Apr 2013 09:09:48 -0700 (PDT)
Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:51560 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <yngve@spec-work.net>) id 1UPxaj-0004Ft-MS; Wed, 10 Apr 2013 18:09:45 +0200
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Peter Saint-Andre" <stpeter@stpeter.im>
References: <5165610C.1020803@stpeter.im> <op.wvbvjzd83dfyax@killashandra.invalid.invalid> <51658870.8070806@stpeter.im>
Date: Wed, 10 Apr 2013 18:09:42 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: Quoted-Printable
From: "Yngve N. Pettersen" <yngve@spec-work.net>
Message-ID: <op.wvb1ugim3dfyax@killashandra.invalid.invalid>
In-Reply-To: <51658870.8070806@stpeter.im>
User-Agent: Opera Mail/12.15 (Win32)
X-Mailman-Approved-At: Wed, 10 Apr 2013 18:13:36 -0700
Cc: draft-ietf-tls-multiple-cert-status-extension.all@tools.ietf.org, The IESG <iesg@ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-tls-multiple-cert-status-extension-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2013 16:09:50 -0000

Hi,

On Wed, 10 Apr 2013 17:42:40 +0200, Peter Saint-Andre <stpeter@stpeter.i=
m>  =

wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Yngve!
>
> On 4/10/13 7:53 AM, Yngve N. Pettersen wrote:
>> Hi Peter and Bert,
>>
>> Thanks for the review.
>>
>> On Wed, 10 Apr 2013 14:54:36 +0200, Peter Saint-Andre
>> <stpeter@stpeter.im> wrote:
>>
>>> Bert Greevenbosch and I have been selected as the joint
>>> Applications Area Directorate reviewers for this draft (for
>>> background on AppsDir, please see =E2=80=8B
>>> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirect=
orate
>>>
>>>
> ).
>>>
>>> Please resolve these comments along with any other Last Call
>>> comments you may receive. Please wait for direction from your
>>> document shepherd or AD before posting a new version of the
>>> draft.
>>>
>>> Document: draft-ietf-tls-multiple-cert-status-extension-05 Title:
>>> The TLS Multiple Certificate Status Request Extension Reviewers:
>>> Bert Greevenbosch and Peter Saint-Andre Review Date: 10 April
>>> 2013 IESG Telechat Date: 2013-04-11 Summary: This draft is almost
>>> ready for publication; comments raised here are for the WG's
>>> consideration.
>>>
>>> Major Issues:
>>>
>>> none
>>>
>>> Minor Issues:
>>>
>>> (1) Maybe a server can maintain cached OCSP responses, e.g. until
>>> after the "nextUpdate" time has expired. Then the server would be
>>> able to use these cached responses instead of acquiring a new
>>> response from the OCSP-responders. (This mechanism is e.g.
>>> defined in [OCSP-MP]). With the new extension, multiple
>>> OCSP-responses from probably different OCSP servers could be
>>> cached. The client needs to verify that each of the OCSP response
>>> is still valid, e.g. that none of the OCSP-responses are too
>>> old.
>>>
>>> [OCSP-MP]: OMA Online Certificate Status Protocol (profile of
>>> [OCSP]) V 1.0, Open Mobile Alliance,
>>> URL:http://www.openmobilealliance.org/
>>>
>>> Would some text about cached OCSP responses be appropriate? (Of
>>> course nonces would make caching impossible, as each OCSP
>>> responder would need to sign the new nonce.)
>>
>> The server would not know if the client have cached the response,
>> and the client would not know if there is a newer response held by
>> the server.
>>
>> The client could leave the request for certificate status out of
>> the handshake, but that would mean that 1) it would not get any
>> updated responses, and 2) if the serve changed its certificate(s)
>> between the previous handshake and the current handshake, it would
>> also not get the new responses, since it did not signal the
>> willingness to receive them.
>>
>> Resolving of that lack of information would require some kind of
>> signaling mechanism, which I think is outside the scope of this
>> particular document.
>>
>> At present, discussion is underway in the TLS WG of adding such a
>> mechanism to the draft-ietf-tls-cached-info
>> <http://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/>. If
>> implemented, that would resolve the signaling mechanism problem,
>> and combine it with a more general mechanism.
>
> Thanks for the pointer to draft-ietf-tls-cached-info. I suppose that,
> if implemented, it might lead to some changes in several TLS-related
> specs, including this one. Correct?

To the extent that there are changes, those would be documented in the  =

cached-info spec, and would depend on the granularity at which data are =
 =

cached.

There would be no change for implementations that does not include  =

cached-info, even if the other party does implement it. Any changes woul=
d  =

only apply when both parties implement cached-info.

>>> (2) Section 2.2, p.5:
>>>
>>> A zero-length "request_extensions" value means that there are no
>>> extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is
>>> not valid for the "Extensions" type).
>>>
>>> This text was copied from RFC 6066. It seems a bit cryptic, but
>>> I suppose it means that the "request_extensions" field does not
>>> exist at all, e.g. the "OCSPStatusRequest" struct only contains
>>> the "responder_id_list<0..2^16-1>"?
>>
>> The record would still contain two zero bytes to indicate the
>> length of the request_extensions vector (the length-field of the
>> vector is not part of the content); the zerolength ASN1.1 SEQUENCE
>> would require a non-zero-length request_extensions field since the
>> field would contain a <SEQUENCE-indication + 0 byte length field>
>> in ASN.1 DER encoding, which would likely be one or two bytes
>> long.
>
> Thanks for the clarification. Would it make sense to add a small note
> to draft-ietf-tls-multiple-cert-status-extension on this point?

I am inclined to think it is not necessary, as I think the requirements =
 =

are clear from the syntax, particularly the use of the "opaque" type.  =

Implementors need to be familiar with both TLS record syntax in order to=
  =

write the code, and the content would have to be generated by some ASN.1=
  =

generator code.

Errors in the first would in particular quickly run into problems with  =

other implementations (unless it happens in the first implementation and=
  =

that implementation gains major marketshare before the problem is  =

discovered; which have happened in SSL/TLS history at least twice IIRC).=
  =

Given that this record is already used in RFC 6066 which is deployed by =
 =

many clients and servers, and I assume the code for this structure will =
be  =

reused, I don't think we are going to see a problem.

However, I did decide to add "DER-encoded" in front of "zero-length ASN.=
1  =

SEQUENCE" to indicate that we are talking about a payload.

>>> (3) Section 2.2, p.6:
>>>
>>> Note that a server MAY also choose not to send a
>>> "CertificateStatus" message, even if it has received a
>>> "status_request_v2" extension in the client hello message and has
>>> sent a "status_request_v2" extension in the server hello
>>> message.
>>>
>>> In essence, this says that it is optional for the server to send
>>> the "CertificateStatus" message. What are the types of conditions
>>> under which it is reasonable to not send the "CertificateStatus"
>>> message?
>>
>> The supporting server might not yet have downloaded an OCSP
>> response. That is, for example, the case with nginx versions able
>> to use RFC 6066 OCSP Stapling. Those servers also have a bug which
>> makes them forward an expired OCSP response while they are fetching
>> the new one, rather than discarding it.
>>
>> In such cases the server can either wait until it receive the
>> response (which might mean a long wait for the client if the
>> responder is slow), or it can leave out the status message in
>> connections it is establishing until it have received the OCSP
>> response.
>
> That makes sense. Explaining that in the spec might make sense, since
> otherwise implementers might think there are other good reasons to not=

> send the "CertificateStatus" message.

However, a general reason for not sending the actual message is that the=
  =

server might know that it can send the message, but does not discover  =

until it is about to set up the message that it cannot send it.

One scenario is that the server does not know that its certificate(s) do=
es  =

not specify OCSP until it tries to get it. One could call that bad desig=
n,  =

but it could also be based on reducing code complexity (e.g., don't  =

involve the certificate parsing code when I am building the server hello=
)

-- =

Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

From lear@cisco.com  Thu Apr 11 00:26:16 2013
Return-Path: <lear@cisco.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3788021F8EC1; Thu, 11 Apr 2013 00:26:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.059
X-Spam-Level: 
X-Spam-Status: No, score=-110.059 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaoIwuyFTBSP; Thu, 11 Apr 2013 00:26:15 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 310EE21F8EBF; Thu, 11 Apr 2013 00:26:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1176; q=dns/txt; s=iport; t=1365665175; x=1366874775; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=D6fucl2W5chUfkuqVFIl9B/YLqtWpnUt0Qk9udOwTSA=; b=BcjF33stW0Jz+lAviklPMovbzf8U3tWRyxVgpJ+6zLBMj9gFgVF8NHMJ RGhRNkD1+p74eBEYdblOm5lLs1z9ipVHr1iyUrPEBun61VkVd8SmjzRs/ Tl2d1hW929ZKP7s/MRWxaWbSXz1LnGiP4lz5w9liTbGG8eRgQ3mA8gW86 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicFAOVkZlGQ/khM/2dsb2JhbABQgwaDZL4dgQEWdIIfAQEBAwEjDwFGEAsaAgUhAgIPAiwaBg0BBwEBiAoGrBySfIEjjXMHgi6BEwOXAJEOgVWBODo
X-IronPort-AV: E=Sophos;i="4.87,454,1363132800"; d="scan'208";a="13255037"
Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 11 Apr 2013 07:26:12 +0000
Received: from mctiny.local ([10.61.162.228]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3B7Q9Oq000513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Apr 2013 07:26:09 GMT
Message-ID: <51666591.30208@cisco.com>
Date: Thu, 11 Apr 2013 09:26:09 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Martin Thomson <martin.thomson@gmail.com>
References: <5151B0B5.2090407@cisco.com> <CABkgnnWNPMgsNACjOYdxcn3VW20LFOOS5XeFO9Nifxv2hJTwUg@mail.gmail.com>
In-Reply-To: <CABkgnnWNPMgsNACjOYdxcn3VW20LFOOS5XeFO9Nifxv2hJTwUg@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, IESG <iesg@ietf.org>, draft-ietf-geopriv-held-measurements.all@tools.ietf.org
Subject: Re: [apps-discuss] Apps Area Review for draft-ietf-geopriv-held-measurements-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2013 07:26:16 -0000

Hi Martin,

All my other review comments are satisfied, save just one:

On 4/11/13 2:00 AM, Martin Thomson wrote:

>> Major issues:
>>
>> § 4.3, page 10: I realize it'd be silly to write a six line RFC for this,
>> but the semantics of the HELD examples seem normative.  I think it's
>> appropriate for them to be so, but then you should make it more explicit.
>> Same with your XMPP example.
> I don't see how you could infer that the example is normative from
> this.  The examples throughout were always intended to be illustrative
> only.

Sorry I meant that you are honing in on HELD even outside of the
specific example.

>
> I can see how you might want to have a separate document for the
> measurement "request", such as it is, but that doesn't fare especially
> well outside of the context of the document, so we decided to keep
> this together with the measurement definitions.

That's right, and I don't think you should create a separate spec.  Now
it's been a while since I did the review but I recall traipsing through
HELD to try to determine whether in fact this spec updates that spec. 
If so that should be indicated.

Eliot



From fgaliegue@gmail.com  Thu Apr 11 06:54:02 2013
Return-Path: <fgaliegue@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B3921F8AE7 for <apps-discuss@ietfa.amsl.com>; Thu, 11 Apr 2013 06:54:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOzOj0fq3FsR for <apps-discuss@ietfa.amsl.com>; Thu, 11 Apr 2013 06:54:00 -0700 (PDT)
Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC8321F8D0F for <apps-discuss@ietf.org>; Thu, 11 Apr 2013 06:53:59 -0700 (PDT)
Received: by mail-ee0-f41.google.com with SMTP id c1so799495eek.28 for <apps-discuss@ietf.org>; Thu, 11 Apr 2013 06:53:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=T/Z0pSyNVIvVx3G7/p2XLV2AenxZ6UyGKKxuWBmNwxY=; b=uK0dCQ7OvKLJBSNERc/31dwuf5vJlF4lyLnNZeqBftRwGLNx6eIUrfHDJ8bd3i4csD AiAeeAEahfanZvoSo2b23smCUzk6EigXpY5hsHMzZlbvZJuBZjWN1xxz8dyOOgIuUhIl vuK1+wFmWpjCFlR1yKPjdk4NxLX5CHgZM5UVZAXEXBINEbfRhJVhwjipfqkQ7wISHWI4 5DCNTjv4tKE9m0/WOjZzmkWFhgFTMOtp2iBEOww3ReOom00F2yv6vhD004zh5CTWTHJ1 LWk8lJq/QkWHeJRwvsCexvzS4hWVL64/6iGu1hVB0iI/Cxknu68suNmAoOSZyWhsihva 3yPw==
MIME-Version: 1.0
X-Received: by 10.14.179.201 with SMTP id h49mr17208905eem.26.1365688438663; Thu, 11 Apr 2013 06:53:58 -0700 (PDT)
Received: by 10.14.213.4 with HTTP; Thu, 11 Apr 2013 06:53:58 -0700 (PDT)
In-Reply-To: <CAL0qLwaoaYbnHiYCuxC050Yn=G3C5skG5m9mkb_SvO0Yhkf8hw@mail.gmail.com>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com> <CALcybBCeyJce+m7GB8ak_Wmwfk6+Z=bcaDKs489H0v4vLOgahw@mail.gmail.com> <CABP7RbfLQ5wCTNEJ4ufEs76YoVBePP8JYLQkjgUHJQ-o3=pUeg@mail.gmail.com> <CAL0qLwYsVt63VAtg0yqG=KDO7e1DvmE-8ywXM8CBqrt8mxDZOA@mail.gmail.com> <CABP7RbfDOS4pdnx5Z4arwLw8demRfKrT4bE+Jb4uzvcdgzKRfw@mail.gmail.com> <CAL0qLwaoaYbnHiYCuxC050Yn=G3C5skG5m9mkb_SvO0Yhkf8hw@mail.gmail.com>
Date: Thu, 11 Apr 2013 15:53:58 +0200
Message-ID: <CALcybBB11EENT6dbxy0Wgb2cVUmuhxbnKOuVirvjd++R6f=5QA@mail.gmail.com>
From: Francis Galiegue <fgaliegue@gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, Joe Gregorio <joe@bitworking.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2013 13:54:02 -0000

On Mon, Apr 8, 2013 at 10:40 PM, Murray S. Kucherawy
<superuser@gmail.com> wrote:
[...]
>
> Everywhere else in the document refers to a list as (value[, value[, ...]]).
> So it seems to me "()" is the empty list, while "[]" is not.
>

Then what would it be? There is no empty list defined at all in the
RFC examples.

I agree that there should be an errata, defining expansion behaviour
for all of these corner cases. Right now, only the tests at
https://github.com/uri-templates/uritemplate-test make any mention of
it and there seems to be a disagreement on how these should be
handled.

--
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com

From martin.thomson@gmail.com  Thu Apr 11 10:14:40 2013
Return-Path: <martin.thomson@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94EB21F920B; Thu, 11 Apr 2013 10:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level: 
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAMReNXdksTe; Thu, 11 Apr 2013 10:14:40 -0700 (PDT)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8ED21F91D8; Thu, 11 Apr 2013 10:14:39 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id d46so1389200wer.2 for <multiple recipients>; Thu, 11 Apr 2013 10:14:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=p42cJ5gdCxeuM+96SVnpmnca9e3S1VGegInY//q/dEA=; b=JNttpGdvFgw1HQu29LFHDmdwjuiwDST0psMg4lS6Uz9cAg28dCUHy/sJG/+tAoX7s+ Wuj/Hk4y/+DiSuTHHJOFDRIsU8ZOBtdeq/JbxGhWrA5sSDFx3ttgOPsYFqGPJMnep4EE 2WY4kskvsOFriJKP63ytLS4zB5b0evgKIspowaCh8akuuWmtA2B0P22j9+otbdUBAveS G8WD4QoyTQxCr2Xwdro5l6ZzTIolBpZwbqLY76hUyVCokemZ8UqfX2dB/6H5mpCYYMyX 4H1NaPY9N+3srjipOQiXFES/EEYCBB4nZfBqrPJi8j1fwKJM11oXldB9Lkh6/L7kUlSS 6fjA==
MIME-Version: 1.0
X-Received: by 10.180.72.228 with SMTP id g4mr35448359wiv.22.1365700478681; Thu, 11 Apr 2013 10:14:38 -0700 (PDT)
Received: by 10.194.41.35 with HTTP; Thu, 11 Apr 2013 10:14:38 -0700 (PDT)
In-Reply-To: <51666591.30208@cisco.com>
References: <5151B0B5.2090407@cisco.com> <CABkgnnWNPMgsNACjOYdxcn3VW20LFOOS5XeFO9Nifxv2hJTwUg@mail.gmail.com> <51666591.30208@cisco.com>
Date: Thu, 11 Apr 2013 10:14:38 -0700
Message-ID: <CABkgnnUFXQ-hH1n8onJzRVPDWsoVXo=uQ75mV639gKrFqCSXSA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Eliot Lear <lear@cisco.com>
Content-Type: text/plain; charset=UTF-8
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, IESG <iesg@ietf.org>, draft-ietf-geopriv-held-measurements.all@tools.ietf.org
Subject: Re: [apps-discuss] Apps Area Review for draft-ietf-geopriv-held-measurements-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2013 17:14:40 -0000

On 11 April 2013 00:26, Eliot Lear <lear@cisco.com> wrote:
> Sorry I meant that you are honing in on HELD even outside of the
> specific example.

Ah yes, I am painfully aware of the sampling bias that arises from a
sample set of one.  However, that's what we have and it wouldn't be
practical to pretend otherwise.  Maybe there needs to be a disclaimer
along the lines of:

"This document attempts to provide generic capabilities that apply to
any location request protocol.  In practice however, only the HELD
protocol [RFC5985] has been considered.  Use of these capabilities in
other protocols could require additional adaptation."

Though that would be a small lie.  Other protocols have been
considered.  I'm aware of at least 3 that could use these
capabilities.  I just don't think that any of those protocols wants
these extensions (for a range of other reasons).

>> I can see how you might want to have a separate document for the
>> measurement "request", such as it is, but that doesn't fare especially
>> well outside of the context of the document, so we decided to keep
>> this together with the measurement definitions.
>
> That's right, and I don't think you should create a separate spec.  Now
> it's been a while since I did the review but I recall traipsing through
> HELD to try to determine whether in fact this spec updates that spec.
> If so that should be indicated.

Ah yes, our document shepherd asked this same question, to wit I
answered: This draft exercises extension points established by <the
document in question: RFC5985> and therefore does not need to update
that document.

We knew about this work when we published HELD, so made sure that the
extension points were available.

From mike5guo@gmail.com  Thu Apr 11 15:27:22 2013
Return-Path: <mike5guo@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CC321F8574 for <apps-discuss@ietfa.amsl.com>; Thu, 11 Apr 2013 15:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, J_CHICKENPOX_53=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2gLMwzz-orI for <apps-discuss@ietfa.amsl.com>; Thu, 11 Apr 2013 15:27:22 -0700 (PDT)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 42B8821F8573 for <apps-discuss@ietf.org>; Thu, 11 Apr 2013 15:27:22 -0700 (PDT)
Received: by mail-ob0-f171.google.com with SMTP id v19so1844751obq.16 for <apps-discuss@ietf.org>; Thu, 11 Apr 2013 15:27:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=D5JFqVWtzoewGDyCKQksix1xMruR9bjkoeHLgysPVNc=; b=LrLYm3aCO+YHJ2309+97W1KYOffpLPFVq6FI+pwmlRTFrhCTCYEvD4OG1EU8XvZQOC iAg9c8l2PTsww9eQpP0O+4gCrB0yTGlj88+3CUgYRbu5OES9axLJLtxKNKE/2wSTFmoA /WV8qDXyTO21wFqFCj+rysDvyrSlAUDS+4h0oEzg9zc2sHopnl0Gb3Ckaa3PHRPUoBlq Lz3PTm2QB21ScnP2VStZ2z2t4bblHT21xNxmed395zDLQUHwxIeXCGmIlTRlJFX7TRzK T9BPs6BDWnJoZZQRchlNBlaA9ci8VtdmVWWUqIE3AqTomxGqa0hfG2pk17deqOIwyD4h zlcg==
MIME-Version: 1.0
X-Received: by 10.60.50.102 with SMTP id b6mr2968387oeo.46.1365719241790; Thu, 11 Apr 2013 15:27:21 -0700 (PDT)
Received: by 10.182.217.6 with HTTP; Thu, 11 Apr 2013 15:27:21 -0700 (PDT)
Date: Fri, 12 Apr 2013 06:27:21 +0800
Message-ID: <CAMFEDe41d8xi0d7a2R=GwYD55m1G-DMV8A7++SH0q-BeoCYBMA@mail.gmail.com>
From: Zhun Guo <mike5guo@gmail.com>
To: apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=001a11c1d64c451d5304da1d4a07
Subject: [apps-discuss] Apply for WG draft:The Interconnection and Interoperability of Different Cloud-office Applications (IDCOA) with the HTML File Format
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2013 22:27:22 -0000

--001a11c1d64c451d5304da1d4a07
Content-Type: text/plain; charset=ISO-8859-1

Dear All:
    I apply my draft to be a WG draft. Please give me more help!Thanks!

Zhun Guo

A new version of I-D, draft-guo-idoca-with-the-html-file-format-00.txt
has been successfully submitted by Zhun Guo and posted to the
IETF repository.

Filename:        draft-guo-idoca-with-the-html-file-format
Revision:        00
Title:           The Interconnection and Interoperability of Different
Cloud-office Applications (IDCOA) with the HTML File Format
Creation date:   2013-03-22
Group:           Individual Submission
Number of pages: 5
URL:
http://www.ietf.org/internet-drafts/draft-guo-idoca-with-the-html-file-format-00.txt
Status:
http://datatracker.ietf.org/doc/draft-guo-idoca-with-the-html-file-format
Htmlized:
http://tools.ietf.org/html/draft-guo-idoca-with-the-html-file-format-00


Abstract:
   At present, the collaboration of documents in a single cloud-office
   Website works wonderfully.  However, the one among different cloud-
   office websites is a little clumsy.  This document analyzes the
   status quo of the collaboration of documents among those existing
   different cloud-office websites and provides a solution how to
   realize IDCOA (the interconnection and interoperability of different
   cloud-office applications) with the html file format.




The IETF Secretariat

--001a11c1d64c451d5304da1d4a07
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Dear All:<div style>=A0 =A0 I apply my draft to be a WG dr=
aft. Please give me more help!Thanks!</div><div style><br></div><div style>=
Zhun Guo</div><div style><br></div><div style><span style=3D"font-family:ar=
ial,sans-serif;font-size:18px">A new version of I-D, draft-guo-idoca-with-t=
he-html-</span><span style=3D"font-family:arial,sans-serif;font-size:18px">=
file-format-00.txt</span><br style=3D"font-family:arial,sans-serif;font-siz=
e:18px">
<span style=3D"font-family:arial,sans-serif;font-size:18px">has been succes=
sfully submitted by Zhun Guo and posted to the</span><br style=3D"font-fami=
ly:arial,sans-serif;font-size:18px"><span style=3D"font-family:arial,sans-s=
erif;font-size:18px">IETF repository.</span><br style=3D"font-family:arial,=
sans-serif;font-size:18px">
<br style=3D"font-family:arial,sans-serif;font-size:18px"><span style=3D"fo=
nt-family:arial,sans-serif;font-size:18px">Filename: =A0 =A0 =A0 =A0draft-g=
uo-idoca-with-the-html-</span><span style=3D"font-family:arial,sans-serif;f=
ont-size:18px">file-format</span><br style=3D"font-family:arial,sans-serif;=
font-size:18px">
<span style=3D"font-family:arial,sans-serif;font-size:18px">Revision: =A0 =
=A0 =A0 =A000</span><br style=3D"font-family:arial,sans-serif;font-size:18p=
x"><span style=3D"font-family:arial,sans-serif;font-size:18px">Title: =A0 =
=A0 =A0 =A0 =A0 The Interconnection and Interoperability of Different Cloud=
-office Applications (IDCOA) with the HTML File Format</span><br style=3D"f=
ont-family:arial,sans-serif;font-size:18px">
<span style=3D"font-family:arial,sans-serif;font-size:18px">Creation date: =
=A0 2013-03-22</span><br style=3D"font-family:arial,sans-serif;font-size:18=
px"><span style=3D"font-family:arial,sans-serif;font-size:18px">Group: =A0 =
=A0 =A0 =A0 =A0 Individual Submission</span><br style=3D"font-family:arial,=
sans-serif;font-size:18px">
<span style=3D"font-family:arial,sans-serif;font-size:18px">Number of pages=
: 5</span><br style=3D"font-family:arial,sans-serif;font-size:18px"><span s=
tyle=3D"font-family:arial,sans-serif;font-size:18px">URL: =A0 =A0 =A0 =A0 =
=A0 =A0=A0</span><a href=3D"http://www.ietf.org/internet-drafts/draft-guo-i=
doca-with-the-html-file-format-00.txt" target=3D"_blank" style=3D"font-fami=
ly:arial,sans-serif;font-size:18px">http://www.ietf.org/internet-drafts/dra=
ft-guo-idoca-with-the-html-file-format-00.txt</a><br style=3D"font-family:a=
rial,sans-serif;font-size:18px">
<span style=3D"font-family:arial,sans-serif;font-size:18px">Status: =A0 =A0=
 =A0 =A0 =A0</span><a href=3D"http://datatracker.ietf.org/doc/draft-guo-ido=
ca-with-the-html-file-format" target=3D"_blank" style=3D"font-family:arial,=
sans-serif;font-size:18px">http://datatracker.ietf.org/doc/draft-guo-idoca-=
with-the-html-file-format</a><br style=3D"font-family:arial,sans-serif;font=
-size:18px">
<span style=3D"font-family:arial,sans-serif;font-size:18px">Htmlized: =A0 =
=A0 =A0 =A0</span><a href=3D"http://tools.ietf.org/html/draft-guo-idoca-wit=
h-the-html-file-format-00" target=3D"_blank" style=3D"font-family:arial,san=
s-serif;font-size:18px">http://tools.ietf.org/html/draft-guo-idoca-with-the=
-html-file-format-00</a><br style=3D"font-family:arial,sans-serif;font-size=
:18px">
<br style=3D"font-family:arial,sans-serif;font-size:18px"><br style=3D"font=
-family:arial,sans-serif;font-size:18px"><span style=3D"font-family:arial,s=
ans-serif;font-size:18px">Abstract:</span><br style=3D"font-family:arial,sa=
ns-serif;font-size:18px">
<span style=3D"font-family:arial,sans-serif;font-size:18px">=A0 =A0At prese=
nt, the collaboration of documents in a single cloud-office</span><br style=
=3D"font-family:arial,sans-serif;font-size:18px"><span style=3D"font-family=
:arial,sans-serif;font-size:18px">=A0 =A0Website works wonderfully. =A0Howe=
ver, the one among different cloud-</span><br style=3D"font-family:arial,sa=
ns-serif;font-size:18px">
<span style=3D"font-family:arial,sans-serif;font-size:18px">=A0 =A0office w=
ebsites is a little clumsy. =A0This document analyzes the</span><br style=
=3D"font-family:arial,sans-serif;font-size:18px"><span style=3D"font-family=
:arial,sans-serif;font-size:18px">=A0 =A0status quo of the collaboration of=
 documents among those existing</span><br style=3D"font-family:arial,sans-s=
erif;font-size:18px">
<span style=3D"font-family:arial,sans-serif;font-size:18px">=A0 =A0differen=
t cloud-office websites and provides a solution how to</span><br style=3D"f=
ont-family:arial,sans-serif;font-size:18px"><span style=3D"font-family:aria=
l,sans-serif;font-size:18px">=A0 =A0realize IDCOA (the interconnection and =
interoperability of different</span><br style=3D"font-family:arial,sans-ser=
if;font-size:18px">
<span style=3D"font-family:arial,sans-serif;font-size:18px">=A0 =A0cloud-of=
fice applications) with the html file format.</span><br style=3D"font-famil=
y:arial,sans-serif;font-size:18px"><br style=3D"font-family:arial,sans-seri=
f;font-size:18px">
<br style=3D"font-family:arial,sans-serif;font-size:18px"><br style=3D"font=
-family:arial,sans-serif;font-size:18px"><br style=3D"font-family:arial,san=
s-serif;font-size:18px"><span style=3D"font-family:arial,sans-serif;font-si=
ze:18px">The IETF Secretariat</span><br>
</div></div>

--001a11c1d64c451d5304da1d4a07--

From ted.ietf@gmail.com  Thu Apr 11 15:51:05 2013
Return-Path: <ted.ietf@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8E121F8935 for <apps-discuss@ietfa.amsl.com>; Thu, 11 Apr 2013 15:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.274
X-Spam-Level: 
X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56sN2Y5W1a0w for <apps-discuss@ietfa.amsl.com>; Thu, 11 Apr 2013 15:51:03 -0700 (PDT)
Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9616521F8842 for <apps-discuss@ietf.org>; Thu, 11 Apr 2013 15:51:01 -0700 (PDT)
Received: by mail-ia0-f171.google.com with SMTP id f27so7280iae.16 for <apps-discuss@ietf.org>; Thu, 11 Apr 2013 15:51:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=hKMTqw/3cppzHKdB2bmIh+atzRgdotcqUbVm1SLzCdI=; b=IhV/3cQTPs9/dn+1iSEEZf9EoLQlPZxguhuSZKiIXF5FDGweUPaY99IQ8j9yo4oXGl hPTWQV72BZYkNdeW7ICl8ezKd6gL8Vr63m++6SCv/mnF2cAkWBipgDhihfy04UMxCvfl vymLN8nrPJc6r9Rdk+0YYiPGaK8PtKRyApVlelU9IGEooc54+4Y7Z2Wx7UoN/2xAYMpy wWVXkfCbN98frneFCLQlwu/iVHzmEO829rO8Agy9ocVT6ovlaMhUZQZ6WdKgcH6GRRXH qWfQc6NNNrm01aPCUyNdr3qzZVn0L94Vp4y8P2tMnxotbsqarNhqiigIhs9WMMFg+xyK iZ2Q==
MIME-Version: 1.0
X-Received: by 10.50.27.10 with SMTP id p10mr114067igg.20.1365720661111; Thu, 11 Apr 2013 15:51:01 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Thu, 11 Apr 2013 15:51:00 -0700 (PDT)
Date: Thu, 11 Apr 2013 15:51:00 -0700
Message-ID: <CA+9kkMDEc1mX77eRYMXPBKnH9X+jOXGVD7pVFArkwSwNsF+wMA@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: apps-discuss@ietf.org, draft-ietf-6renum-gap-analysis.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=047d7b10cd29de865504da1d9ec2
Subject: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Apr 2013 22:51:05 -0000

--047d7b10cd29de865504da1d9ec2
Content-Type: text/plain; charset=ISO-8859-1

I have been selected as the Applications Area Directorate reviewer
for this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:draft-ietf-6renum-gap-analysis-05
Title: IPv6 Site Renumbering Gap Analysis
Reviewer: Ted Hardie
Review Date: April 11, 2013

Summary: This document is basically ready to be published as an
Informational draft.  There are minor issues which the authors may wish to
address before final publication.


Minor Issues:

The document currently motivates its work with the following statement:

   If IPv6 site renumbering continues to be considered
   difficult, network managers will turn to Provider Independent (PI)
   addressing for IPv6 to attempt to minimize the need for future
   renumbering. However, widespread use of PI may create very serious
   BGP4 scaling problems. It is thus desirable to develop tools and
   practices that may make renumbering a simpler process to reduce
   demand for IPv6 PI space.

A citation for this would be useful.  It might also be worth it to
highlight other potential risks--for example, the widespread deployment
of ULAs, which do not admit of aggregation, or the deployment of

address translation technologies which make referral more difficult.  I note
that RFC 5887 included some of these issues.  If the intent is to reference
those from RFC 5887, I note that  the document currently says that it

"starts from existing work in [RFC5887],
[I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]." but the references
to these documents are informative.  If the document is meant to be an
extension,
rather than a replacement, such that these documents must be read to
get the full
picture, than a normative reference may be better.

For the session survivability section, a reference to RFC 6724 may be
useful, so
that those adding new global addresses understand how the application
API to determine
which address is used with interact with the addition of new addresses (if there
is a specific draft or other treatment of that topic, that would be even better,
but I am not personally aware of one).

In section 6, the document currently says:

   When nodes in a site have been renumbered, then all the entries in
   the site which contain the nodes' addresses must be updated. The
   entries mainly include DNS records and filters in various entities
   such as ACLs in firewalls/gateways.

This appears to imply that these updates must take place after the renumbering
event, but this is variable.  ACLs and filters may well be updated in advance;
DNS may be updated concurrently or post facto.  A rewording to highlight that
this is variable by record type may be useful.

Section 9.2, in the bullet entitled "DNS data structure optimization"
The discusses a DNS feature proposed but declared historic. I don't think it
identifies the related renumbering gap in a way that is useful for a naive
reader.  If it cannot be reworded to focus on the gap, I suggest it be
removed.

In section 9.4, the document says:

      For application layer, as [RFC5887] said, in general, we can
      assert that any implementation is at risk from renumbering if it
      does not check that an address is valid each time it opens a new
      communications session.

This might be reworded to  include or focus on session resumption, rather than
new communications sessions.  From an applications perspective, the laptop
"sleep" function seems to be one of the bigger risks of this.

Nit:

For me personally, section 6.1 seemed needlessly pessimistic.

--047d7b10cd29de865504da1d9ec2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I have been selected as the Applications Area Directorate <span>reviewer</s=
pan><br>
for this draft (for background on <span>appsdir</span>, please see<br>
<a href=3D"http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDi=
rectorate" target=3D"_blank">http://trac.tools.ietf.org/area/<span>app</spa=
n>/trac/wiki/ApplicationsAreaDirectorate</a><br>
).<br>
<br>
Please resolve these comments along with any other Last Call comments<br>
you may receive. Please wait for direction from your document shepherd<br>
or AD before posting a new version of the draft.<br><br>Document:draft-ietf=
-6renum-gap-analysis-05<div>
Title: IPv6 Site Renumbering Gap Analysis
<br><span>Reviewer</span>: Ted Hardie<br>
<span>Review</span> Date: April 11, 2013<br></div><br>Summary: This documen=
t is basically ready to be published as an Informational draft.=A0 There ar=
e minor issues which the authors may wish to address before final publicati=
on.<br>
<br><br>Minor Issues:<br><br>The document currently motivates its work with=
 the following statement:<br><br><pre>   If IPv6 site renumbering continues=
 to be considered
   difficult, network managers will turn to Provider Independent (PI)
   addressing for IPv6 to attempt to minimize the need for future
   renumbering. However, widespread use of PI may create very serious
   BGP4 scaling problems. It is thus desirable to develop tools and
   practices that may make renumbering a simpler process to reduce
   demand for IPv6 PI space.<br><br>A citation for this would be useful.  I=
t might also be worth it to <br>highlight other potential risks--for exampl=
e, the widespread deployment<br>of ULAs, which do not admit of aggregation,=
 or the deployment of <br>

address translation technologies which make referral more difficult.  I not=
e<br>that RFC 5887 included some of these issues.  If the intent is to refe=
rence<br>those from RFC 5887, I note that  the document currently says that=
 it <br>

&quot;starts from existing work in [RFC5887],
[I-D.chown-v6ops-renumber-thinkabout] and [RFC4192].&quot; but the referenc=
es<br>to these documents are informative.  If the document is meant to be a=
n extension,<br>rather than a replacement, such that these documents must b=
e read to get the full
picture, than a normative reference may be better.<br><br>For the session s=
urvivability section, a reference to RFC 6724 may be useful, so <br>that th=
ose adding new global addresses understand how the application API to deter=
mine<br>
which address is used with interact with the addition of new addresses (if =
there<br>is a specific draft or other treatment of that topic, that would b=
e even better,<br>but I am not personally aware of one).<br><br>In section =
6, the document currently says:<br>
<br>   When nodes in a site have been renumbered, then all the entries in
   the site which contain the nodes&#39; addresses must be updated. The
   entries mainly include DNS records and filters in various entities
   such as ACLs in firewalls/gateways.<br><br>This appears to imply that th=
ese updates must take place after the renumbering<br>event, but this is var=
iable.  ACLs and filters may well be updated in advance;<br>DNS may be upda=
ted concurrently or post facto.  A rewording to highlight that <br>
this is variable by record type may be useful.<br><br>Section 9.2, in the b=
ullet entitled &quot;DNS data structure optimization&quot;<br>The discusses=
 a DNS feature proposed but declared historic. I don&#39;t think it<br>
identifies the related renumbering gap in a way that is useful for a naive =
<br>reader.  If it cannot be reworded to focus on the gap, I suggest it be<=
br>removed.<br><br>In section 9.4, the document says:<br><br>      For appl=
ication layer, as [RFC5887] said, in general, we can
      assert that any implementation is at risk from renumbering if it
      does not check that an address is valid each time it opens a new
      communications session.<br><br>This might be reworded to  include or =
focus on session resumption, rather than <br>new communications sessions.  =
>From an applications perspective, the laptop<br>&quot;sleep&quot; function =
seems to be one of the bigger risks of this.  <br>
<br>Nit:<br><br>For me personally, section 6.1 seemed needlessly pessimisti=
c. <br></pre>

--047d7b10cd29de865504da1d9ec2--

From yaojk@cnnic.cn  Fri Apr 12 00:57:45 2013
Return-Path: <yaojk@cnnic.cn>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D1221F8D12 for <apps-discuss@ietfa.amsl.com>; Fri, 12 Apr 2013 00:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.836
X-Spam-Level: 
X-Spam-Status: No, score=-96.836 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, J_CHICKENPOX_54=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WyW2PJIRMjZ for <apps-discuss@ietfa.amsl.com>; Fri, 12 Apr 2013 00:57:44 -0700 (PDT)
Received: from cnnic.cn (unknown [218.241.105.202]) by ietfa.amsl.com (Postfix) with SMTP id A47D521F8BE4 for <apps-discuss@ietf.org>; Fri, 12 Apr 2013 00:57:43 -0700 (PDT)
X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn
Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 12 Apr 2013 15:57:32 +0800
Message-ID: <6E0E2EDBD7BF49FF94AD9DBA96C88E07@LENOVO47E041CF>
From: "Jiankang YAO" <yaojk@cnnic.cn>
To: <apps-discuss@ietf.org>, <thomas@netapp.com>
Date: Fri, 12 Apr 2013 15:57:32 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Cc: iesg@ietf.org
Subject: [apps-discuss] AppsDir review of draft-ietf-nfsv4-rfc3530bis-25
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2013 07:57:45 -0000

SSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIEFwcGxpY2F0aW9ucyBBcmVhIERpcmVjdG9yYXRl
IHJldmlld2VyIA0KZm9yIHRoaXMgZHJhZnQgKGZvciBiYWNrZ3JvdW5kIG9uIGFwcHNkaXIsIHBs
ZWFzZSANCnNlZSANCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvYXBwL3RyYWMvd2lr
aS9BcHBsaWNhdGlvbnNBcmVhRGlyZWN0b3JhdGUgDQopLiAgDQpQbGVhc2UgcmVzb2x2ZSB0aGVz
ZSBjb21tZW50cyBhbG9uZyB3aXRoIGFueSBvdGhlciBjb21tZW50cyANCnlvdSBtYXkgcmVjZWl2
ZS4gUGxlYXNlIHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgDQpzaGVwaGVy
ZCBvciBBRCBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCg0KRG9j
dW1lbnQ6IA0KZHJhZnQtaWV0Zi1uZnN2NC1yZmMzNTMwYmlzLTI1IA0KVGl0bGU6IA0KTmV0d29y
ayBGaWxlIFN5c3RlbSAoTkZTKSBWZXJzaW9uIDQgUHJvdG9jb2wNCg0KDQpSZXZpZXdlcjogSmlh
bmthbmcgWWFvDQpSZXZpZXcgRGF0ZTogQXByaWwgMTIsIDIwMTMNCg0KU3VtbWFyeToNCg0KVGhp
cyBkcmFmdCBpcyB2ZXJ5IGxvbmcuIEkgbWFpbmx5IGZvY3VzIG9uIHNlY3Rpb24gMTIgb2YgdGhp
cyBkb2N1bWVudC5UaGlzIHBhcnQgaXMgYWJvdXQgaW50ZXJuYXRpb25hbGl6YXRpb24uDQoNCk1h
am9yIGlzc3VlOm5vbmUuDQoNCk1pbm9yIGlzc3VlOg0KDQogIFRoaXMgcGFydCByZWZlciB0byBJ
U08uMTA2NDYtMS4xOTkzLCB3aGljaCBpcyBhbG1vc3Qgc2FtZSB0byBVTklDT0RFIDMuMi4gVGhl
IFJGQzM0NTQgcmVmZXJyZWQgYnkgdGhpcyBkb2N1bWVudCBpcyBhbHNvIGJhc2VkIG9uIElTTy4x
MDY0Ni0xLjE5OTMuIFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIFVOSUNPREUgaGFzIGJlZW4gdXBk
YXRlZCB0byBWZXJzaW9uIDYuMiBmcm9tIHZlcnNpb24gMy4yLiBSRkMzNDU0IG1heSBub3Qgd29y
ayBmb3IgVU5JQ09ERSA2LjIuDQogIFNob3VsZCB0aGlzIGRvY3VtZW50IGJlIHVwZGF0ZWQgdG8g
cmVmZXIgdG8gdGhlIG5ldyB2ZXJzaW9uIG9mIFVOSUNPREU/DQoNCiANCg0KQmVzdCBSZWdhcmRz
DQoNCkppYW5rYW5nIFlhbw==


From Carolin.Latze@swisscom.com  Fri Apr 12 07:36:29 2013
Return-Path: <Carolin.Latze@swisscom.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF0921F89DB for <apps-discuss@ietfa.amsl.com>; Fri, 12 Apr 2013 07:36:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ogc6n2oT6E0 for <apps-discuss@ietfa.amsl.com>; Fri, 12 Apr 2013 07:36:28 -0700 (PDT)
Received: from mail.swisscom.com (outmail110.swisscom.com [193.222.81.110]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD6E21F86E8 for <apps-discuss@ietf.org>; Fri, 12 Apr 2013 07:36:27 -0700 (PDT)
Received: by mail.swisscom.com; Fri, 12 Apr 2013 16:36:26 +0200
From: <Carolin.Latze@swisscom.com>
To: <apps-discuss@ietf.org>
Thread-Topic: New Version Notification for draft-mavrogiannopoulos-tpmuri-00.txt
Thread-Index: AQHN9XobJZBB8IyfJkicwT854E/ymZjTKz+A
Date: Fri, 12 Apr 2013 14:36:24 +0000
Message-ID: <2FFA20399C56CD49B5BEEAD147D58DE54097E901@sg000710.corproot.net>
In-Reply-To: <20130118124816.19028.15269.idtracker@ietfa.amsl.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [193.222.87.68]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7C2283FCABC7824CBB163AEC27C4DE54@swisscom.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [apps-discuss] FW: New Version Notification for draft-mavrogiannopoulos-tpmuri-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2013 14:36:29 -0000

Hi all

In January, we submitted an I-D that described how you can identify keys
that are stored inside a TPM. Just recently we learned that it might be of
interest for the the appsarea to discuss this I-D.

This proposal has been inspired by the PKCS#11 URI. We believe that those
URIs are a great possibility to identify keys stored in security modules
in order to use them for instance in standard TLS libraries. Although the
TPM has a PKCS#11 interface (well let's put it like this:  it is possible
to create a PKCS#11 interface around a TPM), it is much more common and
powerful to work without such an interface. Therefore we propose to define
another URI for TPM secured keys.

Best regards
Carolin





On 1/18/13 1:48 PM, "internet-drafts@ietf.org" <internet-drafts@ietf.org>
wrote:

>
>A new version of I-D, draft-mavrogiannopoulos-tpmuri-00.txt
>has been successfully submitted by Carolin Latze and posted to the
>IETF repository.
>
>Filename:	 draft-mavrogiannopoulos-tpmuri
>Revision:	 00
>Title:		 The TPMKEY URI Scheme
>Creation date:	 2013-01-18
>WG ID:		 Individual Submission
>Number of pages: 6
>URL:            =20
>http://www.ietf.org/internet-drafts/draft-mavrogiannopoulos-tpmuri-00.txt
>Status:         =20
>http://datatracker.ietf.org/doc/draft-mavrogiannopoulos-tpmuri
>Htmlized:       =20
>http://tools.ietf.org/html/draft-mavrogiannopoulos-tpmuri-00
>
>
>Abstract:
>   This memo specifies a TPMKEY Uniform Resource Identifier (URI) Scheme
>   for identifying cryptographic keys stored in TPM chips and access
>   using the TCG Software Stack (TSS).  The URI is based on how TPM keys
>   are identified in the TSS specification.
>
>                 =20
>       =20
>
>
>The IETF Secretariat
>


From superuser@gmail.com  Fri Apr 12 12:10:33 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E5B21F8F15 for <apps-discuss@ietfa.amsl.com>; Fri, 12 Apr 2013 12:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.487
X-Spam-Level: 
X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.111,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEUMLCQ5VfEZ for <apps-discuss@ietfa.amsl.com>; Fri, 12 Apr 2013 12:10:33 -0700 (PDT)
Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 22BB221F8F13 for <apps-discuss@ietf.org>; Fri, 12 Apr 2013 12:10:32 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id x12so1789947wgg.4 for <apps-discuss@ietf.org>; Fri, 12 Apr 2013 12:10:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=mBUafpFOkEUWW2ZKqF3Y/FtVHlUsBNosVi1sMPBOvKg=; b=UFOaiXmjqZYQA9BRZ3+9A3HZSbtaDMk+cToKSNP7v2z6RXu7WzshO5VujlZ4irUBqg EPmyeFOI0pt+3J9napAWiC62848V/z3qwA0u0SOa71Y/yhexf5nPA4/7EMX2eA9rIuBK fs95Fbqf+6TtP37Jt73uCScqJ/yy4leruszNVQ+tBm7Kny3Msn42hwW6Qo4t0j11NOrh AgSW3jmGf7vnO2x+6RqdWUKjmTq4dwBZsilBIyJU2/4Oe0KvxWTio0i7dmUdKTpPay8x I9fnX5mFZBHl5FoF2nX/q+PBF8kTnznpzMyG2IA+X2/BTv6RKyfu9k6wkLusMNGpuAk/ a4qQ==
MIME-Version: 1.0
X-Received: by 10.194.93.68 with SMTP id cs4mr19711063wjb.17.1365793832231; Fri, 12 Apr 2013 12:10:32 -0700 (PDT)
Received: by 10.180.36.176 with HTTP; Fri, 12 Apr 2013 12:10:31 -0700 (PDT)
Date: Fri, 12 Apr 2013 12:10:31 -0700
Message-ID: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b5d8cff34e7f304da2ea805
Subject: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2013 19:10:33 -0000

--047d7b5d8cff34e7f304da2ea805
Content-Type: text/plain; charset=ISO-8859-1

Hello again,

After discussion with some IESG members and the DMARC community, a revised
charter has now been posted for consideration:

http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

Thanks to everyone who provided constructive help in getting this reformed
into a palatable charter.  Please feel free to offer more comments; if it
seems non-upsetting, we'd like to ask the ADs to put it on a future
telechat.

Thanks,
-MSK

--047d7b5d8cff34e7f304da2ea805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Hello again,<br><br>After discussion with some I=
ESG members and the DMARC community, a revised charter has now been posted =
for consideration:<br><br><a href=3D"http://wiki.tools.ietf.org/wg/appsawg/=
trac/wiki/DMARC">http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC</a><=
br>
<br></div>Thanks to everyone who provided constructive help in getting this=
 reformed into a palatable charter.=A0 Please feel free to offer more comme=
nts; if it seems non-upsetting, we&#39;d like to ask the ADs to put it on a=
 future telechat.<br>
<br>Thanks,<br></div>-MSK<br></div>

--047d7b5d8cff34e7f304da2ea805--

From leo.liubing@huawei.com  Thu Apr 11 20:01:17 2013
Return-Path: <leo.liubing@huawei.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354D421F871C for <apps-discuss@ietfa.amsl.com>; Thu, 11 Apr 2013 20:01:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level: 
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_PAIN=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cyDqdd6rYaz for <apps-discuss@ietfa.amsl.com>; Thu, 11 Apr 2013 20:01:13 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9573121F8678 for <apps-discuss@ietf.org>; Thu, 11 Apr 2013 20:01:12 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ART58298; Fri, 12 Apr 2013 03:01:05 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Apr 2013 04:00:29 +0100
Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Apr 2013 11:01:03 +0800
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.42]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Fri, 12 Apr 2013 11:00:56 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: Ted Hardie <ted.ietf@gmail.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "draft-ietf-6renum-gap-analysis.all@tools.ietf.org" <draft-ietf-6renum-gap-analysis.all@tools.ietf.org>
Thread-Topic: Review of draft-ietf-6renum-gap-analysis-05
Thread-Index: AQHONwcY0vdwoOJq1Eis2vBZoqHNl5jRyugQ
Date: Fri, 12 Apr 2013 03:00:54 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEE@nkgeml506-mbx.china.huawei.com>
References: <CA+9kkMDEc1mX77eRYMXPBKnH9X+jOXGVD7pVFArkwSwNsF+wMA@mail.gmail.com>
In-Reply-To: <CA+9kkMDEc1mX77eRYMXPBKnH9X+jOXGVD7pVFArkwSwNsF+wMA@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.161]
Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEEnkgeml506mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Fri, 12 Apr 2013 13:44:42 -0700
Subject: Re: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2013 03:01:17 -0000

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEEnkgeml506mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi, Ted

Many thanks for your review, it would be helpful to refine the draft. Pleas=
e see replies inline.

Best regards,
Bing

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Friday, April 12, 2013 6:51 AM
To: apps-discuss@ietf.org; draft-ietf-6renum-gap-analysis.all@tools.ietf.or=
g
Subject: Review of draft-ietf-6renum-gap-analysis-05

I have been selected as the Applications Area Directorate reviewer
for this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:draft-ietf-6renum-gap-analysis-05
Title: IPv6 Site Renumbering Gap Analysis
Reviewer: Ted Hardie
Review Date: April 11, 2013

Summary: This document is basically ready to be published as an Information=
al draft.  There are minor issues which the authors may wish to address bef=
ore final publication.


Minor Issues:

The document currently motivates its work with the following statement:

   If IPv6 site renumbering continues to be considered

   difficult, network managers will turn to Provider Independent (PI)

   addressing for IPv6 to attempt to minimize the need for future

   renumbering. However, widespread use of PI may create very serious

   BGP4 scaling problems. It is thus desirable to develop tools and

   practices that may make renumbering a simpler process to reduce

   demand for IPv6 PI space.

A citation for this would be useful.  It might also be worth it to
highlight other potential risks--for example, the widespread deployment
of ULAs, which do not admit of aggregation, or the deployment of


[Bing] Ok, thanks for the suggestion. We'll include the reference on BGP4 s=
caling issue, as well as considering whether there are other potential risk=
s.

But for the specific ULA problem, it might be different. ULA is intended to=
 be used within a certain scope, normally, within an enterprise network. So=
 it won't bother the global routing scalability.

In fact we suggest to use ULA along with PA in enterprise to avoid some ren=
umbering or to make internal communication more stable when switching globa=
l prefixes. It was documented in the recently published 6renum RFC6879 (Ple=
ase see section 4.1)



address translation technologies which make referral more difficult.  I not=
e
that RFC 5887 included some of these issues.  If the intent is to reference
those from RFC 5887, I note that  the document currently says that it




"starts from existing work in [RFC5887],

[I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]." but the references
to these documents are informative.  If the document is meant to be an exte=
nsion,
rather than a replacement, such that these documents must be read to get th=
e full

picture, than a normative reference may be better.



[Bing] These documents are important input for the gap analysis draft. They=
 indeed have not a few crossed content, but our intention on the gap draft =
was different, so it is neither extension nor replacement.

RFC5887&draft-thinkabout are more comprehensive analysis/guidelines on IPv6=
 renumbering issue; RFC4192 emphasizes on a "make before break" prefix swit=
ching operation.

This gap draft  addresses the IPv6 enterprise scenarios described in RFC687=
9, and focusing on identifying what is missing to make renum more automatic=
 and less error-prone.


For the session survivability section, a reference to RFC 6724 may be usefu=
l, so
that those adding new global addresses understand how the application API t=
o determine


which address is used with interact with the addition of new addresses (if =
there
is a specific draft or other treatment of that topic, that would be even be=
tter,
but I am not personally aware of one).



[Bing] OK. Address selection is indeed important.


In section 6, the document currently says:


   When nodes in a site have been renumbered, then all the entries in

   the site which contain the nodes' addresses must be updated. The

   entries mainly include DNS records and filters in various entities

   such as ACLs in firewalls/gateways.

This appears to imply that these updates must take place after the renumber=
ing
event, but this is variable.  ACLs and filters may well be updated in advan=
ce;
DNS may be updated concurrently or post facto.  A rewording to highlight th=
at

this is variable by record type may be useful.



[Bing] Ok, thanks.

Section 9.2, in the bullet entitled "DNS data structure optimization"
The discusses a DNS feature proposed but declared historic. I don't think i=
t

identifies the related renumbering gap in a way that is useful for a naive
reader.  If it cannot be reworded to focus on the gap, I suggest it be
removed.


[Bing] When we wrote the draft, we considered if the IPv6 DNS record could =
be structured as separating prefix and suffix, that would be very helpful f=
or renumbering. Because in IPv6, most of the time we just change the prefix=
es rather than the whole addresses.

We found A6 has the similar feature, but it has been moved to historic. How=
ever,  the idea of separating prefix and suffix is still considered valuabl=
e, but there might not  be able to develop a new DNS record in a short time=
, so we name the idea as "DNS data structure optimization" and put it into =
"gaps considered unsolvable".

We can add some minor texts to explain the intention.

In section 9.4, the document says:

      For application layer, as [RFC5887] said, in general, we can

      assert that any implementation is at risk from renumbering if it

      does not check that an address is valid each time it opens a new

      communications session.

This might be reworded to  include or focus on session resumption, rather t=
han
new communications sessions.  From an applications perspective, the laptop
"sleep" function seems to be one of the bigger risks of this.


[Bing] Ok, thanks.

Nit:

For me personally, section 6.1 seemed needlessly pessimistic.

[Bing] It is sad but true. And we are curious about how much operational is=
sues there to prevent DDNS widely deployed in real networks.

If possible, we might consider to make a dedicated draft to talk about this=
 issue in the future.



--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEEnkgeml506mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML \9884\8BBE\683C\5F0F Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.HTMLChar
	{mso-style-name:"HTML \9884\8BBE\683C\5F0F Char";
	mso-style-priority:99;
	mso-style-link:"HTML \9884\8BBE\683C\5F0F";
	font-family:"Courier New";}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi, Ted<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Many thank=
s for your review, it would be helpful to refine the draft. Please see repl=
ies inline.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Best regar=
ds,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Bing<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;"> Ted Hardie [mailto:ted.ietf@gmail.com]
<br>
<b>Sent:</b> Friday, April 12, 2013 6:51 AM<br>
<b>To:</b> apps-discuss@ietf.org; draft-ietf-6renum-gap-analysis.all@tools.=
ietf.org<br>
<b>Subject:</b> Review of draft-ietf-6renum-gap-analysis-05<o:p></o:p></spa=
n></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I have been selected as the App=
lications Area Directorate reviewer<br>
for this draft (for background on appsdir, please see<br>
<a href=3D"http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDi=
rectorate" target=3D"_blank">http://trac.tools.ietf.org/area/app/trac/wiki/=
ApplicationsAreaDirectorate</a><br>
).<br>
<br>
Please resolve these comments along with any other Last Call comments<br>
you may receive. Please wait for direction from your document shepherd<br>
or AD before posting a new version of the draft.<br>
<br>
Document:draft-ietf-6renum-gap-analysis-05<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Title: IPv6 Site Renumbering Ga=
p Analysis
<br>
Reviewer: Ted Hardie<br>
Review Date: April 11, 2013<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US">=
<br>
Summary: This document is basically ready to be published as an Information=
al draft.&nbsp; There are minor issues which the authors may wish to addres=
s before final publication.<br>
<br>
<br>
Minor Issues:<br>
<br>
The document currently motivates its work with the following statement:<o:p=
></o:p></span></p>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; If IPv6 site renumbering continues t=
o be considered<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; difficult, network managers will tur=
n to Provider Independent (PI)<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; addressing for IPv6 to attempt to mi=
nimize the need for future<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; renumbering. However, widespread use=
 of PI may create very serious<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; BGP4 scaling problems. It is thus de=
sirable to develop tools and<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; practices that may make renumbering =
a simpler process to reduce<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; demand for IPv6 PI space.<br><br>A c=
itation for this would be useful.&nbsp; It might also be worth it to <br>hi=
ghlight other potential risks--for example, the widespread deployment<br>of=
 ULAs, which do not admit of aggregation, or the deployment of <br><br><o:p=
></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Bing] Ok, thanks for the su=
ggestion. We&#8217;ll include the reference on BGP4 scaling issue, as well =
as considering whether there are other potential risks.<o:p></o:p></span></=
pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">But for the specific ULA pro=
blem, it might be different. ULA is intended to be used within a certain sc=
ope, normally, within an enterprise network. So it won&#8217;t bother the g=
lobal routing scalability.<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">In fact we suggest to use UL=
A along with PA in enterprise to avoid some renumbering or to make internal=
 communication more stable when switching global prefixes. It was documente=
d in the recently published 6renum RFC6879 (Please see section 4.1)<o:p></o=
:p></span></pre>
<pre><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></pre>
<pre><span lang=3D"EN-US">address translation technologies which make refer=
ral more difficult.&nbsp; I note<br>that RFC 5887 included some of these is=
sues.&nbsp; If the intent is to reference<br>those from RFC 5887, I note th=
at&nbsp; the document currently says that it <br><br><o:p></o:p></span></pr=
e>
<pre><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></pre>
<pre><span lang=3D"EN-US">&quot;starts from existing work in [RFC5887],<o:p=
></o:p></span></pre>
<pre><span lang=3D"EN-US">[I-D.chown-v6ops-renumber-thinkabout] and [RFC419=
2].&quot; but the references<br>to these documents are informative.&nbsp; I=
f the document is meant to be an extension,<br>rather than a replacement, s=
uch that these documents must be read to get the full<o:p></o:p></span></pr=
e>
<pre><span lang=3D"EN-US">picture, than a normative reference may be better=
.<span style=3D"color:#1F497D"><o:p></o:p></span></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pr=
e>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Bing] These documents are i=
mportant input for the gap analysis draft. They indeed have not a few cross=
ed content, but our intention on the gap draft was different, so it is neit=
her extension nor replacement.<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">RFC5887&amp;draft-thinkabout=
 are more comprehensive analysis/guidelines on IPv6 renumbering issue; RFC4=
192 emphasizes on a &#8220;make before break&#8221; prefix switching operat=
ion.<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">This gap draft &nbsp;address=
es the IPv6 enterprise scenarios described in RFC6879, and focusing on iden=
tifying what is missing to make renum more automatic and less error-prone.<=
o:p></o:p></span></pre>
<pre><span lang=3D"EN-US"><br><br>For the session survivability section, a =
reference to RFC 6724 may be useful, so <br>that those adding new global ad=
dresses understand how the application API to determine<br><br><o:p></o:p><=
/span></pre>
<pre><span lang=3D"EN-US">which address is used with interact with the addi=
tion of new addresses (if there<br>is a specific draft or other treatment o=
f that topic, that would be even better,<br>but I am not personally aware o=
f one).<span style=3D"color:#1F497D"><o:p></o:p></span></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pr=
e>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Bing] OK. Address selection=
 is indeed important. <o:p></o:p></span></pre>
<pre><span lang=3D"EN-US"><br><br>In section 6, the document currently says=
:<br><br><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US"><br>&nbsp;&nbsp; When nodes in a site have been r=
enumbered, then all the entries in<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; the site which contain the nodes' ad=
dresses must be updated. The<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; entries mainly include DNS records a=
nd filters in various entities<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; such as ACLs in firewalls/gateways.<=
br><br>This appears to imply that these updates must take place after the r=
enumbering<br>event, but this is variable.&nbsp; ACLs and filters may well =
be updated in advance;<br>DNS may be updated concurrently or post facto.&nb=
sp; A rewording to highlight that <o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">this is variable by record type may be useful.<sp=
an style=3D"color:#1F497D"><o:p></o:p></span></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pr=
e>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Bing] Ok, thanks.</span><sp=
an lang=3D"EN-US"><br><br>Section 9.2, in the bullet entitled &quot;DNS dat=
a structure optimization&quot;<br>The discusses a DNS feature proposed but =
declared historic. I don't think it<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">identifies the related renumbering gap in a way t=
hat is useful for a naive <br>reader.&nbsp; If it cannot be reworded to foc=
us on the gap, I suggest it be<br>removed.<br><br><span style=3D"color:#1F4=
97D"><o:p></o:p></span></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Bing] When we wrote the dra=
ft, we considered if the IPv6 DNS record could be structured as separating =
prefix and suffix, that would be very helpful for renumbering. Because in I=
Pv6, most of the time we just change the prefixes rather than the whole add=
resses.<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">We found A6 has the similar =
feature, but it has been moved to historic. However, &nbsp;the idea of sepa=
rating prefix and suffix is still considered valuable, but there might not =
&nbsp;be able to develop a new DNS record in a short time, so we name the i=
dea as &#8220;DNS data structure optimization&#8221; and put it into &#8220=
;gaps considered unsolvable&#8221;.<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">We can add some minor texts =
to explain the intention.<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US"><br>In section 9.4, the document says:<br><br>&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; For application layer, as [RFC5887] said, in ge=
neral, we can<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; assert that any im=
plementation is at risk from renumbering if it<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; does not check tha=
t an address is valid each time it opens a new<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; communications ses=
sion.<br><br>This might be reworded to&nbsp; include or focus on session re=
sumption, rather than <br>new communications sessions.&nbsp; From an applic=
ations perspective, the laptop<br>&quot;sleep&quot; function seems to be on=
e of the bigger risks of this.&nbsp; <br><br><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Bing] Ok, thanks.<o:p></o:p=
></span></pre>
<pre><span lang=3D"EN-US"><br>Nit:<br><br>For me personally, section 6.1 se=
emed needlessly pessimistic. <o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Bing] It is sad but true. A=
nd we are curious about how much operational issues there to prevent DDNS w=
idely deployed in real networks.<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">If possible, we might consid=
er to make a dedicated draft to talk about this issue in the future. <o:p><=
/o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></pr=
e>
</div>
</div>
</body>
</html>

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEEnkgeml506mbxchi_--

From scott@kitterman.com  Fri Apr 12 14:56:05 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC85A21F8F5C for <apps-discuss@ietfa.amsl.com>; Fri, 12 Apr 2013 14:56:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Y5c7OuKkg2b for <apps-discuss@ietfa.amsl.com>; Fri, 12 Apr 2013 14:56:05 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E2D6921F8F58 for <apps-discuss@ietf.org>; Fri, 12 Apr 2013 14:56:04 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2E85320E40D2; Fri, 12 Apr 2013 17:56:04 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1365803764; bh=U46Dw7kyyPkqoM7cUgqtaeJ06p7sgfUqHe3Oc2GjKAc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=o8P6gs4d0ZtoaWpU+qI3mfcMS19Cef9r/Wd5VnZe1w8+m6pP9pssK6z0kVwAlmb8D usvwd7ewwsao7DAsm/Y8q+Uvdrc7I7IpBTFzn6ZuN+Cp0dMAKQ5G8z8pCAVSsydwFk if66zBi2oXkCx+c+ww0monWWSYJpngI4dw9Ud1Fw=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 10AD320E40B0;  Fri, 12 Apr 2013 17:56:03 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Fri, 12 Apr 2013 17:56 -0400
Message-ID: <6600677.x1Szm294G3@scott-latitude-e6320>
User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; )
In-Reply-To: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Apr 2013 21:56:05 -0000

On Friday, April 12, 2013 12:10:31 PM Murray S. Kucherawy wrote:
> Hello again,
> 
> After discussion with some IESG members and the DMARC community, a revised
> charter has now been posted for consideration:
> 
> http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC
> 
> Thanks to everyone who provided constructive help in getting this reformed
> into a palatable charter.  Please feel free to offer more comments; if it
> seems non-upsetting, we'd like to ask the ADs to put it on a future
> telechat.

"The initial charter for this working group does not include revising the base 
specification"

I don't think removing the work on the base specification from the charter 
really addresses the concern that the previous draft charter over constrained 
work on the base charter.  "You have to recharter" to make a change seems very 
constraining.

At some point, if DMARC is going to be an IETF standard, dmarc.org is going to 
have to let go of change control.  I think this revision goes in the opposite 
direction.

There were a number of suggestions based on DKIM and other WG charters that 
seemed to me like a good basis for balancing the concerns of existing 
implementers with the idea of allowing an IETF working group to actually do 
work.

By removing the work from the working group entirely, I think this is the 
wrong direction to go in.

Scott K

From jtrentadams@gmail.com  Fri Apr 12 18:12:03 2013
Return-Path: <jtrentadams@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E0821F8E99 for <apps-discuss@ietfa.amsl.com>; Fri, 12 Apr 2013 18:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.048
X-Spam-Level: 
X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBKCezsZAcDp for <apps-discuss@ietfa.amsl.com>; Fri, 12 Apr 2013 18:12:02 -0700 (PDT)
Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 739D621F8D4E for <apps-discuss@ietf.org>; Fri, 12 Apr 2013 18:12:02 -0700 (PDT)
Received: by mail-ob0-f177.google.com with SMTP id 16so764681obc.22 for <apps-discuss@ietf.org>; Fri, 12 Apr 2013 18:12:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=SKI7pyqq1dc4Nt2jvfWGj4FaMwG++uo2pBKMZlgpG98=; b=xmzi0o5gpZIA449yVTuXByCop/dHGwX79FTbU3svf2Y6+Xz4rXT53eVV3wYzIOuQF7 OkGpJYvDskx2Aen3z1uae3qntJh7Qgf+Vp+xkJoC4HVslvYP6pnUDbRHFeA3A3Cgbcep BLaj8KUFBcJnQSVi25BdZ/7hfdhZvEq1MUI+TPDgJHGaPFjx3kRMmWkwbjaqB2FR2sfO A5B6wCqNo/Fj1OHFHAyhbnZE1AVeco2iDFaPt+PivmPLHyQakGrcoRiqmdFyXqw2LxlE vREDxXeg/0cnEk56/mzDHzA9IDWbA+LpOFmchhZqrYKuaaiUTcz2DnoedVJpYFba+DeM 8ceQ==
X-Received: by 10.60.76.234 with SMTP id n10mr4659780oew.63.1365815521901; Fri, 12 Apr 2013 18:12:01 -0700 (PDT)
Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPS id dv8sm1933165obb.5.2013.04.12.18.12.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Apr 2013 18:12:01 -0700 (PDT)
Message-ID: <5168B0E0.5020804@gmail.com>
Date: Fri, 12 Apr 2013 19:12:00 -0600
From: "J. Trent Adams" <jtrentadams@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <6600677.x1Szm294G3@scott-latitude-e6320>
In-Reply-To: <6600677.x1Szm294G3@scott-latitude-e6320>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Apr 2013 01:12:03 -0000

To speak in favor of the newly revised charter, I believe that it is a
reasonable balance when considering the context. Specifically, a lot of
organizations already see real value in the current version of the base
specification.

That's not to say it can't be improved, but the stability of the version
at this stage of deployment is an important factor. It will be through
continued wide-spread adoption and feedback on real-world utility that
will help suggest improvements to the group.

The proposed charter does a good job of taking a pragmatic, lessons
learned type of approach. It considers the experience that only comes
from "running code", capturing what works (and documenting it), all the
while cataloging ways it can be improved. There is also lot of room for
work on important, non-disruptive extensions (some ideas for which are
included, while others will undoubtedly arise).

Then, once a reasonable amount of due diligence is performed by the
broader community, the group will have the data it needs to determine if
the base specification itself should be improved. If so, the group can
re-charter with that work in scope and the specification will be in it's
capable hands.

Basically, it seems to me that this is a very healthy approach in which
I look forward to participating.

Thanks,
Trent


On 4/12/13 3:56 PM, Scott Kitterman wrote:
> On Friday, April 12, 2013 12:10:31 PM Murray S. Kucherawy wrote:
>> Hello again,
>>
>> After discussion with some IESG members and the DMARC community, a revised
>> charter has now been posted for consideration:
>>
>> http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC
>>
>> Thanks to everyone who provided constructive help in getting this reformed
>> into a palatable charter.  Please feel free to offer more comments; if it
>> seems non-upsetting, we'd like to ask the ADs to put it on a future
>> telechat.
> "The initial charter for this working group does not include revising the base 
> specification"
>
> I don't think removing the work on the base specification from the charter 
> really addresses the concern that the previous draft charter over constrained 
> work on the base charter.  "You have to recharter" to make a change seems very 
> constraining.
>
> At some point, if DMARC is going to be an IETF standard, dmarc.org is going to 
> have to let go of change control.  I think this revision goes in the opposite 
> direction.
>
> There were a number of suggestions based on DKIM and other WG charters that 
> seemed to me like a good basis for balancing the concerns of existing 
> implementers with the idea of allowing an IETF working group to actually do 
> work.
>
> By removing the work from the working group entirely, I think this is the 
> wrong direction to go in.
>
> Scott K
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

-- 
J. Trent Adams

LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams


From dhc@dcrocker.net  Fri Apr 12 19:20:51 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113BA21F8EE6 for <apps-discuss@ietfa.amsl.com>; Fri, 12 Apr 2013 19:20:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.539
X-Spam-Level: 
X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpjUUKdc6uVI for <apps-discuss@ietfa.amsl.com>; Fri, 12 Apr 2013 19:20:50 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6A57221F8E72 for <apps-discuss@ietf.org>; Fri, 12 Apr 2013 19:20:50 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3D2KnVq014704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Apr 2013 19:20:50 -0700
Message-ID: <5168C0FA.9020709@dcrocker.net>
Date: Fri, 12 Apr 2013 19:20:42 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Scott Kitterman <scott@kitterman.com>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <6600677.x1Szm294G3@scott-latitude-e6320>
In-Reply-To: <6600677.x1Szm294G3@scott-latitude-e6320>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 12 Apr 2013 19:20:50 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Apr 2013 02:20:51 -0000

Scott,

Would that these processes were more smooth. However...


On 4/12/2013 2:56 PM, Scott Kitterman wrote:
> "The initial charter for this working group does not include revising the base
> specification"
>
> I don't think removing the work on the base specification from the charter
> really addresses the concern that the previous draft charter over constrained
> work on the base charter.  "You have to recharter" to make a change seems very
> constraining.

To charter a working group that will make changes to a specification, 
there first must be a sense of the kinds of changes that are needed and 
desired by the folks who will develop and deploy the changes.

Before bringing the spec to the IETF venue, we looked quite hard amongst 
the current DMARC community for a meaningful, near-term work-list to 
attempt on the base spec, and failed to develop one.

So Scott, what changes to the DMARC base spec are you seeking and why 
and who wants them and how do we know this?


> There were a number of suggestions based on DKIM and other WG charters that
> seemed to me like a good basis for balancing the concerns of existing
> implementers with the idea of allowing an IETF working group to actually do
> work.

The issue is not whether random, thoughtful folk can imagine a range of 
changes to make.  The question is what is actually needed and by whom 
and what the basis for believing this is.

Start by considering that there is a recent installed base, which means 
that the folks currently deploying DMARC, to cover roughly 60% of the 
world's mailboxes, would like to recover their initial investment before 
making more changes.  Then consider that they haven't yet registered 
requests for changes or enhancements.  Then please explain the basis for 
changing to make more changes now?

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From scott@kitterman.com  Fri Apr 12 23:00:51 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFEC21F8F1A for <apps-discuss@ietfa.amsl.com>; Fri, 12 Apr 2013 23:00:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mh0iC0DJLd8s for <apps-discuss@ietfa.amsl.com>; Fri, 12 Apr 2013 23:00:49 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9D32421F8F15 for <apps-discuss@ietf.org>; Fri, 12 Apr 2013 23:00:49 -0700 (PDT)
Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 2BDACD04088; Sat, 13 Apr 2013 01:00:49 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1365832849; bh=mjtzJfJHofrdnZczsDhdoNVG5PU3yIA70P+3ogilbIQ=; h=In-Reply-To:References:Subject:From:Date:To:From; b=LV/5FCnqzXwnRkTjIZ1kpfdaYABr87WPEwVVs8JSon0rkI7MWpuQgZ+OJOIGCyeMT YUzeQV1R2vAEP/JQCJXxC1XbFGYIyqUeQNXlj3I06DoyL2QRDMO8hivx45lI7EG/jx 9gVLBtDCwislRK8ZK6Yl8ncTrwWKg8G4SMLJo80w=
Received: from [IPV6:2600:1002:b10b:eb7d:82bb:5363:3b75:3fe3] (unknown [IPv6:2600:1002:b10b:eb7d:82bb:5363:3b75:3fe3]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C2D50D04059;  Sat, 13 Apr 2013 01:00:48 -0500 (CDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <5168C0FA.9020709@dcrocker.net>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <6600677.x1Szm294G3@scott-latitude-e6320> <5168C0FA.9020709@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Scott Kitterman <scott@kitterman.com>
Date: Sat, 13 Apr 2013 02:00:45 -0400
To: apps-discuss@ietf.org
Message-ID: <0d7d06e2-a54b-45ec-a33f-dbfa2b20bc0e@email.android.com>
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Apr 2013 06:00:51 -0000

Dave Crocker <dhc@dcrocker.net> wrote:

>Scott,
>
>Would that these processes were more smooth. However...
>
>
>On 4/12/2013 2:56 PM, Scott Kitterman wrote:
>> "The initial charter for this working group does not include revising
>the base
>> specification"
>>
>> I don't think removing the work on the base specification from the
>charter
>> really addresses the concern that the previous draft charter over
>constrained
>> work on the base charter.  "You have to recharter" to make a change
>seems very
>> constraining.
>
>To charter a working group that will make changes to a specification, 
>there first must be a sense of the kinds of changes that are needed and
>desired by the folks who will develop and deploy the changes.
>
>Before bringing the spec to the IETF venue, we looked quite hard
>amongst 
>the current DMARC community for a meaningful, near-term work-list to 
>attempt on the base spec, and failed to develop one.
>
>So Scott, what changes to the DMARC base spec are you seeking and why 
>and who wants them and how do we know this?

In part, I don't. DMARC has been developed in private by a relatively small group of people. I think it's not unreasonable to consider the spec might be improved by broader review.  Things that were written by people who already "know" what the spec is supposed to mean are often less clear to those outside the group. Until a broader group actually reviews it, there's no way to know. 

That's not a matter of changing the protocol, but improving the text.  I don't see any reason for existing implementers to fear improved text.

The one thing I think does need to be changed is the policy override approach.  Changing SPF policy based on DMARC is a layering violation at the very least. While reading the envelope (HELO/5321.Mail From) I have to change processing based information in the body (5322.From).  Many SPF implementations don't have access to the body making it difficult to implement correctly. 

Not only is the current design wrong, it's nor needed to solve the problem DMARC was meant to solve.

Similarly, due to this override, a DMARC policy of none can't be used just to collect data as it will change mail processing as well.

>
>> There were a number of suggestions based on DKIM and other WG
>charters that
>> seemed to me like a good basis for balancing the concerns of existing
>> implementers with the idea of allowing an IETF working group to
>actually do
>> work.
>
>The issue is not whether random, thoughtful folk can imagine a range of
>changes to make.  The question is what is actually needed and by whom 
>and what the basis for believing this is.
>
>Start by considering that there is a recent installed base, which means
>
>that the folks currently deploying DMARC, to cover roughly 60% of the 
>world's mailboxes, would like to recover their initial investment
>before 
>making more changes.  Then consider that they haven't yet registered 
>requests for changes or enhancements.  Then please explain the basis
>for 
>changing to make more changes now?

The current design is wrong. The specific issues I'm concerned with now can be resolved without forcing existing implementers to change anything, so no investment is at risk.  Improving and clarifying the text of the spec is similarly not a risk.

Fundamentally, rubber stamping the work of a private design team is not the IETF way.  Your arguments can be applied to almost any technology brought to the IETF with an existing constituency. 

Given the current draft charter, I think a working group is pointless. 

Scott K

From dhc@dcrocker.net  Sat Apr 13 04:38:04 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0333521F8496 for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 04:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.549
X-Spam-Level: 
X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byDqwZjt0xnb for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 04:38:00 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6240121F848D for <apps-discuss@ietf.org>; Sat, 13 Apr 2013 04:37:58 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3DBbvsN021837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Apr 2013 04:37:58 -0700
Message-ID: <5169438B.3010400@dcrocker.net>
Date: Sat, 13 Apr 2013 04:37:47 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Scott Kitterman <scott@kitterman.com>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <6600677.x1Szm294G3@scott-latitude-e6320> <5168C0FA.9020709@dcrocker.net> <0d7d06e2-a54b-45ec-a33f-dbfa2b20bc0e@email.android.com>
In-Reply-To: <0d7d06e2-a54b-45ec-a33f-dbfa2b20bc0e@email.android.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 13 Apr 2013 04:37:58 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Apr 2013 11:38:04 -0000

Scott,


On 4/12/2013 11:00 PM, Scott Kitterman wrote:
>> So Scott, what changes to the DMARC base spec are you seeking and
>> why and who wants them and how do we know this?
>
> In part, I don't. DMARC has been developed in private by a relatively
> small group of people. I think it's not unreasonable to consider the
> spec might be improved by broader review.

    It's entirely reasonable.  That's why the draft charter provides for 
such future effort: "However, if resolving any of the issues listed in 
the areas of focus below does require changes to the base specification, 
or if the specification needs to be revised to correct technical errors 
deemed essential for proper use, the group will recharter accordingly."

    The specification has been public for considerably more than a year, 
including a press release and a public discussion list, with adoption 
covering roughly 60% of the world's mailboxes.  That's not a small base 
of experience.  So there's been plenty of opportunity for community 
review and input, including requests for changes.  And yet, there is so 
far no such list of requests.


 >  Things that were written
> by people who already "know" what the spec is supposed to mean are
> often less clear to those outside the group. Until a broader group
> actually reviews it, there's no way to know.

   You are correct, of course.  However the range of implementers now 
goes considerably beyond the original group, and yet there is so far no 
concrete list of interesting changes being requested.


> That's not a matter of changing the protocol, but improving the text.

    Well, that's what we originally submitted for chartering, but at 
least one AD didn't like it.


> The one thing I think does need to be changed is the policy override
> approach.  Changing SPF policy based on DMARC is a layering violation
> at the very least.

    Sorry, but I'm missing the reference.  Please point to the section 
of text you don't like and describe the kind of change you are seeking.

(FWIW, on reflection, I'm not a fan of the term policy override, since 
it implies that the recipient has somehow been bound to conformance to 
the sender's policies...)


> While reading the envelope (HELO/5321.Mail From) I
> have to change processing based information in the body (5322.From).
> Many SPF implementations don't have access to the body making it
> difficult to implement correctly.

    If they are doing DMARC, they do have access.


> Not only is the current design wrong, it's nor needed to solve the
> problem DMARC was meant to solve.

    Sounds like a protocol change.  That's rather more than merely 
improving the text.


> Similarly, due to this override, a DMARC policy of none can't be used
> just to collect data as it will change mail processing as well.

    I don't understand.


> The current design is wrong. The specific issues I'm concerned with
> now can be resolved without forcing existing implementers to change
> anything, so no investment is at risk.

    The idea that one can change a design, without having to change 
code, is new to me.  Please explain.


> Fundamentally, rubber stamping the work of a private design team is
> not the IETF way.

    What part of the work in the latest draft charter would produce 
rubber stamping?

    But since you are being pedagogical about how the IETF does things, 
please note that working group charters are supposed to specify the 
nature of the work to be done.  Working groups that start without a 
sense of what problem they are trying to solve to tend to have poor 
outcomes.  If you can specify the nature of the technical, work to be 
done, sufficiently to garner support for it, then it's certainly worth 
considering.


d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From scott@kitterman.com  Sat Apr 13 05:29:30 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C8521F85E7 for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 05:29:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlqS3QHSixSI for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 05:29:29 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) by ietfa.amsl.com (Postfix) with ESMTP id 80EF321F852A for <apps-discuss@ietf.org>; Sat, 13 Apr 2013 05:29:29 -0700 (PDT)
Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id A7E8FD04088; Sat, 13 Apr 2013 07:29:28 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1365856168; bh=crWTPJvCq7Yx01gJelGT7FHrbieu/dWEcaKoSKf8R/o=; h=In-Reply-To:References:Subject:From:Date:To:From; b=hAjKHXf6rbhjyaX8ZdsNIwEJvkBF5/Fs+mDVlUyIMaM4SGR3jv+EqgzdncyCqVx5t bQo4GPUW20qoUXgUQJttd6m5dMWM+3eXmMcisdtUROHeEuCJBPLXLyaowlKeKRxXIi zHBCgHSWzHsVA0YFwP6/oBwGDASIjhoKDjx5kVAw=
Received: from [IPV6:2600:1002:b10b:eb7d:82bb:5363:3b75:3fe3] (unknown [IPv6:2600:1002:b10b:eb7d:82bb:5363:3b75:3fe3]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 3E86AD04059;  Sat, 13 Apr 2013 07:29:27 -0500 (CDT)
User-Agent: K-9 Mail for Android
In-Reply-To: <5169438B.3010400@dcrocker.net>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <6600677.x1Szm294G3@scott-latitude-e6320> <5168C0FA.9020709@dcrocker.net> <0d7d06e2-a54b-45ec-a33f-dbfa2b20bc0e@email.android.com> <5169438B.3010400@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Scott Kitterman <scott@kitterman.com>
Date: Sat, 13 Apr 2013 08:29:24 -0400
To: apps-discuss@ietf.org
Message-ID: <96b24146-6c51-4002-946f-0c84e29a2acd@email.android.com>
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Apr 2013 12:29:30 -0000

Dave Crocker <dhc@dcrocker.net> wrote:

>Scott,
>
>
>On 4/12/2013 11:00 PM, Scott Kitterman wrote:
>>> So Scott, what changes to the DMARC base spec are you seeking and
>>> why and who wants them and how do we know this?
>>
>> In part, I don't. DMARC has been developed in private by a relatively
>> small group of people. I think it's not unreasonable to consider the
>> spec might be improved by broader review.
>
>  It's entirely reasonable.  That's why the draft charter provides for 
>such future effort: "However, if resolving any of the issues listed in 
>the areas of focus below does require changes to the base
>specification, 
>or if the specification needs to be revised to correct technical errors
>
>deemed essential for proper use, the group will recharter accordingly."
>
>  The specification has been public for considerably more than a year, 
>including a press release and a public discussion list, with adoption 
>covering roughly 60% of the world's mailboxes.  That's not a small base
>
>of experience.  So there's been plenty of opportunity for community 
>review and input, including requests for changes.  And yet, there is so
>
>far no such list of requests.
>
>
> >  Things that were written
>> by people who already "know" what the spec is supposed to mean are
>> often less clear to those outside the group. Until a broader group
>> actually reviews it, there's no way to know.
>
>   You are correct, of course.  However the range of implementers now 
>goes considerably beyond the original group, and yet there is so far no
>
>concrete list of interesting changes being requested.
>
>
>> That's not a matter of changing the protocol, but improving the text.
>
>    Well, that's what we originally submitted for chartering, but at 
>least one AD didn't like it.

I'll respond to the balance of your message once I'm back at a computer since collecting the relevant references using just my phone would be excessively painful. 

Was the one AD that didn't like it the discussion on this list or elsewhere? If it was elsewhere, please provide a reference so we can understand the nature of the objection.

Scott K


From paul.hoffman@vpnc.org  Sat Apr 13 07:13:56 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2D921F8556 for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 07:13:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTdyiOO85Npf for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 07:13:56 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 07E8D21F8550 for <apps-discuss@ietf.org>; Sat, 13 Apr 2013 07:13:56 -0700 (PDT)
Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3DEDqdq044186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <apps-discuss@ietf.org>; Sat, 13 Apr 2013 07:13:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com>
Date: Sat, 13 Apr 2013 07:13:52 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <980EF5BE-EE46-4D93-BD85-2A991C93BD35@vpnc.org>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
X-Mailer: Apple Mail (2.1503)
Subject: [apps-discuss] DMARC and the conflict of extensions vs. deployment
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Apr 2013 14:13:57 -0000

=3D=3D=3D=3D=3D
The initial charter for this working group does not include revising the =
base specification, but rather producing incremental extensions to it. =
However, if resolving any of the issues listed in the areas of focus =
below does require changes to the base specification, or if the =
specification needs to be revised to correct technical errors deemed =
essential for proper use, the group will recharter accordingly.
=3D=3D=3D=3D=3D

To me, this says "the WG should produce incremental extensions where =
needed". However:

=3D=3D=3D=3D=3D
At the time of chartering, DMARC has already achieved an estimated =
coverage of 60% of the Internet's mailboxes. Consequently, any =
extensions or revisions that create software or operations =
incompatibilities with this significant installed base need to be =
considered carefully. The strong preference is for the working group to =
preserve existing software and procedures. For changes likely to affect =
the installed base, the working group will actively seek to include =
developers and operators of DMARC-based mechanisms outside the core set =
of working group participants in its consensus discussions.
=3D=3D=3D=3D=3D

To me, that says that the WG cannot produce an incremental extension =
because existing software and procedures would have to be updated.  That =
statement seems to include even the listed milestones. For example, I =
cannot see how to make DMARC work with mailing lists without changing =
software and/or procedures. Similarly, even if there is agreement on =
transitive trust agreements will change procedures significantly.

If the people proposing the charter want a WG that extends the base =
spec, the latter paragraph needs to be removed. If the people proposing =
the charter want a WG that does not change the software and operations =
currently deployed, the first paragraph needs to be remove, and make it =
clear that the WG's only deliverables are the implementation and =
deployment guide and practices guides from later in the charter.

Having both paragraphs in the charter leaves the WG participants not =
knowing what it is they can do, and yet that knowing is exactly why the =
IETF has charters.



Assuming that the people proposing the charter really want the =
limitations from the second quote above (which seems likely), I propose =
that the WG not be formed. Forming a WG with limitations that are =
imposed from outside the IETF will cause the waste of hundreds or =
thousands of IETF participant hours. The phrase "needs to be considered =
carefully" is a call to endless debates about what "carefully" means and =
who ultimately gets to be the careful considerers who count.

The main proponents of the private DMARC spec are already active IETF =
participants. They can recruit the rest of us to join the private DMARC =
work effort without wasting a lot of IETF time on helping a private =
effort. They can send mail to AppsArea when they want people to join =
their private discussions on extensions to DMARC. They can (and should!) =
update people at the face-to-face IETF meetings. They can (and should!) =
publishing the results of their private efforts as RFCs through the ISE; =
that's a great use of the ISE track of RFCs. But trying to have an IETF =
WG-that-isn't-really-a-WG seems wasteful of valuable resources.

Note: if I'm wrong above and the people proposing the charter ditch the =
restrictions of the second quote, the charter still needs more work, =
namely adding a sentence or two to each deliverable about what is =
expected of those extensions.

--Paul Hoffman=

From dhc@dcrocker.net  Sat Apr 13 13:55:54 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9DE621F8DFC for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 13:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.556
X-Spam-Level: 
X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqB2LvOw8nfZ for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 13:55:52 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D27E421F8D92 for <apps-discuss@ietf.org>; Sat, 13 Apr 2013 13:55:52 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3DKtp7l029036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Apr 2013 13:55:52 -0700
Message-ID: <5169C64F.4070201@dcrocker.net>
Date: Sat, 13 Apr 2013 13:55:43 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Scott Kitterman <scott@kitterman.com>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <6600677.x1Szm294G3@scott-latitude-e6320> <5168C0FA.9020709@dcrocker.net> <0d7d06e2-a54b-45ec-a33f-dbfa2b20bc0e@email.android.com> <5169438B.3010400@dcrocker.net> <96b24146-6c51-4002-946f-0c84e29a2acd@email.android.com>
In-Reply-To: <96b24146-6c51-4002-946f-0c84e29a2acd@email.android.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 13 Apr 2013 13:55:52 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Apr 2013 20:55:54 -0000

On 4/13/2013 5:29 AM, Scott Kitterman wrote:
> Was the one AD that didn't like it the discussion on this list or elsewhere?


This (apps-discuss) list.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From dhc@dcrocker.net  Sat Apr 13 14:01:24 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4A021F8D92 for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 14:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.562
X-Spam-Level: 
X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxSw+bP7sogC for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 14:01:24 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1350F21F8D90 for <apps-discuss@ietf.org>; Sat, 13 Apr 2013 14:01:24 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3DL1NbM029125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Apr 2013 14:01:23 -0700
Message-ID: <5169C79A.2050402@dcrocker.net>
Date: Sat, 13 Apr 2013 14:01:14 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <980EF5BE-EE46-4D93-BD85-2A991C93BD35@vpnc.org>
In-Reply-To: <980EF5BE-EE46-4D93-BD85-2A991C93BD35@vpnc.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 13 Apr 2013 14:01:23 -0700 (PDT)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC and the conflict of extensions vs. deployment
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Apr 2013 21:01:25 -0000

On 4/13/2013 7:13 AM, Paul Hoffman wrote:
> At the time of chartering, DMARC has already achieved an estimated coverage of 60% of the Internet's mailboxes. Consequently, any extensions or revisions that create software or operations incompatibilities with this significant installed base need to be considered carefully. The strong preference is for the working group to preserve existing software and procedures. For changes likely to affect the installed base, the working group will actively seek to include developers and operators of DMARC-based mechanisms outside the core set of working group participants in its consensus discussions.
> =====
>
> To me, that says that the WG cannot produce an incremental extension because existing software and procedures would have to be updated.


Speaking for myself only, of course, but...


That's an unexpected interpretation of the text.

Normally, an "incremental extension" is taken to mean that it provides 
/additional/ capabilities that are not essential to core operation. 
(cf., smtp extensions or mime).

That is, whatever was original working will still work, albeit without 
whatever new and spiffy capabilities are specified in the incremental 
extensions.

By way of a marked contrast, cf. IPv4 vs. IPv6.

While I can certainly imagine a frame of mind that counts IPv6 as an 
"incremental extension" to IPv4, that frame of mind is certainly not the 
one intended for reading the draft charter.

To summarize:  the charter seeks to constrain work that might /force/ a 
change in the existing installed base, by virtue of creating an 
interoperability problem, rather than to necessarily constrain value-add 
enhancements that are optional.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From paul.hoffman@vpnc.org  Sat Apr 13 15:06:58 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C96121F8E72 for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 15:06:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujuyQ8jpVpGd for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 15:06:57 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 65BF921F863C for <apps-discuss@ietf.org>; Sat, 13 Apr 2013 15:06:57 -0700 (PDT)
Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r3DM6pgP056057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 13 Apr 2013 15:06:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <5169C79A.2050402@dcrocker.net>
Date: Sat, 13 Apr 2013 15:06:51 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <BC12EAE3-0A70-4769-A19F-0CAA5143EE69@vpnc.org>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <980EF5BE-EE46-4D93-BD85-2A991C93BD35@vpnc.org> <5169C79A.2050402@dcrocker.net>
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.1503)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC and the conflict of extensions vs. deployment
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Apr 2013 22:06:58 -0000

Thanks, this is very helpful, and may make the charter proposal much =
more palatable.

On Apr 13, 2013, at 2:01 PM, Dave Crocker <dhc@dcrocker.net> wrote:

> Normally, an "incremental extension" is taken to mean that it provides =
/additional/ capabilities that are not essential to core operation. =
(cf., smtp extensions or mime).

I would not say that is the "normal" definition of an incremental =
extension, but it is one that helps here. Given that, and the obvious =
distaste for revisions that would force changes in the deployed servers, =
would the following shorter paragraph be an acceptable replacement for =
the two paragraphs in question ("The initial charter..." and "At the =
time...")?

=3D=3D=3D=3D=3D
The initial charter for this Working Group consists only of incremental =
extensions to the base specification.  An incremental extension is one =
that would allow an extended system to interoperate with an unextended =
system. This charter explicitly does not include revising the base =
specification. If creating any of the WG deliverables requires =
non-interoperable changes to the base specification, or if the =
specification needs to be revised to correct technical errors deemed =
essential for proper use, the group would need to recharter to revise =
the base specification in the specific areas needed.
=3D=3D=3D=3D=3D

This wording removes the conflation of extensions and revisions in the =
current charter text, it removes sentences about why the WG should avoid =
rechartering, and makes it completely clear what the boundaries for the =
listed WG work items are.

Having said that, I think both the current text and my proposal above =
have a thorny constitutional problem: if the WG recharters to change a =
problem in the base specification, the WG would be working on an =
protocol that is an RFC that is outside the IETF Stream. I suspect that =
that should only be done if the result is bringing the revised base spec =
into the IETF Stream as an Standards Track document. But I think that =
issue can be noted here (not in the charter) and only raised if the =
recharter actually happens.

--Paul Hoffman=

From superuser@gmail.com  Sat Apr 13 16:25:43 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1DE21F8E9E for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 16:25:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.535
X-Spam-Level: 
X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOlz5E25lUKK for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 16:25:43 -0700 (PDT)
Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C8C3B21F8B08 for <apps-discuss@ietf.org>; Sat, 13 Apr 2013 16:25:42 -0700 (PDT)
Received: by mail-we0-f175.google.com with SMTP id t11so2872339wey.20 for <apps-discuss@ietf.org>; Sat, 13 Apr 2013 16:25:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=1ZDGKaaHEBBR9Ee+oS0cPWQcQYXFLkOoPqwvnGfPfkQ=; b=MuXAymB+O/tvYdX8njax4kLB4duzFCfimf49lSRNsVCteRBWtVjtIEBjGtcMQissZT JZKabntj7t+S6zzCpDcTqfqw8p1Jc+Gnwa7EXpBDfkwNDyuarR/fV724odTS7xjf+qrD SzW4nGOGuP4hJZU4kV+4Bb5DDibqR5P9n4jhAoS6W4YZYVgd7mXM6YgVNTO20GxuJ2wj 6ZBSVWcbZdC+xLShuz/P7YJOkUZuBfce5Q+EI3jaI6aU9VZehH5EN4Qq0JTrgfDJWTL/ tSKRijy08N9VfOianZQ+MD13LN5TRYLo6d/+7KbzZ5Y6X3u5akfMDkDonZ0QYtr+YaPV qmvA==
MIME-Version: 1.0
X-Received: by 10.180.37.73 with SMTP id w9mr1308378wij.32.1365895541968; Sat, 13 Apr 2013 16:25:41 -0700 (PDT)
Received: by 10.180.36.176 with HTTP; Sat, 13 Apr 2013 16:25:41 -0700 (PDT)
In-Reply-To: <BC12EAE3-0A70-4769-A19F-0CAA5143EE69@vpnc.org>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <980EF5BE-EE46-4D93-BD85-2A991C93BD35@vpnc.org> <5169C79A.2050402@dcrocker.net> <BC12EAE3-0A70-4769-A19F-0CAA5143EE69@vpnc.org>
Date: Sat, 13 Apr 2013 16:25:41 -0700
Message-ID: <CAL0qLwb9XRBYwAXBGXxrGjzejf7jAMJcNERo3yu1JM-dm4L-gA@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary=e89a8f502ee894565604da465653
Cc: Dave Crocker <dcrocker@bbiw.net>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC and the conflict of extensions vs. deployment
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Apr 2013 23:25:44 -0000

--e89a8f502ee894565604da465653
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Apr 13, 2013 at 3:06 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> Having said that, I think both the current text and my proposal above have
> a thorny constitutional problem: if the WG recharters to change a problem
> in the base specification, the WG would be working on an protocol that is
> an RFC that is outside the IETF Stream. I suspect that that should only be
> done if the result is bringing the revised base spec into the IETF Stream
> as an Standards Track document. But I think that issue can be noted here
> (not in the charter) and only raised if the recharter actually happens.
>
>
>
I'm pretty sure the intent is to publish the current base draft through the
ISE, since it was developed outside the IETF, but if it changes (via
rechartering), move it to the IETF stream.  The latter can obsolete the
former if the timing warrants doing so.  Thus, if the working group is ever
actually cracking open the base draft, it's on the IETF stream.

--e89a8f502ee894565604da465653
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sat, Apr 13, 2013 at 3:06 PM, Paul Hoffman <span dir=3D=
"ltr">&lt;<a href=3D"mailto:paul.hoffman@vpnc.org" target=3D"_blank">paul.h=
offman@vpnc.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Having said that, I think both the current t=
ext and my proposal above have a thorny constitutional problem: if the WG r=
echarters to change a problem in the base specification, the WG would be wo=
rking on an protocol that is an RFC that is outside the IETF Stream. I susp=
ect that that should only be done if the result is bringing the revised bas=
e spec into the IETF Stream as an Standards Track document. But I think tha=
t issue can be noted here (not in the charter) and only raised if the recha=
rter actually happens.<br>

<span class=3D"HOEnZb"><font color=3D"#888888"><br><br></font></span></bloc=
kquote><br></div><div class=3D"gmail_quote">I&#39;m pretty sure the intent =
is to publish the current base draft through the ISE, since it was develope=
d outside the IETF, but if it changes (via rechartering), move it to the IE=
TF stream.=A0 The latter can obsolete the former if the timing warrants doi=
ng so.=A0 Thus, if the working group is ever actually cracking open the bas=
e draft, it&#39;s on the IETF stream.<br>
</div></div></div>

--e89a8f502ee894565604da465653--

From MHammer@ag.com  Sat Apr 13 18:03:37 2013
Return-Path: <MHammer@ag.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2C321F8AF8 for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 18:03:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtcydawF1EH2 for <apps-discuss@ietfa.amsl.com>; Sat, 13 Apr 2013 18:03:36 -0700 (PDT)
Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) by ietfa.amsl.com (Postfix) with ESMTP id 431F221F8A6B for <apps-discuss@ietf.org>; Sat, 13 Apr 2013 18:03:36 -0700 (PDT)
Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.02.0328.009; Sat, 13 Apr 2013 21:03:34 -0400
From: "MH Michael Hammer (5304)" <MHammer@ag.com>
To: "dcrocker@bbiw.net" <dcrocker@bbiw.net>, Paul Hoffman <paul.hoffman@vpnc.org>
Thread-Topic: [apps-discuss] DMARC and the conflict of extensions vs. deployment
Thread-Index: AQHOOIoRlPdaPR4eKE2ku5GDO9sgvZjU5bgw
Date: Sun, 14 Apr 2013 01:03:34 +0000
Message-ID: <CE39F90A45FF0C49A1EA229FC9899B05648B66@USCLES544.agna.amgreetings.com>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <980EF5BE-EE46-4D93-BD85-2A991C93BD35@vpnc.org> <5169C79A.2050402@dcrocker.net>
In-Reply-To: <5169C79A.2050402@dcrocker.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.104.254.232]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] DMARC and the conflict of extensions vs.	deployment
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Apr 2013 01:03:37 -0000

Daves comments match my understanding of the intent of the draft charter.

Mike

> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-
> bounces@ietf.org] On Behalf Of Dave Crocker
> Sent: Saturday, April 13, 2013 5:01 PM
> To: Paul Hoffman
> Cc: IETF Apps Discuss
> Subject: Re: [apps-discuss] DMARC and the conflict of extensions vs.
> deployment
>=20
>=20
>=20
> On 4/13/2013 7:13 AM, Paul Hoffman wrote:
> > At the time of chartering, DMARC has already achieved an estimated
> coverage of 60% of the Internet's mailboxes. Consequently, any extensions
> or revisions that create software or operations incompatibilities with th=
is
> significant installed base need to be considered carefully. The strong
> preference is for the working group to preserve existing software and
> procedures. For changes likely to affect the installed base, the working =
group
> will actively seek to include developers and operators of DMARC-based
> mechanisms outside the core set of working group participants in its
> consensus discussions.
> > =3D=3D=3D=3D=3D
> >
> > To me, that says that the WG cannot produce an incremental extension
> because existing software and procedures would have to be updated.
>=20
>=20
> Speaking for myself only, of course, but...
>=20
>=20
> That's an unexpected interpretation of the text.
>=20
> Normally, an "incremental extension" is taken to mean that it provides
> /additional/ capabilities that are not essential to core operation.
> (cf., smtp extensions or mime).
>=20
> That is, whatever was original working will still work, albeit without wh=
atever
> new and spiffy capabilities are specified in the incremental extensions.
>=20
> By way of a marked contrast, cf. IPv4 vs. IPv6.
>=20
> While I can certainly imagine a frame of mind that counts IPv6 as an
> "incremental extension" to IPv4, that frame of mind is certainly not the =
one
> intended for reading the draft charter.
>=20
> To summarize:  the charter seeks to constrain work that might /force/ a
> change in the existing installed base, by virtue of creating an interoper=
ability
> problem, rather than to necessarily constrain value-add enhancements that
> are optional.
>=20
> d/
> --
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From bclaise@cisco.com  Mon Apr 15 03:22:07 2013
Return-Path: <bclaise@cisco.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF8F21F9318; Mon, 15 Apr 2013 03:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKl4HjpG7DTE; Mon, 15 Apr 2013 03:22:06 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB5D21F9305; Mon, 15 Apr 2013 03:22:06 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3FALmIR021118; Mon, 15 Apr 2013 12:21:48 +0200 (CEST)
Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3FAL01o003398; Mon, 15 Apr 2013 12:21:16 +0200 (CEST)
Message-ID: <516BD48C.9070204@cisco.com>
Date: Mon, 15 Apr 2013 12:21:00 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: S Moonesamy <sm+ietf@elandsys.com>
References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> <6.2.5.6.2.20130409084702.0c6104b8@elandnews.com> <001501ce35be$68c93c00$3a5bb400$@dantonio@uniparthenope.it> <6.2.5.6.2.20130410010433.0ca8b920@elandnews.com>
In-Reply-To: <6.2.5.6.2.20130410010433.0ca8b920@elandnews.com>
Content-Type: multipart/alternative; boundary="------------010705090806020107060306"
Cc: apps-discuss@ietf.org, Salvatore D'Antonio <salvatore.dantonio@uniparthenope.it>, iesg@ietf.org, ipfix@ietf.org, draft-ietf-ipfix-flow-selection-tech.all@tools.ietf.org
Subject: Re: [apps-discuss] Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt> (APPSDIR review)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2013 10:22:07 -0000

This is a multi-part message in MIME format.
--------------010705090806020107060306
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Salvatore, document shepherd,
> Hi Salvatore,
> At 00:38 10-04-2013, Salvatore D'Antonio wrote:
>> I did not adequately addressed your comment because I thought that the
>> guidelines specified in RFC 5226 were sufficient to deal with the issues
>> concerning the management of the sub-registry.
>
> Ok.
>
>> I would greatly appreciate if you could provide me with the reference 
>> to a
>> Draft where documentation and criteria for managing assignments are
>> specified so that I may use such Draft as an example.
>
> Section 4.1 of RFC 5226 points to Sections 6 and 7.2 in RFC 3748 as an 
> example about Expert Review.  Section 7.1 of RFC 5102 is another 
> example.  I suggest discussing the proposed change with the document 
> shepherd or the Area Director to see whether it is appropriate.
A similar example is http://tools.ietf.org/html/rfc5476#section-8.2, 
which refers to http://tools.ietf.org/html/rfc5477#section-8.2.1

Combining this text with your IANA considerations, this should be...
Document shepherd and authors, please double-check, it's easy to make a 
mistake.


            9.1.1
            <http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-15#section-9.1.1>.
            flowSelectorAlgorithm


        Description:

           This Information Element identifies the Intermediate Flow
           Selection Process technique (e.g., Filtering, Sampling) that is
           applied by the Intermediate Flow Selection Process.

           Most of these techniques have parameters.  Its configuration
           parameter(s) MUST be clearly specified.  Further Information
           Elements are needed to fully specify packet selection with these
           methods and all their parameters.

           Further method identifiers may be added to the list below.  It
           might be necessary to define new Information Elements to specify
           their parameters.

           The flowSelectorAlgorithm registry is maintained by IANA.  New
           assignments for the registry will be administered by IANA, on a
           First Come First Served basis [RFC5226  <http://tools.ietf.org/html/rfc5226>], subject to Expert Review
           [RFC5226  <http://tools.ietf.org/html/rfc5226>].

           The registry can be updated when specifications of the new
           method(s) and any new Information Elements are provided.

           The group of experts must double check the flowSelectorAlgorithm
           definitions and Information Elements with already defined
           flowSelectorAlgorithm and Information Elements for completeness,
           accuracy, and redundancy.  Those experts will initially be drawn
           from the Working Group Chairs and document editors of the IPFIX
           and PSAMP Working Groups.

           The following Intermediate Flow Selection Process Techniques
           identifiers are defined here:
        

               +----+------------------------+--------------------------+
               | ID |        Technique       |      Parameters          |
               +----+------------------------+--------------------------+
               | 1  | Systematic count-based | flowSamplingInterval     |
               |    | Sampling               | flowSamplingSpacing      |
               +----+------------------------+--------------------------+
               | 2  | Systematic time-based  | flowSamplingTimeInterval |
               |    | Sampling               | flowSamplingTimeSpacing  |
               +----+------------------------+--------------------------+
               | 3  | Random n-out-of-N      | samplingSize             |
               |    | Sampling               | samplingPopulation       |
               +----+------------------------+--------------------------+
               | 4  | Uniform probabilistic  | samplingProbability      |
               |    | Sampling               |                          |
               +----+------------------------+--------------------------+
               | 5  | Property Match         | Information Element      |
               |    | Filtering              | Value Range              |
               +----+------------------------+--------------------------+
               |   Hash-based Filtering      | hashInitialiserValue     |
               +----+------------------------+ hashFlowDomain           |
               | 6  | using BOB              | hashSelectedRangeMin     |
               +----+------------------------+ hashSelectedRangeMax     |
               | 7  | using IPSX             | hashOutputRangeMin       |
               +----+------------------------+ hashOutputRangeMax       |
               | 8  | using CRC              |                          |
               +----+------------------------+--------------------------+
               | 9  | Flow-state Dependent   | No agreed Parameters     |
               |    | Intermediate Flow      |                          |
               |    | Selection Process      |                          |
               +----+------------------------+--------------------------+

                   Intermediate Flow Selection Process Techniques

        Abstract Data Type: unsigned16

        ElementId: TBD1

        Data Type Semantics: identifier

        Status: Current


Regards, Benoit.



--------------010705090806020107060306
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Salvatore, document shepherd,<br>
    </div>
    <blockquote
      cite="mid:6.2.5.6.2.20130410010433.0ca8b920@elandnews.com"
      type="cite">Hi Salvatore,
      <br>
      At 00:38 10-04-2013, Salvatore D'Antonio wrote:
      <br>
      <blockquote type="cite">I did not adequately addressed your
        comment because I thought that the
        <br>
        guidelines specified in RFC 5226 were sufficient to deal with
        the issues
        <br>
        concerning the management of the sub-registry.
        <br>
      </blockquote>
      <br>
      Ok.
      <br>
      <br>
      <blockquote type="cite">I would greatly appreciate if you could
        provide me with the reference to a
        <br>
        Draft where documentation and criteria for managing assignments
        are
        <br>
        specified so that I may use such Draft as an example.
        <br>
      </blockquote>
      <br>
      Section 4.1 of RFC 5226 points to Sections 6 and 7.2 in RFC 3748
      as an example about Expert Review.&nbsp; Section 7.1 of RFC 5102 is
      another example.&nbsp; I suggest discussing the proposed change with
      the document shepherd or the Area Director to see whether it is
      appropriate.
      <br>
    </blockquote>
    A similar example is <a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc5476#section-8.2">http://tools.ietf.org/html/rfc5476#section-8.2</a>,
    which refers to <a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc5477#section-8.2.1">http://tools.ietf.org/html/rfc5477#section-8.2.1</a><br>
    <br>
    Combining this text with your IANA considerations, this should be...<br>
    Document shepherd and authors, please double-check, it's easy to
    make a mistake.<br>
    <br>
    <blockquote>
      <pre class="newpage"><span class="h4"><h4><a class="selflink" name="section-9.1.1" href="http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-15#section-9.1.1">9.1.1</a>.  flowSelectorAlgorithm</h4></span>
   Description:

      This Information Element identifies the Intermediate Flow
      Selection Process technique (e.g., Filtering, Sampling) that is
      applied by the Intermediate Flow Selection Process.  

      Most of these techniques have parameters.  Its configuration 
      parameter(s) MUST be clearly specified.  Further Information
      Elements are needed to fully specify packet selection with these
      methods and all their parameters. 

      Further method identifiers may be added to the list below.  It
      might be necessary to define new Information Elements to specify
      their parameters.

      The flowSelectorAlgorithm registry is maintained by IANA.  New
      assignments for the registry will be administered by IANA, on a 
      First Come First Served basis [<a href="http://tools.ietf.org/html/rfc5226" title="&quot;Guidelines for Writing an IANA Considerations Section in RFCs&quot;">RFC5226</a>], subject to Expert Review 
      [<a href="http://tools.ietf.org/html/rfc5226" title="&quot;Guidelines for Writing an IANA Considerations Section in RFCs&quot;">RFC5226</a>].

      The registry can be updated when specifications of the new
      method(s) and any new Information Elements are provided.

      The group of experts must double check the flowSelectorAlgorithm 
      definitions and Information Elements with already defined
      flowSelectorAlgorithm and Information Elements for completeness,
      accuracy, and redundancy.  Those experts will initially be drawn
      from the Working Group Chairs and document editors of the IPFIX
      and PSAMP Working Groups.

      The following Intermediate Flow Selection Process Techniques
      identifiers are defined here:
&nbsp;&nbsp; 

          +----+------------------------+--------------------------+
          | ID |        Technique       |      Parameters          |
          +----+------------------------+--------------------------+
          | 1  | Systematic count-based | flowSamplingInterval     |
          |    | Sampling               | flowSamplingSpacing      |
          +----+------------------------+--------------------------+
          | 2  | Systematic time-based  | flowSamplingTimeInterval |
          |    | Sampling               | flowSamplingTimeSpacing  |
          +----+------------------------+--------------------------+
          | 3  | Random n-out-of-N      | samplingSize             |
          |    | Sampling               | samplingPopulation       |
          +----+------------------------+--------------------------+
          | 4  | Uniform probabilistic  | samplingProbability      |
          |    | Sampling               |                          |
          +----+------------------------+--------------------------+
          | 5  | Property Match         | Information Element      |
          |    | Filtering              | Value Range              |
          +----+------------------------+--------------------------+
          |   Hash-based Filtering      | hashInitialiserValue     |
          +----+------------------------+ hashFlowDomain           |
          | 6  | using BOB              | hashSelectedRangeMin     |
          +----+------------------------+ hashSelectedRangeMax     |
          | 7  | using IPSX             | hashOutputRangeMin       |
          +----+------------------------+ hashOutputRangeMax       |
          | 8  | using CRC              |                          |
          +----+------------------------+--------------------------+
          | 9  | Flow-state Dependent   | No agreed Parameters     |
          |    | Intermediate Flow      |                          |
          |    | Selection Process      |                          |
          +----+------------------------+--------------------------+

              Intermediate Flow Selection Process Techniques

   Abstract Data Type: unsigned16

   ElementId: TBD1

   Data Type Semantics: identifier

   Status: Current</pre>
    </blockquote>
    <br>
    Regards, Benoit.<br>
    <pre class="newpage"><span class="h4"></span></pre>
    <br>
  </body>
</html>

--------------010705090806020107060306--

From bclaise@cisco.com  Mon Apr 15 02:44:32 2013
Return-Path: <bclaise@cisco.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A8821F9393; Mon, 15 Apr 2013 02:44:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAhkDykt+3bA; Mon, 15 Apr 2013 02:44:30 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0A91921F938E; Mon, 15 Apr 2013 02:44:29 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3F9iA4R016779; Mon, 15 Apr 2013 11:44:10 +0200 (CEST)
Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r3F9glMg020166; Mon, 15 Apr 2013 11:43:07 +0200 (CEST)
Message-ID: <516BCB97.9040404@cisco.com>
Date: Mon, 15 Apr 2013 11:42:47 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "Salvatore D'Antonio" <salvatore.dantonio@uniparthenope.it>
References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it>
In-Reply-To: <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it>
Content-Type: multipart/alternative; boundary="------------040708030002030600080801"
X-Mailman-Approved-At: Mon, 15 Apr 2013 08:41:56 -0700
Cc: rahulp@cisco.com, 'IETF discussion list' <ietf@ietf.org>, draft-ietf-ipfix-flow-selection-tech@tools.ietf.org, apps-discuss@ietf.org, 'General Area Review Team' <gen-art@ietf.org>, 'S Moonesamy' <sm+ietf@elandsys.com>, ipfix-chairs@tools.ietf.org, ipfix@ietf.org, iesg@ietf.org, "'Joel M. Halpern'" <jmh@joelhalpern.com>, "'A. Jean Mahoney'" <mahoney@nostrum.com>
Subject: Re: [apps-discuss] R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2013 09:44:32 -0000

This is a multi-part message in MIME format.
--------------040708030002030600080801
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Salvatore
>
> Dear all,
>
> A new version of the Internet Draft on Flow Selection Techniques has 
> been submitted. It contains the following changes:
>
> -A new section illustrating the difference between Intermediate Flow 
> Selection Process and Intermediate Selection Process has been added,
>
> -The sentence "In order to be compliant with this document, at least 
> the Property  Match Filtering MUST be implemented." has been removed 
> in Section 1,
>
> -“MUST” has been replaced with “SHOULD” in Section 5.1,
>
Actually, the feedback was:

    In Section 1:

       "In order to be compliant with this document, at least the Property
        Match Filtering MUST be implemented."

    The above text is repeated in Section 5.1.  I suggest removing this
    sentence as it does not seem related to scope.

    My reading of the "MUST" is that it is being used for compliance
    instead of the reasons described in RFC 2119.  I suggest reviewing
    the usage of RFC 2119 key words in Section 5.1.

So the solution is not to change MUST to SHOULD.
The question is whether "MUST" versus "must" must be used.
I understand the concern. For compliance reason with the PSAMP RFC 5475 
(which is closely related) ...


        7 <http://tools.ietf.org/html/rfc5475#section-7>. Parameters for
        the Description of Selection Techniques

        This section gives an overview of different alternative selection
        schemes and their required parameters.  In order to be compliant with
        PSAMP, at least one of proposed schemes MUST be implemented.

... I would keep the initial "MUST" from the previous draft version.

> -“The flowSelectorAlgorithm registry is maintained by IANA." has been 
> replaced with “IANA is requested to create the flowSelectorAlgorithm 
> registry.”
>
> -The sentence "The registry can be updated when specifications of the 
> new  technique(s) and any new Information Elements are provided." has 
> been removed since it did not clarify how the registry will be managed.
>
> - Section 6.1.1 “Property Match Filtering” has been changed by adding 
> some text on how Property Match Filtering can be  used by an 
> Intermediate Flow Selection Process in the Metering Process, in the 
>  Exporting Process and within an IPFIX Mediator.
>
When publishing a new version, please correct this editorial issue.

  " ... and Flow duration. in
    the An example is the selection of the largest ..."


> Best regards,
>
> Salvatore
>
> *Da:*Benoit Claise [mailto:bclaise@cisco.com]
> *Inviato:* lunedì 8 aprile 2013 15:21
> *A:* draft-ietf-ipfix-flow-selection-tech@tools.ietf.org
> *Cc:* ipfix-chairs@tools.ietf.org
> *Oggetto:* Fwd: Last Call Expired: 
> <draft-ietf-ipfix-flow-selection-tech-14.txt>
>
> Dear authors,
>
> The IETF last call has finished.
> Can you please update your draft based on the feedback received.
> Then I will progress it.
>
> Regards, Benoit
>
>
>
> -------- Original Message --------
>
> *Subject: *
>
> 	
>
> Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>
>
> *Date: *
>
> 	
>
> Mon, 01 Apr 2013 00:28:46 -0700
>
> *From: *
>
> 	
>
> DraftTracker Mail System <iesg-secretary@ietf.org> 
> <mailto:iesg-secretary@ietf.org>
>
> *To: *
>
> 	
>
> iesg@ietf.org <mailto:iesg@ietf.org>, ipfix-chairs@tools.ietf.org 
> <mailto:ipfix-chairs@tools.ietf.org>, 
> draft-ietf-ipfix-flow-selection-tech@tools.ietf.org 
> <mailto:draft-ietf-ipfix-flow-selection-tech@tools.ietf.org>
>
> *CC: *
>
> 	
>
> iesg-secretary@ietf.org <mailto:iesg-secretary@ietf.org>
>
> Please DO NOT reply to this email.
>   
> I-D: <draft-ietf-ipfix-flow-selection-tech-14.txt>
> ID Tracker URL:http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/
>   
> IETF Last Call has ended, and the state has been changed to
> Waiting for AD Go-Ahead.
>   
>   
>   
>
> ------------------------------------------------------------------------
>
> Nessun virus nel messaggio.
> Controllato da AVG - www.avg.com <http://www.avg.com>
> Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di 
> rilascio: 07/04/2013
>
>
> *******************************************************************************************************
>
> IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO
>
> Il 5 per mille all'Università degli Studi di Napoli 
> "Parthenope"incrementa le borse di studio agli studenti - codice 
> fiscale *80018240632*
>
> _http://www.uniparthenope.it/index.php/5xmille_
>
> _http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille_
>
>
> Questa informativa è inserita in automatico dal sistema al fine 
> esclusivo della realizzazione dei fini istituzionali dell'ente.
>
>
>
>
> *******************************************************************************************************
>
> IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO
>
> Il 5 per mille all'Università degli Studi di Napoli 
> "Parthenope"incrementa le borse di studio agli studenti - codice 
> fiscale *80018240632*
>
> _http://www.uniparthenope.it/index.php/5xmille_
>
> _http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille_
>
>
> Questa informativa è inserita in automatico dal sistema al fine 
> esclusivo della realizzazione dei fini istituzionali dell'ente.
>
>
>


--------------040708030002030600080801
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Salvatore<br>
    </div>
    <blockquote
      cite="mid:005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <meta name="Generator" content="Microsoft Word 12 (filtered
        medium)">
      <!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
      <style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"Segoe UI";
	panose-1:2 11 5 2 4 2 4 2 2 3;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"Preformattato HTML Carattere";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
span.PreformattatoHTMLCarattere
	{mso-style-name:"Preformattato HTML Carattere";
	mso-style-priority:99;
	mso-style-link:"Preformattato HTML";
	font-family:Consolas;
	color:black;}
span.StileMessaggioDiPostaElettronica19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 2.0cm 2.0cm 2.0cm;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:217212090;
	mso-list-type:hybrid;
	mso-list-template-ids:308057158 -1513439274 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
      <div class="Section1">
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Dear
            all,<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">A
            new version of the Internet Draft on Flow Selection
            Techniques
            has been submitted. It contains the following changes:<o:p></o:p></span></p>
        <p class="MsoListParagraph"
          style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span
              style="mso-list:Ignore">-<span style="font:7.0pt
                &quot;Times New Roman&quot;">         
              </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">A
            new section illustrating the difference between Intermediate
            Flow Selection Process and Intermediate Selection Process
            has been added,<o:p></o:p></span></p>
        <p class="MsoListParagraph"
          style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span
              style="mso-list:Ignore">-<span style="font:7.0pt
                &quot;Times New Roman&quot;">         
              </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">The
            sentence "In order to be compliant with this document,
            at least the Property  Match Filtering MUST be implemented."
            has been removed
            in Section 1,<o:p></o:p></span></p>
        <p class="MsoListParagraph"
          style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span
              style="mso-list:Ignore">-<span style="font:7.0pt
                &quot;Times New Roman&quot;">         
              </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">“MUST”
            has been replaced with “SHOULD” in Section 5.1,</span></p>
      </div>
    </blockquote>
    Actually, the feedback was:<br>
    <blockquote>In Section 1:
      <br>
      <br>
        "In order to be compliant with this document, at least the
      Property
      <br>
         Match Filtering MUST be implemented."
      <br>
      <br>
      The above text is repeated in Section 5.1.  I suggest removing
      this sentence as it does not seem related to scope.
      <br>
      <br>
      My reading of the "MUST" is that it is being used for compliance
      instead of the reasons described in RFC 2119.  I suggest reviewing
      the usage of RFC 2119 key words in Section 5.1.
      <br>
      <br>
    </blockquote>
    So the solution is not to change MUST to SHOULD.<br>
    The question is whether "MUST" versus "must" must be used.<br>
    I understand the concern. For compliance reason with the PSAMP RFC
    5475 (which is closely related) ...<br>
    <blockquote>
      <pre class="newpage"><span class="h2"><h2><a class="selflink" name="section-7" href="http://tools.ietf.org/html/rfc5475#section-7">7</a>.  Parameters for the Description of Selection Techniques</h2></span>   This section gives an overview of different alternative selection
   schemes and their required parameters.  In order to be compliant with
   PSAMP, at least one of proposed schemes MUST be implemented.

</pre>
    </blockquote>
    ... I would keep the initial "MUST" from the previous draft version.
    <blockquote> </blockquote>
    <blockquote
      cite="mid:005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it"
      type="cite">
      <div class="Section1">
        <p class="MsoListParagraph"
          style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p>
        <p class="MsoListParagraph"
          style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span
              style="mso-list:Ignore">-<span style="font:7.0pt
                &quot;Times New Roman&quot;">         
              </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">“The
            flowSelectorAlgorithm registry is maintained by IANA."
            has been replaced with “IANA is requested to create the
            flowSelectorAlgorithm
            registry.”<o:p></o:p></span></p>
        <p class="MsoListParagraph"
          style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span
              style="mso-list:Ignore">-<span style="font:7.0pt
                &quot;Times New Roman&quot;">         
              </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">The
            sentence "The registry can be updated when
            specifications of the new  technique(s) and any new
            Information Elements are
            provided." has been removed since it did not clarify how the
            registry will
            be managed.<o:p></o:p></span></p>
        <p class="MsoListParagraph"
          style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><span
              style="mso-list:Ignore">-<span style="font:7.0pt
                &quot;Times New Roman&quot;">         
              </span></span></span><!--[endif]--><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"> Section
            6.1.1 “Property Match Filtering” has been changed by
            adding some text on how Property Match Filtering can be
             used by an
            Intermediate Flow Selection Process in the Metering Process,
            in the  Exporting
            Process and within an IPFIX Mediator.</span></p>
      </div>
    </blockquote>
    When publishing a new version, please correct this editorial issue.<br>
    <br>
    <pre class="newpage"> " ... and Flow duration. in
   the An example is the selection of the largest ..."</pre>
    <br>
    <blockquote
      cite="mid:005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it"
      type="cite">
      <div class="Section1">
        <p class="MsoListParagraph"
          style="text-indent:-18.0pt;mso-list:l0 level1 lfo1"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Best
            regards,<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Salvatore<o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p> </o:p></span></p>
        <div>
          <div style="border:none;border-top:solid #B5C4DF
            1.0pt;padding:3.0pt 0cm 0cm 0cm">
            <p class="MsoNormal"><b><span
                  style="font-size:10.0pt;font-family:&quot;Segoe
                  UI&quot;,&quot;sans-serif&quot;;
                  color:windowtext" lang="IT">Da:</span></b><span
                style="font-size:10.0pt;
                font-family:&quot;Segoe
                UI&quot;,&quot;sans-serif&quot;;color:windowtext"
                lang="IT"> Benoit Claise
                [<a class="moz-txt-link-freetext" href="mailto:bclaise@cisco.com">mailto:bclaise@cisco.com</a>] <br>
                <b>Inviato:</b> lunedì 8 aprile 2013 15:21<br>
                <b>A:</b>
                <a class="moz-txt-link-abbreviated" href="mailto:draft-ietf-ipfix-flow-selection-tech@tools.ietf.org">draft-ietf-ipfix-flow-selection-tech@tools.ietf.org</a><br>
                <b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:ipfix-chairs@tools.ietf.org">ipfix-chairs@tools.ietf.org</a><br>
                <b>Oggetto:</b> Fwd: Last Call Expired:
                &lt;draft-ietf-ipfix-flow-selection-tech-14.txt&gt;<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Dear authors,<br>
          <br>
          The IETF last call has finished.<br>
          Can you please update your draft based on the feedback
          received.<br>
          Then I will progress it.<br>
          <br>
          Regards, Benoit<o:p></o:p></p>
        <div>
          <p class="MsoNormal"><br>
            <br>
            -------- Original Message -------- <o:p></o:p></p>
          <table class="MsoNormalTable" border="0" cellpadding="0"
            cellspacing="0">
            <tbody>
              <tr>
                <td style="padding:0cm 0cm 0cm 0cm" nowrap="nowrap"
                  valign="top">
                  <p class="MsoNormal" style="text-align:right"
                    align="right"><b>Subject: <o:p></o:p></b></p>
                </td>
                <td style="padding:0cm 0cm 0cm 0cm">
                  <p class="MsoNormal">Last Call Expired:
                    &lt;draft-ietf-ipfix-flow-selection-tech-14.txt&gt;<o:p></o:p></p>
                </td>
              </tr>
              <tr>
                <td style="padding:0cm 0cm 0cm 0cm" nowrap="nowrap"
                  valign="top">
                  <p class="MsoNormal" style="text-align:right"
                    align="right"><b>Date: <o:p></o:p></b></p>
                </td>
                <td style="padding:0cm 0cm 0cm 0cm">
                  <p class="MsoNormal">Mon, 01 Apr 2013 00:28:46 -0700<o:p></o:p></p>
                </td>
              </tr>
              <tr>
                <td style="padding:0cm 0cm 0cm 0cm" nowrap="nowrap"
                  valign="top">
                  <p class="MsoNormal" style="text-align:right"
                    align="right"><b>From: <o:p></o:p></b></p>
                </td>
                <td style="padding:0cm 0cm 0cm 0cm">
                  <p class="MsoNormal">DraftTracker Mail System <a
                      moz-do-not-send="true"
                      href="mailto:iesg-secretary@ietf.org">&lt;iesg-secretary@ietf.org&gt;</a><o:p></o:p></p>
                </td>
              </tr>
              <tr>
                <td style="padding:0cm 0cm 0cm 0cm" nowrap="nowrap"
                  valign="top">
                  <p class="MsoNormal" style="text-align:right"
                    align="right"><b>To: <o:p></o:p></b></p>
                </td>
                <td style="padding:0cm 0cm 0cm 0cm">
                  <p class="MsoNormal"><a moz-do-not-send="true"
                      href="mailto:iesg@ietf.org">iesg@ietf.org</a>, <a
                      moz-do-not-send="true"
                      href="mailto:ipfix-chairs@tools.ietf.org">ipfix-chairs@tools.ietf.org</a>,
                    <a moz-do-not-send="true"
                      href="mailto:draft-ietf-ipfix-flow-selection-tech@tools.ietf.org">draft-ietf-ipfix-flow-selection-tech@tools.ietf.org</a><o:p></o:p></p>
                </td>
              </tr>
              <tr>
                <td style="padding:0cm 0cm 0cm 0cm" nowrap="nowrap"
                  valign="top">
                  <p class="MsoNormal" style="text-align:right"
                    align="right"><b>CC: <o:p></o:p></b></p>
                </td>
                <td style="padding:0cm 0cm 0cm 0cm">
                  <p class="MsoNormal"><a moz-do-not-send="true"
                      href="mailto:iesg-secretary@ietf.org">iesg-secretary@ietf.org</a><o:p></o:p></p>
                </td>
              </tr>
            </tbody>
          </table>
          <p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
          <pre>Please DO NOT reply to this email.<o:p></o:p></pre>
          <pre><o:p> </o:p></pre>
          <pre>I-D: &lt;draft-ietf-ipfix-flow-selection-tech-14.txt&gt;<o:p></o:p></pre>
          <pre>ID Tracker URL: <a moz-do-not-send="true" href="http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/">http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/</a><o:p></o:p></pre>
          <pre><o:p> </o:p></pre>
          <pre>IETF Last Call has ended, and the state has been changed to<o:p></o:p></pre>
          <pre>Waiting for AD Go-Ahead.<o:p></o:p></pre>
          <pre><o:p> </o:p></pre>
          <pre><o:p> </o:p></pre>
          <pre><o:p> </o:p></pre>
          <p class="MsoNormal"><o:p> </o:p></p>
        </div>
        <p class="MsoNormal"><o:p> </o:p></p>
        <div class="MsoNormal" style="text-align:center" align="center">
          <hr style="color:#A0A0A0" noshade="noshade" size="1"
            width="100%" align="center">
        </div>
        <p class="MsoNormal"
          style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Nessun
virus
          nel messaggio.<br>
          Controllato da AVG - <a moz-do-not-send="true"
            href="http://www.avg.com">www.avg.com</a><br>
          Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data
          di rilascio:
          07/04/2013<o:p></o:p></p>
      </div>
      <br>
      <style type="text/css">

	<!--

		@page { margin-left: 2cm; margin-right: 2cm; margin-top: 2.5cm; margin-bottom: 2cm }

		P { margin-bottom: 0.21cm; direction: ltr; color: #000000; widows: 2; orphans: 2 }

		P.western { font-family: "Times New Roman", serif; font-size: 8pt; so-language: it-IT }

		P.cjk { font-family: "Times New Roman", serif; font-size: 8pt }

		P.ctl { font-family: "Times New Roman", serif; font-size: 8pt; so-language: ar-SA }

		A:link { color: #0000ff }

	-->

	</style>
      <!--</HEAD></BODY>-->
      <p text="#000000" link="#0000ff" dir="LTR" lang="it-IT">
      </p>
      <p class="western" style="margin-bottom: 0cm"><font face="Arial,
          sans-serif">*******************************************************************************************************</font></p>
      <p class="western" style="margin-bottom: 0cm"><font face="Arial,
          sans-serif">IL
          MERITO DEGLI STUDENTI VIENE RICONOSCIUTO</font></p>
      <p class="western" style="margin-bottom: 0cm"> </p>
      <p class="western" style="margin-bottom: 0cm"><font
          color="#000000"><font face="Arial, sans-serif">Il
            5 per mille all'Università degli Studi di Napoli
            "Parthenope"incrementa le borse di studio agli studenti
            - codice fiscale </font></font><font color="#000000"><font
            face="Arial, sans-serif"><b>80018240632</b></font></font><font
          color="#000000"><font face="Arial, sans-serif">
          </font></font>
      </p>
      <p class="western" style="margin-bottom: 0cm"><a
          moz-do-not-send="true"
          href="http://www.uniparthenope.it/index.php/5xmille"><font
            color="#0000ff"><font face="Arial, sans-serif"><u>http://www.uniparthenope.it/index.php/5xmille</u></font></font></a><font
          color="#000000"><font face="Arial, sans-serif"> </font></font></p>
      <p class="western" style="margin-bottom: 0cm"> </p>
      <p class="western" style="margin-bottom: 0cm"><a
          moz-do-not-send="true"
href="http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille"><font
            color="#0000ff"><font face="Arial, sans-serif"><u>http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille</u></font></font></a></p>
      <p class="western" style="margin-bottom: 0cm"> <font face="Arial,
          sans-serif"><br>
          Questa
          informativa è inserita in automatico dal sistema al fine
          esclusivo
          della realizzazione dei fini istituzionali dell'ente.</font></p>
      <p class="western" style="margin-bottom: 0cm"><br>
      </p>
      <!--</BODY>-->
      <!--</HTML>-->
      <br>
      <br>
      <style type="text/css">

	<!--

		@page { margin-left: 2cm; margin-right: 2cm; margin-top: 2.5cm; margin-bottom: 2cm }

		P { margin-bottom: 0.21cm; direction: ltr; color: #000000; widows: 2; orphans: 2 }

		P.western { font-family: "Times New Roman", serif; font-size: 8pt; so-language: it-IT }

		P.cjk { font-family: "Times New Roman", serif; font-size: 8pt }

		P.ctl { font-family: "Times New Roman", serif; font-size: 8pt; so-language: ar-SA }

		A:link { color: #0000ff }

	-->

	</style>
      <!--</HEAD></BODY>-->
      <p text="#000000" link="#0000ff" dir="LTR" lang="it-IT">
      </p>
      <p class="western" style="margin-bottom: 0cm"><font face="Arial,
          sans-serif">*******************************************************************************************************</font></p>
      <p class="western" style="margin-bottom: 0cm"><font face="Arial,
          sans-serif">IL
          MERITO DEGLI STUDENTI VIENE RICONOSCIUTO</font></p>
      <p class="western" style="margin-bottom: 0cm"> </p>
      <p class="western" style="margin-bottom: 0cm"><font
          color="#000000"><font face="Arial, sans-serif">Il
            5 per mille all'Università degli Studi di Napoli
            "Parthenope"incrementa le borse di studio agli studenti
            - codice fiscale </font></font><font color="#000000"><font
            face="Arial, sans-serif"><b>80018240632</b></font></font><font
          color="#000000"><font face="Arial, sans-serif">
          </font></font>
      </p>
      <p class="western" style="margin-bottom: 0cm"><a
          moz-do-not-send="true"
          href="http://www.uniparthenope.it/index.php/5xmille"><font
            color="#0000ff"><font face="Arial, sans-serif"><u>http://www.uniparthenope.it/index.php/5xmille</u></font></font></a><font
          color="#000000"><font face="Arial, sans-serif"> </font></font></p>
      <p class="western" style="margin-bottom: 0cm"> </p>
      <p class="western" style="margin-bottom: 0cm"><a
          moz-do-not-send="true"
href="http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille"><font
            color="#0000ff"><font face="Arial, sans-serif"><u>http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille</u></font></font></a></p>
      <p class="western" style="margin-bottom: 0cm"> <font face="Arial,
          sans-serif"><br>
          Questa
          informativa è inserita in automatico dal sistema al fine
          esclusivo
          della realizzazione dei fini istituzionali dell'ente.</font></p>
      <p class="western" style="margin-bottom: 0cm"><br>
      </p>
      <!--</BODY>-->
      <!--</HTML>-->
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------040708030002030600080801--

From scott@kitterman.com  Mon Apr 15 13:02:59 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9529621F8F7A for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 13:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwGFJ2eXdS-j for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 13:02:58 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC8E21F8F76 for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 13:02:57 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 4AD9F20E40FE; Mon, 15 Apr 2013 16:02:57 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366056177; bh=DXY3geJf7W4yDJVVv82P76A6S8hSLbHpZWzZC3J3BxU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gk/asFl4UljQ2RL37l5tSVmVcwxNt6bDU7si7BWS6rZUEd1eZTyowIR8P9laJV0eW oShmo/FbWHXKqA5xcHTLYXVD7S9zx1eE1DidLjYc7OLvdeUJIZLsOkrcEke4xJvXwU IIig7M//tYFwrrLe5ganJDUh07BFxelBqvE9EHG8=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 2242B20E4076;  Mon, 15 Apr 2013 16:02:56 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Mon, 15 Apr 2013 16:02:56 -0400
Message-ID: <3121454.RJqk1xG6s9@scott-latitude-e6320>
User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; )
In-Reply-To: <5169438B.3010400@dcrocker.net>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <0d7d06e2-a54b-45ec-a33f-dbfa2b20bc0e@email.android.com> <5169438B.3010400@dcrocker.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2013 20:02:59 -0000

On Saturday, April 13, 2013 04:37:47 AM Dave Crocker wrote:
> Scott,
> 
> On 4/12/2013 11:00 PM, Scott Kitterman wrote:
> >> So Scott, what changes to the DMARC base spec are you seeking and
> >> why and who wants them and how do we know this?
> > 
> > In part, I don't. DMARC has been developed in private by a relatively
> > small group of people. I think it's not unreasonable to consider the
> > spec might be improved by broader review.
> 
>     It's entirely reasonable.  That's why the draft charter provides for
> such future effort: "However, if resolving any of the issues listed in
> the areas of focus below does require changes to the base specification,
> or if the specification needs to be revised to correct technical errors
> deemed essential for proper use, the group will recharter accordingly."
> 
>     The specification has been public for considerably more than a year,
> including a press release and a public discussion list, with adoption
> covering roughly 60% of the world's mailboxes.  That's not a small base
> of experience.  So there's been plenty of opportunity for community
> review and input, including requests for changes.  And yet, there is so
> far no such list of requests.

Not true.  There was a long thread, almost a year ago on the interaction of 
DMARC policy with policy aspects of other domain authentication technologies 
(SPF and DKIM/ADSP) that starts here:

http://www.dmarc.org/pipermail/dmarc-discuss/2012-July/001104.html

While some of the issues addressed in that thread have been addressed (the 
most critical one that DMARC policy of none should not alter processing for 
SPF or DKIM/ADSP in particular), I don't think the issue is fully resolved.  
Here's the current, relevant snippet from the draft submitted to the IETF:

>    DMARC-compliant Mail Receivers SHOULD disregard any mail directive
>    discovered as part of an authentication mechanism (e.g., ADSP, SPF)
>    where a DMARC policy is also discovered that specifies a policy other
>    than "none". {R7} To enable Domain Owners to receive DMARC feedback
>    without impacting existing mail processing, discovered policies of
>    "p=none" SHOULD NOT modify existing mail disposition processing.
>    Note that some Mail Receivers may reject email based upon SPF policy
>    mechanisms before email enters DMARC-specific processing.

I think the initial SHOULD represents a layering violation that is technically 
inappropriate from a design perspective, will substantially complicate 
implementation, and is not needed.  Details to follow.

>  >  Things that were written
> > 
> > by people who already "know" what the spec is supposed to mean are
> > often less clear to those outside the group. Until a broader group
> > actually reviews it, there's no way to know.
> 
>    You are correct, of course.  However the range of implementers now
> goes considerably beyond the original group, and yet there is so far no
> concrete list of interesting changes being requested.

The current implementers don't need the IETF spec.  The RFC should be oriented 
towards future implementers (Ironic note: I was on the other side if this 
exact question about 4408bis in SPFbis and lost - I am now convinced that this 
view is the right one).  

Absent a working group to actually do some independent review, there's no way 
of knowing what would come up.  The currently proposed charter, by design, 
minimizes the incentive to actually do so.  The only IETF review of the base 
spec would be a, by design, very limited scope review by the IESG.

> > That's not a matter of changing the protocol, but improving the text.
> 
>     Well, that's what we originally submitted for chartering, but at
> least one AD didn't like it.

Right, but the direction that the AD didn't like it was that the previous 
proposal constrained the working group too much.  Removing the work entirely 
from the working group seems like doing the opposite of addressing the 
concern.  It seemed to me that there were a number of reasonable suggestions, 
including coming from the AD in question, that did a nice job of balancing the 
concerns of existing implementers without handcuffing the proposed working 
group.  I think the current draft charter is an over-reaction in the wrong 
directions.

> > The one thing I think does need to be changed is the policy override
> > approach.  Changing SPF policy based on DMARC is a layering violation
> > at the very least.
> 
>     Sorry, but I'm missing the reference.  Please point to the section
> of text you don't like and describe the kind of change you are seeking.
> 
> (FWIW, on reflection, I'm not a fan of the term policy override, since
> it implies that the recipient has somehow been bound to conformance to
> the sender's policies...)

See the text quoted above for the specific reference.  

In order to implement DMARC it's necessary for the component of a mail system 
that does SPF processing to have access to the 5322.From extracted from the 
body of the message (because of the SHOULD to skip SPF related policy 
decisions for domains that have a DMARC policy != none and 5322.From provides 
the domain needed to determine if a DMARC policy is relevant for the message).

Requiring data from the message body to do operations on the envelope is not a 
good idea.

> > While reading the envelope (HELO/5321.Mail From) I
> > have to change processing based information in the body (5322.From).
> > Many SPF implementations don't have access to the body making it
> > difficult to implement correctly.
> 
>     If they are doing DMARC, they do have access.

Eventually, but not necessarily when the SPF processing is done.

I have currently deployed DMARC verification for testing (I'm adding the 
relevant authentication results header fields, but not enforcing reject 
policies).  I'll use my current setup as a specific example of why following 
"SHOULD disregard any mail directive discovered as part of an authentication 
mechanism (e.g., ADSP, SPF)" adds substantial complexity to implementation and 
deployment due to the layering violation inherent in that requirement.

For this deployment, the MTA is Postfix, the SPF verifier is pypolicyd-spf, the 
DKIM verifier is opendkim, and the DMARC verifier is opendmarc.

Postfix has an "Access Policy Delegation" interface 
(http://www.postfix.org/SMTPD_POLICY_README.html) that is used by pypolicyd-spf 
to do SPF verification during the SMTP session.  SPF 5321.Mail From and HELO 
results are determined and, if the mail is not rejected/deferred, an 
appropriate Received-SPF or Authentication-Results header field is added.  This 
is done after mail from or rcpt to.

After the body of the message is received (after data), it is passed via the 
milter interface to opendkim for DKIM verification (which adds an 
Authentication-Results header field for DKIM) and then to opendmarc which also 
adds an appropriate Authentication-Results header field (since I'm not 
enforcing DMARC policy yet, it always just adds the field).

SPF checking via the "Access Policy Delegation" interface is the standard 
approach for Postfix deployments (in fact, the interface was specifically added 
to support SPF checking, although it is used for many other things as well).  
As is appropriate for an MTA, the policy interface operates on the envelope of 
the message and does not provide access to the body of the message, which 
typically has not been transmitted when it is invoked.

The requirement to have access to the body of the message to do SPF checking 
in a DMARC environment is an architectural mess.

> > Not only is the current design wrong, it's nor needed to solve the
> > problem DMARC was meant to solve.
> 
>     Sounds like a protocol change.  That's rather more than merely
> improving the text.

Yes, but not one that would require implementations to be changed to fix, which 
I think is the important point.  I believe that SHOULD/MAY in "SHOULD 
disregard any mail directive discovered as part of an authentication mechanism 
(e.g., ADSP, SPF)" is probably sufficient, but since they can already do that, I 
don't know what the point of even having it in the spec is.

> > Similarly, due to this override, a DMARC policy of none can't be used
> > just to collect data as it will change mail processing as well.
> 
>     I don't understand.

This particular aspect of the issue has been corrected in the current draft, 
sorry for dragging it in.

> > The current design is wrong. The specific issues I'm concerned with
> > now can be resolved without forcing existing implementers to change
> > anything, so no investment is at risk.
> 
>     The idea that one can change a design, without having to change
> code, is new to me.  Please explain.

If you change a SHOULD requirement to a MAY requirement then nothing forces 
existing implementations to change.  The can, but they don't have to.

> > Fundamentally, rubber stamping the work of a private design team is
> > not the IETF way.
> 
>     What part of the work in the latest draft charter would produce
> rubber stamping?
> 
>     But since you are being pedagogical about how the IETF does things,
> please note that working group charters are supposed to specify the
> nature of the work to be done.  Working groups that start without a
> sense of what problem they are trying to solve to tend to have poor
> outcomes.  If you can specify the nature of the technical, work to be
> done, sufficiently to garner support for it, then it's certainly worth
> considering.

I'm aware of one technical issue that I believe to be significant that needs to 
be addressed and wasn't addressed by the private design group.  Unless it's in 
scope for a working group to review the input of that work to the IETF, there 
is not likely to be the same level of review.

Additionally, I think it is very odd to submit the base spec as an independent 
submission and then form a working group to extend it.  As I understand it, 
part of a working group effort is to get consensus around technical efforts.  
I'm not sure how you get consensus to extend something for which there is no 
IETF consensus.  

I might even think that perhaps that the bit in RFC 4846 about the IESG review 
where it mentioned independent submissions shouldn't be an end run around the 
working group process might be relevant.  It also seems to me that if the 
DMARC base spec seeks to modify processing for IETF RFCs, it's pretty much 
inherently a conflict of the type that IESG review of independent submissions 
is supposed to identify.

I think that if DMARC were entirely laid on top of SPF/DKIM/ADSP and there was 
not also a parallel proposal for an IETF working group to extend DMARC, then 
independent submission would not be inappropriate, but I'd still prefer to see 
DMARC standardized through the IETF.  I think that there will be a better 
product as a result (and I also think it's not at all difficult to craft charter 
language that will adequately address the equities of early adopters).

Scott K

From ted.ietf@gmail.com  Mon Apr 15 15:34:43 2013
Return-Path: <ted.ietf@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FF421E8043 for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 15:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.902
X-Spam-Level: 
X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[AWL=-0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_PAIN=2.3, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uTW9cjjnqbL for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 15:34:42 -0700 (PDT)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id AB20721E8040 for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 15:34:41 -0700 (PDT)
Received: by mail-ie0-f177.google.com with SMTP id 9so5978808iec.8 for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 15:34:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=y5QkcaWwCAmrQsk/XjVZrRVuAPHgieArsI/zb5f1TzU=; b=vpVcLObb8LrfZMjVF4nrxwZijDvjqNJwEvC4bksS8E6heZyKGL8i4JNHpeC4qhN/ca vEcIKw6K0L2p8JLpxz+8zz76EhJIKXyiBS9P8G/tyvTrkwAL5iOWuYNGngqarqK8aXCL NP6rcnCINtSpC+oyxerwYwQyQuPE61bU9BV/lYBiMGqJoIzvzEoy6GXo/90np9c9rvcv OgTV2eckla86495naSJ3Gd5oEChzwN+ThfCrOJx4UpWcLHDYTb7qqrGQihHZ5m9R+09J S9ZfTpEaG5/SV7kLRxKDqCke5x9+EpsPnQ9pRa+FSdQT3nWE3VuRhXZTeQEzktCqQECF yIsQ==
MIME-Version: 1.0
X-Received: by 10.50.170.102 with SMTP id al6mr6504528igc.20.1366065277729; Mon, 15 Apr 2013 15:34:37 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Mon, 15 Apr 2013 15:34:37 -0700 (PDT)
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEE@nkgeml506-mbx.china.huawei.com>
References: <CA+9kkMDEc1mX77eRYMXPBKnH9X+jOXGVD7pVFArkwSwNsF+wMA@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEE@nkgeml506-mbx.china.huawei.com>
Date: Mon, 15 Apr 2013 15:34:37 -0700
Message-ID: <CA+9kkMA7+_m5s-iEo24H9jrGt9Osn32iMBDSSEyL7FNyeDT5+g@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: "Liubing (Leo)" <leo.liubing@huawei.com>
Content-Type: multipart/alternative; boundary=e89a8f3bb0679e81dd04da6ddbed
Cc: "draft-ietf-6renum-gap-analysis.all@tools.ietf.org" <draft-ietf-6renum-gap-analysis.all@tools.ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2013 22:34:43 -0000

--e89a8f3bb0679e81dd04da6ddbed
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 11, 2013 at 8:00 PM, Liubing (Leo) <leo.liubing@huawei.com>wrot=
e:

>  Hi, Ted****
>
> ** **
>
> Many thanks for your review, it would be helpful to refine the draft.
> Please see replies inline.****
>
> ** **
>
> Best regards,****
>
> Bing****
>
> ** **
>
> *From:* Ted Hardie [mailto:ted.ietf@gmail.com]
> *Sent:* Friday, April 12, 2013 6:51 AM
> *To:* apps-discuss@ietf.org;
> draft-ietf-6renum-gap-analysis.all@tools.ietf.org
> *Subject:* Review of draft-ietf-6renum-gap-analysis-05****
>
> ** **
>
> I have been selected as the Applications Area Directorate reviewer
> for this draft (for background on appsdir, please see
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
> ).
>
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
>
> Document:draft-ietf-6renum-gap-analysis-05****
>
> Title: IPv6 Site Renumbering Gap Analysis
> Reviewer: Ted Hardie
> Review Date: April 11, 2013****
>
>
> Summary: This document is basically ready to be published as an
> Informational draft.  There are minor issues which the authors may wish t=
o
> address before final publication.
>
>
> Minor Issues:
>
> The document currently motivates its work with the following statement:**=
*
> *
>
>    If IPv6 site renumbering continues to be considered****
>
>    difficult, network managers will turn to Provider Independent (PI)****
>
>    addressing for IPv6 to attempt to minimize the need for future****
>
>    renumbering. However, widespread use of PI may create very serious****
>
>    BGP4 scaling problems. It is thus desirable to develop tools and****
>
>    practices that may make renumbering a simpler process to reduce****
>
>    demand for IPv6 PI space.
>
> A citation for this would be useful.  It might also be worth it to
> highlight other potential risks--for example, the widespread deployment
> of ULAs, which do not admit of aggregation, or the deployment of
>
> ****
>
> [Bing] Ok, thanks for the suggestion. We=92ll include the reference on BG=
P4 scaling issue, as well as considering whether there are other potential =
risks.****
>
> But for the specific ULA problem, it might be different. ULA is intended =
to be used within a certain scope, normally, within an enterprise network. =
So it won=92t bother the global routing scalability.****
>
> In fact we suggest to use ULA along with PA in enterprise to avoid some r=
enumbering or to make internal communication more stable when switching glo=
bal prefixes. It was documented in the recently published 6renum RFC6879 (P=
lease see section 4.1)****
>
> **
>
>
My feelings on ULAs are both largely unprintable and pretty well-known.
I'll spare you the re-iteration.


> **
>
> address translation technologies which make referral more difficult.  I n=
ote
> that RFC 5887 included some of these issues.  If the intent is to referen=
ce
> those from RFC 5887, I note that  the document currently says that it
>
> ****
>
> ** **
>
> "starts from existing work in [RFC5887],****
>
> [I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]." but the references
> to these documents are informative.  If the document is meant to be an ex=
tension,
> rather than a replacement, such that these documents must be read to get =
the full****
>
> picture, than a normative reference may be better.****
>
> ** **
>
> [Bing] These documents are important input for the gap analysis draft. Th=
ey indeed have not a few crossed content, but our intention on the gap draf=
t was different, so it is neither extension nor replacement.****
>
> RFC5887&draft-thinkabout are more comprehensive analysis/guidelines on IP=
v6 renumbering issue; RFC4192 emphasizes on a =93make before break=94 prefi=
x switching operation.****
>
> This gap draft  addresses the IPv6 enterprise scenarios described in RFC6=
879, and focusing on identifying what is missing to make renum more automat=
ic and less error-prone.****
>
>
>
> Well, we don't have a category for "informative, but really important
context", so I leave it to you to pick.  I would personally likely choose
normative to highlight their importance.



> For the session survivability section, a reference to RFC 6724 may be use=
ful, so
> that those adding new global addresses understand how the application API=
 to determine
>
> ****
>
> which address is used with interact with the addition of new addresses (i=
f there
> is a specific draft or other treatment of that topic, that would be even =
better,
> but I am not personally aware of one).****
>
> ** **
>
> [Bing] OK. Address selection is indeed important. ****
>
>
>
> In section 6, the document currently says:
>
> ****
>
>
>    When nodes in a site have been renumbered, then all the entries in****
>
>    the site which contain the nodes' addresses must be updated. The****
>
>    entries mainly include DNS records and filters in various entities****
>
>    such as ACLs in firewalls/gateways.
>
> This appears to imply that these updates must take place after the renumb=
ering
> event, but this is variable.  ACLs and filters may well be updated in adv=
ance;
> DNS may be updated concurrently or post facto.  A rewording to highlight =
that ****
>
> this is variable by record type may be useful.****
>
> ** **
>
> [Bing] Ok, thanks.
>
>
> Section 9.2, in the bullet entitled "DNS data structure optimization"
> The discusses a DNS feature proposed but declared historic. I don't think=
 it****
>
> identifies the related renumbering gap in a way that is useful for a naiv=
e
> reader.  If it cannot be reworded to focus on the gap, I suggest it be
> removed.
>
> ****
>
> [Bing] When we wrote the draft, we considered if the IPv6 DNS record coul=
d be structured as separating prefix and suffix, that would be very helpful=
 for renumbering. Because in IPv6, most of the time we just change the pref=
ixes rather than the whole addresses.****
>
> We found A6 has the similar feature, but it has been moved to historic. H=
owever,  the idea of separating prefix and suffix is still considered valua=
ble, but there might not  be able to develop a new DNS record in a short ti=
me, so we name the idea as =93DNS data structure optimization=94 and put it=
 into =93gaps considered unsolvable=94.****
>
> We can add some minor texts to explain the intention.****
>
>
> Thanks.  I do think it should be clear that you are not attempting to
resurrect the A6 vs. AAAA argument.


> In section 9.4, the document says:
>
>       For application layer, as [RFC5887] said, in general, we can****
>
>       assert that any implementation is at risk from renumbering if it***=
*
>
>       does not check that an address is valid each time it opens a new***=
*
>
>       communications session.
>
> This might be reworded to  include or focus on session resumption, rather=
 than
> new communications sessions.  From an applications perspective, the lapto=
p
> "sleep" function seems to be one of the bigger risks of this.
>
> ****
>
> [Bing] Ok, thanks.****
>
>
> Nit:
>
> For me personally, section 6.1 seemed needlessly pessimistic. ****
>
> [Bing] It is sad but true. And we are curious about how much operational =
issues there to prevent DDNS widely deployed in real networks.****
>
> If possible, we might consider to make a dedicated draft to talk about th=
is issue in the future. ****
>
> ** **
>
>   Thanks for your quick reply,

Ted Hardie

--e89a8f3bb0679e81dd04da6ddbed
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 11, 2013 at 8:00 PM, Liubing (Leo) <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:leo.liubing@huawei.com" target=3D"_blank">leo.liubing@huawei.co=
m</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">






<div link=3D"blue" vlink=3D"purple" lang=3D"ZH-CN">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">Hi, Ted<u>=
</u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US"><u></u>=A0=
<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">Many thank=
s for your review, it would be helpful to refine the draft. Please see repl=
ies inline.<u></u><u></u></span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US"><u></u>=A0=
<u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">Best regar=
ds,<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">Bing<u></u=
><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:10.5pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US"><u></u>=A0=
<u></u></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt;font-family:&quot=
;Tahoma&quot;,&quot;sans-serif&quot;" lang=3D"EN-US">From:</span></b><span =
style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&q=
uot;" lang=3D"EN-US"> Ted Hardie [mailto:<a href=3D"mailto:ted.ietf@gmail.c=
om" target=3D"_blank">ted.ietf@gmail.com</a>]
<br>
<b>Sent:</b> Friday, April 12, 2013 6:51 AM<br>
<b>To:</b> <a href=3D"mailto:apps-discuss@ietf.org" target=3D"_blank">apps-=
discuss@ietf.org</a>; <a href=3D"mailto:draft-ietf-6renum-gap-analysis.all@=
tools.ietf.org" target=3D"_blank">draft-ietf-6renum-gap-analysis.all@tools.=
ietf.org</a><br>

<b>Subject:</b> Review of draft-ietf-6renum-gap-analysis-05<u></u><u></u></=
span></p>
</div>
</div><div class=3D"im">
<p class=3D"MsoNormal"><span lang=3D"EN-US"><u></u>=A0<u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">I have been selected as the App=
lications Area Directorate reviewer<br>
for this draft (for background on appsdir, please see<br>
<a href=3D"http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDi=
rectorate" target=3D"_blank">http://trac.tools.ietf.org/area/app/trac/wiki/=
ApplicationsAreaDirectorate</a><br>
).<br>
<br>
Please resolve these comments along with any other Last Call comments<br>
you may receive. Please wait for direction from your document shepherd<br>
or AD before posting a new version of the draft.<br>
<br>
Document:draft-ietf-6renum-gap-analysis-05<u></u><u></u></span></p>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Title: IPv6 Site Renumbering Ga=
p Analysis
<br>
Reviewer: Ted Hardie<br>
Review Date: April 11, 2013<u></u><u></u></span></p>
</div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US">=
<br>
Summary: This document is basically ready to be published as an Information=
al draft.=A0 There are minor issues which the authors may wish to address b=
efore final publication.<br>
<br>
<br>
Minor Issues:<br>
<br>
The document currently motivates its work with the following statement:<u><=
/u><u></u></span></p>
<pre><span lang=3D"EN-US">=A0=A0 If IPv6 site renumbering continues to be c=
onsidered<u></u><u></u></span></pre>
<pre><span lang=3D"EN-US">=A0=A0 difficult, network managers will turn to P=
rovider Independent (PI)<u></u><u></u></span></pre>
<pre><span lang=3D"EN-US">=A0=A0 addressing for IPv6 to attempt to minimize=
 the need for future<u></u><u></u></span></pre>
<pre><span lang=3D"EN-US">=A0=A0 renumbering. However, widespread use of PI=
 may create very serious<u></u><u></u></span></pre>
<pre><span lang=3D"EN-US">=A0=A0 BGP4 scaling problems. It is thus desirabl=
e to develop tools and<u></u><u></u></span></pre>
<pre><span lang=3D"EN-US">=A0=A0 practices that may make renumbering a simp=
ler process to reduce<u></u><u></u></span></pre>
<pre><span lang=3D"EN-US">=A0=A0 demand for IPv6 PI space.<br><br>A citatio=
n for this would be useful.=A0 It might also be worth it to <br>highlight o=
ther potential risks--for example, the widespread deployment<br>of ULAs, wh=
ich do not admit of aggregation, or the deployment of <br>
<br><u></u><u></u></span></pre>
</div><pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">[Bing] Ok, thanks for =
the suggestion. We=92ll include the reference on BGP4 scaling issue, as wel=
l as considering whether there are other potential risks.<u></u><u></u></sp=
an></pre>

<pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d" lang=3D"EN-US">But for the specific ULA pro=
blem, it might be different. ULA is intended to be used within a certain sc=
ope, normally, within an enterprise network. So it won=92t bother the globa=
l routing scalability.<u></u><u></u></span></pre>

<pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d" lang=3D"EN-US">In fact we suggest to use UL=
A along with PA in enterprise to avoid some renumbering or to make internal=
 communication more stable when switching global prefixes. It was documente=
d in the recently published 6renum RFC6879 (Please see section 4.1)<u></u><=
u></u></span></pre>
<div class=3D"im">
<pre><span lang=3D"EN-US"><u></u>=A0</span></pre></div></div></div></div></=
blockquote><div><br>My feelings on ULAs are both largely unprintable and pr=
etty well-known.=A0 I&#39;ll spare you the re-iteration.<br>=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex">
<div link=3D"blue" vlink=3D"purple" lang=3D"ZH-CN"><div><div style=3D"borde=
r:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div class=
=3D"im"><pre><span lang=3D"EN-US"><u></u></span></pre>
<pre><span lang=3D"EN-US">address translation technologies which make refer=
ral more difficult.=A0 I note<br>that RFC 5887 included some of these issue=
s.=A0 If the intent is to reference<br>those from RFC 5887, I note that=A0 =
the document currently says that it <br>
<br><u></u><u></u></span></pre>
<pre><span lang=3D"EN-US"><u></u>=A0<u></u></span></pre>
<pre><span lang=3D"EN-US">&quot;starts from existing work in [RFC5887],<u><=
/u><u></u></span></pre>
<pre><span lang=3D"EN-US">[I-D.chown-v6ops-renumber-thinkabout] and [RFC419=
2].&quot; but the references<br>to these documents are informative.=A0 If t=
he document is meant to be an extension,<br>rather than a replacement, such=
 that these documents must be read to get the full<u></u><u></u></span></pr=
e>

<pre><span lang=3D"EN-US">picture, than a normative reference may be better=
.<span style=3D"color:#1f497d"><u></u><u></u></span></span></pre>
<pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d" lang=3D"EN-US"><u></u>=A0<u></u></span></pr=
e>
</div><pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">[Bing] These documents=
 are important input for the gap analysis draft. They indeed have not a few=
 crossed content, but our intention on the gap draft was different, so it i=
s neither extension nor replacement.<u></u><u></u></span></pre>

<pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d" lang=3D"EN-US">RFC5887&amp;draft-thinkabout=
 are more comprehensive analysis/guidelines on IPv6 renumbering issue; RFC4=
192 emphasizes on a =93make before break=94 prefix switching operation.<u><=
/u><u></u></span></pre>

<pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d" lang=3D"EN-US">This gap draft =A0addresses =
the IPv6 enterprise scenarios described in RFC6879, and focusing on identif=
ying what is missing to make renum more automatic and less error-prone.<u><=
/u><u></u></span></pre>
<div class=3D"im">
<pre><span lang=3D"EN-US"><br><br></span></pre></div></div></div></div></bl=
ockquote><div>Well, we don&#39;t have a category for &quot;informative, but=
 really important context&quot;, so I leave it to you to pick.=A0 I would p=
ersonally likely choose normative to highlight their importance.<br>
<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div link=3D"blue" vlink=3D"pur=
ple" lang=3D"ZH-CN"><div><div style=3D"border:none;border-left:solid blue 1=
.5pt;padding:0cm 0cm 0cm 4.0pt">
<div class=3D"im"><pre><span lang=3D"EN-US">For the session survivability s=
ection, a reference to RFC 6724 may be useful, so <br>that those adding new=
 global addresses understand how the application API to determine<br><br><u=
></u><u></u></span></pre>

<pre><span lang=3D"EN-US">which address is used with interact with the addi=
tion of new addresses (if there<br>is a specific draft or other treatment o=
f that topic, that would be even better,<br>but I am not personally aware o=
f one).<span style=3D"color:#1f497d"><u></u><u></u></span></span></pre>

<pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d" lang=3D"EN-US"><u></u>=A0<u></u></span></pr=
e>
</div><pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">[Bing] OK. Address sel=
ection is indeed important. <u></u><u></u></span></pre><div class=3D"im">
<pre><span lang=3D"EN-US"><br><br>In section 6, the document currently says=
:<br><br><u></u><u></u></span></pre>
<pre><span lang=3D"EN-US"><br>=A0=A0 When nodes in a site have been renumbe=
red, then all the entries in<u></u><u></u></span></pre>
<pre><span lang=3D"EN-US">=A0=A0 the site which contain the nodes&#39; addr=
esses must be updated. The<u></u><u></u></span></pre>
<pre><span lang=3D"EN-US">=A0=A0 entries mainly include DNS records and fil=
ters in various entities<u></u><u></u></span></pre>
<pre><span lang=3D"EN-US">=A0=A0 such as ACLs in firewalls/gateways.<br><br=
>This appears to imply that these updates must take place after the renumbe=
ring<br>event, but this is variable.=A0 ACLs and filters may well be update=
d in advance;<br>
DNS may be updated concurrently or post facto.=A0 A rewording to highlight =
that <u></u><u></u></span></pre>
<pre><span lang=3D"EN-US">this is variable by record type may be useful.<sp=
an style=3D"color:#1f497d"><u></u><u></u></span></span></pre>
<pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d" lang=3D"EN-US"><u></u>=A0<u></u></span></pr=
e>
</div><pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">[Bing] Ok, thanks.</sp=
an><div class=3D"im"><span lang=3D"EN-US"><br><br>Section 9.2, in the bulle=
t entitled &quot;DNS data structure optimization&quot;<br>
The discusses a DNS feature proposed but declared historic. I don&#39;t thi=
nk it<u></u><u></u></span></div></pre><div class=3D"im">
<pre><span lang=3D"EN-US">identifies the related renumbering gap in a way t=
hat is useful for a naive <br>reader.=A0 If it cannot be reworded to focus =
on the gap, I suggest it be<br>removed.<br><br><span style=3D"color:#1f497d=
"><u></u><u></u></span></span></pre>

</div><pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">[Bing] When we wrote t=
he draft, we considered if the IPv6 DNS record could be structured as separ=
ating prefix and suffix, that would be very helpful for renumbering. Becaus=
e in IPv6, most of the time we just change the prefixes rather than the who=
le addresses.<u></u><u></u></span></pre>

<pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d" lang=3D"EN-US">We found A6 has the similar =
feature, but it has been moved to historic. However, =A0the idea of separat=
ing prefix and suffix is still considered valuable, but there might not =A0=
be able to develop a new DNS record in a short time, so we name the idea as=
 =93DNS data structure optimization=94 and put it into =93gaps considered u=
nsolvable=94.<u></u><u></u></span></pre>

<pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d" lang=3D"EN-US">We can add some minor texts =
to explain the intention.<u></u><u></u></span></pre><div class=3D"im">
<pre><span lang=3D"EN-US"><br></span></pre></div></div></div></div></blockq=
uote><div>Thanks.=A0 I do think it should be clear that you are not attempt=
ing to resurrect the A6 vs. AAAA argument.<br>=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
<div link=3D"blue" vlink=3D"purple" lang=3D"ZH-CN"><div><div style=3D"borde=
r:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt"><div class=
=3D"im"><pre><span lang=3D"EN-US">In section 9.4, the document says:<br><br=
>=A0=A0=A0=A0=A0 For application layer, as [RFC5887] said, in general, we c=
an<u></u><u></u></span></pre>

<pre><span lang=3D"EN-US">=A0=A0=A0=A0=A0 assert that any implementation is=
 at risk from renumbering if it<u></u><u></u></span></pre>
<pre><span lang=3D"EN-US">=A0=A0=A0=A0=A0 does not check that an address is=
 valid each time it opens a new<u></u><u></u></span></pre>
<pre><span lang=3D"EN-US">=A0=A0=A0=A0=A0 communications session.<br><br>Th=
is might be reworded to=A0 include or focus on session resumption, rather t=
han <br>new communications sessions.=A0 From an applications perspective, t=
he laptop<br>
&quot;sleep&quot; function seems to be one of the bigger risks of this.=A0 =
<br><br><u></u><u></u></span></pre>
</div><pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">[Bing] Ok, thanks.<u><=
/u><u></u></span></pre><div class=3D"im">
<pre><span lang=3D"EN-US"><br>Nit:<br><br>For me personally, section 6.1 se=
emed needlessly pessimistic. <u></u><u></u></span></pre>
</div><pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,=
&quot;sans-serif&quot;;color:#1f497d" lang=3D"EN-US">[Bing] It is sad but t=
rue. And we are curious about how much operational issues there to prevent =
DDNS widely deployed in real networks.<u></u><u></u></span></pre>

<pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d" lang=3D"EN-US">If possible, we might consid=
er to make a dedicated draft to talk about this issue in the future. <u></u=
><u></u></span></pre>

<pre><span style=3D"font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;=
sans-serif&quot;;color:#1f497d" lang=3D"EN-US"><u></u>=A0<u></u></span></pr=
e>
</div>
</div>
</div>

</blockquote></div>Thanks for your quick reply,<br><br>Ted Hardie<br>

--e89a8f3bb0679e81dd04da6ddbed--

From fgaliegue@gmail.com  Mon Apr 15 15:59:49 2013
Return-Path: <fgaliegue@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F226521F925A for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 15:59:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLvyhRdFU1a8 for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 15:59:48 -0700 (PDT)
Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id D581A21F8E9A for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 15:59:47 -0700 (PDT)
Received: by mail-ea0-f169.google.com with SMTP id n15so2505259ead.28 for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 15:59:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TuQ7RP4HjXoxvjR3tUnVH0DuzWZMU1PZuqfmEck//qQ=; b=TxQvchMXouZ6yNFkqyfHoVBBERdStmld8nLCxP52jpNKRUCP47865rQKYfJBCb65lF I0Fv0zS4GJ701rJxNPJJ3oqp68RsPLi4ZOmP+hhTh8nXNrmqH+mGyQQGem1Lp4NrVy26 4F1x0fGJ7BIDysL0347StKehP0ivDCBl5rG0DE+NaY9+idrsama/clrBXzu7jid5YD2o M2nNlsW2GDbh0ldJVODWpEgP7FVCOpEhwGc8mP7hWeCJzhIqjBxTi04nvXQJTy+eDkFz QZ/9FCDEWNTdb3jcM3fdQF8swEODu2vo71IQ+rlVdzn6bnM6NaSnteeB2JNn56cfRzR3 TwDQ==
MIME-Version: 1.0
X-Received: by 10.14.89.69 with SMTP id b45mr66983939eef.10.1366066786853; Mon, 15 Apr 2013 15:59:46 -0700 (PDT)
Received: by 10.14.213.4 with HTTP; Mon, 15 Apr 2013 15:59:46 -0700 (PDT)
In-Reply-To: <CALcybBB11EENT6dbxy0Wgb2cVUmuhxbnKOuVirvjd++R6f=5QA@mail.gmail.com>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com> <CALcybBCeyJce+m7GB8ak_Wmwfk6+Z=bcaDKs489H0v4vLOgahw@mail.gmail.com> <CABP7RbfLQ5wCTNEJ4ufEs76YoVBePP8JYLQkjgUHJQ-o3=pUeg@mail.gmail.com> <CAL0qLwYsVt63VAtg0yqG=KDO7e1DvmE-8ywXM8CBqrt8mxDZOA@mail.gmail.com> <CABP7RbfDOS4pdnx5Z4arwLw8demRfKrT4bE+Jb4uzvcdgzKRfw@mail.gmail.com> <CAL0qLwaoaYbnHiYCuxC050Yn=G3C5skG5m9mkb_SvO0Yhkf8hw@mail.gmail.com> <CALcybBB11EENT6dbxy0Wgb2cVUmuhxbnKOuVirvjd++R6f=5QA@mail.gmail.com>
Date: Tue, 16 Apr 2013 00:59:46 +0200
Message-ID: <CALcybBDc4Zad-Yc-+4Wgats78EtR-0iR-TmSGOu++zODjnH9mA@mail.gmail.com>
From: Francis Galiegue <fgaliegue@gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, Joe Gregorio <joe@bitworking.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2013 22:59:49 -0000

On Thu, Apr 11, 2013 at 3:53 PM, Francis Galiegue <fgaliegue@gmail.com> wrote:
[...]
>>
>> Everywhere else in the document refers to a list as (value[, value[, ...]]).
>> So it seems to me "()" is the empty list, while "[]" is not.
>>
>
> Then what would it be? There is no empty list defined at all in the
> RFC examples.
>
> I agree that there should be an errata, defining expansion behaviour
> for all of these corner cases. Right now, only the tests at
> https://github.com/uri-templates/uritemplate-test make any mention of
> it and there seems to be a disagreement on how these should be
> handled.
>

Ping?

My opinion is that this is of fundamental importance if RFC 6570 has
to have any impact over already existing uses of "poorer" forms of
this RFC. Right now, the RFC is unambiguous, and more worryingly, I
see no way out of it, since there is no clear, definite answer to my
initial question.

I have a pretty complete RFC 6570 implementation, but these corner
cases are what prevent me from arguing that "yes, it obeys the RFC",
especially since some advanced tests out there seem to disagree with
my, and others', interpretation of this RFC.

Please share your thoughts,
--
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com

From fgaliegue@gmail.com  Mon Apr 15 16:05:47 2013
Return-Path: <fgaliegue@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D7421F939C for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 16:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQEsFfMPbviU for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 16:05:46 -0700 (PDT)
Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6F321F9380 for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 16:05:46 -0700 (PDT)
Received: by mail-ea0-f175.google.com with SMTP id r16so2391662ead.6 for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 16:05:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=M5vLOTGBwfQyuOjtXlI33MzFf5JjI+WV3IG57H/Pv68=; b=qxX2oBTAPhNzRYUhiNnxXMvm89hTHs8ZJ5eKWZVV8V9m3r9+uV83/uybmZ9tPctfvB S7NPl2nGpZV12oaWyMlLOV+uvi15iWW3cUraWEtO8ffCyot8ylLJh1OfR2v5yxyWDy5T vq4y+BwCLtIXufU8DEOxGUga1cSM74p52UujbeTSMd/qqheoNEBCnCsWKkhnNgPcsogN P4fxkO4A74Vvj/SyQ3jzteDBHmzsrVLA+HUMdP7Xh0N3bd6IAQBquWOFkyKW9EnTMrwi XVwQEvgF4hlNcX6H8HhTntXoTIa3VL9awWYQO/J/HqMxUNFX9tzn52sYZtom9fX0rz/o 6LVA==
MIME-Version: 1.0
X-Received: by 10.14.89.69 with SMTP id b45mr67027256eef.10.1366067145442; Mon, 15 Apr 2013 16:05:45 -0700 (PDT)
Received: by 10.14.213.4 with HTTP; Mon, 15 Apr 2013 16:05:45 -0700 (PDT)
In-Reply-To: <CALcybBDc4Zad-Yc-+4Wgats78EtR-0iR-TmSGOu++zODjnH9mA@mail.gmail.com>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com> <CALcybBCeyJce+m7GB8ak_Wmwfk6+Z=bcaDKs489H0v4vLOgahw@mail.gmail.com> <CABP7RbfLQ5wCTNEJ4ufEs76YoVBePP8JYLQkjgUHJQ-o3=pUeg@mail.gmail.com> <CAL0qLwYsVt63VAtg0yqG=KDO7e1DvmE-8ywXM8CBqrt8mxDZOA@mail.gmail.com> <CABP7RbfDOS4pdnx5Z4arwLw8demRfKrT4bE+Jb4uzvcdgzKRfw@mail.gmail.com> <CAL0qLwaoaYbnHiYCuxC050Yn=G3C5skG5m9mkb_SvO0Yhkf8hw@mail.gmail.com> <CALcybBB11EENT6dbxy0Wgb2cVUmuhxbnKOuVirvjd++R6f=5QA@mail.gmail.com> <CALcybBDc4Zad-Yc-+4Wgats78EtR-0iR-TmSGOu++zODjnH9mA@mail.gmail.com>
Date: Tue, 16 Apr 2013 01:05:45 +0200
Message-ID: <CALcybBAF12qGskfwyHyhtkdriBkAe9hECRb-J_EkJdf7RsjkHg@mail.gmail.com>
From: Francis Galiegue <fgaliegue@gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, Joe Gregorio <joe@bitworking.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2013 23:05:47 -0000

On Tue, Apr 16, 2013 at 12:59 AM, Francis Galiegue <fgaliegue@gmail.com> wrote:

[...]
> Right now, the RFC is unambiguous

I meant "ambiguous" here, sorry for the confusion.

--
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com

From dret@berkeley.edu  Mon Apr 15 16:08:52 2013
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB1221E8039 for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 16:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcKItbQrEA-F for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 16:08:51 -0700 (PDT)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 914BF21E8037 for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 16:08:51 -0700 (PDT)
Received: from 99-38-249-227.lightspeed.sntcca.sbcglobal.net ([99.38.249.227] helo=dretpro.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1URsW1-0004qJ-9H; Mon, 15 Apr 2013 16:08:51 -0700
Message-ID: <516C887F.7020007@berkeley.edu>
Date: Mon, 15 Apr 2013 16:08:47 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Francis Galiegue <fgaliegue@gmail.com>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com> <CALcybBCeyJce+m7GB8ak_Wmwfk6+Z=bcaDKs489H0v4vLOgahw@mail.gmail.com> <CABP7RbfLQ5wCTNEJ4ufEs76YoVBePP8JYLQkjgUHJQ-o3=pUeg@mail.gmail.com> <CAL0qLwYsVt63VAtg0yqG=KDO7e1DvmE-8ywXM8CBqrt8mxDZOA@mail.gmail.com> <CABP7RbfDOS4pdnx5Z4arwLw8demRfKrT4bE+Jb4uzvcdgzKRfw@mail.gmail.com> <CAL0qLwaoaYbnHiYCuxC050Yn=G3C5skG5m9mkb_SvO0Yhkf8hw@mail.gmail.com> <CALcybBB11EENT6dbxy0Wgb2cVUmuhxbnKOuVirvjd++R6f=5QA@mail.gmail.com> <CALcybBDc4Zad-Yc-+4Wgats78EtR-0iR-TmSGOu++zODjnH9mA@mail.gmail.com>
In-Reply-To: <CALcybBDc4Zad-Yc-+4Wgats78EtR-0iR-TmSGOu++zODjnH9mA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Joe Gregorio <joe@bitworking.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2013 23:08:52 -0000

hello.

On 2013-04-15 15:59 , Francis Galiegue wrote:
> I have a pretty complete RFC 6570 implementation, but these corner
> cases are what prevent me from arguing that "yes, it obeys the RFC",
> especially since some advanced tests out there seem to disagree with
> my, and others', interpretation of this RFC.

i just want to add my support for francis' question. i am not as far 
down the line implementing the spec, but i see myself asking the same 
question once i am. and i am still interested how james (snell) solved 
this riddle when adding support for the test case (where the test case 
behavior is hard to explain from the spec language).

http://code.google.com/p/uri-templates/wiki/Implementations lists a 
number of implementations, and it would be interesting to know what they 
have been doing, and how they handle the test case in question.

thanks and cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

From superuser@gmail.com  Mon Apr 15 16:10:30 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A220121E803D for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 16:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TXAIGzvk5Fg for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 16:10:30 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A787321E8037 for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 16:10:29 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id c10so2086958wiw.14 for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 16:10:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=n/k6C1L0D2IDtZFg9MkUlWpYvlPbnCLKVmmzavoVVBc=; b=tzMF+KDIGe1jRkQQimN3CbK0uCXIJm8/sZWHWwR3BiLt6NqU4PcpQ19Orr5VZIQs3m ct0Y04yXlkj9HpmGcGGYmxhZH+jq7X+Yaer64ndrR8kOE4jS8vAhNKrIAv1OMmA4oSv6 HkcLor17KTlRoOPFaf7/toR1lzW7EYaSRCmbEt7o8dat6x4GIFm+zzBOFHPp2ZYzv7LU vJTKeV+hYyKKDp87jqvtnq9bX0hqZVi7lI4e6LWloXZTDrrH04+wIaTsFWC1DrOBJtCp f9jKwaPe0OjCdCe3/KCVcuwEETTf53/IBAIvwF9My/YUJPWS7bgip7y8py9ZBVya1F2O 91iQ==
MIME-Version: 1.0
X-Received: by 10.180.97.233 with SMTP id ed9mr14986326wib.32.1366067428652; Mon, 15 Apr 2013 16:10:28 -0700 (PDT)
Received: by 10.180.36.176 with HTTP; Mon, 15 Apr 2013 16:10:28 -0700 (PDT)
In-Reply-To: <516C887F.7020007@berkeley.edu>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com> <CALcybBCeyJce+m7GB8ak_Wmwfk6+Z=bcaDKs489H0v4vLOgahw@mail.gmail.com> <CABP7RbfLQ5wCTNEJ4ufEs76YoVBePP8JYLQkjgUHJQ-o3=pUeg@mail.gmail.com> <CAL0qLwYsVt63VAtg0yqG=KDO7e1DvmE-8ywXM8CBqrt8mxDZOA@mail.gmail.com> <CABP7RbfDOS4pdnx5Z4arwLw8demRfKrT4bE+Jb4uzvcdgzKRfw@mail.gmail.com> <CAL0qLwaoaYbnHiYCuxC050Yn=G3C5skG5m9mkb_SvO0Yhkf8hw@mail.gmail.com> <CALcybBB11EENT6dbxy0Wgb2cVUmuhxbnKOuVirvjd++R6f=5QA@mail.gmail.com> <CALcybBDc4Zad-Yc-+4Wgats78EtR-0iR-TmSGOu++zODjnH9mA@mail.gmail.com> <516C887F.7020007@berkeley.edu>
Date: Mon, 15 Apr 2013 16:10:28 -0700
Message-ID: <CAL0qLwbMYmHMoPHuUs4aLE4GYWFJog6pp-bGr1vN6TpA__rLeg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Erik Wilde <dret@berkeley.edu>
Content-Type: multipart/alternative; boundary=f46d044306aad3001304da6e5b02
Cc: Joe Gregorio <joe@bitworking.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2013 23:10:30 -0000

--f46d044306aad3001304da6e5b02
Content-Type: text/plain; charset=ISO-8859-1

I emailed the authors several days ago.  None replied.

Unless one of our ADs thinks it's a bad idea (and hopefully they're
watching), I would post an erratum.

-MSK


On Mon, Apr 15, 2013 at 4:08 PM, Erik Wilde <dret@berkeley.edu> wrote:

> hello.
>
>
> On 2013-04-15 15:59 , Francis Galiegue wrote:
>
>> I have a pretty complete RFC 6570 implementation, but these corner
>> cases are what prevent me from arguing that "yes, it obeys the RFC",
>> especially since some advanced tests out there seem to disagree with
>> my, and others', interpretation of this RFC.
>>
>
> i just want to add my support for francis' question. i am not as far down
> the line implementing the spec, but i see myself asking the same question
> once i am. and i am still interested how james (snell) solved this riddle
> when adding support for the test case (where the test case behavior is hard
> to explain from the spec language).
>
> http://code.google.com/p/uri-**templates/wiki/Implementations<http://code.google.com/p/uri-templates/wiki/Implementations>lists a number of implementations, and it would be interesting to know what
> they have been doing, and how they handle the test case in question.
>
> thanks and cheers,
>
>
> dret.
>
> --
> erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
>            | UC Berkeley  -  School of Information (ISchool) |
>            | http://dret.net/netdret http://twitter.com/dret |
>

--f46d044306aad3001304da6e5b02
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>I emailed the authors several days ago.=A0 None =
replied.<br><br></div>Unless one of our ADs thinks it&#39;s a bad idea (and=
 hopefully they&#39;re watching), I would post an erratum.<br><br></div>-MS=
K<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon,=
 Apr 15, 2013 at 4:08 PM, Erik Wilde <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:dret@berkeley.edu" target=3D"_blank">dret@berkeley.edu</a>&gt;</span> wro=
te:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">hello.<div class=3D"im"><br>
<br>
On 2013-04-15 15:59 , Francis Galiegue wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I have a pretty complete RFC 6570 implementation, but these corner<br>
cases are what prevent me from arguing that &quot;yes, it obeys the RFC&quo=
t;,<br>
especially since some advanced tests out there seem to disagree with<br>
my, and others&#39;, interpretation of this RFC.<br>
</blockquote>
<br></div>
i just want to add my support for francis&#39; question. i am not as far do=
wn the line implementing the spec, but i see myself asking the same questio=
n once i am. and i am still interested how james (snell) solved this riddle=
 when adding support for the test case (where the test case behavior is har=
d to explain from the spec language).<br>

<br>
<a href=3D"http://code.google.com/p/uri-templates/wiki/Implementations" tar=
get=3D"_blank">http://code.google.com/p/uri-<u></u>templates/wiki/Implement=
ations</a> lists a number of implementations, and it would be interesting t=
o know what they have been doing, and how they handle the test case in ques=
tion.<br>

<br>
thanks and cheers,<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
dret.<br>
<br>
-- <br>
erik wilde | mailto:<a href=3D"mailto:dret@berkeley.edu" target=3D"_blank">=
dret@berkeley.edu</a> =A0- =A0tel:<a href=3D"tel:%2B1-510-2061079" value=3D=
"+15102061079" target=3D"_blank">+1-510-2061079</a> |<br>
=A0 =A0 =A0 =A0 =A0 =A0| UC Berkeley =A0- =A0School of Information (ISchool=
) |<br>
=A0 =A0 =A0 =A0 =A0 =A0| <a href=3D"http://dret.net/netdret" target=3D"_bla=
nk">http://dret.net/netdret</a> <a href=3D"http://twitter.com/dret" target=
=3D"_blank">http://twitter.com/dret</a> |<br>
</div></div></blockquote></div><br></div>

--f46d044306aad3001304da6e5b02--

From dhc@dcrocker.net  Mon Apr 15 17:15:36 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F67B21F93EE for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 17:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jJUmnmxEolB for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 17:15:35 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4C321F93D4 for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 17:15:35 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3G0FY6k017376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Apr 2013 17:15:35 -0700
Message-ID: <516C9824.6040503@dcrocker.net>
Date: Mon, 15 Apr 2013 17:15:32 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Scott Kitterman <scott@kitterman.com>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <0d7d06e2-a54b-45ec-a33f-dbfa2b20bc0e@email.android.com> <5169438B.3010400@dcrocker.net> <3121454.RJqk1xG6s9@scott-latitude-e6320>
In-Reply-To: <3121454.RJqk1xG6s9@scott-latitude-e6320>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 15 Apr 2013 17:15:35 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 00:15:36 -0000

Scott,

At the risk of this going too far afield from a chartering discussion --
it might be worth moving this thread to dmarc@ietf.org:


On 4/15/2013 1:02 PM, Scott Kitterman wrote:
> On Saturday, April 13, 2013 04:37:47 AM Dave Crocker wrote:
>> The specification has been public for considerably more than a
>> year, including a press release and a public discussion list, with
>> adoption covering roughly 60% of the world's mailboxes.  That's not
>> a small base of experience.  So there's been plenty of opportunity
>> for community review and input, including requests for changes.
>> And yet, there is so far no such list of requests.
>
> Not true.  There was a long thread, almost a year ago on the
> interaction of DMARC policy with policy aspects of other domain
> authentication technologies (SPF and DKIM/ADSP) that starts here:
>
> http://www.dmarc.org/pipermail/dmarc-discuss/2012-July/001104.html

I apologize for being unclear.  I didn't mean that no individuals had
any requests.  I meant that there has been no demonstration of community
support -- a rough consensus kind of support -- for changes.

To my own reading, the thread you cite nicely demonstrates this:
community interest, community discussion, but no community support for 
change.  If you feel otherwise, please document it.


> While some of the issues addressed in that thread have been addressed
> (the most critical one that DMARC policy of none should not alter
> processing for SPF or DKIM/ADSP in particular), I don't think the
> issue is fully resolved.

I don't see that thread as having created items to be resolved.  Again,
feel free to document otherwise.

And given considerably more of one year for that public discussion, we
haven't identified any items that might show community support for
modifying the base specification.


> Here's the current, relevant snippet from the draft submitted to the
> IETF:
>
>> DMARC-compliant Mail Receivers SHOULD disregard any mail directive
>> discovered as part of an authentication mechanism (e.g., ADSP,
>> SPF) where a DMARC policy is also discovered that specifies a
>> policy other than "none". {R7} To enable Domain Owners to receive
>> DMARC feedback without impacting existing mail processing,
>> discovered policies of "p=none" SHOULD NOT modify existing mail
>> disposition processing. Note that some Mail Receivers may reject
>> email based upon SPF policy mechanisms before email enters
>> DMARC-specific processing.
>
> I think the initial SHOULD represents a layering violation that is
> technically inappropriate from a design perspective, will
> substantially complicate implementation, and is not needed.  Details
> to follow.

FWIW, with respect to policy mechanisms, I think this is less a matter 
of "layering" than of "replacement". DMARC is asserting authority over 
the topic of policy, to the extent is has /overlap/ (rather than 
layering) with SPF or ADSP.


>
>>> Things that were written
>>>
>>> by people who already "know" what the spec is supposed to mean
>>> are often less clear to those outside the group. Until a broader
>>> group actually reviews it, there's no way to know.
>>
>> You are correct, of course.  However the range of implementers now
>> goes considerably beyond the original group, and yet there is so
>> far no concrete list of interesting changes being requested.
>
> The current implementers don't need the IETF spec.  The RFC should be
> oriented towards future implementers

Perhaps you missed the part about there now being a number of
implementers who were not part of the writing team?  Again, one would
have expected significant critical feedback from them, about problems
with the writing, over the last 1+ year.  (But then, the latest draft
does contain revisions...)

In any event, with an area director strongly against a "just improve 
the writing" work item, and no list of changes to be made to the base, 
there doesn't seem to be much to discuss about it.


> Absent a working group to actually do some independent review,
> there's no way of knowing what would come up.

You seem to think that it's ok to start a working group when there is no 
known work other than "review the document and figure out what might 
need doing".  By contrast, my long-standing model of a working group 
charter is that there is a clear set of problems to solve and/or 
enhancements to add and that this is clear /before/ chartering.


>> Well, that's what we originally submitted for chartering, but at
>> least one AD didn't like it.
>
> Right, but the direction that the AD didn't like it was that the
> previous proposal constrained the working group too much.

He didn't seem to want any meaningful constraint.  While he, you, or 
whoever might feel that's fine, the folks currently holding the spec 
need more assurance of stability for the specification than that, given 
how recent the investment in it has been.


>  It seemed to me that there were
> a number of reasonable suggestions, including coming from the AD in
> question, that did a nice job of balancing the concerns of existing
> implementers without handcuffing the proposed working group.

That doesn't match my own reading of the thread(s).


>>> The one thing I think does need to be changed is the policy
>>> override approach.  Changing SPF policy based on DMARC is a
>>> layering violation at the very least.
...
> See the text quoted above for the specific reference.

You mean:
 >    DMARC-compliant Mail Receivers SHOULD disregard any mail directive
...
 >    mechanisms before email enters DMARC-specific processing.
?

Where is there a demonstration of community support for changing this?


> In order to implement DMARC it's necessary for the component of a
> mail system that does SPF processing to have access to the 5322.From
> extracted from the body of the message (because of the SHOULD to skip
> SPF related policy decisions for domains that have a DMARC policy !=
> none and 5322.From provides the domain needed to determine if a DMARC
> policy is relevant for the message).
>
> Requiring data from the message body to do operations on the envelope
> is not a good idea.

Strictly speaking, it's not doing an operation /on/ the envelope, but in 
any event, the linkage to SPF's use of envelope information and DMARC's 
use of rfc5322.From information is rather basic to DMARC.

 From what I can tell, the change that you are concerned with, is 
DMARC's overriding SPF's /disposition/ mechanism, rather than its 
authentication mechanism.

In any event who supports the change besides you?  You've voiced it for 
awhile, so there ought to be some indication of support by now.


> The requirement to have access to the body of the message to do SPF
> checking in a DMARC environment is an architectural mess.

I guess I'm not seeing it as doing SPF checking.


>>> Not only is the current design wrong, it's nor needed to solve
>>> the problem DMARC was meant to solve.
>>
>> Sounds like a protocol change.  That's rather more than merely
>> improving the text.
>
> Yes, but not one that would require implementations to be changed to

...
>> The idea that one can change a design, without having to change
>> code, is new to me.  Please explain.
>
> If you change a SHOULD requirement to a MAY requirement then nothing
> forces existing implementations to change.

You mean beyond reducing the likelihood that it will get implemented; 
are you asserting that this won't affect interoperability?

But again, this is frankly moot, absent a community desire to change the 
base specification.


>>> Fundamentally, rubber stamping the work of a private design team
>>> is not the IETF way.
>>
>> What part of the work in the latest draft charter would produce
>> rubber stamping?
>>
>> But since you are being pedagogical about how the IETF does
>> things, please note that working group charters are supposed to
>> specify the nature of the work to be done.  Working groups that
>> start without a sense of what problem they are trying to solve to
>> tend to have poor outcomes.  If you can specify the nature of the
>> technical, work to be done, sufficiently to garner support for it,
>> then it's certainly worth considering.
>
> I'm aware of one technical issue that I believe to be significant
> that needs to be addressed and wasn't addressed by the private design
> group.  Unless it's in scope for a working group to review the input
> of that work to the IETF, there is not likely to be the same level of
> review.

Scott, yes it's clear that you believe the issue is significant.  What's 
missing is an indication that the rest of the community wants a change.



> Additionally, I think it is very odd to submit the base spec as an
> independent submission and then form a working group to extend it.

Not "typical", no.  So?


> As I understand it, part of a working group effort is to get
> consensus around technical efforts. I'm not sure how you get
> consensus to extend something for which there is no IETF consensus.

The question will be consensus around the extensions.  Isn't modularity 
nice?


> I might even think that perhaps that the bit in RFC 4846 about the
> IESG review where it mentioned independent submissions shouldn't be
> an end run around the working group process might be relevant.

OK.  Please point to an existing IETF effort that this might be 
considered an end-run around.  That's what that reference was/is 
intended to mean.  And who else shares this view?


>  It
> also seems to me that if the DMARC base spec seeks to modify
> processing for IETF RFCs,

It doesn't.


> I think that if DMARC were entirely laid on top of SPF/DKIM/ADSP and
> there was not also a parallel proposal for an IETF working group to
> extend DMARC, then independent submission would not be inappropriate,

So, you think that ARP was inappropriate to have as an IETF effort, 
given that essentially all of the media specifications over which it 
operates -- that is, which it "extends" -- are outside of the IETF?


d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From stephen.farrell@cs.tcd.ie  Mon Apr 15 17:35:08 2013
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8ED821F93E2 for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 17:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wA8kcpJgZNZZ for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 17:35:07 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 946C821F93E1 for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 17:35:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 954A3BE62; Tue, 16 Apr 2013 01:34:45 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkK1rj24SSzt; Tue, 16 Apr 2013 01:34:44 +0100 (IST)
Received: from [10.87.48.4] (unknown [86.44.70.2]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AFF20BE61; Tue, 16 Apr 2013 01:34:44 +0100 (IST)
Message-ID: <516C9CA4.5020700@cs.tcd.ie>
Date: Tue, 16 Apr 2013 01:34:44 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: dcrocker@bbiw.net
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <0d7d06e2-a54b-45ec-a33f-dbfa2b20bc0e@email.android.com> <5169438B.3010400@dcrocker.net> <3121454.RJqk1xG6s9@scott-latitude-e6320> <516C9824.6040503@dcrocker.net>
In-Reply-To: <516C9824.6040503@dcrocker.net>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Scott Kitterman <scott@kitterman.com>, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 00:35:09 -0000

On 04/16/2013 01:15 AM, Dave Crocker wrote:
> 
>>> Well, that's what we originally submitted for chartering, but at
>>> least one AD didn't like it.
>>
>> Right, but the direction that the AD didn't like it was that the
>> previous proposal constrained the working group too much.
> 
> He didn't seem to want any meaningful constraint.  While he, you, or
> whoever might feel that's fine, the folks currently holding the spec
> need more assurance of stability for the specification than that, given
> how recent the investment in it has been.

I guess I'm the "he" above.

I've no idea what Dave means by "meaningful constraint." (That may
be just down to misinterpretations though. Hard to tell.)

I continue to argue for the same handling that the IETF used
for DKIM and XMPP. That seems to have worked well twice. I'm
quite surprised the DMARC group seem so much more concerned
about stupid changes than either the XMPP or DKIM folk, esp
since there seems to be quite an overlap between the DKIM
and DMARC groups. (Please do correct me if I'm wrong about
that overlap; its quite possible.)

I had a real problem with the previous proposed charter. I'm
not sure yet if I do with this one (while still preferring
doing what we did with DKIM/XMPP.) In order to know if I've a
problem with this one, I think I need to read the "base" spec
(which I've yet to do) because the current proposal seems to
be to have the ISE and chartering processes run in parallel
(which I find very odd). I suspect its very likely I will have
a problem with that, unless the ISE RFC has issued before the
IETF WG chartering process starts. (Only then can IETF folk
decide if they're ok with a new WG, since only then will the
ISE RFC text be final; but there is a chance that the "base"
spec is so good that its obvious, so I will read it first.)

And just in case that previous paragraph was confusing:

I continue to argue for the same handling that the IETF used
for DKIM and XMPP:-)

S.




From scott@kitterman.com  Mon Apr 15 18:35:53 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0892421F9458 for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 18:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXupo-2pxuFp for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 18:35:51 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCC321F9434 for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 18:35:51 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 8379720E40FE; Mon, 15 Apr 2013 21:35:50 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366076150; bh=0Np0PP0b9TwVEZeOP3u1yeAiHFte+bgmYGNkkJPOghU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eYHt2uirpn8zP9Ll92VBEo+4S8VF5ARA9llQ+tASW/YzeS2HL8cLStQXjfrXFedh2 caUM1/5C72+Yck1ucXujh453GQOiLuDI5EiuXbar0LsN7HPOumJoadGYEw2p+vPTAS X5tfDtS4IuddezhotoyWbUdeJnTFwK1n0dQGJalg=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 63F1520E4076;  Mon, 15 Apr 2013 21:35:49 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Mon, 15 Apr 2013 21:35:37 -0400
Message-ID: <8990489.xAljaCmULD@scott-latitude-e6320>
User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; )
In-Reply-To: <516C9824.6040503@dcrocker.net>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <3121454.RJqk1xG6s9@scott-latitude-e6320> <516C9824.6040503@dcrocker.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 01:35:53 -0000

On Monday, April 15, 2013 05:15:32 PM Dave Crocker wrote:
> Scott,
> 
> At the risk of this going too far afield from a chartering discussion --
> it might be worth moving this thread to dmarc@ietf.org:
> 
> On 4/15/2013 1:02 PM, Scott Kitterman wrote:
> > On Saturday, April 13, 2013 04:37:47 AM Dave Crocker wrote:
> >> The specification has been public for considerably more than a
> >> year, including a press release and a public discussion list, with
> >> adoption covering roughly 60% of the world's mailboxes.  That's not
> >> a small base of experience.  So there's been plenty of opportunity
> >> for community review and input, including requests for changes.
> >> And yet, there is so far no such list of requests.
> > 
> > Not true.  There was a long thread, almost a year ago on the
> > interaction of DMARC policy with policy aspects of other domain
> > authentication technologies (SPF and DKIM/ADSP) that starts here:
> > 
> > http://www.dmarc.org/pipermail/dmarc-discuss/2012-July/001104.html
> 
> I apologize for being unclear.  I didn't mean that no individuals had
> any requests.  I meant that there has been no demonstration of community
> support -- a rough consensus kind of support -- for changes.
> 
> To my own reading, the thread you cite nicely demonstrates this:
> community interest, community discussion, but no community support for
> change.  If you feel otherwise, please document it.
> 
> > While some of the issues addressed in that thread have been addressed
> > (the most critical one that DMARC policy of none should not alter
> > processing for SPF or DKIM/ADSP in particular), I don't think the
> > issue is fully resolved.
> 
> I don't see that thread as having created items to be resolved.  Again,
> feel free to document otherwise.
> 
> And given considerably more of one year for that public discussion, we
> haven't identified any items that might show community support for
> modifying the base specification.
> 
> > Here's the current, relevant snippet from the draft submitted to the
> > 
> > IETF:
> >> DMARC-compliant Mail Receivers SHOULD disregard any mail directive
> >> discovered as part of an authentication mechanism (e.g., ADSP,
> >> SPF) where a DMARC policy is also discovered that specifies a
> >> policy other than "none". {R7} To enable Domain Owners to receive
> >> DMARC feedback without impacting existing mail processing,
> >> discovered policies of "p=none" SHOULD NOT modify existing mail
> >> disposition processing. Note that some Mail Receivers may reject
> >> email based upon SPF policy mechanisms before email enters
> >> DMARC-specific processing.
> > 
> > I think the initial SHOULD represents a layering violation that is
> > technically inappropriate from a design perspective, will
> > substantially complicate implementation, and is not needed.  Details
> > to follow.
> 
> FWIW, with respect to policy mechanisms, I think this is less a matter
> of "layering" than of "replacement". DMARC is asserting authority over
> the topic of policy, to the extent is has /overlap/ (rather than
> layering) with SPF or ADSP.
> 
> >>> Things that were written
> >>> 
> >>> by people who already "know" what the spec is supposed to mean
> >>> are often less clear to those outside the group. Until a broader
> >>> group actually reviews it, there's no way to know.
> >> 
> >> You are correct, of course.  However the range of implementers now
> >> goes considerably beyond the original group, and yet there is so
> >> far no concrete list of interesting changes being requested.
> > 
> > The current implementers don't need the IETF spec.  The RFC should be
> > oriented towards future implementers
> 
> Perhaps you missed the part about there now being a number of
> implementers who were not part of the writing team?  Again, one would
> have expected significant critical feedback from them, about problems
> with the writing, over the last 1+ year.  (But then, the latest draft
> does contain revisions...)
> 
> In any event, with an area director strongly against a "just improve
> the writing" work item, and no list of changes to be made to the base,
> there doesn't seem to be much to discuss about it.
> 
> > Absent a working group to actually do some independent review,
> > there's no way of knowing what would come up.
> 
> You seem to think that it's ok to start a working group when there is no
> known work other than "review the document and figure out what might
> need doing".  By contrast, my long-standing model of a working group
> charter is that there is a clear set of problems to solve and/or
> enhancements to add and that this is clear /before/ chartering.
> 
> >> Well, that's what we originally submitted for chartering, but at
> >> least one AD didn't like it.
> > 
> > Right, but the direction that the AD didn't like it was that the
> > previous proposal constrained the working group too much.
> 
> He didn't seem to want any meaningful constraint.  While he, you, or
> whoever might feel that's fine, the folks currently holding the spec
> need more assurance of stability for the specification than that, given
> how recent the investment in it has been.
> 
> >  It seemed to me that there were
> > 
> > a number of reasonable suggestions, including coming from the AD in
> > question, that did a nice job of balancing the concerns of existing
> > implementers without handcuffing the proposed working group.
> 
> That doesn't match my own reading of the thread(s).
> 
> >>> The one thing I think does need to be changed is the policy
> >>> override approach.  Changing SPF policy based on DMARC is a
> >>> layering violation at the very least.
> 
> ...
> 
> > See the text quoted above for the specific reference.
> 
> You mean:
>  >    DMARC-compliant Mail Receivers SHOULD disregard any mail directive
> 
> ...
> 
>  >    mechanisms before email enters DMARC-specific processing.
> 
> ?
> 
> Where is there a demonstration of community support for changing this?
> 
> > In order to implement DMARC it's necessary for the component of a
> > mail system that does SPF processing to have access to the 5322.From
> > extracted from the body of the message (because of the SHOULD to skip
> > SPF related policy decisions for domains that have a DMARC policy !=
> > none and 5322.From provides the domain needed to determine if a DMARC
> > policy is relevant for the message).
> > 
> > Requiring data from the message body to do operations on the envelope
> > is not a good idea.
> 
> Strictly speaking, it's not doing an operation /on/ the envelope, but in
> any event, the linkage to SPF's use of envelope information and DMARC's
> use of rfc5322.From information is rather basic to DMARC.
> 
>  From what I can tell, the change that you are concerned with, is
> DMARC's overriding SPF's /disposition/ mechanism, rather than its
> authentication mechanism.
> 
> In any event who supports the change besides you?  You've voiced it for
> awhile, so there ought to be some indication of support by now.
> 
> > The requirement to have access to the body of the message to do SPF
> > checking in a DMARC environment is an architectural mess.
> 
> I guess I'm not seeing it as doing SPF checking.
> 
> >>> Not only is the current design wrong, it's nor needed to solve
> >>> the problem DMARC was meant to solve.
> >> 
> >> Sounds like a protocol change.  That's rather more than merely
> >> improving the text.
> > 
> > Yes, but not one that would require implementations to be changed to
> 
> ...
> 
> >> The idea that one can change a design, without having to change
> >> code, is new to me.  Please explain.
> > 
> > If you change a SHOULD requirement to a MAY requirement then nothing
> > forces existing implementations to change.
> 
> You mean beyond reducing the likelihood that it will get implemented;
> are you asserting that this won't affect interoperability?
> 
> But again, this is frankly moot, absent a community desire to change the
> base specification.
> 
> >>> Fundamentally, rubber stamping the work of a private design team
> >>> is not the IETF way.
> >> 
> >> What part of the work in the latest draft charter would produce
> >> rubber stamping?
> >> 
> >> But since you are being pedagogical about how the IETF does
> >> things, please note that working group charters are supposed to
> >> specify the nature of the work to be done.  Working groups that
> >> start without a sense of what problem they are trying to solve to
> >> tend to have poor outcomes.  If you can specify the nature of the
> >> technical, work to be done, sufficiently to garner support for it,
> >> then it's certainly worth considering.
> > 
> > I'm aware of one technical issue that I believe to be significant
> > that needs to be addressed and wasn't addressed by the private design
> > group.  Unless it's in scope for a working group to review the input
> > of that work to the IETF, there is not likely to be the same level of
> > review.
> 
> Scott, yes it's clear that you believe the issue is significant.  What's
> missing is an indication that the rest of the community wants a change.
> 
> > Additionally, I think it is very odd to submit the base spec as an
> > independent submission and then form a working group to extend it.
> 
> Not "typical", no.  So?
> 
> > As I understand it, part of a working group effort is to get
> > consensus around technical efforts. I'm not sure how you get
> > consensus to extend something for which there is no IETF consensus.
> 
> The question will be consensus around the extensions.  Isn't modularity
> nice?
> 
> > I might even think that perhaps that the bit in RFC 4846 about the
> > IESG review where it mentioned independent submissions shouldn't be
> > an end run around the working group process might be relevant.
> 
> OK.  Please point to an existing IETF effort that this might be
> considered an end-run around.  That's what that reference was/is
> intended to mean.  And who else shares this view?
> 
> >  It
> > 
> > also seems to me that if the DMARC base spec seeks to modify
> > processing for IETF RFCs,
> 
> It doesn't.
> 
> > I think that if DMARC were entirely laid on top of SPF/DKIM/ADSP and
> > there was not also a parallel proposal for an IETF working group to
> > extend DMARC, then independent submission would not be inappropriate,
> 
> So, you think that ARP was inappropriate to have as an IETF effort,
> given that essentially all of the media specifications over which it
> operates -- that is, which it "extends" -- are outside of the IETF?

I'll let Stephen speak for his own opinion on the chartering constraint issue.  
In my opinion, there's a reasonable way to write a charter that allows 
meaningful discussion and consideration of the current design, but that 
provides appropriate constraint on trivial changes.

As for the current issue I have with the design, I haven't particularly 
attempted to gather a constituency for it.  It was my impression from when we 
discussed it almost a year ago there would be an eventual IETF working group 
to work through this and any other issues people found.

I think that if a draft is submitted as a candidate working group work item 
and the sponsors don't like the result of the chartering discussion and that 
draft is suddenly an independent submission, that's pretty well, by definition, 
an end around the working group process.

2119 SHOULD words about how to change SPF and DKIM/ADSP processing are 
certainly modifying the intent of IETF RFCs.  Once again, it's pretty 
obviously the case and the only reason to avoid accepting it is to have a safe 
dodge of the ISE path to avoid an IETF working group and some need to get 
consensus outside of the private design group.

I keep hearing the IETF is about getting technology right and not about votes 
or who people work for.  The current design is wrong and in a way that it 
doesn't need to be wrong because all domains that don't want mail rejected on 
the basis of SPF or DKIM/ADSP need to do is publish policy records that say 
that.  DMARC trying to replace that existing functionality is utterly 
unnecessary.

Scott K

From dhc@dcrocker.net  Mon Apr 15 20:36:22 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7553121F910B for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 20:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBaIohJxxWfH for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 20:36:21 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id AC37C21F8F5B for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 20:36:21 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3G3aKWW020266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Apr 2013 20:36:21 -0700
Message-ID: <516CC734.6050303@dcrocker.net>
Date: Mon, 15 Apr 2013 20:36:20 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Scott Kitterman <scott@kitterman.com>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <3121454.RJqk1xG6s9@scott-latitude-e6320> <516C9824.6040503@dcrocker.net> <8990489.xAljaCmULD@scott-latitude-e6320>
In-Reply-To: <8990489.xAljaCmULD@scott-latitude-e6320>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 15 Apr 2013 20:36:21 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 03:36:22 -0000

On 4/15/2013 6:35 PM, Scott Kitterman wrote:
> I think that if a draft is submitted as a candidate working group work item
> and the sponsors don't like the result of the chartering discussion and that
> draft is suddenly an independent submission, that's pretty well, by definition,
> an end around the working group process.


That's the same as saying that when one starts a negotiation, one is 
obligated to make a contract.

The initial chartering process is a negotiation between those bringing 
the work into the IETF and the IETF community.  Either side is free to 
agree or disagree with whatever terms they wish.

And free to walk away when there is not a sufficient meeting of the 
minds doing the negotiating.

The IETF does not have a 'right' to the work that is brought to it.

The ISE mechanism is for stuff that is relevant to the community, but 
isn't going through IETF or IRTF processing.  As a body of documents, 
the RFC series is larger than the IETF.


Work that is brought to the IETF has different levels of completeness 
and maturity, and different timings for having achieved those levels.

When the IETF charters a group and includes existing material, the 
charter can cast the role of that material in very different ways:

      It can treat it as nor more than a set of ideas, to be used or 
ignored;

      It can treat it as a basic design, with all of the actual details 
still fluid;

      It can treat it as a rough draft, to be massively revised;

      It can treat it as a solid specification that merely needs review, 
refinement and maybe enhancement;

      It can treat it as a deployed technology that should try to 
protect its installed base, but will tolerate some disruption;

      It can treat it as a deployed technology that /must/ protect its 
installed base and must ensure that core interoperability is retained 
with that installed base.


No doubt there are some other variations I've missed, but I hope this is 
enough to make clear that the choice of language in a working group 
charter, to constrain or not constrain the working group can make an 
enormous difference.

Equally, those bringing technology to the IETF do so at different points 
in the maturity of their work.  Any of the above might make sense, 
depending upon that maturity, the extent of deployment, and the timing 
of the investment made by the installed base.

When technology is brand new, with at most some prototypes done as 
proofs of concept, then significant changes to the spec won't 
necessarily add much to the development cost.  On the other extreme, a 
mature, deployed market can be almost cavalier about the freedom of a 
working group charter, because a working group that gets silly can be 
ignored: that is, the installed base is sufficiently well-established 
and unified in what it will accept, so that it's leverage is clear.

However, immediately after the development investment is made -- and 
especially when there has been considerable initial deployment, but 
still room for quite a bit more -- the installed and potential base will 
not take kindly to disruptive standards work; in fact such work can 
seriously damage adoption.

DKIM had almost no deployed base.  Jabber had quite a bit of deployed 
and mature base.

DMARC has a very large, newly-deployed base that just made the 
investment.  Making any changes that render the base not fully 
interoperable will a) piss of the folk who just made the investment, and 
b) possibly sour the folk considering deployment.  It typically at least 
causes the potential adopters to delay, sometime for years.

The charter that was originally submitted was tuned to the reality of 
DMARC's maturity and deployment.  Since that caused so much heartache to 
a few folk, the new draft charter removes the base spec from the current 
equation.  When deployment settles down and initial investment costs 
have been recovered, it will make sense to review the status of the base 
specification.


d/

ps.  I'm merely speaking for myself, of course, and not on behalf of the 
DMARC consortium.
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From scott@kitterman.com  Mon Apr 15 20:58:23 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CB021F9516 for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 20:58:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfEoaKsMwPyX for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 20:58:22 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 12C1A21F94FF for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 20:58:21 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5D6E020E40FE; Mon, 15 Apr 2013 23:58:21 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366084701; bh=xYPZ4MEgIRSR9hkIMGXbG1q4moP4HVBXAJGZHbhKtaY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=g7sdjcLgOrYvqIYy4e53Y1+052N8z9mjDhr1NVIZjOJzV++gcNCQ3XY/3kxylSKTC BDz+0uZapo4HtcXAgs1/65tZG148yUKv6KdxPru1t4u1v1XwzUl1aWc5mt6uGPW75e /xL0rrKy/EsmsMYYP3Q/9RT+Xhot6wbzss8spyEM=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 3E95B20E4076;  Mon, 15 Apr 2013 23:58:20 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Mon, 15 Apr 2013 23:58:20 -0400
Message-ID: <15015065.dv5A4A6JuL@scott-latitude-e6320>
User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; )
In-Reply-To: <516CC734.6050303@dcrocker.net>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <8990489.xAljaCmULD@scott-latitude-e6320> <516CC734.6050303@dcrocker.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 03:58:23 -0000

On Monday, April 15, 2013 08:36:20 PM Dave Crocker wrote:
> On 4/15/2013 6:35 PM, Scott Kitterman wrote:
> > I think that if a draft is submitted as a candidate working group work
> > item
> > and the sponsors don't like the result of the chartering discussion and
> > that draft is suddenly an independent submission, that's pretty well, by
> > definition, an end around the working group process.
> 
> That's the same as saying that when one starts a negotiation, one is
> obligated to make a contract.
> 
> The initial chartering process is a negotiation between those bringing
> the work into the IETF and the IETF community.  Either side is free to
> agree or disagree with whatever terms they wish.
> 
> And free to walk away when there is not a sufficient meeting of the
> minds doing the negotiating.
> 
> The IETF does not have a 'right' to the work that is brought to it.
> 
> The ISE mechanism is for stuff that is relevant to the community, but
> isn't going through IETF or IRTF processing.  As a body of documents,
> the RFC series is larger than the IETF.
> 
> 
> Work that is brought to the IETF has different levels of completeness
> and maturity, and different timings for having achieved those levels.
> 
> When the IETF charters a group and includes existing material, the
> charter can cast the role of that material in very different ways:
> 
>       It can treat it as nor more than a set of ideas, to be used or
> ignored;
> 
>       It can treat it as a basic design, with all of the actual details
> still fluid;
> 
>       It can treat it as a rough draft, to be massively revised;
> 
>       It can treat it as a solid specification that merely needs review,
> refinement and maybe enhancement;
> 
>       It can treat it as a deployed technology that should try to
> protect its installed base, but will tolerate some disruption;
> 
>       It can treat it as a deployed technology that /must/ protect its
> installed base and must ensure that core interoperability is retained
> with that installed base.
> 
> 
> No doubt there are some other variations I've missed, but I hope this is
> enough to make clear that the choice of language in a working group
> charter, to constrain or not constrain the working group can make an
> enormous difference.
> 
> Equally, those bringing technology to the IETF do so at different points
> in the maturity of their work.  Any of the above might make sense,
> depending upon that maturity, the extent of deployment, and the timing
> of the investment made by the installed base.
> 
> When technology is brand new, with at most some prototypes done as
> proofs of concept, then significant changes to the spec won't
> necessarily add much to the development cost.  On the other extreme, a
> mature, deployed market can be almost cavalier about the freedom of a
> working group charter, because a working group that gets silly can be
> ignored: that is, the installed base is sufficiently well-established
> and unified in what it will accept, so that it's leverage is clear.
> 
> However, immediately after the development investment is made -- and
> especially when there has been considerable initial deployment, but
> still room for quite a bit more -- the installed and potential base will
> not take kindly to disruptive standards work; in fact such work can
> seriously damage adoption.
> 
> DKIM had almost no deployed base.  Jabber had quite a bit of deployed
> and mature base.
> 
> DMARC has a very large, newly-deployed base that just made the
> investment.  Making any changes that render the base not fully
> interoperable will a) piss of the folk who just made the investment, and
> b) possibly sour the folk considering deployment.  It typically at least
> causes the potential adopters to delay, sometime for years.
> 
> The charter that was originally submitted was tuned to the reality of
> DMARC's maturity and deployment.  Since that caused so much heartache to
> a few folk, the new draft charter removes the base spec from the current
> equation.  When deployment settles down and initial investment costs
> have been recovered, it will make sense to review the status of the base
> specification.
> 
> 
> d/
> 
> ps.  I'm merely speaking for myself, of course, and not on behalf of the
> DMARC consortium.

In this case it's more like announcing a lockout when the initial offer from 
management isn't accepted without modification by the union rather than 
determining a meeting of the minds cannot be achieved after good faith 
negotiations.

1.  How about this?
2.  Not quite, here are some alternatives we could discuss.
1.  I quit.

that's hardly a negotiation.

Your argument against a working group is that it will be hard to get people 
who have adopted DMARC already to implement interoperability improvements 
because they just implemented it.  Are you suggesting that it will be easier, 
later, when there is more deployment and the current pattern is better 
established?

Scott K

From jasnell@gmail.com  Mon Apr 15 21:49:07 2013
Return-Path: <jasnell@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0194721F94A4 for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 21:49:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.666
X-Spam-Level: 
X-Spam-Status: No, score=-6.666 tagged_above=-999 required=5 tests=[AWL=-3.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VANpIavAdSWZ for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 21:49:06 -0700 (PDT)
Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id E4F0C21F94DC for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 21:49:05 -0700 (PDT)
Received: by mail-oa0-f50.google.com with SMTP id n1so97207oag.23 for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 21:49:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=CygF7BSoL/iIf3sA8BqfbpRiVW7c8jo3ImIoBtG02YM=; b=jx0g671sR7WmsPjvSufKM0lZYj3pMLeNP4Ck6a7eBeqC9luh2zAPdBrsLdDCFTC3vr vSc0L9S/Oxko78KWJwjP9Sk8haIkHlw7N2GID0f2EIiR4p9mjUOGSd600rWHjs0P9/Js a12midhWuoMf8bqx4USDy/Zj8qIk1/0gAqJd7Gg2ZovqdNEzhQ1rwPf+eRQPJgSghuRT 1m1u7EbMJWz6256tQwuODc+mZH6EBnW2Et9VBzwHhPT0hbGji0YVi6o+GJ0rRfxoFyqx 6u2wBaaX4QN0grQgyrmI4NEPkX3NKZ5/nQkIYt9u0oYBn2Xt52+ABJoeWpWahbtAuzol FkAg==
X-Received: by 10.60.50.102 with SMTP id b6mr267394oeo.46.1366087745543; Mon, 15 Apr 2013 21:49:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.132.102 with HTTP; Mon, 15 Apr 2013 21:48:45 -0700 (PDT)
In-Reply-To: <516C887F.7020007@berkeley.edu>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CAL0qLwYR+HknkVH5Y_jusqBv3=QbALFe=5t3FhYArNxzQYDPpQ@mail.gmail.com> <CALcybBCeyJce+m7GB8ak_Wmwfk6+Z=bcaDKs489H0v4vLOgahw@mail.gmail.com> <CABP7RbfLQ5wCTNEJ4ufEs76YoVBePP8JYLQkjgUHJQ-o3=pUeg@mail.gmail.com> <CAL0qLwYsVt63VAtg0yqG=KDO7e1DvmE-8ywXM8CBqrt8mxDZOA@mail.gmail.com> <CABP7RbfDOS4pdnx5Z4arwLw8demRfKrT4bE+Jb4uzvcdgzKRfw@mail.gmail.com> <CAL0qLwaoaYbnHiYCuxC050Yn=G3C5skG5m9mkb_SvO0Yhkf8hw@mail.gmail.com> <CALcybBB11EENT6dbxy0Wgb2cVUmuhxbnKOuVirvjd++R6f=5QA@mail.gmail.com> <CALcybBDc4Zad-Yc-+4Wgats78EtR-0iR-TmSGOu++zODjnH9mA@mail.gmail.com> <516C887F.7020007@berkeley.edu>
From: James M Snell <jasnell@gmail.com>
Date: Mon, 15 Apr 2013 21:48:45 -0700
Message-ID: <CABP7RbeJj3T_UnEN6o1eBHv3_u5QN2q+Dk+Yd8rd_Y_Oz-ZMRQ@mail.gmail.com>
To: Erik Wilde <dret@berkeley.edu>
Content-Type: text/plain; charset=UTF-8
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, Joe Gregorio <joe@bitworking.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 04:49:07 -0000

My apologies, I've been tied up in a number of other tasks and forgot
to respond further on this thread. Posting errata for the spec is
likely a good idea. When I implemented this, whenever I came up
against something that was ambiguous, I simply referred to the
examples given in the spec for guidance. There is no *normative* text
in the draft that describes this issue but there is a non-normative
example that illustrates, what I suspect, is the author's intent.
That, obviously, cannot be verified without the authors speaking up
and responding to the inquiry.

On Mon, Apr 15, 2013 at 4:08 PM, Erik Wilde <dret@berkeley.edu> wrote:
> hello.
>
>
> On 2013-04-15 15:59 , Francis Galiegue wrote:
>>
>> I have a pretty complete RFC 6570 implementation, but these corner
>> cases are what prevent me from arguing that "yes, it obeys the RFC",
>> especially since some advanced tests out there seem to disagree with
>> my, and others', interpretation of this RFC.
>
>
> i just want to add my support for francis' question. i am not as far down
> the line implementing the spec, but i see myself asking the same question
> once i am. and i am still interested how james (snell) solved this riddle
> when adding support for the test case (where the test case behavior is hard
> to explain from the spec language).
>
> http://code.google.com/p/uri-templates/wiki/Implementations lists a number
> of implementations, and it would be interesting to know what they have been
> doing, and how they handle the test case in question.
>
> thanks and cheers,
>
>
> dret.
>
> --
> erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
>            | UC Berkeley  -  School of Information (ISchool) |
>            | http://dret.net/netdret http://twitter.com/dret |
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From brian.e.carpenter@gmail.com  Mon Apr 15 23:45:58 2013
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA05821F9630 for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 23:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.099
X-Spam-Level: 
X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMDW-ABi3cbe for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 23:45:58 -0700 (PDT)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0980421F962E for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 23:45:57 -0700 (PDT)
Received: by mail-we0-f173.google.com with SMTP id t57so96297wey.4 for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 23:45:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=w8v3DAWVyC6quHQRUoisDjODcbZK1oIxmf5Rw5VnnQU=; b=u/OZYD+ka8TfUt75sYayycDeUQKZJ6Cosvj+MP5iH/4nGfpQb7+ITWm+jyGbD/vUcq phUbh3QqfJ7Z88Rw6Er3hPFSFHqMVUdgRa4uBy1oaJmbN/Fqusrpl18e+GEHZtc4s5f2 GLb8a1hYFdQp4BspCZInJ9bKPOt5xzzrn3NMdT5cGYGdXGoiSj1IxWCNszVd6ytXpCPh L2DQvlPEWa0Nl/+VcbWhUYg3N5vNqcsFUNYOrFVTqbvq5sbD5Grlx7WURp7KSCU2X6PA 38tLFFD0UL1ihKe82/sckxEDRXGuX3mi3ZfjXbUTelRYAs6Djil4XzxXqaCOMzWcX2k9 sG7w==
X-Received: by 10.194.176.165 with SMTP id cj5mr1248700wjc.37.1366094756745; Mon, 15 Apr 2013 23:45:56 -0700 (PDT)
Received: from [10.3.2.18] (a2.norwich.yourspac.nsdsl.net. [94.229.131.97]) by mx.google.com with ESMTPS id fp2sm17443975wib.7.2013.04.15.23.45.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 23:45:55 -0700 (PDT)
Message-ID: <516CF39D.7020306@gmail.com>
Date: Tue, 16 Apr 2013 07:45:49 +0100
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Liubing (Leo)" <leo.liubing@huawei.com>
References: <CA+9kkMDEc1mX77eRYMXPBKnH9X+jOXGVD7pVFArkwSwNsF+wMA@mail.gmail.com>	<8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEE@nkgeml506-mbx.china.huawei.com> <CA+9kkMA7+_m5s-iEo24H9jrGt9Osn32iMBDSSEyL7FNyeDT5+g@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6FC22B@nkgeml506-mbx.china.huawei.com>
In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F453D6FC22B@nkgeml506-mbx.china.huawei.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "draft-ietf-6renum-gap-analysis.all@tools.ietf.org" <draft-ietf-6renum-gap-analysis.all@tools.ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 06:45:58 -0000

>>> "starts from existing work in [RFC5887],
>>> [I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]." but the references
>>> to these documents are informative.  If the document is meant to be an extension,
>>> rather than a replacement, such that these documents must be read to get the full
>>> picture, than a normative reference may be better.

>> Well, we don't have a category for "informative, but really important context", so I leave it to you to pick.  I would personally likely choose normative to highlight their importance.
> 
> [Bing2] Ok, if normative could highlight the importance without implication of extension or replacement, then I think it is good. Thanks for the suggestion.

RFC 5887 and 4192 are Informational so cannot be normative, and the draft
is long-expired so cannot be normative.

Regards
   Brian

From ietfc@btconnect.com  Tue Apr 16 01:29:32 2013
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7773E21F9680 for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 01:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGTaTgT66vlq for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 01:29:31 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 1577321F9677 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 01:29:30 -0700 (PDT)
Received: from mail147-ch1-R.bigfish.com (10.43.68.244) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Tue, 16 Apr 2013 08:29:30 +0000
Received: from mail147-ch1 (localhost [127.0.0.1])	by mail147-ch1-R.bigfish.com (Postfix) with ESMTP id 434E42207BA; Tue, 16 Apr 2013 08:29:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.250.69; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0711HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -22
X-BigFish: PS-22(zzbb2dI98dI9371I542I1432I1418Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL8275bh8275dh8275chz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah304l1155h)
Received: from mail147-ch1 (localhost.localdomain [127.0.0.1]) by mail147-ch1 (MessageSwitch) id 1366100967795039_28938; Tue, 16 Apr 2013 08:29:27 +0000 (UTC)
Received: from CH1EHSMHS020.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.239])	by mail147-ch1.bigfish.com (Postfix) with ESMTP id B53AC3601C0;	Tue, 16 Apr 2013 08:29:27 +0000 (UTC)
Received: from AMXPRD0711HT004.eurprd07.prod.outlook.com (157.56.250.69) by CH1EHSMHS020.bigfish.com (10.43.70.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 16 Apr 2013 08:29:26 +0000
Received: from AMXPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.242.9.165) with Microsoft SMTP Server (TLS) id 14.16.293.5; Tue, 16 Apr 2013 08:29:22 +0000
Message-ID: <010901ce3a7b$d60eb6c0$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: <dcrocker@bbiw.net>, Scott Kitterman <scott@kitterman.com>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com><3121454.RJqk1xG6s9@scott-latitude-e6320><516C9824.6040503@dcrocker.net><8990489.xAljaCmULD@scott-latitude-e6320> <516CC734.6050303@dcrocker.net>
Date: Tue, 16 Apr 2013 09:24:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.248.133]
X-FOPE-CRA-SourceIpAddress: 157.56.250.69
X-FOPE-CRA-DRYRUN: 1207119;1
X-FOPE-BFA-SENDER: ietfc@btconnect.com
X-FOPE-BFA-RECEIVER: apps-discuss@ietf.org
X-FOPE-BFA-RECEIVER: scott@kitterman.com
X-FOPE-BFA-RECEIVER: dcrocker@bbiw.net
X-OriginatorOrg: btconnect.com
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 08:29:32 -0000

----- Original Message -----
From: "Dave Crocker" <dhc@dcrocker.net>
To: "Scott Kitterman" <scott@kitterman.com>
Cc: <apps-discuss@ietf.org>
Sent: Tuesday, April 16, 2013 4:36 AM
>
> On 4/15/2013 6:35 PM, Scott Kitterman wrote:
> > I think that if a draft is submitted as a candidate working group
work item
> > and the sponsors don't like the result of the chartering discussion
and that
> > draft is suddenly an independent submission, that's pretty well, by
definition,
> > an end around the working group process.
>
> That's the same as saying that when one starts a negotiation, one is
> obligated to make a contract.
>
> The initial chartering process is a negotiation between those bringing
> the work into the IETF and the IETF community.  Either side is free to
> agree or disagree with whatever terms they wish.
>
> And free to walk away when there is not a sufficient meeting of the
> minds doing the negotiating.
>
> The IETF does not have a 'right' to the work that is brought to it.
>
> The ISE mechanism is for stuff that is relevant to the community, but
> isn't going through IETF or IRTF processing.  As a body of documents,
> the RFC series is larger than the IETF.

There is also the option of documenting existing practice, either via
the ISE or as an Individual submission, as an Informational RFC, with an
IETF Working Group later producing a Standards Track series of RFC of an
evolving specification.  (I have seen two examples of this).

Tom Petch

> Work that is brought to the IETF has different levels of completeness
> and maturity, and different timings for having achieved those levels.
>
> When the IETF charters a group and includes existing material, the
> charter can cast the role of that material in very different ways:
>
>       It can treat it as nor more than a set of ideas, to be used or
> ignored;
>
>       It can treat it as a basic design, with all of the actual
details
> still fluid;
>
>       It can treat it as a rough draft, to be massively revised;
>
>       It can treat it as a solid specification that merely needs
review,
> refinement and maybe enhancement;
>
>       It can treat it as a deployed technology that should try to
> protect its installed base, but will tolerate some disruption;
>
>       It can treat it as a deployed technology that /must/ protect its
> installed base and must ensure that core interoperability is retained
> with that installed base.
>
>
> No doubt there are some other variations I've missed, but I hope this
is
> enough to make clear that the choice of language in a working group
> charter, to constrain or not constrain the working group can make an
> enormous difference.
>
> Equally, those bringing technology to the IETF do so at different
points
> in the maturity of their work.  Any of the above might make sense,
> depending upon that maturity, the extent of deployment, and the timing
> of the investment made by the installed base.
>
> When technology is brand new, with at most some prototypes done as
> proofs of concept, then significant changes to the spec won't
> necessarily add much to the development cost.  On the other extreme, a
> mature, deployed market can be almost cavalier about the freedom of a
> working group charter, because a working group that gets silly can be
> ignored: that is, the installed base is sufficiently well-established
> and unified in what it will accept, so that it's leverage is clear.
>
> However, immediately after the development investment is made -- and
> especially when there has been considerable initial deployment, but
> still room for quite a bit more -- the installed and potential base
will
> not take kindly to disruptive standards work; in fact such work can
> seriously damage adoption.
>
> DKIM had almost no deployed base.  Jabber had quite a bit of deployed
> and mature base.
>
> DMARC has a very large, newly-deployed base that just made the
> investment.  Making any changes that render the base not fully
> interoperable will a) piss of the folk who just made the investment,
and
> b) possibly sour the folk considering deployment.  It typically at
least
> causes the potential adopters to delay, sometime for years.
>
> The charter that was originally submitted was tuned to the reality of
> DMARC's maturity and deployment.  Since that caused so much heartache
to
> a few folk, the new draft charter removes the base spec from the
current
> equation.  When deployment settles down and initial investment costs
> have been recovered, it will make sense to review the status of the
base
> specification.
>
>
> d/
>
> ps.  I'm merely speaking for myself, of course, and not on behalf of
the
> DMARC consortium.
> --
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>



From barryleiba.mailing.lists@gmail.com  Tue Apr 16 05:27:39 2013
Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F289C21F96EB for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 05:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.477
X-Spam-Level: 
X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwvBeEP6ZfSI for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 05:27:39 -0700 (PDT)
Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFB121F96D7 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 05:27:38 -0700 (PDT)
Received: by mail-ve0-f171.google.com with SMTP id b10so349711vea.30 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 05:27:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=g124kLjB7pj2qD3eU9TvftUzRMzjsOStY1mGAYHNmbg=; b=B5VV1koWZ6kZ9j+Lus71tMoWWMWK1CZYdAHpUS4NN5eB8Odb1/dStftj79gKJWIR/w jlISDRK4cFyXYuFo6J+taY7qzRHna2hHX0HUPRO+xuO2yml2X2URz8S7K++ENx4LbMWA N2vEo/Gni9UJWwEGTuDxXkODvqgPM54VS2F4oZILAc3+3Vg4xASdnsBGDGOf2xaMSEyB ZjpuKSrEOr5re/HRxyaq+jzHm75uZXIWvpZORXmf/mqYK8+/JxLgJJ5D//YUldtyjbDa 1MKAGyACTzgDvO/G5JTO/TCyRaqUiB8EMc88+3RwWrI07I8r7u19RNeIjQ1pZFZ8YC00 xFLw==
MIME-Version: 1.0
X-Received: by 10.52.121.112 with SMTP id lj16mr1124677vdb.84.1366115258502; Tue, 16 Apr 2013 05:27:38 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Tue, 16 Apr 2013 05:27:38 -0700 (PDT)
In-Reply-To: <516CF39D.7020306@gmail.com>
References: <CA+9kkMDEc1mX77eRYMXPBKnH9X+jOXGVD7pVFArkwSwNsF+wMA@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEE@nkgeml506-mbx.china.huawei.com> <CA+9kkMA7+_m5s-iEo24H9jrGt9Osn32iMBDSSEyL7FNyeDT5+g@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6FC22B@nkgeml506-mbx.china.huawei.com> <516CF39D.7020306@gmail.com>
Date: Tue, 16 Apr 2013 08:27:38 -0400
X-Google-Sender-Auth: 4vXwg3Q8pTY7WzfKzO_42_oT8tc
Message-ID: <CAC4RtVB_BN3oYwpWBW6pGHXK_OvbP2588AnpxEU_L+RV5jE9ng@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary=089e01184dc2b4923704da797e71
Cc: "draft-ietf-6renum-gap-analysis.all@tools.ietf.org" <draft-ietf-6renum-gap-analysis.all@tools.ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "Liubing \(Leo\)" <leo.liubing@huawei.com>
Subject: Re: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 12:27:40 -0000

--089e01184dc2b4923704da797e71
Content-Type: text/plain; charset=ISO-8859-1

> RFC 5887 and 4192 are Informational so cannot be normative

That's not true any more -- we've allowed downrefs to Informational
documents for some time now, if the community agrees, through a note in the
last call announcement, that they are necessary references.  All we'd have
to do is run a last call that specifically mentions them.

Barry

On Tuesday, April 16, 2013, Brian E Carpenter wrote:

> >>> "starts from existing work in [RFC5887],
> >>> [I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]." but the
> references
> >>> to these documents are informative.  If the document is meant to be an
> extension,
> >>> rather than a replacement, such that these documents must be read to
> get the full
> >>> picture, than a normative reference may be better.
>
> >> Well, we don't have a category for "informative, but really important
> context", so I leave it to you to pick.  I would personally likely choose
> normative to highlight their importance.
> >
> > [Bing2] Ok, if normative could highlight the importance without
> implication of extension or replacement, then I think it is good. Thanks
> for the suggestion.
>
> RFC 5887 and 4192 are Informational so cannot be normative, and the draft
> is long-expired so cannot be normative.
>
> Regards
>    Brian
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org <javascript:;>
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--089e01184dc2b4923704da797e71
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

&gt;=A0<font><span style=3D"line-height:normal;background-color:rgba(255,25=
5,255,0)">RFC 5887 and 4192 are Informational so cannot be normative</span>=
</font><div><font><span style=3D"line-height:normal"><br></span></font></di=
v><div>
<font><span style=3D"line-height:normal">That&#39;s not true any more -- we=
&#39;ve allowed downrefs to Informational documents for some time now, if t=
he community agrees, through a note in the last call announcement, that the=
y are necessary references. =A0All we&#39;d have to do is run a last call t=
hat specifically mentions them.</span></font></div>
<div><font><span style=3D"line-height:normal"><br></span></font></div><div>=
<font><span style=3D"line-height:normal">Barry<span></span><br></span></fon=
t><br>On Tuesday, April 16, 2013, Brian E Carpenter  wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
&gt;&gt;&gt; &quot;starts from existing work in [RFC5887],<br>
&gt;&gt;&gt; [I-D.chown-v6ops-renumber-thinkabout] and [RFC4192].&quot; but=
 the references<br>
&gt;&gt;&gt; to these documents are informative. =A0If the document is mean=
t to be an extension,<br>
&gt;&gt;&gt; rather than a replacement, such that these documents must be r=
ead to get the full<br>
&gt;&gt;&gt; picture, than a normative reference may be better.<br>
<br>
&gt;&gt; Well, we don&#39;t have a category for &quot;informative, but real=
ly important context&quot;, so I leave it to you to pick. =A0I would person=
ally likely choose normative to highlight their importance.<br>
&gt;<br>
&gt; [Bing2] Ok, if normative could highlight the importance without implic=
ation of extension or replacement, then I think it is good. Thanks for the =
suggestion.<br>
<br>
RFC 5887 and 4192 are Informational so cannot be normative, and the draft<b=
r>
is long-expired so cannot be normative.<br>
<br>
Regards<br>
=A0 =A0Brian<br>
_______________________________________________<br>
apps-discuss mailing list<br>
<a href=3D"javascript:;" onclick=3D"_e(event, &#39;cvml&#39;, &#39;apps-dis=
cuss@ietf.org&#39;)">apps-discuss@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
</blockquote></div>

--089e01184dc2b4923704da797e71--

From brian.e.carpenter@gmail.com  Tue Apr 16 05:35:17 2013
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C0B21F969B for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 05:35:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.849
X-Spam-Level: 
X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFdBpBtlfbj6 for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 05:35:17 -0700 (PDT)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id B3C0321F935D for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 05:35:16 -0700 (PDT)
Received: by mail-we0-f179.google.com with SMTP id p43so308931wea.38 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 05:35:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TbYJHGa00Ucxoc/9j1AiV+YVFZ0ZSuuRS317Nw2GDAM=; b=APf06zcfJ5wsiEPrnpjJkml9bUTt3WQuZyf8Doeb2gnPsVBD+ArEVebBQw8peeaAsQ EURrXruPpC6+aJihY9p4cJiOJ3o2LIRCv5pMKPV3b/cgJ0YdqLEbRiAy54kEI/TaUaCi r12xlpj3rwd6w872NJtxvP8V5U6jd77bSOOzdnTnRguAcix4bwE5jMop2Y6stl+59ont NziD/l5zgU1DgJ3NyzAGh6fBwjXobssq7yUl0or14nlq8nYjdWwkTaSRmHiunQcBflNn RKiFxOrTsxGiADc4wK3ZiFA9Z0SxplGCXFxJxAdFxB82Fx6MzHTgCEgKdI8s1w+dvhg8 JWkQ==
X-Received: by 10.180.93.134 with SMTP id cu6mr3262229wib.8.1366115715917; Tue, 16 Apr 2013 05:35:15 -0700 (PDT)
Received: from [10.3.2.18] (a2.norwich.yourspac.nsdsl.net. [94.229.131.97]) by mx.google.com with ESMTPS id ej8sm19172601wib.9.2013.04.16.05.35.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Apr 2013 05:35:15 -0700 (PDT)
Message-ID: <516D4583.7020707@gmail.com>
Date: Tue, 16 Apr 2013 13:35:15 +0100
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Barry Leiba <barryleiba@computer.org>
References: <CA+9kkMDEc1mX77eRYMXPBKnH9X+jOXGVD7pVFArkwSwNsF+wMA@mail.gmail.com>	<8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEE@nkgeml506-mbx.china.huawei.com>	<CA+9kkMA7+_m5s-iEo24H9jrGt9Osn32iMBDSSEyL7FNyeDT5+g@mail.gmail.com>	<8AE0F17B87264D4CAC7DE0AA6C406F453D6FC22B@nkgeml506-mbx.china.huawei.com>	<516CF39D.7020306@gmail.com> <CAC4RtVB_BN3oYwpWBW6pGHXK_OvbP2588AnpxEU_L+RV5jE9ng@mail.gmail.com>
In-Reply-To: <CAC4RtVB_BN3oYwpWBW6pGHXK_OvbP2588AnpxEU_L+RV5jE9ng@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "draft-ietf-6renum-gap-analysis.all@tools.ietf.org" <draft-ietf-6renum-gap-analysis.all@tools.ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "Liubing \(Leo\)" <leo.liubing@huawei.com>
Subject: Re: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 12:35:17 -0000

On 16/04/2013 13:27, Barry Leiba wrote:
>> RFC 5887 and 4192 are Informational so cannot be normative
> 
> That's not true any more -- we've allowed downrefs to Informational
> documents for some time now, if the community agrees, through a note in the
> last call announcement, that they are necessary references.  All we'd have
> to do is run a last call that specifically mentions them.

Yes, I am aware of that, and it's a matter of judgement, but
since this draft is not in any sense a protocol specification
or a pseudo-BCP, I am not sure why it needs *any* normative
references, let alone downrefs. There is certainly no
process requirement for them.

   Brian

> Barry
> 
> On Tuesday, April 16, 2013, Brian E Carpenter wrote:
> 
>>>>> "starts from existing work in [RFC5887],
>>>>> [I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]." but the
>> references
>>>>> to these documents are informative.  If the document is meant to be an
>> extension,
>>>>> rather than a replacement, such that these documents must be read to
>> get the full
>>>>> picture, than a normative reference may be better.
>>>> Well, we don't have a category for "informative, but really important
>> context", so I leave it to you to pick.  I would personally likely choose
>> normative to highlight their importance.
>>> [Bing2] Ok, if normative could highlight the importance without
>> implication of extension or replacement, then I think it is good. Thanks
>> for the suggestion.
>>
>> RFC 5887 and 4192 are Informational so cannot be normative, and the draft
>> is long-expired so cannot be normative.
>>
>> Regards
>>    Brian
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org <javascript:;>
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
> 

From dcrocker@bbiw.net  Tue Apr 16 07:47:09 2013
Return-Path: <dcrocker@bbiw.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F0021F9733 for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 07:47:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSlp0YfD6dAg for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 07:47:08 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id AE75421F9500 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 07:47:08 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3GEl5Dg030713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Apr 2013 07:47:06 -0700
Message-ID: <516D6469.3060109@bbiw.net>
Date: Tue, 16 Apr 2013 07:47:05 -0700
From: Dave Crocker <dcrocker@bbiw.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "t.petch" <ietfc@btconnect.com>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com><3121454.RJqk1xG6s9@scott-latitude-e6320><516C9824.6040503@dcrocker.net><8990489.xAljaCmULD@scott-latitude-e6320> <516CC734.6050303@dcrocker.net> <010901ce3a7b$d60eb6c0$4001a8c0@gateway.2wire.net>
In-Reply-To: <010901ce3a7b$d60eb6c0$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 16 Apr 2013 07:47:06 -0700 (PDT)
Cc: Scott Kitterman <scott@kitterman.com>, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 14:47:09 -0000

On 4/16/2013 1:24 AM, t.petch wrote:
> There is also the option of documenting existing practice, either via
> the ISE or as an Individual submission, as an Informational RFC, with an
> IETF Working Group later producing a Standards Track series of RFC of an
> evolving specification.  (I have seen two examples of this).


Right.  I was focused only on documents being brought into a wg, but it 
probably helps to be more complete and cite the (not all that uncommon) 
path of starting with an Independent RFC that is informational.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From ted.ietf@gmail.com  Tue Apr 16 08:06:17 2013
Return-Path: <ted.ietf@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A365921F9750 for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 08:06:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.751
X-Spam-Level: 
X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=0.849,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+-yIzJFlbNG for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 08:06:16 -0700 (PDT)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 68D9021F974F for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 08:06:16 -0700 (PDT)
Received: by mail-ie0-f180.google.com with SMTP id qd14so603428ieb.39 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 08:06:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=B+S+6j1/sTjjZKJgiYPb/UeOxxiIpNGR0+LI0ZmWOy4=; b=IdrvzezpWLveKq8TI5516No5zcI/5L4AwVQQqzhKpdP9MVXjWRfB4Y4i22A1i8xwDw TviLgpfStRnIZ6owPQ++2XiKdysRQmOuj+yqkmu6+BnB2VHnN+ZrcXNagSOv1+wGXVh3 Bz7QpxDdMZa7FeNIpc6E54CZkZbLPQodmhCvwC2Q0GJa2mkT/voyPMiVeJqCd9P4kyLO Zh1L2MM4xSFW5GjPfN64IXRPwyAuYRjU4V+cmrk5Qsv0jfPO2/xq6zar0qQC/PHBb2Ah mr9kTg6VD0rvU86HI4AUQgHrV9VDzhwrr2SZYwOQQ77/G3DXGmdsKe6xm4uPeWkZN44J Ld4Q==
MIME-Version: 1.0
X-Received: by 10.50.87.71 with SMTP id v7mr1479544igz.96.1366124775974; Tue, 16 Apr 2013 08:06:15 -0700 (PDT)
Received: by 10.43.135.202 with HTTP; Tue, 16 Apr 2013 08:06:15 -0700 (PDT)
In-Reply-To: <516D4583.7020707@gmail.com>
References: <CA+9kkMDEc1mX77eRYMXPBKnH9X+jOXGVD7pVFArkwSwNsF+wMA@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEE@nkgeml506-mbx.china.huawei.com> <CA+9kkMA7+_m5s-iEo24H9jrGt9Osn32iMBDSSEyL7FNyeDT5+g@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6FC22B@nkgeml506-mbx.china.huawei.com> <516CF39D.7020306@gmail.com> <CAC4RtVB_BN3oYwpWBW6pGHXK_OvbP2588AnpxEU_L+RV5jE9ng@mail.gmail.com> <516D4583.7020707@gmail.com>
Date: Tue, 16 Apr 2013 08:06:15 -0700
Message-ID: <CA+9kkMA2FDH3DSLED33uS5R0VSxyUok96OEU9=LtODu+nYRv3A@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary=089e0103ef52fdb05f04da7bb5b8
Cc: Barry Leiba <barryleiba@computer.org>, "Liubing \(Leo\)" <leo.liubing@huawei.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "draft-ietf-6renum-gap-analysis.all@tools.ietf.org" <draft-ietf-6renum-gap-analysis.all@tools.ietf.org>
Subject: Re: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 15:06:17 -0000

--089e0103ef52fdb05f04da7bb5b8
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 16, 2013 at 5:35 AM, Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> Yes, I am aware of that, and it's a matter of judgement, but
> since this draft is not in any sense a protocol specification
> or a pseudo-BCP, I am not sure why it needs *any* normative
> references, let alone downrefs. There is certainly no
> process requirement for them.
>
>
I certainly agree that there is no process requirement, but there is a
potentially useful result.  When I see a document like this with 9
normative references (as it has now), I get the sense that those are the
ones which are needed context and that the informative ones are useful
additional information.  That maps to "Essential reading" and "Useful
additional information", which is pretty much the same mapping as
"Normative" and "Informative" have in a protocol spec.  It's not *exactly*
the same, I grant you, but it's an approximation.  My question about the
three listed as "starts from" might have been better phrased as:  are these
"Essential Reading" or "Useful additional information"?

regards,

Ted Hardie


>    Brian
>
> > Barry
> >
> > On Tuesday, April 16, 2013, Brian E Carpenter wrote:
> >
> >>>>> "starts from existing work in [RFC5887],
> >>>>> [I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]." but the
> >> references
> >>>>> to these documents are informative.  If the document is meant to be
> an
> >> extension,
> >>>>> rather than a replacement, such that these documents must be read to
> >> get the full
> >>>>> picture, than a normative reference may be better.
> >>>> Well, we don't have a category for "informative, but really important
> >> context", so I leave it to you to pick.  I would personally likely
> choose
> >> normative to highlight their importance.
> >>> [Bing2] Ok, if normative could highlight the importance without
> >> implication of extension or replacement, then I think it is good. Thanks
> >> for the suggestion.
> >>
> >> RFC 5887 and 4192 are Informational so cannot be normative, and the
> draft
> >> is long-expired so cannot be normative.
> >>
> >> Regards
> >>    Brian
> >> _______________________________________________
> >> apps-discuss mailing list
> >> apps-discuss@ietf.org <javascript:;>
> >> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>
> >
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--089e0103ef52fdb05f04da7bb5b8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 16, 2013 at 5:35 AM, Brian E Carpenter <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:brian.e.carpenter@gmail.com" target=3D"_blank">brian.e.carp=
enter@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div class=3D"im">Yes, I am aware of that, and it&#39;s a matter of judgeme=
nt, but<br></div>
since this draft is not in any sense a protocol specification<br>
or a pseudo-BCP, I am not sure why it needs *any* normative<br>
references, let alone downrefs. There is certainly no<br>
process requirement for them.<br>
<br></blockquote><div><br>I certainly agree that there is no process requir=
ement, but there is a potentially useful result.=A0 When I see a document l=
ike this with 9 normative references (as it has now), I get the sense that =
those are the ones which are needed context and that the informative ones a=
re useful additional information.=A0 That maps to &quot;Essential reading&q=
uot; and &quot;Useful additional information&quot;, which is pretty much th=
e same mapping as &quot;Normative&quot; and &quot;Informative&quot; have in=
 a protocol spec.=A0 It&#39;s not *exactly* the same, I grant you, but it&#=
39;s an approximation.=A0 My question about the three listed as &quot;start=
s from&quot; might have been better phrased as:=A0 are these &quot;Essentia=
l Reading&quot; or &quot;Useful additional information&quot;?<br>
<br>regards,<br><br>Ted Hardie<br>=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
=A0 =A0Brian<br>
<div class=3D"im"><br>
&gt; Barry<br>
&gt;<br>
&gt; On Tuesday, April 16, 2013, Brian E Carpenter wrote:<br>
&gt;<br>
&gt;&gt;&gt;&gt;&gt; &quot;starts from existing work in [RFC5887],<br>
&gt;&gt;&gt;&gt;&gt; [I-D.chown-v6ops-renumber-thinkabout] and [RFC4192].&q=
uot; but the<br>
&gt;&gt; references<br>
&gt;&gt;&gt;&gt;&gt; to these documents are informative. =A0If the document=
 is meant to be an<br>
&gt;&gt; extension,<br>
&gt;&gt;&gt;&gt;&gt; rather than a replacement, such that these documents m=
ust be read to<br>
&gt;&gt; get the full<br>
&gt;&gt;&gt;&gt;&gt; picture, than a normative reference may be better.<br>
&gt;&gt;&gt;&gt; Well, we don&#39;t have a category for &quot;informative, =
but really important<br>
&gt;&gt; context&quot;, so I leave it to you to pick. =A0I would personally=
 likely choose<br>
&gt;&gt; normative to highlight their importance.<br>
&gt;&gt;&gt; [Bing2] Ok, if normative could highlight the importance withou=
t<br>
&gt;&gt; implication of extension or replacement, then I think it is good. =
Thanks<br>
&gt;&gt; for the suggestion.<br>
&gt;&gt;<br>
&gt;&gt; RFC 5887 and 4192 are Informational so cannot be normative, and th=
e draft<br>
&gt;&gt; is long-expired so cannot be normative.<br>
&gt;&gt;<br>
&gt;&gt; Regards<br>
&gt;&gt; =A0 =A0Brian<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; apps-discuss mailing list<br>
</div>&gt;&gt; <a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.o=
rg</a> &lt;javascript:;&gt;<br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" tar=
get=3D"_blank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
<div class=3D"HOEnZb"><div class=3D"h5">&gt;&gt;<br>
&gt;<br>
_______________________________________________<br>
apps-discuss mailing list<br>
<a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
</div></div></blockquote></div><br>

--089e0103ef52fdb05f04da7bb5b8--

From jtrentadams@gmail.com  Tue Apr 16 08:23:22 2013
Return-Path: <jtrentadams@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC1C21F972A for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 08:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh0MjW8XikS8 for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 08:23:21 -0700 (PDT)
Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0525521F9399 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 08:23:20 -0700 (PDT)
Received: by mail-oa0-f46.google.com with SMTP id h2so608070oag.33 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 08:23:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=lG5rGVtfu5OfdtQ6c0T5tRTGfjFm+e69Kkcv804KT6I=; b=YA0LbGvxIdzG8qUiz9ycw8dDlapywywzIuxWswXnZy5AzCMCIxkvXeZdH6oZGWN6jP ZkczfKYVQgrmwZhunj01I1VyteFI6fD598X5g2VCq1nHuqSrfFGxCxfWIamuCgnldbyc mVJtt4sh9iMjWy3dY/13bFUrOcEr+kJTfjpiLG5I/cOH5IuOsGUHjRzkpVXyDvtS+2oQ lREKTZ1jZtAoFpuLpCDe/sRvhBZpEozHScSCJpJ+41sbg2H8YMtxp3vYwRLZ33KWTpnC fNDc+WXFity170uLF6/ZsTyeqiKfAF9o/6C8h9IK2IGDYBdu4nlReioQlv3HmtMq36qc Uy8w==
X-Received: by 10.182.102.228 with SMTP id fr4mr925243obb.84.1366125800516; Tue, 16 Apr 2013 08:23:20 -0700 (PDT)
Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPS id jw8sm388392obb.14.2013.04.16.08.23.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Apr 2013 08:23:19 -0700 (PDT)
Message-ID: <516D6CE6.4070509@gmail.com>
Date: Tue, 16 Apr 2013 09:23:18 -0600
From: "J. Trent Adams" <jtrentadams@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Scott Kitterman <scott@kitterman.com>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <8990489.xAljaCmULD@scott-latitude-e6320> <516CC734.6050303@dcrocker.net> <15015065.dv5A4A6JuL@scott-latitude-e6320>
In-Reply-To: <15015065.dv5A4A6JuL@scott-latitude-e6320>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 15:23:23 -0000

On 4/15/13 9:58 PM, Scott Kitterman wrote:
> On Monday, April 15, 2013 08:36:20 PM Dave Crocker wrote:
>> On 4/15/2013 6:35 PM, Scott Kitterman wrote:
>>> I think that if a draft is submitted as a candidate working group work
>>> item
>>> and the sponsors don't like the result of the chartering discussion and
>>> that draft is suddenly an independent submission, that's pretty well, by
>>> definition, an end around the working group process.
>> That's the same as saying that when one starts a negotiation, one is
>> obligated to make a contract.
>>
>> The initial chartering process is a negotiation between those bringing
>> the work into the IETF and the IETF community.  Either side is free to
>> agree or disagree with whatever terms they wish.
>>
>> And free to walk away when there is not a sufficient meeting of the
>> minds doing the negotiating.
>>
>> The IETF does not have a 'right' to the work that is brought to it.
>>
>> The ISE mechanism is for stuff that is relevant to the community, but
>> isn't going through IETF or IRTF processing.  As a body of documents,
>> the RFC series is larger than the IETF.
>>
>>
>> Work that is brought to the IETF has different levels of completeness
>> and maturity, and different timings for having achieved those levels.
>>
>> When the IETF charters a group and includes existing material, the
>> charter can cast the role of that material in very different ways:
>>
>>       It can treat it as nor more than a set of ideas, to be used or
>> ignored;
>>
>>       It can treat it as a basic design, with all of the actual details
>> still fluid;
>>
>>       It can treat it as a rough draft, to be massively revised;
>>
>>       It can treat it as a solid specification that merely needs review,
>> refinement and maybe enhancement;
>>
>>       It can treat it as a deployed technology that should try to
>> protect its installed base, but will tolerate some disruption;
>>
>>       It can treat it as a deployed technology that /must/ protect its
>> installed base and must ensure that core interoperability is retained
>> with that installed base.
>>
>>
>> No doubt there are some other variations I've missed, but I hope this is
>> enough to make clear that the choice of language in a working group
>> charter, to constrain or not constrain the working group can make an
>> enormous difference.
>>
>> Equally, those bringing technology to the IETF do so at different points
>> in the maturity of their work.  Any of the above might make sense,
>> depending upon that maturity, the extent of deployment, and the timing
>> of the investment made by the installed base.
>>
>> When technology is brand new, with at most some prototypes done as
>> proofs of concept, then significant changes to the spec won't
>> necessarily add much to the development cost.  On the other extreme, a
>> mature, deployed market can be almost cavalier about the freedom of a
>> working group charter, because a working group that gets silly can be
>> ignored: that is, the installed base is sufficiently well-established
>> and unified in what it will accept, so that it's leverage is clear.
>>
>> However, immediately after the development investment is made -- and
>> especially when there has been considerable initial deployment, but
>> still room for quite a bit more -- the installed and potential base will
>> not take kindly to disruptive standards work; in fact such work can
>> seriously damage adoption.
>>
>> DKIM had almost no deployed base.  Jabber had quite a bit of deployed
>> and mature base.
>>
>> DMARC has a very large, newly-deployed base that just made the
>> investment.  Making any changes that render the base not fully
>> interoperable will a) piss of the folk who just made the investment, and
>> b) possibly sour the folk considering deployment.  It typically at least
>> causes the potential adopters to delay, sometime for years.
>>
>> The charter that was originally submitted was tuned to the reality of
>> DMARC's maturity and deployment.  Since that caused so much heartache to
>> a few folk, the new draft charter removes the base spec from the current
>> equation.  When deployment settles down and initial investment costs
>> have been recovered, it will make sense to review the status of the base
>> specification.
>>
>>
>> d/
>>
>> ps.  I'm merely speaking for myself, of course, and not on behalf of the
>> DMARC consortium.
> In this case it's more like announcing a lockout when the initial offer from 
> management isn't accepted without modification by the union rather than 
> determining a meeting of the minds cannot be achieved after good faith 
> negotiations.
>
> 1.  How about this?
> 2.  Not quite, here are some alternatives we could discuss.
> 1.  I quit.
>
> that's hardly a negotiation.
>
> Your argument against a working group is that it will be hard to get people 
> who have adopted DMARC already to implement interoperability improvements 
> because they just implemented it.  Are you suggesting that it will be easier, 
> later, when there is more deployment and the current pattern is better 
> established?

Yes, in this case it's likely that will occur. I can't speak to
everyone's development pipeline, of course, but in my experience
moderate to large enterprises require months and years of planning. The
most reasonable architects I've known include upgrade paths during
initial planning which address exactly what I think you're describing.
They'll be planning their solution based on current knowledge (ie the
existing spec) with a mind toward something like a two-year upgrade to
whatever the extensions (or possible revision) may be.

Another way to look at it is that since there's real value seen in
deployment today, there's a counter-incentive to wait an indeterminate
time for a possible revision. Each day that passes is another day that
customers are being phished... and, sadly, each phishing attack is yet
another opportunity for a cascading set of casualties (think: spear
phishing a whale).

I'm pretty sure we all agree that perfection can be the enemy of the
good. Getting a stable, useful, though possibly sub-perfect, solution
running is a reasonable path toward iterative improvement. Yes, it'll
take time to correct the ship under full sail, but it's possible (and
likely).

I'm all for learning as we go. Let's buckle down, explore some of the
key focus areas identified as possible (non-disruptive) extensions for
now and see how they play. Through that journey we will also learn what
needs to be done to improve the base and be the stronger for it.

Hoping for a brighter future,
Trent

>
> Scott K
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams


From leo.liubing@huawei.com  Mon Apr 15 18:26:03 2013
Return-Path: <leo.liubing@huawei.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5D021F91B8 for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 18:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level: 
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_PAIN=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xji9SMPkT6eF for <apps-discuss@ietfa.amsl.com>; Mon, 15 Apr 2013 18:25:59 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5D59921F909A for <apps-discuss@ietf.org>; Mon, 15 Apr 2013 18:25:58 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARW36357; Tue, 16 Apr 2013 01:25:57 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 16 Apr 2013 02:25:50 +0100
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 16 Apr 2013 02:25:55 +0100
Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.13]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Tue, 16 Apr 2013 09:25:48 +0800
From: "Liubing (Leo)" <leo.liubing@huawei.com>
To: Ted Hardie <ted.ietf@gmail.com>
Thread-Topic: Review of draft-ietf-6renum-gap-analysis-05
Thread-Index: AQHONwcY0vdwoOJq1Eis2vBZoqHNl5jRyugQgAWTv4CAALKmYA==
Date: Tue, 16 Apr 2013 01:25:48 +0000
Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F453D6FC22B@nkgeml506-mbx.china.huawei.com>
References: <CA+9kkMDEc1mX77eRYMXPBKnH9X+jOXGVD7pVFArkwSwNsF+wMA@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEE@nkgeml506-mbx.china.huawei.com> <CA+9kkMA7+_m5s-iEo24H9jrGt9Osn32iMBDSSEyL7FNyeDT5+g@mail.gmail.com>
In-Reply-To: <CA+9kkMA7+_m5s-iEo24H9jrGt9Osn32iMBDSSEyL7FNyeDT5+g@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.111.98.161]
Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F453D6FC22Bnkgeml506mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Tue, 16 Apr 2013 08:29:26 -0700
Cc: "draft-ietf-6renum-gap-analysis.all@tools.ietf.org" <draft-ietf-6renum-gap-analysis.all@tools.ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 01:26:04 -0000

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D6FC22Bnkgeml506mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi, Ted

Just a couple of minor replies in line. Thank you.

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Tuesday, April 16, 2013 6:35 AM
To: Liubing (Leo)
Cc: apps-discuss@ietf.org; draft-ietf-6renum-gap-analysis.all@tools.ietf.or=
g
Subject: Re: Review of draft-ietf-6renum-gap-analysis-05

On Thu, Apr 11, 2013 at 8:00 PM, Liubing (Leo) <leo.liubing@huawei.com<mail=
to:leo.liubing@huawei.com>> wrote:
Hi, Ted

Many thanks for your review, it would be helpful to refine the draft. Pleas=
e see replies inline.

Best regards,
Bing

From: Ted Hardie [mailto:ted.ietf@gmail.com<mailto:ted.ietf@gmail.com>]
Sent: Friday, April 12, 2013 6:51 AM
To: apps-discuss@ietf.org<mailto:apps-discuss@ietf.org>; draft-ietf-6renum-=
gap-analysis.all@tools.ietf.org<mailto:draft-ietf-6renum-gap-analysis.all@t=
ools.ietf.org>
Subject: Review of draft-ietf-6renum-gap-analysis-05

I have been selected as the Applications Area Directorate reviewer
for this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:draft-ietf-6renum-gap-analysis-05
Title: IPv6 Site Renumbering Gap Analysis
Reviewer: Ted Hardie
Review Date: April 11, 2013

Summary: This document is basically ready to be published as an Information=
al draft.  There are minor issues which the authors may wish to address bef=
ore final publication.


Minor Issues:

The document currently motivates its work with the following statement:

   If IPv6 site renumbering continues to be considered

   difficult, network managers will turn to Provider Independent (PI)

   addressing for IPv6 to attempt to minimize the need for future

   renumbering. However, widespread use of PI may create very serious

   BGP4 scaling problems. It is thus desirable to develop tools and

   practices that may make renumbering a simpler process to reduce

   demand for IPv6 PI space.

A citation for this would be useful.  It might also be worth it to
highlight other potential risks--for example, the widespread deployment
of ULAs, which do not admit of aggregation, or the deployment of




[Bing] Ok, thanks for the suggestion. We'll include the reference on BGP4 s=
caling issue, as well as considering whether there are other potential risk=
s.

But for the specific ULA problem, it might be different. ULA is intended to=
 be used within a certain scope, normally, within an enterprise network. So=
 it won't bother the global routing scalability.

In fact we suggest to use ULA along with PA in enterprise to avoid some ren=
umbering or to make internal communication more stable when switching globa=
l prefixes. It was documented in the recently published 6renum RFC6879 (Ple=
ase see section 4.1)



My feelings on ULAs are both largely unprintable and pretty well-known.  I'=
ll spare you the re-iteration.

[Bing2] I might misunderstood your previous comment on ULA. Thanks for spar=
ing the re-iteration :)



address translation technologies which make referral more difficult.  I not=
e
that RFC 5887 included some of these issues.  If the intent is to reference
those from RFC 5887, I note that  the document currently says that it






"starts from existing work in [RFC5887],

[I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]." but the references
to these documents are informative.  If the document is meant to be an exte=
nsion,
rather than a replacement, such that these documents must be read to get th=
e full

picture, than a normative reference may be better.



[Bing] These documents are important input for the gap analysis draft. They=
 indeed have not a few crossed content, but our intention on the gap draft =
was different, so it is neither extension nor replacement.

RFC5887&draft-thinkabout are more comprehensive analysis/guidelines on IPv6=
 renumbering issue; RFC4192 emphasizes on a "make before break" prefix swit=
ching operation.

This gap draft  addresses the IPv6 enterprise scenarios described in RFC687=
9, and focusing on identifying what is missing to make renum more automatic=
 and less error-prone.


Well, we don't have a category for "informative, but really important conte=
xt", so I leave it to you to pick.  I would personally likely choose normat=
ive to highlight their importance.

[Bing2] Ok, if normative could highlight the importance without implication=
 of extension or replacement, then I think it is good. Thanks for the sugge=
stion.

Best regards,
Bing




For the session survivability section, a reference to RFC 6724 may be usefu=
l, so
that those adding new global addresses understand how the application API t=
o determine

which address is used with interact with the addition of new addresses (if =
there
is a specific draft or other treatment of that topic, that would be even be=
tter,
but I am not personally aware of one).



[Bing] OK. Address selection is indeed important.


In section 6, the document currently says:

   When nodes in a site have been renumbered, then all the entries in

   the site which contain the nodes' addresses must be updated. The

   entries mainly include DNS records and filters in various entities

   such as ACLs in firewalls/gateways.

This appears to imply that these updates must take place after the renumber=
ing
event, but this is variable.  ACLs and filters may well be updated in advan=
ce;


DNS may be updated concurrently or post facto.  A rewording to highlight th=
at

this is variable by record type may be useful.



[Bing] Ok, thanks.


Section 9.2, in the bullet entitled "DNS data structure optimization"


The discusses a DNS feature proposed but declared historic. I don't think i=
t

identifies the related renumbering gap in a way that is useful for a naive
reader.  If it cannot be reworded to focus on the gap, I suggest it be
removed.

[Bing] When we wrote the draft, we considered if the IPv6 DNS record could =
be structured as separating prefix and suffix, that would be very helpful f=
or renumbering. Because in IPv6, most of the time we just change the prefix=
es rather than the whole addresses.

We found A6 has the similar feature, but it has been moved to historic. How=
ever,  the idea of separating prefix and suffix is still considered valuabl=
e, but there might not  be able to develop a new DNS record in a short time=
, so we name the idea as "DNS data structure optimization" and put it into =
"gaps considered unsolvable".

We can add some minor texts to explain the intention.


Thanks.  I do think it should be clear that you are not attempting to resur=
rect the A6 vs. AAAA argument.


In section 9.4, the document says:

      For application layer, as [RFC5887] said, in general, we can

      assert that any implementation is at risk from renumbering if it

      does not check that an address is valid each time it opens a new

      communications session.

This might be reworded to  include or focus on session resumption, rather t=
han
new communications sessions.  From an applications perspective, the laptop


"sleep" function seems to be one of the bigger risks of this.

[Bing] Ok, thanks.

Nit:

For me personally, section 6.1 seemed needlessly pessimistic.

[Bing] It is sad but true. And we are curious about how much operational is=
sues there to prevent DDNS widely deployed in real networks.

If possible, we might consider to make a dedicated draft to talk about this=
 issue in the future.


Thanks for your quick reply,

Ted Hardie

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D6FC22Bnkgeml506mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro=
soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"&#1;" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML \9884\8BBE\683C\5F0F Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.HTMLChar
	{mso-style-name:"HTML \9884\8BBE\683C\5F0F Char";
	mso-style-priority:99;
	mso-style-link:"HTML \9884\8BBE\683C\5F0F";
	font-family:"Courier New";}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi, Ted<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Just a cou=
ple of minor replies in line. Thank you.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;"> Ted Hardie [mailto:ted.ietf@gmail.com]
<br>
<b>Sent:</b> Tuesday, April 16, 2013 6:35 AM<br>
<b>To:</b> Liubing (Leo)<br>
<b>Cc:</b> apps-discuss@ietf.org; draft-ietf-6renum-gap-analysis.all@tools.=
ietf.org<br>
<b>Subject:</b> Re: Review of draft-ietf-6renum-gap-analysis-05<o:p></o:p><=
/span></p>
</div>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">On Thu, Apr 11, 2013 at 8:00 PM=
, Liubing (Leo) &lt;<a href=3D"mailto:leo.liubing@huawei.com" target=3D"_bl=
ank">leo.liubing@huawei.com</a>&gt; wrote:<o:p></o:p></span></p>
<div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi, Ted</span><span lang=
=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span lang=
=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Many thanks for your rev=
iew, it would be helpful to refine the draft. Please see replies
 inline.</span><span lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span lang=
=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Best regards,</span><spa=
n lang=3D"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Bing</span><span lang=3D=
"EN-US"><o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;C=
alibri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span lang=
=3D"EN-US"><o:p></o:p></span></p>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quo=
t;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span lang=3D"EN-US"=
 style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&=
quot;"> Ted
 Hardie [mailto:<a href=3D"mailto:ted.ietf@gmail.com" target=3D"_blank">ted=
.ietf@gmail.com</a>]
<br>
<b>Sent:</b> Friday, April 12, 2013 6:51 AM<br>
<b>To:</b> <a href=3D"mailto:apps-discuss@ietf.org" target=3D"_blank">apps-=
discuss@ietf.org</a>;
<a href=3D"mailto:draft-ietf-6renum-gap-analysis.all@tools.ietf.org" target=
=3D"_blank">
draft-ietf-6renum-gap-analysis.all@tools.ietf.org</a><br>
<b>Subject:</b> Review of draft-ietf-6renum-gap-analysis-05</span><span lan=
g=3D"EN-US"><o:p></o:p></span></p>
</div>
</div>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US">&nbsp;<o:p></o:p></span></p>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US">I have been selected as the Applications Area=
 Directorate reviewer<br>
for this draft (for background on appsdir, please see<br>
<a href=3D"http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDi=
rectorate" target=3D"_blank">http://trac.tools.ietf.org/area/app/trac/wiki/=
ApplicationsAreaDirectorate</a><br>
).<br>
<br>
Please resolve these comments along with any other Last Call comments<br>
you may receive. Please wait for direction from your document shepherd<br>
or AD before posting a new version of the draft.<br>
<br>
Document:draft-ietf-6renum-gap-analysis-05<o:p></o:p></span></p>
<div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a=
lt:auto"><span lang=3D"EN-US">Title: IPv6 Site Renumbering Gap Analysis
<br>
Reviewer: Ted Hardie<br>
Review Date: April 11, 2013<o:p></o:p></span></p>
</div>
<p class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;margin-bottom:12.0p=
t"><span lang=3D"EN-US"><br>
Summary: This document is basically ready to be published as an Information=
al draft.&nbsp; There are minor issues which the authors may wish to addres=
s before final publication.<br>
<br>
<br>
Minor Issues:<br>
<br>
The document currently motivates its work with the following statement:<o:p=
></o:p></span></p>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; If IPv6 site renumbering continues t=
o be considered<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; difficult, network managers will tur=
n to Provider Independent (PI)<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; addressing for IPv6 to attempt to mi=
nimize the need for future<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; renumbering. However, widespread use=
 of PI may create very serious<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; BGP4 scaling problems. It is thus de=
sirable to develop tools and<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; practices that may make renumbering =
a simpler process to reduce<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; demand for IPv6 PI space.<br><br>A c=
itation for this would be useful.&nbsp; It might also be worth it to <br>hi=
ghlight other potential risks--for example, the widespread deployment<br>of=
 ULAs, which do not admit of aggregation, or the deployment of <br><br><o:p=
></o:p></span></pre>
<pre><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></pre>
</div>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Bing] Ok, thanks for the su=
ggestion. We&#8217;ll include the reference on BGP4 scaling issue, as well =
as considering whether there are other potential risks.</span><span lang=3D=
"EN-US"><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">But for the specific ULA pro=
blem, it might be different. ULA is intended to be used within a certain sc=
ope, normally, within an enterprise network. So it won&#8217;t bother the g=
lobal routing scalability.</span><span lang=3D"EN-US"><o:p></o:p></span></p=
re>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">In fact we suggest to use UL=
A along with PA in enterprise to avoid some renumbering or to make internal=
 communication more stable when switching global prefixes. It was documente=
d in the recently published 6renum RFC6879 (Please see section 4.1)</span><=
span lang=3D"EN-US"><o:p></o:p></span></pre>
<div>
<pre><span lang=3D"EN-US">&nbsp;<o:p></o:p></span></pre>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><br>
My feelings on ULAs are both largely unprintable and pretty well-known.&nbs=
p; I'll spare you the re-iteration.<span style=3D"color:#1F497D"><o:p></o:p=
></span></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Bing2] I =
might misunderstood your previous comment on ULA. Thanks for sparing the re=
-iteration
</span><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:Wingdings=
;color:#1F497D">J</span><span lang=3D"EN-US" style=3D"font-size:10.5pt;font=
-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><br>
&nbsp;<o:p></o:p></span></p>
</div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<pre><span lang=3D"EN-US">address translation technologies which make refer=
ral more difficult.&nbsp; I note<br>that RFC 5887 included some of these is=
sues.&nbsp; If the intent is to reference<br>those from RFC 5887, I note th=
at&nbsp; the document currently says that it <br><br><o:p></o:p></span></pr=
e>
<pre><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&quot;starts from existing work in [RFC5887],<o:p=
></o:p></span></pre>
<pre><span lang=3D"EN-US">[I-D.chown-v6ops-renumber-thinkabout] and [RFC419=
2].&quot; but the references<br>to these documents are informative.&nbsp; I=
f the document is meant to be an extension,<br>rather than a replacement, s=
uch that these documents must be read to get the full<o:p></o:p></span></pr=
e>
<pre><span lang=3D"EN-US">picture, than a normative reference may be better=
.<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span lang=3D"E=
N-US"><o:p></o:p></span></pre>
</div>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Bing] These documents are i=
mportant input for the gap analysis draft. They indeed have not a few cross=
ed content, but our intention on the gap draft was different, so it is neit=
her extension nor replacement.</span><span lang=3D"EN-US"><o:p></o:p></span=
></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">RFC5887&amp;draft-thinkabout=
 are more comprehensive analysis/guidelines on IPv6 renumbering issue; RFC4=
192 emphasizes on a &#8220;make before break&#8221; prefix switching operat=
ion.</span><span lang=3D"EN-US"><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">This gap draft &nbsp;address=
es the IPv6 enterprise scenarios described in RFC6879, and focusing on iden=
tifying what is missing to make renum more automatic and less error-prone.<=
/span><span lang=3D"EN-US"><o:p></o:p></span></pre>
<div>
<pre style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US"><o:p>&nbsp;</o:p><=
/span></pre>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Well, we don't have a category =
for &quot;informative, but really important context&quot;, so I leave it to=
 you to pick.&nbsp; I would personally likely choose normative to highlight=
 their importance.<br>
<br>
<span style=3D"color:#1F497D"><o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Bing2] Ok=
, if normative could highlight the importance without implication of extens=
ion or replacement, then I think it is good. Thanks for the
 suggestion.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Best regar=
ds,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Bing<o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-=
family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp=
;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><br>
&nbsp;<o:p></o:p></span></p>
</div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<pre style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US">For the session su=
rvivability section, a reference to RFC 6724 may be useful, so <br>that tho=
se adding new global addresses understand how the application API to determ=
ine<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">which address is used with interact with the addi=
tion of new addresses (if there<br>is a specific draft or other treatment o=
f that topic, that would be even better,<br>but I am not personally aware o=
f one).<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span lang=3D"E=
N-US"><o:p></o:p></span></pre>
</div>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Bing] OK. Address selection=
 is indeed important. </span><span lang=3D"EN-US"><o:p></o:p></span></pre>
<div>
<pre style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US"><br><br>In section=
 6, the document currently says:<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US"><br>&nbsp;&nbsp; When nodes in a site have been r=
enumbered, then all the entries in<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; the site which contain the nodes' ad=
dresses must be updated. The<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; entries mainly include DNS records a=
nd filters in various entities<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp; such as ACLs in firewalls/gateways.<=
br><br>This appears to imply that these updates must take place after the r=
enumbering<br>event, but this is variable.&nbsp; ACLs and filters may well =
be updated in advance;<br><br><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">DNS may be updated concurrently or post facto.&nb=
sp; A rewording to highlight that <o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">this is variable by record type may be useful.<o:=
p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span lang=3D"E=
N-US"><o:p></o:p></span></pre>
</div>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Bing] Ok, thanks.</span><sp=
an lang=3D"EN-US"><o:p></o:p></span></pre>
<div>
<pre><span lang=3D"EN-US"><br><br>Section 9.2, in the bullet entitled &quot=
;DNS data structure optimization&quot;<br><br><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">The discusses a DNS feature proposed but declared=
 historic. I don't think it<o:p></o:p></span></pre>
</div>
<div>
<pre style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US">identifies the rel=
ated renumbering gap in a way that is useful for a naive <br>reader.&nbsp; =
If it cannot be reworded to focus on the gap, I suggest it be<br>removed.<o=
:p></o:p></span></pre>
</div>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Bing] When we wrote the dra=
ft, we considered if the IPv6 DNS record could be structured as separating =
prefix and suffix, that would be very helpful for renumbering. Because in I=
Pv6, most of the time we just change the prefixes rather than the whole add=
resses.</span><span lang=3D"EN-US"><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">We found A6 has the similar =
feature, but it has been moved to historic. However, &nbsp;the idea of sepa=
rating prefix and suffix is still considered valuable, but there might not =
&nbsp;be able to develop a new DNS record in a short time, so we name the i=
dea as &#8220;DNS data structure optimization&#8221; and put it into &#8220=
;gaps considered unsolvable&#8221;.</span><span lang=3D"EN-US"><o:p></o:p><=
/span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">We can add some minor texts =
to explain the intention.</span><span lang=3D"EN-US"><o:p></o:p></span></pr=
e>
<div>
<pre><span lang=3D"EN-US"><o:p>&nbsp;</o:p></span></pre>
</div>
</div>
</div>
</div>
</blockquote>
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Thanks.&nbsp; I do think it sho=
uld be clear that you are not attempting to resurrect the A6 vs. AAAA argum=
ent.<br>
&nbsp;<o:p></o:p></span></p>
</div>
<blockquote style=3D"border:none;border-left:solid #CCCCCC 1.0pt;padding:0c=
m 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt">
<div>
<pre><span lang=3D"EN-US">In section 9.4, the document says:<br><br>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; For application layer, as [RFC5887] said, in genera=
l, we can<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; assert that any im=
plementation is at risk from renumbering if it<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; does not check tha=
t an address is valid each time it opens a new<o:p></o:p></span></pre>
<pre><span lang=3D"EN-US">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; communications ses=
sion.<br><br>This might be reworded to&nbsp; include or focus on session re=
sumption, rather than <br>new communications sessions.&nbsp; From an applic=
ations perspective, the laptop<br><br><o:p></o:p></span></pre>
<pre style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US">&quot;sleep&quot; =
function seems to be one of the bigger risks of this.&nbsp; <o:p></o:p></sp=
an></pre>
</div>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Bing] Ok, thanks.</span><sp=
an lang=3D"EN-US"><o:p></o:p></span></pre>
<div>
<pre><span lang=3D"EN-US"><br>Nit:<br><br>For me personally, section 6.1 se=
emed needlessly pessimistic. <o:p></o:p></span></pre>
</div>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">[Bing] It is sad but true. A=
nd we are curious about how much operational issues there to prevent DDNS w=
idely deployed in real networks.</span><span lang=3D"EN-US"><o:p></o:p></sp=
an></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">If possible, we might consid=
er to make a dedicated draft to talk about this issue in the future. </span=
><span lang=3D"EN-US"><o:p></o:p></span></pre>
<pre><span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:&quot;Calib=
ri&quot;,&quot;sans-serif&quot;;color:#1F497D">&nbsp;</span><span lang=3D"E=
N-US"><o:p></o:p></span></pre>
</div>
</div>
</div>
</blockquote>
</div>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Thanks for your quick reply,<br=
>
<br>
Ted Hardie<o:p></o:p></span></p>
</div>
</div>
</body>
</html>

--_000_8AE0F17B87264D4CAC7DE0AA6C406F453D6FC22Bnkgeml506mbxchi_--

From brian.e.carpenter@gmail.com  Tue Apr 16 08:32:04 2013
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6CE21F9756 for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 08:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.766
X-Spam-Level: 
X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waMZzsVDRhfp for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 08:32:03 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3513E21F9721 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 08:32:03 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id hj19so597556wib.14 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 08:32:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kdRDtfAeKHOuEVYb0XD5Z0VJ7Uda9Yn7Xp4q8bbF1DU=; b=do/PlZYxx98545OiH/tIsd6qu8xwFCa0pDP2FIwnUjsP9OErt6pvbBL6mX+4CtCjHf 3vAdp0lF7jyM9lz6UgsA0ua8d6OzBKn9QZMPlb3zWngOEwFc6e8SzVyG4G8czRuF2GT5 YnAkXzfm6jFIlT3WI+rHI9IuoecurfzFstRi9eUabrZZPkBZFKn1InRej8o5a541ez4m AlectIStk+ZW/hsnm3+FfDoLByeOzAtJxzbiBTs6bwbxTMNhQ4Cf3D7Moj2WsHGVesaR RRxr57fwBT2a6uli/F16Bu2r8lAQBBzSHXu0gPsmAC26eLsMgIfn+0gtgsvktSyZo8PF rNGA==
X-Received: by 10.194.143.50 with SMTP id sb18mr4824684wjb.44.1366126322319; Tue, 16 Apr 2013 08:32:02 -0700 (PDT)
Received: from [10.3.2.18] (a2.norwich.yourspac.nsdsl.net. [94.229.131.97]) by mx.google.com with ESMTPS id fp2sm20100506wib.7.2013.04.16.08.31.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Apr 2013 08:32:00 -0700 (PDT)
Message-ID: <516D6EF1.90001@gmail.com>
Date: Tue, 16 Apr 2013 16:32:01 +0100
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ted Hardie <ted.ietf@gmail.com>
References: <CA+9kkMDEc1mX77eRYMXPBKnH9X+jOXGVD7pVFArkwSwNsF+wMA@mail.gmail.com>	<8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEE@nkgeml506-mbx.china.huawei.com>	<CA+9kkMA7+_m5s-iEo24H9jrGt9Osn32iMBDSSEyL7FNyeDT5+g@mail.gmail.com>	<8AE0F17B87264D4CAC7DE0AA6C406F453D6FC22B@nkgeml506-mbx.china.huawei.com>	<516CF39D.7020306@gmail.com>	<CAC4RtVB_BN3oYwpWBW6pGHXK_OvbP2588AnpxEU_L+RV5jE9ng@mail.gmail.com>	<516D4583.7020707@gmail.com> <CA+9kkMA2FDH3DSLED33uS5R0VSxyUok96OEU9=LtODu+nYRv3A@mail.gmail.com>
In-Reply-To: <CA+9kkMA2FDH3DSLED33uS5R0VSxyUok96OEU9=LtODu+nYRv3A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Barry Leiba <barryleiba@computer.org>, "Liubing \(Leo\)" <leo.liubing@huawei.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "draft-ietf-6renum-gap-analysis.all@tools.ietf.org" <draft-ietf-6renum-gap-analysis.all@tools.ietf.org>
Subject: Re: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 15:32:04 -0000

Ted,

On 16/04/2013 16:06, Ted Hardie wrote:
> On Tue, Apr 16, 2013 at 5:35 AM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
> 
>> Yes, I am aware of that, and it's a matter of judgement, but
>> since this draft is not in any sense a protocol specification
>> or a pseudo-BCP, I am not sure why it needs *any* normative
>> references, let alone downrefs. There is certainly no
>> process requirement for them.
>>
>>
> I certainly agree that there is no process requirement, but there is a
> potentially useful result.  When I see a document like this with 9
> normative references (as it has now), I get the sense that those are the
> ones which are needed context and that the informative ones are useful
> additional information.  That maps to "Essential reading" and "Useful
> additional information", which is pretty much the same mapping as
> "Normative" and "Informative" have in a protocol spec.  It's not *exactly*
> the same, I grant you, but it's an approximation.  My question about the
> three listed as "starts from" might have been better phrased as:  are these
> "Essential Reading" or "Useful additional information"?

IMHO, the RFCs are necessary reading for a complete understanding.
The I-D is far too expired for that, although there has been some
discussion of reviving its contents.

Of course, as an author I will follow whatever the WG chairs and AD
decide is the consensus - it's just that doing a second downref Last Call
for this document seems a bit OTT.

    Brian
> 
> regards,
> 
> Ted Hardie
> 
> 
>>    Brian
>>
>>> Barry
>>>
>>> On Tuesday, April 16, 2013, Brian E Carpenter wrote:
>>>
>>>>>>> "starts from existing work in [RFC5887],
>>>>>>> [I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]." but the
>>>> references
>>>>>>> to these documents are informative.  If the document is meant to be
>> an
>>>> extension,
>>>>>>> rather than a replacement, such that these documents must be read to
>>>> get the full
>>>>>>> picture, than a normative reference may be better.
>>>>>> Well, we don't have a category for "informative, but really important
>>>> context", so I leave it to you to pick.  I would personally likely
>> choose
>>>> normative to highlight their importance.
>>>>> [Bing2] Ok, if normative could highlight the importance without
>>>> implication of extension or replacement, then I think it is good. Thanks
>>>> for the suggestion.
>>>>
>>>> RFC 5887 and 4192 are Informational so cannot be normative, and the
>> draft
>>>> is long-expired so cannot be normative.
>>>>
>>>> Regards
>>>>    Brian
>>>> _______________________________________________
>>>> apps-discuss mailing list
>>>> apps-discuss@ietf.org <javascript:;>
>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
> 

From dhc@dcrocker.net  Tue Apr 16 08:37:12 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA2921F9784 for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 08:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxvVUw21l6AF for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 08:37:11 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 79A1721F9776 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 08:37:11 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3GFbAZY031568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Apr 2013 08:37:11 -0700
Message-ID: <516D7026.6040409@dcrocker.net>
Date: Tue, 16 Apr 2013 08:37:10 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Scott Kitterman <scott@kitterman.com>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <8990489.xAljaCmULD@scott-latitude-e6320> <516CC734.6050303@dcrocker.net> <15015065.dv5A4A6JuL@scott-latitude-e6320>
In-Reply-To: <15015065.dv5A4A6JuL@scott-latitude-e6320>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 16 Apr 2013 08:37:11 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 15:37:12 -0000

On 4/15/2013 8:58 PM, Scott Kitterman wrote:
> On Monday, April 15, 2013 08:36:20 PM Dave Crocker wrote:
>> That's the same as saying that when one starts a negotiation, one is
>> obligated to make a contract.
...
> In this case it's more like announcing a lockout when the initial offer from
> management isn't accepted without modification by the union rather than
> determining a meeting of the minds cannot be achieved after good faith
> negotiations.
>
> 1.  How about this?
> 2.  Not quite, here are some alternatives we could discuss.
> 1.  I quit.
>
> that's hardly a negotiation.


1. The exchange was more elaborate than that, including clarification 
for the reasons of the charter draft(s) that have been offered.  In 
addition, please note that the counter-proposal has not justified its 
position and, in fact, has been offered with complete rigidity, up to 
today, and hasn't responded to the concerns raised with it.

2. The lockout imagine is striking and entirely inapplicable, since 
there is no pre-existing relationship, nevermind an employer/employee one.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From barryleiba.mailing.lists@gmail.com  Tue Apr 16 12:07:26 2013
Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DD221F976A for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 12:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.851
X-Spam-Level: 
X-Spam-Status: No, score=-102.851 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm3wpFEvDlDs for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 12:07:25 -0700 (PDT)
Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32BE721F9771 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 12:07:25 -0700 (PDT)
Received: by mail-ve0-f172.google.com with SMTP id db10so753595veb.17 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 12:07:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0HzfbEpEt+4SfO0vwMUG/gGYn2sODDGaOyoHa6y7AVs=; b=XtUzsS6nao4Jgkdo1Znv7BecjLeqW2yDdT8HAqxMm4QeOOdpe5xypgxrnmJGZ9/swW r2V0UBs0rkdVPKp6dbO/U45nXFJNEpXxfbqsxFcajkx82xfCtOR0/EIDGRcNjhatIcSV QEQnzFu8VCrN4lXirdyONTnvT1/q2crgcWaImt/3ZfXo5b4v0BUnOtFfpkUZiBpT5QCV SQZJDSmL8PHyiNvmaZVgXposWo2U3kQoBxSpm9+olgDmbt3zhQTwJ50KrQ7Qs4yJPLtX jhCCz316buoaW0+XFVJEEuTOT4S9n4cki1D8XGnKhxJreHGJ54LXVbBdeH39mcPMGW1H PXyA==
MIME-Version: 1.0
X-Received: by 10.220.99.75 with SMTP id t11mr2514730vcn.72.1366139244545; Tue, 16 Apr 2013 12:07:24 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Tue, 16 Apr 2013 12:07:24 -0700 (PDT)
In-Reply-To: <516D6EF1.90001@gmail.com>
References: <CA+9kkMDEc1mX77eRYMXPBKnH9X+jOXGVD7pVFArkwSwNsF+wMA@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEE@nkgeml506-mbx.china.huawei.com> <CA+9kkMA7+_m5s-iEo24H9jrGt9Osn32iMBDSSEyL7FNyeDT5+g@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6FC22B@nkgeml506-mbx.china.huawei.com> <516CF39D.7020306@gmail.com> <CAC4RtVB_BN3oYwpWBW6pGHXK_OvbP2588AnpxEU_L+RV5jE9ng@mail.gmail.com> <516D4583.7020707@gmail.com> <CA+9kkMA2FDH3DSLED33uS5R0VSxyUok96OEU9=LtODu+nYRv3A@mail.gmail.com> <516D6EF1.90001@gmail.com>
Date: Tue, 16 Apr 2013 15:07:24 -0400
X-Google-Sender-Auth: b-6jLh0m-XbQ7F5kk4Euwn5Asi4
Message-ID: <CAC4RtVB3x3A3oPWwHjdqX1MscxPHmDnC0fyFutra1wGQkmLtCQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary=089e015373f4628be404da7f1412
Cc: "draft-ietf-6renum-gap-analysis.all@tools.ietf.org" <draft-ietf-6renum-gap-analysis.all@tools.ietf.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "Liubing \(Leo\)" <leo.liubing@huawei.com>
Subject: Re: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 19:07:26 -0000

--089e015373f4628be404da7f1412
Content-Type: text/plain; charset=ISO-8859-1

> it's just that doing a second downref Last Call for this document seems a
bit OTT.

Actually, as this doc is itself Informational, there are no downrefs.  We
can change any reference to normative, with no need for a second last call.
 That would only be needed if this doc were Standards Track or BCP.

Barry

On Tuesday, April 16, 2013, Brian E Carpenter wrote:

> Ted,
>
> On 16/04/2013 16:06, Ted Hardie wrote:
> > On Tue, Apr 16, 2013 at 5:35 AM, Brian E Carpenter <
> > brian.e.carpenter@gmail.com <javascript:;>> wrote:
> >
> >> Yes, I am aware of that, and it's a matter of judgement, but
> >> since this draft is not in any sense a protocol specification
> >> or a pseudo-BCP, I am not sure why it needs *any* normative
> >> references, let alone downrefs. There is certainly no
> >> process requirement for them.
> >>
> >>
> > I certainly agree that there is no process requirement, but there is a
> > potentially useful result.  When I see a document like this with 9
> > normative references (as it has now), I get the sense that those are the
> > ones which are needed context and that the informative ones are useful
> > additional information.  That maps to "Essential reading" and "Useful
> > additional information", which is pretty much the same mapping as
> > "Normative" and "Informative" have in a protocol spec.  It's not
> *exactly*
> > the same, I grant you, but it's an approximation.  My question about the
> > three listed as "starts from" might have been better phrased as:  are
> these
> > "Essential Reading" or "Useful additional information"?
>
> IMHO, the RFCs are necessary reading for a complete understanding.
> The I-D is far too expired for that, although there has been some
> discussion of reviving its contents.
>
> Of course, as an author I will follow whatever the WG chairs and AD
> decide is the consensus - it's just that doing a second downref Last Call
> for this document seems a bit OTT.
>
>     Brian
> >
> > regards,
> >
> > Ted Hardie
> >
> >
> >>    Brian
> >>
> >>> Barry
> >>>
> >>> On Tuesday, April 16, 2013, Brian E Carpenter wrote:
> >>>
> >>>>>>> "starts from existing work in [RFC5887],
> >>>>>>> [I-D.chown-v6ops-renumber-thinkabout] and [RFC4192]." but the
> >>>> references
> >>>>>>> to these documents are informative.  If the document is meant to be
> >> an
> >>>> extension,
> >>>>>>> rather than a replacement, such that these documents must be read
> to
> >>>> get the full
> >>>>>>> picture, than a normative reference may be better.
> >>>>>> Well, we don't have a category for "informative, but really
> important
> >>>> context", so I leave it to you to pick.  I would personally likely
> >> choose
> >>>> normative to highlight their importance.
> >>>>> [Bing2] Ok, if normative could highlight the importance without
> >>>> implication of extension or replacement, then I think it is good.
> Thanks
> >>>> for the suggestion.
> >>>>
> >>>> RFC 5887 and 4192 are Informational so cannot be normative, and the
> >> draft
> >>>> is long-expired so cannot be normative.
> >>>>
> >>>> Regards
> >>>>    Brian
> >>>> _______________________________________________
> >>>> apps-discuss mailing list
> >>>> apps-discuss@ietf.org <javascript:;> <javascript:;>
> >>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>>>
> >> _______________________________________________
> >> apps-discuss mailing list
> >> apps-discuss@ietf.org <javascript:;>
> >> https://www.ietf.org/mailman/listinfo/apps-discuss
> >>
> >
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org <javascript:;>
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--089e015373f4628be404da7f1412
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<font><span style=3D"line-height:normal;background-color:rgba(255,255,255,0=
)">&gt; it&#39;s just that doing a second downref Last Call=A0for this docu=
ment seems a bit OTT.</span></font><div><font><span style=3D"line-height:no=
rmal"><br>
</span></font></div><div><font><span style=3D"line-height:normal">Actually,=
 as this doc is itself Informational, there are no downrefs. =A0We can chan=
ge any reference to normative, with no need for a second last call. =A0That=
 would only be needed if this doc were Standards Track or BCP.</span></font=
></div>
<div><font><span style=3D"line-height:normal"><br></span></font></div><div>=
<font><span style=3D"line-height:normal">Barry<span></span><br></span></fon=
t><br>On Tuesday, April 16, 2013, Brian E Carpenter  wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
Ted,<br>
<br>
On 16/04/2013 16:06, Ted Hardie wrote:<br>
&gt; On Tue, Apr 16, 2013 at 5:35 AM, Brian E Carpenter &lt;<br>
&gt; <a href=3D"javascript:;" onclick=3D"_e(event, &#39;cvml&#39;, &#39;bri=
an.e.carpenter@gmail.com&#39;)">brian.e.carpenter@gmail.com</a>&gt; wrote:<=
br>
&gt;<br>
&gt;&gt; Yes, I am aware of that, and it&#39;s a matter of judgement, but<b=
r>
&gt;&gt; since this draft is not in any sense a protocol specification<br>
&gt;&gt; or a pseudo-BCP, I am not sure why it needs *any* normative<br>
&gt;&gt; references, let alone downrefs. There is certainly no<br>
&gt;&gt; process requirement for them.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt; I certainly agree that there is no process requirement, but there is a=
<br>
&gt; potentially useful result. =A0When I see a document like this with 9<b=
r>
&gt; normative references (as it has now), I get the sense that those are t=
he<br>
&gt; ones which are needed context and that the informative ones are useful=
<br>
&gt; additional information. =A0That maps to &quot;Essential reading&quot; =
and &quot;Useful<br>
&gt; additional information&quot;, which is pretty much the same mapping as=
<br>
&gt; &quot;Normative&quot; and &quot;Informative&quot; have in a protocol s=
pec. =A0It&#39;s not *exactly*<br>
&gt; the same, I grant you, but it&#39;s an approximation. =A0My question a=
bout the<br>
&gt; three listed as &quot;starts from&quot; might have been better phrased=
 as: =A0are these<br>
&gt; &quot;Essential Reading&quot; or &quot;Useful additional information&q=
uot;?<br>
<br>
IMHO, the RFCs are necessary reading for a complete understanding.<br>
The I-D is far too expired for that, although there has been some<br>
discussion of reviving its contents.<br>
<br>
Of course, as an author I will follow whatever the WG chairs and AD<br>
decide is the consensus - it&#39;s just that doing a second downref Last Ca=
ll<br>
for this document seems a bit OTT.<br>
<br>
=A0 =A0 Brian<br>
&gt;<br>
&gt; regards,<br>
&gt;<br>
&gt; Ted Hardie<br>
&gt;<br>
&gt;<br>
&gt;&gt; =A0 =A0Brian<br>
&gt;&gt;<br>
&gt;&gt;&gt; Barry<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Tuesday, April 16, 2013, Brian E Carpenter wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; &quot;starts from existing work in [RFC5887],<=
br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; [I-D.chown-v6ops-renumber-thinkabout] and [RFC=
4192].&quot; but the<br>
&gt;&gt;&gt;&gt; references<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; to these documents are informative. =A0If the =
document is meant to be<br>
&gt;&gt; an<br>
&gt;&gt;&gt;&gt; extension,<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; rather than a replacement, such that these doc=
uments must be read to<br>
&gt;&gt;&gt;&gt; get the full<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; picture, than a normative reference may be bet=
ter.<br>
&gt;&gt;&gt;&gt;&gt;&gt; Well, we don&#39;t have a category for &quot;infor=
mative, but really important<br>
&gt;&gt;&gt;&gt; context&quot;, so I leave it to you to pick. =A0I would pe=
rsonally likely<br>
&gt;&gt; choose<br>
&gt;&gt;&gt;&gt; normative to highlight their importance.<br>
&gt;&gt;&gt;&gt;&gt; [Bing2] Ok, if normative could highlight the importanc=
e without<br>
&gt;&gt;&gt;&gt; implication of extension or replacement, then I think it i=
s good. Thanks<br>
&gt;&gt;&gt;&gt; for the suggestion.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; RFC 5887 and 4192 are Informational so cannot be normative=
, and the<br>
&gt;&gt; draft<br>
&gt;&gt;&gt;&gt; is long-expired so cannot be normative.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Regards<br>
&gt;&gt;&gt;&gt; =A0 =A0Brian<br>
&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt; apps-discuss mailing list<br>
&gt;&gt;&gt;&gt; <a href=3D"javascript:;" onclick=3D"_e(event, &#39;cvml&#3=
9;, &#39;apps-discuss@ietf.org&#39;)">apps-discuss@ietf.org</a> &lt;javascr=
ipt:;&gt;<br>
&gt;&gt;&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/apps-disc=
uss" target=3D"_blank">https://www.ietf.org/mailman/listinfo/apps-discuss</=
a><br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; apps-discuss mailing list<br>
&gt;&gt; <a href=3D"javascript:;" onclick=3D"_e(event, &#39;cvml&#39;, &#39=
;apps-discuss@ietf.org&#39;)">apps-discuss@ietf.org</a><br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" tar=
get=3D"_blank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
&gt;&gt;<br>
&gt;<br>
_______________________________________________<br>
apps-discuss mailing list<br>
<a href=3D"javascript:;" onclick=3D"_e(event, &#39;cvml&#39;, &#39;apps-dis=
cuss@ietf.org&#39;)">apps-discuss@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
</blockquote></div>

--089e015373f4628be404da7f1412--

From sm@elandsys.com  Tue Apr 16 12:36:48 2013
Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414E021F9742; Tue, 16 Apr 2013 12:36:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGW04HhK5Bcn; Tue, 16 Apr 2013 12:36:47 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1CA21F973A; Tue, 16 Apr 2013 12:36:47 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.138.179]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3GJZRj7011253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Apr 2013 12:35:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366140941; bh=fOvrmS88agpU0TjUzxZppqFBXBBAWd9vbk5t+sMcmVA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=C0lrhNw1LOn+i1LJul7hUNp1FISbOw4InOyVgswgiqUPrZIgsEW34wg0K2ZbqNjiB I1Y92j0nUn/h8D+CCX7K37cZ9ov3pJekjiI8mhj3Y4DZ7rpAAvWFl9cYnjsvwxAjTl GStLZEnBPiYc3M4ztdnZjlH7A054ycI1qEsbn8s8=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366140941; i=@elandsys.com; bh=fOvrmS88agpU0TjUzxZppqFBXBBAWd9vbk5t+sMcmVA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=RZLmDHQ7P6r+/pEHNSzbtWh1oP/e1mT4xG81iLB41cVaaMwieROElX7IuEvGF+EFo XbL/ROBVjoLB1WYtJvdRPkCEbrwo7PK2bF8/W6mRUz2b2Xhffx8dwICr5Z/4VO7XZZ LwfQH5RDGV7K5T/U75yLr2ewEY0xDND1DZIVJIiw=
Message-Id: <6.2.5.6.2.20130416112752.0b46f6e0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 16 Apr 2013 12:28:38 -0700
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <516D6EF1.90001@gmail.com>
References: <CA+9kkMDEc1mX77eRYMXPBKnH9X+jOXGVD7pVFArkwSwNsF+wMA@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6EEAEE@nkgeml506-mbx.china.huawei.com> <CA+9kkMA7+_m5s-iEo24H9jrGt9Osn32iMBDSSEyL7FNyeDT5+g@mail.gmail.com> <8AE0F17B87264D4CAC7DE0AA6C406F453D6FC22B@nkgeml506-mbx.china.huawei.com> <516CF39D.7020306@gmail.com> <CAC4RtVB_BN3oYwpWBW6pGHXK_OvbP2588AnpxEU_L+RV5jE9ng@mail.gmail.com> <516D4583.7020707@gmail.com> <CA+9kkMA2FDH3DSLED33uS5R0VSxyUok96OEU9=LtODu+nYRv3A@mail.gmail.com> <516D6EF1.90001@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: draft-ietf-6renum-gap-analysis.all@tools.ietf.org, apps-discuss@ietf.org, "Liubing \(Leo\)" <leo.liubing@huawei.com>, renum@ietf.org
Subject: Re: [apps-discuss] Review of draft-ietf-6renum-gap-analysis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Apr 2013 19:36:48 -0000

Hi Brian,
At 08:32 16-04-2013, Brian E Carpenter wrote:
>Of course, as an author I will follow whatever the WG chairs and AD
>decide is the consensus - it's just that doing a second downref Last Call
>for this document seems a bit OTT.

Agreed.

I agree with the comments posted by Ted Hardie at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09296.html

RFC 2874 is a normative reference which is only mentioned in Section 
9.2.  The status of that RFC is Historic.

RFC 2894 is a normative reference.  It is referenced in Section 3.1 
(relevant protocols and mechanisms).  It is mentioned that the 
protocol is not widely used.  Should I read that RFC before reading 
draft-ietf-6renum-gap-analysis-05?

RFC 3971 is a normative reference in 
draft-ietf-6renum-gap-analysis-05.  It is only referenced in the 
Security Considerations section.

RFC 3956 is listed both as an informative and a normative reference.

Section 1 mentions that:

   "This document does further analysis and identifies the valuable and
    solvable issues, digs out of some undiscovered gaps, and gives some
    solution suggestions."

Should I read RFC 5887, I-D.chown-v6ops-renumber-thinkabout and RFC 
4192 before reading draft-ietf-6renum-gap-analysis-05?

Regards,
S. Moonesamy  


From scott@kitterman.com  Tue Apr 16 18:20:27 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1736E21F9636 for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 18:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N98ZsBmmKoyr for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 18:20:25 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 936C821F9380 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 18:20:25 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 00A3720E40DB; Tue, 16 Apr 2013 21:20:24 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366161624; bh=N3oDTMyy3XxWS6sXb/vYCf5L0rkJDVrp6iPQvEit14s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=F7MxLFywTFVv6PfBoVunvOpGr5zDqsWKU5XfOHtEHSEDhLCksvg3jOW6OSzMrj9ue RFl5fxkm/VSqh5M/1DW3L/SO+dtEmTUOJ/nvhnDNZZJJERPaUbb7Q3sUoz40kPBPv6 pxLr0zXGhG6r+MKckyKUSg0LlVwO66lwD4A+/hyU=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DE90F20E40C6;  Tue, 16 Apr 2013 21:20:23 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Tue, 16 Apr 2013 21:20:23 -0400
Message-ID: <1492962.W7Nvur4DRk@scott-latitude-e6320>
User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; )
In-Reply-To: <516D6CE6.4070509@gmail.com>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <15015065.dv5A4A6JuL@scott-latitude-e6320> <516D6CE6.4070509@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2013 01:20:27 -0000

On Tuesday, April 16, 2013 09:23:18 AM J. Trent Adams wrote:
> On 4/15/13 9:58 PM, Scott Kitterman wrote:
> > On Monday, April 15, 2013 08:36:20 PM Dave Crocker wrote:
> >> On 4/15/2013 6:35 PM, Scott Kitterman wrote:
> >>> I think that if a draft is submitted as a candidate working group work
> >>> item
> >>> and the sponsors don't like the result of the chartering discussion and
> >>> that draft is suddenly an independent submission, that's pretty well, by
> >>> definition, an end around the working group process.
> >> 
> >> That's the same as saying that when one starts a negotiation, one is
> >> obligated to make a contract.
> >> 
> >> The initial chartering process is a negotiation between those bringing
> >> the work into the IETF and the IETF community.  Either side is free to
> >> agree or disagree with whatever terms they wish.
> >> 
> >> And free to walk away when there is not a sufficient meeting of the
> >> minds doing the negotiating.
> >> 
> >> The IETF does not have a 'right' to the work that is brought to it.
> >> 
> >> The ISE mechanism is for stuff that is relevant to the community, but
> >> isn't going through IETF or IRTF processing.  As a body of documents,
> >> the RFC series is larger than the IETF.
> >> 
> >> 
> >> Work that is brought to the IETF has different levels of completeness
> >> and maturity, and different timings for having achieved those levels.
> >> 
> >> When the IETF charters a group and includes existing material, the
> >> 
> >> charter can cast the role of that material in very different ways:
> >>       It can treat it as nor more than a set of ideas, to be used or
> >> 
> >> ignored;
> >> 
> >>       It can treat it as a basic design, with all of the actual details
> >> 
> >> still fluid;
> >> 
> >>       It can treat it as a rough draft, to be massively revised;
> >>       
> >>       It can treat it as a solid specification that merely needs review,
> >> 
> >> refinement and maybe enhancement;
> >> 
> >>       It can treat it as a deployed technology that should try to
> >> 
> >> protect its installed base, but will tolerate some disruption;
> >> 
> >>       It can treat it as a deployed technology that /must/ protect its
> >> 
> >> installed base and must ensure that core interoperability is retained
> >> with that installed base.
> >> 
> >> 
> >> No doubt there are some other variations I've missed, but I hope this is
> >> enough to make clear that the choice of language in a working group
> >> charter, to constrain or not constrain the working group can make an
> >> enormous difference.
> >> 
> >> Equally, those bringing technology to the IETF do so at different points
> >> in the maturity of their work.  Any of the above might make sense,
> >> depending upon that maturity, the extent of deployment, and the timing
> >> of the investment made by the installed base.
> >> 
> >> When technology is brand new, with at most some prototypes done as
> >> proofs of concept, then significant changes to the spec won't
> >> necessarily add much to the development cost.  On the other extreme, a
> >> mature, deployed market can be almost cavalier about the freedom of a
> >> working group charter, because a working group that gets silly can be
> >> ignored: that is, the installed base is sufficiently well-established
> >> and unified in what it will accept, so that it's leverage is clear.
> >> 
> >> However, immediately after the development investment is made -- and
> >> especially when there has been considerable initial deployment, but
> >> still room for quite a bit more -- the installed and potential base will
> >> not take kindly to disruptive standards work; in fact such work can
> >> seriously damage adoption.
> >> 
> >> DKIM had almost no deployed base.  Jabber had quite a bit of deployed
> >> and mature base.
> >> 
> >> DMARC has a very large, newly-deployed base that just made the
> >> investment.  Making any changes that render the base not fully
> >> interoperable will a) piss of the folk who just made the investment, and
> >> b) possibly sour the folk considering deployment.  It typically at least
> >> causes the potential adopters to delay, sometime for years.
> >> 
> >> The charter that was originally submitted was tuned to the reality of
> >> DMARC's maturity and deployment.  Since that caused so much heartache to
> >> a few folk, the new draft charter removes the base spec from the current
> >> equation.  When deployment settles down and initial investment costs
> >> have been recovered, it will make sense to review the status of the base
> >> specification.
> >> 
> >> 
> >> d/
> >> 
> >> ps.  I'm merely speaking for myself, of course, and not on behalf of the
> >> DMARC consortium.
> > 
> > In this case it's more like announcing a lockout when the initial offer
> > from management isn't accepted without modification by the union rather
> > than determining a meeting of the minds cannot be achieved after good
> > faith negotiations.
> > 
> > 1.  How about this?
> > 2.  Not quite, here are some alternatives we could discuss.
> > 1.  I quit.
> > 
> > that's hardly a negotiation.
> > 
> > Your argument against a working group is that it will be hard to get
> > people
> > who have adopted DMARC already to implement interoperability improvements
> > because they just implemented it.  Are you suggesting that it will be
> > easier, later, when there is more deployment and the current pattern is
> > better established?
> 
> Yes, in this case it's likely that will occur. I can't speak to
> everyone's development pipeline, of course, but in my experience
> moderate to large enterprises require months and years of planning. The
> most reasonable architects I've known include upgrade paths during
> initial planning which address exactly what I think you're describing.
> They'll be planning their solution based on current knowledge (ie the
> existing spec) with a mind toward something like a two-year upgrade to
> whatever the extensions (or possible revision) may be.
> 
> Another way to look at it is that since there's real value seen in
> deployment today, there's a counter-incentive to wait an indeterminate
> time for a possible revision. Each day that passes is another day that
> customers are being phished... and, sadly, each phishing attack is yet
> another opportunity for a cascading set of casualties (think: spear
> phishing a whale).
> 
> I'm pretty sure we all agree that perfection can be the enemy of the
> good. Getting a stable, useful, though possibly sub-perfect, solution
> running is a reasonable path toward iterative improvement. Yes, it'll
> take time to correct the ship under full sail, but it's possible (and
> likely).
> 
> I'm all for learning as we go. Let's buckle down, explore some of the
> key focus areas identified as possible (non-disruptive) extensions for
> now and see how they play. Through that journey we will also learn what
> needs to be done to improve the base and be the stronger for it.
> 
> Hoping for a brighter future,
> Trent

If what you have now on dmarc.org addresses the current need, why involve the 
IETF at all?  It seems to me that having any DMARC working group at all would 
have the kind of chilling effect you're concerned about.  I doubt that many 
outsiders would have their concerns assuaged by tight charter language.

Scott K

From scott@kitterman.com  Tue Apr 16 18:23:14 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4971A21F9627 for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 18:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgAguqLd2mfu for <apps-discuss@ietfa.amsl.com>; Tue, 16 Apr 2013 18:23:13 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4F321F95F3 for <apps-discuss@ietf.org>; Tue, 16 Apr 2013 18:23:13 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0680020E40DB; Tue, 16 Apr 2013 21:23:13 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366161793; bh=gGnMV7727/0XAnntMsQDqnRUK+0jwa9z2xS10vtulfM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=P8JocE12i46uaNgav6Y6m/TdSYl6IIICAbVWIKHPy/KIGIaLVY09s7+mUc+ZJpCN+ mLq3RsOS/NsVuQUhPGwnmAQ5dLWU/qjkUdlrBUXyEG9K1Vb1rt6B17iZSeySaWRgp2 c5+hM036O8+DbuGuM6TObJZ+w/pi0PQADEG9Zg/o=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DDBD520E40C6;  Tue, 16 Apr 2013 21:23:12 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Tue, 16 Apr 2013 21:23:12 -0400
Message-ID: <29070418.Ips48RWf4b@scott-latitude-e6320>
User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; )
In-Reply-To: <516D7026.6040409@dcrocker.net>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <15015065.dv5A4A6JuL@scott-latitude-e6320> <516D7026.6040409@dcrocker.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2013 01:23:14 -0000

On Tuesday, April 16, 2013 08:37:10 AM Dave Crocker wrote:
> On 4/15/2013 8:58 PM, Scott Kitterman wrote:
> > On Monday, April 15, 2013 08:36:20 PM Dave Crocker wrote:
> >> That's the same as saying that when one starts a negotiation, one is
> >> obligated to make a contract.
> 
> ...
> 
> > In this case it's more like announcing a lockout when the initial offer
> > from management isn't accepted without modification by the union rather
> > than determining a meeting of the minds cannot be achieved after good
> > faith negotiations.
> > 
> > 1.  How about this?
> > 2.  Not quite, here are some alternatives we could discuss.
> > 1.  I quit.
> > 
> > that's hardly a negotiation.
> 
> 1. The exchange was more elaborate than that, including clarification
> for the reasons of the charter draft(s) that have been offered.  In
> addition, please note that the counter-proposal has not justified its
> position and, in fact, has been offered with complete rigidity, up to
> today, and hasn't responded to the concerns raised with it.
> 
> 2. The lockout imagine is striking and entirely inapplicable, since
> there is no pre-existing relationship, nevermind an employer/employee one.
> 
Right.  It's an analogy and like all analogy is imperfect.  The part that's 
relevant is claiming a meeting of the minds is impossible without any serious 
effort to try (that's my assessment of the public discussion on the topic).

Also imperfect, but perhaps less orthogonal might be the analogy of the kid 
that shows up at the playground with a cool new toy and stomps off and goes 
home when the other kids won't play with the toy precisely according to his 
rules.

Scott K

From internet-drafts@ietf.org  Tue Apr 16 19:54:06 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4873C21F95E0; Tue, 16 Apr 2013 19:54:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.525
X-Spam-Level: 
X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTkIE--Ls8I5; Tue, 16 Apr 2013 19:54:05 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFD421F972A; Tue, 16 Apr 2013 19:54:05 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.43.p4
Message-ID: <20130417025405.14655.77004.idtracker@ietfa.amsl.com>
Date: Tue, 16 Apr 2013 19:54:05 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-13.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2013 02:54:06 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Applications Area Working Group Working G=
roup of the IETF.

	Title           : WebFinger
	Author(s)       : Paul E. Jones
                          Gonzalo Salgueiro
                          Joseph Smarr
	Filename        : draft-ietf-appsawg-webfinger-13.txt
	Pages           : 23
	Date            : 2013-04-16

Abstract:
   This specification defines the WebFinger protocol, which can be used
   to discover information about people or other entities on the
   Internet using standard HTTP methods.  WebFinger discovers
   information for a URI that might not be usable as a locator
   otherwise, such as account or email URIs.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-13

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-webfinger-13


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From markus.lanthaler@gmx.net  Wed Apr 17 04:41:03 2013
Return-Path: <markus.lanthaler@gmx.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969A421F8CE2 for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 04:41:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.85
X-Spam-Level: 
X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j5fSb9RmSoe for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 04:41:01 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6460021F8C23 for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 04:41:01 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LmxXe-1V2bUu1sWC-00h9Li for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 13:41:00 +0200
Received: (qmail invoked by alias); 17 Apr 2013 11:41:00 -0000
Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp002) with SMTP; 17 Apr 2013 13:41:00 +0200
X-Authenticated: #419883
X-Provags-ID: V01U2FsdGVkX1/X8sVPm7/X7qsOB6P7Aki5A0zVmAyeIMuPbxkCyw td1TFVPBAcaopc
From: "Markus Lanthaler" <markus.lanthaler@gmx.net>
To: <apps-discuss@ietf.org>
Date: Wed, 17 Apr 2013 13:40:52 +0200
Message-ID: <00da01ce3b60$6bc16a20$43443e60$@lanthaler@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: de
Thread-Index: Ac47XZd+DCCMadE4TpOkTlE8/Em3fwAAbUmg
X-Y-GMX-Trusted: 0
Subject: [apps-discuss] FW: New Version Notification for draft-lanthaler-profile-registry-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2013 11:41:03 -0000

Hi,

I've just uploaded a new version of my I-D which incorporates Dave =
Cridland's feedback. Thanks again!

Since this is my first I-D I'm not familiar with the processes yet. If =
my understanding of RFC2026 & RFC4846 is correct, the next step would be =
to send a publication request to the RFC editor. Or do I have to contact =
the Area Directors because the document requires IANA allocations?


Thanks,
Markus


--
Markus Lanthaler
@markuslanthaler




-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20
Sent: Wednesday, April 17, 2013 1:21 PM
To: mail@markus-lanthaler.com
Subject: New Version Notification for =
draft-lanthaler-profile-registry-01.txt


A new version of I-D, draft-lanthaler-profile-registry-01.txt
has been successfully submitted by Markus Lanthaler and posted to the
IETF repository.

Filename:	 draft-lanthaler-profile-registry
Revision:	 01
Title:		 The IETF Profile URI Registry
Creation date:	 2013-04-17
Group:		 Individual Submission
Number of pages: 6
URL:             =
http://www.ietf.org/internet-drafts/draft-lanthaler-profile-registry-01.t=
xt
Status:          =
http://datatracker.ietf.org/doc/draft-lanthaler-profile-registry
Htmlized:        =
http://tools.ietf.org/html/draft-lanthaler-profile-registry-01
Diff:            =
http://www.ietf.org/rfcdiff?url2=3Ddraft-lanthaler-profile-registry-01

Abstract:
   This document defines a registry for profile URIs and establishes an
   IETF URN Sub-namespace to be used in specifications standardizing
   profiles.

                                                                         =
        =20


The IETF Secretariat


From joe.gregorio@gmail.com  Wed Apr 17 07:03:21 2013
Return-Path: <joe.gregorio@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7915521F871C for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 07:03:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FralMmxXHYY4 for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 07:03:20 -0700 (PDT)
Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 504C521F8709 for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 07:03:20 -0700 (PDT)
Received: by mail-ia0-f179.google.com with SMTP id l25so1450982iad.24 for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 07:03:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Dd6JNtyqtXyY3orxVGsbkwOvx0URlBeGmFa1qN0I/Ms=; b=x7Nezzz8h8zW1EWKMvSdobSukH5FgwXuNd6sJzS0Ywazs5SVe6b8wCans39SI9QGLL LIPwoGcbwn6D96bBwHTgXEPjqdcOBTIY+wdn/E+kUxNeJ/fDbNiMeBXRUTuwXRj8kRLD DkSHxWN/zlJy7wGYYUP1j7c158pv82psTtTmg+AlsUY2bMIQbou+7isM8ElQWvVnGH6/ pTStA8RyUGXF67OCxpZ9n6gbrQ7uPWXGvI7/A/8c4/KCRs6WtyGv+zgbZrUCQGpZtgg3 o7MBC7g8MjTp57GoXgUmxAryaK8sqDU6Ux0iHjNFArqdCgB/xqUgICXMHX3AeJusarpE 7azA==
MIME-Version: 1.0
X-Received: by 10.43.8.200 with SMTP id ot8mr3658430icb.11.1366207399597; Wed, 17 Apr 2013 07:03:19 -0700 (PDT)
Sender: joe.gregorio@gmail.com
Received: by 10.64.53.136 with HTTP; Wed, 17 Apr 2013 07:03:19 -0700 (PDT)
In-Reply-To: <51625870.8000906@berkeley.edu>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu>
Date: Wed, 17 Apr 2013 10:03:19 -0400
X-Google-Sender-Auth: 3cpT4pqqw_jyyiqr6uHDi1YXsj4
Message-ID: <CA+-NybWfR47yScyTBi7BRpJgj5SnCxWY1rDV5KC8PuE+JEV90A@mail.gmail.com>
From: Joe Gregorio <joe@bitworking.org>
To: Erik Wilde <dret@berkeley.edu>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2013 14:03:21 -0000

Sorry for the delay in responding.

On Mon, Apr 8, 2013 at 1:41 AM, Erik Wilde <dret@berkeley.edu> wrote:
> hello francis.
>
>
> On 2013-04-07 13:38 , Francis Galiegue wrote:
>>
>> On Fri, Apr 5, 2013 at 8:39 PM, Francis Galiegue <fgaliegue@gmail.com>
>> wrote:
>>>
>>> Let us say that there is a variable called "list", whose value is an
>>> empty list:
>>> list = []
>>> Now let us have this template:
>>> X{.list}
>>> Should the expansion be "X" or "X."? And, more importantly, why?
>>
>> Any insights? I have read the spec by and large (RFC 6570) and still
>> cannot figure it out...
>
>
> https://github.com/dret/uritemplate-test/blob/master/spec-examples-by-section.json
> (line 234) says it's "X", but i am really interested in the "why"
> explanation as well. http://tools.ietf.org/html/rfc6570#section-3.2.5 says
> that

The answer is in the text you quote:

"for each defined variable in the variable-list, append '.' to the
result string and then perform variable expansion"

The set of variables in the variable list is the empty set, so no '.'
is appended.

I agree that if this is confusing an addendum is in order.

  -joe

>, and i cannot find any
> text saying that an empty list is considered to be undefined. i have read
> the spec recently and never looked at this particular case, but without
> looking at the test cases i would have said it has to be expanded to "X."
> and not "X".
>
> cheers,
>
> dret.
>
> --
> erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
>            | UC Berkeley  -  School of Information (ISchool) |
>            | http://dret.net/netdret http://twitter.com/dret |
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss



--
Joe Gregorio        http://bitworking.org

From fgaliegue@gmail.com  Wed Apr 17 07:31:16 2013
Return-Path: <fgaliegue@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D35721F8A11 for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 07:31:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agUMkw3jn3RA for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 07:31:15 -0700 (PDT)
Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 519A121F8A0C for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 07:31:15 -0700 (PDT)
Received: by mail-ee0-f42.google.com with SMTP id e49so86399eek.29 for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 07:31:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=elMzPReFzqd4L5CvLmJ43QjZNdVWFqcspUFvOIHYhY4=; b=idlX9ncZ+Sl2tt7N/1Evm116LZa+XzOSmodUgYRgDRUtZuqOfQAvTDJNNwZPMIWrfM zG480eYz65kC5d/1nl5W6qZbeF/ixmpFCkrvKdLVGiUmn9NDCegNCnNUWeGmQxlVBElg 8y30Ay0iEz0Jeqvpzq0m5DK2iR0W6lCtMrjelRBdOcy1YlxOoCq3GEOepfBv/FWiqd/3 IMTiEfSwZyfeDuh4LMDfBBj3cfZejub80ELo518rgpSulEK/lrFToIG/qW3fYyfGXCQv +9UEZ8nuAEL5LFOi2LfFuvfjgp8EQYa/YYXQUzhnLla2dBrCZL1Y7kPiLm7XpS/Kl4eG dDMQ==
MIME-Version: 1.0
X-Received: by 10.14.179.201 with SMTP id h49mr18758668eem.26.1366209074414; Wed, 17 Apr 2013 07:31:14 -0700 (PDT)
Received: by 10.14.213.4 with HTTP; Wed, 17 Apr 2013 07:31:14 -0700 (PDT)
In-Reply-To: <CA+-NybWfR47yScyTBi7BRpJgj5SnCxWY1rDV5KC8PuE+JEV90A@mail.gmail.com>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CA+-NybWfR47yScyTBi7BRpJgj5SnCxWY1rDV5KC8PuE+JEV90A@mail.gmail.com>
Date: Wed, 17 Apr 2013 16:31:14 +0200
Message-ID: <CALcybBD83_x9P0=tNy+4i91mgyYrDWpVHp++QtF06Ouc7sjZ8w@mail.gmail.com>
From: Francis Galiegue <fgaliegue@gmail.com>
To: Joe Gregorio <joe@bitworking.org>
Content-Type: text/plain; charset=UTF-8
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2013 14:31:16 -0000

On Wed, Apr 17, 2013 at 4:03 PM, Joe Gregorio <joe@bitworking.org> wrote:
[...]
>>
>>
>> https://github.com/dret/uritemplate-test/blob/master/spec-examples-by-section.json
>> (line 234) says it's "X", but i am really interested in the "why"
>> explanation as well. http://tools.ietf.org/html/rfc6570#section-3.2.5 says
>> that
>
> The answer is in the text you quote:
>
> "for each defined variable in the variable-list, append '.' to the
> result string and then perform variable expansion"
>
> The set of variables in the variable list is the empty set, so no '.'
> is appended.
>

Is it really the case? I don't see an empty list as an undefined variable.

Or it would mean that the first thing which needs to be done is expand
variable values (scalars, lists, associative arrays) before "grouping"
them.


--
Francis Galiegue, fgaliegue@gmail.com
JSON Schema in Java: http://json-schema-validator.herokuapp.com

From superuser@gmail.com  Wed Apr 17 07:41:30 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1F121F8E3C for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 07:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level: 
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFVkQaBj6hnJ for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 07:41:29 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id B7C1421F8E04 for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 07:41:23 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hq17so1624663wib.5 for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 07:41:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RFC1Sk4R7lTITXf5/8vkfaZCDKp+ffuwYCmjnQmQ+0I=; b=PCJRiydlGnC0DdEBL3Qj1B8FK0cYlEsjiBqyuRYOIIg7wBji+8fhPrRMmJYiu7WBT7 FsgEjXYvJT+2fFzjYYC90R/NP9f9959KMBBs/hr8f0zz6aKkXZOKvDfVEp1PPVzmwpQV yo7CkfVPD+fY7Ll+kO4cq9bM5U13nOarIZcdtebWa6nlCArjC9H6YxYS79SdPNhGz4hs LWig1wg90laXCvJI/Lzp5Bh8/M5rZDW8umZ2w7KQIA92x6ar5QJQvL1uWGDqAKOmEllU GAv+puX+WN4W1W9mRX9wFNCNHVwK2ShH/03vuWWIyu/DEaTvkMDidFfNOk+Gu2PSoj6n YKIg==
MIME-Version: 1.0
X-Received: by 10.180.37.73 with SMTP id w9mr6375438wij.32.1366209682943; Wed, 17 Apr 2013 07:41:22 -0700 (PDT)
Received: by 10.180.36.176 with HTTP; Wed, 17 Apr 2013 07:41:22 -0700 (PDT)
In-Reply-To: <516e8a54.45f7440a.7dcc.1253SMTPIN_ADDED_BROKEN@mx.google.com>
References: <516e8a54.45f7440a.7dcc.1253SMTPIN_ADDED_BROKEN@mx.google.com>
Date: Wed, 17 Apr 2013 07:41:22 -0700
Message-ID: <CAL0qLwb+9CYnOYw9kcMdzZvyPagcUrhxUkmOiMZNAXpzFe6MYA@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
Content-Type: multipart/alternative; boundary=e89a8f502ee8d73a5e04da8f7ade
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] FW: New Version Notification for draft-lanthaler-profile-registry-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2013 14:41:30 -0000

--e89a8f502ee8d73a5e04da8f7ade
Content-Type: text/plain; charset=ISO-8859-1

This document creates a registry, so I'm fairly certain it needs to go
through the IETF Stream, which means an Area Director has to sponsor it or
a working group has to adopt it.  On the other hand, although Independent
Submission stream drafts can't create registry entries when the registry
has certain constraints, I couldn't find anything constraining registry
creation.  Someone should check my math here.

You could ask this working group if it's interested in working on the
document for starters.

-MSK, APPSAWG co-chair


On Wed, Apr 17, 2013 at 4:40 AM, Markus Lanthaler
<markus.lanthaler@gmx.net>wrote:

> Hi,
>
> I've just uploaded a new version of my I-D which incorporates Dave
> Cridland's feedback. Thanks again!
>
> Since this is my first I-D I'm not familiar with the processes yet. If my
> understanding of RFC2026 & RFC4846 is correct, the next step would be to
> send a publication request to the RFC editor. Or do I have to contact the
> Area Directors because the document requires IANA allocations?
>
>
> Thanks,
> Markus
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
>
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Wednesday, April 17, 2013 1:21 PM
> To: mail@markus-lanthaler.com
> Subject: New Version Notification for
> draft-lanthaler-profile-registry-01.txt
>
>
> A new version of I-D, draft-lanthaler-profile-registry-01.txt
> has been successfully submitted by Markus Lanthaler and posted to the
> IETF repository.
>
> Filename:        draft-lanthaler-profile-registry
> Revision:        01
> Title:           The IETF Profile URI Registry
> Creation date:   2013-04-17
> Group:           Individual Submission
> Number of pages: 6
> URL:
> http://www.ietf.org/internet-drafts/draft-lanthaler-profile-registry-01.txt
> Status:
> http://datatracker.ietf.org/doc/draft-lanthaler-profile-registry
> Htmlized:
> http://tools.ietf.org/html/draft-lanthaler-profile-registry-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-lanthaler-profile-registry-01
>
> Abstract:
>    This document defines a registry for profile URIs and establishes an
>    IETF URN Sub-namespace to be used in specifications standardizing
>    profiles.
>
>
>
>
> The IETF Secretariat
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--e89a8f502ee8d73a5e04da8f7ade
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>This document creates a registry, so I&#39;m fairly c=
ertain it needs to go through the IETF Stream, which means an Area Director=
 has to sponsor it or a working group has to adopt it.=A0 On the other hand=
, although Independent Submission stream drafts can&#39;t create registry e=
ntries when the registry has certain constraints, I couldn&#39;t find anyth=
ing constraining registry creation.=A0 Someone should check my math here.<b=
r>
<br>You could ask this working group if it&#39;s interested in working on t=
he document for starters.<br><br></div>-MSK, APPSAWG co-chair<br></div><div=
 class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Apr 17, 2=
013 at 4:40 AM, Markus Lanthaler <span dir=3D"ltr">&lt;<a href=3D"mailto:ma=
rkus.lanthaler@gmx.net" target=3D"_blank">markus.lanthaler@gmx.net</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi,<br>
<br>
I&#39;ve just uploaded a new version of my I-D which incorporates Dave Crid=
land&#39;s feedback. Thanks again!<br>
<br>
Since this is my first I-D I&#39;m not familiar with the processes yet. If =
my understanding of RFC2026 &amp; RFC4846 is correct, the next step would b=
e to send a publication request to the RFC editor. Or do I have to contact =
the Area Directors because the document requires IANA allocations?<br>

<br>
<br>
Thanks,<br>
Markus<br>
<br>
<br>
--<br>
Markus Lanthaler<br>
@markuslanthaler<br>
<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: <a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org<=
/a> [mailto:<a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@iet=
f.org</a>]<br>
Sent: Wednesday, April 17, 2013 1:21 PM<br>
To: <a href=3D"mailto:mail@markus-lanthaler.com">mail@markus-lanthaler.com<=
/a><br>
Subject: New Version Notification for draft-lanthaler-profile-registry-01.t=
xt<br>
<br>
<br>
A new version of I-D, draft-lanthaler-profile-registry-01.txt<br>
has been successfully submitted by Markus Lanthaler and posted to the<br>
IETF repository.<br>
<br>
Filename: =A0 =A0 =A0 =A0draft-lanthaler-profile-registry<br>
Revision: =A0 =A0 =A0 =A001<br>
Title: =A0 =A0 =A0 =A0 =A0 The IETF Profile URI Registry<br>
Creation date: =A0 2013-04-17<br>
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission<br>
Number of pages: 6<br>
URL: =A0 =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.ietf.org/internet-drafts=
/draft-lanthaler-profile-registry-01.txt" target=3D"_blank">http://www.ietf=
.org/internet-drafts/draft-lanthaler-profile-registry-01.txt</a><br>
Status: =A0 =A0 =A0 =A0 =A0<a href=3D"http://datatracker.ietf.org/doc/draft=
-lanthaler-profile-registry" target=3D"_blank">http://datatracker.ietf.org/=
doc/draft-lanthaler-profile-registry</a><br>
Htmlized: =A0 =A0 =A0 =A0<a href=3D"http://tools.ietf.org/html/draft-lantha=
ler-profile-registry-01" target=3D"_blank">http://tools.ietf.org/html/draft=
-lanthaler-profile-registry-01</a><br>
Diff: =A0 =A0 =A0 =A0 =A0 =A0<a href=3D"http://www.ietf.org/rfcdiff?url2=3D=
draft-lanthaler-profile-registry-01" target=3D"_blank">http://www.ietf.org/=
rfcdiff?url2=3Ddraft-lanthaler-profile-registry-01</a><br>
<br>
Abstract:<br>
=A0 =A0This document defines a registry for profile URIs and establishes an=
<br>
=A0 =A0IETF URN Sub-namespace to be used in specifications standardizing<br=
>
=A0 =A0profiles.<br>
<br>
<br>
<br>
<br>
The IETF Secretariat<br>
<br>
_______________________________________________<br>
apps-discuss mailing list<br>
<a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
</blockquote></div><br></div>

--e89a8f502ee8d73a5e04da8f7ade--

From joe.gregorio@gmail.com  Wed Apr 17 07:41:39 2013
Return-Path: <joe.gregorio@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F0F21E8051 for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 07:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X53asPToobmr for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 07:41:36 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 12D2A21E804D for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 07:41:36 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id ar20so2017720iec.0 for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 07:41:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JpjmOvbsroKe8JK50XG8DtitwcRRnMUHQxmaHqRiBtk=; b=FBKNxA3NO9OD1KAuC3EHP0exvCJyrdE0kC13U5akMWH7p6iJkIRNccnFzTx8glSiJ5 NiZ3mFatSntNZILEsOO8nCWieb1UBOCikAb9KxEk0X28S0zny8OGVWwE4NUOZJz2bGIW CqrBxS47zjTUFTauZpGlmIHN0BcEy3P/b/7Hw6Mcq/9jAQi4EnQAMgLru9o3CsvvEFEx SEWJ5Oy6IQFoyChYkWoDMsTPguV3UF7sftyYPvQd4faSVIszO7QMhhSOd/7ZaxFlqg7a tbAjpCRo/7aWuB5ywrfS3WDf55n4J+9/mEI3fPww7teTX4Ox5lhhTewJL29N3sgNSqdV c+vg==
MIME-Version: 1.0
X-Received: by 10.50.55.8 with SMTP id n8mr4233381igp.28.1366209695610; Wed, 17 Apr 2013 07:41:35 -0700 (PDT)
Sender: joe.gregorio@gmail.com
Received: by 10.64.53.136 with HTTP; Wed, 17 Apr 2013 07:41:35 -0700 (PDT)
In-Reply-To: <CALcybBD83_x9P0=tNy+4i91mgyYrDWpVHp++QtF06Ouc7sjZ8w@mail.gmail.com>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CA+-NybWfR47yScyTBi7BRpJgj5SnCxWY1rDV5KC8PuE+JEV90A@mail.gmail.com> <CALcybBD83_x9P0=tNy+4i91mgyYrDWpVHp++QtF06Ouc7sjZ8w@mail.gmail.com>
Date: Wed, 17 Apr 2013 10:41:35 -0400
X-Google-Sender-Auth: aD6Uqlb724ko--9SJFXymc7PPS8
Message-ID: <CA+-NybWeL0MtaXOiq-zqYpyWU7TmveoR+q20yb5Rr6XOw0W3QA@mail.gmail.com>
From: Joe Gregorio <joe@bitworking.org>
To: Francis Galiegue <fgaliegue@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2013 14:41:39 -0000

On Wed, Apr 17, 2013 at 10:31 AM, Francis Galiegue <fgaliegue@gmail.com> wrote:
> On Wed, Apr 17, 2013 at 4:03 PM, Joe Gregorio <joe@bitworking.org> wrote:
> [...]
>>>
>>>
>>> https://github.com/dret/uritemplate-test/blob/master/spec-examples-by-section.json
>>> (line 234) says it's "X", but i am really interested in the "why"
>>> explanation as well. http://tools.ietf.org/html/rfc6570#section-3.2.5 says
>>> that
>>
>> The answer is in the text you quote:
>>
>> "for each defined variable in the variable-list, append '.' to the
>> result string and then perform variable expansion"
>>
>> The set of variables in the variable list is the empty set, so no '.'
>> is appended.
>>
>
> Is it really the case?

Yes.

> I don't see an empty list as an undefined variable.

Which is why an addendum should be added to the spec.

>
> Or it would mean that the first thing which needs to be done is expand
> variable values (scalars, lists, associative arrays) before "grouping"
> them.
>
>
> --
> Francis Galiegue, fgaliegue@gmail.com
> JSON Schema in Java: http://json-schema-validator.herokuapp.com
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss



--
Joe Gregorio        http://bitworking.org

From ht@inf.ed.ac.uk  Wed Apr 17 08:02:55 2013
Return-Path: <ht@inf.ed.ac.uk>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEA721F85B3; Wed, 17 Apr 2013 08:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5zfAm914VDr; Wed, 17 Apr 2013 08:02:54 -0700 (PDT)
Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id A7E9D21F8564; Wed, 17 Apr 2013 08:02:53 -0700 (PDT)
Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r3HF2iWY005855; Wed, 17 Apr 2013 16:02:44 +0100 (BST)
Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id r3HF2j2n015914; Wed, 17 Apr 2013 16:02:45 +0100
Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r3HF2jwx006980;  Wed, 17 Apr 2013 16:02:45 +0100
Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r3HF2jnC006976; Wed, 17 Apr 2013 16:02:45 +0100
X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: apps-discuss@ietf.org, draft-ietf-geopriv-relative-location.all@tools.ietf.org
From: ht@inf.ed.ac.uk (Henry S. Thompson)
Date: Wed, 17 Apr 2013 16:02:44 +0100
Message-ID: <f5bmwsxnqsr.fsf@calexico.inf.ed.ac.uk>
User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus
X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102
Cc: appsdir@ietf.org, iesg@ietf.org
Subject: [apps-discuss] Appsdir review of draft-ietf-geopriv-relative-location
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2013 15:02:55 -0000

I have been selected as the Applications Area Review Team reviewer for
this draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-geopriv-relative-location

Title: Relative Location Representation

Reviewer: Henry S. Thompson

Review Date: 2013-04-16

Summary: This draft is almost ready for publication as a Proposed
Standard but has a few issues that should be fixed before publication

Minor Issues: 

  3 The use of the phrases '"baseline" location' and '"reference"
    location' to mean the same thing (?) is confusing in the extreme
    (as is the fact that sometimes the phrase includes scare-quotes,
    but sometimes not).

    For example, in the following, what is meant to be the difference
    between the two highlighted phrases?

      "In particular, while it is possible to put all location
       information into the 'reference' location (leaving an
                             ^^^^^^^^^
       universally broad 'baseline'), location objects SHOULD NOT have
       all location information in the baseline location.  Doing this
                                       ^^^^^^^^
       would cause clients that do not understand relative location to
       incorrectly interpret the baseline location (i.e., the
       reference point) as the actual, precise location of the
       client."

   Furthermore wrt this passage, either I'm confused, or there's a
   mistake at the second highlighted point.  I was expecting
   "relative", not "baseline" (or "reference").  After all, if all the
   information is in the baseline, then there is no information in the
   relative part, and so not processing it misses nothing???

   Ah, repeated re-readings have uncovered the origin of the problem,
   further back:

     "A client that does understand this extension will interpret the
      location within the relative element as a refinement of the
      baseline location, which gives the reference location for the
      relative offset."

   I read that the first five times as if it were bracketed like this:

      [a refinement of [the baseline location, which gives the
       reference location for the relative offset]].

   But you mean it as if it were bracketed like this:

    [a refinement of the baseline location], [which gives the
       reference location for the relative offset].

   So, I suggest you rephrase the whole sentence along the following
   lines:

     "A client that does understand this extension will interpret the
      location within the relative element as a refinement of the
      baseline location.  The resulting refined location then gives
      the reference location for the relative offset."

  With that change, the paragraph containing the first quote above
  (the para beginning "The baseline location SHOULD be general
  enough") is comprehensible, but still very dense.  I know
  illustrations are hard when one is restricted to ASCII-art, but a
  pair of examples would be a great help here, where one obeys the
  rules, and is not understood wrongly by a non-extension-supporting
  app, but the other breaks the rules, and therefore liable to be
  interpreted wrongly by such an app.

  And, finally, perhaps just _after_ the example now at the end of
  this section, just a brief gloss along the lines of

    The baseline location, given by the first ca:civicAddress element,
    the first child of the gp:location-info, is a street address, to
    the level of detail of the house number (123).  The reference
    location is [now the front door, something else if you fix the 5.1
    issue below].  The actual location, which is still within the
    baseline building, is a point 100m east and 50m north [?] of the
    front door.

  4.11.1

    "An 'http:' or 'https:' URL MUST be used unless . . ."

  Wouldn't it be more in the spirit of 2119 to say "A URI with scheme
  other than 'http:' or 'https:' SHOULD NOT be used unless" ?

  5.1 Civic PIDF with Polygon Offset [also at end of section 3]

  This example uses the ca:INT element, which as far as I can tell is
  only defined in the expired draft-rosen-geopriv-pidf-interior [1].
  It would be better to adjust the example so that it uses elements
  and validates with schema documents all of which can be found in
  current RFCs.

  5.2 Geo PIDF with Circle Offset

  Once the cut-and-paste error identified below in the 'Nits' section
  is fixed, the result has 4 schema-validity errors, all of which I
  presume should be straightforward to correct:

   ex5.xml:14:4: Invalid per cvc-complex-type.1.2.4 : element
   {http://www.opengis.net/gml}:radius not allowed here (5) in element
   {http://www.opengis.net/pidflo/1.0}:Circle, expecting
    {http://www.opengis.net/pidflo/1.0}:radius

   ex5.xml:25:6: Invalid per cvc-complex-type.1.2.4 : element
   {http://www.opengis.net/gml}:Circle not allowed here (1) in element
   {urn:ietf:params:xml:ns:pidf:geopriv10:relative}:offset, expecting
    {http://www.opengis.net/gml}:OrientableCurve,...,
    {http://www.opengis.net/gml}:LineString

   ex5.xml:25:6: Invalid per cvc-complex-type.1.3 : undeclared
       attribute {None}:srsName

   ex5.xml:28:3: Invalid per cvc-complex-type.1.2.4 : element
   {http://www.opengis.net/gml}:radius not allowed here (4) in element
   {http://www.opengis.net/gml}:Circle, expecting
    {http://www.opengis.net/gml}:pos,
    {http://www.opengis.net/gml}:pointProperty,
    {http://www.opengis.net/gml}:pointRep,$

Nits: 

  5.1, 5.2 [examples]

  These examples rely on schema documents which require moderately
  tedious indirection via the XML registry [2] to find -- it would be
  helpful if the references section at least included the relevant
  RFCs, at least 3863, 4479 and 5139.

  5.2

   <rel:urltype="image/png"> --> <rel:url type="image/png">

   There are a number of spurious lines at the end of the example,
   which don't match anything at the beginning and render the whole
   thing non-well-formed:

     </gp:geopriv>
    </status>
    <timestamp>2003-06-22T20:57:29Z</timestamp>
   </tuple>

   ???

  6. Schema Definition

  The repeated pattern used for complex type definition in this schema
  doc is as follows:

  <xs:complexType name="relativeType">
    <xs:complexContent>
      <xs:restriction base="xs:anyType">
	<xs:sequence>
         ...
  	</xs:sequence>
	<xs:anyAttribute namespace="##other" processContents="lax"/>
      </xs:restriction>
    </xs:complexContent>
  </xs:complexType>

  This is overly . . . complex and invites confusion, as it is
  strictly equivalent to the much simpler

  <xs:complexType name="relativeType">
    <xs:sequence>
     ...
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax"/>
  </xs:complexType>

  Please simplify all your complex type definitions along these lines.
  

[1] https://datatracker.ietf.org/doc/draft-rosen-geopriv-pidf-interior/
[2] http://www.iana.org/assignments/xml-registry/xml-registry.xml

-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

From barryleiba.mailing.lists@gmail.com  Wed Apr 17 08:31:27 2013
Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F43121F8E36 for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 08:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.935
X-Spam-Level: 
X-Spam-Status: No, score=-102.935 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83QFtCZAZlM6 for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 08:31:26 -0700 (PDT)
Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7111C21F8E2C for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 08:31:26 -0700 (PDT)
Received: by mail-ve0-f174.google.com with SMTP id jz10so1523488veb.19 for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 08:31:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qlzPVddHLghtKwz795YBpkZEOuyaCpg6vNwDwQXrIzg=; b=eorrlLkm5s6bQy0oQV/qi5smonxJ57jz76JnXIrZWtART7/DTh+6D1MissrLtNc77P wJANgjymTjVBXHM4KuDb6www6gWRe2AxZXPSgRvsRIdqWw3ad0UeiWwDlwXPlg0DMKos 4xoncL0VTzY8Jx7YzQUcax3+m0P850Kk6cF70K9CL8qMlpWBEHpWgPKVAusPQ55xP17X Gsu0tOHUGeDWBJcQUBtCE51pfnuREJ1DyrKQPMaxDQ5Gp0AJuZm8Y2lj8HCilFGLnmO+ 4oR3jvKxUnm+lF29t34QxkXTBD/eNYn36jYOeJC6EecLZJVDsz6MDl747wXlMUv7/Bfc xDAQ==
MIME-Version: 1.0
X-Received: by 10.52.96.138 with SMTP id ds10mr4503168vdb.3.1366212685887; Wed, 17 Apr 2013 08:31:25 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Wed, 17 Apr 2013 08:31:25 -0700 (PDT)
In-Reply-To: <CAL0qLwb+9CYnOYw9kcMdzZvyPagcUrhxUkmOiMZNAXpzFe6MYA@mail.gmail.com>
References: <516e8a54.45f7440a.7dcc.1253SMTPIN_ADDED_BROKEN@mx.google.com> <CAL0qLwb+9CYnOYw9kcMdzZvyPagcUrhxUkmOiMZNAXpzFe6MYA@mail.gmail.com>
Date: Wed, 17 Apr 2013 11:31:25 -0400
X-Google-Sender-Auth: rLZHrMbzyMaAJ5yr9DGi3Niq46s
Message-ID: <CAC4RtVC+rr0ZwBRk0jit7Ye-7H6D8yawiW7OG2RFhns5jqbQyQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] FW: New Version Notification for draft-lanthaler-profile-registry-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2013 15:31:27 -0000

>> Since this is my first I-D I'm not familiar with the processes yet. If my understanding
>> of RFC2026 & RFC4846 is correct, the next step would be to send a publication
>> request to the RFC editor. Or do I have to contact the Area Directors because the
>> document requires IANA allocations?
>
> This document creates a registry, so I'm fairly certain it needs to go
> through the IETF Stream, which means an Area Director has to sponsor it or a
> working group has to adopt it.  On the other hand, although Independent
> Submission stream drafts can't create registry entries when the registry has
> certain constraints, I couldn't find anything constraining registry
> creation.  Someone should check my math here.

There's nothing that says you can't create a new registry through the
Independent Stream, as long as the IESG doesn't think it conflicts
with IETF work, so that's not the issue here.

The reason this can't go through the Independent Stream (that is,
directly to the RFC Editor) is that it's requesting an IETF-namespace
URN sub-namespace in the second bullet of Section 4.  RFC 3553 says
this about that:

   Process of identifier assignment:

      Identifiers are assigned only after a particular protocol element
      or number has been registered with the IANA using standard
      policies and procedures, or documented in an RFC describing a
      standards track protocol.  This means that the 'gating' function
      for assignment is the "IETF Consensus" process documented in RFC
      2434 [4].

I suggest that the appsawg might process this document.

Barry

From markus.lanthaler@gmx.net  Wed Apr 17 13:32:23 2013
Return-Path: <markus.lanthaler@gmx.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89A521E809C for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 13:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZl+tmuJ1LlE for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 13:32:23 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 1D68E21E809B for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 13:32:22 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.10]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lyxby-1Ug1Jg1isq-014FUN for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 22:32:08 +0200
Received: (qmail invoked by alias); 17 Apr 2013 20:32:08 -0000
Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp010) with SMTP; 17 Apr 2013 22:32:08 +0200
X-Authenticated: #419883
X-Provags-ID: V01U2FsdGVkX18mK3xwR9MmE90Lh/M71e38KqT63HZYgr7C0cGzal pZkhkZZ2TzRcVf
From: "Markus Lanthaler" <markus.lanthaler@gmx.net>
To: "'Barry Leiba'" <barryleiba@computer.org>, "'Murray S. Kucherawy'" <superuser@gmail.com>
References: <516e8a54.45f7440a.7dcc.1253SMTPIN_ADDED_BROKEN@mx.google.com>	<CAL0qLwb+9CYnOYw9kcMdzZvyPagcUrhxUkmOiMZNAXpzFe6MYA@mail.gmail.com> <CAC4RtVC+rr0ZwBRk0jit7Ye-7H6D8yawiW7OG2RFhns5jqbQyQ@mail.gmail.com>
In-Reply-To: <CAC4RtVC+rr0ZwBRk0jit7Ye-7H6D8yawiW7OG2RFhns5jqbQyQ@mail.gmail.com>
Date: Wed, 17 Apr 2013 22:32:00 +0200
Message-ID: <028001ce3baa$9e3fbf20$dabf3d60$@lanthaler@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Content-Language: de
Thread-Index: Ac47gJ+crLH15qQwRkaAb94yZK/c5gAKP2Iw
X-Y-GMX-Trusted: 0
Cc: 'IETF Apps Discuss' <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] FW: New Version Notification for draft-lanthaler-profile-registry-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2013 20:32:24 -0000

First of all, thanks to both of you for the quick reply!

> > This document creates a registry, so I'm fairly certain it needs to
> > go through the IETF Stream, which means an Area Director has to
> > sponsor it or a working group has to adopt it.  On the other hand,
> > although Independent Submission stream drafts can't create registry
> > entries when the registry has certain constraints, I couldn't find
> > anything constraining registry creation.  Someone should check my
> > math here.
> 
> There's nothing that says you can't create a new registry through the
> Independent Stream, as long as the IESG doesn't think it conflicts
> with IETF work, so that's not the issue here.

Great. Good to know.


> The reason this can't go through the Independent Stream (that is,
> directly to the RFC Editor) is that it's requesting an IETF-namespace
> URN sub-namespace in the second bullet of Section 4.  RFC 3553 says
> this about that:
> 
>    Process of identifier assignment:
> 
>       Identifiers are assigned only after a particular protocol element
>       or number has been registered with the IANA using standard
>       policies and procedures, or documented in an RFC describing a
>       standards track protocol.  This means that the 'gating' function
>       for assignment is the "IETF Consensus" process documented in RFC
>       2434 [4].
> 
> I suggest that the appsawg might process this document.

OK.. so I think all I can do now is to kindly ask the appsawg whether it is
interested in this work and use the document as starting point for the rest
of the process.


Thanks again,
Markus


--
Markus Lanthaler
@markuslanthaler


From superuser@gmail.com  Wed Apr 17 20:16:53 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81ECC21E8095 for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 20:16:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=-0.021,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yU2JNSLWvOqm for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 20:16:53 -0700 (PDT)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C7B6021E80ED for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 20:16:52 -0700 (PDT)
Received: by mail-we0-f173.google.com with SMTP id t57so1770001wey.18 for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 20:16:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QfdJi2E8dJO5QkYHOMYKwwDQ1NTrktB4qU3DlF7bigI=; b=wAsLvGkg8KqsTCzJnnZcWuk+h6d2S+Nue8Y4Ya7d77TkxVACSk6JcdZFY1TrhYlkqI K61fbFLEHdgmnAMx5iTt2zO4/NBFI8VcEnebc5u6IglcZCIkFyDuGfS4JGOEuOaxFVAB wsyZkcWj395+OycVRkAThPzmLYsuo5EHlDjVOepJ+yrMlT2FBoKlz+Wkh+oxBzHolLWv 1benABCL/56t565T9/ndqEVBXL7ggo0wzCsG2xVmVLSA3UmIhyIk+bB+nYILs5VoBnyo 7ERo4f/QNDdFNNMundZXh9XWWOJ0asYQMc9CX780ala3hsMVR+ObpY2+Lydk2jWba7m5 Jhtw==
MIME-Version: 1.0
X-Received: by 10.194.109.35 with SMTP id hp3mr15416163wjb.15.1366255011982; Wed, 17 Apr 2013 20:16:51 -0700 (PDT)
Received: by 10.180.36.176 with HTTP; Wed, 17 Apr 2013 20:16:51 -0700 (PDT)
In-Reply-To: <516f06c9.c1c20e0a.46f3.ffffb0bfSMTPIN_ADDED_BROKEN@mx.google.com>
References: <516e8a54.45f7440a.7dcc.1253SMTPIN_ADDED_BROKEN@mx.google.com> <CAL0qLwb+9CYnOYw9kcMdzZvyPagcUrhxUkmOiMZNAXpzFe6MYA@mail.gmail.com> <CAC4RtVC+rr0ZwBRk0jit7Ye-7H6D8yawiW7OG2RFhns5jqbQyQ@mail.gmail.com> <516f06c9.c1c20e0a.46f3.ffffb0bfSMTPIN_ADDED_BROKEN@mx.google.com>
Date: Wed, 17 Apr 2013 20:16:51 -0700
Message-ID: <CAL0qLwY5LHuVdk__ySDDxBjsyfV0c5yTxZSRKj+Me5b+-2TsqA@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
Content-Type: multipart/alternative; boundary=089e010d8574a9762b04da9a089b
Cc: Barry Leiba <barryleiba@computer.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] FW: New Version Notification for draft-lanthaler-profile-registry-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2013 03:16:53 -0000

--089e010d8574a9762b04da9a089b
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 17, 2013 at 1:32 PM, Markus Lanthaler
<markus.lanthaler@gmx.net>wrote:

> OK.. so I think all I can do now is to kindly ask the appsawg whether it is
> interested in this work and use the document as starting point for the rest
> of the process.
>
>
You have thus asked the question.  Do any participants have comments in
support or opposition?

-MSK, APPSAWG co-chair

--089e010d8574a9762b04da9a089b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Apr 17, 2013 at 1:32 PM, Markus Lanthaler <span di=
r=3D"ltr">&lt;<a href=3D"mailto:markus.lanthaler@gmx.net" target=3D"_blank"=
>markus.lanthaler@gmx.net</a>&gt;</span> wrote:<br><div class=3D"gmail_extr=
a"><div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">OK.. so I think all I can do now is to kindl=
y ask the appsawg whether it is<br>
interested in this work and use the document as starting point for the rest=
<br>
of the process.<br>
<br></blockquote><div><br></div><div>You have thus asked the question.=A0 D=
o any participants have comments in support or opposition?<br><br></div><di=
v>-MSK, APPSAWG co-chair<br>=A0<br></div></div><br></div></div>

--089e010d8574a9762b04da9a089b--

From dhc@dcrocker.net  Wed Apr 17 20:39:33 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD90F21E80F3 for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 20:39:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYtnVdcuPqMD for <apps-discuss@ietfa.amsl.com>; Wed, 17 Apr 2013 20:39:33 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3C67621E80C4 for <apps-discuss@ietf.org>; Wed, 17 Apr 2013 20:39:33 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3I3dO69001223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 Apr 2013 20:39:24 -0700
Message-ID: <516F6AEB.2000908@dcrocker.net>
Date: Wed, 17 Apr 2013 20:39:23 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Murray S. Kucherawy" <superuser@gmail.com>
References: <516e8a54.45f7440a.7dcc.1253SMTPIN_ADDED_BROKEN@mx.google.com> <CAL0qLwb+9CYnOYw9kcMdzZvyPagcUrhxUkmOiMZNAXpzFe6MYA@mail.gmail.com> <CAC4RtVC+rr0ZwBRk0jit7Ye-7H6D8yawiW7OG2RFhns5jqbQyQ@mail.gmail.com> <516f06c9.c1c20e0a.46f3.ffffb0bfSMTPIN_ADDED_BROKEN@mx.google.com> <CAL0qLwY5LHuVdk__ySDDxBjsyfV0c5yTxZSRKj+Me5b+-2TsqA@mail.gmail.com>
In-Reply-To: <CAL0qLwY5LHuVdk__ySDDxBjsyfV0c5yTxZSRKj+Me5b+-2TsqA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 17 Apr 2013 20:39:25 -0700 (PDT)
Cc: Barry Leiba <barryleiba@computer.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] FW: New Version Notification for draft-lanthaler-profile-registry-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2013 03:39:33 -0000

On 4/17/2013 8:16 PM, Murray S. Kucherawy wrote:
> On Wed, Apr 17, 2013 at 1:32 PM, Markus Lanthaler
> <markus.lanthaler@gmx.net <mailto:markus.lanthaler@gmx.net>> wrote:
>
>     OK.. so I think all I can do now is to kindly ask the appsawg
>     whether it is
>     interested in this work and use the document as starting point for
>     the rest
>     of the process.
>
>
> You have thus asked the question.  Do any participants have comments in
> support or opposition?


On the average, something like this is best done when motivated by some 
specific needs for its capabilities, rather than as an abstract exercise.

So my own question is:  what profiles are needed immediately?

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From dhc@dcrocker.net  Thu Apr 18 09:12:25 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A443021F90FD for <apps-discuss@ietfa.amsl.com>; Thu, 18 Apr 2013 09:12:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeuC07I5vDtP for <apps-discuss@ietfa.amsl.com>; Thu, 18 Apr 2013 09:12:24 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9487621F90F4 for <apps-discuss@ietf.org>; Thu, 18 Apr 2013 09:12:24 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3IGCNMw015332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Apr 2013 09:12:24 -0700
Message-ID: <51701B63.1080204@dcrocker.net>
Date: Thu, 18 Apr 2013 09:12:19 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Scott Kitterman <scott@kitterman.com>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <15015065.dv5A4A6JuL@scott-latitude-e6320> <516D7026.6040409@dcrocker.net> <29070418.Ips48RWf4b@scott-latitude-e6320>
In-Reply-To: <29070418.Ips48RWf4b@scott-latitude-e6320>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 18 Apr 2013 09:12:24 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2013 16:12:25 -0000

On 4/16/2013 6:23 PM, Scott Kitterman wrote:
> On Tuesday, April 16, 2013 08:37:10 AM Dave Crocker wrote:
>> On 4/15/2013 8:58 PM, Scott Kitterman wrote:
>>> 1.  How about this?
>>> 2.  Not quite, here are some alternatives we could discuss.
>>> 1.  I quit.
>>>
>>> that's hardly a negotiation.
>>
>> 1. The exchange was more elaborate than that,
...
>> 2. The lockout imagine is striking and entirely inapplicable, since
>> there is no pre-existing relationship, nevermind an employer/employee one.
>>
> Right.  It's an analogy and like all analogy is imperfect.


Scott,

An analogy is supposed to demonstrate core properties that match the 
situation.  Similarly:

> Also imperfect, but perhaps less orthogonal might be the analogy of the kid
> that shows up at the playground with a cool new toy and stomps off and goes
> home when the other kids won't play with the toy precisely according to his
> rules.

entirely misses the point of what is currently happening.


The current exchange has had more of the flavor of:

    A:    How about X.
    B&C:  That's unacceptable, so do alternatives Y or Z.
    A:    Here are the reasons those alternatives don't match the
          current situation and here are the distinctive characteristics
          of the current situation.
    B&C:  Do Y or Z
    {rinse repeat}
    A:    OK, how about A.
    B&C:  Do Y or Z

After some iterations in this model, it become clear that the 
negotiation isn't a negotiation.

Until you and Stephen engage in discussing the substance of the 
responses you've been getting, there isn't a meaningful discussion 
happening.

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From markus.lanthaler@gmx.net  Thu Apr 18 11:35:13 2013
Return-Path: <markus.lanthaler@gmx.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6F121F9356 for <apps-discuss@ietfa.amsl.com>; Thu, 18 Apr 2013 11:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=0.600,  BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVbk+tb8f5Of for <apps-discuss@ietfa.amsl.com>; Thu, 18 Apr 2013 11:35:12 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 328DF21F9377 for <apps-discuss@ietf.org>; Thu, 18 Apr 2013 11:34:58 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.33]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LyxXq-1UXRzt1iwy-0149sd for <apps-discuss@ietf.org>; Thu, 18 Apr 2013 20:34:57 +0200
Received: (qmail invoked by alias); 18 Apr 2013 18:34:57 -0000
Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp033) with SMTP; 18 Apr 2013 20:34:57 +0200
X-Authenticated: #419883
X-Provags-ID: V01U2FsdGVkX18V8nYfpKMV2hw2MC6B/0bZzBgJ7GlF2nyBnW5pzd btdqDiY6tlQXW8
From: "Markus Lanthaler" <markus.lanthaler@gmx.net>
To: <dcrocker@bbiw.net>, "'Murray S. Kucherawy'" <superuser@gmail.com>
References: <516e8a54.45f7440a.7dcc.1253SMTPIN_ADDED_BROKEN@mx.google.com> <CAL0qLwb+9CYnOYw9kcMdzZvyPagcUrhxUkmOiMZNAXpzFe6MYA@mail.gmail.com> <CAC4RtVC+rr0ZwBRk0jit7Ye-7H6D8yawiW7OG2RFhns5jqbQyQ@mail.gmail.com> <516f06c9.c1c20e0a.46f3.ffffb0bfSMTPIN_ADDED_BROKEN@mx.google.com> <CAL0qLwY5LHuVdk__ySDDxBjsyfV0c5yTxZSRKj+Me5b+-2TsqA@mail.gmail.com> <516F6AEB.2000908@dcrocker.net>
In-Reply-To: <516F6AEB.2000908@dcrocker.net>
Date: Thu, 18 Apr 2013 20:34:48 +0200
Message-ID: <015a01ce3c63$6a1e69d0$3e5b3d70$@lanthaler@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac475lcXRf6KcglcScywM1PnhbQkgQAeRtXA
Content-Language: de
X-Y-GMX-Trusted: 0
Cc: 'Barry Leiba' <barryleiba@computer.org>, 'IETF Apps Discuss' <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] FW: New Version Notification for draft-lanthaler-profile-registry-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2013 18:35:13 -0000

On Thursday, April 18, 2013 5:39 AM, Dave Crocker wrote:
> On the average, something like this is best done when motivated by some
> specific needs for its capabilities, rather than as an abstract
> exercise.
> 
> So my own question is:  what profiles are needed immediately?

That's a good point. The JSON-LD specification [1], which is now in Last
Call at W3C, e.g., defines three profile URIs. Since it is being defined at
W3C, it also uses URIs in W3C's URI space. AFAIK, nothing comparable
(URI-space-wise) exists for RFCs. The profile link relation was approved
just recently and media type definitions are already beginning to include
profile parameters following its semantics [1], [2], [3], [4] (or are being
re-registered to do so).

I think the potential gain of reserving some URN space for this to enable
standards to mint unambiguous and, more importantly, stable identifiers far
outweighs the potential harm it might do. In fact, I can't see any potential
"harm" apart from "wasting" one URN sub-namespace if it doesn't get adopted.

This may not answer your question directly. We are a bit in a
chicken-and-egg situation here. Obviously profiles can't make use of such an
URN before the sub-namespace is established. Nevertheless, I think this I-D
represents an important piece to ensure that profiles can be used to build
interoperable and evolvable solutions. It is similar to media types: nothing
"breaks" if you use proprietary ones but you will lose a lot of advantages
by doing so. In these instances, centralization is a feature.

I hope this clarifies the motivation behind this effort. If not, please let
me know and I'll try my best to respond to your concerns.


Cheers,
Markus



[1] http://www.w3.org/TR/json-ld/#application-ld-json
[2] http://amundsen.com/media-types/collection/format/
[3] http://tools.ietf.org/html/draft-kelly-json-hal
[4] http://tools.ietf.org/html/draft-wilde-atom-profile


--
Markus Lanthaler
@markuslanthaler


From scott@kitterman.com  Thu Apr 18 11:54:03 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443F121F90F6 for <apps-discuss@ietfa.amsl.com>; Thu, 18 Apr 2013 11:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNjW1xFRu+Mo for <apps-discuss@ietfa.amsl.com>; Thu, 18 Apr 2013 11:54:00 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id AA30521F911C for <apps-discuss@ietf.org>; Thu, 18 Apr 2013 11:53:55 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id D585020E40D4; Thu, 18 Apr 2013 14:53:54 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366311234; bh=Cso/hprlh2OWczO4YeG8NHbKl7ssgeIGNKmIjOocCas=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cdsHfaqzXVYEL3xvpPR2R578zTzMV6gPr31knPbn/q7t4YUsDjBYkZionh1eQHtc/ qpLyuKNzdPGziozP5M0DvWzInclNpTw5AAhNRFno4RXlh04yzghmEXrWEFUteUCj/X QmVkjuPfO2P2Dqwo8Brv6zjvA5J+gnnIXkfTX8OM=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B8E9620E4090;  Thu, 18 Apr 2013 14:53:54 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Thu, 18 Apr 2013 14:53:53 -0400
Message-ID: <4299196.YodGhlyJ6a@scott-latitude-e6320>
User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; )
In-Reply-To: <51701B63.1080204@dcrocker.net>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <29070418.Ips48RWf4b@scott-latitude-e6320> <51701B63.1080204@dcrocker.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2013 18:54:03 -0000

On Thursday, April 18, 2013 09:12:19 AM Dave Crocker wrote:
> On 4/16/2013 6:23 PM, Scott Kitterman wrote:
> > On Tuesday, April 16, 2013 08:37:10 AM Dave Crocker wrote:
> >> On 4/15/2013 8:58 PM, Scott Kitterman wrote:
> >>> 1.  How about this?
> >>> 2.  Not quite, here are some alternatives we could discuss.
> >>> 1.  I quit.
> >>> 
> >>> that's hardly a negotiation.
> >> 
> >> 1. The exchange was more elaborate than that,
> 
> ...
> 
> >> 2. The lockout imagine is striking and entirely inapplicable, since
> >> there is no pre-existing relationship, nevermind an employer/employee
> >> one.
> > 
> > Right.  It's an analogy and like all analogy is imperfect.
> 
> Scott,
> 
> An analogy is supposed to demonstrate core properties that match the
> 
> situation.  Similarly:
> > Also imperfect, but perhaps less orthogonal might be the analogy of the
> > kid
> > that shows up at the playground with a cool new toy and stomps off and
> > goes
> > home when the other kids won't play with the toy precisely according to
> > his
> > rules.
> 
> entirely misses the point of what is currently happening.
> 
> 
> The current exchange has had more of the flavor of:
> 
>     A:    How about X.
>     B&C:  That's unacceptable, so do alternatives Y or Z.
>     A:    Here are the reasons those alternatives don't match the
>           current situation and here are the distinctive characteristics
>           of the current situation.
>     B&C:  Do Y or Z
>     {rinse repeat}
>     A:    OK, how about A.
>     B&C:  Do Y or Z
> 
> After some iterations in this model, it become clear that the
> negotiation isn't a negotiation.
> 
> Until you and Stephen engage in discussing the substance of the
> responses you've been getting, there isn't a meaningful discussion
> happening.

OK.  It seemed to me that in your analogy is was more like A saying "How about 
X" over and over.

Since you are a part of the DMARC development community, do you have a sense 
of if that group is willing to support a working group charter that allows for 
technical changes to be made in the protocol in the event significant technical 
issues are discovered?

Scott K

From jtrentadams@gmail.com  Thu Apr 18 13:46:56 2013
Return-Path: <jtrentadams@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73F621F934B for <apps-discuss@ietfa.amsl.com>; Thu, 18 Apr 2013 13:46:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level: 
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNOeUYMz0ZFH for <apps-discuss@ietfa.amsl.com>; Thu, 18 Apr 2013 13:46:56 -0700 (PDT)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id DB2B121F933B for <apps-discuss@ietf.org>; Thu, 18 Apr 2013 13:46:55 -0700 (PDT)
Received: by mail-ie0-f177.google.com with SMTP id 9so3789955iec.8 for <apps-discuss@ietf.org>; Thu, 18 Apr 2013 13:46:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=vphHwoKtHg7hTCUUcwh4r+vGH9WZe14MhzixBk8f59s=; b=LRM2f+2dKPHelMSi8dJBhxmkBtmvVNNv5VQa+LqLnYHgnd4Pg+M4TmNlrQiAmxj9Od K6/CHJ/aHPUDDRXTgvVyqakdxfLVTLDHa/kibGeykVvs2O4W+VPXWZhOOpfpB6WXuCiC jo1FcuMMhr0aJnOSvn1G6Z1aBcj+Fw1cksubtb3cXf0vzQ2NypeCTqMGTQLG5rWGz6Y9 ijF1ItfS1EKii/z4fnwKA+2ovu+FvZLUZZO22MuqybU7yWHKzth5NI/mFWLuADjfcOWH D+3JAn7jNwVOPuImU1JCQRZhg7xE07m6c4WXXB88c3Encx1x12nJr4wflC3xJWoBH5Ya QZoQ==
X-Received: by 10.50.187.225 with SMTP id fv1mr7962740igc.74.1366318015376; Thu, 18 Apr 2013 13:46:55 -0700 (PDT)
Received: from jtrentadams-isoc.local (c-76-25-71-111.hsd1.co.comcast.net. [76.25.71.111]) by mx.google.com with ESMTPSA id in10sm140710igc.1.2013.04.18.13.46.53 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 13:46:54 -0700 (PDT)
Message-ID: <51705BBD.3070907@gmail.com>
Date: Thu, 18 Apr 2013 14:46:53 -0600
From: "J. Trent Adams" <jtrentadams@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <29070418.Ips48RWf4b@scott-latitude-e6320> <51701B63.1080204@dcrocker.net> <4299196.YodGhlyJ6a@scott-latitude-e6320>
In-Reply-To: <4299196.YodGhlyJ6a@scott-latitude-e6320>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2013 20:46:57 -0000

Scott -

On 4/18/13 12:53 PM, Scott Kitterman wrote:
> On Thursday, April 18, 2013 09:12:19 AM Dave Crocker wrote:
>> On 4/16/2013 6:23 PM, Scott Kitterman wrote:
>>> On Tuesday, April 16, 2013 08:37:10 AM Dave Crocker wrote:
>>>> On 4/15/2013 8:58 PM, Scott Kitterman wrote:
>>>>> 1.  How about this?
>>>>> 2.  Not quite, here are some alternatives we could discuss.
>>>>> 1.  I quit.
>>>>>
>>>>> that's hardly a negotiation.
>>>> 1. The exchange was more elaborate than that,
>> ...
>>
>>>> 2. The lockout imagine is striking and entirely inapplicable, since
>>>> there is no pre-existing relationship, nevermind an employer/employee
>>>> one.
>>> Right.  It's an analogy and like all analogy is imperfect.
>> Scott,
>>
>> An analogy is supposed to demonstrate core properties that match the
>>
>> situation.  Similarly:
>>> Also imperfect, but perhaps less orthogonal might be the analogy of the
>>> kid
>>> that shows up at the playground with a cool new toy and stomps off and
>>> goes
>>> home when the other kids won't play with the toy precisely according to
>>> his
>>> rules.
>> entirely misses the point of what is currently happening.
>>
>>
>> The current exchange has had more of the flavor of:
>>
>>     A:    How about X.
>>     B&C:  That's unacceptable, so do alternatives Y or Z.
>>     A:    Here are the reasons those alternatives don't match the
>>           current situation and here are the distinctive characteristics
>>           of the current situation.
>>     B&C:  Do Y or Z
>>     {rinse repeat}
>>     A:    OK, how about A.
>>     B&C:  Do Y or Z
>>
>> After some iterations in this model, it become clear that the
>> negotiation isn't a negotiation.
>>
>> Until you and Stephen engage in discussing the substance of the
>> responses you've been getting, there isn't a meaningful discussion
>> happening.
> OK.  It seemed to me that in your analogy is was more like A saying "How about 
> X" over and over.
>
> Since you are a part of the DMARC development community, do you have a sense 
> of if that group is willing to support a working group charter that allows for 
> technical changes to be made in the protocol in the event significant technical 
> issues are discovered?

If I'm not mistaken, I think that the proposed charter makes provision
for exactly that happening. If enough data points are gathered through
the work of the group, it can decide to re-charter and crack open the
spec itself. We'll just want to be sure that it's a data-driven decision
rather than something more theoretical.

Does that hit close to what you're looking to achieve?

- Trent

>
> Scott K
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams


From scott@kitterman.com  Thu Apr 18 13:50:55 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0B521F912C for <apps-discuss@ietfa.amsl.com>; Thu, 18 Apr 2013 13:50:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jgE9g8qdlsN for <apps-discuss@ietfa.amsl.com>; Thu, 18 Apr 2013 13:50:53 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E111121F90D5 for <apps-discuss@ietf.org>; Thu, 18 Apr 2013 13:50:51 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3750320E40D4; Thu, 18 Apr 2013 16:50:51 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366318251; bh=5HFVq7irViQU82RtYQjZ2LyvvL7gaiypryuiQsyd9TU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=S88Y427aoeXavzc16NfjivleY9uewxl+Dekp5Q3jg6D4xdH98f4kBHBxjwi6I8DWA Az8mbgPU5WBhWOsWeQmrhZ3/vuWMw/yzclfqBkRX9kmUPdZXb0FBGSQ9vKLL7cm/R5 TuqeyrfUgTH1nd+Tdr4puUw+k+ePhPxOYdhcFnbA=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1CBD020E4090;  Thu, 18 Apr 2013 16:50:50 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Thu, 18 Apr 2013 16:50:50 -0400
Message-ID: <5158537.VifRbVZBdl@scott-latitude-e6320>
User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; )
In-Reply-To: <51705BBD.3070907@gmail.com>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <4299196.YodGhlyJ6a@scott-latitude-e6320> <51705BBD.3070907@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2013 20:50:55 -0000

On Thursday, April 18, 2013 02:46:53 PM J. Trent Adams wrote:
> Scott -
> 
> On 4/18/13 12:53 PM, Scott Kitterman wrote:
> > On Thursday, April 18, 2013 09:12:19 AM Dave Crocker wrote:
> >> On 4/16/2013 6:23 PM, Scott Kitterman wrote:
> >>> On Tuesday, April 16, 2013 08:37:10 AM Dave Crocker wrote:
> >>>> On 4/15/2013 8:58 PM, Scott Kitterman wrote:
> >>>>> 1.  How about this?
> >>>>> 2.  Not quite, here are some alternatives we could discuss.
> >>>>> 1.  I quit.
> >>>>> 
> >>>>> that's hardly a negotiation.
> >>>> 
> >>>> 1. The exchange was more elaborate than that,
> >> 
> >> ...
> >> 
> >>>> 2. The lockout imagine is striking and entirely inapplicable, since
> >>>> there is no pre-existing relationship, nevermind an employer/employee
> >>>> one.
> >>> 
> >>> Right.  It's an analogy and like all analogy is imperfect.
> >> 
> >> Scott,
> >> 
> >> An analogy is supposed to demonstrate core properties that match the
> >> 
> >> situation.  Similarly:
> >>> Also imperfect, but perhaps less orthogonal might be the analogy of the
> >>> kid
> >>> that shows up at the playground with a cool new toy and stomps off and
> >>> goes
> >>> home when the other kids won't play with the toy precisely according to
> >>> his
> >>> rules.
> >> 
> >> entirely misses the point of what is currently happening.
> >> 
> >> The current exchange has had more of the flavor of:
> >>     A:    How about X.
> >>     B&C:  That's unacceptable, so do alternatives Y or Z.
> >>     A:    Here are the reasons those alternatives don't match the
> >>     
> >>           current situation and here are the distinctive characteristics
> >>           of the current situation.
> >>     
> >>     B&C:  Do Y or Z
> >>     {rinse repeat}
> >>     A:    OK, how about A.
> >>     B&C:  Do Y or Z
> >> 
> >> After some iterations in this model, it become clear that the
> >> negotiation isn't a negotiation.
> >> 
> >> Until you and Stephen engage in discussing the substance of the
> >> responses you've been getting, there isn't a meaningful discussion
> >> happening.
> > 
> > OK.  It seemed to me that in your analogy is was more like A saying "How
> > about X" over and over.
> > 
> > Since you are a part of the DMARC development community, do you have a
> > sense of if that group is willing to support a working group charter that
> > allows for technical changes to be made in the protocol in the event
> > significant technical issues are discovered?
> 
> If I'm not mistaken, I think that the proposed charter makes provision
> for exactly that happening. If enough data points are gathered through
> the work of the group, it can decide to re-charter and crack open the
> spec itself. We'll just want to be sure that it's a data-driven decision
> rather than something more theoretical.
> 
> Does that hit close to what you're looking to achieve?

No.  The latest draft excludes such work from consideration without 
rechartering.  It pretty much the opposite of what I was looking to achieve.

Unless working on the base draft is part of the work of the working group, it 
won't happen.  Personally, I'm far more interested in the base spec than any 
extensions proposed so far.  I doubt I'd devote much time to the working group 
if chartered based on the current draft.

Scott K

From dhc@dcrocker.net  Thu Apr 18 14:03:43 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D7821F8782 for <apps-discuss@ietfa.amsl.com>; Thu, 18 Apr 2013 14:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6iVeMiFBbTh for <apps-discuss@ietfa.amsl.com>; Thu, 18 Apr 2013 14:03:42 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0840D21F859A for <apps-discuss@ietf.org>; Thu, 18 Apr 2013 14:03:42 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r3IL3fJk020277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Apr 2013 14:03:41 -0700
Message-ID: <51705FA9.2080106@dcrocker.net>
Date: Thu, 18 Apr 2013 14:03:37 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Scott Kitterman <scott@kitterman.com>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <4299196.YodGhlyJ6a@scott-latitude-e6320> <51705BBD.3070907@gmail.com> <5158537.VifRbVZBdl@scott-latitude-e6320>
In-Reply-To: <5158537.VifRbVZBdl@scott-latitude-e6320>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 18 Apr 2013 14:03:41 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2013 21:03:43 -0000

On 4/18/2013 1:50 PM, Scott Kitterman wrote:
>> If I'm not mistaken, I think that the proposed charter makes provision
>> >for exactly that happening. If enough data points are gathered through
>> >the work of the group, it can decide to re-charter and crack open the
>> >spec itself. We'll just want to be sure that it's a data-driven decision
>> >rather than something more theoretical.
>> >
>> >Does that hit close to what you're looking to achieve?
> No.  The latest draft excludes such work from consideration without
> rechartering.  It pretty much the opposite of what I was looking to achieve.
>
> Unless working on the base draft is part of the work of the working group, it
> won't happen.


Scott,

We've done multiple queries to the community, for a listing of work to 
be done.  There's currently no community desire to work on the base 
specification.

While you've made your own desire clear, there is no evidence of 
community support for the change you want.

It makes no sense to charter a working group to change a specification, 
when there is no community desire to change it.  Indeed, the IETF does 
not typically charter a group to do work when there is no support for 
doing the work and, in fact, no list of the work to be done.

If there is a serious problem discovered with the current base 
specification, the community will want it fixed.  At that point, getting 
rechartering is likely to be pretty easy, since it will have specific 
focus, rather than being open-ended.

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

From scott@kitterman.com  Thu Apr 18 14:09:49 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E834221F8CDD for <apps-discuss@ietfa.amsl.com>; Thu, 18 Apr 2013 14:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0pnGdh3cBAx for <apps-discuss@ietfa.amsl.com>; Thu, 18 Apr 2013 14:09:47 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id CE26F21F8C98 for <apps-discuss@ietf.org>; Thu, 18 Apr 2013 14:09:47 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id F1D5220E40D4; Thu, 18 Apr 2013 17:09:44 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1366319385; bh=l1dkkvWlyJmRcQmPwcXMHJ3PzUOB/wXiTwDmrZTiRmM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=k3IMlZ83bvTQhOKDILjV6HpRqVslpCoyIxu1+MILG2lTdpuag2Ylh6HdaB2JcjjXD 0Pmz5Hegq3EM4wwXffgePARzlnDldeMonQgKDWPUsm2ko5N+yE8caYkJtqA33lBHNk PnO/KTVKzdz1YGxSt5Q3xGx7v+D/c17cKIma/rFI=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id D725720E4090;  Thu, 18 Apr 2013 17:09:44 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Thu, 18 Apr 2013 17:09:43 -0400
Message-ID: <2779691.DUaGRL1rZT@scott-latitude-e6320>
User-Agent: KMail/4.9.5 (Linux/3.5.0-27-generic; KDE/4.9.5; i686; ; )
In-Reply-To: <51705FA9.2080106@dcrocker.net>
References: <CAL0qLwbcH-yOj0MxfGghQZPwGMt5mRBY5U5zBxdXc1oX6SogHA@mail.gmail.com> <5158537.VifRbVZBdl@scott-latitude-e6320> <51705FA9.2080106@dcrocker.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] Revised DMARC working group charter proposal
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2013 21:09:49 -0000

On Thursday, April 18, 2013 02:03:37 PM Dave Crocker wrote:
> On 4/18/2013 1:50 PM, Scott Kitterman wrote:
> >> If I'm not mistaken, I think that the proposed charter makes provision
> >> 
> >> >for exactly that happening. If enough data points are gathered through
> >> >the work of the group, it can decide to re-charter and crack open the
> >> >spec itself. We'll just want to be sure that it's a data-driven decision
> >> >rather than something more theoretical.
> >> >
> >> >Does that hit close to what you're looking to achieve?
> > 
> > No.  The latest draft excludes such work from consideration without
> > rechartering.  It pretty much the opposite of what I was looking to
> > achieve.
> > 
> > Unless working on the base draft is part of the work of the working group,
> > it won't happen.
> 
> Scott,
> 
> We've done multiple queries to the community, for a listing of work to
> be done.  There's currently no community desire to work on the base
> specification.
> 
> While you've made your own desire clear, there is no evidence of
> community support for the change you want.
> 
> It makes no sense to charter a working group to change a specification,
> when there is no community desire to change it.  Indeed, the IETF does
> not typically charter a group to do work when there is no support for
> doing the work and, in fact, no list of the work to be done.
> 
> If there is a serious problem discovered with the current base
> specification, the community will want it fixed.  At that point, getting
> rechartering is likely to be pretty easy, since it will have specific
> focus, rather than being open-ended.

I think it's buggy in one way I've already described, but since it both 
doesn't affect existing IETF RFCs (and this is suitable for independent 
submission) and replaces the policy aspects of SPF and DKIM/ADSP (so it's not 
architecturally buggy), I'm sure it's fine.

Scott K

From stephen.farrell@cs.tcd.ie  Fri Apr 19 03:58:30 2013
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF4B21F9305; Fri, 19 Apr 2013 03:58:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6jXXMTEmCnh; Fri, 19 Apr 2013 03:58:29 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 93D3D21F8F28; Fri, 19 Apr 2013 03:58:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 16AABBE70; Fri, 19 Apr 2013 11:58:05 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6fUiIlILzr9; Fri, 19 Apr 2013 11:58:05 +0100 (IST)
Received: from [IPv6:2001:770:10:203:b90d:e185:2958:9b0] (unknown [IPv6:2001:770:10:203:b90d:e185:2958:9b0]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DAE5CBE6E; Fri, 19 Apr 2013 11:58:04 +0100 (IST)
Message-ID: <5171233D.303@cs.tcd.ie>
Date: Fri, 19 Apr 2013 11:58:05 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Manu Sporny <msporny@digitalbazaar.com>
References: <5170652F.60609@digitalbazaar.com>
In-Reply-To: <5170652F.60609@digitalbazaar.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: IETF HTTP Auth <http-auth@ietf.org>, Web Payments CG <public-webpayments@w3.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] [http-auth] Web Keys and HTTP Signatures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2013 10:58:30 -0000

Hi Manu,

Just on the HOBA bit...

On 04/18/2013 10:27 PM, Manu Sporny wrote:
> 
> HTTP Origin-Bound Authentication (HOBA)
> http://tools.ietf.org/id/draft-farrell-httpbis-hoba-02.txt
> 
> We had considered signatures in the URL in the second approach to the
> problem in the Web Keys spec. We eventually rejected the solution
> because of limitations in the URL length in some browsers and because we
> wanted the semantics of the HTTP headers to be able to be a part of the
> digital signature. We also didn't want large signed messages being
> dumped to the webserver logs (the request line is typically included).
> So, while HOBA does solve the problem, it doesn't solve it in a way that
> is acceptable to us.

I think you're misreading the spec a little, or we've written
it badly:-)

The HTTP scheme in HOBA is an HTTP authentication scheme so I
don't know what you mean when you say putting the signatures
in the URLs, since we don't do that. I think its that part
(section 4 of the HOBA draft) where there's most in common
between these, but also section 6.

The non-normative JS stuff does say to put the signature in
the URL though yes, but is quite a work-in-progress. That
section is really there to demonstrate that a site could do
the moral equivalent of HOBA without waiting for all UAs
to implement the spec. so e.g., if forms made for a better
example that'd be ok too I think (not sure if my co-authors
agree though). But your points about message size and logs
are reasonable.

HOBA is just about public key methods, not HMAC which is
a real difference.

All in all your stuff and this looks quite similar to me, so
I'd say we should talk all right.

Cheers,
S.




From msporny@digitalbazaar.com  Thu Apr 18 14:27:13 2013
Return-Path: <msporny@digitalbazaar.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A41B21F90EB; Thu, 18 Apr 2013 14:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.497
X-Spam-Level: 
X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[AWL=-5.002, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcGV3lQfD4ta; Thu, 18 Apr 2013 14:27:12 -0700 (PDT)
Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id D87F121F90CC; Thu, 18 Apr 2013 14:27:12 -0700 (PDT)
Received: from zoe.digitalbazaar.com ([192.168.0.99] ident=msporny) by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from <msporny@digitalbazaar.com>) id 1USwMK-00028p-03; Thu, 18 Apr 2013 17:27:12 -0400
Message-ID: <5170652F.60609@digitalbazaar.com>
Date: Thu, 18 Apr 2013 17:27:11 -0400
From: Manu Sporny <msporny@digitalbazaar.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.5) Gecko/20120624 Icedove/10.0.5
MIME-Version: 1.0
To: IETF HTTP Auth <http-auth@ietf.org>,  IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 19 Apr 2013 08:10:09 -0700
Cc: Web Payments CG <public-webpayments@w3.org>
Subject: [apps-discuss] Web Keys and HTTP Signatures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2013 21:29:05 -0000

My name is Manu Sporny. I'm the current Chair of the W3C RDFa WG, JSON
for Linking Data (JSON-LD) CG, and Web Payments CG. I am also an editor
of various W3C specs and member of the HTML WG and RDF WG.

There is a relatively new spec at W3C called Web Keys[1] that now
supports HTTP Signatures[2]. It is being worked on as a part of the Web
Payments[3] work. Specifically, the PaySwarm[4] specifications use Web
Keys and HTTP request signatures.

We'd like to coordinate with the IETF on this work to make sure we have
all parties interested in solving this problem involved in the work. We
would also like more eyes doing security audits[5] on the protocol.

For a high-level introduction to Web Keys, see the Mozilla Hacks article:

https://hacks.mozilla.org/2013/04/web-payments-with-payswarm-identity-part-1-of-3/

For a high-level introduction to the Web Payments work, look here:

http://blog.meritora.com/launch/

One of the first questions that came up in the IETF HTTP WG thread[5] on
the matter is why none of the other HTTP authentication schemes were
acceptable to the Web Payments group at W3C. Here is a quick run-down of
the reasoning:

HTTP Origin-Bound Authentication (HOBA)
http://tools.ietf.org/id/draft-farrell-httpbis-hoba-02.txt

We had considered signatures in the URL in the second approach to the
problem in the Web Keys spec. We eventually rejected the solution
because of limitations in the URL length in some browsers and because we
wanted the semantics of the HTTP headers to be able to be a part of the
digital signature. We also didn't want large signed messages being
dumped to the webserver logs (the request line is typically included).
So, while HOBA does solve the problem, it doesn't solve it in a way that
is acceptable to us.

HTTP Mutual Authentication
http://tools.ietf.org/html/draft-oiwa-http-mutualauth-12

Overkill for our purposes and requires multiple bounces back and forth
between the client and the server. Key exchange isn't required since
that's taken care of by the Web Keys PKI framework. We don't intend the
Web Keys HTTP signature protocol to be session-based, as a session-based
value can be built on top of HTTP signatures pretty easily.

HTTP Multilegged Auth
http://tools.ietf.org/id/draft-montenegro-httpbis-multilegged-auth-01.txt

Seems like overkill for our needs and is fairly specific to HTTP 2.0. We
wanted something that could work for HTTP 1.0. Multi-legged
authentication is something that we're not interested in solving using
HTTP Signatures. Putting state into the protocol is something we'd like
to avoid if possible.

HTTP Salted Challenge Response
http://tools.ietf.org/html/draft-melnikov-httpbis-scram-auth-00

Uses HMACs, doesn't use public key crypto, which is a requirement for
Web Keys and the Web Payments work.

HTTP REST Auth
http://tools.ietf.org/id/draft-williams-http-rest-auth-03.txt

This was the solution that seemed to be most interesting to the Web Keys
and Web Payments work. However, it requires quite a bit of state to be
remembered by the server (the Session URIs). Keeping the state of a
"session" around isn't desirable. We didn't want there to be a concept
of logging in and logging out of a website w/ the HTTP Signature stuff.
We'd rather that sessions are built on top of HTTP Signatures via a HTTP
header or cookie. Again, if we had to pick a back-up solution, HTTP REST
Auth seems like it might work for us, but we'd rather not use if we
don't have to.

I'll stop here and wait for feedback from the groups that are involved.
I am in contact with Stephen Farrell and a few other folks at IETF about
where best to coordinate the work.

-- manu

[1] https://payswarm.com/specs/source/web-keys/
[2]
https://github.com/joyent/node-http-signature/blob/master/http_signing.md
[3] http://www.w3.org/community/webpayments/
[4] https://payswarm.com/
[5] http://lists.w3.org/Archives/Public/ietf-http-wg/2013AprJun/0145.html

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

From cyrus@daboo.name  Fri Apr 19 08:33:55 2013
Return-Path: <cyrus@daboo.name>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7708A21F8E48; Fri, 19 Apr 2013 08:33:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbGJPzd-RjyJ; Fri, 19 Apr 2013 08:33:54 -0700 (PDT)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 833C121F8F45; Fri, 19 Apr 2013 08:33:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 06D1541A2A7C; Fri, 19 Apr 2013 11:33:54 -0400 (EDT)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdkhLuDa--nT; Fri, 19 Apr 2013 11:33:53 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 03ADA41A2A6E; Fri, 19 Apr 2013 11:33:51 -0400 (EDT)
Date: Fri, 19 Apr 2013 11:33:48 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Manu Sporny <msporny@digitalbazaar.com>, IETF HTTP Auth <http-auth@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Message-ID: <87A0FB6A602993DC8BFA8CC3@caldav.corp.apple.com>
In-Reply-To: <5170652F.60609@digitalbazaar.com>
References: <5170652F.60609@digitalbazaar.com>
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=1912
Cc: Web Payments CG <public-webpayments@w3.org>
Subject: Re: [apps-discuss] Web Keys and HTTP Signatures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2013 15:33:55 -0000

Hi Manu,

--On April 18, 2013 at 5:27:11 PM -0400 Manu Sporny 
<msporny@digitalbazaar.com> wrote:

> My name is Manu Sporny. I'm the current Chair of the W3C RDFa WG, JSON
> for Linking Data (JSON-LD) CG, and Web Payments CG. I am also an editor
> of various W3C specs and member of the HTML WG and RDF WG.
>
> There is a relatively new spec at W3C called Web Keys[1] that now
> supports HTTP Signatures[2]. It is being worked on as a part of the Web
> Payments[3] work. Specifically, the PaySwarm[4] specifications use Web
> Keys and HTTP request signatures.
>
> We'd like to coordinate with the IETF on this work to make sure we have
> all parties interested in solving this problem involved in the work. We
> would also like more eyes doing security audits[5] on the protocol.

> [2]
> https://github.com/joyent/node-http-signature/blob/master/http_signing.md

That draft is very similar to the approach we have used in iSchedule 
(<https://datatracker.ietf.org/doc/draft-desruisseaux-ischedule/>) - which 
is an HTTP-based calendar and scheduling messaging protocol.

We choose to re-use existing email signing technology - DKIM 
(<http://tools.ietf.org/html/rfc6376>) - primarily because the security 
model and key management were a good fit for our application. There is also 
the benefit of code re-use, and working with a protocol that is already 
deployed and used heavily in the email environment. Also, DKIM was designed 
with the prospect of being applicable to protocols beyond email technology 
- and I think with iSchedule we have proven it can work with HTTP.

I would definitely urge you to take a serious look at DKIM. There are a 
number of interesting features there that don't seem to have been addressed 
in the draft you cited. In particular dealing with both header and body 
canonicalization (headers are particular problem in HTTP due to 
intermediaries, caches etc).

-- 
Cyrus Daboo


From msporny@digitalbazaar.com  Sat Apr 20 20:20:04 2013
Return-Path: <msporny@digitalbazaar.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D8121F8ECB; Sat, 20 Apr 2013 20:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level: 
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgmBYBvYpaVV; Sat, 20 Apr 2013 20:20:02 -0700 (PDT)
Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 73F9F21F89FB; Sat, 20 Apr 2013 20:20:02 -0700 (PDT)
Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from <msporny@digitalbazaar.com>) id 1UTkoh-0001UP-WB; Sat, 20 Apr 2013 23:19:54 -0400
Message-ID: <51735AD2.9040900@digitalbazaar.com>
Date: Sat, 20 Apr 2013 23:19:46 -0400
From: Manu Sporny <msporny@digitalbazaar.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <5170652F.60609@digitalbazaar.com> <5171233D.303@cs.tcd.ie>
In-Reply-To: <5171233D.303@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sun, 21 Apr 2013 08:06:29 -0700
Cc: IETF HTTP Auth <http-auth@ietf.org>, Mark Cavage <mark.cavage@joyent.com>, Web Payments CG <public-webpayments@w3.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] [http-auth] Web Keys and HTTP Signatures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Apr 2013 03:20:04 -0000

On 04/19/2013 06:58 AM, Stephen Farrell wrote:
>> HTTP Origin-Bound Authentication (HOBA) 
>> http://tools.ietf.org/id/draft-farrell-httpbis-hoba-02.txt
>> 
>> We had considered signatures in the URL in the second approach to
>> the problem in the Web Keys spec. We eventually rejected the
>> solution because of limitations in the URL length in some browsers
>> and because we wanted the semantics of the HTTP headers to be able
>> to be a part of the digital signature. We also didn't want large
>> signed messages being dumped to the webserver logs (the request
>> line is typically included). So, while HOBA does solve the problem,
>> it doesn't solve it in a way that is acceptable to us.
> 
> I think you're misreading the spec a little, or we've written it
> badly:-)

I did misread the spec a bit, confusing some of the features in other
HTTP Auth specs with some of the HOBA features. So, I took tonight to do
a thorough review of the spec and outline the issues that we have with
the current HOBA spec located at:

http://tools.ietf.org/html/draft-farrell-httpbis-hoba-02

I do agree that we should chat a bit more deeply about HOBA, Web Keys,
Persona, and HTTP Signatures. So, please take this not as negative
feedback, but constructive criticism and the first exchange toward
attempting to map out a way forward for these specs.

Here's the HOBA spec review from a Web Keys / Web Payments perspective:

1.  Introduction
----------------

> HOBA also defines some services that are required for modern HTTP 
> authentication:
> 
> o  Servers can bind a CPK with an identifier, such as an account 
> name.  HOBA allows servers to define their own policies for binding
> CPKs with accounts during account registration.

While a bit vague, we want to ensure that there is a well-defined way to
do this. We're currently in the process of discussing how this should
happen with the Mozilla Persona team. Ideally, the CPKs are setup or
transmitted to the server when a Persona-like login exchange happens.
We'd like to provide CPKs via some sort of identity expressed as Linked
Data, like the sort that's defined in the Web Keys spec:

curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu

> o  Users are likely to use more than one device or user agent (UA) 
> for the same HTTP based service, so HOBA gives a way to associate 
> more than one CPK to the same account, but without having to register
> for each separately.

+1, the approach above is how we accomplish this for Web Keys.

> o  Users are also likely to lose a private key, or the client's 
> memory of which key pair is associated with which origin.  For 
> example if a user loses the computer or mobile device in which state
> is stored.  HOBA allows for clients to tell servers to delete the
> association between a CPK and an account.

We took this approach 3+ years ago and quickly found that it would be a
nightmare to have to contact every server that you've performed a login
on to delete the association. Even worse, if you don't do this and the
key is compromised, you enable the attacker to gain access to the server
without your knowledge.

Instead, the server should track an "identity" and that identity will
have keys that are currently valid, or that have been revoked (like the
following):

curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu/keys/3

The server MUST check the validity of a key before allowing login. There
could be cache values / E-Tags associated with keys to make sure that
they're being properly cached via HTTP proxies.

> o  Logout features can be useful for user agents, so HOBA defines a 
> way to close a current HTTP "session", and also a way to close all 
> current sessions, even if more than one session is currently active
> from different user agents for the same account.

Session management absolutely should not be a part of the base
specification on HTTP Signatures. It should be layered on top of HTTP
signatures. I realize that HOBA might be doing this to "solve" the
session login problem on the Web via HTTP Auth once and for all, but
this is at the wrong level of abstraction. You can implement sessions on
top of HTTP Signatures any way that you would like (session cookies,
HTTP headers carrying session information, URL query parameters with
session information, etc.).

There should be a separation between HTTP Signatures and HTTP session
management.

1.2.  Terminology
-----------------

> also optionally include an HTTP "realm" as defined in the HTTP 
> authentication specification.

We don't use realm as most Access Control List (ACL) systems require far
more complicated forms of specifying what the client can and cannot do
with a particular CPK.

For example, look at the way OAuth is used in Twitter. When you provide
a website with a particular OAuth token, you can grant them a number of
privileges wrt. your account: let them see my e-mail address, let them
tweet on my behalf, let them see my followers, let them see my profile
information, etc. These sorts of access grants rarely fit nicely into a
"realm" field. We think ACL should be a completely separate spec that is
layered on top of HTTP Signatures or HOBA. We don't think it is a good
idea to solve the problem at this level.

2.  HOBA for Both HTTP Authentication and JavaScript
----------------------------------------------------

> On receipt of a challenge from a server, the client marshals a
> to-be- signed blob that includes the web-origin name, the realm, and
> the challenge string; and signs that hashed blob using the hash
> algorithm identified with the challenge and the private key
> corresponding to the CPK for that web-origin.

Yikes, this stomps all over the work that Mozilla is doing on Persona
(and not in a good way). They seem to have a good solution for this, we
should build off of that. The Javascript implementation of HOBA is also
a hack in that it shoves authentication parameters into the URL and we
/definitely/ don't want a Web where that becomes the norm. If this stuff
is going to be integrated into the browser, we should not create a
solution that makes it difficult for that to happen.

The solution shouldn't have a JavaScript-version and an HTTP-version. It
should all run over HTTP, especially since the very large majority of
JavaScript environments are capable of accessing and writing HTTP headers.

3.  HOBA HTTP Authentication Mechanism
--------------------------------------

> On receipt of a challenge from a server, the client marshals a
> to-be- signed blob that includes the web-origin name, the realm, and
> the challenge string; and signs that hashed blob using the hash
> algorithm identified with the challenge and the private key
> corresponding to the CPK for that web-origin.

This challenge-response-session approach is a tried and true design, but
one that's fairly inefficient in that it requires multiple round-trips
in the common case between server and client to perform a single
authenticated operation.

The Web Keys specification takes a different approach in that the server
does not need to provide a challenge because the client includes a
client-specific time-boxed nonce. The nonce is guaranteed to increment
so replay attacks are prevented as long as the server tracks the nonces
correctly, which is the same requirement that TLS has. Only the latest
nonce per client needs to be tracked for a certain period of time, e.g.
5 minutes, which greatly reduces memory overhead on the server.

The downside is that both client and server must have their clocks
fairly closely aligned, which is not necessarily a terrible requirement
given the state of modern timekeeping technology on the Internet. In the
very worst case, the protocol could be expanded such that the server
provides a clock timestamp that the client can use to calculate it's own
clock skew based on the server's current clock.

Using a Linked Data-based identity coupled with an HTTP Signature and a
time-boxed nonce allows a client to make a direct signed request to a
server in 1 HTTP exchange instead of 2.

This is a fairly sharp deviation between the Web Keys + HTTP Signatures
spec and the HOBA spec.

4.  Using HOBA-http
-------------------

> 4.1.  CPK Preparation Phase
> 
> In the CPK preparation phase, the client determines if it already
> has a CPK for the web-origin it is going to.  If the has a CPK, the 
> client will use it; if the client does not have a CPK, it generates 
> one in anticipation of the server asking for one.

With Web Keys, the client does not create a new CPK for every
web-origin. It creates a single CPK for each identity associated with
the client.

With HOBA, providing a new key for every website that the client visits
is overkill and would result in a key management nightmare for the
person using a browser. Dialogs would include dozens of keys in the
average case, which would be a bit of a usability nightmare.

The Web Keys approach is to provide every identity on each device a key.
So, if you visit google.com and you have one personal identity and one
professional identity, and you use both on your home computer, then your
home computer would have two keys regardless of the number of websites
that you visit. Those keys would be tied to each public Linked Data
identity.

> 4.2.  Signing Phase
> 
> The user agent tries to access a protected resource on the server. 
> The server sends the HOBA WWW-Authenticate challenge.  The user
> agent receives the challenge and signs the challenge using the CPK
> it either already had or just generated.  The server validates the 
> signature.  If validation fails, the server aborts the transaction.

As explained above, the Web Keys + HTTP Signature approach is to not
utilize a challenge-response approach, but rather a Linked Data identity
coupled with a client-specific time-boxed nonce to achieve the same
level of protection.

There /could/ be a Web Keys WWW-Authenticate message, but all that would
do would be to notify the client that a Web Keys-based authentication
should be performed when communicating with the server.

> 4.3.  Authentication Phase
> 
> In the authentication phase, the server extracts the CPK from the 
> signing phase and decides if it recognizes the CPK.  If the server 
> recognizes the CPK, the server may finish the client authentication 
> process.

Since the Web Keys specification uses a URL to express the key used for
the digital signature, a server can discover the identity associated
with the key pretty easily. For example, if this key was specified in
the HTTP Signature: https://dev.payswarm.com/i/manu/keys/3

The server would get the key:

curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu/keys/3

look for the owner of the key in the data, which would be:

https://dev.payswarm.com/i/manu

fetch that profile:

curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu

and then see if it has that identity on record as having an account on
the server. If it does, then it would verify that the key is owned by
the profile and check the validity of the signature.

4.3.  Authentication Phase
--------------------------

The last part of the first paragraph and the last 3 paragraphs should
just say that each topic covered is out of scope. The vast majority of
this section deals with things that are out of scope for HOBA (and most
HTTP Auth schemes).

4.4.  Logging in on a New User Agent
------------------------------------

The vast majority of this section is out of scope for this spec as well.

5.  Using HOBA-js
-----------------

I don't understand why HOBA-http cannot be accomplished via JavaScript
and XHR? Why do you need an entirely different way of encoding the HOBA
protocol using only URL-based parameters?

Unless I'm missing something, the entirety of this section is at the
wrong level of abstraction and unnecessary.

6.1.  Registration
------------------

This section is interesting because we've been struggling to figure out
a way to have UAs automatically (or semi-automatically) create accounts
on new web-origins. That said, Mozilla Persona is far ahead of us here,
so we should probably just fall in line w/ what they're doing.

6.2.  Associating Additional Keys to an Exiting Account
-------------------------------------------------------

As explained above, this is unnecessary if you use a Linked Data
identity like Web Keys does. You never have to add additional keys to an
existing account because the person accessing the site has already
paired their device with a key using their Identity Provider. When they
hit a web-origin, that association is already complete, therefore there
is nothing for the web-origin to do except lookup the key and the
identity. In effect, that key is automatically picked up by every
website that accesses the Linked Data identity.

6.3.  Logging Out
-----------------

Again, this is at the wrong level of abstraction, at least as far as Web
Keys and HTTP Signatures are concerned. If HOBA is to become a standard
way of doing HTTP session management, then this would be fine. That
said, I think you'll be competing with Mozilla Persona at that point.

-----------------------------------------------------------------------

Hopefully this is helpful to the HOBA editors. I'm having a chat with
one of the editors next week and I wanted to make sure to get this out
there so he has time to review the comments before our chat.

Again, this was just a friendly review of the spec before we try to
figure out how we can coordinate this activity between W3C and IETF.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

From salvatore.dantonio@uniparthenope.it  Sat Apr 20 17:06:26 2013
Return-Path: <salvatore.dantonio@uniparthenope.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DB221F8A00; Sat, 20 Apr 2013 17:06:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.035
X-Spam-Level: ****
X-Spam-Status: No, score=4.035 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, MSGID_MULTIPLE_AT=1.449, RCVD_ILLEGAL_IP=1.908]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUw3hRp9HRmG; Sat, 20 Apr 2013 17:06:24 -0700 (PDT)
Received: from mail.uniparthenope.it (mail.uniparthenope.it [192.167.9.244]) by ietfa.amsl.com (Postfix) with ESMTP id B657E21F888F; Sat, 20 Apr 2013 17:06:23 -0700 (PDT)
Received: from mail2.uniparthenope.it (unknown [10.1.2.108]) by mail.uniparthenope.it (Postfix) with SMTP id D0D4F42536; Sun, 21 Apr 2013 00:06:22 +0000 (UTC)
Received: from (unknown [192.168.241.108]) by mail2.uniparthenope.it with smtp id 1da8_4bd40ed6_aa17_11e2_9101_001372515a5c; Sun, 21 Apr 2013 02:06:21 +0200
Received: from spamk.uniparthenope.it (localhost [127.0.0.1]) by spamk.uniparthenope.it (Postfix) with ESMTP id 781BFC432C; Sun, 21 Apr 2013 02:06:20 +0200 (CEST)
Received: by spamk.uniparthenope.it (Postfix, from userid 500) id 5D40EC4351; Sun, 21 Apr 2013 02:06:20 +0200 (CEST)
Received: from mail.uniparthenope.it (unknown [192.168.241.109]) by spamk.uniparthenope.it (Postfix) with ESMTP id B34CAC4377; Sun, 21 Apr 2013 02:06:13 +0200 (CEST)
Received: by mail.uniparthenope.it (Postfix, from userid 108) id 9DFC0421AD; Sun, 21 Apr 2013 02:06:13 +0200 (CEST)
Received: from saldantoPC (unknown [2.237.123.176]) (Authenticated sender: salvatore.dantonio@uniparthenope.it) by mail.uniparthenope.it (Postfix) with ESMTPA id ABE80421AD; Sun, 21 Apr 2013 02:06:11 +0200 (CEST)
From: "Salvatore D'Antonio" <salvatore.dantonio@uniparthenope.it>
To: "'Benoit Claise'" <bclaise@cisco.com>
References: <20130401072846.32360.9502.idtracker@ietfa.amsl.com> <5162C44B.5030904@cisco.com> <005701ce3538$8f0b3480$ad219d80$@dantonio@uniparthenope.it> <516BCB97.9040404@cisco.com>
In-Reply-To: <516BCB97.9040404@cisco.com>
Date: Sun, 21 Apr 2013 02:06:14 +0200
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac45veJiRHrdfH9cTm69S7sEnZNliAEY1GBQ
Content-Language: it
Message-ID: <001001ce3e24$0a931840$1fb948c0$@dantonio@uniparthenope.it>
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01CE3E34.CE1BE840"
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.42/RELEASE, bases: 20130420 #9915320, check: 20130421 clean
X-Mailman-Approved-At: Sun, 21 Apr 2013 08:06:39 -0700
Cc: rahulp@cisco.com, 'IETF discussion list' <ietf@ietf.org>, draft-ietf-ipfix-flow-selection-tech@tools.ietf.org, apps-discuss@ietf.org, 'General Area Review Team' <gen-art@ietf.org>, 'S Moonesamy' <sm+ietf@elandsys.com>, ipfix-chairs@tools.ietf.org, ipfix@ietf.org, iesg@ietf.org, "'Joel M. Halpern'" <jmh@joelhalpern.com>, "'A. Jean Mahoney'" <mahoney@nostrum.com>
Subject: [apps-discuss] R: R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Apr 2013 00:06:26 -0000

Messaggio multipart in formato MIME.

------=_NextPart_000_0011_01CE3E34.CE1BE840
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Dear Benoit, all

=20

I submitted v16 of the Internet Draft.

=20

I modified section 9.1.1 on the maintenance of the flowSelectorAlgorithm =
registry and fixed the editorial issue in section  6.1.1

=20

I have also used MUST in section 6.1

=20

Best regards,

=20

Salvatore

=20

=20

Da: Benoit Claise [mailto:bclaise@cisco.com]=20
Inviato: luned=C3=AC 15 aprile 2013 11:43
A: Salvatore D'Antonio
Cc: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org; =
ipfix-chairs@tools.ietf.org; 'S Moonesamy'; apps-discuss@ietf.org; =
iesg@ietf.org; 'Joel M. Halpern'; 'A. Jean Mahoney'; 'General Area =
Review Team'; 'IETF discussion list'; rahulp@cisco.com; ipfix@ietf.org
Oggetto: Re: R: Last Call Expired: =
<draft-ietf-ipfix-flow-selection-tech-14.txt>

=20

Salvatore

Dear all,

=20

A new version of the Internet Draft on Flow Selection Techniques has =
been submitted. It contains the following changes:

-          A new section illustrating the difference between =
Intermediate Flow Selection Process and Intermediate Selection Process =
has been added,

-          The sentence "In order to be compliant with this document, at =
least the Property  Match Filtering MUST be implemented." has been =
removed in Section 1,

-          =E2=80=9CMUST=E2=80=9D has been replaced with =
=E2=80=9CSHOULD=E2=80=9D in Section 5.1,

Actually, the feedback was:

In Section 1:=20

  "In order to be compliant with this document, at least the Property=20
   Match Filtering MUST be implemented."=20

The above text is repeated in Section 5.1.  I suggest removing this =
sentence as it does not seem related to scope.=20

My reading of the "MUST" is that it is being used for compliance instead =
of the reasons described in RFC 2119.  I suggest reviewing the usage of =
RFC 2119 key words in Section 5.1.=20

So the solution is not to change MUST to SHOULD.
The question is whether "MUST" versus "must" must be used.
I understand the concern. For compliance reason with the PSAMP RFC 5475 =
(which is closely related) ...


 <http://tools.ietf.org/html/rfc5475#section-7> 7.  Parameters for the =
Description of Selection Techniques

   This section gives an overview of different alternative selection
   schemes and their required parameters.  In order to be compliant with
   PSAMP, at least one of proposed schemes MUST be implemented.
=20

... I would keep the initial "MUST" from the previous draft version.=20

-          =E2=80=9CThe flowSelectorAlgorithm registry is maintained by =
IANA." has been replaced with =E2=80=9CIANA is requested to create the =
flowSelectorAlgorithm registry.=E2=80=9D

-          The sentence "The registry can be updated when specifications =
of the new  technique(s) and any new Information Elements are provided." =
has been removed since it did not clarify how the registry will be =
managed.

-           Section 6.1.1 =E2=80=9CProperty Match Filtering=E2=80=9D has =
been changed by adding some text on how Property Match Filtering can be  =
used by an Intermediate Flow Selection Process in the Metering Process, =
in the  Exporting Process and within an IPFIX Mediator.

When publishing a new version, please correct this editorial issue.

 " ... and Flow duration. in
   the An example is the selection of the largest ..."





=20

Best regards,

=20

Salvatore

=20

Da: Benoit Claise [mailto:bclaise@cisco.com]=20
Inviato: luned=C3=AC 8 aprile 2013 15:21
A: draft-ietf-ipfix-flow-selection-tech@tools.ietf.org
Cc: ipfix-chairs@tools.ietf.org
Oggetto: Fwd: Last Call Expired: =
<draft-ietf-ipfix-flow-selection-tech-14.txt>

=20

Dear authors,

The IETF last call has finished.
Can you please update your draft based on the feedback received.
Then I will progress it.

Regards, Benoit



-------- Original Message --------=20


Subject:=20

Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>


Date:=20

Mon, 01 Apr 2013 00:28:46 -0700


From:=20

DraftTracker Mail System  <mailto:iesg-secretary@ietf.org> =
<iesg-secretary@ietf.org>


To:=20

iesg@ietf.org, ipfix-chairs@tools.ietf.org, =
draft-ietf-ipfix-flow-selection-tech@tools.ietf.org


CC:=20

iesg-secretary@ietf.org

=20

Please DO NOT reply to this email.
=20
I-D: <draft-ietf-ipfix-flow-selection-tech-14.txt>
ID Tracker URL: =
http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/
=20
IETF Last Call has ended, and the state has been changed to
Waiting for AD Go-Ahead.
=20
=20
=20

=20

=20

  _____ =20

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di =
rilascio: 07/04/2013





*************************************************************************=
******************************

IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO

=20

Il 5 per mille all'Universit=C3=A0 degli Studi di Napoli =
"Parthenope"incrementa le borse di studio agli studenti - codice fiscale =
80018240632=20

 <http://www.uniparthenope.it/index.php/5xmille> =
http://www.uniparthenope.it/index.php/5xmille=20

=20

 =
<http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-p=
arthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-d=
el-5-per-mille> =
http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-pa=
rthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-de=
l-5-per-mille

=20
Questa informativa =C3=A8 inserita in automatico dal sistema al fine =
esclusivo della realizzazione dei fini istituzionali dell'ente.

=20






*************************************************************************=
******************************

IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO

=20

Il 5 per mille all'Universit=C3=A0 degli Studi di Napoli =
"Parthenope"incrementa le borse di studio agli studenti - codice fiscale =
80018240632=20

 <http://www.uniparthenope.it/index.php/5xmille> =
http://www.uniparthenope.it/index.php/5xmille=20

=20

 =
<http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-p=
arthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-d=
el-5-per-mille> =
http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-pa=
rthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-de=
l-5-per-mille

=20
Questa informativa =C3=A8 inserita in automatico dal sistema al fine =
esclusivo della realizzazione dei fini istituzionali dell'ente.

=20

=20

=20


******************************************************************************=09=0A
IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO=0A
 =0A
Il 5 per mille all'Universita' degli Studi di Napoli "Parthenope" incrementa le borse di studio agli studenti - codice fiscale 80018240632=0A
http://www.uniparthenope.it/index.php/5xmille =0A
 =0A
http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille=0A
 =0A
Questa informativa e' inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente.=0A

------=_NextPart_000_0011_01CE3E34.CE1BE840
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Consolas;
	panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
	{font-family:"Segoe UI";
	panose-1:2 11 5 2 4 2 4 2 2 3;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
h2
	{mso-style-priority:9;
	mso-style-link:"Titolo 2 Carattere";
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:18.0pt;
	font-family:"Times New Roman","serif";
	color:black;
	font-weight:bold;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	margin-bottom:5.95pt;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
pre
	{mso-style-priority:99;
	mso-style-link:"Preformattato HTML Carattere";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";
	color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
span.PreformattatoHTMLCarattere
	{mso-style-name:"Preformattato HTML Carattere";
	mso-style-priority:99;
	mso-style-link:"Preformattato HTML";
	font-family:Consolas;
	color:black;}
span.StileMessaggioDiPostaElettronica20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.h2
	{mso-style-name:h2;}
span.Titolo2Carattere
	{mso-style-name:"Titolo 2 Carattere";
	mso-style-priority:9;
	mso-style-link:"Titolo 2";
	font-family:"Cambria","serif";
	color:#4F81BD;
	font-weight:bold;}
p.western, li.western, div.western
	{mso-style-name:western;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	margin-bottom:5.95pt;
	margin-left:0cm;
	font-size:8.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
p.cjk, li.cjk, div.cjk
	{mso-style-name:cjk;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	margin-bottom:5.95pt;
	margin-left:0cm;
	font-size:8.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
p.ctl, li.ctl, div.ctl
	{mso-style-name:ctl;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	margin-bottom:5.95pt;
	margin-left:0cm;
	font-size:8.0pt;
	font-family:"Times New Roman","serif";
	color:black;}
span.StileMessaggioDiPostaElettronica27
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 2.0cm 2.0cm 2.0cm;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:217212090;
	mso-list-type:hybrid;
	mso-list-template-ids:308057158 -1513439274 134807555 134807557 =
134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
	{mso-level-start-at:0;
	mso-level-number-format:bullet;
	mso-level-text:-;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;}
@list l0:level2
	{mso-level-tab-stop:72.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level3
	{mso-level-tab-stop:108.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level4
	{mso-level-tab-stop:144.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level5
	{mso-level-tab-stop:180.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level6
	{mso-level-tab-stop:216.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level7
	{mso-level-tab-stop:252.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level8
	{mso-level-tab-stop:288.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l0:level9
	{mso-level-tab-stop:324.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-GB link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Dear Benoit, all<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I submitted v16 of the Internet =
Draft.<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I modified section 9.1.1 on the maintenance of the =
flowSelectorAlgorithm
registry and fixed the editorial issue in section =
=C2=A06.1.1<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I have also used MUST in section =
6.1<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Best regards,<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Salvatore<o:p></o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0cm 0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DIT =
style=3D'font-size:10.0pt;font-family:"Segoe UI","sans-serif";
color:windowtext'>Da:</span></b><span lang=3DIT =
style=3D'font-size:10.0pt;
font-family:"Segoe UI","sans-serif";color:windowtext'> Benoit Claise
[mailto:bclaise@cisco.com] <br>
<b>Inviato:</b> luned=C3=AC 15 aprile 2013 11:43<br>
<b>A:</b> Salvatore D'Antonio<br>
<b>Cc:</b> draft-ietf-ipfix-flow-selection-tech@tools.ietf.org;
ipfix-chairs@tools.ietf.org; 'S Moonesamy'; apps-discuss@ietf.org;
iesg@ietf.org; 'Joel M. Halpern'; 'A. Jean Mahoney'; 'General Area =
Review
Team'; 'IETF discussion list'; rahulp@cisco.com; ipfix@ietf.org<br>
<b>Oggetto:</b> Re: R: Last Call Expired:
&lt;draft-ietf-ipfix-flow-selection-tech-14.txt&gt;<o:p></o:p></span></p>=


</div>

</div>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<div>

<p class=3DMsoNormal>Salvatore<o:p></o:p></p>

</div>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Dear all,</span><o:p></o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>A new version of the Internet Draft on Flow Selection =
Techniques
has been submitted. It contains the following =
changes:</span><o:p></o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo2'><![if !supportLists]><span
style=3D'font-family:"Calibri","sans-serif"'><span =
style=3D'mso-list:Ignore'>-<span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>A new section illustrating the difference between =
Intermediate Flow
Selection Process and Intermediate Selection Process has been =
added,</span><o:p></o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo2'><![if !supportLists]><span
style=3D'font-family:"Calibri","sans-serif"'><span =
style=3D'mso-list:Ignore'>-<span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The sentence &quot;In order to be compliant with this =
document,
at least the Property &nbsp;Match Filtering MUST be implemented.&quot; =
has been
removed in Section 1,</span><o:p></o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo2'><![if !supportLists]><span
style=3D'font-family:"Calibri","sans-serif"'><span =
style=3D'mso-list:Ignore'>-<span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>=E2=80=9CMUST=E2=80=9D has been replaced with =
=E2=80=9CSHOULD=E2=80=9D in Section 5.1,</span><o:p></o:p></p>

</blockquote>

<p class=3DMsoNormal>Actually, the feedback was:<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>In Section 1: <br>
<br>
&nbsp; &quot;In order to be compliant with this document, at least the =
Property
<br>
&nbsp;&nbsp; Match Filtering MUST be implemented.&quot; <br>
<br>
The above text is repeated in Section 5.1.&nbsp; I suggest removing this =
sentence
as it does not seem related to scope. <br>
<br>
My reading of the &quot;MUST&quot; is that it is being used for =
compliance
instead of the reasons described in RFC 2119.&nbsp; I suggest reviewing =
the
usage of RFC 2119 key words in Section 5.1. <o:p></o:p></p>

<p class=3DMsoNormal>So the solution is not to change MUST to =
SHOULD.<br>
The question is whether &quot;MUST&quot; versus &quot;must&quot; must be =
used.<br>
I understand the concern. For compliance reason with the PSAMP RFC 5475 =
(which
is closely related) ...<o:p></o:p></p>

<h2><a name=3Dsection-7></a><a =
href=3D"http://tools.ietf.org/html/rfc5475#section-7"><span
style=3D'font-family:"Courier New"'>7</span></a><span =
style=3D'font-family:"Courier New"'>.=C2=A0
Parameters for the Description of Selection =
Techniques<o:p></o:p></span></h2>

<pre>=C2=A0=C2=A0 This section gives an overview of different =
alternative selection<o:p></o:p></pre><pre>=C2=A0=C2=A0 schemes and =
their required parameters.=C2=A0 In order to be compliant =
with<o:p></o:p></pre><pre>=C2=A0=C2=A0 PSAMP, at least one of proposed =
schemes MUST be =
implemented.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre>

<p class=3DMsoNormal>... I would keep the initial &quot;MUST&quot; from =
the
previous draft version. <o:p></o:p></p>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo2'><![if !supportLists]><span
style=3D'font-family:"Calibri","sans-serif"'><span =
style=3D'mso-list:Ignore'>-<span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>=E2=80=9CThe flowSelectorAlgorithm registry is maintained =
by IANA.&quot;
has been replaced with =E2=80=9CIANA is requested to create the =
flowSelectorAlgorithm
registry.=E2=80=9D</span><o:p></o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo2'><![if !supportLists]><span
style=3D'font-family:"Calibri","sans-serif"'><span =
style=3D'mso-list:Ignore'>-<span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>The sentence &quot;The registry can be updated when
specifications of the new&nbsp; technique(s) and any new Information =
Elements
are provided.&quot; has been removed since it did not clarify how the =
registry
will be managed.</span><o:p></o:p></p>

<p class=3DMsoListParagraph style=3D'text-indent:-18.0pt;mso-list:l0 =
level1 lfo2'><![if !supportLists]><span
style=3D'font-family:"Calibri","sans-serif"'><span =
style=3D'mso-list:Ignore'>-<span
style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;Section 6.1.1 =E2=80=9CProperty Match =
Filtering=E2=80=9D has been changed
by adding some text on how Property Match Filtering can be &nbsp;used by =
an
Intermediate Flow Selection Process in the Metering Process, in the
&nbsp;Exporting Process and within an IPFIX =
Mediator.</span><o:p></o:p></p>

</blockquote>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>When publishing a =
new version,
please correct this editorial issue.<o:p></o:p></p>

<pre>=C2=A0&quot; ... and Flow duration. =
in<o:p></o:p></pre><pre>=C2=A0=C2=A0 the An example is the selection of =
the largest ...&quot;<o:p></o:p></pre>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Best regards,</span><o:p></o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Salvatore</span><o:p></o:p></p>

<p class=3DMsoNormal><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;</span><o:p></o:p></p>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt =
0cm 0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DIT =
style=3D'font-size:10.0pt'>Da:</span></b><span
lang=3DIT style=3D'font-size:10.0pt'> Benoit Claise [<a
href=3D"mailto:bclaise@cisco.com">mailto:bclaise@cisco.com</a>] <br>
<b>Inviato:</b> luned=C3=AC 8 aprile 2013 15:21<br>
<b>A:</b> <a =
href=3D"mailto:draft-ietf-ipfix-flow-selection-tech@tools.ietf.org">draft=
-ietf-ipfix-flow-selection-tech@tools.ietf.org</a><br>
<b>Cc:</b> <a =
href=3D"mailto:ipfix-chairs@tools.ietf.org">ipfix-chairs@tools.ietf.org</=
a><br>
<b>Oggetto:</b> Fwd: Last Call Expired: =
&lt;draft-ietf-ipfix-flow-selection-tech-14.txt&gt;</span><o:p></o:p></p>=


</div>

</div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

<p class=3DMsoNormal>Dear authors,<br>
<br>
The IETF last call has finished.<br>
Can you please update your draft based on the feedback received.<br>
Then I will progress it.<br>
<br>
Regards, Benoit<o:p></o:p></p>

<div>

<p class=3DMsoNormal><br>
<br>
-------- Original Message -------- <o:p></o:p></p>

<table class=3DMsoNormalTable border=3D0 cellspacing=3D0 =
cellpadding=3D0>
 <tr>
  <td nowrap valign=3Dtop style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal align=3Dright =
style=3D'text-align:right'><b>Subject: </b><o:p></o:p></p>
  </td>
  <td style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal>Last Call Expired:
  &lt;draft-ietf-ipfix-flow-selection-tech-14.txt&gt;<o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td nowrap valign=3Dtop style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><b>Date: =
</b><o:p></o:p></p>
  </td>
  <td style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal>Mon, 01 Apr 2013 00:28:46 -0700<o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td nowrap valign=3Dtop style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><b>From: =
</b><o:p></o:p></p>
  </td>
  <td style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal>DraftTracker Mail System <a
  =
href=3D"mailto:iesg-secretary@ietf.org">&lt;iesg-secretary@ietf.org&gt;</=
a><o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td nowrap valign=3Dtop style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><b>To: =
</b><o:p></o:p></p>
  </td>
  <td style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal><a =
href=3D"mailto:iesg@ietf.org">iesg@ietf.org</a>, <a
  =
href=3D"mailto:ipfix-chairs@tools.ietf.org">ipfix-chairs@tools.ietf.org</=
a>, <a
  =
href=3D"mailto:draft-ietf-ipfix-flow-selection-tech@tools.ietf.org">draft=
-ietf-ipfix-flow-selection-tech@tools.ietf.org</a><o:p></o:p></p>
  </td>
 </tr>
 <tr>
  <td nowrap valign=3Dtop style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal align=3Dright style=3D'text-align:right'><b>CC: =
</b><o:p></o:p></p>
  </td>
  <td style=3D'padding:0cm 0cm 0cm 0cm'>
  <p class=3DMsoNormal><a =
href=3D"mailto:iesg-secretary@ietf.org">iesg-secretary@ietf.org</a><o:p><=
/o:p></p>
  </td>
 </tr>
</table>

<p class=3DMsoNormal =
style=3D'margin-bottom:12.0pt'>&nbsp;<o:p></o:p></p>

<pre>Please DO NOT reply to this =
email.<o:p></o:p></pre><pre>&nbsp;<o:p></o:p></pre><pre>I-D: =
&lt;draft-ietf-ipfix-flow-selection-tech-14.txt&gt;<o:p></o:p></pre><pre>=
ID Tracker URL: <a
href=3D"http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-t=
ech/">http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tec=
h/</a><o:p></o:p></pre><pre>&nbsp;<o:p></o:p></pre><pre>IETF Last Call =
has ended, and the state has been changed =
to<o:p></o:p></pre><pre>Waiting for AD =
Go-Ahead.<o:p></o:p></pre><pre>&nbsp;<o:p></o:p></pre><pre>&nbsp;<o:p></o=
:p></pre><pre>&nbsp;<o:p></o:p></pre>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

</div>

<p class=3DMsoNormal>&nbsp;<o:p></o:p></p>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

<hr size=3D1 width=3D"100%" noshade style=3D'color:#A0A0A0' =
align=3Dcenter>

</div>

<p class=3DMsoNormal =
style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Nessun
virus nel messaggio.<br>
Controllato da AVG - <a href=3D"http://www.avg.com">www.avg.com</a><br>
Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di =
rilascio:
07/04/2013<o:p></o:p></p>

<p class=3DMsoNormal><br>
<br>
<o:p></o:p></p>

<p class=3Dwestern =
style=3D'margin-bottom:0cm;margin-bottom:.0001pt'><span
style=3D'font-family:"Arial","sans-serif"'>******************************=
*************************************************************************=
</span><o:p></o:p></p>

<p class=3Dwestern =
style=3D'margin-bottom:0cm;margin-bottom:.0001pt'><span
style=3D'font-family:"Arial","sans-serif"'>IL MERITO DEGLI =
STUDENTI&nbsp;VIENE
RICONOSCIUTO</span><o:p></o:p></p>

<p class=3Dwestern =
style=3D'margin-bottom:0cm;margin-bottom:.0001pt'>&nbsp;<o:p></o:p></p>

<p class=3Dwestern =
style=3D'margin-bottom:0cm;margin-bottom:.0001pt'><span
style=3D'font-family:"Arial","sans-serif"'>Il 5 per mille =
all'Universit=C3=A0 degli
Studi di Napoli &quot;Parthenope&quot;incrementa le borse di studio agli
studenti - codice fiscale <b>80018240632</b> </span><o:p></o:p></p>

<p class=3Dwestern style=3D'margin-bottom:0cm;margin-bottom:.0001pt'><a
href=3D"http://www.uniparthenope.it/index.php/5xmille"><span =
style=3D'font-family:
"Arial","sans-serif"'>http://www.uniparthenope.it/index.php/5xmille</span=
></a><span
style=3D'font-family:"Arial","sans-serif"'>&nbsp;</span><o:p></o:p></p>

<p class=3Dwestern =
style=3D'margin-bottom:0cm;margin-bottom:.0001pt'>&nbsp;<o:p></o:p></p>

<p class=3Dwestern style=3D'margin-bottom:0cm;margin-bottom:.0001pt'><a
href=3D"http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/29=
43-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-pro=
venti-del-5-per-mille"><span
style=3D'font-family:"Arial","sans-serif"'>http://www.uniparthenope.it/in=
dex.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di=
-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille</span></a><o:p><=
/o:p></p>

<p class=3Dwestern =
style=3D'margin-bottom:0cm;margin-bottom:.0001pt'>&nbsp;<span
style=3D'font-family:"Arial","sans-serif"'><br>
Questa informativa =C3=A8 inserita in automatico dal sistema al fine =
esclusivo della
realizzazione dei fini istituzionali dell'ente.</span><o:p></o:p></p>

<p class=3Dwestern =
style=3D'margin-bottom:0cm;margin-bottom:.0001pt'><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><br>
<br>
<br>
<o:p></o:p></p>

<p class=3Dwestern =
style=3D'margin-bottom:0cm;margin-bottom:.0001pt'><span
style=3D'font-family:"Arial","sans-serif"'>******************************=
*************************************************************************=
</span><o:p></o:p></p>

<p class=3Dwestern =
style=3D'margin-bottom:0cm;margin-bottom:.0001pt'><span
style=3D'font-family:"Arial","sans-serif"'>IL MERITO DEGLI =
STUDENTI&nbsp;VIENE
RICONOSCIUTO</span><o:p></o:p></p>

<p class=3Dwestern =
style=3D'margin-bottom:0cm;margin-bottom:.0001pt'>&nbsp;<o:p></o:p></p>

<p class=3Dwestern =
style=3D'margin-bottom:0cm;margin-bottom:.0001pt'><span
style=3D'font-family:"Arial","sans-serif"'>Il 5 per mille =
all'Universit=C3=A0 degli
Studi di Napoli &quot;Parthenope&quot;incrementa le borse di studio agli
studenti - codice fiscale <b>80018240632</b> </span><o:p></o:p></p>

<p class=3Dwestern style=3D'margin-bottom:0cm;margin-bottom:.0001pt'><a
href=3D"http://www.uniparthenope.it/index.php/5xmille"><span =
style=3D'font-family:
"Arial","sans-serif"'>http://www.uniparthenope.it/index.php/5xmille</span=
></a><span
style=3D'font-family:"Arial","sans-serif"'>&nbsp;</span><o:p></o:p></p>

<p class=3Dwestern =
style=3D'margin-bottom:0cm;margin-bottom:.0001pt'>&nbsp;<o:p></o:p></p>

<p class=3Dwestern style=3D'margin-bottom:0cm;margin-bottom:.0001pt'><a
href=3D"http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/29=
43-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-pro=
venti-del-5-per-mille"><span
style=3D'font-family:"Arial","sans-serif"'>http://www.uniparthenope.it/in=
dex.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di=
-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille</span></a><o:p><=
/o:p></p>

<p class=3Dwestern =
style=3D'margin-bottom:0cm;margin-bottom:.0001pt'>&nbsp;<span
style=3D'font-family:"Arial","sans-serif"'><br>
Questa informativa =C3=A8 inserita in automatico dal sistema al fine =
esclusivo della
realizzazione dei fini istituzionali dell'ente.</span><o:p></o:p></p>

<p class=3Dwestern =
style=3D'margin-bottom:0cm;margin-bottom:.0001pt'><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>


<br>=
<STYLE TYPE=3D"text/css">=0A
=09<!--=0A
=09=09@page { margin-left: 2cm; margin-right: 2cm; margin-top: 2.5cm; margin-bottom: 2cm }=0A
=09=09P { margin-bottom: 0.21cm; direction: ltr; color: #000000; widows: 2; orphans: 2 }=0A
=09=09P.western { font-family: "Times New Roman", serif; font-size: 8pt; so-language: it-IT }=0A
=09=09P.cjk { font-family: "Times New Roman", serif; font-size: 8pt }=0A
=09=09P.ctl { font-family: "Times New Roman", serif; font-size: 8pt; so-language: ar-SA }=0A
=09=09A:link { color: #0000ff }=0A
=09-->=0A
=09</STYLE>=0A
<!--</HEAD></BODY>-->=0A
<P LANG=3D"it-IT" TEXT=3D"#000000" LINK=3D"#0000ff" DIR=3D"LTR">=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><FONT FACE=3D"Arial, sans-serif">*******************************************************************************************************</FONT></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><FONT FACE=3D"Arial, sans-serif">IL=0A
MERITO DEGLI STUDENTI&nbsp;VIENE RICONOSCIUTO</FONT></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm">&nbsp;</P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><FONT COLOR=3D"#000000"><FONT FACE=3D"Arial, sans-serif">Il=0A
5 per mille all'Universit&agrave degli Studi di Napoli &quot;Parthenope&quot;incrementa le borse di studio agli studenti=0A
- codice fiscale </FONT></FONT><FONT COLOR=3D"#000000"><FONT FACE=3D"Arial, sans-serif"><B>80018240632</B></FONT></FONT><FONT COLOR=3D"#000000"><FONT FACE=3D"Arial, sans-serif">=0A
</FONT></FONT>=0A
</P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><A HREF=3D"http://www.uniparthenope.it/index.php/5xmille"><FONT COLOR=3D"#0000ff"><FONT FACE=3D"Arial, sans-serif"><U>http://www.uniparthenope.it/index.php/5xmille</U></FONT></FONT></A><FONT COLOR=3D"#000000"><FONT FACE=3D"Arial, sans-serif">&nbsp;</FONT></FONT></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm">&nbsp;</P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><A HREF=3D"http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille"><FONT COLOR=3D"#0000ff"><FONT FACE=3D"Arial, sans-serif"><U>http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille</U></FONT></FONT></A></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm">&nbsp;<FONT FACE=3D"Arial, sans-serif"><BR>Questa=0A
informativa &egrave inserita in automatico dal sistema al fine esclusivo=0A
della realizzazione dei fini istituzionali dell&#39;ente.</FONT></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><BR>=0A
</P>=0A
<!--</BODY>-->=0A
<!--</HTML>-->=0A
<br>=
</body>

</html>

<br>=
<STYLE TYPE=3D"text/css">=0A
=09<!--=0A
=09=09@page { margin-left: 2cm; margin-right: 2cm; margin-top: 2.5cm; margin-bottom: 2cm }=0A
=09=09P { margin-bottom: 0.21cm; direction: ltr; color: #000000; widows: 2; orphans: 2 }=0A
=09=09P.western { font-family: "Times New Roman", serif; font-size: 8pt; so-language: it-IT }=0A
=09=09P.cjk { font-family: "Times New Roman", serif; font-size: 8pt }=0A
=09=09P.ctl { font-family: "Times New Roman", serif; font-size: 8pt; so-language: ar-SA }=0A
=09=09A:link { color: #0000ff }=0A
=09-->=0A
=09</STYLE>=0A
<!--</HEAD></BODY>-->=0A
<P LANG=3D"it-IT" TEXT=3D"#000000" LINK=3D"#0000ff" DIR=3D"LTR">=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><FONT FACE=3D"Arial, sans-serif">*******************************************************************************************************</FONT></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><FONT FACE=3D"Arial, sans-serif">IL=0A
MERITO DEGLI STUDENTI&nbsp;VIENE RICONOSCIUTO</FONT></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm">&nbsp;</P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><FONT COLOR=3D"#000000"><FONT FACE=3D"Arial, sans-serif">Il=0A
5 per mille all'Universit&agrave degli Studi di Napoli &quot;Parthenope&quot;incrementa le borse di studio agli studenti=0A
- codice fiscale </FONT></FONT><FONT COLOR=3D"#000000"><FONT FACE=3D"Arial, sans-serif"><B>80018240632</B></FONT></FONT><FONT COLOR=3D"#000000"><FONT FACE=3D"Arial, sans-serif">=0A
</FONT></FONT>=0A
</P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><A HREF=3D"http://www.uniparthenope.it/index.php/5xmille"><FONT COLOR=3D"#0000ff"><FONT FACE=3D"Arial, sans-serif"><U>http://www.uniparthenope.it/index.php/5xmille</U></FONT></FONT></A><FONT COLOR=3D"#000000"><FONT FACE=3D"Arial, sans-serif">&nbsp;</FONT></FONT></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm">&nbsp;</P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><A HREF=3D"http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille"><FONT COLOR=3D"#0000ff"><FONT FACE=3D"Arial, sans-serif"><U>http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille</U></FONT></FONT></A></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm">&nbsp;<FONT FACE=3D"Arial, sans-serif"><BR>Questa=0A
informativa &egrave inserita in automatico dal sistema al fine esclusivo=0A
della realizzazione dei fini istituzionali dell&#39;ente.</FONT></P>=0A
<P CLASS=3D"western" STYLE=3D"margin-bottom: 0cm"><BR>=0A
</P>=0A
<!--</BODY>-->=0A
<!--</HTML>-->=0A
<br>=
------=_NextPart_000_0011_01CE3E34.CE1BE840--

From stephen.farrell@cs.tcd.ie  Sun Apr 21 11:14:06 2013
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172B721F86EA; Sun, 21 Apr 2013 11:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsQrzvWNTM2g; Sun, 21 Apr 2013 11:14:04 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8E121F8411; Sun, 21 Apr 2013 11:14:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 39FBBBE60; Sun, 21 Apr 2013 19:13:41 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB3yYL5bFFAj; Sun, 21 Apr 2013 19:13:38 +0100 (IST)
Received: from [10.87.48.4] (unknown [86.42.31.67]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A83C7BE25; Sun, 21 Apr 2013 19:13:38 +0100 (IST)
Message-ID: <51742C51.1010003@cs.tcd.ie>
Date: Sun, 21 Apr 2013 19:13:37 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Manu Sporny <msporny@digitalbazaar.com>
References: <5170652F.60609@digitalbazaar.com> <5171233D.303@cs.tcd.ie> <51735AD2.9040900@digitalbazaar.com>
In-Reply-To: <51735AD2.9040900@digitalbazaar.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: IETF HTTP Auth <http-auth@ietf.org>, Mark Cavage <mark.cavage@joyent.com>, Web Payments CG <public-webpayments@w3.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] [http-auth] Web Keys and HTTP Signatures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Apr 2013 18:14:06 -0000

HI Manu,

Thanks for the thorough review. Some good points and
defo a bunch of things to check out... but not today:-)

I'll take a better look at this Monday,
Cheers,
S.

On 04/21/2013 04:19 AM, Manu Sporny wrote:
> On 04/19/2013 06:58 AM, Stephen Farrell wrote:
>>> HTTP Origin-Bound Authentication (HOBA) 
>>> http://tools.ietf.org/id/draft-farrell-httpbis-hoba-02.txt
>>>
>>> We had considered signatures in the URL in the second approach to
>>> the problem in the Web Keys spec. We eventually rejected the
>>> solution because of limitations in the URL length in some browsers
>>> and because we wanted the semantics of the HTTP headers to be able
>>> to be a part of the digital signature. We also didn't want large
>>> signed messages being dumped to the webserver logs (the request
>>> line is typically included). So, while HOBA does solve the problem,
>>> it doesn't solve it in a way that is acceptable to us.
>>
>> I think you're misreading the spec a little, or we've written it
>> badly:-)
> 
> I did misread the spec a bit, confusing some of the features in other
> HTTP Auth specs with some of the HOBA features. So, I took tonight to do
> a thorough review of the spec and outline the issues that we have with
> the current HOBA spec located at:
> 
> http://tools.ietf.org/html/draft-farrell-httpbis-hoba-02
> 
> I do agree that we should chat a bit more deeply about HOBA, Web Keys,
> Persona, and HTTP Signatures. So, please take this not as negative
> feedback, but constructive criticism and the first exchange toward
> attempting to map out a way forward for these specs.
> 
> Here's the HOBA spec review from a Web Keys / Web Payments perspective:
> 
> 1.  Introduction
> ----------------
> 
>> HOBA also defines some services that are required for modern HTTP 
>> authentication:
>>
>> o  Servers can bind a CPK with an identifier, such as an account 
>> name.  HOBA allows servers to define their own policies for binding
>> CPKs with accounts during account registration.
> 
> While a bit vague, we want to ensure that there is a well-defined way to
> do this. We're currently in the process of discussing how this should
> happen with the Mozilla Persona team. Ideally, the CPKs are setup or
> transmitted to the server when a Persona-like login exchange happens.
> We'd like to provide CPKs via some sort of identity expressed as Linked
> Data, like the sort that's defined in the Web Keys spec:
> 
> curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu
> 
>> o  Users are likely to use more than one device or user agent (UA) 
>> for the same HTTP based service, so HOBA gives a way to associate 
>> more than one CPK to the same account, but without having to register
>> for each separately.
> 
> +1, the approach above is how we accomplish this for Web Keys.
> 
>> o  Users are also likely to lose a private key, or the client's 
>> memory of which key pair is associated with which origin.  For 
>> example if a user loses the computer or mobile device in which state
>> is stored.  HOBA allows for clients to tell servers to delete the
>> association between a CPK and an account.
> 
> We took this approach 3+ years ago and quickly found that it would be a
> nightmare to have to contact every server that you've performed a login
> on to delete the association. Even worse, if you don't do this and the
> key is compromised, you enable the attacker to gain access to the server
> without your knowledge.
> 
> Instead, the server should track an "identity" and that identity will
> have keys that are currently valid, or that have been revoked (like the
> following):
> 
> curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu/keys/3
> 
> The server MUST check the validity of a key before allowing login. There
> could be cache values / E-Tags associated with keys to make sure that
> they're being properly cached via HTTP proxies.
> 
>> o  Logout features can be useful for user agents, so HOBA defines a 
>> way to close a current HTTP "session", and also a way to close all 
>> current sessions, even if more than one session is currently active
>> from different user agents for the same account.
> 
> Session management absolutely should not be a part of the base
> specification on HTTP Signatures. It should be layered on top of HTTP
> signatures. I realize that HOBA might be doing this to "solve" the
> session login problem on the Web via HTTP Auth once and for all, but
> this is at the wrong level of abstraction. You can implement sessions on
> top of HTTP Signatures any way that you would like (session cookies,
> HTTP headers carrying session information, URL query parameters with
> session information, etc.).
> 
> There should be a separation between HTTP Signatures and HTTP session
> management.
> 
> 1.2.  Terminology
> -----------------
> 
>> also optionally include an HTTP "realm" as defined in the HTTP 
>> authentication specification.
> 
> We don't use realm as most Access Control List (ACL) systems require far
> more complicated forms of specifying what the client can and cannot do
> with a particular CPK.
> 
> For example, look at the way OAuth is used in Twitter. When you provide
> a website with a particular OAuth token, you can grant them a number of
> privileges wrt. your account: let them see my e-mail address, let them
> tweet on my behalf, let them see my followers, let them see my profile
> information, etc. These sorts of access grants rarely fit nicely into a
> "realm" field. We think ACL should be a completely separate spec that is
> layered on top of HTTP Signatures or HOBA. We don't think it is a good
> idea to solve the problem at this level.
> 
> 2.  HOBA for Both HTTP Authentication and JavaScript
> ----------------------------------------------------
> 
>> On receipt of a challenge from a server, the client marshals a
>> to-be- signed blob that includes the web-origin name, the realm, and
>> the challenge string; and signs that hashed blob using the hash
>> algorithm identified with the challenge and the private key
>> corresponding to the CPK for that web-origin.
> 
> Yikes, this stomps all over the work that Mozilla is doing on Persona
> (and not in a good way). They seem to have a good solution for this, we
> should build off of that. The Javascript implementation of HOBA is also
> a hack in that it shoves authentication parameters into the URL and we
> /definitely/ don't want a Web where that becomes the norm. If this stuff
> is going to be integrated into the browser, we should not create a
> solution that makes it difficult for that to happen.
> 
> The solution shouldn't have a JavaScript-version and an HTTP-version. It
> should all run over HTTP, especially since the very large majority of
> JavaScript environments are capable of accessing and writing HTTP headers.
> 
> 3.  HOBA HTTP Authentication Mechanism
> --------------------------------------
> 
>> On receipt of a challenge from a server, the client marshals a
>> to-be- signed blob that includes the web-origin name, the realm, and
>> the challenge string; and signs that hashed blob using the hash
>> algorithm identified with the challenge and the private key
>> corresponding to the CPK for that web-origin.
> 
> This challenge-response-session approach is a tried and true design, but
> one that's fairly inefficient in that it requires multiple round-trips
> in the common case between server and client to perform a single
> authenticated operation.
> 
> The Web Keys specification takes a different approach in that the server
> does not need to provide a challenge because the client includes a
> client-specific time-boxed nonce. The nonce is guaranteed to increment
> so replay attacks are prevented as long as the server tracks the nonces
> correctly, which is the same requirement that TLS has. Only the latest
> nonce per client needs to be tracked for a certain period of time, e.g.
> 5 minutes, which greatly reduces memory overhead on the server.
> 
> The downside is that both client and server must have their clocks
> fairly closely aligned, which is not necessarily a terrible requirement
> given the state of modern timekeeping technology on the Internet. In the
> very worst case, the protocol could be expanded such that the server
> provides a clock timestamp that the client can use to calculate it's own
> clock skew based on the server's current clock.
> 
> Using a Linked Data-based identity coupled with an HTTP Signature and a
> time-boxed nonce allows a client to make a direct signed request to a
> server in 1 HTTP exchange instead of 2.
> 
> This is a fairly sharp deviation between the Web Keys + HTTP Signatures
> spec and the HOBA spec.
> 
> 4.  Using HOBA-http
> -------------------
> 
>> 4.1.  CPK Preparation Phase
>>
>> In the CPK preparation phase, the client determines if it already
>> has a CPK for the web-origin it is going to.  If the has a CPK, the 
>> client will use it; if the client does not have a CPK, it generates 
>> one in anticipation of the server asking for one.
> 
> With Web Keys, the client does not create a new CPK for every
> web-origin. It creates a single CPK for each identity associated with
> the client.
> 
> With HOBA, providing a new key for every website that the client visits
> is overkill and would result in a key management nightmare for the
> person using a browser. Dialogs would include dozens of keys in the
> average case, which would be a bit of a usability nightmare.
> 
> The Web Keys approach is to provide every identity on each device a key.
> So, if you visit google.com and you have one personal identity and one
> professional identity, and you use both on your home computer, then your
> home computer would have two keys regardless of the number of websites
> that you visit. Those keys would be tied to each public Linked Data
> identity.
> 
>> 4.2.  Signing Phase
>>
>> The user agent tries to access a protected resource on the server. 
>> The server sends the HOBA WWW-Authenticate challenge.  The user
>> agent receives the challenge and signs the challenge using the CPK
>> it either already had or just generated.  The server validates the 
>> signature.  If validation fails, the server aborts the transaction.
> 
> As explained above, the Web Keys + HTTP Signature approach is to not
> utilize a challenge-response approach, but rather a Linked Data identity
> coupled with a client-specific time-boxed nonce to achieve the same
> level of protection.
> 
> There /could/ be a Web Keys WWW-Authenticate message, but all that would
> do would be to notify the client that a Web Keys-based authentication
> should be performed when communicating with the server.
> 
>> 4.3.  Authentication Phase
>>
>> In the authentication phase, the server extracts the CPK from the 
>> signing phase and decides if it recognizes the CPK.  If the server 
>> recognizes the CPK, the server may finish the client authentication 
>> process.
> 
> Since the Web Keys specification uses a URL to express the key used for
> the digital signature, a server can discover the identity associated
> with the key pretty easily. For example, if this key was specified in
> the HTTP Signature: https://dev.payswarm.com/i/manu/keys/3
> 
> The server would get the key:
> 
> curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu/keys/3
> 
> look for the owner of the key in the data, which would be:
> 
> https://dev.payswarm.com/i/manu
> 
> fetch that profile:
> 
> curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu
> 
> and then see if it has that identity on record as having an account on
> the server. If it does, then it would verify that the key is owned by
> the profile and check the validity of the signature.
> 
> 4.3.  Authentication Phase
> --------------------------
> 
> The last part of the first paragraph and the last 3 paragraphs should
> just say that each topic covered is out of scope. The vast majority of
> this section deals with things that are out of scope for HOBA (and most
> HTTP Auth schemes).
> 
> 4.4.  Logging in on a New User Agent
> ------------------------------------
> 
> The vast majority of this section is out of scope for this spec as well.
> 
> 5.  Using HOBA-js
> -----------------
> 
> I don't understand why HOBA-http cannot be accomplished via JavaScript
> and XHR? Why do you need an entirely different way of encoding the HOBA
> protocol using only URL-based parameters?
> 
> Unless I'm missing something, the entirety of this section is at the
> wrong level of abstraction and unnecessary.
> 
> 6.1.  Registration
> ------------------
> 
> This section is interesting because we've been struggling to figure out
> a way to have UAs automatically (or semi-automatically) create accounts
> on new web-origins. That said, Mozilla Persona is far ahead of us here,
> so we should probably just fall in line w/ what they're doing.
> 
> 6.2.  Associating Additional Keys to an Exiting Account
> -------------------------------------------------------
> 
> As explained above, this is unnecessary if you use a Linked Data
> identity like Web Keys does. You never have to add additional keys to an
> existing account because the person accessing the site has already
> paired their device with a key using their Identity Provider. When they
> hit a web-origin, that association is already complete, therefore there
> is nothing for the web-origin to do except lookup the key and the
> identity. In effect, that key is automatically picked up by every
> website that accesses the Linked Data identity.
> 
> 6.3.  Logging Out
> -----------------
> 
> Again, this is at the wrong level of abstraction, at least as far as Web
> Keys and HTTP Signatures are concerned. If HOBA is to become a standard
> way of doing HTTP session management, then this would be fine. That
> said, I think you'll be competing with Mozilla Persona at that point.
> 
> -----------------------------------------------------------------------
> 
> Hopefully this is helpful to the HOBA editors. I'm having a chat with
> one of the editors next week and I wanted to make sure to get this out
> there so he has time to review the comments before our chat.
> 
> Again, this was just a friendly review of the spec before we try to
> figure out how we can coordinate this activity between W3C and IETF.
> 
> -- manu
> 

From mike@mtcc.com  Sun Apr 21 14:40:11 2013
Return-Path: <mike@mtcc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1446B21F929E; Sun, 21 Apr 2013 14:40:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVJbjoVjEnYy; Sun, 21 Apr 2013 14:40:10 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 6916C21F8D2C; Sun, 21 Apr 2013 14:40:10 -0700 (PDT)
Received: from piolinux.mtcc.com (65-172-209-232.dsl.volcano.net [65.172.209.232]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r3LLduT2019446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Apr 2013 14:39:57 -0700
Message-ID: <51745CA7.20907@mtcc.com>
Date: Sun, 21 Apr 2013 14:39:51 -0700
From: Michael Thomas <mike@mtcc.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Manu Sporny <msporny@digitalbazaar.com>
References: <5170652F.60609@digitalbazaar.com>	<87A0FB6A602993DC8BFA8CC3@caldav.corp.apple.com> <5174578E.70601@digitalbazaar.com>
In-Reply-To: <5174578E.70601@digitalbazaar.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1807; t=1366580397; x=1367444397; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20<mike@mtcc.com> |Subject:=20Re=3A=20[http-auth]=20[apps-discuss]=20Web=20Ke ys=20and=20HTTP=20Signatures |Sender:=20 |To:=20Manu=20Sporny=20<msporny@digitalbazaar.com> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=s8EamIKRYfgcDQbZV7K8irnk6CgAclrNO7VNDDijtCg=; b=tVQevi6VdKP3D7+1LO0qrBaitfThrfpqkgv0VqY/Z2C0mr7X3DLE4Vl78K 4Z1ItGQHZysnjEp1JkTB86xpq+yPqwTOKCFLOUs1XC8pQIfw72UKbytxT8dK k+/xDQ2iXI9sw9BzqyMoslnAYIq4Ior6SIXkMSb9fMuEhp3lvN3Ds=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
X-Mailman-Approved-At: Mon, 22 Apr 2013 00:17:37 -0700
Cc: IETF HTTP Auth <http-auth@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>, Web Payments CG <public-webpayments@w3.org>
Subject: Re: [apps-discuss] [http-auth]  Web Keys and HTTP Signatures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Apr 2013 21:40:11 -0000

Manu Sporny wrote:
> Yes, it seems like a very applicable technology for your use case. The
> one thing I missed is whether or not DKIM allows multiple identities per
> user in a domain? Does it let users create as many sub-accounts as they
> want and associate keys with them? Anything is possible, what I'm asking
> is if this is something that is standardized. Access to DNS places a
> pretty high bar and we were hoping to lower that by a significant amount
> with Web Keys.
> 
>>From my understanding, DKIM defines a domain-level digital signature
> authentication framework. WebKeys defines a identity-level digital
> signature authentication framework.


You can have any number of selectors per domain. Selectors can be delegated
as needed (or not). Whether it's a good idea to have zillions of records served
by given zone is another matter. I assume that an untrusted client has a selector.
That is another thing that's worth considering because the use case it's been
deployed with is mainly ~trustable entities. I don't see why that would be problem
off the top of my head, but it's worth thinking about.

> Where DKIM uses the DNS system to discover key information for a domain.
> Web Keys uses the Web and Linked Data formats to discover key
> information for a particular identity.

DKIM uses DNS to store raw public keys. No more, no less. It is linked to
a domain insofar as the domain's owners/managers determines what is populated
in its zone files. The bigger issue in my mind is whether you need DNSSEC.
For mail signing, it was an acceptable risk to not have the keys themselves
be signed. If you require that level of protection, then it implies DNSSEC
and all of the machinery behind it. Which isn't to say it's not possible,
just TANSTAAFL.

Mike

From mike@mtcc.com  Sun Apr 21 15:28:05 2013
Return-Path: <mike@mtcc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6508721F8606; Sun, 21 Apr 2013 15:28:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1yQ54p36+FC; Sun, 21 Apr 2013 15:28:04 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id B17F721F85EE; Sun, 21 Apr 2013 15:28:04 -0700 (PDT)
Received: from piolinux.mtcc.com (65-172-209-232.dsl.volcano.net [65.172.209.232]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r3LMRsFN005687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Apr 2013 15:27:56 -0700
Message-ID: <517467E6.5050407@mtcc.com>
Date: Sun, 21 Apr 2013 15:27:50 -0700
From: Michael Thomas <mike@mtcc.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Manu Sporny <msporny@digitalbazaar.com>
References: <5170652F.60609@digitalbazaar.com> <5171233D.303@cs.tcd.ie> <51735AD2.9040900@digitalbazaar.com>
In-Reply-To: <51735AD2.9040900@digitalbazaar.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4113; t=1366583277; x=1367447277; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20<mike@mtcc.com> |Subject:=20Re=3A=20[http-auth]=20Web=20Keys=20and=20HTTP=2 0Signatures |Sender:=20 |To:=20Manu=20Sporny=20<msporny@digitalbazaar.com> |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=8ZBasjG/AvuJPxLUB+9nYO6kLTbXp5GcSKFuh6Y3aWE=; b=g3Nj4eog5rEx1C3Pn/riVYayUxMpTVYuVAk6a65IcA2kVQLHvEHK15lhfl oeLUlWyVWf1r0ht0PGkvhlqjuHVz5uv0LibdZ7jFk/JYFKT1lbxUE1+0ZysA BoqFJrlLrSdSWfz2gCWEdsPWDCxuG1qJjLwv22w9BjUHwW1uKQoM8=;
Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; );  dkim-asp=pass header.From=mike@mtcc.com
X-Mailman-Approved-At: Mon, 22 Apr 2013 00:17:56 -0700
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, IETF HTTP Auth <http-auth@ietf.org>, Web Payments CG <public-webpayments@w3.org>, Mark Cavage <mark.cavage@joyent.com>
Subject: Re: [apps-discuss] [http-auth] Web Keys and HTTP Signatures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Apr 2013 22:28:05 -0000

Manu Sporny wrote:

> The Javascript implementation of HOBA is also
> a hack in that it shoves authentication parameters into the URL and we
> /definitely/ don't want a Web where that becomes the norm. If this stuff
> is going to be integrated into the browser, we should not create a
> solution that makes it difficult for that to happen.

Um, HOBA-js is just client server protocol. It is completely normal and expected
for a web site to define the url parameters coming from the client. There's nothing
magical about signature parameters. The one thing that would need to be mentioned is
that there is no significance to the parameter names -- there would be no iana
registry or anything like that. The client and server would just need to agree
to their names and functionality which is nothing different than any other parameter.

 > The server would get the key:
> 
> curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu/keys/3
> 
> look for the owner of the key in the data, which would be:
> 
> https://dev.payswarm.com/i/manu
> 
> fetch that profile:
> 
> curl -H "Accept: application/ld+json" https://dev.payswarm.com/i/manu
> 
> and then see if it has that identity on record as having an account on
> the server. If it does, then it would verify that the key is owned by
> the profile and check the validity of the signature.

I don't know whether this is relevant, but HOBA doesn't require third parties.
It's just a get-rid-of-passwords-as-currently-deployed scheme. As such, it
doesn't require 3rd party trust, somebody else's business model, etc. Just drop
hoba in and deprecate passwords being stored on servers. I for one would be happy to
see a spec that limits itself to just the client server problem so that web
sites can get their heads around even that smaller problem without them exploding
when you drag 3rd party complexity in.


> 4.3.  Authentication Phase
> --------------------------
> 
> The last part of the first paragraph and the last 3 paragraphs should
> just say that each topic covered is out of scope. The vast majority of
> this section deals with things that are out of scope for HOBA (and most
> HTTP Auth schemes).
> 
> 4.4.  Logging in on a New User Agent
> ------------------------------------
> 
> The vast majority of this section is out of scope for this spec as well.

I think you might be taking this draft way too literally. At least from my
vantage point, the idea in HOBA for the here and now is to sketch out how
this kind of idea could work, and the discussions about session, etc, is
to illustrate how it might work with real world sites today with real world
session management, etc. That is, you shouldn't read too much normative into
this draft.

> 
> 5.  Using HOBA-js
> -----------------
> 
> I don't understand why HOBA-http cannot be accomplished via JavaScript
> and XHR? Why do you need an entirely different way of encoding the HOBA
> protocol using only URL-based parameters?

The current draft is an amalgamation of two ideas that are generally similar.
I had independently come up with HOBA-js and then noticed Paul and Stephen
working on something similar. My idea was to use javascript+crypto libraries
and do this entirely at the application layer. Obviously webcrypto would be
a huge help, and get rid of dodgy js crypto libraries but it isn't available
yet.

This blog post documents what I did.

http://rip-van-webble.blogspot.com/2012/06/using-asymmetric-keys-for-web-joinlogin.html

I actually have a live implementation that does this. FWIW, it uses time stamps instead
of nonces for replay protection.

> Unless I'm missing something, the entirety of this section is at the
> wrong level of abstraction and unnecessary.

It shows that this can be done today, and that it doesn't even require standardization.
The reason I put it out there is because crypto is hard to get right, and even if it
doesn't _require_ standardization, standardization is a good way of getting clueful
eyeballs on would-be crypto deployments.

Mike

From msporny@digitalbazaar.com  Sun Apr 21 14:18:20 2013
Return-Path: <msporny@digitalbazaar.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3657D21F8B5F; Sun, 21 Apr 2013 14:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level: 
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNXlNVAwMeUz; Sun, 21 Apr 2013 14:18:19 -0700 (PDT)
Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFC321F8682; Sun, 21 Apr 2013 14:18:19 -0700 (PDT)
Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from <msporny@digitalbazaar.com>) id 1UU1eF-0003sw-U2; Sun, 21 Apr 2013 17:18:13 -0400
Message-ID: <5174578E.70601@digitalbazaar.com>
Date: Sun, 21 Apr 2013 17:18:06 -0400
From: Manu Sporny <msporny@digitalbazaar.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4
MIME-Version: 1.0
To: Cyrus Daboo <cyrus@daboo.name>
References: <5170652F.60609@digitalbazaar.com> <87A0FB6A602993DC8BFA8CC3@caldav.corp.apple.com>
In-Reply-To: <87A0FB6A602993DC8BFA8CC3@caldav.corp.apple.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 22 Apr 2013 00:18:06 -0700
Cc: IETF HTTP Auth <http-auth@ietf.org>, Web Payments CG <public-webpayments@w3.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Web Keys and HTTP Signatures
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Apr 2013 21:18:20 -0000

On 04/19/2013 11:33 AM, Cyrus Daboo wrote:
>> https://github.com/joyent/node-http-signature/blob/master/http_signing.md
>
> That draft is very similar to the approach we have used in iSchedule
>  (<https://datatracker.ietf.org/doc/draft-desruisseaux-ischedule/>) -
>  which is an HTTP-based calendar and scheduling messaging protocol.

Thanks for the pointer to the draft. I skimmed it and I agree that there
are a number of very interesting similarities.

> We choose to re-use existing email signing technology - DKIM 
> (<http://tools.ietf.org/html/rfc6376>) - primarily because the 
> security model and key management were a good fit for our 
> application. There is also the benefit of code re-use, and working 
> with a protocol that is already deployed and used heavily in the 
> email environment. Also, DKIM was designed with the prospect of
> being applicable to protocols beyond email technology - and I think
> with iSchedule we have proven it can work with HTTP.

Yes, it seems like a very applicable technology for your use case. The
one thing I missed is whether or not DKIM allows multiple identities per
user in a domain? Does it let users create as many sub-accounts as they
want and associate keys with them? Anything is possible, what I'm asking
is if this is something that is standardized. Access to DNS places a
pretty high bar and we were hoping to lower that by a significant amount
with Web Keys.

>From my understanding, DKIM defines a domain-level digital signature
authentication framework. WebKeys defines a identity-level digital
signature authentication framework.

Where DKIM uses the DNS system to discover key information for a domain.
Web Keys uses the Web and Linked Data formats to discover key
information for a particular identity.

> I would definitely urge you to take a serious look at DKIM. There
> are a number of interesting features there that don't seem to have
> been addressed in the draft you cited. In particular dealing with
> both header and body canonicalization (headers are particular problem
> in HTTP due to intermediaries, caches etc).

Yes, Proxy header modification is a problem for Web Keys and HTTP
Signatures now. We think we have some working solutions, but won't know
for sure until we get some deployment experience with the protocol (or
someone that has already been through that pain point can let us know
what we're doing wrong).

I agree with you. We need to take a serious look at DKIM and your spec
and figure out if we missed something obvious with Web Keys and HTTP
Signatures. Glancing through your spec sparked a few ideas, so I'm
looking forward to a thorough read and review of it wrt. Web Keys and
HTTP Signatures.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

From xhe@hitachi.cn  Sun Apr 21 23:58:26 2013
Return-Path: <xhe@hitachi.cn>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B70A21F84B0 for <apps-discuss@ietfa.amsl.com>; Sun, 21 Apr 2013 23:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.151
X-Spam-Level: 
X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_EQ_STATICB=1.372, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWeDEBSnWnQr for <apps-discuss@ietfa.amsl.com>; Sun, 21 Apr 2013 23:58:26 -0700 (PDT)
Received: from hitachihk8.hitachi.cn (static-ip-174-194-65-202.rev.dyxnet.com [202.65.194.174]) by ietfa.amsl.com (Postfix) with ESMTP id A1B8C21F8618 for <apps-discuss@ietf.org>; Sun, 21 Apr 2013 23:58:23 -0700 (PDT)
Received: (qmail 13645 invoked from network); 22 Apr 2013 06:58:21 -0000
X-NetworkBox-HamSign: 0101;OUT;hitachihk8;3c0543634f39216b380754b165ed3789;
Received: from unknown (HELO mfrelay04.hitachi.co.jp) (133.144.234.179) by 172-3-20-1.lightspeed.nworla.sbcglobal.net with SMTP; 22 Apr 2013 06:58:21 -0000
Received: from vshuts04.hitachi.co.jp (vshuts04.hitachi.co.jp [10.201.6.86]) by mfrelay04.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id r3M6wKtF028937 for <apps-discuss@ietf.org>; Mon, 22 Apr 2013 15:58:21 +0900
Received: from localhost (unknown [127.0.0.1]) by IMSVA (Postfix) with SMTP id 8E500140061 for <apps-discuss@ietf.org>; Mon, 22 Apr 2013 15:58:20 +0900 (JST)
X-IMSS-HAND-OFF-DIRECTIVE: 133.144.234.22:25
Received: from hitachi.cn (unknown [170.95.94.58]) by vshuts04.hitachi.co.jp (Postfix) with ESMTP id C819214005D for <apps-discuss@ietf.org>; Mon, 22 Apr 2013 15:58:10 +0900 (JST)
Received: (qmail 23737 invoked from network); 22 Apr 2013 06:58:10 -0000
X-NetworkBox-HamSign: 0101;OUT;hitachihk5;33686cabbf7ebe6a6926e5a65b25ed66;
Received: from hchidc094072.hitachi-china.com (170.95.94.72) by 172.16.10.14 with SMTP; 22 Apr 2013 06:58:10 -0000
Received: from hcrdbjipnl017 ([10.96.2.119]) by hchidc094072.hitachi-china.com with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 22 Apr 2013 14:58:09 +0800
From: "He Xuan" <xhe@hitachi.cn>
To: "'IETF Apps Discuss'" <apps-discuss@ietf.org>, <draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org>
References: <515D75FE.9070008@isode.com>
In-Reply-To: <515D75FE.9070008@isode.com>
Date: Mon, 22 Apr 2013 14:58:09 +0800
Message-ID: <00a601ce3f26$bfbe4cf0$3f3ae6d0$@cn>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac4xMkGo67Fl3sUGR0e7hoscyk0PBwN8M1Bw
Content-Language: zh-cn
X-OriginalArrivalTime: 22 Apr 2013 06:58:09.0654 (UTC) FILETIME=[BF9FA160:01CE3F26]
X-Scanned-By-hitachihk5: Virus scan performed by network-box
X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1366613890.142-23732-000
X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.02/0.05 secs)
X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0
X-NetworkBox-BounceSign-hitachi: 0101;15817;23a1c928
X-Scanned-By-hitachihk8: Virus scan performed by network-box
X-Scanned-By-hitachihk8: Scanner file id is hitachihk8-1366613901.729-13636-000
X-Scanned-By-hitachihk8: No known viruses found in message (received+scanned in 0.03/0.07 secs)
X-Scanned-By-hitachihk8: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0
X-Scanned-By-hitachihk8: Whitelisted with valid signature (outbound via Network Box hitachihk5)
X-Mailman-Approved-At: Mon, 22 Apr 2013 00:18:14 -0700
Cc: 'The IESG' <iesg@ietf.org>
Subject: [apps-discuss] AppsDir review of draft-ietf-6man-stable-privacy-addresses-06
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Apr 2013 06:58:26 -0000

I have been selected as the Applications Area Directorate (appsdir) 
reviewer for this draft.  (For background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments 
you may receive.  Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-ietf-6man-stable-privacy-addresses-06
Title: A method for Generating Stable Privacy-Enhanced Addresses with IPv6
Stateless Address Autoconfiguration (SLAAC)
Reviewer: Eliot Lear and Xuan He
Review Date: April 22, 2013
IETF Last Call Date: April 26, 2013
IESG Telechat Date: not known

Summary: This draft is nearly ready for publication as an Standards Track
RFC.

Major Issues: none.

Minor:

In section 1, section 2 and section 6, it would be better to list detailed
quotation section number such as "see Appendix A.1" or "see Appendix A.2",
since there is a complex appendix. 

Nits:

In Appendix, 1st paragraph: (non-exaustive) should be a typo.

Disclaimer:
The contents of this e-mail, and its attachments, if any, are confidential and may be protected
by law against any unauthorized use.  If you have received this e-mail by mistake or have
reason to believe that you are not the intended recipient, please notify the sender by reply
e-mail as soon as possible and delete it from your computer system immediately thereafter.
If you are not the intended recipient, you must not copy this e-mail or attachment or disclose
the contents to any other person.  While we have made every effort to keep our network virus free,
we take no responsibility for any computer virus which might be transferred by way of this e-mail.

From fgont@si6networks.com  Mon Apr 22 09:17:43 2013
Return-Path: <fgont@si6networks.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C533D21F8EAF; Mon, 22 Apr 2013 09:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmLwZUJozYWg; Mon, 22 Apr 2013 09:17:43 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2403A21F8E99; Mon, 22 Apr 2013 09:17:43 -0700 (PDT)
Received: from [201.157.17.130] (helo=[172.20.4.229]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from <fgont@si6networks.com>) id 1UUJQp-00027j-9H; Mon, 22 Apr 2013 18:17:31 +0200
Message-ID: <5175628A.8030301@si6networks.com>
Date: Mon, 22 Apr 2013 11:17:14 -0500
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: He Xuan <xhe@hitachi.cn>
References: <515D75FE.9070008@isode.com> <00a601ce3f26$bfbe4cf0$3f3ae6d0$@cn>
In-Reply-To: <00a601ce3f26$bfbe4cf0$3f3ae6d0$@cn>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 23 Apr 2013 14:26:30 -0700
Cc: draft-ietf-6man-stable-privacy-addresses.all@tools.ietf.org, 'The IESG' <iesg@ietf.org>, 'IETF Apps Discuss' <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] AppsDir review of draft-ietf-6man-stable-privacy-addresses-06
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Apr 2013 16:17:43 -0000

Hi, He,

On 04/22/2013 01:58 AM, He Xuan wrote:
> Summary: This draft is nearly ready for publication as an Standards Track
> RFC.
> 
> Major Issues: none.
> 
> Minor:
> 
> In section 1, section 2 and section 6, it would be better to list detailed
> quotation section number such as "see Appendix A.1" or "see Appendix A.2",
> since there is a complex appendix. 

Will do.



> Nits:
> 
> In Appendix, 1st paragraph: (non-exaustive) should be a typo.

Fixed.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From mnot@mnot.net  Tue Apr 23 17:08:01 2013
Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8E321F93CA; Tue, 23 Apr 2013 17:08:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.518
X-Spam-Level: 
X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=-3.919, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGjhb8gg2F25; Tue, 23 Apr 2013 17:08:00 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6E91D21F93B9; Tue, 23 Apr 2013 17:08:00 -0700 (PDT)
Received: from [192.168.1.80] (unknown [118.209.190.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D1894509B6; Tue, 23 Apr 2013 20:07:54 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 24 Apr 2013 10:07:50 +1000
Message-Id: <68113CC9-033D-4E61-8190-2D3B9CE92CB0@mnot.net>
To: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>, draft-ietf-oauth-revocation.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
X-Mailer: Apple Mail (2.1503)
Cc: IESG IESG <iesg@ietf.org>
Subject: [apps-discuss] Apps Area Review of draft-ietf-oauth-revocation-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Apr 2013 00:08:01 -0000

I have been selected as the Applications Area Review Team reviewer for =
this draft (for background on apps-review, please see =
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments =
you may receive. Please wait for direction from your document shepherd =
or AD before posting a new version of the draft.

Document: draft-ietf-oauth-revocation-07
Title: Token Revocation
Reviewer: Mark Nottingham
Review Date: 24 April 2013
IETF Last Call Date: 30 April 2013
IESG Telechat Date: unknown

Summary: This draft is has issues that should be fixed before =
publication.

Major Issues:

1) Section 2 states that the means of discovering the revocation =
endpoint is out of scope of this specification, and that it can be =
achieved by consulting documentation.=20

This is a poor design choice, at odds with the Web architecture, and =
fails to provide interoperability. A discovery mechanism should be =
specified.

One way to do it would be to allow the revocation URI to be indicated at =
an earlier part of the OAuth interchange.=20

Another (potentially simpler) to do it would be to assign a URI to the =
token itself, and allow a properly authorised client to DELETE that URI; =
this removes the need to specify a body format.

Minor Issues:

2) The specification title is too broad; "Token Revocation" could apply =
to many IETF technologies. Suggest "OAuth Token Revocation".


--
Mark Nottingham   http://www.mnot.net/




From dcrocker@gmail.com  Wed Apr 24 06:38:31 2013
Return-Path: <dcrocker@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C43421F9157; Wed, 24 Apr 2013 06:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level: 
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-o0ewgwq80o; Wed, 24 Apr 2013 06:38:30 -0700 (PDT)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D593321F8FEB; Wed, 24 Apr 2013 06:38:29 -0700 (PDT)
Received: by mail-ob0-f174.google.com with SMTP id wc20so1489205obb.33 for <multiple recipients>; Wed, 24 Apr 2013 06:38:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=BG2mvgzxiq3Jb3k3LbYoIpE3XhIP74qyz1P5xETaxjE=; b=ITotPVA7yGalnt92LrGLD8qxTg+RMAjFUloipfcPFzeT3CsaDBTlA67BP+PB1t4OAA gWh8lF/o5e+tDGj1APvBX81QuvTY7yB4bOPnnWq7fU3y7rzmKY0FwnKFS3Icxgplg81u l1IYKflvGABCW4vLSdUxQQf3bEjfcwNnP3ZqjbgU2gqeijnzWcpSo9LH2vw573/Yx4jq vrmIjJjC0zP5aW0Sg06E2aeS0iCvDNtlP/gXxHP+2DuoLPGAliRk5EUXj7T+oELgzI0u MPRMZ7M+/hmGy/Dzw6340PsPTRZ9CXWLZYl/eHn8HQvoDPJqzajL/Xt+BeUpcuRR0Aic lamQ==
X-Received: by 10.60.55.3 with SMTP id n3mr14383179oep.118.1366810709318; Wed, 24 Apr 2013 06:38:29 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net. [76.218.9.215]) by mx.google.com with ESMTPSA id ru4sm993593obb.4.2013.04.24.06.38.26 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 06:38:28 -0700 (PDT)
Message-ID: <5177E050.6020908@gmail.com>
Date: Wed, 24 Apr 2013 06:38:24 -0700
From: Dave Crocker <dcrocker@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: draft-sheffer-running-code.all@tools.ietf.org, apps-discuss@ietf.org,  iesg@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 24 Apr 2013 08:47:27 -0700
Subject: [apps-discuss] Review of:  draft-sheffer-running-code
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Apr 2013 13:38:31 -0000

Howdy.

I have been selected as the Applications Area Review Team reviewer for 
this draft (for background on apps-review, please see 
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.


Review
------


Title:    Improving Awareness of Running Code: the Implementation Status 
Section

I-D:      draft-sheffer-running-code-04

Reviewer:     D. Crocker
Review Date:  24 April 2013


Summary:

Given an organizational motto of "Rough consensus and running code", 
implementation experience has a value built into the IETF's DNA.  
However formal IETF reliance on running code for specifications has been 
minimal, with its only universal occurrence being in consideration of 
advanced standards status; it is notably /not/ an organizational 
requirement for entry-level Proposed Standard status, if only for the 
very high barrier to publication this imposes on document versions that 
were intended to be preliminary.  The current draft proposes an 
experiment to optionally include documentation of implementations as 
part of document development, prior to issuance of a specification as an 
RFC.

Within the broader perspective of pre- and post-standardization efforts, 
it is quite common to document available implementations of a 
specification.  (As a convenient example, see http://dkim.org/deploy.)  
In effect, the current proposal merely seeks to have a common IETF-based 
means of recording a type of information that industry has already 
frequently formulated.

In their current form, the draft and the proposal seem likely to be 
useful.  However, both could be improved.

The draft includes some language and assertions that would benefit from 
being a bit more carefully written; questions, comments and suggestions 
are in the detailed comments below.

The proposal itself would benefit from directly paying more attention to 
existing industry practice, which is implied by the "alternatives" 
section; that is, that implementation lists already happen and are 
maintained after IETF document processing. The proposal should do a 
better job of integrating this fact into its design.

One approach could be a relatively simple document change, to 
distinguish between specifying the information to be reported, as 
distinct from the means of reporting it -- think of it as payload vs. 
mechanism...  Specify them separately.  Then define both how to 
incorporate the information directly and the form of an external 
citation to it; this would eliminate the document's section on 
'alternatives' and treat the original and alternative methods as equal.

d/





Detailed Comments:

> 1.  Introduction
>
>     Most IETF participants are familiar with the saying, "rough consensus
>     and running code" [Tao], and can identify with its pragmatic
>     approach.  However, there are many examples of Internet-Drafts
>     containing protocol specification that have gone through to
>     publication as Proposed Standard RFCs without implementation.  Some
>     of them may never get implemented.

The "however" implies that it is wrong or problematic for Proposed to be 
assigned to unimplemented protocols.  It isn't.  I suggest a softer 
tone, while still noting the relevantfact. Something like:

      It is not a requirement of Proposed Standard status to have any 
implementations; by the time of reaching that status, some 
specifications have been implemented and some have not. Indeed, some 
never get implemented.


>     Over time, a variety of policies have been implemented within the
implemented -> applied


>     IETF to consider running code.  In the Routing Area it used to be a
>     requirement that one or more implementations must exist before an
>     Internet-Draft could be published as a Proposed Standard RFC
>     [RFC1264].  That RFC was later obsoleted and the requirement for
>     implementation was lifted, but each working group was given the
>     authority to impose its own implementation requirements [RFC4794] and
>     at least one working group (IDR) continues to require two independent
>     implementations.
>
>     The hypothesis behind this document is that there are benefits to the
this -> the current


>     IETF standardization process of producing implementations of protocol
>     specifications before publication as RFCs.  These benefits, which
I suspect that that isn't its "hypothesis" at all, since the document 
does nothing to specify or directly affect policies for requiring or 
encouraging implementation.  Perhaps there is a hope that the proposed 
notation about implementations will serve as some sort of encouragement, 
but that's pretty indirect; success or failure of the proposed 
experiment won't validate or invalidate whether there are benefits to 
early implementation.  And providing for a notation convention hardly 
constitutes an 'incentive'.

Rather, I believe the premise of the document is that the community is 
aided by /more widely knowing about/ early implementations.


>     include determining that the specification is comprehensible and that
>     there is sufficient interest to implement, are further discussed in
>     Section 4.
>
>     This document describes a simple process that allows authors of

process -> mechanism


>     Internet-Drafts to record the status of known implementations, by
>     including an Implementation Status section.  The document defines
>     (quite informally) the contents of this section, to ensure that the
>     relevant information is included.  This will allow reviewers and
>     working groups to assign due consideration to documents that have the
>     benefit of running code, by considering the running code as evidence
>     of valuable experimentation and feedback that has made the
>     implemented protocols more mature.

The above last sentence seems to be the actual claimed value proposition 
for the experiment.


>     This document provides a mechanism to record and publicize the
This sentence seems entirely redundant.


>     existence of running code.  It is up to the individual working groups
>     to use this information as they see fit, but one result might be the
>     preferential treatment of documents resulting in them being processed
>     more rapidly.
I think it won't be the working group that 'uses' the information, but 
rather IETF management and the broader community?


>     The process in this document is offered as an experiment.  Authors of
>     Internet-Drafts are encouraged to consider using the process for
>     their documents, and working groups are invited to think about
>     applying the process to all of their protocol specifications.
>
>     The scope of the intended experiment is all Internet-Drafts whether

Probably not all I-Ds, since they do not all contain implementable 
specifications.


>
>
> Sheffer & Farrel        Expires October 14, 2013                [Page 3]
> 
> Internet-Draft                Running Code                    April 2013
>
>
>     produced within IETF working groups, outside working groups but

What I-Ds are produced by "outside working groups"?  I can't tell who 
this refers to.It's probably just as well to remove the attempted case 
analysis for groups and just say that the scope is all specifications 
issued as I-Ds.


>     intended for IETF consensus, or for publication on the Independent
>     Stream.  However, it is expected that most benefit from the

that most benefit from the experiment will
->
the greatest benefit in the experiment will


>     experiment will be seen with Standards Track documents developed
>     within working groups.

Here's my guess:

1. Those offering comments or making decisions about the status of 
document will be aided by this added information.

2. Those deciding about whether to write code or deploy it will be aided.

I think the latter is likely to be the greater benefit.


>     The authors of this document intend to collate experiences with this
>     experiment and to report them to the community.
>
>
> 2.  The "Implementation Status" Section
>
>     Each Internet-Draft may contain a section entitled "Implementation
>     Status".  This section, if it appears, should be located just before
>     the "Security Considerations" section and contain, for each existing
>     implementation:
>
>     o  The implementation's name and/or a link to a web page describing
>        the implementation.
>     o  A brief general description.
>     o  The implementation's level of maturity: research, prototype,
>        alpha, beta, production, widely used etc.
>     o  Coverage: which parts of the protocol specification are
>        implemented and which versions of the Internet-Draft were
>        implemented.
>     o  Licensing: the terms under which the implementation can be used.
>        For example: proprietary, royalty licensing, freely distributable
>        with acknowledgement (BSD style), freely distributable with
>        requirement to redistribute source (GPL style), other (specify).
>     o  Contact information: ideally a person's name and email address,
>        but possibly just a URL or mailing list.
List the organization that did the implementation and contact 
information for the proper place in the organization.


>     In addition, this section can contain information about the
>     interoperability of any or all of the implementations.
>
>     Since this information is necessarily time-dependent, it is
>     inappropriate for inclusion in a published RFC.  The authors should

Way to bury the lead.  This stuff won't be in the published document?  
It's only for pre-publication?


>     include a note to the RFC Editor requesting that the section be
>     removed before publication.
>
> 2.1.  Introductory Text
>
>     The following boilerplate text is proposed to head the Implementation
>     Status section:
>
>
>
>
>
>
>
> Sheffer & Farrel        Expires October 14, 2013                [Page 4]
> 
> Internet-Draft                Running Code                    April 2013
>
>
>        This section records the status of known implementations of the
>        protocol defined by this specification at the time of posting of
>        this Internet-Draft, and is based on a proposal described in [RFC
>        Editor: replace by a reference to this document].  According to
>        [RFC Editor: replace by a reference to this document], "this will
>        allow reviewers and working groups to assign due consideration to
>        documents that have the benefit of running code, by considering
>        the running code as evidence of valuable experimentation and
>        feedback that has made the implemented protocols more mature.  It
>        is up to the individual working groups to use this information as
>        they see fit".
>
>     Authors are requested to add a note to the RFC Editor at the top of
>     this section, advising the Editor to remove the entire section before
>     publication, as well as the reference to [RFC Editor: replace by a
>     reference to this document].
>
>
> 3.  Alternative Formats
Yes!


>     Sometimes it can be advantageous to publish the implementation status
>     separately from the base Internet-Draft, e.g. on the IETF wiki:
>
>     o  When the Implementation Status section becomes too large to be
>        conveniently managed within the document.
>     o  When a working group decides to have implementors, rather than
>        authors, keep the status of their implementations current.
>     o  When a working group already maintains an active wiki and prefers
>        to use it for this purpose.
>
>     It is highly desirable for all readers of the Internet-Draft to be
>     made aware of this information.  Initially this can be done by
>     replacing the Implementation Status section's contents with a URL
>     pointing to the wiki.  Later, the IETF Tools may support this
>     functionality, e.g. by including such a link from the HTMLized draft
>     version, similar to the IPR link.
>
>     If the implementation status is published separately from the I-D,
>     then this information needs to be openly available without requiring
>     authentication, registration or access controls if it is to have any
>     useful effects.
>
>
> 4.  Benefits
>
>     Publishing the information about implementations provides the working
>     group with several benefits:
>
>
>
>
> Sheffer & Farrel        Expires October 14, 2013                [Page 5]
> 
> Internet-Draft                Running Code                    April 2013
>
>
>     o  Participants are motivated to implement protocol proposals, which
>        helps in discovering protocol flaws at an early stage.

The psychological premise seems to be that getting cited in this list 
will somehow serve as an incentive to implementers. I can imagine that 
they'll like being listed, but find it extremely difficult to believe 
that it will affect whether they do the work; not that I think it's a 
deciding factor, but note that the ego value is further reduced by the 
information's being ephemeral, since it it removed prior to RFC publication!


>     o  Other participants can use the software, to evaluate the
>        usefulness of protocol features, its correctness (to some degree)
>        and other properties, such as resilience and scalability.

Efficacy of the spec.


>     o  WG members may choose to perform interoperability testing with
>        known implementations, especially when they are publicly
>        available.

Interoperability of the spec.


>     o  In the case of open source, people may want to study the code to
>        better understand the protocol and its limitations, determine if
>        the implementation matches the protocol specification, and whether
>        the protocol specification has omissions or ambiguities.
Reference implementation as exemplar.


>     o  Working group chairs and ADs may use the information provided to
>        help prioritize the progress of I-Ds in some way.
What does "prioritize the progress" mean?


>     o  Similarly, the information is useful when deciding whether the
>        document should be progressed on a different track (individual
>        submission, Experimental etc.).
Assess spec maturity.  (This seems redundant with the combination of 
Efficacy and Interoperability?)


>     o  And lastly, some protocol features may be hard to understand, and
>        for such features, the mere assurance that they can be implemented
>        is beneficial.
mumble.  Might highlight problems with the spec language. Might 
undermine the spec text by causing code to be used in place of it?


>     We do not specify here whether and to what degree working groups are
>     expected to prefer proposals that have "running code" associated with
>     them, over others that do not.
>
>
> 5.  Process Experiment
>
>     The current proposal is proposed as an experiment.  The inclusion of
>     "Implementation Status" sections in Internet-Drafts is not mandatory,
>     but the authors of this document wish to encourage authors of other
>     Internet-Drafts to try out this simple process to discover whether it
>     is useful.  Working group chairs are invited to suggest this process
>     to document editors in their working groups, and to draw the
>     attention of their working group participants to "Implementation
>     Status" sections where they exist.
>
>     Following a community discussion, it was concluded that [RFC3933] is
>     not an appropriate framework for this experiment, primarily because
>     no change is required to any existing process.

It defines a document meta-data encoding mechanism. That's not really a 
"process".


> 7.  Security Considerations
>
>     This is a process document and therefore, it does not have a direct
>     effect on the security of any particular IETF protocol.  Better

Better -> However, better



From torsten@lodderstedt.net  Wed Apr 24 10:16:59 2013
Return-Path: <torsten@lodderstedt.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7076421F963F; Wed, 24 Apr 2013 10:16:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.032
X-Spam-Level: 
X-Spam-Status: No, score=0.032 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xo9bqJ7PCBP5; Wed, 24 Apr 2013 10:16:58 -0700 (PDT)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7009521F961E; Wed, 24 Apr 2013 10:16:41 -0700 (PDT)
Received: from [79.253.49.97] (helo=[192.168.71.56]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1UV3J9-0005Nw-DB; Wed, 24 Apr 2013 19:16:39 +0200
References: <68113CC9-033D-4E61-8190-2D3B9CE92CB0@mnot.net>
Mime-Version: 1.0 (1.0)
In-Reply-To: <68113CC9-033D-4E61-8190-2D3B9CE92CB0@mnot.net>
Content-Type: multipart/alternative; boundary=Apple-Mail-C1161E88-7F4A-42F0-946C-0AAA3EB40977
Content-Transfer-Encoding: 7bit
Message-Id: <77D6DF69-0715-485F-AF6E-D34D5990F5B1@lodderstedt.net>
X-Mailer: iPad Mail (10B329)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Wed, 24 Apr 2013 19:16:37 +0200
To: Mark Nottingham <mnot@mnot.net>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "draft-ietf-oauth-revocation.all@tools.ietf.org" <draft-ietf-oauth-revocation.all@tools.ietf.org>, IESG IESG <iesg@ietf.org>, "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Apps Area Review of draft-ietf-oauth-revocation-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Apr 2013 17:16:59 -0000

--Apple-Mail-C1161E88-7F4A-42F0-946C-0AAA3EB40977
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi Mark,

thanks for your feedback. I added my comments inline.

Am 24.04.2013 um 02:07 schrieb Mark Nottingham <mnot@mnot.net>:

> I have been selected as the Applications Area Review Team reviewer for thi=
s draft (for background on apps-review, please see http://www.apps.ietf.org/=
content/applications-area-review-team).
>=20
> Please resolve these comments along with any other Last Call comments you m=
ay receive. Please wait for direction from your document shepherd or AD befo=
re posting a new version of the draft.
>=20
> Document: draft-ietf-oauth-revocation-07
> Title: Token Revocation
> Reviewer: Mark Nottingham
> Review Date: 24 April 2013
> IETF Last Call Date: 30 April 2013
> IESG Telechat Date: unknown
>=20
> Summary: This draft is has issues that should be fixed before publication.=

>=20
> Major Issues:
>=20
> 1) Section 2 states that the means of discovering the revocation endpoint i=
s out of scope of this specification, and that it can be achieved by consult=
ing documentation.=20
>=20
> This is a poor design choice, at odds with the Web architecture, and fails=
 to provide interoperability. A discovery mechanism should be specified.


I'm surprised about your assessment. My draft is just an extension to RFC674=
9, which leaves discovery out of scope as well.=20
In my opinion, how the clients gets to know the revocation URL is a domain o=
r application specific aspect. I expect OAuth profiles, such as OpenID Conne=
ct, to define this.

>=20
> One way to do it would be to allow the revocation URI to be indicated at a=
n earlier part of the OAuth interchange.=20
>=20
> Another (potentially simpler) to do it would be to assign a URI to the tok=
en itself, and allow a properly authorised client to DELETE that URI; this r=
emoves the need to specify a body format.

And there are much more possible options, e.g. using WebFinger. But is their=
 THE discovery mechanism?
>=20
> Minor Issues:
>=20
> 2) The specification title is too broad; "Token Revocation" could apply to=
 many IETF technologies. Suggest "OAuth Token Revocation".
>=20

I will change the title.

Regards,
Torsten.

>=20
> --
> Mark Nottingham   http://www.mnot.net/
>=20
>=20
>=20

--Apple-Mail-C1161E88-7F4A-42F0-946C-0AAA3EB40977
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><span style=3D"-webkit-text-size-adjust: au=
to; "><div>Hi Mark,</div><div><br></div><div>thanks for your feedback. I add=
ed my comments inline.</div><div><br>Am 24.04.2013 um 02:07 schrieb Mark Not=
tingham &lt;<a href=3D"mailto:mnot@mnot.net">mnot@mnot.net</a>&gt;:<br><br><=
/div><blockquote type=3D"cite"><div><span>I have been selected as the Applic=
ations Area Review Team reviewer for this draft (for background on apps-revi=
ew, please see <a href=3D"http://www.apps.ietf.org/content/applications-area=
-review-team">http://www.apps.ietf.org/content/applications-area-review-team=
</a>).</span><br><span></span><br><span>Please resolve these comments along w=
ith any other Last Call comments you may receive. Please wait for direction f=
rom your document shepherd or AD before posting a new version of the draft.<=
/span><br><span></span><br><span>Document: draft-ietf-oauth-revocation-07</s=
pan><br><span>Title: Token Revocation</span><br><span>Reviewer: Mark Notting=
ham</span><br><span>Review Date: 24 April 2013</span><br><span>IETF Last Cal=
l Date: 30 April 2013</span><br><span>IESG Telechat Date: unknown</span><br>=
<span></span><br><span>Summary: This draft is has issues that should be fixe=
d before publication.</span><br><span></span><br><span>Major Issues:</span><=
br><span></span><br><span>1) Section 2 states that the means of discovering t=
he revocation endpoint is out of scope of this specification, and that it ca=
n be achieved by consulting documentation. </span><br><span></span><br><span=
>This is a poor design choice, at odds with the Web architecture, and fails t=
o provide interoperability. A discovery mechanism should be specified.</span=
><br></div></blockquote><div><br></div><div><br></div><font face=3D".Helveti=
caNeueUI"><span style=3D"font-size: 15px; line-height: 19px; white-space: no=
wrap; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-compo=
sition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-=
color: rgba(77, 128, 180, 0.230469); -webkit-text-size-adjust: none;">I'm su=
rprised about your assessment. My draft is just an extension to </span></fon=
t></span><font face=3D".HelveticaNeueUI"><span style=3D"font-size: 15px; lin=
e-height: 19px; white-space: nowrap; -webkit-tap-highlight-color: rgba(26, 2=
6, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.2304=
69); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);">RFC6749=
, which leaves discovery out of scope as well.&nbsp;</span></font><div><span=
 style=3D"font-size: 15px; line-height: 19px; white-space: nowrap; -webkit-t=
ap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-col=
or: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77,=
 128, 180, 0.230469); ">In my opinion, how the clients gets to know the revo=
cation URL is a domain or application specific aspect. I&nbsp;</span><span s=
tyle=3D"font-size: 15px; line-height: 19px; white-space: nowrap; -webkit-tap=
-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color=
: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 1=
28, 180, 0.230469); ">expect OAuth profiles, such as OpenID Connect, to defi=
ne this.</span><div><div><span style=3D"font-size: 15px; line-height: 19px; w=
hite-space: nowrap; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969);=
 -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-comp=
osition-frame-color: rgba(77, 128, 180, 0.230469);"><br></span><blockquote t=
ype=3D"cite" style=3D"-webkit-text-size-adjust: auto; "><div><span></span><b=
r><span>One way to do it would be to allow the revocation URI to be indicate=
d at an earlier part of the OAuth interchange. </span><br><span></span><br><=
span>Another (potentially simpler) to do it would be to assign a URI to the t=
oken itself, and allow a properly authorised client to DELETE that URI; this=
 removes the need to specify a body format.</span><br></div></blockquote><di=
v><br></div>And there are much more possible options, e.g. using WebFinger. B=
ut is their THE discovery mechanism?<br><blockquote type=3D"cite" style=3D"-=
webkit-text-size-adjust: auto; "><div><span></span><br><span>Minor Issues:</=
span><br><span></span><br><span>2) The specification title is too broad; "To=
ken Revocation" could apply to many IETF technologies. Suggest "OAuth Token R=
evocation".</span><br><span></span><br></div></blockquote><div><br></div>I w=
ill change the title.</div><div><br></div><div>Regards,</div><div>Torsten.</=
div><div><br><blockquote type=3D"cite" style=3D"-webkit-text-size-adjust: au=
to; "><div><span></span><br><span>--</span><br><span>Mark Nottingham &nbsp;&=
nbsp;<a href=3D"http://www.mnot.net/">http://www.mnot.net/</a></span><br><sp=
an></span><br><span></span><br><span></span><br></div></blockquote></div></d=
iv></div></body></html>=

--Apple-Mail-C1161E88-7F4A-42F0-946C-0AAA3EB40977--

From dick.hardt@gmail.com  Wed Apr 24 10:34:54 2013
Return-Path: <dick.hardt@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E5321F8793; Wed, 24 Apr 2013 10:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.714
X-Spam-Level: 
X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10ufuQT40ixO; Wed, 24 Apr 2013 10:34:53 -0700 (PDT)
Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id B03D321F877B; Wed, 24 Apr 2013 10:34:53 -0700 (PDT)
Received: by mail-pa0-f47.google.com with SMTP id bj1so1333235pad.34 for <multiple recipients>; Wed, 24 Apr 2013 10:34:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=8WPJejxm2w6U/hSCRPiDI/z44yzJx08POKpsyBtq3sk=; b=jmQs+6wqJwxoIxyl9VybAF0sAQoFx1l+dOwJPfVFziaRsU9Kp9i+ZUb4T8CVz46uTl uvEwzDj+/uIjfHaAYM/KA+jJDfQkKgiBEBlvlH4yvqq3bBuaGZlDC6YQe1ErBnpEZvaa NNNvK8+yReSTB3Ny4B1GoVCMego3Dpk7LVYvI1hZB6DNymjbASq/Fwb/emSXkjCgLI9m FEstz7urS8A+4zdoe1PHG6qhY3KNDcSOW26xD0tkuSssCdu5ZacCwrQkt1U/S3wHhHjy kh40te0bsKWIx5ouOHosEfCh6ofx6RpEiEH+f0PiKFE7kzHl5VSVz6NTF+FrBgzjdBt7 oQ+w==
X-Received: by 10.66.235.3 with SMTP id ui3mr24637242pac.200.1366824893527; Wed, 24 Apr 2013 10:34:53 -0700 (PDT)
Received: from [10.0.0.58] (c-98-210-193-30.hsd1.ca.comcast.net. [98.210.193.30]) by mx.google.com with ESMTPSA id dr4sm3820761pbb.19.2013.04.24.10.34.50 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Apr 2013 10:34:51 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0DC6BD84-288B-4AF5-AAB0-0B084047AD57"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Dick Hardt <dick.hardt@gmail.com>
In-Reply-To: <77D6DF69-0715-485F-AF6E-D34D5990F5B1@lodderstedt.net>
Date: Wed, 24 Apr 2013 10:34:48 -0700
Message-Id: <2760360C-76A7-40D3-9B57-157FCA9A7A8A@gmail.com>
References: <68113CC9-033D-4E61-8190-2D3B9CE92CB0@mnot.net> <77D6DF69-0715-485F-AF6E-D34D5990F5B1@lodderstedt.net>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: Apple Mail (2.1503)
Cc: draft-ietf-oauth-revocation.all@tools.ietf.org, Mark Nottingham <mnot@mnot.net>, IESG IESG <iesg@ietf.org>, "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Apps Area Review of draft-ietf-oauth-revocation-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Apr 2013 17:34:54 -0000

--Apple-Mail=_0DC6BD84-288B-4AF5-AAB0-0B084047AD57
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Torsten

Unlike RFC 6749 where the user is starting from documentation, OAuth =
Revocation is an extension to an existing protocol.

FWIW: I agree with Mark that having the revocation URL be returned as an =
additional parameter in the access token request similar to how the =
refresh token is preferable.

Use of the  DELETE verb on the revocation URL is a great suggestion and =
makes the protocol more web like and straight forward.

-- Dick

On Apr 24, 2013, at 10:16 AM, Torsten Lodderstedt =
<torsten@lodderstedt.net> wrote:

> Hi Mark,
>=20
> thanks for your feedback. I added my comments inline.
>=20
> Am 24.04.2013 um 02:07 schrieb Mark Nottingham <mnot@mnot.net>:
>=20
>> I have been selected as the Applications Area Review Team reviewer =
for this draft (for background on apps-review, please see =
http://www.apps.ietf.org/content/applications-area-review-team).
>>=20
>> Please resolve these comments along with any other Last Call comments =
you may receive. Please wait for direction from your document shepherd =
or AD before posting a new version of the draft.
>>=20
>> Document: draft-ietf-oauth-revocation-07
>> Title: Token Revocation
>> Reviewer: Mark Nottingham
>> Review Date: 24 April 2013
>> IETF Last Call Date: 30 April 2013
>> IESG Telechat Date: unknown
>>=20
>> Summary: This draft is has issues that should be fixed before =
publication.
>>=20
>> Major Issues:
>>=20
>> 1) Section 2 states that the means of discovering the revocation =
endpoint is out of scope of this specification, and that it can be =
achieved by consulting documentation.=20
>>=20
>> This is a poor design choice, at odds with the Web architecture, and =
fails to provide interoperability. A discovery mechanism should be =
specified.
>=20
>=20
> I'm surprised about your assessment. My draft is just an extension to =
RFC6749, which leaves discovery out of scope as well.=20
> In my opinion, how the clients gets to know the revocation URL is a =
domain or application specific aspect. I expect OAuth profiles, such as =
OpenID Connect, to define this.
>=20
>>=20
>> One way to do it would be to allow the revocation URI to be indicated =
at an earlier part of the OAuth interchange.=20
>>=20
>> Another (potentially simpler) to do it would be to assign a URI to =
the token itself, and allow a properly authorised client to DELETE that =
URI; this removes the need to specify a body format.
>=20
> And there are much more possible options, e.g. using WebFinger. But is =
their THE discovery mechanism?
>>=20
>> Minor Issues:
>>=20
>> 2) The specification title is too broad; "Token Revocation" could =
apply to many IETF technologies. Suggest "OAuth Token Revocation".
>>=20
>=20
> I will change the title.
>=20
> Regards,
> Torsten.
>=20
>>=20
>> --
>> Mark Nottingham   http://www.mnot.net/
>>=20
>>=20
>>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


--Apple-Mail=_0DC6BD84-288B-4AF5-AAB0-0B084047AD57
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi =
Torsten<div><br></div><div>Unlike RFC 6749 where the user is starting =
from documentation, OAuth Revocation is an extension to an existing =
protocol.</div><div><br></div><div>FWIW: I agree with Mark that having =
the revocation URL be returned as an additional parameter in the access =
token request similar to how the refresh token is =
preferable.<div><br></div><div>Use of the &nbsp;DELETE verb on the =
revocation URL is a great suggestion and makes the protocol more web =
like and straight forward.</div><div><br></div><div>-- =
Dick<br><div><br><div><div>On Apr 24, 2013, at 10:16 AM, Torsten =
Lodderstedt &lt;<a =
href=3D"mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"><div dir=3D"auto"><span =
style=3D"-webkit-text-size-adjust: auto; "><div>Hi =
Mark,</div><div><br></div><div>thanks for your feedback. I added my =
comments inline.</div><div><br>Am 24.04.2013 um 02:07 schrieb Mark =
Nottingham &lt;<a =
href=3D"mailto:mnot@mnot.net">mnot@mnot.net</a>&gt;:<br><br></div><blockqu=
ote type=3D"cite"><span>I have been selected as the Applications Area =
Review Team reviewer for this draft (for background on apps-review, =
please see <a =
href=3D"http://www.apps.ietf.org/content/applications-area-review-team">ht=
tp://www.apps.ietf.org/content/applications-area-review-team</a>).</span><=
br><span></span><br><span>Please resolve these comments along with any =
other Last Call comments you may receive. Please wait for direction from =
your document shepherd or AD before posting a new version of the =
draft.</span><br><span></span><br><span>Document: =
draft-ietf-oauth-revocation-07</span><br><span>Title: Token =
Revocation</span><br><span>Reviewer: Mark =
Nottingham</span><br><span>Review Date: 24 April =
2013</span><br><span>IETF Last Call Date: 30 April =
2013</span><br><span>IESG Telechat Date: =
unknown</span><br><span></span><br><span>Summary: This draft is has =
issues that should be fixed before =
publication.</span><br><span></span><br><span>Major =
Issues:</span><br><span></span><br><span>1) Section 2 states that the =
means of discovering the revocation endpoint is out of scope of this =
specification, and that it can be achieved by consulting documentation. =
</span><br><span></span><br><span>This is a poor design choice, at odds =
with the Web architecture, and fails to provide interoperability. A =
discovery mechanism should be =
specified.</span><br></blockquote><div><br></div><div><br></div><font =
face=3D".HelveticaNeueUI"><span style=3D"font-size: 15px; line-height: =
19px; white-space: nowrap; -webkit-tap-highlight-color: rgba(26, 26, 26, =
0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, =
0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, =
0.230469); -webkit-text-size-adjust: none;">I'm surprised about your =
assessment. My draft is just an extension to </span></font></span><font =
face=3D".HelveticaNeueUI"><span style=3D"font-size: 15px; line-height: =
19px; white-space: nowrap; -webkit-tap-highlight-color: rgba(26, 26, 26, =
0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, =
0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, =
0.230469);">RFC6749, which leaves discovery out of scope as =
well.&nbsp;</span></font><div><span style=3D"font-size: 15px; =
line-height: 19px; white-space: nowrap; -webkit-tap-highlight-color: =
rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, =
192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, =
0.230469); ">In my opinion, how the clients gets to know the revocation =
URL is a domain or application specific aspect. I&nbsp;</span><span =
style=3D"font-size: 15px; line-height: 19px; white-space: nowrap; =
-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); =
-webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); =
-webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">expect =
OAuth profiles, such as OpenID Connect, to define =
this.</span><div><div><span style=3D"font-size: 15px; line-height: 19px; =
white-space: nowrap; -webkit-tap-highlight-color: rgba(26, 26, 26, =
0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, =
0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, =
0.230469);"><br></span><blockquote type=3D"cite" =
style=3D"-webkit-text-size-adjust: auto; "><span></span><br><span>One =
way to do it would be to allow the revocation URI to be indicated at an =
earlier part of the OAuth interchange. =
</span><br><span></span><br><span>Another (potentially simpler) to do it =
would be to assign a URI to the token itself, and allow a properly =
authorised client to DELETE that URI; this removes the need to specify a =
body format.</span><br></blockquote><div><br></div>And there are much =
more possible options, e.g. using WebFinger. But is their THE discovery =
mechanism?<br><blockquote type=3D"cite" style=3D"-webkit-text-size-adjust:=
 auto; "><span></span><br><span>Minor =
Issues:</span><br><span></span><br><span>2) The specification title is =
too broad; "Token Revocation" could apply to many IETF technologies. =
Suggest "OAuth Token =
Revocation".</span><br><span></span><br></blockquote><div><br></div>I =
will change the =
title.</div><div><br></div><div>Regards,</div><div>Torsten.</div><div><br>=
<blockquote type=3D"cite" style=3D"-webkit-text-size-adjust: auto; =
"><span></span><br><span>--</span><br><span>Mark Nottingham =
&nbsp;&nbsp;<a =
href=3D"http://www.mnot.net/">http://www.mnot.net/</a></span><br><span></s=
pan><br><span></span><br><span></span><br></blockquote></div></div></div><=
/div>_______________________________________________<br>apps-discuss =
mailing list<br><a =
href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>https:/=
/www.ietf.org/mailman/listinfo/apps-discuss<br></blockquote></div><br></di=
v></div></div></body></html>=

--Apple-Mail=_0DC6BD84-288B-4AF5-AAB0-0B084047AD57--

From torsten@lodderstedt.net  Wed Apr 24 11:06:50 2013
Return-Path: <torsten@lodderstedt.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6135B21F8C38; Wed, 24 Apr 2013 11:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.032
X-Spam-Level: 
X-Spam-Status: No, score=0.032 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghs1VybHKwVe; Wed, 24 Apr 2013 11:06:49 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 0D45B21F896D; Wed, 24 Apr 2013 11:06:49 -0700 (PDT)
Received: from [79.253.49.97] (helo=[192.168.71.56]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1UV45f-0007R8-1y; Wed, 24 Apr 2013 20:06:47 +0200
References: <68113CC9-033D-4E61-8190-2D3B9CE92CB0@mnot.net> <77D6DF69-0715-485F-AF6E-D34D5990F5B1@lodderstedt.net> <2760360C-76A7-40D3-9B57-157FCA9A7A8A@gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <2760360C-76A7-40D3-9B57-157FCA9A7A8A@gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-2763BD80-1BD5-465D-8CE9-CE3858B29B30
Content-Transfer-Encoding: 7bit
Message-Id: <EAA8FD66-1F5F-4A36-A1A2-677BD34AC102@lodderstedt.net>
X-Mailer: iPad Mail (10B329)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Wed, 24 Apr 2013 20:06:45 +0200
To: Dick Hardt <dick.hardt@gmail.com>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "draft-ietf-oauth-revocation.all@tools.ietf.org" <draft-ietf-oauth-revocation.all@tools.ietf.org>, Mark Nottingham <mnot@mnot.net>, IESG IESG <iesg@ietf.org>, "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Apps Area Review of draft-ietf-oauth-revocation-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Apr 2013 18:06:50 -0000

--Apple-Mail-2763BD80-1BD5-465D-8CE9-CE3858B29B30
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi Dick,



Am 24.04.2013 um 19:34 schrieb Dick Hardt <dick.hardt@gmail.com>:

> Hi Torsten
>=20
> Unlike RFC 6749 where the user is starting from documentation, OAuth Revoc=
ation is an extension to an existing protocol.
>=20

I don't get your point. Revocation is an extension to the OAuth framework.
Why is the situation any different from any other endpoint?

> FWIW: I agree with Mark that having the revocation URL be returned as an a=
dditional parameter in the access token request similar to how the refresh t=
oken is preferable.


>=20
> Use of the  DELETE verb on the revocation URL is a great suggestion and ma=
kes the protocol more web like and straight forward.
>=20

We discussed this and other alternative options a long time ago and the WG d=
ecided to go for the design described in the draft.

Regards,
Torsten.
> -- Dick
>=20
> On Apr 24, 2013, at 10:16 AM, Torsten Lodderstedt <torsten@lodderstedt.net=
> wrote:
>=20
>> Hi Mark,
>>=20
>> thanks for your feedback. I added my comments inline.
>>=20
>> Am 24.04.2013 um 02:07 schrieb Mark Nottingham <mnot@mnot.net>:
>>=20
>>> I have been selected as the Applications Area Review Team reviewer for t=
his draft (for background on apps-review, please see http://www.apps.ietf.or=
g/content/applications-area-review-team).
>>>=20
>>> Please resolve these comments along with any other Last Call comments yo=
u may receive. Please wait for direction from your document shepherd or AD b=
efore posting a new version of the draft.
>>>=20
>>> Document: draft-ietf-oauth-revocation-07
>>> Title: Token Revocation
>>> Reviewer: Mark Nottingham
>>> Review Date: 24 April 2013
>>> IETF Last Call Date: 30 April 2013
>>> IESG Telechat Date: unknown
>>>=20
>>> Summary: This draft is has issues that should be fixed before publicatio=
n.
>>>=20
>>> Major Issues:
>>>=20
>>> 1) Section 2 states that the means of discovering the revocation endpoin=
t is out of scope of this specification, and that it can be achieved by cons=
ulting documentation.=20
>>>=20
>>> This is a poor design choice, at odds with the Web architecture, and fai=
ls to provide interoperability. A discovery mechanism should be specified.
>>=20
>>=20
>> I'm surprised about your assessment. My draft is just an extension to RFC=
6749, which leaves discovery out of scope as well.=20
>> In my opinion, how the clients gets to know the revocation URL is a domai=
n or application specific aspect. I expect OAuth profiles, such as OpenID Co=
nnect, to define this.
>>=20
>>>=20
>>> One way to do it would be to allow the revocation URI to be indicated at=
 an earlier part of the OAuth interchange.=20
>>>=20
>>> Another (potentially simpler) to do it would be to assign a URI to the t=
oken itself, and allow a properly authorised client to DELETE that URI; this=
 removes the need to specify a body format.
>>=20
>> And there are much more possible options, e.g. using WebFinger. But is th=
eir THE discovery mechanism?
>>>=20
>>> Minor Issues:
>>>=20
>>> 2) The specification title is too broad; "Token Revocation" could apply t=
o many IETF technologies. Suggest "OAuth Token Revocation".
>>=20
>> I will change the title.
>>=20
>> Regards,
>> Torsten.
>>=20
>>>=20
>>> --
>>> Mark Nottingham   http://www.mnot.net/
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20

--Apple-Mail-2763BD80-1BD5-465D-8CE9-CE3858B29B30
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Hi Dick,</div><div><br></div><div><br>=
</div><div><br>Am 24.04.2013 um 19:34 schrieb Dick Hardt &lt;<a href=3D"mail=
to:dick.hardt@gmail.com">dick.hardt@gmail.com</a>&gt;:<br><br></div><blockqu=
ote type=3D"cite"><div><meta http-equiv=3D"Content-Type" content=3D"text/htm=
l charset=3Dus-ascii">Hi Torsten<div><br></div><div>Unlike RFC 6749 where th=
e user is starting from documentation, OAuth Revocation is an extension to a=
n existing protocol.</div><div><br></div></div></blockquote><div><br></div>I=
 don't get your point. Revocation is an extension to the OAuth framework.<di=
v>Why is the situation any different from any other endpoint?</div><div><div=
><br><blockquote type=3D"cite"><div><div>FWIW: I agree with Mark that having=
 the revocation URL be returned as an additional parameter in the access tok=
en request similar to how the refresh token is preferable.</div></div></bloc=
kquote></div><div><br><blockquote type=3D"cite"><div><div><div><br></div><di=
v>Use of the &nbsp;DELETE verb on the revocation URL is a great suggestion a=
nd makes the protocol more web like and straight forward.</div><div><br></di=
v></div></div></blockquote><div><br></div>We discussed this and other altern=
ative options a long time ago and the WG decided to go for the design descri=
bed in the draft.<div><br></div><div>Regards,</div><div>Torsten.<br><blockqu=
ote type=3D"cite"><div><div><div>-- Dick<br><div><br><div><div>On Apr 24, 20=
13, at 10:16 AM, Torsten Lodderstedt &lt;<a href=3D"mailto:torsten@lodderste=
dt.net">torsten@lodderstedt.net</a>&gt; wrote:</div><br class=3D"Apple-inter=
change-newline"><blockquote type=3D"cite"><meta http-equiv=3D"content-type" c=
ontent=3D"text/html; charset=3Dutf-8"><div dir=3D"auto"><span style=3D"-webk=
it-text-size-adjust: auto; "><div>Hi Mark,</div><div><br></div><div>thanks f=
or your feedback. I added my comments inline.</div><div><br>Am 24.04.2013 um=
 02:07 schrieb Mark Nottingham &lt;<a href=3D"mailto:mnot@mnot.net">mnot@mno=
t.net</a>&gt;:<br><br></div><blockquote type=3D"cite"><span>I have been sele=
cted as the Applications Area Review Team reviewer for this draft (for backg=
round on apps-review, please see <a href=3D"http://www.apps.ietf.org/content=
/applications-area-review-team">http://www.apps.ietf.org/content/application=
s-area-review-team</a>).</span><br><span></span><br><span>Please resolve the=
se comments along with any other Last Call comments you may receive. Please w=
ait for direction from your document shepherd or AD before posting a new ver=
sion of the draft.</span><br><span></span><br><span>Document: draft-ietf-oau=
th-revocation-07</span><br><span>Title: Token Revocation</span><br><span>Rev=
iewer: Mark Nottingham</span><br><span>Review Date: 24 April 2013</span><br>=
<span>IETF Last Call Date: 30 April 2013</span><br><span>IESG Telechat Date:=
 unknown</span><br><span></span><br><span>Summary: This draft is has issues t=
hat should be fixed before publication.</span><br><span></span><br><span>Maj=
or Issues:</span><br><span></span><br><span>1) Section 2 states that the mea=
ns of discovering the revocation endpoint is out of scope of this specificat=
ion, and that it can be achieved by consulting documentation. </span><br><sp=
an></span><br><span>This is a poor design choice, at odds with the Web archi=
tecture, and fails to provide interoperability. A discovery mechanism should=
 be specified.</span><br></blockquote><div><br></div><div><br></div><font fa=
ce=3D".HelveticaNeueUI"><span style=3D"font-size: 15px; line-height: 19px; w=
hite-space: nowrap; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969);=
 -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-comp=
osition-frame-color: rgba(77, 128, 180, 0.230469); -webkit-text-size-adjust:=
 none;">I'm surprised about your assessment. My draft is just an extension t=
o </span></font></span><font face=3D".HelveticaNeueUI"><span style=3D"font-s=
ize: 15px; line-height: 19px; white-space: nowrap; -webkit-tap-highlight-col=
or: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 19=
2, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230=
469);">RFC6749, which leaves discovery out of scope as well.&nbsp;</span></f=
ont><div><span style=3D"font-size: 15px; line-height: 19px; white-space: now=
rap; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-compos=
ition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-c=
olor: rgba(77, 128, 180, 0.230469); ">In my opinion, how the clients gets to=
 know the revocation URL is a domain or application specific aspect. I&nbsp;=
</span><span style=3D"font-size: 15px; line-height: 19px; white-space: nowra=
p; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composit=
ion-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-col=
or: rgba(77, 128, 180, 0.230469); ">expect OAuth profiles, such as OpenID Co=
nnect, to define this.</span><div><div><span style=3D"font-size: 15px; line-=
height: 19px; white-space: nowrap; -webkit-tap-highlight-color: rgba(26, 26,=
 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469=
); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);"><br></spa=
n><blockquote type=3D"cite" style=3D"-webkit-text-size-adjust: auto; "><span=
></span><br><span>One way to do it would be to allow the revocation URI to b=
e indicated at an earlier part of the OAuth interchange. </span><br><span></=
span><br><span>Another (potentially simpler) to do it would be to assign a U=
RI to the token itself, and allow a properly authorised client to DELETE tha=
t URI; this removes the need to specify a body format.</span><br></blockquot=
e><div><br></div>And there are much more possible options, e.g. using WebFin=
ger. But is their THE discovery mechanism?<br><blockquote type=3D"cite" styl=
e=3D"-webkit-text-size-adjust: auto; "><span></span><br><span>Minor Issues:<=
/span><br><span></span><br><span>2) The specification title is too broad; "T=
oken Revocation" could apply to many IETF technologies. Suggest "OAuth Token=
 Revocation".</span><br><span></span><br></blockquote><div><br></div>I will c=
hange the title.</div><div><br></div><div>Regards,</div><div>Torsten.</div><=
div><br><blockquote type=3D"cite" style=3D"-webkit-text-size-adjust: auto; "=
><span></span><br><span>--</span><br><span>Mark Nottingham &nbsp;&nbsp;<a hr=
ef=3D"http://www.mnot.net/">http://www.mnot.net/</a></span><br><span></span>=
<br><span></span><br><span></span><br></blockquote></div></div></div></div>_=
______________________________________________<br>apps-discuss mailing list<=
br><a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br><a h=
ref=3D"https://www.ietf.org/mailman/listinfo/apps-discuss">https://www.ietf.=
org/mailman/listinfo/apps-discuss</a><br></blockquote></div><br></div></div>=
</div></div></blockquote></div></div></div></body></html>=

--Apple-Mail-2763BD80-1BD5-465D-8CE9-CE3858B29B30--

From markus.lanthaler@gmx.net  Wed Apr 24 11:52:48 2013
Return-Path: <markus.lanthaler@gmx.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B71B21F910E for <apps-discuss@ietfa.amsl.com>; Wed, 24 Apr 2013 11:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level: 
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYGxA+AoFylp for <apps-discuss@ietfa.amsl.com>; Wed, 24 Apr 2013 11:52:48 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id DAFAD21F9104 for <apps-discuss@ietf.org>; Wed, 24 Apr 2013 11:52:47 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Ltkst-1UfQPj2Q2H-0118Zo for <apps-discuss@ietf.org>; Wed, 24 Apr 2013 20:52:46 +0200
Received: (qmail invoked by alias); 24 Apr 2013 18:52:46 -0000
Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp001) with SMTP; 24 Apr 2013 20:52:46 +0200
X-Authenticated: #419883
X-Provags-ID: V01U2FsdGVkX1/WkJhWdWDWAOjuQq0S4/qZVXLdkdASK6cb0ruvq0 GTMXWqE1aaU/+W
From: "Markus Lanthaler" <markus.lanthaler@gmx.net>
To: "'Murray S. Kucherawy'" <superuser@gmail.com>
References: <516e8a54.45f7440a.7dcc.1253SMTPIN_ADDED_BROKEN@mx.google.com>	<CAL0qLwb+9CYnOYw9kcMdzZvyPagcUrhxUkmOiMZNAXpzFe6MYA@mail.gmail.com>	<CAC4RtVC+rr0ZwBRk0jit7Ye-7H6D8yawiW7OG2RFhns5jqbQyQ@mail.gmail.com>	<516f06c9.c1c20e0a.46f3.ffffb0bfSMTPIN_ADDED_BROKEN@mx.google.com> <CAL0qLwY5LHuVdk__ySDDxBjsyfV0c5yTxZSRKj+Me5b+-2TsqA@mail.gmail.com>
In-Reply-To: <CAL0qLwY5LHuVdk__ySDDxBjsyfV0c5yTxZSRKj+Me5b+-2TsqA@mail.gmail.com>
Date: Wed, 24 Apr 2013 20:52:41 +0200
Message-ID: <00cb01ce411c$e744ab50$b5ce01f0$@lanthaler@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac474yvfacmw20RERwCD14m59HnlygFOREow
Content-Language: de
X-Y-GMX-Trusted: 0
Cc: 'Barry Leiba' <barryleiba@computer.org>, 'IETF Apps Discuss' <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] FW: New Version Notification for draft-lanthaler-profile-registry-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Apr 2013 18:52:48 -0000

On Thursday, April 18, 2013 5:17 AM, Murray S. Kucherawy wrote:=20

> > On Wed, Apr 17, 2013 at 1:32 PM, Markus Lanthaler wrote:
> > OK.. so I think all I can do now is to kindly ask the appsawg =
whether it
is
> > interested in this work and use the document as starting point for =
the
rest
> > of the process.
>
> You have thus asked the question.=A0 Do any participants have comments =
in
> support or opposition?
> -MSK, APPSAWG co-chair

Unfortunately there haven't been many reactions. So, how do we proceed?


Thanks,
Markus


--
Markus Lanthaler
@markuslanthaler


From dave@cridland.net  Wed Apr 24 12:33:29 2013
Return-Path: <dave@cridland.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CCD21F8900 for <apps-discuss@ietfa.amsl.com>; Wed, 24 Apr 2013 12:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.477
X-Spam-Level: 
X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX49LP3VdYRz for <apps-discuss@ietfa.amsl.com>; Wed, 24 Apr 2013 12:33:28 -0700 (PDT)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDFE21F8700 for <apps-discuss@ietf.org>; Wed, 24 Apr 2013 12:33:27 -0700 (PDT)
Received: by mail-oa0-f44.google.com with SMTP id h1so2127329oag.31 for <apps-discuss@ietf.org>; Wed, 24 Apr 2013 12:33:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=d10Hzzzf6UHcNmfObyriD1PH4OTcs54YhHY5jdCnXrI=; b=SfRceLCgJP5L6c4jgv2CibM8S0IEH1D1FhnijN9NNBsYrQG8FyRA79OjB7NFnJikZI cXwFaB8zqzaiqu9DDiKs9Y4i98D9zxS82xyoY0fJLcP4I+lKuEbh3rfKusyWjIIYWNd8 CUCuOQ5pZJKHPXL2Adxq2ZAedF9Y2nHbBR+ME=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=d10Hzzzf6UHcNmfObyriD1PH4OTcs54YhHY5jdCnXrI=; b=TkRoEuUplFKB3bq6XEy65uRb115JNJrsvFecU0ROLN2U0TzXnB3PmbJjeYvyWd7Hiv FFu3BDRH0/5cvweXy1M89HVF8kVqNfnqPLZ9u6mhj24W7PapF+HVZa9w9txAUxS4qPRg yeq28lnLCMKeB9ZxHyGlqJ9xWcepytLwo/BWoSIDEpfBOSnGvqvveAkdGH5DKUM2y0SK FCa5Ii2afpSytjPgfImDkWupkpoVw5n8doUi7j2Xs1Ll5eSNgVlnTX9MiXDfKNJkey8g k8OFFAbp6XyUQzL5/RYHQn0CYXedUTc5tC9nhfXhDmf1LFy5QweY8+LivbWQhHiKj88u MMQA==
MIME-Version: 1.0
X-Received: by 10.60.131.240 with SMTP id op16mr7171029oeb.12.1366832007377; Wed, 24 Apr 2013 12:33:27 -0700 (PDT)
Received: by 10.60.13.200 with HTTP; Wed, 24 Apr 2013 12:33:27 -0700 (PDT)
Received: by 10.60.13.200 with HTTP; Wed, 24 Apr 2013 12:33:27 -0700 (PDT)
In-Reply-To: <51782a0a.21f2440a.747e.5f13SMTPIN_ADDED_BROKEN@mx.google.com>
References: <516e8a54.45f7440a.7dcc.1253SMTPIN_ADDED_BROKEN@mx.google.com> <CAL0qLwb+9CYnOYw9kcMdzZvyPagcUrhxUkmOiMZNAXpzFe6MYA@mail.gmail.com> <CAC4RtVC+rr0ZwBRk0jit7Ye-7H6D8yawiW7OG2RFhns5jqbQyQ@mail.gmail.com> <516f06c9.c1c20e0a.46f3.ffffb0bfSMTPIN_ADDED_BROKEN@mx.google.com> <CAL0qLwY5LHuVdk__ySDDxBjsyfV0c5yTxZSRKj+Me5b+-2TsqA@mail.gmail.com> <51782a0a.21f2440a.747e.5f13SMTPIN_ADDED_BROKEN@mx.google.com>
Date: Wed, 24 Apr 2013 20:33:27 +0100
Message-ID: <CAKHUCzyEy33RMt-cmRPwy00xyE4qP1GYMmMv475XQQnKFu+CaQ@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
Content-Type: multipart/alternative; boundary=047d7b471f4c4485d604db206024
X-Gm-Message-State: ALoCoQlnhUTTDBtitwjTkPvgzCh7oRPUR6jI+IH9aaPWNNmWrnwWdy7RUTJJl2ZLtymEtv/jxEmW
Cc: Barry Leiba <barryleiba@computer.org>, apps-discuss@ietf.org
Subject: Re: [apps-discuss] FW: New Version Notification for draft-lanthaler-profile-registry-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Apr 2013 19:33:29 -0000

--047d7b471f4c4485d604db206024
Content-Type: text/plain; charset=ISO-8859-1

Oh, sorry.

I've no objections. The work seems to be needed, if I understand the
situation correctly, and would appear to be within the working group's
remit.

It's not really my field, but I'm happy to devote a cycle or two for
reviewing.

--047d7b471f4c4485d604db206024
Content-Type: text/html; charset=ISO-8859-1

<p dir="ltr">Oh, sorry.</p>
<p dir="ltr">I&#39;ve no objections. The work seems to be needed, if I understand the situation correctly, and would appear to be within the working group&#39;s remit.</p>
<p dir="ltr">It&#39;s not really my field, but I&#39;m happy to devote a cycle or two for reviewing.</p>

--047d7b471f4c4485d604db206024--

From jan.algermissen@nordsc.com  Wed Apr 24 13:49:24 2013
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F4421F85EE; Wed, 24 Apr 2013 13:49:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXl06Wnik5Uw; Wed, 24 Apr 2013 13:49:24 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5217121F85E8; Wed, 24 Apr 2013 13:49:23 -0700 (PDT)
Received: from [192.168.2.102] (p548FAF67.dip0.t-ipconnect.de [84.143.175.103]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MAkiB-1UKyYR3Ajr-00C4qQ; Wed, 24 Apr 2013 22:49:17 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <77D6DF69-0715-485F-AF6E-D34D5990F5B1@lodderstedt.net>
Date: Wed, 24 Apr 2013 22:49:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D656389-2D20-4FC8-A88A-395593E77FAC@nordsc.com>
References: <68113CC9-033D-4E61-8190-2D3B9CE92CB0@mnot.net> <77D6DF69-0715-485F-AF6E-D34D5990F5B1@lodderstedt.net>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: Apple Mail (2.1499)
X-Provags-ID: V02:K0:Wn9ZTuU5QHEBK9dqB9190mkRNlg0buof/7HF3iKI99i RrBhNZFAiO4gbZ0XGg6DLziparbTQfGLbeoCxOnbmzycqr09qL vnx2o6LtGQQiYSzjT56CpwZK93qdsO51N7wmQqCvi5VGQ+9v1D twKEDbdCdqIDiu7tsHACOPF6bzg540I7BZt+qGMuc+/geTUJyy SCu6zIG8IMqyWxUtXkomNYPZJxSTvMpjBoRhUDQsobDuMSk1a4 lHXgLXeCsS+zB5h76Ix8jbbxq/eKPymruFzcynzDFG4QTu+U4L syXtIIz8IjeK8D/k+WqLwjhY5uaV5CSaTCohuNsUZ8F40Glsl9 03tUdDmFHPToOopcMt/0bMVhsl+JycyShkHGEPeK25KBo2xLZH 6j61AMsqWYlHA==
Cc: draft-ietf-oauth-revocation.all@tools.ietf.org, Mark Nottingham <mnot@mnot.net>, IESG IESG <iesg@ietf.org>, "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Apps Area Review of draft-ietf-oauth-revocation-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Apr 2013 20:49:24 -0000

On 24.04.2013, at 19:16, Torsten Lodderstedt <torsten@lodderstedt.net> =
wrote:

> Hi Mark,
>=20
> thanks for your feedback. I added my comments inline.
>=20
> Am 24.04.2013 um 02:07 schrieb Mark Nottingham <mnot@mnot.net>:
>=20
>>=20
>> One way to do it would be to allow the revocation URI to be indicated =
at an earlier part of the OAuth interchange.=20
>>=20
>> Another (potentially simpler) to do it would be to assign a URI to =
the token itself, and allow a properly authorised client to DELETE that =
URI; this removes the need to specify a body format.
>=20
> And there are much more possible options, e.g. using WebFinger. But is =
their THE discovery mechanism?

What is the point of a specification that avoids making decisions? Being =
in the HTTP environment actually provides so detailed 'guidelines' how =
to do design such things like discovery and deletion of 'stuff' that it =
makes no sense whatsoever to defer that to, um, profiles (which is sort =
of a synonym for 'dunno, shove that decision in that future basket').

Stick a post in the ground and move on :-)

My 2c

Jan=

From sm@elandsys.com  Wed Apr 24 21:56:00 2013
Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A607B21F9120 for <apps-discuss@ietfa.amsl.com>; Wed, 24 Apr 2013 21:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sf8nVqVQN86B for <apps-discuss@ietfa.amsl.com>; Wed, 24 Apr 2013 21:56:00 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C373421F8712 for <apps-discuss@ietf.org>; Wed, 24 Apr 2013 21:55:59 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.138.130]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3P4tWws012233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Apr 2013 21:55:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1366865751; bh=m0mrHwzL/ek4T7iqzNsCtqxpNSlSZHzeQQAlMYKm+t8=; h=Date:To:From:Subject:Cc; b=yol/pV7ZalnM4wv9RqPpO9u0RSI2QFC6mKlA5aVFhyex7hVZ/69Z/zMIKKUn7xnZl CTI4FMjLDam2OrxClFYBtDcpv6Q0+TWwS25fSlQozq2fzi8jR05SBPpH0MuI/HCPot crKskrOeQUhBVKbf8xNRrs/R2xW+iS3zIXSX45K4=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1366865751; i=@elandsys.com; bh=m0mrHwzL/ek4T7iqzNsCtqxpNSlSZHzeQQAlMYKm+t8=; h=Date:To:From:Subject:Cc; b=E4IiPO3oF2tXUXQRpNuRdVPwc0OAG53bWn80H0FlAjd2Wz3oS3uUlcKvbMSATOFU6 plbN44v61TivxIO/YEKt6dzRZ2QmVDZhNQUe9lhWr034grkDzKrCwsy2Clx8iK20to CjRuDeozE0vOf0qqheFvuCvB3x2YZ+UexbH+Jprk=
Message-Id: <6.2.5.6.2.20130424214755.0a3408d0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 24 Apr 2013 21:55:06 -0700
To: Salvatore Loreto <salvatore.loreto@ericsson.com>
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Barry Leiba <barryleiba@computer.org>, apps-discuss@ietf.org
Subject: [apps-discuss] Status of draft-ietf-appsawg-rfc5451bis-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Apr 2013 04:56:00 -0000

Hi Sal,

There has been a short discussion about 
draft-ietf-appsawg-rfc5451bis-00 and that is reflected in the 
draft.  I suggest moving the draft to WGLC.

Thanks,
S. Moonesamy (as document shepherd)


From dret@berkeley.edu  Fri Apr 26 10:20:39 2013
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CADE21F997D for <apps-discuss@ietfa.amsl.com>; Fri, 26 Apr 2013 10:20:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pt7Hcx0MqRDM for <apps-discuss@ietfa.amsl.com>; Fri, 26 Apr 2013 10:20:38 -0700 (PDT)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA1021F9971 for <apps-discuss@ietf.org>; Fri, 26 Apr 2013 10:20:38 -0700 (PDT)
Received: from c-71-226-42-42.hsd1.az.comcast.net ([71.226.42.42] helo=dretair.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1UVmK2-00043n-E3; Fri, 26 Apr 2013 10:20:35 -0700
Message-ID: <517AB75F.7020904@berkeley.edu>
Date: Fri, 26 Apr 2013 10:20:31 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CA+-NybWfR47yScyTBi7BRpJgj5SnCxWY1rDV5KC8PuE+JEV90A@mail.gmail.com>
In-Reply-To: <CA+-NybWfR47yScyTBi7BRpJgj5SnCxWY1rDV5KC8PuE+JEV90A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Joe Gregorio <joe@bitworking.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2013 17:20:39 -0000

hello joe.

thanks for the response!

On 2013-04-17 07:03 , Joe Gregorio wrote:
> On Mon, Apr 8, 2013 at 1:41 AM, Erik Wilde <dret@berkeley.edu> wrote:
>> https://github.com/dret/uritemplate-test/blob/master/spec-examples-by-section.json
>> (line 234) says it's "X", but i am really interested in the "why"
>> explanation as well. http://tools.ietf.org/html/rfc6570#section-3.2.5 says
>> that
> The answer is in the text you quote:
> "for each defined variable in the variable-list, append '.' to the
> result string and then perform variable expansion"
> The set of variables in the variable list is the empty set, so no '.'
> is appended.
> I agree that if this is confusing an addendum is in order.

... and just when i wanted to submit an erratum and searched for the 
best place where to put clarifying text, i ran into the last paragraph 
of http://tools.ietf.org/html/rfc6570#section-2.3 :

"A variable defined as a list value is considered undefined if the list 
contains zero members. A variable defined as an associative array of 
(name, value) pairs is considered undefined if the array contains zero 
members or if all member names in the array are associated with 
undefined values."

while still being a bit of an unintuitive definition for me, it seems as 
if this particular paragraph was never mentioned in previous 
discussions, and indeed clarifies that an empty array should be 
considered as an "undefined variable". for now, i'll assume that this 
settles things and will not file an erratum. but if people think 
(fracis? james?) that this still isn't good enough, then please speak up.

thanks and cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

From jasnell@gmail.com  Fri Apr 26 10:28:19 2013
Return-Path: <jasnell@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AF421F95EE for <apps-discuss@ietfa.amsl.com>; Fri, 26 Apr 2013 10:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.954
X-Spam-Level: 
X-Spam-Status: No, score=-6.954 tagged_above=-999 required=5 tests=[AWL=-3.355, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH02Gji7WfgQ for <apps-discuss@ietfa.amsl.com>; Fri, 26 Apr 2013 10:28:18 -0700 (PDT)
Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id 938DD21F8ADC for <apps-discuss@ietf.org>; Fri, 26 Apr 2013 10:28:18 -0700 (PDT)
Received: by mail-oa0-f41.google.com with SMTP id g12so4281617oah.0 for <apps-discuss@ietf.org>; Fri, 26 Apr 2013 10:28:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=WuUdlADtvmND3VDp2PW3piIIBlT4bb5zJyz8doUmIDY=; b=BIgOw5rD323qS2EikQxDXGb9/pcl6dXoztnd71tlsbJKEgf2Z6hnFtL/KToJ+rflHD ogBMus4IyzNhlIP6uwhf7F5fKu1cgFZtBlfBM4GkPCAQICq+7m8IAhGty7lpXkwXxNUA 2fFj0hcVWbSMv52Pj9UVFEyfOugewY8qap+cgAL6cb0dj1rnnWZOQQZn7yo28AAidq4m 14VtcomB5lQmW0e7bgMQeArXw8CVRcGdoSEw+E7UnpAUGiPSzyUO2X9mgaSdoPg+03HB kqTh4t93//Isk4dXydcQWvnmD8lB8J+pfczFqSH3jmvBBYdt6ND5Q7JAkHrj724cY7qP Zqew==
X-Received: by 10.182.156.103 with SMTP id wd7mr22743990obb.33.1366997298110;  Fri, 26 Apr 2013 10:28:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.3.137 with HTTP; Fri, 26 Apr 2013 10:27:58 -0700 (PDT)
In-Reply-To: <517AB75F.7020904@berkeley.edu>
References: <CALcybBBXFDvAp1xpbi4=55Gq0QbfbTH7TV=1MTko7nNdtt-5WQ@mail.gmail.com> <CALcybBBcCTh8+RVWp5UW+2-s9EdKxdoeGdcq6+yGrGJk1nzP0w@mail.gmail.com> <51625870.8000906@berkeley.edu> <CA+-NybWfR47yScyTBi7BRpJgj5SnCxWY1rDV5KC8PuE+JEV90A@mail.gmail.com> <517AB75F.7020904@berkeley.edu>
From: James M Snell <jasnell@gmail.com>
Date: Fri, 26 Apr 2013 10:27:58 -0700
Message-ID: <CABP7Rbc8A0JKFT+zm_z5DAcsjQ-Ncmg3tr2WM-3iWoB1WGia7w@mail.gmail.com>
To: Erik Wilde <dret@berkeley.edu>
Content-Type: text/plain; charset=UTF-8
Cc: Joe Gregorio <joe@bitworking.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Question about URI template and expansion of an empty list
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2013 17:28:19 -0000

Nope, it works. I've maintained that the spec is fine like it is ;-)
Honestly, I never really saw where the confusion was.

On Fri, Apr 26, 2013 at 10:20 AM, Erik Wilde <dret@berkeley.edu> wrote:
> hello joe.
>
> thanks for the response!
>
>
> On 2013-04-17 07:03 , Joe Gregorio wrote:
>>
>> On Mon, Apr 8, 2013 at 1:41 AM, Erik Wilde <dret@berkeley.edu> wrote:
>>>
>>>
>>> https://github.com/dret/uritemplate-test/blob/master/spec-examples-by-section.json
>>> (line 234) says it's "X", but i am really interested in the "why"
>>> explanation as well. http://tools.ietf.org/html/rfc6570#section-3.2.5
>>> says
>>> that
>>
>> The answer is in the text you quote:
>> "for each defined variable in the variable-list, append '.' to the
>> result string and then perform variable expansion"
>> The set of variables in the variable list is the empty set, so no '.'
>> is appended.
>> I agree that if this is confusing an addendum is in order.
>
>
> ... and just when i wanted to submit an erratum and searched for the best
> place where to put clarifying text, i ran into the last paragraph of
> http://tools.ietf.org/html/rfc6570#section-2.3 :
>
> "A variable defined as a list value is considered undefined if the list
> contains zero members. A variable defined as an associative array of (name,
> value) pairs is considered undefined if the array contains zero members or
> if all member names in the array are associated with undefined values."
>
> while still being a bit of an unintuitive definition for me, it seems as if
> this particular paragraph was never mentioned in previous discussions, and
> indeed clarifies that an empty array should be considered as an "undefined
> variable". for now, i'll assume that this settles things and will not file
> an erratum. but if people think (fracis? james?) that this still isn't good
> enough, then please speak up.
>
> thanks and cheers,
>
>
> dret.
>
> --
> erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
>            | UC Berkeley  -  School of Information (ISchool) |
>            | http://dret.net/netdret http://twitter.com/dret |
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From dret@berkeley.edu  Fri Apr 26 16:04:07 2013
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3DF21F86EB for <apps-discuss@ietfa.amsl.com>; Fri, 26 Apr 2013 16:04:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OJ0ZqjsLJUy for <apps-discuss@ietfa.amsl.com>; Fri, 26 Apr 2013 16:04:06 -0700 (PDT)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id CF17121F85BB for <apps-discuss@ietf.org>; Fri, 26 Apr 2013 16:04:06 -0700 (PDT)
Received: from c-71-226-42-42.hsd1.az.comcast.net ([71.226.42.42] helo=dretair.local) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1UVrgT-0000yn-5E; Fri, 26 Apr 2013 16:04:06 -0700
Message-ID: <517B07E3.7000402@berkeley.edu>
Date: Fri, 26 Apr 2013 16:04:03 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Atom-Syntax <atom-syntax@imc.org>,  "apps-discuss@ietf.org application-layer protocols" <apps-discuss@ietf.org>
References: <20130426221934.8104.31109.idtracker@ietfa.amsl.com>
In-Reply-To: <20130426221934.8104.31109.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20130426221934.8104.31109.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] Fwd: New Version Notification for draft-wilde-atom-profile-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2013 23:04:07 -0000

A new version of I-D, draft-wilde-atom-profile-01.txt
has been successfully submitted by Erik Wilde and posted to the
IETF repository.

Filename:	 draft-wilde-atom-profile
Revision:	 01
Title:		 Profile Support for the Atom Syndication Format
Creation date:	 2013-04-26
Group:		 Individual Submission
Number of pages: 8
URL: 
http://www.ietf.org/internet-drafts/draft-wilde-atom-profile-01.txt
Status:          http://datatracker.ietf.org/doc/draft-wilde-atom-profile
Htmlized:        http://tools.ietf.org/html/draft-wilde-atom-profile-01
Diff: 
http://www.ietf.org/rfcdiff?url2=draft-wilde-atom-profile-01

Abstract:
    The Atom syndication format is a generic XML format for representing
    collections.  Profiles are one way how Atom feeds can indicate that
    they support specific extensions.  To make this support visible on
    the media type level, this specification re-registers the Atom media
    type, and adds a "profile" media type parameter.  This allows
    profiles to become visible at the media type level, so that servers
    as well as clients can indicate support for specific Atom profiles in
    conversations, for example when communicating via HTTP

From mscurtescu@google.com  Fri Apr 26 10:50:26 2013
Return-Path: <mscurtescu@google.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C1B21F99CA for <apps-discuss@ietfa.amsl.com>; Fri, 26 Apr 2013 10:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.593
X-Spam-Level: 
X-Spam-Status: No, score=-101.593 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2GVQyQq8rlr for <apps-discuss@ietfa.amsl.com>; Fri, 26 Apr 2013 10:50:24 -0700 (PDT)
Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 1382D21F9993 for <apps-discuss@ietf.org>; Fri, 26 Apr 2013 10:50:23 -0700 (PDT)
Received: by mail-vc0-f181.google.com with SMTP id hr11so2676287vcb.40 for <apps-discuss@ietf.org>; Fri, 26 Apr 2013 10:50:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=97cxkLR08McFgdosdsQ0ZHack0S+YFXx6Yy532U2To4=; b=Uhaz4nc3/L0XZntIepTHaNTssdUoLwpTSrTUxXMsY4Bfr2G4vrImg+nx7l/owvNd8u orNzD2LRKrd8uHdjSSp3vT+7OEWyhVntZ4y35dz1375VE1pBTn5fiuNA0YCgC7p2fN8W XB2MQzpXV0ioi1QVxuJCtw3w7w35VGjYIXKnU4cL/91WYf4Sa9ftqM0PQQsOXBHKAuDZ NCdGi8o+UpwBuTro2rrX/Wo/3a/p0gC6fMS0Qn/jIXa2JV2sct7CgSqvQQZCXvwObX/9 dA37IJQhkQVO8BUcIWhzSAkanryogPUD1bfXl2zt68hAg9Pp3wKxKD9ePPols53l2jpa NE+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=97cxkLR08McFgdosdsQ0ZHack0S+YFXx6Yy532U2To4=; b=feRcJcAlovbCpzJKU3vIF9tUXBXTr2W7Ew0J+E8HI/Jc9uHrElkNYIvaIhNwhd3TR2 hY7eaoV+OPmDKdT+dtFAmIBlNmZW7shhGq7HOBtiYMB1Tlpr+lcVc+mKuxZUYBvY+LDB 0o/na7Slif2q04lPiw92kxY/PC4eZHxglbcqekXEt+HxHC3t/L2UYzZi/0lhaWlU6y40 Hy+3aW/JMkzUdy3Ba0PbifOyC7sb/1fms3uRhQEZY4mND4OMLZOKFtI4N+P9/5XpVIT7 aX2NlnlWl3Un6cwjFaoHMFCGj8CBoPjhZu57ZDXNRkCakSRg98/xlPzQ5CTYsWOuQvLs sETg==
X-Received: by 10.52.157.194 with SMTP id wo2mr25020889vdb.30.1366998623390; Fri, 26 Apr 2013 10:50:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.154.206 with HTTP; Fri, 26 Apr 2013 10:50:03 -0700 (PDT)
In-Reply-To: <EAA8FD66-1F5F-4A36-A1A2-677BD34AC102@lodderstedt.net>
References: <68113CC9-033D-4E61-8190-2D3B9CE92CB0@mnot.net> <77D6DF69-0715-485F-AF6E-D34D5990F5B1@lodderstedt.net> <2760360C-76A7-40D3-9B57-157FCA9A7A8A@gmail.com> <EAA8FD66-1F5F-4A36-A1A2-677BD34AC102@lodderstedt.net>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Fri, 26 Apr 2013 10:50:03 -0700
Message-ID: <CAGdjJpLxKBtUoCcmbwDyU0duvbEYqGg8ihyf8DGN0PfbM_SUhg@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: multipart/alternative; boundary=089e016338c05b4f4d04db472b98
X-Gm-Message-State: ALoCoQmhF98GGqTlHoprf7Mz+BgLvRDO1nRl5FWn+PaZO78IjJS6u69lX3hzzKjyJEo3D0W4g52KsMsyXXwHDcAHbgZWNrZaSsOyA5YeMwvjdrEd70ObZKk2mb0uHbOMP+dn+InhD6DE18TzNJe7brdcJFV9yQurPh5vAOZLPkWxv4JL5Tjx9z9kE7aK9BVbyE/L2Z6WBu4r
X-Mailman-Approved-At: Sat, 27 Apr 2013 08:04:05 -0700
Cc: "draft-ietf-oauth-revocation.all@tools.ietf.org" <draft-ietf-oauth-revocation.all@tools.ietf.org>, Mark Nottingham <mnot@mnot.net>, IESG IESG <iesg@ietf.org>, "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Apps Area Review of draft-ietf-oauth-revocation-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2013 17:50:26 -0000

--089e016338c05b4f4d04db472b98
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 24, 2013 at 11:06 AM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> Hi Dick,
>
>
>
> Am 24.04.2013 um 19:34 schrieb Dick Hardt <dick.hardt@gmail.com>:
>
> Hi Torsten
>
> Unlike RFC 6749 where the user is starting from documentation, OAuth
> Revocation is an extension to an existing protocol.
>
>
> I don't get your point. Revocation is an extension to the OAuth framework.
> Why is the situation any different from any other endpoint?
>
> FWIW: I agree with Mark that having the revocation URL be returned as an
> additional parameter in the access token request similar to how the refresh
> token is preferable.
>
>
I think discovery should be solved in general for OAuth 2, an ad hoc
solution for revocation does sound right. For example, when authorization
codes are returned the URL of the token endpoint is not returned. Returning
discovery information with every single response is an overkill IMO, but
the whole discussion should happen somewhere else.

Maybe tokens should have been URLs, but again, it is too late for that
discussion and this spec cannot enforce or require that.


Use of the  DELETE verb on the revocation URL is a great suggestion and
> makes the protocol more web like and straight forward.
>
>
> We discussed this and other alternative options a long time ago and the WG
> decided to go for the design described in the draft.
>
> Regards,
> Torsten.
>
> -- Dick
>
> On Apr 24, 2013, at 10:16 AM, Torsten Lodderstedt <torsten@lodderstedt.net>
> wrote:
>
> Hi Mark,
>
> thanks for your feedback. I added my comments inline.
>
> Am 24.04.2013 um 02:07 schrieb Mark Nottingham <mnot@mnot.net>:
>
> I have been selected as the Applications Area Review Team reviewer for
> this draft (for background on apps-review, please see
> http://www.apps.ietf.org/content/applications-area-review-team).
>
> Please resolve these comments along with any other Last Call comments you
> may receive. Please wait for direction from your document shepherd or AD
> before posting a new version of the draft.
>
> Document: draft-ietf-oauth-revocation-07
> Title: Token Revocation
> Reviewer: Mark Nottingham
> Review Date: 24 April 2013
> IETF Last Call Date: 30 April 2013
> IESG Telechat Date: unknown
>
> Summary: This draft is has issues that should be fixed before publication.
>
> Major Issues:
>
> 1) Section 2 states that the means of discovering the revocation endpoint
> is out of scope of this specification, and that it can be achieved by
> consulting documentation.
>
> This is a poor design choice, at odds with the Web architecture, and fails
> to provide interoperability. A discovery mechanism should be specified.
>
>
>
> I'm surprised about your assessment. My draft is just an extension to RFC6749,
> which leaves discovery out of scope as well.
> In my opinion, how the clients gets to know the revocation URL is a domain
> or application specific aspect. I expect OAuth profiles, such as OpenID
> Connect, to define this.
>
>
> One way to do it would be to allow the revocation URI to be indicated at
> an earlier part of the OAuth interchange.
>
> Another (potentially simpler) to do it would be to assign a URI to the
> token itself, and allow a properly authorised client to DELETE that URI;
> this removes the need to specify a body format.
>
>
> And there are much more possible options, e.g. using WebFinger. But is
> their THE discovery mechanism?
>
>
> Minor Issues:
>
> 2) The specification title is too broad; "Token Revocation" could apply to
> many IETF technologies. Suggest "OAuth Token Revocation".
>
>
> I will change the title.
>
> Regards,
> Torsten.
>
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>

--089e016338c05b4f4d04db472b98
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, Apr 24, 2013 at 11:06 AM, Torsten Lodderstedt <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:torsten@lodderstedt.net" target=3D"_bla=
nk">torsten@lodderstedt.net</a>&gt;</span> wrote:<br><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>Hi Dick,</div><div><b=
r></div><div><br></div><div><br>Am 24.04.2013 um 19:34 schrieb Dick Hardt &=
lt;<a href=3D"mailto:dick.hardt@gmail.com" target=3D"_blank">dick.hardt@gma=
il.com</a>&gt;:<br>

<br></div><div class=3D"im"><blockquote type=3D"cite"><div>Hi Torsten<div><=
br></div><div>Unlike RFC 6749 where the user is starting from documentation=
, OAuth Revocation is an extension to an existing protocol.</div><div><br>
</div>
</div></blockquote><div><br></div></div>I don&#39;t get your point. Revocat=
ion is an extension to the OAuth framework.<div>Why is the situation any di=
fferent from any other endpoint?</div><div><div class=3D"im"><div><br><bloc=
kquote type=3D"cite">

<div><div>FWIW: I agree with Mark that having the revocation URL be returne=
d as an additional parameter in the access token request similar to how the=
 refresh token is preferable.</div></div></blockquote></div></div></div>

</div></blockquote><div><br></div><div style>I think discovery should be so=
lved in general for OAuth 2, an ad hoc solution for revocation does sound r=
ight. For example, when authorization codes are returned the URL of the tok=
en endpoint is not returned. Returning discovery information with every sin=
gle response is an overkill IMO, but the whole discussion should happen som=
ewhere else.</div>

<div style><br></div><div style>Maybe tokens should have been URLs, but aga=
in, it is too late for that discussion and this spec cannot enforce or requ=
ire that.</div><div style><br></div><div style><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div dir=3D"auto"><div class=3D"im"><blockquote type=3D"cite"><div>Use of t=
he =A0DELETE verb on the revocation URL is a great suggestion and makes the=
 protocol more web like and straight forward.<br></div><div><br></div></blo=
ckquote>

<div><br></div></div>We discussed this and other alternative options a long=
 time ago and the WG decided to go for the design described in the draft.<d=
iv><br></div><div>Regards,</div><div>Torsten.<div><div class=3D"h5"><br>
<blockquote type=3D"cite">
<div><div><div>-- Dick<br><div><br><div><div>On Apr 24, 2013, at 10:16 AM, =
Torsten Lodderstedt &lt;<a href=3D"mailto:torsten@lodderstedt.net" target=
=3D"_blank">torsten@lodderstedt.net</a>&gt; wrote:</div><br><blockquote typ=
e=3D"cite">

<div dir=3D"auto"><span><div>Hi Mark,</div><div><br></div><div>thanks for y=
our feedback. I added my comments inline.</div><div><br>Am 24.04.2013 um 02=
:07 schrieb Mark Nottingham &lt;<a href=3D"mailto:mnot@mnot.net" target=3D"=
_blank">mnot@mnot.net</a>&gt;:<br>

<br></div><blockquote type=3D"cite"><span>I have been selected as the Appli=
cations Area Review Team reviewer for this draft (for background on apps-re=
view, please see <a href=3D"http://www.apps.ietf.org/content/applications-a=
rea-review-team" target=3D"_blank">http://www.apps.ietf.org/content/applica=
tions-area-review-team</a>).</span><br>

<span></span><br><span>Please resolve these comments along with any other L=
ast Call comments you may receive. Please wait for direction from your docu=
ment shepherd or AD before posting a new version of the draft.</span><br>

<span></span><br><span>Document: draft-ietf-oauth-revocation-07</span><br><=
span>Title: Token Revocation</span><br><span>Reviewer: Mark Nottingham</spa=
n><br><span>Review Date: 24 April 2013</span><br><span>IETF Last Call Date:=
 30 April 2013</span><br>

<span>IESG Telechat Date: unknown</span><br><span></span><br><span>Summary:=
 This draft is has issues that should be fixed before publication.</span><b=
r><span></span><br><span>Major Issues:</span><br><span></span><br><span>1) =
Section 2 states that the means of discovering the revocation endpoint is o=
ut of scope of this specification, and that it can be achieved by consultin=
g documentation. </span><br>

<span></span><br><span>This is a poor design choice, at odds with the Web a=
rchitecture, and fails to provide interoperability. A discovery mechanism s=
hould be specified.</span><br></blockquote><div><br></div><div><br></div>

<font face=3D".HelveticaNeueUI"><span style=3D"font-size:15px;line-height:1=
9px;white-space:nowrap">I&#39;m surprised about your assessment. My draft i=
s just an extension to </span></font></span><font face=3D".HelveticaNeueUI"=
><span style=3D"font-size:15px;line-height:19px;white-space:nowrap">RFC6749=
, which leaves discovery out of scope as well.=A0</span></font><div>

<span style=3D"font-size:15px;line-height:19px;white-space:nowrap">In my op=
inion, how the clients gets to know the revocation URL is a domain or appli=
cation specific aspect. I=A0</span><span style=3D"font-size:15px;line-heigh=
t:19px;white-space:nowrap">expect OAuth profiles, such as OpenID Connect, t=
o define this.</span><div>

<div><span style=3D"font-size:15px;line-height:19px;white-space:nowrap"><br=
></span><blockquote type=3D"cite"><span></span><br><span>One way to do it w=
ould be to allow the revocation URI to be indicated at an earlier part of t=
he OAuth interchange. </span><br>

<span></span><br><span>Another (potentially simpler) to do it would be to a=
ssign a URI to the token itself, and allow a properly authorised client to =
DELETE that URI; this removes the need to specify a body format.</span><br>

</blockquote><div><br></div>And there are much more possible options, e.g. =
using WebFinger. But is their THE discovery mechanism?<br><blockquote type=
=3D"cite"><span></span><br><span>Minor Issues:</span><br><span></span><br>

<span>2) The specification title is too broad; &quot;Token Revocation&quot;=
 could apply to many IETF technologies. Suggest &quot;OAuth Token Revocatio=
n&quot;.</span><br><span></span><br></blockquote><div><br></div>I will chan=
ge the title.</div>

<div><br></div><div>Regards,</div><div>Torsten.</div><div><br><blockquote t=
ype=3D"cite"><span></span><br><span>--</span><br><span>Mark Nottingham =A0=
=A0<a href=3D"http://www.mnot.net/" target=3D"_blank">http://www.mnot.net/<=
/a></span><br>

<span></span><br><span></span><br><span></span><br></blockquote></div></div=
></div></div>_______________________________________________<br>apps-discus=
s mailing list<br><a href=3D"mailto:apps-discuss@ietf.org" target=3D"_blank=
">apps-discuss@ietf.org</a><br>

<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br></blockquot=
e></div><br></div></div></div></div></blockquote></div></div></div></div></=
blockquote>

</div><br></div></div>

--089e016338c05b4f4d04db472b98--

From sm@elandsys.com  Sat Apr 27 13:27:15 2013
Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6A621F98CD for <apps-discuss@ietfa.amsl.com>; Sat, 27 Apr 2013 13:27:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE1DatHFxM+V for <apps-discuss@ietfa.amsl.com>; Sat, 27 Apr 2013 13:27:15 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C98D21F98C8 for <apps-discuss@ietf.org>; Sat, 27 Apr 2013 13:27:15 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.152.148]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3RKQsVk000648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Apr 2013 13:27:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367094426; bh=wFWrFwxk1NkhURs4Qc4J5W3Jr5904IOspOGbbRdL8l0=; h=Date:To:From:Subject:Cc; b=ZReHJifAJhAdXr5KUALf2ndqkk6s48k7PeZ4pGhNsVyLxLPzGOpUZ3srVzcEi1hZB b+jGcSav1oPa3p8zoE8O9VpkqG69oiM+ak0EHAhV+vioAC8JJfMnjjkeKS0ssHYSdG GlhOmzIH6GwHUz6+9wUpjOqk1h+IU2M8KLo3W0a0=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367094426; i=@elandsys.com; bh=wFWrFwxk1NkhURs4Qc4J5W3Jr5904IOspOGbbRdL8l0=; h=Date:To:From:Subject:Cc; b=1J9CDKJ4DrNY0Zyo73uGv8gacicTsVS9gLUne3S1x98faq1DTvNJfSRsp1Cfchywo mH0v2T9CfhMMDBfqmnR/ErOpNGQKU8N+s+4DtsUrxCEP3Qbcr990W46ZGdnII8pQ+j q7YXcHaDEuV74mkG+4mezpH1Sc1du+j0QqHn90DQ=
Message-Id: <6.2.5.6.2.20130427132058.0beb2648@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 27 Apr 2013 13:26:35 -0700
To: "Murray S. Kucherawy" <superuser@gmail.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] Moderation of johnsonhammond2@hushmail.com
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Apr 2013 20:27:16 -0000

Hi Murray, Sal,

I enabled moderation for johnsonhammond2@hushmail.com as there has 
been off-topic messages from that email address to several IETF mailing lists.

Regards,
S. Moonesamy (as list moderator)


From superuser@gmail.com  Sat Apr 27 14:40:51 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BCC21F9903 for <apps-discuss@ietfa.amsl.com>; Sat, 27 Apr 2013 14:40:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.321
X-Spam-Level: 
X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=0.278,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhP57sPbBVfd for <apps-discuss@ietfa.amsl.com>; Sat, 27 Apr 2013 14:40:51 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id E978221F9901 for <apps-discuss@ietf.org>; Sat, 27 Apr 2013 14:40:50 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id c10so1679170wiw.14 for <apps-discuss@ietf.org>; Sat, 27 Apr 2013 14:40:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=y31Y3Ehn3kreAS9bw6VLhI1Q+9ujnQ4I1d2Z4XutOLA=; b=Do3cAXYUo0xbbvysPUANIYtECmmMYL6zA4k8yVQRE6YCyUu2HK4rfTaOsjqKpVGiom 1RJw3FYy5HKBoWTNHopyHtB222pfPktBMMSdSaOGVhijQKyw4QgZuzdp4MECBCOV1IUu Dgd8pzGib8DnkCLVXPN+ulcx1mJ/AqWKEj89gYR2z6os7DYE6atqI2o6bpNhAZcm+zYg 831B9+1sffryotd5TGzxSaLKAy8MkhKUfTZCG5jHMLHEwOrZIN9hcC3zxN1+A7Y02yuO zweC5xPy5NFydzI6pbUF+TzZZ/ddeJ+oY0RLim5tnv1R+i7qumDGX7Tve/YLlIC3gflB uXOg==
MIME-Version: 1.0
X-Received: by 10.194.222.100 with SMTP id ql4mr44892752wjc.59.1367098849642;  Sat, 27 Apr 2013 14:40:49 -0700 (PDT)
Received: by 10.180.14.34 with HTTP; Sat, 27 Apr 2013 14:40:49 -0700 (PDT)
In-Reply-To: <6.2.5.6.2.20130427132058.0beb2648@elandnews.com>
References: <6.2.5.6.2.20130427132058.0beb2648@elandnews.com>
Date: Sat, 27 Apr 2013 14:40:49 -0700
Message-ID: <CAL0qLwYHw=2HXE=Cc_9u9EyCGzh+goXweXHvNT_Ugyp27_G51A@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: S Moonesamy <sm+ietf@elandsys.com>
Content-Type: multipart/alternative; boundary=001a11c1b9424e4f6f04db5e8135
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Moderation of johnsonhammond2@hushmail.com
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Apr 2013 21:40:51 -0000

--001a11c1b9424e4f6f04db5e8135
Content-Type: text/plain; charset=ISO-8859-1

You got to it before I did.  I just did it on the other lists I maintain.


On Sat, Apr 27, 2013 at 1:26 PM, S Moonesamy <sm+ietf@elandsys.com> wrote:

> Hi Murray, Sal,
>
> I enabled moderation for johnsonhammond2@hushmail.com as there has been
> off-topic messages from that email address to several IETF mailing lists.
>
> Regards,
> S. Moonesamy (as list moderator)
>
>

--001a11c1b9424e4f6f04db5e8135
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You got to it before I did.=A0 I just did it on the other =
lists I maintain.<br></div><div class=3D"gmail_extra"><br><br><div class=3D=
"gmail_quote">On Sat, Apr 27, 2013 at 1:26 PM, S Moonesamy <span dir=3D"ltr=
">&lt;<a href=3D"mailto:sm+ietf@elandsys.com" target=3D"_blank">sm+ietf@ela=
ndsys.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi Murray, Sal,<br>
<br>
I enabled moderation for <a href=3D"mailto:johnsonhammond2@hushmail.com" ta=
rget=3D"_blank">johnsonhammond2@hushmail.com</a> as there has been off-topi=
c messages from that email address to several IETF mailing lists.<br>
<br>
Regards,<br>
S. Moonesamy (as list moderator)<br>
<br>
</blockquote></div><br></div>

--001a11c1b9424e4f6f04db5e8135--

From alexey.melnikov@isode.com  Sun Apr 28 14:33:33 2013
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E79621F8496; Sun, 28 Apr 2013 14:33:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyi275RBdwBI; Sun, 28 Apr 2013 14:33:32 -0700 (PDT)
Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3BC21F8314; Sun, 28 Apr 2013 14:33:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1367184808; d=isode.com; s=selector; i=@isode.com; bh=m9hWLLMyaT4hQn74HjSjpUc5FlPfM/mKuXIJgixu+Jw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Iwr+W8FLb8S0wDmTo8PgqA3lK3qvJlzN409uHaYbEDrnb70mfWk0a10GpQDrjv3jJkYJJN 7F6L7sfVRhTX2up2JsTBuVdKR8NqHvOdAzVBr6u8wgc2vG27+RCaVMQCVHOVoclKlimOxC gCaUBlpj6SGlxN9QxYF9QO9sWM/xIIA=;
Received: from [172.20.10.2] ((unknown) [212.183.128.229])  by waldorf.isode.com (submission channel) via TCP with ESMTPA  id <UX2VpAB4oTv1@waldorf.isode.com>; Sun, 28 Apr 2013 22:33:28 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <517D855C.40701@isode.com>
Date: Sun, 28 Apr 2013 21:23:56 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: Carsten Bormann <cabo@tzi.org>
References: <515D75FE.9070008@isode.com> <8C2FE55F-A4FF-4340-AEBF-C626B42BAA67@tzi.org>
In-Reply-To: <8C2FE55F-A4FF-4340-AEBF-C626B42BAA67@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "HE, XUAN -HCHBJ" <xhe@hitachi.cn>, core@ietf.org, draft-ietf-core-coap.all@tools.ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [apps-discuss] AppsDir review of draft-ietf-core-coap-14
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Apr 2013 21:33:33 -0000

On 04/04/2013 14:57, Carsten Bormann wrote:
> Hi Alexey,
Hi Carsten,
Sorry for the slow response, I was on holidays.
> thank you for this review.
>
>> In Section 3, version number field: have you thought about backward compatibility rules for future versions (if any) and version negotiation rules?
> I don't think we discussed this in the WG.
> I remember some hallway discussions the gist of which is approximately:
> We don't know yet why we would have a version transition, so it is hard to plan for it.
> Whatever we define now is likely to be wrong when we actually know what we need.
> Anything that is radical enough that we can't express it in an option is likely to change the message layout enough that it's not even clear what kind of error response to send back.
> Sending back something for anything also has its perils.
>
> So the version number is mainly in there as an insurance against unknown unknowns.
> One other purpose is to allow some multiplexing on the UDP port, including to avoid STUN codepoints.
Ok.

>> In Section 4.6: is a SHOULD requirement on IP MTU actually valid in this document? IMHO, you can't redefine what relevant RFCs say about that.
> There is no SHOULD on the MTU, but a SHOULD on what CoAP implementations should assume as an MTU.
> Most of our users think in terms of IPv6, so 1280 is a good assumption.
> For IPv4, 1280 is also a good base assumption.  There is an extensive implementation note on that, which qualifies this further.
>
> The upshot really is that you want to limit the payload size to 1KiB and, if you use all that, be reasonable about the option size; but for constrained applications, these numbers are already high.
I would rather you said just that in the document. But Ok, your 
explanation is sufficient.

>> In 5.10.8, last para: wouldn't it be more correct to say that preconditions must be tested after all other verification is performed? If not, what is the intent of the MAY?
> It gives the server some lenience.  It does allow checking for the preconditions first, and it does allow for checking them last.  (We always try to give the server some lenience to implement things in a way that is best for the specific constrained node.)  In other words, the client cannot rely on, say, a 4.05 indicating that the preconditions did match, or on a 4.12 indicating that the method would have been allowed, but the server is free to check things in either order.
I am not sure this is very interoperable, but maybe this doesn't matter.
>> In 6.4: why is URI's default encoding is UTF-8 and not ASCII? URIs can't contain 8bit data. Or did you mean IRIs? (Hopefully you haven't!)
> We certainly didn't mean IRIs.  Specifying UTF-8 and ASCII should be equivalent here.
> (Either way is likely to confuse a different part of the audience.)

I think you should just say ASCII.


From cabo@tzi.org  Sun Apr 28 15:02:48 2013
Return-Path: <cabo@tzi.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2777F21F9682; Sun, 28 Apr 2013 15:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.482
X-Spam-Level: 
X-Spam-Status: No, score=-105.482 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6gks7xusNDk; Sun, 28 Apr 2013 15:02:47 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5E29121F8233; Sun, 28 Apr 2013 15:02:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r3SM2bQx003649; Mon, 29 Apr 2013 00:02:37 +0200 (CEST)
Received: from [192.168.217.105] (p54894882.dip0.t-ipconnect.de [84.137.72.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 84ECF3173; Mon, 29 Apr 2013 00:02:36 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <517D855C.40701@isode.com>
Date: Mon, 29 Apr 2013 00:02:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <FE456076-8517-46A9-972A-834E8DCD58BD@tzi.org>
References: <515D75FE.9070008@isode.com> <8C2FE55F-A4FF-4340-AEBF-C626B42BAA67@tzi.org> <517D855C.40701@isode.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: Apple Mail (2.1503)
Cc: "HE, XUAN -HCHBJ" <xhe@hitachi.cn>, core@ietf.org, draft-ietf-core-coap.all@tools.ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [apps-discuss] AppsDir review of draft-ietf-core-coap-14
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Apr 2013 22:02:48 -0000

Hi Alexey,

> Sorry for the slow response, I was on holidays.

I'll start my vacation (in Russia, by the way) on Friday...
Hope to have a -16 by then.

>>> In 6.4: why is URI's default encoding is UTF-8 and not ASCII? URIs =
can't contain 8bit data. Or did you mean IRIs? (Hopefully you haven't!)
>> We certainly didn't mean IRIs.  Specifying UTF-8 and ASCII should be =
equivalent here.
>> (Either way is likely to confuse a different part of the audience.)
>=20
> I think you should just say ASCII.

This is what the current draft -16pre says:

   2.  Resolve the |url| string using the process of reference
       resolution defined by [RFC3986].  At this stage the URL is in
       ASCII encoding [RFC0020], even though the decoded components will
       be interpreted in UTF-8 [RFC3629] after step 5, 8 and 9.

I think this should be much clearer.

Gr=FC=DFe, Carsten


From sm@elandsys.com  Sun Apr 28 23:36:35 2013
Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE3921F97EE; Sun, 28 Apr 2013 23:36:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJhfTatUXZOE; Sun, 28 Apr 2013 23:36:34 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B531521F97E0; Sun, 28 Apr 2013 23:36:34 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.226.235.145]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3T6aK0S017956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Apr 2013 23:36:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367217393; bh=aWp8PCMxDoEoNtGBOpYa0lKKWEERyw0seaCmWBW/eHg=; h=Date:To:From:Subject:Cc; b=B1XzKBXRArZDFabUq4olawm5k2yUJuIElMxF12jQhw2zVYDUuh8utiSSxvj60fGdh FQlYhAXU2cjGR2g2LpUlUu6DUgGD2nH4uTbqz8v84KQlbYtJWYeSTFGKfy3gEBKbqW 6Q+4WEdg+5ac4Qaw5CuVe1eSGaqhEP/Ktb/7orNo=
Message-Id: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 28 Apr 2013 23:36:08 -0700
To: apps-discuss@ietf.org, draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org
From: Martin Thomson <martin.thomson@gmail.com> (by way of S Moonesamy <sm+ietf@elandsys.com>)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: iesg@ietf.org
Subject: [apps-discuss] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Apr 2013 06:36:35 -0000

(Apologies, I have this habit of not including directorates on
directorate reviews.  Correcting this oversight.)

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-netmod-rfc6021-bis-01
Title: Common YANG Data Types
Reviewer: Martin Thomson
Review Date: 2013-04-29

Summary: This draft is ready for publication as a Proposed Standard
RFC.  I have some minor issues and questions.

This is some of the most readable code that I have seen.

Major Issues: none

Minor Issues:

Section 4:
There is an RFC that describes a canonical textual representation of
IPv6 addresses.  You should use that: RFC 5952.

domain-name doesn't mention RFC 5890 at all (5891 is cited, but not
used in the text).  I assume that these are LDH-labels:
http://tools.ietf.org/html/rfc5890#section-2.3.1 and that this
document should say as much.

Questions:

Section 3:
phys-address: why is this optionally empty?  Maybe explain why in the
document - value absent?
hex-string: why is this required to include at least one octet? The
text does not mention this at all, I tend to find lots of uses for
empty octet strings, so this seems odd.
xpath1.0: are we expected to infer that "context" includes document
and where the namespace prefixes are bound?

Section 4:
ipv6-address: that is a very short IPv6 pattern.  Is it provably
correct?  I only ask because I've had occasion to build a real
pattern, and it's very long (the following is based on the "official"
ABNF definition):

          <xs:pattern value="[0-9A-Fa-f]{1,4}(:[0-9A-Fa-f]{1,4}){7}"/>
          <!-- Double colon start -->
          <xs:pattern value=":(:[0-9A-Fa-f]{1,4}){1,7}"/>
          <!-- Double colon middle -->
          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,6}
                 (:[0-9A-Fa-f]{1,4}){1}"/>
          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,5}
                 (:[0-9A-Fa-f]{1,4}){1,2}"/>
          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,4}
                 (:[0-9A-Fa-f]{1,4}){1,3}"/>
          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,3}
                 (:[0-9A-Fa-f]{1,4}){1,4}"/>
          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,2}
                 (:[0-9A-Fa-f]{1,4}){1,5}"/>
          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1}
                 (:[0-9A-Fa-f]{1,4}){1,6}"/>
          <!-- Double colon end -->
          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,7}:"/>
          <!-- IPv4-Compatible and IPv4-Mapped Addresses -->
          <xs:pattern value="((:(:0{1,4}){0,3}:[fF]{4})|(0{1,4}:
          (:0{1,4}){0,2}:[fF]{4})|((0{1,4}:){2}
          (:0{1,4})?:[fF]{4})|((0{1,4}:){3}:[fF]{4})
          |((0{1,4}:){4}[fF]{4})):(25[0-5]|2[0-4][0-9]|
          [0-1]?[0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]
          ?[0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]?
          [0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]?
          [0-9]?[0-9])"/>

Nits: I didn't find anything at all, and the items that idnits found
were bogus, so it looks good.
_______________________________________________
appsdir mailing list
appsdir@ietf.org
https://www.ietf.org/mailman/listinfo/appsdir


From alexey.melnikov@isode.com  Mon Apr 29 02:31:07 2013
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9D421F9A33; Mon, 29 Apr 2013 02:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.203
X-Spam-Level: 
X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DTRzR-VwRlr; Mon, 29 Apr 2013 02:31:06 -0700 (PDT)
Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 807C621F9A31; Mon, 29 Apr 2013 02:31:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1367227863; d=isode.com; s=selector; i=@isode.com; bh=fJU+7I+0o8cfbe+c74zZ2jtCqFxcy3chDpxmGbC0kc0=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=GITAbdv6eCqRUpHhgP1IUfc+z2bN/yecHx2aiSQwq7VZTKlVkt00JTV0wsV/Lw3GfO7VeF 62iVma5plBkz/5KHMsCfoklFdqkEnRvAMDZevDqGCeyA7B3dHiWmZBeqxU/2cIW2DlphMo fWdIE39kCRPQ9goq9GflVFbU7enfbhY=;
Received: from [172.17.128.24] (richard.isode.com [62.3.217.249])  by waldorf.isode.com (submission channel) via TCP with ESMTPSA  id <UX491QB4oT1a@waldorf.isode.com>; Mon, 29 Apr 2013 10:31:03 +0100
References: <515D75FE.9070008@isode.com> <8C2FE55F-A4FF-4340-AEBF-C626B42BAA67@tzi.org> <517D855C.40701@isode.com> <FE456076-8517-46A9-972A-834E8DCD58BD@tzi.org>
In-Reply-To: <FE456076-8517-46A9-972A-834E8DCD58BD@tzi.org>
Message-Id: <5387C390-3033-4455-B8C8-8172897F2B0F@isode.com>
X-Mailer: iPad Mail (9B206)
From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Mon, 29 Apr 2013 10:33:56 +0100
To: Carsten Bormann <cabo@tzi.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Cc: "HE, XUAN -HCHBJ" <xhe@hitachi.cn>, "core@ietf.org" <core@ietf.org>, "draft-ietf-core-coap.all@tools.ietf.org" <draft-ietf-core-coap.all@tools.ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [apps-discuss] AppsDir review of draft-ietf-core-coap-14
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Apr 2013 09:31:07 -0000

On 28 Apr 2013, at 23:02, Carsten Bormann <cabo@tzi.org> wrote:

> Hi Alexey,
>=20
>> Sorry for the slow response, I was on holidays.
>=20
> I'll start my vacation (in Russia, by the way) on Friday...
> Hope to have a -16 by then.
>=20
>>>> In 6.4: why is URI's default encoding is UTF-8 and not ASCII? URIs can'=
t contain 8bit data. Or did you mean IRIs? (Hopefully you haven't!)
>>> We certainly didn't mean IRIs.  Specifying UTF-8 and ASCII should be equ=
ivalent here.
>>> (Either way is likely to confuse a different part of the audience.)
>>=20
>> I think you should just say ASCII.
>=20
> This is what the current draft -16pre says:
>=20
>   2.  Resolve the |url| string using the process of reference
>       resolution defined by [RFC3986].  At this stage the URL is in
>       ASCII encoding [RFC0020], even though the decoded components will
>       be interpreted in UTF-8 [RFC3629] after step 5, 8 and 9.
>=20
> I think this should be much clearer.

Yes, this works. Thanks!


From cyrus@daboo.name  Mon Apr 29 06:50:26 2013
Return-Path: <cyrus@daboo.name>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800FD21F9DB1; Mon, 29 Apr 2013 06:50:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.203
X-Spam-Level: 
X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwR5+EgYjx8h; Mon, 29 Apr 2013 06:50:25 -0700 (PDT)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF8121F9DAE; Mon, 29 Apr 2013 06:50:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 3F7B1425132D; Mon, 29 Apr 2013 09:50:17 -0400 (EDT)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nH1O-SW8EcRj; Mon, 29 Apr 2013 09:50:16 -0400 (EDT)
Received: from [17.45.162.251] (unknown [17.45.162.251]) by daboo.name (Postfix) with ESMTPSA id 1638A4251323; Mon, 29 Apr 2013 09:50:14 -0400 (EDT)
Date: Mon, 29 Apr 2013 09:50:15 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: apps-discuss@ietf.org, draft-ietf-spfbis-4408bis.all@tools.ietf.org
Message-ID: <9E5D5870D2E1345B7ABA6971@cyrus.local>
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; size=2701
Cc: iesg@ietf.org
Subject: [apps-discuss] APPSDIR review of draft-ietf-spfbis-4408bis-14.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Apr 2013 13:50:26 -0000

Hi,

I have been selected as the Applications Area Directorate reviewer for this =

draft (for background on appsdir, please see=20
=E2=80=8Bhttp://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirec=
torate=20
).

Please resolve these comments along with any other Last Call comments you=20
may receive. Please wait for direction from your document shepherd or AD=20
before posting a new version of the draft.

Document: draft-ietf-spfbis-4408bis-14.txt
Title: Sender Policy Framework (SPF) for Authorizing Use of Domains in=20
Email, Version 1
Reviewer: Cyrus Daboo
Review Date: 2013-04-29

Summary: This draft is almost ready for publication as an RFC, subject to=20
some minor issues that should be resolved.

Overview: This document is an update to RFC4408 that seeks to upgrade the=20
specification from experimental status, clarifying a number of issues in=20
the original specification, providing in depth detail of actual deployment=20
experience, and documenting various extensions now in common use. The new=20
draft achieves these aims and provides a good reference for implementors.

Major Issues: None

Minor Issues:

	Section 4.6.1 ABNF terms "A / MX / PTR / IP4 / IP6" are upper case but=20
terminal terms are lower case in Section 5 (but uppercase in Appendix A).=20
Looks like these need fixing in Section 5.

	Section 6.2 Paragraph 6 There is a reference to Section 2.6.4 but that=20
section does not contain anything relevant. Either remove the reference or=20
point to a relevant section.

	Section 7.1 Paragraph 2 States "subject to LDH rule" - that needs a=20
reference to RFC3696 Section 2 (reference was in RFC 4408).

Section 11.3 Why no mention of DNSSEC as a way to alleviate this issue? Has =

anyone been using DNSSEC with SPF? If not, why not?

Nits:

	Section 2.4 (argument list) and Section 4.1 appear to duplicate similar=20
information - consider removing the list of args in Section 2.4 and add a=20
reference to $4.1.
	
	Section 2.5 Paragraph 2 First part of sentence hard to read - break it up=20
with commas.
	
	Section 2.6 and Section 8 appear to duplicate a lot of similar=20
information. Please consider trimming down Section 2.6 and have it refer to =

Section 8 for full details.
	
	Section 3.5 Paragraph 1 Has the word "discouraged". Shouldn't this use a=20
2119 term, e.g.: "NOT RECOMMENDED"?
	
	Section 6.1 Paragraph 1 Remove second sentence - pretty much the same as=20
the first one.
	
	Section 6.2 Paragraph 4 Put exp in double-quotes.
	
	Section 10 Paragraph 1 SHOULD - in this context it is not really=20
appropriate to use a 2119 term. Please rephrase.
	
	Various places: permerror is sometimes used without double-quotes around=20
it - I think all uses should have double-quotes.


--=20
Cyrus Daboo


From tedyoung@gmail.com  Mon Apr 29 15:36:09 2013
Return-Path: <tedyoung@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DD821F9A96 for <apps-discuss@ietfa.amsl.com>; Mon, 29 Apr 2013 15:36:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhqCZNqQMyq0 for <apps-discuss@ietfa.amsl.com>; Mon, 29 Apr 2013 15:36:03 -0700 (PDT)
Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 752CC21F9A81 for <apps-discuss@ietf.org>; Mon, 29 Apr 2013 15:36:03 -0700 (PDT)
Received: by mail-lb0-f176.google.com with SMTP id p10so1011362lbv.7 for <apps-discuss@ietf.org>; Mon, 29 Apr 2013 15:36:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=aYZaDiJaIGaiFEeLZsvvw+/IoHllJQ28D5INjYtq8aY=; b=hLL2kVAwPex2yXpn7XWecgsDmu2+S3GepCO8SJpCoXFs8HdMlSwf3ObwJlgMgM7w91 UiW7Pyip3kHAJIAhiKHL2HfqoHJrkIHX9OO9Xgr9lupP/4ob9Ra+frGkyLoIEymr9anb +4hLR2bi+umroxvBUfIWq/ghxz9eh5NjpBlHpTpIjb3fR0kGJVGnf7EjWC9MbDbjf7JD 5CN0tlJnY2ei0fp0OPgSKgfVXIuLc1avUGBpOTrxZBaUaJc78zTpAar7n8RyZ9B7JmBj 6bD789xdp7t/rAdL7YmENteOq4mD2/el0/Y2OVhjXTO1bBR0EpNTi+9w6NfKv9g8MHvy lJlQ==
MIME-Version: 1.0
X-Received: by 10.152.21.106 with SMTP id u10mr4177835lae.11.1367274962200; Mon, 29 Apr 2013 15:36:02 -0700 (PDT)
Received: by 10.114.175.202 with HTTP; Mon, 29 Apr 2013 15:36:02 -0700 (PDT)
Date: Mon, 29 Apr 2013 15:36:02 -0700
Message-ID: <CAOp_J8nfdqTxXJA8siTyhjTaxuhGYs9wWTMuFu2hCe6mccTQig@mail.gmail.com>
From: "Ted M. Young [@jitterted]" <tedyoung@gmail.com>
To: apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=089e013d17006eae4d04db878234
Cc: mnot@mnot.net
Subject: [apps-discuss] draft-nottingham-json-home-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Apr 2013 22:36:09 -0000

--089e013d17006eae4d04db878234
Content-Type: text/plain; charset=ISO-8859-1

I see that this draft has expired. Is there an -03 coming up (I see it in
your github)? We're implementing it in a RESTful experiment and it'd be
nice if it were still considered active (not that expiration would stop us
for this experiment).

Also, I've been trying to find if there's been discussion around the name
of the media type, i.e., /json-home vs. /home+json. I don't want to beat a
dead horse if this has already been discussed and the reasons explained.

Thanks,
;ted

--
http://about.me/tedmyoung

--089e013d17006eae4d04db878234
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I see that this draft has expired. Is there an -03 coming =
up (I see it in your github)? We&#39;re implementing it in a RESTful experi=
ment and it&#39;d be nice if it were still considered active (not that expi=
ration would stop us for this experiment).<div>
<br></div><div>Also, I&#39;ve been trying to find if there&#39;s been discu=
ssion around the name of the media type, i.e., /json-home vs. /home+json. I=
 don&#39;t want to beat a dead horse if this has already been discussed and=
 the reasons explained.</div>
<div><br></div><div style>Thanks,</div><div style>;ted</div><div style><br>=
</div><div style>--</div><div style><a href=3D"http://about.me/tedmyoung">h=
ttp://about.me/tedmyoung</a></div><div style><br></div></div>

--089e013d17006eae4d04db878234--

From mnot@mnot.net  Mon Apr 29 18:00:06 2013
Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E32621F9B8F for <apps-discuss@ietfa.amsl.com>; Mon, 29 Apr 2013 18:00:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.093
X-Spam-Level: 
X-Spam-Status: No, score=-106.093 tagged_above=-999 required=5 tests=[AWL=-3.494, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pW6zOiQ-ZRSq for <apps-discuss@ietfa.amsl.com>; Mon, 29 Apr 2013 18:00:00 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 996E921F9B8C for <apps-discuss@ietf.org>; Mon, 29 Apr 2013 17:59:59 -0700 (PDT)
Received: from mnot-mini.mnot.net (unknown [118.209.190.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AB66B509B5; Mon, 29 Apr 2013 20:59:57 -0400 (EDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAOp_J8nfdqTxXJA8siTyhjTaxuhGYs9wWTMuFu2hCe6mccTQig@mail.gmail.com>
Date: Tue, 30 Apr 2013 10:59:53 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <F922078B-323B-4956-A932-E620CC5120AB@mnot.net>
References: <CAOp_J8nfdqTxXJA8siTyhjTaxuhGYs9wWTMuFu2hCe6mccTQig@mail.gmail.com>
To: Ted M. Young [@jitterted] <tedyoung@gmail.com>
X-Mailer: Apple Mail (2.1503)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-nottingham-json-home-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2013 01:00:06 -0000

On 30/04/2013, at 8:36 AM, Ted M. Young [@jitterted] =
<tedyoung@gmail.com> wrote:

> I see that this draft has expired. Is there an -03 coming up (I see it =
in your github)? We're implementing it in a RESTful experiment and it'd =
be nice if it were still considered active (not that expiration would =
stop us for this experiment).

Oh, it's still active, just a slow burner. Once we get HTTP/1.1 to bed, =
i'll be spending some more time on it.


> Also, I've been trying to find if there's been discussion around the =
name of the media type, i.e., /json-home vs. /home+json. I don't want to =
beat a dead horse if this has already been discussed and the reasons =
explained.

I think it's likely the media type will change at some point, as we'll =
probably be making breaking changes before it's done.

Cheers,


--
Mark Nottingham   http://www.mnot.net/




From tbray@textuality.com  Mon Apr 29 21:44:20 2013
Return-Path: <tbray@textuality.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114EC21F9AF4 for <apps-discuss@ietfa.amsl.com>; Mon, 29 Apr 2013 21:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.357
X-Spam-Level: *
X-Spam-Status: No, score=1.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13Kmg9+2jZGX for <apps-discuss@ietfa.amsl.com>; Mon, 29 Apr 2013 21:44:14 -0700 (PDT)
Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B06D221F9AE1 for <apps-discuss@ietf.org>; Mon, 29 Apr 2013 21:44:12 -0700 (PDT)
Received: by mail-ve0-f171.google.com with SMTP id oy12so76502veb.16 for <apps-discuss@ietf.org>; Mon, 29 Apr 2013 21:44:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=XUzOC26uJ0W1nDVGQEXiHZGTH68hGMPIsvFm2cA+WWc=; b=RT+i3nbsf2F2cZIi7elp+DFfmdcSr9k/UaEbKECJ39Pwo7wD+5WxEj11JVldF/c1z6 DLqaQIxqKH5Web7vzNPoHKGbDDZyjapKuwvCoN1tSvKGUCIg1XJf+2r8to8KiP9EvPfb bxh3E7ss9yPaAp3uWoyAYGpvtRfEnDN7CYJyp+itAViUw/2dMEo2+cQs832A84UxKCT7 1V0ZvheiQirPWS5eb/fBGZMMjAlrrqKXnk+FKys5dExYAoflQeuaxwPtN0CRPjTUiNHW R3+HtKzbpPX924v86bwtXc1oV/vmX143nFqX5rNGDeoMWRDEV7hSxzarq4Qoh9DpH3aV C2Jg==
MIME-Version: 1.0
X-Received: by 10.220.46.197 with SMTP id k5mr34673891vcf.40.1367297049364; Mon, 29 Apr 2013 21:44:09 -0700 (PDT)
Received: by 10.220.26.4 with HTTP; Mon, 29 Apr 2013 21:44:09 -0700 (PDT)
X-Originating-IP: [24.84.235.32]
Date: Mon, 29 Apr 2013 21:44:09 -0700
Message-ID: <CAHBU6iu_BzHCJxJnXCEU_fRuwkp=UghLwG7hsgaMKMFSq=yzag@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>,  draft-ietf-netmod-interfaces-cfg.all@tools.ietf.org, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c2ca40ee1d6d04db8ca655
X-Gm-Message-State: ALoCoQnMoxi4/vs5TWJyI62Lrzmay15u8vrOvS5PpTlGlyfaqymH2Ahr3lEByRC3rVIYqsrQv5uZ
Subject: [apps-discuss] Apps Area review of draft-ietf-netmod-interfaces-cfg-10
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2013 04:44:20 -0000

--001a11c2ca40ee1d6d04db8ca655
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I have been selected as the Applications Area Directorate reviewer for this
draft (for background on appsdir, please see=20
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate )=
.

Please resolve these comments along with any other Last Call comments you
may receive. Please wait for direction from your document shepherd or AD
before posting a new version of the draft.

Document: draft-ietf-netmod-interfaces-cfg-10
Title: A YANG Data Model for Interface Management
Reviewer: Tim Bray
Review Date: April 29

Summary: I see no objections to publication of this document as a
standards-track RFC

Note: I=92m not an expert in Netconf/YANG stuff, so really my only comments
are on style, coherence, and XML-sanity.  However, the presentation was
clear enough to be be comprehensible to the non-expert.

Major Issues: Don=92t see any

Minor Issues: Not obvious why all the examples are shuffled off into
Appendices, they=92re pretty essential to understanding the spec.

Nits:

3. =93The data model in the module "ietf-interfaces" has the following
structure...=94 - This is the first time the label =93ietf-interfaces=94 ha=
s
appeared. Is it a well-known name from another spec or are we defining it
here?  If the former, please reference. If the latter, maybe say something
like =93We define a module named "ietf-interfaces" whose data model has the
following structure...

3.1 =93The data model for interfaces presented in this document uses a flat
list of interfaces.=94 - does this mean that the model in section 3. should
have =93interface*=94 rather than just =93interface=94 as a child of =93int=
erfaces=94?
I have to say that this looks like a hash table indexed by name rather than
a =93flat list=94 in the conventional software sense.

--001a11c2ca40ee1d6d04db8ca655
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I have been selected as the Applications Area Directo=
rate reviewer for this draft (for background on appsdir, please see <a href=
=3D"http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectora=
te">http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectora=
te</a> ).<br>
<br>Please resolve these comments along with any other Last Call comments y=
ou may receive. Please wait for direction from your document shepherd or AD=
 before posting a new version of the draft.<br><br>Document: draft-ietf-net=
mod-interfaces-cfg-10<br>
Title: A YANG Data Model for Interface Management<br>Reviewer: Tim Bray<br>=
Review Date: April 29<br><br>Summary: I see no objections to publication of=
 this document as a standards-track RFC<br><br></div><div>Note: I=92m not a=
n expert in Netconf/YANG stuff, so really my only comments are on style, co=
herence, and XML-sanity.=A0 However, the presentation was clear enough to b=
e be comprehensible to the non-expert.<br>
</div><div><br>Major Issues: Don=92t see any<br><br>Minor Issues: Not obvio=
us why all the examples are shuffled off into Appendices, they=92re pretty =
essential to understanding the spec.<br><br>Nits:<br><br>3. =93The data mod=
el in the module &quot;ietf-interfaces&quot; has the following structure...=
=94 - This is the first time the label =93ietf-interfaces=94 has appeared. =
Is it a well-known name from another spec or are we defining it here?=A0 If=
 the former, please reference. If the latter, maybe say something like =93W=
e define a module named &quot;ietf-interfaces&quot; whose data model has th=
e following structure...<br>
<br>3.1 =93The data model for interfaces presented in this document uses a =
flat list of interfaces.=94 - does this mean that the model in section 3. s=
hould have =93interface*=94 rather than just =93interface=94 as a child of =
=93interfaces=94?=A0 I have to say that this looks like a hash table indexe=
d by name rather than a =93flat list=94 in the conventional software sense.=
<br>
<br></div><div><br></div><div><br><br></div></div>

--001a11c2ca40ee1d6d04db8ca655--

From dret@berkeley.edu  Mon Apr 29 21:56:18 2013
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7742D21F9A3E for <apps-discuss@ietfa.amsl.com>; Mon, 29 Apr 2013 21:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TYkFAEfrz7b for <apps-discuss@ietfa.amsl.com>; Mon, 29 Apr 2013 21:56:14 -0700 (PDT)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 26EAD21F99DB for <apps-discuss@ietf.org>; Mon, 29 Apr 2013 21:56:14 -0700 (PDT)
Received: from mobile-166-147-108-028.mycingular.net ([166.147.108.28] helo=dretair.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1UX2bq-0007V5-Fk; Mon, 29 Apr 2013 21:56:13 -0700
Message-ID: <517F4EE2.3090002@berkeley.edu>
Date: Mon, 29 Apr 2013 21:56:02 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "apps-discuss@ietf.org application-layer protocols" <apps-discuss@ietf.org>
References: <CAOp_J8nfdqTxXJA8siTyhjTaxuhGYs9wWTMuFu2hCe6mccTQig@mail.gmail.com>
In-Reply-To: <CAOp_J8nfdqTxXJA8siTyhjTaxuhGYs9wWTMuFu2hCe6mccTQig@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] draft-nottingham-json-home-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2013 04:56:18 -0000

hello ted.

On 2013-04-29 15:36 , Ted M. Young [@jitterted] wrote:
> I see that this draft has expired. Is there an -03 coming up (I see it
> in your github)? We're implementing it in a RESTful experiment and it'd
> be nice if it were still considered active (not that expiration would
> stop us for this experiment).

we're implementing -02 as well, and -03 hopefully isn't too far away.

> Also, I've been trying to find if there's been discussion around the
> name of the media type, i.e., /json-home vs. /home+json. I don't want to
> beat a dead horse if this has already been discussed and the reasons
> explained.

as mark said, it probably will end up following the new suffix 
convention. http://tools.ietf.org/html/draft-wilde-home-xml is the XML 
version of the same model (it is supposed to be in sync with the current 
JSON-based spec), and uses application/home+xml as media type.

cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

From ht@inf.ed.ac.uk  Tue Apr 30 07:32:29 2013
Return-Path: <ht@inf.ed.ac.uk>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D87A21F9AA5 for <apps-discuss@ietfa.amsl.com>; Tue, 30 Apr 2013 07:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9K1ykh-IkNS for <apps-discuss@ietfa.amsl.com>; Tue, 30 Apr 2013 07:32:24 -0700 (PDT)
Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC4821F98B9 for <apps-discuss@ietf.org>; Tue, 30 Apr 2013 07:32:22 -0700 (PDT)
Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r3UEW6X9008042 for <apps-discuss@ietf.org>; Tue, 30 Apr 2013 15:32:11 +0100 (BST)
Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r3UEW32N001122 for <apps-discuss@ietf.org>; Tue, 30 Apr 2013 15:32:04 +0100
Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r3UEW5nF030589 for <apps-discuss@ietf.org>; Tue, 30 Apr 2013 15:32:05 +0100
Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r3UEW4rs030584; Tue, 30 Apr 2013 15:32:04 +0100
X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: apps-discuss@ietf.org
From: ht@inf.ed.ac.uk (Henry S. Thompson)
User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b32 (linux)
Date: Tue, 30 Apr 2013 15:32:04 +0100
Message-ID: <f5b38u89jiz.fsf@calexico.inf.ed.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus
X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205
Subject: [apps-discuss] Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2013 14:32:29 -0000

We need to move forward on replacing 3023 (XML Media Types).  Before
we adopted draft-ietf-appsawg-xml-mediatypes, a number of folk
expressed interest in helping move this forward, including Julian,
Martin, Tony, Tim and SM, but no actual comments have been sent to
this list.

Further to a suggestion from Julian, perhaps if people would chip in
with their (un)favourite bugs/problems in/with 3023, I can try to
show how the draft [1] addresses them.

Comments directed straight at the draft w/o reference to 3023 are, of
course, also welcome.

ht

[1] http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-00
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

From mbj@tail-f.com  Tue Apr 30 01:38:46 2013
Return-Path: <mbj@tail-f.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE3A21F9ABF; Tue, 30 Apr 2013 01:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.189
X-Spam-Level: 
X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+tY+MsrRHra; Tue, 30 Apr 2013 01:38:41 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2E67C21F9AE2; Tue, 30 Apr 2013 01:38:40 -0700 (PDT)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 47F1C12008B7; Tue, 30 Apr 2013 10:38:39 +0200 (CEST)
Date: Tue, 30 Apr 2013 10:38:39 +0200 (CEST)
Message-Id: <20130430.103839.1231060720297181226.mbj@tail-f.com>
To: tbray@textuality.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CAHBU6iu_BzHCJxJnXCEU_fRuwkp=UghLwG7hsgaMKMFSq=yzag@mail.gmail.com>
References: <CAHBU6iu_BzHCJxJnXCEU_fRuwkp=UghLwG7hsgaMKMFSq=yzag@mail.gmail.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 30 Apr 2013 09:34:09 -0700
Cc: draft-ietf-netmod-interfaces-cfg.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Apps Area review of draft-ietf-netmod-interfaces-cfg-10
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2013 08:38:46 -0000

Hi,

Thank you for your review.  Comments inline.

Tim Bray <tbray@textuality.com> wrote:
> I have been selected as the Applications Area Directorate reviewer for this
> draft (for background on appsdir, please see 
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).
> 
> Please resolve these comments along with any other Last Call comments you
> may receive. Please wait for direction from your document shepherd or AD
> before posting a new version of the draft.
> 
> Document: draft-ietf-netmod-interfaces-cfg-10
> Title: A YANG Data Model for Interface Management
> Reviewer: Tim Bray
> Review Date: April 29
> 
> Summary: I see no objections to publication of this document as a
> standards-track RFC
> 
> Note: I$B!G(Bm not an expert in Netconf/YANG stuff, so really my only comments
> are on style, coherence, and XML-sanity.  However, the presentation was
> clear enough to be be comprehensible to the non-expert.
> 
> Major Issues: Don$B!G(Bt see any
> 
> Minor Issues: Not obvious why all the examples are shuffled off into
> Appendices, they$B!G(Bre pretty essential to understanding the spec.
> 
> Nits:
> 
> 3. $B!H(BThe data model in the module "ietf-interfaces" has the following
> structure...$B!I(B - This is the first time the label $B!H(Bietf-interfaces$B!I(B has
> appeared. Is it a well-known name from another spec or are we defining it
> here?  If the former, please reference. If the latter, maybe say something
> like $B!H(BWe define a module named "ietf-interfaces" whose data model has the
> following structure...

Ok, I will fix this.

> 3.1 $B!H(BThe data model for interfaces presented in this document uses a flat
> list of interfaces.$B!I(B - does this mean that the model in section 3. should
> have $B!H(Binterface*$B!I(B rather than just $B!H(Binterface$B!I(B as a child of $B!H(Binterfaces$B!I(B?

In this tree diagram, the notion "interface [name]" means that it is a
YANG list, with "name" as key.

> I have to say that this looks like a hash table indexed by name rather than
> a $B!H(Bflat list$B!I(B in the conventional software sense.

It refers to the YANG term "list".  When we say "flat list" it means
that it is YANG list where each interface has its own entry in the
"flat list".  Another design approach could have been to represent
subinterfaces in a nested list.



/martin

From j.schoenwaelder@jacobs-university.de  Tue Apr 30 01:32:13 2013
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7D521F9403; Tue, 30 Apr 2013 01:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level: 
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BWhmRVcANTg; Tue, 30 Apr 2013 01:32:09 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C3D9121F9AFC; Tue, 30 Apr 2013 01:32:08 -0700 (PDT)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 106AB20C19; Tue, 30 Apr 2013 10:32:08 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FkIdBeuzvjuP; Tue, 30 Apr 2013 10:32:07 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25EBC20C0C; Tue, 30 Apr 2013 10:32:07 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 1101325E9CE6; Tue, 30 Apr 2013 10:32:07 +0200 (CEST)
Date: Tue, 30 Apr 2013 10:32:06 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20130430083206.GD46852@elstar.local>
Mail-Followup-To: Martin Thomson <martin.thomson@gmail.com>, apps-discuss@ietf.org, draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, iesg@ietf.org, netmod@ietf.org
References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Mailman-Approved-At: Tue, 30 Apr 2013 09:34:17 -0700
Cc: draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, netmod@ietf.org, iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2013 08:32:13 -0000

Hi,

thanks for the review. I will respond to your questions inline.

/js

On Sun, Apr 28, 2013 at 11:36:08PM -0700, Martin Thomson wrote:
> (Apologies, I have this habit of not including directorates on
> directorate reviews.  Correcting this oversight.)
> 
> I have been selected as the Applications Area Directorate reviewer for
> this draft (for background on appsdir, please see
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
> ).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-ietf-netmod-rfc6021-bis-01
> Title: Common YANG Data Types
> Reviewer: Martin Thomson
> Review Date: 2013-04-29
> 
> Summary: This draft is ready for publication as a Proposed Standard
> RFC.  I have some minor issues and questions.
> 
> This is some of the most readable code that I have seen.
> 
> Major Issues: none
> 
> Minor Issues:
> 
> Section 4:
> There is an RFC that describes a canonical textual representation of
> IPv6 addresses.  You should use that: RFC 5952.

The typedef ipv6-address has a reference to RFC 5952. I believe the
text in the description statement is inline with RFC 5952. Note that
this text did not change since RFC 6021 (and other than clarifications
we likely do not want changes).

> domain-name doesn't mention RFC 5890 at all (5891 is cited, but not
> used in the text).  I assume that these are LDH-labels:
> http://tools.ietf.org/html/rfc5890#section-2.3.1 and that this
> document should say as much.

I am not sure what you think is unclear. Note that the definition of
the typedef domain-name is unchanged from the one in RFC 6021. Perhaps
you can make a concrete text change proposal so I better understand
what your concern is.

> Questions:
> 
> Section 3:
> phys-address: why is this optionally empty?  Maybe explain why in the
> document - value absent?

The primary reason is to be consistent with the PhysAddress textual
convention of RFC 2579. Note that this definition did not change since
RFC 6021. What an empty address means needs to be defined where the
type is used. I do not think we can regulate that in the type
definition itself. All we could do is add a 'warning' that this type
allows zero-length strings as values and hence users of this type
either need to subtype this type or explain the semantics of a
zero-length string.

> hex-string: why is this required to include at least one octet? The
> text does not mention this at all, I tend to find lots of uses for
> empty octet strings, so this seems odd.

I will take this to the WG. Note that in YANG you often use choices to
model situations where in other frameworks you give special meanings
to say zero-length strings.

> xpath1.0: are we expected to infer that "context" includes document
> and where the namespace prefixes are bound?

The term context is I think well defined in section 1 of the XML Path
Language specification <http://www.w3.org/TR/xpath/> (the document
cited in the reference statement). Note that this typedef is unchanged
from the one in RFC 6021.

> Section 4:
> ipv6-address: that is a very short IPv6 pattern.  Is it provably
> correct?  I only ask because I've had occasion to build a real
> pattern, and it's very long (the following is based on the "official"
> ABNF definition):
> 
>          <xs:pattern value="[0-9A-Fa-f]{1,4}(:[0-9A-Fa-f]{1,4}){7}"/>
>          <!-- Double colon start -->
>          <xs:pattern value=":(:[0-9A-Fa-f]{1,4}){1,7}"/>
>          <!-- Double colon middle -->
>          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,6}
>                 (:[0-9A-Fa-f]{1,4}){1}"/>
>          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,5}
>                 (:[0-9A-Fa-f]{1,4}){1,2}"/>
>          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,4}
>                 (:[0-9A-Fa-f]{1,4}){1,3}"/>
>          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,3}
>                 (:[0-9A-Fa-f]{1,4}){1,4}"/>
>          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,2}
>                 (:[0-9A-Fa-f]{1,4}){1,5}"/>
>          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1}
>                 (:[0-9A-Fa-f]{1,4}){1,6}"/>
>          <!-- Double colon end -->
>          <xs:pattern value="([0-9A-Fa-f]{1,4}:){1,7}:"/>
>          <!-- IPv4-Compatible and IPv4-Mapped Addresses -->
>          <xs:pattern value="((:(:0{1,4}){0,3}:[fF]{4})|(0{1,4}:
>          (:0{1,4}){0,2}:[fF]{4})|((0{1,4}:){2}
>          (:0{1,4})?:[fF]{4})|((0{1,4}:){3}:[fF]{4})
>          |((0{1,4}:){4}[fF]{4})):(25[0-5]|2[0-4][0-9]|
>          [0-1]?[0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]
>          ?[0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]?
>          [0-9]?[0-9])\.(25[0-5]|2[0-4][0-9]|[0-1]?
>          [0-9]?[0-9])"/>

Note sure what the "official" ABNF definition is but we believe that
the two pattern are correct. So far nobody was able to find a case
that was not properly accepted by the pattern. You are welcome to try
to find something where our two pattern break. ;-)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

From Peter.Rushforth@NRCan-RNCan.gc.ca  Tue Apr 30 12:21:05 2013
Return-Path: <Peter.Rushforth@NRCan-RNCan.gc.ca>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7518821F9C70 for <apps-discuss@ietfa.amsl.com>; Tue, 30 Apr 2013 12:21:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iq-zeGjdVDKA for <apps-discuss@ietfa.amsl.com>; Tue, 30 Apr 2013 12:20:58 -0700 (PDT)
Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id 76F2C21F9C07 for <apps-discuss@ietf.org>; Tue, 30 Apr 2013 12:20:55 -0700 (PDT)
Received: from S-BSC-CAS1.nrn.nrcan.gc.ca (132.156.238.11) by S-BSC-EDGE1.nrcan.gc.ca (132.156.238.13) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 30 Apr 2013 15:20:53 -0400
Received: from S-BSC-MBX1.nrn.nrcan.gc.ca ([169.254.1.97]) by S-BSC-CAS1.nrn.nrcan.gc.ca ([fe80::a1cd:5722:74ed:d1fd%21]) with mapi id 14.02.0342.003; Tue, 30 Apr 2013 15:20:53 -0400
From: "Rushforth, Peter" <Peter.Rushforth@NRCan-RNCan.gc.ca>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Thread-Topic: [apps-discuss] Getting 3023bis,	a.k.a. draft-ietf-appsawg-xml-mediatypes, moving
Thread-Index: AQHORa+Mzw7c9r1aD0ytKlzWRPtL8ZjvHZQA
Date: Tue, 30 Apr 2013 19:20:53 +0000
Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF249DAECA@S-BSC-MBX1.nrn.nrcan.gc.ca>
References: <f5b38u89jiz.fsf@calexico.inf.ed.ac.uk>
In-Reply-To: <f5b38u89jiz.fsf@calexico.inf.ed.ac.uk>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [132.156.238.22]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] Getting 3023bis, a.k.a. draft-ietf-appsawg-xml-mediatypes, moving
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2013 19:21:05 -0000

Henry, Chris et al.,

> Further to a suggestion from Julian, perhaps if people would=20
> chip in with their (un)favourite bugs/problems in/with 3023,=20
> I can try to show how the draft [1] addresses them.
>=20
> Comments directed straight at the draft w/o reference to 3023=20
> are, of course, also welcome.


Section 8.

Suggest to remove the recommendation to register media types with +xml
suffix.  Suggest to add recommendation for a 'profile' parameter for applic=
ation/xml,
as is being done for atom : http://tools.ietf.org/html/draft-wilde-atom-pro=
file-01

Suggest to remove reference to Appendix A.  Remove Appendix A, also. All
of that stuff is not the business of this RFC, but is the responsibility=20
of the registration procedure, in my opinion.=20

Suggest to remove discussion of hypertext linking.  XML does not include
hypermedia affordances, so there is a disconnect between what can be expect=
ed in
application/xml vs. what is discussed in this RFC.  If an XML vocabulary
contains XLinks, let that vocabulary register its own media type.
Also, relative to the discussion of XLinks in that section, the web is
not limited to XML documents (heck they hardly even exist on the web),
so perhaps XLink itself needs an update to allow linking to non-XML
representations.

Regards,
Peter Rushforth




From martin.thomson@gmail.com  Tue Apr 30 12:29:34 2013
Return-Path: <martin.thomson@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DD021F984B; Tue, 30 Apr 2013 12:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VkAPh2Ep2CC; Tue, 30 Apr 2013 12:29:32 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2B66E21F992E; Tue, 30 Apr 2013 12:29:02 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id m15so831870wgh.5 for <multiple recipients>; Tue, 30 Apr 2013 12:29:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=SA1BqMG1R8xDriSJQbUH5xR7wT9S25vujE/zleBuWS8=; b=a8uFymPea6P+YprXtI1ruGjnh4CMkh/LijzfMySq3V0cjS1a4tSlc5QqfYsy4HEYO2 2Xu3Y7xwgtyzI7IxYbthCO6VmZl8J3C5LodyRXpE3uTOOH7r5E/7Oj5wR6w9uTDuRkBA +yKZkSQY34voTaEPXp99YgCiFDH+ScMCgRBaejdzpCIH7U6P6okoMxlS0mF45YNRJ4C0 TNWOup5+kJdCpdHANxLcedWwWd5CT7UQJ0PURZX3oJkbDCDvhjrNPwk/7W5eqW52r/II +h8oRtJ0qd7JrGKq4VSXoyn18ux8yvWNYgjvBbQaqURBwVqUF8l7k2r2ivoXLIF8zw0p g3tw==
MIME-Version: 1.0
X-Received: by 10.194.109.227 with SMTP id hv3mr41538571wjb.32.1367350142347;  Tue, 30 Apr 2013 12:29:02 -0700 (PDT)
Received: by 10.194.33.102 with HTTP; Tue, 30 Apr 2013 12:29:02 -0700 (PDT)
In-Reply-To: <20130430083206.GD46852@elstar.local>
References: <6.2.5.6.2.20130428233426.0b62fed0@elandnews.com> <20130430083206.GD46852@elstar.local>
Date: Tue, 30 Apr 2013 12:29:02 -0700
Message-ID: <CABkgnnUe=9RsND+30y3kK39AjvEHe4KKV2qsj=ZkqCAXf0GPHA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>,  Martin Thomson <martin.thomson@gmail.com>, IETF Apps Discuss <apps-discuss@ietf.org>,  draft-ietf-netmod-rfc6021-bis.all@tools.ietf.org, The IESG <iesg@ietf.org>, netmod@ietf.org
Content-Type: text/plain; charset=UTF-8
Subject: Re: [apps-discuss] [appsdir] Fwd: APPSDIR review of draft-ietf-netmod-rfc6021-bis-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2013 19:29:34 -0000

One meta-comment.  I don't consider the contents of RFC 6021 to have
any bearing on the review of this document.  I'm not familiar with
6021, so I consider all of this to be new.

On 30 April 2013 01:32, Juergen Schoenwaelder
<j.schoenwaelder@jacobs-university.de> wrote:
>> There is an RFC that describes a canonical textual representation of
>> IPv6 addresses.  You should use that: RFC 5952.
>
> The typedef ipv6-address has a reference to RFC 5952. I believe the
> text in the description statement is inline with RFC 5952. Note that
> this text did not change since RFC 6021 (and other than clarifications
> we likely do not want changes).

That's unfortunate because I can't tell whether RFC 5952 and the
following are the same very easily:

   "The canonical format of IPv6 addresses uses the compressed
         format described in RFC 4291, Section 2.2, item 2 with the
         following additional rules: the :: substitution must be
         applied to the longest sequence of all-zero 16-bit chunks
         in an IPv6 address.  If there is a tie, the first sequence
         of all-zero 16-bit chunks is replaced by ::.  Single
         all-zero 16-bit chunks are not compressed.  The canonical
         format uses lowercase characters and leading zeros are
         not allowed.  The canonical format for the zone index is
         the numerical format as described in RFC 4007, Section
         11.2."

Suggest:
   "The canonical format of IPv6 addresses is described in RFC5952;
the canonical form of the zone index is described in RFC 4007, Section
11.2."

Adding something to references is not the same as providing normative
text that stipulates how the information is intended to be consumed.
If the intent is to have the reference as normative, informative
references are fine as disassociated links.

>> domain-name doesn't mention RFC 5890 at all (5891 is cited, but not
>> used in the text).  I assume that these are LDH-labels:
>> http://tools.ietf.org/html/rfc5890#section-2.3.1 and that this
>> document should say as much.
>
> I am not sure what you think is unclear. Note that the definition of
> the typedef domain-name is unchanged from the one in RFC 6021. Perhaps
> you can make a concrete text change proposal so I better understand
> what your concern is.

The pattern for domain-name implies LDH label, however the textual
description does not.

OLD:
Internet domain names are only loosely specified.  Section
         3.5 of RFC 1034 recommends a syntax (modified in Section
         2.1 of RFC 1123).  The pattern above is intended to allow
         for current practice in domain name use, and some possible
         future expansion.  It is designed to hold various types of
         domain names, including names used for A or AAAA records
         (host names) and other records, such as SRV records.  Note
         that Internet host names have a stricter syntax (described
         in RFC 952) than the DNS recommendations in RFCs 1034 and
         1123, and that systems that want to store host names in
         schema nodes using the domain-name type are recommended to
         adhere to this stricter standard to ensure interoperability.
NEW:
  "A domain-name MUST consist of LDH-labels as defined in RFC 5890.

  Note: If fields of this type are used to store host names [RFC0952],
host names use a stricter syntax.  Systems that store host names
SHOULD enforce stronger restrictions or use a derived type for host
names."

>> phys-address: why is this optionally empty?  Maybe explain why in the
>> document - value absent?
>
> The primary reason is to be consistent with the PhysAddress textual
> convention of RFC 2579. Note that this definition did not change since
> RFC 6021. What an empty address means needs to be defined where the
> type is used. I do not think we can regulate that in the type
> definition itself. All we could do is add a 'warning' that this type
> allows zero-length strings as values and hence users of this type
> either need to subtype this type or explain the semantics of a
> zero-length string.

Yes, either would be nice, but I'm not that concerned about these.  I
prefer to see such surprises explained in some way.  e.g.,
"phys-address permits an empty string to so that the textual
convention established in RFC 2579 can be used.  An empty string has
no defined semantics here, subtypes SHOULD either assign semantics to
this value or eliminate it."

>> hex-string: why is this required to include at least one octet? The
>> text does not mention this at all, I tend to find lots of uses for
>> empty octet strings, so this seems odd.
>
> I will take this to the WG. Note that in YANG you often use choices to
> model situations where in other frameworks you give special meanings
> to say zero-length strings.

> ipv6 pattern
> Note sure what the "official" ABNF definition is but we believe that
> the two pattern are correct. So far nobody was able to find a case
> that was not properly accepted by the pattern. You are welcome to try
> to find something where our two pattern break. ;-)

Sorry, "official" is my shorthand for saying: there is an RFC out
there that defines this ABNF but I was too lazy to go and look for it
because I know that chances are I will find the wrong one.

The first pattern is overly restrictive, I think (only double colon at
the start?).  The second is definitely overly permissive.
This:sentence:is::actually:valid.  (I think).

> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>