From evnikita2@gmail.com Sun Jan 1 00:25:46 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BA321F8496; Sun, 1 Jan 2012 00:25:46 -0800 (PST) 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 O8ZRQdgYje6B; Sun, 1 Jan 2012 00:25:46 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EEE7521F849B; Sun, 1 Jan 2012 00:25:45 -0800 (PST) Received: by obcuz6 with SMTP id uz6so12774560obc.31 for ; Sun, 01 Jan 2012 00:25:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=V6GnkoT3lm+Bj/4/1/ho3FcPn7085fBqGQkcPKY82rw=; b=iIOhwh21mbk+8a1CBY+KmX0dO4CHAlAHl5WW9EFYbQLIQAfjCqi6mZgaE4bU/hSuaw EJTMH7PP6R4W7DzA2AJkHHGD39mdOGujO578qP5cU2KQ60HlE6AKp4Nrv6LfwMOylPpV +EjRlulX37i6uZJR1s4FshzxlMYLw6L20coNM= MIME-Version: 1.0 Received: by 10.182.15.104 with SMTP id w8mr38921150obc.20.1325406342975; Sun, 01 Jan 2012 00:25:42 -0800 (PST) Received: by 10.182.30.167 with HTTP; Sun, 1 Jan 2012 00:25:42 -0800 (PST) In-Reply-To: <4EFC88F5.4070106@gmx.de> References: <20111209175852.12171.32923.idtracker@ietfa.amsl.com> <4EFC88F5.4070106@gmx.de> Date: Sun, 1 Jan 2012 10:25:42 +0200 Message-ID: Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC From: Mykyta Yevstifeyev To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 08:25:46 -0000 Julian, all, When I came to fixing the examples section per received comments, I first began to refine the example on references to separate disclosures, and what I got was: ... Please visit the IPR page for the list of patent disclosures made with respect to this specification. ... (unchanged fragment of list) and, later, IPR Disclosure #1097 (this was fixed to suit real situation with RFC 5925). And, after a closer look, I realized that the separate-patent-disclosure semantics and a list-thereof one are completely different. That is a simple and compelling reason, I think, to distinguish the semantics. And that's why we have 'item' and 'collection' relations (now in LC) defined as pair (actually, what my document defines may be considered to be a special case of these in some way). The only thing is that such proposed definition is different from the current W3C's use of 'disclosure' relation, which is used as my proposed 'disclosure-list', but once we have defined both, W3C will migrate to a new, correct one (I hope). All the best, and happy New Year, Mykyta Yevstifeyev 2011/12/29 Julian Reschke : > On 2011-12-27 07:52, Mykyta Yevstifeyev wrote: >> >> Hello, >> >> I'd like to seek consensus on separating the semantics of link >> relation for separate disclosure and a list thereof, correspondingly >> defining two link relations - 'disclosure' and 'disclosure-list'. =A0You >> may see my edits made to Section 2 of the doc. below, which I'm >> proposing: >> >> 2. 'disclosure' Link Relation Type >> >> =A0 =A0Whenever the 'disclosure' relation is defined, the target IRI >> =A0 =A0[RFC5988] MUST refer to a particular patent disclosure made with >> =A0 =A0respect to the material being referenced by context IRI. >> >> 3. 'disclosure-list' Link Relation Type >> >> =A0 =A0Whenever the 'disclosure' relation is defined, the target IRI MUS= T >> =A0 =A0designate a list of patent disclosures made with respect to the >> =A0 =A0material being referenced by context IRI. >> >> As the doc. is in Last Call now, in order not to initiate a new one, >> please comment on these changes before January 6, so that I could know >> which version I should submit for IESG evaluation. >> ... > > > I don't see a compelling reason to distinguish both. > > Best regards, Julian From julian.reschke@gmx.de Sun Jan 1 05:57:35 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0710F21F9283 for ; Sun, 1 Jan 2012 05:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.449 X-Spam-Level: X-Spam-Status: No, score=-104.449 tagged_above=-999 required=5 tests=[AWL=-1.850, 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 LxyAvqNgZ8TH for ; Sun, 1 Jan 2012 05:57:34 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8B2B321F946D for ; Sun, 1 Jan 2012 05:57:13 -0800 (PST) Received: (qmail invoked by alias); 01 Jan 2012 13:57:11 -0000 Received: from p5DCC3F8F.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.63.143] by mail.gmx.net (mp006) with SMTP; 01 Jan 2012 14:57:11 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX183RqV9wtA3Npq6mGLpnaqDBtMfmz6Cln023Dxhx2 9Z+XPpKwkL2L+N Message-ID: <4F006633.1040800@gmx.de> Date: Sun, 01 Jan 2012 14:57:07 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Mykyta Yevstifeyev Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC References: <20111209175852.12171.32923.idtracker@ietfa.amsl.com> <4EFC88F5.4070106@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 13:57:35 -0000 On 2012-01-01 09:25, Mykyta Yevstifeyev wrote: > Julian, all, > > When I came to fixing the examples section per received comments, I > first began to refine the example on references to separate > disclosures, and what I got was: > > > ... > Please visit > > the IPR page for the list of patent disclosures made with > respect to this specification. > ... > > > (unchanged fragment of list) and, later, > > href="https://datatracker.ietf.org/ipr/1097/">IPR Disclosure > #1097 > > (this was fixed to suit real situation with RFC 5925). And, after a > closer look, I realized that the separate-patent-disclosure semantics > and a list-thereof one are completely different. That is a simple and > compelling reason, I think, to distinguish the semantics. > > And that's why we have 'item' and 'collection' relations (now in LC) > defined as pair (actually, what my document defines may be considered > to be a special case of these in some way). > > The only thing is that such proposed definition is different from the > current W3C's use of 'disclosure' relation, which is used as my > proposed 'disclosure-list', but once we have defined both, W3C will > migrate to a new, correct one (I hope). > > All the best, and happy New Year, > Mykyta Yevstifeyev > ... Not convinced. I thought the purpose was to document an existing use? Now you're adding another one (post-LC), and it's (as far as I can tell) totally unclear what the W3C's take on this is. (they introduced the link relation, after all) Best regards, Julian From evnikita2@gmail.com Sun Jan 1 06:04:02 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902A321F98B8; Sun, 1 Jan 2012 06:04:02 -0800 (PST) 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 ev7qwGmpJFyJ; Sun, 1 Jan 2012 06:04:02 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E729321F98B7; Sun, 1 Jan 2012 06:04:01 -0800 (PST) Received: by obcuz6 with SMTP id uz6so12867392obc.31 for ; Sun, 01 Jan 2012 06:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uqIW3cVPfTjRstNWRSFpMmgssSB59qnI2x/Ogei38VY=; b=i/6tGM5/Vvc33BKqzWEZAX26JHpIGOVRzGezea5xwRlBRHPm9PbR5LkywXOqqTgiCV LetrLpyFlMw38kQW+e6ZtR+yfZvwa2jH79+YWT1D5DDHLxSK5s2gr2ozXZK1Hkez1Kw3 bX/MYQ5QMKhsBpRM/s2Kp+sNt2pwUIKQkdSec= MIME-Version: 1.0 Received: by 10.182.117.97 with SMTP id kd1mr12966607obb.50.1325426641551; Sun, 01 Jan 2012 06:04:01 -0800 (PST) Received: by 10.182.30.167 with HTTP; Sun, 1 Jan 2012 06:04:01 -0800 (PST) In-Reply-To: <4F006633.1040800@gmx.de> References: <20111209175852.12171.32923.idtracker@ietfa.amsl.com> <4EFC88F5.4070106@gmx.de> <4F006633.1040800@gmx.de> Date: Sun, 1 Jan 2012 16:04:01 +0200 Message-ID: Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC From: Mykyta Yevstifeyev To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 14:04:02 -0000 Julian, I'd be glad to describe current use, but as long as we want to introduce a possibility to reference separate disclosures, we cannot fit two separate semantic models in one relation type. And the naming 'disclosure' suits separate instances of disclosures rather than a list. And, should there be no objections, the document may be processed with the change without 2nd LC. Mykyta Yevstifeyev 2012/1/1 Julian Reschke : > On 2012-01-01 09:25, Mykyta Yevstifeyev wrote: >> >> Julian, all, >> >> When I came to fixing the examples section per received comments, I >> first began to refine the example on references to separate >> disclosures, and what I got was: >> >> =A0 =A0 >> =A0 =A0 =A0... >> =A0 =A0 =A0Please visit >> =A0 =A0 =A0 >> =A0 =A0 =A0the IPR page =A0for the list of patent disclosures made w= ith >> =A0 =A0 =A0respect to this specification. >> =A0 =A0 =A0... >> =A0 =A0 >> >> (unchanged fragment of list) and, later, >> >> =A0 =A0 > =A0 =A0 =A0href=3D"https://datatracker.ietf.org/ipr/1097/">IPR Disclosur= e >> =A0 =A0 #1097 >> >> (this was fixed to suit real situation with RFC 5925). =A0And, after a >> closer look, I realized that the separate-patent-disclosure semantics >> and a list-thereof one are completely different. =A0That is a simple and >> compelling reason, I think, to distinguish the semantics. >> >> And that's why we have 'item' and 'collection' relations (now in LC) >> defined as pair (actually, what my document defines may be considered >> to be a special case of these in some way). >> >> The only thing is that such proposed definition is different from the >> current W3C's use of 'disclosure' relation, which is used as my >> proposed 'disclosure-list', but once we have defined both, W3C will >> migrate to a new, correct one (I hope). >> >> All the best, and happy New Year, >> Mykyta Yevstifeyev >> ... > > > Not convinced. I thought the purpose was to document an existing use? Now > you're adding another one (post-LC), and it's (as far as I can tell) tota= lly > unclear what the W3C's take on this is. (they introduced the link relatio= n, > after all) > > Best regards, Julian From tlr@w3.org Sun Jan 1 06:21:44 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E3421F993F; Sun, 1 Jan 2012 06:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 j-121rlmzpEs; Sun, 1 Jan 2012 06:21:43 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id BAA0C21F9907; Sun, 1 Jan 2012 06:21:43 -0800 (PST) Received: from ip-88-207-233-25.dyn.luxdsl.pt.lu ([88.207.233.25] helo=[192.168.2.104]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1RhMI7-0006l6-Or; Sun, 01 Jan 2012 09:21:39 -0500 Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Roessler In-Reply-To: Date: Sun, 1 Jan 2012 15:21:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111209175852.12171.32923.idtracker@ietfa.amsl.com> <4EFC88F5.4070106@gmx.de> <4F006633.1040800@gmx.de> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1251.1) Cc: Julian Reschke , ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 14:21:44 -0000 Mykyta, thank you for working on this draft. Before you try to get a = specification through Last Call that's possibly at odds with the current = (and as far as I know original) use of the link relationship, it would = perhaps be useful to talk to the current users of this particular link = relationship, and request their review of the specification, and find = out their views on the proposed change to its semantics. A good place to reach many of the interested parties would be the = spec-prod@w3.org mailing list. Also, I'd recommend that you contact Ian Jacobs, W3C's head of = communications; he's in charge of the detailed publication requirements = for W3C specifications. Before these steps have happened, it would appear premature to me to = request publication of this document as an RFC. Regards, -- Thomas Roessler, W3C (@roessler) On 2012-01-01, at 15:04 +0100, Mykyta Yevstifeyev wrote: > Julian, >=20 > I'd be glad to describe current use, but as long as we want to > introduce a possibility to reference separate disclosures, we cannot > fit two separate semantic models in one relation type. And the naming > 'disclosure' suits separate instances of disclosures rather than a > list. And, should there be no objections, the document may be > processed with the change without 2nd LC. >=20 > Mykyta Yevstifeyev >=20 > 2012/1/1 Julian Reschke : >> On 2012-01-01 09:25, Mykyta Yevstifeyev wrote: >>>=20 >>> Julian, all, >>>=20 >>> When I came to fixing the examples section per received comments, I >>> first began to refine the example on references to separate >>> disclosures, and what I got was: >>>=20 >>> >>> ... >>> Please visit >>> = >>> the IPR page for the list of patent disclosures made with >>> respect to this specification. >>> ... >>> >>>=20 >>> (unchanged fragment of list) and, later, >>>=20 >>> >> href=3D"https://datatracker.ietf.org/ipr/1097/">IPR Disclosure >>> #1097 >>>=20 >>> (this was fixed to suit real situation with RFC 5925). And, after a >>> closer look, I realized that the separate-patent-disclosure = semantics >>> and a list-thereof one are completely different. That is a simple = and >>> compelling reason, I think, to distinguish the semantics. >>>=20 >>> And that's why we have 'item' and 'collection' relations (now in LC) >>> defined as pair (actually, what my document defines may be = considered >>> to be a special case of these in some way). >>>=20 >>> The only thing is that such proposed definition is different from = the >>> current W3C's use of 'disclosure' relation, which is used as my >>> proposed 'disclosure-list', but once we have defined both, W3C will >>> migrate to a new, correct one (I hope). >>>=20 >>> All the best, and happy New Year, >>> Mykyta Yevstifeyev >>> ... >>=20 >>=20 >> Not convinced. I thought the purpose was to document an existing use? = Now >> you're adding another one (post-LC), and it's (as far as I can tell) = totally >> unclear what the W3C's take on this is. (they introduced the link = relation, >> after all) >>=20 >> Best regards, Julian > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From ron.even.tlv@gmail.com Sun Jan 1 06:24:52 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3172921F8F28; Sun, 1 Jan 2012 06:24:52 -0800 (PST) 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 ZAF-wq0Vr0Ih; Sun, 1 Jan 2012 06:24:51 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A924021F9993; Sun, 1 Jan 2012 06:24:50 -0800 (PST) Received: by eekc14 with SMTP id c14so13605489eek.31 for ; Sun, 01 Jan 2012 06:24:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:content-language:thread-index; bh=67bCB4eFmApPYeRKbteNdHIKFjAtwVCL2mcl/EYmQ5Q=; b=KYE/Bp1dKNN9gTDTH3QR9Zn2+P/13TV/ojN0ezCBORid1o4Np8dmYkaZOX45C2jPTw BchrRWLq+7Ac9AZBRvAQGCbpgwrD1LT1QTUjwwATxdFGRqDBrgMANGdM6omonwVLFoNz gXOAjaiaLa+z6megmUF46qL3gF2Vexe9G2SBY= Received: by 10.14.122.198 with SMTP id t46mr18187127eeh.83.1325427883716; Sun, 01 Jan 2012 06:24:43 -0800 (PST) Received: from windows8d787f9 ([109.67.213.220]) by mx.google.com with ESMTPS id 76sm177626148eeh.0.2012.01.01.06.24.40 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 01 Jan 2012 06:24:42 -0800 (PST) From: "Roni Even" To: Subject: Gen-ART last call review of draft-ietf-dhc-vpn-option-14 Date: Sun, 1 Jan 2012 16:21:20 +0200 Message-ID: <4f006caa.e4030e0a.7250.5065@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01CCC8A1.683BA150" X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AczIkKG6Azp6dpNpQTCIHYj/7O3giQ== Cc: gen-art@ietf.org, 'IETF-Discussion list' X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 14:24:52 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_003D_01CCC8A1.683BA150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dhc-vpn-option-14 Reviewer: Roni Even Review Date: 2012-1-1 IETF LC End Date: 2012-1-4 IESG Telechat date: 2012-1-5 Summary: This draft is ready for publication as a standard RFC. Major issues: Minor issues: Nits/editorial comments: 1. In section 3.2 "Type and VSS Information -- see Section 35" should be 3.5 2. In section 3.3 "This sub-option only only" 3. In 3.5 last bullet not clear - "and the length of the MUST be 1." ------=_NextPart_000_003D_01CCC8A1.683BA150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am the = assigned Gen-ART reviewer for this draft. For background on Gen-ART, = please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq= >.

Please resolve these = comments along with any other Last Call comments you may = receive.

Document: = draft-ietf-dhc-vpn-option-14

Reviewer: = Roni Even

Review = Date: 2012–1–1

IETF LC = End Date: 2012–1–4

IESG = Telechat date:  2012-1-5

 =

Summary: = This draft is ready for publication as a standard  RFC.  =

 =

Major = issues:

 =

 =

Minor = issues:

 =

 =

Nits/editor= ial comments: 

 =

1.       = In section = 3.2 “Type and VSS = Information -- see Section 35” should be 3.5=

2.       = In section = 3.3 “This = sub-option only only” =

3.       = In 3.5 last bullet not clear - = “and the length of the MUST be 1.”=

 =

 

------=_NextPart_000_003D_01CCC8A1.683BA150-- From derhoermi@gmx.net Sun Jan 1 06:51:06 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE05521F8B63 for ; Sun, 1 Jan 2012 06:51:06 -0800 (PST) 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 qvSiaFdhG3bP for ; Sun, 1 Jan 2012 06:51:05 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9EF4221F8B16 for ; Sun, 1 Jan 2012 06:51:02 -0800 (PST) Received: (qmail invoked by alias); 01 Jan 2012 14:51:00 -0000 Received: from dslb-094-223-218-043.pools.arcor-ip.net (EHLO HIVE) [94.223.218.43] by mail.gmx.net (mp028) with SMTP; 01 Jan 2012 15:51:00 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18tGFkiwwct6KfA8DBzCXPp7PLQWqWmxpdXJ2c+cU bG6FvbBXj0pcTZ From: Bjoern Hoehrmann To: Thomas Roessler Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC Date: Sun, 01 Jan 2012 15:51:01 +0100 Message-ID: References: <20111209175852.12171.32923.idtracker@ietfa.amsl.com> <4EFC88F5.4070106@gmx.de> <4F006633.1040800@gmx.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: Julian Reschke , ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 14:51:06 -0000 * Thomas Roessler wrote: >thank you for working on this draft. Before you try to get a >specification through Last Call that's possibly at odds with the current >(and as far as I know original) use of the link relationship, it would >perhaps be useful to talk to the current users of this particular link >relationship, and request their review of the specification, and find >out their views on the proposed change to its semantics. > >A good place to reach many of the interested parties would be the >spec-prod@w3.org mailing list. > >Also, I'd recommend that you contact Ian Jacobs, W3C's head of >communications; he's in charge of the detailed publication requirements >for W3C specifications. > >Before these steps have happened, it would appear premature to me to >request publication of this document as an RFC. If Ian Jacobs is responsible for the things discussed on spec-prod, I'd think he reads that mailing list, and the mailing list has been aware of the draft since the first version has been published in October 2011, . What might be useful is to ask W3C's IETF Liaison what W3C's policy is with respect to registration of link relations W3C makes up and uses on its web site. The Internet Community shouldn't really have to clean up after the W3C to ensure proper registration of link relations W3C uses. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From tlr@w3.org Sun Jan 1 07:04:59 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD9321F936E; Sun, 1 Jan 2012 07:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fQvdJ6PNz51D; Sun, 1 Jan 2012 07:04:58 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id BC33021F936D; Sun, 1 Jan 2012 07:04:58 -0800 (PST) Received: from ip-88-207-233-25.dyn.luxdsl.pt.lu ([88.207.233.25] helo=[192.168.2.104]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1RhMxy-00008J-2F; Sun, 01 Jan 2012 10:04:54 -0500 Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Roessler In-Reply-To: Date: Sun, 1 Jan 2012 16:04:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111209175852.12171.32923.idtracker@ietfa.amsl.com> <4EFC88F5.4070106@gmx.de> <4F006633.1040800@gmx.de> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1251.1) Cc: Julian Reschke , ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 15:04:59 -0000 On 2012-01-01, at 15:51 +0100, Bjoern Hoehrmann wrote: > * Thomas Roessler wrote: >> thank you for working on this draft. Before you try to get a >> specification through Last Call that's possibly at odds with the = current >> (and as far as I know original) use of the link relationship, it = would >> perhaps be useful to talk to the current users of this particular = link >> relationship, and request their review of the specification, and find >> out their views on the proposed change to its semantics. >>=20 >> A good place to reach many of the interested parties would be the >> spec-prod@w3.org mailing list. >>=20 >> Also, I'd recommend that you contact Ian Jacobs, W3C's head of >> communications; he's in charge of the detailed publication = requirements >> for W3C specifications. >>=20 >> Before these steps have happened, it would appear premature to me to >> request publication of this document as an RFC. >=20 > If Ian Jacobs is responsible for the things discussed on spec-prod, = I'd think he reads that mailing list, and the mailing list has been = aware of the draft since the first version has been published in October = 2011, > . Neither the intention to last call the draft, nor the proposed = incompatible change were announced to that list. From derhoermi@gmx.net Sun Jan 1 08:13:36 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C071311E8081 for ; Sun, 1 Jan 2012 08:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.162 X-Spam-Level: X-Spam-Status: No, score=-1.162 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, MANGLED_PREMTR=2.3] 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 fKIF+6cgtkls for ; Sun, 1 Jan 2012 08:13:36 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id A5D6811E807F for ; Sun, 1 Jan 2012 08:13:35 -0800 (PST) Received: (qmail invoked by alias); 01 Jan 2012 16:13:33 -0000 Received: from dslb-094-223-218-043.pools.arcor-ip.net (EHLO HIVE) [94.223.218.43] by mail.gmx.net (mp003) with SMTP; 01 Jan 2012 17:13:33 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/lEJl+sBHl6Hs7zAlvMzTMmO6LZEyaycD5icagI0 gjEHYtpseICAqo From: Bjoern Hoehrmann To: Thomas Roessler Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC Date: Sun, 01 Jan 2012 17:13:33 +0100 Message-ID: <4tu0g7d98h4st9ejgs32son1tldca2p0l9@hive.bjoern.hoehrmann.de> References: <20111209175852.12171.32923.idtracker@ietfa.amsl.com> <4EFC88F5.4070106@gmx.de> <4F006633.1040800@gmx.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: Julian Reschke , ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 16:13:36 -0000 * Thomas Roessler wrote: >On 2012-01-01, at 15:51 +0100, Bjoern Hoehrmann wrote: >> * Thomas Roessler wrote: >>> Before these steps have happened, it would appear premature to me to >>> request publication of this document as an RFC. >Neither the intention to last call the draft, nor the proposed >incompatible change were announced to that list. So what is the point of order you are trying to raise? Registering the link relation pretty much requires publication of the draft as RFC, so the intent should be implicit, and given the length of the draft, and my review comments, the timing should be rather clear to anyone who cared aswell, so I don't see how the request for publication was prema- ture. If you only want to make sure interested parties are aware of the state of the discussion around the document, you can just tell them, like I did when I copied my review comments to spec-prod, or point this thread out to W3C's IETF Liaison so they can spread the word for you. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From tlr@w3.org Sun Jan 1 09:06:27 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9311F0C36; Sun, 1 Jan 2012 09:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.384 X-Spam-Level: X-Spam-Status: No, score=-9.384 tagged_above=-999 required=5 tests=[AWL=-1.215, BAYES_00=-2.599, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_HI=-8, SARE_RMML_Stock10=0.13] 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 9o2epcVJ9oGX; Sun, 1 Jan 2012 09:06:27 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id EEB1A1F0C35; Sun, 1 Jan 2012 09:06:26 -0800 (PST) Received: from ip-88-207-233-25.dyn.luxdsl.pt.lu ([88.207.233.25] helo=[192.168.2.104]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1RhOrX-0005HP-NI; Sun, 01 Jan 2012 12:06:23 -0500 Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Thomas Roessler In-Reply-To: <4tu0g7d98h4st9ejgs32son1tldca2p0l9@hive.bjoern.hoehrmann.de> Date: Sun, 1 Jan 2012 18:06:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111209175852.12171.32923.idtracker@ietfa.amsl.com> <4EFC88F5.4070106@gmx.de> <4F006633.1040800@gmx.de> <4tu0g7d98h4st9ejgs32son1tldca2p0l9@hive.bjoern.hoehrmann.de> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1251.1) Cc: Julian Reschke , ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 17:06:27 -0000 Bjoern, I'm not interested in a game of process nomics. rel=3Ddisclosure has been in actual and continuous use in highly stable = documents for almost 10 years now; a very quick search turns up early = usage in late 2002. As far as I can tell, it starts to show up as a = "suggestion" in the W3C publication rules some time between April and = September 2002.=20 That predates the Web Linking spec (and its creation of the current = relationship value registry) by about 8 years. The draft before the IETF now started out as inspired by and documenting = the existing usage. That is a very welcome and useful thing to do. The proposal is now =97 in last call =97 changing into "hey, let's = actually redefine the usage of that link relationship, W3C will just = follow." I think that that is an unwise step unless you actually have = buy-in from those who build the current W3C tool-chain, and from those = who maintain the current set of documents. The very least I'd expect is = that those who propose the change make an effort to get in touch with = the current users of the link relationship. Posting an idea to = ietf@ietf.org is not a good way to do so. Further, I think that it will be pretty unlikely that we'll make changes = to Recommendations and other publications going back over 10 years to = accommodate the proposed new usage. Speaking personally, -1 to the proposed change of semantics. Speaking as liaison, I've already pointed you at the appropriate people = to ask for review. This being an individual, informational draft, I = think it's fair to expect the submitter to go and secure the appropriate = review. Regards, -- Thomas Roessler, W3C (@roessler) On 2012-01-01, at 17:13 +0100, Bjoern Hoehrmann wrote: > * Thomas Roessler wrote: >> On 2012-01-01, at 15:51 +0100, Bjoern Hoehrmann wrote: >>> * Thomas Roessler wrote: >>>> Before these steps have happened, it would appear premature to me = to >>>> request publication of this document as an RFC. >=20 >> Neither the intention to last call the draft, nor the proposed >> incompatible change were announced to that list. >=20 > So what is the point of order you are trying to raise? Registering the > link relation pretty much requires publication of the draft as RFC, so > the intent should be implicit, and given the length of the draft, and > my review comments, the timing should be rather clear to anyone who > cared aswell, so I don't see how the request for publication was = prema- > ture. >=20 > If you only want to make sure interested parties are aware of the = state > of the discussion around the document, you can just tell them, like I > did when I copied my review comments to spec-prod, or point this = thread > out to W3C's IETF Liaison so they can spread the word for you. > --=20 > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 = http://bjoern.hoehrmann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 = http://www.bjoernsworld.de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 = http://www.websitedev.de/=20 >=20 From john-ietf@jck.com Sun Jan 1 09:11:15 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C20921F8BB1; Sun, 1 Jan 2012 09:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.525 X-Spam-Level: X-Spam-Status: No, score=-101.525 tagged_above=-999 required=5 tests=[AWL=-1.356, BAYES_00=-2.599, MANGLED_PREMTR=2.3, SARE_RMML_Stock10=0.13, 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 YBBKwMRO5oXV; Sun, 1 Jan 2012 09:11:08 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 6464B21F8BAB; Sun, 1 Jan 2012 09:11:08 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RhOw4-000AKP-62; Sun, 01 Jan 2012 12:11:04 -0500 X-Vipre-Scanned: 07ED0B2E002C3107ED0C7B-TDI Date: Sun, 01 Jan 2012 12:11:03 -0500 From: John C Klensin To: Thomas Roessler , Bjoern Hoehrmann Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC Message-ID: <923706E64FA52E97136B664D@[192.168.1.128]> In-Reply-To: References: <20111209175852.12171.32923.idtracker@ietfa.amsl.com> <4EFC88F5.4070106@gmx.de> <4F006633.1040800@gmx.de> <4tu0g7d98h4st9ejgs32son1tldca2p0l9@hive.bjoern.hoehrmann.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Julian Reschke , ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 17:11:15 -0000 FWIW, I strongly support Thomas's position. This should either be a narrow description of existing practice or should not be approved by the IETF without review and buy-in from the communities who actually use and support this mechanism. =20 john --On Sunday, January 01, 2012 18:06 +0100 Thomas Roessler wrote: > Bjoern, >=20 > I'm not interested in a game of process nomics. >=20 > rel=3Ddisclosure has been in actual and continuous use in = highly > stable documents for almost 10 years now; a very quick search > turns up early usage in late 2002. As far as I can tell, it > starts to show up as a "suggestion" in the W3C publication > rules some time between April and September 2002.=20 >=20 > That predates the Web Linking spec (and its creation of the > current relationship value registry) by about 8 years. >=20 > The draft before the IETF now started out as inspired by and > documenting the existing usage. That is a very welcome and > useful thing to do. >=20 > The proposal is now =E2=80=94 in last call =E2=80=94 changing = into "hey, > let's actually redefine the usage of that link relationship, > W3C will just follow." I think that that is an unwise step > unless you actually have buy-in from those who build the > current W3C tool-chain, and from those who maintain the > current set of documents. The very least I'd expect is that > those who propose the change make an effort to get in touch > with the current users of the link relationship. Posting an > idea to ietf@ietf.org is not a good way to do so. >=20 > Further, I think that it will be pretty unlikely that we'll > make changes to Recommendations and other publications going > back over 10 years to accommodate the proposed new usage. >=20 > Speaking personally, -1 to the proposed change of semantics. >=20 > Speaking as liaison, I've already pointed you at the > appropriate people to ask for review. This being an > individual, informational draft, I think it's fair to expect > the submitter to go and secure the appropriate review. >=20 > Regards, > -- > Thomas Roessler, W3C (@roessler) >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 2012-01-01, at 17:13 +0100, Bjoern Hoehrmann wrote: >=20 >> * Thomas Roessler wrote: >>> On 2012-01-01, at 15:51 +0100, Bjoern Hoehrmann wrote: >>>> * Thomas Roessler wrote: >>>>> Before these steps have happened, it would appear >>>>> premature to me to request publication of this document as >>>>> an RFC. >>=20 >>> Neither the intention to last call the draft, nor the >>> proposed incompatible change were announced to that list. >>=20 >> So what is the point of order you are trying to raise? >> Registering the link relation pretty much requires >> publication of the draft as RFC, so the intent should be >> implicit, and given the length of the draft, and my review >> comments, the timing should be rather clear to anyone who >> cared aswell, so I don't see how the request for publication >> was prema- ture. >>=20 >> If you only want to make sure interested parties are aware of >> the state of the discussion around the document, you can just >> tell them, like I did when I copied my review comments to >> spec-prod, or point this thread out to W3C's IETF Liaison so >> they can spread the word for you. --=20 >> Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de = =C2=B7 >> http://bjoern.hoehrmann.de Am Badedeich 7 =C2=B7 Telefon: >> +49(0)160/4415681 =C2=B7 http://www.bjoernsworld.de 25899 >> Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 >> http://www.websitedev.de/=20 >>=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From derhoermi@gmx.net Sun Jan 1 10:13:30 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C1321F8D43 for ; Sun, 1 Jan 2012 10:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=0.460, 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 VY3on6T5jroz for ; Sun, 1 Jan 2012 10:13:30 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 5A72121F8D42 for ; Sun, 1 Jan 2012 10:13:29 -0800 (PST) Received: (qmail invoked by alias); 01 Jan 2012 18:13:24 -0000 Received: from dslb-094-223-218-043.pools.arcor-ip.net (EHLO HIVE) [94.223.218.43] by mail.gmx.net (mp057) with SMTP; 01 Jan 2012 19:13:24 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/UDN8U89HUNHm1IlLWO+DilimTdghhFfOYqYvXI7 YPpsTxRMcAbDCr From: Bjoern Hoehrmann To: Thomas Roessler Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC Date: Sun, 01 Jan 2012 19:13:24 +0100 Message-ID: References: <4EFC88F5.4070106@gmx.de> <4F006633.1040800@gmx.de> <4tu0g7d98h4st9ejgs32son1tldca2p0l9@hive.bjoern.hoehrmann.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: Julian Reschke , ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 18:13:30 -0000 * Thomas Roessler wrote: >I'm not interested in a game of process nomics. If you are not interested in discussing whether it was "premature ... to request publication of this document as an RFC" then don't suggest that it was? The IETF is currently discussing proper procedures for this kind of third-party registration in various places like "happiana", you will excuse that some of us are interested in finding suitable guidelines. >Speaking as liaison, I've already pointed you at the appropriate people >to ask for review. This being an individual, informational draft, I >think it's fair to expect the submitter to go and secure the appropriate >review. I think it's fair to expect you to keep people in the W3C apprised about developments in the IETF relevant to their work, and I think it's fair to dismiss your opinion in this matter given that you don't want to dis- cuss it. Mykyta Yevstifeyev made a draft, interested parties were made aware of the draft, and after some weeks with no comments from them, as far as I am aware, Mykyta Yevstifeyev asked for publication of the draft as RFC. I don't think there is anything wrong with that. If you disagree perhaps you can find someone to argue your point on the "happiana" list so we can give better guidance to our fellow community members. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From julian.reschke@gmx.de Sun Jan 1 10:28:54 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C4E21F8E25 for ; Sun, 1 Jan 2012 10:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.228 X-Spam-Level: X-Spam-Status: No, score=-104.228 tagged_above=-999 required=5 tests=[AWL=-1.629, 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 ggZw+60tbuKy for ; Sun, 1 Jan 2012 10:28:54 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id C9D8421F8E22 for ; Sun, 1 Jan 2012 10:28:53 -0800 (PST) Received: (qmail invoked by alias); 01 Jan 2012 18:28:52 -0000 Received: from p5DCC3F8F.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.63.143] by mail.gmx.net (mp070) with SMTP; 01 Jan 2012 19:28:52 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+gzKQCE+Kg/JqFrteBdE2r4JBzVPK2kxwBrL9X4x gG1p6MTbIX5ueU Message-ID: <4F00A5DF.3090605@gmx.de> Date: Sun, 01 Jan 2012 19:28:47 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC References: <4EFC88F5.4070106@gmx.de> <4F006633.1040800@gmx.de> <4tu0g7d98h4st9ejgs32son1tldca2p0l9@hive.bjoern.hoehrmann.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 18:28:55 -0000 On 2012-01-01 19:13, Bjoern Hoehrmann wrote: > * Thomas Roessler wrote: >> I'm not interested in a game of process nomics. > > If you are not interested in discussing whether it was "premature ... to > request publication of this document as an RFC" then don't suggest that > it was? The IETF is currently discussing proper procedures for this kind > of third-party registration in various places like "happiana", you will > excuse that some of us are interested in finding suitable guidelines. > >> Speaking as liaison, I've already pointed you at the appropriate people >> to ask for review. This being an individual, informational draft, I >> think it's fair to expect the submitter to go and secure the appropriate >> review. > > I think it's fair to expect you to keep people in the W3C apprised about > developments in the IETF relevant to their work, and I think it's fair > to dismiss your opinion in this matter given that you don't want to dis- > cuss it. Mykyta Yevstifeyev made a draft, interested parties were made > aware of the draft, and after some weeks with no comments from them, as > far as I am aware, Mykyta Yevstifeyev asked for publication of the draft > as RFC. I don't think there is anything wrong with that. If you disagree > perhaps you can find someone to argue your point on the "happiana" list > so we can give better guidance to our fellow community members. Björn, I'm almost with you. However, changing the actual definition and adding an additional post LC would be kind of surprising, wouldn't it? Best regards, Julian From derhoermi@gmx.net Sun Jan 1 10:31:08 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716E611E8080 for ; Sun, 1 Jan 2012 10:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 wE10wevKohBw for ; Sun, 1 Jan 2012 10:31:08 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 81EB811E8073 for ; Sun, 1 Jan 2012 10:31:07 -0800 (PST) Received: (qmail invoked by alias); 01 Jan 2012 18:31:06 -0000 Received: from dslb-094-223-218-043.pools.arcor-ip.net (EHLO HIVE) [94.223.218.43] by mail.gmx.net (mp070) with SMTP; 01 Jan 2012 19:31:06 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19xQnlf0ahxPkH9I1sqwobgl1IGTvWiS/8cy5p1e4 OX9Tu9FS51UgS1 From: Bjoern Hoehrmann To: Mykyta Yevstifeyev Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC Date: Sun, 01 Jan 2012 19:31:07 +0100 Message-ID: References: <20111209175852.12171.32923.idtracker@ietfa.amsl.com> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 18:31:08 -0000 * Mykyta Yevstifeyev wrote: >I'd like to seek consensus on separating the semantics of link >relation for separate disclosure and a list thereof, correspondingly >defining two link relations - 'disclosure' and 'disclosure-list'. You >may see my edits made to Section 2 of the doc. below, which I'm >proposing: > >2. 'disclosure' Link Relation Type > > Whenever the 'disclosure' relation is defined, the target IRI > [RFC5988] MUST refer to a particular patent disclosure made with > respect to the material being referenced by context IRI. > >3. 'disclosure-list' Link Relation Type > > Whenever the 'disclosure' relation is defined, the target IRI MUST > designate a list of patent disclosures made with respect to the > material being referenced by context IRI. > >As the doc. is in Last Call now, in order not to initiate a new one, >please comment on these changes before January 6, so that I could know >which version I should submit for IESG evaluation. I do not think you should (be able to) make such a change without a new Last Call, and I disagree with the separation. Reasons include that it's unclear which relation you use if you have one disclosure where many patents are disclosed; would that be "disclosure" because it's just one disclosure, or would it be a "disclosure-list" because many patents are disclosed? On the German Wikipedia people are even used to flamewars concerning List articles that have no or just one item, where some ar- gue that you need at least two items to have a list. In this sense you could probably always use 'disclosure-list' in place of 'disclosure' if you think empty and single item lists are meaningful concepts. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From derhoermi@gmx.net Sun Jan 1 10:55:11 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906BB1F0C43 for ; Sun, 1 Jan 2012 10:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, 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 MNGKjzYdWk2A for ; Sun, 1 Jan 2012 10:55:10 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4A2151F0C3B for ; Sun, 1 Jan 2012 10:55:10 -0800 (PST) Received: (qmail invoked by alias); 01 Jan 2012 18:55:08 -0000 Received: from dslb-094-223-218-043.pools.arcor-ip.net (EHLO HIVE) [94.223.218.43] by mail.gmx.net (mp028) with SMTP; 01 Jan 2012 19:55:08 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+y5thPW5yyApIAoDyumqCj1y/yy0PhSw5tpvErXV ScBfB1cRCrOueK From: Bjoern Hoehrmann To: Julian Reschke Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC Date: Sun, 01 Jan 2012 19:55:08 +0100 Message-ID: References: <4F006633.1040800@gmx.de> <4tu0g7d98h4st9ejgs32son1tldca2p0l9@hive.bjoern.hoehrmann.de> <4F00A5DF.3090605@gmx.de> In-Reply-To: <4F00A5DF.3090605@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 18:55:11 -0000 * Julian Reschke wrote: >I'm almost with you. > >However, changing the actual definition and adding an additional post LC >would be kind of surprising, wouldn't it? Among the goals of the Internet Standards Process are "openness" and "fairness" and I would find these principles grossly violated if the IESG would approve the document for publication with the proposed changes applied but without another Last Call. With another Last Call and if there is rough consensus in favour of the changes, and that'd include running code, then that's fine with me, regardless of whether an intention to publish an Internet-Draft as RFC is communicated to some obscure W3C mailing list, or who communicates such an intention. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From john-ietf@jck.com Sun Jan 1 11:22:10 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2007D21F8BB8; Sun, 1 Jan 2012 11:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.627 X-Spam-Level: X-Spam-Status: No, score=-102.627 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 720jriGZcyy4; Sun, 1 Jan 2012 11:22:09 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 15B5521F8BB0; Sun, 1 Jan 2012 11:22:09 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RhQyu-000Bg2-9M; Sun, 01 Jan 2012 14:22:08 -0500 X-Vipre-Scanned: 08650A7A002C3108650BC7-TDI Date: Sun, 01 Jan 2012 14:22:07 -0500 From: John C Klensin To: ietf@ietf.org Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC Message-ID: <75C7A8A2BD7D3D528DF8DF0C@[192.168.1.128]> In-Reply-To: <4F00A5DF.3090605@gmx.de> References: <4EFC88F5.4070106@gmx.de> <4F006633.1040800@gmx.de> <4tu0g7d98h4st9ejgs32son1tldca2p0l9@hive.bjoern.hoehrmann.de> <4F00A5DF.3090605@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 19:22:10 -0000 Hi. While I'm highly sympathetic to Thomas Roessler's position which I interpret as this needing (as a matter of courtesy and cooperation, if nothing else) affirmative signoff from the relevant parties in W3C, I would settle for any clear set of comments from them. But I think this also needs some examination in terms IETF relationships and process independent of the W3C-related issues. It is, IMO, entirely appropriate to publish a specification as Informational when it precisely describes some existing practice for the information of the community. We have a long history of doing that in what is now called the Independent and, when the specification bears some direct relationship to other IETF work, in the IETF stream. But this document, in the -00 version circulated for Last Call, is not such a precise, factual, description: it contains errors or misstatements (examples below) and it contains extensions beyond the existing practice that are not clearly identified and that, as far as I can tell, have not been deployed or tested. While I see no reason why they would not "work", experience is the proper test of whether some particular approach or syntax is adequate. I believe that the IESG ought to take exceptional care with individual submissions, precisely because they are published in the IETF stream, requiring significant expertise or careful reading to determine whether they actually represent informed and competent IETF consensus. Against that test, this document is not ready for approval and RFC publication. Specific examples: (1) The second sentence of the Introduction begins "This document specifies a new type of such relationship...". But this is not "new": it has been around for years, as the next paragraph (and comments on the IETF list) indicate. (2) The last paragraph of the Introduction reads: "This document is to formally register the 'disclosure' Link Relation Type with IANA and provide a permanent record on it for the Internet community. Additionally, it expands the sphere of this relation type to allow its use when referring to separate patent disclosures." So it registers the type (good, IMO); makes a permanent and public record --which the author believes W3C has failed to do (good, IMO); documents the existing practice (also good, IMO); and creates an untested extension (outside the scope of Informational publication of an existing practice, IMO). (3) There is no analysis at all of whether the compound use of this relation identifier (within a
    element) might confuse any existing implementations and, if so, how that confusion would play itself out. For example, we have learned the hard way in other areas that, when multiple instances of the same information-label appear with different values and without that being explicitly provided for in the specification, some implementations will use the first one and ignore the others, others will pick the last one and ignore the others, some will reject the construct entirely, and still others will try to somehow combine the fields. If we know what would happen here, the document doesn't say so. Without such an analysis, the statement of true belief in Security Considerations may be a little bit optimistic. (4) While it is not unusual for Acknowledgments sections to be updated during or after Last Call, an entry of for the only contributors to the document make it impossible for the community to verify that the BCP78 requirements have been followed. I think this document could be cleaned up and made ready for publication by using any of the following three options: (i) Formally ask W3C if the document cited as "[W3C-PUBRULES]" is an appropriate specification of this relation type or if some other document exists or can be constructed within a reasonable (and fixed) period of time. If so, reference it normatively, producing an RFC only if the current state of the Link Relation registry requires that. Forget about extensions except insofar as they come through the process that produced this specification. (ii) Prepare and publish an Informational RFC that strictly describes the existing practice and says so. Publish a separate document, probably as Experimental, that proposes and argues for the extension. (iii) Modify this document to be _extremely_ clear about what is existing practice and what is the author's suggestion about an extension. For the latter, the change being made, the justification for it, and a risk analysis should be present and explicit. If IETF publication as an RFC is anticipated for any of those three options, the inconsistent language should be cleaned up; the Acknowledgments section completed; and evidence that the author, the shepherd, and/or the sponsoring AD were in a bit too much of a hurry to get the document into Last Call as "" in the page headers should be fixed. regards and happy new year to all, john From evnikita2@gmail.com Sun Jan 1 23:19:55 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD4E21F8E84; Sun, 1 Jan 2012 23:19:55 -0800 (PST) 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 fzW+LZuYozVB; Sun, 1 Jan 2012 23:19:54 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B245721F8F0A; Sun, 1 Jan 2012 23:19:54 -0800 (PST) Received: by obcuz6 with SMTP id uz6so13195392obc.31 for ; Sun, 01 Jan 2012 23:19:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3cEMRo8SoGPFgB0vHevBwwI5pXMyZESiO8sui+jVrrc=; b=tZ7NNxtvV6nHBHfwqpl8a9c9eVnnm5N8F1mJDeUw9E6MZvRzLLIrhWfc59fwBqDLx7 kAcxoi1tjOFFrb3iohad1utQWk/s6Bc88+kBrumgKxPq8hUoYTEmkFZCqRUyWGtYs8Wz anXiNjX/Uq/vT+oqd9ZXSl/FKA5aaPGONvoXE= MIME-Version: 1.0 Received: by 10.182.76.134 with SMTP id k6mr32616756obw.10.1325488793927; Sun, 01 Jan 2012 23:19:53 -0800 (PST) Received: by 10.182.30.167 with HTTP; Sun, 1 Jan 2012 23:19:53 -0800 (PST) In-Reply-To: References: <4F006633.1040800@gmx.de> <4tu0g7d98h4st9ejgs32son1tldca2p0l9@hive.bjoern.hoehrmann.de> <4F00A5DF.3090605@gmx.de> Date: Mon, 2 Jan 2012 09:19:53 +0200 Message-ID: Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC From: Mykyta Yevstifeyev To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Julian Reschke , ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 07:19:55 -0000 Thanks to everybody for discussion. I've sent a note to spec-prod list, which you may find at http://lists.w3.org/Archives/Public/spec-prod/2012JanMar/0000.html, and I'll notify you of the responses that I expect to receive before Thursday. Mykyta Yevstifeyev 2012/1/1 Bjoern Hoehrmann : > * Julian Reschke wrote: >>I'm almost with you. >> >>However, changing the actual definition and adding an additional post LC >>would be kind of surprising, wouldn't it? > > Among the goals of the Internet Standards Process are "openness" and > "fairness" and I would find these principles grossly violated if the > IESG would approve the document for publication with the proposed > changes applied but without another Last Call. With another Last Call > and if there is rough consensus in favour of the changes, and that'd > include running code, then that's fine with me, regardless of whether > an intention to publish an Internet-Draft as RFC is communicated to > some obscure W3C mailing list, or who communicates such an intention. > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld= .de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= .de/ > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From evnikita2@gmail.com Sun Jan 1 23:27:32 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88A821F8EC0 for ; Sun, 1 Jan 2012 23:27:32 -0800 (PST) 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 I2bkmfWIx50h for ; Sun, 1 Jan 2012 23:27:32 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2B221F8EBF for ; Sun, 1 Jan 2012 23:27:32 -0800 (PST) Received: by obcuz6 with SMTP id uz6so13198508obc.31 for ; Sun, 01 Jan 2012 23:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ECJvnKxrfMcAZ/3Oh4buyQOGT4NPErH0/net6gjj+dw=; b=gdE2Jvz/vEyPJIHfGCGrNs+36HHaC+sDT+nlDkBfYIJZENTUNUMZNHB7l7wh9XUg+R sB5h2RwHcjKtVMQlytO8w+9N1xuWtoJrGw2ZvVEhX4zcVqiCH8HowfqL93r7ZJagBri8 pzucw4n+tg9X2jWXlGvKdhmxmqLs2zkp7QNfw= MIME-Version: 1.0 Received: by 10.182.160.1 with SMTP id xg1mr41191303obb.30.1325489251851; Sun, 01 Jan 2012 23:27:31 -0800 (PST) Received: by 10.182.30.167 with HTTP; Sun, 1 Jan 2012 23:27:31 -0800 (PST) In-Reply-To: References: <20111209175852.12171.32923.idtracker@ietfa.amsl.com> Date: Mon, 2 Jan 2012 09:27:31 +0200 Message-ID: Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC From: Mykyta Yevstifeyev To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 07:27:33 -0000 2012/1/1 Bjoern Hoehrmann : > * Mykyta Yevstifeyev wrote: >>I'd like to seek consensus on separating the semantics of link >>relation for separate disclosure and a list thereof, correspondingly >>defining two link relations - 'disclosure' and 'disclosure-list'. =A0You >>may see my edits made to Section 2 of the doc. below, which I'm >>proposing: >> >>2. 'disclosure' Link Relation Type >> >> =A0 Whenever the 'disclosure' relation is defined, the target IRI >> =A0 [RFC5988] MUST refer to a particular patent disclosure made with >> =A0 respect to the material being referenced by context IRI. >> >>3. 'disclosure-list' Link Relation Type >> >> =A0 Whenever the 'disclosure' relation is defined, the target IRI MUST >> =A0 designate a list of patent disclosures made with respect to the >> =A0 material being referenced by context IRI. >> >>As the doc. is in Last Call now, in order not to initiate a new one, >>please comment on these changes before January 6, so that I could know >>which version I should submit for IESG evaluation. > > I do not think you should (be able to) make such a change without a new > Last Call, and I disagree with the separation. Reasons include that it's > unclear which relation you use if you have one disclosure where many > patents are disclosed; would that be "disclosure" because it's just one > disclosure, or would it be a "disclosure-list" because many patents are > disclosed? 'disclosure', because the semantics concern the patent disclosure, not the patent. > On the German Wikipedia people are even used to flamewars > concerning List articles that have no or just one item, where some ar- > gue that you need at least two items to have a list. In this sense you > could probably always use 'disclosure-list' in place of 'disclosure' if > you think empty and single item lists are meaningful concepts. A list should be considered to be a list even if it is empty or has one entry, so we can use 'disclosure-list' here. Mykyta Yevstifeyev > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld= .de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= .de/ From evnikita2@gmail.com Sun Jan 1 23:36:53 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EF421F8F04; Sun, 1 Jan 2012 23:36:53 -0800 (PST) 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 AQASAVmhhu4r; Sun, 1 Jan 2012 23:36:52 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 907FA21F8D3D; Sun, 1 Jan 2012 23:36:52 -0800 (PST) Received: by obcuz6 with SMTP id uz6so13204411obc.31 for ; Sun, 01 Jan 2012 23:36:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/yRlLD0Lgy0tjUupPb5zCpSuIRfMgVHc8wn/jW1q0bs=; b=x9aU+f6VQMfLvnd4NyPT0iPHd0JTlTwZvo8HanKjTqi+vQW58/XX4tEfPDtsk13B3q IhuacnbJd/G1efN2AGPAGxHQI8VxdkNfeJgFS5d3Ibht30cCf0r0gB7XfUQvwNFBovkQ lRxXvBP0U7G3LMpn9ll2AYvNApi5n4pY3xB1M= MIME-Version: 1.0 Received: by 10.182.45.102 with SMTP id l6mr41243400obm.0.1325489811085; Sun, 01 Jan 2012 23:36:51 -0800 (PST) Received: by 10.182.30.167 with HTTP; Sun, 1 Jan 2012 23:36:51 -0800 (PST) In-Reply-To: <75C7A8A2BD7D3D528DF8DF0C@192.168.1.128> References: <4EFC88F5.4070106@gmx.de> <4F006633.1040800@gmx.de> <4tu0g7d98h4st9ejgs32son1tldca2p0l9@hive.bjoern.hoehrmann.de> <4F00A5DF.3090605@gmx.de> <75C7A8A2BD7D3D528DF8DF0C@192.168.1.128> Date: Mon, 2 Jan 2012 09:36:51 +0200 Message-ID: Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC From: Mykyta Yevstifeyev To: John C Klensin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 07:36:53 -0000 2012/1/1 John C Klensin : > Hi. > > While I'm highly sympathetic to Thomas Roessler's position which > I interpret as this needing (as a matter of courtesy and > cooperation, if nothing else) affirmative signoff from the > relevant parties in W3C, I would settle for any clear set of > comments from them. > > But I think this also needs some examination in terms IETF > relationships and process independent of the W3C-related issues. > > It is, IMO, entirely appropriate to publish a specification as > Informational when it precisely describes some existing practice > for the information of the community. =A0We have a long history of > doing that in what is now called the Independent and, when the > specification bears some direct relationship to other IETF work, > in the IETF stream. =A0But this document, in the -00 version > circulated for Last Call, is not such a precise, factual, > description: it contains errors or misstatements (examples > below) and it contains extensions beyond the existing practice > that are not clearly identified and that, as far as I can tell, > have not been deployed or tested. =A0 =A0While I see no reason why > they would not "work", experience is the proper test of whether > some particular approach or syntax is adequate. > > I believe that the IESG ought to take exceptional care with > individual submissions, precisely because they are published in > the IETF stream, requiring significant expertise or careful > reading to determine whether they actually represent informed > and competent IETF consensus. =A0Against that test, this document > is not ready for approval and RFC publication. =A0 Specific > examples: > > =A0 =A0 =A0 =A0(1) The second sentence of the Introduction begins "This > =A0 =A0 =A0 =A0document specifies a new type of such relationship...". > =A0 =A0 =A0 =A0But this is not "new": it has been around for years, as > =A0 =A0 =A0 =A0the next paragraph (and comments on the IETF list) > =A0 =A0 =A0 =A0indicate. It's "new" in context of being formally registered. > > =A0 =A0 =A0 =A0(2) The last paragraph of the Introduction reads: "This > =A0 =A0 =A0 =A0document is to formally register the 'disclosure' Link > =A0 =A0 =A0 =A0Relation Type with IANA and provide a permanent record > =A0 =A0 =A0 =A0on it for the Internet community. =A0Additionally, it > =A0 =A0 =A0 =A0expands the sphere of this relation type to allow its > =A0 =A0 =A0 =A0use when referring to separate patent disclosures." =A0So > =A0 =A0 =A0 =A0it registers the type (good, IMO); makes a permanent and > =A0 =A0 =A0 =A0public record --which the author believes W3C has failed > =A0 =A0 =A0 =A0to do (good, IMO); documents the existing practice (also > =A0 =A0 =A0 =A0good, IMO); and creates an untested extension (outside > =A0 =A0 =A0 =A0the scope of Informational publication of an existing > =A0 =A0 =A0 =A0practice, IMO). So do you propose dropping the semantics for separate disclosures and leaving the original W3C's? > > =A0 =A0 =A0 =A0(3) There is no analysis at all of whether the compound > =A0 =A0 =A0 =A0use of this relation identifier (within a
      element) > =A0 =A0 =A0 =A0might confuse any existing implementations and, if so, > =A0 =A0 =A0 =A0how that confusion would play itself out. =A0For example, > =A0 =A0 =A0 =A0we have learned the hard way in other =A0 areas that, when > =A0 =A0 =A0 =A0multiple instances of the same information-label appear > =A0 =A0 =A0 =A0with different values and without that being explicitly > =A0 =A0 =A0 =A0provided for in the specification, some implementations > =A0 =A0 =A0 =A0will use the first one and ignore the others, others > =A0 =A0 =A0 =A0will pick the last one and ignore the others, some will > =A0 =A0 =A0 =A0reject the construct entirely, and still others will try > =A0 =A0 =A0 =A0to somehow combine the fields. =A0If we know what would > =A0 =A0 =A0 =A0happen here, the document doesn't say so. =A0 Without such > =A0 =A0 =A0 =A0an analysis, the statement of true belief in Security > =A0 =A0 =A0 =A0Considerations may be a little bit optimistic. > > =A0 =A0 =A0 =A0(4) While it is not unusual for Acknowledgments sections > =A0 =A0 =A0 =A0to be updated during or after Last Call, an entry of > =A0 =A0 =A0 =A0 for the only contributors to the document make it > =A0 =A0 =A0 =A0impossible for the community to verify that the BCP78 > =A0 =A0 =A0 =A0requirements have been followed. occurred because there were no comments received before LC; but now, I hope, this may be corrected. > > I think this document could be cleaned up and made ready for > publication by using any of the following three options: > > (i) Formally ask W3C if the document cited as "[W3C-PUBRULES]" > is an appropriate specification of this relation type or if some > other document exists or can be constructed within a reasonable > (and fixed) period of time. =A0If so, reference it normatively, > producing an RFC only if the current state of the Link Relation > registry requires that. =A0Forget about extensions except insofar > as they come through the process that produced this > specification. > > (ii) Prepare and publish an Informational RFC that strictly > describes the existing practice and says so. =A0Publish a separate > document, probably as Experimental, that proposes and argues for > the extension. > > (iii) Modify this document to be _extremely_ clear about what is > existing practice and what is the author's suggestion about an > extension. =A0For the latter, the change being made, the > justification for it, and a risk analysis should be present and > explicit. While that was me who proposed the change to semantics, I tend more and more to agree with documenting the existing practice; but let's wait a response from W3C community first to see what's their attitude towards the proposal. Mykyta Yevstifeyev > > If IETF publication as an RFC is anticipated for any of those > three options, the inconsistent language should be cleaned up; > the Acknowledgments section completed; and evidence that the > author, the shepherd, and/or the sponsoring AD were in a bit too > much of a hurry to get the document into Last Call as " Title>" in the page headers should be fixed. > > regards and happy new year to all, > =A0 =A0john > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From cyrus@daboo.name Mon Jan 2 11:43:55 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6387721F849B; Mon, 2 Jan 2012 11:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 mtIsTPEA5uAM; Mon, 2 Jan 2012 11:43:54 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9AE21F8498; Mon, 2 Jan 2012 11:43:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id DE1C51F93F01; Mon, 2 Jan 2012 14:43:52 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGsOODTmPNvg; Mon, 2 Jan 2012 14:43:51 -0500 (EST) Received: from [10.0.1.8] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 35B571F93EF6; Mon, 2 Jan 2012 14:43:51 -0500 (EST) Date: Mon, 02 Jan 2012 14:43:58 -0500 From: Cyrus Daboo To: david.black@emc.com, arnaud.quillaud@oracle.com, gen-art@ietf.org, ietf@ietf.org Subject: Re: Gen-ART review of draft-daboo-webdav-sync-06 Message-ID: <250FD273F8360ED86D73260F@cyrus.local> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC94C9@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC94C9@MX14A.corp.emc.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=5426 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 19:43:55 -0000 Hi David, Thank you for your review. Comments inline: --On December 27, 2011 11:07:49 PM -0500 david.black@emc.com wrote: > [1] -Major- Section 3.5 does not appear to cover the case reporting added > elements on a subsequent synchronization. The problem may be that the > word "changed" as used in Section 3.5.1 is assumed to cover adding an > element - if so, that's not a good assumption, and the addition case > should be explicitly called out in the title and body of Section 3.5.1. The first sentence of 3.5.1 is: A member URL MUST be reported as changed if it has been mapped as a member of the target collection since the request sync-token was generated. The term "mapped" implies creation/addition of a new resource in this case. That may not be obvious to anyone who is not intimately familiar with WebDAV terminology here, so I propose changing that to: A member URL MUST be reported as changed if it has been newly mapped as a member of the target collection since the request sync-token was generated (e.g., when a new resource has been created as a child of the collection). > [2] -Major- The operations to retrieve changed members of a collection > are not atomic wrt the operation that obtains a report on what has > changed; collection changes can occur between retrieving the report and > retrieving the changed elements or while retrieving the changed elements. > For this reason, simply obtaining a change report and then retrieving the > elements that have changed according to the report may not result in a > consistent (e.g., as of a point in time) copy of a collection. I believe > that this absence of atomicity is a WebDAV "feature", as opposed to a > "bug", but I believe that this behavior and what to do about it should be > discussed in the draft. I suggest the following, possibly to the end of > section 3.1 > > i) Add a sentence or two to warn that obtaining a change report and then > retrieving the changed elements may not result in a consistent local > version of the collection if nothing else is done because changes may > have occurred in the interim. > > ii Add a discussion of how to ensure that a local copy of the collection > is consistent. The basic idea is to re-presented the sync token for that > copy to the server after the changed elements have been retrieved; the > local copy is consistent if the server reports that there have been no > changes. Some pseudo-code may help, e.g.: > > GetSyncCollectionReport(in token, out newtoken, out report); > while (ReportHasChangedItems(report) { > GetChangedItems(report) > token = newtoken; > GetSyncCollectionReport(in token, out newtoken, out report); > } > > Actual code should include a counter that counts the number of iterations > of the while loop and exits with an error if the number of iterations > exceeds some limit; that error exit implies that the collection is > (currently) changing too rapidly to obtain a consistent local version. Good point. I agree that this deserves some additional text to clarify this situation. However, I would rather not go into too much detail of how clients "re-sync" in cases like this as there are a bunch of different ways that could happen each of which depends on exactly what the client is trying to do (e.g., in a lot of cases clients will be doing two-way syncs so will need to reconcile server and local changes within the loop you propose above - the details of that are not in scope for this specification). What I propose is the addition of the following paragraph to the end of Section 3.1: Typically, a client will use the synchronization report to retrieve the list of changes, and will follow that with requests to retrieve the content of changed resources. It is possible that additional changes to the collection could occur between the time of the synchronization report and resource content retrieval, which could result in an inconsistent view of the collection. When clients use this method of synchronization, they need to be aware that such additional changes could occur, and track them through normal means (e.g., differences between the ETag values returned in the synchronization report and those returned when actually fetching resource content), conditional requests as described in Section 5, or repeating the synchronization process until no changes are returned. > [3] -Minor- idnits 2.12.12 reports a Downref to RFC 5842. Please > consult your Area Director (Peter Saint-Andre) to determine what to do > about this Downref (it requires attention, but may not require changes to > the draft). Working with IESG on this one. > Nit: I suggest not using the author's own name (cyrusdaboo) in the > examples. Someone may copy the code from the resulting RFC. This has been common practice in most of the other CalDAV/CardDAV RFCs I have worked on and has not been the source of any problems, so I would rather leave this unchanged. If there is an official IETF policy on using "real names" in examples, then I would be happy to change to follow that, but I am not aware of anything like that. > Nit: idnits 2.12.12 reports that draft-ietf-vcarddav-carddav has been > published as RFC 6352; the RFC Editor will correct this if a new version > of the draft is not required for other reasons. Fixed in my working copy. -- Cyrus Daboo From john@jck.com Sun Jan 1 15:13:33 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B6721F8DF2; Sun, 1 Jan 2012 15:13:33 -0800 (PST) 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 zA6j3iX+3b66; Sun, 1 Jan 2012 15:13:33 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id F17F821F8CE1; Sun, 1 Jan 2012 15:13:32 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RhUam-000Dux-GK; Sun, 01 Jan 2012 18:13:28 -0500 X-Vipre-Scanned: 0938D654002C310938D7A1-TDI Date: Sun, 01 Jan 2012 18:13:27 -0500 From: John C Klensin To: Bjoern Hoehrmann , Julian Reschke Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC Message-ID: <13A424AF00755C9AFA871B99@[192.168.1.128]> In-Reply-To: References: <4F006633.1040800@gmx.de> <4tu0g7d98h4st9ejgs32son1tldca2p0l9@hive.bjoern.hoehrmann.de> <4F00A5DF.3090605@gmx.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailman-Approved-At: Tue, 03 Jan 2012 07:19:46 -0800 Cc: ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 23:13:33 -0000 --On Sunday, January 01, 2012 19:55 +0100 Bjoern Hoehrmann wrote: > Among the goals of the Internet Standards Process are > "openness" and "fairness" and I would find these principles > grossly violated if the IESG would approve the document for > publication with the proposed changes applied but without > another Last Call. With another Last Call and if there is > rough consensus in favour of the changes, and that'd include > running code, then that's fine with me, regardless of whether > an intention to publish an Internet-Draft as RFC is > communicated to some obscure W3C mailing list, or who > communicates such an intention. Bj=C3=B6rn, For better or worse, the IETF tries to maintain close working relationships with a number of other SDOs. While there are exceptions, those relationships work best when we are willing to go out of our way to be sure that everyone stays informed and, in particular, that we don't appropriate their standards or conventions and start making changes to them... and when they reciprocate. =20 While different ADs handle it differently, we have also traditionally made the assumption that authors requesting individual submission publication have to take most of the responsibility for making sure all of the ducks are lined up. They cannot, for example, rely on a WG to do that (since there isn't one) nor on IETF Last Call to spot everything that they, who are presumably expert enough to have constructed the document in the first place, should have spotted. That said, I basically agree with what you have written above, tempered by the understanding that I think it is in the IETF's best interest (as well as just plain polite) to go to W3C and say, repeatedly if necessary, "do you really, really, not have anything to say about this?" We certainly expect the same from other SDOs we work with and W3C has give us that courtesy on some occasions when we have been slow to respond. john From pthubert@cisco.com Mon Jan 2 08:43:31 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451E111E80A5 for ; Mon, 2 Jan 2012 08:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.286 X-Spam-Level: X-Spam-Status: No, score=-10.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, 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 8JIJ2zHjAZN0 for ; Mon, 2 Jan 2012 08:43:30 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id BBFD011E80A3 for ; Mon, 2 Jan 2012 08:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4861; q=dns/txt; s=iport; t=1325522609; x=1326732209; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=M3UJ1+7U3n1AxZmagQex7mcIZ0LgOqB6/S+UcuvJhmU=; b=iWsBr3sVyLbLsxnRjTVJznADk9BSiJOdXIS33cyzueHGEUHCTKCbUzUo /Xa1ftlQ3WhlPHtO+4B0uPhEuwOuScVSKMBv+EHSrkv+1vfXziQPXYrfg c8I5OZsZ0Oc308iHRRmKuxVtpigS/z14ScnReCvoXx+K4ws3e2KXYGF67 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIzAJbdAU+Q/khM/2dsb2JhbABEggWqU4EFgXIBAQEEAQEBDwEdPhcEAgEIEQQBAQsGEwQBBgEmAR4JCAEBBBMIGodgllkBnUGCVYhXYwSIBIpZlFo X-IronPort-AV: E=Sophos;i="4.71,445,1320624000"; d="scan'208";a="125220779" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 02 Jan 2012 16:43:25 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q02GhPJP019957 for ; Mon, 2 Jan 2012 16:43:25 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Jan 2012 17:43:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Last Call: (Neighbor DiscoveryOptimization for Low Power and Lossy Networks (6LoWPAN)) toProposed Standard Date: Mon, 2 Jan 2012 17:42:16 +0100 Message-ID: In-Reply-To: <20111216210133.32142.90446.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: (Neighbor DiscoveryOptimization for Low Power and Lossy Networks (6LoWPAN)) toProposed Standard Thread-Index: Acy8NfTj6aG0kyxhTh6HoPqL4UrQoANMg8kA References: <20111216210133.32142.90446.idtracker@ietfa.amsl.com> From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 02 Jan 2012 16:43:25.0783 (UTC) FILETIME=[A5D6AE70:01CCC96D] X-Mailman-Approved-At: Tue, 03 Jan 2012 07:19:46 -0800 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 16:43:31 -0000 Hi: I posted support for this draft to the WG mailing list. At the same = time, I regretted the lack of a sequence counter in the registration = mechanism. Ralph suggested that I share my concerns in this step of the = review process. The sequence counter existed in earlier versions of the draft and was = called a TID (see = http://tools.ietf.org/html/draft-ietf-6lowpan-nd-08#page-18). Similar = sequence counters exist in other registration mechanisms such as MIPv6.=20 The sequence counter is useful for: 1) anti-replay 2) correlation of requests and responses in case messages cross (e.g. in = mesh under) 3) mobility support (when radio conditions change, a device might need = to select an alternate router) Items 1 and 2 were not enough to convince the authors to keep the TID, = and item 3 is somewhat an external to the specification. Yet, item 3 is = the one I'm most concerned with, because it is required in order to = inject the registration in a routing protocol such as RPL, or over a = backbone in an ND proxy operation as was supported in earlier versions = of the draft (till 8). In the case of RPL, the path sequence in the transit option is used to = determine which path is stale after a movement as described in = http://tools.ietf.org/html/draft-ietf-roll-rpl-19#section-9.2.1 . The = TID would be trivially mapped into that path sequence but cannot be = regenerated by the attachment router should the device move. IOW, = without a TID, a device must be hardwired to its router for RPL to = operate properly. RPL is very explicit about that limitation in section = 7.1: " If a host does not pass a counter to its router, then the router is = in charge of computing the Path Sequence on behalf of the host and the = host can only register to one router for that purpose. " In the case of the backbone router that is now discussed separately from = ND in = http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-02, we = want a transparent mobility for the constrained device, so we need a = mechanism to determine the freshest of conflicting registrations. The = backbone routers would use the TID to figure which registration is = freshest and determine which router should proxy over the backbone.=20 In any case, it appears that though the ND mechanism could probably live = without a sequence counter in most cases, a sequence counter is quite = critical for the global integration of the protocol in a multi-hop radio = infrastructure. What do you think? Pascal -----Original Message----- From: ietf-announce-bounces@ietf.org = [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: vendredi 16 d=E9cembre 2011 22:02 To: IETF-Announce Cc: 6lowpan@lists.ietf.org Subject: Last Call: (Neighbor = DiscoveryOptimization for Low Power and Lossy Networks (6LoWPAN)) = toProposed Standard The IESG has received a request from the IPv6 over Low power WPAN WG (6lowpan) to consider the following document: - 'Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits = final comments on this action. Please send substantive comments to the = ietf@ietf.org mailing lists by 2012-01-04. Exceptionally, comments may = be sent to iesg@ietf.org instead. In either case, please retain the = beginning of the Subject line to allow automated sorting. Abstract The IETF 6LoWPAN working group defines IPv6 over Low-power Wireless Personal Area Networks such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non-transitive wireless links. The traditional IPv6 link concept and heavy use of multicast make the protocol inefficient and sometimes impractical in a low power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, addressing mechanisms and duplicate address detection for 6LoWPAN and similar networks. The document, thus updates RFC 4944 to specify the use of the optimizations defined here. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6lowpan-nd/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6lowpan-nd/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From david.black@emc.com Mon Jan 2 11:55:58 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320AF11E80C6; Mon, 2 Jan 2012 11:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 AzQ4g31VB77R; Mon, 2 Jan 2012 11:55:57 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4D60E11E80B9; Mon, 2 Jan 2012 11:55:57 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q02JtlZm018667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jan 2012 14:55:47 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 2 Jan 2012 14:55:36 -0500 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q02JtZkF021140; Mon, 2 Jan 2012 14:55:35 -0500 Received: from mx14a.corp.emc.com ([169.254.1.216]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Mon, 2 Jan 2012 14:55:35 -0500 From: To: , , , Date: Mon, 2 Jan 2012 14:55:34 -0500 Subject: RE: Gen-ART review of draft-daboo-webdav-sync-06 Thread-Topic: Gen-ART review of draft-daboo-webdav-sync-06 Thread-Index: AczJhuX3bpwOzRy0QUCSyWq/599zNQAAKF4Q Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B9F@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC94C9@MX14A.corp.emc.com> <250FD273F8360ED86D73260F@cyrus.local> In-Reply-To: <250FD273F8360ED86D73260F@cyrus.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Tue, 03 Jan 2012 07:19:46 -0800 Cc: david.black@emc.com X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 19:55:58 -0000 Hi Cyrus, The proposed changes for the two major issues look good to me: [1] I'm pleased that the concern about adding elements turned out to be a w= ording issue. [2] Your proposed new text is fine - it provides adequate notice/warning ab= out possible collection inconsistency, so I'm ok with not providing pseudo-code. I'll leave the Downref issue ([3]) for you and Peter to work out with the I= ESG, and I'm fine with continued use of your name in the examples if that's common pract= ice. Thanks, --David > -----Original Message----- > From: Cyrus Daboo [mailto:cyrus@daboo.name] > Sent: Monday, January 02, 2012 2:44 PM > To: Black, David; arnaud.quillaud@oracle.com; gen-art@ietf.org; ietf@ietf= .org > Cc: stpeter@stpeter.im > Subject: Re: Gen-ART review of draft-daboo-webdav-sync-06 >=20 > Hi David, > Thank you for your review. Comments inline: >=20 > --On December 27, 2011 11:07:49 PM -0500 david.black@emc.com wrote: >=20 > > [1] -Major- Section 3.5 does not appear to cover the case reporting add= ed > > elements on a subsequent synchronization. The problem may be that the > > word "changed" as used in Section 3.5.1 is assumed to cover adding an > > element - if so, that's not a good assumption, and the addition case > > should be explicitly called out in the title and body of Section 3.5.1. >=20 > The first sentence of 3.5.1 is: >=20 > A member URL MUST be reported as changed if it has been mapped as a > member of the target collection since the request sync-token was > generated. >=20 > The term "mapped" implies creation/addition of a new resource in this cas= e. > That may not be obvious to anyone who is not intimately familiar with > WebDAV terminology here, so I propose changing that to: >=20 > A member URL MUST be reported as changed if it has been newly mapped = as > a member of the target collection since the request sync-token was > generated (e.g., when a new resource has been created as a child of t= he > collection). >=20 > > [2] -Major- The operations to retrieve changed members of a collection > > are not atomic wrt the operation that obtains a report on what has > > changed; collection changes can occur between retrieving the report and > > retrieving the changed elements or while retrieving the changed element= s. > > For this reason, simply obtaining a change report and then retrieving t= he > > elements that have changed according to the report may not result in a > > consistent (e.g., as of a point in time) copy of a collection. I belie= ve > > that this absence of atomicity is a WebDAV "feature", as opposed to a > > "bug", but I believe that this behavior and what to do about it should = be > > discussed in the draft. I suggest the following, possibly to the end o= f > > section 3.1 > > > > i) Add a sentence or two to warn that obtaining a change report and the= n > > retrieving the changed elements may not result in a consistent local > > version of the collection if nothing else is done because changes may > > have occurred in the interim. > > > > ii Add a discussion of how to ensure that a local copy of the collectio= n > > is consistent. The basic idea is to re-presented the sync token for tha= t > > copy to the server after the changed elements have been retrieved; the > > local copy is consistent if the server reports that there have been no > > changes. Some pseudo-code may help, e.g.: > > > > GetSyncCollectionReport(in token, out newtoken, out report); > > while (ReportHasChangedItems(report) { > > GetChangedItems(report) > > token =3D newtoken; > > GetSyncCollectionReport(in token, out newtoken, out report); > > } > > > > Actual code should include a counter that counts the number of iteratio= ns > > of the while loop and exits with an error if the number of iterations > > exceeds some limit; that error exit implies that the collection is > > (currently) changing too rapidly to obtain a consistent local version. >=20 > Good point. I agree that this deserves some additional text to clarify th= is > situation. However, I would rather not go into too much detail of how > clients "re-sync" in cases like this as there are a bunch of different wa= ys > that could happen each of which depends on exactly what the client is > trying to do (e.g., in a lot of cases clients will be doing two-way syncs > so will need to reconcile server and local changes within the loop you > propose above - the details of that are not in scope for this > specification). What I propose is the addition of the following paragraph > to the end of Section 3.1: >=20 > Typically, a client will use the synchronization report to retrieve t= he > list of changes, and will follow that with requests to retrieve the > content of changed resources. It is possible that additional changes = to > the collection could occur between the time of the synchronization > report and resource content retrieval, which could result in an > inconsistent view of the collection. When clients use this method of > synchronization, they need to be aware that such additional changes > could occur, and track them through normal means (e.g., differences > between the ETag values returned in the synchronization report and > those returned when actually fetching resource content), conditional > requests as described in Section 5, or repeating the synchronization > process until no changes are returned. >=20 > > [3] -Minor- idnits 2.12.12 reports a Downref to RFC 5842. Please > > consult your Area Director (Peter Saint-Andre) to determine what to do > > about this Downref (it requires attention, but may not require changes = to > > the draft). >=20 > Working with IESG on this one. >=20 > > Nit: I suggest not using the author's own name (cyrusdaboo) in the > > examples. Someone may copy the code from the resulting RFC. >=20 > This has been common practice in most of the other CalDAV/CardDAV RFCs I > have worked on and has not been the source of any problems, so I would > rather leave this unchanged. If there is an official IETF policy on using > "real names" in examples, then I would be happy to change to follow that, > but I am not aware of anything like that. >=20 > > Nit: idnits 2.12.12 reports that draft-ietf-vcarddav-carddav has been > > published as RFC 6352; the RFC Editor will correct this if a new versio= n > > of the draft is not required for other reasons. >=20 > Fixed in my working copy. >=20 >=20 > -- > Cyrus Daboo >=20 From wesley.george@twcable.com Tue Jan 3 08:52:17 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9019121F84D9; Tue, 3 Jan 2012 08:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.937 X-Spam-Level: X-Spam-Status: No, score=0.937 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 yRI9EkxtsmeC; Tue, 3 Jan 2012 08:52:17 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id DA13E21F84D4; Tue, 3 Jan 2012 08:52:16 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.71,449,1320642000"; d="scan'208";a="302906118" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 03 Jan 2012 11:51:05 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Tue, 3 Jan 2012 11:52:16 -0500 From: "George, Wes" To: "ietf@ietf.org" Date: Tue, 3 Jan 2012 11:52:15 -0500 Subject: primary Paris hotel booking Thread-Topic: primary Paris hotel booking Thread-Index: AczKOAu3q17U65cKTlyCnZAsRQ6uPg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IAOC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 16:52:17 -0000 Happy New Year, it's time for our triannual hotel complaint thread. I hate to do it, but I think that there are people who haven't looked at th= is yet, and I'm hoping that we can perhaps rectify it before the majority o= f folks try to book: "Instructions for making reservations at Hotel Concorde: Please fill out the reservations form and fax it directly to the hotel at: = +33 1 57 00 50 79 or email it to cmasson@concorde-hotels.com" It's 2012, but the IETF and this hotel chain expects us to book reservation= s at the main conference hotel by (international) FAX or by *emailing* a fo= rm which includes a credit card number so that the hotel can hold the room = and implement its relatively bizarre prepay/anti-cancellation policy. Would it be trolling to ask whether anyone verified that "cmasson" has supp= ort for PGP encrypted-email and a proper method of securely storing (and th= en destroying after use) the several hundred credit card numbers they are a= bout to receive? What person or rate code should we ask for when booking our rooms over the = phone? (hey if I'm going old school, I'm doing it all the way!) Though, giv= en the above, I'm relatively worried that my credit card number will simply= end up on an unprotected spreadsheet on a PC somewhere in their office eve= n if I call to book. More practically, the hotel blocks at the primary hotel typically fill up q= uite fast once registration is opened, especially since the overflow hotel = is actually more expensive than the primary. Does the hotel fax/call us bac= k to tell us that they have no more rooms available for our requested dates= , or is the block open-ended such that they will keep selling rooms in it u= ntil the cutoff regardless of the number? Evidently "ability to book group rate rooms online" is something that shoul= d be added to our list of hotel requirements. I'm stunned that it's not the= re already. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From tnadeau@lucidvision.com Tue Jan 3 10:57:27 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EFB5E8012; Tue, 3 Jan 2012 10:57:27 -0800 (PST) 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 NhjgJogIygkY; Tue, 3 Jan 2012 10:57:27 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3819E5E8011; Tue, 3 Jan 2012 10:57:27 -0800 (PST) Received: from [10.100.68.169] (unknown [141.202.11.155]) by lucidvision.com (Postfix) with ESMTP id 6797A203A0AE; Tue, 3 Jan 2012 13:57:26 -0500 (EST) Subject: Re: primary Paris hotel booking Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Thomas Nadeau In-Reply-To: Date: Tue, 3 Jan 2012 13:57:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <34EF3F99-10DE-4B6B-92A7-2DD255412A0C@lucidvision.com> References: To: "George, Wes" X-Mailer: Apple Mail (2.1251.1) Cc: IAOC , "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 18:57:28 -0000 I agree. In addition to that the pre-pay situation can be a = major PITA for expensing purposes. We should add "normal" booking = procedures to the hotel requirements list as well. --Tom On Jan 3, 2012, at 11:52 AM, George, Wes wrote: > Happy New Year, it's time for our triannual hotel complaint thread. > I hate to do it, but I think that there are people who haven't looked = at this yet, and I'm hoping that we can perhaps rectify it before the = majority of folks try to book: >=20 > "Instructions for making reservations at Hotel Concorde: > Please fill out the reservations form and fax it directly to the hotel = at: +33 1 57 00 50 79 or email it to cmasson@concorde-hotels.com" >=20 > It's 2012, but the IETF and this hotel chain expects us to book = reservations at the main conference hotel by (international) FAX or by = *emailing* a form which includes a credit card number so that the hotel = can hold the room and implement its relatively bizarre = prepay/anti-cancellation policy. > Would it be trolling to ask whether anyone verified that "cmasson" has = support for PGP encrypted-email and a proper method of securely storing = (and then destroying after use) the several hundred credit card numbers = they are about to receive? >=20 > What person or rate code should we ask for when booking our rooms over = the phone? (hey if I'm going old school, I'm doing it all the way!) = Though, given the above, I'm relatively worried that my credit card = number will simply end up on an unprotected spreadsheet on a PC = somewhere in their office even if I call to book. >=20 > More practically, the hotel blocks at the primary hotel typically fill = up quite fast once registration is opened, especially since the overflow = hotel is actually more expensive than the primary. Does the hotel = fax/call us back to tell us that they have no more rooms available for = our requested dates, or is the block open-ended such that they will keep = selling rooms in it until the cutoff regardless of the number? >=20 > Evidently "ability to book group rate rooms online" is something that = should be added to our list of hotel requirements. I'm stunned that it's = not there already. >=20 > Wes George >=20 >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From eosborne@cisco.com Tue Jan 3 11:02:38 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7981C5E8036; Tue, 3 Jan 2012 11:02:38 -0800 (PST) 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 G99ftUOu1VR9; Tue, 3 Jan 2012 11:02:38 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DA9FC5E8034; Tue, 3 Jan 2012 11:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eosborne@cisco.com; l=202; q=dns/txt; s=iport; t=1325617358; x=1326826958; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=4+xNSI8angl7qu1ZHX6cYf2YqZv/MDBupj72bklMef4=; b=PDPzMJjf8jKcoCWT4XiKYbmOjWDbBH3hjzXXSXWybVACgmLs7m24odRV Odjr9cHSCMjUlw6FmdDJiwEcXXuMb6h0uOm+qDdYM4kIP1x2uAjzvoMUz gMT3N71Suub/JOwqPLrDXBQlKPU+np7SJW6/aOaLsqFe+YrC+AzkEvQzp k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQIAB9QA0+tJV2b/2dsb2JhbABDggWqW4EFgXIBAQEDARIBHQo/BQsCAQgiBhgGAVYBAQQBGhqHWJdbAY0ekFyLLGMEiDefHg X-IronPort-AV: E=Sophos;i="4.71,451,1320624000"; d="scan'208";a="48371310" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 03 Jan 2012 19:02:37 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q03J2bJe004456; Tue, 3 Jan 2012 19:02:37 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jan 2012 13:02:37 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: primary Paris hotel booking Date: Tue, 3 Jan 2012 13:02:36 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: primary Paris hotel booking Thread-Index: AczKOAu3q17U65cKTlyCnZAsRQ6uPgAEgyQg References: From: "Eric Osborne (eosborne)" To: "George, Wes" , X-OriginalArrivalTime: 03 Jan 2012 19:02:37.0402 (UTC) FILETIME=[42345BA0:01CCCA4A] Cc: IAOC X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:02:38 -0000 > What person or rate code should we ask for when booking our rooms over > the phone? (hey if I'm going old school, I'm doing it all the way!) The pdf has a reference number on it. eric From john-ietf@jck.com Tue Jan 3 11:47:10 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339EC11E8095; Tue, 3 Jan 2012 11:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.88 X-Spam-Level: X-Spam-Status: No, score=-101.88 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_05=-1.11, 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 mTuLoJTa+rCS; Tue, 3 Jan 2012 11:47:09 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 8D51821F8498; Tue, 3 Jan 2012 11:47:09 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RiAKA-000JES-5D; Tue, 03 Jan 2012 14:47:06 -0500 Date: Tue, 03 Jan 2012 14:47:05 -0500 From: John C Klensin To: Thomas Nadeau , "George, Wes" Subject: Re: primary Paris hotel booking Message-ID: <724966C28B9125CC9920D631@PST.JCK.COM> In-Reply-To: <34EF3F99-10DE-4B6B-92A7-2DD255412A0C@lucidvision.com> References: <34EF3F99-10DE-4B6B-92A7-2DD255412A0C@lucidvision.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: IAOC , ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:47:10 -0000 --On Tuesday, January 03, 2012 13:57 -0500 Thomas Nadeau wrote: >... > I agree. In addition to that the pre-pay situation can be a > major PITA for expensing purposes. We should add "normal" > booking procedures to the hotel requirements list as well. It is a little worse than "merely" a PITA. I've worked for companies who would absolutely forbid making a reservation with a non-refundable deposit more than two months in advance of a meeting unless I was personally willing to assume the risk... and who might treat such a one-day fee as non-reimbursable even if I did stay in the hotel. The good news about Paris is that there is a large supply of hotels in a wide range of qualities and prices and the subway system is comprehensible and works very well. I sort of hate to suggest this, but, if the conditions and/or rates for the IETF-designated hotels don't seem reasonable, go elsewhere (just remember that no one will listen if you don't like the hotel Internet service). One might even speculate that, if a sufficiently large number of people refused to accept the Hotel Concorde's terms and conditions (booking policies, cancellation policies, or something else) and "voted" by refusing to book there, the IAOC might get the message far more clearly than any number of requests or complaints about what they should negotiate. john From mstjohns@comcast.net Tue Jan 3 11:48:27 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAF411E8095 for ; Tue, 3 Jan 2012 11:48:27 -0800 (PST) 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 5GHkPqWQzFx0 for ; Tue, 3 Jan 2012 11:48:26 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 69AEA21F84AD for ; Tue, 3 Jan 2012 11:48:26 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta15.westchester.pa.mail.comcast.net with comcast id H6JZ1i00327AodY5F7oS0L; Tue, 03 Jan 2012 19:48:26 +0000 Received: from Mike-PC3.comcast.net ([68.83.222.237]) by omta19.westchester.pa.mail.comcast.net with comcast id H7oS1i00C57vnMg3f7oSQr; Tue, 03 Jan 2012 19:48:26 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 03 Jan 2012 14:48:25 -0500 To: Thomas Nadeau , "George, Wes" From: Michael StJohns Subject: Re: primary Paris hotel booking In-Reply-To: <34EF3F99-10DE-4B6B-92A7-2DD255412A0C@lucidvision.com> References: <34EF3F99-10DE-4B6B-92A7-2DD255412A0C@lucidvision.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20120103194826.69AEA21F84AD@ietfa.amsl.com> Cc: IAOC , "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:48:27 -0000 The pre-pay is pretty annoying. And the "if you cancel too late, we'll take all your money" *really* annoys me. So much so that I booked on-line, direct with the hotel at a higher rate for a nicer room, but still better than the rate for the alternate hotel. And no-prepay and cancel by 4pm the arrival day or pay one day's room. I hate doing it this way - the IETF doesn't get any credit for rooms sold. Mike At 01:57 PM 1/3/2012, Thomas Nadeau wrote: > I agree. In addition to that the pre-pay situation can be a major PITA for expensing purposes. We should add "normal" booking procedures to the hotel requirements list as well. > > --Tom > > >On Jan 3, 2012, at 11:52 AM, George, Wes wrote: > >> Happy New Year, it's time for our triannual hotel complaint thread. >> I hate to do it, but I think that there are people who haven't looked at this yet, and I'm hoping that we can perhaps rectify it before the majority of folks try to book: >> >> "Instructions for making reservations at Hotel Concorde: >> Please fill out the reservations form and fax it directly to the hotel at: +33 1 57 00 50 79 or email it to cmasson@concorde-hotels.com" >> >> It's 2012, but the IETF and this hotel chain expects us to book reservations at the main conference hotel by (international) FAX or by *emailing* a form which includes a credit card number so that the hotel can hold the room and implement its relatively bizarre prepay/anti-cancellation policy. >> Would it be trolling to ask whether anyone verified that "cmasson" has support for PGP encrypted-email and a proper method of securely storing (and then destroying after use) the several hundred credit card numbers they are about to receive? >> >> What person or rate code should we ask for when booking our rooms over the phone? (hey if I'm going old school, I'm doing it all the way!) Though, given the above, I'm relatively worried that my credit card number will simply end up on an unprotected spreadsheet on a PC somewhere in their office even if I call to book. >> >> More practically, the hotel blocks at the primary hotel typically fill up quite fast once registration is opened, especially since the overflow hotel is actually more expensive than the primary. Does the hotel fax/call us back to tell us that they have no more rooms available for our requested dates, or is the block open-ended such that they will keep selling rooms in it until the cutoff regardless of the number? >> >> Evidently "ability to book group rate rooms online" is something that should be added to our list of hotel requirements. I'm stunned that it's not there already. >> >> Wes George >> >> >> >> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf From adrian@olddog.co.uk Tue Jan 3 12:12:15 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CF121F856B; Tue, 3 Jan 2012 12:12:15 -0800 (PST) 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 Gn02S9hnq-m3; Tue, 3 Jan 2012 12:12:14 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 5287C21F853E; Tue, 3 Jan 2012 12:12:14 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q03KCCFA026089; Tue, 3 Jan 2012 20:12:12 GMT Received: from 950129200 (201.88.202.62.cust.bluewin.ch [62.202.88.201]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id q03KC8I2026078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jan 2012 20:12:10 GMT From: "Adrian Farrel" To: "'John C Klensin'" References: <34EF3F99-10DE-4B6B-92A7-2DD255412A0C@lucidvision.com> <724966C28B9125CC9920D631@PST.JCK.COM> In-Reply-To: <724966C28B9125CC9920D631@PST.JCK.COM> Subject: RE: primary Paris hotel booking Date: Tue, 3 Jan 2012 20:12:09 -0000 Message-ID: <018f01ccca53$fb5d3df0$f217b9d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJP9A1HyVNXqS+2m5AzwgrItcMFIwFjph06Ad0XZouU2rmXQA== Content-Language: en-gb Cc: 'IAOC' , ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:12:15 -0000 > One might even speculate that, if a > sufficiently large number of people refused to accept the Hotel > Concorde's terms and conditions (booking policies, cancellation > policies, or something else) and "voted" by refusing to book > there, the IAOC might get the message far more clearly than any > number of requests or complaints about what they should > negotiate. Much though it pains me to agree with John so early in the year and risk the precedent... +1 From eburger@standardstrack.com Tue Jan 3 12:54:26 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B03611E811C for ; Tue, 3 Jan 2012 12:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 7QI1GukXjudw for ; Tue, 3 Jan 2012 12:54:25 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 90B1811E811B for ; Tue, 3 Jan 2012 12:54:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=fYWkP0Z+zYrsmWtsotDXs6+8gLeMEhrhIFNeMi/0jzz1D9CuRA9mhRGXluzQGWjVWKe5s1+TyBAV/ni+IOjqZZzg9ECkcJRiid4ll2b0UJ/eUt9zdamkBxKzytGJYMpq; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:62949 helo=[192.168.15.184]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RiBNF-0002Fz-NV for ietf@ietf.org; Tue, 03 Jan 2012 12:54:22 -0800 From: Eric Burger Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-21--575489828; protocol="application/pkcs7-signature"; micalg=sha1 Subject: Re: primary Paris hotel booking Date: Tue, 3 Jan 2012 15:54:20 -0500 In-Reply-To: <20120103194826.69AEA21F84AD@ietfa.amsl.com> To: IETF Discussion References: <34EF3F99-10DE-4B6B-92A7-2DD255412A0C@lucidvision.com> <20120103194826.69AEA21F84AD@ietfa.amsl.com> Message-Id: <0A4FD46C-F43E-46A7-BA1D-B7684632DED8@standardstrack.com> X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:54:26 -0000 --Apple-Mail-21--575489828 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Actually (shhhh), the IETF *does* get credit for rooms sold. We = reconcile the attendee list with hotel guests. Go for it. On Jan 3, 2012, at 2:48 PM, Michael StJohns wrote: > The pre-pay is pretty annoying. And the "if you cancel too late, = we'll take all your money" *really* annoys me. So much so that I booked = on-line, direct with the hotel at a higher rate for a nicer room, but = still better than the rate for the alternate hotel. And no-prepay and = cancel by 4pm the arrival day or pay one day's room. >=20 > I hate doing it this way - the IETF doesn't get any credit for rooms = sold. >=20 > Mike >=20 >=20 >=20 > At 01:57 PM 1/3/2012, Thomas Nadeau wrote: >=20 >> I agree. In addition to that the pre-pay situation can be a = major PITA for expensing purposes. We should add "normal" booking = procedures to the hotel requirements list as well. >>=20 >> --Tom >>=20 >>=20 >> On Jan 3, 2012, at 11:52 AM, George, Wes wrote: >>=20 >>> Happy New Year, it's time for our triannual hotel complaint thread. >>> I hate to do it, but I think that there are people who haven't = looked at this yet, and I'm hoping that we can perhaps rectify it before = the majority of folks try to book: >>>=20 >>> "Instructions for making reservations at Hotel Concorde: >>> Please fill out the reservations form and fax it directly to the = hotel at: +33 1 57 00 50 79 or email it to cmasson@concorde-hotels.com" >>>=20 >>> It's 2012, but the IETF and this hotel chain expects us to book = reservations at the main conference hotel by (international) FAX or by = *emailing* a form which includes a credit card number so that the hotel = can hold the room and implement its relatively bizarre = prepay/anti-cancellation policy. >>> Would it be trolling to ask whether anyone verified that "cmasson" = has support for PGP encrypted-email and a proper method of securely = storing (and then destroying after use) the several hundred credit card = numbers they are about to receive? >>>=20 >>> What person or rate code should we ask for when booking our rooms = over the phone? (hey if I'm going old school, I'm doing it all the way!) = Though, given the above, I'm relatively worried that my credit card = number will simply end up on an unprotected spreadsheet on a PC = somewhere in their office even if I call to book. >>>=20 >>> More practically, the hotel blocks at the primary hotel typically = fill up quite fast once registration is opened, especially since the = overflow hotel is actually more expensive than the primary. Does the = hotel fax/call us back to tell us that they have no more rooms available = for our requested dates, or is the block open-ended such that they will = keep selling rooms in it until the cutoff regardless of the number? >>>=20 >>> Evidently "ability to book group rate rooms online" is something = that should be added to our list of hotel requirements. I'm stunned that = it's not there already. >>>=20 >>> Wes George >>>=20 >>>=20 >>>=20 >>> This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>>=20 >>=20 >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --Apple-Mail-21--575489828 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ 9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX 56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0 FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0 okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwMTAzMjA1NDIxWjAjBgkqhkiG9w0BCQQxFgQU 2wu6s4oVXZSXovfcJePnqdN2CoUwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw DQYJKoZIhvcNAQEBBQAEggEAWg2hb/qYv1ZotObp02IyogPij94bsrgg234goyBfTwhll/8GWWYP adPuVnuliGBLU2DLRWjEjTfSkklysbimBKm8C1Tyrc70u52Owz8McOfOHPJbZ+42woEtwFAWauhY xRsQQznrC/geaHgDmQFwHukIbsfEkSGEV2Sem/cK+oeJzqZcOGl0Y4AOKQ/R+Amx+6J+IDKibuCv HQCoiEBGpcoZxVNnz+0DKb354JFX6/Tkv7wLZEW1Sl4eHscMATQ5EK+GzR6UvQHyobKYIjiUHmLH fjwpeRJtpSZDXLlQD0FBmb2tJyzdXFlKViamm5UJDmd8m3J7nQJSjfLkMS5+dQAAAAAAAA== --Apple-Mail-21--575489828-- From andy@netconfcentral.org Tue Jan 3 13:01:13 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF1F11E8129 for ; Tue, 3 Jan 2012 13:01:13 -0800 (PST) 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 lPa11Vxgwgh5 for ; Tue, 3 Jan 2012 13:01:13 -0800 (PST) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id B985311E8128 for ; Tue, 3 Jan 2012 13:01:12 -0800 (PST) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q03L1AMR018796 for ; Tue, 3 Jan 2012 16:01:12 -0500 Authentication-Results: cm-omr14 smtp.user=andy@andybierman.com; auth=pass (PLAIN) X-Authenticated-UID: andy@andybierman.com Received: from [75.84.164.152] ([75.84.164.152:43443] helo=[192.168.0.126]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id CD/42-28108-59C630F4; Tue, 03 Jan 2012 16:01:10 -0500 Message-ID: <4F036C93.9090806@netconfcentral.org> Date: Tue, 03 Jan 2012 13:01:07 -0800 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: "George, Wes" Subject: Re: primary Paris hotel booking References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 21:01:14 -0000 On 01/03/2012 08:52 AM, George, Wes wrote: > Happy New Year, it's time for our triannual hotel complaint thread. > I hate to do it, but I think that there are people who haven't looked at this yet, and I'm hoping that we can perhaps rectify it before the majority of folks try to book: > > "Instructions for making reservations at Hotel Concorde: > Please fill out the reservations form and fax it directly to the hotel at: +33 1 57 00 50 79 or email it to cmasson@concorde-hotels.com" I crossed my fingers and clicked 'send' of the PDF with my credit card number in it. I didn't pay enough attention to the no-refund policy. :-( I emailed my reservation on 12/22 and got a confirmation email on 12/26. So far, my credit card has not been charged anything. I think there should always be a full-refund cut-off date for the IETF hotel, even if it is 2 months in advance. I thought the cut-off was 15 days, but that is just for 2 more nights billed in advance, not the first night. Andy From john-ietf@jck.com Tue Jan 3 13:03:56 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC0A11E8127 for ; Tue, 3 Jan 2012 13:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 NzownUiqRH1n for ; Tue, 3 Jan 2012 13:03:55 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 8970611E80AA for ; Tue, 3 Jan 2012 13:03:55 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RiBWU-000K44-U3; Tue, 03 Jan 2012 16:03:55 -0500 Date: Tue, 03 Jan 2012 16:03:54 -0500 From: John C Klensin To: Eric Burger , IETF Discussion Subject: Re: primary Paris hotel booking Message-ID: In-Reply-To: <0A4FD46C-F43E-46A7-BA1D-B7684632DED8@standardstrack.com> References: <34EF3F99-10DE-4B6B-92A7-2DD255412A0C@lucidvision.com> <20120103194826.69AEA21F84AD@ietfa.amsl.com> <0A4FD46C-F43E-46A7-BA1D-B7684632DED8@standardstrack.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 21:03:56 -0000 --On Tuesday, January 03, 2012 15:54 -0500 Eric Burger wrote: > Actually (shhhh), the IETF *does* get credit for rooms sold. > We reconcile the attendee list with hotel guests. Go for it. In a way, that is really too bad. If people find the cancellation or other) policies problematic enough to actually change their behavior (as distinct from whining), it would be good for the IAOC to get that message in a way that was clear and couldn't be avoided. If you don't incur a penalty for failure to fill a block and/or can't really tell "paid a higher rate to get a better policy" from "reserved after the block was full or past the deadline", then there are few, if any, incentives for telling a hotel that these sort of policies won't do. john From brian.e.carpenter@gmail.com Tue Jan 3 13:36:03 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399EB11E80CB for ; Tue, 3 Jan 2012 13:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.465 X-Spam-Level: X-Spam-Status: No, score=-103.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, 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 yY2N1kmidpU8 for ; Tue, 3 Jan 2012 13:36:02 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A544411E80B2 for ; Tue, 3 Jan 2012 13:36:02 -0800 (PST) Received: by iabz21 with SMTP id z21so10307896iab.31 for ; Tue, 03 Jan 2012 13:36:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=k6dFw+QvB70H7KWvXnZ8NYnIE0spZbW2Moi9OlIPbik=; b=inLLpiqexDDDK1ts7586rQx+CaJGREkk5xHN8++mfRxp7V4wWRtIEMOTzK+O5CmHOw pHHZsK+vmiatmROVAAJrQffttTHVOIltCHU6yhx3zofNyYZVh1qU4/CQ8fxsLUl7KSaY mcOFk2oFPffV3p7bksfD2iDhWf9sNRf6E97T8= Received: by 10.50.187.233 with SMTP id fv9mr65170946igc.24.1325626562355; Tue, 03 Jan 2012 13:36:02 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id h9sm181141184ibh.11.2012.01.03.13.35.58 (version=SSLv3 cipher=OTHER); Tue, 03 Jan 2012 13:36:00 -0800 (PST) Message-ID: <4F0374BB.8020102@gmail.com> Date: Wed, 04 Jan 2012 10:35:55 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John C Klensin Subject: Re: primary Paris hotel booking References: <34EF3F99-10DE-4B6B-92A7-2DD255412A0C@lucidvision.com> <20120103194826.69AEA21F84AD@ietfa.amsl.com> <0A4FD46C-F43E-46A7-BA1D-B7684632DED8@standardstrack.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF Discussion , Eric Burger X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 21:36:03 -0000 On 2012-01-04 10:03, John C Klensin wrote: > > --On Tuesday, January 03, 2012 15:54 -0500 Eric Burger > wrote: > >> Actually (shhhh), the IETF *does* get credit for rooms sold. >> We reconcile the attendee list with hotel guests. Go for it. > > In a way, that is really too bad. If people find the > cancellation or other) policies problematic enough to actually > change their behavior (as distinct from whining), it would be > good for the IAOC to get that message in a way that was clear > and couldn't be avoided. If you don't incur a penalty for > failure to fill a block and/or can't really tell "paid a higher > rate to get a better policy" from "reserved after the block was > full or past the deadline", then there are few, if any, > incentives for telling a hotel that these sort of policies won't > do. There's a third case, "paid a lower rate than the conference rate" (usually due to a smart corporate travel agent). I've never understood why conferences don't get a corporate-equivalent rate. Brian From eburger@standardstrack.com Tue Jan 3 13:52:59 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B0411E810C for ; Tue, 3 Jan 2012 13:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 HsXGmeCX4bHV for ; Tue, 3 Jan 2012 13:52:58 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 0773D11E80DA for ; Tue, 3 Jan 2012 13:52:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=ZqYlCuYuPear5xDJRfubsphTd0wNFgzM+qfG0J3WLXhyDh2orWynH6rm+S7SBzfR4ER8DAlPaz5RZ5qf9tuYFvAKKvA1Dj3SjU1LC91SvZXB+AXDA6rq/m1HH5fD6zcN; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:63932 helo=[192.168.15.184]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RiCHu-0000cA-0s; Tue, 03 Jan 2012 13:52:54 -0800 Subject: Re: primary Paris hotel booking Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-30--571977056; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <4F0374BB.8020102@gmail.com> Date: Tue, 3 Jan 2012 16:52:53 -0500 Message-Id: <707BC10D-68E3-4D81-B0A9-82F25F71A7C0@standardstrack.com> References: <34EF3F99-10DE-4B6B-92A7-2DD255412A0C@lucidvision.com> <20120103194826.69AEA21F84AD@ietfa.amsl.com> <0A4FD46C-F43E-46A7-BA1D-B7684632DED8@standardstrack.com> <4F0374BB.8020102@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: IETF Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 21:52:59 -0000 --Apple-Mail-30--571977056 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I do not know why hotels will not put it into a contract; believe me we = try. I call this the double-secret discount. It would be nice if the = hotels gave us Most Favored Nation status, but since they do not, and no = hotel has, this is the next best thing. On Jan 3, 2012, at 4:35 PM, Brian E Carpenter wrote: > On 2012-01-04 10:03, John C Klensin wrote: >>=20 >> --On Tuesday, January 03, 2012 15:54 -0500 Eric Burger >> wrote: >>=20 >>> Actually (shhhh), the IETF *does* get credit for rooms sold. >>> We reconcile the attendee list with hotel guests. Go for it. >>=20 >> In a way, that is really too bad. If people find the >> cancellation or other) policies problematic enough to actually >> change their behavior (as distinct from whining), it would be >> good for the IAOC to get that message in a way that was clear >> and couldn't be avoided. If you don't incur a penalty for >> failure to fill a block and/or can't really tell "paid a higher >> rate to get a better policy" from "reserved after the block was >> full or past the deadline", then there are few, if any, >> incentives for telling a hotel that these sort of policies won't >> do. >=20 > There's a third case, "paid a lower rate than the conference rate" > (usually due to a smart corporate travel agent). I've never > understood why conferences don't get a corporate-equivalent rate. >=20 > Brian > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --Apple-Mail-30--571977056 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ 9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX 56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0 FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0 okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwMTAzMjE1MjU0WjAjBgkqhkiG9w0BCQQxFgQU OfZ1HBtmIuwRvlC/s/EIxcpYmKIwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw DQYJKoZIhvcNAQEBBQAEggEAnLoP9DBtcNngkApEPwpwoj4/+ADpYeIQgVNOSyHa53g4XdFtf/j5 S6t3/5z8pkaacHGadnC2BX4YRl3YUz/ghNJNjH6QF5KVMWV9k9QEqYPQTAWRHuCY06ovYGHnA492 J4XdLEo9RVj2txOcyjK3YMm4iiWniuouFmoTLoCFNNfd7gTdfLpFkmkDl56GnTvRwbSikm2Jp18U CjBEULM6PZCgRcJ8D3+PprVlDtw7ay4SlbEo4V/FQnsPlrgx6hiWuNR68043nCld8KyOdyEJ8f/2 8o8/cZF0r5qe2NcN8ic/cAxojTJz1FKSjo/Ii3tlLKCENE6qGHHKq1ksI8TE4AAAAAAAAA== --Apple-Mail-30--571977056-- From stpeter@stpeter.im Tue Jan 3 14:19:11 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD1311E80B3; Tue, 3 Jan 2012 14:19:11 -0800 (PST) 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 egru+8wVm578; Tue, 3 Jan 2012 14:19:11 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A128E11E80A3; Tue, 3 Jan 2012 14:19:10 -0800 (PST) Received: from dhcp-64-101-72-124.cisco.com (unknown [64.101.72.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A1B064248C; Tue, 3 Jan 2012 15:27:46 -0700 (MST) Message-ID: <4F037EDB.30608@stpeter.im> Date: Tue, 03 Jan 2012 15:19:07 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Mykyta Yevstifeyev Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC References: <4EFC88F5.4070106@gmx.de> <4F006633.1040800@gmx.de> <4tu0g7d98h4st9ejgs32son1tldca2p0l9@hive.bjoern.hoehrmann.de> <4F00A5DF.3090605@gmx.de> <75C7A8A2BD7D3D528DF8DF0C@192.168.1.128> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: John C Klensin , ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 22:19:11 -0000 On 1/2/12 12:36 AM, Mykyta Yevstifeyev wrote: > While that was me who proposed the change to semantics, I tend more > and more to agree with documenting the existing practice; but let's > wait a response from W3C community first to see what's their attitude > towards the proposal. Mykyta, You have not yet submitted a revised I-D. Currently the document under consideration is draft-yevstifeyev-disclosure-relation-00. If you want to make fundamental changes to the spec, please do so by submitting a revised I-D. In the meantime, I have deferred the document to the January 19 telechat while you decide how you want to proceed. If you decide that you want to define two link relations instead of one, you will need to submit a revised I-D, which will need to undergo another review on the link-relations@ietf.org list and then another IETF Last Call. There is no need to waste IESG and general IETF attention on this specification if the author can't make up his mind about his own intentions. Peter -- Peter Saint-Andre https://stpeter.im/ From randy@psg.com Tue Jan 3 14:40:03 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8D311E80CC; Tue, 3 Jan 2012 14:40:03 -0800 (PST) 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 pMSUWN22Wvsp; Tue, 3 Jan 2012 14:40:02 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 6A63B11E8093; Tue, 3 Jan 2012 14:40:02 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RiD1U-0005cl-O7; Tue, 03 Jan 2012 22:40:00 +0000 Date: Wed, 04 Jan 2012 07:39:59 +0900 Message-ID: From: Randy Bush To: "George, Wes" Subject: Re: primary Paris hotel booking In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: IAOC , "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 22:40:03 -0000 http://franceforrent.com/ From d3e3e3@gmail.com Tue Jan 3 15:23:57 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9647B21F84FA for ; Tue, 3 Jan 2012 15:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.215 X-Spam-Level: X-Spam-Status: No, score=-104.215 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, 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 WI5M4mMRwTKn for ; Tue, 3 Jan 2012 15:23:57 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B49D621F84F8 for ; Tue, 3 Jan 2012 15:23:56 -0800 (PST) Received: by laah2 with SMTP id h2so6998665laa.31 for ; Tue, 03 Jan 2012 15:23:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=OCSiAGL3zv8JMSnbP6+S5nxlqcNu65d+LkDp2kuISME=; b=sKYZFOObEfM/kRvrogqbNCJaP76gIYC+hWmfV5gN1AtDD+rK901b9vUhekYoutk1Zc u2GYFuA5zwqRjgZj/q4AqMUX4J3tK4r7hSPGy62tnlDk8BtndlaOu3Q9nzdBqvCmhCyg KvZf0KIN44v+k/xEhECmzgqvR7n/UGaXldJCE= Received: by 10.152.133.70 with SMTP id pa6mr43847909lab.0.1325633034262; Tue, 03 Jan 2012 15:23:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.112.99 with HTTP; Tue, 3 Jan 2012 15:23:33 -0800 (PST) In-Reply-To: <4F036C93.9090806@netconfcentral.org> References: <4F036C93.9090806@netconfcentral.org> From: Donald Eastlake Date: Tue, 3 Jan 2012 18:23:33 -0500 Message-ID: Subject: Re: primary Paris hotel booking To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 23:23:57 -0000 On Tue, Jan 3, 2012 at 4:01 PM, Andy Bierman wrot= e: > On 01/03/2012 08:52 AM, George, Wes wrote: >> >> Happy New Year, it's time for our triannual hotel complaint thread. >> I hate to do it, but I think that there are people who haven't looked at >> this yet, and I'm hoping that we can perhaps rectify it before the major= ity >> of folks try to book: >> >> =A0"Instructions for making reservations at Hotel Concorde: >> Please fill out the reservations form and fax it directly to the hotel a= t: >> +33 1 57 00 50 79 or email it to cmasson@concorde-hotels.com" > > I crossed my fingers and clicked 'send' of the PDF with my credit card > number in it. > I didn't pay enough attention to the no-refund policy. =A0:-( > > I emailed my reservation on 12/22 and got a confirmation email on 12/26. > So far, my credit card has not been charged anything. > > I think there should always be a full-refund cut-off date for the IETF > hotel, even if > it is 2 months in advance. =A0I thought the cut-off was 15 days, but that= is > just > for 2 more nights billed in advance, not the first night. Actually, that's unclear. I've read the form several times. It says you lose any non-refudable deposit. And it says the two-day charge is non-refundable. But it never says that the initial one-day charge is non-refundable... Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > Andy > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From bob.hinden@gmail.com Tue Jan 3 16:02:54 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504DA1F0C57; Tue, 3 Jan 2012 16:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.592 X-Spam-Level: X-Spam-Status: No, score=-103.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, 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 b0Tx827DIJCw; Tue, 3 Jan 2012 16:02:53 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFC181F0C50; Tue, 3 Jan 2012 16:02:49 -0800 (PST) Received: by iabz21 with SMTP id z21so10478969iab.31 for ; Tue, 03 Jan 2012 16:02:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=o/1z+AUkvfF9ApuNswWiChOnN0+kdZfD/Z4EpJpsAvA=; b=mYuOAMQYN+KTkhpm1T1eNcDugIP1eO/XNHuDPA09kRAPGbfHpRqRcpGnINp06c/EU4 eODIbBA8uBCJwWkk+/MCvlZCf7jVXiKEH/hlQ/dsXFZrt8NNWNOMPx08hye3bHzHo2/V bShAyfRDL540oINsAH7DfpoELv2rhumLj8gWA= Received: by 10.42.135.69 with SMTP id o5mr66326555ict.34.1325635369435; Tue, 03 Jan 2012 16:02:49 -0800 (PST) Received: from [172.16.224.217] ([209.97.127.34]) by mx.google.com with ESMTPS id g34sm182391525ibk.10.2012.01.03.16.02.48 (version=SSLv3 cipher=OTHER); Tue, 03 Jan 2012 16:02:48 -0800 (PST) Subject: Re: [IAOC] primary Paris hotel booking Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: Date: Tue, 3 Jan 2012 16:02:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <336D4C73-04AD-47B7-988A-73D3A1A65EA2@gmail.com> References: To: "George, Wes" X-Mailer: Apple Mail (2.1084) Cc: IAOC , Bob Hinden , "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 00:02:54 -0000 Wes, I think everyone on the IAOC was surprised when we first heard that the = meeting hotel insisted that people can only use fax or email to send in = their reservations. We tried to get the hotel to change this, but they = would not budge. This included their rejection of accepting = reservations by phone. Other nearby hotels were much more expensive, so this reservation method = was reluctantly accepted. You are, of course, free to book online but when I checked earlier today = the rates were higher even without breakfast included (but the = cancelation policy less was severe). Your tradeoff. In this venue, the = IETF will receive credit for your stay if you book on line (or through = your corporate travel department). It also most goes with out saying that there are also many other hotels = in Paris at lower and higher rates. Bob On Jan 3, 2012, at 8:52 AM, George, Wes wrote: > Happy New Year, it's time for our triannual hotel complaint thread. > I hate to do it, but I think that there are people who haven't looked = at this yet, and I'm hoping that we can perhaps rectify it before the = majority of folks try to book: >=20 > "Instructions for making reservations at Hotel Concorde: > Please fill out the reservations form and fax it directly to the hotel = at: +33 1 57 00 50 79 or email it to cmasson@concorde-hotels.com" >=20 > It's 2012, but the IETF and this hotel chain expects us to book = reservations at the main conference hotel by (international) FAX or by = *emailing* a form which includes a credit card number so that the hotel = can hold the room and implement its relatively bizarre = prepay/anti-cancellation policy. > Would it be trolling to ask whether anyone verified that "cmasson" has = support for PGP encrypted-email and a proper method of securely storing = (and then destroying after use) the several hundred credit card numbers = they are about to receive? >=20 > What person or rate code should we ask for when booking our rooms over = the phone? (hey if I'm going old school, I'm doing it all the way!) = Though, given the above, I'm relatively worried that my credit card = number will simply end up on an unprotected spreadsheet on a PC = somewhere in their office even if I call to book. >=20 > More practically, the hotel blocks at the primary hotel typically fill = up quite fast once registration is opened, especially since the overflow = hotel is actually more expensive than the primary. Does the hotel = fax/call us back to tell us that they have no more rooms available for = our requested dates, or is the block open-ended such that they will keep = selling rooms in it until the cutoff regardless of the number? >=20 > Evidently "ability to book group rate rooms online" is something that = should be added to our list of hotel requirements. I'm stunned that it's = not there already. >=20 > Wes George >=20 >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > IAOC mailing list > IAOC@ietf.org > https://www.ietf.org/mailman/listinfo/iaoc From kaushalshriyan@gmail.com Tue Jan 3 17:53:46 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5AE21F85C8 for ; Tue, 3 Jan 2012 17:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_20=-0.74, 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 JZfbRTHj7tno for ; Tue, 3 Jan 2012 17:53:46 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 346E021F85C6 for ; Tue, 3 Jan 2012 17:53:45 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so14262974vcb.31 for ; Tue, 03 Jan 2012 17:53:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=ox7T/c8ieZr8W7WwgIRlaPv2T/JwtOfUJn3fxYwn0Hg=; b=wuiM2c7YHxGrM8Q7ZigLKW550f1Zgf3UfQ+PCTLPPRQvcsJFvHJVSe3uoMCW2S3elv CoZ4dwAXjqPoC9r2RPLclI2DZtbFrvCTRoYb2XBAkTyAWTKtM+u2S7jgsbr8p6zSjBP5 GGfjiAgg4sHRi4m9lbUjHUAAIqM57EXQ8i2l8= Received: by 10.220.148.196 with SMTP id q4mr30513227vcv.42.1325642024309; Tue, 03 Jan 2012 17:53:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.5.208 with HTTP; Tue, 3 Jan 2012 17:53:24 -0800 (PST) From: Kaushal Shriyan Date: Wed, 4 Jan 2012 07:23:24 +0530 Message-ID: Subject: Protocol Definition To: ietf@ietf.org Content-Type: multipart/alternative; boundary=f46d0438939df5529d04b5aa15d5 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 01:53:46 -0000 --f46d0438939df5529d04b5aa15d5 Content-Type: text/plain; charset=ISO-8859-1 Hi, Can someone please explain me the term "Protocol". Does it also mean it has some software code underlying beneath it. Please help me understand. Regards, Kaushal --f46d0438939df5529d04b5aa15d5 Content-Type: text/html; charset=ISO-8859-1 Hi,

      Can someone please explain me the term "Protocol". Does it also mean it has some software code underlying beneath it. Please help me understand.

      Regards,

      Kaushal
      --f46d0438939df5529d04b5aa15d5-- From ole@cisco.com Tue Jan 3 17:59:24 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43AB11E807F for ; Tue, 3 Jan 2012 17:59:24 -0800 (PST) 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=[AWL=0.000, 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 sSMXliIgk9iU for ; Tue, 3 Jan 2012 17:59:23 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8DE11E8080 for ; Tue, 3 Jan 2012 17:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ole@cisco.com; l=829; q=dns/txt; s=iport; t=1325642363; x=1326851963; h=date:from:reply-to:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=fQMzFd7AdTCqwL+sIUUS2swiqYdV4MPIgVRB+PirRAE=; b=T3NgpcNXdh2bbHDj3pj2yb+j8QuNKkpmlO+iUUuY/ry87NZfeJsRktSY O7Rnw+rJCeHOtAJljnwRwcweXjwA7S8QSEQn7Radd/DUc2SouChIRgt28 3xkg2vmD/XE3wlED2llV5RRYRFPuq9ROBss3tTztb+hG6Bm99Bx16lhbn Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEHANawA0+rRDoI/2dsb2JhbABAA4IFoSGJPIEFgXIBAQEDARIBAgEkPwULC0ZXBhMih1gIlzMBgy4PAZphiHCDHwSIN5c9h2M X-IronPort-AV: E=Sophos;i="4.71,453,1320624000"; d="scan'208";a="21975919" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 04 Jan 2012 01:59:23 +0000 Received: from rcdn-vpn-client-10-89-1-59.cisco.com (rcdn-vpn-client-10-89-1-59.cisco.com [10.89.1.59]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q041xMTV008475; Wed, 4 Jan 2012 01:59:22 GMT Date: Tue, 3 Jan 2012 17:59:22 -0800 (PST) From: Ole Jacobsen To: Kaushal Shriyan Subject: Re: Protocol Definition In-Reply-To: Message-ID: References: User-Agent: Alpine 2.01 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ole Jacobsen List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 01:59:24 -0000 In very simple terms: A protocol is a set of rules for interaction. In this case the interaction is between computers. This can involve both hardware and software and protocols define the interactions as well as the "formats" (bits on the wire etc). For a much more comprehensive definition, see: http://en.wikipedia.org/wiki/Communications_protocol Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: ole@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo On Wed, 4 Jan 2012, Kaushal Shriyan wrote: > Hi, > > Can someone please explain me the term "Protocol". Does it also mean it has > some software code underlying beneath it. Please help me understand. > > Regards, > > Kaushal > From john-ietf@jck.com Tue Jan 3 18:21:47 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB6421F857B; Tue, 3 Jan 2012 18:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 aeHQj2vKF4Uy; Tue, 3 Jan 2012 18:21:43 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 30E0F21F8575; Tue, 3 Jan 2012 18:21:42 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RiGU1-000NSZ-WF; Tue, 03 Jan 2012 21:21:42 -0500 Date: Tue, 03 Jan 2012 21:21:41 -0500 From: John C Klensin To: Mykyta Yevstifeyev Subject: Re: Last Call: (The 'disclosure' Link Relation Type) to Informational RFC Message-ID: In-Reply-To: References: <4EFC88F5.4070106@gmx.de> <4F006633.1040800@gmx.de> <4tu0g7d98h4st9ejgs32son1tldca2p0l9@hive.bjoern.hoehrmann.de> <4F00A5DF.3090605@gmx.de> <75C7A8A2BD7D3D528DF8DF0C@192.168.1.128> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 02:21:47 -0000 --On Monday, January 02, 2012 09:36 +0200 Mykyta Yevstifeyev wrote: >... >> I believe that the IESG ought to take exceptional care with >> individual submissions, precisely because they are published >> in the IETF stream, requiring significant expertise or = careful >> reading to determine whether they actually represent informed >> and competent IETF consensus. =C2=A0Against that test, this >> document is not ready for approval and RFC publication. = =C2=A0 >> Specific examples: >>=20 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0(1) The second sentence of the = Introduction begins >> "This =C2=A0 =C2=A0 =C2=A0 =C2=A0document specifies a new = type of such >> relationship...". =C2=A0 =C2=A0 =C2=A0 =C2=A0But this is not = "new": it has >> been around for years, as =C2=A0 =C2=A0 =C2=A0 =C2=A0the next = paragraph (and >> comments on the IETF list) =C2=A0 =C2=A0 =C2=A0 = =C2=A0indicate. >=20 > It's "new" in context of being formally registered. Then say that it specifies a registration for something that has been around for a while, not that it is "new". >> =C2=A0 =C2=A0 =C2=A0 =C2=A0(2) The last paragraph of the = Introduction reads: >> "This =C2=A0 =C2=A0 =C2=A0 =C2=A0document is to formally = register the >> 'disclosure' Link =C2=A0 =C2=A0 =C2=A0 =C2=A0Relation Type = with IANA and >> provide a permanent record =C2=A0 =C2=A0 =C2=A0 =C2=A0on it = for the Internet >> community. =C2=A0Additionally, it =C2=A0 =C2=A0 =C2=A0 = =C2=A0expands the sphere >> of this relation type to allow its =C2=A0 =C2=A0 =C2=A0 = =C2=A0use when >> referring to separate patent disclosures." =C2=A0So =C2=A0 = =C2=A0 =C2=A0 =C2=A0it >> registers the type (good, IMO); makes a permanent and =C2=A0 = =C2=A0 >> =C2=A0 =C2=A0public record --which the author believes W3C = has failed >> =C2=A0 =C2=A0 =C2=A0 =C2=A0to do (good, IMO); documents the = existing practice >> (also =C2=A0 =C2=A0 =C2=A0 =C2=A0good, IMO); and creates an = untested >> extension (outside =C2=A0 =C2=A0 =C2=A0 =C2=A0the scope of = Informational >> publication of an existing =C2=A0 =C2=A0 =C2=A0 = =C2=A0practice, IMO). > So do you propose dropping the semantics for separate > disclosures and leaving the original W3C's? I propose that you figure out what you want to do, that you be very explicit about what (if anything) is new and what is existing practice, and that you get out a new I-D that says whatever you intend. If you are asking me the substantive question, I think that, if you are going to propose an extension, you are obligated to be very clear what the extension is and to do a careful review of what issues might arise with it. I'm not sure I have an opinion about whether the extension is a good idea -- I need that information to figure it out and I think it is your obligation to supply it. I think what I'm saying here is consistent in general principles, if not in detail, with Peter's recent note -- making what you are proposing clear is your responsibility. Please don't ask the community to spend time on review until you have a very specific and clear proposal with which you are satisfied. >... >> =C2=A0 =C2=A0 =C2=A0 =C2=A0(4) While it is not unusual for = Acknowledgments >> sections =C2=A0 =C2=A0 =C2=A0 =C2=A0to be updated during or = after Last Call, >> an entry of =C2=A0 =C2=A0 =C2=A0 =C2=A0 for the only = contributors to the >> document make it =C2=A0 =C2=A0 =C2=A0 =C2=A0impossible for = the community to >> verify that the BCP78 =C2=A0 =C2=A0 =C2=A0 =C2=A0requirements = have been >> followed. >=20 > occurred because there were no comments received before > LC; but now, I hope, this may be corrected. Then get a new I-D posted (see Peter's note). >> I think this document could be cleaned up and made ready for >> publication by using any of the following three options: >... >> (iii) Modify this document to be _extremely_ clear about what >> is existing practice and what is the author's suggestion >> about an extension. =C2=A0For the latter, the change being = made, >> the justification for it, and a risk analysis should be >> present and explicit. >=20 > While that was me who proposed the change to semantics, I tend > more and more to agree with documenting the existing practice; > but let's wait a response from W3C community first to see > what's their attitude towards the proposal. Documenting the existing spec would work for me (but so would doing so and adding a well-vetted and well-documented extension). I do suggest that you not "wait" for a response from W3C but that you try to actively engage with them, seeking help from Thomas, Julian, Mark, or others as appropriate. best, john From evnikita2@gmail.com Tue Jan 3 22:29:29 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A931F21F85D3; Tue, 3 Jan 2012 22:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 IWbplk0+kvlu; Tue, 3 Jan 2012 22:29:28 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8686921F85D2; Tue, 3 Jan 2012 22:29:28 -0800 (PST) Received: by obcuz6 with SMTP id uz6so15395245obc.31 for ; Tue, 03 Jan 2012 22:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=OMdJ3jJtQ6coE2koFwyK+3dbl/H3tOpCe96wxzWJnCE=; b=Rk/i33fsdSn0qi3tafwa4ukcZ6F2aZ3YIjRRYiJaw92ljfDPYsk1Al8nclHLSBMc8N yKSafvyCY1Jjyuq63OK2Va2WWbHuNiFRr+c5XwIJJpEsOZM4Hqyk5VcbhKAfqFr04Our 8/vkwYkIVYJJb+HkQ44d4TKIQjHb3H0oKEqvI= MIME-Version: 1.0 Received: by 10.182.15.104 with SMTP id w8mr47413757obc.20.1325658567003; Tue, 03 Jan 2012 22:29:27 -0800 (PST) Received: by 10.182.30.167 with HTTP; Tue, 3 Jan 2012 22:29:26 -0800 (PST) Date: Wed, 4 Jan 2012 08:29:26 +0200 Message-ID: Subject: Re: Last Call: - update From: Mykyta Yevstifeyev To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: John C Klensin , ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 06:29:29 -0000 So I've submitted the revised version, taking into account all the LC comments, and the consensus on defining W3C's current practice (as I see many comments received with this respect) rather than two separate relation types. A number of other edits have been made; you may see the diffs at http://tools.ietf.org/rfcdiff?url2=draft-yevstifeyev-disclosure-relation-01 and the draft at tools.ietf.org/html/draft-yevstifeyev-disclosure-relation-01. Meanwhile, as the document is deferred to next IESG telechat, you may freely submit your comments on this version, either publicly or privately to the author. Mykyta Yevstifeyev 2012/1/4 Peter Saint-Andre : > > > On 1/2/12 12:36 AM, Mykyta Yevstifeyev wrote: > >> While that was me who proposed the change to semantics, I tend more >> and more to agree with documenting the existing practice; but let's >> wait a response from W3C community first to see what's their attitude >> towards the proposal. > > Mykyta, > > You have not yet submitted a revised I-D. Currently the document under > consideration is draft-yevstifeyev-disclosure-relation-00. If you want > to make fundamental changes to the spec, please do so by submitting a > revised I-D. > > In the meantime, I have deferred the document to the January 19 telechat > while you decide how you want to proceed. > > If you decide that you want to define two link relations instead of one, > you will need to submit a revised I-D, which will need to undergo > another review on the link-relations@ietf.org list and then another IETF > Last Call. > > There is no need to waste IESG and general IETF attention on this > specification if the author can't make up his mind about his own intentions. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > From yaakov_s@rad.com Wed Jan 4 02:07:28 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A05421F868A for ; Wed, 4 Jan 2012 02:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.298 X-Spam-Level: X-Spam-Status: No, score=-101.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 uVjBa0bS6Kkd for ; Wed, 4 Jan 2012 02:07:27 -0800 (PST) Received: from rad.co.il (mailrelay02.rad.co.il [62.0.23.237]) by ietfa.amsl.com (Postfix) with ESMTP id E3F2B21F8685 for ; Wed, 4 Jan 2012 02:07:24 -0800 (PST) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 4 Jan 2012 12:04:24 +0200 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Wed, 4 Jan 2012 12:07:20 +0200 From: Yaakov Stein To: Ole Jacobsen , Kaushal Shriyan Subject: RE: Protocol Definition Thread-Topic: Protocol Definition Thread-Index: AQHMyoO4uTrSvisg80qAwUBf6ZqN4pX7UmUAgACpgAA= Date: Wed, 4 Jan 2012 10:07:20 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 10:07:28 -0000 A protocol is to communications what an algorithm is to computation. Y(J)S -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Ole= Jacobsen Sent: Wednesday, January 04, 2012 03:59 To: Kaushal Shriyan Cc: ietf@ietf.org Subject: Re: Protocol Definition In very simple terms: A protocol is a set of rules for interaction. In=20 this case the interaction is between computers. This can involve both=20 hardware and software and protocols define the interactions as well as=20 the "formats" (bits on the wire etc). For a much more comprehensive definition, see: http://en.wikipedia.org/wiki/Communications_protocol Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: ole@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo On Wed, 4 Jan 2012, Kaushal Shriyan wrote: > Hi, >=20 > Can someone please explain me the term "Protocol". Does it also mean it h= as > some software code underlying beneath it. Please help me understand. >=20 > Regards, >=20 > Kaushal >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From tlr@w3.org Wed Jan 4 03:31:13 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B93821F86B8; Wed, 4 Jan 2012 03:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.194 X-Spam-Level: X-Spam-Status: No, score=-10.194 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, 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 djqHilLJYten; Wed, 4 Jan 2012 03:31:12 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFFA21F8685; Wed, 4 Jan 2012 03:31:12 -0800 (PST) Received: from ip-88-207-233-25.dyn.luxdsl.pt.lu ([88.207.233.25] helo=[192.168.2.104]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1RiP3g-0001Te-3M; Wed, 04 Jan 2012 06:31:04 -0500 Subject: Re: Last Call: - update Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Thomas Roessler In-Reply-To: Date: Wed, 4 Jan 2012 12:31:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1251.1) Cc: John C Klensin , iesg , ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 11:31:13 -0000 Thanks. In an editorial nit, the first example in 2.1 still uses the = "disclosure-list" relationship type. -- Thomas Roessler, W3C (@roessler) On 2012-01-04, at 07:29 +0100, Mykyta Yevstifeyev wrote: > So I've submitted the revised version, taking into account all the LC > comments, and the consensus on defining W3C's current practice (as I > see many comments received with this respect) rather than two separate > relation types. A number of other edits have been made; you may see > the diffs at = http://tools.ietf.org/rfcdiff?url2=3Ddraft-yevstifeyev-disclosure-relation= -01 > and the draft at > tools.ietf.org/html/draft-yevstifeyev-disclosure-relation-01. > Meanwhile, as the document is deferred to next IESG telechat, you may > freely submit your comments on this version, either publicly or > privately to the author. >=20 > Mykyta Yevstifeyev >=20 > 2012/1/4 Peter Saint-Andre : >> >>=20 >> On 1/2/12 12:36 AM, Mykyta Yevstifeyev wrote: >>=20 >>> While that was me who proposed the change to semantics, I tend more >>> and more to agree with documenting the existing practice; but let's >>> wait a response from W3C community first to see what's their = attitude >>> towards the proposal. >>=20 >> Mykyta, >>=20 >> You have not yet submitted a revised I-D. Currently the document = under >> consideration is draft-yevstifeyev-disclosure-relation-00. If you = want >> to make fundamental changes to the spec, please do so by submitting a >> revised I-D. >>=20 >> In the meantime, I have deferred the document to the January 19 = telechat >> while you decide how you want to proceed. >>=20 >> If you decide that you want to define two link relations instead of = one, >> you will need to submit a revised I-D, which will need to undergo >> another review on the link-relations@ietf.org list and then another = IETF >> Last Call. >>=20 >> There is no need to waste IESG and general IETF attention on this >> specification if the author can't make up his mind about his own = intentions. >>=20 >> Peter >>=20 >> -- >> Peter Saint-Andre >> https://stpeter.im/ >>=20 >>=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From evnikita2@gmail.com Wed Jan 4 03:39:26 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E25E21F8723; Wed, 4 Jan 2012 03:39:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 Rn7L1GF6Pu5L; Wed, 4 Jan 2012 03:39:25 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BD83521F8727; Wed, 4 Jan 2012 03:39:25 -0800 (PST) Received: by mail-tul01m020-f172.google.com with SMTP id uz6so15725019obc.31 for ; Wed, 04 Jan 2012 03:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=W4u8pFOV9xq+//jhe4EbNLwSz2ml67XHp4C73gwe/9M=; b=lsYxZL9bYkJFqYnDC4ldqIHqiDwuLHDXO0C42tRleR/mdXIBu1bz8DBEsn0lgB7L+F 043sRyc84Rr5W1gGSjnFTehxvhzE73a0vLidUhRwgAIhf45bfZQp7DDXKmH5LVgCKTsl B7RNfjkN0QfVID7e7pY6RRuGdZ4dn40NDaBTk= MIME-Version: 1.0 Received: by 10.182.160.1 with SMTP id xg1mr48160122obb.30.1325677165645; Wed, 04 Jan 2012 03:39:25 -0800 (PST) Received: by 10.182.30.167 with HTTP; Wed, 4 Jan 2012 03:39:25 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Jan 2012 13:39:25 +0200 Message-ID: Subject: Re: Last Call: - update From: Mykyta Yevstifeyev To: Thomas Roessler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: John C Klensin , ietf@ietf.org, iesg X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 11:39:27 -0000 Yes, fixed now. Mykyta 2012/1/4 Thomas Roessler : > Thanks. > > In an editorial nit, the first example in 2.1 still uses the "disclosure-= list" relationship type. > -- > Thomas Roessler, W3C =A0 =A0(@roessler) > > > > > > > > On 2012-01-04, at 07:29 +0100, Mykyta Yevstifeyev wrote: > >> So I've submitted the revised version, taking into account all the LC >> comments, and the consensus on defining W3C's current practice (as I >> see many comments received with this respect) rather than two separate >> relation types. =A0A number of other edits have been made; you may see >> the diffs at http://tools.ietf.org/rfcdiff?url2=3Ddraft-yevstifeyev-disc= losure-relation-01 >> and the draft at >> tools.ietf.org/html/draft-yevstifeyev-disclosure-relation-01. >> Meanwhile, as the document is deferred to next IESG telechat, you may >> freely submit your comments on this version, either publicly or >> privately to the author. >> >> Mykyta Yevstifeyev >> >> 2012/1/4 Peter Saint-Andre : >>> >>> >>> On 1/2/12 12:36 AM, Mykyta Yevstifeyev wrote: >>> >>>> While that was me who proposed the change to semantics, I tend more >>>> and more to agree with documenting the existing practice; but let's >>>> wait a response from W3C community first to see what's their attitude >>>> towards the proposal. >>> >>> Mykyta, >>> >>> You have not yet submitted a revised I-D. Currently the document under >>> consideration is draft-yevstifeyev-disclosure-relation-00. If you want >>> to make fundamental changes to the spec, please do so by submitting a >>> revised I-D. >>> >>> In the meantime, I have deferred the document to the January 19 telecha= t >>> while you decide how you want to proceed. >>> >>> If you decide that you want to define two link relations instead of one= , >>> you will need to submit a revised I-D, which will need to undergo >>> another review on the link-relations@ietf.org list and then another IET= F >>> Last Call. >>> >>> There is no need to waste IESG and general IETF attention on this >>> specification if the author can't make up his mind about his own intent= ions. >>> >>> Peter >>> >>> -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>> >>> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> > From dhc@dcrocker.net Thu Jan 5 06:49:05 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D9521F87B3 for ; Thu, 5 Jan 2012 06:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 ZjLP6LdR-4d0 for ; Thu, 5 Jan 2012 06:49:05 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 12E6621F8716 for ; Thu, 5 Jan 2012 06:49:05 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q05EmwMw026295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jan 2012 06:49:04 -0800 Message-ID: <4F05B856.9050205@dcrocker.net> Date: Thu, 05 Jan 2012 06:48:54 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Protocol Definition References: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> 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, 05 Jan 2012 06:49:04 -0800 (PST) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 14:49:05 -0000 On 1/4/2012 2:07 AM, Yaakov Stein wrote: > A protocol is to communications what an algorithm is to computation. The mantra that I was taught many years ago was that a process is a program in execution. A program is the instructions. That seems compatible with the above observations. (One can quibble about the difference between algorithm and program. An algorithm is a component of a program. The distinction is relevant here because a protocol is typically a complete mechanism rather than being a component of the mechanisms. On the other hand, an entire Internet service might comprise multiple protocols.) My question is: If protocol corresponds with program or algorithm, then what is the communications term that corresponds to process? It's tempting to say "port number", but that doesn't seem very satisfying. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dave@cridland.net Thu Jan 5 07:02:01 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3286721F87B5 for ; Thu, 5 Jan 2012 07:02:01 -0800 (PST) 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 r6h1xqcIpu1X for ; Thu, 5 Jan 2012 07:02:00 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 5C78621F86E3 for ; Thu, 5 Jan 2012 07:02:00 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 86D6C1168087; Thu, 5 Jan 2012 15:01:59 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26iR9MjyHmJr; Thu, 5 Jan 2012 15:01:57 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 6E5BB1168067; Thu, 5 Jan 2012 15:01:57 +0000 (GMT) Subject: Re: Protocol Definition References: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> <4F05B856.9050205@dcrocker.net> In-Reply-To: <4F05B856.9050205@dcrocker.net> MIME-Version: 1.0 Message-Id: <3013.1325775717.451646@puncture> Date: Thu, 05 Jan 2012 15:01:57 +0000 From: Dave Cridland To: Dave CROCKER , IETF-Discussion Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 15:02:01 -0000 On Thu Jan 5 14:48:54 2012, Dave CROCKER wrote: > If protocol corresponds with program or algorithm, then what > is the communications term that corresponds to process? > > It's tempting to say "port number", but that doesn't seem very > satisfying. "Session"? Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From dhc@dcrocker.net Thu Jan 5 08:50:37 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E5421F882A for ; Thu, 5 Jan 2012 08:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.932 X-Spam-Level: X-Spam-Status: No, score=-6.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 DSmGtFnYDinw for ; Thu, 5 Jan 2012 08:50:36 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E2DDD21F8827 for ; Thu, 5 Jan 2012 08:50:34 -0800 (PST) Received: from [192.168.1.9] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q05GoRFP028475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jan 2012 08:50:33 -0800 Message-ID: <4F05D4CF.4060105@dcrocker.net> Date: Thu, 05 Jan 2012 08:50:23 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Protocol Definition References: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> <4F05B856.9050205@dcrocker.net> In-Reply-To: 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, 05 Jan 2012 08:50:34 -0800 (PST) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 16:50:37 -0000 >> (One can quibble about the difference between algorithm and >> program. An algorithm is a component of a program. ... > Or an algorithm is an abstraction (usually mathematical as > distinct from some other sort of specification) and the program > (or part of it) is a specific realization of that abstraction. As a discussion detached from utility in the IETF, that view has academic merit, of course. In terms of practical IETF discussions -- and for the comparative purposes this thread was developing -- I am used to the view that a program typically contains multiple algorithms and therefore performs a larger and integrated /set/ of activities (functions). Note that Wikipedia nicely correlates algorithm with function, which largely matches the "component of" view that I suggested. > The difference between that distinction and the one you make is > that we have a long history of correct algorithms and incorrect > or inadequate implementations. And indeed the tendency to confuse constructs /within/ network architecture with the distinction /between/ network architecture and software implementation is quite common. For the IETF, we typically do not focus on implementation correctness, except to the extent that a pattern of implementation problems might affect architectural choices to improve simplicity. I've assumed that this thread on the IETF list ought to focus on uses of the terms that aid IETF work... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From kathleen.moriarty@emc.com Wed Jan 4 08:04:14 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BB721F877C; Wed, 4 Jan 2012 08:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.188, 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 DJSuuqbJWDy6; Wed, 4 Jan 2012 08:04:13 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6FE21F8739; Wed, 4 Jan 2012 08:04:12 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q04G4Bsf007405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jan 2012 11:04:11 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 4 Jan 2012 11:03:58 -0500 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q04G3s7v007704; Wed, 4 Jan 2012 11:03:54 -0500 Received: from mx06a.corp.emc.com ([169.254.1.218]) by mxhub21.corp.emc.com ([128.222.70.133]) with mapi; Wed, 4 Jan 2012 11:03:54 -0500 From: To: , , Date: Wed, 4 Jan 2012 11:03:52 -0500 Subject: Gen-ART review of draft-ash-gcac-algorithm-spec-03.txt Thread-Topic: Gen-ART review of draft-ash-gcac-algorithm-spec-03.txt Thread-Index: AczK+nPFt5VM3MIeTsqVi90pJuZBGA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Thu, 05 Jan 2012 08:51:00 -0800 Cc: dave.mcdysan@verizon.com, gash5107@yahoo.com X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 16:04:14 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ash-gcac-algorithm-spec-03.txt Reviewer: Kathleen M. Moriarty Review Date: 1/4/12 IETF LC End Date: 1/11/12 IESG Telechat date: 1/19/12 Summary: The draft is essentially ready with nits. The last nit could be = a minor issue, but has a simple resolution. The security considerations se= ction points out possible attacks and should also require logging of events= tied to the users/groups responsible for those actions. Major issues: Minor issues: Nits/editorial comments: The last line of the abstract should be on the previous line. On the second to last paragraph of page 8, the following acronym is listed:= emergency traffic (ETS), should there be something for the "S"? The second to last sentence of the same paragraph: Consider changing from: "Several assured forwarding (AF) queues may be used for various data traffic, for example, premium private data traffic, premium public data traffic, and a separate best-effort queue is used for the best-effort traffic." To: "Several assured forwarding (AF) queues may be used for various data traffic, for example, premium private data traffic, premium public data traffic, and a separate best-effort queue for the best-effort traffic." First paragraph of section 3: Consider removing "however", it doesn't add a= nything: Change from: "Requiring nodes to expose detailed and up-to-date CAC information, however, may result in unacceptably high rate of routing updates." To: "Requiring nodes to expose detailed and up-to-date CAC information may result in unacceptably high rate of routing updates." Second paragraph of Section 3: Consider removing "and cannot" - it is unnec= essary: Change from: "This common interpretation is in the form of an MPLS GCAC algorithm to be performed during MPLS LSP path selection to determine if a link or node can or cannot be included for consideration." To: "This common interpretation is in the form of an MPLS GCAC algorithm to be performed during MPLS LSP path selection to determine if a link or node can be included for consideration." Section 3.2: Consider breaking the first sentence into two: "The assumption behind the MPLS GCAC is that the ratio between BWMck, which represents the safety margin the node is putting above the SBWck, and the standard deviation of the SBWck defined below does not change significantly as one new aggregate flow is added on the link." Security Considerations: I think a requirement for logging should be specified here as well. If an = attack were to occur, you will want the user/group and actions taken to be = logged to trace the attack. Without this, the other enforcement mechanisms= are inadequate. Sentence that spans page 17-18 should be broken into multiple sentences (re= adable, but long - as is the following sentence): "For example, if aggregate flow requests are made for CT LSP bandwidth that exceeds the current DSTE tunnel bandwidth allocation, the GEF initiates a bandwidth modification request on the appropriate LSP(s), which may entail increasing the current LSP bandwidth allocation by a discrete increment of bandwidth denoted here as DBW, where DBW is the additional amount needed by the current aggregate flow request." There is an extra line in the second line of A.1. Thanks, Kathleen From john@jck.com Thu Jan 5 07:13:31 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4171921F8801 for ; Thu, 5 Jan 2012 07:13:31 -0800 (PST) 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 jJ--sxZnkB4H for ; Thu, 5 Jan 2012 07:13:30 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 9586F21F8750 for ; Thu, 5 Jan 2012 07:13:30 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Rip0O-0001rW-Jx; Thu, 05 Jan 2012 10:13:24 -0500 Date: Thu, 05 Jan 2012 10:13:23 -0500 From: John C Klensin To: dcrocker@bbiw.net, ietf@ietf.org Subject: Re: Protocol Definition Message-ID: In-Reply-To: <4F05B856.9050205@dcrocker.net> References: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> <4F05B856.9050205@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mailman-Approved-At: Thu, 05 Jan 2012 08:51:12 -0800 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 15:13:31 -0000 --On Thursday, January 05, 2012 06:48 -0800 Dave CROCKER wrote: > (One can quibble about the difference between algorithm and > program. An algorithm is a component of a program. The > distinction is relevant here because a protocol is typically a > complete mechanism rather than being a component of the > mechanisms. On the other hand, an entire Internet service > might comprise multiple protocols.) Or an algorithm is an abstraction (usually mathematical as distinct from some other sort of specification) and the program (or part of it) is a specific realization of that abstraction. The difference between that distinction and the one you make is that we have a long history of correct algorithms and incorrect or inadequate implementations. john From tglassey@earthlink.net Thu Jan 5 09:06:48 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDF921F8844 for ; Thu, 5 Jan 2012 09:06:48 -0800 (PST) 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 8n09Zn2ub5le for ; Thu, 5 Jan 2012 09:06:48 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9B221F87E0 for ; Thu, 5 Jan 2012 09:06:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=YGXPbdCqI+MV+fpzn0iDry6QvsF8Mv4yx4g7AC1AAYQzGkK46IGUxwNmfdx2BSWi; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Opacus-Archived:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [216.171.124.10] (helo=[216.171.125.68]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Riqm5-0004tc-PR for ietf@ietf.org; Thu, 05 Jan 2012 12:06:45 -0500 Message-ID: <4F05D8A0.6080708@earthlink.net> Date: Thu, 05 Jan 2012 09:06:40 -0800 From: todd glassey User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Protocol Definition References: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> <4F05B856.9050205@dcrocker.net> In-Reply-To: <4F05B856.9050205@dcrocker.net> X-Opacus-Archived: none X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79fcf888cfd562114df275271961fd3f13350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 216.171.124.10 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 17:06:48 -0000 On 1/5/2012 6:48 AM, Dave CROCKER wrote: > > > On 1/4/2012 2:07 AM, Yaakov Stein wrote: >> A protocol is to communications what an algorithm is to computation. > > > The mantra that I was taught many years ago was that a process is a > program in execution. A program is the instructions. That seems > compatible with the above observations. > > (One can quibble about the difference between algorithm and program. An > algorithm is a component of a program. The program is the code-based implementation of the alg? The distinction is relevant here > because a protocol is typically a complete mechanism rather than being a > component of the mechanisms. I.e. "A complete method of doing something"... > On the other hand, an entire Internet > service might comprise multiple protocols.) Yes but the Service then is a superset of the Protocols themselves in that instance as opposed to a single service. > > > My question is: > > If protocol corresponds with program or algorithm, then what is the > communications term that corresponds to process? I think Event Streams seems to be the best way of categorizing those happenings (or events). > > It's tempting to say "port number", but that doesn't seem very > satisfying. No, you are right here and it's because there may be no ports/sockets in the protocol as in IPC for instance. > > d/ -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. From dhc@dcrocker.net Thu Jan 5 09:13:59 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2E121F8761 for ; Thu, 5 Jan 2012 09:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.885 X-Spam-Level: X-Spam-Status: No, score=-6.885 tagged_above=-999 required=5 tests=[AWL=-0.286, 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 cGbul04CXttr for ; Thu, 5 Jan 2012 09:13:58 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C90BA21F883F for ; Thu, 5 Jan 2012 09:13:58 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q05HDoXk028909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jan 2012 09:13:56 -0800 Message-ID: <4F05DA49.8050802@dcrocker.net> Date: Thu, 05 Jan 2012 09:13:45 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Dave Cridland Subject: Re: Protocol Definition References: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> <4F05B856.9050205@dcrocker.net> <3013.1325775717.451646@puncture> In-Reply-To: <3013.1325775717.451646@puncture> 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, 05 Jan 2012 09:13:56 -0800 (PST) Cc: IETF-Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 17:13:59 -0000 On 1/5/2012 7:01 AM, Dave Cridland wrote: > On Thu Jan 5 14:48:54 2012, Dave CROCKER wrote: >> If protocol corresponds with program or algorithm, then what is the >> communications term that corresponds to process? >> >> It's tempting to say "port number", but that doesn't seem very satisfying. > > "Session"? That's an appealing suggestion. It is based on a 'state' existing between the two end points and it is above transport (so we don't have to worry about tcp vs udp vs...). On the other hand, isn't a session able to have more than one "connection" and, therefore, possibly be running more than one protocol? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dotis@mail-abuse.org Thu Jan 5 09:54:02 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A46B21F877D for ; Thu, 5 Jan 2012 09:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.176 X-Spam-Level: X-Spam-Status: No, score=-102.176 tagged_above=-999 required=5 tests=[AWL=0.423, 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 tqKovvw4YN-f for ; Thu, 5 Jan 2012 09:53:59 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id EBDD121F8775 for ; Thu, 5 Jan 2012 09:53:57 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway1.sdi.trendnet.org [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id B872E17400FA for ; Thu, 5 Jan 2012 17:53:56 +0000 (UTC) Message-ID: <4F05E3B8.5030305@mail-abuse.org> Date: Thu, 05 Jan 2012 09:54:00 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Protocol Definition References: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> <4F05B856.9050205@dcrocker.net> <3013.1325775717.451646@puncture> <4F05DA49.8050802@dcrocker.net> In-Reply-To: <4F05DA49.8050802@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 17:54:02 -0000 On 1/5/12 9:13 AM, Dave CROCKER wrote: > On 1/5/2012 7:01 AM, Dave Cridland wrote: > > On Thu Jan 5 14:48:54 2012, Dave CROCKER wrote: > >> If protocol corresponds with program or algorithm, then what is > >> the communications term that corresponds to process? > >> > >> It's tempting to say "port number", but that doesn't seem very > >> satisfying. > > > > "Session"? > > That's an appealing suggestion. It is based on a 'state' existing > between the two end points and it is above transport (so we don't > have to worry about tcp vs udp vs...). > > On the other hand, isn't a session able to have more than one > "connection" and, therefore, possibly be running more than one > protocol? Dave, Agreed. A multiple stream protocol aggregates multiple endpoints into an Association where each then signals supported protocols. Within each protocol, various algorithms are applied, often in phases such as Bind, Listen, Accept, Connect, Close, Shutdown, SendMsg, RecvMsg, GetPeerName. An algorithm might be expressed using computer languages that incorporate elaborate mathematical models, such as simple hash functions used to validate packets. One of the protocols supported is SDP Session Description Protocol that carries media over the multiple streams. This provides for Sessions, Associations and Connections. See: http://tools.ietf.org/html/draft-loreto-mmusic-sctp-sdp-07#page-3 -Doug From dave@cridland.net Thu Jan 5 13:41:55 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8CC21F88CC for ; Thu, 5 Jan 2012 13:41:55 -0800 (PST) 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 1J3qoRJzsWpY for ; Thu, 5 Jan 2012 13:41:54 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4B121F8838 for ; Thu, 5 Jan 2012 13:41:54 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 0FE511168087; Thu, 5 Jan 2012 21:41:52 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ba4+VtkZlxGz; Thu, 5 Jan 2012 21:41:49 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 19FA61168067; Thu, 5 Jan 2012 21:41:49 +0000 (GMT) Subject: Re: Protocol Definition References: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> <4F05B856.9050205@dcrocker.net> <3013.1325775717.451646@puncture> <4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org> In-Reply-To: <4F05E3B8.5030305@mail-abuse.org> MIME-Version: 1.0 Message-Id: <3013.1325799709.099423@puncture> Date: Thu, 05 Jan 2012 21:41:49 +0000 From: Dave Cridland To: Douglas Otis , IETF-Discussion Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 21:41:55 -0000 On Thu Jan 5 17:54:00 2012, Douglas Otis wrote: > Agreed. A multiple stream protocol aggregates multiple endpoints > into an Association where each then signals supported protocols. > Within each protocol, various algorithms are applied, often in > phases such as Bind, Listen, Accept, Connect, Close, Shutdown, > SendMsg, RecvMsg, GetPeerName. An algorithm might be expressed > using computer languages that incorporate elaborate mathematical > models, such as simple hash functions used to validate packets. > One of the protocols supported is SDP Session Description Protocol > that carries media over the multiple streams. This provides for > Sessions, Associations and Connections. As you say, algorithms can be expressed in terms of other algorithms. And yes, "session" is certainly an overloaded term (as is protocol, mind, which can be used for extensions and "sub protocols" as well). But I think it's the best we have, and I think it's commonly used anyway. Association, to my mind, means a transport layer connection, hence it's usage in SNMP and other OSI-related things. Session isn't much less damaged, as a term, I admit, but it is in common usage. And like algorithms, and protocols, you can open up a session to find other sessions inside. So for example a session of XMPP may include: - Multiple sequential XMPP-carrying TCP sessions ("connections"), which are considered a single "Session" by dint of using XEP-0198 (An "XMPP Extension Protocol") to glue them together. - Jingle negotiations, which speak an XML adaptation of SDP, negotiating RTP sessions for A/V. Now, it's entirely fair to say that your XMPP session may include multiple TCP sessions, and each TCP session speaking XMPP may use Jingle sessions to negotiate multiple media sessions. We have lots of terms that require qualification to be of any use, and "session", "protocol", and even "connection" all need this. Dave. (Sent over a mail session using both IMAP and ESMTP sessions in concert with an ACAP session). -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From paul.hoffman@vpnc.org Thu Jan 5 14:05:55 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CC421F88DF for ; Thu, 5 Jan 2012 14:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 OqXlWNdTQYH8 for ; Thu, 5 Jan 2012 14:05:54 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9C76421F88DC for ; Thu, 5 Jan 2012 14:05:54 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q05M5rYM096015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 5 Jan 2012 15:05:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Requirements for improving IETF remote participation Date: Thu, 5 Jan 2012 14:05:53 -0800 Message-Id: To: IETF Discussion Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 22:05:55 -0000 Greetings again. As Ray Pelletier said on this list earlier, I have been = tasked with creating a set of requirements for the IETF's remote = participation system (RPS). The first draft is now at = . The = discussion of the requirements is happening on the "vmeet" mailing list; = see . This first draft compiles many (but certainly not all!) of the comments = I have heard so far, but I expect it to change a fair amount in the = coming months. If you are active in the IETF, even if you rarely or = never come to IETF meetings, your input is welcome. --Paul Hoffman From fernando.gont.netbook.win@gmail.com Thu Jan 5 17:03:34 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B7A11E8097 for ; Thu, 5 Jan 2012 17:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 ogoKi1Nnazuj for ; Thu, 5 Jan 2012 17:03:34 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C040E11E80AD for ; Thu, 5 Jan 2012 17:03:29 -0800 (PST) Received: by mail-yw0-f44.google.com with SMTP id j72so478055yhj.31 for ; Thu, 05 Jan 2012 17:03:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=5EfFdFNFGZN7H6inuiqNpHzSF2NvJ8DLpDqyP/F7DGo=; b=Q8q2nKPZQBrkiM8V99HmU6C6k4qGYvAwRJt8AiUOfi0oJX9V1Furkl7qVq210H2hsa AdawdY/W2Qcrrr/eW+OnMee86y1wIYmgcrKYC5X+iCuPt2jBHL2ki/sOi62Wh9gXP+oa 6cJl8OezCEw4JPOuUFwWDzLQOVtl57CGr5S8c= Received: by 10.236.154.37 with SMTP id g25mr4791364yhk.112.1325811809631; Thu, 05 Jan 2012 17:03:29 -0800 (PST) Received: from [192.168.123.102] ([190.48.248.59]) by mx.google.com with ESMTPS id f17sm10737340ann.21.2012.01.05.17.03.22 (version=SSLv3 cipher=OTHER); Thu, 05 Jan 2012 17:03:28 -0800 (PST) Sender: Fernando Gont Message-ID: <4F062286.5060903@gont.com.ar> Date: Thu, 05 Jan 2012 19:21:58 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: Protocol Definition References: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> <4F05B856.9050205@dcrocker.net> In-Reply-To: <4F05B856.9050205@dcrocker.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 01:03:34 -0000 On 01/05/2012 11:48 AM, Dave CROCKER wrote: > If protocol corresponds with program or algorithm, then what is the > communications term that corresponds to process? "Protocol Machine". or "Protocol Instance". Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From dhc@dcrocker.net Thu Jan 5 19:03:44 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937C821F88CF for ; Thu, 5 Jan 2012 19:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.849 X-Spam-Level: X-Spam-Status: No, score=-6.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 M07OREXWo9ls for ; Thu, 5 Jan 2012 19:03:44 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE9421F88C8 for ; Thu, 5 Jan 2012 19:03:40 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0633VnS006473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jan 2012 19:03:37 -0800 Message-ID: <4F06647E.2010905@dcrocker.net> Date: Thu, 05 Jan 2012 19:03:26 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Dave Cridland Subject: Re: Protocol Definition References: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> <4F05B856.9050205@dcrocker.net> <3013.1325775717.451646@puncture> <4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org> <3013.1325799709.099423@puncture> In-Reply-To: <3013.1325799709.099423@puncture> 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, 05 Jan 2012 19:03:38 -0800 (PST) Cc: IETF-Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 03:03:44 -0000 On 1/5/2012 1:41 PM, Dave Cridland wrote: > Association, to my mind, means a transport layer connection, hence it's usage in > SNMP and other OSI-related things. > > Session isn't much less damaged, as a term, I admit, but it is in common usage. > And like algorithms, and protocols, you can open up a session to find other > sessions inside. Actually, my recollection is that 'association' was an application-level construct from OSI. But I came to the same conclusion as you: "session" is an established term in IETF parlance and has the basic reality of describing a protocol in operation between two (or more?) hosts/endsystems/endpoints/... Does this resonate with others? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jmh@joelhalpern.com Thu Jan 5 19:10:43 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75CC821F88DC for ; Thu, 5 Jan 2012 19:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.225 X-Spam-Level: X-Spam-Status: No, score=-102.225 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 l-Brxq6qeOd9 for ; Thu, 5 Jan 2012 19:10:43 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 229B721F88DA for ; Thu, 5 Jan 2012 19:10:42 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id E60EACCFFB for ; Thu, 5 Jan 2012 19:10:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id AC8AF1C08CF; Thu, 5 Jan 2012 19:10:32 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.101] (pool-71-161-50-89.clppva.btas.verizon.net [71.161.50.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id D73DE1C08CC; Thu, 5 Jan 2012 19:10:31 -0800 (PST) Message-ID: <4F06662A.6070504@joelhalpern.com> Date: Thu, 05 Jan 2012 22:10:34 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: Protocol Definition References: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> <4F05B856.9050205@dcrocker.net> <3013.1325775717.451646@puncture> <4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org> <3013.1325799709.099423@puncture> <4F06647E.2010905@dcrocker.net> In-Reply-To: <4F06647E.2010905@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF-Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 03:10:43 -0000 I suspect that the "correct" choices depends upon how you look at the analogy. What seemed to me the closest analog to "process" would be the actual messages on the wires. yours, Joel On 1/5/2012 10:03 PM, Dave CROCKER wrote: > > > On 1/5/2012 1:41 PM, Dave Cridland wrote: >> Association, to my mind, means a transport layer connection, hence >> it's usage in >> SNMP and other OSI-related things. >> >> Session isn't much less damaged, as a term, I admit, but it is in >> common usage. >> And like algorithms, and protocols, you can open up a session to find >> other >> sessions inside. > > > Actually, my recollection is that 'association' was an application-level > construct from OSI. > > But I came to the same conclusion as you: "session" is an established > term in IETF parlance and has the basic reality of describing a protocol > in operation between two (or more?) hosts/endsystems/endpoints/... > > Does this resonate with others? > > d/ From dhc@dcrocker.net Thu Jan 5 19:17:25 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFEB21F8829 for ; Thu, 5 Jan 2012 19:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.821 X-Spam-Level: X-Spam-Status: No, score=-6.821 tagged_above=-999 required=5 tests=[AWL=-0.222, 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 EMAhCeNWSznO for ; Thu, 5 Jan 2012 19:17:24 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 845AF21F8824 for ; Thu, 5 Jan 2012 19:17:24 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q063HIAM006780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jan 2012 19:17:24 -0800 Message-ID: <4F0667B9.30604@dcrocker.net> Date: Thu, 05 Jan 2012 19:17:13 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Joel M. Halpern" Subject: Re: Protocol Definition References: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> <4F05B856.9050205@dcrocker.net> <3013.1325775717.451646@puncture> <4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org> <3013.1325799709.099423@puncture> <4F06647E.2010905@dcrocker.net> <4F06662A.6070504@joelhalpern.com> In-Reply-To: <4F06662A.6070504@joelhalpern.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]); Thu, 05 Jan 2012 19:17:24 -0800 (PST) Cc: IETF-Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 03:17:25 -0000 On 1/5/2012 7:10 PM, Joel M. Halpern wrote: > I suspect that the "correct" choices depends upon how you look at the analogy. > What seemed to me the closest analog to "process" would be the actual messages > on the wires. Nah. A message on the wire is a single unit in an activity. And taken on its own, in the host or on the wire, it's actually static. It isn't the activity. A process is an activity. The challenge is a term for the /flow/ of messages. It would be nice if it were a single word. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From narten@us.ibm.com Thu Jan 5 21:53:10 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E413D11E8075 for ; Thu, 5 Jan 2012 21:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.449 X-Spam-Level: X-Spam-Status: No, score=-105.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_TOOL=2.3, 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 3NueiyakaTlb for ; Thu, 5 Jan 2012 21:53:10 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAC821F87E4 for ; Thu, 5 Jan 2012 21:53:08 -0800 (PST) Received: from /spool/local by e2.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 6 Jan 2012 00:53:07 -0500 Received: from d01relay07.pok.ibm.com (9.56.227.147) by e2.ny.us.ibm.com (192.168.1.102) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 6 Jan 2012 00:53:04 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q065r4Ti3035264 for ; Fri, 6 Jan 2012 00:53:04 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q065r41H032330 for ; Fri, 6 Jan 2012 00:53:04 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.192.143]) by d01av04.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q065r3tT032296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Jan 2012 00:53:03 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id q065r2QF007153 for ; Fri, 6 Jan 2012 00:53:03 -0500 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.14.4/8.14.4/Submit) id q065r27D007108 for ietf@ietf.org; Fri, 6 Jan 2012 00:53:02 -0500 From: Thomas Narten Message-Id: <201201060553.q065r27D007108@rotala.raleigh.ibm.com> Date: Fri, 06 Jan 2012 00:53:02 -0500 To: ietf@ietf.org Subject: Weekly posting summary for ietf@ietf.org User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 12010605-5112-0000-0000-000003C4A501 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 05:53:11 -0000 Total of 59 messages in the last 7 days. script run at: Fri Jan 6 00:53:02 EST 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 11.86% | 7 | 12.60% | 57079 | evnikita2@gmail.com 8.47% | 5 | 8.91% | 40337 | john-ietf@jck.com 8.47% | 5 | 7.46% | 33795 | derhoermi@gmx.net 8.47% | 5 | 6.79% | 30739 | dhc@dcrocker.net 6.78% | 4 | 6.67% | 30218 | tlr@w3.org 3.39% | 2 | 6.98% | 31588 | eburger@standardstrack.com 3.39% | 2 | 3.08% | 13944 | julian.reschke@gmx.de 3.39% | 2 | 2.95% | 13375 | dave@cridland.net 3.39% | 2 | 2.83% | 12836 | john@jck.com 1.69% | 1 | 3.24% | 14685 | ron.even.tlv@gmail.com 1.69% | 1 | 2.65% | 11995 | david.black@emc.com 1.69% | 1 | 2.42% | 10981 | pthubert@cisco.com 1.69% | 1 | 2.30% | 10413 | cyrus@daboo.name 1.69% | 1 | 2.00% | 9065 | bob.hinden@gmail.com 1.69% | 1 | 1.98% | 8972 | kathleen.moriarty@emc.com 1.69% | 1 | 1.92% | 8676 | mstjohns@comcast.net 1.69% | 1 | 1.67% | 7580 | tnadeau@lucidvision.com 1.69% | 1 | 1.65% | 7474 | wesley.george@twcable.com 1.69% | 1 | 1.55% | 7001 | d3e3e3@gmail.com 1.69% | 1 | 1.54% | 6984 | tglassey@earthlink.net 1.69% | 1 | 1.50% | 6770 | brian.e.carpenter@gmail.com 1.69% | 1 | 1.46% | 6629 | narten@us.ibm.com 1.69% | 1 | 1.44% | 6522 | stpeter@stpeter.im 1.69% | 1 | 1.44% | 6502 | jmh@joelhalpern.com 1.69% | 1 | 1.41% | 6390 | ole@cisco.com 1.69% | 1 | 1.41% | 6365 | dotis@mail-abuse.org 1.69% | 1 | 1.41% | 6364 | yaakov_s@rad.com 1.69% | 1 | 1.35% | 6118 | eosborne@cisco.com 1.69% | 1 | 1.35% | 6105 | andy@netconfcentral.org 1.69% | 1 | 1.31% | 5944 | fernando@gont.com.ar 1.69% | 1 | 1.29% | 5848 | kaushalshriyan@gmail.com 1.69% | 1 | 1.21% | 5495 | adrian@olddog.co.uk 1.69% | 1 | 1.18% | 5356 | paul.hoffman@vpnc.org 1.69% | 1 | 1.03% | 4685 | randy@psg.com --------+------+--------+----------+------------------------ 100.00% | 59 |100.00% | 452830 | Total From sm@resistor.net Fri Jan 6 02:05:05 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0985821F88CB for ; Fri, 6 Jan 2012 02:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 rz7ESUlHqgIp for ; Fri, 6 Jan 2012 02:05:02 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C37F121F88C9 for ; Fri, 6 Jan 2012 02:05:02 -0800 (PST) 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 q06A4rKq005227; Fri, 6 Jan 2012 02:04:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1325844299; i=@resistor.net; bh=DM6YL5K9sDFlI9KrMxBtV2WpWkQSepnrHZe+qOMhdlA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=IQ52aq9TWadAA1mmeSsltJ1TYkaUd3SIqOcDJmN8kJxpHgbQQ/IdAVCjVHvTjKq+u so9VCIrR4H4huxupkiIAILDAi8lNe67CfUKzqrbx1yX6VCjsjCf1EmqbSZyGFWbE3p tCfXV5Q6qv/neZ/n7q7Z/aLiGLAW+pHMiERz6Mh4= Message-Id: <6.2.5.6.2.20120105215913.0b943e50@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Jan 2012 02:00:08 -0800 To: IETF Discussion From: SM Subject: Re: Requirements for improving IETF remote participation In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Paul Hoffman X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 10:05:05 -0000 At 14:05 05-01-2012, Paul Hoffman wrote: >This first draft compiles many (but certainly not all!) of the >comments I have heard so far, but I expect it to change a fair >amount in the coming months. If you are active in the IETF, even if >you rarely or never come to IETF meetings, your input is welcome. 'There are two types of participants at the three-times-a-year IETF meetings: those who are at the meeting in person ("local attendees") and those who are not at the meeting in person but participate by following the meeting online ("remote attendees").' There are more than two types of participants: (a) The old boys club (b) usual attendees (c) "local" attendees (d) people who follow the work to see what is going on (e) remote attendees In Section 2: "Bar BoFs at regular IETF meetings are not listed above because they mostly happen in places where remote participation can't be scheduled." Aren't Bar BoFs informal? There are also BoFs and "side-meetings" (draft-eggert-successful-bar-bof-06). In Section 3: "Some participants think the tools are fine and are grateful that they exist" Some participants are grateful because they don't take things for granted. "Local attendees don't have a feeling for how many remote attendees are just listening like most of the local attendees." Local attendees do not care about remote participants. It is left to the reader to determine whether participant (b) gives any thought to from participant (c) (language issue). "The IETF has years of experience with the two primary tools used at its regular meetings" And yet the same issues occur again and again. "At recent IETF meetings, remote attendance is almost always less than 10% of local attendance, and is often less than 5%." It would be interesting to compare local and remote contributions as attendance can be passive. "Further, a WG chair might copy the latest information and send it to the WG mailing list, but there can be later changes." Please see "Topics to Add" at http://wiki.tools.ietf.org/group/wgchairs/ There hasn't been a lot of contributions to that web page over the last five years. The community has a culture of arguing against each other and getting RFC published as quickly as possible instead of contributing. In Section 3.2.3: "It has become fairly common for presenters to not have their presentations available for distribution until just before the WG meeting." http://www.ietf.org/mail-archive/web/ietf/current/msg70388.html The following working groups have not submitted their minutes: DHC PCP SOFTWIRE TRILL MULTRANS (BOF) RADEXT AVTCORE AVTEXT CODEC P2PSIP VIPR TSVWG Is it fairly common for WG Chairs to do nothing until an AD complains? In Section 3.3: "This method of participation often works adequately, but there are many places where it fails." The problem is the audio delay. Even if the delay was a few seconds only, that would still happen as it is difficult to manage the in-room discussion and remote participation at the same time. 'The presentation ends and is over time, so Carl says "we need to move on", so Robert never gets to ask his question.' And it can discourage Robert from further participation. "Sam only volunteered to be scribe because no one else would do it" Instead of asking for scribes, it might be helpful to explain what is required of a scribe and see that people are not disadvantaged from participating when they volunteer. In Section 3.4: "Although the previous section may seem like it is a bit harsh on WG chairs" Stating the facts can be a harsh. "Chris cannot do something about the situation without making Sam look bad." And the WG Chair ends up looking bad. In Section 3.5, I'll mention that Meetecho can also be used for remote presentations (I suggest asking them about the details instead of assuming anything). The problem with any tool is that people expect them to work. Some people do not pay attention to the details and that can cause last minute surprises. In Section 4: "Meeting rooms have many mics: one or two for the chairs, one for the presenter, and at least one for other local attendees to ask questions." And sometimes the mic does not work. In Section 4.1.2: "Remote attendees who are speaking over the audio must be visible to the local attendees." That's not a good idea if the remote participant is many time zones away. :-) In Section 4.1.3: "The instant messaging system must allow any registered user (even those registered anonymously) to post messages in the WG's or BoF's room." Isn't the current XMPP approach workable? What is the meaning of "those registered anonymously"? In Section 4.1.4: "The input format for slide presentations must be either PDF or PowerPoint." See long thread at http://www.ietf.org/mail-archive/web/ietf/current/msg70422.html about PPTX. In Section 4.2.1: "There is no such confusion in the room of local attendees because everyone has a name badge." There is confusion in the room as the name badge may not be visit or for other reasons. "The RPS tools must be available for lunch meetings scheduled by the IETF Secretariat, such as for the Security Directorate" I object to the non-inclusion of the kangaroo directorate (no offense intended). :-) In Section 4.2.2: "Mixing remote attendees into this social structure will be a daunting task, but one that has been dealt with in many remote participation systems" This is using a technical solution to solve a social problem. Going back to my first comment, participant (c) can be useful input to participant (e) as they share similar constraints. "It is not yet clear how the set of remote attendees would be treated." The same way participant (a) treat participants from outside their group. in Section 4.4: "At recent IETF meetings, there has been very little input from remote attendees even when there is a lot in the room, but that may be due to the current setup, not lack of interest." It's difficult to figure which audio stream is available for the plenaries. There isn't anyone to channel questions to the mic. While a lot of the issues covered in draft-ietf-genarea-rps-reqs-00 affect remote participation, they fall outside the scope of the IAOC. A session with 20 attendees does not have the same dynamics as one with 200 attendees. 25% participation in the first group is workable; it's not for a wider group. The Remote Participation Services takes a one size fits all approach. I suggest not trying to solve all the problems at once. The social issues could be discussed in a separate document. As for the technical issues, the requirements could target a small and manageable audience. It might be a way to gain more experience about the problems (identify what works, what can be addressed without too much effort, and what cannot be fixed). This could be done as an experiment. The alternative is to pursue the current approach. WG Chairs might be blamed for problems outside their control. On an unrelated note, the newcomers training is a failure. It tries to cover too much in a limited amount of time. There is limited interaction. Regards, -sm From tglassey@earthlink.net Fri Jan 6 04:54:01 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCBF21F890E for ; Fri, 6 Jan 2012 04:54:01 -0800 (PST) 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 sozLKN9BlHWn for ; Fri, 6 Jan 2012 04:53:57 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCA821F8908 for ; Fri, 6 Jan 2012 04:53:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=PHdKI4ucHhBjlzWPGmvp+OVhk68+tke73f0lP6hsPNYM/rNIRZpGLTaQqewTrO3v; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Opacus-Archived:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.101]) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Rj9Iy-0005VY-8s for ietf@ietf.org; Fri, 06 Jan 2012 07:53:56 -0500 Message-ID: <4F06EEDE.2080008@earthlink.net> Date: Fri, 06 Jan 2012 04:53:50 -0800 From: todd glassey User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Requirements for improving IETF remote participation References: In-Reply-To: X-Opacus-Archived: none X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec798d84b8416f8f35e7d31d7c7351317a61350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 12:54:01 -0000 On 1/5/2012 2:05 PM, Paul Hoffman wrote: > Greetings again. As Ray Pelletier said on this list earlier, I have been tasked with creating a set of requirements for the IETF's remote participation system (RPS). The first draft is now at . The discussion of the requirements is happening on the "vmeet" mailing list; see . > > This first draft compiles many (but certainly not all!) of the comments I have heard so far, but I expect it to change a fair amount in the coming months. If you are active in the IETF, even if you rarely or never come to IETF meetings, your input is welcome. > > --Paul Hoffman The key comment should be "That one can fully participate without having to bear the expense of continuous travel to the various global spots the ISOC and IETF place the meetings". The issue is whether direct in-person participation is necessary and to date it has been a mandatory part of holding office inside the IETF so this also is a concern with how it mandates access for the ADA as well. Todd > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. From jeanjour@comcast.net Fri Jan 6 05:28:43 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B8921F86B2 for ; Fri, 6 Jan 2012 05:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.299 X-Spam-Level: X-Spam-Status: No, score=-100.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3, 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 8zbbzRogQ1Pq for ; Fri, 6 Jan 2012 05:28:42 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 36C6E21F8683 for ; Fri, 6 Jan 2012 05:28:42 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta07.westchester.pa.mail.comcast.net with comcast id JDFe1i0040QuhwU57DUiSC; Fri, 06 Jan 2012 13:28:42 +0000 Received: from [10.0.1.26] ([24.218.154.214]) by omta02.westchester.pa.mail.comcast.net with comcast id JDUi1i0044dorGg3NDUiaE; Fri, 06 Jan 2012 13:28:42 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <201201060553.q065r27D007108@rotala.raleigh.ibm.com> References: <201201060553.q065r27D007108@rotala.raleigh.ibm.com> Date: Fri, 6 Jan 2012 08:20:59 -0500 To: Thomas Narten , ietf@ietf.org From: John Day Subject: Re: Weekly posting summary for ietf@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 13:28:43 -0000 Yes, "association" was an application level term in OSI. This was because the wire stringers, i.e. PTT types, had forced a definition of "connection" that was wrong. In OSI, a "connection" was between the (N+1)-entities (protocol machines). Not the (N)-entities as it should be. TCP gets this wrong as well, where connections are between port-ids that are at the layer boundary. (Connection here is used to be interchangeable with flow. Not intended to imply only those protocols with feedback mechanisms.) This error leads to all sorts of problems, which are avoided by delta-t which decouples port allocation and synchronization. The convention of the use of port-ids is to create a "connection-id," i.e. to distinguish multiple flows between the same two addresses. Early on there was considerable experimentation with how to do this. Some protocols would have a "connection-id" field and one end would number from one end of the field and the other end from the other end. That of course had problems. Since port-ids were locally unique, the idea was hit upon that concatenating them would be a simpler way to do it. The kludge of using them for application names came later. It turns out the port-id concept is crucial to getting layer boundaries right. This discussion has only touched the tip of the iceberg on the analogy of protocol and program. There is the Protocol as Program in the large, i.e. across all systems, e.g. the TCP spec laid out in the RFC. There is the protocol in a system in a layer (one might have multiple of these for different security domains or some such).and there are then multiple instances of that for each flow/connection. As to what is a protocol, someone already hit pretty close. a set of rules and formats (semantic and syntatic) which determines the communication behavior of a state machine. It has been amusing how often some think that merely writing down the format of the messages is a protocol specification. Take care, John At 0:53 -0500 2012/01/06, Thomas Narten wrote: >Total of 59 messages in the last 7 days. > >script run at: Fri Jan 6 00:53:02 EST 2012 > > Messages | Bytes | Who >--------+------+--------+----------+------------------------ > 11.86% | 7 | 12.60% | 57079 | evnikita2@gmail.com > 8.47% | 5 | 8.91% | 40337 | john-ietf@jck.com > 8.47% | 5 | 7.46% | 33795 | derhoermi@gmx.net > 8.47% | 5 | 6.79% | 30739 | dhc@dcrocker.net > 6.78% | 4 | 6.67% | 30218 | tlr@w3.org > 3.39% | 2 | 6.98% | 31588 | eburger@standardstrack.com > 3.39% | 2 | 3.08% | 13944 | julian.reschke@gmx.de > 3.39% | 2 | 2.95% | 13375 | dave@cridland.net > 3.39% | 2 | 2.83% | 12836 | john@jck.com > 1.69% | 1 | 3.24% | 14685 | ron.even.tlv@gmail.com > 1.69% | 1 | 2.65% | 11995 | david.black@emc.com > 1.69% | 1 | 2.42% | 10981 | pthubert@cisco.com > 1.69% | 1 | 2.30% | 10413 | cyrus@daboo.name > 1.69% | 1 | 2.00% | 9065 | bob.hinden@gmail.com > 1.69% | 1 | 1.98% | 8972 | kathleen.moriarty@emc.com > 1.69% | 1 | 1.92% | 8676 | mstjohns@comcast.net > 1.69% | 1 | 1.67% | 7580 | tnadeau@lucidvision.com > 1.69% | 1 | 1.65% | 7474 | wesley.george@twcable.com > 1.69% | 1 | 1.55% | 7001 | d3e3e3@gmail.com > 1.69% | 1 | 1.54% | 6984 | tglassey@earthlink.net > 1.69% | 1 | 1.50% | 6770 | brian.e.carpenter@gmail.com > 1.69% | 1 | 1.46% | 6629 | narten@us.ibm.com > 1.69% | 1 | 1.44% | 6522 | stpeter@stpeter.im > 1.69% | 1 | 1.44% | 6502 | jmh@joelhalpern.com > 1.69% | 1 | 1.41% | 6390 | ole@cisco.com > 1.69% | 1 | 1.41% | 6365 | dotis@mail-abuse.org > 1.69% | 1 | 1.41% | 6364 | yaakov_s@rad.com > 1.69% | 1 | 1.35% | 6118 | eosborne@cisco.com > 1.69% | 1 | 1.35% | 6105 | andy@netconfcentral.org > 1.69% | 1 | 1.31% | 5944 | fernando@gont.com.ar > 1.69% | 1 | 1.29% | 5848 | kaushalshriyan@gmail.com > 1.69% | 1 | 1.21% | 5495 | adrian@olddog.co.uk > 1.69% | 1 | 1.18% | 5356 | paul.hoffman@vpnc.org > 1.69% | 1 | 1.03% | 4685 | randy@psg.com >--------+------+--------+----------+------------------------ >100.00% | 59 |100.00% | 452830 | Total > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf From adrian@olddog.co.uk Fri Jan 6 07:11:07 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D3E21F87CC for ; Fri, 6 Jan 2012 07:11:07 -0800 (PST) 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 mNLcrAhStQGT for ; Fri, 6 Jan 2012 07:11:06 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id D2FEF21F87B0 for ; Fri, 6 Jan 2012 07:11:03 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q06FB1Ox003618; Fri, 6 Jan 2012 15:11:01 GMT Received: from 950129200 (adsl-89-217-79-52.adslplus.ch [89.217.79.52]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q06FAQ8W003016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jan 2012 15:10:48 GMT From: "Adrian Farrel" To: "'SM'" , "'IETF Discussion'" References: <6.2.5.6.2.20120105215913.0b943e50@resistor.net> In-Reply-To: <6.2.5.6.2.20120105215913.0b943e50@resistor.net> Subject: RE: Requirements for improving IETF remote participation Date: Fri, 6 Jan 2012 15:10:26 -0000 Message-ID: <005201cccc85$64342f40$2c9c8dc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJXYhZqoJe2iM/GevVX+4l0xZRKxwGR8PtTlN2x3EA= Content-Language: en-gb Cc: 'Paul Hoffman' X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 15:11:07 -0000 SM wrote: > There are more than two types of participants: Not sure if I count as an "old boy" or not. Don't think I am as old as I feel. Anyway, I think it important to add to the categories of participants those who *are* local participants, but who are not in the room where the meeting is taking place. A number of people attempt to follow multiple parallel meetings using jabber and/or headphones. For them, speaking participation usually requires someone to channel over jabber, or a sprint between rooms. Such participants, like remote participants, would benefit from having the projector streamed as well as audio. > In Section 2: > > "Bar BoFs at regular IETF meetings are not listed above > because they mostly happen in places where remote participation can't > be scheduled." > > Aren't Bar BoFs informal? There are also BoFs and "side-meetings" > (draft-eggert-successful-bar-bof-06). Yes. Please do not make *any* provisions for remote participation at side meetings. If the organisers want to arrange that sort of thing they can put their mobile phone on the bar! > In Section 3.3: > > "This method of participation often works adequately, but there are > many places where it fails." > > The problem is the audio delay. Even if the delay was a few seconds > only, that would still happen as it is difficult to manage the > in-room discussion and remote participation at the same time. I have found that the audio delay builds. Disconnecting and reconnecting to the meeting catches you up. > In Section 4.1.2: > > "Remote attendees who are speaking over the > audio must be visible to the local attendees." > > That's not a good idea if the remote participant is many time zones away. :-) It is also not a requirement and may be impractical on low b/w links. Should I send a short video of me typing this email? Cheers, Adrian From paul.hoffman@vpnc.org Fri Jan 6 07:56:59 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F4C21F87E9 for ; Fri, 6 Jan 2012 07:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 C-Y4CoGSXqQ2 for ; Fri, 6 Jan 2012 07:56:59 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6487121F87E1 for ; Fri, 6 Jan 2012 07:56:59 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q06FuwBN031475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Jan 2012 08:56:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Subject: Re: Requirements for improving IETF remote participation Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <6.2.5.6.2.20120105215913.0b943e50@resistor.net> Date: Fri, 6 Jan 2012 07:56:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <25537A12-AD25-4C13-8412-CE51A8F9663E@vpnc.org> References: <6.2.5.6.2.20120105215913.0b943e50@resistor.net> To: SM X-Mailer: Apple Mail (2.1251.1) Cc: IETF Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 15:56:59 -0000 Thanks for the comments, but it would be *really* good if you took them = to the vmeet mailing list: On Jan 5, 2012, at 2:05 PM, Paul Hoffman wrote: > The discussion of the requirements is happening on the "vmeet" mailing = list; see . You of all people should be aware of the utility of having discussions = on one focused mailing list. :-) --Paul= From marshall.eubanks@gmail.com Fri Jan 6 08:48:08 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E9021F87EA for ; Fri, 6 Jan 2012 08:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.571 X-Spam-Level: X-Spam-Status: No, score=-103.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, 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 1CYYPsIg-kqq for ; Fri, 6 Jan 2012 08:48:07 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3C221F87E1 for ; Fri, 6 Jan 2012 08:48:07 -0800 (PST) Received: by obcuz6 with SMTP id uz6so2375217obc.31 for ; Fri, 06 Jan 2012 08:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=e70Qb6ykWQeivNBQAQsXStXvaeJze0PWH8Ipxzbo2Ew=; b=jdyoJZ174MV7lm70j8+4v54sDwcrg/7/YUl+hsJWMotKHEi3c97KfPlDCqSJ2Epzou tbAcZOI4ggfxOF35MubUE+iJ+XLYhOxIzxOt9XFEheKFDGx7q/cQ1rxi2n6izGGQUWc3 VOkW9rTy5vcAkioQuo4ymv06ZxTBzRgyAhDyo= MIME-Version: 1.0 Received: by 10.182.111.36 with SMTP id if4mr5417651obb.38.1325868486118; Fri, 06 Jan 2012 08:48:06 -0800 (PST) Received: by 10.182.72.199 with HTTP; Fri, 6 Jan 2012 08:48:06 -0800 (PST) In-Reply-To: <005201cccc85$64342f40$2c9c8dc0$@olddog.co.uk> References: <6.2.5.6.2.20120105215913.0b943e50@resistor.net> <005201cccc85$64342f40$2c9c8dc0$@olddog.co.uk> Date: Fri, 6 Jan 2012 11:48:06 -0500 Message-ID: Subject: Re: Requirements for improving IETF remote participation From: Marshall Eubanks To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SM , IETF Discussion , Paul Hoffman X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 16:48:08 -0000 On Fri, Jan 6, 2012 at 10:10 AM, Adrian Farrel wrote: > SM wrote: > >> There are more than two types of participants: > > Not sure if I count as an "old boy" or not. Don't think I am as old as I = feel. > > Anyway, I think it important to add to the categories of participants tho= se who > *are* local participants, but who are not in the room where the meeting i= s > taking place. A number of people attempt to follow multiple parallel meet= ings > using jabber and/or headphones. For them, speaking participation usually > requires someone to channel over jabber, or a sprint between rooms. > > Such participants, like remote participants, would benefit from having th= e > projector streamed as well as audio. > >> In Section 2: >> >> =A0 =A0"Bar BoFs at regular IETF meetings are not listed above >> =A0 =A0 because they mostly happen in places where remote participation = can't >> =A0 =A0 be scheduled." >> >> Aren't Bar BoFs informal? =A0There are also BoFs and "side-meetings" >> (draft-eggert-successful-bar-bof-06). > > Yes. Please do not make *any* provisions for remote participation at side > meetings. If the organisers want to arrange that sort of thing they can p= ut > their mobile phone on the bar! > >> In Section 3.3: >> >> =A0 =A0"This method of participation often works adequately, but there a= re >> =A0 =A0 many places where it fails." >> >> The problem is the audio delay. =A0Even if the delay was a few seconds >> only, that would still happen as it is difficult to manage the >> in-room discussion and remote participation at the same time. > > I have found that the audio delay builds. Disconnecting and reconnecting = to the > meeting catches you up. > >> In Section 4.1.2: >> >> =A0 =A0"Remote attendees who are speaking over the >> =A0 =A0 audio must be visible to the local attendees." >> >> That's not a good idea if the remote participant is many time zones away= . :-) > > It is also not a requirement and may be impractical on low b/w links. > Should I send a short video of me typing this email? In this context "seeing" and "visible" are frequently used to mean that the fact of participation is visible, not that they are "on screen," and that is how I interpreted the above. For example, WebEx and similar services show you who has joined the meeting, and who of that list is speaking, but not (as generally used in the IETF) a video feed. So, you do get to see who's speaking, even if you can't see them on screen. Also, other remote attendees should see this too. So, how about =A0 =A0"At a minimum the email addresses of remote attendees who are speaking over the =A0 =A0 audio must be visible to the local and remote attendees." I say email addresses should be required because - you have to give an email address to join any WG mail list and - we do not require a mapping of email addresses to legal names on WG mail lists so - this would allow for exactly the same amount of identification and privacy as on WG mail lists. Also, I suggest that we use the phrase "on video" or "on screen" to make it clear when that is specifically intended. And, on that subject, can we have a glossary in this document to describe such specialized jargon, as there is a bunch ? Regards Marshall > > Cheers, > Adrian > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From marshall.eubanks@gmail.com Fri Jan 6 08:50:42 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43E421F8961 for ; Fri, 6 Jan 2012 08:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, 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 anI7rZctla9w for ; Fri, 6 Jan 2012 08:50:42 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1550D21F8921 for ; Fri, 6 Jan 2012 08:50:42 -0800 (PST) Received: by obcuz6 with SMTP id uz6so2378536obc.31 for ; Fri, 06 Jan 2012 08:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CGi5rlHEb360QHjLH6R1b4eIupBwYTVS/M5tj4OjWxg=; b=ri+jufsY2VGGLkhXfrxXb22QS3hy2r0+60Ul7CG4V7ZXSXRAHuZVYAVtb7bCrX6/wO /faq+NaDg+K+7At3m4ujOJUTYxdaN6bh/10+vkt5UCkYPR3/1HqqTfbg91+T113o9MDB dvCLcaXL/gZsavynJEgjglpf9foN1+5U4tZA4= MIME-Version: 1.0 Received: by 10.182.111.36 with SMTP id if4mr5426603obb.38.1325868641747; Fri, 06 Jan 2012 08:50:41 -0800 (PST) Received: by 10.182.72.199 with HTTP; Fri, 6 Jan 2012 08:50:41 -0800 (PST) In-Reply-To: <005201cccc85$64342f40$2c9c8dc0$@olddog.co.uk> References: <6.2.5.6.2.20120105215913.0b943e50@resistor.net> <005201cccc85$64342f40$2c9c8dc0$@olddog.co.uk> Date: Fri, 6 Jan 2012 11:50:41 -0500 Message-ID: Subject: Re: Requirements for improving IETF remote participation From: Marshall Eubanks To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SM , IETF Discussion , Paul Hoffman X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 16:50:43 -0000 On Fri, Jan 6, 2012 at 10:10 AM, Adrian Farrel wrote: > SM wrote: > >> There are more than two types of participants: > > Not sure if I count as an "old boy" or not. Don't think I am as old as I = feel. > > Anyway, I think it important to add to the categories of participants tho= se who > *are* local participants, but who are not in the room where the meeting i= s > taking place. A number of people attempt to follow multiple parallel meet= ings > using jabber and/or headphones. For them, speaking participation usually > requires someone to channel over jabber, or a sprint between rooms. > > Such participants, like remote participants, would benefit from having th= e > projector streamed as well as audio. > >> In Section 2: >> >> =A0 =A0"Bar BoFs at regular IETF meetings are not listed above >> =A0 =A0 because they mostly happen in places where remote participation = can't >> =A0 =A0 be scheduled." >> >> Aren't Bar BoFs informal? =A0There are also BoFs and "side-meetings" >> (draft-eggert-successful-bar-bof-06). > > Yes. Please do not make *any* provisions for remote participation at side > meetings. If the organisers want to arrange that sort of thing they can p= ut > their mobile phone on the bar! > I go further : Any meeting that uses IETF RPS is an official IETF meeting subject to the NOTE WELL and (where appropriate) IETF rules for announcements and minute taking. Regards Marshall >> In Section 3.3: >> >> =A0 =A0"This method of participation often works adequately, but there a= re >> =A0 =A0 many places where it fails." >> >> The problem is the audio delay. =A0Even if the delay was a few seconds >> only, that would still happen as it is difficult to manage the >> in-room discussion and remote participation at the same time. > > I have found that the audio delay builds. Disconnecting and reconnecting = to the > meeting catches you up. > >> In Section 4.1.2: >> >> =A0 =A0"Remote attendees who are speaking over the >> =A0 =A0 audio must be visible to the local attendees." >> >> That's not a good idea if the remote participant is many time zones away= . :-) > > It is also not a requirement and may be impractical on low b/w links. > Should I send a short video of me typing this email? > > Cheers, > Adrian > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From gash5107@yahoo.com Thu Jan 5 10:52:05 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A4421F887F for ; Thu, 5 Jan 2012 10:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 H94oKvF-tRzr for ; Thu, 5 Jan 2012 10:52:02 -0800 (PST) Received: from nm21-vm1.bullet.mail.ne1.yahoo.com (nm21-vm1.bullet.mail.ne1.yahoo.com [98.138.91.46]) by ietfa.amsl.com (Postfix) with SMTP id B757521F8869 for ; Thu, 5 Jan 2012 10:52:01 -0800 (PST) Received: from [98.138.90.48] by nm21.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jan 2012 18:51:55 -0000 Received: from [98.138.89.250] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jan 2012 18:51:55 -0000 Received: from [127.0.0.1] by omp1042.mail.ne1.yahoo.com with NNFMP; 05 Jan 2012 18:51:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 418550.59574.bm@omp1042.mail.ne1.yahoo.com Received: (qmail 13720 invoked by uid 60001); 5 Jan 2012 18:51:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1325789515; bh=jq79mEowR4GmxBrmDLd3SSGU5qp7hB++U1P7pVcCqZE=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=mJCuR678arp4UGABWeOukJAd/c8MsDTQ4MS27sM9/OTvHkXt2SNNvn4PhlD46VSz3or3Pq2Jw77qcoXaqBCNlfRI156b/xT++tOrcFK8qFWkAgT93QaylZ39RyQ7TZUq9MiiFIEp4DktTvThbIMFtcnNsYmVzg15HpNi8+6VbeY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=E9ITPS/lpAWrLlyIZC75lpFUy58b14snjPnmxktLPCfVhh8QE84EWpE1QI8mTQqy06Ns8Zx05weY3YksCHHTFiBmtdTHg6xFdrGHaqaKOSquUh6KKHKvpRcsYIDVbe7wMmQrBNKEyJNlE4blj4n7jYAZayE/JlGzZg7qSbw9V78=; X-YMail-OSG: q_SDHP4VM1mM7Y7wjX8MCIYINsj7JrBkshOkAvXYOY4oQev L.y40Pksk3GeialF6LcH7U9WhH.dkyCEqySn8X6y412fL9jm07krVbByLixb vd.9tTcDEDJcuGifhq6wdr_QF0c3W7.KWmqS8Yj4p6I.B_lOyi1YRSw.NAAc NsHEhd1dW7llpVqFh1xmaS3b1N2GBp3jMoDXCiALzCv0I0qeO.yQrReV.4jX sPcEvYyET4wVf0VEq._3kUJHlShOakkocHiinPdLEyrbayGo6BLisAyaEWU5 8oCEQvXa73N29gMQ8RzTq9Oe59iHbkRVnEfnamp8b1sJD9Gwjj6onZFRFbFK MfsUA6KWDid87mRkT37C0bmcu9NCKIOsuUl3Q5oapV4JRkUHOnN2.xqKcyll aOKCO6BnUp0HjkdVUYeAyGVU96_.QeiHSsbV6_g-- Received: from [71.233.102.170] by web125905.mail.ne1.yahoo.com via HTTP; Thu, 05 Jan 2012 10:51:55 PST X-Mailer: YahooMailWebService/0.8.115.331698 References: Message-ID: <1325789515.13158.YahooMailNeo@web125905.mail.ne1.yahoo.com> Date: Thu, 5 Jan 2012 10:51:55 -0800 (PST) From: Gerald Ash Subject: Re: Gen-ART review of draft-ash-gcac-algorithm-spec-03.txt To: "kathleen.moriarty@emc.com" , "gen-art@ietf.org" , "ietf@ietf.org" , "draft-ash-gcac-algorithm-spec.all@tools.ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-2119685684-1575650744-1325789515=:13158" X-Mailman-Approved-At: Fri, 06 Jan 2012 09:19:43 -0800 Cc: "dave.mcdysan@verizon.com" , Jerry Ash , Leeyoung , young lee X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Gerald Ash List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 18:52:05 -0000 ---2119685684-1575650744-1325789515=:13158 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Kathleen,=0A=A0=0AThanks for your review.=A0 We'll pick up these editori= al changes as RFC Editor notes.=0A=A0=0AThanks again,=0AJerry=0A=0A=0A_____= ___________________________=0AFrom: "kathleen.moriarty@emc.com" =0ATo: gen-art@ietf.org; ietf@ietf.org; draft-ash-gcac-algo= rithm-spec.all@tools.ietf.org =0ACc: gash5107@yahoo.com; dave.mcdysan@veriz= on.com =0ASent: Wednesday, January 4, 2012 11:03 AM=0ASubject: Gen-ART revi= ew of draft-ash-gcac-algorithm-spec-03.txt=0A=0AI am the assigned Gen-ART r= eviewer for this draft. For background on=0AGen-ART, please see the FAQ at= =0A.=0A=0APlease r= esolve these comments along with any other Last Call comments=0Ayou may rec= eive.=0A=0ADocument: draft-ash-gcac-algorithm-spec-03.txt=0AReviewer: Kathl= een M. Moriarty=0AReview Date: 1/4/12=0AIETF LC End Date: 1/11/12=0AIESG Te= lechat date: 1/19/12=0A=0ASummary:=A0 The draft is essentially ready with n= its.=A0 The last nit could be a minor issue, but has a simple resolution.= =A0 The security considerations section points out possible attacks and sho= uld also require logging of events tied to the users/groups responsible for= those actions.=0A=0AMajor issues:=0A=0AMinor issues:=0A=0ANits/editorial c= omments:=0AThe last line of the abstract should be on the previous line.=0A= =0AOn the second to last paragraph of page 8, the following acronym is list= ed: emergency traffic (ETS), should there be something for the "S"?=0AThe s= econd to last sentence of the same paragraph:=0AConsider changing from:=0A"= Several=0A=A0 assured forwarding (AF) queues may be used for various data t= raffic,=0A=A0 for example, premium private data traffic, premium public dat= a=0A=A0 traffic, and a separate best-effort queue is used for the best-effo= rt=0A=A0 traffic."=0ATo: "Several=0A=A0 assured forwarding (AF) queues may = be used for various data traffic,=0A=A0 for example, premium private data t= raffic, premium public data=0A=A0 traffic, and a separate best-effort queue= for the best-effort=0A=A0 traffic."=0A=0AFirst paragraph of section 3: Con= sider removing "however", it doesn't add anything:=0AChange from: "Requirin= g nodes to expose detailed and=0A=A0 up-to-date CAC information, however, m= ay result in unacceptably high=0A=A0 rate of routing updates."=0ATo: "Requi= ring nodes to expose detailed and=0A=A0 up-to-date CAC information may resu= lt in unacceptably high=0A=A0 rate of routing updates."=0A=0ASecond paragra= ph of Section 3: Consider removing "and cannot" - it is unnecessary:=0AChan= ge from: "This common=0A=A0 interpretation is in the form of an MPLS GCAC a= lgorithm to be=0A=A0 performed during MPLS LSP path selection to determine = if a link or=0A=A0 node can or cannot be included for consideration."=0ATo:= "This common=0A=A0 interpretation is in the form of an MPLS GCAC algorithm= to be=0A=A0 performed during MPLS LSP path selection to determine if a lin= k or=0A=A0 node can be included for consideration."=0A=0ASection 3.2: Consi= der breaking the first sentence into two:=0A"The assumption behind the MPLS= GCAC is that the ratio between BWMck,=0A=A0 which represents the safety ma= rgin the node is putting above the=0A=A0 SBWck, and the standard deviation = of the SBWck defined below does not=0A=A0 change significantly as one new a= ggregate flow is added on the link."=0A=0ASecurity Considerations:=0AI thin= k a requirement for logging should be specified here as well.=A0 If an atta= ck were to occur, you will want the user/group and actions taken to be logg= ed to trace the attack.=A0 Without this, the other enforcement mechanisms a= re inadequate.=0A=0ASentence that spans page 17-18 should be broken into mu= ltiple sentences (readable, but long - as is the following sentence):=0A"Fo= r=0A=A0 example, if aggregate flow requests are made for CT LSP bandwidth= =0A=A0 that exceeds the current DSTE tunnel bandwidth allocation, the GEF= =0A=A0 initiates a bandwidth modification request on the appropriate LSP(s)= ,=0A=A0 which may entail increasing the current LSP bandwidth allocation by= a=0A=A0 discrete increment of bandwidth denoted here as DBW, where DBW is = the=0A=A0 additional amount needed by the current aggregate flow request."= =0A=0AThere is an extra line in the second line of A.1.=0A=0A=0A=0AThanks,= =0AKathleen ---2119685684-1575650744-1325789515=:13158 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
      Hi Kathleen,
       
      Thanks for your revi= ew.  We'll pick up these editorial changes as RFC Editor notes.=
       
      Thanks again,=
      Jerry

      From:= "kathleen.moriarty@emc.com" <kathleen.moriarty@emc.com>To: gen-art@ietf.org; iet= f@ietf.org; draft-ash-gcac-algorithm-spec.all@tools.ietf.org
      Cc: gash5107@yahoo.com; dave.mcdysan@= verizon.com
      Sent: Wedne= sday, January 4, 2012 11:03 AM
      Subj= ect: Gen-ART review of draft-ash-gcac-algorithm-spec-03.txt
      <= /FONT>
      I am the assigned Gen-ART reviewer for this draft. For background on
      Gen-ART, please see the FAQ at
      <http://wiki.tools.iet= f.org/area/gen/trac/wiki/GenArtfaq>.

      Please resolve these com= ments along with any other Last Call comments
      you may receive.

      Do= cument: draft-ash-gcac-algorithm-spec-03.txt
      Reviewer: Kathleen M. Moria= rty
      Review Date: 1/4/12
      IETF LC End Date: 1/11/12
      IESG Telechat da= te: 1/19/12

      Summary:  The draft is essentially ready with nits.=   The last nit could be a minor issue, but has a simple resolution.&nb= sp; The security considerations section points out possible attacks and sho= uld also require logging of events tied to the users/groups responsible for= those actions.

      Major issues:

      Minor issues:

      Nits/edito= rial comments:
      The last line of the abstract should be on the previous l= ine.

      On the second to last paragraph of page 8, the following acronym is listed: emergency traffic (ETS), should there be something for = the "S"?
      The second to last sentence of the same paragraph:
      Consider = changing from:
      "Several
        assured forwarding (AF) queues may be = used for various data traffic,
        for example, premium private data = traffic, premium public data
        traffic, and a separate best-effort = queue is used for the best-effort
        traffic."
      To: "Several
      &n= bsp; assured forwarding (AF) queues may be used for various data traffic,  for example, premium private data traffic, premium public data
      =   traffic, and a separate best-effort queue for the best-effort
      &nb= sp; traffic."

      First paragraph of section 3: Consider removing "howev= er", it doesn't add anything:
      Change from: "Requiring nodes to expose de= tailed and
        up-to-date CAC information, however, may result in una= cceptably high
        rate of routing updates."
      To: "Requiring nodes to expose detailed and
        up-to-date CAC information may resu= lt in unacceptably high
        rate of routing updates."

      Second p= aragraph of Section 3: Consider removing "and cannot" - it is unnecessary:<= BR>Change from: "This common
        interpretation is in the form of an = MPLS GCAC algorithm to be
        performed during MPLS LSP path selectio= n to determine if a link or
        node can or cannot be included for co= nsideration."
      To: "This common
        interpretation is in the form o= f an MPLS GCAC algorithm to be
        performed during MPLS LSP path sel= ection to determine if a link or
        node can be included for conside= ration."

      Section 3.2: Consider breaking the first sentence into two:=
      "The assumption behind the MPLS GCAC is that the ratio between BWMck,  which represents the safety margin the node is putting above the  SBWck, and the standard deviation of the SBWck defined below does not
        change significantly as one new aggregate flow is= added on the link."

      Security Considerations:
      I think a requireme= nt for logging should be specified here as well.  If an attack were to= occur, you will want the user/group and actions taken to be logged to trac= e the attack.  Without this, the other enforcement mechanisms are inad= equate.

      Sentence that spans page 17-18 should be broken into multipl= e sentences (readable, but long - as is the following sentence):
      "For  example, if aggregate flow requests are made for CT LSP bandwidth  that exceeds the current DSTE tunnel bandwidth allocation, the GEF=
        initiates a bandwidth modification request on the appropriate LS= P(s),
        which may entail increasing the current LSP bandwidth alloc= ation by a
        discrete increment of bandwidth denoted here as DBW, w= here DBW is the
        additional amount needed by the current aggregate flow request."

      There is an extra line in the second line = of A.1.



      Thanks,
      Kathleen



      ---2119685684-1575650744-1325789515=:13158-- From ben@nostrum.com Thu Jan 5 14:32:48 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5609921F88CE; Thu, 5 Jan 2012 14:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 jaqhfyuKWzow; Thu, 5 Jan 2012 14:32:47 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A0B6B21F88B1; Thu, 5 Jan 2012 14:32:45 -0800 (PST) Received: from [10.0.1.2] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q05MWiLP071831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Jan 2012 16:32:45 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Gen-ART LC Review of draft-ietf-kitten-sasl-saml-06 Date: Thu, 5 Jan 2012 16:32:44 -0600 Message-Id: <3D6A7926-001A-409D-BC01-B45AD8C68AEC@nostrum.com> To: draft-ietf-kitten-sasl-saml.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Fri, 06 Jan 2012 09:19:43 -0800 Cc: "gen-art@ietf.org Review Team" , The IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 22:32:48 -0000 I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at = . Please resolve these comments along with any other Last Call comments = you may receive. Document: draft-ietf-kitten-sasl-saml-06 Reviewer: Ben Campbell Review Date: 2012-01-05 IETF LC End Date:2012-01-05 IESG Telechat date: (if known) Summary: This draft is on the right track for publication as a proposed = standard. However, there are a few minor issues, and sufficient = editorial issues to make the document difficult to understand.=20 *** I noticed shortly before sending this that the authors submitted = version 07 today. I have not reviewed that version--this review refers = to version 06. Major issues: None Minor issues: -- section 3.2, last paragraph: "=85 needs to correlate the TCP session = from the SASL client with the SAML authentication." Please elaborate on this correlation -- section 4, 2nd paragraph: "The SAML Idenity Provider does not have a = role in GSS-API, and is considered an internal matter for the OpenID = mechanism." Please elaborate, as this is the only mention of OpenID in the draft. It = seems out of context. (If OpenID was in fact intended, please include a = citation?) -- section 4, 3rd and 4th paragraph (paragraph a and b) These seem like protocol affecting differences. If so, they need = elaboration, such as normative statements and formal definitions, or = references to such. -- section 5, general: The section seems to need further elaboration or references -- section 6.1, step 5 (alt) Please describe the circumstances where the alternative step would = occur. (also, please spell out "alternative")=20 -- section 6.1, step 6: "The client now sends the URL to a browser for = processing." Isn't that a question of software design rather than protocol? (unless = you mean something more abstract by "browser", in which case it would = help to say so.) Also, this section compresses the interaction with the identity = provider. Why not show the details for those steps like the others? (If = you mean them to be out of scope, then why give as much detail as you = do?) -- section 6.2: The draft does not provide the decoding of the Base64 encoded parts like = it did in 6.1, Without the decodes, the example is not very = illuminating. -- section 7.4: "This is an option the user has to understand and decide = to use if the IdP is supporting it." I doubt end users will read this spec. What does this mean for = implementors? Nits/editorial comments: -- General: There are a lot of editorial and organizational issues, some of which = created difficulty in understanding the authors' intent. I noted a = number of these below, but I doubt I caught everything. I suggest this = draft have another detailed proofreading and editing pass before it = progresses. -- Pagination is strange throughout the document. (Mostly blank pages, = etc.) It's worse in the PDF version, but still not right in the text = version. -- section 1.1, 2nd paragraph: Repeating the SAML 2.0 citation here would be helpful. -- section 1.2, 1st paragraph The sentence structure makes it ambiguous whether the other side of the = or should be just certificate validation, or TLS with cert validation.=20= -- section 2, list starting in 2nd paragraph: Please leave a blank line between list items. Without it, you get a = wall-of-text effect that's difficult to read. -- section 2, list item 3: Is "service provider" a well defined term as used here? -- section 2, paragraph after 1st numbered list: "This will be discussed = below. The steps are shown from below:" Redundant sentences. Also, I assume the discussion has already been = written, so "will be" is not correct. -- section 2, 2nd paragraph after 2nd numbered list: "=85 flow appears = as follows:" Please explicitly mention the figure number. E.g. "=85 flow appears as = shown in Figure XX." -- section 2, figure 2: The numbers in parentheses are confusing. We just saw a numbered list = that sort of corresponds to this flow, but the numbers don't match up. I = realize later sections refer back to these numbers, but without some = mention of that, a reader is almost certainly going to try to correlate = this to the previous list. -- section 3, 1st paragraph: "Recall section 5 of [RFC4422] for what = needs to be described here." That reads like an author's "to do" note to himself. Has the needed = description been completed, or does it still need to be described? -- section 3, 2nd paragraph: "The name of this mechanism "SAML20"." Missing word? -- "(via "gs2-header")" Missing word? -- section 3, 3rd paragraph: "The first mechanism message from the = client to the server is the "initial-response" described below." Please explicitly mention section.=20 -- section 3, 4th paragraph: "The second mechanism message is from the = server to the client, the "authentication- request" described below." I can't parse this sentence--are there missing words? Also, please = mention section instead of saying "below". -- section 3.1, first paragraph: Is "authorization identifier" the same as "IdP-Identifier"? -- section 3.1, ABNF Is this the authoritative definition for "initial-response"? If so, = please mention that in the text. The including section does not mention = "initial-response" -- section 3.1, last paragraph: Used as follows where, the rest of this paragraph? If so, then the "used = as follows" clause is redundant. Also, the paragraph would be much = easier to read if you broke it into a bulleted list. The 3rd sentence is awkward. I suggest something like "The =85 field is = used as described in section 5." Is there a word missing from the forth sentence?=20 -- section 3.2, 1st paragraph: s/ (re)directs/ redirects . Also, what gets redirected (i.e. what is the = direct object of "redirects"?) -- section 3.2, 3rd paragraph (2nd note) I can't parse this. -- section 3.2, BNF Is this the formal definition of authentication-request? The next = paragraph suggests it is defined in a referenced document. If so, then = the repeated definition creates confusion about which document is = authoritative on the matter. (if the definition is repeated here as a = courtesy, please say so explicitly) -- section 3.2, 6th paragraph: "The client now sends=85" s/now/then. Also, It seems like these sections jump back and forth = between message definitions and a sequence of steps. I find that = confusing. It would be better to keep the "sequence of steps" and the = "message definitions" separate. But if you want each section to = represent one or more steps in a sequence, then please add some context = (e.g. "Once the widget completes the steps in section XXX, it then =85" = ). Keep in mind readers often jump directly to a section from the table = of contents. -- section 3.3, 2nd paragraph: "and SHALL be used to set state in the = server accordingly, and it shall be used by the server" Is this new normative language, or a repeat of language from the SAML = spec? -- section 4, 1st paragraph: I have difficulty parsing this. -- section 4, 2nd paragraph, final sentence: sentence fragment. -- section 5, 1st sentence: 'The "gs2-cb-flag" MUST use "n" ' =85 MUST be set to "n"? (Or even better, 'the [actor] MUST set the = [flag] to "n" ' -- section 7 " This section will address=85" Addresses ( unless you haven't addressed it yet) Also, does the GSS-API description introduce security considerations? If = not, please say so. -- section 7.1, "=85 unless a client always verify the server identity=85 = " s/verify/verifies -- section 7.3: "SASL servers should be aware that SAML IdPs will track = - to some extent - user access to their services." I'm not sure what it means for a server to be aware of this sort of = thing. You are talking about people, not servers, right? What actions do = you propose implementors take to mitigate this? -- section 7.4: s/you/users "By using the same identifier to log into every Relying Party, collusion = between Relying Parties is possible." But this isn't the Relying Party's decision, it is? I think you mean to = say, if the client (or user) does this, it create a vulnerability where = the Relying Parties can collude=85 -- section 8: I suggest breaking each IANA requested action into its own subsection. = Otherwise the second action looks like an afterthought, or a comment on = the first. From sm@resistor.net Fri Jan 6 11:45:37 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AED221F8872 for ; Fri, 6 Jan 2012 11:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 5s10+bVw3gR8 for ; Fri, 6 Jan 2012 11:45:36 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F85921F8836 for ; Fri, 6 Jan 2012 11:45:35 -0800 (PST) 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 q06JjKkS005323 for ; Fri, 6 Jan 2012 11:45:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1325879127; i=@resistor.net; bh=NwhW67QBZvQoFFjhvSi9R0RbXo+2S2M+9q/I53MTdpI=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=q8nssTi93zM9ApXUPnEdORKOrUoDVFsidL/UJ8WqORYt/zlJ/+PSWwjQhMC6QyPY8 zTvRVCt/tMVLIMRtlbeLSojDaKCGNSo6+7a3gLX916OA5TyocLCK/ikjP1M9XcCmWH Ox7g2xY2wHkkumIiLyya1G9SR9Sy50k4wUlJiDe8= Message-Id: <6.2.5.6.2.20120106103309.0acbfab0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Jan 2012 11:22:28 -0800 To: ietf@ietf.org From: SM Subject: RE: Requirements for improving IETF remote participation In-Reply-To: <005201cccc85$64342f40$2c9c8dc0$@olddog.co.uk> References: <6.2.5.6.2.20120105215913.0b943e50@resistor.net> <005201cccc85$64342f40$2c9c8dc0$@olddog.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 19:45:37 -0000 At 07:10 06-01-2012, Adrian Farrel wrote: >Not sure if I count as an "old boy" or not. Don't think I am as old as I feel. You are not in that group. BTW, it's not age related. >Yes. Please do not make *any* provisions for remote participation at side >meetings. If the organisers want to arrange that sort of thing they can put >their mobile phone on the bar! :-) >It is also not a requirement and may be impractical on low b/w links. I didn't see any discussion of low bandwidth access in the draft. Based on a comment posted last year, it looks like it will not be part of RPS. >Should I send a short video of me typing this email? No. :-) >On Jan 5, 2012, at 2:05 PM, Paul Hoffman wrote: >You of all people should be aware of the utility of having >discussions on one focused mailing list. :-) Yes, like vip. :-) I forgot the following requirement: "The specifications shall rely solely upon IETF and other open standards for all communications and interactions." The IETF uses Skype for remote presentations. It will turn a blind eye when the above requirement is bypassed. At 08:48 06-01-2012, Marshall Eubanks wrote: >I say email addresses should be required because There are XMPP identities (JID). That unfortunately does not map to a participant's email address as Jabber never reached "must have" status. Regards, -sm From marshall.eubanks@gmail.com Fri Jan 6 11:51:31 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4019321F887C for ; Fri, 6 Jan 2012 11:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.573 X-Spam-Level: X-Spam-Status: No, score=-103.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, 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 ixFTNUV2mLBz for ; Fri, 6 Jan 2012 11:51:29 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id CBE1C21F8876 for ; Fri, 6 Jan 2012 11:51:26 -0800 (PST) Received: by obcuz6 with SMTP id uz6so2586394obc.31 for ; Fri, 06 Jan 2012 11:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3TkUzxqz0W8zachbSOs0w50eMaLyDGrrypNsytj9J9g=; b=hRaxoVtKErnbGhr54h0pTW/VidxFGrRjSl8tv33dow9puC4fzQ5ueUDruwk8DCeccU ACUibqZqsec2TYXagJRIRtLoPxoJkJ7tsgaUXqrY7hTq+kP53tm9oZiX4knsf9DfBCgY 7kiQmqVJriI409WxzYgOUsNmv3jl2rZI7U+dQ= MIME-Version: 1.0 Received: by 10.182.15.105 with SMTP id w9mr5956854obc.18.1325879486423; Fri, 06 Jan 2012 11:51:26 -0800 (PST) Received: by 10.182.72.199 with HTTP; Fri, 6 Jan 2012 11:51:26 -0800 (PST) In-Reply-To: <6.2.5.6.2.20120106103309.0acbfab0@resistor.net> References: <6.2.5.6.2.20120105215913.0b943e50@resistor.net> <005201cccc85$64342f40$2c9c8dc0$@olddog.co.uk> <6.2.5.6.2.20120106103309.0acbfab0@resistor.net> Date: Fri, 6 Jan 2012 14:51:26 -0500 Message-ID: Subject: Re: Requirements for improving IETF remote participation From: Marshall Eubanks To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 19:51:31 -0000 On Fri, Jan 6, 2012 at 2:22 PM, SM wrote: > At 07:10 06-01-2012, Adrian Farrel wrote: >> >> Not sure if I count as an "old boy" or not. Don't think I am as old as I >> feel. > > > You are not in that group. =A0BTW, it's not age related. > > >> Yes. Please do not make *any* provisions for remote participation at sid= e >> meetings. If the organisers want to arrange that sort of thing they can >> put >> their mobile phone on the bar! > > > :-) > >> It is also not a requirement and may be impractical on low b/w links. > > > I didn't see any discussion of low bandwidth access in the draft. =A0Base= d on > a comment posted last year, it looks like it will not be part of RPS. > > >> Should I send a short video of me typing this email? > > > No. :-) > >> On Jan 5, 2012, at 2:05 PM, Paul Hoffman wrote: >> You of all people should be aware of the utility of having discussions o= n >> one focused mailing list. :-) > > > Yes, like vip. =A0:-) > > I forgot the following requirement: > > =A0"The specifications shall rely solely upon IETF and other open > =A0 standards for all communications and interactions." > > The IETF uses Skype for remote presentations. =A0It will turn a blind eye= when > the above requirement is bypassed. > > > At 08:48 06-01-2012, Marshall Eubanks wrote: >> >> I say email addresses should be required because > > > There are XMPP identities (JID). =A0That unfortunately does not map to a > participant's email address as Jabber never reached "must have" status. > True. Acquiring data to make that mapping would be useful, but this might to too much to require. Marshall > Regards, > -sm > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From dave@cridland.net Fri Jan 6 12:40:39 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D761C21F8737 for ; Fri, 6 Jan 2012 12:40:39 -0800 (PST) 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 s1Iwrtr81Hx8 for ; Fri, 6 Jan 2012 12:40:38 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id A77F521F8661 for ; Fri, 6 Jan 2012 12:40:37 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 9F5BE1168067; Fri, 6 Jan 2012 20:40:36 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T3FqFVsu1jA; Fri, 6 Jan 2012 20:40:34 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 0BD621168087; Fri, 6 Jan 2012 20:40:30 +0000 (GMT) Subject: Re: Requirements for improving IETF remote participation References: <6.2.5.6.2.20120105215913.0b943e50@resistor.net> In-Reply-To: <6.2.5.6.2.20120105215913.0b943e50@resistor.net> MIME-Version: 1.0 Message-Id: <28948.1325882430.043580@puncture> Date: Fri, 06 Jan 2012 20:40:30 +0000 From: Dave Cridland To: SM , Paul Hoffman , IETF-Discussion Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 20:40:39 -0000 On Fri Jan 6 10:00:08 2012, SM wrote: > In Section 4.1.3: > > "The instant messaging system must allow any registered user (even > those registered anonymously) to post messages in the WG's or > BoF's > room." > > Isn't the current XMPP approach workable? What is the meaning of > "those registered anonymously"? XMPP does allow ANONYMOUS SASL access, although such accounts are often restricted. It may mean this. It might also mean anonymous in the sense of the XEP-0045 room occupant, whose real jid can be revealed (or not) as the room's configuration dictates. As a general note, if there is specific functionality that the IETF feels is desirable from XEP-0045 or XMPP in general, the XSF would be delighted to hear about it - enough XSF participants are also IETF participants than merely discussing it here it probably fine, but if someone posts things to standards@xmpp.org that'd be great too. Dave. (Some parts of this message in some respects as XSF chair, which isn't a parallel to IETF chair, so probably best I don't dwell on it...). -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From dave@cridland.net Fri Jan 6 12:40:42 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FB111E80BD for ; Fri, 6 Jan 2012 12:40:42 -0800 (PST) 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 VIJp0LAbxUoL for ; Fri, 6 Jan 2012 12:40:41 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 2E18521F85E8 for ; Fri, 6 Jan 2012 12:40:36 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id A1092116808D; Fri, 6 Jan 2012 20:40:33 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDSoPYH+bDpo; Fri, 6 Jan 2012 20:40:29 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 8CECE1168067; Fri, 6 Jan 2012 20:40:29 +0000 (GMT) Subject: Re: Requirements for improving IETF remote participation References: <6.2.5.6.2.20120105215913.0b943e50@resistor.net> <005201cccc85$64342f40$2c9c8dc0$@olddog.co.uk> <6.2.5.6.2.20120106103309.0acbfab0@resistor.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <28948.1325882429.556558@puncture> Date: Fri, 06 Jan 2012 20:40:29 +0000 From: Dave Cridland To: Marshall Eubanks , IETF-Discussion , SM Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: 8Bit X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 20:40:42 -0000 On Fri Jan 6 19:51:26 2012, Marshall Eubanks wrote: > On Fri, Jan 6, 2012 at 2:22 PM, SM wrote: > > At 08:48 06-01-2012, Marshall Eubanks wrote: > >> > >> I say email addresses should be required because > > > > > > There are XMPP identities (JID).  That unfortunately does not map > to a > > participant's email address as Jabber never reached "must have" > status. > > > > True. Acquiring data to make that mapping would be useful, but this > might to too much to > require. XEP-0054 provides a method for discovering any email address the owner of the jid has provided. It's very widely supported, although whether people have placed an email address into their vCard is entirely up to them. (Also, JIDs look like, and might even be, the same as an email address, however they're fully internationalized, and have different resitrictions. Nevertheless, as a stable identifier for a person, they're pretty good, relatively hard to spoof, and almost as easy to obtain.) Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From scott@kitterman.com Fri Jan 6 13:27:04 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82B921F8788 for ; Fri, 6 Jan 2012 13:27:04 -0800 (PST) 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 9jkMYfTHBtyw for ; Fri, 6 Jan 2012 13:27:04 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id EB07B21F873C for ; Fri, 6 Jan 2012 13:27:03 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 1C39420E4100; Fri, 6 Jan 2012 16:27:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1325885223; bh=h4Bmbfk2RHmtSBuYtYHWnhdOyOfV0s4bCn30oTNr2Qc=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=HZB8VwKth9fj8IeEpso0yr2bHnUOPh5u4UapaxNsptDjRy60MJEnIU0OB9o0NiodH xiP0ik/bHdnmhZKYt/VI/oo3tzdDn5e3Q2hQ/szhGu5fBf9Akq+TQ9Q6ZWb3dyUm5c aDMNoqUPAMW0AK7TI8w+Tu7E9u4BImuFRQk3jUX4= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id F298520E4083; Fri, 6 Jan 2012 16:27:02 -0500 (EST) From: Scott Kitterman To: ietf@ietf.org Subject: Re: Last Call: (Authentication-Results Registration Update for SPF Results) to Proposed Standard Date: Fri, 06 Jan 2012 16:27:02 -0500 Message-ID: <1365130.JbgXqW9ph6@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-14-generic-pae; KDE/4.7.3; i686; ; ) In-Reply-To: <20120106212239.31169.16750.idtracker@ietfa.amsl.com> References: <20120106212239.31169.16750.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 21:27:04 -0000 On Friday, January 06, 2012 01:22:39 PM The IESG wrote: > The IESG has received a request from an individual submitter to consider > the following document: > - 'Authentication-Results Registration Update for SPF Results' > as a Proposed Standard This is the obvious fix to an obvious bug. It should go forward. Scott K From sm@resistor.net Sat Jan 7 08:11:54 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D9621F84F1 for ; Sat, 7 Jan 2012 08:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 LsA67CDK97GK for ; Sat, 7 Jan 2012 08:11:52 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C81121F84EF for ; Sat, 7 Jan 2012 08:11:52 -0800 (PST) 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 q07GBZYG028184 for ; Sat, 7 Jan 2012 08:11:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1325952703; i=@resistor.net; bh=KHwMXDc0wE3mIJUdSXj+0kwyzFecv7QR79nEPKPextE=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=bbFwKfAY2Virwy8Kwi7dyQ0dP0SWxW5ONDHYHIUeDFuU7pO5J9tET3A0WLA/9h0gk A1wsFvUtQWr96dUmCK6Bx9ECz9puhWTeHPcj5yAiWQ5SZEZI8GfQFIHeA0bzzdxG5I SozfmZe9yo6r/E8XsDn8I5kpUra2KQ4LrBZb4xKg= Message-Id: <6.2.5.6.2.20120107071336.0a5b7df0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 07 Jan 2012 07:41:52 -0800 To: ietf@ietf.org From: SM Subject: Re: Last Call: (Authentication-Results Registration Update for SPF Results) to Proposed Standard In-Reply-To: <20120106212239.31169.16750.idtracker@ietfa.amsl.com> References: <20120106212239.31169.16750.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 16:11:54 -0000 At 13:22 06-01-2012, The IESG wrote: >The IESG has received a request from an individual submitter to consider >the following document: >- 'Authentication-Results Registration Update for SPF Results' > as a Proposed Standard Summary: I support the publication of this draft. As a editorial nit, the Introduction Section mentions that the memo updates the IANA registries. Erratum # 2617 is also about Section 2.4.2. I suggest changing the heading of Section 3 to "Update to Section 2.4.2 of RFC 5451" and some rewording of the paragraph: The "hardfail" result value for [SPF] (and thus also for [SENDER-ID]) in Section 2.4.2 of RFC 5451 is replaced with the "fail" result value. fail: This client is explicitly not authorized to inject or relay mail using the sender's DNS domain. Note that the update affects the example in Appendix B.5. Regards, -sm From yaakov_s@rad.com Sat Jan 7 12:11:16 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C2721F848F for ; Sat, 7 Jan 2012 12:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 UWGmEbhjl1YT for ; Sat, 7 Jan 2012 12:11:15 -0800 (PST) Received: from rad.co.il (mailrelay02.rad.co.il [62.0.23.237]) by ietfa.amsl.com (Postfix) with ESMTP id AC53321F84B4 for ; Sat, 7 Jan 2012 12:11:12 -0800 (PST) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 7 Jan 2012 22:07:22 +0200 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Sat, 7 Jan 2012 22:11:03 +0200 From: Yaakov Stein To: "dcrocker@bbiw.net" , Dave Cridland Subject: RE: Protocol Definition Thread-Topic: Protocol Definition Thread-Index: AQHMyoO4uTrSvisg80qAwUBf6ZqN4pX7UmUAgACpgACAAb/WAIAAA6aAgAAk04CAAAs/AIAAP6aAgABZ3ACAAseB0A== Date: Sat, 7 Jan 2012 20:11:02 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9042C6EEA@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> <4F05B856.9050205@dcrocker.net> <3013.1325775717.451646@puncture> <4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org> <3013.1325799709.099423@puncture> <4F06647E.2010905@dcrocker.net> In-Reply-To: <4F06647E.2010905@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.232.33.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF-Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 20:11:16 -0000 X.200 - ITU's version of the OSI model - defines an "association" as peerin= g at any layer of the OSI stack. Thus an association at layer 3 is a pair of IP addresses, while an associat= ion at layer 4 is a pair of socket IDs. If the association is requested then it becomes a "connection". A "session" is an association at layer 5. A process in computation is defined as an entity that is independent=20 in the sense that it can request and own resources (e.g., CPU time and memo= ry). Many processes can exist side by side, and can even communicate via IPC, but processes do not have a hierarchy such as we have in communications. The closest thing is the fact that processes can own tasks or threads as su= b-entities (tasks are not indendent - their memory and CPU time are taken from their f= ather process). Just as an association runs protocols at different layers, a single process= frequently runs multiple algorithms. But these algorithms are usually not layered. A protocol between two entities often involves algorithms on both sides, but an association does not necessarily link two processes on the communica= ting sides. Y(J)S -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Dav= e CROCKER Sent: Friday, January 06, 2012 05:03 To: Dave Cridland Cc: IETF-Discussion Subject: Re: Protocol Definition On 1/5/2012 1:41 PM, Dave Cridland wrote: > Association, to my mind, means a transport layer connection, hence it's u= sage in > SNMP and other OSI-related things. > > Session isn't much less damaged, as a term, I admit, but it is in common = usage. > And like algorithms, and protocols, you can open up a session to find oth= er > sessions inside. Actually, my recollection is that 'association' was an application-level=20 construct from OSI. But I came to the same conclusion as you: "session" is an established term= in=20 IETF parlance and has the basic reality of describing a protocol in operati= on=20 between two (or more?) hosts/endsystems/endpoints/... Does this resonate with others? d/ --=20 Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From jeanjour@comcast.net Sat Jan 7 13:00:18 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDA221F84EC for ; Sat, 7 Jan 2012 13:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=1.150, 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 gM9YuLtNEHiu for ; Sat, 7 Jan 2012 13:00:17 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 611B321F84DA for ; Sat, 7 Jan 2012 13:00:17 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta05.westchester.pa.mail.comcast.net with comcast id Jkyx1i0040QuhwU55l0HCG; Sat, 07 Jan 2012 21:00:17 +0000 Received: from [10.0.1.26] ([24.218.154.214]) by omta02.westchester.pa.mail.comcast.net with comcast id Jl0G1i00A4dorGg3Nl0GYX; Sat, 07 Jan 2012 21:00:17 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <07F7D7DED63154409F13298786A2ADC9042C6EEA@EXRAD5.ad.rad.co.il> References: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il> <4F05B856.9050205@dcrocker.net> <3013.1325775717.451646@puncture> <4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org> <3013.1325799709.099423@puncture> <4F06647E.2010905@dcrocker.net> <07F7D7DED63154409F13298786A2ADC9042C6EEA@EXRAD5.ad.rad.co.il> Date: Sat, 7 Jan 2012 16:00:14 -0500 To: Yaakov Stein , "dcrocker@bbiw.net" , Dave Cridland From: John Day Subject: RE: Protocol Definition Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: IETF-Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 21:00:18 -0000 At 20:11 +0000 2012/01/07, Yaakov Stein wrote: >X.200 - ITU's version of the OSI model - defines an "association" as >peering at any layer of the OSI stack. >Thus an association at layer 3 is a pair of IP addresses, while an >association at layer 4 is a pair of socket IDs. Not quite. The identification is only part of what constitutes an association. The situation at layer 3 is a bit more complex since there are potentially 3 data transfer protocols in Layer 3 depending on requirements, configuration, and technology: SNAC, SNDC, and SNIC. An assoication consists of the shared state for an instance of communication among (N)-entities. (see below). It is true it is a general concept that appears in all layers. I believe I wrote that definition. (X.200 and ISO 7498 are the same document. There is not an ISO version and an ITU version.) It was inserted rather late because of the requirements for the Application Layer Structure document (ISO 9545, X.207) >If the association is requested then it becomes a "connection". No, this is not true. The association is only the shared state between the protocol entities. As I indicated in the previous email. A "connection" is more encompassing. It includes shared state from the corresponding (N+1)-entities, the (N)-service-access-points, and the (N)-entities. (The role of (N)-SAPs in the OSI Reference Model is another major flaw in the model.) >A "session" is an association at layer 5. No, I believe they would have said that a "session" was a connection at layer 5. (However, by October 1983, it was recognized that the upper 3 layers were a fiction and the protocol specifications were "adjusted" so they could be implemented as a single state machine. (This became the OSI clueless test. Anyone who built the upper 3 layers as 3 separate layers was clearly clueless.) > >A process in computation is defined as an entity that is independent >in the sense that it can request and own resources (e.g., CPU time >and memory). >Many processes can exist side by side, and can even communicate via IPC, >but processes do not have a hierarchy such as we have in communications. >The closest thing is the fact that processes can own tasks or >threads as sub-entities >(tasks are not indendent - their memory and CPU time are taken from >their father process). If you are looking at X.200. You might also look at the definitions (N)-entity-type and (N)-entity-invocation. > >Just as an association runs protocols at different layers, a single >process frequently runs multiple algorithms. Associations don't run anything. An (N)-association is the locus of shared state between two (N)-entities. Actually, (N)-entity-invocations. As I implied in my last email, the definition of "association" should have been the definition of "connection" or "flow." An association corresponded to the shared state of a single flow or connection in a single layer. The reason both were needed because the PTTs forced a wrong definition of connection in the very early going. The definition of connection was set by 1978. The definition of association did not appear until later. I would have to check, but I don't think association is the 1984 version of the Reference Model but only the 1994 edition. Some of us knew the definition of connection was wrong in 78, but we didn't have the proof yet. Doing the application layer structure provided that argument. >But these algorithms are usually not layered. > >A protocol between two entities often involves algorithms on both sides, >but an association does not necessarily link two processes on the >communicating sides. Sorry but this is incorrect. An association (as defined by X.200 does) link two processes on the communicating sides and involves algorithms on both sides. (see above) Take care, John Day Rapptorteur OSI Reference Model, 1980 - 1997 > >Y(J)S > > >-----Original Message----- >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf >Of Dave CROCKER >Sent: Friday, January 06, 2012 05:03 >To: Dave Cridland >Cc: IETF-Discussion >Subject: Re: Protocol Definition > > > >On 1/5/2012 1:41 PM, Dave Cridland wrote: >> Association, to my mind, means a transport layer connection, hence >>it's usage in >> SNMP and other OSI-related things. >> >> Session isn't much less damaged, as a term, I admit, but it is in >>common usage. >> And like algorithms, and protocols, you can open up a session to find other >> sessions inside. > > >Actually, my recollection is that 'association' was an application-level >construct from OSI. > >But I came to the same conclusion as you: "session" is an established term in >IETF parlance and has the basic reality of describing a protocol in operation >between two (or more?) hosts/endsystems/endpoints/... > >Does this resonate with others? > >d/ >-- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf From randy_presuhn@mindspring.com Sat Jan 7 16:20:37 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3F421F8491 for ; Sat, 7 Jan 2012 16:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=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 9vzbIxxUMGrd for ; Sat, 7 Jan 2012 16:20:36 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id A3F6A21F8489 for ; Sat, 7 Jan 2012 16:20:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GgsZ/bnqEGCFvUu2vN22q/zyooTuJjkGRPnVMvOQYpzLgDm//NMQRYYM32eP/mfz; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.187.239.79] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RjgUz-0001ti-Kq for ietf@ietf.org; Sat, 07 Jan 2012 19:20:33 -0500 Message-ID: <001801cccd9b$c9f36be0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "IETF Discussion" Subject: merlot.tools.ietf.org getting bounced by Earthlink.net Date: Sat, 7 Jan 2012 16:23:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f812be86c63f5918b75e142ed2bbe0285350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.239.79 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 00:20:37 -0000 Hi - If you're using the IETF tools to distribute information, you should be aware of this... ... > host mx4.mindspring.com [207.69.189.220]: 550 IP 194.146.105.14 is blocked by EarthLink. Go to earthlink.net/block for details. ... 194.146.105.14 is merlot.tools.ietf.org Their support pages provide no avenue for the intended recipient of blocked email to request action be taken. Randy From msk@cloudmark.com Sat Jan 7 22:03:35 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0B621F84B3 for ; Sat, 7 Jan 2012 22:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 CDG3WjreeUXr for ; Sat, 7 Jan 2012 22:03:34 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id AB0C921F849C for ; Sat, 7 Jan 2012 22:03:34 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 7 Jan 2012 22:03:23 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 7 Jan 2012 22:03:29 -0800 From: "Murray S. Kucherawy" To: "ietf@ietf.org" Date: Sat, 7 Jan 2012 22:03:30 -0800 Subject: RE: Last Call: (Authentication-Results Registration Update for SPF Results) to Proposed Standard Thread-Topic: Last Call: (Authentication-Results Registration Update for SPF Results) to Proposed Standard Thread-Index: AczNVyJqnen9jkFCTaeiwU16E8ZT6gAcrN7w Message-ID: References: <20120106212239.31169.16750.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120107071336.0a5b7df0@resistor.net> In-Reply-To: <6.2.5.6.2.20120107071336.0a5b7df0@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 06:03:35 -0000 > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of S= M > Sent: Saturday, January 07, 2012 7:42 AM > To: ietf@ietf.org > Subject: Re: Last Call: > (Authentication-Results Registration Update for SPF Results) to > Proposed Standard Hi SM, > As a editorial nit, the Introduction Section mentions that the memo > updates the IANA registries. Erratum # 2617 is also about Section > 2.4.2. I suggest changing the heading of Section 3 to "Update to > Section 2.4.2 of RFC 5451" and some rewording of the paragraph: >=20 > The "hardfail" result value for [SPF] (and thus also for [SENDER-ID]) > in Section 2.4.2 of RFC 5451 is replaced with the "fail" result value. >=20 > fail: This client is explicitly not authorized to inject or relay > mail using the sender's DNS domain. That's a reasonable suggestion, but I think the important thing is to chang= e the registry than to update RFC5451 itself. If there are any sites that = actually used the wrong value found in the original document, they may cont= inue to do so and the definition for it needs to be in effect someplace. > Note that the update affects the example in Appendix B.5. There's a separate erratum against the example as well, but that's less of = a bug than a registry inconsistency. We can fix the example whenever we fe= el like advancing a proper RFC5451bis. Nevertheless, I wouldn't object to acknowledging in this draft that the exa= mple you cited also has the same error. Would that suffice? -MSK From daedulus@btconnect.com Sun Jan 8 01:02:43 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2892E21F847C for ; Sun, 8 Jan 2012 01:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.705, 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 smmeNaUFeIro for ; Sun, 8 Jan 2012 01:02:42 -0800 (PST) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id A01B921F8469 for ; Sun, 8 Jan 2012 01:02:40 -0800 (PST) Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2bthomr09.btconnect.com with SMTP id FVV49316; Sun, 08 Jan 2012 09:02:26 +0000 (GMT) Message-ID: <000b01cccddb$fd4214c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: References: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il><4F05B856.9050205@dcrocker.net> <3013.1325775717.451646@puncture><4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org><3013.1325799709.099423@puncture> <4F06647E.2010905@dcrocker.net><4F06662A.6070504@joelhalpern.com> <4F0667B9.30604@dcrocker.net> Subject: Re: Protocol Definition Date: Sun, 8 Jan 2012 09:03:13 +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-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4F095B9E.0065, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.8.73314:17:7.944, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, LEO_OBFU_SUBJ_RE, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, BODY_SIZE_1700_1799, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0206.4F095BA6.00F1,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: IETF-Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 09:02:43 -0000 ----- Original Message ----- From: "Dave CROCKER" To: "Joel M. Halpern" Cc: "IETF-Discussion" Sent: Friday, January 06, 2012 4:17 AM > On 1/5/2012 7:10 PM, Joel M. Halpern wrote: > > I suspect that the "correct" choices depends upon how you look at the analogy. > > What seemed to me the closest analog to "process" would be the actual messages > > on the wires. > > Nah. A message on the wire is a single unit in an activity. And taken on its > own, in the host or on the wire, it's actually static. > > It isn't the activity. A process is an activity. The challenge is a term for > the /flow/ of messages. > > It would be nice if it were a single word. I agree that a message is not the right word, but I think that protocol is:-) 'Protocol' started as the draft treaty that formed part of diplomatic exchanges, ie it was the physical manifestation, not the abstract concept, so I would use it in that sense for networking. For the abstract side of networking, I would use the same terminology as I would use for a 'program'. After all, a network is just a single, multi-tasking system in which the 'links' that tie together the multiple tasks have been stretched a little and made manifest so I use the same constructs, the same tools - eg state machines - for both. In a multi-tasking operating system, you will have post and wait and some such, in a network you have send and receive and some such, same difference. Tom Petch > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > From sm@resistor.net Sun Jan 8 01:38:31 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D979021F8487 for ; Sun, 8 Jan 2012 01:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 z6Y+-RXUFNyS for ; Sun, 8 Jan 2012 01:38:29 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7D921F847F for ; Sun, 8 Jan 2012 01:38:29 -0800 (PST) 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 q089cFIF006507 for ; Sun, 8 Jan 2012 01:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326015506; i=@resistor.net; bh=ubVyuRpEQLp6xdqhgBhlmx7Xhp7CMtRaQ3V+R8SHLLI=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=a7BmZuut1omyC8hGF9IPcFNnQe7+PAnGmoyQTe3t/qE6He0M3a0hq5yQ2omHcwYW9 kGDkPuwAQOwYggxtbMruvKLlySvkrLc2autEoQe7rbFge2HURtSmzFxdOsW2wJKN6m hDt86sfziiRCgljC29xoQmTGhbasibS3qaubsUtA= Message-Id: <6.2.5.6.2.20120108010312.0bfb9428@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 08 Jan 2012 01:13:21 -0800 To: ietf@ietf.org From: SM Subject: RE: Last Call: (Authentication-Results Registration Update for SPF Results) to Proposed Standard In-Reply-To: References: <20120106212239.31169.16750.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120107071336.0a5b7df0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 09:38:32 -0000 Hi Murray, At 22:03 07-01-2012, Murray S. Kucherawy wrote: >That's a reasonable suggestion, but I think the important thing is >to change the registry than to update RFC5451 itself. If there are >any sites that actually used the wrong value found in the original >document, they may continue to do so and the definition for it needs >to be in effect someplace. Ok. >There's a separate erratum against the example as well, but that's >less of a bug than a registry inconsistency. We can fix the example >whenever we feel like advancing a proper RFC5451bis. Agreed. >Nevertheless, I wouldn't object to acknowledging in this draft that >the example you cited also has the same error. Would that suffice? Yes. Off-topic note, see http://www.rfc-editor.org/errata_search.php?rfc=6434 Regards, -sm From jeanjour@comcast.net Sun Jan 8 04:01:23 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AFD21F8559 for ; Sun, 8 Jan 2012 04:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.724 X-Spam-Level: X-Spam-Status: No, score=-101.724 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 A2WoUDbEbAWe for ; Sun, 8 Jan 2012 04:01:23 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1397721F84A1 for ; Sun, 8 Jan 2012 04:01:22 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta10.westchester.pa.mail.comcast.net with comcast id JztM1i00927AodY5A01MW9; Sun, 08 Jan 2012 12:01:21 +0000 Received: from [10.0.1.26] ([24.218.154.214]) by omta19.westchester.pa.mail.comcast.net with comcast id K01L1i0094dorGg3f01Lbm; Sun, 08 Jan 2012 12:01:21 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <000b01cccddb$fd4214c0$4001a8c0@gateway.2wire.net> References: <07F7D 7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il><4F05B856.9050205@ dcrocker.net> <3013.1325775717.451646@puncture><4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org><3013.1325799709.099423@puncture> <4F06647E.2010905@dcrocker.net><4F06662A.6070504@joelhalpern.com> <4F0667B9.30604@dcrocker.net> <000b01cccddb$fd4214c0$4001a8c0@gateway.2wire.net> Date: Sun, 8 Jan 2012 07:00:52 -0500 To: "t.petch" , From: John Day Subject: Re: Protocol Definition Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: IETF-Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 12:01:24 -0000 Your are correct. In fact, from the beginning the ARPANET and CYCLADES groups saw this as a distributed computing problem. We have often said that much of the reason that early effort was a success is that we were operating systems guys not telecom guys. The early applications were all aimed at replicating OS functionality in the network. My favorite "proof" of this is that contrary to what many textbooks say, Telnet is not a remote login protocol; but a terminal device driver protocol. But there was much work prior to 1975 on the network as distributed computation. The problem was our ideas were ahead of what the hardware could do "cheaply." Even so, by 1975 we had fielded an application that implemented a land use planning system that used databases on both coasts invisibly to the user sitting at a plasma screen with touch. The keyboard was only for data entry. (There were other equally ambitious efforts) Somehow this direction was lost and we took a step backwards to a focus on "endpoints" as it has been characterized.) You are also correct that strictly speaking the words "protocol" and "algorithm" are probably the same. Other fields, such as biology, use protocol to mean the list of steps to produce something. There has always been a debate about the abstract definition of "process." (To punt the definition I have thought of it as "a locus of execution" or "the instantiation of a program" but of course those beg other questions.) ;-) Which is why OSI gave up and adopted "entity" as about the only word they could find that didn't have implications about how it was implemented. Take care, John At 9:03 +0100 2012/01/08, t.petch wrote: >----- Original Message ----- >From: "Dave CROCKER" >To: "Joel M. Halpern" >Cc: "IETF-Discussion" >Sent: Friday, January 06, 2012 4:17 AM > >> On 1/5/2012 7:10 PM, Joel M. Halpern wrote: >> > I suspect that the "correct" choices depends upon how you look at the >analogy. >> > What seemed to me the closest analog to "process" would be the actual >messages >> > on the wires. >> >> Nah. A message on the wire is a single unit in an activity. And >>taken on its >> own, in the host or on the wire, it's actually static. >> >> It isn't the activity. A process is an activity. The challenge >>is a term for >> the /flow/ of messages. >> >> It would be nice if it were a single word. > >I agree that a message is not the right word, but I think that protocol is:-) >'Protocol' started as the draft treaty that formed part of >diplomatic exchanges, >ie it was the physical manifestation, not the abstract concept, so I would use >it in that sense for networking. > >For the abstract side of networking, I would use the same >terminology as I would >use for a 'program'. After all, a network is just a single, multi-tasking >system in which the 'links' that tie together the multiple tasks have been >stretched a little and made manifest so I use the same constructs, the same >tools - eg state machines - for both. In a multi-tasking operating >system, you >will have post and wait and some such, in a network you have send and receive >and some such, same difference. > >Tom Petch > >> >> d/ >> -- >> >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> >> > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www.ietf.org/mailman/listinfo/ietf From sustrik@250bpm.com Sun Jan 8 14:38:38 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B60621F85E7 for ; Sun, 8 Jan 2012 14:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 WV8vF9a8z+Md for ; Sun, 8 Jan 2012 14:38:38 -0800 (PST) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id F112121F85E6 for ; Sun, 8 Jan 2012 14:38:37 -0800 (PST) Received: from [192.168.0.47] (unknown [118.131.79.167]) by mail.moloch.sk (Postfix) with ESMTPSA id 3DB281800F86; Sun, 8 Jan 2012 23:38:32 +0100 (CET) Message-ID: <4F0A1AE4.3050306@250bpm.com> Date: Sun, 08 Jan 2012 23:38:28 +0100 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: John Day Subject: Re: Protocol Definition References: <07F7D 7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il><4F05B856.9050205@ dcrocker.net> <3013.1325775717.451646@puncture><4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org><3013.1325799709.099423@puncture> <4F06647E.2010905@dcrocker.net><4F06662A.6070504@joelhalpern.com> <4F0667B9.30604@dcrocker.net> <000b01cccddb$fd4214c0$4001a8c0@gateway.2wire.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dcrocker@bbiw.net, IETF-Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 22:38:38 -0000 On 08/01/12 13:00, John Day wrote: > You are also correct that strictly speaking the words "protocol" and > "algorithm" are probably the same. That is an interesting point. What I encounter often is the belief that protocol is just "description of bytes on the wire". People often forget about the stuff that cannot be seen on the wire (e.g. TCP state machine). The area I work in has little or no special "bytes on wire" (simple message-based underlying transport is sufficient) but a lot of algorithmic stuff. Consequently, it was often dismissed as not being a protocol. Martin From jeanjour@comcast.net Sun Jan 8 20:35:12 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623C221F861A for ; Sun, 8 Jan 2012 20:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.116 X-Spam-Level: X-Spam-Status: No, score=-103.116 tagged_above=-999 required=5 tests=[AWL=1.483, BAYES_00=-2.599, GB_I_LETTER=-2, 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 0-DM9zDwBoE8 for ; Sun, 8 Jan 2012 20:35:11 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id AE48C21F85EE for ; Sun, 8 Jan 2012 20:35:11 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta08.westchester.pa.mail.comcast.net with comcast id KGZN1i0011swQuc58GbCeu; Mon, 09 Jan 2012 04:35:12 +0000 Received: from [10.0.1.26] ([24.218.154.214]) by omta15.westchester.pa.mail.comcast.net with comcast id KGbA1i00A4dorGg3bGbBP1; Mon, 09 Jan 2012 04:35:12 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <4F0A1AE4.3050306@250bpm.com> References: <07F7D 7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il><4F05B856.9050205@ dcrocker.net> <3013.1325775717.451646@puncture><4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org><3013.1325799709.099423@puncture> <4F06647E.2010905@dcrocker.net><4F06662A.6070504@joelhalpern.com> <4F0667B9.30604@dcrocker.net> <000b01cccddb$fd4214c0$4001a8c0@gateway.2wire.net> <4F0A1AE4.3050306@250bpm.com> Date: Sun, 8 Jan 2012 23:35:05 -0500 To: Martin Sustrik , John Day From: John Day Subject: Re: Protocol Definition Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: dcrocker@bbiw.net, IETF-Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 04:35:12 -0000 At 23:38 +0100 2012/01/08, Martin Sustrik wrote: >On 08/01/12 13:00, John Day wrote: > >>You are also correct that strictly speaking the words "protocol" and >>"algorithm" are probably the same. > >That is an interesting point. > >What I encounter often is the belief that protocol is just >"description of bytes on the wire". People often forget about the >stuff that cannot be seen on the wire (e.g. TCP state machine). This is clearly not the case and has never been the case. In fact, "bytes on the wire" is probably the smallest part of a protocol specification. A protocol specification must specify what to do with the "bytes on the wire/" The next time someone suggests that merely ask, what do you do with the bytes on the wire? Where is that specified? The action to be taken when a message arrives is all there is. There was once a group who thought that names of the fields in their protocol was sufficient to specify what was to be done with them. I pointed out the them that a legal value of every field in their protocol was the letter "Z". They objected to this quite strenuously, but I asked to show me where it said this was not the case. ;-) Anyone who says that merely specifying the format of messages (bytes on the wire, as you say) constitutes a protocol specification is clearly not competent to be making such pronouncements. > >The area I work in has little or no special "bytes on wire" (simple >message-based underlying transport is sufficient) but a lot of >algorithmic stuff. Consequently, it was often dismissed as not being >a protocol. "has little or no special "bytes on wire" (simple message-based underlying transport is sufficient)" I have no clue what this phrase could possibly mean. If you are passing messages, there must be "bytes on the wire" otherwise, the messages have not been exchanged. Take care, John Day >Martin From sustrik@250bpm.com Sun Jan 8 22:29:26 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD19621F8449 for ; Sun, 8 Jan 2012 22:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.694 X-Spam-Level: X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 dT+Ohkuz+v6I for ; Sun, 8 Jan 2012 22:29:26 -0800 (PST) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id E59C021F8445 for ; Sun, 8 Jan 2012 22:29:25 -0800 (PST) Received: from [130.100.142.206] (unknown [211.175.81.2]) by mail.moloch.sk (Postfix) with ESMTPSA id 0C62D1800F76; Mon, 9 Jan 2012 07:29:19 +0100 (CET) Message-ID: <4F0A893B.4080104@250bpm.com> Date: Mon, 09 Jan 2012 15:29:15 +0900 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: John Day Subject: Re: Protocol Definition References: <07F7D 7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il><4F05B856.9050205@ dcrocker.net> <3013.1325775717.451646@puncture><4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org><3013.1325799709.099423@puncture> <4F06647E.2010905@dcrocker.net><4F06662A.6070504@joelhalpern.com> <4F0667B9.30604@dcrocker.net> <000b01cccddb$fd4214c0$4001a8c0@gateway.2wire.net> <4F0A1AE4.3050306@250bpm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dcrocker@bbiw.net, IETF-Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 06:29:26 -0000 On 01/09/2012 01:35 PM, John Day wrote: > At 23:38 +0100 2012/01/08, Martin Sustrik wrote: >> On 08/01/12 13:00, John Day wrote: >> >>> You are also correct that strictly speaking the words "protocol" and >>> "algorithm" are probably the same. >> >> That is an interesting point. >> >> What I encounter often is the belief that protocol is just >> "description of bytes on the wire". People often forget about the >> stuff that cannot be seen on the wire (e.g. TCP state machine). > > This is clearly not the case and has never been the case. > > In fact, "bytes on the wire" is probably the smallest part of a protocol > specification. A protocol specification must specify what to do with the > "bytes on the wire/" > > The next time someone suggests that merely ask, what do you do with the > bytes on the wire? Where is that specified? The action to be taken when > a message arrives is all there is. > > There was once a group who thought that names of the fields in their > protocol was sufficient to specify what was to be done with them. I > pointed out the them that a legal value of every field in their protocol > was the letter "Z". They objected to this quite strenuously, but I asked > to show me where it said this was not the case. ;-) > > Anyone who says that merely specifying the format of messages (bytes on > the wire, as you say) constitutes a protocol specification is clearly > not competent to be making such pronouncements. Agreed. However, consider following problem: Imagine there's a specification that doesn't define any new wire formats, only specific ways to handle existing messages (UDP packets, SCTP messages or whatever). Is it still eligible to become an IETF protocol? >> The area I work in has little or no special "bytes on wire" (simple >> message-based underlying transport is sufficient) but a lot of >> algorithmic stuff. Consequently, it was often dismissed as not being a >> protocol. > > "has little or no special "bytes on wire" (simple message-based > underlying transport is sufficient)" I have no clue what this phrase > could possibly mean. If you are passing messages, there must be "bytes > on the wire" otherwise, the messages have not been exchanged. What I am working on is business messaging (a.k.a. message-oriented middleware). In lot of cases it works ok with existing message formats (e.g. UDP packets, PGM APDUs, SCTP messages etc.) and doesn't require any additional data to be passed on the wire. What the specification focuses on are things like: If TCP is used to form a one-to-many message distribution tree, how should we handle TCP flowcontrol/pushback in such a way that a single slow receiver doesn't block the whole message distribution tree? Or: How to receive messages from multiple sources without allowing one sender to starve out the receiver and thus block the other senders (some form of fair-queueing is needed)? Etc. Martin From msk@cloudmark.com Sun Jan 8 23:08:59 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC9821F8672 for ; Sun, 8 Jan 2012 23:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 i775+dTmZwOF for ; Sun, 8 Jan 2012 23:08:59 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 09FAC21F866E for ; Sun, 8 Jan 2012 23:08:59 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 8 Jan 2012 23:08:51 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Sun, 8 Jan 2012 23:08:58 -0800 From: "Murray S. Kucherawy" To: "ietf@ietf.org" Date: Sun, 8 Jan 2012 23:09:00 -0800 Subject: RE: Last Call: (Authentication-Results Registration Update for SPF Results) to Proposed Standard Thread-Topic: Last Call: (Authentication-Results Registration Update for SPF Results) to Proposed Standard Thread-Index: AczN6WGYUHoXebcBQUaBT4VUjTDapgAtB8GA Message-ID: References: <20120106212239.31169.16750.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120107071336.0a5b7df0@resistor.net> <6.2.5.6.2.20120108010312.0bfb9428@resistor.net> In-Reply-To: <6.2.5.6.2.20120108010312.0bfb9428@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 07:08:59 -0000 > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of S= M > Sent: Sunday, January 08, 2012 1:13 AM > To: ietf@ietf.org > Subject: RE: Last Call: > (Authentication-Results Registration Update for SPF Results) to > Proposed Standard >=20 > >Nevertheless, I wouldn't object to acknowledging in this draft that the > >example you cited also has the same error. Would that suffice? >=20 > Yes. I've added such an appendix for -02. Thanks for the suggestion. -MSK From jeanjour@comcast.net Mon Jan 9 04:13:58 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C116E21F8715 for ; Mon, 9 Jan 2012 04:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.487 X-Spam-Level: X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=1.113, BAYES_00=-2.599, GB_I_LETTER=-2, 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 0jRxw5Y03451 for ; Mon, 9 Jan 2012 04:13:58 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id F1D1721F870B for ; Mon, 9 Jan 2012 04:13:57 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta12.westchester.pa.mail.comcast.net with comcast id KQDQ1i00216LCl05CQDypT; Mon, 09 Jan 2012 12:13:58 +0000 Received: from [10.0.1.26] ([24.218.154.214]) by omta06.westchester.pa.mail.comcast.net with comcast id KQDw1i00t4dorGg3SQDxMX; Mon, 09 Jan 2012 12:13:58 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <4F0A893B.4080104@250bpm.com> References: <07F7D 7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il><4F05B856.9050205@ dcrocker.net> <3013.1325775717.451646@puncture><4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org><3013.1325799709.099423@puncture> <4F06647E.2010905@dcrocker.net><4F06662A.6070504@joelhalpern.com> <4F0667B9.30604@dcrocker.net> <000b01cccddb$fd4214c0$4001a8c0@gateway.2wire.net> <4F0A1AE4.3050306@250bpm.com> <4F0A893B.4080104@250bpm.com> Date: Mon, 9 Jan 2012 07:08:05 -0500 To: Martin Sustrik , John Day From: John Day Subject: Re: Protocol Definition Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: dcrocker@bbiw.net, IETF-Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 12:13:58 -0000 At 15:29 +0900 2012/01/09, Martin Sustrik wrote: >On 01/09/2012 01:35 PM, John Day wrote: >>At 23:38 +0100 2012/01/08, Martin Sustrik wrote: >>>On 08/01/12 13:00, John Day wrote: >>> >>>>You are also correct that strictly speaking the words "protocol" and >>>>"algorithm" are probably the same. >>> >>>That is an interesting point. >>> >>>What I encounter often is the belief that protocol is just >>>"description of bytes on the wire". People often forget about the >>>stuff that cannot be seen on the wire (e.g. TCP state machine). >> >>This is clearly not the case and has never been the case. >> >>In fact, "bytes on the wire" is probably the smallest part of a protocol >>specification. A protocol specification must specify what to do with the >>"bytes on the wire/" >> >>The next time someone suggests that merely ask, what do you do with the >>bytes on the wire? Where is that specified? The action to be taken when >>a message arrives is all there is. >> >>There was once a group who thought that names of the fields in their >>protocol was sufficient to specify what was to be done with them. I >>pointed out the them that a legal value of every field in their protocol >>was the letter "Z". They objected to this quite strenuously, but I asked >>to show me where it said this was not the case. ;-) >> >>Anyone who says that merely specifying the format of messages (bytes on >>the wire, as you say) constitutes a protocol specification is clearly >>not competent to be making such pronouncements. > >Agreed. However, consider following problem: Imagine there's a >specification that doesn't define any new wire formats, only >specific ways to handle existing messages (UDP packets, SCTP >messages or whatever). Is it still eligible to become an IETF >protocol? Two problems here: 1) The scope of the IETF has nothing to do with the original question of "what is a protocol?" For that you will have to consult the rules of the IETF. 2) The specifications of UDP, SCTP, etc provide the full and complete specification of their messages. So you must be defining something else, or you are proposing modifications to these protocols, so you should be working with their groups. In the case of UDP, I highly doubt this. Sounds to me that you are working with the very old phone company "beads-on-a-string" model rather than the more modern layered model. But then that seems to be fairly prevalent in the IETF. > >>>The area I work in has little or no special "bytes on wire" (simple >>>message-based underlying transport is sufficient) but a lot of >>>algorithmic stuff. Consequently, it was often dismissed as not being a >>>protocol. >> >>"has little or no special "bytes on wire" (simple message-based >>underlying transport is sufficient)" I have no clue what this phrase >>could possibly mean. If you are passing messages, there must be "bytes >>on the wire" otherwise, the messages have not been exchanged. > >What I am working on is business messaging (a.k.a. message-oriented >middleware). In lot of cases it works ok with existing message >formats (e.g. UDP packets, PGM APDUs, SCTP messages etc.) and >doesn't require any additional data to be passed on the wire. This makes no sense whatsoever. UDP and SCTP messages change the state (not much in the case of UDP) of their protocol machines, etc. If what you say is true, i.e. doesn't require any additional data to be passed on the wire, then I can guarantee that your "business messaging" does nothing. UDP and SCTP messages are consumed by those protocols machines. > >What the specification focuses on are things like: If TCP is used to >form a one-to-many message distribution tree, how should we handle >TCP flowcontrol/pushback in such a way that a single slow receiver >doesn't block the whole message distribution tree? Or: How to >receive messages from multiple sources without allowing one sender >to starve out the receiver and thus block the other senders (some >form of fair-queueing is needed)? Etc. These are local matters unless feedback is used. In which case there is a protocol. Having worked through these issues years ago, it sound to me like you don't have a clear picture of the model. Take care, John Day >Martin From se.pankaj@gmail.com Mon Jan 9 06:30:45 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA5821F8772 for ; Mon, 9 Jan 2012 06:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 1PwJ2rN05S1t for ; Mon, 9 Jan 2012 06:30:42 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id CDED721F8751 for ; Mon, 9 Jan 2012 06:30:41 -0800 (PST) Received: by qadz3 with SMTP id z3so2195570qad.10 for ; Mon, 09 Jan 2012 06:30:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=X/QAuwJJeJl1Fu4VsKGO7mKTlmiOJUF8SGxNmcKt7zU=; b=Ibya1lYtcVoxMVpZq3U5MaQzXER7Hrt+d6YOPgRoWfkt3Cs0GF/ZakaC1gNc1dLeIW +6u42GLX8fJUazvsp2hnneVmCV236rG/5UCiR0eY1D+EKg7OXdJneGyAPCD5lCiZIjHc FYz0pw4nnsNmO51uzsI9dzyZPSSdP+rQo6tbg= MIME-Version: 1.0 Received: by 10.224.203.67 with SMTP id fh3mr19935153qab.13.1326119441306; Mon, 09 Jan 2012 06:30:41 -0800 (PST) Received: by 10.229.160.12 with HTTP; Mon, 9 Jan 2012 06:30:41 -0800 (PST) In-Reply-To: <4F0A1AE4.3050306@250bpm.com> References: <3013.1325775717.451646@puncture> <4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org> <3013.1325799709.099423@puncture> <4F06647E.2010905@dcrocker.net> <4F06662A.6070504@joelhalpern.com> <4F0667B9.30604@dcrocker.net> <000b01cccddb$fd4214c0$4001a8c0@gateway.2wire.net> <4F0A1AE4.3050306@250bpm.com> Date: Mon, 9 Jan 2012 20:00:41 +0530 Message-ID: Subject: Re: Protocol Definition From: pankaj kumar To: Martin Sustrik Content-Type: multipart/alternative; boundary=20cf300fb08d3a933704b6193e10 Cc: IETF-Discussion , dcrocker@bbiw.net X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 14:30:45 -0000 --20cf300fb08d3a933704b6193e10 Content-Type: text/plain; charset=ISO-8859-1 What I feel that protocol is rules for any mode of communication or for exchange of data. e.g. - People speaks in English and English grammar is kind of protocol otherwise it is difficult to understand communication if sentences are not properly as per grammar. Now you can have a point that even we can understand semantic of the sentence even if it is not correct as per grammar; it is because we are human being and we can understand by guessing intelligence. But it is difficult/impossible in networking to transfer data without protocol because at every received byte or every received chunk of bytes you can not have artificial intelligence to decode the received data. other example: you have some rules to play every games- rules in chess, football, tennis etc. In this way I understand protocol is must and needed set of rules in every communication (networking or in-human) special to make it is successful. Otherwise without protocol, things will be left on wild guess or on sixth sense of the system. On Mon, Jan 9, 2012 at 4:08 AM, Martin Sustrik wrote: > On 08/01/12 13:00, John Day wrote: > > You are also correct that strictly speaking the words "protocol" and >> "algorithm" are probably the same. >> > > That is an interesting point. > > What I encounter often is the belief that protocol is just "description of > bytes on the wire". People often forget about the stuff that cannot be seen > on the wire (e.g. TCP state machine). > > The area I work in has little or no special "bytes on wire" (simple > message-based underlying transport is sufficient) but a lot of algorithmic > stuff. Consequently, it was often dismissed as not being a protocol. > > Martin > > > ______________________________**_________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/**listinfo/ietf > -- Thanks & Regards, Pankaj Kumar, Mobile: +91 8939008891 http://in.linkedin.com/in/techiepankaj --20cf300fb08d3a933704b6193e10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What I feel that protocol is rules for any mode of communication or for exc= hange of data.
      e.g. - People speaks in English and English grammar is kind of protocol=20 otherwise it is difficult to understand communication if sentences are=20 not properly as per grammar. Now you can have a point that even we can=20 understand semantic of the sentence even if it is not correct as per=20 grammar; it is because we are human being and we can understand by=20 guessing intelligence. But it is difficult/impossible in networking to=20 transfer data without protocol because at every received byte or every=20 received chunk of bytes you can not have artificial intelligence to=20 decode the received data.

      other example: you have some rules to play= every games- rules in chess, football, tennis etc.

      In this way I un= derstand protocol is must and needed set of rules in every communication (n= etworking=A0 or in-human) special to make it is successful.

      Otherwise without protocol, things will be left on wild guess or on six= th sense of the system.


      On Mon, Jan 9= , 2012 at 4:08 AM, Martin Sustrik <sustrik@250bpm.com> wrot= e:
      On 08/01/12 13:00, John Day wrote:

      You are also correct that strictly speaking the words "protocol" = and
      "algorithm" are probably the same.

      That is an interesting point.

      What I encounter often is the belief that protocol is just "descriptio= n of bytes on the wire". People often forget about the stuff that cann= ot be seen on the wire (e.g. TCP state machine).

      The area I work in has little or no special "bytes on wire" (simp= le message-based underlying transport is sufficient) but a lot of algorithm= ic stuff. Consequently, it was often dismissed as not being a protocol.

      Martin


      _______________________________________________
      Ietf mailing list
      Ietf@ietf.org
      ht= tps://www.ietf.org/mailman/listinfo/ietf



      --
      Thanks &= ; Regards,

      Pankaj Kumar,

      Mobile: +91 8939008891
      http://in.= linkedin.com/in/techiepankaj
      --20cf300fb08d3a933704b6193e10-- From dhc@dcrocker.net Mon Jan 9 06:39:49 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAA821F8592 for ; Mon, 9 Jan 2012 06:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[AWL=-0.396, 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 Fc+YflvNxzNi for ; Mon, 9 Jan 2012 06:39:44 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E359B21F8587 for ; Mon, 9 Jan 2012 06:39:44 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q09EdWn7004314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jan 2012 06:39:37 -0800 Message-ID: <4F0AFC1C.1060905@dcrocker.net> Date: Mon, 09 Jan 2012 06:39:24 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "t.petch" Subject: Re: Protocol Definition References: <07F7D7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il><4F05B856.9050205@dcrocker.net> <3013.1325775717.451646@puncture><4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org><3013.1325799709.099423@puncture> <4F06647E.2010905@dcrocker.net><4F06662A.6070504@joelhalpern.com> <4F0667B9.30604@dcrocker.net> <000b01cccddb$fd4214c0$4001a8c0@gateway.2wire.net> In-Reply-To: <000b01cccddb$fd4214c0$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]); Mon, 09 Jan 2012 06:39:38 -0800 (PST) Cc: dcrocker@bbiw.net, IETF-Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 14:39:49 -0000 On 1/8/2012 12:03 AM, t.petch wrote: > I agree that a message is not the right word, but I think that protocol is:-) There is a specific distinction that is intended by having two different words: description vs. operation. A program is a description of behavior. A process is the operation of the description. It is the behavioral performance. Protocol refers to the description of an interaction. The term being explored is for the operation of that description. It is the interaction. > For the abstract side of networking, I would use the same terminology as I would > use for a 'program'. If you mean that you would say 'process' for both, that does have the appeal of familiarity, but the problem of overloading. Worse, I'd fear that it encourages a failure to appreciate the differences between networking architecture and software implementation. Since this failure is quite prevalent, I suggest we not encourage it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From jeanjour@comcast.net Mon Jan 9 07:37:05 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C1D21F87A8 for ; Mon, 9 Jan 2012 07:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.409 X-Spam-Level: X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 ijoa5QpCN2kj for ; Mon, 9 Jan 2012 07:37:04 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 88A0B21F8795 for ; Mon, 9 Jan 2012 07:37:04 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta07.westchester.pa.mail.comcast.net with comcast id KQCY1i0091c6gX857Td5Gt; Mon, 09 Jan 2012 15:37:05 +0000 Received: from [10.0.1.26] ([24.218.154.214]) by omta23.westchester.pa.mail.comcast.net with comcast id KTd21i02u4dorGg3jTd36G; Mon, 09 Jan 2012 15:37:05 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <4F0AFC1C.1060905@dcrocker.net> References: <07F7D 7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il><4F05B856.9050205@ dcrocker.net> <3013.1325775717.451646@puncture><4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org><3013.1325799709.099423@puncture> <4F06647E.2010905@dcrocker.net><4F06662A.6070504@joelhalpern.com> <4F0667B9.30604@dcrocker.net> <000b01cccddb$fd4214c0$4001a8c0@gateway.2wire.net> <4F0AFC1C.1060905@dcrocker.net> Date: Mon, 9 Jan 2012 10:36:59 -0500 To: dcrocker@bbiw.net, "t.petch" From: John Day Subject: Re: Protocol Definition Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: dcrocker@bbiw.net, IETF-Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 15:37:05 -0000 At 6:39 -0800 2012/01/09, Dave CROCKER wrote: >On 1/8/2012 12:03 AM, t.petch wrote: >>I agree that a message is not the right word, but I think that protocol is:-) > >There is a specific distinction that is intended by having two >different words: description vs. operation. > >A program is a description of behavior. A process is the operation >of the description. It is the behavioral performance. > >Protocol refers to the description of an interaction. The term >being explored is for the operation of that description. It is the >interaction. > Agreed. >>For the abstract side of networking, I would use the same >>terminology as I would >>use for a 'program'. > >If you mean that you would say 'process' for both, that does have >the appeal of familiarity, but the problem of overloading. Worse, >I'd fear that it encourages a failure to appreciate the differences >between networking architecture and software implementation. Since >this failure is quite prevalent, I suggest we not encourage it. Well, pretty close. There is a copious literature on the formal description and verification of protocols beginning in the 70s. There are two major issues that is not normally found in defining a "program": 1) is specifying the asynchrony, ensuring no races, and 2) keeping the specification implementation independent. One does not want the specification to unnecessarily constrain the implementation strategy. The general rule is Day's First Rule of Architecture: Anything you can get away with that is undetectable from the outside is legal. Or when it comes to implementation sleaze the architecture. We have seen the problems of code monoculture or just assuming the other guys knew how to code. Take care, John From scott.mansfield@ericsson.com Sun Jan 8 05:54:59 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BE921F857D; Sun, 8 Jan 2012 05:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.608 X-Spam-Level: X-Spam-Status: No, score=-6.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 hw2VTqNPz50Q; Sun, 8 Jan 2012 05:54:58 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A62EB21F857A; Sun, 8 Jan 2012 05:54:58 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q08Dslvg030164; Sun, 8 Jan 2012 07:54:50 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Sun, 8 Jan 2012 08:54:41 -0500 From: Scott Mansfield To: "ietf@ietf.org" , "mpls@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Date: Sun, 8 Jan 2012 08:53:05 -0500 Subject: FW: New Liaison Statement, "LS370 - Current status of Recommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" Thread-Topic: New Liaison Statement, "LS370 - Current status of Recommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" Thread-Index: AczN3sDx/mJ/vGigQiGFDbfLLXEytgAKv9cA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 09 Jan 2012 09:08:02 -0800 Cc: "swallow@cisco.com" , "stbryant@cisco.com" , "adrian@olddog.co.uk" , "andrew.g.malis@verizon.com" , "dbrungard@att.com" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 13:54:59 -0000 This is a liaison from the ITU-T SG15 WP3 providing a copy of the Determine= d recommendation G.8113.1 (May 2011). The liaison also provides a pointer = to the internet draft draft-betts-itu-oam-ach-code-point that requests an A= Ch code point that is needed by G.8113.1. This is a liaison that will requ= ire a response and the ITU-T has requested a response no later than 1 Augus= t 2012. I would suggest that we use the liaison response to provide the ou= tcome of running the IETF process required to assign the requested code poi= nt. Regards, -scott. IETF-ITU Liaison Manager for MPLS > -----Original Message----- > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]=20 > Sent: Sunday, January 08, 2012 3:23 AM > To: chair@ietf.org > Cc: yoichi.maeda@ttc.or.jp;=20 > steve.trowbridge@alcatel-lucent.com; iesg@ietf.org;=20 > lear@cisco.com; Scott Mansfield; malcolm.betts@zte.com.cn;=20 > tsbsg15@itu.int; greg.jones@itu.int; hiroshi.ota@itu.int > Subject: New Liaison Statement, "LS370 - Current status of=20 > Recommendation ITU-T G.8113.1/Y.1372.1, Operations,=20 > Administration and Maintenance mechanism for MPLS-TP in=20 > Packet Transport Network (PTN)" >=20 > Title: LS370 - Current status of Recommendation ITU-T=20 > G.8113.1/Y.1372.1, Operations, Administration and Maintenance=20 > mechanism for MPLS-TP in Packet Transport Network (PTN)=20 > Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/ >=20 > From: ITU-T SG 15 (Greg Jones ) > To: The IESG (chair@ietf.org) > Cc:=20 > yoichi.maeda@ttc.or.jp,steve.trowbridge@alcatel-lucent.com,ies > g@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com > Reponse Contact:=20 > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > Technical Contact: malcolm.betts@zte.com.cn > Purpose: For information >=20 > Body: The December meeting of ITU-T Study Group 15 considered=20 > the approval of Recommendation ITU-T G.8113.1/Y.1372.1,=20 > Operations, Administration and Maintenance mechanism for=20 > MPLS-TP in Packet Transport Network (PTN). Unfortunately the=20 > Study Group could not approve this Recommendation so it was=20 > forwarded to the WTSA (20-29 November 2012) for approval. =20 > One of the issues that prevented the approval in SG 15 was=20 > the lack of an ACh code point to support this Recommendation.=20 > To resolve this issue SG 15 therefore requests the IETF to=20 > assign an ACh code point. An IETF draft=20 > draft-betts-itu-oam-ach-code-point has been submitted to=20 > request this code point. > We have attached the text of the current draft of=20 > Recommendation ITU-T G.8113.1/Y.1372.1 that has been=20 > forwarded to the WTSA for approval. > Attach: COM15R-22. >=20 > Attachment(s): >=20 > LS370 - pdf body=20 > https://datatracker.ietf.org/documents/LIAISON/file1306.pdf >=20 > LS370 - pdf attachment=20 > https://datatracker.ietf.org/documents/LIAISON/file1307.pdf >=20 >=20 > = From scott.mansfield@ericsson.com Sun Jan 8 06:03:02 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B618A21F857F; Sun, 8 Jan 2012 06:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.608 X-Spam-Level: X-Spam-Status: No, score=-6.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 T6toldkBkO4w; Sun, 8 Jan 2012 06:03:02 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA1521F857A; Sun, 8 Jan 2012 06:03:02 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q08E2xVd015650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 8 Jan 2012 08:02:59 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 8 Jan 2012 09:02:58 -0500 From: Scott Mansfield To: "ietf@ietf.org" , "mpls@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Date: Sun, 8 Jan 2012 09:01:22 -0500 Subject: FW: New Liaison Statement, "LS368 - MPLS-TP Recommendations" Thread-Topic: New Liaison Statement, "LS368 - MPLS-TP Recommendations" Thread-Index: AczN4pkSBaUC0mYaQoOGlA/HaKlurQAKkiSA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 09 Jan 2012 09:08:02 -0800 Cc: "swallow@cisco.com" , "stbryant@cisco.com" , "adrian@olddog.co.uk" , "andrew.g.malis@verizon.com" , "dbrungard@att.com" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 14:03:02 -0000 This is a liaison from SG15 Q9, Q12, and Q14 providing the text of G.8110.1= , G.8121, and G.8151. This liaison is for information only. G.8110.1 was = approved at the SG15 plenary meeting in December 2011. G.8121 and G.8151 e= ntered the alternative approval process (AAP) and will enter a 4 week last = call (the last call hasn't been initiated yet). Regards, -scott. IETF-ITU Liaison Manager for MPLS > -----Original Message----- > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]=20 > Sent: Sunday, January 08, 2012 3:51 AM > To: rcallon@juniper.net; swallow@cisco.com; loa@pi.nu > Cc: yoichi.maeda@ttc.or.jp;=20 > steve.trowbridge@alcatel-lucent.com; mpls@ietf.org;=20 > lear@cisco.com; Scott Mansfield; stbryant@cisco.com;=20 > adrian@olddog.co.uk; malcolm.betts@zte.com.cn; Ghani Abbas;=20 > Kam.Lam@alcatel-lucent.com; tsbsg15@itu.int;=20 > greg.jones@itu.int; hiroshi.ota@itu.int > Subject: New Liaison Statement, "LS368 - MPLS-TP Recommendations" >=20 > Title: LS368 - MPLS-TP Recommendations > Submission Date: 2012-01-08 > URL of the IETF Web page: /liaison/1126/ >=20 > From: ITU-T SG 15 (Greg Jones ) > To: Multiprotocol Label Switching (rcallon@juniper.net,=20 > swallow@cisco.com, loa@pi.nu) > Cc:=20 > yoichi.maeda@ttc.or.jp,steve.trowbridge@alcatel-lucent.com,mpl > s@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com,stbryan > t@cisco.com,adrian@olddog.co.uk > Reponse Contact:=20 > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > Technical Contact:=20 > malcolm.betts@zte.com.cn,Ghani.Abbas@ericsson.com,Kam.Lam@alca > tel-lucent.com > Purpose: For information >=20 > Body: At the December 2011 meeting of ITU-T Study Group 15,=20 > Recommendation ITU-T G.8110.1/Y.1370.1 "Architecture of MPLS=20 > Transport Profile (MPLS-TP) layer network" was approved. A=20 > copy is attached for your information. =20 > We would like to draw your attention to clause 10 that=20 > describes the MPLS-TP Diff-Serv Architecture. > In addition, the approval process was initiated for=20 > Recommendations ITU-T G.8121/Y.1381 "Characteristics of=20 > MPLS-TP Network Equipment Functional Blocks" and ITU-T=20 > G.8151/Y.1374 "Management aspects of the MPLS-TP network element". >=20 > Attach: TD517/PLEN Rev.3, TD540/PLEN Rev.1, TD543/PLEN Rev.1. >=20 > Attachment(s): >=20 > LS368 - pdf body=20 > https://datatracker.ietf.org/documents/LIAISON/file1308.pdf >=20 > LS368 - Att1_PLEN-517Rev3=20 > https://datatracker.ietf.org/documents/LIAISON/file1309.pdf >=20 > LS368 - Att2_PLEN-540Rev1=20 > https://datatracker.ietf.org/documents/LIAISON/file1310.pdf >=20 > LS368 - Att3_PLEN-543Rev1=20 > https://datatracker.ietf.org/documents/LIAISON/file1311.pdf >=20 >=20 > = From joelja@bogus.com Mon Jan 9 09:09:59 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FD911E809A for ; Mon, 9 Jan 2012 09:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 g05KCpREjEER for ; Mon, 9 Jan 2012 09:09:57 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2496011E807A for ; Mon, 9 Jan 2012 09:09:56 -0800 (PST) Received: from Joels-MacBook-Pro.local (host-64-47-136-190.masergy.com [64.47.136.190]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q09H9rq3052216 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Mon, 9 Jan 2012 17:09:53 GMT (envelope-from joelja@bogus.com) Message-ID: <4F0B1F5C.10400@bogus.com> Date: Mon, 09 Jan 2012 09:09:48 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: SM Subject: Re: Requirements for improving IETF remote participation References: <6.2.5.6.2.20120105215913.0b943e50@resistor.net> In-Reply-To: <6.2.5.6.2.20120105215913.0b943e50@resistor.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Mon, 09 Jan 2012 17:09:53 +0000 (UTC) Cc: IETF Discussion , Paul Hoffman X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:09:59 -0000 On 1/6/12 02:00 , SM wrote: > "The RPS tools must be available for lunch meetings scheduled by > the IETF Secretariat, such as for the Security Directorate" > > I object to the non-inclusion of the kangaroo directorate (no offense > intended). :-) That implies coverage of a much greater number of rooms, e.g. 16 or more potentialy. when you count the offices and small breakout rooms in addition to the 8 scheduled meeting rooms. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From adrian@olddog.co.uk Mon Jan 9 09:33:27 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B9811E80C7; Mon, 9 Jan 2012 09:33:27 -0800 (PST) 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 WYEK9gKkXSNS; Mon, 9 Jan 2012 09:33:26 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 710AA11E80A3; Mon, 9 Jan 2012 09:33:26 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q09HXJIt020028; Mon, 9 Jan 2012 17:33:19 GMT Received: from 950129200 (adsl-84-227-210-28.adslplus.ch [84.227.210.28]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id q09HXHb2019949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Jan 2012 17:33:18 GMT From: "Adrian Farrel" To: , "'Huub helvoort'" References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> In-Reply-To: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> Subject: RE: Questions about draft-betts-itu-oam-ach-code-point Date: Mon, 9 Jan 2012 17:33:16 -0000 Message-ID: <01cf01cccef4$c5e6ef90$51b4ceb0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMS9l89V+yYISRa9OjQYS/w8kDy1ZN3+0VQ Content-Language: en-gb Cc: mpls@ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:33:27 -0000 Hi Huub and Malcolm, I recognise that the intervening month between my original email and this one included an SG15 meeting, Christmas, and New Year, but I had hoped for a response by now so that we could work out what to do with the document. In the meantime, at least my question 4 has progressed. Can you confirm that the version of G.8113.1 for which a code point is requested is that which has been sent to WTSA by SG15 (i.e., that which was determined), and that there are no plans to make any updates or revisions to that document until after it has been approved. Thanks, Adrian > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Adrian > Farrel > Sent: 09 December 2011 10:49 > To: draft-betts-itu-oam-ach-code-point@tools.ietf.org; 'Huub helvoort' > Cc: mpls@ietf.org; ietf@ietf.org > Subject: Questions about draft-betts-itu-oam-ach-code-point > > Hi Malcolm and Huub, > > I have squeezed a little time from the current ITU-T meeting to look at your > draft and write-up. I have also read the email threads on the IETF discussion > list and the MPLS list. Sorry that this has taken me a week to process, but your > publication request came at pretty much the worst possible time for getting me > to do this task. > > I don't like proliferating threads across multiple mailing lists. On the other > hand it is difficult to ensure that all the constituencies are present, so I am > perpetuating the cross-posting. > > My review of the document... > > 1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I think > only one of these is real (the spurious space in a citation). The other nits are > spurious caused by citations wrapping across lines. Could you please keep a note > of the nit so that you can fix it the next time the draft is respun or so it can > be captured in an RFC Editor Note at a later stage (you don't have to post a new > revision to address this now unless you really want to). > > 2. This document requests a code point from a registry that contains code points > that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D > whether it is your intention that your code point would also be applicable in > both cases. What is your intention? Is this "obvious" from G.8113.1 or does it > need to be clarified? > > > My review of the write-up and discussions... > > 3. There seems to be quite a feeling on the mailing lists that this document > should be run through the MPLS working group. The write-up makes a case for > progressing it as AD sponsored. As far as I can see, the main assertions to > answer are as follows. Do you have a view on these points before I make a > decision on what to do? > > a. This is a proposal to use an MPLS code point and so is part of MPLS by > definition. > > b. The type of network being managed by the OAM described in G.8113.1 is an > MPLS network. Therefore, this is clearly relevant to the MPLS working . > > Do you object to this going through the MPLS on principle, or were you just > hoping to save the WG the work? If the latter, and if the WG wants to look at > the draft, the easiest approach seems to be to redirect the work to the working > group. > > 4. G.8113.1 is clearly important to understanding to which the code point is > being put. Thus, an available and stable copy of group. G.8113.1 will be key to > the last call review of you I-D. Can you make a stable copy available (for > example, through liaison)? How does the editing work currently in progress in > the SG15 meeting affect that availability? > > 5. Can you clarify for me why the suggested value has been suggested. This will > help guide IANA who would normally do their allocation in a "tidy" way. > > Looking forward to your reply. > > Thanks, > Adrian From nurit.sprecher@nsn.com Mon Jan 9 09:41:53 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D055311E80E6; Mon, 9 Jan 2012 09:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.507 X-Spam-Level: X-Spam-Status: No, score=-6.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 sgfjPvmaeHaC; Mon, 9 Jan 2012 09:41:53 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 90B0811E80BD; Mon, 9 Jan 2012 09:41:52 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q09HfkoF014113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Jan 2012 18:41:46 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q09HfkhZ009479; Mon, 9 Jan 2012 18:41:46 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 18:41:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [CCAMP] New Liaison Statement, "LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in PacketTransport Network (PTN)" Date: Mon, 9 Jan 2012 18:41:43 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326405178E7C@DEMUEXC014.nsn-intra.net> In-Reply-To: <077E41CFFD002C4CAB7DFA4386A5326405178E68@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] New Liaison Statement, "LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in PacketTransport Network (PTN)" Thread-Index: AczN3sDx/mJ/vGigQiGFDbfLLXEytgAKv9cAADpI3OAAAL2zAA== References: <077E41CFFD002C4CAB7DFA4386A5326405178E68@DEMUEXC014.nsn-intra.net> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" , "ext Scott Mansfield" , , , , X-OriginalArrivalTime: 09 Jan 2012 17:41:46.0156 (UTC) FILETIME=[F51D76C0:01CCCEF5] Cc: andrew.g.malis@verizon.com, dbrungard@att.com X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:41:54 -0000 When saying support, I mean of course that I fully support the proposal = of Scott! -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: =E1 09 =E9=F0=E5=E0=F8 2012 19:20 To: ext Scott Mansfield; ietf@ietf.org; mpls@ietf.org; pwe3@ietf.org; = ccamp@ietf.org Cc: andrew.g.malis@verizon.com; dbrungard@att.com Subject: Re: [CCAMP] New Liaison Statement,"LS370 - Current status = ofRecommendation ITU-T G.8113.1/Y.1372.1,Operations,Administration = andMaintenance mechanism for MPLS-TP in PacketTransport Network (PTN)" Support -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of = ext Scott Mansfield Sent: =E0 08 =E9=F0=E5=E0=F8 2012 15:53 To: ietf@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org Cc: swallow@cisco.com; stbryant@cisco.com; adrian@olddog.co.uk; = andrew.g.malis@verizon.com; dbrungard@att.com Subject: FW: New Liaison Statement, "LS370 - Current status = ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration = andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" This is a liaison from the ITU-T SG15 WP3 providing a copy of the = Determined recommendation G.8113.1 (May 2011). The liaison also = provides a pointer to the internet draft = draft-betts-itu-oam-ach-code-point that requests an ACh code point that = is needed by G.8113.1. This is a liaison that will require a response = and the ITU-T has requested a response no later than 1 August 2012. I = would suggest that we use the liaison response to provide the outcome of = running the IETF process required to assign the requested code point. Regards, -scott. IETF-ITU Liaison Manager for MPLS > -----Original Message----- > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]=20 > Sent: Sunday, January 08, 2012 3:23 AM > To: chair@ietf.org > Cc: yoichi.maeda@ttc.or.jp;=20 > steve.trowbridge@alcatel-lucent.com; iesg@ietf.org;=20 > lear@cisco.com; Scott Mansfield; malcolm.betts@zte.com.cn;=20 > tsbsg15@itu.int; greg.jones@itu.int; hiroshi.ota@itu.int > Subject: New Liaison Statement, "LS370 - Current status of=20 > Recommendation ITU-T G.8113.1/Y.1372.1, Operations,=20 > Administration and Maintenance mechanism for MPLS-TP in=20 > Packet Transport Network (PTN)" >=20 > Title: LS370 - Current status of Recommendation ITU-T=20 > G.8113.1/Y.1372.1, Operations, Administration and Maintenance=20 > mechanism for MPLS-TP in Packet Transport Network (PTN)=20 > Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/ >=20 > From: ITU-T SG 15 (Greg Jones ) > To: The IESG (chair@ietf.org) > Cc:=20 > yoichi.maeda@ttc.or.jp,steve.trowbridge@alcatel-lucent.com,ies > g@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com > Reponse Contact:=20 > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > Technical Contact: malcolm.betts@zte.com.cn > Purpose: For information >=20 > Body: The December meeting of ITU-T Study Group 15 considered=20 > the approval of Recommendation ITU-T G.8113.1/Y.1372.1,=20 > Operations, Administration and Maintenance mechanism for=20 > MPLS-TP in Packet Transport Network (PTN). Unfortunately the=20 > Study Group could not approve this Recommendation so it was=20 > forwarded to the WTSA (20-29 November 2012) for approval. =20 > One of the issues that prevented the approval in SG 15 was=20 > the lack of an ACh code point to support this Recommendation.=20 > To resolve this issue SG 15 therefore requests the IETF to=20 > assign an ACh code point. An IETF draft=20 > draft-betts-itu-oam-ach-code-point has been submitted to=20 > request this code point. > We have attached the text of the current draft of=20 > Recommendation ITU-T G.8113.1/Y.1372.1 that has been=20 > forwarded to the WTSA for approval. > Attach: COM15R-22. >=20 > Attachment(s): >=20 > LS370 - pdf body=20 > https://datatracker.ietf.org/documents/LIAISON/file1306.pdf >=20 > LS370 - pdf attachment=20 > https://datatracker.ietf.org/documents/LIAISON/file1307.pdf >=20 >=20 >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From chalikars@gmail.com Tue Jan 10 05:19:37 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27B421F84F1 for ; Tue, 10 Jan 2012 05:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, 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 mSL+MGw7+7gm for ; Tue, 10 Jan 2012 05:19:34 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9376521F84EC for ; Tue, 10 Jan 2012 05:19:33 -0800 (PST) Received: by wibhj6 with SMTP id hj6so4369415wib.31 for ; Tue, 10 Jan 2012 05:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=JrdHFTbKdSYR641yU4U+4z6ml9G3wsty1cr2KL5IZJs=; b=iT0R9N0wiuu3pALXyott+h+W4LjbTaRGlALmxu/0SPewRxslECe8YBdCZjWDBWRSgP i4ZrC0pqw5nOMhPJutJLBITW5inQ6KAoN3NLGgbb/PWFa78EKvd+Ce40uUITW2/cNAzq jbq3DZ1xGTrDZGJ/Vx/KO9JdlLBdEcedsuV7o= Received: by 10.180.75.7 with SMTP id y7mr35906677wiv.2.1326201572521; Tue, 10 Jan 2012 05:19:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.83.3 with HTTP; Tue, 10 Jan 2012 05:19:00 -0800 (PST) In-Reply-To: References: From: Sanjay Chalikar Date: Tue, 10 Jan 2012 18:49:00 +0530 Message-ID: Subject: Re: Ietf Digest, Vol 44, Issue 17 To: ietf@ietf.org Content-Type: multipart/alternative; boundary=f46d0434bf56a176a704b62c5d8f X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 13:19:37 -0000 --f46d0434bf56a176a704b62c5d8f Content-Type: text/plain; charset=ISO-8859-1 I agree to Dave's point but that should be description vs. operation + Prohibition also. We need to add a prohibition protocol field in the TCP/IP suite. that should be in IP Packet with perfect 8 bits field ... what say??? greetings, Sanjay Chalikar +91- 96 37 43 62 87. On Mon, Jan 9, 2012 at 11:11 PM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/ietf > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send Ietf mailing list submissions to > ietf@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/ietf > or, via email, send a message with subject or body 'help' to > ietf-request@ietf.org > > You can reach the person managing the list at > ietf-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ietf digest..." > > > Today's Topics: > > 1. Re: Protocol Definition (Dave CROCKER) > 2. Re: Protocol Definition (John Day) > 3. FW: New Liaison Statement, "LS370 - Current status of > Recommendation ITU-T G.8113.1/Y.1372.1, Operations, > Administration and Maintenance mechanism for MPLS-TP in Packet > Transport Network (PTN)" (Scott Mansfield) > 4. FW: New Liaison Statement, "LS368 - MPLS-TP Recommendations" > (Scott Mansfield) > 5. Re: Requirements for improving IETF remote participation > (Joel jaeggli) > 6. RE: Questions about draft-betts-itu-oam-ach-code-point > (Adrian Farrel) > 7. RE: [CCAMP] New Liaison Statement, "LS370 - Current status > ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, > Administration andMaintenance mechanism for MPLS-TP in > PacketTransport Network (PTN)" > (Sprecher, Nurit (NSN - IL/Hod HaSharon)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 09 Jan 2012 06:39:24 -0800 > From: Dave CROCKER > To: "t.petch" > Cc: dcrocker@bbiw.net, IETF-Discussion > Subject: Re: Protocol Definition > Message-ID: <4F0AFC1C.1060905@dcrocker.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > On 1/8/2012 12:03 AM, t.petch wrote: > > I agree that a message is not the right word, but I think that protocol > is:-) > > There is a specific distinction that is intended by having two different > words: > description vs. operation. > > A program is a description of behavior. A process is the operation of the > description. It is the behavioral performance. > > Protocol refers to the description of an interaction. The term being > explored > is for the operation of that description. It is the interaction. > > > > For the abstract side of networking, I would use the same terminology as > I would > > use for a 'program'. > > If you mean that you would say 'process' for both, that does have the > appeal of > familiarity, but the problem of overloading. Worse, I'd fear that it > encourages > a failure to appreciate the differences between networking architecture and > software implementation. Since this failure is quite prevalent, I suggest > we > not encourage it. > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > > ------------------------------ > > Message: 2 > Date: Mon, 9 Jan 2012 10:36:59 -0500 > From: John Day > To: dcrocker@bbiw.net, "t.petch" > Cc: dcrocker@bbiw.net, IETF-Discussion > Subject: Re: Protocol Definition > Message-ID: > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > > At 6:39 -0800 2012/01/09, Dave CROCKER wrote: > >On 1/8/2012 12:03 AM, t.petch wrote: > >>I agree that a message is not the right word, but I think that protocol > is:-) > > > >There is a specific distinction that is intended by having two > >different words: description vs. operation. > > > >A program is a description of behavior. A process is the operation > >of the description. It is the behavioral performance. > > > >Protocol refers to the description of an interaction. The term > >being explored is for the operation of that description. It is the > >interaction. > > > > Agreed. > > >>For the abstract side of networking, I would use the same > >>terminology as I would > >>use for a 'program'. > > > >If you mean that you would say 'process' for both, that does have > >the appeal of familiarity, but the problem of overloading. Worse, > >I'd fear that it encourages a failure to appreciate the differences > >between networking architecture and software implementation. Since > >this failure is quite prevalent, I suggest we not encourage it. > > Well, pretty close. There is a copious literature on the formal > description and verification of protocols beginning in the 70s. > > There are two major issues that is not normally found in defining a > "program": 1) is specifying the asynchrony, ensuring no races, and > 2) keeping the specification implementation independent. One does > not want the specification to unnecessarily constrain the > implementation strategy. The general rule is Day's First Rule of > Architecture: Anything you can get away with that is undetectable > from the outside is legal. Or when it comes to implementation sleaze > the architecture. > > We have seen the problems of code monoculture or just assuming the > other guys knew how to code. > > Take care, > John > > > ------------------------------ > > Message: 3 > Date: Sun, 8 Jan 2012 08:53:05 -0500 > From: Scott Mansfield > To: "ietf@ietf.org" , "mpls@ietf.org" , > "pwe3@ietf.org" , "ccamp@ietf.org" > Cc: "swallow@cisco.com" , "stbryant@cisco.com" > , "adrian@olddog.co.uk" >, > "andrew.g.malis@verizon.com" , > "dbrungard@att.com" > Subject: FW: New Liaison Statement, "LS370 - Current status of > Recommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration > and > Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" > Message-ID: > < > FDC72027C316A44F82F425284E1C4C321736E51ABE@EUSAACMS0701.eamcs.ericsson.se> > > Content-Type: text/plain; charset="us-ascii" > > > This is a liaison from the ITU-T SG15 WP3 providing a copy of the > Determined recommendation G.8113.1 (May 2011). The liaison also provides a > pointer to the internet draft draft-betts-itu-oam-ach-code-point that > requests an ACh code point that is needed by G.8113.1. This is a liaison > that will require a response and the ITU-T has requested a response no > later than 1 August 2012. I would suggest that we use the liaison response > to provide the outcome of running the IETF process required to assign the > requested code point. > > Regards, > -scott. > IETF-ITU Liaison Manager for MPLS > > > > -----Original Message----- > > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org] > > Sent: Sunday, January 08, 2012 3:23 AM > > To: chair@ietf.org > > Cc: yoichi.maeda@ttc.or.jp; > > steve.trowbridge@alcatel-lucent.com; iesg@ietf.org; > > lear@cisco.com; Scott Mansfield; malcolm.betts@zte.com.cn; > > tsbsg15@itu.int; greg.jones@itu.int; hiroshi.ota@itu.int > > Subject: New Liaison Statement, "LS370 - Current status of > > Recommendation ITU-T G.8113.1/Y.1372.1, Operations, > > Administration and Maintenance mechanism for MPLS-TP in > > Packet Transport Network (PTN)" > > > > Title: LS370 - Current status of Recommendation ITU-T > > G.8113.1/Y.1372.1, Operations, Administration and Maintenance > > mechanism for MPLS-TP in Packet Transport Network (PTN) > > Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/ > > > > From: ITU-T SG 15 (Greg Jones ) > > To: The IESG (chair@ietf.org) > > Cc: > > yoichi.maeda@ttc.or.jp,steve.trowbridge@alcatel-lucent.com,ies > > g@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com > > Reponse Contact: > > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > > Technical Contact: malcolm.betts@zte.com.cn > > Purpose: For information > > > > Body: The December meeting of ITU-T Study Group 15 considered > > the approval of Recommendation ITU-T G.8113.1/Y.1372.1, > > Operations, Administration and Maintenance mechanism for > > MPLS-TP in Packet Transport Network (PTN). Unfortunately the > > Study Group could not approve this Recommendation so it was > > forwarded to the WTSA (20-29 November 2012) for approval. > > One of the issues that prevented the approval in SG 15 was > > the lack of an ACh code point to support this Recommendation. > > To resolve this issue SG 15 therefore requests the IETF to > > assign an ACh code point. An IETF draft > > draft-betts-itu-oam-ach-code-point has been submitted to > > request this code point. > > We have attached the text of the current draft of > > Recommendation ITU-T G.8113.1/Y.1372.1 that has been > > forwarded to the WTSA for approval. > > Attach: COM15R-22. > > > > Attachment(s): > > > > LS370 - pdf body > > https://datatracker.ietf.org/documents/LIAISON/file1306.pdf > > > > LS370 - pdf attachment > > https://datatracker.ietf.org/documents/LIAISON/file1307.pdf > > > > > > > > ------------------------------ > > Message: 4 > Date: Sun, 8 Jan 2012 09:01:22 -0500 > From: Scott Mansfield > To: "ietf@ietf.org" , "mpls@ietf.org" , > "pwe3@ietf.org" , "ccamp@ietf.org" > Cc: "swallow@cisco.com" , "stbryant@cisco.com" > , "adrian@olddog.co.uk" >, > "andrew.g.malis@verizon.com" , > "dbrungard@att.com" > Subject: FW: New Liaison Statement, "LS368 - MPLS-TP Recommendations" > Message-ID: > < > FDC72027C316A44F82F425284E1C4C321736E51ABF@EUSAACMS0701.eamcs.ericsson.se> > > Content-Type: text/plain; charset="us-ascii" > > > > This is a liaison from SG15 Q9, Q12, and Q14 providing the text of > G.8110.1, G.8121, and G.8151. This liaison is for information only. > G.8110.1 was approved at the SG15 plenary meeting in December 2011. > G.8121 and G.8151 entered the alternative approval process (AAP) and will > enter a 4 week last call (the last call hasn't been initiated yet). > > Regards, > -scott. > IETF-ITU Liaison Manager for MPLS > > > -----Original Message----- > > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org] > > Sent: Sunday, January 08, 2012 3:51 AM > > To: rcallon@juniper.net; swallow@cisco.com; loa@pi.nu > > Cc: yoichi.maeda@ttc.or.jp; > > steve.trowbridge@alcatel-lucent.com; mpls@ietf.org; > > lear@cisco.com; Scott Mansfield; stbryant@cisco.com; > > adrian@olddog.co.uk; malcolm.betts@zte.com.cn; Ghani Abbas; > > Kam.Lam@alcatel-lucent.com; tsbsg15@itu.int; > > greg.jones@itu.int; hiroshi.ota@itu.int > > Subject: New Liaison Statement, "LS368 - MPLS-TP Recommendations" > > > > Title: LS368 - MPLS-TP Recommendations > > Submission Date: 2012-01-08 > > URL of the IETF Web page: /liaison/1126/ > > > > From: ITU-T SG 15 (Greg Jones ) > > To: Multiprotocol Label Switching (rcallon@juniper.net, > > swallow@cisco.com, loa@pi.nu) > > Cc: > > yoichi.maeda@ttc.or.jp,steve.trowbridge@alcatel-lucent.com,mpl > > s@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com,stbryan > > t@cisco.com,adrian@olddog.co.uk > > Reponse Contact: > > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > > Technical Contact: > > malcolm.betts@zte.com.cn,Ghani.Abbas@ericsson.com,Kam.Lam@alca > > tel-lucent.com > > Purpose: For information > > > > Body: At the December 2011 meeting of ITU-T Study Group 15, > > Recommendation ITU-T G.8110.1/Y.1370.1 "Architecture of MPLS > > Transport Profile (MPLS-TP) layer network" was approved. A > > copy is attached for your information. > > We would like to draw your attention to clause 10 that > > describes the MPLS-TP Diff-Serv Architecture. > > In addition, the approval process was initiated for > > Recommendations ITU-T G.8121/Y.1381 "Characteristics of > > MPLS-TP Network Equipment Functional Blocks" and ITU-T > > G.8151/Y.1374 "Management aspects of the MPLS-TP network element". > > > > Attach: TD517/PLEN Rev.3, TD540/PLEN Rev.1, TD543/PLEN Rev.1. > > > > Attachment(s): > > > > LS368 - pdf body > > https://datatracker.ietf.org/documents/LIAISON/file1308.pdf > > > > LS368 - Att1_PLEN-517Rev3 > > https://datatracker.ietf.org/documents/LIAISON/file1309.pdf > > > > LS368 - Att2_PLEN-540Rev1 > > https://datatracker.ietf.org/documents/LIAISON/file1310.pdf > > > > LS368 - Att3_PLEN-543Rev1 > > https://datatracker.ietf.org/documents/LIAISON/file1311.pdf > > > > > > > > ------------------------------ > > Message: 5 > Date: Mon, 09 Jan 2012 09:09:48 -0800 > From: Joel jaeggli > To: SM > Cc: IETF Discussion , Paul Hoffman > > Subject: Re: Requirements for improving IETF remote participation > Message-ID: <4F0B1F5C.10400@bogus.com> > Content-Type: text/plain; charset=ISO-8859-1 > > > On 1/6/12 02:00 , SM wrote: > > "The RPS tools must be available for lunch meetings scheduled by > > the IETF Secretariat, such as for the Security Directorate" > > > > I object to the non-inclusion of the kangaroo directorate (no offense > > intended). :-) > > That implies coverage of a much greater number of rooms, e.g. 16 or more > potentialy. when you count the offices and small breakout rooms in > addition to the 8 scheduled meeting rooms. > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > > > > ------------------------------ > > Message: 6 > Date: Mon, 9 Jan 2012 17:33:16 -0000 > From: "Adrian Farrel" > To: , "'Huub > helvoort'" > Cc: mpls@ietf.org, ietf@ietf.org > Subject: RE: Questions about draft-betts-itu-oam-ach-code-point > Message-ID: <01cf01cccef4$c5e6ef90$51b4ceb0$@olddog.co.uk> > Content-Type: text/plain; charset="us-ascii" > > Hi Huub and Malcolm, > > I recognise that the intervening month between my original email and this > one > included an SG15 meeting, Christmas, and New Year, but I had hoped for a > response by now so that we could work out what to do with the document. > > In the meantime, at least my question 4 has progressed. Can you confirm > that the > version of G.8113.1 for which a code point is requested is that which has > been > sent to WTSA by SG15 (i.e., that which was determined), and that there are > no > plans to make any updates or revisions to that document until after it has > been > approved. > > Thanks, > Adrian > > > -----Original Message----- > > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > Adrian > > Farrel > > Sent: 09 December 2011 10:49 > > To: draft-betts-itu-oam-ach-code-point@tools.ietf.org; 'Huub helvoort' > > Cc: mpls@ietf.org; ietf@ietf.org > > Subject: Questions about draft-betts-itu-oam-ach-code-point > > > > Hi Malcolm and Huub, > > > > I have squeezed a little time from the current ITU-T meeting to look at > your > > draft and write-up. I have also read the email threads on the IETF > discussion > > list and the MPLS list. Sorry that this has taken me a week to process, > but > your > > publication request came at pretty much the worst possible time for > getting me > > to do this task. > > > > I don't like proliferating threads across multiple mailing lists. On the > other > > hand it is difficult to ensure that all the constituencies are present, > so I > am > > perpetuating the cross-posting. > > > > My review of the document... > > > > 1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I > think > > only one of these is real (the spurious space in a citation). The other > nits > are > > spurious caused by citations wrapping across lines. Could you please > keep a > note > > of the nit so that you can fix it the next time the draft is respun or > so it > can > > be captured in an RFC Editor Note at a later stage (you don't have to > post a > new > > revision to address this now unless you really want to). > > > > 2. This document requests a code point from a registry that contains code > points > > that are used equally for MPLS LSPs and pseudowires. I can't tell from > the I-D > > whether it is your intention that your code point would also be > applicable in > > both cases. What is your intention? Is this "obvious" from G.8113.1 or > does it > > need to be clarified? > > > > > > My review of the write-up and discussions... > > > > 3. There seems to be quite a feeling on the mailing lists that this > document > > should be run through the MPLS working group. The write-up makes a case > for > > progressing it as AD sponsored. As far as I can see, the main assertions > to > > answer are as follows. Do you have a view on these points before I make a > > decision on what to do? > > > > a. This is a proposal to use an MPLS code point and so is part of MPLS by > > definition. > > > > b. The type of network being managed by the OAM described in G.8113.1 is > an > > MPLS network. Therefore, this is clearly relevant to the MPLS working . > > > > Do you object to this going through the MPLS on principle, or were you > just > > hoping to save the WG the work? If the latter, and if the WG wants to > look at > > the draft, the easiest approach seems to be to redirect the work to the > working > > group. > > > > 4. G.8113.1 is clearly important to understanding to which the code > point is > > being put. Thus, an available and stable copy of group. G.8113.1 will be > key > to > > the last call review of you I-D. Can you make a stable copy available > (for > > example, through liaison)? How does the editing work currently in > progress in > > the SG15 meeting affect that availability? > > > > 5. Can you clarify for me why the suggested value has been suggested. > This > will > > help guide IANA who would normally do their allocation in a "tidy" way. > > > > Looking forward to your reply. > > > > Thanks, > > Adrian > > > > ------------------------------ > > Message: 7 > Date: Mon, 9 Jan 2012 18:41:43 +0100 > From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" > > To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" > , "ext Scott Mansfield" > , , < > mpls@ietf.org>, > , > Cc: andrew.g.malis@verizon.com, dbrungard@att.com > Subject: RE: [CCAMP] New Liaison Statement, "LS370 - Current status > ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, > Administration > andMaintenance mechanism for MPLS-TP in PacketTransport Network > (PTN)" > Message-ID: > <077E41CFFD002C4CAB7DFA4386A5326405178E7C@DEMUEXC014.nsn-intra.net> > Content-Type: text/plain; charset="windows-1255" > > When saying support, I mean of course that I fully support the proposal of > Scott! > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of > Sprecher, Nurit (NSN - IL/Hod HaSharon) > Sent: ? 09 ????? 2012 19:20 > To: ext Scott Mansfield; ietf@ietf.org; mpls@ietf.org; pwe3@ietf.org; > ccamp@ietf.org > Cc: andrew.g.malis@verizon.com; dbrungard@att.com > Subject: Re: [CCAMP] New Liaison Statement,"LS370 - Current status > ofRecommendation ITU-T G.8113.1/Y.1372.1,Operations,Administration > andMaintenance mechanism for MPLS-TP in PacketTransport Network (PTN)" > > Support > > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > ext Scott Mansfield > Sent: ? 08 ????? 2012 15:53 > To: ietf@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Cc: swallow@cisco.com; stbryant@cisco.com; adrian@olddog.co.uk; > andrew.g.malis@verizon.com; dbrungard@att.com > Subject: FW: New Liaison Statement, "LS370 - Current status > ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration > andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" > > > This is a liaison from the ITU-T SG15 WP3 providing a copy of the > Determined recommendation G.8113.1 (May 2011). The liaison also provides a > pointer to the internet draft draft-betts-itu-oam-ach-code-point that > requests an ACh code point that is needed by G.8113.1. This is a liaison > that will require a response and the ITU-T has requested a response no > later than 1 August 2012. I would suggest that we use the liaison response > to provide the outcome of running the IETF process required to assign the > requested code point. > > Regards, > -scott. > IETF-ITU Liaison Manager for MPLS > > > > -----Original Message----- > > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org] > > Sent: Sunday, January 08, 2012 3:23 AM > > To: chair@ietf.org > > Cc: yoichi.maeda@ttc.or.jp; > > steve.trowbridge@alcatel-lucent.com; iesg@ietf.org; > > lear@cisco.com; Scott Mansfield; malcolm.betts@zte.com.cn; > > tsbsg15@itu.int; greg.jones@itu.int; hiroshi.ota@itu.int > > Subject: New Liaison Statement, "LS370 - Current status of > > Recommendation ITU-T G.8113.1/Y.1372.1, Operations, > > Administration and Maintenance mechanism for MPLS-TP in > > Packet Transport Network (PTN)" > > > > Title: LS370 - Current status of Recommendation ITU-T > > G.8113.1/Y.1372.1, Operations, Administration and Maintenance > > mechanism for MPLS-TP in Packet Transport Network (PTN) > > Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/ > > > > From: ITU-T SG 15 (Greg Jones ) > > To: The IESG (chair@ietf.org) > > Cc: > > yoichi.maeda@ttc.or.jp,steve.trowbridge@alcatel-lucent.com,ies > > g@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com > > Reponse Contact: > > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > > Technical Contact: malcolm.betts@zte.com.cn > > Purpose: For information > > > > Body: The December meeting of ITU-T Study Group 15 considered > > the approval of Recommendation ITU-T G.8113.1/Y.1372.1, > > Operations, Administration and Maintenance mechanism for > > MPLS-TP in Packet Transport Network (PTN). Unfortunately the > > Study Group could not approve this Recommendation so it was > > forwarded to the WTSA (20-29 November 2012) for approval. > > One of the issues that prevented the approval in SG 15 was > > the lack of an ACh code point to support this Recommendation. > > To resolve this issue SG 15 therefore requests the IETF to > > assign an ACh code point. An IETF draft > > draft-betts-itu-oam-ach-code-point has been submitted to > > request this code point. > > We have attached the text of the current draft of > > Recommendation ITU-T G.8113.1/Y.1372.1 that has been > > forwarded to the WTSA for approval. > > Attach: COM15R-22. > > > > Attachment(s): > > > > LS370 - pdf body > > https://datatracker.ietf.org/documents/LIAISON/file1306.pdf > > > > LS370 - pdf attachment > > https://datatracker.ietf.org/documents/LIAISON/file1307.pdf > > > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > > ------------------------------ > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > > End of Ietf Digest, Vol 44, Issue 17 > ************************************ > --f46d0434bf56a176a704b62c5d8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
      I agree to Dave's point but th= at should be=A0 description vs. operation + Prohibition also. We need to add a prohibition = protocol field in the TCP/IP suite. that should be in IP Packet with perfec= t 8 bits field ... what say???

      <= /font>
      greetings,
      Sanjay Chalikar
      +91-=A096 37 43 62 87.
      =



      On Mon, Jan 9, 2012 at 11:11 PM, <ietf-request@ietf.= org> wrote:
      If you have received this digest without all the individual message
      attachments you will need to update your digest options in your list
      subscription. =A0To do so, go to

      ht= tps://www.ietf.org/mailman/listinfo/ietf

      Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
      MIME or Plain Text Digests?" to MIME. =A0You can set this option
      globally for all the list digests you receive at this point.



      Send Ietf mailing list submissions to
      =A0 =A0 =A0 =A0ietf@ietf.org

      To subscribe or unsubscribe via the World Wide Web, visit
      =A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/ietf
      or, via email, send a message with subject or body 'help' to
      =A0 =A0 =A0 =A0ietf-request@ietf.= org

      You can reach the person managing the list at
      =A0 =A0 =A0 =A0ietf-owner@ietf.org<= /a>

      When replying, please edit your Subject line so it is more specific
      than "Re: Contents of Ietf digest..."


      Today's Topics:

      =A0 1. Re: Protocol Definition (Dave CROCKER)
      =A0 2. Re: Protocol Definition (John Day)
      =A0 3. FW: New Liaison Statement, "LS370 - Current status of
      =A0 =A0 =A0Recommendation ITU-T G.8113.1/Y.1372.1, Operations,
      =A0 =A0 =A0Administration and =A0 =A0 =A0 =A0Maintenance mechanism for MPL= S-TP in Packet
      =A0 =A0 =A0Transport Network (PTN)" (Scott Mansfield)
      =A0 4. FW: New Liaison Statement, "LS368 - MPLS-TP Recommendations&qu= ot;
      =A0 =A0 =A0(Scott Mansfield)
      =A0 5. Re: Requirements for improving IETF remote participation
      =A0 =A0 =A0(Joel jaeggli)
      =A0 6. RE: Questions about draft-betts-itu-oam-ach-code-point
      =A0 =A0 =A0(Adrian Farrel)
      =A0 7. RE: [CCAMP] New Liaison Statement, =A0 =A0 =A0 =A0"LS370 - Cur= rent status
      =A0 =A0 =A0ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations,
      =A0 =A0 =A0Administration andMaintenance mechanism for MPLS-TP in
      =A0 =A0 =A0PacketTransport =A0 Network (PTN)"
      =A0 =A0 =A0(Sprecher, Nurit (NSN - IL/Hod HaSharon))


      ----------------------------------------------------------------------

      Message: 1
      Date: Mon, 09 Jan 2012 06:39:24 -0800
      From: Dave CROCKER <      dhc@dcrocker.net= >
      To: "t.petch" <daedu= lus@btconnect.com>
      Cc: dcrocker@bbiw.net, IETF-Discus= sion <ietf@ietf.org>
      Subject: Re: Protocol Definition
      Message-ID: <4F0AFC1C.1= 060905@dcrocker.net>
      Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed



      On 1/8/2012 12:03 AM, t.petch wrote:
      > I agree that a message is not the right word, but I think that protoco= l is:-)

      There is a specific distinction that is intended by having two different wo= rds:
      =A0description vs. operation.

      A program is a description of behavior. =A0A process is the operation of th= e
      description. =A0It is the behavioral performance.

      Protocol refers to the description of an interaction. =A0The term being exp= lored
      is for the operation of that description. It is the interaction.


      > For the abstract side of networking, I would use the same terminology = as I would
      > use for a 'program'.

      If you mean that you would say 'process' for both, that does have t= he appeal of
      familiarity, but the problem of overloading. =A0Worse, I'd fear that it= encourages
      a failure to appreciate the differences between networking architecture and=
      software implementation. =A0Since this failure is quite prevalent, I sugges= t we
      not encourage it.

      d/
      --

      =A0 Dave Crocker
      =A0 Brandenburg InternetWorking
      =A0 bbiw.net


      ------------------------------

      Message: 2
      Date: Mon, 9 Jan 2012 10:36:59 -0500
      From: John Day <jeanjour@comcast= .net>
      To: dcrocker@bbiw.net, "t.pet= ch" <daedulus@btconnect.c= om>
      Cc: dcrocker@bbiw.net, IETF-Discus= sion <ietf@ietf.org>
      Subject: Re: Protocol Definition
      Message-ID: <a06240809cb30b7a03ac3@[10.0.1.26]>
      Content-Type: text/plain; charset=3D"us-ascii" ; format=3D"f= lowed"

      At 6:39 -0800 2012/01/09, Dave CROCKER wrote:
      >On 1/8/2012 12:03 AM, t.petch wrote:
      >>I agree that a message is not the right word, but I think that prot= ocol is:-)
      >
      >There is a specific distinction that is intended by having two
      >different words: =A0description vs. operation.
      >
      >A program is a description of behavior. =A0A process is the operation >of the description. =A0It is the behavioral performance.
      >
      >Protocol refers to the description of an interaction. =A0The term
      >being explored is for the operation of that description. It is the
      >interaction.
      >

      Agreed.

      >>For the abstract side of networking, I would use the same
      >>terminology as I would
      >>use for a 'program'.
      >
      >If you mean that you would say 'process' for both, that does ha= ve
      >the appeal of familiarity, but the problem of overloading. =A0Worse, >I'd fear that it encourages a failure to appreciate the differences=
      >between networking architecture and software implementation. =A0Since >this failure is quite prevalent, I suggest we not encourage it.

      Well, pretty close. =A0There is a copious literature on the formal
      description and verification of protocols beginning in the 70s.

      There are two major issues that is not normally found in defining a
      "program": =A01) is specifying the asynchrony, ensuring no races,= and
      2) keeping the specification implementation independent. =A0One does
      not want the specification to unnecessarily constrain the
      implementation strategy. =A0The general rule is Day's First Rule of
      Architecture: =A0Anything you can get away with that is undetectable
      from the outside is legal. =A0Or when it comes to implementation sleaze
      the architecture.

      We have seen the problems of code monoculture or just assuming the
      other guys knew how to code.

      Take care,
      John


      ------------------------------

      Message: 3
      Date: Sun, 8 Jan 2012 08:53:05 -0500
      From: Scott Mansfield <s= cott.mansfield@ericsson.com>
      To: "ietf@ietf.org" <ietf@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>,
      =A0 =A0 =A0 =A0"pwe3@ietf.org&qu= ot; <pwe3@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>
      Cc: "swallow@cisco.com" = <swallow@cisco.com>, =A0 =A0= "stbryant@cisco.com" =A0 =A0 =A0 =A0<stbryant@cisco.co= m>, =A0 "adrian@olddog.c= o.uk" <adrian@olddog.co.= uk>,
      =A0 =A0 =A0 =A0"andrew.= g.malis@verizon.com" <andrew.g.malis@verizon.com>,
      =A0 =A0 =A0 =A0"dbrungard@att.co= m" <dbrungard@att.com&= gt;
      Subject: FW: New Liaison Statement, "LS370 - Current status of
      =A0 =A0 =A0 =A0Recommendation ITU-T G.8113.1/Y.1372.1, Operations, Adminis= tration and
      =A0 =A0 =A0 =A0Maintenance mechanism for MPLS-TP in Packet Transport Netwo= rk (PTN)"
      Message-ID:
      =A0 =A0 =A0 =A0<FDC72027C316A44F82F425284E1C4C321736E= 51ABE@EUSAACMS0701.eamcs.ericsson.se>

      Content-Type: text/plain; charset=3D"us-ascii"


      This is a liaison from the ITU-T SG15 WP3 providing a copy of the Determine= d recommendation G.8113.1 (May 2011). =A0The liaison also provides a pointe= r to the internet draft draft-betts-itu-oam-ach-code-point that requests an= ACh code point that is needed by G.8113.1. =A0This is a liaison that will = require a response and the ITU-T has requested a response no later than 1 A= ugust 2012. =A0I would suggest that we use the liaison response to provide = the outcome of running the IETF process required to assign the requested co= de point.

      Regards,
      -scott.
      IETF-ITU Liaison Manager for MPLS


      > -----Original Message-----
      > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]
      > Sent: Sunday, January 08, 2012 3:23 AM
      > To: chair@ietf.org
      > Cc: yoichi.maeda@ttc.or.jp;
      >       steve.trowbridg= e@alcatel-lucent.com; iesg@ietf.org;
      >       lear@cisco.com; Scott Mansfield;= malcolm.betts@zte.com.cn;<= br> > tsbsg15@itu.int; greg.jones@itu.int; hiroshi.ota@itu.int
      > Subject: New Liaison Statement, "LS370 - Current status of
      > Recommendation ITU-T G.8113.1/Y.1372.1, Operations,
      > Administration and Maintenance mechanism for MPLS-TP in
      > Packet Transport Network (PTN)"
      >
      > Title: LS370 - Current status of Recommendation ITU-T
      > G.8113.1/Y.1372.1, Operations, Administration and Maintenance
      > mechanism for MPLS-TP in Packet Transport Network (PTN)
      > Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/ >
      > From: ITU-T SG 15 =A0(Greg Jones <greg.jones@itu.int>)
      > To: The IESG (chair@ietf.org) > Cc:
      > yoichi.maeda@ttc.or.jp,<= a href=3D"mailto:steve.trowbridge@alcatel-lucent.com">steve.trowbridge@alca= tel-lucent.com,ies
      > g@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com
      > Reponse Contact:
      > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int
      > Technical Contact: malcolm= .betts@zte.com.cn
      > Purpose: For information
      >
      > Body: The December meeting of ITU-T Study Group 15 considered
      > the approval of Recommendation ITU-T G.8113.1/Y.1372.1,
      > Operations, Administration and Maintenance mechanism for
      > MPLS-TP in Packet Transport Network (PTN). =A0Unfortunately the
      > Study Group could not approve this Recommendation so it was
      > forwarded to the WTSA (20-29 November 2012) for approval.
      > One of the issues that prevented the approval in SG 15 was
      > the lack of an ACh code point to support this Recommendation.
      > =A0To resolve this issue SG 15 therefore requests the IETF to
      > assign an ACh code point. =A0An IETF draft
      > draft-betts-itu-oam-ach-code-point has been submitted to
      > request this code point.
      > We have attached the text of the current draft of
      > Recommendation ITU-T G.8113.1/Y.1372.1 that has been
      > forwarded to the WTSA for approval.
      > Attach: COM15R-22.
      >
      > Attachment(s):
      >
      > =A0 =A0 LS370 - pdf body
      > https://datatracker.ietf.org/documents/LIAISON/file1306= .pdf
      >
      > =A0 =A0 LS370 - pdf attachment
      > https://datatracker.ietf.org/documents/LIAISON/file1307= .pdf
      >
      >
      >

      ------------------------------

      Message: 4
      Date: Sun, 8 Jan 2012 09:01:22 -0500
      From: Scott Mansfield <s= cott.mansfield@ericsson.com>
      To: "ietf@ietf.org" <ietf@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>,
      =A0 =A0 =A0 =A0"pwe3@ietf.org&qu= ot; <pwe3@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>
      Cc: "swallow@cisco.com" = <swallow@cisco.com>, =A0 =A0= "stbryant@cisco.com" =A0 =A0 =A0 =A0<stbryant@cisco.co= m>, =A0 "adrian@olddog.c= o.uk" <adrian@olddog.co.= uk>,
      =A0 =A0 =A0 =A0"andrew.= g.malis@verizon.com" <andrew.g.malis@verizon.com>,
      =A0 =A0 =A0 =A0"dbrungard@att.co= m" <dbrungard@att.com&= gt;
      Subject: FW: New Liaison Statement, "LS368 - MPLS-TP Recommendations&q= uot;
      Message-ID:
      =A0 =A0 =A0 =A0<FDC72027C316A44F82F425284E1C4C321736E= 51ABF@EUSAACMS0701.eamcs.ericsson.se>

      Content-Type: text/plain; charset=3D"us-ascii"



      This is a liaison from SG15 Q9, Q12, and Q14 providing the text of G.8110.1= , G.8121, and G.8151. =A0This liaison is for information only. =A0G.8110.1 = was approved at the SG15 plenary meeting in December 2011. =A0G.8121 and G.= 8151 entered the alternative approval process (AAP) and will enter a 4 week= last call (the last call hasn't been initiated yet).

      Regards,
      -scott.
      IETF-ITU Liaison Manager for MPLS

      > -----Original Message-----
      > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]
      > Sent: Sunday, January 08, 2012 3:51 AM
      > To: rcallon@juniper.net; swallow@cisco.com; loa@pi.nu
      > Cc: yoichi.maeda@ttc.or.jp;
      >       steve.trowbridg= e@alcatel-lucent.com; mpls@ietf.org      ;
      >       lear@cisco.com; Scott Mansfield;= stbryant@cisco.com;
      > adrian@olddog.co.uk; malcolm.betts@zte.com.cn; Ghani A= bbas;
      > Kam.Lam@alcatel-lucent.c= om; tsbsg15@itu.int;
      > greg.jones@itu.int; hiroshi.ota@itu.int
      > Subject: New Liaison Statement, "LS368 - MPLS-TP Recommendations&= quot;
      >
      > Title: LS368 - MPLS-TP Recommendations
      > Submission Date: 2012-01-08
      > URL of the IETF Web page: /liaison/1126/
      >
      > From: ITU-T SG 15 =A0(Greg Jones <greg.jones@itu.int>)
      > To: Multiprotocol Label Switching (rcallon@juniper.net,
      > swallow@cisco.com, loa@pi.nu)
      > Cc:
      > yoichi.maeda@ttc.or.jp,<= a href=3D"mailto:steve.trowbridge@alcatel-lucent.com">steve.trowbridge@alca= tel-lucent.com,mpl
      > s@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com,stbryan
      > t@cisco.com,adrian@olddog.co.uk
      > Reponse Contact:
      > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int
      > Technical Contact:
      > malcolm.betts@zte.com.cn,Ghani.Abbas@ericsson.com= ,Kam.Lam@alca
      > tel-lucent.com=
      > Purpose: For information
      >
      > Body: At the December 2011 meeting of ITU-T Study Group 15,
      > Recommendation ITU-T G.8110.1/Y.1370.1 "Architecture of MPLS
      > Transport Profile (MPLS-TP) layer network" was approved. =A0A
      > copy is attached for your information.
      > We would like to draw your attention to clause 10 that
      > describes the MPLS-TP Diff-Serv Architecture.
      > In addition, the approval process was initiated for
      > Recommendations ITU-T G.8121/Y.1381 "Characteristics of
      > MPLS-TP Network Equipment Functional Blocks" and ITU-T
      > G.8151/Y.1374 "Management aspects of the MPLS-TP network element&= quot;.
      >
      > Attach: TD517/PLEN Rev.3, TD540/PLEN Rev.1, TD543/PLEN Rev.1.
      >
      > Attachment(s):
      >
      > =A0 =A0 LS368 - pdf body
      > https://datatracker.ietf.org/documents/LIAISON/file1308= .pdf
      >
      > =A0 =A0 LS368 - Att1_PLEN-517Rev3
      > https://datatracker.ietf.org/documents/LIAISON/file1309= .pdf
      >
      > =A0 =A0 LS368 - Att2_PLEN-540Rev1
      > https://datatracker.ietf.org/documents/LIAISON/file1310= .pdf
      >
      > =A0 =A0 LS368 - Att3_PLEN-543Rev1
      > https://datatracker.ietf.org/documents/LIAISON/file1311= .pdf
      >
      >
      >

      ------------------------------

      Message: 5
      Date: Mon, 09 Jan 2012 09:09:48 -0800
      From: Joel jaeggli <joelja@bogus.com= >
      To: SM <sm@resistor.net>
      Cc: IETF Discussion <ietf@ietf.org&= gt;, Paul Hoffman
      =A0 =A0 =A0 =A0<paul.hoffman@v= pnc.org>
      Subject: Re: Requirements for improving IETF remote participation
      Message-ID: <4F0B1F5C.10400@= bogus.com>
      Content-Type: text/plain; charset=3DISO-8859-1


      On 1/6/12 02:00 , SM wrote:
      > =A0 "The RPS tools must be available for lunch meetings scheduled= by
      > =A0 =A0the IETF Secretariat, such =A0as for the Security Directorate&q= uot;
      >
      > I object to the non-inclusion of the kangaroo directorate (no offense<= br> > intended). :-)

      That implies coverage of a much greater number of rooms, e.g. 16 or more potentialy. when you count the offices and small breakout rooms in
      addition to the 8 scheduled meeting rooms.

      > _______________________________________________
      > Ietf mailing list
      > Ietf@ietf.org
      > https://www.ietf.org/mailman/listinfo/ietf
      >



      ------------------------------

      Message: 6
      Date: Mon, 9 Jan 2012 17:33:16 -0000
      From: "Adrian Farrel" <= adrian@olddog.co.uk>
      To: <draft-betts-itu-oam-ach-code-point@tools.ietf.org>, =A0 =A0 =A0 = =A0"'Huub
      =A0 =A0 =A0 =A0helvoort'" <huub.van.helvoort@huawei.com>
      Cc: mpls@ietf.org, ietf@ietf.org
      Subject: RE: Questions about draft-betts-itu-oam-ach-code-point
      Message-ID: <01cf01cccef4$c5e6ef90$51b4ceb0$@olddog.co.uk>
      Content-Type: text/plain; =A0 =A0 =A0 charset=3D"us-ascii"

      Hi Huub and Malcolm,

      I recognise that the intervening month between my original email and this o= ne
      included an SG15 meeting, Christmas, and New Year, but I had hoped for a response by now so that we could work out what to do with the document.

      In the meantime, at least my question 4 has progressed. Can you confirm tha= t the
      version of G.8113.1 for which a code point is requested is that which has b= een
      sent to WTSA by SG15 (i.e., that which was determined), and that there are = no
      plans to make any updates or revisions to that document until after it has = been
      approved.

      Thanks,
      Adrian

      > -----Original Message-----
      > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Adrian
      > Farrel
      > Sent: 09 December 2011 10:49
      > To:       draft-betts-itu-oam-ach-code-point@tools.ietf.org; 'Huub helvoor= t'
      > Cc: mpls@ietf.org; ietf@ietf.org
      > Subject: Questions about draft-betts-itu-oam-ach-code-point
      >
      > Hi Malcolm and Huub,
      >
      > I have squeezed a little time from the current ITU-T meeting to look a= t your
      > draft and write-up. I have also read the email threads on the IETF dis= cussion
      > list and the MPLS list. Sorry that this has taken me a week to process= , but
      your
      > publication request came at pretty much the worst possible time for ge= tting me
      > to do this task.
      >
      > I don't like proliferating threads across multiple mailing lists. = On the other
      > hand it is difficult to ensure that all the constituencies are present= , so I
      am
      > perpetuating the cross-posting.
      >
      > My review of the document...
      >
      > 1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I think=
      > only one of these is real (the spurious space in a citation). The othe= r nits
      are
      > spurious caused by citations wrapping across lines. Could you please k= eep a
      note
      > of the nit so that you can fix it the next time the draft is respun or= so it
      can
      > be captured in an RFC Editor Note at a later stage (you don't have= to post a
      new
      > revision to address this now unless you really want to).
      >
      > 2. This document requests a code point from a registry that contains c= ode
      points
      > that are used equally for MPLS LSPs and pseudowires. I can't tell = from the I-D
      > whether it is your intention that your code point would also be applic= able in
      > both cases. What is your intention? Is this "obvious" from G= .8113.1 or does it
      > need to be clarified?
      >
      >
      > My review of the write-up and discussions...
      >
      > 3. There seems to be quite a feeling on the mailing lists that this do= cument
      > should be run through the MPLS working group. The write-up makes a cas= e for
      > progressing it as AD sponsored. As far as I can see, the main assertio= ns to
      > answer are as follows. Do you have a view on these points before I mak= e a
      > decision on what to do?
      >
      > a. This is a proposal to use an MPLS code point and so is part of MPLS= by
      > definition.
      >
      > b. The type of network being managed by the OAM described in G.8113.1 = is an
      > MPLS network. Therefore, this is clearly relevant to the MPLS working = .
      >
      > Do you object to this going through the MPLS on principle, or were you= just
      > hoping to save the WG the work? If the latter, and if the WG wants to = look at
      > the draft, the easiest approach seems to be to redirect the work to th= e
      working
      > group.
      >
      > 4. G.8113.1 is clearly important to understanding to which the code po= int is
      > being put. Thus, an available and stable copy of group. G.8113.1 will = be key
      to
      > the last call review of you I-D. Can you make a stable copy available = (for
      > example, through liaison)? How does the editing work currently in prog= ress in
      > the SG15 meeting affect that availability?
      >
      > 5. Can you clarify for me why the suggested value has been suggested. = This
      will
      > help guide IANA who would normally do their allocation in a "tidy= " way.
      >
      > Looking forward to your reply.
      >
      > Thanks,
      > Adrian



      ------------------------------

      Message: 7
      Date: Mon, 9 Jan 2012 18:41:43 +0100
      From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
      =A0 =A0 =A0 =A0<nurit.spreche= r@nsn.com>
      To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)"
      =A0 =A0 =A0 =A0<nurit.spreche= r@nsn.com>, =A0 =A0 =A0 "ext Scott Mansfield"
      =A0 =A0 =A0 =A0<scott.m= ansfield@ericsson.com>, <ietf@ie= tf.org>, =A0 =A0 =A0 =A0<mpls@ie= tf.org>,
      =A0 =A0 =A0 =A0<pwe3@ietf.org>,= <ccamp@ietf.org>
      Cc: andrew.g.malis@verizon.co= m, dbrungard@att.com
      Subject: RE: [CCAMP] New Liaison Statement, =A0 =A0 "LS370 - Current s= tatus
      =A0 =A0 =A0 =A0ofRecommendation ITU-T G.8113.1/Y.1372.1, =A0 =A0 =A0 Opera= tions, =A0 =A0 Administration
      =A0 =A0 =A0 =A0andMaintenance mechanism for MPLS-TP in PacketTransport Net= work (PTN)"
      Message-ID:
      =A0 =A0 =A0 =A0<077E41CFFD002C4CAB7DFA4386A5326405178E7C@DEMU= EXC014.nsn-intra.net>
      Content-Type: text/plain; =A0 =A0 =A0 charset=3D"windows-1255"
      When saying support, I mean of course that I fully support the proposal of = Scott!

      -----Original Message-----
      From: ccamp-bounces@ietf.org = [mailto:ccamp-bounces@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
      Sent: ? 09 ????? 2012 19:20
      To: ext Scott Mansfield;       ietf@ietf.org= ; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf= .org
      Cc: andrew.g.malis@verizon.co= m; dbrungard@att.com
      Subject: Re: [CCAMP] New Liaison Statement,"LS370 - Current status ofR= ecommendation ITU-T G.8113.1/Y.1372.1,Operations,Administration andMaintena= nce mechanism for MPLS-TP in PacketTransport Network (PTN)"

      Support

      -----Original Message-----
      From: ietf-bounces@ietf.org [m= ailto:ietf-bounces@ietf.org] O= n Behalf Of ext Scott Mansfield
      Sent: ? 08 ????? 2012 15:53
      To: ietf@ietf.org; mpls@ietf.org; pwe3@ietf= .org; ccamp@ietf.org
      Cc: swallow@cisco.com; stbryant@cisco.com; adrian@olddog.co.uk; andrew.g.malis@verizon.com; dbrungard@att.com
      Subject: FW: New Liaison Statement, "LS370 - Current status ofRecommen= dation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance m= echanism for MPLS-TP in Packet Transport Network (PTN)"


      This is a liaison from the ITU-T SG15 WP3 providing a copy of the Determine= d recommendation G.8113.1 (May 2011). =A0The liaison also provides a pointe= r to the internet draft draft-betts-itu-oam-ach-code-point that requests an= ACh code point that is needed by G.8113.1. =A0This is a liaison that will = require a response and the ITU-T has requested a response no later than 1 A= ugust 2012. =A0I would suggest that we use the liaison response to provide = the outcome of running the IETF process required to assign the requested co= de point.

      Regards,
      -scott.
      IETF-ITU Liaison Manager for MPLS


      > -----Original Message-----
      > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]
      > Sent: Sunday, January 08, 2012 3:23 AM
      > To: chair@ietf.org
      > Cc: yoichi.maeda@ttc.or.jp;
      >       steve.trowbridg= e@alcatel-lucent.com; iesg@ietf.org;
      >       lear@cisco.com; Scott Mansfield;= malcolm.betts@zte.com.cn;<= br> > tsbsg15@itu.int; greg.jones@itu.int; hiroshi.ota@itu.int
      > Subject: New Liaison Statement, "LS370 - Current status of
      > Recommendation ITU-T G.8113.1/Y.1372.1, Operations,
      > Administration and Maintenance mechanism for MPLS-TP in
      > Packet Transport Network (PTN)"
      >
      > Title: LS370 - Current status of Recommendation ITU-T
      > G.8113.1/Y.1372.1, Operations, Administration and Maintenance
      > mechanism for MPLS-TP in Packet Transport Network (PTN)
      > Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/ >
      > From: ITU-T SG 15 =A0(Greg Jones <greg.jones@itu.int>)
      > To: The IESG (chair@ietf.org) > Cc:
      > yoichi.maeda@ttc.or.jp,<= a href=3D"mailto:steve.trowbridge@alcatel-lucent.com">steve.trowbridge@alca= tel-lucent.com,ies
      > g@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com
      > Reponse Contact:
      > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int
      > Technical Contact: malcolm= .betts@zte.com.cn
      > Purpose: For information
      >
      > Body: The December meeting of ITU-T Study Group 15 considered
      > the approval of Recommendation ITU-T G.8113.1/Y.1372.1,
      > Operations, Administration and Maintenance mechanism for
      > MPLS-TP in Packet Transport Network (PTN). =A0Unfortunately the
      > Study Group could not approve this Recommendation so it was
      > forwarded to the WTSA (20-29 November 2012) for approval.
      > One of the issues that prevented the approval in SG 15 was
      > the lack of an ACh code point to support this Recommendation.
      > =A0To resolve this issue SG 15 therefore requests the IETF to
      > assign an ACh code point. =A0An IETF draft
      > draft-betts-itu-oam-ach-code-point has been submitted to
      > request this code point.
      > We have attached the text of the current draft of
      > Recommendation ITU-T G.8113.1/Y.1372.1 that has been
      > forwarded to the WTSA for approval.
      > Attach: COM15R-22.
      >
      > Attachment(s):
      >
      > =A0 =A0 LS370 - pdf body
      > https://datatracker.ietf.org/documents/LIAISON/file1306= .pdf
      >
      > =A0 =A0 LS370 - pdf attachment
      > https://datatracker.ietf.org/documents/LIAISON/file1307= .pdf
      >
      >
      >
      _______________________________________________
      Ietf mailing list
      Ietf@ietf.org
      ht= tps://www.ietf.org/mailman/listinfo/ietf
      _______________________________________________
      CCAMP mailing list
      CCAMP@ietf.org
      h= ttps://www.ietf.org/mailman/listinfo/ccamp


      ------------------------------

      _______________________________________________
      Ietf mailing list
      Ietf@ietf.org
      ht= tps://www.ietf.org/mailman/listinfo/ietf


      End of Ietf Digest, Vol 44, Issue 17
      ************************************

      --f46d0434bf56a176a704b62c5d8f-- From yaakov_s@rad.com Tue Jan 10 06:54:01 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C09421F860E for ; Tue, 10 Jan 2012 06:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.731 X-Spam-Level: X-Spam-Status: No, score=-101.731 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 4N4RBQLsnzHJ for ; Tue, 10 Jan 2012 06:54:00 -0800 (PST) Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id 3674921F854A for ; Tue, 10 Jan 2012 06:53:57 -0800 (PST) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 10 Jan 2012 16:49:23 +0200 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.01.0323.003; Tue, 10 Jan 2012 16:53:51 +0200 From: Yaakov Stein To: John Day , t.petch , "dcrocker@bbiw.net" Subject: RE: Protocol Definition Thread-Topic: Protocol Definition Thread-Index: AQHMzdv4uTrSvisg80qAwUBf6ZqN4pYCPRcAgAN1cyA= Date: Tue, 10 Jan 2012 14:53:50 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9042C9474@EXRAD5.ad.rad.co.il> References: <07F7D 7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il><4F05B856.9050205@ dcrocker.net> <3013.1325775717.451646@puncture><4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org><3013.1325799709.099423@puncture> <4F06647E.2010905@dcrocker.net><4F06662A.6070504@joelhalpern.com> <4F0667B9.30604@dcrocker.net> <000b01cccddb$fd4214c0$4001a8c0@gateway.2wire.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF-Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 14:54:01 -0000 X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E609E21F8606 for ; Tue, 10 Jan 2012 07:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.641 X-Spam-Level: X-Spam-Status: No, score=-102.641 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 n4vKh22k+Rkb for ; Tue, 10 Jan 2012 07:15:23 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 4574021F8569 for ; Tue, 10 Jan 2012 07:15:23 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta09.westchester.pa.mail.comcast.net with comcast id KpWy1i0021uE5Es59rFP8D; Tue, 10 Jan 2012 15:15:23 +0000 Received: from [10.0.1.26] ([24.218.154.214]) by omta16.westchester.pa.mail.comcast.net with comcast id KrFN1i01J4dorGg3crFNab; Tue, 10 Jan 2012 15:15:23 +0000 Mime-Version: 1.0 Message-Id: In-Reply-To: <07F7D7DED63154409F13298786A2ADC9042C9474@EXRAD5.ad.rad.co.il> References: <07F7D 7DED63154409F13298786A2ADC9042C5169@EXRAD5.ad.rad.co.il><4F05B856.9050205@ dcrocker.net> <3013.1325775717.451646@puncture><4F05DA49.8050802@dcrocker.net> <4F05E3B8.5030305@mail-abuse.org><3013.1325799709.099423@puncture> <4F06647E.2010905@dcrocker.net><4F06662A.6070504@joelhalpern.com> <4F0667B9.30604@dcrocker.net> <000b01cccddb$fd4214c0$4001a8c0@gateway.2wire.net> <07F7D7DED63154409F13298786A2ADC9042C9474@EXRAD5.ad.rad.co.il> Date: Tue, 10 Jan 2012 10:07:25 -0500 To: Yaakov Stein , John Day , t.petch , "dcrocker@bbiw.net" From: John Day Subject: RE: Protocol Definition Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: IETF-Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 15:15:24 -0000 What you say is true of "communication or network protocols." The statement below was written in the context of the wider use of the word protocol (and what you would probably find in the dictionary) in the fields of biology, chemistry, and diplomacy. In this case, one could view our use of the term as a specialization of the general use. After all, a network protocol is a distributed algorithm. The communicating peers only make sense together. At 14:53 +0000 2012/01/10, Yaakov Stein wrote: >< "algorithm" are probably the same. > >No, they aren't. > >In protocols it is essential that there are at least 2 communicating >entities running the same protocol (or at least compatible >protocols). >Each side may be running algorithm(s), but the protocol states what >I have to do when >the other side sends (or doesn't send) me a message of a certain type. > >Algorithms frequently have inputs, but these need not come from >other algorithms, >and are treated accordingly. > >Y(J)S From bernard_aboba@hotmail.com Tue Jan 10 10:37:40 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA5921F8550; Tue, 10 Jan 2012 10:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.391 X-Spam-Level: X-Spam-Status: No, score=-101.391 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=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 2oVpXZTZBJwK; Tue, 10 Jan 2012 10:37:40 -0800 (PST) Received: from blu0-omc2-s32.blu0.hotmail.com (blu0-omc2-s32.blu0.hotmail.com [65.55.111.107]) by ietfa.amsl.com (Postfix) with ESMTP id F241821F858B; Tue, 10 Jan 2012 10:37:39 -0800 (PST) Received: from BLU152-W23 ([65.55.111.71]) by blu0-omc2-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 10:37:38 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_7fc7e043-8ee9-4b86-8d7e-b13da2848036_" X-Originating-IP: [131.107.0.94] From: Bernard Aboba To: , , "radiusext@ops.ietf.org" , "iesg@ietf.org" Subject: Review of draft-ietf-nextext-radius-pmip6 Date: Tue, 10 Jan 2012 10:37:37 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 10 Jan 2012 18:37:38.0414 (UTC) FILETIME=[EDA130E0:01CCCFC6] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 18:37:40 -0000 --_7fc7e043-8ee9-4b86-8d7e-b13da2848036_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The document appears to contain typos in sections 4.16 and 4.17. =20 In section 4.16=2C it appears that "Home LMA IPv6 address" should be replac= ed by "Home DHCPv6 server address": 4.16. PMIP6-Home-DHCP6-Server-Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home LMA IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In Section 4.17=2C it appears that "Visited LMA IPv6 address" should be rep= laced by "Visited DHCPv6 server address": 4.17. PMIP6-Visited-DHCP6-Server-Address 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited DHCPv6 server address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Visited LMA IPv6 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2. Table of Attributes The following table provides a guide to attributes that may be found in authentication and authorization RADIUS messages between MAG and the AAA Server. Request Accept Reject Challenge # Attribute 0-1 0-1 0-1 0-1 80 Message-Authenticator [BA] The Message-Authenticator attribute is mandatory-to-implement in a num= ber of=20 RADIUS usages=2C including EAP (RFC 3579). Leaving out Message-Authenticat= or could=20 result in Access-Requests lacking authentication and integrity protection. RFC 6158 Section 3.1 states: While [RFC2865] did not require authentication and integrity protection of RADIUS Access-Request packets=2C subsequent authentication mechanism specifications=2C such as RADIUS/EAP [RFC3579] and Digest Authentication [RFC5090]=2C have mandated authentication and integrity protection for certain RADIUS packets. [RFC5080]=2C Section 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets=2C including Access-Request packets performing authorization checks. It is expected that specifications for new RADIUS authentication mechanisms will continue this practice. =20 = --_7fc7e043-8ee9-4b86-8d7e-b13da2848036_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
      The document appears to contain typos in sections 4.16 and 4.17. =3B&nb= sp=3B

      In section 4.16=2C it appears that "Home LMA IPv6 address" sh= ould be replaced by "Home DHCPv6 server address":

      4.16.  PMIP6-Home-DHCP6-Server-Address


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |   Length      |  Home DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Home DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Home DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     Home DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Home LMA IPv6 address      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In Section 4.17=2C it appears that "Visited LMA IPv6 address" should be rep=
laced by "Visited DHCPv6 server address":

4.17.  PMIP6-Visited-DHCP6-Server-Address

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |   Length      | Visited DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Visited DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Visited DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    Visited DHCPv6 server address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Visited LMA IPv6 address     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      5.2.  Table=
 of Attributes

   The following table provides a guide to attributes that may be found
   in authentication and authorization RADIUS messages between MAG and
   the AAA Server.

      Request Accept Reject Challenge #  Attribute

   0-1     0-1    0-1    0-1      80  Message-Authenticator


      [BA]=
 The Message-Authenticator attribute is mandatory-to-implement in a number =
of 
      RADIUS usages=2C including EAP (RFC 3579).  Leaving out Message-Auth=
enticator could 
      result in Access-Requests lacking authentication andintegrity protection.  RFC 6158 Section 3.1 states:

         While [RFC28=
65] did not require authentication and integrity
   protection of RADIUS Access-Request packets=2C subsequent
   authentication mechanism specifications=2C such as RADIUS/EAP [RFC3579]
   and Digest Authentication [RFC5090]=2C have mandated authentication and
   integrity protection for certain RADIUS packets.  [RFC5080]=2C Section
   2.1.1 makes this behavior RECOMMENDED for all Access-Request packets=2C
   including Access-Request packets performing authorization checks.  It
   is expected that specifications for new RADIUS authentication
   mechanisms will continue this practice.


      =
      = --_7fc7e043-8ee9-4b86-8d7e-b13da2848036_-- From wesley.george@twcable.com Tue Jan 10 11:51:37 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFCF21F868A for ; Tue, 10 Jan 2012 11:51:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 75DMzAhdiktn for ; Tue, 10 Jan 2012 11:51:37 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id A489C21F86A5 for ; Tue, 10 Jan 2012 11:51:35 -0800 (PST) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.71,488,1320642000"; d="scan'208";a="322260924" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 10 Jan 2012 14:45:15 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Tue, 10 Jan 2012 14:51:31 -0500 From: "George, Wes" To: "ietf@ietf.org" Date: Tue, 10 Jan 2012 14:51:30 -0500 Subject: draft-george-travel-faq-02 Thread-Topic: draft-george-travel-faq-02 Thread-Index: AczPzY0wywVJRbniTWWUidz8aAez7wAAVlmA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:51:37 -0000 SSd2ZSBtYWRlIHVwZGF0ZXMgdG8gdGhpcyBkb2N1bWVudCB0byBpbXByb3ZlIHRoZSBzdHJ1Y3R1 cmUgKG1vcmUgc3Vic2VjdGlvbnMgaW5zdGVhZCBvZiBtdWx0aXBsZSBsZXZlbHMgb2YgYnVsbGV0 cykgYXMgd2VsbCBhcyB0byBpbmNvcnBvcmF0ZSB0aGUgZ3JlYXQgZmVlZGJhY2sgb24gY29udGVu dCB0aGF0IEkndmUgcmVjZWl2ZWQgZnJvbSBsb3RzIG9mIGZvbGtzLiBJJ20gc2VuZGluZyBpdCBm b3Igb25lIG1vcmUgcm91bmQgb2YgcmV2aWV3IGFuZCBmZWVkYmFjayBiZWZvcmUgSSBtb3ZlIHRv d2FyZHMgcHVibGlzaGluZy4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWdlb3Jn ZS10cmF2ZWwtZmFxDQoNClVubGVzcyBJIHJlY2VpdmUgZmVlZGJhY2sgdG8gdGhlIGNvbnRyYXJ5 LCBJJ2xsIGJlIHB1cnN1aW5nIHRoaXMgYXMgYW4gSW5kZXBlbmRlbnQgU3VibWlzc2lvbi4NCg0K VGhhbmtzDQpXZXMgR2VvcmdlDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Z10NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTAsIDIwMTIgMjoyNSBQTQ0KVG86IEdlb3JnZSwg V2VzDQpDYzogR2VvcmdlLCBXZXMNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtZ2VvcmdlLXRyYXZlbC1mYXEtMDIudHh0DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1nZW9yZ2UtdHJhdmVsLWZhcS0wMi50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBXZXNsZXkgR2VvcmdlIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9y eS4NCg0KRmlsZW5hbWU6ICAgICAgICBkcmFmdC1nZW9yZ2UtdHJhdmVsLWZhcQ0KUmV2aXNpb246 ICAgICAgICAwMg0KVGl0bGU6ICAgICAgICAgICBJRVRGIG1lZXRpbmcgYXR0ZW5kZWVzJiMzOTsg RnJlcXVlbnRseSBBc2tlZCAodHJhdmVsKSBRdWVzdGlvbnMNCkNyZWF0aW9uIGRhdGU6ICAgMjAx Mi0wMS0xMA0KV0cgSUQ6ICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBv ZiBwYWdlczogMTENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGF0dGVtcHRzIHRvIHBy b3ZpZGUgYSBsaXN0IG9mIHRoZSBjb21tb24gRnJlcXVlbnRseQ0KICAgQXNrZWQgUXVlc3Rpb25z IChGQVFzKSB0aGF0IElFVEYgbWVldGluZyBhdHRlbmRlZXMgb2Z0ZW4gYXNrDQogICByZWdhcmRp bmcgdHJhdmVsIGxvZ2lzdGljcyBhbmQgbG9jYWwgaW5mb3JtYXRpb24uICBJdCBpcyBpbnRlbmRl ZCB0bw0KICAgYXNzaXN0IHRob3NlIHdobyBhcmUgd2lsbGluZyB0byBwcm92aWRlIGxvY2FsIGlu Zm9ybWF0aW9uLCBzbyB0aGF0IGlmDQogICB0aGV5IHdpc2ggdG8gcHJlLXBvcHVsYXRlIGFuc3dl cnMgdG8gc29tZSBvciBhbGwgb2YgdGhlc2UgcXVlc3Rpb25zDQogICBlaXRoZXIgaW4gdGhlIElF VEYgV2lraSBvciBhIG1lZXRpbmctc3BlY2lmaWMgc2l0ZSwgdGhleSBoYXZlIGENCiAgIHJlYXNv bmFibHkgY29tcGxldGUgbGlzdCBvZiBpZGVhcyB0byBkcmF3IGZyb20uICBJdCBpcyBub3QgbWVh bnQgYXMgYQ0KICAgbGlzdCBvZiByZXF1aXJlZCBpbmZvcm1hdGlvbiB0aGF0IHRoZSBob3N0IG9y IHNlY3JldGFyaWF0IG5lZWRzIHRvDQogICBwcm92aWRlLCBtZXJlbHkgYXMgYSBndWlkZWxpbmUu DQoNCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2Yg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5 IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1Ympl Y3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1h aWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2Vu IGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBF LW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBh bnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From msk@cloudmark.com Tue Jan 10 20:40:45 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D2F11E808A; Tue, 10 Jan 2012 20:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 R2PyupSmiN2N; Tue, 10 Jan 2012 20:40:44 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBA311E8080; Tue, 10 Jan 2012 20:40:44 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Jan 2012 20:40:37 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Jan 2012 20:40:43 -0800 From: "Murray S. Kucherawy" To: "david.black@emc.com" , "ietf@cybernothing.org" , "gen-art@ietf.org" , "ietf@ietf.org" Date: Tue, 10 Jan 2012 20:40:42 -0800 Subject: RE: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Index: AczQCujbMXhqirD5Sk6EB1sS2KVtOQACZtUQ Message-ID: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "presnick@qualcomm.com" , "marf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 04:40:45 -0000 > -----Original Message----- > From: david.black@emc.com [mailto:david.black@emc.com] > Sent: Tuesday, January 10, 2012 6:44 PM > To: ietf@cybernothing.org; Murray S. Kucherawy; gen-art@ietf.org; ietf@ie= tf.org > Cc: david.black@emc.com; marf@ietf.org; presnick@qualcomm.com > Subject: Gen-ART review of draft-ietf-marf-redaction-04 Hi David, thanks for the review. > [1] The first open issue is the absence of security guidance to ensure th= at this > redaction technique effectively hides the redacted information. The reda= ction > technique is to concatenate a secret string (called the "redaction key") = to the > information to be redacted, apply "any hashing/digest algorithm", convert= the output > to base64 and use that base64 string to replace the redacted information. > [...] >=20 > I suggest a couple of changes: > 1) Change "any hashing/digest algorithm" to require use of a secure hash,= and > explain what is meant by "secure hash" in the security considerations se= ction. > 2) Require a minimum length of the "redaction key" string, and strongly s= uggest > (SHOULD) that it be randomly generated (e.g., by running sufficient outp= ut > of an entropy-rich random number generator through a base64 converter). >=20 > For the latter change, figure out the amount of entropy that should be us= ed > for redaction - the recommended string length will be larger because prin= table > ASCII is not entropy-dense (at best it's good for 6 bits of entropy in ea= ch > 8-bit character, and human-written text such as this message has signific= antly > less). >=20 > From a pure security perspective, use of HMAC with specified secure hashe= s > (SHA2-family) and an approach of hashing the "redaction key" down to a bi= nary > key for HMAC would be a stronger approach. I suggest that authors conside= r > approach, but there may be practical usage concerns that suggest not > adopting it. These are all good points. My gut reaction is to say that this is all good= advice and entirely correct but probably goes a little far for the problem= space we're trying to address. Thus, my inclination is to make the follow= ing changes (subject to WG consensus): - add all of this advice to Security Considerations, with forward reference= s to it elsewhere in the document - make a SHOULD suggestion as to the minimum redaction key length (instead = of a requirement) - make a SHOULD suggestion as to the type of hash to be used (instead of a = requirement) Would those be sufficient? > [2] The second open issue is absence of security considerations for the r= edaction > key. The security considerations section needs to caution that the redac= tion key > is a secret key that must be managed and protected as a secret key. > Disclosure of a redaction key removes the redaction from all reports that= used > that key. As part of this, guidance should be provided on when and how to= change > the redaction key in order to limit the effects of loss of secrecy for a = single > redaction key. Also a good point. I don't think this is the right place to introduce advi= ce about key rotation and the like as those are well-discussed concepts, so= instead Security Considerations can simply make reference to such material= elsewhere. I'll go find some. I know there's stuff like that in RFC6376 = (DKIM) but I'm sure there are better ones. > Editorial Nit: I believe that "anonymization" is a better description of = what > this draft is doing (as opposed to "redaction"), particularly as the resu= lt is > intended to be correlatable via string match across reports from the > same source. Fair enough. We can add a sentence to that effect in the Introduction. To the MARF working group: Please let me know if the above suggestions suff= ice (reply only to the marf list, please). I will summarize and have a new= version ready to publish when LC closes, and make sure David sees it aroun= d the same time. -MSK From jouni.nospam@gmail.com Tue Jan 10 22:30:53 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F062721F8615; Tue, 10 Jan 2012 22:30:52 -0800 (PST) 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 BOBDs1+uEmON; Tue, 10 Jan 2012 22:30:52 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB48721F8607; Tue, 10 Jan 2012 22:30:51 -0800 (PST) Received: by eaad11 with SMTP id d11so39449eaa.31 for ; Tue, 10 Jan 2012 22:30:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=QyMttemzBFsfngCjXRw8yRhkOr3VeMWE6ZDus5OHwTc=; b=pWuv8W01LsVxScXi4EqSLPgPp5y1EEWiMmCO3EW5sRgzp5Ecwe3h4JvMCaiCSgGG7v gOSGPHM4pxHAiwu7MRV6XFc6gSnHsej/ACDGsqiHs6ZSseZkK+sDxPu9Xt7q2VocCGhr MuHnzOMqbAHKd3yRCykv/8BlrpCT8OVcWzhCU= Received: by 10.213.36.11 with SMTP id r11mr1203047ebd.69.1326263449243; Tue, 10 Jan 2012 22:30:49 -0800 (PST) Received: from gprs-prointernet-ff4f6a00-100.dhcp.inet.fi (gprs-prointernet-ff4f6a00-100.dhcp.inet.fi. [93.106.79.100]) by mx.google.com with ESMTPS id a60sm1853215eeb.4.2012.01.10.22.30.42 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jan 2012 22:30:47 -0800 (PST) Subject: Re: Review of draft-ietf-nextext-radius-pmip6 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Wed, 11 Jan 2012 08:30:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5D26445C-2511-41C9-BFC7-E8881DF0BA96@gmail.com> References: To: Bernard Aboba X-Mailer: Apple Mail (2.1084) Cc: "iesg@ietf.org" , ietf@ietf.org, xiayangsong@huawei.com, "radiusext@ops.ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 06:30:53 -0000 Bernard, Thank you for your review. See my comments inline. On Jan 10, 2012, at 8:37 PM, Bernard Aboba wrote: > The document appears to contain typos in sections 4.16 and 4.17. =20 >=20 > In section 4.16, it appears that "Home LMA IPv6 address" should be = replaced by "Home DHCPv6 server address": Blimey.. we'll fix this. > 4.16. PMIP6-Home-DHCP6-Server-Address >=20 >=20 >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Home DHCPv6 server address > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Home DHCPv6 server address > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Home DHCPv6 server address > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Home DHCPv6 server address > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Home LMA IPv6 address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > In Section 4.17, it appears that "Visited LMA IPv6 address" should be = replaced by "Visited DHCPv6 server address": And the same here.. >=20 > 4.17. PMIP6-Visited-DHCP6-Server-Address >=20 >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Visited DHCPv6 server address > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Visited DHCPv6 server address > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Visited DHCPv6 server address > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Visited DHCPv6 server address > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Visited LMA IPv6 address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 >=20 > 5.2. Table of Attributes >=20 >=20 > The following table provides a guide to attributes that may be = found > in authentication and authorization RADIUS messages between MAG and > the AAA Server. >=20 >=20 > Request Accept Reject Challenge # Attribute >=20 > 0-1 0-1 0-1 0-1 80 Message-Authenticator >=20 >=20 >=20 > [BA] The Message-Authenticator attribute is mandatory-to-implement in = a number of=20 > RADIUS usages, including EAP (RFC 3579). Leaving out = Message-Authenticator could=20 > result in Access-Requests lacking authentication and > integrity protection. RFC 6158 Section 3.1 states: Good point. So, you are saying that we should have: 1 0-1 0-1 0-1 80 Message-Authenticator or would=20 1 1 1 1 80 Message-Authenticator be even better as RFC3759 & 5090 do? - Jouni >=20 > While [RFC2865] did not require authentication and integrity > protection of RADIUS Access-Request packets, subsequent > authentication mechanism specifications, such as RADIUS/EAP = [RFC3579] > and Digest Authentication [RFC5090], have mandated authentication = and > integrity protection for certain RADIUS packets. [RFC5080], = Section > 2.1.1 makes this behavior RECOMMENDED for all Access-Request = packets, > including Access-Request packets performing authorization checks. = It > is expected that specifications for new RADIUS authentication > mechanisms will continue this practice. >=20 >=20 > =20 >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From bernard_aboba@hotmail.com Tue Jan 10 23:03:14 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C0021F882C; Tue, 10 Jan 2012 23:03:14 -0800 (PST) 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.390, 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 WtXl0qNJ9oDI; Tue, 10 Jan 2012 23:03:14 -0800 (PST) Received: from blu0-omc2-s36.blu0.hotmail.com (blu0-omc2-s36.blu0.hotmail.com [65.55.111.111]) by ietfa.amsl.com (Postfix) with ESMTP id CED6821F8823; Tue, 10 Jan 2012 23:03:09 -0800 (PST) Received: from BLU0-P3-EAS22 ([65.55.111.73]) by blu0-omc2-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 23:03:09 -0800 X-Originating-IP: [24.17.217.162] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Subject: Re: Review of draft-ietf-nextext-radius-pmip6 References: <5D26445C-2511-41C9-BFC7-E8881DF0BA96@gmail.com> Content-Transfer-Encoding: quoted-printable From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" In-Reply-To: <5D26445C-2511-41C9-BFC7-E8881DF0BA96@gmail.com> Date: Tue, 10 Jan 2012 23:04:18 -0800 To: jouni korhonen MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 11 Jan 2012 07:03:09.0382 (UTC) FILETIME=[135D3E60:01CCD02F] Cc: "iesg@ietf.org" , "ietf@ietf.org" , "xiayangsong@huawei.com" , "radiusext@ops.ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 07:03:14 -0000 Message-Authenticator should be mandatory (1 1 1 1). On Jan 10, 2012, at 22:30, "jouni korhonen" wrote: > Bernard, >=20 > Thank you for your review. See my comments inline. >=20 >=20 > On Jan 10, 2012, at 8:37 PM, Bernard Aboba wrote: >=20 >> The document appears to contain typos in sections 4.16 and 4.17. =20 >>=20 >> In section 4.16, it appears that "Home LMA IPv6 address" should be replac= ed by "Home DHCPv6 server address": >=20 > Blimey.. we'll fix this. >=20 >> 4.16. PMIP6-Home-DHCP6-Server-Address >>=20 >>=20 >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Length | Home DHCPv6 server address >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Home DHCPv6 server address >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Home DHCPv6 server address >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Home DHCPv6 server address >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Home LMA IPv6 address | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >> In Section 4.17, it appears that "Visited LMA IPv6 address" should be rep= laced by "Visited DHCPv6 server address": >=20 > And the same here.. >=20 >=20 >>=20 >> 4.17. PMIP6-Visited-DHCP6-Server-Address >>=20 >>=20 >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Length | Visited DHCPv6 server address >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Visited DHCPv6 server address >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Visited DHCPv6 server address >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Visited DHCPv6 server address >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Visited LMA IPv6 address | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>=20 >>=20 >> 5.2. Table of Attributes >>=20 >>=20 >> The following table provides a guide to attributes that may be found >> in authentication and authorization RADIUS messages between MAG and >> the AAA Server. >>=20 >>=20 >> Request Accept Reject Challenge # Attribute >>=20 >> 0-1 0-1 0-1 0-1 80 Message-Authenticator >>=20 >>=20 >>=20 >> [BA] The Message-Authenticator attribute is mandatory-to-implement in a n= umber of=20 >> RADIUS usages, including EAP (RFC 3579). Leaving out Message-Authenticat= or could=20 >> result in Access-Requests lacking authentication and >> integrity protection. RFC 6158 Section 3.1 states: >=20 > Good point. So, you are saying that we should have: >=20 > 1 0-1 0-1 0-1 80 Message-Authenticator >=20 > or would=20 >=20 > 1 1 1 1 80 Message-Authenticator >=20 > be even better as RFC3759 & 5090 do? >=20 >=20 > - Jouni >=20 >=20 >=20 >>=20 >> While [RFC2865] did not require authentication and integrity >> protection of RADIUS Access-Request packets, subsequent >> authentication mechanism specifications, such as RADIUS/EAP [RFC3579] >> and Digest Authentication [RFC5090], have mandated authentication and >> integrity protection for certain RADIUS packets. [RFC5080], Section >> 2.1.1 makes this behavior RECOMMENDED for all Access-Request packets, >> including Access-Request packets performing authorization checks. It >> is expected that specifications for new RADIUS authentication >> mechanisms will continue this practice. >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >=20 From jouni.nospam@gmail.com Tue Jan 10 23:16:54 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F189E21F883D; Tue, 10 Jan 2012 23:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 TZcZ0VDBefIP; Tue, 10 Jan 2012 23:16:54 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B249821F883A; Tue, 10 Jan 2012 23:16:53 -0800 (PST) Received: by werb14 with SMTP id b14so351819wer.31 for ; Tue, 10 Jan 2012 23:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wKaB5gqDQcDzbdGm9sz0VfjDQ666OzEOu61LNIJgH+o=; b=mDymZR6Zvq88cs+N1ngDpuR2aPGlgue6UiAjTDnk09YQoXSrHuJxh55vR8i7mI4ky3 /vnVwlcgUxD19cUBxG7cxtosxQR3K2taZnbtBA3yKWXJ6bsOFKG1wqSuq403nO37dLsm HNGqKUadnSVfNWmxhvfAD9YRfWfGRrgKn2hp8= Received: by 10.180.80.162 with SMTP id s2mr8676723wix.10.1326266212856; Tue, 10 Jan 2012 23:16:52 -0800 (PST) Received: from [10.255.132.235] ([192.100.123.77]) by mx.google.com with ESMTPS id di5sm928888wib.3.2012.01.10.23.16.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Jan 2012 23:16:51 -0800 (PST) Subject: Re: Review of draft-ietf-nextext-radius-pmip6 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Wed, 11 Jan 2012 09:11:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D26445C-2511-41C9-BFC7-E8881DF0BA96@gmail.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1084) Cc: radext@ietf.org, ietf@ietf.org, Frank Xia , "iesg@ietf.org IESG" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 07:16:55 -0000 On Jan 11, 2012, at 9:04 AM, Bernard Aboba wrote: > Message-Authenticator should be mandatory (1 1 1 1). Ack. Thanks Bernard. - Jouni >=20 >=20 > On Jan 10, 2012, at 22:30, "jouni korhonen" = wrote: >=20 >> Bernard, >>=20 >> Thank you for your review. See my comments inline. >>=20 >>=20 >> On Jan 10, 2012, at 8:37 PM, Bernard Aboba wrote: >>=20 >>> The document appears to contain typos in sections 4.16 and 4.17. =20= >>>=20 >>> In section 4.16, it appears that "Home LMA IPv6 address" should be = replaced by "Home DHCPv6 server address": >>=20 >> Blimey.. we'll fix this. >>=20 >>> 4.16. PMIP6-Home-DHCP6-Server-Address >>>=20 >>>=20 >>>=20 >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type | Length | Home DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Home DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Home DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Home DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Home LMA IPv6 address | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>> In Section 4.17, it appears that "Visited LMA IPv6 address" should = be replaced by "Visited DHCPv6 server address": >>=20 >> And the same here.. >>=20 >>=20 >>>=20 >>> 4.17. PMIP6-Visited-DHCP6-Server-Address >>>=20 >>>=20 >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type | Length | Visited DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Visited DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Visited DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Visited DHCPv6 server address >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> Visited LMA IPv6 address | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>>=20 >>> 5.2. Table of Attributes >>>=20 >>>=20 >>> The following table provides a guide to attributes that may be = found >>> in authentication and authorization RADIUS messages between MAG and >>> the AAA Server. >>>=20 >>>=20 >>> Request Accept Reject Challenge # Attribute >>>=20 >>> 0-1 0-1 0-1 0-1 80 Message-Authenticator >>>=20 >>>=20 >>>=20 >>> [BA] The Message-Authenticator attribute is mandatory-to-implement = in a number of=20 >>> RADIUS usages, including EAP (RFC 3579). Leaving out = Message-Authenticator could=20 >>> result in Access-Requests lacking authentication and >>> integrity protection. RFC 6158 Section 3.1 states: >>=20 >> Good point. So, you are saying that we should have: >>=20 >> 1 0-1 0-1 0-1 80 Message-Authenticator >>=20 >> or would=20 >>=20 >> 1 1 1 1 80 Message-Authenticator >>=20 >> be even better as RFC3759 & 5090 do? >>=20 >>=20 >> - Jouni >>=20 >>=20 >>=20 >>>=20 >>> While [RFC2865] did not require authentication and integrity >>> protection of RADIUS Access-Request packets, subsequent >>> authentication mechanism specifications, such as RADIUS/EAP = [RFC3579] >>> and Digest Authentication [RFC5090], have mandated authentication = and >>> integrity protection for certain RADIUS packets. [RFC5080], = Section >>> 2.1.1 makes this behavior RECOMMENDED for all Access-Request = packets, >>> including Access-Request packets performing authorization checks. = It >>> is expected that specifications for new RADIUS authentication >>> mechanisms will continue this practice. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Ietf mailing list >>> Ietf@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf >>=20 From housley@vigilsec.com Wed Jan 11 05:36:46 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A62921F87D8; Wed, 11 Jan 2012 05:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.077, 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 TBWRYVRpOQzq; Wed, 11 Jan 2012 05:36:45 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 81EE821F87B9; Wed, 11 Jan 2012 05:36:45 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 18C389A4782; Wed, 11 Jan 2012 08:36:55 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 9CY859hR99lI; Wed, 11 Jan 2012 08:36:39 -0500 (EST) Received: from [192.168.43.193] (unknown [198.232.60.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id B894B9A4737; Wed, 11 Jan 2012 08:36:53 -0500 (EST) Subject: Re: An Antitrust Policy for the IETF Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <20120110205143.6FDCF21F86F9@ietfa.amsl.com> Date: Wed, 11 Jan 2012 08:36:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120110205143.6FDCF21F86F9@ietfa.amsl.com> To: IETF , IESG X-Mailer: Apple Mail (2.1084) Cc: antitrust-policy@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 13:36:46 -0000 Based on the length of this thread, it is clear to me that more = discussion is needed, but I do not think that the IETF mail list is the = place to have it. So, the antitrust-policy mail list has been set up to = continue the discussion. It is clear to me that many people are questioning what would go in such = a policy. I have been working on a strawman. It is short, but it = answers the question about what topics would be covered. I will post = that strawman to the antitrust-policy mail list for discussion from two = perspectives. First, does the IETF want to adopt an antitrust policy. = Second, the strawman will provide the basis for a conversation on the = content of such a policy if the consensus is that the IETF wants to = adopt one. I'll wait a few days so that people have time to join the = antitrust-policy mail list before the discussion begins. Russ On Jan 10, 2012, at 3:51 PM, IETF Secretariat wrote: > A new IETF non-working group email list has been created. >=20 > List address: antitrust-policy@ietf.org > Archive: http://www.ietf.org/mail-archive/web/antitrust-policy/ > To subscribe: https://www.ietf.org/mailman/listinfo/antitrust-policy >=20 > Purpose: Discuss the need for an antitrust or competition policy for = the IETF. If the consensus is to create one, then the content of that = policy will be discussed as well. From malcolm.betts@zte.com.cn Wed Jan 11 07:39:02 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE4421F874C; Wed, 11 Jan 2012 07:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 DjEYlKjH+YNq; Wed, 11 Jan 2012 07:39:01 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6753E21F873B; Wed, 11 Jan 2012 07:39:00 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690817668700; Wed, 11 Jan 2012 23:17:04 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 95170.4345976004; Wed, 11 Jan 2012 23:38:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q0BFcfQc018910; Wed, 11 Jan 2012 23:38:41 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <01cf01cccef4$c5e6ef90$51b4ceb0$@olddog.co.uk> References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> <01cf01cccef4$c5e6ef90$51b4ceb0$@olddog.co.uk> To: Subject: RE: Questions about draft-betts-itu-oam-ach-code-point MIME-Version: 1.0 X-KeepSent: 5883B78D:5D3252AF-85257982:00557BCD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Wed, 11 Jan 2012 10:38:38 -0500 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-01-11 23:38:45, Serialize complete at 2012-01-11 23:38:45 Content-Type: multipart/alternative; boundary="=_alternative 0055F1DA85257982_=" X-MAIL: mse02.zte.com.cn q0BFcfQc018910 Cc: mpls@ietf.org, draft-betts-itu-oam-ach-code-point@tools.ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 15:39:03 -0000 This is a multipart message in MIME format. --=_alternative 0055F1DA85257982_= Content-Type: text/plain; charset="US-ASCII" Hi Adrian, I can confirm that the draft is requesting a code point for the version of G.8113.1 that was forwarded to WTSA by SG 15, this is the same as the draft that was determined in February 2011, I am not anticipating any changes prior to the approval decision at WTSA. None of the changes in G.8113.1 that were anticipated in draft-betts-itu-oam-ach-code-point-01 were implemented, I will post a new version draft-betts-itu-oam-ach-code-point to correctly reflect the content and title on G.8113.1 and respond to the other questions later this week. Regards, Malcolm "Adrian Farrel" 09/01/2012 12:33 PM Please respond to To , "'Huub helvoort'" cc , Subject RE: Questions about draft-betts-itu-oam-ach-code-point Hi Huub and Malcolm, I recognise that the intervening month between my original email and this one included an SG15 meeting, Christmas, and New Year, but I had hoped for a response by now so that we could work out what to do with the document. In the meantime, at least my question 4 has progressed. Can you confirm that the version of G.8113.1 for which a code point is requested is that which has been sent to WTSA by SG15 (i.e., that which was determined), and that there are no plans to make any updates or revisions to that document until after it has been approved. Thanks, Adrian > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Adrian > Farrel > Sent: 09 December 2011 10:49 > To: draft-betts-itu-oam-ach-code-point@tools.ietf.org; 'Huub helvoort' > Cc: mpls@ietf.org; ietf@ietf.org > Subject: Questions about draft-betts-itu-oam-ach-code-point > > Hi Malcolm and Huub, > > I have squeezed a little time from the current ITU-T meeting to look at your > draft and write-up. I have also read the email threads on the IETF discussion > list and the MPLS list. Sorry that this has taken me a week to process, but your > publication request came at pretty much the worst possible time for getting me > to do this task. > > I don't like proliferating threads across multiple mailing lists. On the other > hand it is difficult to ensure that all the constituencies are present, so I am > perpetuating the cross-posting. > > My review of the document... > > 1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I think > only one of these is real (the spurious space in a citation). The other nits are > spurious caused by citations wrapping across lines. Could you please keep a note > of the nit so that you can fix it the next time the draft is respun or so it can > be captured in an RFC Editor Note at a later stage (you don't have to post a new > revision to address this now unless you really want to). > > 2. This document requests a code point from a registry that contains code points > that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D > whether it is your intention that your code point would also be applicable in > both cases. What is your intention? Is this "obvious" from G.8113.1 or does it > need to be clarified? > > > My review of the write-up and discussions... > > 3. There seems to be quite a feeling on the mailing lists that this document > should be run through the MPLS working group. The write-up makes a case for > progressing it as AD sponsored. As far as I can see, the main assertions to > answer are as follows. Do you have a view on these points before I make a > decision on what to do? > > a. This is a proposal to use an MPLS code point and so is part of MPLS by > definition. > > b. The type of network being managed by the OAM described in G.8113.1 is an > MPLS network. Therefore, this is clearly relevant to the MPLS working . > > Do you object to this going through the MPLS on principle, or were you just > hoping to save the WG the work? If the latter, and if the WG wants to look at > the draft, the easiest approach seems to be to redirect the work to the working > group. > > 4. G.8113.1 is clearly important to understanding to which the code point is > being put. Thus, an available and stable copy of group. G.8113.1 will be key to > the last call review of you I-D. Can you make a stable copy available (for > example, through liaison)? How does the editing work currently in progress in > the SG15 meeting affect that availability? > > 5. Can you clarify for me why the suggested value has been suggested. This will > help guide IANA who would normally do their allocation in a "tidy" way. > > Looking forward to your reply. > > Thanks, > Adrian --=_alternative 0055F1DA85257982_= Content-Type: text/html; charset="US-ASCII" Hi Adrian,

      I can confirm that the draft is requesting a code point for the version of G.8113.1 that was forwarded to WTSA by SG 15, this is the same as the draft that was determined in February 2011, I am not anticipating any changes prior to the approval decision at WTSA.  None of the changes in G.8113.1 that were anticipated in draft-betts-itu-oam-ach-code-point-01 were implemented,  I will post a new version draft-betts-itu-oam-ach-code-point to correctly reflect the content and title on G.8113.1 and respond to the other questions later this week.

      Regards,

      Malcolm


      "Adrian Farrel" <adrian@olddog.co.uk>

      09/01/2012 12:33 PM
      Please respond to
      <adrian@olddog.co.uk>
      To
      		<draft-betts-itu-oam-ach-code-point@tools.ietf.org>, "'Huub helvoort'" <huub.van.helvoort@huawei.com>
      cc
      		<mpls@ietf.org>, <ietf@ietf.org>
      Subject
      		RE: Questions about draft-betts-itu-oam-ach-code-point





      Hi Huub and Malcolm,

      I recognise that the intervening month between my original email and this one
      included an SG15 meeting, Christmas, and New Year, but I had hoped for a
      response by now so that we could work out what to do with the document.

      In the meantime, at least my question 4 has progressed. Can you confirm that the
      version of G.8113.1 for which a code point is requested is that which has been
      sent to WTSA by SG15 (i.e., that which was determined), and that there are no
      plans to make any updates or revisions to that document until after it has been
      approved.

      Thanks,
      Adrian

      > -----Original Message-----
      > From: ietf-bounces@ietf.org [      mailto:ietf-bounces@ietf.org] On Behalf Of Adrian
      > Farrel
      > Sent: 09 December 2011 10:49
      > To: draft-betts-itu-oam-ach-code-point@tools.ietf.org; 'Huub helvoort'
      > Cc: mpls@ietf.org; ietf@ietf.org
      > Subject: Questions about draft-betts-itu-oam-ach-code-point
      >
      > Hi Malcolm and Huub,
      >
      > I have squeezed a little time from the current ITU-T meeting to look at your
      > draft and write-up. I have also read the email threads on the IETF discussion
      > list and the MPLS list. Sorry that this has taken me a week to process, but
      your
      > publication request came at pretty much the worst possible time for getting me
      > to do this task.
      >
      > I don't like proliferating threads across multiple mailing lists. On the other
      > hand it is difficult to ensure that all the constituencies are present, so I
      am
      > perpetuating the cross-posting.
      >
      > My review of the document...
      >
      > 1. idnits (      http://www.ietf.org/tools/idnits/) shows a couple of nits. I think
      > only one of these is real (the spurious space in a citation). The other nits
      are
      > spurious caused by citations wrapping across lines. Could you please keep a
      note
      > of the nit so that you can fix it the next time the draft is respun or so it
      can
      > be captured in an RFC Editor Note at a later stage (you don't have to post a
      new
      > revision to address this now unless you really want to).
      >
      > 2. This document requests a code point from a registry that contains code
      points
      > that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D
      > whether it is your intention that your code point would also be applicable in
      > both cases. What is your intention? Is this "obvious" from G.8113.1 or does it
      > need to be clarified?
      >
      >
      > My review of the write-up and discussions...
      >
      > 3. There seems to be quite a feeling on the mailing lists that this document
      > should be run through the MPLS working group. The write-up makes a case for
      > progressing it as AD sponsored. As far as I can see, the main assertions to
      > answer are as follows. Do you have a view on these points before I make a
      > decision on what to do?
      >
      > a. This is a proposal to use an MPLS code point and so is part of MPLS by
      > definition.
      >
      > b. The type of network being managed by the OAM described in G.8113.1 is an
      > MPLS network. Therefore, this is clearly relevant to the MPLS working .
      >
      > Do you object to this going through the MPLS on principle, or were you just
      > hoping to save the WG the work? If the latter, and if the WG wants to look at
      > the draft, the easiest approach seems to be to redirect the work to the
      working
      > group.
      >
      > 4. G.8113.1 is clearly important to understanding to which the code point is
      > being put. Thus, an available and stable copy of group. G.8113.1 will be key
      to
      > the last call review of you I-D. Can you make a stable copy available (for
      > example, through liaison)? How does the editing work currently in progress in
      > the SG15 meeting affect that availability?
      >
      > 5. Can you clarify for me why the suggested value has been suggested. This
      will
      > help guide IANA who would normally do their allocation in a "tidy" way.
      >
      > Looking forward to your reply.
      >
      > Thanks,
      > Adrian
      --=_alternative 0055F1DA85257982_=-- From nurit.sprecher@nsn.com Mon Jan 9 09:20:11 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F8911E809B; Mon, 9 Jan 2012 09:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 hLnwcX7-t59J; Mon, 9 Jan 2012 09:20:10 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4B61311E809A; Mon, 9 Jan 2012 09:20:09 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q09HK3XF004485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Jan 2012 18:20:03 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q09HJrxG026756; Mon, 9 Jan 2012 18:20:03 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jan 2012 18:20:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: New Liaison Statement, "LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" Date: Mon, 9 Jan 2012 18:19:57 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A5326405178E68@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Liaison Statement, "LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" Thread-Index: AczN3sDx/mJ/vGigQiGFDbfLLXEytgAKv9cAADpI3OA= References: From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Scott Mansfield" , , , , X-OriginalArrivalTime: 09 Jan 2012 17:20:02.0328 (UTC) FILETIME=[EBF91980:01CCCEF2] X-Mailman-Approved-At: Wed, 11 Jan 2012 07:57:04 -0800 Cc: swallow@cisco.com, adrian@olddog.co.uk, andrew.g.malis@verizon.com, dbrungard@att.com, stbryant@cisco.com X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:20:11 -0000 Support -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of = ext Scott Mansfield Sent: =E0 08 =E9=F0=E5=E0=F8 2012 15:53 To: ietf@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org Cc: swallow@cisco.com; stbryant@cisco.com; adrian@olddog.co.uk; = andrew.g.malis@verizon.com; dbrungard@att.com Subject: FW: New Liaison Statement, "LS370 - Current status = ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration = andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)" This is a liaison from the ITU-T SG15 WP3 providing a copy of the = Determined recommendation G.8113.1 (May 2011). The liaison also = provides a pointer to the internet draft = draft-betts-itu-oam-ach-code-point that requests an ACh code point that = is needed by G.8113.1. This is a liaison that will require a response = and the ITU-T has requested a response no later than 1 August 2012. I = would suggest that we use the liaison response to provide the outcome of = running the IETF process required to assign the requested code point. Regards, -scott. IETF-ITU Liaison Manager for MPLS > -----Original Message----- > From: Liaison Statement Management Tool [mailto:lsmt@ietf.org]=20 > Sent: Sunday, January 08, 2012 3:23 AM > To: chair@ietf.org > Cc: yoichi.maeda@ttc.or.jp;=20 > steve.trowbridge@alcatel-lucent.com; iesg@ietf.org;=20 > lear@cisco.com; Scott Mansfield; malcolm.betts@zte.com.cn;=20 > tsbsg15@itu.int; greg.jones@itu.int; hiroshi.ota@itu.int > Subject: New Liaison Statement, "LS370 - Current status of=20 > Recommendation ITU-T G.8113.1/Y.1372.1, Operations,=20 > Administration and Maintenance mechanism for MPLS-TP in=20 > Packet Transport Network (PTN)" >=20 > Title: LS370 - Current status of Recommendation ITU-T=20 > G.8113.1/Y.1372.1, Operations, Administration and Maintenance=20 > mechanism for MPLS-TP in Packet Transport Network (PTN)=20 > Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/ >=20 > From: ITU-T SG 15 (Greg Jones ) > To: The IESG (chair@ietf.org) > Cc:=20 > yoichi.maeda@ttc.or.jp,steve.trowbridge@alcatel-lucent.com,ies > g@ietf.org,lear@cisco.com,Scott.Mansfield@Ericsson.com > Reponse Contact:=20 > tsbsg15@itu.int,greg.jones@itu.int,hiroshi.ota@itu.int > Technical Contact: malcolm.betts@zte.com.cn > Purpose: For information >=20 > Body: The December meeting of ITU-T Study Group 15 considered=20 > the approval of Recommendation ITU-T G.8113.1/Y.1372.1,=20 > Operations, Administration and Maintenance mechanism for=20 > MPLS-TP in Packet Transport Network (PTN). Unfortunately the=20 > Study Group could not approve this Recommendation so it was=20 > forwarded to the WTSA (20-29 November 2012) for approval. =20 > One of the issues that prevented the approval in SG 15 was=20 > the lack of an ACh code point to support this Recommendation.=20 > To resolve this issue SG 15 therefore requests the IETF to=20 > assign an ACh code point. An IETF draft=20 > draft-betts-itu-oam-ach-code-point has been submitted to=20 > request this code point. > We have attached the text of the current draft of=20 > Recommendation ITU-T G.8113.1/Y.1372.1 that has been=20 > forwarded to the WTSA for approval. > Attach: COM15R-22. >=20 > Attachment(s): >=20 > LS370 - pdf body=20 > https://datatracker.ietf.org/documents/LIAISON/file1306.pdf >=20 > LS370 - pdf attachment=20 > https://datatracker.ietf.org/documents/LIAISON/file1307.pdf >=20 >=20 >=20 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From david.black@emc.com Tue Jan 10 18:44:43 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231A321F847C; Tue, 10 Jan 2012 18:44:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 KfruPwjNhBJW; Tue, 10 Jan 2012 18:44:42 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC3E21F8499; Tue, 10 Jan 2012 18:44:42 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0B2iWxI019520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 21:44:32 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 10 Jan 2012 21:44:19 -0500 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0B2iIN1003220; Tue, 10 Jan 2012 21:44:18 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Tue, 10 Jan 2012 21:44:18 -0500 From: To: , , , Date: Tue, 10 Jan 2012 21:44:16 -0500 Subject: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Index: AczQCujbMXhqirD5Sk6EB1sS2KVtOQ== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Wed, 11 Jan 2012 07:57:05 -0800 Cc: presnick@qualcomm.com, david.black@emc.com, marf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 02:44:43 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at . Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-marf-redaction-04 Reviewer: David L. Black Review Date: January 10, 2012 IETF LC End Date: January 18, 2011 IESG Telechat Date: January 19, 2011 Summary: This draft is on the right track but has open issues, described in= the review. This draft specifies a method for redacting information from email abuse re= ports (e.g., hiding the local part [user] of an email address), while still allow= ing correlation of the redacted information across related abuse reports from t= he same source. The draft is short, clear, and well written. There are two open issues: [1] The first open issue is the absence of security guidance to ensure that= this redaction technique effectively hides the redacted information. The redact= ion technique is to concatenate a secret string (called the "redaction key") to= the information to be redacted, apply "any hashing/digest algorithm", convert t= he output to base64 and use that base64 string to replace the redacted information. There are two important ways in which this technique could fail to effectiv= ely hide the redacted information: - The secret string may inject insufficient entropy. - The hashing/digest algorithm may be weak. To take an extreme example, if the secret string ("redaction key") consists= of a single ASCII character, and a short email local part is being redacted, the= n the output is highly vulnerable to dictionary and brute force attacks because o= nly 6 bits of entropy are added (the result may look secure, but it's not). Beyond th= is extreme example, this is a potentially real concern - e.g., applying the rule of th= umb that ASCII text contains 4-5 bits of entropy per character, the example in Appen= dix A uses a "redaction key" of "potatoes" that injects at most 40 bits of entrop= y - is that sufficient for email redaction purposes? To take a silly example, if a CRC is used as the hash with that sort of sho= rt input, the result is not particularly difficult to invert. I suggest a couple of changes: 1) Change "any hashing/digest algorithm" to require use of a secure hash, a= nd explain what is meant by "secure hash" in the security considerations sect= ion. 2) Require a minimum length of the "redaction key" string, and strongly sug= gest (SHOULD) that it be randomly generated (e.g., by running sufficient output of an entropy-rich random number generator through a base64 converter). For the latter change, figure out the amount of entropy that should be used for redaction - the recommended string length will be larger because printa= ble ASCII is not entropy-dense (at best it's good for 6 bits of entropy in each 8-bit character, and human-written text such as this message has significan= tly less). >From a pure security perspective, use of HMAC with specified secure hashes (SHA2-family) and an approach of hashing the "redaction key" down to a bina= ry key for HMAC would be a stronger approach. I suggest that authors consider approach, but there may be practical usage concerns that suggest not adopt= ing it. [2] The second open issue is absence of security considerations for the red= action key. The security considerations section needs to caution that the redacti= on key is a secret key that must be managed and protected as a secret key. Disclo= sure of a redaction key removes the redaction from all reports that used that ke= y. As part of this, guidance should be provided on when and how to change the redaction key in order to limit the effects of loss of secrecy for a single redaction key. Editorial Nit: I believe that "anonymization" is a better description of wh= at this draft is doing (as opposed to "redaction"), particularly as the result= is intended to be correlatable via string match across reports from the same s= ource. idnits 2.12.13 didn't find any nits. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From david.black@emc.com Tue Jan 10 23:38:58 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A1A21F884A; Tue, 10 Jan 2012 23:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 hVL1roMscuMS; Tue, 10 Jan 2012 23:38:57 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id AA66921F8846; Tue, 10 Jan 2012 23:38:57 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0B7cksC029723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 02:38:47 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 11 Jan 2012 02:38:33 -0500 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0B7cTgd021556; Wed, 11 Jan 2012 02:38:29 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Wed, 11 Jan 2012 02:38:28 -0500 From: To: , , , Date: Wed, 11 Jan 2012 02:38:26 -0500 Subject: RE: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Index: AczQCujbMXhqirD5Sk6EB1sS2KVtOQACZtUQAAZ2BJA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D8B@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Wed, 11 Jan 2012 07:57:06 -0800 Cc: presnick@qualcomm.com, marf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 07:38:58 -0000 Hi Murray, Thanks for the quick response. > These are all good points. My gut reaction is to say that this is all go= od advice and entirely > correct but probably goes a little far for the problem space we're trying= to address. =20 That sounds reasonable to me, and I like John Levine's suggestion to add ma= terial to explain more about the level of security that is appropriate for this problem space= and why. In light of such an explanation, an HMAC-based mechanism could well be overkill. > - make a SHOULD suggestion as to the minimum redaction key length (instea= d of a requirement) > - make a SHOULD suggestion as to the type of hash to be used (instead of = a requirement) I have a hard time believing that the examples used in the review ("a" as t= he redaction key, CRC as the hash) are ever acceptable, and for that reason, I think a c= ouple of MUSTs would be in order to prohibit that sort of nonsense. In particular: - I think there ought to be a MUST minimum length requirement on the redaction key string to prevent really short ones. - I think use of a secure hash ought to be a MUST to prevent use of CRC and other bad ideas. That could be accompanied by additional guidance that may or may not be "SH= OULDs", e.g., suggest a SHA2 hash as a good secure hash, suggest use of a longer string t= han the minimum requirement. > > [2] The second open issue is absence of security considerations for the= redaction > > key. The security considerations section needs to caution that the red= action key > > is a secret key that must be managed and protected as a secret key. > > Disclosure of a redaction key removes the redaction from all reports th= at used > > that key. As part of this, guidance should be provided on when and how = to change > > the redaction key in order to limit the effects of loss of secrecy for = a single > > redaction key. > > Also a good point. I don't think this is the right place to introduce ad= vice about key rotation and > the like as those are well-discussed concepts, so instead Security Consid= erations can simply make > reference to such material elsewhere. I'll go find some. I know there's= stuff like that in RFC6376 > (DKIM) but I'm sure there are better ones. That would be fine - introducing the concept of key rotation as a means to = reduce the impact of key compromise accompanied by a reference to a longer explanation elsewhere see= ms reasonable. Thanks, --David > -----Original Message----- > From: Murray S. Kucherawy [mailto:msk@cloudmark.com] > Sent: Tuesday, January 10, 2012 11:41 PM > To: Black, David; ietf@cybernothing.org; gen-art@ietf.org; ietf@ietf.org > Cc: marf@ietf.org; presnick@qualcomm.com > Subject: RE: Gen-ART review of draft-ietf-marf-redaction-04 >=20 > > -----Original Message----- > > From: david.black@emc.com [mailto:david.black@emc.com] > > Sent: Tuesday, January 10, 2012 6:44 PM > > To: ietf@cybernothing.org; Murray S. Kucherawy; gen-art@ietf.org; ietf@= ietf.org > > Cc: david.black@emc.com; marf@ietf.org; presnick@qualcomm.com > > Subject: Gen-ART review of draft-ietf-marf-redaction-04 >=20 > Hi David, thanks for the review. >=20 > > [1] The first open issue is the absence of security guidance to ensure = that this > > redaction technique effectively hides the redacted information. The re= daction > > technique is to concatenate a secret string (called the "redaction key"= ) to the > > information to be redacted, apply "any hashing/digest algorithm", conve= rt the output > > to base64 and use that base64 string to replace the redacted informatio= n. > > [...] > > > > I suggest a couple of changes: > > 1) Change "any hashing/digest algorithm" to require use of a secure has= h, and > > explain what is meant by "secure hash" in the security considerations = section. > > 2) Require a minimum length of the "redaction key" string, and strongly= suggest > > (SHOULD) that it be randomly generated (e.g., by running sufficient ou= tput > > of an entropy-rich random number generator through a base64 converter)= . > > > > For the latter change, figure out the amount of entropy that should be = used > > for redaction - the recommended string length will be larger because pr= intable > > ASCII is not entropy-dense (at best it's good for 6 bits of entropy in = each > > 8-bit character, and human-written text such as this message has signif= icantly > > less). > > > > From a pure security perspective, use of HMAC with specified secure has= hes > > (SHA2-family) and an approach of hashing the "redaction key" down to a = binary > > key for HMAC would be a stronger approach. I suggest that authors consi= der > > approach, but there may be practical usage concerns that suggest not > > adopting it. >=20 > These are all good points. My gut reaction is to say that this is all go= od advice and entirely > correct but probably goes a little far for the problem space we're trying= to address. Thus, my > inclination is to make the following changes (subject to WG consensus): >=20 > - add all of this advice to Security Considerations, with forward referen= ces to it elsewhere in the > document > - make a SHOULD suggestion as to the minimum redaction key length (instea= d of a requirement) > - make a SHOULD suggestion as to the type of hash to be used (instead of = a requirement) >=20 > Would those be sufficient? >=20 > > [2] The second open issue is absence of security considerations for the= redaction > > key. The security considerations section needs to caution that the red= action key > > is a secret key that must be managed and protected as a secret key. > > Disclosure of a redaction key removes the redaction from all reports th= at used > > that key. As part of this, guidance should be provided on when and how = to change > > the redaction key in order to limit the effects of loss of secrecy for = a single > > redaction key. >=20 > Also a good point. I don't think this is the right place to introduce ad= vice about key rotation and > the like as those are well-discussed concepts, so instead Security Consid= erations can simply make > reference to such material elsewhere. I'll go find some. I know there's= stuff like that in RFC6376 > (DKIM) but I'm sure there are better ones. >=20 > > Editorial Nit: I believe that "anonymization" is a better description o= f what > > this draft is doing (as opposed to "redaction"), particularly as the re= sult is > > intended to be correlatable via string match across reports from the > > same source. >=20 > Fair enough. We can add a sentence to that effect in the Introduction. >=20 > To the MARF working group: Please let me know if the above suggestions su= ffice (reply only to the marf > list, please). I will summarize and have a new version ready to publish = when LC closes, and make sure > David sees it around the same time. >=20 > -MSK From mallman@icir.org Wed Jan 11 05:52:56 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D7F21F86E5; Wed, 11 Jan 2012 05:52:56 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Header field occurs more than once: "Cc" occurs 3 times X-Spam-Flag: NO X-Spam-Score: -106.289 X-Spam-Level: X-Spam-Status: No, score=-106.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 tC6QtZZ+aBk7; Wed, 11 Jan 2012 05:52:55 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id B8D1E21F86E1; Wed, 11 Jan 2012 05:52:55 -0800 (PST) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q0BDqopm018330; Wed, 11 Jan 2012 05:52:51 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 5052515DBEA0; Wed, 11 Jan 2012 08:52:50 -0500 (EST) To: ietf@ietf.org From: Mark Allman Subject: tsv-dir review of draft-ietf-mile-rfc4046-bis-05 Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Born in the USA X-URL-0: http://www.icir.org/mallman-files/Document62102.doc X-URL-1: http://www.icir.org/mallman-files/Document97827.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma37937-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 11 Jan 2012 08:52:50 -0500 Sender: mallman@icir.org Message-Id: <20120111135250.5052515DBEA0@lawyers.icir.org> X-Mailman-Approved-At: Wed, 11 Jan 2012 07:57:06 -0800 Cc: mile@ietf.org, tsv-area@ietf.org, tsv-dir@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 13:52:56 -0000 ----------ma37937-1 Content-Type: text/plain Content-Disposition: inline I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. This draft is basically ready for publication, but has nits that should be fixed before publication. In reading this document I flagged two issues. Neither of them huge, but I'd think perhaps they should be addressed before publication. (1) The language is a little wonky in my opinion. The document is laying out a 'transport protocol'. But, while this protocol does transport bits of data this is absolutely not a layer 4 protocol and so I was initially a bit confused. This draft lays out an application layer protocol (a slightly tweaked version of HTTP to be exact). It would seem useful to me to clean this up. (2) I wondered why the document said hosts MUST use port 4590. Certainly having a well know port is useful in many cases. But, I don't see why some consortium couldn't decide they were going to use port 4545 or whatever. Likewise, when setting up a callback it'd seem straightforward to give a port number, as well. I am not sure it is the biggest deal in the world, but a solution that leveraged late binding would strikes me as more flexible and hence better. allman ----------ma37937-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk8NlDEACgkQWyrrWs4yIs7S3ACfSB5LMu62jT5ifhdpLmX7lt0o jV0AoJkq8Wdd97cNuYqvOI89sPGEWMVQ =iqhf -----END PGP SIGNATURE----- ----------ma37937-1-- From stephen.farrell@cs.tcd.ie Wed Jan 11 09:32:01 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA7F21F8760; Wed, 11 Jan 2012 09:32:01 -0800 (PST) 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 wwZzdVolBZXV; Wed, 11 Jan 2012 09:32:00 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 29ECA21F8751; Wed, 11 Jan 2012 09:31:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 3FDB8153FAB; Wed, 11 Jan 2012 17:31:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1326303118; bh=zOKPkls++v2o1A EJPOPjuwbYuJRtTAOe6ASgTAkbXAI=; b=RRLeG/IOKc/ED2+eILiQ0R9gQQ5XXF 2WkbU+buwUsIVNMT4fadDNKWNMxaYHQzVKI+COQ3SQvOisfNV4azRNmNrOpzny91 To86r6fjv6iAKblfuZC7vgv1y4XsmRcaWIkRGDy/z35klCIb4Crsb3cJ9N3W1s10 OhPXbJNB0tExp9FO6jEeKMoriXl0WRWY1Lc8orX/Jbyvve9OzGY6HKWDBLYHz9uG TAONHmozk/2vPsIdCUasoQvA6hQsjG4idOojy0RtvuXv+EYGch5tB1mjLEgZlthV 73mDQFGP8ayc0T6uxS+U2U+/h69q5Qw6dZD1JHR46xjyXLrExPv5DWaw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id ePos7JxZj4G0; Wed, 11 Jan 2012 17:31:58 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0C6A1171C7D; Wed, 11 Jan 2012 17:31:57 +0000 (GMT) Message-ID: <4F0DC78D.2010809@cs.tcd.ie> Date: Wed, 11 Jan 2012 17:31:57 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: IETF-Discussion Subject: Re: WG Review: Recharter of Diameter Maintenance and Extensions (dime) References: <20120111163717.591B021F87EF@ietfa.amsl.com> In-Reply-To: <20120111163717.591B021F87EF@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, iesg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 17:32:01 -0000 Hi, During the IESG internal review of this I asked whether or not there was interest in trying to tackle end to end security for AVPs. I do know there is at least some interest in that but its not clear there's enough to warrant including it in the re-charter so I said I'd ask when the recharter went out for review... So - anyone interested in DIME solving that problem? (And willing and able to help do the work of course.) As of now, Diameter really only has hop-by-hop security which is ok in many cases but far from ideal (wearing my security hat) in some. Thanks, Stephen. On 01/11/2012 04:37 PM, IESG Secretary wrote: > A modified charter has been submitted for the Diameter Maintenance and > Extensions (dime) working group in the Operations and Management Area of > the IETF. The IESG has not made any determination as yet. The modified > charter is provided below for informational purposes only. Please send > your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, > January 18, 2012. > > Diameter Maintenance and Extensions (dime) > ----------------------------------------- > Current Status: Active > > Last Modified: 2012-01-10 > > Chairs: > Lionel Morand > Jouni Korhonen > > Operations and Management Area Directors: > Dan Romascanu > Ronald Bonica > > Operations and Management Area Advisor: > Dan Romascanu > > Mailing Lists: > General Discussion: dime@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/dime > Archive: > http://www.ietf.org/mail-archive/web/dime/current/maillist.html > > Description of Working Group: > > The Diameter Maintenance and Extensions WG will focus on maintenance and > extensions to the Diameter protocol required to enable its use for > authentication, authorization, accounting, charging in network access, > provisioning of configuration information within the network, and for > new AAA session management uses within the extensibility rules of the > Diameter base protocol. > > The DIME working group plans to address the following items: > > - Maintaining and/or progressing, along the standards track, the > Diameter Base protocol and Diameter Applications. This includes > extensions to Diameter Base protocol that can be considered as enhanced > features or bug fixes. > > - Diameter application design guideline. This document will provide > guidelines for design of Diameter extensions. It will detail when to > consider reusing an existing application and when to develop a new > application. > > - Protocol extensions for the management of Diameter entities. This work > focuses on the standardization of Management Information Bases (MIBs) to > configure Diameter entities (such as the Diameter Base protocol or > Diameter Credit Control nodes). The usage of other management protocols > for configuring Diameter entities may be future work within the group. > > - Protocol extensions for bulk and grouped AAA session management. The > aim of this work is to study and standardize a solution for handling > groups of AAA sessions within the Diameter base protocol context. The > solution would define how to identify and handle grouped AAA sessions in > commands and operations. > > Additionally, Diameter-based systems require interoperability in order > to work. The working group, along with the AD, will need to evaluate any > potential extensions and require verification that the proposed > extension is needed, and is within the extensibility rules of Diameter > and AAA scope. Coordination with other IETF working groups and other > SDOs (e.g. 3GPP) will be used to ensure this. > > Goals and Milestones: > > Done - Submit the following two Diameter Mobility documents to the > IESG for consideration as a Proposed Standards:* 'Diameter > Mobile IPv6: Support for Home Agent to Diameter Server > Interaction' * 'Diameter Mobile IPv6: Support for Network > Access Server to Diameter Server Interaction' > Done - Submit 'Diameter API' to the IESG for consideration as an > Informational RFC > Done - Submit 'Quality of Service Parameters for Usage with > Diameter' to the IESG for consideration as a Proposed > Standard. > Done - Submit 'Diameter QoS Application' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Support for EAP Re-authentication > Protocol' as DIME working group item > Done - Submit 'Diameter User-Name and Realm Based Request Routing > Clarifications' as DIME working group item > Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group > item > Done - Submit 'Quality of Service Attributes for Diameter' to the > IESG for consideration as a Proposed Standard > Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter User-Name and Realm Based Request Routing > Clarifications' to the IESG for consideration as a Proposed > Standard > Done - Submit 'Diameter NAT Control Application' as DIME working > group item > Done - Submit 'Diameter Capabilities Update' as DIME working group > item > Done - Submit 'Diameter Credit Control Application MIB' to the > IESG for consideration as an Informational RFC > Done - Submit 'Diameter Base Protocol MIB' to the IESG for > consideration as an Informational RFC > Done - Submit 'Diameter Capabilities Update' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Extended NAPTR' as DIME working group item > Done - Submit 'Realm-Based Redirection In Diameter' as DIME > working group item > Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized > Routing' as DIME working group item > Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic > Key Transport' as DIME working group item > Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME > working group item > Done - Submit 'Diameter IKEv2 PSK' as DIME working group item > Done - Submit Revision of 'Diameter Base Protocol' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic > Key Transport' to the IESG for consideration as a Proposed > Standard > Done - Submit 'Diameter Priority Attribute Value Pairs' to the > IESG for consideration as a Proposed Standard > Done - Submit Revision of 'Diameter Network Access Server > Application - RFC 4005bis' as DIME working group item > Done - Submit 'Diameter NAT Control Application' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration > as a Proposed Standard > Done - Submit 'Diameter Extended NAPTR' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized > Routing' to the IESG for consideration as a Proposed > Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG > for consideration as a Proposed Standard > Mar 2012 - Submit Revision of 'Diameter Network Access Server > Application - RFC 4005bis' to the IESG for consideration as a > Proposed Standard > May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG > for consideration as a BCP document Standard > Jul 2012 - Submit 'Diameter Support for EAP Re-authentication > Protocol' to the IESG for consideration as a Proposed > Standard > Aug 2012 - Submit a document on 'Protocol extension for bulk and group > signaling' as a working group item > Aug 2013 - Submit a document on 'Protocol extension for bulk and group > signaling' to the IESG for consideration as a Proposed > Standard > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From paul.hoffman@vpnc.org Wed Jan 11 11:02:48 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70B921F852F; Wed, 11 Jan 2012 11:02:48 -0800 (PST) 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 xmsPyCy0PuVz; Wed, 11 Jan 2012 11:02:48 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCBB21F84D4; Wed, 11 Jan 2012 11:02:48 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0BJ2kd0059299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Jan 2012 12:02:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Subject: Re: Gen-ART review of draft-ietf-marf-redaction-04 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> Date: Wed, 11 Jan 2012 11:02:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <636DA6C1-48E5-4A3D-BEE8-B6AD46E7DF49@vpnc.org> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> To: IETF Discussion X-Mailer: Apple Mail (2.1251.1) Cc: gen-art@ietf.org, marf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 19:02:49 -0000 On Jan 10, 2012, at 6:44 PM, = wrote: > [1] The first open issue is the absence of security guidance to ensure = that this > redaction technique effectively hides the redacted information. The = redaction > technique is to concatenate a secret string (called the "redaction = key") to the > information to be redacted, apply "any hashing/digest algorithm", = convert the output > to base64 and use that base64 string to replace the redacted = information. >=20 > There are two important ways in which this technique could fail to = effectively hide > the redacted information: > - The secret string may inject insufficient entropy. > - The hashing/digest algorithm may be weak. >=20 > To take an extreme example, if the secret string ("redaction key") = consists of a > single ASCII character, and a short email local part is being = redacted, then the > output is highly vulnerable to dictionary and brute force attacks = because only 6 bits > of entropy are added (the result may look secure, but it's not). = Beyond this extreme > example, this is a potentially real concern - e.g., applying the rule = of thumb that > ASCII text contains 4-5 bits of entropy per character, the example in = Appendix A > uses a "redaction key" of "potatoes" that injects at most 40 bits of = entropy - > is that sufficient for email redaction purposes? >=20 > To take a silly example, if a CRC is used as the hash with that sort = of short input, > the result is not particularly difficult to invert. >=20 > I suggest a couple of changes: > 1) Change "any hashing/digest algorithm" to require use of a secure = hash, and > explain what is meant by "secure hash" in the security = considerations section. Simply saying "any hash algorithm listed in [FIPS180-3]" is precise and = sufficient. > 2) Require a minimum length of the "redaction key" string, and = strongly suggest > (SHOULD) that it be randomly generated (e.g., by running = sufficient output > of an entropy-rich random number generator through a base64 = converter). Proposal: "The redaction key SHOULD be based on at least 64 bits of = pseudo-random input that is converted to base64". > [2] The second open issue is absence of security considerations for = the redaction > key. The security considerations section needs to caution that the = redaction key > is a secret key that must be managed and protected as a secret key. = Disclosure > of a redaction key removes the redaction from all reports that used = that key. Agree. > As part of this, guidance should be provided on when and how to change = the > redaction key in order to limit the effects of loss of secrecy for a = single > redaction key. Disagree, given that we have absolutely no idea how systems that use = this will work operationally. Simply telling them "if it is no longer = secret, you're hosed" is sufficient. --Paul Hoffman From sm@resistor.net Wed Jan 11 11:50:41 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6063E21F84F5; Wed, 11 Jan 2012 11:50:41 -0800 (PST) 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 0on2hh3+H8cF; Wed, 11 Jan 2012 11:50:38 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDF821F84F3; Wed, 11 Jan 2012 11:50:38 -0800 (PST) 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 q0BJoTsG014962; Wed, 11 Jan 2012 11:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326311436; i=@resistor.net; bh=P/QL1U+E812ocBWJFlglwAiQx/51Q3iWIN49ZNK0JJ8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=vH84mbHasBOfd1qJ41w0Uj4cFl/swBxBc0Qd/Y4EPtwix9vcNIN76Ez5dYNdwypd5 sgqBIQDsjPsW7wXLhdpAqSuB+abo7eNzV8YlnNPHqfyO71Mq0jnTfymIWgl7/jFeRf w7e68PP6yekAVJRawnLfO3loEnrD/NFlMydsgWjc= Message-Id: <6.2.5.6.2.20120111112546.0c105678@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Jan 2012 11:50:20 -0800 To: david.black@emc.com From: SM Subject: Re: Gen-ART review of draft-ietf-marf-redaction-04 In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc. com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: gen-art@ietf.org, ietf@ietf.org, marf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 19:50:41 -0000 Hi David, At 18:44 10-01-2012, david.black@emc.com wrote: >I am the assigned Gen-ART reviewer for this draft. For background on >Gen-ART, please I appreciate that you have spent your time and effort in performing the review. I find the review useful. > From a pure security perspective, use of HMAC with specified secure hashes >(SHA2-family) and an approach of hashing the "redaction key" down to a binary >key for HMAC would be a stronger approach. I suggest that authors consider >approach, but there may be practical usage concerns that suggest >not adopting it. > >[2] The second open issue is absence of security considerations for >the redaction >key. The security considerations section needs to caution that the >redaction key >is a secret key that must be managed and protected as a secret >key. Disclosure >of a redaction key removes the redaction from all reports that used that key. >As part of this, guidance should be provided on when and how to change the >redaction key in order to limit the effects of loss of secrecy for a single >redaction key. The comments are from a security perspective. To be candid, redaction is silly as the email folks know how to get around that. The secret key does not even have to be broken; a cookie in the message would get you the information you want. The cost of preserving the secrecy is not worth it in my opinion. Regards, -sm From jouni.nospam@gmail.com Thu Jan 12 04:08:17 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E68C21F85C6; Thu, 12 Jan 2012 04:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 7F0p7xcyJMKG; Thu, 12 Jan 2012 04:08:16 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB3DF21F84B2; Thu, 12 Jan 2012 04:08:15 -0800 (PST) Received: by wibhj6 with SMTP id hj6so1445113wib.31 for ; Thu, 12 Jan 2012 04:08:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=EnBnRiaOfXA8RWsKwUn9oFklN8M9OqgjabcvTdPe7Uw=; b=qGEQXAGUunpJmVkvUMt8JI/+IZcoFLc6UP4JoxU4dEbn3atlrgGCcgWIRj6IHf11z6 073ERBCDiwj7pxQF5whFDiWDUrpOdXw649/eRuPxzgS/sq4dj3LsG8dWtGBhehyC8+Of cbcaW185fHwTATmb75/aiq+RIh7rMhuAohavI= Received: by 10.180.99.225 with SMTP id et1mr938552wib.2.1326370093913; Thu, 12 Jan 2012 04:08:13 -0800 (PST) Received: from [10.255.133.241] ([192.100.123.77]) by mx.google.com with ESMTPS id 1sm8591897wiz.11.2012.01.12.04.08.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jan 2012 04:08:12 -0800 (PST) Subject: Re: WG Review: Recharter of Diameter Maintenance and Extensions (dime) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4F0DC78D.2010809@cs.tcd.ie> Date: Thu, 12 Jan 2012 14:08:08 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20120111163717.591B021F87EF@ietfa.amsl.com> <4F0DC78D.2010809@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, IETF-Discussion , iesg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 12:08:17 -0000 Stephen, This topic raises its head every now and then when a Dime document arrives at IESG ;) Apart from that there has been very little serious public discussion about it recently, for some unknown reason to me. A detail worth pointing out is that the support for the End-to-End security framework (E2E-Sequence AVP and 'P'-bit in the AVP header) has been deprecated in RFC3588bis (now in IESG). So we are "free" to start from scratch. If there is enough serious energy and vision for pursuing end-to-end security, I do not see current proposed charter text prohibiting it: "- Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes." I would argue the end-to-end security is an enhanced feature for Diameter base protocol that fixes a serious bug/flaw in security. On the other hand, if an explicit note is needed about this topic in the charter, I might hesitate to include such in this round. I would first like to see some concrete movement & work around this topic. - Jouni On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: > > Hi, > > During the IESG internal review of this I asked whether > or not there was interest in trying to tackle end to > end security for AVPs. I do know there is at least some > interest in that but its not clear there's enough to > warrant including it in the re-charter so I said I'd > ask when the recharter went out for review... > > So - anyone interested in DIME solving that problem? > (And willing and able to help do the work of course.) > > As of now, Diameter really only has hop-by-hop security > which is ok in many cases but far from ideal (wearing > my security hat) in some. > > Thanks, > Stephen. > > On 01/11/2012 04:37 PM, IESG Secretary wrote: >> A modified charter has been submitted for the Diameter Maintenance and >> Extensions (dime) working group in the Operations and Management Area of >> the IETF. The IESG has not made any determination as yet. The modified >> charter is provided below for informational purposes only. Please send >> your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, >> January 18, 2012. >> >> Diameter Maintenance and Extensions (dime) >> ----------------------------------------- >> Current Status: Active >> >> Last Modified: 2012-01-10 >> >> Chairs: >> Lionel Morand >> Jouni Korhonen >> >> Operations and Management Area Directors: >> Dan Romascanu >> Ronald Bonica >> >> Operations and Management Area Advisor: >> Dan Romascanu >> >> Mailing Lists: >> General Discussion: dime@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/dime >> Archive: >> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >> >> Description of Working Group: >> >> The Diameter Maintenance and Extensions WG will focus on maintenance and >> extensions to the Diameter protocol required to enable its use for >> authentication, authorization, accounting, charging in network access, >> provisioning of configuration information within the network, and for >> new AAA session management uses within the extensibility rules of the >> Diameter base protocol. >> >> The DIME working group plans to address the following items: >> >> - Maintaining and/or progressing, along the standards track, the >> Diameter Base protocol and Diameter Applications. This includes >> extensions to Diameter Base protocol that can be considered as enhanced >> features or bug fixes. >> >> - Diameter application design guideline. This document will provide >> guidelines for design of Diameter extensions. It will detail when to >> consider reusing an existing application and when to develop a new >> application. >> >> - Protocol extensions for the management of Diameter entities. This work >> focuses on the standardization of Management Information Bases (MIBs) to >> configure Diameter entities (such as the Diameter Base protocol or >> Diameter Credit Control nodes). The usage of other management protocols >> for configuring Diameter entities may be future work within the group. >> >> - Protocol extensions for bulk and grouped AAA session management. The >> aim of this work is to study and standardize a solution for handling >> groups of AAA sessions within the Diameter base protocol context. The >> solution would define how to identify and handle grouped AAA sessions in >> commands and operations. >> >> Additionally, Diameter-based systems require interoperability in order >> to work. The working group, along with the AD, will need to evaluate any >> potential extensions and require verification that the proposed >> extension is needed, and is within the extensibility rules of Diameter >> and AAA scope. Coordination with other IETF working groups and other >> SDOs (e.g. 3GPP) will be used to ensure this. >> >> Goals and Milestones: >> >> Done - Submit the following two Diameter Mobility documents to the >> IESG for consideration as a Proposed Standards:* 'Diameter >> Mobile IPv6: Support for Home Agent to Diameter Server >> Interaction' * 'Diameter Mobile IPv6: Support for Network >> Access Server to Diameter Server Interaction' >> Done - Submit 'Diameter API' to the IESG for consideration as an >> Informational RFC >> Done - Submit 'Quality of Service Parameters for Usage with >> Diameter' to the IESG for consideration as a Proposed >> Standard. >> Done - Submit 'Diameter QoS Application' to the IESG for >> consideration as a Proposed Standard >> Done - Submit 'Diameter Support for EAP Re-authentication >> Protocol' as DIME working group item >> Done - Submit 'Diameter User-Name and Realm Based Request Routing >> Clarifications' as DIME working group item >> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group >> item >> Done - Submit 'Quality of Service Attributes for Diameter' to the >> IESG for consideration as a Proposed Standard >> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >> consideration as a Proposed Standard >> Done - Submit 'Diameter User-Name and Realm Based Request Routing >> Clarifications' to the IESG for consideration as a Proposed >> Standard >> Done - Submit 'Diameter NAT Control Application' as DIME working >> group item >> Done - Submit 'Diameter Capabilities Update' as DIME working group >> item >> Done - Submit 'Diameter Credit Control Application MIB' to the >> IESG for consideration as an Informational RFC >> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >> consideration as an Informational RFC >> Done - Submit 'Diameter Capabilities Update' to the IESG for >> consideration as a Proposed Standard >> Done - Submit 'Diameter Extended NAPTR' as DIME working group item >> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >> working group item >> Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized >> Routing' as DIME working group item >> Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic >> Key Transport' as DIME working group item >> Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME >> working group item >> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item >> Done - Submit Revision of 'Diameter Base Protocol' to the IESG for >> consideration as a Proposed Standard >> Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic >> Key Transport' to the IESG for consideration as a Proposed >> Standard >> Done - Submit 'Diameter Priority Attribute Value Pairs' to the >> IESG for consideration as a Proposed Standard >> Done - Submit Revision of 'Diameter Network Access Server >> Application - RFC 4005bis' as DIME working group item >> Done - Submit 'Diameter NAT Control Application' to the IESG for >> consideration as a Proposed Standard >> Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration >> as a Proposed Standard >> Done - Submit 'Diameter Extended NAPTR' to the IESG for >> consideration as a Proposed Standard >> Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized >> Routing' to the IESG for consideration as a Proposed >> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG >> for consideration as a Proposed Standard >> Mar 2012 - Submit Revision of 'Diameter Network Access Server >> Application - RFC 4005bis' to the IESG for consideration as a >> Proposed Standard >> May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG >> for consideration as a BCP document Standard >> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >> Protocol' to the IESG for consideration as a Proposed >> Standard >> Aug 2012 - Submit a document on 'Protocol extension for bulk and group >> signaling' as a working group item >> Aug 2013 - Submit a document on 'Protocol extension for bulk and group >> signaling' to the IESG for consideration as a Proposed >> Standard >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >> > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From stephen.farrell@cs.tcd.ie Thu Jan 12 04:13:15 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E62321F8475; Thu, 12 Jan 2012 04:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 yFUf-ualDbKv; Thu, 12 Jan 2012 04:13:14 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1254F21F8528; Thu, 12 Jan 2012 04:13:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1B4BC153FA1; Thu, 12 Jan 2012 12:13:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1326370392; bh=xh94EXIvsgItnn pCxpOlIq5yKLBujlOrxbc2QQ7dVF4=; b=php450/7S0YxqHUcWEwMi3whXwjjUN XNEC5oLJClGzzQajw4Wnpf9MzInmAEWxZ839NFG9gwRCf8gaQPOQvW0kagtR/LkI wbkGyeVXCPCRtwQbkJMmWluCHmTlvUOuDIbCE61/I6NdokNPogZT8z2hfq/y71al G/HDA8hOYJPYxwCLpQPyH3jTOPgQsPH8nGL/+lbTtK/ESSMxX/1YkrBHnmC9ARL1 eP6M5fjVsRiBU/+p7M86IpMLpPtwFYWUwNNtmhXCI5HLsGRObULhPxX1sxj2WgdB AYt7KnyMBvK3y3j5Grnsagp0yqQSzhydaMV60mfQMFA8eGQ48QJH1OBw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id JeOKSlkNCVNn; Thu, 12 Jan 2012 12:13:12 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 10E8F171C77; Thu, 12 Jan 2012 12:13:12 +0000 (GMT) Message-ID: <4F0ECE57.3020900@cs.tcd.ie> Date: Thu, 12 Jan 2012 12:13:11 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: jouni korhonen Subject: Re: WG Review: Recharter of Diameter Maintenance and Extensions (dime) References: <20120111163717.591B021F87EF@ietfa.amsl.com> <4F0DC78D.2010809@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, IETF-Discussion , iesg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 12:13:15 -0000 Hi Jouni, Right, I'm trying to encourage this - I'm not trying to make it a gating function for the recharter. Its still worth doing though if we can find some victims with enough energy:-) I agree that the current charter text might not need to be modified, OTOH, if there were folks who wanted to do the work, a milestone might be good. I also agree that as of now, that addition is not warranted. Cheers, S On 01/12/2012 12:08 PM, jouni korhonen wrote: > > Stephen, > > This topic raises its head every now and then when a Dime > document arrives at IESG ;) Apart from that there has been > very little serious public discussion about it recently, > for some unknown reason to me. A detail worth pointing out > is that the support for the End-to-End security framework > (E2E-Sequence AVP and 'P'-bit in the AVP header) has been > deprecated in RFC3588bis (now in IESG). So we are "free" > to start from scratch. > > If there is enough serious energy and vision for pursuing > end-to-end security, I do not see current proposed charter > text prohibiting it: > > "- Maintaining and/or progressing, along the standards track, the > Diameter Base protocol and Diameter Applications. This includes > extensions to Diameter Base protocol that can be considered as > enhanced features or bug fixes." > > I would argue the end-to-end security is an enhanced feature for > Diameter base protocol that fixes a serious bug/flaw in security. > On the other hand, if an explicit note is needed about this topic > in the charter, I might hesitate to include such in this round. > I would first like to see some concrete movement& work around > this topic. > > - Jouni > > > > On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: > >> >> Hi, >> >> During the IESG internal review of this I asked whether >> or not there was interest in trying to tackle end to >> end security for AVPs. I do know there is at least some >> interest in that but its not clear there's enough to >> warrant including it in the re-charter so I said I'd >> ask when the recharter went out for review... >> >> So - anyone interested in DIME solving that problem? >> (And willing and able to help do the work of course.) >> >> As of now, Diameter really only has hop-by-hop security >> which is ok in many cases but far from ideal (wearing >> my security hat) in some. >> >> Thanks, >> Stephen. >> >> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>> A modified charter has been submitted for the Diameter Maintenance and >>> Extensions (dime) working group in the Operations and Management Area of >>> the IETF. The IESG has not made any determination as yet. The modified >>> charter is provided below for informational purposes only. Please send >>> your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, >>> January 18, 2012. >>> >>> Diameter Maintenance and Extensions (dime) >>> ----------------------------------------- >>> Current Status: Active >>> >>> Last Modified: 2012-01-10 >>> >>> Chairs: >>> Lionel Morand >>> Jouni Korhonen >>> >>> Operations and Management Area Directors: >>> Dan Romascanu >>> Ronald Bonica >>> >>> Operations and Management Area Advisor: >>> Dan Romascanu >>> >>> Mailing Lists: >>> General Discussion: dime@ietf.org >>> To Subscribe: https://www.ietf.org/mailman/listinfo/dime >>> Archive: >>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>> >>> Description of Working Group: >>> >>> The Diameter Maintenance and Extensions WG will focus on maintenance and >>> extensions to the Diameter protocol required to enable its use for >>> authentication, authorization, accounting, charging in network access, >>> provisioning of configuration information within the network, and for >>> new AAA session management uses within the extensibility rules of the >>> Diameter base protocol. >>> >>> The DIME working group plans to address the following items: >>> >>> - Maintaining and/or progressing, along the standards track, the >>> Diameter Base protocol and Diameter Applications. This includes >>> extensions to Diameter Base protocol that can be considered as enhanced >>> features or bug fixes. >>> >>> - Diameter application design guideline. This document will provide >>> guidelines for design of Diameter extensions. It will detail when to >>> consider reusing an existing application and when to develop a new >>> application. >>> >>> - Protocol extensions for the management of Diameter entities. This work >>> focuses on the standardization of Management Information Bases (MIBs) to >>> configure Diameter entities (such as the Diameter Base protocol or >>> Diameter Credit Control nodes). The usage of other management protocols >>> for configuring Diameter entities may be future work within the group. >>> >>> - Protocol extensions for bulk and grouped AAA session management. The >>> aim of this work is to study and standardize a solution for handling >>> groups of AAA sessions within the Diameter base protocol context. The >>> solution would define how to identify and handle grouped AAA sessions in >>> commands and operations. >>> >>> Additionally, Diameter-based systems require interoperability in order >>> to work. The working group, along with the AD, will need to evaluate any >>> potential extensions and require verification that the proposed >>> extension is needed, and is within the extensibility rules of Diameter >>> and AAA scope. Coordination with other IETF working groups and other >>> SDOs (e.g. 3GPP) will be used to ensure this. >>> >>> Goals and Milestones: >>> >>> Done - Submit the following two Diameter Mobility documents to the >>> IESG for consideration as a Proposed Standards:* 'Diameter >>> Mobile IPv6: Support for Home Agent to Diameter Server >>> Interaction' * 'Diameter Mobile IPv6: Support for Network >>> Access Server to Diameter Server Interaction' >>> Done - Submit 'Diameter API' to the IESG for consideration as an >>> Informational RFC >>> Done - Submit 'Quality of Service Parameters for Usage with >>> Diameter' to the IESG for consideration as a Proposed >>> Standard. >>> Done - Submit 'Diameter QoS Application' to the IESG for >>> consideration as a Proposed Standard >>> Done - Submit 'Diameter Support for EAP Re-authentication >>> Protocol' as DIME working group item >>> Done - Submit 'Diameter User-Name and Realm Based Request Routing >>> Clarifications' as DIME working group item >>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group >>> item >>> Done - Submit 'Quality of Service Attributes for Diameter' to the >>> IESG for consideration as a Proposed Standard >>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>> consideration as a Proposed Standard >>> Done - Submit 'Diameter User-Name and Realm Based Request Routing >>> Clarifications' to the IESG for consideration as a Proposed >>> Standard >>> Done - Submit 'Diameter NAT Control Application' as DIME working >>> group item >>> Done - Submit 'Diameter Capabilities Update' as DIME working group >>> item >>> Done - Submit 'Diameter Credit Control Application MIB' to the >>> IESG for consideration as an Informational RFC >>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>> consideration as an Informational RFC >>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>> consideration as a Proposed Standard >>> Done - Submit 'Diameter Extended NAPTR' as DIME working group item >>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>> working group item >>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized >>> Routing' as DIME working group item >>> Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic >>> Key Transport' as DIME working group item >>> Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME >>> working group item >>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item >>> Done - Submit Revision of 'Diameter Base Protocol' to the IESG for >>> consideration as a Proposed Standard >>> Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic >>> Key Transport' to the IESG for consideration as a Proposed >>> Standard >>> Done - Submit 'Diameter Priority Attribute Value Pairs' to the >>> IESG for consideration as a Proposed Standard >>> Done - Submit Revision of 'Diameter Network Access Server >>> Application - RFC 4005bis' as DIME working group item >>> Done - Submit 'Diameter NAT Control Application' to the IESG for >>> consideration as a Proposed Standard >>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration >>> as a Proposed Standard >>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>> consideration as a Proposed Standard >>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized >>> Routing' to the IESG for consideration as a Proposed >>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG >>> for consideration as a Proposed Standard >>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>> Application - RFC 4005bis' to the IESG for consideration as a >>> Proposed Standard >>> May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG >>> for consideration as a BCP document Standard >>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>> Protocol' to the IESG for consideration as a Proposed >>> Standard >>> Aug 2012 - Submit a document on 'Protocol extension for bulk and group >>> signaling' as a working group item >>> Aug 2013 - Submit a document on 'Protocol extension for bulk and group >>> signaling' to the IESG for consideration as a Proposed >>> Standard >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > From dromasca@avaya.com Thu Jan 12 04:16:02 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFCB21F8528; Thu, 12 Jan 2012 04:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.763 X-Spam-Level: X-Spam-Status: No, score=-102.763 tagged_above=-999 required=5 tests=[AWL=-0.164, 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 Jcyv4sZsXhSZ; Thu, 12 Jan 2012 04:16:01 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 60A7921F8545; Thu, 12 Jan 2012 04:16:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHzNDk/GmAcF/2dsb2JhbAA5Cq0GgQWBcgEBAQECAQEBAQ8eCjQLDAQCAQgNBAQBAQEKAgQMCwEGASYfCQgBAQQBEggBEgeHWAicNJsdiGCCWmMEmn+MSw X-IronPort-AV: E=Sophos;i="4.71,497,1320642000"; d="scan'208";a="226393410" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 12 Jan 2012 07:16:00 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Jan 2012 07:11:34 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Review: Recharter of Diameter Maintenance and Extensions (dime) Date: Thu, 12 Jan 2012 13:15:57 +0100 Message-ID: In-Reply-To: <4F0ECE57.3020900@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Diameter Maintenance and Extensions (dime) Thread-Index: AczRI5OWhvhx1Pj+R2SNnGslpuoTlwAACHUQ References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> From: "Romascanu, Dan (Dan)" To: "Stephen Farrell" , "jouni korhonen" Cc: jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, IETF-Discussion , iesg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 12:16:02 -0000 Hi, If a number of hands were raised now and the folks commanding them say 'we are ready to work on this NOW' I would support including explicit wording in the charter. If this does not happen until the telechat next week the current text is good enough to allow interested people to start working on contributions that can be individual submissions. If these submissions are consistent enough the WG can add the milestone later in the charter and adopt the submissions as WG items.=20 Dan > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > Stephen Farrell > Sent: Thursday, January 12, 2012 2:13 PM > To: jouni korhonen > Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; > dime@ietf.org; IETF-Discussion; iesg@ietf.org > Subject: Re: WG Review: Recharter of Diameter Maintenance and > Extensions (dime) >=20 >=20 > Hi Jouni, >=20 > Right, I'm trying to encourage this - I'm not trying > to make it a gating function for the recharter. Its > still worth doing though if we can find some victims > with enough energy:-) >=20 > I agree that the current charter text might not need > to be modified, OTOH, if there were folks who wanted to > do the work, a milestone might be good. I also agree > that as of now, that addition is not warranted. >=20 > Cheers, > S >=20 > On 01/12/2012 12:08 PM, jouni korhonen wrote: > > > > Stephen, > > > > This topic raises its head every now and then when a Dime > > document arrives at IESG ;) Apart from that there has been > > very little serious public discussion about it recently, > > for some unknown reason to me. A detail worth pointing out > > is that the support for the End-to-End security framework > > (E2E-Sequence AVP and 'P'-bit in the AVP header) has been > > deprecated in RFC3588bis (now in IESG). So we are "free" > > to start from scratch. > > > > If there is enough serious energy and vision for pursuing > > end-to-end security, I do not see current proposed charter > > text prohibiting it: > > > > "- Maintaining and/or progressing, along the standards track, the > > Diameter Base protocol and Diameter Applications. This includes > > extensions to Diameter Base protocol that can be considered as > > enhanced features or bug fixes." > > > > I would argue the end-to-end security is an enhanced feature for > > Diameter base protocol that fixes a serious bug/flaw in security. > > On the other hand, if an explicit note is needed about this topic > > in the charter, I might hesitate to include such in this round. > > I would first like to see some concrete movement& work around > > this topic. > > > > - Jouni > > > > > > > > On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: > > > >> > >> Hi, > >> > >> During the IESG internal review of this I asked whether > >> or not there was interest in trying to tackle end to > >> end security for AVPs. I do know there is at least some > >> interest in that but its not clear there's enough to > >> warrant including it in the re-charter so I said I'd > >> ask when the recharter went out for review... > >> > >> So - anyone interested in DIME solving that problem? > >> (And willing and able to help do the work of course.) > >> > >> As of now, Diameter really only has hop-by-hop security > >> which is ok in many cases but far from ideal (wearing > >> my security hat) in some. > >> > >> Thanks, > >> Stephen. > >> > >> On 01/11/2012 04:37 PM, IESG Secretary wrote: > >>> A modified charter has been submitted for the Diameter Maintenance > and > >>> Extensions (dime) working group in the Operations and Management > Area of > >>> the IETF. The IESG has not made any determination as yet. The > modified > >>> charter is provided below for informational purposes only. Please > send > >>> your comments to the IESG mailing list (iesg@ietf.org) by > Wednesday, > >>> January 18, 2012. > >>> > >>> Diameter Maintenance and Extensions (dime) > >>> ----------------------------------------- > >>> Current Status: Active > >>> > >>> Last Modified: 2012-01-10 > >>> > >>> Chairs: > >>> Lionel Morand > >>> Jouni Korhonen > >>> > >>> Operations and Management Area Directors: > >>> Dan Romascanu > >>> Ronald Bonica > >>> > >>> Operations and Management Area Advisor: > >>> Dan Romascanu > >>> > >>> Mailing Lists: > >>> General Discussion: dime@ietf.org > >>> To Subscribe: https://www.ietf.org/mailman/listinfo/dime > >>> Archive: > >>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html > >>> > >>> Description of Working Group: > >>> > >>> The Diameter Maintenance and Extensions WG will focus on > maintenance and > >>> extensions to the Diameter protocol required to enable its use for > >>> authentication, authorization, accounting, charging in network > access, > >>> provisioning of configuration information within the network, and > for > >>> new AAA session management uses within the extensibility rules of > the > >>> Diameter base protocol. > >>> > >>> The DIME working group plans to address the following items: > >>> > >>> - Maintaining and/or progressing, along the standards track, the > >>> Diameter Base protocol and Diameter Applications. This includes > >>> extensions to Diameter Base protocol that can be considered as > enhanced > >>> features or bug fixes. > >>> > >>> - Diameter application design guideline. This document will provide > >>> guidelines for design of Diameter extensions. It will detail when > to > >>> consider reusing an existing application and when to develop a new > >>> application. > >>> > >>> - Protocol extensions for the management of Diameter entities. This > work > >>> focuses on the standardization of Management Information Bases > (MIBs) to > >>> configure Diameter entities (such as the Diameter Base protocol or > >>> Diameter Credit Control nodes). The usage of other management > protocols > >>> for configuring Diameter entities may be future work within the > group. > >>> > >>> - Protocol extensions for bulk and grouped AAA session management. > The > >>> aim of this work is to study and standardize a solution for > handling > >>> groups of AAA sessions within the Diameter base protocol context. > The > >>> solution would define how to identify and handle grouped AAA > sessions in > >>> commands and operations. > >>> > >>> Additionally, Diameter-based systems require interoperability in > order > >>> to work. The working group, along with the AD, will need to > evaluate any > >>> potential extensions and require verification that the proposed > >>> extension is needed, and is within the extensibility rules of > Diameter > >>> and AAA scope. Coordination with other IETF working groups and > other > >>> SDOs (e.g. 3GPP) will be used to ensure this. > >>> > >>> Goals and Milestones: > >>> > >>> Done - Submit the following two Diameter Mobility documents to > the > >>> IESG for consideration as a Proposed Standards:* > 'Diameter > >>> Mobile IPv6: Support for Home Agent to Diameter Server > >>> Interaction' * 'Diameter Mobile IPv6: Support for > Network > >>> Access Server to Diameter Server Interaction' > >>> Done - Submit 'Diameter API' to the IESG for consideration as > an > >>> Informational RFC > >>> Done - Submit 'Quality of Service Parameters for Usage with > >>> Diameter' to the IESG for consideration as a Proposed > >>> Standard. > >>> Done - Submit 'Diameter QoS Application' to the IESG for > >>> consideration as a Proposed Standard > >>> Done - Submit 'Diameter Support for EAP Re-authentication > >>> Protocol' as DIME working group item > >>> Done - Submit 'Diameter User-Name and Realm Based Request > Routing > >>> Clarifications' as DIME working group item > >>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working > group > >>> item > >>> Done - Submit 'Quality of Service Attributes for Diameter' to > the > >>> IESG for consideration as a Proposed Standard > >>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for > >>> consideration as a Proposed Standard > >>> Done - Submit 'Diameter User-Name and Realm Based Request > Routing > >>> Clarifications' to the IESG for consideration as a > Proposed > >>> Standard > >>> Done - Submit 'Diameter NAT Control Application' as DIME > working > >>> group item > >>> Done - Submit 'Diameter Capabilities Update' as DIME working > group > >>> item > >>> Done - Submit 'Diameter Credit Control Application MIB' to the > >>> IESG for consideration as an Informational RFC > >>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for > >>> consideration as an Informational RFC > >>> Done - Submit 'Diameter Capabilities Update' to the IESG for > >>> consideration as a Proposed Standard > >>> Done - Submit 'Diameter Extended NAPTR' as DIME working group > item > >>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME > >>> working group item > >>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized > >>> Routing' as DIME working group item > >>> Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic > >>> Key Transport' as DIME working group item > >>> Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME > >>> working group item > >>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item > >>> Done - Submit Revision of 'Diameter Base Protocol' to the IESG > for > >>> consideration as a Proposed Standard > >>> Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic > >>> Key Transport' to the IESG for consideration as a > Proposed > >>> Standard > >>> Done - Submit 'Diameter Priority Attribute Value Pairs' to the > >>> IESG for consideration as a Proposed Standard > >>> Done - Submit Revision of 'Diameter Network Access Server > >>> Application - RFC 4005bis' as DIME working group item > >>> Done - Submit 'Diameter NAT Control Application' to the IESG > for > >>> consideration as a Proposed Standard > >>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for > consideration > >>> as a Proposed Standard > >>> Done - Submit 'Diameter Extended NAPTR' to the IESG for > >>> consideration as a Proposed Standard > >>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized > >>> Routing' to the IESG for consideration as a Proposed > >>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG > >>> for consideration as a Proposed Standard > >>> Mar 2012 - Submit Revision of 'Diameter Network Access Server > >>> Application - RFC 4005bis' to the IESG for > consideration as a > >>> Proposed Standard > >>> May 2012 - Submit 'Diameter Application Design Guidelines' to the > IESG > >>> for consideration as a BCP document Standard > >>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication > >>> Protocol' to the IESG for consideration as a Proposed > >>> Standard > >>> Aug 2012 - Submit a document on 'Protocol extension for bulk and > group > >>> signaling' as a working group item > >>> Aug 2013 - Submit a document on 'Protocol extension for bulk and > group > >>> signaling' to the IESG for consideration as a Proposed > >>> Standard > >>> _______________________________________________ > >>> IETF-Announce mailing list > >>> IETF-Announce@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ietf-announce > >>> > >> _______________________________________________ > >> Ietf mailing list > >> Ietf@ietf.org > >> https://www.ietf.org/mailman/listinfo/ietf > > From david.black@emc.com Wed Jan 11 12:52:16 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C594321F8533; Wed, 11 Jan 2012 12:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 bHtTnlnLbzDm; Wed, 11 Jan 2012 12:52:16 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id DA0BD21F85D5; Wed, 11 Jan 2012 12:52:15 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0BKqAAZ025206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 15:52:12 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 11 Jan 2012 15:52:02 -0500 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.222.70.133]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0BKq12u024049; Wed, 11 Jan 2012 15:52:01 -0500 Received: from mxhub39.corp.emc.com (128.222.70.106) by mxhub21.corp.emc.com (128.222.70.133) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 11 Jan 2012 15:52:01 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub39.corp.emc.com ([128.222.70.106]) with mapi; Wed, 11 Jan 2012 15:52:01 -0500 From: To: Date: Wed, 11 Jan 2012 15:51:58 -0500 Subject: RE: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-04 Thread-Index: AczQmns3tJWBjqmEQUeESbIBILYfNwABuHzw Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B8106C@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> <6.2.5.6.2.20120111112546.0c105678@resistor.net> In-Reply-To: <6.2.5.6.2.20120111112546.0c105678@resistor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Thu, 12 Jan 2012 08:14:06 -0800 Cc: gen-art@ietf.org, ietf@ietf.org, marf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 20:52:16 -0000 Hi, Thanks for the response - I appreciate the perspective. > The comments are from a security perspective. To be candid, > redaction is silly as the email folks know how to get around > that. The secret key does not even have to be broken; a cookie in > the message would get you the information you want. The cost of > preserving the secrecy is not worth it in my opinion. At a minimum, I like John Levine's suggestion that the draft explain the level of security required for redaction in practice. Such an explanation could help illuminate whether the secure hash (the example in the draft uses SHA-1) is for obfuscation purposes vs. actual security. Absent such an explanation, I saw the use of a secure hash and inferred the existence of actual security requirements. If that was an incorrect inference, then text should be added to the draft to avoid having other readers make similarly incorrect inferences. Thanks, --David > -----Original Message----- > From: SM [mailto:sm@resistor.net] > Sent: Wednesday, January 11, 2012 2:50 PM > To: Black, David > Cc: marf@ietf.org; gen-art@ietf.org; ietf@ietf.org > Subject: Re: Gen-ART review of draft-ietf-marf-redaction-04 >=20 > Hi David, > At 18:44 10-01-2012, david.black@emc.com wrote: > >I am the assigned Gen-ART reviewer for this draft. For background on > >Gen-ART, please >=20 > I appreciate that you have spent your time and effort in performing > the review. I find the review useful. >=20 > > From a pure security perspective, use of HMAC with specified secure has= hes > >(SHA2-family) and an approach of hashing the "redaction key" down to a b= inary > >key for HMAC would be a stronger approach. I suggest that authors consid= er > >approach, but there may be practical usage concerns that suggest > >not adopting it. > > > >[2] The second open issue is absence of security considerations for > >the redaction > >key. The security considerations section needs to caution that the > >redaction key > >is a secret key that must be managed and protected as a secret > >key. Disclosure > >of a redaction key removes the redaction from all reports that used that= key. > >As part of this, guidance should be provided on when and how to change t= he > >redaction key in order to limit the effects of loss of secrecy for a sin= gle > >redaction key. >=20 > The comments are from a security perspective. To be candid, > redaction is silly as the email folks know how to get around > that. The secret key does not even have to be broken; a cookie in > the message would get you the information you want. The cost of > preserving the secrecy is not worth it in my opinion. >=20 > Regards, > -sm >=20 From lionel.morand@orange.com Thu Jan 12 01:26:34 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FAB21F84D4; Thu, 12 Jan 2012 01:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 ayau2eQSdqlQ; Thu, 12 Jan 2012 01:26:34 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 722AD21F84D6; Thu, 12 Jan 2012 01:26:33 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BC4E4A441AB; Thu, 12 Jan 2012 10:27:57 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id AE07AA441AA; Thu, 12 Jan 2012 10:27:57 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 10:26:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] WG Review: Recharter of Diameter Maintenance andExtensions (dime) Date: Thu, 12 Jan 2012 10:25:16 +0100 Message-ID: In-Reply-To: <4F0DC78D.2010809@cs.tcd.ie> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WG Review: Recharter of Diameter Maintenance andExtensions (dime) Thread-Index: AczQqKKC8/aVVhX8RdOvAsOHSUKYDwAYwcMA References: <20120111163717.591B021F87EF@ietfa.amsl.com> <4F0DC78D.2010809@cs.tcd.ie> From: To: , X-OriginalArrivalTime: 12 Jan 2012 09:26:30.0875 (UTC) FILETIME=[44AAAAB0:01CCD10C] X-Mailman-Approved-At: Thu, 12 Jan 2012 08:14:08 -0800 Cc: jouni.korhonen@nsn.com, dime@ietf.org, iesg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 09:26:35 -0000 Hi Stephen, I confirm that there is an interest and this interest is increasing. Now, not sure that I'm the best candidate to lead this work even if I = can help. We will see if there is more support that would motivate to put it right = now in the charter. Regards, Lionel -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Stephen Farrell Envoy=E9=A0: mercredi 11 janvier 2012 18:32 =C0=A0: IETF-Discussion Cc=A0: jouni.korhonen@nsn.com; MORAND Lionel RD-CORE-ISS; dime@ietf.org; = iesg@ietf.org Objet=A0: Re: [Dime] WG Review: Recharter of Diameter Maintenance = andExtensions (dime) Hi, During the IESG internal review of this I asked whether or not there was interest in trying to tackle end to end security for AVPs. I do know there is at least some interest in that but its not clear there's enough to warrant including it in the re-charter so I said I'd ask when the recharter went out for review... So - anyone interested in DIME solving that problem? (And willing and able to help do the work of course.) As of now, Diameter really only has hop-by-hop security which is ok in many cases but far from ideal (wearing my security hat) in some. Thanks, Stephen. On 01/11/2012 04:37 PM, IESG Secretary wrote: > A modified charter has been submitted for the Diameter Maintenance and > Extensions (dime) working group in the Operations and Management Area = of > the IETF. The IESG has not made any determination as yet. The = modified > charter is provided below for informational purposes only. Please = send > your comments to the IESG mailing list (iesg@ietf.org) by Wednesday, > January 18, 2012. > > Diameter Maintenance and Extensions (dime) > ----------------------------------------- > Current Status: Active > > Last Modified: 2012-01-10 > > Chairs: > Lionel Morand > Jouni Korhonen > > Operations and Management Area Directors: > Dan Romascanu > Ronald Bonica > > Operations and Management Area Advisor: > Dan Romascanu > > Mailing Lists: > General Discussion: dime@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/dime > Archive: > http://www.ietf.org/mail-archive/web/dime/current/maillist.html > > Description of Working Group: > > The Diameter Maintenance and Extensions WG will focus on maintenance = and > extensions to the Diameter protocol required to enable its use for > authentication, authorization, accounting, charging in network access, > provisioning of configuration information within the network, and for > new AAA session management uses within the extensibility rules of the > Diameter base protocol. > > The DIME working group plans to address the following items: > > - Maintaining and/or progressing, along the standards track, the > Diameter Base protocol and Diameter Applications. This includes > extensions to Diameter Base protocol that can be considered as = enhanced > features or bug fixes. > > - Diameter application design guideline. This document will provide > guidelines for design of Diameter extensions. It will detail when to > consider reusing an existing application and when to develop a new > application. > > - Protocol extensions for the management of Diameter entities. This = work > focuses on the standardization of Management Information Bases (MIBs) = to > configure Diameter entities (such as the Diameter Base protocol or > Diameter Credit Control nodes). The usage of other management = protocols > for configuring Diameter entities may be future work within the group. > > - Protocol extensions for bulk and grouped AAA session management. The > aim of this work is to study and standardize a solution for handling > groups of AAA sessions within the Diameter base protocol context. The > solution would define how to identify and handle grouped AAA sessions = in > commands and operations. > > Additionally, Diameter-based systems require interoperability in order > to work. The working group, along with the AD, will need to evaluate = any > potential extensions and require verification that the proposed > extension is needed, and is within the extensibility rules of Diameter > and AAA scope. Coordination with other IETF working groups and other > SDOs (e.g. 3GPP) will be used to ensure this. > > Goals and Milestones: > > Done - Submit the following two Diameter Mobility documents to the > IESG for consideration as a Proposed Standards:* 'Diameter > Mobile IPv6: Support for Home Agent to Diameter Server > Interaction' * 'Diameter Mobile IPv6: Support for Network > Access Server to Diameter Server Interaction' > Done - Submit 'Diameter API' to the IESG for consideration as an > Informational RFC > Done - Submit 'Quality of Service Parameters for Usage with > Diameter' to the IESG for consideration as a Proposed > Standard. > Done - Submit 'Diameter QoS Application' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Support for EAP Re-authentication > Protocol' as DIME working group item > Done - Submit 'Diameter User-Name and Realm Based Request Routing > Clarifications' as DIME working group item > Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group > item > Done - Submit 'Quality of Service Attributes for Diameter' to the > IESG for consideration as a Proposed Standard > Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter User-Name and Realm Based Request Routing > Clarifications' to the IESG for consideration as a = Proposed > Standard > Done - Submit 'Diameter NAT Control Application' as DIME working > group item > Done - Submit 'Diameter Capabilities Update' as DIME working group > item > Done - Submit 'Diameter Credit Control Application MIB' to the > IESG for consideration as an Informational RFC > Done - Submit 'Diameter Base Protocol MIB' to the IESG for > consideration as an Informational RFC > Done - Submit 'Diameter Capabilities Update' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Extended NAPTR' as DIME working group item > Done - Submit 'Realm-Based Redirection In Diameter' as DIME > working group item > Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized > Routing' as DIME working group item > Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic > Key Transport' as DIME working group item > Done - Submit 'Diameter Priority Attribute Value Pairs' as DIME > working group item > Done - Submit 'Diameter IKEv2 PSK' as DIME working group item > Done - Submit Revision of 'Diameter Base Protocol' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Attribute-Value Pairs for Cryptographic > Key Transport' to the IESG for consideration as a Proposed > Standard > Done - Submit 'Diameter Priority Attribute Value Pairs' to the > IESG for consideration as a Proposed Standard > Done - Submit Revision of 'Diameter Network Access Server > Application - RFC 4005bis' as DIME working group item > Done - Submit 'Diameter NAT Control Application' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter IKEv2 PSK' to the IESG for consideration > as a Proposed Standard > Done - Submit 'Diameter Extended NAPTR' to the IESG for > consideration as a Proposed Standard > Done - Submit 'Diameter Support for Proxy Mobile IPv6 Localized > Routing' to the IESG for consideration as a Proposed > Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the IESG > for consideration as a Proposed Standard > Mar 2012 - Submit Revision of 'Diameter Network Access Server > Application - RFC 4005bis' to the IESG for consideration = as a > Proposed Standard > May 2012 - Submit 'Diameter Application Design Guidelines' to the IESG > for consideration as a BCP document Standard > Jul 2012 - Submit 'Diameter Support for EAP Re-authentication > Protocol' to the IESG for consideration as a Proposed > Standard > Aug 2012 - Submit a document on 'Protocol extension for bulk and group > signaling' as a working group item > Aug 2013 - Submit a document on 'Protocol extension for bulk and group > signaling' to the IESG for consideration as a Proposed > Standard > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From malcolm.betts@zte.com.cn Thu Jan 12 09:17:53 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793AF21F8568; Thu, 12 Jan 2012 09:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 95WIMx9gHXRL; Thu, 12 Jan 2012 09:17:52 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDD221F8559; Thu, 12 Jan 2012 09:17:51 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 566901107637492; Fri, 13 Jan 2012 00:55:58 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 4315.4635944796; Fri, 13 Jan 2012 01:17:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q0CHHYA1076639; Fri, 13 Jan 2012 01:17:34 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn) In-Reply-To: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> To: adrian@olddog.co.uk Subject: Re: Questions about draft-betts-itu-oam-ach-code-point MIME-Version: 1.0 X-KeepSent: 3DDAB338:E71941EB-85257983:005DFB2E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Malcolm.BETTS@zte.com.cn Date: Thu, 12 Jan 2012 12:17:27 -0500 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-01-13 01:17:37, Serialize complete at 2012-01-13 01:17:37 Content-Type: multipart/alternative; boundary="=_alternative 005EFE9085257983_=" X-MAIL: mse01.zte.com.cn q0CHHYA1076639 Cc: ietf-bounces@ietf.org, draft-betts-itu-oam-ach-code-point@tools.ietf.org, ietf@ietf.org, mpls@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 17:17:53 -0000 This is a multipart message in MIME format. --=_alternative 005EFE9085257983_= Content-Type: text/plain; charset="US-ASCII" Hi Adrian, Please see in line below for my response to your questions. I will post a revised version of the draft tomorrow. Regards, Malcolm "Adrian Farrel" Sent by: ietf-bounces@ietf.org 09/12/2011 05:49 AM Please respond to adrian@olddog.co.uk To , "'Huub helvoort'" cc mpls@ietf.org, ietf@ietf.org Subject Questions about draft-betts-itu-oam-ach-code-point Hi Malcolm and Huub, I have squeezed a little time from the current ITU-T meeting to look at your draft and write-up. I have also read the email threads on the IETF discussion list and the MPLS list. Sorry that this has taken me a week to process, but your publication request came at pretty much the worst possible time for getting me to do this task. I don't like proliferating threads across multiple mailing lists. On the other hand it is difficult to ensure that all the constituencies are present, so I am perpetuating the cross-posting. My review of the document... 1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I think only one of these is real (the spurious space in a citation). The other nits are spurious caused by citations wrapping across lines. Could you please keep a note of the nit so that you can fix it the next time the draft is respun or so it can be captured in an RFC Editor Note at a later stage (you don't have to post a new revision to address this now unless you really want to). [MB] OK fixed in the update 2. This document requests a code point from a registry that contains code points that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D whether it is your intention that your code point would also be applicable in both cases. What is your intention? Is this "obvious" from G.8113.1 or does it need to be clarified? [MB] The draft requests a code point to support Ethernet based OAM messages the use of these messages on MPLS-TP LSPs and PWs is described in G.8113.1 other uses are not prohibited by this draft. My review of the write-up and discussions... 3. There seems to be quite a feeling on the mailing lists that this document should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look at the draft, the easiest approach seems to be to redirect the work to the working group. [MB] G.8113.1 supports a subset of the functions defined in draft-bhh-mpls-tp-oam-y1731-08. The -00 version was posted in March 2009, the draft was presented at several meetings in 2009 and early 2010 and had extensive discussion on the MPLS mailing list. However, the MPLS WG have, by rough consensus, adopted a different approach. Therefore, further review by the MPLS WG is of little value. 4. G.8113.1 is clearly important to understanding to which the code point is being put. Thus, an available and stable copy of group. G.8113.1 will be key to the last call review of you I-D. Can you make a stable copy available (for example, through liaison)? How does the editing work currently in progress in the SG15 meeting affect that availability? [MB] The draft is requesting a code point for the version of G.8113.1 that was forwarded to WTSA by SG 15 in December, this is the same as the draft that was determined in February 2011, I am not anticipating any changes prior to the approval decision at WTSA. None of the changes in G.8113.1 that were discussed during the drafting sessions and were anticipated in draft-betts-itu-oam-ach-code-point-01 were implemented, as I stated above I will post a new version draft-betts-itu-oam-ach-code-point to correctly reflect the content and title of G.8113.1 later this week. 5. Can you clarify for me why the suggested value has been suggested. This will help guide IANA who would normally do their allocation in a "tidy" way. [MB] This value corresponds to the Ethertype used for Ethernet OAM Looking forward to your reply. Thanks, Adrian _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --=_alternative 005EFE9085257983_= Content-Type: text/html; charset="US-ASCII" Hi Adrian,

      Please see in line below for my response to your questions.  I will post a revised version of the draft tomorrow.

      Regards,

      Malcolm




      "Adrian Farrel" <adrian@olddog.co.uk>
      Sent by: ietf-bounces@ietf.org

      09/12/2011 05:49 AM
      Please respond to
      adrian@olddog.co.uk
      To
      		<draft-betts-itu-oam-ach-code-point@tools.ietf.org>, "'Huub helvoort'" <huub.van.helvoort@huawei.com>
      cc
      		mpls@ietf.org, ietf@ietf.org
      Subject
      		Questions about draft-betts-itu-oam-ach-code-point





      Hi Malcolm and Huub,

      I have squeezed a little time from the current ITU-T meeting to look at your
      draft and write-up. I have also read the email threads on the IETF discussion
      list and the MPLS list. Sorry that this has taken me a week to process, but your
      publication request came at pretty much the worst possible time for getting me
      to do this task.

      I don't like proliferating threads across multiple mailing lists. On the other
      hand it is difficult to ensure that all the constituencies are present, so I am
      perpetuating the cross-posting.

      My review of the document...

      1. idnits (      http://www.ietf.org/tools/idnits/) shows a couple of nits. I think
      only one of these is real (the spurious space in a citation). The other nits are
      spurious caused by citations wrapping across lines. Could you please keep a note
      of the nit so that you can fix it the next time the draft is respun or so it can
      be captured in an RFC Editor Note at a later stage (you don't have to post a new
      revision to address this now unless you really want to).
      [MB] OK fixed in the update

      2. This document requests a code point from a registry that contains code points
      that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D
      whether it is your intention that your code point would also be applicable in
      both cases. What is your intention? Is this "obvious" from G.8113.1 or does it
      need to be clarified?
      [MB] The draft requests a code point to support Ethernet based OAM messages the use of these messages on MPLS-TP LSPs and PWs is described in G.8113.1 other uses are not prohibited by this draft.

      My review of the write-up and discussions...

      3. There seems to be quite a feeling on the mailing lists that this document
      should be run through the MPLS working group. The write-up makes a case for
      progressing it as AD sponsored. As far as I can see, the main assertions to
      answer are as follows. Do you have a view on these points before I make a
      decision on what to do?

      a. This is a proposal to use an MPLS code point and so is part of MPLS by
      definition.

      b. The type of network being managed by the OAM described in G.8113.1 is an MPLS
      network. Therefore, this is clearly relevant to the MPLS working .

      Do you object to this going through the MPLS on principle, or were you just
      hoping to save the WG the work? If the latter, and if the WG wants to look at
      the draft, the easiest approach seems to be to redirect the work to the working
      group.
      [MB]  G.8113.1 supports a subset of the functions defined in draft-bhh-mpls-tp-oam-y1731-08.  The -00 version was posted in March 2009, the draft was presented at several meetings in 2009 and early 2010 and had extensive discussion on the MPLS mailing list.  However, the MPLS WG have, by rough consensus, adopted a different approach.  Therefore, further review by the MPLS WG is of little value.

      4. G.8113.1 is clearly important to understanding to which the code point is
      being put. Thus, an available and stable copy of group. G.8113.1 will be key to
      the last call review of you I-D. Can you make a stable copy available (for
      example, through liaison)? How does the editing work currently in progress in
      the SG15 meeting affect that availability?
      [MB] The draft is requesting a code point for the version of G.8113.1 that was forwarded to WTSA by SG 15 in December, this is the same as the draft that was determined in February 2011, I am not anticipating any changes prior to the approval decision at WTSA.  None of the changes in G.8113.1 that were discussed during the drafting sessions and were anticipated in draft-betts-itu-oam-ach-code-point-01 were implemented,  as I stated above I will post a new version draft-betts-itu-oam-ach-code-point to correctly reflect the content and title of G.8113.1 later this week.

      5. Can you clarify for me why the suggested value has been suggested. This will
      help guide IANA who would normally do their allocation in a "tidy" way.

      [MB]  This value corresponds to the Ethertype used for Ethernet OAM


      Looking forward to your reply.

      Thanks,
      Adrian

      _______________________________________________
      Ietf mailing list
      Ietf@ietf.org
      https://www.ietf.org/mailman/listinfo/ietf
      --=_alternative 005EFE9085257983_=-- From jdrake@juniper.net Thu Jan 12 12:19:34 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6443121F8685; Thu, 12 Jan 2012 12:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.943 X-Spam-Level: X-Spam-Status: No, score=-3.943 tagged_above=-999 required=5 tests=[AWL=2.655, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 gdvKRKPEHWY2; Thu, 12 Jan 2012 12:19:32 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB9721F85ED; Thu, 12 Jan 2012 12:19:23 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTw9AR0PpZBNSK1TAc1P+WJohw3hmamUx@postini.com; Thu, 12 Jan 2012 12:19:32 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 12 Jan 2012 12:18:03 -0800 From: John E Drake To: "Malcolm.BETTS@zte.com.cn" , "adrian@olddog.co.uk" Date: Thu, 12 Jan 2012 12:18:01 -0800 Subject: RE: Questions about draft-betts-itu-oam-ach-code-point Thread-Topic: Questions about draft-betts-itu-oam-ach-code-point Thread-Index: AczRTigf4fEhMW1tRmCVZffVeuduHQAFXqKg Message-ID: <5E893DB832F57341992548CDBB333163A54CA3676F@EMBX01-HQ.jnpr.net> References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A54CA3676FEMBX01HQjnprn_" MIME-Version: 1.0 Cc: "ietf-bounces@ietf.org" , "draft-betts-itu-oam-ach-code-point@tools.ietf.org" , "ietf@ietf.org" , "mpls@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 20:19:34 -0000 --_000_5E893DB832F57341992548CDBB333163A54CA3676FEMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Snipped, comments inline. 3. There seems to be quite a feeling on the mailing lists that this documen= t should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an= MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look = at the draft, the easiest approach seems to be to redirect the work to the wor= king group. [MB] G.8113.1 supports a subset of the functions defined in draft-bhh-mpls= -tp-oam-y1731-08. The -00 version was posted in March 2009, the draft was = presented at several meetings in 2009 and early 2010 and had extensive disc= ussion on the MPLS mailing list. However, the MPLS WG have, by rough conse= nsus, adopted a different approach. Therefore, further review by the MPLS = WG is of little value. [JD] Um, I don't think so. Since, as you state above, G.8113.1 is effectively draft-bhh and since dra= ft-bhh was explicitly rejected by the MPLS WG, your draft, which requests a= code point for G.8113.1, is basically an attempt to subvert the decision b= y the MPLS WG to reject draft-bhh by attempting to bypass the WG with an in= dividual submission. So, I think it is clear that your draft belongs in the MPLS WG. Incidentally, the MPLS/GMPLS change process was put in place in reaction to= the publication of another individual submission, RFC3474, which was compl= etely non-interoperable with standard RSVP, a surprisingly similar situatio= n. --_000_5E893DB832F57341992548CDBB333163A54CA3676FEMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

      Snipped, comments inline.


      3. There s= eems to be quite a feeling on the mailing lists that this document
      = should be run through the MPLS working group. The write-up makes a case= for
      progressing it as AD sponsored. As far as I can see, the m= ain assertions to
      answer are as follows. Do you have a view on = these points before I make a
      decision on what to do?
      a. This is a proposal to use an MPLS code point and so is part of MPL= S by
      definition.

      b. The type of network being m= anaged by the OAM described in G.8113.1 is an MPLS
      network. The= refore, this is clearly relevant to the MPLS working .

      Do y= ou object to this going through the MPLS on principle, or were you just
      hoping to save the WG the work? If the latter, and if the WG wants= to look at
      the draft, the easiest approach seems to be to redi= rect the work to the working
      group.

      [MB]  G.8113.1 supports a subset of the f= unctions defined in draft-bhh-mpls-tp-oam-y1731-08.  The -00 version w= as posted in March 2009, the draft was presented at several meetings in 200= 9 and early 2010 and had extensive discussion on the MPLS mailing list. &nb= sp;However, the MPLS WG have, by rough consensus, adopted a different appro= ach.  Therefore, further review by the MPLS WG is of little value.

      [JD]   Um, I don̵= 7;t think so. 

      Since, as yo= u state above, G.8113.1 is  effectively draft-bhh and since draft-bhh = was explicitly rejected by the MPLS WG, your draft, which requests a code p= oint for G.8113.1, is basically an attempt to subvert the decision by the M= PLS WG to reject draft-bhh by attempting to bypass the WG with an individua= l submission. 

      So, I think = it  is clear that your draft belongs in the MPLS WG.  =

      <= i>Incidentally, the MPLS/GMPLS change process= was put in place in reaction to the publication of another individual subm= ission, RFC3474, which was completely non-interoperable with standard RSVP,= a surprisingly similar situation.

      = --_000_5E893DB832F57341992548CDBB333163A54CA3676FEMBX01HQjnprn_-- From tnadeau@lucidvision.com Thu Jan 12 12:29:54 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E1411E8083; Thu, 12 Jan 2012 12:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.833 X-Spam-Level: X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599, HTML_MESSAGE=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 HUfMQUxNqqiA; Thu, 12 Jan 2012 12:29:53 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6E411E8072; Thu, 12 Jan 2012 12:29:53 -0800 (PST) Received: from [192.168.1.64] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 00A01204ADF7; Thu, 12 Jan 2012 15:29:52 -0500 (EST) Subject: Re: Questions about draft-betts-itu-oam-ach-code-point Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_EC987B83-5D08-4BE1-926B-7E147D592BDF" From: Thomas Nadeau In-Reply-To: <5E893DB832F57341992548CDBB333163A54CA3676F@EMBX01-HQ.jnpr.net> Date: Thu, 12 Jan 2012 15:29:51 -0500 Message-Id: <61AA59DB-E638-4F20-BDEA-F487337ECE38@lucidvision.com> References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> <5E893DB832F57341992548CDBB333163A54CA3676F@EMBX01-HQ.jnpr.net> To: John E Drake X-Mailer: Apple Mail (2.1251.1) Cc: "mpls@ietf.org" , "draft-betts-itu-oam-ach-code-point@tools.ietf.org" , "ietf@ietf.org" , "ietf-bounces@ietf.org" , "adrian@olddog.co.uk" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 20:29:54 -0000 --Apple-Mail=_EC987B83-5D08-4BE1-926B-7E147D592BDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jan 12, 2012, at 3:18 PM, John E Drake wrote: > Snipped, comments inline. >=20 > 3. There seems to be quite a feeling on the mailing lists that this = document > should be run through the MPLS working group. The write-up makes a = case for > progressing it as AD sponsored. As far as I can see, the main = assertions to > answer are as follows. Do you have a view on these points before I = make a > decision on what to do? >=20 > a. This is a proposal to use an MPLS code point and so is part of MPLS = by > definition. >=20 > b. The type of network being managed by the OAM described in G.8113.1 = is an MPLS > network. Therefore, this is clearly relevant to the MPLS working . >=20 > Do you object to this going through the MPLS on principle, or were you = just > hoping to save the WG the work? If the latter, and if the WG wants to = look at > the draft, the easiest approach seems to be to redirect the work to = the working > group. >=20 > [MB] G.8113.1 supports a subset of the functions defined in = draft-bhh-mpls-tp-oam-y1731-08. The -00 version was posted in March = 2009, the draft was presented at several meetings in 2009 and early 2010 = and had extensive discussion on the MPLS mailing list. However, the = MPLS WG have, by rough consensus, adopted a different approach. = Therefore, further review by the MPLS WG is of little value.=20 >=20 > [JD] Um, I don=92t think so.=20 >=20 > Since, as you state above, G.8113.1 is effectively draft-bhh and = since draft-bhh was explicitly rejected by the MPLS WG, your draft, = which requests a code point for G.8113.1, is basically an attempt to = subvert the decision by the MPLS WG to reject draft-bhh by attempting to = bypass the WG with an individual submission.=20 >=20 > So, I think it is clear that your draft belongs in the MPLS WG.=20 >=20 > Incidentally, the MPLS/GMPLS change process was put in place in = reaction to the publication of another individual submission, RFC3474, = which was completely non-interoperable with standard RSVP, a = surprisingly similar situation. >=20 Well said John. I couldn't have put it any better myself, and so = agree with that statement %100. --Tom --Apple-Mail=_EC987B83-5D08-4BE1-926B-7E147D592BDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
      On Jan 12, 2012, at 3:18 PM, John E = Drake wrote:

      Snipped, comments = inline.


      3. There seems to be quite a feeling on the mailing = lists that this document
      should be run through the MPLS working group. The write-up makes = a case for
      answer = are as follows. Do you have a view on these points before I make = a
      decision on what to = do?

      a. This is a = proposal to use an MPLS code point and so is part of MPLS by
      definition.

      b. The type of network being = managed by the OAM described in G.8113.1 is an MPLS
      network. Therefore, this is = clearly relevant to the MPLS working .

      Do you object to this going = through the MPLS on principle, or were you just
      hoping to save the WG the work? = If the latter, and if the WG wants to look at
      the draft, the easiest approach = seems to be to redirect the work to the working
      group.

       [JD] =   Um, I don=92t think = so. 

      Since, as you = state above, G.8113.1 is  effectively draft-bhh and since draft-bhh = was explicitly rejected by the MPLS WG, your draft, which requests a = code point for G.8113.1, is basically an attempt to subvert the decision = by the MPLS WG to reject draft-bhh by attempting to bypass the WG with = an individual submission. 

      Incidentally, = the MPLS/GMPLS change process was put in place in reaction to the = publication of another individual submission, RFC3474, which was = completely non-interoperable with standard RSVP, a surprisingly similar = situation.

      = Well said John. I couldn't have put it any better myself, and so = agree with that statement %100.

      = --Tom


      = --Apple-Mail=_EC987B83-5D08-4BE1-926B-7E147D592BDF-- From nurit.sprecher@nsn.com Thu Jan 12 12:39:00 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD0A21F86D8; Thu, 12 Jan 2012 12:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 L0Zv+D5fnZD6; Thu, 12 Jan 2012 12:38:58 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB7D21F86D7; Thu, 12 Jan 2012 12:38:56 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q0CKctIq020157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Jan 2012 21:38:55 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q0CKct7e014370; Thu, 12 Jan 2012 21:38:55 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 21:38:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCD16A.336E0F94" Subject: RE: [mpls] Questions about draft-betts-itu-oam-ach-code-point Date: Thu, 12 Jan 2012 21:38:52 +0100 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264051C52A3@DEMUEXC014.nsn-intra.net> In-Reply-To: <61AA59DB-E638-4F20-BDEA-F487337ECE38@lucidvision.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Questions about draft-betts-itu-oam-ach-code-point Thread-Index: AczRaPk52GABdzJgSZm0yu19PmyZjAAACFVg References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk><5E893DB832F57341992548CDBB333163A54CA3676F@EMBX01-HQ.jnpr.net> <61AA59DB-E638-4F20-BDEA-F487337ECE38@lucidvision.com> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Thomas Nadeau" , "John E Drake" X-OriginalArrivalTime: 12 Jan 2012 20:38:55.0243 (UTC) FILETIME=[33C8ADB0:01CCD16A] Cc: mpls@ietf.org, draft-betts-itu-oam-ach-code-point@tools.ietf.org, ietf@ietf.org, ietf-bounces@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 20:39:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCD16A.336E0F94 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I fully agree with John and Tom. G.8113.1 intends to provide an OAM solution for MPLS-TP networks and the discussion on your draft completely belongs in the MPLS WG and also in the PWE3 WG. =20 Two more points: * Malcolm, you say that that the requested code point is not limited to G.8113.1..."other uses are not prohibited by this draft." I think it should be very clear for what exactly use it is requested.=20 * Malcolm, you mention that the value of the code point corresponds to the Ethertype used for Ethernet OAM....are you sure you approached the appropriate organization for the code point you are looking for? It seems that you either need to approach the IEEE and look for an EtherType or simply use PWs to transmit Ethernet OAM.=20 Best regards, Nurit =20 =20 From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Thomas Nadeau Sent: Thursday, January 12, 2012 10:30 PM To: John E Drake Cc: mpls@ietf.org; draft-betts-itu-oam-ach-code-point@tools.ietf.org; ietf@ietf.org; ietf-bounces@ietf.org Subject: Re: [mpls] Questions about draft-betts-itu-oam-ach-code-point =20 =20 On Jan 12, 2012, at 3:18 PM, John E Drake wrote: Snipped, comments inline. 3. There seems to be quite a feeling on the mailing lists that this document should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look at the draft, the easiest approach seems to be to redirect the work to the working group. [MB] G.8113.1 supports a subset of the functions defined in draft-bhh-mpls-tp-oam-y1731-08. The -00 version was posted in March 2009, the draft was presented at several meetings in 2009 and early 2010 and had extensive discussion on the MPLS mailing list. However, the MPLS WG have, by rough consensus, adopted a different approach. Therefore, further review by the MPLS WG is of little value.=20 [JD] Um, I don't think so.=20 Since, as you state above, G.8113.1 is effectively draft-bhh and since draft-bhh was explicitly rejected by the MPLS WG, your draft, which requests a code point for G.8113.1, is basically an attempt to subvert the decision by the MPLS WG to reject draft-bhh by attempting to bypass the WG with an individual submission.=20 So, I think it is clear that your draft belongs in the MPLS WG.=20 Incidentally, the MPLS/GMPLS change process was put in place in reaction to the publication of another individual submission, RFC3474, which was completely non-interoperable with standard RSVP, a surprisingly similar situation. =20 Well said John. I couldn't have put it any better myself, and so agree with that statement %100. =20 --Tom =20 =20 ------_=_NextPart_001_01CCD16A.336E0F94 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

      Hi,

      I fully agree with John and Tom.

      G.8113.1 intends to provide an OAM solution for MPLS-TP networks and = the discussion on your draft completely belongs in the MPLS WG and also = in the PWE3 WG.  

      Two more points:

      ·         = Malcolm, you say that that the requested code point is not limited to G.8113.1..."other uses are not prohibited by = this draft." I think it should be very clear for what exactly use = it is requested.

      ·         = Malcolm, you mention that the value of the code point corresponds to = the Ethertype used for Ethernet OAM....are you sure you approached the = appropriate organization for the code point you are looking for? It = seems that you either need to approach the IEEE and look for an = EtherType or simply use PWs to transmit Ethernet OAM. =

      Best regards,

      Nurit

       

       

      From:= = mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = ext Thomas Nadeau
      Sent: Thursday, January 12, 2012 10:30 = PM
      To: John E Drake
      Cc: mpls@ietf.org; = draft-betts-itu-oam-ach-code-point@tools.ietf.org; ietf@ietf.org; = ietf-bounces@ietf.org
      Subject: Re: [mpls] Questions about = draft-betts-itu-oam-ach-code-point

       

       

      On = Jan 12, 2012, at 3:18 PM, John E Drake wrote:



      Snipped, comments = inline.


      3. There = seems to be quite a feeling on the mailing lists that this = document
      should be run through the MPLS working group. The = write-up makes a case for
      progressing it as AD sponsored. As = far as I can see, the main assertions to
      answer are as = follows. Do you have a view on these points before I make = a
      decision on what to do?

      a. This is a = proposal to use an MPLS code point and so is part of MPLS = by
      definition.

      b. The type of network being = managed by the OAM described in G.8113.1 is an MPLS
      network. = Therefore, this is clearly relevant to the MPLS working = .

      Do you object to this going through the MPLS on = principle, or were you just
      hoping to save the WG the work? = If the latter, and if the WG wants to look at
      the draft, the = easiest approach seems to be to redirect the work to the = working
      group.

      [MB]  G.8113.1 supports a subset of the = functions defined in draft-bhh-mpls-tp-oam-y1731-08.  The -00 = version was posted in March 2009, the draft was presented at several = meetings in 2009 and early 2010 and had extensive discussion on the MPLS = mailing list.  However, the MPLS WG have, by rough consensus, = adopted a different approach.  Therefore, further review by the = MPLS WG is of little value. 

      [JD] =   Um, I don’t think = so. 

      Since, as you state above, G.8113.1 is =  effectively draft-bhh and since draft-bhh was explicitly rejected = by the MPLS WG, your draft, which requests a code point for G.8113.1, is = basically an attempt to subvert the decision by the MPLS WG to reject = draft-bhh by attempting to bypass the WG with an individual = submission. 

      So, I = think it  is clear that your draft belongs in the MPLS = WG. 

      Incidentally, the MPLS/GMPLS change process was = put in place in reaction to the publication of another individual = submission, RFC3474, which was completely non-interoperable with = standard RSVP, a surprisingly similar = situation.

       

              &n= bsp;   Well said John. I couldn't have put it any = better myself, and so agree with that statement = %100.

       

              &n= bsp;   --Tom

       

       

      ------_=_NextPart_001_01CCD16A.336E0F94-- From glenzorn@gmail.com Thu Jan 12 19:34:17 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5828521F859E; Thu, 12 Jan 2012 19:34:17 -0800 (PST) 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 sqNhPfrep1dC; Thu, 12 Jan 2012 19:34:16 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DF0AA21F859B; Thu, 12 Jan 2012 19:34:15 -0800 (PST) Received: by iaae16 with SMTP id e16so3753435iaa.31 for ; Thu, 12 Jan 2012 19:34:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yapoY1WTAXLQYgPnCvtrT4mQLxCYG4XI8uyVSPCDp6A=; b=qXJffjI2sp//fowFfPRBOrTCrENukU4enRrYYCvqgxUsDHcnsEC7+i++3HfsMWfQ5q 2KszR+OzmCcgLi/MkOrkJhKMKJTQ2WiiHIJuKIvqdunNc1SPv5ucTkYzhd8xpPDWlvMM nrJ+C/m+75TEdOZ/1CLlFjiuoPtpK2U/E/cfs= Received: by 10.42.243.2 with SMTP id lk2mr1091229icb.8.1326425655372; Thu, 12 Jan 2012 19:34:15 -0800 (PST) Received: from [192.168.1.98] (ppp-124-122-159-242.revip2.asianet.co.th. [124.122.159.242]) by mx.google.com with ESMTPS id yg2sm4390880igb.1.2012.01.12.19.34.09 (version=SSLv3 cipher=OTHER); Thu, 12 Jan 2012 19:34:13 -0800 (PST) Message-ID: <4F0FA62D.4090808@gmail.com> Date: Fri, 13 Jan 2012 10:34:05 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF-Discussion , jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, iesg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 03:34:17 -0000 On 1/12/2012 7:15 PM, Romascanu, Dan (Dan) wrote: > Hi, > > If a number of hands were raised now and the folks commanding them say > 'we are ready to work on this NOW' I would support including explicit > wording in the charter. Consider my hand raised. If this does not happen until the telechat next > week the current text is good enough to allow interested people to start > working on contributions that can be individual submissions. If these > submissions are consistent enough the WG can add the milestone later in > the charter and adopt the submissions as WG items. > > Dan > > > > > >> -----Original Message----- >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > Of >> Stephen Farrell >> Sent: Thursday, January 12, 2012 2:13 PM >> To: jouni korhonen >> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >> dime@ietf.org; IETF-Discussion; iesg@ietf.org >> Subject: Re: WG Review: Recharter of Diameter Maintenance and >> Extensions (dime) >> >> >> Hi Jouni, >> >> Right, I'm trying to encourage this - I'm not trying >> to make it a gating function for the recharter. Its >> still worth doing though if we can find some victims >> with enough energy:-) >> >> I agree that the current charter text might not need >> to be modified, OTOH, if there were folks who wanted to >> do the work, a milestone might be good. I also agree >> that as of now, that addition is not warranted. >> >> Cheers, >> S >> >> On 01/12/2012 12:08 PM, jouni korhonen wrote: >>> >>> Stephen, >>> >>> This topic raises its head every now and then when a Dime >>> document arrives at IESG ;) Apart from that there has been >>> very little serious public discussion about it recently, >>> for some unknown reason to me. A detail worth pointing out >>> is that the support for the End-to-End security framework >>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been >>> deprecated in RFC3588bis (now in IESG). So we are "free" >>> to start from scratch. >>> >>> If there is enough serious energy and vision for pursuing >>> end-to-end security, I do not see current proposed charter >>> text prohibiting it: >>> >>> "- Maintaining and/or progressing, along the standards track, the >>> Diameter Base protocol and Diameter Applications. This includes >>> extensions to Diameter Base protocol that can be considered as >>> enhanced features or bug fixes." >>> >>> I would argue the end-to-end security is an enhanced feature for >>> Diameter base protocol that fixes a serious bug/flaw in security. >>> On the other hand, if an explicit note is needed about this topic >>> in the charter, I might hesitate to include such in this round. >>> I would first like to see some concrete movement& work around >>> this topic. >>> >>> - Jouni >>> >>> >>> >>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: >>> >>>> >>>> Hi, >>>> >>>> During the IESG internal review of this I asked whether >>>> or not there was interest in trying to tackle end to >>>> end security for AVPs. I do know there is at least some >>>> interest in that but its not clear there's enough to >>>> warrant including it in the re-charter so I said I'd >>>> ask when the recharter went out for review... >>>> >>>> So - anyone interested in DIME solving that problem? >>>> (And willing and able to help do the work of course.) >>>> >>>> As of now, Diameter really only has hop-by-hop security >>>> which is ok in many cases but far from ideal (wearing >>>> my security hat) in some. >>>> >>>> Thanks, >>>> Stephen. >>>> >>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>>>> A modified charter has been submitted for the Diameter Maintenance >> and >>>>> Extensions (dime) working group in the Operations and Management >> Area of >>>>> the IETF. The IESG has not made any determination as yet. The >> modified >>>>> charter is provided below for informational purposes only. Please >> send >>>>> your comments to the IESG mailing list (iesg@ietf.org) by >> Wednesday, >>>>> January 18, 2012. >>>>> >>>>> Diameter Maintenance and Extensions (dime) >>>>> ----------------------------------------- >>>>> Current Status: Active >>>>> >>>>> Last Modified: 2012-01-10 >>>>> >>>>> Chairs: >>>>> Lionel Morand >>>>> Jouni Korhonen >>>>> >>>>> Operations and Management Area Directors: >>>>> Dan Romascanu >>>>> Ronald Bonica >>>>> >>>>> Operations and Management Area Advisor: >>>>> Dan Romascanu >>>>> >>>>> Mailing Lists: >>>>> General Discussion: dime@ietf.org >>>>> To Subscribe: > https://www.ietf.org/mailman/listinfo/dime >>>>> Archive: >>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>>>> >>>>> Description of Working Group: >>>>> >>>>> The Diameter Maintenance and Extensions WG will focus on >> maintenance and >>>>> extensions to the Diameter protocol required to enable its use for >>>>> authentication, authorization, accounting, charging in network >> access, >>>>> provisioning of configuration information within the network, and >> for >>>>> new AAA session management uses within the extensibility rules of >> the >>>>> Diameter base protocol. >>>>> >>>>> The DIME working group plans to address the following items: >>>>> >>>>> - Maintaining and/or progressing, along the standards track, the >>>>> Diameter Base protocol and Diameter Applications. This includes >>>>> extensions to Diameter Base protocol that can be considered as >> enhanced >>>>> features or bug fixes. >>>>> >>>>> - Diameter application design guideline. This document will > provide >>>>> guidelines for design of Diameter extensions. It will detail when >> to >>>>> consider reusing an existing application and when to develop a new >>>>> application. >>>>> >>>>> - Protocol extensions for the management of Diameter entities. > This >> work >>>>> focuses on the standardization of Management Information Bases >> (MIBs) to >>>>> configure Diameter entities (such as the Diameter Base protocol or >>>>> Diameter Credit Control nodes). The usage of other management >> protocols >>>>> for configuring Diameter entities may be future work within the >> group. >>>>> >>>>> - Protocol extensions for bulk and grouped AAA session management. >> The >>>>> aim of this work is to study and standardize a solution for >> handling >>>>> groups of AAA sessions within the Diameter base protocol context. >> The >>>>> solution would define how to identify and handle grouped AAA >> sessions in >>>>> commands and operations. >>>>> >>>>> Additionally, Diameter-based systems require interoperability in >> order >>>>> to work. The working group, along with the AD, will need to >> evaluate any >>>>> potential extensions and require verification that the proposed >>>>> extension is needed, and is within the extensibility rules of >> Diameter >>>>> and AAA scope. Coordination with other IETF working groups and >> other >>>>> SDOs (e.g. 3GPP) will be used to ensure this. >>>>> >>>>> Goals and Milestones: >>>>> >>>>> Done - Submit the following two Diameter Mobility documents to >> the >>>>> IESG for consideration as a Proposed Standards:* >> 'Diameter >>>>> Mobile IPv6: Support for Home Agent to Diameter Server >>>>> Interaction' * 'Diameter Mobile IPv6: Support for >> Network >>>>> Access Server to Diameter Server Interaction' >>>>> Done - Submit 'Diameter API' to the IESG for consideration as >> an >>>>> Informational RFC >>>>> Done - Submit 'Quality of Service Parameters for Usage with >>>>> Diameter' to the IESG for consideration as a Proposed >>>>> Standard. >>>>> Done - Submit 'Diameter QoS Application' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Support for EAP Re-authentication >>>>> Protocol' as DIME working group item >>>>> Done - Submit 'Diameter User-Name and Realm Based Request >> Routing >>>>> Clarifications' as DIME working group item >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working >> group >>>>> item >>>>> Done - Submit 'Quality of Service Attributes for Diameter' to >> the >>>>> IESG for consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter User-Name and Realm Based Request >> Routing >>>>> Clarifications' to the IESG for consideration as a >> Proposed >>>>> Standard >>>>> Done - Submit 'Diameter NAT Control Application' as DIME >> working >>>>> group item >>>>> Done - Submit 'Diameter Capabilities Update' as DIME working >> group >>>>> item >>>>> Done - Submit 'Diameter Credit Control Application MIB' to the >>>>> IESG for consideration as an Informational RFC >>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>>>> consideration as an Informational RFC >>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working group >> item >>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>>>> working group item >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > Localized >>>>> Routing' as DIME working group item >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > Cryptographic >>>>> Key Transport' as DIME working group item >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as > DIME >>>>> working group item >>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item >>>>> Done - Submit Revision of 'Diameter Base Protocol' to the IESG >> for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > Cryptographic >>>>> Key Transport' to the IESG for consideration as a >> Proposed >>>>> Standard >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to the >>>>> IESG for consideration as a Proposed Standard >>>>> Done - Submit Revision of 'Diameter Network Access Server >>>>> Application - RFC 4005bis' as DIME working group item >>>>> Done - Submit 'Diameter NAT Control Application' to the IESG >> for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for >> consideration >>>>> as a Proposed Standard >>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > Localized >>>>> Routing' to the IESG for consideration as a Proposed >>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the > IESG >>>>> for consideration as a Proposed Standard >>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>>>> Application - RFC 4005bis' to the IESG for >> consideration as a >>>>> Proposed Standard >>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to the >> IESG >>>>> for consideration as a BCP document Standard >>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>>>> Protocol' to the IESG for consideration as a Proposed >>>>> Standard >>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and >> group >>>>> signaling' as a working group item >>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and >> group >>>>> signaling' to the IESG for consideration as a Proposed >>>>> Standard >>>>> _______________________________________________ >>>>> IETF-Announce mailing list >>>>> IETF-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>> >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >>> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From rcallon@juniper.net Thu Jan 12 21:48:47 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C3D21F8551; Thu, 12 Jan 2012 21:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.656 X-Spam-Level: X-Spam-Status: No, score=-106.656 tagged_above=-999 required=5 tests=[AWL=-0.057, 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 xWBNWaumuflJ; Thu, 12 Jan 2012 21:48:47 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id EDF2B21F8550; Thu, 12 Jan 2012 21:48:44 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTw/FvAj6/+PlCe+4snfpp0oPoMGMdmO0@postini.com; Thu, 12 Jan 2012 21:48:46 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 12 Jan 2012 21:44:36 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 13 Jan 2012 00:44:36 -0500 From: Ross Callon To: "adrian@olddog.co.uk" Date: Fri, 13 Jan 2012 00:43:42 -0500 Subject: point 3 in... RE: Questions about draft-betts-itu-oam-ach-code-point Thread-Topic: point 3 in... RE: Questions about draft-betts-itu-oam-ach-code-point Thread-Index: Acy2X5y3KbEf1KvoQbCo+WO6uBJnUAbU2KUQ Message-ID: References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> In-Reply-To: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 05:48:48 -0000 > Adrian wrote: > My review of the write-up and discussions... > > 3. There seems to be quite a feeling on the mailing lists that this docum= ent > should be run through the MPLS working group. The write-up makes a case f= or > progressing it as AD sponsored. As far as I can see, the main assertions = to > answer are as follows. Do you have a view on these points before I make a > decision on what to do? > > a. This is a proposal to use an MPLS code point and so is part of MPLS by >definition. > > b. The type of network being managed by the OAM described in G.8113.1 is = an MPLS > network. Therefore, this is clearly relevant to the MPLS working . > > Do you object to this going through the MPLS on principle, or were you ju= st > hoping to save the WG the work? If the latter, and if the WG wants to loo= k at > the draft, the easiest approach seems to be to redirect the work to the w= orking > group. My personal opinion (speaking as an individual)... It is pretty clear that there is a lot of interest in this topic in the MPL= S WG. It also is clear that this proposal is very much about MPLS. Thus dra= ft-betts-itu-oam-ach-code-point needs to be last called in the MPLS WG.=20 It seems clear that the document also needs IETF last call. I assume this m= eans that one last call would be posted to both the MPLS and IETF WG lists.= =20 It seems that this same last call should also be copied to the PWE3 list.=20 Ross From narten@us.ibm.com Thu Jan 12 21:53:09 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A835A21F8576 for ; Thu, 12 Jan 2012 21:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.216 X-Spam-Level: X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 97wZGWOFR0Ew for ; Thu, 12 Jan 2012 21:53:09 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by ietfa.amsl.com (Postfix) with ESMTP id B1F1B21F8577 for ; Thu, 12 Jan 2012 21:53:08 -0800 (PST) Received: from /spool/local by e4.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 13 Jan 2012 00:53:06 -0500 Received: from d01relay03.pok.ibm.com (9.56.227.235) by e4.ny.us.ibm.com (192.168.1.104) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 13 Jan 2012 00:53:04 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q0D5r3Xb300604 for ; Fri, 13 Jan 2012 00:53:03 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q0D5r3Ic002994 for ; Fri, 13 Jan 2012 03:53:03 -0200 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.192.143]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q0D5r3fR002972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Jan 2012 03:53:03 -0200 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id q0D5r2bN002072 for ; Fri, 13 Jan 2012 00:53:02 -0500 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.14.4/8.14.4/Submit) id q0D5r2ek002029 for ietf@ietf.org; Fri, 13 Jan 2012 00:53:02 -0500 From: Thomas Narten Message-Id: <201201130553.q0D5r2ek002029@rotala.raleigh.ibm.com> Date: Fri, 13 Jan 2012 00:53:01 -0500 To: ietf@ietf.org Subject: Weekly posting summary for ietf@ietf.org User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 12011305-3534-0000-0000-0000047D9439 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 05:53:09 -0000 Total of 64 messages in the last 7 days. script run at: Fri Jan 13 00:53:01 EST 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 10.94% | 7 | 8.81% | 59494 | jeanjour@comcast.net 7.81% | 5 | 5.62% | 37937 | sm@resistor.net 1.56% | 1 | 10.11% | 68260 | chalikars@gmail.com 4.69% | 3 | 5.98% | 40367 | nurit.sprecher@nsn.com 4.69% | 3 | 5.08% | 34301 | jouni.nospam@gmail.com 4.69% | 3 | 4.53% | 30557 | david.black@emc.com 4.69% | 3 | 3.55% | 23949 | marshall.eubanks@gmail.com 3.12% | 2 | 5.07% | 34242 | malcolm.betts@zte.com.cn 4.69% | 3 | 3.23% | 21806 | msk@cloudmark.com 3.12% | 2 | 4.57% | 30839 | stephen.farrell@cs.tcd.ie 3.12% | 2 | 3.09% | 20885 | bernard_aboba@hotmail.com 3.12% | 2 | 2.40% | 16232 | scott.mansfield@ericsson.com 3.12% | 2 | 2.34% | 15823 | adrian@olddog.co.uk 3.12% | 2 | 2.07% | 13980 | sustrik@250bpm.com 3.12% | 2 | 2.03% | 13682 | yaakov_s@rad.com 3.12% | 2 | 1.95% | 13190 | dave@cridland.net 3.12% | 2 | 1.91% | 12919 | paul.hoffman@vpnc.org 1.56% | 1 | 2.68% | 18116 | glenzorn@gmail.com 1.56% | 1 | 2.66% | 17952 | gash5107@yahoo.com 1.56% | 1 | 2.62% | 17668 | dromasca@avaya.com 1.56% | 1 | 2.18% | 14702 | lionel.morand@orange.com 1.56% | 1 | 2.05% | 13851 | tnadeau@lucidvision.com 1.56% | 1 | 1.96% | 13242 | ben@nostrum.com 1.56% | 1 | 1.90% | 12829 | jdrake@juniper.net 1.56% | 1 | 1.63% | 11001 | se.pankaj@gmail.com 1.56% | 1 | 1.18% | 7991 | narten@us.ibm.com 1.56% | 1 | 1.16% | 7815 | daedulus@btconnect.com 1.56% | 1 | 1.09% | 7353 | wesley.george@twcable.com 1.56% | 1 | 1.09% | 7337 | mallman@icir.org 1.56% | 1 | 0.99% | 6699 | tglassey@earthlink.net 1.56% | 1 | 0.97% | 6546 | dhc@dcrocker.net 1.56% | 1 | 0.94% | 6374 | housley@vigilsec.com 1.56% | 1 | 0.87% | 5894 | scott@kitterman.com 1.56% | 1 | 0.84% | 5638 | joelja@bogus.com 1.56% | 1 | 0.83% | 5572 | randy_presuhn@mindspring.com --------+------+--------+----------+------------------------ 100.00% | 64 |100.00% | 675043 | Total From dromasca@avaya.com Thu Jan 12 22:16:06 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25CA21F85FC; Thu, 12 Jan 2012 22:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.263 X-Spam-Level: X-Spam-Status: No, score=-103.263 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, 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 o15cqaSs1rjD; Thu, 12 Jan 2012 22:16:05 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id D9FC021F85F9; Thu, 12 Jan 2012 22:16:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsEFABbKD0+HCzI1/2dsb2JhbAA4Cp5ighSMG4EFgXIBAQEBAwEBAQ8IAhEDPgsMBAIBCA0EBAEBAQoCBAwEAQYBBgEgBh8JCAEBBBMIARIHh2CbYJsdiGCCWmMEiAiSeIUEh0c X-IronPort-AV: E=Sophos;i="4.71,502,1320642000"; d="scan'208,217";a="286029901" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Jan 2012 01:16:00 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Jan 2012 01:02:44 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCD1BA.D0A60F87" Subject: RE: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) Date: Fri, 13 Jan 2012 07:14:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) Thread-Index: AczRpDrqi4QXYP6KTl22emwkgS5qzgAFmPVY References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> <4F0FA62D.4090808@gmail.com> From: "Romascanu, Dan (Dan)" To: "Glen Zorn" Cc: IETF-Discussion , jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, iesg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 06:16:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCD1BA.D0A60F87 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks, Glen! Can we see (at least) a couple of more hands from people = willing to participate in the editing of this document?=20 Dan -----Original Message----- From: Glen Zorn [mailto:glenzorn@gmail.com] Sent: Fri 1/13/2012 5:34 AM To: Romascanu, Dan (Dan) Cc: Stephen Farrell; jouni korhonen; jouni.korhonen@nsn.com; = lionel.morand@orange-ftgroup.com; dime@ietf.org; IETF-Discussion; = iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and = Extensions (dime) =20 On 1/12/2012 7:15 PM, Romascanu, Dan (Dan) wrote: > Hi, >=20 > If a number of hands were raised now and the folks commanding them say > 'we are ready to work on this NOW' I would support including explicit > wording in the charter.=20 Consider my hand raised. If this does not happen until the telechat next > week the current text is good enough to allow interested people to = start > working on contributions that can be individual submissions. If these > submissions are consistent enough the WG can add the milestone later = in > the charter and adopt the submissions as WG items.=20 >=20 > Dan >=20 >=20 >=20 >=20 >=20 >> -----Original Message----- >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > Of >> Stephen Farrell >> Sent: Thursday, January 12, 2012 2:13 PM >> To: jouni korhonen >> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >> dime@ietf.org; IETF-Discussion; iesg@ietf.org >> Subject: Re: WG Review: Recharter of Diameter Maintenance and >> Extensions (dime) >> >> >> Hi Jouni, >> >> Right, I'm trying to encourage this - I'm not trying >> to make it a gating function for the recharter. Its >> still worth doing though if we can find some victims >> with enough energy:-) >> >> I agree that the current charter text might not need >> to be modified, OTOH, if there were folks who wanted to >> do the work, a milestone might be good. I also agree >> that as of now, that addition is not warranted. >> >> Cheers, >> S >> >> On 01/12/2012 12:08 PM, jouni korhonen wrote: >>> >>> Stephen, >>> >>> This topic raises its head every now and then when a Dime >>> document arrives at IESG ;) Apart from that there has been >>> very little serious public discussion about it recently, >>> for some unknown reason to me. A detail worth pointing out >>> is that the support for the End-to-End security framework >>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been >>> deprecated in RFC3588bis (now in IESG). So we are "free" >>> to start from scratch. >>> >>> If there is enough serious energy and vision for pursuing >>> end-to-end security, I do not see current proposed charter >>> text prohibiting it: >>> >>> "- Maintaining and/or progressing, along the standards track, the >>> Diameter Base protocol and Diameter Applications. This includes >>> extensions to Diameter Base protocol that can be considered as >>> enhanced features or bug fixes." >>> >>> I would argue the end-to-end security is an enhanced feature for >>> Diameter base protocol that fixes a serious bug/flaw in security. >>> On the other hand, if an explicit note is needed about this topic >>> in the charter, I might hesitate to include such in this round. >>> I would first like to see some concrete movement& work around >>> this topic. >>> >>> - Jouni >>> >>> >>> >>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: >>> >>>> >>>> Hi, >>>> >>>> During the IESG internal review of this I asked whether >>>> or not there was interest in trying to tackle end to >>>> end security for AVPs. I do know there is at least some >>>> interest in that but its not clear there's enough to >>>> warrant including it in the re-charter so I said I'd >>>> ask when the recharter went out for review... >>>> >>>> So - anyone interested in DIME solving that problem? >>>> (And willing and able to help do the work of course.) >>>> >>>> As of now, Diameter really only has hop-by-hop security >>>> which is ok in many cases but far from ideal (wearing >>>> my security hat) in some. >>>> >>>> Thanks, >>>> Stephen. >>>> >>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>>>> A modified charter has been submitted for the Diameter Maintenance >> and >>>>> Extensions (dime) working group in the Operations and Management >> Area of >>>>> the IETF. The IESG has not made any determination as yet. The >> modified >>>>> charter is provided below for informational purposes only. Please >> send >>>>> your comments to the IESG mailing list (iesg@ietf.org) by >> Wednesday, >>>>> January 18, 2012. >>>>> >>>>> Diameter Maintenance and Extensions (dime) >>>>> ----------------------------------------- >>>>> Current Status: Active >>>>> >>>>> Last Modified: 2012-01-10 >>>>> >>>>> Chairs: >>>>> Lionel Morand >>>>> Jouni Korhonen >>>>> >>>>> Operations and Management Area Directors: >>>>> Dan Romascanu >>>>> Ronald Bonica >>>>> >>>>> Operations and Management Area Advisor: >>>>> Dan Romascanu >>>>> >>>>> Mailing Lists: >>>>> General Discussion: dime@ietf.org >>>>> To Subscribe: > https://www.ietf.org/mailman/listinfo/dime >>>>> Archive: >>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>>>> >>>>> Description of Working Group: >>>>> >>>>> The Diameter Maintenance and Extensions WG will focus on >> maintenance and >>>>> extensions to the Diameter protocol required to enable its use for >>>>> authentication, authorization, accounting, charging in network >> access, >>>>> provisioning of configuration information within the network, and >> for >>>>> new AAA session management uses within the extensibility rules of >> the >>>>> Diameter base protocol. >>>>> >>>>> The DIME working group plans to address the following items: >>>>> >>>>> - Maintaining and/or progressing, along the standards track, the >>>>> Diameter Base protocol and Diameter Applications. This includes >>>>> extensions to Diameter Base protocol that can be considered as >> enhanced >>>>> features or bug fixes. >>>>> >>>>> - Diameter application design guideline. This document will > provide >>>>> guidelines for design of Diameter extensions. It will detail when >> to >>>>> consider reusing an existing application and when to develop a new >>>>> application. >>>>> >>>>> - Protocol extensions for the management of Diameter entities. > This >> work >>>>> focuses on the standardization of Management Information Bases >> (MIBs) to >>>>> configure Diameter entities (such as the Diameter Base protocol or >>>>> Diameter Credit Control nodes). The usage of other management >> protocols >>>>> for configuring Diameter entities may be future work within the >> group. >>>>> >>>>> - Protocol extensions for bulk and grouped AAA session management. >> The >>>>> aim of this work is to study and standardize a solution for >> handling >>>>> groups of AAA sessions within the Diameter base protocol context. >> The >>>>> solution would define how to identify and handle grouped AAA >> sessions in >>>>> commands and operations. >>>>> >>>>> Additionally, Diameter-based systems require interoperability in >> order >>>>> to work. The working group, along with the AD, will need to >> evaluate any >>>>> potential extensions and require verification that the proposed >>>>> extension is needed, and is within the extensibility rules of >> Diameter >>>>> and AAA scope. Coordination with other IETF working groups and >> other >>>>> SDOs (e.g. 3GPP) will be used to ensure this. >>>>> >>>>> Goals and Milestones: >>>>> >>>>> Done - Submit the following two Diameter Mobility documents to >> the >>>>> IESG for consideration as a Proposed Standards:* >> 'Diameter >>>>> Mobile IPv6: Support for Home Agent to Diameter Server >>>>> Interaction' * 'Diameter Mobile IPv6: Support for >> Network >>>>> Access Server to Diameter Server Interaction' >>>>> Done - Submit 'Diameter API' to the IESG for consideration as >> an >>>>> Informational RFC >>>>> Done - Submit 'Quality of Service Parameters for Usage with >>>>> Diameter' to the IESG for consideration as a Proposed >>>>> Standard. >>>>> Done - Submit 'Diameter QoS Application' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Support for EAP Re-authentication >>>>> Protocol' as DIME working group item >>>>> Done - Submit 'Diameter User-Name and Realm Based Request >> Routing >>>>> Clarifications' as DIME working group item >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working >> group >>>>> item >>>>> Done - Submit 'Quality of Service Attributes for Diameter' to >> the >>>>> IESG for consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter User-Name and Realm Based Request >> Routing >>>>> Clarifications' to the IESG for consideration as a >> Proposed >>>>> Standard >>>>> Done - Submit 'Diameter NAT Control Application' as DIME >> working >>>>> group item >>>>> Done - Submit 'Diameter Capabilities Update' as DIME working >> group >>>>> item >>>>> Done - Submit 'Diameter Credit Control Application MIB' to the >>>>> IESG for consideration as an Informational RFC >>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>>>> consideration as an Informational RFC >>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working group >> item >>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>>>> working group item >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > Localized >>>>> Routing' as DIME working group item >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > Cryptographic >>>>> Key Transport' as DIME working group item >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as > DIME >>>>> working group item >>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item >>>>> Done - Submit Revision of 'Diameter Base Protocol' to the IESG >> for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > Cryptographic >>>>> Key Transport' to the IESG for consideration as a >> Proposed >>>>> Standard >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to the >>>>> IESG for consideration as a Proposed Standard >>>>> Done - Submit Revision of 'Diameter Network Access Server >>>>> Application - RFC 4005bis' as DIME working group item >>>>> Done - Submit 'Diameter NAT Control Application' to the IESG >> for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for >> consideration >>>>> as a Proposed Standard >>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > Localized >>>>> Routing' to the IESG for consideration as a Proposed >>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the > IESG >>>>> for consideration as a Proposed Standard >>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>>>> Application - RFC 4005bis' to the IESG for >> consideration as a >>>>> Proposed Standard >>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to the >> IESG >>>>> for consideration as a BCP document Standard >>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>>>> Protocol' to the IESG for consideration as a Proposed >>>>> Standard >>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and >> group >>>>> signaling' as a working group item >>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and >> group >>>>> signaling' to the IESG for consideration as a Proposed >>>>> Standard >>>>> _______________________________________________ >>>>> IETF-Announce mailing list >>>>> IETF-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>> >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >>> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01CCD1BA.D0A60F87 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Dime] WG Review: Recharter of Diameter Maintenance and = Extensions (dime)

      Thanks, Glen! Can we see (at least) a couple of more = hands from people willing to participate in the editing of this = document?

      Dan



      -----Original Message-----
      From: Glen Zorn [mailto:glenzorn@gmail.com]
      Sent: Fri 1/13/2012 5:34 AM
      To: Romascanu, Dan (Dan)
      Cc: Stephen Farrell; jouni korhonen; jouni.korhonen@nsn.com; = lionel.morand@orange-ftgroup.com; dime@ietf.org; IETF-Discussion; = iesg@ietf.org
      Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and = Extensions (dime)

      On 1/12/2012 7:15 PM, Romascanu, Dan (Dan) wrote:
      > Hi,
      >
      > If a number of hands were raised now and the folks commanding them = say
      > 'we are ready to work on this NOW' I would support including = explicit
      > wording in the charter.

      Consider my hand raised.

      If this does not happen until the telechat next
      > week the current text is good enough to allow interested people to = start
      > working on contributions that can be individual submissions. If = these
      > submissions are consistent enough the WG can add the milestone = later in
      > the charter and adopt the submissions as WG items.
      >
      > Dan
      >
      >
      >
      >
      >
      >> -----Original Message-----
      >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] = On Behalf
      > Of
      >> Stephen Farrell
      >> Sent: Thursday, January 12, 2012 2:13 PM
      >> To: jouni korhonen
      >> Cc: jouni.korhonen@nsn.com; = lionel.morand@orange-ftgroup.com;
      >> dime@ietf.org; IETF-Discussion; iesg@ietf.org
      >> Subject: Re: WG Review: Recharter of Diameter Maintenance = and
      >> Extensions (dime)
      >>
      >>
      >> Hi Jouni,
      >>
      >> Right, I'm trying to encourage this - I'm not trying
      >> to make it a gating function for the recharter. Its
      >> still worth doing though if we can find some victims
      >> with enough energy:-)
      >>
      >> I agree that the current charter text might not need
      >> to be modified, OTOH, if there were folks who wanted to
      >> do the work, a milestone might be good. I also agree
      >> that as of now, that addition is not warranted.
      >>
      >> Cheers,
      >> S
      >>
      >> On 01/12/2012 12:08 PM, jouni korhonen wrote:
      >>>
      >>> Stephen,
      >>>
      >>> This topic raises its head every now and then when a = Dime
      >>> document arrives at IESG ;) Apart from that there has = been
      >>> very little serious public discussion about it = recently,
      >>> for some unknown reason to me. A detail worth pointing = out
      >>> is that the support for the End-to-End security = framework
      >>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has = been
      >>> deprecated in RFC3588bis (now in IESG). So we are = "free"
      >>> to start from scratch.
      >>>
      >>> If there is enough serious energy and vision for = pursuing
      >>> end-to-end security, I do not see current proposed = charter
      >>> text prohibiting it:
      >>>
      >>> "- Maintaining and/or progressing, along the standards = track, the
      >>>     Diameter Base protocol and Diameter = Applications. This includes
      >>>     extensions to Diameter Base = protocol that can be considered as
      >>>     enhanced features or bug = fixes."
      >>>
      >>> I would argue the end-to-end security is an enhanced = feature for
      >>> Diameter base protocol that fixes a serious bug/flaw in = security.
      >>> On the other hand, if an explicit note is needed about this = topic
      >>> in the charter, I might hesitate to include such in this = round.
      >>> I would first like to see some concrete movement&  = work around
      >>> this topic.
      >>>
      >>> - Jouni
      >>>
      >>>
      >>>
      >>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote:
      >>>
      >>>>
      >>>> Hi,
      >>>>
      >>>> During the IESG internal review of this I asked = whether
      >>>> or not there was interest in trying to tackle end = to
      >>>> end security for AVPs. I do know there is at least = some
      >>>> interest in that but its not clear there's enough = to
      >>>> warrant including it in the re-charter so I said = I'd
      >>>> ask when the recharter went out for review...
      >>>>
      >>>> So - anyone interested in DIME solving that = problem?
      >>>> (And willing and able to help do the work of = course.)
      >>>>
      >>>> As of now, Diameter really only has hop-by-hop = security
      >>>> which is ok in many cases but far from ideal = (wearing
      >>>> my security hat) in some.
      >>>>
      >>>> Thanks,
      >>>> Stephen.
      >>>>
      >>>> On 01/11/2012 04:37 PM, IESG Secretary wrote:
      >>>>> A modified charter has been submitted for the = Diameter Maintenance
      >> and
      >>>>> Extensions (dime) working group in the Operations = and Management
      >> Area of
      >>>>> the IETF.  The IESG has not made any = determination as yet.  The
      >> modified
      >>>>> charter is provided below for informational = purposes only.  Please
      >> send
      >>>>> your comments to the IESG mailing list = (iesg@ietf.org) by
      >> Wednesday,
      >>>>> January 18, 2012.
      >>>>>
      >>>>> Diameter Maintenance and Extensions (dime)
      >>>>> -----------------------------------------
      >>>>> Current Status: Active
      >>>>>
      >>>>> Last Modified: 2012-01-10
      >>>>>
      >>>>> Chairs:
      >>>>>      Lionel = Morand<lionel.morand@orange-ftgroup.com>
      >>>>>      Jouni = Korhonen<jouni.korhonen@nsn.com>
      >>>>>
      >>>>> Operations and Management Area Directors:
      >>>>>      Dan = Romascanu<dromasca@avaya.com>
      >>>>>      Ronald = Bonica<rbonica@juniper.net>
      >>>>>
      >>>>> Operations and Management Area Advisor:
      >>>>>      Dan = Romascanu<dromasca@avaya.com>
      >>>>>
      >>>>> Mailing Lists:
      >>>>>      General Discussion: = dime@ietf.org
      >>>>>      To Subscribe:
      > https://www.ietf.org/= mailman/listinfo/dime
      >>>>>      Archive:
      >>>>> = http://www.ietf.org/mail-archive/web/dime/current/maillist.html
      >>>>>
      >>>>> Description of Working Group:
      >>>>>
      >>>>> The Diameter Maintenance and Extensions WG will = focus on
      >> maintenance and
      >>>>> extensions to the Diameter protocol required to = enable its use for
      >>>>> authentication, authorization, accounting, charging = in network
      >> access,
      >>>>> provisioning of configuration information within = the network, and
      >> for
      >>>>> new AAA session management uses within the = extensibility rules of
      >> the
      >>>>> Diameter base protocol.
      >>>>>
      >>>>> The DIME working group plans to address the = following items:
      >>>>>
      >>>>> - Maintaining and/or progressing, along the = standards track, the
      >>>>> Diameter Base protocol and Diameter Applications. = This includes
      >>>>> extensions to Diameter Base protocol that can be = considered as
      >> enhanced
      >>>>> features or bug fixes.
      >>>>>
      >>>>> - Diameter application design guideline. This = document will
      > provide
      >>>>> guidelines for design of Diameter extensions. It = will detail when
      >> to
      >>>>> consider reusing an existing application and when = to develop a new
      >>>>> application.
      >>>>>
      >>>>> - Protocol extensions for the management of = Diameter entities.
      > This
      >> work
      >>>>> focuses on the standardization of Management = Information Bases
      >> (MIBs) to
      >>>>> configure Diameter entities (such as the Diameter = Base protocol or
      >>>>> Diameter Credit Control nodes). The usage of other = management
      >> protocols
      >>>>> for configuring Diameter entities may be future = work within the
      >> group.
      >>>>>
      >>>>> - Protocol extensions for bulk and grouped AAA = session management.
      >> The
      >>>>> aim of this work is to study and standardize a = solution for
      >> handling
      >>>>> groups of AAA sessions within the Diameter base = protocol context.
      >> The
      >>>>> solution would define how to identify and handle = grouped AAA
      >> sessions in
      >>>>> commands and operations.
      >>>>>
      >>>>> Additionally, Diameter-based systems require = interoperability in
      >> order
      >>>>> to work. The working group, along with the AD, will = need to
      >> evaluate any
      >>>>> potential extensions and require verification that = the proposed
      >>>>> extension is needed, and is within the = extensibility rules of
      >> Diameter
      >>>>> and AAA scope. Coordination with other IETF working = groups and
      >> other
      >>>>> SDOs (e.g. 3GPP) will be used to ensure this.
      >>>>>
      >>>>> Goals and Milestones:
      >>>>>
      >>>>> Done     - Submit the following = two Diameter Mobility documents to
      >> the
      >>>>>         = ;    IESG for consideration as a Proposed Standards:*
      >> 'Diameter
      >>>>>         = ;    Mobile IPv6: Support for Home Agent to Diameter = Server
      >>>>>         = ;    Interaction' * 'Diameter Mobile IPv6: Support = for
      >> Network
      >>>>>         = ;    Access Server to Diameter Server Interaction'
      >>>>> Done     - Submit 'Diameter = API' to the IESG for consideration as
      >> an
      >>>>>         = ;    Informational RFC
      >>>>> Done     - Submit 'Quality of = Service Parameters for Usage with
      >>>>>         = ;    Diameter' to the IESG for consideration as a = Proposed
      >>>>>         = ;    Standard.
      >>>>> Done     - Submit 'Diameter QoS = Application' to the IESG for
      >>>>>         = ;    consideration as a Proposed Standard
      >>>>> Done     - Submit 'Diameter = Support for EAP Re-authentication
      >>>>>         = ;    Protocol' as DIME working group item
      >>>>> Done     - Submit 'Diameter = User-Name and Realm Based Request
      >> Routing
      >>>>>         = ;    Clarifications' as DIME working group item
      >>>>> Done     - Submit 'Diameter = Proxy Mobile IPv6' as DIME working
      >> group
      >>>>>         = ;    item
      >>>>> Done     - Submit 'Quality of = Service Attributes for Diameter' to
      >> the
      >>>>>         = ;    IESG for consideration as a Proposed Standard
      >>>>> Done     - Submit 'Diameter = Proxy Mobile IPv6' to the IESG for
      >>>>>         = ;    consideration as a Proposed Standard
      >>>>> Done     - Submit 'Diameter = User-Name and Realm Based Request
      >> Routing
      >>>>>         = ;    Clarifications' to the IESG for consideration as = a
      >> Proposed
      >>>>>         = ;    Standard
      >>>>> Done     - Submit 'Diameter NAT = Control Application' as DIME
      >> working
      >>>>>         = ;    group item
      >>>>> Done     - Submit 'Diameter = Capabilities Update' as DIME working
      >> group
      >>>>>         = ;    item
      >>>>> Done     - Submit 'Diameter = Credit Control Application MIB' to the
      >>>>>         = ;    IESG for consideration as an Informational RFC
      >>>>> Done     - Submit 'Diameter = Base Protocol MIB' to the IESG for
      >>>>>         = ;    consideration as an Informational RFC
      >>>>> Done     - Submit 'Diameter = Capabilities Update' to the IESG for
      >>>>>         = ;    consideration as a Proposed Standard
      >>>>> Done     - Submit 'Diameter = Extended NAPTR' as DIME working group
      >> item
      >>>>> Done     - Submit 'Realm-Based = Redirection In Diameter' as DIME
      >>>>>         = ;    working group item
      >>>>> Done     - Submit 'Diameter = Support for Proxy Mobile IPv6
      > Localized
      >>>>>         = ;    Routing' as DIME working group item
      >>>>> Done     - Submit 'Diameter = Attribute-Value Pairs for
      > Cryptographic
      >>>>>         = ;    Key Transport' as DIME working group item
      >>>>> Done     - Submit 'Diameter = Priority Attribute Value Pairs' as
      > DIME
      >>>>>         = ;    working group item
      >>>>> Done     - Submit 'Diameter = IKEv2 PSK' as DIME working group item
      >>>>> Done     - Submit Revision of = 'Diameter Base Protocol' to the IESG
      >> for
      >>>>>         = ;    consideration as a Proposed Standard
      >>>>> Done     - Submit 'Diameter = Attribute-Value Pairs for
      > Cryptographic
      >>>>>         = ;    Key Transport' to the IESG for consideration as = a
      >> Proposed
      >>>>>         = ;    Standard
      >>>>> Done     - Submit 'Diameter = Priority Attribute Value Pairs' to the
      >>>>>         = ;    IESG for consideration as a Proposed Standard
      >>>>> Done     - Submit Revision of = 'Diameter Network Access Server
      >>>>>         = ;    Application - RFC 4005bis' as DIME working group = item
      >>>>> Done     - Submit 'Diameter NAT = Control Application' to the IESG
      >> for
      >>>>>         = ;    consideration as a Proposed Standard
      >>>>> Done     - Submit 'Diameter = IKEv2 PSK' to the IESG for
      >> consideration
      >>>>>         = ;    as a Proposed Standard
      >>>>> Done     - Submit 'Diameter = Extended NAPTR' to the IESG for
      >>>>>         = ;    consideration as a Proposed Standard
      >>>>> Done     - Submit 'Diameter = Support for Proxy Mobile IPv6
      > Localized
      >>>>>         = ;    Routing' to the IESG for consideration as a = Proposed
      >>>>> Mar 2012 - Submit 'Realm-Based Redirection In = Diameter' to the
      > IESG
      >>>>>         = ;    for consideration as a Proposed Standard
      >>>>> Mar 2012 - Submit Revision of 'Diameter Network = Access Server
      >>>>>         = ;    Application - RFC 4005bis' to the IESG for
      >> consideration as a
      >>>>>         = ;    Proposed Standard
      >>>>> May 2012 - Submit 'Diameter Application Design = Guidelines' to the
      >> IESG
      >>>>>         = ;    for consideration as a BCP document Standard
      >>>>> Jul 2012 - Submit 'Diameter Support for EAP = Re-authentication
      >>>>>         = ;    Protocol' to the IESG for consideration as a = Proposed
      >>>>>         = ;    Standard
      >>>>> Aug 2012 - Submit a document on 'Protocol extension = for bulk and
      >> group
      >>>>>         = ;    signaling' as a working group item
      >>>>> Aug 2013 - Submit a document on 'Protocol extension = for bulk and
      >> group
      >>>>>         = ;    signaling' to the IESG for consideration as a = Proposed
      >>>>>         = ;    Standard
      >>>>> _______________________________________________
      >>>>> IETF-Announce mailing list
      >>>>> IETF-Announce@ietf.org
      >>>>> https://www.= ietf.org/mailman/listinfo/ietf-announce
      >>>>>
      >>>> _______________________________________________
      >>>> Ietf mailing list
      >>>> Ietf@ietf.org
      >>>> https://www.ietf.org/= mailman/listinfo/ietf
      >>>
      > _______________________________________________
      > DiME mailing list
      > DiME@ietf.org
      > https://www.ietf.org/= mailman/listinfo/dime

      ------_=_NextPart_001_01CCD1BA.D0A60F87-- From ron.even.tlv@gmail.com Thu Jan 12 23:20:25 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251AB21F84D7; Thu, 12 Jan 2012 23:20:25 -0800 (PST) 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=[AWL=0.000, 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 rNs6z1fujk16; Thu, 12 Jan 2012 23:20:24 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4D5A21F84CD; Thu, 12 Jan 2012 23:20:22 -0800 (PST) Received: by eeit10 with SMTP id t10so22335eei.31 for ; Thu, 12 Jan 2012 23:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=MTzSjehSdqJWkFmzv7sEq65Kjbz2vcphhWhbeNQWGLk=; b=fFnyTSGfYIgx53SYS5JGuMSM3GlhWQXPmg/tI/a2IT8Agv9eZo/ZQfPaRYWLyhhSAN KJO/LGnie6UrhTR637jYOMmjEIjgSqdpGbdj9tRXbbpQsC5o+UBN5ZL9yuXq5/qCGuwe NmkO6Lf8eX8isFPGQyNj/3qy9aswObFftwcd4= Received: by 10.213.32.208 with SMTP id e16mr338191ebd.145.1326439221792; Thu, 12 Jan 2012 23:20:21 -0800 (PST) Received: from windows8d787f9 (bzq-79-180-198-96.red.bezeqint.net. [79.180.198.96]) by mx.google.com with ESMTPS id x43sm25934136eef.8.2012.01.12.23.20.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jan 2012 23:20:19 -0800 (PST) From: "Roni Even" To: "'Kireeti Kompella'" References: <4e6757ab.87c5e30a.061b.0446@mx.google.com> In-Reply-To: Subject: RE: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 Date: Fri, 13 Jan 2012 09:16:51 +0200 Message-ID: <4f0fdb33.c3630e0a.7550.fffff20b@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-Index: Acx0phniNB2Aj/ikRoOGlEj3bxY2RRdHP47g Cc: draft-kompella-l2vpn-l2vpn.all@tools.ietf.org, gen-art@ietf.org, 'IETF-Discussion list' X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 07:20:25 -0000 Hi, I looked at the 08 version and the major issues are addressed. What about minor issue number 3? Roni Even > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Friday, September 16, 2011 10:23 PM > To: Roni Even > Cc: Kireeti Kompella; draft-kompella-l2vpn-l2vpn.all@tools.ietf.org; > gen-art@ietf.org; IETF-Discussion list > Subject: Re: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 > > Hi Roni, > > On Sep 7, 2011, at 4:37 , Roni Even wrote: > > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . > > Thanks! > > > Please resolve these comments along with any other Last Call comments > you may receive. > > > > Document: draft-kompella-l2vpn-l2vpn-07 > > Reviewer: Roni Even > > Review Date: 2011-9-7 > > IETF LC End Date: 2011-9-27 > > IESG Telechat date: > > > > Summary: This draft is not ready for publication as an informational > RFC. > > > > Major issues: > > > > The IANA considerations section says: > > "the values already allocated are in Table 1 of Section 4. The > allocation policy for new entries up to and including value 127 is > "Standards Action". The allocation policy for values 128 through 251 > is "First Come First Served". The values from 252 through 255 are for > "Experimental Use"." > > Standards Action will be changed to Expert Review. > > > Yet this is document is intended for Informational status which > contradict the standard action. This is also true for the second > registry defined. > > > > Is this document really an Informational one? > > My only comment is that it is not Historic. > > > Minor issues: > > > > 1. In section 1.2.2 "Since "traditional" Layer 2 VPNs (i.e., > real Frame Relay circuits connecting sites) are indistinguishable from > tunnel-based VPNs from the customer's point-of-view, migrating from > one to the other raises few issues." What are the few issues? > > A subtlety: "few issues" means not many, not deep; it's a careful way > of saying, "just about no issues". "A few issues" would require > elaboration. > > > 2. In section 4 "L2VPN TLVs can be added to extend the > information carried in the NLRI, using the format shown in Figure 2". > How is the TLV carried in the NLRI, in which field, section 4.1 only > talk about the structure of the TLV. > > I'll take the figure from 3.2.2 of RFC 4761 and show where the TLVs go. > > > 3. Section 4.2 refers to section 4 but I am not sure where this > mechanism in section 4 is. > > Will clarify. > > > > > > > > > > > > > Nits/editorial comments: > > > > 1. Section 3.1 is called network topology but the whole text is > an example of a network topology. Maybe the title should be "Example of > a network toplogy". > > Sure. > > > 2. Section 5 starts with "As defined so far in the document .." > But the using IP only is already discussed in previous sections. > > Do you have a suggestion for rewording? > > Thanks, > Kireeti. > > > > > > > > From stbryant@cisco.com Fri Jan 13 01:27:18 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB5921F85AD; Fri, 13 Jan 2012 01:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.641 X-Spam-Level: X-Spam-Status: No, score=-110.641 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ZbU04yYXGfyM; Fri, 13 Jan 2012 01:27:18 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C222F21F851A; Fri, 13 Jan 2012 01:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=3894; q=dns/txt; s=iport; t=1326446838; x=1327656438; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=9Q47+TbWj4/vpCVTBKCOCybivfHwd1r1uwrq9YOT/wE=; b=fl/KJ7O1Bmx4JuwvYIPIAe9zC391qE8LgzF+YvWltoNZakw/Ejd3IIPr QwEUQSuzMak4ThRHiXrHV4tjhj9CTM/rp0B3jYm7+YzoNKdZ44SpPYPbp Hfg3CW9hH1vqU6yuHlWf9PJUMrk5p9VOliELateV/88gZbtMGSzyvDfo+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8FAIz4D0+Q/khR/2dsb2JhbABCnmSOL4EFgXIBAQEDAQEBAQ8BAgFYCgEFBwQPDQMBAgoWDwkDAgECARUoCAYBDAEFAgEBHodYCJkCAYMyDwGaWIwdBJUOkjw X-IronPort-AV: E=Sophos;i="4.71,503,1320624000"; d="scan'208,217";a="126320142" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 13 Jan 2012 09:27:16 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0D9RBQe025948; Fri, 13 Jan 2012 09:27:14 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q0D9RAiG022309; Fri, 13 Jan 2012 09:27:10 GMT Message-ID: <4F0FF8F2.2080108@cisco.com> Date: Fri, 13 Jan 2012 09:27:14 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: sidr@ietf.org, IETF Discussion Subject: draft-ietf-sidr-rpki-rtr-24.txt References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/alternative; boundary="------------010405050304030109080003" Cc: draft-ietf-sidr-rpki-rtr@tools.ietf.org, "sidr-chairs@tools.ietf.org" , sec-ads@tools.ietf.org, "rtg-ads@tools.ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 09:27:19 -0000 This is a multi-part message in MIME format. --------------010405050304030109080003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I believe that version 24 addresses all of the actionable comments that the authors have received and I propose to continue with the publication process by requesting IESG review. Stewart -------- Original Message -------- Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-24.txt Date: Thu, 12 Jan 2012 17:33:22 -0800 From: Randy Bush To: internet-drafts@ietf.org CC: sidr@ietf.org this draft a result of helpful security and routing ad reviews > Title : The RPKI/Router Protocol > Author(s) : Randy Bush > Rob Austein > Filename : draft-ietf-sidr-rpki-rtr-24.txt > Pages : 25 > Date : 2012-01-12 and the tasty bit tools neglects to tell the wg Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-rtr-24 randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --------------010405050304030109080003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I believe that version 24 addresses all of the actionable
      comments that the authors have received and I propose
      to continue with the publication process by requesting IESG
      review.

      Stewart


      -------- Original Message --------
      Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-24.txt
      Date: Thu, 12 Jan 2012 17:33:22 -0800
      From: Randy Bush <randy@psg.com>
      To: internet-drafts@ietf.org
      CC: sidr@ietf.org 


      this draft a result of helpful security and routing ad reviews

> 	Title           : The RPKI/Router Protocol
> 	Author(s)       : Randy Bush
>                         Rob Austein
> 	Filename        : draft-ietf-sidr-rpki-rtr-24.txt
> 	Pages           : 25
> 	Date            : 2012-01-12

and the tasty bit tools neglects to tell the wg

Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-rtr-24

randy
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
      --------------010405050304030109080003-- From loa@pi.nu Fri Jan 13 02:46:35 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3040521F8547; Fri, 13 Jan 2012 02:46:35 -0800 (PST) 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 6Qr-AfgQ6Dh3; Fri, 13 Jan 2012 02:46:34 -0800 (PST) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 8618321F853F; Fri, 13 Jan 2012 02:46:34 -0800 (PST) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 64DC251401F; Fri, 13 Jan 2012 11:46:32 +0100 (CET) Message-ID: <4F100B87.7000905@pi.nu> Date: Fri, 13 Jan 2012 11:46:31 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "ietf@ietf.org" Subject: Re: [mpls] point 3 in... RE: Questions about draft-betts-itu-oam-ach-code-point References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "adrian@olddog.co.uk" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 10:46:35 -0000 All (taking chair hat off), I agree with Ross's comments below that if the document is last called it should go through a wg last call (pwe3 and mpls) and through an IETF last call. I agree that these last calls could be in parallel is necessary, but I believe that running the wg last call first and the IETF last call would be beneficial. Given that we have a stable document with stable references to last call. /Loa On 2012-01-13 06:43, Ross Callon wrote: >> Adrian wrote: >> My review of the write-up and discussions... >> >> 3. There seems to be quite a feeling on the mailing lists that this document >> should be run through the MPLS working group. The write-up makes a case for >> progressing it as AD sponsored. As far as I can see, the main assertions to >> answer are as follows. Do you have a view on these points before I make a >> decision on what to do? >> >> a. This is a proposal to use an MPLS code point and so is part of MPLS by >> definition. >> >> b. The type of network being managed by the OAM described in G.8113.1 is an MPLS >> network. Therefore, this is clearly relevant to the MPLS working . >> >> Do you object to this going through the MPLS on principle, or were you just >> hoping to save the WG the work? If the latter, and if the WG wants to look at >> the draft, the easiest approach seems to be to redirect the work to the working >> group. > > My personal opinion (speaking as an individual)... > > It is pretty clear that there is a lot of interest in this topic in the MPLS WG. It also is clear that this proposal is very much about MPLS. Thus draft-betts-itu-oam-ach-code-point needs to be last called in the MPLS WG. > > It seems clear that the document also needs IETF last call. I assume this means that one last call would be posted to both the MPLS and IETF WG lists. > > It seems that this same last call should also be copied to the PWE3 list. > > Ross > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From agmalis@gmail.com Fri Jan 13 02:58:41 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5082321F85F1; Fri, 13 Jan 2012 02:58:41 -0800 (PST) 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 cr2P6ztzYa6I; Fri, 13 Jan 2012 02:58:40 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7747421F8565; Fri, 13 Jan 2012 02:58:40 -0800 (PST) Received: by qcsc1 with SMTP id c1so234103qcs.31 for ; Fri, 13 Jan 2012 02:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=pKZzjJ5xHHCDs1650CJJDWBj3iS31Y38YZw2pUoyn+I=; b=UG+lNakycHtApIhEzcUyq7wUf/hBNO/gA/00+Sqhx6inuXEjmFEVKFBm7GbK9C0XdW jH/EV0vX3I5Bo7fcS+RTedFvocz89AS694H9zqoanQ+uq3l1UHq1+Dfah0KK9HXn9MPz vAM7zh9fzbwbemchAYPgvcxK4yjtIbmy/aDW8= Received: by 10.229.136.70 with SMTP id q6mr66498qct.137.1326452317260; Fri, 13 Jan 2012 02:58:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.84.130 with HTTP; Fri, 13 Jan 2012 02:58:16 -0800 (PST) In-Reply-To: <4F100B87.7000905@pi.nu> References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk> <4F100B87.7000905@pi.nu> From: "Andrew G. Malis" Date: Fri, 13 Jan 2012 05:58:16 -0500 Message-ID: Subject: Re: [mpls] point 3 in... RE: Questions about draft-betts-itu-oam-ach-code-point To: Loa Andersson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , pwe3@ietf.org, "ietf@ietf.org" , "adrian@olddog.co.uk" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 10:58:41 -0000 Also taking my chair hat off ... as Malcolm stated that G.8113.1 applies to PWs, and the requested allocation is in a registry that originated in the PWE3 working group, I agree that a PWE3 WG last call is warranted. This could certainly take place in parallel with the MPLS WG last call. Cheers, Andy On Fri, Jan 13, 2012 at 5:46 AM, Loa Andersson wrote: > All (taking chair hat off), > > I agree with Ross's comments below that if the document is last called > it should go through a wg last call (pwe3 and mpls) and through an IETF > last call. > > I agree that these last calls could be in parallel is necessary, but I > believe that running the wg last call first and the IETF last call would > be beneficial. Given that we have a stable document with stable > references to last call. > > /Loa > > > > On 2012-01-13 06:43, Ross Callon wrote: >>> >>> Adrian wrote: >>> My review of the write-up and discussions... >>> >>> 3. There seems to be quite a feeling on the mailing lists that this >>> document >>> should be run through the MPLS working group. The write-up makes a case >>> for >>> progressing it as AD sponsored. As far as I can see, the main assertion= s >>> to >>> answer are as follows. Do you have a view on these points before I make= a >>> decision on what to do? >>> >>> a. This is a proposal to use an MPLS code point and so is part of MPLS = by >>> definition. >>> >>> b. The type of network being managed by the OAM described in G.8113.1 i= s >>> an MPLS >>> network. Therefore, this is clearly relevant to the MPLS working . >>> >>> Do you object to this going through the MPLS on principle, or were you >>> just >>> hoping to save the WG the work? If the latter, and if the WG wants to >>> look at >>> the draft, the easiest approach seems to be to redirect the work to the >>> working >>> group. >> >> >> My personal opinion (speaking as an individual)... >> >> It is pretty clear that there is a lot of interest in this topic in the > > MPLS WG. It also is clear that this proposal is very much about MPLS. > Thus draft-betts-itu-oam-ach-code-point needs to be last called in the MP= LS > WG. >> >> >> It seems clear that the document also needs IETF last call. I assume thi= s > > means that one last call would be posted to both the MPLS and IETF WG lis= ts. >> >> >> It seems that this same last call should also be copied to the PWE3 list= . >> >> Ross >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls > > > -- > > > Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.= andersson@ericsson.com > Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu > Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +4= 6 10 717 52 13 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +46 767 72 92 13 > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From glenzorn@gmail.com Fri Jan 13 04:23:25 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C229B21F8599; Fri, 13 Jan 2012 04:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=0.327, 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 qVY-ZvVdPjpK; Fri, 13 Jan 2012 04:23:24 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 608D621F84DE; Fri, 13 Jan 2012 04:23:24 -0800 (PST) Received: by iaae16 with SMTP id e16so4496576iaa.31 for ; Fri, 13 Jan 2012 04:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uQWT4ib+X6+DaX+BHau+6291+W1quzhUPmxF6zk1Mcc=; b=RKmdNMSdiEVM0+TYx4rfpRvBMAvY57tFwJULlnEIjFH9vsb/6HyJJI+A4R5aJyFYUl Z6nNGV5+Y6ByiIpDOKg3MLV7YgEKlR5hK9vsPWPrNH8iDoLl0HzI0RWkYckUW816ZNzK PP+SxO+jt+x6U5VQ0b9KF2B6GA08WfDrpM0v4= Received: by 10.42.73.138 with SMTP id s10mr455913icj.38.1326457401649; Fri, 13 Jan 2012 04:23:21 -0800 (PST) Received: from [192.168.1.98] (ppp-124-122-159-242.revip2.asianet.co.th. [124.122.159.242]) by mx.google.com with ESMTPS id x18sm28514120ibi.2.2012.01.13.04.23.16 (version=SSLv3 cipher=OTHER); Fri, 13 Jan 2012 04:23:20 -0800 (PST) Message-ID: <4F102230.1000905@gmail.com> Date: Fri, 13 Jan 2012 19:23:12 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> <4F0FA62D.4090808@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF-Discussion , jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, iesg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 12:23:25 -0000 On 1/13/2012 1:14 PM, Romascanu, Dan (Dan) wrote: > Thanks, Glen! Can we see (at least) a couple of more hands from people > willing to participate in the editing of this document? Personally, I think that one editor is enough ;-). I think that we could use some people providing technical expertise, though... > > Dan > > > > -----Original Message----- > From: Glen Zorn [mailto:glenzorn@gmail.com] > Sent: Fri 1/13/2012 5:34 AM > To: Romascanu, Dan (Dan) > Cc: Stephen Farrell; jouni korhonen; jouni.korhonen@nsn.com; > lionel.morand@orange-ftgroup.com; dime@ietf.org; IETF-Discussion; > iesg@ietf.org > Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and > Extensions (dime) > > On 1/12/2012 7:15 PM, Romascanu, Dan (Dan) wrote: >> Hi, >> >> If a number of hands were raised now and the folks commanding them say >> 'we are ready to work on this NOW' I would support including explicit >> wording in the charter. > > Consider my hand raised. > > If this does not happen until the telechat next >> week the current text is good enough to allow interested people to start >> working on contributions that can be individual submissions. If these >> submissions are consistent enough the WG can add the milestone later in >> the charter and adopt the submissions as WG items. >> >> Dan >> >> >> >> >> >>> -----Original Message----- >>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf >> Of >>> Stephen Farrell >>> Sent: Thursday, January 12, 2012 2:13 PM >>> To: jouni korhonen >>> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >>> dime@ietf.org; IETF-Discussion; iesg@ietf.org >>> Subject: Re: WG Review: Recharter of Diameter Maintenance and >>> Extensions (dime) >>> >>> >>> Hi Jouni, >>> >>> Right, I'm trying to encourage this - I'm not trying >>> to make it a gating function for the recharter. Its >>> still worth doing though if we can find some victims >>> with enough energy:-) >>> >>> I agree that the current charter text might not need >>> to be modified, OTOH, if there were folks who wanted to >>> do the work, a milestone might be good. I also agree >>> that as of now, that addition is not warranted. >>> >>> Cheers, >>> S >>> >>> On 01/12/2012 12:08 PM, jouni korhonen wrote: >>>> >>>> Stephen, >>>> >>>> This topic raises its head every now and then when a Dime >>>> document arrives at IESG ;) Apart from that there has been >>>> very little serious public discussion about it recently, >>>> for some unknown reason to me. A detail worth pointing out >>>> is that the support for the End-to-End security framework >>>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been >>>> deprecated in RFC3588bis (now in IESG). So we are "free" >>>> to start from scratch. >>>> >>>> If there is enough serious energy and vision for pursuing >>>> end-to-end security, I do not see current proposed charter >>>> text prohibiting it: >>>> >>>> "- Maintaining and/or progressing, along the standards track, the >>>> Diameter Base protocol and Diameter Applications. This includes >>>> extensions to Diameter Base protocol that can be considered as >>>> enhanced features or bug fixes." >>>> >>>> I would argue the end-to-end security is an enhanced feature for >>>> Diameter base protocol that fixes a serious bug/flaw in security. >>>> On the other hand, if an explicit note is needed about this topic >>>> in the charter, I might hesitate to include such in this round. >>>> I would first like to see some concrete movement& work around >>>> this topic. >>>> >>>> - Jouni >>>> >>>> >>>> >>>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> During the IESG internal review of this I asked whether >>>>> or not there was interest in trying to tackle end to >>>>> end security for AVPs. I do know there is at least some >>>>> interest in that but its not clear there's enough to >>>>> warrant including it in the re-charter so I said I'd >>>>> ask when the recharter went out for review... >>>>> >>>>> So - anyone interested in DIME solving that problem? >>>>> (And willing and able to help do the work of course.) >>>>> >>>>> As of now, Diameter really only has hop-by-hop security >>>>> which is ok in many cases but far from ideal (wearing >>>>> my security hat) in some. >>>>> >>>>> Thanks, >>>>> Stephen. >>>>> >>>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>>>>> A modified charter has been submitted for the Diameter Maintenance >>> and >>>>>> Extensions (dime) working group in the Operations and Management >>> Area of >>>>>> the IETF. The IESG has not made any determination as yet. The >>> modified >>>>>> charter is provided below for informational purposes only. Please >>> send >>>>>> your comments to the IESG mailing list (iesg@ietf.org) by >>> Wednesday, >>>>>> January 18, 2012. >>>>>> >>>>>> Diameter Maintenance and Extensions (dime) >>>>>> ----------------------------------------- >>>>>> Current Status: Active >>>>>> >>>>>> Last Modified: 2012-01-10 >>>>>> >>>>>> Chairs: >>>>>> Lionel Morand >>>>>> Jouni Korhonen >>>>>> >>>>>> Operations and Management Area Directors: >>>>>> Dan Romascanu >>>>>> Ronald Bonica >>>>>> >>>>>> Operations and Management Area Advisor: >>>>>> Dan Romascanu >>>>>> >>>>>> Mailing Lists: >>>>>> General Discussion: dime@ietf.org >>>>>> To Subscribe: >> https://www.ietf.org/mailman/listinfo/dime >>>>>> Archive: >>>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>>>>> >>>>>> Description of Working Group: >>>>>> >>>>>> The Diameter Maintenance and Extensions WG will focus on >>> maintenance and >>>>>> extensions to the Diameter protocol required to enable its use for >>>>>> authentication, authorization, accounting, charging in network >>> access, >>>>>> provisioning of configuration information within the network, and >>> for >>>>>> new AAA session management uses within the extensibility rules of >>> the >>>>>> Diameter base protocol. >>>>>> >>>>>> The DIME working group plans to address the following items: >>>>>> >>>>>> - Maintaining and/or progressing, along the standards track, the >>>>>> Diameter Base protocol and Diameter Applications. This includes >>>>>> extensions to Diameter Base protocol that can be considered as >>> enhanced >>>>>> features or bug fixes. >>>>>> >>>>>> - Diameter application design guideline. This document will >> provide >>>>>> guidelines for design of Diameter extensions. It will detail when >>> to >>>>>> consider reusing an existing application and when to develop a new >>>>>> application. >>>>>> >>>>>> - Protocol extensions for the management of Diameter entities. >> This >>> work >>>>>> focuses on the standardization of Management Information Bases >>> (MIBs) to >>>>>> configure Diameter entities (such as the Diameter Base protocol or >>>>>> Diameter Credit Control nodes). The usage of other management >>> protocols >>>>>> for configuring Diameter entities may be future work within the >>> group. >>>>>> >>>>>> - Protocol extensions for bulk and grouped AAA session management. >>> The >>>>>> aim of this work is to study and standardize a solution for >>> handling >>>>>> groups of AAA sessions within the Diameter base protocol context. >>> The >>>>>> solution would define how to identify and handle grouped AAA >>> sessions in >>>>>> commands and operations. >>>>>> >>>>>> Additionally, Diameter-based systems require interoperability in >>> order >>>>>> to work. The working group, along with the AD, will need to >>> evaluate any >>>>>> potential extensions and require verification that the proposed >>>>>> extension is needed, and is within the extensibility rules of >>> Diameter >>>>>> and AAA scope. Coordination with other IETF working groups and >>> other >>>>>> SDOs (e.g. 3GPP) will be used to ensure this. >>>>>> >>>>>> Goals and Milestones: >>>>>> >>>>>> Done - Submit the following two Diameter Mobility documents to >>> the >>>>>> IESG for consideration as a Proposed Standards:* >>> 'Diameter >>>>>> Mobile IPv6: Support for Home Agent to Diameter Server >>>>>> Interaction' * 'Diameter Mobile IPv6: Support for >>> Network >>>>>> Access Server to Diameter Server Interaction' >>>>>> Done - Submit 'Diameter API' to the IESG for consideration as >>> an >>>>>> Informational RFC >>>>>> Done - Submit 'Quality of Service Parameters for Usage with >>>>>> Diameter' to the IESG for consideration as a Proposed >>>>>> Standard. >>>>>> Done - Submit 'Diameter QoS Application' to the IESG for >>>>>> consideration as a Proposed Standard >>>>>> Done - Submit 'Diameter Support for EAP Re-authentication >>>>>> Protocol' as DIME working group item >>>>>> Done - Submit 'Diameter User-Name and Realm Based Request >>> Routing >>>>>> Clarifications' as DIME working group item >>>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working >>> group >>>>>> item >>>>>> Done - Submit 'Quality of Service Attributes for Diameter' to >>> the >>>>>> IESG for consideration as a Proposed Standard >>>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>>>>> consideration as a Proposed Standard >>>>>> Done - Submit 'Diameter User-Name and Realm Based Request >>> Routing >>>>>> Clarifications' to the IESG for consideration as a >>> Proposed >>>>>> Standard >>>>>> Done - Submit 'Diameter NAT Control Application' as DIME >>> working >>>>>> group item >>>>>> Done - Submit 'Diameter Capabilities Update' as DIME working >>> group >>>>>> item >>>>>> Done - Submit 'Diameter Credit Control Application MIB' to the >>>>>> IESG for consideration as an Informational RFC >>>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>>>>> consideration as an Informational RFC >>>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>>>>> consideration as a Proposed Standard >>>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working group >>> item >>>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>>>>> working group item >>>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 >> Localized >>>>>> Routing' as DIME working group item >>>>>> Done - Submit 'Diameter Attribute-Value Pairs for >> Cryptographic >>>>>> Key Transport' as DIME working group item >>>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as >> DIME >>>>>> working group item >>>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item >>>>>> Done - Submit Revision of 'Diameter Base Protocol' to the IESG >>> for >>>>>> consideration as a Proposed Standard >>>>>> Done - Submit 'Diameter Attribute-Value Pairs for >> Cryptographic >>>>>> Key Transport' to the IESG for consideration as a >>> Proposed >>>>>> Standard >>>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to the >>>>>> IESG for consideration as a Proposed Standard >>>>>> Done - Submit Revision of 'Diameter Network Access Server >>>>>> Application - RFC 4005bis' as DIME working group item >>>>>> Done - Submit 'Diameter NAT Control Application' to the IESG >>> for >>>>>> consideration as a Proposed Standard >>>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for >>> consideration >>>>>> as a Proposed Standard >>>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>>>>> consideration as a Proposed Standard >>>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 >> Localized >>>>>> Routing' to the IESG for consideration as a Proposed >>>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the >> IESG >>>>>> for consideration as a Proposed Standard >>>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>>>>> Application - RFC 4005bis' to the IESG for >>> consideration as a >>>>>> Proposed Standard >>>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to the >>> IESG >>>>>> for consideration as a BCP document Standard >>>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>>>>> Protocol' to the IESG for consideration as a Proposed >>>>>> Standard >>>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and >>> group >>>>>> signaling' as a working group item >>>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and >>> group >>>>>> signaling' to the IESG for consideration as a Proposed >>>>>> Standard >>>>>> _______________________________________________ >>>>>> IETF-Announce mailing list >>>>>> IETF-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>>> >>>>> _______________________________________________ >>>>> Ietf mailing list >>>>> Ietf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf >>>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > From daedulus@btconnect.com Fri Jan 13 04:48:25 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7896C21F8661 for ; Fri, 13 Jan 2012 04:48:25 -0800 (PST) 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 r81-28C-22Hc for ; Fri, 13 Jan 2012 04:48:24 -0800 (PST) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id 74C8B21F8663 for ; Fri, 13 Jan 2012 04:48:23 -0800 (PST) Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2bthomr09.btconnect.com with SMTP id FXP33846; Fri, 13 Jan 2012 12:48:01 +0000 (GMT) Message-ID: <003b01ccd1e9$510d19e0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "ext Thomas Nadeau" , "John E Drake" References: <015f01ccb660$3991bdb0$acb53910$@olddog.co.uk><5E893DB832F57341992548CDBB333163A54CA3676F@EMBX01-HQ.jnpr.net><61AA59DB-E638-4F20-BDEA-F487337ECE38@lucidvision.com> <077E41CFFD002C4CAB7DFA4386A53264051C52A3@DEMUEXC014.nsn-intra.net> Subject: Re: [mpls] Questions about draft-betts-itu-oam-ach-code-point Date: Fri, 13 Jan 2012 12:48:06 +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-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0303.4F1027FE.00DA, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.11.215414:17:7.944, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __STOCK_PHRASE_7, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, MULTIPLE_RCPTS, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4F102802.0114,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: draft-betts-itu-oam-ach-code-point@tools.ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 12:48:25 -0000 Inline Tom Petch From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Thomas Nadeau Sent: Thursday, January 12, 2012 10:30 PM To: John E Drake Cc: mpls@ietf.org; draft-betts-itu-oam-ach-code-point@tools.ietf.org; ietf@ietf.org; ietf-bounces@ietf.org On Jan 12, 2012, at 3:18 PM, John E Drake wrote: Snipped, comments inline. 3. There seems to be quite a feeling on the mailing lists that this document should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look at the draft, the easiest approach seems to be to redirect the work to the working group. [MB] G.8113.1 supports a subset of the functions defined in draft-bhh-mpls-tp-oam-y1731-08. The -00 version was posted in March 2009, the draft was presented at several meetings in 2009 and early 2010 and had extensive discussion on the MPLS mailing list. However, the MPLS WG have, by rough consensus, adopted a different approach. Therefore, further review by the MPLS WG is of little value. [JD] Um, I don't think so. Since, as you state above, G.8113.1 is effectively draft-bhh and since draft-bhh was explicitly rejected by the MPLS WG, your draft, which requests a code point for G.8113.1, is basically an attempt to subvert the decision by the MPLS WG to reject draft-bhh by attempting to bypass the WG with an individual submission. So, I think it is clear that your draft belongs in the MPLS WG. This I think is the danger of having the MPLS WG review the document. draft-bhh was rejected by the MPLS WG and that is history. Another SDO wants to standardise the technology and, while the IETF may think that that is the wrong approach, that is not our decision. We do however lay claim to control of the code points which would make this technology easier to deploy and that is what this I-D requests. Unless there is some inherent problem in having a code point that invokes a different technology, then there is no reason why we should reject this reasonable request. The risk is that the request for a code point will degenerate into a draft-bhh, now in its G. form, bashing exercise, which can have no positive outcome. We have already decided that draft-bhh is not something we want to standardise, we have already said that having two competing standards is not a good idea (which the current draft recognises); allocating a code point does no more than let the market place decide which approach is better. Tom Petch Incidentally, the MPLS/GMPLS change process was put in place in reaction to the publication of another individual submission, RFC3474, which was completely non-interoperable with standard RSVP, a surprisingly similar situation. Well said John. I couldn't have put it any better myself, and so agree with that statement %100. --Tom From hannes.tschofenig@gmx.net Fri Jan 13 05:01:32 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E7921F8665 for ; Fri, 13 Jan 2012 05:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 sGXX6h1lBb+x for ; Fri, 13 Jan 2012 05:01:31 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id B08AD21F8666 for ; Fri, 13 Jan 2012 05:01:30 -0800 (PST) Received: (qmail invoked by alias); 13 Jan 2012 13:01:25 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.103]) [88.115.216.191] by mail.gmx.net (mp033) with SMTP; 13 Jan 2012 14:01:25 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18yclsqCNUy/t8c6QVzL8HoqEQC9x4/Y2fjd+Ag9Q +vARF5r8mgc+Ch Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4F102230.1000905@gmail.com> Date: Fri, 13 Jan 2012 15:01:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <03BB1E4C-63F2-407C-B36B-B614E5185739@gmx.net> References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> <4F0FA62D.4090808@gmail.com> <4F102230.1000905@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: IETF-Discussion , Jouni Korhonen , Dan Romascanu , Lionel Morand , dime@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 13:01:32 -0000 Regarding end-to-end security: I believe we should separate the = procedure for establishing the keys from the actual protection.=20 I could imagine a couple of different ways to establish the keys.=20 Does that sound reasonable? On Jan 13, 2012, at 2:23 PM, Glen Zorn wrote: > On 1/13/2012 1:14 PM, Romascanu, Dan (Dan) wrote: >=20 >> Thanks, Glen! Can we see (at least) a couple of more hands from = people >> willing to participate in the editing of this document? >=20 > Personally, I think that one editor is enough ;-). I think that we > could use some people providing technical expertise, though... >=20 >>=20 >> Dan >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Glen Zorn [mailto:glenzorn@gmail.com] >> Sent: Fri 1/13/2012 5:34 AM >> To: Romascanu, Dan (Dan) >> Cc: Stephen Farrell; jouni korhonen; jouni.korhonen@nsn.com; >> lionel.morand@orange-ftgroup.com; dime@ietf.org; IETF-Discussion; >> iesg@ietf.org >> Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and >> Extensions (dime) >>=20 >> On 1/12/2012 7:15 PM, Romascanu, Dan (Dan) wrote: >>> Hi, >>>=20 >>> If a number of hands were raised now and the folks commanding them = say >>> 'we are ready to work on this NOW' I would support including = explicit >>> wording in the charter. >>=20 >> Consider my hand raised. >>=20 >> If this does not happen until the telechat next >>> week the current text is good enough to allow interested people to = start >>> working on contributions that can be individual submissions. If = these >>> submissions are consistent enough the WG can add the milestone later = in >>> the charter and adopt the submissions as WG items. >>>=20 >>> Dan >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On = Behalf >>> Of >>>> Stephen Farrell >>>> Sent: Thursday, January 12, 2012 2:13 PM >>>> To: jouni korhonen >>>> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >>>> dime@ietf.org; IETF-Discussion; iesg@ietf.org >>>> Subject: Re: WG Review: Recharter of Diameter Maintenance and >>>> Extensions (dime) >>>>=20 >>>>=20 >>>> Hi Jouni, >>>>=20 >>>> Right, I'm trying to encourage this - I'm not trying >>>> to make it a gating function for the recharter. Its >>>> still worth doing though if we can find some victims >>>> with enough energy:-) >>>>=20 >>>> I agree that the current charter text might not need >>>> to be modified, OTOH, if there were folks who wanted to >>>> do the work, a milestone might be good. I also agree >>>> that as of now, that addition is not warranted. >>>>=20 >>>> Cheers, >>>> S >>>>=20 >>>> On 01/12/2012 12:08 PM, jouni korhonen wrote: >>>>>=20 >>>>> Stephen, >>>>>=20 >>>>> This topic raises its head every now and then when a Dime >>>>> document arrives at IESG ;) Apart from that there has been >>>>> very little serious public discussion about it recently, >>>>> for some unknown reason to me. A detail worth pointing out >>>>> is that the support for the End-to-End security framework >>>>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been >>>>> deprecated in RFC3588bis (now in IESG). So we are "free" >>>>> to start from scratch. >>>>>=20 >>>>> If there is enough serious energy and vision for pursuing >>>>> end-to-end security, I do not see current proposed charter >>>>> text prohibiting it: >>>>>=20 >>>>> "- Maintaining and/or progressing, along the standards track, the >>>>> Diameter Base protocol and Diameter Applications. This includes >>>>> extensions to Diameter Base protocol that can be considered as >>>>> enhanced features or bug fixes." >>>>>=20 >>>>> I would argue the end-to-end security is an enhanced feature for >>>>> Diameter base protocol that fixes a serious bug/flaw in security. >>>>> On the other hand, if an explicit note is needed about this topic >>>>> in the charter, I might hesitate to include such in this round. >>>>> I would first like to see some concrete movement& work around >>>>> this topic. >>>>>=20 >>>>> - Jouni >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: >>>>>=20 >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> During the IESG internal review of this I asked whether >>>>>> or not there was interest in trying to tackle end to >>>>>> end security for AVPs. I do know there is at least some >>>>>> interest in that but its not clear there's enough to >>>>>> warrant including it in the re-charter so I said I'd >>>>>> ask when the recharter went out for review... >>>>>>=20 >>>>>> So - anyone interested in DIME solving that problem? >>>>>> (And willing and able to help do the work of course.) >>>>>>=20 >>>>>> As of now, Diameter really only has hop-by-hop security >>>>>> which is ok in many cases but far from ideal (wearing >>>>>> my security hat) in some. >>>>>>=20 >>>>>> Thanks, >>>>>> Stephen. >>>>>>=20 >>>>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>>>>>> A modified charter has been submitted for the Diameter = Maintenance >>>> and >>>>>>> Extensions (dime) working group in the Operations and Management >>>> Area of >>>>>>> the IETF. The IESG has not made any determination as yet. The >>>> modified >>>>>>> charter is provided below for informational purposes only. = Please >>>> send >>>>>>> your comments to the IESG mailing list (iesg@ietf.org) by >>>> Wednesday, >>>>>>> January 18, 2012. >>>>>>>=20 >>>>>>> Diameter Maintenance and Extensions (dime) >>>>>>> ----------------------------------------- >>>>>>> Current Status: Active >>>>>>>=20 >>>>>>> Last Modified: 2012-01-10 >>>>>>>=20 >>>>>>> Chairs: >>>>>>> Lionel Morand >>>>>>> Jouni Korhonen >>>>>>>=20 >>>>>>> Operations and Management Area Directors: >>>>>>> Dan Romascanu >>>>>>> Ronald Bonica >>>>>>>=20 >>>>>>> Operations and Management Area Advisor: >>>>>>> Dan Romascanu >>>>>>>=20 >>>>>>> Mailing Lists: >>>>>>> General Discussion: dime@ietf.org >>>>>>> To Subscribe: >>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> Archive: >>>>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>>>>>>=20 >>>>>>> Description of Working Group: >>>>>>>=20 >>>>>>> The Diameter Maintenance and Extensions WG will focus on >>>> maintenance and >>>>>>> extensions to the Diameter protocol required to enable its use = for >>>>>>> authentication, authorization, accounting, charging in network >>>> access, >>>>>>> provisioning of configuration information within the network, = and >>>> for >>>>>>> new AAA session management uses within the extensibility rules = of >>>> the >>>>>>> Diameter base protocol. >>>>>>>=20 >>>>>>> The DIME working group plans to address the following items: >>>>>>>=20 >>>>>>> - Maintaining and/or progressing, along the standards track, the >>>>>>> Diameter Base protocol and Diameter Applications. This includes >>>>>>> extensions to Diameter Base protocol that can be considered as >>>> enhanced >>>>>>> features or bug fixes. >>>>>>>=20 >>>>>>> - Diameter application design guideline. This document will >>> provide >>>>>>> guidelines for design of Diameter extensions. It will detail = when >>>> to >>>>>>> consider reusing an existing application and when to develop a = new >>>>>>> application. >>>>>>>=20 >>>>>>> - Protocol extensions for the management of Diameter entities. >>> This >>>> work >>>>>>> focuses on the standardization of Management Information Bases >>>> (MIBs) to >>>>>>> configure Diameter entities (such as the Diameter Base protocol = or >>>>>>> Diameter Credit Control nodes). The usage of other management >>>> protocols >>>>>>> for configuring Diameter entities may be future work within the >>>> group. >>>>>>>=20 >>>>>>> - Protocol extensions for bulk and grouped AAA session = management. >>>> The >>>>>>> aim of this work is to study and standardize a solution for >>>> handling >>>>>>> groups of AAA sessions within the Diameter base protocol = context. >>>> The >>>>>>> solution would define how to identify and handle grouped AAA >>>> sessions in >>>>>>> commands and operations. >>>>>>>=20 >>>>>>> Additionally, Diameter-based systems require interoperability in >>>> order >>>>>>> to work. The working group, along with the AD, will need to >>>> evaluate any >>>>>>> potential extensions and require verification that the proposed >>>>>>> extension is needed, and is within the extensibility rules of >>>> Diameter >>>>>>> and AAA scope. Coordination with other IETF working groups and >>>> other >>>>>>> SDOs (e.g. 3GPP) will be used to ensure this. >>>>>>>=20 >>>>>>> Goals and Milestones: >>>>>>>=20 >>>>>>> Done - Submit the following two Diameter Mobility documents = to >>>> the >>>>>>> IESG for consideration as a Proposed Standards:* >>>> 'Diameter >>>>>>> Mobile IPv6: Support for Home Agent to Diameter = Server >>>>>>> Interaction' * 'Diameter Mobile IPv6: Support for >>>> Network >>>>>>> Access Server to Diameter Server Interaction' >>>>>>> Done - Submit 'Diameter API' to the IESG for consideration = as >>>> an >>>>>>> Informational RFC >>>>>>> Done - Submit 'Quality of Service Parameters for Usage with >>>>>>> Diameter' to the IESG for consideration as a Proposed >>>>>>> Standard. >>>>>>> Done - Submit 'Diameter QoS Application' to the IESG for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Support for EAP Re-authentication >>>>>>> Protocol' as DIME working group item >>>>>>> Done - Submit 'Diameter User-Name and Realm Based Request >>>> Routing >>>>>>> Clarifications' as DIME working group item >>>>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working >>>> group >>>>>>> item >>>>>>> Done - Submit 'Quality of Service Attributes for Diameter' = to >>>> the >>>>>>> IESG for consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter User-Name and Realm Based Request >>>> Routing >>>>>>> Clarifications' to the IESG for consideration as a >>>> Proposed >>>>>>> Standard >>>>>>> Done - Submit 'Diameter NAT Control Application' as DIME >>>> working >>>>>>> group item >>>>>>> Done - Submit 'Diameter Capabilities Update' as DIME working >>>> group >>>>>>> item >>>>>>> Done - Submit 'Diameter Credit Control Application MIB' to = the >>>>>>> IESG for consideration as an Informational RFC >>>>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>>>>>> consideration as an Informational RFC >>>>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working = group >>>> item >>>>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>>>>>> working group item >>>>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 >>> Localized >>>>>>> Routing' as DIME working group item >>>>>>> Done - Submit 'Diameter Attribute-Value Pairs for >>> Cryptographic >>>>>>> Key Transport' as DIME working group item >>>>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as >>> DIME >>>>>>> working group item >>>>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group = item >>>>>>> Done - Submit Revision of 'Diameter Base Protocol' to the = IESG >>>> for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Attribute-Value Pairs for >>> Cryptographic >>>>>>> Key Transport' to the IESG for consideration as a >>>> Proposed >>>>>>> Standard >>>>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to = the >>>>>>> IESG for consideration as a Proposed Standard >>>>>>> Done - Submit Revision of 'Diameter Network Access Server >>>>>>> Application - RFC 4005bis' as DIME working group item >>>>>>> Done - Submit 'Diameter NAT Control Application' to the IESG >>>> for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for >>>> consideration >>>>>>> as a Proposed Standard >>>>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 >>> Localized >>>>>>> Routing' to the IESG for consideration as a Proposed >>>>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the >>> IESG >>>>>>> for consideration as a Proposed Standard >>>>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>>>>>> Application - RFC 4005bis' to the IESG for >>>> consideration as a >>>>>>> Proposed Standard >>>>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to = the >>>> IESG >>>>>>> for consideration as a BCP document Standard >>>>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>>>>>> Protocol' to the IESG for consideration as a Proposed >>>>>>> Standard >>>>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and >>>> group >>>>>>> signaling' as a working group item >>>>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and >>>> group >>>>>>> signaling' to the IESG for consideration as a = Proposed >>>>>>> Standard >>>>>>> _______________________________________________ >>>>>>> IETF-Announce mailing list >>>>>>> IETF-Announce@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>>>>=20 >>>>>> _______________________________________________ >>>>>> Ietf mailing list >>>>>> Ietf@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ietf >>>>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From bill.wu@huawei.com Thu Jan 12 22:40:04 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E644D21F84E2; Thu, 12 Jan 2012 22:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 khbkF+T5aY8j; Thu, 12 Jan 2012 22:40:01 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 369F321F849B; Thu, 12 Jan 2012 22:40:01 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXQ004HV56EMI@szxga03-in.huawei.com>; Fri, 13 Jan 2012 14:39:51 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LXQ0089956ETZ@szxga03-in.huawei.com>; Fri, 13 Jan 2012 14:39:50 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGK56535; Fri, 13 Jan 2012 14:39:49 +0800 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Jan 2012 14:39:38 +0800 Received: from w53375q (10.138.41.130) by szxeml421-hub.china.huawei.com (10.82.67.160) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 13 Jan 2012 14:39:38 +0800 Date: Fri, 13 Jan 2012 14:39:37 +0800 From: Qin Wu Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance andExtensions (dime) X-Originating-IP: [10.138.41.130] To: "Romascanu, Dan (Dan)" , Glen Zorn Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: multipart/alternative; boundary="Boundary_(ID_CJ0OBoOpPYNtfrO0+8V4aQ)" X-Priority: 3 X-MSMail-priority: Normal X-CFilter-Loop: Reflected References: <20120111163717.591B021F87EF@ietfa.amsl.com> <4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> <4F0FA62D.4090808@gmail.com> X-Mailman-Approved-At: Fri, 13 Jan 2012 09:31:23 -0800 Cc: IETF-Discussion , jouni.korhonen@nsn.com, lionel.morand@orange-ftgroup.com, dime@ietf.org, iesg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 06:40:04 -0000 --Boundary_(ID_CJ0OBoOpPYNtfrO0+8V4aQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT RE: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime)Count me. I remember there was an initial individual submission from Glen and me regarding end to end security topic. http://tools.ietf.org/html/draft-zorn-dime-n2n-sec-lite-01 unfortunetely not finished due to lacking energy in the last year . This may serve as a good input to this topic although more input are needed. Regards! -Qin ----- Original Message ----- From: Romascanu, Dan (Dan) To: Glen Zorn Cc: IETF-Discussion ; jouni.korhonen@nsn.com ; lionel.morand@orange-ftgroup.com ; dime@ietf.org ; iesg@ietf.org ; Stephen Farrell Sent: Friday, January 13, 2012 2:14 PM Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance andExtensions (dime) Thanks, Glen! Can we see (at least) a couple of more hands from people willing to participate in the editing of this document? Dan -----Original Message----- From: Glen Zorn [mailto:glenzorn@gmail.com] Sent: Fri 1/13/2012 5:34 AM To: Romascanu, Dan (Dan) Cc: Stephen Farrell; jouni korhonen; jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; dime@ietf.org; IETF-Discussion; iesg@ietf.org Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime) On 1/12/2012 7:15 PM, Romascanu, Dan (Dan) wrote: > Hi, > > If a number of hands were raised now and the folks commanding them say > 'we are ready to work on this NOW' I would support including explicit > wording in the charter. Consider my hand raised. If this does not happen until the telechat next > week the current text is good enough to allow interested people to start > working on contributions that can be individual submissions. If these > submissions are consistent enough the WG can add the milestone later in > the charter and adopt the submissions as WG items. > > Dan > > > > > >> -----Original Message----- >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > Of >> Stephen Farrell >> Sent: Thursday, January 12, 2012 2:13 PM >> To: jouni korhonen >> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >> dime@ietf.org; IETF-Discussion; iesg@ietf.org >> Subject: Re: WG Review: Recharter of Diameter Maintenance and >> Extensions (dime) >> >> >> Hi Jouni, >> >> Right, I'm trying to encourage this - I'm not trying >> to make it a gating function for the recharter. Its >> still worth doing though if we can find some victims >> with enough energy:-) >> >> I agree that the current charter text might not need >> to be modified, OTOH, if there were folks who wanted to >> do the work, a milestone might be good. I also agree >> that as of now, that addition is not warranted. >> >> Cheers, >> S >> >> On 01/12/2012 12:08 PM, jouni korhonen wrote: >>> >>> Stephen, >>> >>> This topic raises its head every now and then when a Dime >>> document arrives at IESG ;) Apart from that there has been >>> very little serious public discussion about it recently, >>> for some unknown reason to me. A detail worth pointing out >>> is that the support for the End-to-End security framework >>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been >>> deprecated in RFC3588bis (now in IESG). So we are "free" >>> to start from scratch. >>> >>> If there is enough serious energy and vision for pursuing >>> end-to-end security, I do not see current proposed charter >>> text prohibiting it: >>> >>> "- Maintaining and/or progressing, along the standards track, the >>> Diameter Base protocol and Diameter Applications. This includes >>> extensions to Diameter Base protocol that can be considered as >>> enhanced features or bug fixes." >>> >>> I would argue the end-to-end security is an enhanced feature for >>> Diameter base protocol that fixes a serious bug/flaw in security. >>> On the other hand, if an explicit note is needed about this topic >>> in the charter, I might hesitate to include such in this round. >>> I would first like to see some concrete movement& work around >>> this topic. >>> >>> - Jouni >>> >>> >>> >>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: >>> >>>> >>>> Hi, >>>> >>>> During the IESG internal review of this I asked whether >>>> or not there was interest in trying to tackle end to >>>> end security for AVPs. I do know there is at least some >>>> interest in that but its not clear there's enough to >>>> warrant including it in the re-charter so I said I'd >>>> ask when the recharter went out for review... >>>> >>>> So - anyone interested in DIME solving that problem? >>>> (And willing and able to help do the work of course.) >>>> >>>> As of now, Diameter really only has hop-by-hop security >>>> which is ok in many cases but far from ideal (wearing >>>> my security hat) in some. >>>> >>>> Thanks, >>>> Stephen. >>>> >>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>>>> A modified charter has been submitted for the Diameter Maintenance >> and >>>>> Extensions (dime) working group in the Operations and Management >> Area of >>>>> the IETF. The IESG has not made any determination as yet. The >> modified >>>>> charter is provided below for informational purposes only. Please >> send >>>>> your comments to the IESG mailing list (iesg@ietf.org) by >> Wednesday, >>>>> January 18, 2012. >>>>> >>>>> Diameter Maintenance and Extensions (dime) >>>>> ----------------------------------------- >>>>> Current Status: Active >>>>> >>>>> Last Modified: 2012-01-10 >>>>> >>>>> Chairs: >>>>> Lionel Morand >>>>> Jouni Korhonen >>>>> >>>>> Operations and Management Area Directors: >>>>> Dan Romascanu >>>>> Ronald Bonica >>>>> >>>>> Operations and Management Area Advisor: >>>>> Dan Romascanu >>>>> >>>>> Mailing Lists: >>>>> General Discussion: dime@ietf.org >>>>> To Subscribe: > https://www.ietf.org/mailman/listinfo/dime >>>>> Archive: >>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>>>> >>>>> Description of Working Group: >>>>> >>>>> The Diameter Maintenance and Extensions WG will focus on >> maintenance and >>>>> extensions to the Diameter protocol required to enable its use for >>>>> authentication, authorization, accounting, charging in network >> access, >>>>> provisioning of configuration information within the network, and >> for >>>>> new AAA session management uses within the extensibility rules of >> the >>>>> Diameter base protocol. >>>>> >>>>> The DIME working group plans to address the following items: >>>>> >>>>> - Maintaining and/or progressing, along the standards track, the >>>>> Diameter Base protocol and Diameter Applications. This includes >>>>> extensions to Diameter Base protocol that can be considered as >> enhanced >>>>> features or bug fixes. >>>>> >>>>> - Diameter application design guideline. This document will > provide >>>>> guidelines for design of Diameter extensions. It will detail when >> to >>>>> consider reusing an existing application and when to develop a new >>>>> application. >>>>> >>>>> - Protocol extensions for the management of Diameter entities. > This >> work >>>>> focuses on the standardization of Management Information Bases >> (MIBs) to >>>>> configure Diameter entities (such as the Diameter Base protocol or >>>>> Diameter Credit Control nodes). The usage of other management >> protocols >>>>> for configuring Diameter entities may be future work within the >> group. >>>>> >>>>> - Protocol extensions for bulk and grouped AAA session management. >> The >>>>> aim of this work is to study and standardize a solution for >> handling >>>>> groups of AAA sessions within the Diameter base protocol context. >> The >>>>> solution would define how to identify and handle grouped AAA >> sessions in >>>>> commands and operations. >>>>> >>>>> Additionally, Diameter-based systems require interoperability in >> order >>>>> to work. The working group, along with the AD, will need to >> evaluate any >>>>> potential extensions and require verification that the proposed >>>>> extension is needed, and is within the extensibility rules of >> Diameter >>>>> and AAA scope. Coordination with other IETF working groups and >> other >>>>> SDOs (e.g. 3GPP) will be used to ensure this. >>>>> >>>>> Goals and Milestones: >>>>> >>>>> Done - Submit the following two Diameter Mobility documents to >> the >>>>> IESG for consideration as a Proposed Standards:* >> 'Diameter >>>>> Mobile IPv6: Support for Home Agent to Diameter Server >>>>> Interaction' * 'Diameter Mobile IPv6: Support for >> Network >>>>> Access Server to Diameter Server Interaction' >>>>> Done - Submit 'Diameter API' to the IESG for consideration as >> an >>>>> Informational RFC >>>>> Done - Submit 'Quality of Service Parameters for Usage with >>>>> Diameter' to the IESG for consideration as a Proposed >>>>> Standard. >>>>> Done - Submit 'Diameter QoS Application' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Support for EAP Re-authentication >>>>> Protocol' as DIME working group item >>>>> Done - Submit 'Diameter User-Name and Realm Based Request >> Routing >>>>> Clarifications' as DIME working group item >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working >> group >>>>> item >>>>> Done - Submit 'Quality of Service Attributes for Diameter' to >> the >>>>> IESG for consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter User-Name and Realm Based Request >> Routing >>>>> Clarifications' to the IESG for consideration as a >> Proposed >>>>> Standard >>>>> Done - Submit 'Diameter NAT Control Application' as DIME >> working >>>>> group item >>>>> Done - Submit 'Diameter Capabilities Update' as DIME working >> group >>>>> item >>>>> Done - Submit 'Diameter Credit Control Application MIB' to the >>>>> IESG for consideration as an Informational RFC >>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>>>> consideration as an Informational RFC >>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working group >> item >>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>>>> working group item >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > Localized >>>>> Routing' as DIME working group item >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > Cryptographic >>>>> Key Transport' as DIME working group item >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as > DIME >>>>> working group item >>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item >>>>> Done - Submit Revision of 'Diameter Base Protocol' to the IESG >> for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > Cryptographic >>>>> Key Transport' to the IESG for consideration as a >> Proposed >>>>> Standard >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to the >>>>> IESG for consideration as a Proposed Standard >>>>> Done - Submit Revision of 'Diameter Network Access Server >>>>> Application - RFC 4005bis' as DIME working group item >>>>> Done - Submit 'Diameter NAT Control Application' to the IESG >> for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for >> consideration >>>>> as a Proposed Standard >>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > Localized >>>>> Routing' to the IESG for consideration as a Proposed >>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the > IESG >>>>> for consideration as a Proposed Standard >>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>>>> Application - RFC 4005bis' to the IESG for >> consideration as a >>>>> Proposed Standard >>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to the >> IESG >>>>> for consideration as a BCP document Standard >>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>>>> Protocol' to the IESG for consideration as a Proposed >>>>> Standard >>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and >> group >>>>> signaling' as a working group item >>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and >> group >>>>> signaling' to the IESG for consideration as a Proposed >>>>> Standard >>>>> _______________________________________________ >>>>> IETF-Announce mailing list >>>>> IETF-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>> >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >>> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ------------------------------------------------------------------------------ _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --Boundary_(ID_CJ0OBoOpPYNtfrO0+8V4aQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT RE: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime)
      Count me.
      I remember there was an initial individual submission from Glen and me regarding end to end security topic.
      unfortunetely not finished due to lacking energy in the last year .
      This may serve as a good input to this topic although more input are needed.
       
      Regards!
      -Qin
      ----- Original Message -----
      Sent: Friday, January 13, 2012 2:14 PM
      Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance andExtensions (dime)

      Thanks, Glen! Can we see (at least) a couple of more hands from people willing to participate in the editing of this document?

      Dan



      -----Original Message-----
      From: Glen Zorn [mailto:glenzorn@gmail.com]
      Sent: Fri 1/13/2012 5:34 AM
      To: Romascanu, Dan (Dan)
      Cc: Stephen Farrell; jouni korhonen; jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; dime@ietf.org; IETF-Discussion; iesg@ietf.org
      Subject: Re: [Dime] WG Review: Recharter of Diameter Maintenance and Extensions (dime)

      On 1/12/2012 7:15 PM, Romascanu, Dan (Dan) wrote:
      > Hi,
      >
      > If a number of hands were raised now and the folks commanding them say
      > 'we are ready to work on this NOW' I would support including explicit
      > wording in the charter.

      Consider my hand raised.

      If this does not happen until the telechat next
      > week the current text is good enough to allow interested people to start
      > working on contributions that can be individual submissions. If these
      > submissions are consistent enough the WG can add the milestone later in
      > the charter and adopt the submissions as WG items.
      >
      > Dan
      >
      >
      >
      >
      >
      >> -----Original Message-----
      >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf
      > Of
      >> Stephen Farrell
      >> Sent: Thursday, January 12, 2012 2:13 PM
      >> To: jouni korhonen
      >> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com;
      >> dime@ietf.org; IETF-Discussion; iesg@ietf.org
      >> Subject: Re: WG Review: Recharter of Diameter Maintenance and
      >> Extensions (dime)
      >>
      >>
      >> Hi Jouni,
      >>
      >> Right, I'm trying to encourage this - I'm not trying
      >> to make it a gating function for the recharter. Its
      >> still worth doing though if we can find some victims
      >> with enough energy:-)
      >>
      >> I agree that the current charter text might not need
      >> to be modified, OTOH, if there were folks who wanted to
      >> do the work, a milestone might be good. I also agree
      >> that as of now, that addition is not warranted.
      >>
      >> Cheers,
      >> S
      >>
      >> On 01/12/2012 12:08 PM, jouni korhonen wrote:
      >>>
      >>> Stephen,
      >>>
      >>> This topic raises its head every now and then when a Dime
      >>> document arrives at IESG ;) Apart from that there has been
      >>> very little serious public discussion about it recently,
      >>> for some unknown reason to me. A detail worth pointing out
      >>> is that the support for the End-to-End security framework
      >>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been
      >>> deprecated in RFC3588bis (now in IESG). So we are "free"
      >>> to start from scratch.
      >>>
      >>> If there is enough serious energy and vision for pursuing
      >>> end-to-end security, I do not see current proposed charter
      >>> text prohibiting it:
      >>>
      >>> "- Maintaining and/or progressing, along the standards track, the
      >>>     Diameter Base protocol and Diameter Applications. This includes
      >>>     extensions to Diameter Base protocol that can be considered as
      >>>     enhanced features or bug fixes."
      >>>
      >>> I would argue the end-to-end security is an enhanced feature for
      >>> Diameter base protocol that fixes a serious bug/flaw in security.
      >>> On the other hand, if an explicit note is needed about this topic
      >>> in the charter, I might hesitate to include such in this round.
      >>> I would first like to see some concrete movement&  work around
      >>> this topic.
      >>>
      >>> - Jouni
      >>>
      >>>
      >>>
      >>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote:
      >>>
      >>>>
      >>>> Hi,
      >>>>
      >>>> During the IESG internal review of this I asked whether
      >>>> or not there was interest in trying to tackle end to
      >>>> end security for AVPs. I do know there is at least some
      >>>> interest in that but its not clear there's enough to
      >>>> warrant including it in the re-charter so I said I'd
      >>>> ask when the recharter went out for review...
      >>>>
      >>>> So - anyone interested in DIME solving that problem?
      >>>> (And willing and able to help do the work of course.)
      >>>>
      >>>> As of now, Diameter really only has hop-by-hop security
      >>>> which is ok in many cases but far from ideal (wearing
      >>>> my security hat) in some.
      >>>>
      >>>> Thanks,
      >>>> Stephen.
      >>>>
      >>>> On 01/11/2012 04:37 PM, IESG Secretary wrote:
      >>>>> A modified charter has been submitted for the Diameter Maintenance
      >> and
      >>>>> Extensions (dime) working group in the Operations and Management
      >> Area of
      >>>>> the IETF.  The IESG has not made any determination as yet.  The
      >> modified
      >>>>> charter is provided below for informational purposes only.  Please
      >> send
      >>>>> your comments to the IESG mailing list (iesg@ietf.org) by
      >> Wednesday,
      >>>>> January 18, 2012.
      >>>>>
      >>>>> Diameter Maintenance and Extensions (dime)
      >>>>> -----------------------------------------
      >>>>> Current Status: Active
      >>>>>
      >>>>> Last Modified: 2012-01-10
      >>>>>
      >>>>> Chairs:
      >>>>>      Lionel Morand<lionel.morand@orange-ftgroup.com>
      >>>>>      Jouni Korhonen<jouni.korhonen@nsn.com>
      >>>>>
      >>>>> Operations and Management Area Directors:
      >>>>>      Dan Romascanu<dromasca@avaya.com>
      >>>>>      Ronald Bonica<rbonica@juniper.net>
      >>>>>
      >>>>> Operations and Management Area Advisor:
      >>>>>      Dan Romascanu<dromasca@avaya.com>
      >>>>>
      >>>>> Mailing Lists:
      >>>>>      General Discussion: dime@ietf.org
      >>>>>      To Subscribe:
      > https://www.ietf.org/mailman/listinfo/dime
      >>>>>      Archive:
      >>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html
      >>>>>
      >>>>> Description of Working Group:
      >>>>>
      >>>>> The Diameter Maintenance and Extensions WG will focus on
      >> maintenance and
      >>>>> extensions to the Diameter protocol required to enable its use for
      >>>>> authentication, authorization, accounting, charging in network
      >> access,
      >>>>> provisioning of configuration information within the network, and
      >> for
      >>>>> new AAA session management uses within the extensibility rules of
      >> the
      >>>>> Diameter base protocol.
      >>>>>
      >>>>> The DIME working group plans to address the following items:
      >>>>>
      >>>>> - Maintaining and/or progressing, along the standards track, the
      >>>>> Diameter Base protocol and Diameter Applications. This includes
      >>>>> extensions to Diameter Base protocol that can be considered as
      >> enhanced
      >>>>> features or bug fixes.
      >>>>>
      >>>>> - Diameter application design guideline. This document will
      > provide
      >>>>> guidelines for design of Diameter extensions. It will detail when
      >> to
      >>>>> consider reusing an existing application and when to develop a new
      >>>>> application.
      >>>>>
      >>>>> - Protocol extensions for the management of Diameter entities.
      > This
      >> work
      >>>>> focuses on the standardization of Management Information Bases
      >> (MIBs) to
      >>>>> configure Diameter entities (such as the Diameter Base protocol or
      >>>>> Diameter Credit Control nodes). The usage of other management
      >> protocols
      >>>>> for configuring Diameter entities may be future work within the
      >> group.
      >>>>>
      >>>>> - Protocol extensions for bulk and grouped AAA session management.
      >> The
      >>>>> aim of this work is to study and standardize a solution for
      >> handling
      >>>>> groups of AAA sessions within the Diameter base protocol context.
      >> The
      >>>>> solution would define how to identify and handle grouped AAA
      >> sessions in
      >>>>> commands and operations.
      >>>>>
      >>>>> Additionally, Diameter-based systems require interoperability in
      >> order
      >>>>> to work. The working group, along with the AD, will need to
      >> evaluate any
      >>>>> potential extensions and require verification that the proposed
      >>>>> extension is needed, and is within the extensibility rules of
      >> Diameter
      >>>>> and AAA scope. Coordination with other IETF working groups and
      >> other
      >>>>> SDOs (e.g. 3GPP) will be used to ensure this.
      >>>>>
      >>>>> Goals and Milestones:
      >>>>>
      >>>>> Done     - Submit the following two Diameter Mobility documents to
      >> the
      >>>>>             IESG for consideration as a Proposed Standards:*
      >> 'Diameter
      >>>>>             Mobile IPv6: Support for Home Agent to Diameter Server
      >>>>>             Interaction' * 'Diameter Mobile IPv6: Support for
      >> Network
      >>>>>             Access Server to Diameter Server Interaction'
      >>>>> Done     - Submit 'Diameter API' to the IESG for consideration as
      >> an
      >>>>>             Informational RFC
      >>>>> Done     - Submit 'Quality of Service Parameters for Usage with
      >>>>>             Diameter' to the IESG for consideration as a Proposed
      >>>>>             Standard.
      >>>>> Done     - Submit 'Diameter QoS Application' to the IESG for
      >>>>>             consideration as a Proposed Standard
      >>>>> Done     - Submit 'Diameter Support for EAP Re-authentication
      >>>>>             Protocol' as DIME working group item
      >>>>> Done     - Submit 'Diameter User-Name and Realm Based Request
      >> Routing
      >>>>>             Clarifications' as DIME working group item
      >>>>> Done     - Submit 'Diameter Proxy Mobile IPv6' as DIME working
      >> group
      >>>>>             item
      >>>>> Done     - Submit 'Quality of Service Attributes for Diameter' to
      >> the
      >>>>>             IESG for consideration as a Proposed Standard
      >>>>> Done     - Submit 'Diameter Proxy Mobile IPv6' to the IESG for
      >>>>>             consideration as a Proposed Standard
      >>>>> Done     - Submit 'Diameter User-Name and Realm Based Request
      >> Routing
      >>>>>             Clarifications' to the IESG for consideration as a
      >> Proposed
      >>>>>             Standard
      >>>>> Done     - Submit 'Diameter NAT Control Application' as DIME
      >> working
      >>>>>             group item
      >>>>> Done     - Submit 'Diameter Capabilities Update' as DIME working
      >> group
      >>>>>             item
      >>>>> Done     - Submit 'Diameter Credit Control Application MIB' to the
      >>>>>             IESG for consideration as an Informational RFC
      >>>>> Done     - Submit 'Diameter Base Protocol MIB' to the IESG for
      >>>>>             consideration as an Informational RFC
      >>>>> Done     - Submit 'Diameter Capabilities Update' to the IESG for
      >>>>>             consideration as a Proposed Standard
      >>>>> Done     - Submit 'Diameter Extended NAPTR' as DIME working group
      >> item
      >>>>> Done     - Submit 'Realm-Based Redirection In Diameter' as DIME
      >>>>>             working group item
      >>>>> Done     - Submit 'Diameter Support for Proxy Mobile IPv6
      > Localized
      >>>>>             Routing' as DIME working group item
      >>>>> Done     - Submit 'Diameter Attribute-Value Pairs for
      > Cryptographic
      >>>>>             Key Transport' as DIME working group item
      >>>>> Done     - Submit 'Diameter Priority Attribute Value Pairs' as
      > DIME
      >>>>>             working group item
      >>>>> Done     - Submit 'Diameter IKEv2 PSK' as DIME working group item
      >>>>> Done     - Submit Revision of 'Diameter Base Protocol' to the IESG
      >> for
      >>>>>             consideration as a Proposed Standard
      >>>>> Done     - Submit 'Diameter Attribute-Value Pairs for
      > Cryptographic
      >>>>>             Key Transport' to the IESG for consideration as a
      >> Proposed
      >>>>>             Standard
      >>>>> Done     - Submit 'Diameter Priority Attribute Value Pairs' to the
      >>>>>             IESG for consideration as a Proposed Standard
      >>>>> Done     - Submit Revision of 'Diameter Network Access Server
      >>>>>             Application - RFC 4005bis' as DIME working group item
      >>>>> Done     - Submit 'Diameter NAT Control Application' to the IESG
      >> for
      >>>>>             consideration as a Proposed Standard
      >>>>> Done     - Submit 'Diameter IKEv2 PSK' to the IESG for
      >> consideration
      >>>>>             as a Proposed Standard
      >>>>> Done     - Submit 'Diameter Extended NAPTR' to the IESG for
      >>>>>             consideration as a Proposed Standard
      >>>>> Done     - Submit 'Diameter Support for Proxy Mobile IPv6
      > Localized
      >>>>>             Routing' to the IESG for consideration as a Proposed
      >>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the
      > IESG
      >>>>>             for consideration as a Proposed Standard
      >>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server
      >>>>>             Application - RFC 4005bis' to the IESG for
      >> consideration as a
      >>>>>             Proposed Standard
      >>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to the
      >> IESG
      >>>>>             for consideration as a BCP document Standard
      >>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication
      >>>>>             Protocol' to the IESG for consideration as a Proposed
      >>>>>             Standard
      >>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and
      >> group
      >>>>>             signaling' as a working group item
      >>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and
      >> group
      >>>>>             signaling' to the IESG for consideration as a Proposed
      >>>>>             Standard
      >>>>> _______________________________________________
      >>>>> IETF-Announce mailing list
      >>>>> IETF-Announce@ietf.org
      >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce
      >>>>>
      >>>> _______________________________________________
      >>>> Ietf mailing list
      >>>> Ietf@ietf.org
      >>>> https://www.ietf.org/mailman/listinfo/ietf
      >>>
      > _______________________________________________
      > DiME mailing list
      > DiME@ietf.org
      > https://www.ietf.org/mailman/listinfo/dime


      _______________________________________________
      DiME mailing list
      DiME@ietf.org
      https://www.ietf.org/mailman/listinfo/dime
      --Boundary_(ID_CJ0OBoOpPYNtfrO0+8V4aQ)-- From kireeti@juniper.net Fri Jan 13 09:37:39 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7157421F852B; Fri, 13 Jan 2012 09:37:39 -0800 (PST) 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 jqpG84ua9HZI; Fri, 13 Jan 2012 09:37:38 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 59B4C21F867F; Fri, 13 Jan 2012 09:37:38 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTxBr2WfBJ5Cmgt4HpV0fp7fBg4LWGUeV@postini.com; Fri, 13 Jan 2012 09:37:38 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 13 Jan 2012 09:35:42 -0800 From: Kireeti Kompella To: Roni Even Date: Fri, 13 Jan 2012 09:35:41 -0800 Subject: Re: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 Thread-Topic: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 Thread-Index: AczSGcWVZIGwNpfQRl2KXMDU0zFrGQ== Message-ID: <3BE55A51-26E0-415F-90C5-AF1905A91237@juniper.net> References: <4e6757ab.87c5e30a.061b.0446@mx.google.com> <4f0fdb33.c3630e0a.7550.fffff20b@mx.google.com> In-Reply-To: <4f0fdb33.c3630e0a.7550.fffff20b@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Kireeti Kompella , "draft-kompella-l2vpn-l2vpn.all@tools.ietf.org" , "gen-art@ietf.org" , IETF-Discussion list X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 17:37:39 -0000 On Jan 12, 2012, at 23:16 , Roni Even wrote: > Hi, > I looked at the 08 version and the major issues are addressed. > What about minor issue number 3? Good point! I will fix (as Stewart suggests, maybe just remove the referen= ce). To your minor issue (2), I've clarified the structure. Do you still want t= o see how it fits into the NLRI? Thanks, Kireeti. > Roni Even >=20 >> -----Original Message----- >> From: Kireeti Kompella [mailto:kireeti@juniper.net] >> Sent: Friday, September 16, 2011 10:23 PM >> To: Roni Even >> Cc: Kireeti Kompella; draft-kompella-l2vpn-l2vpn.all@tools.ietf.org; >> gen-art@ietf.org; IETF-Discussion list >> Subject: Re: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 >>=20 >> Hi Roni, >>=20 >> On Sep 7, 2011, at 4:37 , Roni Even wrote: >>=20 >>> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> . >>=20 >> Thanks! >>=20 >>> Please resolve these comments along with any other Last Call comments >> you may receive. >>>=20 >>> Document: draft-kompella-l2vpn-l2vpn-07 >>> Reviewer: Roni Even >>> Review Date: 2011-9-7 >>> IETF LC End Date: 2011-9-27 >>> IESG Telechat date: >>>=20 >>> Summary: This draft is not ready for publication as an informational >> RFC. >>>=20 >>> Major issues: >>>=20 >>> The IANA considerations section says: >>> "the values already allocated are in Table 1 of Section 4. The >> allocation policy for new entries up to and including value 127 is >> "Standards Action". The allocation policy for values 128 through 251 >> is "First Come First Served". The values from 252 through 255 are for >> "Experimental Use"." >>=20 >> Standards Action will be changed to Expert Review. >>=20 >>> Yet this is document is intended for Informational status which >> contradict the standard action. This is also true for the second >> registry defined. >>>=20 >>> Is this document really an Informational one? >>=20 >> My only comment is that it is not Historic. >>=20 >>> Minor issues: >>>=20 >>> 1. In section 1.2.2 "Since "traditional" Layer 2 VPNs (i.e., >> real Frame Relay circuits connecting sites) are indistinguishable from >> tunnel-based VPNs from the customer's point-of-view, migrating from >> one to the other raises few issues." What are the few issues? >>=20 >> A subtlety: "few issues" means not many, not deep; it's a careful way >> of saying, "just about no issues". "A few issues" would require >> elaboration. >>=20 >>> 2. In section 4 "L2VPN TLVs can be added to extend the >> information carried in the NLRI, using the format shown in Figure 2". >> How is the TLV carried in the NLRI, in which field, section 4.1 only >> talk about the structure of the TLV. >>=20 >> I'll take the figure from 3.2.2 of RFC 4761 and show where the TLVs go. >>=20 >>> 3. Section 4.2 refers to section 4 but I am not sure where this >> mechanism in section 4 is. >>=20 >> Will clarify. >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Nits/editorial comments: >>>=20 >>> 1. Section 3.1 is called network topology but the whole text is >> an example of a network topology. Maybe the title should be "Example of >> a network toplogy". >>=20 >> Sure. >>=20 >>> 2. Section 5 starts with "As defined so far in the document .." >> But the using IP only is already discussed in previous sections. >>=20 >> Do you have a suggestion for rewording? >>=20 >> Thanks, >> Kireeti. >>=20 >>=20 >>>=20 >>>=20 >>> >=20 From ron.even.tlv@gmail.com Fri Jan 13 09:47:16 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE5B21F858D; Fri, 13 Jan 2012 09:47:16 -0800 (PST) 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=[AWL=0.000, 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 9Bzg3ob42CaQ; Fri, 13 Jan 2012 09:47:16 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 712E021F8587; Fri, 13 Jan 2012 09:47:15 -0800 (PST) Received: by eaad11 with SMTP id d11so272237eaa.31 for ; Fri, 13 Jan 2012 09:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=LVjowe5VkJkZVX3TRCNsx9FJJNT0KPBxiSzAuj88+Wo=; b=auRTPXRvj/Y7UuiLOZWsM/wmKFzdZPDfsLkLJWy2yCvnm0O6VK3yXPuhOzaZMo2FVN y70J6COucqf00lTjy1Z2Cx0vsvPrCp47Fxe6XidymTj5tnSqyZhuZIuMYHgPLDVlO4NY Qo6z3aXnCdFQ3jzLykyrtJq1xswZ6QVr9DH20= Received: by 10.213.22.139 with SMTP id n11mr487578ebb.14.1326476834599; Fri, 13 Jan 2012 09:47:14 -0800 (PST) Received: from windows8d787f9 (bzq-79-180-198-96.red.bezeqint.net. [79.180.198.96]) by mx.google.com with ESMTPS id e12sm32130743eea.5.2012.01.13.09.47.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Jan 2012 09:47:13 -0800 (PST) From: "Roni Even" To: "'Kireeti Kompella'" References: <4e6757ab.87c5e30a.061b.0446@mx.google.com> <4f0fdb33.c3630e0a.7550.fffff20b@mx.google.com> <3BE55A51-26E0-415F-90C5-AF1905A91237@juniper.net> In-Reply-To: <3BE55A51-26E0-415F-90C5-AF1905A91237@juniper.net> Subject: RE: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 Date: Fri, 13 Jan 2012 19:43:43 +0200 Message-ID: <4f106e21.8c1b0e0a.7e1f.ffffe57a@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-Index: AczSGcWVZIGwNpfQRl2KXMDU0zFrGQAAP4Yg Cc: draft-kompella-l2vpn-l2vpn.all@tools.ietf.org, gen-art@ietf.org, 'IETF-Discussion list' X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 17:47:16 -0000 Hi, I am OK with minor issue 2 now. Issue 3 was my only point Roni > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Friday, January 13, 2012 7:36 PM > To: Roni Even > Cc: Kireeti Kompella; draft-kompella-l2vpn-l2vpn.all@tools.ietf.org; > gen-art@ietf.org; IETF-Discussion list > Subject: Re: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 > > On Jan 12, 2012, at 23:16 , Roni Even wrote: > > > Hi, > > I looked at the 08 version and the major issues are addressed. > > What about minor issue number 3? > > Good point! I will fix (as Stewart suggests, maybe just remove the > reference). > > To your minor issue (2), I've clarified the structure. Do you still > want to see how it fits into the NLRI? > > Thanks, > Kireeti. > > > Roni Even > > > >> -----Original Message----- > >> From: Kireeti Kompella [mailto:kireeti@juniper.net] > >> Sent: Friday, September 16, 2011 10:23 PM > >> To: Roni Even > >> Cc: Kireeti Kompella; draft-kompella-l2vpn-l2vpn.all@tools.ietf.org; > >> gen-art@ietf.org; IETF-Discussion list > >> Subject: Re: Gen-ART LC review of draft-kompella-l2vpn-l2vpn-07 > >> > >> Hi Roni, > >> > >> On Sep 7, 2011, at 4:37 , Roni Even wrote: > >> > >>> I am the assigned Gen-ART reviewer for this draft. For background > on > >> Gen-ART, please see the FAQ at > >> . > >> > >> Thanks! > >> > >>> Please resolve these comments along with any other Last Call > >>> comments > >> you may receive. > >>> > >>> Document: draft-kompella-l2vpn-l2vpn-07 > >>> Reviewer: Roni Even > >>> Review Date: 2011-9-7 > >>> IETF LC End Date: 2011-9-27 > >>> IESG Telechat date: > >>> > >>> Summary: This draft is not ready for publication as an > informational > >> RFC. > >>> > >>> Major issues: > >>> > >>> The IANA considerations section says: > >>> "the values already allocated are in Table 1 of Section 4. The > >> allocation policy for new entries up to and including value 127 is > >> "Standards Action". The allocation policy for values 128 through > 251 > >> is "First Come First Served". The values from 252 through 255 are > >> for "Experimental Use"." > >> > >> Standards Action will be changed to Expert Review. > >> > >>> Yet this is document is intended for Informational status which > >> contradict the standard action. This is also true for the second > >> registry defined. > >>> > >>> Is this document really an Informational one? > >> > >> My only comment is that it is not Historic. > >> > >>> Minor issues: > >>> > >>> 1. In section 1.2.2 "Since "traditional" Layer 2 VPNs (i.e., > >> real Frame Relay circuits connecting sites) are indistinguishable > >> from tunnel-based VPNs from the customer's point-of-view, migrating > >> from one to the other raises few issues." What are the few issues? > >> > >> A subtlety: "few issues" means not many, not deep; it's a careful > way > >> of saying, "just about no issues". "A few issues" would require > >> elaboration. > >> > >>> 2. In section 4 "L2VPN TLVs can be added to extend the > >> information carried in the NLRI, using the format shown in Figure > 2". > >> How is the TLV carried in the NLRI, in which field, section 4.1 only > >> talk about the structure of the TLV. > >> > >> I'll take the figure from 3.2.2 of RFC 4761 and show where the TLVs > go. > >> > >>> 3. Section 4.2 refers to section 4 but I am not sure where > this > >> mechanism in section 4 is. > >> > >> Will clarify. > >> > >>> > >>> > >>> > >>> > >>> > >>> Nits/editorial comments: > >>> > >>> 1. Section 3.1 is called network topology but the whole text > is > >> an example of a network topology. Maybe the title should be "Example > >> of a network toplogy". > >> > >> Sure. > >> > >>> 2. Section 5 starts with "As defined so far in the document > .." > >> But the using IP only is already discussed in previous sections. > >> > >> Do you have a suggestion for rewording? > >> > >> Thanks, > >> Kireeti. > >> > >> > >>> > >>> > >>> > > From shanna@juniper.net Fri Jan 13 12:01:14 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B3221F8448; Fri, 13 Jan 2012 12:01:14 -0800 (PST) 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 H8DSbSPTIox0; Fri, 13 Jan 2012 12:01:13 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id AD57711E80AD; Fri, 13 Jan 2012 12:00:52 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTxCNdI2mv9psM928MBHXSxY+WsabjS/h@postini.com; Fri, 13 Jan 2012 12:00:59 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 13 Jan 2012 11:59:55 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 13 Jan 2012 14:59:54 -0500 From: Stephen Hanna To: "draft-nottingham-http-new-status@tools.ietf.org" , "secdir@ietf.org" , "ietf@ietf.org" Date: Fri, 13 Jan 2012 14:59:53 -0500 Subject: secdir review of draft-nottingham-http-new-status-03 Thread-Topic: secdir review of draft-nottingham-http-new-status-03 Thread-Index: AczSLeo7PTPAq42hRwirXy24basViA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 20:01:14 -0000 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This document specifies new HTTP status codes for a variety of common situations. Although I am not an HTTP expert, it seems to me that this document is clear, well-written, and reasonable. >From a security perspective, this document seems to have little impact either positive or negative. However, the Security Considerations section does not meet our usual standards. While the authors include a subsection on each new status code, they do not explain clearly what the security implications are for each status code and how any possible negative impacts could be reduced. Riccardo Bernardini already commented on this issue during IETF LC. However, I do not agree with Mr. Bernardini that sections 7.1 and 7.2 are not security related. Rather, the security implications are just not clearly stated. For example, section 7.2 points out that servers may not want to always use the 429 status code when receiving too many requests from one client. This has security implications in that a server under attack with excessive requests from one client may compound the problem by queuing 429 status codes for every request from that client. However, this is not stated explicitly in section 7.2. Fleshing out the subsections of section 7 (Security Considerations) should help solve the problem by providing a clear description of security problems related to these result codes and recommended mitigations. Section 7.4 does a decent job of describing the problems but fails to describe mitigations. I think that having the client use HTTPS instead of HTTP for important requests and limiting the effects of HTTP (not HTTPS) responses is an obvious mitigation. I do have a question about the issues raised in Appendix B. These are all legitimate issues. However, it seems to me that having status code 511 should help with these. A browser or non-browser application could recognize status code 511 as an indication that a captive portal is in use and avoid capturing favicons, looking for P3P files, and doing other things that should wait until after the captive portal is blocking access. When the original website stops returning 511, such activities could resume. I may be wrong in suggesting these ideas but if not it would be good to note them here. From julian.reschke@gmx.de Fri Jan 13 12:26:53 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E9121F848C for ; Fri, 13 Jan 2012 12:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.556 X-Spam-Level: X-Spam-Status: No, score=-103.556 tagged_above=-999 required=5 tests=[AWL=-0.957, 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 MgPgG9+EoXcn for ; Fri, 13 Jan 2012 12:26:53 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 7F65C21F8495 for ; Fri, 13 Jan 2012 12:26:52 -0800 (PST) Received: (qmail invoked by alias); 13 Jan 2012 20:26:51 -0000 Received: from p5DCC28C9.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.40.201] by mail.gmx.net (mp069) with SMTP; 13 Jan 2012 21:26:51 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/1gFl4Jo31RC5WyQUqS1V15w7h84H03l+atE5rFN Ih+kw4M/O5gn69 Message-ID: <4F109383.1090505@gmx.de> Date: Fri, 13 Jan 2012 21:26:43 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Stephen Hanna Subject: Re: secdir review of draft-nottingham-http-new-status-03 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "draft-nottingham-http-new-status@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 20:26:54 -0000 On 2012-01-13 20:59, Stephen Hanna wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document specifies new HTTP status codes for a variety of > common situations. Although I am not an HTTP expert, it seems > to me that this document is clear, well-written, and reasonable. +1 >> From a security perspective, this document seems to have little > impact either positive or negative. However, the Security > Considerations section does not meet our usual standards. > While the authors include a subsection on each new status code, > they do not explain clearly what the security implications are > for each status code and how any possible negative impacts > could be reduced. In general, the proposed new codes just allow to describe a problem more clearly; previously, a more generic status code would have to be used. As such, they do not change security at all. > Riccardo Bernardini already commented on this issue during > IETF LC. However, I do not agree with Mr. Bernardini that > sections 7.1 and 7.2 are not security related. Rather, the > security implications are just not clearly stated. For example, > section 7.2 points out that servers may not want to always > use the 429 status code when receiving too many requests > from one client. This has security implications in that > a server under attack with excessive requests from one > client may compound the problem by queuing 429 status codes > for every request from that client. However, this is not > stated explicitly in section 7.2. Fleshing out the subsections "Servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps." > of section 7 (Security Considerations) should help solve the > problem by providing a clear description of security problems > related to these result codes and recommended mitigations. > Section 7.4 does a decent job of describing the problems > but fails to describe mitigations. I think that having the > client use HTTPS instead of HTTP for important requests > and limiting the effects of HTTP (not HTTPS) responses > is an obvious mitigation. It's not the job of this spec to completely describe security considerations with respect to captive portals. All the spec does is defining a new status code that, when used, makes captive portals a bit better to work with. > I do have a question about the issues raised in Appendix B. > These are all legitimate issues. However, it seems to me > that having status code 511 should help with these. A Indeed; that's why 511 is there in the first place. The introduction to Appendix B should state that. > ... Best regards, Julian From shanna@juniper.net Fri Jan 13 13:38:01 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE2711E8072; Fri, 13 Jan 2012 13:38:01 -0800 (PST) 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 jmLJwx5rmiPG; Fri, 13 Jan 2012 13:38:00 -0800 (PST) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id E33431F0C38; Fri, 13 Jan 2012 13:37:45 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTxCkKbHP00G72Ri3Abpj4eTMkCEanwp7@postini.com; Fri, 13 Jan 2012 13:37:51 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 13 Jan 2012 13:26:30 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 13 Jan 2012 16:26:29 -0500 From: Stephen Hanna To: Julian Reschke Date: Fri, 13 Jan 2012 16:26:28 -0500 Subject: RE: secdir review of draft-nottingham-http-new-status-03 Thread-Topic: secdir review of draft-nottingham-http-new-status-03 Thread-Index: AczSMbESPXFYh7cpTSiWb/c10V+TNAABO4tQ Message-ID: References: <4F109383.1090505@gmx.de> In-Reply-To: <4F109383.1090505@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-nottingham-http-new-status@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 21:38:01 -0000 Julian, I'm sure that in your view one sentence is adequate to explain all the security implications of each status code. However, you may want to consider that some readers may not have quite the same deep grasp of the matter that you do. Therefore, I think it would be wise to provide more explanation. Here's an example for section 7.2 on status code 429 (Too Many Requests): Section 7.2 429 Too Many Requests While status code 429 can be helpful in figuring out why a server is not responding to requests, it can also be harmful. When a server is under attack or simply receiving a very large number of requests from a single party, responding to each of these requests with a 429 status code will consume resources that could be better used in other ways. Therefore, a server in such circumstances may choose to send a 429 status code only the first time a client exceeds its limit and ignore subsequent requests from this client until its limit is no longer exceeded. Other approaches may also be employed. As you can see, I described security problems that could occur with this status code and explained how those problems can be avoided or mitigated. While it's true that these problems could occur when a more generic status code is used to handle the case of "too many requests", that does not mean that they are not relevant to this document. On the contrary, the fact that this document is providing more detailed status codes gives us the opportunity and one can argue the obligation to provide more detailed security analysis relevant to these more detailed status codes. And I'm glad that you saw the value in my comment about Appendix B! Thanks, Steve > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Friday, January 13, 2012 3:27 PM > To: Stephen Hanna > Cc: draft-nottingham-http-new-status@tools.ietf.org; secdir@ietf.org; > ietf@ietf.org > Subject: Re: secdir review of draft-nottingham-http-new-status-03 >=20 > On 2012-01-13 20:59, Stephen Hanna wrote: > > I have reviewed this document as part of the security directorate's > > ongoing effort to review all IETF documents being processed by the > > IESG. These comments were written primarily for the benefit of the > > security area directors. Document editors and WG chairs should treat > > these comments just like any other last call comments. > > > > This document specifies new HTTP status codes for a variety of > > common situations. Although I am not an HTTP expert, it seems > > to me that this document is clear, well-written, and reasonable. >=20 > +1 >=20 > >> From a security perspective, this document seems to have little > > impact either positive or negative. However, the Security > > Considerations section does not meet our usual standards. > > While the authors include a subsection on each new status code, > > they do not explain clearly what the security implications are > > for each status code and how any possible negative impacts > > could be reduced. >=20 > In general, the proposed new codes just allow to describe a problem > more > clearly; previously, a more generic status code would have to be used. >=20 > As such, they do not change security at all. >=20 > > Riccardo Bernardini already commented on this issue during > > IETF LC. However, I do not agree with Mr. Bernardini that > > sections 7.1 and 7.2 are not security related. Rather, the > > security implications are just not clearly stated. For example, > > section 7.2 points out that servers may not want to always > > use the 429 status code when receiving too many requests > > from one client. This has security implications in that > > a server under attack with excessive requests from one > > client may compound the problem by queuing 429 status codes > > for every request from that client. However, this is not > > stated explicitly in section 7.2. Fleshing out the subsections >=20 > "Servers are not required to use the 429 status code; when limiting > resource usage, it may be more appropriate to just drop connections, or > take other steps." >=20 > > of section 7 (Security Considerations) should help solve the > > problem by providing a clear description of security problems > > related to these result codes and recommended mitigations. > > Section 7.4 does a decent job of describing the problems > > but fails to describe mitigations. I think that having the > > client use HTTPS instead of HTTP for important requests > > and limiting the effects of HTTP (not HTTPS) responses > > is an obvious mitigation. >=20 > It's not the job of this spec to completely describe security > considerations with respect to captive portals. >=20 > All the spec does is defining a new status code that, when used, makes > captive portals a bit better to work with. >=20 > > I do have a question about the issues raised in Appendix B. > > These are all legitimate issues. However, it seems to me > > that having status code 511 should help with these. A >=20 > Indeed; that's why 511 is there in the first place. The introduction to > Appendix B should state that. >=20 > > ... >=20 > Best regards, Julian From sm@resistor.net Sat Jan 14 04:03:18 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468A221F8503; Sat, 14 Jan 2012 04:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.637 X-Spam-Level: X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 FP+rCpyK9QeI; Sat, 14 Jan 2012 04:03:16 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0315521F84F6; Sat, 14 Jan 2012 04:03:15 -0800 (PST) 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 q0EC38d3029048; Sat, 14 Jan 2012 04:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326542594; i=@resistor.net; bh=ZcBVy0ynj9LmI3kldrOBqrt0ON1qSrXUFxLPiJdeAXE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=PkqRCff2RgCjQmFaI98Cr5hVLU7ruHKd7DH39LxlZ7s8smt5RH1E4et1D69HwFkPL o6UOXs84gm23FwjZ9OPpoPUZe+jYDOepP8P8w2klkAblQBIwVKRSNYicq0EBc7V8Ie d2+IZOc/tTdRS7D+smLd8PoaSMVqtoW4SbBJyQ34= Message-Id: <6.2.5.6.2.20120114024516.09b814f8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 14 Jan 2012 04:00:29 -0800 To: Zoltan Ordogh From: SM Subject: Re: [apps-discuss] Spam reporting over IMAP In-Reply-To: <1DE983233DBBEB4A81F18FABD8208D76226BE438@XMB107ACNC.rim.ne t> References: <1DE983233DBBEB4A81F18FABD8208D76226BE438@XMB107ACNC.rim.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: trustees@ietf.org, ietf@ietf.org, apps-discuss@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 12:03:18 -0000 Hi Zoltan, At 11:11 13-01-2012, Zoltan Ordogh wrote: >Instead of responding to individual emails one by one, I try to >clarify some of the concerns at least in a single response. The single response does not address the issue I raised ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04079.html ). >PS. I am solely a technical contributor, so asking me IPR-related >questions will always be a dead end. Please direct those questions >directly to the appropriate contact person, which, in, this case is >Sarah Guichard. Thank you. draft-ordogh-spam-reporting-using-imap-kleansed-00 lists Zoltan Ordogh, Research In Motion Limited, as the author of the Internet-Draft. The document states that: "This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79." Do you have any concerns about draft-ordogh-spam-reporting-using-imap-kleansed-00 in respect to BCP 78 and BCP 79? Regards, -sm From vesely@tana.it Sat Jan 14 05:32:30 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9387121F859F; Sat, 14 Jan 2012 05:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=-1.078, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MANGLED_SPAM=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 fHcR3j9R8J0L; Sat, 14 Jan 2012 05:32:29 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6430721F8567; Sat, 14 Jan 2012 05:32:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1326547947; bh=szuSUpjJlPSOEFbZeT6bT7V6pHJE0X7dsE9RW9uhpwU=; l=2493; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=HKotkOIBMRykYeUr/yJHXNR8hXbtoD2fANcWDcQCKaZ1XfJW9hHSnlgtTB72VtEcZ T1JmAwuowgDeS5LJiA3uN3W6xsgMBp6+OnuZEzZ8vEjJKPU5WZnk4c0meKXIrLMJUe JniTTPc7uHgo6XxMn4gZNX8E1JQoUCLitu0mEZ+I= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 14 Jan 2012 14:32:27 +0100 id 00000000005DC035.000000004F1183EB.00001F3E Message-ID: <4F1183EA.4070505@tana.it> Date: Sat, 14 Jan 2012 14:32:26 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Zoltan Ordogh Subject: Re: [apps-discuss] Spam reporting over IMAP References: <1DE983233DBBEB4A81F18FABD8208D76226BE438@XMB107ACNC.rim.net> In-Reply-To: <1DE983233DBBEB4A81F18FABD8208D76226BE438@XMB107ACNC.rim.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: ietf , apps-discuss@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 13:32:30 -0000 Hi Zoltan, On 13/Jan/12 20:11, Zoltan Ordogh wrote: > > I would like to start with a story. A rather similar story is summarized here: http://wiki.asrg.sp.am/wiki/Adding_a_junk_button_to_MUAs > A bit later, a liaison statement was sent from OMA to IETF, seeking > collaboration and a “home†for the draft; as required by RFC3975. I assume you're still talking about SREP. I read a reply by John Klensin, whom I consider a sort of IETF guru, and it didn't prospect a bright future for the draft. I posted a "kleansed" version trying to address some of those concerns, in an attempt to improve the chances that APPSAWG will adopt it. Somewhat arbitrarily, I changed the IPR qualification of the document too. In fact, I had the impression that the IPR was that way because OMA SpamRep was being mentioned, albeit not being specified, and also because that was one of the points raised. I hope my editing was correct, but your approval as author is needed. > PS. I am solely a technical contributor, So am I (but I signed no contract.) > so asking me IPR-related questions will always be a dead end. As a survival requirement, you have to be able to answer SM's question, though. > Please direct those questions directly to the appropriate contact > person, which, in, this case is Sarah Guichard. I sent my previous comment on this to Jon M. Jurgovan, cc Sarah Guichard, but had no reply either. > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public information. Any use of this information by anyone other > than the intended recipient is prohibited. The above boilerplate formally makes of no effect whatever else you wrote in that message, according to Andrew's explanation: http://www.ietf.org/mail-archive/web/ietf/current/msg67516.html I usually group these issues to the same bin I use for IPRs, as I guess many others on this list do. Unfortunately, at times they become relevant, which is why we have to deal with them. See "survival" above :-) Specifically, if you need a written authorization of your employer in order to contribute technical specifications to the IETF under IETF's terms, please ask them to provide it. I guess we need that paperwork. Ciao Ale From john-ietf@jck.com Sat Jan 14 09:40:17 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329D121F8578; Sat, 14 Jan 2012 09:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 z0NqVTusuzfP; Sat, 14 Jan 2012 09:40:16 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by ietfa.amsl.com (Postfix) with ESMTP id 1D38B21F856C; Sat, 14 Jan 2012 09:40:16 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1Rm7aJ-000PBX-Qr; Sat, 14 Jan 2012 12:40:08 -0500 Date: Sat, 14 Jan 2012 12:40:06 -0500 From: John C Klensin To: Alessandro Vesely , Zoltan Ordogh Subject: Re: [apps-discuss] Spam reporting over IMAP Message-ID: <8F9BBA9DC2586FB6E35803F4@PST.JCK.COM> In-Reply-To: <4F1183EA.4070505@tana.it> References: <1DE983233DBBEB4A81F18FABD8208D76226BE438@XMB107ACNC.rim.net> <4F1183EA.4070505@tana.it> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: ietf , apps-discuss@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 17:40:17 -0000 --On Saturday, January 14, 2012 14:32 +0100 Alessandro Vesely wrote: >... >> A bit later, a liaison statement was sent from OMA to IETF, >> seeking collaboration and a "home" for the draft; as >> required by RFC3975. > > I assume you're still talking about SREP. I read a reply by > John Klensin, whom I consider a sort of IETF guru, and it > didn't prospect a bright future for the draft. I posted a > "kleansed" version trying to address some of those concerns, > in an attempt to improve the chances that APPSAWG will adopt > it. Somewhat arbitrarily, I changed the IPR qualification of > the document too. In fact, I had the impression that the IPR > was that way because OMA SpamRep was being mentioned, albeit > not being specified, and also because that was one of the > points raised. > I hope my editing was correct, but your approval as author is > needed. >... Alessandro, Zoltan, Guru or not (some would certainly dispute that), this is strictly a personal comment and personal opinion. Just to clarify my view of this (other may have different opinions)... (1) I think SM's question, and anything else having to do with the IRP status of this document (or pair of documents) has to be completely clear. The IETF could certainly decide to process the document even if the technology were encumbered (has happened many times before), but uncertainty is pretty much a showstopper. Alessandro's concerns about distribution disclaimers on email messages that discuss the topic only reinforce my concern in this area. (2) Similarly, both of you, and RIM and OMA, need to understand that handing something like this off to IETF, especially for standards-track processing, is a handoff of change control. The IETF can modify (we hope improve) things as it likes, even after approval of the first version of the document as a Proposed Standard. Joint ownership/ change control arrangements are possible, but they are very hard and time-consuming to negotiate and perhaps, due to some bad experience, likely to get harder. (3) The leadership of AppAWG, and the ADs, will do as they think appropriate, but, if I were making the rules, no one would spend energy trying to sort out the differences between a pair of competing documents. I suggest that the two of you get together, offlist, and see if you can reach clear agreement on a single draft that supercedes both documents. That is a matter of courtesy to those of us you are asking to consider the work and is quite independent of the IPR concerns (although they do interact). All three of those issues are administrative, not technical. They should be easily solved. My personal preferences is that the AppsAWG, and the apps-discuss list, spend no more time on this until/unless they are resolved. YMMD, of course. (4) The core of my previous comments was a technical concern, not an administrative one. Even if one ignores the security concerns, the stability issues for normative references, and so on, many of us believe that the IMAP protocol has become far too complicated, with too many options and features. That complexity increases the requirements on IMAP servers that wish to support a wide range of clients and applications and on clients that wish to support a reasonable range of features but work with servers that may not support all of them. Whatever the advantages, too much code and too many code paths are not conducive to very high quality, bug-free, implementations. This proposal seems to me to take IMAP into a whole new area. I'm not questions whether or not that is possible because I'd be certain it would be, even without the assertiosn that there are implementations out there. I am questioning whether there is a strong enough case to be made that this belongs in IMAP to justify further clutter in the protocol and even lower odds of seeing high-quality clients. I observe that probably the best general-purpose --as distinct from, e.g., specialized for mobile devices-- IMAP client out there is now quite old, largely unmaintained, and has not picked up on any of the new features added in the last several years. Neither version of the document really addresses that issue. Some of the comments from the two of you about why it is hard and/or expensive to do it in other ways certainly have merit, but need, IMO, to be balanced off against other considerations including the above. That balance won't be easy to find especially since, as I am sure you both know, there is no community agreement about the degree to which it is appropriate to make normal, desired, email work worse in order to provide better facilities for spam-handling, especially spam-handling at or after the final delivery MTA. Bottom line: I think we should see a single draft that really addresses all of the technical issues, including the design tradeoffs and security topics, _and_ addresses the IPR/administrative one in a way with which we can all be comfortable before being asked to decide whether AppsAWG should take this up. If asked to make a decision without such a draft having been posted, I would vote "no". john From chair@ietf.org Sun Jan 15 12:12:37 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80B921F84A2; Sun, 15 Jan 2012 12:12:37 -0800 (PST) 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 GmP7rOK16l-C; Sun, 15 Jan 2012 12:12:37 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:123a::1:14]) by ietfa.amsl.com (Postfix) with ESMTP id 49AD121F84A0; Sun, 15 Jan 2012 12:12:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 8854512C95C; Sun, 15 Jan 2012 12:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdtHb5PKiaRh; Sun, 15 Jan 2012 12:12:38 -0800 (PST) Received: from [192.168.2.104] (pool-96-241-165-215.washdc.fios.verizon.net [96.241.165.215]) by c8a.amsl.com (Postfix) with ESMTPSA id 1270412C959; Sun, 15 Jan 2012 12:12:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Subject: Paris IETF Codesprint Mime-Version: 1.0 (Apple Message framework v1084) From: IETF Chair Date: Sun, 15 Jan 2012 15:12:32 -0500 Content-Transfer-Encoding: 7bit Message-Id: <68346139-29F8-4B71-9CCA-6AC158C85E6F@ietf.org> To: IETF Announcement list X-Mailer: Apple Mail (2.1084) Cc: 83all@ietf.org, IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 20:12:37 -0000 Paris IETF Codesprint When: Saturday, 24 March 2012, starting at 9:30 AM Where: IETF Hotel What: A bunch of hackers get together to work on code for the IETF. All code will become part of the open source IETF tools. Who: Hopefully you can help Many of the results of previous codesprint activities are being used every day by the IETF community. Shortly before the Paris meeting, we will transition from the current database schema to a new one. We believe that the new schema will make many tasks much easier. No doubt, the transition will uncover new bugs. Work to polish or improve existing tools, fix bugs, or make new tools. All efforts are appreciated and most welcome. Steve Conte will be helping with advance planning. Henrik Levkowetz will be coordinating the event in Paris. You can find more information here: http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF83Sprint If you are able to participate, please sign up on the wiki at: http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF83SprintSignUp Please support the tools development effort, Russ From jouni.nospam@gmail.com Mon Jan 16 06:50:28 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3541621F8616; Mon, 16 Jan 2012 06:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.631 X-Spam-Level: X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[AWL=-0.032, 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 ZKesKvVnhIcj; Mon, 16 Jan 2012 06:50:27 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20DAD21F860F; Mon, 16 Jan 2012 06:50:25 -0800 (PST) Received: by lagv3 with SMTP id v3so1903415lag.31 for ; Mon, 16 Jan 2012 06:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=HwICT3BSl8RsggkgVoSj4J7TlaWAx5ns34NGVXqMmGE=; b=bajDxDmYJLwxGHThJyeO5MCvOIFl828pVu4QxZl6ugzBIyL3fA4TOtKbz4DmMweQOJ k8xX22AkxaW1TcIqsFEhEvksY0TTgQneymhpbzYnd5kKJ8oVEVq/bImcvNy27kc40Xkn yBXG5NfvfV+u4p1v1KQ23fYz1Lt5GA71x5jus= Received: by 10.152.145.71 with SMTP id ss7mr6001031lab.28.1326725425066; Mon, 16 Jan 2012 06:50:25 -0800 (PST) Received: from a88-112-207-191.elisa-laajakaista.fi (a88-112-207-191.elisa-laajakaista.fi. [88.112.207.191]) by mx.google.com with ESMTPS id k4sm17635003lby.1.2012.01.16.06.50.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Jan 2012 06:50:20 -0800 (PST) Subject: Re: WG Review: Recharter of Diameter Maintenance and Extensions (dime) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Mon, 16 Jan 2012 16:50:15 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3EF888CD-2843-440B-AF9A-ACE0CEF33180@gmail.com> References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> To: Stephen Farrell , "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.1084) Cc: Jouni Korhonen , "lionel.morand@orange-ftgroup.com> Morand" , dime@ietf.org, IETF-Discussion , "iesg@ietf.org IESG" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 14:50:28 -0000 Stephen, Dan, What if we just add a milestone to the charter to indicate that end-to-end security is coming to our table? Jul 2012 - Sumbit 'problem statement and requirements for Diameter end-to-end security framework' as Dime working group item. Dec 2012 - Submit 'problem statement and requirements for Diameter end-to-end security framework' to the IESG for consideration as an Informational RFC. I would give some time folks to work this out.. and then when we actually know what we and especially IETF external deployment folks want, we can move to solution part.. Seems like a relaxed milestone plan but I have doubts it would progress any faster in real life even if milestones were tighter ;) - Jouni On Jan 12, 2012, at 2:15 PM, Romascanu, Dan (Dan) wrote: > Hi, > > If a number of hands were raised now and the folks commanding them say > 'we are ready to work on this NOW' I would support including explicit > wording in the charter. If this does not happen until the telechat next > week the current text is good enough to allow interested people to start > working on contributions that can be individual submissions. If these > submissions are consistent enough the WG can add the milestone later in > the charter and adopt the submissions as WG items. > > Dan > > > > > >> -----Original Message----- >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > Of >> Stephen Farrell >> Sent: Thursday, January 12, 2012 2:13 PM >> To: jouni korhonen >> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >> dime@ietf.org; IETF-Discussion; iesg@ietf.org >> Subject: Re: WG Review: Recharter of Diameter Maintenance and >> Extensions (dime) >> >> >> Hi Jouni, >> >> Right, I'm trying to encourage this - I'm not trying >> to make it a gating function for the recharter. Its >> still worth doing though if we can find some victims >> with enough energy:-) >> >> I agree that the current charter text might not need >> to be modified, OTOH, if there were folks who wanted to >> do the work, a milestone might be good. I also agree >> that as of now, that addition is not warranted. >> >> Cheers, >> S >> >> On 01/12/2012 12:08 PM, jouni korhonen wrote: >>> >>> Stephen, >>> >>> This topic raises its head every now and then when a Dime >>> document arrives at IESG ;) Apart from that there has been >>> very little serious public discussion about it recently, >>> for some unknown reason to me. A detail worth pointing out >>> is that the support for the End-to-End security framework >>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been >>> deprecated in RFC3588bis (now in IESG). So we are "free" >>> to start from scratch. >>> >>> If there is enough serious energy and vision for pursuing >>> end-to-end security, I do not see current proposed charter >>> text prohibiting it: >>> >>> "- Maintaining and/or progressing, along the standards track, the >>> Diameter Base protocol and Diameter Applications. This includes >>> extensions to Diameter Base protocol that can be considered as >>> enhanced features or bug fixes." >>> >>> I would argue the end-to-end security is an enhanced feature for >>> Diameter base protocol that fixes a serious bug/flaw in security. >>> On the other hand, if an explicit note is needed about this topic >>> in the charter, I might hesitate to include such in this round. >>> I would first like to see some concrete movement& work around >>> this topic. >>> >>> - Jouni >>> >>> >>> >>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: >>> >>>> >>>> Hi, >>>> >>>> During the IESG internal review of this I asked whether >>>> or not there was interest in trying to tackle end to >>>> end security for AVPs. I do know there is at least some >>>> interest in that but its not clear there's enough to >>>> warrant including it in the re-charter so I said I'd >>>> ask when the recharter went out for review... >>>> >>>> So - anyone interested in DIME solving that problem? >>>> (And willing and able to help do the work of course.) >>>> >>>> As of now, Diameter really only has hop-by-hop security >>>> which is ok in many cases but far from ideal (wearing >>>> my security hat) in some. >>>> >>>> Thanks, >>>> Stephen. >>>> >>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>>>> A modified charter has been submitted for the Diameter Maintenance >> and >>>>> Extensions (dime) working group in the Operations and Management >> Area of >>>>> the IETF. The IESG has not made any determination as yet. The >> modified >>>>> charter is provided below for informational purposes only. Please >> send >>>>> your comments to the IESG mailing list (iesg@ietf.org) by >> Wednesday, >>>>> January 18, 2012. >>>>> >>>>> Diameter Maintenance and Extensions (dime) >>>>> ----------------------------------------- >>>>> Current Status: Active >>>>> >>>>> Last Modified: 2012-01-10 >>>>> >>>>> Chairs: >>>>> Lionel Morand >>>>> Jouni Korhonen >>>>> >>>>> Operations and Management Area Directors: >>>>> Dan Romascanu >>>>> Ronald Bonica >>>>> >>>>> Operations and Management Area Advisor: >>>>> Dan Romascanu >>>>> >>>>> Mailing Lists: >>>>> General Discussion: dime@ietf.org >>>>> To Subscribe: > https://www.ietf.org/mailman/listinfo/dime >>>>> Archive: >>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>>>> >>>>> Description of Working Group: >>>>> >>>>> The Diameter Maintenance and Extensions WG will focus on >> maintenance and >>>>> extensions to the Diameter protocol required to enable its use for >>>>> authentication, authorization, accounting, charging in network >> access, >>>>> provisioning of configuration information within the network, and >> for >>>>> new AAA session management uses within the extensibility rules of >> the >>>>> Diameter base protocol. >>>>> >>>>> The DIME working group plans to address the following items: >>>>> >>>>> - Maintaining and/or progressing, along the standards track, the >>>>> Diameter Base protocol and Diameter Applications. This includes >>>>> extensions to Diameter Base protocol that can be considered as >> enhanced >>>>> features or bug fixes. >>>>> >>>>> - Diameter application design guideline. This document will > provide >>>>> guidelines for design of Diameter extensions. It will detail when >> to >>>>> consider reusing an existing application and when to develop a new >>>>> application. >>>>> >>>>> - Protocol extensions for the management of Diameter entities. > This >> work >>>>> focuses on the standardization of Management Information Bases >> (MIBs) to >>>>> configure Diameter entities (such as the Diameter Base protocol or >>>>> Diameter Credit Control nodes). The usage of other management >> protocols >>>>> for configuring Diameter entities may be future work within the >> group. >>>>> >>>>> - Protocol extensions for bulk and grouped AAA session management. >> The >>>>> aim of this work is to study and standardize a solution for >> handling >>>>> groups of AAA sessions within the Diameter base protocol context. >> The >>>>> solution would define how to identify and handle grouped AAA >> sessions in >>>>> commands and operations. >>>>> >>>>> Additionally, Diameter-based systems require interoperability in >> order >>>>> to work. The working group, along with the AD, will need to >> evaluate any >>>>> potential extensions and require verification that the proposed >>>>> extension is needed, and is within the extensibility rules of >> Diameter >>>>> and AAA scope. Coordination with other IETF working groups and >> other >>>>> SDOs (e.g. 3GPP) will be used to ensure this. >>>>> >>>>> Goals and Milestones: >>>>> >>>>> Done - Submit the following two Diameter Mobility documents to >> the >>>>> IESG for consideration as a Proposed Standards:* >> 'Diameter >>>>> Mobile IPv6: Support for Home Agent to Diameter Server >>>>> Interaction' * 'Diameter Mobile IPv6: Support for >> Network >>>>> Access Server to Diameter Server Interaction' >>>>> Done - Submit 'Diameter API' to the IESG for consideration as >> an >>>>> Informational RFC >>>>> Done - Submit 'Quality of Service Parameters for Usage with >>>>> Diameter' to the IESG for consideration as a Proposed >>>>> Standard. >>>>> Done - Submit 'Diameter QoS Application' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Support for EAP Re-authentication >>>>> Protocol' as DIME working group item >>>>> Done - Submit 'Diameter User-Name and Realm Based Request >> Routing >>>>> Clarifications' as DIME working group item >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working >> group >>>>> item >>>>> Done - Submit 'Quality of Service Attributes for Diameter' to >> the >>>>> IESG for consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter User-Name and Realm Based Request >> Routing >>>>> Clarifications' to the IESG for consideration as a >> Proposed >>>>> Standard >>>>> Done - Submit 'Diameter NAT Control Application' as DIME >> working >>>>> group item >>>>> Done - Submit 'Diameter Capabilities Update' as DIME working >> group >>>>> item >>>>> Done - Submit 'Diameter Credit Control Application MIB' to the >>>>> IESG for consideration as an Informational RFC >>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>>>> consideration as an Informational RFC >>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working group >> item >>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>>>> working group item >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > Localized >>>>> Routing' as DIME working group item >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > Cryptographic >>>>> Key Transport' as DIME working group item >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as > DIME >>>>> working group item >>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item >>>>> Done - Submit Revision of 'Diameter Base Protocol' to the IESG >> for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > Cryptographic >>>>> Key Transport' to the IESG for consideration as a >> Proposed >>>>> Standard >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to the >>>>> IESG for consideration as a Proposed Standard >>>>> Done - Submit Revision of 'Diameter Network Access Server >>>>> Application - RFC 4005bis' as DIME working group item >>>>> Done - Submit 'Diameter NAT Control Application' to the IESG >> for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for >> consideration >>>>> as a Proposed Standard >>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>>>> consideration as a Proposed Standard >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > Localized >>>>> Routing' to the IESG for consideration as a Proposed >>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the > IESG >>>>> for consideration as a Proposed Standard >>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>>>> Application - RFC 4005bis' to the IESG for >> consideration as a >>>>> Proposed Standard >>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to the >> IESG >>>>> for consideration as a BCP document Standard >>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>>>> Protocol' to the IESG for consideration as a Proposed >>>>> Standard >>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and >> group >>>>> signaling' as a working group item >>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and >> group >>>>> signaling' to the IESG for consideration as a Proposed >>>>> Standard >>>>> _______________________________________________ >>>>> IETF-Announce mailing list >>>>> IETF-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>> >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf >>> From dromasca@avaya.com Mon Jan 16 06:51:54 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB8E21F861C; Mon, 16 Jan 2012 06:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.279 X-Spam-Level: X-Spam-Status: No, score=-103.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, 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 y20ec7J3098P; Mon, 16 Jan 2012 06:51:53 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2F921F861A; Mon, 16 Jan 2012 06:51:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FAP82FE+HCzI1/2dsb2JhbAA5CqEdiw+BC4EFgXIBAQEBAwEBAQ8eCjQLDAQCAQgNBAQBAQEKAgQMCwEGASAGHwkIAQEEARIIARACB4dgmkKbGIhaUDYBBVYIAgcCAgEJAQEBKw4cCTcFAYFtVxYBAQECgkdjBJsEhQiHRw X-IronPort-AV: E=Sophos;i="4.71,518,1320642000"; d="scan'208";a="324692901" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 Jan 2012 09:51:51 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 16 Jan 2012 09:38:29 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WG Review: Recharter of Diameter Maintenance and Extensions (dime) Date: Mon, 16 Jan 2012 15:51:47 +0100 Message-ID: In-Reply-To: <3EF888CD-2843-440B-AF9A-ACE0CEF33180@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Diameter Maintenance and Extensions (dime) Thread-Index: AczUXjUzcN3PXAR3TBWDL/SWdNVzqAAACFrw References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> <3EF888CD-2843-440B-AF9A-ACE0CEF33180@gmail.com> From: "Romascanu, Dan (Dan)" To: "jouni korhonen" , "Stephen Farrell" Cc: Jouni Korhonen , lionel.morand@orange-ftgroup.com, dime@ietf.org, IETF-Discussion , iesg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 14:51:54 -0000 This would be fine with me. Dan > -----Original Message----- > From: jouni korhonen [mailto:jouni.nospam@gmail.com] > Sent: Monday, January 16, 2012 4:50 PM > To: Stephen Farrell; Romascanu, Dan (Dan) > Cc: Jouni Korhonen; lionel.morand@orange-ftgroup.com> Morand; > dime@ietf.org; IETF-Discussion; iesg@ietf.org IESG > Subject: Re: WG Review: Recharter of Diameter Maintenance and > Extensions (dime) >=20 > Stephen, Dan, >=20 > What if we just add a milestone to the charter to indicate that > end-to-end security is coming to our table? >=20 > Jul 2012 - Sumbit 'problem statement and requirements for Diameter > end-to-end security framework' as Dime working group item. > Dec 2012 - Submit 'problem statement and requirements for Diameter > end-to-end security framework' to the IESG for > consideration > as an Informational RFC. >=20 > I would give some time folks to work this out.. and then when we > actually > know what we and especially IETF external deployment folks want, we can > move to solution part.. Seems like a relaxed milestone plan but I have > doubts it would progress any faster in real life even if milestones > were > tighter ;) >=20 > - Jouni >=20 > On Jan 12, 2012, at 2:15 PM, Romascanu, Dan (Dan) wrote: >=20 > > Hi, > > > > If a number of hands were raised now and the folks commanding them > say > > 'we are ready to work on this NOW' I would support including explicit > > wording in the charter. If this does not happen until the telechat > next > > week the current text is good enough to allow interested people to > start > > working on contributions that can be individual submissions. If these > > submissions are consistent enough the WG can add the milestone later > in > > the charter and adopt the submissions as WG items. > > > > Dan > > > > > > > > > > > >> -----Original Message----- > >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf > > Of > >> Stephen Farrell > >> Sent: Thursday, January 12, 2012 2:13 PM > >> To: jouni korhonen > >> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; > >> dime@ietf.org; IETF-Discussion; iesg@ietf.org > >> Subject: Re: WG Review: Recharter of Diameter Maintenance and > >> Extensions (dime) > >> > >> > >> Hi Jouni, > >> > >> Right, I'm trying to encourage this - I'm not trying > >> to make it a gating function for the recharter. Its > >> still worth doing though if we can find some victims > >> with enough energy:-) > >> > >> I agree that the current charter text might not need > >> to be modified, OTOH, if there were folks who wanted to > >> do the work, a milestone might be good. I also agree > >> that as of now, that addition is not warranted. > >> > >> Cheers, > >> S > >> > >> On 01/12/2012 12:08 PM, jouni korhonen wrote: > >>> > >>> Stephen, > >>> > >>> This topic raises its head every now and then when a Dime > >>> document arrives at IESG ;) Apart from that there has been > >>> very little serious public discussion about it recently, > >>> for some unknown reason to me. A detail worth pointing out > >>> is that the support for the End-to-End security framework > >>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been > >>> deprecated in RFC3588bis (now in IESG). So we are "free" > >>> to start from scratch. > >>> > >>> If there is enough serious energy and vision for pursuing > >>> end-to-end security, I do not see current proposed charter > >>> text prohibiting it: > >>> > >>> "- Maintaining and/or progressing, along the standards track, the > >>> Diameter Base protocol and Diameter Applications. This includes > >>> extensions to Diameter Base protocol that can be considered as > >>> enhanced features or bug fixes." > >>> > >>> I would argue the end-to-end security is an enhanced feature for > >>> Diameter base protocol that fixes a serious bug/flaw in security. > >>> On the other hand, if an explicit note is needed about this topic > >>> in the charter, I might hesitate to include such in this round. > >>> I would first like to see some concrete movement& work around > >>> this topic. > >>> > >>> - Jouni > >>> > >>> > >>> > >>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: > >>> > >>>> > >>>> Hi, > >>>> > >>>> During the IESG internal review of this I asked whether > >>>> or not there was interest in trying to tackle end to > >>>> end security for AVPs. I do know there is at least some > >>>> interest in that but its not clear there's enough to > >>>> warrant including it in the re-charter so I said I'd > >>>> ask when the recharter went out for review... > >>>> > >>>> So - anyone interested in DIME solving that problem? > >>>> (And willing and able to help do the work of course.) > >>>> > >>>> As of now, Diameter really only has hop-by-hop security > >>>> which is ok in many cases but far from ideal (wearing > >>>> my security hat) in some. > >>>> > >>>> Thanks, > >>>> Stephen. > >>>> > >>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: > >>>>> A modified charter has been submitted for the Diameter > Maintenance > >> and > >>>>> Extensions (dime) working group in the Operations and Management > >> Area of > >>>>> the IETF. The IESG has not made any determination as yet. The > >> modified > >>>>> charter is provided below for informational purposes only. > Please > >> send > >>>>> your comments to the IESG mailing list (iesg@ietf.org) by > >> Wednesday, > >>>>> January 18, 2012. > >>>>> > >>>>> Diameter Maintenance and Extensions (dime) > >>>>> ----------------------------------------- > >>>>> Current Status: Active > >>>>> > >>>>> Last Modified: 2012-01-10 > >>>>> > >>>>> Chairs: > >>>>> Lionel Morand > >>>>> Jouni Korhonen > >>>>> > >>>>> Operations and Management Area Directors: > >>>>> Dan Romascanu > >>>>> Ronald Bonica > >>>>> > >>>>> Operations and Management Area Advisor: > >>>>> Dan Romascanu > >>>>> > >>>>> Mailing Lists: > >>>>> General Discussion: dime@ietf.org > >>>>> To Subscribe: > > https://www.ietf.org/mailman/listinfo/dime > >>>>> Archive: > >>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html > >>>>> > >>>>> Description of Working Group: > >>>>> > >>>>> The Diameter Maintenance and Extensions WG will focus on > >> maintenance and > >>>>> extensions to the Diameter protocol required to enable its use > for > >>>>> authentication, authorization, accounting, charging in network > >> access, > >>>>> provisioning of configuration information within the network, and > >> for > >>>>> new AAA session management uses within the extensibility rules of > >> the > >>>>> Diameter base protocol. > >>>>> > >>>>> The DIME working group plans to address the following items: > >>>>> > >>>>> - Maintaining and/or progressing, along the standards track, the > >>>>> Diameter Base protocol and Diameter Applications. This includes > >>>>> extensions to Diameter Base protocol that can be considered as > >> enhanced > >>>>> features or bug fixes. > >>>>> > >>>>> - Diameter application design guideline. This document will > > provide > >>>>> guidelines for design of Diameter extensions. It will detail when > >> to > >>>>> consider reusing an existing application and when to develop a > new > >>>>> application. > >>>>> > >>>>> - Protocol extensions for the management of Diameter entities. > > This > >> work > >>>>> focuses on the standardization of Management Information Bases > >> (MIBs) to > >>>>> configure Diameter entities (such as the Diameter Base protocol > or > >>>>> Diameter Credit Control nodes). The usage of other management > >> protocols > >>>>> for configuring Diameter entities may be future work within the > >> group. > >>>>> > >>>>> - Protocol extensions for bulk and grouped AAA session > management. > >> The > >>>>> aim of this work is to study and standardize a solution for > >> handling > >>>>> groups of AAA sessions within the Diameter base protocol context. > >> The > >>>>> solution would define how to identify and handle grouped AAA > >> sessions in > >>>>> commands and operations. > >>>>> > >>>>> Additionally, Diameter-based systems require interoperability in > >> order > >>>>> to work. The working group, along with the AD, will need to > >> evaluate any > >>>>> potential extensions and require verification that the proposed > >>>>> extension is needed, and is within the extensibility rules of > >> Diameter > >>>>> and AAA scope. Coordination with other IETF working groups and > >> other > >>>>> SDOs (e.g. 3GPP) will be used to ensure this. > >>>>> > >>>>> Goals and Milestones: > >>>>> > >>>>> Done - Submit the following two Diameter Mobility documents > to > >> the > >>>>> IESG for consideration as a Proposed Standards:* > >> 'Diameter > >>>>> Mobile IPv6: Support for Home Agent to Diameter Server > >>>>> Interaction' * 'Diameter Mobile IPv6: Support for > >> Network > >>>>> Access Server to Diameter Server Interaction' > >>>>> Done - Submit 'Diameter API' to the IESG for consideration as > >> an > >>>>> Informational RFC > >>>>> Done - Submit 'Quality of Service Parameters for Usage with > >>>>> Diameter' to the IESG for consideration as a Proposed > >>>>> Standard. > >>>>> Done - Submit 'Diameter QoS Application' to the IESG for > >>>>> consideration as a Proposed Standard > >>>>> Done - Submit 'Diameter Support for EAP Re-authentication > >>>>> Protocol' as DIME working group item > >>>>> Done - Submit 'Diameter User-Name and Realm Based Request > >> Routing > >>>>> Clarifications' as DIME working group item > >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working > >> group > >>>>> item > >>>>> Done - Submit 'Quality of Service Attributes for Diameter' to > >> the > >>>>> IESG for consideration as a Proposed Standard > >>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for > >>>>> consideration as a Proposed Standard > >>>>> Done - Submit 'Diameter User-Name and Realm Based Request > >> Routing > >>>>> Clarifications' to the IESG for consideration as a > >> Proposed > >>>>> Standard > >>>>> Done - Submit 'Diameter NAT Control Application' as DIME > >> working > >>>>> group item > >>>>> Done - Submit 'Diameter Capabilities Update' as DIME working > >> group > >>>>> item > >>>>> Done - Submit 'Diameter Credit Control Application MIB' to > the > >>>>> IESG for consideration as an Informational RFC > >>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for > >>>>> consideration as an Informational RFC > >>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for > >>>>> consideration as a Proposed Standard > >>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working group > >> item > >>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME > >>>>> working group item > >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > > Localized > >>>>> Routing' as DIME working group item > >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > > Cryptographic > >>>>> Key Transport' as DIME working group item > >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as > > DIME > >>>>> working group item > >>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group item > >>>>> Done - Submit Revision of 'Diameter Base Protocol' to the > IESG > >> for > >>>>> consideration as a Proposed Standard > >>>>> Done - Submit 'Diameter Attribute-Value Pairs for > > Cryptographic > >>>>> Key Transport' to the IESG for consideration as a > >> Proposed > >>>>> Standard > >>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to > the > >>>>> IESG for consideration as a Proposed Standard > >>>>> Done - Submit Revision of 'Diameter Network Access Server > >>>>> Application - RFC 4005bis' as DIME working group item > >>>>> Done - Submit 'Diameter NAT Control Application' to the IESG > >> for > >>>>> consideration as a Proposed Standard > >>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for > >> consideration > >>>>> as a Proposed Standard > >>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for > >>>>> consideration as a Proposed Standard > >>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 > > Localized > >>>>> Routing' to the IESG for consideration as a Proposed > >>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the > > IESG > >>>>> for consideration as a Proposed Standard > >>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server > >>>>> Application - RFC 4005bis' to the IESG for > >> consideration as a > >>>>> Proposed Standard > >>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to the > >> IESG > >>>>> for consideration as a BCP document Standard > >>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication > >>>>> Protocol' to the IESG for consideration as a Proposed > >>>>> Standard > >>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and > >> group > >>>>> signaling' as a working group item > >>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and > >> group > >>>>> signaling' to the IESG for consideration as a Proposed > >>>>> Standard > >>>>> _______________________________________________ > >>>>> IETF-Announce mailing list > >>>>> IETF-Announce@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce > >>>>> > >>>> _______________________________________________ > >>>> Ietf mailing list > >>>> Ietf@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ietf > >>> From stephen.farrell@cs.tcd.ie Mon Jan 16 06:53:22 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37C121F862A; Mon, 16 Jan 2012 06:53:21 -0800 (PST) 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 te5zC8GPI+Cv; Mon, 16 Jan 2012 06:53:20 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 56A4D21F8617; Mon, 16 Jan 2012 06:53:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 9C373171C27; Mon, 16 Jan 2012 14:53:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1326725590; bh=iJDKde82yHkZnw wMR8Yb/Gx598Xeriekx1jlmKfNkTI=; b=cCyZ7IuBmK5geiAUh+8tUYEzhiy6e6 H7xA1p8yKDc/y7JH73VY7QlgjtnDPId/FjzeH9ggmbUA0lwJvv+opn1VBFRgBfs7 JEU38NkYIV7pugkNNbD1zv8TboxSFts4dTr4Acww1ukNjroXUGN93jiDF/5VBkx3 dPQnvPGirZR9tpNVLACwcZCMBlblxmbYpkxJ2zVGpXK+dQ/qw9NJWiMI03Ycv/7K 7P1noaHKuNPf6Zu0Z1kEd7kkq5XxDBNeLqxgd6Vplkr4oYS65Hd/Ljd4O3sR1lHu S11AKPw9pTjfvTMD6hLbNf1lChkgOK8yTXEUrJ+VRisr+Tu0S4gN9pbg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id kxi5PIWXDm-x; Mon, 16 Jan 2012 14:53:10 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id F09E1171C29; Mon, 16 Jan 2012 14:53:09 +0000 (GMT) Message-ID: <4F1439D5.6010502@cs.tcd.ie> Date: Mon, 16 Jan 2012 14:53:09 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Subject: Re: WG Review: Recharter of Diameter Maintenance and Extensions (dime) References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> <3EF888CD-2843-440B-AF9A-ACE0CEF33180@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF-Discussion , Jouni Korhonen , lionel.morand@orange-ftgroup.com, dime@ietf.org, iesg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 14:53:22 -0000 And I'd be ecstatic (when it happens:-) Thanks, S On 01/16/2012 02:51 PM, Romascanu, Dan (Dan) wrote: > This would be fine with me. > > Dan > > > > >> -----Original Message----- >> From: jouni korhonen [mailto:jouni.nospam@gmail.com] >> Sent: Monday, January 16, 2012 4:50 PM >> To: Stephen Farrell; Romascanu, Dan (Dan) >> Cc: Jouni Korhonen; lionel.morand@orange-ftgroup.com> Morand; >> dime@ietf.org; IETF-Discussion; iesg@ietf.org IESG >> Subject: Re: WG Review: Recharter of Diameter Maintenance and >> Extensions (dime) >> >> Stephen, Dan, >> >> What if we just add a milestone to the charter to indicate that >> end-to-end security is coming to our table? >> >> Jul 2012 - Sumbit 'problem statement and requirements for Diameter >> end-to-end security framework' as Dime working group > item. >> Dec 2012 - Submit 'problem statement and requirements for Diameter >> end-to-end security framework' to the IESG for >> consideration >> as an Informational RFC. >> >> I would give some time folks to work this out.. and then when we >> actually >> know what we and especially IETF external deployment folks want, we > can >> move to solution part.. Seems like a relaxed milestone plan but I > have >> doubts it would progress any faster in real life even if milestones >> were >> tighter ;) >> >> - Jouni >> >> On Jan 12, 2012, at 2:15 PM, Romascanu, Dan (Dan) wrote: >> >>> Hi, >>> >>> If a number of hands were raised now and the folks commanding them >> say >>> 'we are ready to work on this NOW' I would support including > explicit >>> wording in the charter. If this does not happen until the telechat >> next >>> week the current text is good enough to allow interested people to >> start >>> working on contributions that can be individual submissions. If > these >>> submissions are consistent enough the WG can add the milestone later >> in >>> the charter and adopt the submissions as WG items. >>> >>> Dan >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On > Behalf >>> Of >>>> Stephen Farrell >>>> Sent: Thursday, January 12, 2012 2:13 PM >>>> To: jouni korhonen >>>> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >>>> dime@ietf.org; IETF-Discussion; iesg@ietf.org >>>> Subject: Re: WG Review: Recharter of Diameter Maintenance and >>>> Extensions (dime) >>>> >>>> >>>> Hi Jouni, >>>> >>>> Right, I'm trying to encourage this - I'm not trying >>>> to make it a gating function for the recharter. Its >>>> still worth doing though if we can find some victims >>>> with enough energy:-) >>>> >>>> I agree that the current charter text might not need >>>> to be modified, OTOH, if there were folks who wanted to >>>> do the work, a milestone might be good. I also agree >>>> that as of now, that addition is not warranted. >>>> >>>> Cheers, >>>> S >>>> >>>> On 01/12/2012 12:08 PM, jouni korhonen wrote: >>>>> >>>>> Stephen, >>>>> >>>>> This topic raises its head every now and then when a Dime >>>>> document arrives at IESG ;) Apart from that there has been >>>>> very little serious public discussion about it recently, >>>>> for some unknown reason to me. A detail worth pointing out >>>>> is that the support for the End-to-End security framework >>>>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been >>>>> deprecated in RFC3588bis (now in IESG). So we are "free" >>>>> to start from scratch. >>>>> >>>>> If there is enough serious energy and vision for pursuing >>>>> end-to-end security, I do not see current proposed charter >>>>> text prohibiting it: >>>>> >>>>> "- Maintaining and/or progressing, along the standards track, the >>>>> Diameter Base protocol and Diameter Applications. This includes >>>>> extensions to Diameter Base protocol that can be considered as >>>>> enhanced features or bug fixes." >>>>> >>>>> I would argue the end-to-end security is an enhanced feature for >>>>> Diameter base protocol that fixes a serious bug/flaw in security. >>>>> On the other hand, if an explicit note is needed about this topic >>>>> in the charter, I might hesitate to include such in this round. >>>>> I would first like to see some concrete movement& work around >>>>> this topic. >>>>> >>>>> - Jouni >>>>> >>>>> >>>>> >>>>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: >>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> During the IESG internal review of this I asked whether >>>>>> or not there was interest in trying to tackle end to >>>>>> end security for AVPs. I do know there is at least some >>>>>> interest in that but its not clear there's enough to >>>>>> warrant including it in the re-charter so I said I'd >>>>>> ask when the recharter went out for review... >>>>>> >>>>>> So - anyone interested in DIME solving that problem? >>>>>> (And willing and able to help do the work of course.) >>>>>> >>>>>> As of now, Diameter really only has hop-by-hop security >>>>>> which is ok in many cases but far from ideal (wearing >>>>>> my security hat) in some. >>>>>> >>>>>> Thanks, >>>>>> Stephen. >>>>>> >>>>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>>>>>> A modified charter has been submitted for the Diameter >> Maintenance >>>> and >>>>>>> Extensions (dime) working group in the Operations and Management >>>> Area of >>>>>>> the IETF. The IESG has not made any determination as yet. The >>>> modified >>>>>>> charter is provided below for informational purposes only. >> Please >>>> send >>>>>>> your comments to the IESG mailing list (iesg@ietf.org) by >>>> Wednesday, >>>>>>> January 18, 2012. >>>>>>> >>>>>>> Diameter Maintenance and Extensions (dime) >>>>>>> ----------------------------------------- >>>>>>> Current Status: Active >>>>>>> >>>>>>> Last Modified: 2012-01-10 >>>>>>> >>>>>>> Chairs: >>>>>>> Lionel Morand >>>>>>> Jouni Korhonen >>>>>>> >>>>>>> Operations and Management Area Directors: >>>>>>> Dan Romascanu >>>>>>> Ronald Bonica >>>>>>> >>>>>>> Operations and Management Area Advisor: >>>>>>> Dan Romascanu >>>>>>> >>>>>>> Mailing Lists: >>>>>>> General Discussion: dime@ietf.org >>>>>>> To Subscribe: >>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> Archive: >>>>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>>>>>> >>>>>>> Description of Working Group: >>>>>>> >>>>>>> The Diameter Maintenance and Extensions WG will focus on >>>> maintenance and >>>>>>> extensions to the Diameter protocol required to enable its use >> for >>>>>>> authentication, authorization, accounting, charging in network >>>> access, >>>>>>> provisioning of configuration information within the network, > and >>>> for >>>>>>> new AAA session management uses within the extensibility rules > of >>>> the >>>>>>> Diameter base protocol. >>>>>>> >>>>>>> The DIME working group plans to address the following items: >>>>>>> >>>>>>> - Maintaining and/or progressing, along the standards track, the >>>>>>> Diameter Base protocol and Diameter Applications. This includes >>>>>>> extensions to Diameter Base protocol that can be considered as >>>> enhanced >>>>>>> features or bug fixes. >>>>>>> >>>>>>> - Diameter application design guideline. This document will >>> provide >>>>>>> guidelines for design of Diameter extensions. It will detail > when >>>> to >>>>>>> consider reusing an existing application and when to develop a >> new >>>>>>> application. >>>>>>> >>>>>>> - Protocol extensions for the management of Diameter entities. >>> This >>>> work >>>>>>> focuses on the standardization of Management Information Bases >>>> (MIBs) to >>>>>>> configure Diameter entities (such as the Diameter Base protocol >> or >>>>>>> Diameter Credit Control nodes). The usage of other management >>>> protocols >>>>>>> for configuring Diameter entities may be future work within the >>>> group. >>>>>>> >>>>>>> - Protocol extensions for bulk and grouped AAA session >> management. >>>> The >>>>>>> aim of this work is to study and standardize a solution for >>>> handling >>>>>>> groups of AAA sessions within the Diameter base protocol > context. >>>> The >>>>>>> solution would define how to identify and handle grouped AAA >>>> sessions in >>>>>>> commands and operations. >>>>>>> >>>>>>> Additionally, Diameter-based systems require interoperability in >>>> order >>>>>>> to work. The working group, along with the AD, will need to >>>> evaluate any >>>>>>> potential extensions and require verification that the proposed >>>>>>> extension is needed, and is within the extensibility rules of >>>> Diameter >>>>>>> and AAA scope. Coordination with other IETF working groups and >>>> other >>>>>>> SDOs (e.g. 3GPP) will be used to ensure this. >>>>>>> >>>>>>> Goals and Milestones: >>>>>>> >>>>>>> Done - Submit the following two Diameter Mobility documents >> to >>>> the >>>>>>> IESG for consideration as a Proposed Standards:* >>>> 'Diameter >>>>>>> Mobile IPv6: Support for Home Agent to Diameter > Server >>>>>>> Interaction' * 'Diameter Mobile IPv6: Support for >>>> Network >>>>>>> Access Server to Diameter Server Interaction' >>>>>>> Done - Submit 'Diameter API' to the IESG for consideration > as >>>> an >>>>>>> Informational RFC >>>>>>> Done - Submit 'Quality of Service Parameters for Usage with >>>>>>> Diameter' to the IESG for consideration as a Proposed >>>>>>> Standard. >>>>>>> Done - Submit 'Diameter QoS Application' to the IESG for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Support for EAP Re-authentication >>>>>>> Protocol' as DIME working group item >>>>>>> Done - Submit 'Diameter User-Name and Realm Based Request >>>> Routing >>>>>>> Clarifications' as DIME working group item >>>>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working >>>> group >>>>>>> item >>>>>>> Done - Submit 'Quality of Service Attributes for Diameter' > to >>>> the >>>>>>> IESG for consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter User-Name and Realm Based Request >>>> Routing >>>>>>> Clarifications' to the IESG for consideration as a >>>> Proposed >>>>>>> Standard >>>>>>> Done - Submit 'Diameter NAT Control Application' as DIME >>>> working >>>>>>> group item >>>>>>> Done - Submit 'Diameter Capabilities Update' as DIME working >>>> group >>>>>>> item >>>>>>> Done - Submit 'Diameter Credit Control Application MIB' to >> the >>>>>>> IESG for consideration as an Informational RFC >>>>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>>>>>> consideration as an Informational RFC >>>>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working > group >>>> item >>>>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>>>>>> working group item >>>>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 >>> Localized >>>>>>> Routing' as DIME working group item >>>>>>> Done - Submit 'Diameter Attribute-Value Pairs for >>> Cryptographic >>>>>>> Key Transport' as DIME working group item >>>>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as >>> DIME >>>>>>> working group item >>>>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group > item >>>>>>> Done - Submit Revision of 'Diameter Base Protocol' to the >> IESG >>>> for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Attribute-Value Pairs for >>> Cryptographic >>>>>>> Key Transport' to the IESG for consideration as a >>>> Proposed >>>>>>> Standard >>>>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to >> the >>>>>>> IESG for consideration as a Proposed Standard >>>>>>> Done - Submit Revision of 'Diameter Network Access Server >>>>>>> Application - RFC 4005bis' as DIME working group item >>>>>>> Done - Submit 'Diameter NAT Control Application' to the IESG >>>> for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for >>>> consideration >>>>>>> as a Proposed Standard >>>>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>>>>>> consideration as a Proposed Standard >>>>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 >>> Localized >>>>>>> Routing' to the IESG for consideration as a Proposed >>>>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the >>> IESG >>>>>>> for consideration as a Proposed Standard >>>>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>>>>>> Application - RFC 4005bis' to the IESG for >>>> consideration as a >>>>>>> Proposed Standard >>>>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to > the >>>> IESG >>>>>>> for consideration as a BCP document Standard >>>>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>>>>>> Protocol' to the IESG for consideration as a Proposed >>>>>>> Standard >>>>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and >>>> group >>>>>>> signaling' as a working group item >>>>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and >>>> group >>>>>>> signaling' to the IESG for consideration as a > Proposed >>>>>>> Standard >>>>>>> _______________________________________________ >>>>>>> IETF-Announce mailing list >>>>>>> IETF-Announce@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>>>> >>>>>> _______________________________________________ >>>>>> Ietf mailing list >>>>>> Ietf@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ietf >>>>> > From jouni.nospam@gmail.com Mon Jan 16 07:02:05 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E835E21F8606; Mon, 16 Jan 2012 07:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.626 X-Spam-Level: X-Spam-Status: No, score=-3.626 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 KNlj7Aqwezih; Mon, 16 Jan 2012 07:02:04 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CCD0921F8605; Mon, 16 Jan 2012 07:02:03 -0800 (PST) Received: by lagv3 with SMTP id v3so1911210lag.31 for ; Mon, 16 Jan 2012 07:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=EYs5m9dX9u+ndiQ9AvOaXl4QU3tcxDDkUBsaQdSehTU=; b=b9wLplBvTpUzbp5o1PlaNEHeLqGEIhEQ3E4UxciU3l2O6dbQUMprXWppmQ71nCDQ2n 342djy+dWFAlN/osbzq0mBcYucgAoAsu0Io+5fIU4riLDRPNr6n6WGbKbJt+XWNyis+p Ddpv2o5E1O3Qep4r2MPqMzCQgmNVii2HVf50Q= Received: by 10.112.101.198 with SMTP id fi6mr3144565lbb.18.1326726122814; Mon, 16 Jan 2012 07:02:02 -0800 (PST) Received: from a88-112-207-191.elisa-laajakaista.fi (a88-112-207-191.elisa-laajakaista.fi. [88.112.207.191]) by mx.google.com with ESMTPS id o10sm17635645lbt.12.2012.01.16.07.02.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Jan 2012 07:02:01 -0800 (PST) Subject: Re: WG Review: Recharter of Diameter Maintenance and Extensions (dime) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <4F1439D5.6010502@cs.tcd.ie> Date: Mon, 16 Jan 2012 17:01:59 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <20120111163717.591B021F87EF@ietfa.amsl.com><4F0DC78D.2010809@cs.tcd.ie> <4F0ECE57.3020900@cs.tcd.ie> <3EF888CD-2843-440B-AF9A-ACE0CEF33180@gmail.com> <4F1439D5.6010502@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Cc: IETF-Discussion , Jouni Korhonen , "Romascanu, Dan \(Dan\)" , lionel.morand@orange-ftgroup.com, dime@ietf.org, iesg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 15:02:06 -0000 So be it.. from my behalf. - Jouni On Jan 16, 2012, at 4:53 PM, Stephen Farrell wrote: > > And I'd be ecstatic (when it happens:-) > > Thanks, > S > > On 01/16/2012 02:51 PM, Romascanu, Dan (Dan) wrote: >> This would be fine with me. >> >> Dan >> >> >> >> >>> -----Original Message----- >>> From: jouni korhonen [mailto:jouni.nospam@gmail.com] >>> Sent: Monday, January 16, 2012 4:50 PM >>> To: Stephen Farrell; Romascanu, Dan (Dan) >>> Cc: Jouni Korhonen; lionel.morand@orange-ftgroup.com> Morand; >>> dime@ietf.org; IETF-Discussion; iesg@ietf.org IESG >>> Subject: Re: WG Review: Recharter of Diameter Maintenance and >>> Extensions (dime) >>> >>> Stephen, Dan, >>> >>> What if we just add a milestone to the charter to indicate that >>> end-to-end security is coming to our table? >>> >>> Jul 2012 - Sumbit 'problem statement and requirements for Diameter >>> end-to-end security framework' as Dime working group >> item. >>> Dec 2012 - Submit 'problem statement and requirements for Diameter >>> end-to-end security framework' to the IESG for >>> consideration >>> as an Informational RFC. >>> >>> I would give some time folks to work this out.. and then when we >>> actually >>> know what we and especially IETF external deployment folks want, we >> can >>> move to solution part.. Seems like a relaxed milestone plan but I >> have >>> doubts it would progress any faster in real life even if milestones >>> were >>> tighter ;) >>> >>> - Jouni >>> >>> On Jan 12, 2012, at 2:15 PM, Romascanu, Dan (Dan) wrote: >>> >>>> Hi, >>>> >>>> If a number of hands were raised now and the folks commanding them >>> say >>>> 'we are ready to work on this NOW' I would support including >> explicit >>>> wording in the charter. If this does not happen until the telechat >>> next >>>> week the current text is good enough to allow interested people to >>> start >>>> working on contributions that can be individual submissions. If >> these >>>> submissions are consistent enough the WG can add the milestone later >>> in >>>> the charter and adopt the submissions as WG items. >>>> >>>> Dan >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On >> Behalf >>>> Of >>>>> Stephen Farrell >>>>> Sent: Thursday, January 12, 2012 2:13 PM >>>>> To: jouni korhonen >>>>> Cc: jouni.korhonen@nsn.com; lionel.morand@orange-ftgroup.com; >>>>> dime@ietf.org; IETF-Discussion; iesg@ietf.org >>>>> Subject: Re: WG Review: Recharter of Diameter Maintenance and >>>>> Extensions (dime) >>>>> >>>>> >>>>> Hi Jouni, >>>>> >>>>> Right, I'm trying to encourage this - I'm not trying >>>>> to make it a gating function for the recharter. Its >>>>> still worth doing though if we can find some victims >>>>> with enough energy:-) >>>>> >>>>> I agree that the current charter text might not need >>>>> to be modified, OTOH, if there were folks who wanted to >>>>> do the work, a milestone might be good. I also agree >>>>> that as of now, that addition is not warranted. >>>>> >>>>> Cheers, >>>>> S >>>>> >>>>> On 01/12/2012 12:08 PM, jouni korhonen wrote: >>>>>> >>>>>> Stephen, >>>>>> >>>>>> This topic raises its head every now and then when a Dime >>>>>> document arrives at IESG ;) Apart from that there has been >>>>>> very little serious public discussion about it recently, >>>>>> for some unknown reason to me. A detail worth pointing out >>>>>> is that the support for the End-to-End security framework >>>>>> (E2E-Sequence AVP and 'P'-bit in the AVP header) has been >>>>>> deprecated in RFC3588bis (now in IESG). So we are "free" >>>>>> to start from scratch. >>>>>> >>>>>> If there is enough serious energy and vision for pursuing >>>>>> end-to-end security, I do not see current proposed charter >>>>>> text prohibiting it: >>>>>> >>>>>> "- Maintaining and/or progressing, along the standards track, the >>>>>> Diameter Base protocol and Diameter Applications. This includes >>>>>> extensions to Diameter Base protocol that can be considered as >>>>>> enhanced features or bug fixes." >>>>>> >>>>>> I would argue the end-to-end security is an enhanced feature for >>>>>> Diameter base protocol that fixes a serious bug/flaw in security. >>>>>> On the other hand, if an explicit note is needed about this topic >>>>>> in the charter, I might hesitate to include such in this round. >>>>>> I would first like to see some concrete movement& work around >>>>>> this topic. >>>>>> >>>>>> - Jouni >>>>>> >>>>>> >>>>>> >>>>>> On Jan 11, 2012, at 7:31 PM, Stephen Farrell wrote: >>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> During the IESG internal review of this I asked whether >>>>>>> or not there was interest in trying to tackle end to >>>>>>> end security for AVPs. I do know there is at least some >>>>>>> interest in that but its not clear there's enough to >>>>>>> warrant including it in the re-charter so I said I'd >>>>>>> ask when the recharter went out for review... >>>>>>> >>>>>>> So - anyone interested in DIME solving that problem? >>>>>>> (And willing and able to help do the work of course.) >>>>>>> >>>>>>> As of now, Diameter really only has hop-by-hop security >>>>>>> which is ok in many cases but far from ideal (wearing >>>>>>> my security hat) in some. >>>>>>> >>>>>>> Thanks, >>>>>>> Stephen. >>>>>>> >>>>>>> On 01/11/2012 04:37 PM, IESG Secretary wrote: >>>>>>>> A modified charter has been submitted for the Diameter >>> Maintenance >>>>> and >>>>>>>> Extensions (dime) working group in the Operations and Management >>>>> Area of >>>>>>>> the IETF. The IESG has not made any determination as yet. The >>>>> modified >>>>>>>> charter is provided below for informational purposes only. >>> Please >>>>> send >>>>>>>> your comments to the IESG mailing list (iesg@ietf.org) by >>>>> Wednesday, >>>>>>>> January 18, 2012. >>>>>>>> >>>>>>>> Diameter Maintenance and Extensions (dime) >>>>>>>> ----------------------------------------- >>>>>>>> Current Status: Active >>>>>>>> >>>>>>>> Last Modified: 2012-01-10 >>>>>>>> >>>>>>>> Chairs: >>>>>>>> Lionel Morand >>>>>>>> Jouni Korhonen >>>>>>>> >>>>>>>> Operations and Management Area Directors: >>>>>>>> Dan Romascanu >>>>>>>> Ronald Bonica >>>>>>>> >>>>>>>> Operations and Management Area Advisor: >>>>>>>> Dan Romascanu >>>>>>>> >>>>>>>> Mailing Lists: >>>>>>>> General Discussion: dime@ietf.org >>>>>>>> To Subscribe: >>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>>> Archive: >>>>>>>> http://www.ietf.org/mail-archive/web/dime/current/maillist.html >>>>>>>> >>>>>>>> Description of Working Group: >>>>>>>> >>>>>>>> The Diameter Maintenance and Extensions WG will focus on >>>>> maintenance and >>>>>>>> extensions to the Diameter protocol required to enable its use >>> for >>>>>>>> authentication, authorization, accounting, charging in network >>>>> access, >>>>>>>> provisioning of configuration information within the network, >> and >>>>> for >>>>>>>> new AAA session management uses within the extensibility rules >> of >>>>> the >>>>>>>> Diameter base protocol. >>>>>>>> >>>>>>>> The DIME working group plans to address the following items: >>>>>>>> >>>>>>>> - Maintaining and/or progressing, along the standards track, the >>>>>>>> Diameter Base protocol and Diameter Applications. This includes >>>>>>>> extensions to Diameter Base protocol that can be considered as >>>>> enhanced >>>>>>>> features or bug fixes. >>>>>>>> >>>>>>>> - Diameter application design guideline. This document will >>>> provide >>>>>>>> guidelines for design of Diameter extensions. It will detail >> when >>>>> to >>>>>>>> consider reusing an existing application and when to develop a >>> new >>>>>>>> application. >>>>>>>> >>>>>>>> - Protocol extensions for the management of Diameter entities. >>>> This >>>>> work >>>>>>>> focuses on the standardization of Management Information Bases >>>>> (MIBs) to >>>>>>>> configure Diameter entities (such as the Diameter Base protocol >>> or >>>>>>>> Diameter Credit Control nodes). The usage of other management >>>>> protocols >>>>>>>> for configuring Diameter entities may be future work within the >>>>> group. >>>>>>>> >>>>>>>> - Protocol extensions for bulk and grouped AAA session >>> management. >>>>> The >>>>>>>> aim of this work is to study and standardize a solution for >>>>> handling >>>>>>>> groups of AAA sessions within the Diameter base protocol >> context. >>>>> The >>>>>>>> solution would define how to identify and handle grouped AAA >>>>> sessions in >>>>>>>> commands and operations. >>>>>>>> >>>>>>>> Additionally, Diameter-based systems require interoperability in >>>>> order >>>>>>>> to work. The working group, along with the AD, will need to >>>>> evaluate any >>>>>>>> potential extensions and require verification that the proposed >>>>>>>> extension is needed, and is within the extensibility rules of >>>>> Diameter >>>>>>>> and AAA scope. Coordination with other IETF working groups and >>>>> other >>>>>>>> SDOs (e.g. 3GPP) will be used to ensure this. >>>>>>>> >>>>>>>> Goals and Milestones: >>>>>>>> >>>>>>>> Done - Submit the following two Diameter Mobility documents >>> to >>>>> the >>>>>>>> IESG for consideration as a Proposed Standards:* >>>>> 'Diameter >>>>>>>> Mobile IPv6: Support for Home Agent to Diameter >> Server >>>>>>>> Interaction' * 'Diameter Mobile IPv6: Support for >>>>> Network >>>>>>>> Access Server to Diameter Server Interaction' >>>>>>>> Done - Submit 'Diameter API' to the IESG for consideration >> as >>>>> an >>>>>>>> Informational RFC >>>>>>>> Done - Submit 'Quality of Service Parameters for Usage with >>>>>>>> Diameter' to the IESG for consideration as a Proposed >>>>>>>> Standard. >>>>>>>> Done - Submit 'Diameter QoS Application' to the IESG for >>>>>>>> consideration as a Proposed Standard >>>>>>>> Done - Submit 'Diameter Support for EAP Re-authentication >>>>>>>> Protocol' as DIME working group item >>>>>>>> Done - Submit 'Diameter User-Name and Realm Based Request >>>>> Routing >>>>>>>> Clarifications' as DIME working group item >>>>>>>> Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working >>>>> group >>>>>>>> item >>>>>>>> Done - Submit 'Quality of Service Attributes for Diameter' >> to >>>>> the >>>>>>>> IESG for consideration as a Proposed Standard >>>>>>>> Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for >>>>>>>> consideration as a Proposed Standard >>>>>>>> Done - Submit 'Diameter User-Name and Realm Based Request >>>>> Routing >>>>>>>> Clarifications' to the IESG for consideration as a >>>>> Proposed >>>>>>>> Standard >>>>>>>> Done - Submit 'Diameter NAT Control Application' as DIME >>>>> working >>>>>>>> group item >>>>>>>> Done - Submit 'Diameter Capabilities Update' as DIME working >>>>> group >>>>>>>> item >>>>>>>> Done - Submit 'Diameter Credit Control Application MIB' to >>> the >>>>>>>> IESG for consideration as an Informational RFC >>>>>>>> Done - Submit 'Diameter Base Protocol MIB' to the IESG for >>>>>>>> consideration as an Informational RFC >>>>>>>> Done - Submit 'Diameter Capabilities Update' to the IESG for >>>>>>>> consideration as a Proposed Standard >>>>>>>> Done - Submit 'Diameter Extended NAPTR' as DIME working >> group >>>>> item >>>>>>>> Done - Submit 'Realm-Based Redirection In Diameter' as DIME >>>>>>>> working group item >>>>>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 >>>> Localized >>>>>>>> Routing' as DIME working group item >>>>>>>> Done - Submit 'Diameter Attribute-Value Pairs for >>>> Cryptographic >>>>>>>> Key Transport' as DIME working group item >>>>>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' as >>>> DIME >>>>>>>> working group item >>>>>>>> Done - Submit 'Diameter IKEv2 PSK' as DIME working group >> item >>>>>>>> Done - Submit Revision of 'Diameter Base Protocol' to the >>> IESG >>>>> for >>>>>>>> consideration as a Proposed Standard >>>>>>>> Done - Submit 'Diameter Attribute-Value Pairs for >>>> Cryptographic >>>>>>>> Key Transport' to the IESG for consideration as a >>>>> Proposed >>>>>>>> Standard >>>>>>>> Done - Submit 'Diameter Priority Attribute Value Pairs' to >>> the >>>>>>>> IESG for consideration as a Proposed Standard >>>>>>>> Done - Submit Revision of 'Diameter Network Access Server >>>>>>>> Application - RFC 4005bis' as DIME working group item >>>>>>>> Done - Submit 'Diameter NAT Control Application' to the IESG >>>>> for >>>>>>>> consideration as a Proposed Standard >>>>>>>> Done - Submit 'Diameter IKEv2 PSK' to the IESG for >>>>> consideration >>>>>>>> as a Proposed Standard >>>>>>>> Done - Submit 'Diameter Extended NAPTR' to the IESG for >>>>>>>> consideration as a Proposed Standard >>>>>>>> Done - Submit 'Diameter Support for Proxy Mobile IPv6 >>>> Localized >>>>>>>> Routing' to the IESG for consideration as a Proposed >>>>>>>> Mar 2012 - Submit 'Realm-Based Redirection In Diameter' to the >>>> IESG >>>>>>>> for consideration as a Proposed Standard >>>>>>>> Mar 2012 - Submit Revision of 'Diameter Network Access Server >>>>>>>> Application - RFC 4005bis' to the IESG for >>>>> consideration as a >>>>>>>> Proposed Standard >>>>>>>> May 2012 - Submit 'Diameter Application Design Guidelines' to >> the >>>>> IESG >>>>>>>> for consideration as a BCP document Standard >>>>>>>> Jul 2012 - Submit 'Diameter Support for EAP Re-authentication >>>>>>>> Protocol' to the IESG for consideration as a Proposed >>>>>>>> Standard >>>>>>>> Aug 2012 - Submit a document on 'Protocol extension for bulk and >>>>> group >>>>>>>> signaling' as a working group item >>>>>>>> Aug 2013 - Submit a document on 'Protocol extension for bulk and >>>>> group >>>>>>>> signaling' to the IESG for consideration as a >> Proposed >>>>>>>> Standard >>>>>>>> _______________________________________________ >>>>>>>> IETF-Announce mailing list >>>>>>>> IETF-Announce@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ietf mailing list >>>>>>> Ietf@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ietf >>>>>> >> From sapnas@s-mail.com Tue Jan 17 05:15:23 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AB121F85AE; Tue, 17 Jan 2012 05:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.523 X-Spam-Level: X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[AWL=-0.628, BAYES_50=0.001, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, 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 CulYX76EEMDE; Tue, 17 Jan 2012 05:15:23 -0800 (PST) Received: from s-mail.com (unknown [82.198.169.101]) by ietfa.amsl.com (Postfix) with ESMTP id 07DBC21F85D5; Tue, 17 Jan 2012 05:15:23 -0800 (PST) Received: from apache by s-mail.com with local (Exim 3.36 #3) id 1Rn8sk-0007Kf-00; Tue, 17 Jan 2012 13:15:22 +0000 Message-ID: <4f157468.79663c4b@s-mail.com> Date: Tue, 17 Jan 2012 13:15:20 +0000 From: sapna s To: ietf@ietf.org Subject: Avoidance draft review MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 13:15:23 -0000 Hi, Please review the *silent* draft in dispatch group for security issue avoidance. Author was earlier talking abt top prize to top person. Top Person was having Prior Knowledge about whereabouts of Most Wanted Person (who was dead in APR last or May first week , who was in the region whose head was sometime Musharraf). Web site at www. .com Looks like due to which top person is blocking the review. Please review draft. Thx Sapna S NOTE: ___________________________________________________________ This letter has been delivered unencrypted. We would like to remind you that full end-to-end protection of email correspondence is only provided if both sender and recipient are Secure Mail users. To register FREE at Secure Mail, please visit our site: http://www.s-mail.com From ben@nostrum.com Fri Jan 13 14:00:10 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5879511E8081; Fri, 13 Jan 2012 14:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.368 X-Spam-Level: X-Spam-Status: No, score=-102.368 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, SPF_PASS=-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 Uji+hLsNOd3d; Fri, 13 Jan 2012 14:00:09 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A0FE611E8072; Fri, 13 Jan 2012 14:00:09 -0800 (PST) Received: from dn3-53.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q0DM08Lh064149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jan 2012 16:00:09 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Gen-ART Telechat Review of draft-ietf-kitten-sasl-saml-08 Date: Fri, 13 Jan 2012 16:00:08 -0600 Message-Id: <5FBCE42B-679F-4BD5-B30B-A11664734A0B@nostrum.com> To: draft-ietf-kitten-sasl-saml.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 17 Jan 2012 08:02:05 -0800 Cc: "gen-art@ietf.org Review Team" , The IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 22:00:10 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-kitten-sasl-saml-08 Reviewer: Ben Campbell Review Date: 2012-01-13 IESG Telechat date: 2012-01-19 Summary: This draft is almost ready for publication as a proposed = standard. There are a few minor issues that should be considered first. Note: This is incremental to my review of version 06 at last call. = Version 08 is considerably improved and resolved most of my comments. = But a few still remain. Quoted text below is from that previous review. Major issues: None Minor issues: > -- section 3.2, last paragraph: "=85 needs to correlate the TCP = session from the SASL client with the SAML authentication." >=20 > Please elaborate on this correlation The author added text, but the new text is about correlating response = with request. The text I mentioned was about correlating a TCP = connection to a SAML authentication. > -- section 4, 3rd and 4th paragraph (paragraph a and b) >=20 > These seem like protocol affecting differences. If so, they need = elaboration, such as normative statements and formal definitions, or = references to such. I did not see a response to this comment. > -- section 5, general: >=20 > The section seems to need further elaboration or references I did not see a response to this comment. > Also, this section compresses the interaction with the identity = provider. Why not show the details for those steps like the others? (If = you mean them to be out of scope, then why give as much detail as you = do?) >=20 I did not see a response to this comment. Nits/editorial comments: > -- Pagination is strange throughout the document. (Mostly blank pages, = etc.) It's worse in the PDF version, but still not right in the text = version. Pagination is still strange. I see a few mostly blank pages, diagrams = split across page breaks, etc. > -- section 3, 1st paragraph: "Recall section 5 of [RFC4422] for what = needs to be described here." >=20 > That reads like an author's "to do" note to himself. Has the needed = description been completed, or does it still need to be described? Partially fixed. I suggest s/"needs to be"/"is" > -- section 3.1, first paragraph: >=20 > Is "authorization identifier" the same as "IdP-Identifier"? The paragraph has been updated, but I still have the question.=20 > -- section 3.3, 2nd paragraph: "and SHALL be used to set state in the = server accordingly, and it shall be used by the server" >=20 > Is this new normative language, or a repeat of language from the SAML = spec? >=20 The author changed SHALL to MUST, which leads me to believe my comment = was not clear. I did not object to SHALL. My concern was, with the = reference to RFC4422, it was not clear if the text was introduction a = new normative requirement, or just restating requirements from 4422. If = the second, then it's important to make sure the reader knows which doc = is authoritative. You can do that by keeping the language descriptive, = or by explicitly (and strongly) attributing the language with something = like 'RFC4433 says, "=85. SHALL=85."' If, on the other hand, this is truly a new normative statement, then no = change is needed. > -- section 4, 1st paragraph: >=20 > I have difficulty parsing this. The text is updated, but I still have trouble parsing it. In particular, = I'm not sure what you mean by the phrase "...and appropriate references = of it not referenced elsewhere in this document=85". > -- section 7=20 >=20 > Does the GSS-API description introduce security considerations? If = not, please say so. >=20 I did not see a response to this comment. From evnikita2@gmail.com Tue Jan 17 10:27:11 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C7D21F85C9 for ; Tue, 17 Jan 2012 10:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[AWL=-1.072, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 0scqz07ZGlKY for ; Tue, 17 Jan 2012 10:27:10 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86D4821F85C4 for ; Tue, 17 Jan 2012 10:27:10 -0800 (PST) Received: by obbwc12 with SMTP id wc12so3516398obb.31 for ; Tue, 17 Jan 2012 10:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=djACRjThXy0KgBVlpBjGeOH9RAfj900qu9OeRIa4Cv0=; b=H1M4VN4ON68cjz9xpF+hdNnF8hKprxIFxpDA/VP+ZMQtZBtwKYSxHDWsdkuYI0Hjzr cS+EPPQdv1/T9bu6xzZhKu8CGE9DokRPeR8el0m3ckNrfv/CWooU0KsmnQ14QKyyPhqc AXo/w7OOt8xu3cp/5dxT/o8zdnED3Nub4e0+k= MIME-Version: 1.0 Received: by 10.182.225.9 with SMTP id rg9mr16116137obc.4.1326824830200; Tue, 17 Jan 2012 10:27:10 -0800 (PST) Received: by 10.182.213.71 with HTTP; Tue, 17 Jan 2012 10:27:10 -0800 (PST) In-Reply-To: <20120117175801.2185.72220.idtracker@ietfa.amsl.com> References: <20120117175801.2185.72220.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2012 20:27:10 +0200 Message-ID: Subject: Re: Last Call: (A URN Namespace For The ucode) to Informational RFC From: Mykyta Yevstifeyev To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 18:27:11 -0000 Hello, Having reviewed this document, I think there is no problem with its publication. Several tiny comments: 1) "RFID" in the Introduction needs expanding at first use. 2) ucode-value =3D 32hex-decimal hex-decimal =3D "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "A" / "B" / "C" / "D" / "E" / "F" may be changed to: ucode-value =3D 32HEXDIG and that's RFC 5234 which defines so you may refer to it later. 3) Rules for lexical equivalence: The entire UCODE-URN is case-sensitive. This is at least wrong for the first three chars in URN (the URI scheme name "urn"), that is case-insensitive as per RFC 3986. What's the reason for setting such regulation? Mykyta Yevstifeyev 2012/1/17 The IESG : > > The IESG has received a request from an individual submitter to consider > the following document: > - 'A URN Namespace For The ucode' > =A0 as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-02-14. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > =A0 This document describes a URN (Uniform Resource Name) namespace for > =A0 ucode, an identifier system for objects and places, =A0used in variou= s > =A0 applications for the ubiquitous computing or the Internet of Things. > > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ishikawa-yrpunl-ucode-urn/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ishikawa-yrpunl-ucode-urn/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From rja.lists@gmail.com Tue Jan 17 14:33:39 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68ECC1F0C4A for ; Tue, 17 Jan 2012 14:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.609 X-Spam-Level: X-Spam-Status: No, score=-3.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 lWhItpuRIeWM for ; Tue, 17 Jan 2012 14:33:38 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id C57571F0C49 for ; Tue, 17 Jan 2012 14:33:38 -0800 (PST) Received: by qadz32 with SMTP id z32so1711116qad.10 for ; Tue, 17 Jan 2012 14:33:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=O2mRBWoUHCBf3Umoaf4Lh2ETezzA65LHJsZh+zLVjxM=; b=Jya7DFjaAfyftuxb1lEDNWMMTzuCwN0Q+vX92I/TqILovG1GxmC/2dLxpaOqBIcu7L ZdDEVM12wplWgPkiOxIAn8G5xYOCBp5zfQeIchVv0nnGjoJtPhkGNG0CZeL4Tqo6txou 3D93KjE+8nGl2Jnvaxzz380ZBv+ILo7U9OWf4= Received: by 10.229.76.91 with SMTP id b27mr7093448qck.124.1326839618211; Tue, 17 Jan 2012 14:33:38 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id co15sm46271449qab.1.2012.01.17.14.33.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Jan 2012 14:33:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) Subject: Re: Last Call: (Secure PSK Authentication for IKE) to Experimental RFC From: RJ Atkinson In-Reply-To: <20120117201414.11129.19922.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2012 17:33:34 -0500 Content-Transfer-Encoding: 7bit Message-Id: <53B30146-B51E-4D68-9F0F-B5A4B47F98D3@gmail.com> References: <20120117201414.11129.19922.idtracker@ietfa.amsl.com> To: ietf@ietf.org X-Mailer: Apple Mail (2.1251.1) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 22:33:39 -0000 On 17 Jan 2012, at 15:14 , The IESG wrote: > The IESG has received a request from an individual submitter to consider > the following document: > - 'Secure PSK Authentication for IKE' > as an Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-02-14. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. This also seems fine to me for Experimental RFC. The proposed IANA allocation also seems fine to me. As with the other 2 I-Ds on this topic today, I can't comment on the mathematics or cryptographic aspects. Getting a solid technical review of those aspects would seem sensible. The IRTF CFRG might be one possible source of such a review. Yours, Ran From simon@josefsson.org Wed Jan 18 05:23:28 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489C021F86B0; Wed, 18 Jan 2012 05:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, 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 iKvdyU93fNKB; Wed, 18 Jan 2012 05:23:27 -0800 (PST) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6613521F86A8; Wed, 18 Jan 2012 05:23:25 -0800 (PST) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q0IDNHGM012292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jan 2012 14:23:19 +0100 From: Simon Josefsson To: Ben Campbell Subject: Re: Gen-ART LC Review of draft-ietf-kitten-sasl-saml-06 References: <3D6A7926-001A-409D-BC01-B45AD8C68AEC@nostrum.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120118:draft-ietf-kitten-sasl-saml.all@tools.ietf.org::yrsBGf6aDTDgf52M:JzT X-Hashcash: 1:22:120118:gen-art@ietf.org::wHEopWDI3EBoGvx0:3Gkm X-Hashcash: 1:22:120118:ietf@ietf.org::NeV6j2gj/szvc9Ht:SdSR X-Hashcash: 1:22:120118:ben@nostrum.com::MZTiEIRtjA8ShkU6:Y2eZ Date: Wed, 18 Jan 2012 14:23:17 +0100 In-Reply-To: <3D6A7926-001A-409D-BC01-B45AD8C68AEC@nostrum.com> (Ben Campbell's message of "Thu, 5 Jan 2012 16:32:44 -0600") Message-ID: <87obu16t6i.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "gen-art@ietf.org Review Team" , The IETF , draft-ietf-kitten-sasl-saml.all@tools.ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 13:23:28 -0000 Ben Campbell writes: > -- section 4, 3rd and 4th paragraph (paragraph a and b) > > These seem like protocol affecting differences. If so, they need > elaboration, such as normative statements and formal definitions, or > references to such. > > -- section 5, general: > > The section seems to need further elaboration or references Hello Ben. Thank you for your review. Klaas pointed me at this part and I will try to work this out with you. Re section 4 I believe your comment is based on a misunderstanding. Let me try to explain what the intention is, and we can work out how to fix the text if needed. What is described in paragraph a) and b) are the protocol requirements that (implicitely) follow from GS2. There is nothing particular to this protocol in there. Let's take a step back: The purpose of GS2 is to map any GSS-API mechanism into a SASL mechanism. However, SASL-SAML is defined as a SASL mechanism (because SASL implementers wants it that way). The point of section 4 is to turn this SASL mechanism into a GSS-API mechanism that, after the SAML GSS-API mechanism is used via GS2, becomes identical to the SAML mechanism defined in the rest of the SASL-SAML document. This is a bit convuleted to describe, but this is the gist of it. (It would have been simpler to specify a SAML GSS-API mechanism and then let GS2 convert it to SASL automatically, but some SASL people doesn't want anything to do with GSS-API so this is a compromise to allow them to implement SAML-SASL without touching GSS-API.) I'm thinking that perhaps the above explanation would be useful to have in the document, to give some background. If you agree, I propose to resolve your section 4 comment by making this change: OLD: The SAML SASL mechanism is actually also a GSS-API mechanism. The SAML user takes the role of the GSS-API Initiator and the SAML NEW: This section specify a GSS-API mechanism that when used via the GS2 bridge to SASL behave like the SASL mechanism defined in this document. Thus, it can loosely be said that the SAML SASL mechanism is also a GSS-API mechanism. The SAML user takes the role of the GSS-API Initiator and the SAML Does this resolve your concern re section 4? Re your section 5 comment, I tend to agree. The section is quite brief because it was ripped out of section 3.1. I propose that we simply collapse this section back into 3.1 where it makes more sense. Thus: OLD: - See Section 5 for the channel binding "gs2-cb-flag" field. NEW: - The "gs2-cb-flag" MUST be set to "n" because channel binding data cannot be integrity protected by the SAML negotiation. (Note: In theory channel binding data could be inserted in the SAML flow by the client and verified by the server, but that is currently not supported in SAML.) And then remove section 5 completely. Section 3 and in particular section 3.1 already contains the relevant references and provides the context where the statements make sense. What do you think? Thanks, /Simon From simon@josefsson.org Wed Jan 18 05:29:39 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808FE21F87F5; Wed, 18 Jan 2012 05:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, 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 kVkRUj-l16Sg; Wed, 18 Jan 2012 05:29:39 -0800 (PST) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id AE4AF21F8707; Wed, 18 Jan 2012 05:29:38 -0800 (PST) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q0IDTatD012501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jan 2012 14:29:37 +0100 From: Simon Josefsson To: Ben Campbell Subject: Re: Gen-ART Telechat Review of draft-ietf-kitten-sasl-saml-08 References: <5FBCE42B-679F-4BD5-B30B-A11664734A0B@nostrum.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120118:gen-art@ietf.org::0WiMm4IQC4Me03Pw:0g1 X-Hashcash: 1:22:120118:ietf@ietf.org::nA6wvOZ4yoIZ9Hww:Y+9 X-Hashcash: 1:22:120118:ben@nostrum.com::+6vXyW0Wx11f+5sP:0Aoj X-Hashcash: 1:22:120118:draft-ietf-kitten-sasl-saml.all@tools.ietf.org::dG4Q9pICu7NCEzyQ:FY9H Date: Wed, 18 Jan 2012 14:29:36 +0100 In-Reply-To: <5FBCE42B-679F-4BD5-B30B-A11664734A0B@nostrum.com> (Ben Campbell's message of "Fri, 13 Jan 2012 16:00:08 -0600") Message-ID: <87k44p6svz.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "gen-art@ietf.org Review Team" , The IETF , draft-ietf-kitten-sasl-saml.all@tools.ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 13:29:39 -0000 Ben Campbell writes: >> -- section 7 >> >> Does the GSS-API description introduce security considerations? If >> not, please say so. >> > > I did not see a response to this comment. I missed this in my last e-mail. I propose we add another sub-section of the security considerations like this: 7.5. GSS-API specific security considerations Security issues inherent in GSS-API (RFC 2743) and GS2 (RFC 5801) apply to the SAML GSS-API mechanism defined in this document. Further, and as discussed in section 4, proper TLS server identity verification is critical to the security of the mechanism. I believe this should cover the relevant security considerations. Of course, having more implementation experience with the SAML mechanism used as a GSS-API mechanism may help to identify further security considerations for the GSS-API mechanism. However, I don't believe that is a show-stopper that prevent publication now. /Simon From julian.reschke@gmx.de Wed Jan 18 06:25:32 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A7621F87DE for ; Wed, 18 Jan 2012 06:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.487 X-Spam-Level: X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=-0.887, 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 y05eBpd3TWKY for ; Wed, 18 Jan 2012 06:25:32 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 74D9A21F87B0 for ; Wed, 18 Jan 2012 06:25:31 -0800 (PST) Received: (qmail invoked by alias); 18 Jan 2012 14:25:29 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp011) with SMTP; 18 Jan 2012 15:25:29 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18I9e09zBAIgUPu/Qmr2/IAmY4XAf4qlwHN9dEsJH AtPBXd2YdOkRxu Message-ID: <4F16D655.6080002@gmx.de> Date: Wed, 18 Jan 2012 15:25:25 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Mykyta Yevstifeyev Subject: Re: Last Call: (A URN Namespace For The ucode) to Informational RFC References: <20120117175801.2185.72220.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 14:25:32 -0000 On 2012-01-17 19:27, Mykyta Yevstifeyev wrote: > Hello, > > Having reviewed this document, I think there is no problem with its > publication. Several tiny comments: > > 1) "RFID" in the Introduction needs expanding at first use. > > 2) ucode-value = 32hex-decimal > hex-decimal = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / > "8" / "9" / "A" / "B" / "C" / "D" / "E" / "F" > > may be changed to: > > ucode-value = 32HEXDIG > > and that's RFC 5234 which defines so you may refer to it later. > > 3) > > Rules for lexical equivalence: > > The entire UCODE-URN is case-sensitive. > > This is at least wrong for the first three chars in URN (the URI > scheme name "urn"), that is case-insensitive as per RFC 3986. What's > the reason for setting such regulation? > ... What's case-sensitive depends on context; for instance, when comparing XML namespace URIs or Atom IDs, everything is case-sensitive. See also . Best regards, Julian From klaas@cisco.com Wed Jan 18 11:42:25 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E38911E8073; Wed, 18 Jan 2012 11:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.075 X-Spam-Level: X-Spam-Status: No, score=-8.075 tagged_above=-999 required=5 tests=[AWL=2.524, BAYES_00=-2.599, 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 vC+rYpZ6KhEY; Wed, 18 Jan 2012 11:42:24 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 55C8921F863C; Wed, 18 Jan 2012 11:42:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=5960; q=dns/txt; s=iport; t=1326915744; x=1328125344; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=5VvDKVygN8JL5pDEKe3lTUCiwh/SUUaR+id8m2HYXdc=; b=acdcz8KrXFacUaRchWo93teHtlADukGb5kkVNaIGIcJ1eWIN4LRlRraK cxhjH4XX/Hb+0dzGve7HhhoyunwRHeKwZ2yMg0DbJJgSiZiBW73End4sz WlFGMUSuW2VVC/PV/6RnC1F2kTHGq/EI5SBGrh3CS8EmXuqH+IhHlgKTz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHcfF0+tJXG9/2dsb2JhbAA7CaxGgQKBBYFyAQEBAwEBAQEPAVsLBQsLFDInMAYTIodYCJpKAZ5RiGhPCwkUCQUBBQgFBBEFAQYBAQYBBRQBBAcBCwECAQEIAQEBChAFDiYMRBAFC4E6AQwHAQYKAgcBAQIDDQECAwEBAwIDAgMEAQSCZGMEkTiDW5JH X-IronPort-AV: E=Sophos;i="4.71,531,1320624000"; d="scan'208";a="52127993" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 18 Jan 2012 19:42:24 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q0IJgMwK030979; Wed, 18 Jan 2012 19:42:22 GMT Subject: Re: Gen-ART Telechat Review of draft-ietf-kitten-sasl-saml-08 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Klaas Wierenga In-Reply-To: <5FBCE42B-679F-4BD5-B30B-A11664734A0B@nostrum.com> Date: Wed, 18 Jan 2012 20:42:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9C1CF025-78C6-47F4-9BFD-77F853C72EF9@cisco.com> References: <5FBCE42B-679F-4BD5-B30B-A11664734A0B@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1251.1) Cc: "gen-art@ietf.org Review Team" , The IETF , draft-ietf-kitten-sasl-saml.all@tools.ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 19:42:25 -0000 Hi Ben, On Jan 13, 2012, at 11:00 PM, Ben Campbell wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >=20 > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. >=20 > Document: draft-ietf-kitten-sasl-saml-08 > Reviewer: Ben Campbell > Review Date: 2012-01-13 > IESG Telechat date: 2012-01-19 >=20 > Summary: This draft is almost ready for publication as a proposed = standard. There are a few minor issues that should be considered first. >=20 > Note: This is incremental to my review of version 06 at last call. = Version 08 is considerably improved and resolved most of my comments. = But a few still remain. Quoted text below is from that previous review. Yes, should have informed you about those changes before. I was going to = wait until I had also incorporated Simon's additions, but I realize that = may have been confusing. >=20 > Major issues: >=20 > None >=20 >=20 > Minor issues: >=20 >> -- section 3.2, last paragraph: "=85 needs to correlate the TCP = session from the SASL client with the SAML authentication." >>=20 >> Please elaborate on this correlation >=20 > The author added text, but the new text is about correlating response = with request. The text I mentioned was about correlating a TCP = connection to a SAML authentication. ah ok, but the intention of the text really is to talk about correlating = the session that the SASL client maintains with the SASL server and the = SAML session that the SAML client has with the SAML server. Would you be = ok with changing the wording to that extent? So: "Also, the SASL server needs to correlate the session it has with the SASL client and the SAML authentication by comparing the ID of the SAML authentication request it has issued = with the one it receives in the SAML authentication statement" >=20 >> -- section 4, 3rd and 4th paragraph (paragraph a and b) >>=20 >> These seem like protocol affecting differences. If so, they need = elaboration, such as normative statements and formal definitions, or = references to such. >=20 > I did not see a response to this comment. see Simon's comments >=20 >> -- section 5, general: >>=20 >> The section seems to need further elaboration or references >=20 > I did not see a response to this comment. >=20 idem >> Also, this section compresses the interaction with the identity = provider. Why not show the details for those steps like the others? (If = you mean them to be out of scope, then why give as much detail as you = do?) >>=20 >=20 > I did not see a response to this comment. I want to give enough details for implementers to understand the full = flow, even though those steps are out-of-scope for this specification. I = thought the [ ] brackets would convey that, do you think it is clearer = to leave that part out altogether? >=20 > Nits/editorial comments: >=20 >> -- Pagination is strange throughout the document. (Mostly blank = pages, etc.) It's worse in the PDF version, but still not right in the = text version. >=20 > Pagination is still strange. I see a few mostly blank pages, diagrams = split across page breaks, etc. hmm, strange, I removed some empty lines and in my version it nicely = broke on session headings, but I'll double check all generated versions = next iteration.=20 >=20 >> -- section 3, 1st paragraph: "Recall section 5 of [RFC4422] for what = needs to be described here." >>=20 >> That reads like an author's "to do" note to himself. Has the needed = description been completed, or does it still need to be described? >=20 > Partially fixed. I suggest s/"needs to be"/"is" ok, will do >=20 >> -- section 3.1, first paragraph: >>=20 >> Is "authorization identifier" the same as "IdP-Identifier"? >=20 > The paragraph has been updated, but I still have the question.=20 It is not, I will add text on that >=20 >> -- section 3.3, 2nd paragraph: "and SHALL be used to set state in = the server accordingly, and it shall be used by the server" >>=20 >> Is this new normative language, or a repeat of language from the SAML = spec? >>=20 >=20 > The author changed SHALL to MUST, which leads me to believe my comment = was not clear. I did not object to SHALL. My concern was, with the = reference to RFC4422, it was not clear if the text was introduction a = new normative requirement, or just restating requirements from 4422. If = the second, then it's important to make sure the reader knows which doc = is authoritative. You can do that by keeping the language descriptive, = or by explicitly (and strongly) attributing the language with something = like 'RFC4433 says, "=85. SHALL=85."' >=20 > If, on the other hand, this is truly a new normative statement, then = no change is needed. right, now I get it. It is indeed intended in the 4422 sense, so I will = take your suggestion >=20 >> -- section 4, 1st paragraph: >>=20 >> I have difficulty parsing this. >=20 > The text is updated, but I still have trouble parsing it. In = particular, I'm not sure what you mean by the phrase "...and appropriate = references of it not referenced elsewhere in this document=85". OK, I propose to just change it to: "This section and its sub-sections are not required for SASL implementors, but this section MUST be observed to implement the GSS- API mechanism discussed below." >> -- section 7=20 >>=20 >> Does the GSS-API description introduce security considerations? If = not, please say so. >>=20 >=20 > I did not see a response to this comment. see response Simon. Klaas >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From touch@isi.edu Wed Jan 18 18:24:09 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6904411E80ED for ; Wed, 18 Jan 2012 18:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.216 X-Spam-Level: X-Spam-Status: No, score=-103.216 tagged_above=-999 required=5 tests=[AWL=-0.617, 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 Wv1tg9eTWUjH for ; Wed, 18 Jan 2012 18:24:08 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8586D11E80F9 for ; Wed, 18 Jan 2012 18:24:04 -0800 (PST) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q0J2Nebo023366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Jan 2012 18:23:41 -0800 (PST) Message-ID: <4F177EAC.7060407@isi.edu> Date: Wed, 18 Jan 2012 18:23:40 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Kaushal Shriyan Subject: Re: Protocol Definition References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 02:24:09 -0000 On 1/3/2012 5:53 PM, Kaushal Shriyan wrote: > Hi, > > Can someone please explain me the term "Protocol". Does it also mean it > has some software code underlying beneath it. Please help me understand. My 2 cents: A protocol is a defined set of rules that function at multiple locations (communication endpoints) that enable shared state (communication), and is composed of: a defined set of messages ("on the wire" part) a defined set of states (localized endpoint state) a set of rules that relate message arrival, message departure, time (optionally), and state transition It's a lot like computation where the input is the received message sequence and the output is the transmitted message sequence. A protocol is to communications as an algorithm is to computation. Code can be used to implement an algorithm. Code can be used to implement a protocol on an endpoint. I.e., a protocol is just a special kind of algorithm - one that is used to support communication. A running algorithm is called a process or thread (typically). Since a protocol *is* an algorithm, a running protocol is just called a communicating process or thread, IMO. A "session" or "connection" defines an association between multiple parties running the same protocol and thus communicating. Joe From bernard_aboba@hotmail.com Wed Jan 18 19:17:29 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1694311E80F8; Wed, 18 Jan 2012 19:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.304 X-Spam-Level: X-Spam-Status: No, score=-102.304 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HTML_MESSAGE=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 Rv4PkC9oD4Oy; Wed, 18 Jan 2012 19:17:27 -0800 (PST) Received: from blu0-omc2-s20.blu0.hotmail.com (blu0-omc2-s20.blu0.hotmail.com [65.55.111.95]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4C511E8093; Wed, 18 Jan 2012 19:17:27 -0800 (PST) Received: from BLU152-W47 ([65.55.111.71]) by blu0-omc2-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Jan 2012 19:17:27 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_8a84e9de-00de-453d-bae0-dbb3494ff61c_" X-Originating-IP: [24.17.217.162] From: Bernard Aboba To: , Subject: Review of draft-ietf-radext-radsec Date: Wed, 18 Jan 2012 19:17:26 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jan 2012 03:17:27.0526 (UTC) FILETIME=[DF180060:01CCD658] X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 03:17:29 -0000 --_8a84e9de-00de-453d-bae0-dbb3494ff61c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a review of "TLS Encryption for RADIUS" draft-ietf-radext-radsec.=20 Overall=2C this draft was a pleasant to read=2C and it is clear that a lot = of thought as well as implementation experience has gone into it.=20 Kudos to the authors.=20 General Issues There is a considerable amount of text relating to dynamic discovery in thi= s document=2C yet there is only an informational reference to it.=20 Since inserting a normative reference to dynamic discovery could delay the = publication of this document unnecessarily=2C my recommendation is to consolidate some of = the dynamic discovery material into a single section in which you can discuss the impli= cations=2C while clearly indicating the status of the dynamic discovery work (e.g. still und= er development=2C optional to implement along with RADSEC=2C etc.).=20 For example=2C you might consider consolidating the following text from Sec= tions 3.1 and 6=20 and placing it prior to the current Section 3.1: Section 3.X: Implications of Dynamic Peer Discovery One mechanism to discover RADIUS over TLS peers dynamically via DNS=20 is specified in [I-D.ietf-radext-dynamic-discovery]. While this mechani= sm is still under development and therefore is not a normative dependency o= f RADIUS/TLS=2C the use of dynamic discovery has potential future implicat= ions that are important to understand.=20 If dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery] is used=2C peer authentication alone is not sufficient=3B the peer must also be authorised to perform user authentications. In these cases=2C the trust fabric cannot depend on peer authentication methods like DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be properly authorised. Typically=2C this can be achieved by adding appropriate authorisation fields into a X.509 certificate. Such fields include SRV authority [RFC4985]=2C subjectAltNames=2C or a defined list of certificate fingerprints. Operators of a RADIUS/TLS infrastructure should define their own authorisation trust model and apply this model to the certificates. The checks enumerated in Section 2.3 provide sufficient flexibility for the implementation of authorisation trust models. [BA] I think you need to be more prescriptive here. Are there specific fields that a RADSEC TLS certificate should contain? Having individual implementations/deployments defining their own authorization schemes seems like a bad idea. =20 In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery]=2C a RADIUS/TLS node needs to be able to accept connections from a large=2C not previously known=2C group of hosts=2C possibly the whole internet. In this case=2C the server's RADIUS/TLS port can not be protected from unauthorised connection attempts with measures on the network layer=2C i.e. access lists and firewalls. This opens more attack vectors for Distributed Denial of Service attacks=2C just like any other service that is supposed to serve arbitrary clients (like for example web servers). In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery]=2C X.509 certificates are the only proof of authorisation for a connecting RADIUS/TLS nodes. Special care needs to be taken that certificates get verified properly according to the chosen trust model (particularly: consulting CRLs=2C checking critical extensions=2C checking subjectAltNames etc.) to prevent unauthorised connections. Other comments Section 1 One mechanism to discover RADIUS over TLS peers with DNS is specified in [I-D.ietf-radext-dynamic-discovery]. [BA] Recommend moving this to a section devoted to dynamic discovery.=20 Section 2.1 See section Section 3.3 (4) and (5) for considerations regarding separation of authentication=2C accounting and dynauth traffic. [BA] Recommend changing to: "See Section 3.3 for considerations regarding separation of authentication=2C accounting and dynamic authorisation traffic." Section 2.3 4. start exchanging RADIUS datagrams. Note Section 3.3 (1) ). The shared secret to compute the (obsolete) MD5 integrity checks and attribute encryption MUST be "radsec" (see Section 3.3 (2) ). Section 3.1 (3) If dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery] is used=2C peer authentication alone is not sufficient=3B the peer must also be authorised to perform user authentications. In these cases=2C the trust fabric cannot depend on peer authentication methods like DNSSEC to identify RADIUS/TLS nodes. The nodes also need to be properly authorised. Typically=2C this can be achieved by adding appropriate authorisation fields into a X.509 certificate. Such fields include SRV authority [RFC4985]=2C subjectAltNames=2C or a defined list of certificate fingerprints. Operators of a RADIUS/TLS infrastructure should define their own authorisation trust model and apply this model to the certificates. The checks enumerated in Section 2.3 provide sufficient flexibility for the implementation of authorisation trust models. As noted above=2C I'd suggest removing this material from Section 3.1 and=20 consolidating it with other dynamic-discovery material. =20 Section 3.3 Note well: it is not required for an implementation to actually process these packet types. It is sufficient that upon receiving such a packet=2C an unconditional NAK is sent back to indicate that the action is not supported. [BA] What Error-Cause attribute value should be included within the NAK to = make it clear that the action is not supported? Error 406 "Unsupported Extension"? That is what RFC 5176 Section 3.5 seems to indicate.=20 There is no RADIUS datagram to signal an Accounting NAK. Clients may be misconfigured to send Accounting packets to a RADIUS/TLS server which does not wish to process their Accounting packet. The server will need to silently drop the packet. The client will need to deduce from the absence of replies that it is misconfigured=3B no negative ICMP response will reveal this. [BA] This seems like a bad idea. How about requiring implementations not supporting Accounting to respond with an Accounting-Response containing Error-Cause attribute value 406? Implementations receiving an Accounting-R= esponse with this Error-Cause can be required to treat this like an ICMP response.= =20 Section 4 As a consequence=2C the selection of transports to communicate from a client to a server is a manual administrative action. An automatic fallback to RADIUS/UDP is NOT RECOMMENDED=2C as it may lead to down- bidding attacks on the peer communication. [BA] If a fixed shared secret "radsec" is used alongside fallback to RADIUS= /UDP=2C that seems more like a MUST NOT!! Section 6 In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery]=2C a RADIUS/TLS node needs to be able to accept connections from a large=2C not previously known=2C group of hosts=2C possibly the whole internet. In this case=2C the server's RADIUS/TLS port can not be protected from unauthorised connection attempts with measures on the network layer=2C i.e. access lists and firewalls. This opens more attack vectors for Distributed Denial of Service attacks=2C just like any other service that is supposed to serve arbitrary clients (like for example web servers). In the case of dynamic peer discovery as per [I-D.ietf-radext-dynamic-discovery]=2C X.509 certificates are the only proof of authorisation for a connecting RADIUS/TLS nodes. Special care needs to be taken that certificates get verified properly according to the chosen trust model (particularly: consulting CRLs=2C checking critical extensions=2C checking subjectAltNames etc.) to prevent unauthorised connections. [BA] I'd recommend collecting this and other dynamic-discovery related mate= rial into a separate section prior to 3.1.=20 Appendix C. Assessment of Crypto-Agility Requirements The RADIUS Crypto-Agility Requirements (link to RFC once issued here) defines numerous classification criteria for protocols that strive to enhance the security of RADIUS. It contains mandatory (M) and recommended (R) criteria which crypto-agile protocols have to fulfill. The authors believe that the following assessment about the crypto-agility properties of RADIUS/TLS are true. [BA] The Crypto-Agility RFC is now published so you should reference that. = = --_8a84e9de-00de-453d-bae0-dbb3494ff61c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
      This is a review of "TLS Encryption for RADIUS" draft-ietf-radext-radsec. <= br>
      Overall=2C this draft was a pleasant to read=2C and it is clear that= a lot of thought as well as implementation experience has gone into it.
      Kudos to the authors.

      General Issue= s

      There is a considerable amount of text relating to dynamic discove= ry in this document=2C yet
      there is only an informational reference to i= t.

      Since inserting a normative reference to dynamic discovery could= delay the publication of
      this document unnecessarily=2C my recommendati= on is to consolidate some of the dynamic
      discovery material into a singl= e section in which you can discuss the implications=2C while
      clearly ind= icating the status of the dynamic discovery work (e.g. still under developm= ent=2C optional to
      implement along with RADSEC=2C etc.).

      For exa= mple=2C you might consider consolidating the following text from Sections 3= .1 and 6
      and placing it prior to the current Section 3.1:

      Sectio= n 3.X: =3B Implications of Dynamic Peer Discovery

       =3B =3B One mechanism to discover RADIUS over TLS peers dynamicall= y via DNS
       =3B =3B is specified in [I-D.ietf-radext-dynamic-discovery]. = =3B While this mechanism
       =3B =3B is still under development and therefore is not a normativ= e dependency of
       =3B =3B RADIUS/TLS=2C the use of dynamic discovery has potential f= uture implications that are
       =3B =3B important to understand.

       =3B =3B If dynam= ic peer discovery as per
       =3B =3B [I-D.ietf-radext-dynamic-disco= very] is used=2C peer authentication
       =3B =3B alone is not suffi= cient=3B the peer must also be authorised to perform
       =3B =3B us= er authentications. =3B In these cases=2C the trust fabric cannot depen= d
       =3B =3B on peer authentication methods like DNSSEC to identif= y RADIUS/TLS
       =3B =3B nodes. =3B The nodes also need to be p= roperly authorised. =3B Typically=2C
       =3B =3B this can be ac= hieved by adding appropriate authorisation fields into
       =3B =3B = a X.509 certificate. =3B Such fields include SRV authority [RFC4985]=2C=
       =3B =3B subjectAltNames=2C or a defined list of certificate fi= ngerprints.
       =3B =3B Operators of a RADIUS/TLS infrastructure sh= ould define their own
       =3B =3B authorisation trust model and app= ly this model to the certificates.
       =3B =3B The checks enumerate= d in Section 2.3 provide sufficient flexibility
       =3B =3B for the= implementation of authorisation trust models.

      [BA] I think you need= to be more prescriptive here. =3B Are there specific
      fields that a = RADSEC TLS certificate should contain? =3B Having individual
      impleme= ntations/deployments defining their own authorization schemes seems
      like= a bad idea. =3B

       =3B =3B In the case of dynamic peer d= iscovery as per
       =3B =3B [I-D.ietf-radext-dynamic-discovery]=2C = a RADIUS/TLS node needs to be
       =3B =3B able to accept connection= s from a large=2C not previously known=2C group
       =3B =3B of host= s=2C possibly the whole internet. =3B In this case=2C the server's
      &= nbsp=3B =3B RADIUS/TLS port can not be protected from unauthorised conn= ection
       =3B =3B attempts with measures on the network layer=2C i= .e. access lists and
       =3B =3B firewalls. =3B This opens more= attack vectors for Distributed Denial of
       =3B =3B Service attac= ks=2C just like any other service that is supposed to
       =3B =3B s= erve arbitrary clients (like for example web servers).

       =3B = =3B In the case of dynamic peer discovery as per
       =3B =3B [I-D.i= etf-radext-dynamic-discovery]=2C X.509 certificates are the only
       = =3B =3B proof of authorisation for a connecting RADIUS/TLS nodes. = =3B Special
       =3B =3B care needs to be taken that certificates ge= t verified properly
       =3B =3B according to the chosen trust model= (particularly: consulting CRLs=2C
       =3B =3B checking critical ex= tensions=2C checking subjectAltNames etc.) to
       =3B =3B prevent u= nauthorised connections.

      Other comments

      Section 1

      &nbs= p=3B =3B One mechanism to discover RADIUS over TLS peers with DNS is sp= ecified in
       =3B =3B [I-D.ietf-radext-dynamic-discovery].

      = [BA] Recommend moving this to a section devoted to dynamic discovery.
      <= br>Section 2.1

       =3B =3B See
       =3B =3B section Sect= ion 3.3 (4) and (5) for considerations regarding
       =3B =3B separa= tion of authentication=2C accounting and dynauth traffic.

      [BA] Recom= mend changing to:

       =3B =3B "See Section 3.3 for consideratio= ns regarding separation of
       =3B =3B =3B authentication=2C ac= counting and dynamic authorisation traffic."

      Section 2.3

      &nbs= p=3B =3B 4. =3B start exchanging RADIUS datagrams. =3B Note Sec= tion 3.3 (1) ). =3B The
       =3B =3B =3B =3B =3B&nbs= p=3B shared secret to compute the (obsolete) MD5 integrity checks and
      &n= bsp=3B =3B =3B =3B =3B =3B attribute encryption MUST be= "radsec" (see Section 3.3 (2) ).

      Section 3.1

       =3B = =3B (3) If dynamic peer discovery as per
       =3B =3B [I-D.ietf-rade= xt-dynamic-discovery] is used=2C peer authentication
       =3B =3B al= one is not sufficient=3B the peer must also be authorised to perform
      &nb= sp=3B =3B user authentications. =3B In these cases=2C the trust fab= ric cannot depend
       =3B =3B on peer authentication methods like D= NSSEC to identify RADIUS/TLS
       =3B =3B nodes. =3B The nodes a= lso need to be properly authorised. =3B Typically=2C
       =3B = =3B this can be achieved by adding appropriate authorisation fields into =3B =3B a X.509 certificate. =3B Such fields include SRV auth= ority [RFC4985]=2C
       =3B =3B subjectAltNames=2C or a defined list= of certificate fingerprints.
       =3B =3B Operators of a RADIUS/TLS= infrastructure should define their own
       =3B =3B authorisation t= rust model and apply this model to the certificates.
       =3B =3B Th= e checks enumerated in Section 2.3 provide sufficient flexibility
       = =3B =3B for the implementation of authorisation trust models.

      As= noted above=2C I'd suggest removing this material from Section 3.1 and consolidating it with other dynamic-discovery material.  =3B

      Se= ction 3.3

       =3B =3B Note well: it is not required for an impl= ementation
       =3B =3B to actually process these packet types. = =3B It is sufficient that upon
       =3B =3B receiving such a packet= =2C an unconditional NAK is sent back to
       =3B =3B indicate that = the action is not supported.

      [BA] What Error-Cause attribute value s= hould be included within the NAK to make it
      clear that the action is not= supported? =3B Error 406 "Unsupported Extension"?
      That is what RFC = 5176 Section 3.5 seems to indicate.

       =3B =3B There
       = =3B =3B is no RADIUS datagram to signal an Accounting NAK. =3B Clie= nts may be
       =3B =3B misconfigured to send Accounting packets to = a RADIUS/TLS server which
       =3B =3B does not wish to process thei= r Accounting packet. =3B The server will
       =3B =3B need to si= lently drop the packet. =3B The client will need to deduce
       =3B&= nbsp=3B from the absence of replies that it is misconfigured=3B no negative=
       =3B =3B ICMP response will reveal this.

      [BA] This seems= like a bad idea. =3B How about requiring implementations not
      suppor= ting Accounting to respond with an Accounting-Response containing
      Error-= Cause attribute value 406? =3B Implementations receiving an Accounting-= Response
      with this Error-Cause can be required to treat this like an ICM= P response.

      Section 4

       =3B =3B As a consequence=2C t= he selection of transports to communicate from a
       =3B =3B client= to a server is a manual administrative action. =3B An automatic
      &nb= sp=3B =3B fallback to RADIUS/UDP is NOT RECOMMENDED=2C as it may lead t= o down-
       =3B =3B bidding attacks on the peer communication.
      <= br>[BA] If a fixed shared secret "radsec" is used alongside fallback to RAD= IUS/UDP=2C
      that seems more like a MUST NOT!!

      Section 6

      &nb= sp=3B =3B In the case of dynamic peer discovery as per
       =3B = =3B [I-D.ietf-radext-dynamic-discovery]=2C a RADIUS/TLS node needs to be =3B =3B able to accept connections from a large=2C not previously= known=2C group
       =3B =3B of hosts=2C possibly the whole internet= . =3B In this case=2C the server's
       =3B =3B RADIUS/TLS port = can not be protected from unauthorised connection
       =3B =3B attem= pts with measures on the network layer=2C i.e. access lists and
       =3B=  =3B firewalls. =3B This opens more attack vectors for Distributed = Denial of
       =3B =3B Service attacks=2C just like any other servic= e that is supposed to
       =3B =3B serve arbitrary clients (like for= example web servers).

       =3B =3B In the case of dynamic peer = discovery as per
       =3B =3B [I-D.ietf-radext-dynamic-discovery]=2C= X.509 certificates are the only
       =3B =3B proof of authorisation= for a connecting RADIUS/TLS nodes. =3B Special
       =3B =3B car= e needs to be taken that certificates get verified properly
       =3B&nbs= p=3B according to the chosen trust model (particularly: consulting CRLs=2C<= br> =3B =3B checking critical extensions=2C checking subjectAltName= s etc.) to
       =3B =3B prevent unauthorised connections.

      [BA] I'd recommend collecting this and other dynamic-discovery related mat= erial
      into a separate section prior to 3.1.

      Appendix C. Assessme= nt of Crypto-Agility Requirements


       =3B =3B The RADIUS Cr= ypto-Agility Requirements (link to RFC once issued here)
       =3B = =3B defines numerous classification criteria for protocols that strive to =3B =3B enhance the security of RADIUS. =3B It contains mand= atory (M) and
       =3B =3B recommended (R) criteria which crypto-agi= le protocols have to
       =3B =3B fulfill. =3B The authors belie= ve that the following assessment about the
       =3B =3B crypto-agili= ty properties of RADIUS/TLS are true.

      [BA] The Crypto-Agility RFC is= now published so you should reference that.
      = --_8a84e9de-00de-453d-bae0-dbb3494ff61c_-- From Hannes.Tschofenig@gmx.net Thu Jan 19 02:22:09 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467DB21F86D0 for ; Thu, 19 Jan 2012 02:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.015 X-Spam-Level: X-Spam-Status: No, score=-102.015 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, 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 gdBzQgPT1AVo for ; Thu, 19 Jan 2012 02:22:08 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2106A21F8476 for ; Thu, 19 Jan 2012 02:22:05 -0800 (PST) Received: (qmail invoked by alias); 19 Jan 2012 10:22:03 -0000 Received: from unknown (EHLO [10.255.135.235]) [192.100.123.77] by mail.gmx.net (mp023) with SMTP; 19 Jan 2012 11:22:03 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19sJ0M/ZhFsP+YZqH076mHxxqAuSubp9BkenTlkw4 0XQ1Zk6BsxEZmS From: Hannes Tschofenig Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Smart Object Security Workshop Announcement Date: Thu, 19 Jan 2012 12:21:57 +0200 Message-Id: <9E2944CA-16CF-4985-9DA6-B7A1A03EFF10@gmx.net> To: IETF-Discussion list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 10:22:09 -0000 Hi all, we would like to make you aware of a workshop on Smart Object Security = on the 23rd March 2012 in Paris (attached to the IETF meeting). We are seeking input from participants to share their thoughts about the = ability to utilize existing and widely deployed security mechanisms for = smart objects. In particular, we are interested to hear about: =95 What techniques for issuing credentials have been deployed? =95 What extensions are useful to make existing security = protocols more suitable for smart objects? =95 What type of credentials are frequently used? =95 What experience has been gained when implementing and = deploying application layer, transport layer, network layer, and link = layer security mechanisms (or a mixture of all of them)? =95 How can =93clever=94 implementations make security protocols = a better fit for constrained devices? =95 Are there lessons we can learn from existing deployments? More workshop details can be found on the webpage of our host: http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ If you plan to participate at the workshop please drop us a message = (with a short description of what you are planning to contribute) and we = can give you an early notice regarding your participation.=20 Greetings The Workshop Organizers From stephen.farrell@cs.tcd.ie Thu Jan 19 04:04:41 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AF921F8623 for ; Thu, 19 Jan 2012 04:04:41 -0800 (PST) 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 kpNEZ3ahABEL for ; Thu, 19 Jan 2012 04:04:36 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id BF24A21F8621 for ; Thu, 19 Jan 2012 04:04:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 404FA15F812; Thu, 19 Jan 2012 12:04:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1326974674; bh=KmTgAKw77I7Sbq RPtqI6L1/C/L7/5ZnT0QgzXDTjdg0=; b=07ipHdK9AE0jntzL676B3yO1vr7eoA scgTjSfBoFhJ8Mv4CaKzdmImQSxJTaXksQFmU5k0CKTj1wehCeTF8x4xHhpygrzf Fz+9ldTRIEt1xYTy0lV9y0DfOPxMo45vcPSzvj2zOZ+UFnUtnOaT4vAK1eyOoTWu lICrTzxAyCPhrXKRzPjAF7iRWDpqG1m4mWjxfzfMxdOamBn6jQNek+r6dz5qIicA d4CU4JJ2HcMX0gG7kN25eonleEqd5AGE4C0LSrYPHvvcMzmur7UAC8qy5mufMiPQ uA55AiU5kapGzbVRTr2KD1zT71LhDm+KYJRBWTcQ8+iFFBMhjSqWX5cQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id zl4nKZylW1bk; Thu, 19 Jan 2012 12:04:34 +0000 (GMT) Received: from [10.87.48.9] (unknown [86.46.16.116]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id BA87615F811; Thu, 19 Jan 2012 12:04:34 +0000 (GMT) Message-ID: <4F1806D2.4050702@cs.tcd.ie> Date: Thu, 19 Jan 2012 12:04:34 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: Smart Object Security Workshop Announcement References: <9E2944CA-16CF-4985-9DA6-B7A1A03EFF10@gmx.net> In-Reply-To: <9E2944CA-16CF-4985-9DA6-B7A1A03EFF10@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF-Discussion list X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 12:04:41 -0000 Hi Hannes, Sounds interesting. I'll try make it there. Cheers, S On 01/19/2012 10:21 AM, Hannes Tschofenig wrote: > Hi all, > > we would like to make you aware of a workshop on Smart Object Security on the 23rd March 2012 in Paris (attached to the IETF meeting). > > We are seeking input from participants to share their thoughts about the ability to utilize existing and widely deployed security mechanisms for smart objects. > > In particular, we are interested to hear about: > • What techniques for issuing credentials have been deployed? > • What extensions are useful to make existing security protocols more suitable for smart objects? > • What type of credentials are frequently used? > • What experience has been gained when implementing and deploying application layer, transport layer, network layer, and link layer security mechanisms (or a mixture of all of them)? > • How can “clever” implementations make security protocols a better fit for constrained devices? > • Are there lessons we can learn from existing deployments? > > More workshop details can be found on the webpage of our host: > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ > > If you plan to participate at the workshop please drop us a message (with a short description of what you are planning to contribute) and we can give you an early notice regarding your participation. > > Greetings > The Workshop Organizers > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From jnc@mercury.lcs.mit.edu Thu Jan 19 08:04:45 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1257721F8678 for ; Thu, 19 Jan 2012 08:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_60=1, 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 QRde6XODB2sh for ; Thu, 19 Jan 2012 08:04:44 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id A953221F8579 for ; Thu, 19 Jan 2012 08:04:37 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BDD0018C0C6; Thu, 19 Jan 2012 11:04:34 -0500 (EST) To: ietf@ietf.org Subject: Story: "Next battle over Net ramps up worldwide" Message-Id: <20120119160434.BDD0018C0C6@mercury.lcs.mit.edu> Date: Thu, 19 Jan 2012 11:04:34 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 16:04:45 -0000 For those who haven't seen it, here: Next battle over Net ramps up worldwide http://www.politico.com/news/stories/0112/71625.html is an interesting story, one which is also fairly accurate (often not true of major media stories about the Internet). Noel From stpeter@stpeter.im Thu Jan 19 08:53:29 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E8B21F8678; Thu, 19 Jan 2012 08:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.658 X-Spam-Level: X-Spam-Status: No, score=-102.658 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 aL4tqjya32ZD; Thu, 19 Jan 2012 08:53:27 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2F09E21F8675; Thu, 19 Jan 2012 08:53:26 -0800 (PST) Received: from dhcp-64-101-72-243.cisco.com (unknown [64.101.72.243]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2F95A40058; Thu, 19 Jan 2012 10:02:52 -0700 (MST) Message-ID: <4F184A85.60604@stpeter.im> Date: Thu, 19 Jan 2012 09:53:25 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: david.black@emc.com Subject: Re: Gen-ART review of draft-daboo-webdav-sync-06 References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC94C9@MX14A.corp.emc.com> <250FD273F8360ED86D73260F@cyrus.local> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B9F@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B9F@MX14A.corp.emc.com> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: gen-art@ietf.org, arnaud.quillaud@oracle.com, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 16:53:29 -0000 Hi David, The text changes that Cyrus proposed have been incorporated into a revised I-D: http://tools.ietf.org/rfcdiff?url2=draft-daboo-webdav-sync-07 Please let us know if the new version accurately reflects your discussion with the authors. Thanks! Peter On 1/2/12 12:55 PM, david.black@emc.com wrote: > Hi Cyrus, > > The proposed changes for the two major issues look good to me: > > [1] I'm pleased that the concern about adding elements turned out to be a wording issue. > > [2] Your proposed new text is fine - it provides adequate notice/warning about possible > collection inconsistency, so I'm ok with not providing pseudo-code. > > I'll leave the Downref issue ([3]) for you and Peter to work out with the IESG, and I'm > fine with continued use of your name in the examples if that's common practice. > > Thanks, > --David > >> -----Original Message----- >> From: Cyrus Daboo [mailto:cyrus@daboo.name] >> Sent: Monday, January 02, 2012 2:44 PM >> To: Black, David; arnaud.quillaud@oracle.com; gen-art@ietf.org; ietf@ietf.org >> Cc: stpeter@stpeter.im >> Subject: Re: Gen-ART review of draft-daboo-webdav-sync-06 >> >> Hi David, >> Thank you for your review. Comments inline: >> >> --On December 27, 2011 11:07:49 PM -0500 david.black@emc.com wrote: >> >>> [1] -Major- Section 3.5 does not appear to cover the case reporting added >>> elements on a subsequent synchronization. The problem may be that the >>> word "changed" as used in Section 3.5.1 is assumed to cover adding an >>> element - if so, that's not a good assumption, and the addition case >>> should be explicitly called out in the title and body of Section 3.5.1. >> >> The first sentence of 3.5.1 is: >> >> A member URL MUST be reported as changed if it has been mapped as a >> member of the target collection since the request sync-token was >> generated. >> >> The term "mapped" implies creation/addition of a new resource in this case. >> That may not be obvious to anyone who is not intimately familiar with >> WebDAV terminology here, so I propose changing that to: >> >> A member URL MUST be reported as changed if it has been newly mapped as >> a member of the target collection since the request sync-token was >> generated (e.g., when a new resource has been created as a child of the >> collection). >> >>> [2] -Major- The operations to retrieve changed members of a collection >>> are not atomic wrt the operation that obtains a report on what has >>> changed; collection changes can occur between retrieving the report and >>> retrieving the changed elements or while retrieving the changed elements. >>> For this reason, simply obtaining a change report and then retrieving the >>> elements that have changed according to the report may not result in a >>> consistent (e.g., as of a point in time) copy of a collection. I believe >>> that this absence of atomicity is a WebDAV "feature", as opposed to a >>> "bug", but I believe that this behavior and what to do about it should be >>> discussed in the draft. I suggest the following, possibly to the end of >>> section 3.1 >>> >>> i) Add a sentence or two to warn that obtaining a change report and then >>> retrieving the changed elements may not result in a consistent local >>> version of the collection if nothing else is done because changes may >>> have occurred in the interim. >>> >>> ii Add a discussion of how to ensure that a local copy of the collection >>> is consistent. The basic idea is to re-presented the sync token for that >>> copy to the server after the changed elements have been retrieved; the >>> local copy is consistent if the server reports that there have been no >>> changes. Some pseudo-code may help, e.g.: >>> >>> GetSyncCollectionReport(in token, out newtoken, out report); >>> while (ReportHasChangedItems(report) { >>> GetChangedItems(report) >>> token = newtoken; >>> GetSyncCollectionReport(in token, out newtoken, out report); >>> } >>> >>> Actual code should include a counter that counts the number of iterations >>> of the while loop and exits with an error if the number of iterations >>> exceeds some limit; that error exit implies that the collection is >>> (currently) changing too rapidly to obtain a consistent local version. >> >> Good point. I agree that this deserves some additional text to clarify this >> situation. However, I would rather not go into too much detail of how >> clients "re-sync" in cases like this as there are a bunch of different ways >> that could happen each of which depends on exactly what the client is >> trying to do (e.g., in a lot of cases clients will be doing two-way syncs >> so will need to reconcile server and local changes within the loop you >> propose above - the details of that are not in scope for this >> specification). What I propose is the addition of the following paragraph >> to the end of Section 3.1: >> >> Typically, a client will use the synchronization report to retrieve the >> list of changes, and will follow that with requests to retrieve the >> content of changed resources. It is possible that additional changes to >> the collection could occur between the time of the synchronization >> report and resource content retrieval, which could result in an >> inconsistent view of the collection. When clients use this method of >> synchronization, they need to be aware that such additional changes >> could occur, and track them through normal means (e.g., differences >> between the ETag values returned in the synchronization report and >> those returned when actually fetching resource content), conditional >> requests as described in Section 5, or repeating the synchronization >> process until no changes are returned. >> >>> [3] -Minor- idnits 2.12.12 reports a Downref to RFC 5842. Please >>> consult your Area Director (Peter Saint-Andre) to determine what to do >>> about this Downref (it requires attention, but may not require changes to >>> the draft). >> >> Working with IESG on this one. >> >>> Nit: I suggest not using the author's own name (cyrusdaboo) in the >>> examples. Someone may copy the code from the resulting RFC. >> >> This has been common practice in most of the other CalDAV/CardDAV RFCs I >> have worked on and has not been the source of any problems, so I would >> rather leave this unchanged. If there is an official IETF policy on using >> "real names" in examples, then I would be happy to change to follow that, >> but I am not aware of anything like that. >> >>> Nit: idnits 2.12.12 reports that draft-ietf-vcarddav-carddav has been >>> published as RFC 6352; the RFC Editor will correct this if a new version >>> of the draft is not required for other reasons. >> >> Fixed in my working copy. >> >> >> -- >> Cyrus Daboo >> > From john-ietf@jck.com Thu Jan 19 08:54:39 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0C021F8678 for ; Thu, 19 Jan 2012 08:54:37 -0800 (PST) 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 Zay+Ongx06qv for ; Thu, 19 Jan 2012 08:54:36 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 28F6E21F8675 for ; Thu, 19 Jan 2012 08:54:36 -0800 (PST) Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RnvCV-000As4-6y; Thu, 19 Jan 2012 11:50:59 -0500 X-Vipre-Scanned: 0C044F37002C310C045084-TDI Date: Thu, 19 Jan 2012 11:54:35 -0500 From: John C Klensin To: Noel Chiappa , ietf@ietf.org Subject: Re: Story: "Next battle over Net ramps up worldwide" Message-ID: <9898A1EE52770599FBDFB823@[192.168.1.128]> In-Reply-To: <20120119160434.BDD0018C0C6@mercury.lcs.mit.edu> References: <20120119160434.BDD0018C0C6@mercury.lcs.mit.edu> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 16:54:40 -0000 --On Thursday, January 19, 2012 11:04 -0500 Noel Chiappa wrote: > For those who haven't seen it, here: > > Next battle over Net ramps up worldwide > http://www.politico.com/news/stories/0112/71625.html > > is an interesting story, one which is also fairly accurate > (often not true of major media stories about the Internet). Yes, although to describe ICANN's decision making process as a "technical body" or "mostly devoid of politics" requires living in a reality different from that understood by anyone who has followed their policy development processes in recent years. Maybe this is even ok, but... john From lear@cisco.com Thu Jan 19 09:01:45 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D7721F846A for ; Thu, 19 Jan 2012 09:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 8XYrqdXL2HAj for ; Thu, 19 Jan 2012 09:01:44 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 893FA21F846C for ; Thu, 19 Jan 2012 09:01:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=977; q=dns/txt; s=iport; t=1326992504; x=1328202104; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=UA93AcKSHWIjhFLvYg4ANv6IT2tTIZi4vB0XZp7FKf8=; b=iglklhXbAqSYc0qSjGL9SDf4Exel4c68mc2PYVDEMDuPGaM+MPHToNfi jLqcXgP/Zje3bnbOV86EmfMVXhopmwLd1yW0pcZk+KKzwXdW/uXRg4sxN kw6BiwZX02Tn8GrVTF+/YAmeOqICV96iG9T67zoSbxCMxyaxe1mRCOng5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYKAJ1LGE+Q/khN/2dsb2JhbABEDoR2p1sHeYEFgXIBAQEEAQEBDwEQRQYKARALDgoCAgUWCwICCQMCAQIBFTAGDQEFAgEBBREIh2KaSAGMYpF6gS+HWwgCAwEEDwIFBgEBCAQMAQELCAEBBAEFCAUEEQUBBgEBBgEFIAELAQIBAQIDAwEBAQECFhUDAQYMBwICAx0DAQYJAgENAQEDCwILAgsDAQEJgTEBAQUCAwcBAQECAQEBAQsJAQECEAECAwEGAwIDBAEEBoIrgRYElReSEzg X-IronPort-AV: E=Sophos;i="4.71,537,1320624000"; d="scan'208";a="64100267" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 19 Jan 2012 17:01:41 +0000 Received: from dhcp-10-61-98-155.cisco.com (dhcp-10-61-98-155.cisco.com [10.61.98.155]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0JH1fTb022699; Thu, 19 Jan 2012 17:01:41 GMT Message-ID: <4F184C74.7010905@cisco.com> Date: Thu, 19 Jan 2012 18:01:40 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Noel Chiappa Subject: Re: Story: "Next battle over Net ramps up worldwide" References: <20120119160434.BDD0018C0C6@mercury.lcs.mit.edu> In-Reply-To: <20120119160434.BDD0018C0C6@mercury.lcs.mit.edu> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 17:01:45 -0000 What this story refers to is the World Conference on International Telecommunications. DID YOU KNOW? ... that the Internet currently runs through a loophole in these international regulations that were last amended in the 1980s? ... that there are some countries who would like to exert more control over what protocols run on the Internet? If you didn't know, perhaps you might want to engage with ISOC to learn more about this. Check out http://www.internetsociety.org/regulation. Eliot On 1/19/12 5:04 PM, Noel Chiappa wrote: > For those who haven't seen it, here: > > Next battle over Net ramps up worldwide > http://www.politico.com/news/stories/0112/71625.html > > is an interesting story, one which is also fairly accurate (often not true > of major media stories about the Internet). > > Noel > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From brian.e.carpenter@gmail.com Thu Jan 19 11:52:09 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591C321F85F1 for ; Thu, 19 Jan 2012 11:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.573 X-Spam-Level: X-Spam-Status: No, score=-103.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, 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 YfaMOtDL3vgp for ; Thu, 19 Jan 2012 11:52:08 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6366021F85E4 for ; Thu, 19 Jan 2012 11:52:08 -0800 (PST) Received: by eaai13 with SMTP id i13so135962eaa.31 for ; Thu, 19 Jan 2012 11:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=TeEafwDzqkq9oI1FsynwJMtIyLLc8bsiiYnoac+VNUE=; b=DrQ5Pto/xyOPnJZyJ6Z0L2oqozkHq3qe0zu9jK+cUEyNJ5jUlZq6vFfldnAxU4smFk tONA3lksoRe9AulCgOML8SdZ7Wqnm1N+MECuvE+GdjYCX3xenb9w/OIljuoSrV/e/BFK jc5x54Hpteub2PNOl8CGzfIdqquPk36lMsdTU= Received: by 10.213.27.16 with SMTP id g16mr7078657ebc.6.1327002725911; Thu, 19 Jan 2012 11:52:05 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id y12sm1567466eeb.11.2012.01.19.11.52.03 (version=SSLv3 cipher=OTHER); Thu, 19 Jan 2012 11:52:05 -0800 (PST) Message-ID: <4F18745B.4090102@gmail.com> Date: Fri, 20 Jan 2012 08:51:55 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eliot Lear Subject: Re: Story: "Next battle over Net ramps up worldwide" References: <20120119160434.BDD0018C0C6@mercury.lcs.mit.edu> <4F184C74.7010905@cisco.com> In-Reply-To: <4F184C74.7010905@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Noel Chiappa , ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 19:52:09 -0000 And don't assume that just because ISOC is on the case that this situation is covered. It's a real threat and every ITU Secretary-General since 1999* has been trying to grab these powers, supported by more or less authoritarian governments. *The last S-G who was not trying this was Pekke Tarjanne, who was largely responsible for telecom liberalisation at the international level. He left office in January 1999. Regards Brian Carpenter On 2012-01-20 06:01, Eliot Lear wrote: > What this story refers to is the World Conference on International > Telecommunications. > > DID YOU KNOW? > > ... that the Internet currently runs through a loophole in these > international regulations that were last amended in the 1980s? > > ... that there are some countries who would like to exert more control > over what protocols run on the Internet? > > If you didn't know, perhaps you might want to engage with ISOC to learn > more about this. Check out http://www.internetsociety.org/regulation. > > Eliot > > On 1/19/12 5:04 PM, Noel Chiappa wrote: >> For those who haven't seen it, here: >> >> Next battle over Net ramps up worldwide >> http://www.politico.com/news/stories/0112/71625.html >> >> is an interesting story, one which is also fairly accurate (often not true >> of major media stories about the Internet). >> >> Noel >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From smb@cs.columbia.edu Thu Jan 19 14:12:03 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4987921F8466 for ; Thu, 19 Jan 2012 14:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.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 x5Co8aApivvk for ; Thu, 19 Jan 2012 14:12:02 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6D76121F858D for ; Thu, 19 Jan 2012 14:12:02 -0800 (PST) Received: from [10.9.0.18] (fireball.cs.columbia.edu [128.59.13.10]) (user=smb2132 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q0JMBxo8003196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Jan 2012 17:11:59 -0500 (EST) Subject: Re: Story: "Next battle over Net ramps up worldwide" Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: <9898A1EE52770599FBDFB823@[192.168.1.128]> Date: Thu, 19 Jan 2012 17:11:58 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <20120119160434.BDD0018C0C6@mercury.lcs.mit.edu> <9898A1EE52770599FBDFB823@[192.168.1.128]> To: John C Klensin X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: Noel Chiappa , ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 22:12:03 -0000 On Jan 19, 2012, at 11:54 35AM, John C Klensin wrote: > > > --On Thursday, January 19, 2012 11:04 -0500 Noel Chiappa > wrote: > >> For those who haven't seen it, here: >> >> Next battle over Net ramps up worldwide >> http://www.politico.com/news/stories/0112/71625.html >> >> is an interesting story, one which is also fairly accurate >> (often not true of major media stories about the Internet). > > Yes, although to describe ICANN's decision making process as a > "technical body" or "mostly devoid of politics" requires living > in a reality different from that understood by anyone who has > followed their policy development processes in recent years. > Maybe this is even ok, but... To Politico, I think "devoid of politics" means there are no Republicans or Democrats involved, and the nodes in our protocol state machines aren't colored red or blue... --Steve Bellovin, https://www.cs.columbia.edu/~smb From sm@resistor.net Thu Jan 19 15:11:41 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934D221F84CE; Thu, 19 Jan 2012 15:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.631 X-Spam-Level: X-Spam-Status: No, score=-102.631 tagged_above=-999 required=5 tests=[AWL=-0.032, 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 ZJD5Jc+ozvPD; Thu, 19 Jan 2012 15:11:40 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEBA21F84C3; Thu, 19 Jan 2012 15:11:40 -0800 (PST) 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 q0JNBWIM021712; Thu, 19 Jan 2012 15:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327014698; i=@resistor.net; bh=8DjRiTad4JD6AIlDKjy0AKp8mU7iPAjzBPXmUx+SV9U=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=vhj7BdHi4ykbGkR65fyVMGCywUaUCK0a4uk4R3rJbI7U5MF7YtiP4V8yhQZzc120j 84sDmRpWyGACTy5eCuFrJ/By0wRl2pzcbbLHrrQ5ODqCwAEArg3SoBkciBMkS8Tidg Y2eGYlkedWqRR/zDgMROSTEhlBE1/xDUSqPo+MFQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327014698; i=@resistor.net; bh=8DjRiTad4JD6AIlDKjy0AKp8mU7iPAjzBPXmUx+SV9U=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=gaBM5MGKdLOfy/lUTLD0veskfark3jKbh/dzoQcU+YFnPcOsYSdy3XlFz4MsybRbi XqH5X1s3rpcUGlVChO3XysUVxJEIZ9mY6TF8Ycw9pip2QEnR+KVfEHtVynNqMbvS8N 36LarFJTmEc0LwBu+Bt++SJOExNTmgM3CvyUBUFI= Message-Id: <6.2.5.6.2.20120119144439.0634f518@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Jan 2012 15:11:02 -0800 To: Zoltan Ordogh From: SM Subject: Re: [apps-discuss] FW: Spam reporting over IMAP In-Reply-To: <1DE983233DBBEB4A81F18FABD8208D76226DA413@XMB107ACNC.rim.ne t> References: <1DE983233DBBEB4A81F18FABD8208D76226DA413@XMB107ACNC.rim.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: ietf , apps-discuss@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 23:11:41 -0000 Hi Zoltan, At 14:10 19-01-2012, Zoltan Ordogh wrote: >I understand the confusion has risen because my name is listed as an >author on draft-ordogh-spam-reporting-using-imap-kleansed-00. >I would like to make it clear that while >draft-ordogh-spam-reporting-using-imap-kleansed-00 bears my name and >I am listed as the author of this, I was not involved - nor >consulted - on its development. I am of course happy to work with >anyone who wishes to progress either draft as long as the work gets >done in IETF. As I said before, if there Thanks for the explanation. >I noticed that a declaration has been made on >draft-ordogh-spam-reporting-using-imap-kleansed-00. This simple fact >should answer SM's question. I would like to thank you and Research In Motion Limited for resolving the issue. Regards, -sm From cheshire@apple.com Thu Jan 19 15:40:44 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0486021F8603; Thu, 19 Jan 2012 15:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 GYcid5NdDEX5; Thu, 19 Jan 2012 15:40:43 -0800 (PST) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7A32721F85FF; Thu, 19 Jan 2012 15:40:40 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0LY200GW4KER6Y72@mail-out.apple.com>; Thu, 19 Jan 2012 15:40:09 -0800 (PST) X-AuditID: 11807112-b7b14ae00000798e-c3-4f18a9d968ac Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay17.apple.com (Apple SCV relay) with SMTP id A0.60.31118.9D9A81F4; Thu, 19 Jan 2012 15:40:09 -0800 (PST) Received: from chesh7.apple.com (chesh7.apple.com [17.193.13.47]) by kencur.apple.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LY200EDWKEXST80@kencur.apple.com>; Thu, 19 Jan 2012 15:40:09 -0800 (PST) Subject: Re: [IAOC] primary Paris hotel booking From: Stuart Cheshire In-reply-to: <336D4C73-04AD-47B7-988A-73D3A1A65EA2@gmail.com> Date: Thu, 19 Jan 2012 15:40:09 -0800 Message-id: <2245046E-C3D3-4C3D-A75A-C5A97DE3213D@apple.com> References: <336D4C73-04AD-47B7-988A-73D3A1A65EA2@gmail.com> To: Bob Hinden X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUiON1OTffmSgl/gxnz9Sw+XbzDavFs43wW ByaPJUt+MgUwRnHZpKTmZJalFunbJXBlXJ6jWXCPreLimn/MDYwLWbsYOTkkBEwkXk7YzQRh i0lcuLeerYuRi0NIoJ1J4vnO5+wQzkQmiTnXFrCBVAkL6Ev035/BDGLzChhKdKw7yg5iMwto SazfeRxsEhuQ/eLzFbB6TgFbieVz/gHFOThYBFQlts1hgijPljj3fAIjhK0t8eTdBVaIkTYS B84tY4TY28kocXnlf7BdIkC9y/v72UHmSAjISjQty5jAKDALyRWzkFwxC8nYBYzMqxgFi1Jz EisNzfUSCwpyUvWS83M3MYJCsKFQaAfj/V16hxgFOBiVeHi5XCX8hVgTy4orcw8xSnAwK4nw NvQBhXhTEiurUovy44tKc1KLDzFKc7AoifNmvRf1FxJITyxJzU5NLUgtgskycXBKNTA6Pplz 4YHAUvniiR3Ruj7WsfF6r/TPzBJ+m+kR/d99911xy08iOYcrvTljemYkPBFl2ew9p6vr22FO Z/PnW1dXLYkobTB/dM4p4t96N7smy0z7fX5rw1gtNi7tyWj2XdfS+Nf0HcvazZI/IqOvPRZj CVRRmxDpqGwitNFqScmaGu/HDftrnyixFGckGmoxFxUnAgCNs3PKPQIAAA== Cc: IAOC , IETF-Discussion list X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 23:40:44 -0000 On 3 Jan 2012, at 16:02, Bob Hinden wrote: > Wes, > > I think everyone on the IAOC was surprised when we first heard that the meeting hotel insisted that people can only use fax or email to send in their reservations. We tried to get the hotel to change this, but they would not budge. This included their rejection of accepting reservations by phone. I sent them an encrypted PDF by email, and then called Hotel Concorde to give Carole Masson the password by phone. I was told that I could neither speak with Carole Masson nor leave a message for her. So right now the hotel has an encrypted PDF from me which they cannot view. BTW, the Hotel Concorde phone number given at is wrong. Web page says: +33 1 40 68 50 50 Actual number: +33 1 40 68 50 68 Stuart Cheshire From cheshire@apple.com Thu Jan 19 16:38:08 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D9C21F8503 for ; Thu, 19 Jan 2012 16:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 vbeDRAmuQC5Y for ; Thu, 19 Jan 2012 16:38:08 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3687421F84F9 for ; Thu, 19 Jan 2012 16:38:08 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0LY200GB8N236YD2@mail-out.apple.com> for ietf@ietf.org; Thu, 19 Jan 2012 16:37:37 -0800 (PST) X-AuditID: 11807136-b7b94ae000002733-0d-4f18b7519607 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 21.81.10035.157B81F4; Thu, 19 Jan 2012 16:37:37 -0800 (PST) Received: from chesh7.apple.com (chesh7.apple.com [17.193.13.47]) by kencur.apple.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0LY200E7CN2PST90@kencur.apple.com> for ietf@ietf.org; Thu, 19 Jan 2012 16:37:37 -0800 (PST) Subject: Re: primary Paris hotel booking From: Stuart Cheshire In-reply-to: <4F0374BB.8020102@gmail.com> Date: Thu, 19 Jan 2012 16:37:37 -0800 Message-id: <12CD270E-7726-4452-95BE-88D2EE15C088@apple.com> References: <34EF3F99-10DE-4B6B-92A7-2DD255412A0C@lucidvision.com> <20120103194826.69AEA21F84AD@ietfa.amsl.com> <0A4FD46C-F43E-46A7-BA1D-B7684632DED8@standardstrack.com> <4F0374BB.8020102@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUiON1OTTdwu4S/wc+DuhbPNs5ncWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs/zcgWPmCs+7pvM0sD4m6mLkZNDQsBEYuXyI+wQtpjEhXvr 2boYuTiEBNqZJI59/8QE4Sxmkpi9pROsSlhAQ+LG6kmMIDavgKFEx7qjYHFmAS2J9TuPg01l A7JffL7CBmJzCmhKHLyzB8xmEVCV6N43jRGivlji6fo1bBC2tsSTdxdYIWbaSNzYfIYRYvEB JonOk3eYQRIiAsYSjV2ngYo4gE6VlWhaljGBUWAWkjNmITljFpKxCxiZVzEKFqXmJFYamuol FhTkpOol5+duYgSFXkOh2Q7GHX/lDjEKcDAq8fByukr4C7EmlhVX5h5ilOBgVhLhbegDCvGm JFZWpRblxxeV5qQWH2KU5mBREufNeC/qLySQnliSmp2aWpBaBJNl4uCUamCUvN2duSbg3ud0 9RUiHBJH9BzXfmqOrPV8J1fzVefxTaZ3Ry3ZCt76/+A04i7T/H/0x2f9gBNTG+ZOr5i5y54r YvLSEx98s09lOPkandlVxSbYIufyO14/3vlg8D6VZ5oiepINVTcsl06Ytloy8K5Uet8k8yXa CTM23az36d2kLtvLLuthJqTEUpyRaKjFXFScCAD3MSSlOQIAAA== Cc: John C Klensin , IETF Discussion , Eric Burger X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 00:38:08 -0000 On 3 Jan 2012, at 13:35, Brian E Carpenter wrote: > There's a third case, "paid a lower rate than the conference rate" > (usually due to a smart corporate travel agent). I've never > understood why conferences don't get a corporate-equivalent rate. > > Brian Good suggestion Brian. I just called our corporate travel department and got the same rate as IETF, including free Internet and breakfast, and "cancel by 6 PM on check-in day". Stuart Cheshire From narten@us.ibm.com Thu Jan 19 21:53:10 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE25A21F85D6 for ; Thu, 19 Jan 2012 21:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.312 X-Spam-Level: X-Spam-Status: No, score=-108.312 tagged_above=-999 required=5 tests=[AWL=2.288, 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 oq6-BtbOvpfu for ; Thu, 19 Jan 2012 21:53:10 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by ietfa.amsl.com (Postfix) with ESMTP id 5737421F85DB for ; Thu, 19 Jan 2012 21:53:09 -0800 (PST) Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 19 Jan 2012 22:53:08 -0700 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 19 Jan 2012 22:53:06 -0700 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id B10171FF0038 for ; Thu, 19 Jan 2012 22:53:04 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q0K5r4lM155714 for ; Thu, 19 Jan 2012 22:53:04 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q0K5r4aU023672 for ; Thu, 19 Jan 2012 22:53:04 -0700 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.192.143]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q0K5r3fs023657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Jan 2012 22:53:03 -0700 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id q0K5r2FS006391 for ; Fri, 20 Jan 2012 00:53:02 -0500 Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.14.4/8.14.4/Submit) id q0K5r2Gi006369 for ietf@ietf.org; Fri, 20 Jan 2012 00:53:02 -0500 From: Thomas Narten Message-Id: <201201200553.q0K5r2Gi006369@rotala.raleigh.ibm.com> Date: Fri, 20 Jan 2012 00:53:02 -0500 To: ietf@ietf.org Subject: Weekly posting summary for ietf@ietf.org User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12012005-7282-0000-0000-000005C6F3AB X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 05:53:11 -0000 Total of 45 messages in the last 7 days. script run at: Fri Jan 20 00:53:01 EST 2012 Messages | Bytes | Who --------+------+--------+----------+------------------------ 4.44% | 2 | 12.17% | 61459 | dromasca@avaya.com 4.44% | 2 | 7.84% | 39608 | jouni.nospam@gmail.com 2.22% | 1 | 9.09% | 45915 | bill.wu@huawei.com 4.44% | 2 | 5.53% | 27909 | stephen.farrell@cs.tcd.ie 4.44% | 2 | 5.07% | 25614 | hannes.tschofenig@gmx.net 4.44% | 2 | 3.64% | 18361 | ron.even.tlv@gmail.com 4.44% | 2 | 3.61% | 18241 | shanna@juniper.net 4.44% | 2 | 3.01% | 15195 | john-ietf@jck.com 4.44% | 2 | 2.92% | 14755 | simon@josefsson.org 4.44% | 2 | 2.80% | 14153 | julian.reschke@gmx.de 2.22% | 1 | 4.97% | 25084 | bernard_aboba@hotmail.com 4.44% | 2 | 2.74% | 13818 | cheshire@apple.com 4.44% | 2 | 2.48% | 12502 | sm@resistor.net 2.22% | 1 | 3.81% | 19260 | glenzorn@gmail.com 2.22% | 1 | 2.32% | 11705 | stpeter@stpeter.im 2.22% | 1 | 2.25% | 11367 | klaas@cisco.com 2.22% | 1 | 1.98% | 10011 | stbryant@cisco.com 2.22% | 1 | 1.87% | 9425 | daedulus@btconnect.com 2.22% | 1 | 1.73% | 8743 | kireeti@juniper.net 2.22% | 1 | 1.72% | 8682 | ben@nostrum.com 2.22% | 1 | 1.65% | 8329 | agmalis@gmail.com 2.22% | 1 | 1.60% | 8074 | narten@us.ibm.com 2.22% | 1 | 1.54% | 7779 | vesely@tana.it 2.22% | 1 | 1.46% | 7362 | evnikita2@gmail.com 2.22% | 1 | 1.42% | 7193 | loa@pi.nu 2.22% | 1 | 1.39% | 7038 | brian.e.carpenter@gmail.com 2.22% | 1 | 1.33% | 6731 | lear@cisco.com 2.22% | 1 | 1.32% | 6691 | rcallon@juniper.net 2.22% | 1 | 1.27% | 6409 | rja.lists@gmail.com 2.22% | 1 | 1.22% | 6157 | touch@isi.edu 2.22% | 1 | 1.17% | 5909 | smb@cs.columbia.edu 2.22% | 1 | 1.17% | 5906 | chair@ietf.org 2.22% | 1 | 1.01% | 5090 | sapnas@s-mail.com 2.22% | 1 | 0.92% | 4626 | jnc@mercury.lcs.mit.edu --------+------+--------+----------+------------------------ 100.00% | 45 |100.00% | 505101 | Total From hallam@gmail.com Fri Jan 20 06:20:51 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8711921F85F7 for ; Fri, 20 Jan 2012 06:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.281 X-Spam-Level: X-Spam-Status: No, score=-3.281 tagged_above=-999 required=5 tests=[AWL=0.317, 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 Pu6Aiuzh-BzP for ; Fri, 20 Jan 2012 06:20:50 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A89B321F8643 for ; Fri, 20 Jan 2012 06:20:50 -0800 (PST) Received: by obbwc12 with SMTP id wc12so935121obb.31 for ; Fri, 20 Jan 2012 06:20:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=xh11zY3v8iQXbSMzZ1a3UIVPvS66b2UnAb4rfNkP4cA=; b=uKz0knlcvq2qhy7kkjKiuQ0mh9oePskfvcNvfU44LKvO27IXyYjgvBVfvuTzRDuGMJ 19xwKjhOMVlG4zZnWjZNCcU5H9MgKMQQ9S1lSvXnCPZ607v+15YHomha9TtXVIOfB4cB fvDtudiNl5rsj9sBLwZ6McmUQiT9zixR/NpoU= MIME-Version: 1.0 Received: by 10.182.159.70 with SMTP id xa6mr27043211obb.1.1327069250346; Fri, 20 Jan 2012 06:20:50 -0800 (PST) Received: by 10.182.11.169 with HTTP; Fri, 20 Jan 2012 06:20:50 -0800 (PST) Date: Fri, 20 Jan 2012 09:20:50 -0500 Message-ID: Subject: ITC copped out on UTC again From: Phillip Hallam-Baker To: IETF Discussion Mailing List Content-Type: multipart/alternative; boundary=14dae9399771425d9604b6f663fd X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 14:20:51 -0000 --14dae9399771425d9604b6f663fd Content-Type: text/plain; charset=ISO-8859-1 If we are ever going to get a handle on Internet time we need to get rid of the arbitrary correction factors introduced by leap seconds. The problems caused by leap seconds are that they make it impossible for two machines to know if they are referring to the same point in future time and quite often introduce errors in the present. 1) No machine can determine the number of seconds between two arbitrary UTC dates in the future since there may be a leap second announced. 2) If Machine A is attempting to synchronize with machine B on a future point in time, they cannot do so unless they know that they have the same view of leap seconds. If a leap second is announced and only one makes the correction, an error is introduced. 3) In practice computer systems rarely apply leap seconds at the correct time in any case. There is thus a jitter introduced around the introduction of leap seconds as different machines get an NTP fix at different points in time. 4) Even though it is possible to represent leap seconds correctly in standard formats, doing so is almost certain to exercise code paths that should be avoided. Since the ITU does not look like sorting this out, I suggest we do so in the IETF. There is no functional reason that Internet protocols should need leap seconds. I suggest that the IETF plan to move to Internet Time in 2015, immediately after the next ITU meeting. Internet time would be TAI plus the number of leap seconds that have accumulated up to the next ITU decision point. So if UTC drops leap seconds at the next meeting the two series will be in sync, otherwise there will be a divergence. -- Website: http://hallambaker.com/ --14dae9399771425d9604b6f663fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
      If we are ever going to get a handle on Internet time we need to get r= id of the arbitrary correction factors introduced by leap seconds.

      The problems caused by leap seconds are that they make it = impossible for two machines to know if they are referring to the same point= in future time and quite often introduce errors in the present.

      1) No machine can determine the number of seconds betwe= en two arbitrary UTC dates in the future since there may be a leap second a= nnounced.

      2) If Machine A is attempting to synchro= nize with machine B on a future point in time, they cannot do so unless the= y know that they have the same view of leap seconds. If a leap second is an= nounced and only one makes the correction, an error is introduced.

      3) In practice computer systems rarely apply leap secon= ds at the correct time in any case. There is thus a jitter introduced aroun= d the introduction of leap seconds as different machines get an NTP fix at = different points in time.

      4) Even though it is possible to represent leap seconds= correctly in standard formats, doing so is almost certain to exercise code= paths that should be avoided.


      Since the ITU does not look like sorting this out, I suggest we do so in th= e IETF. There is no functional reason that Internet protocols should need l= eap seconds.=A0

      I suggest that the IETF plan to mo= ve to Internet Time in 2015, immediately after the next ITU meeting. Intern= et time would be TAI plus the number of leap seconds that have accumulated = up to the next ITU decision point. So if UTC drops leap seconds at the next= meeting the two series will be in sync, otherwise there will be a divergen= ce.



      --
      Website: http://hallambaker.com/

      --14dae9399771425d9604b6f663fd-- From nick@inex.ie Fri Jan 20 06:41:31 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C08421F84A6 for ; Fri, 20 Jan 2012 06:41:31 -0800 (PST) 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 IOFq0hQADYMV for ; Fri, 20 Jan 2012 06:41:30 -0800 (PST) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8F05521F8446 for ; Fri, 20 Jan 2012 06:41:29 -0800 (PST) X-Envelope-To: ietf@ietf.org Received: from cupcake.internal.acquirer.com (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q0KEgcsU041786 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 20 Jan 2012 14:42:38 GMT (envelope-from nick@inex.ie) Message-ID: <4F197D14.7080807@inex.ie> Date: Fri, 20 Jan 2012 14:41:24 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker Subject: Re: ITC copped out on UTC again References: In-Reply-To: X-Enigmail-Version: 1.3.4 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 14:41:31 -0000 Phillip, On 20/01/2012 14:20, Phillip Hallam-Baker wrote: > If we are ever going to get a handle on Internet time we need to get rid of > the arbitrary correction factors introduced by leap seconds. Your arguments in favour of abolishing leap seconds are all good. But can you please do us all a favour and provide a similarly lucid list of reasons that an apologist would use to say that leap seconds should be kept. Nick From lear@cisco.com Fri Jan 20 06:42:16 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9B421F84CF for ; Fri, 20 Jan 2012 06:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wQeLtFvfT6mA for ; Fri, 20 Jan 2012 06:42:15 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id CE5DF21F8446 for ; Fri, 20 Jan 2012 06:42:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=7496; q=dns/txt; s=iport; t=1327070535; x=1328280135; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=kvCTmAVuWuoH+/wGezyAytGlpWtpaVGsxfovERRLi/k=; b=A7cW4+01OwMGLIrDRrWCVqkFce4ascKx7wH+740thtQBNooenLUe6BoO nDZM+BCycn9SndomHX4/15dX9QfzprlWCK9N7ePTT8MkFY3apmOEaKd/Y V5MGkU8kV7h9fL8WWCDojjun0KAde/c+w1JNNRkjohHrauxXIVtdGpZnE 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAN9GU+Q/khN/2dsb2JhbABDhQSofoEFgXIBAQEEAQEBDwEQSwoBEAsYCQwKCwICCQMCAQIBFTAGDQEFAgEBHodimgMBjGORY4h+ghKBFgSVGZJM X-IronPort-AV: E=Sophos;i="4.71,542,1320624000"; d="scan'208,217";a="127122821" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 20 Jan 2012 14:41:54 +0000 Received: from dhcp-10-55-91-62.cisco.com (dhcp-10-55-91-62.cisco.com [10.55.91.62]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0KEfrxF017064; Fri, 20 Jan 2012 14:41:53 GMT Message-ID: <4F197D30.3080400@cisco.com> Date: Fri, 20 Jan 2012 15:41:52 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker Subject: Re: ITC copped out on UTC again References: In-Reply-To: X-Enigmail-Version: 1.3.4 Content-Type: multipart/alternative; boundary="------------070605050807040804070505" Cc: IETF Discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 14:42:16 -0000 This is a multi-part message in MIME format. --------------070605050807040804070505 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Phillip, For those who are interested in the proceedings, they took place yesterday at the ITU's Radio Advisory Group (RAG). The United States introduced the proposal to do away with leap seconds. They were not, shall we say, universally supported. Those in favor were largely in line with what you wrote below, Phillip. Those opposed were not clear that there really was a problem to solve, and wanted more time to consult. The matter was referred back to the study group for further consideration, as well as broader consultation, and will be taken up again at the next RAG (approximately two years from now). If you have a TIES account at the ITU, you can listen to the proceedings by going to the following link and moving to time index 1:43:15 or so. http://www.itu.int/ibs/ITU-R/RA12/links/1-20120119-1400-en.smil Regards, Eliot On 1/20/12 3:20 PM, Phillip Hallam-Baker wrote: > If we are ever going to get a handle on Internet time we need to get > rid of the arbitrary correction factors introduced by leap seconds. > > The problems caused by leap seconds are that they make it impossible > for two machines to know if they are referring to the same point in > future time and quite often introduce errors in the present. > > 1) No machine can determine the number of seconds between two > arbitrary UTC dates in the future since there may be a leap second > announced. > > 2) If Machine A is attempting to synchronize with machine B on a > future point in time, they cannot do so unless they know that they > have the same view of leap seconds. If a leap second is announced and > only one makes the correction, an error is introduced. > > 3) In practice computer systems rarely apply leap seconds at the > correct time in any case. There is thus a jitter introduced around the > introduction of leap seconds as different machines get an NTP fix at > different points in time. > > 4) Even though it is possible to represent leap seconds correctly in > standard formats, doing so is almost certain to exercise code paths > that should be avoided. > > > Since the ITU does not look like sorting this out, I suggest we do so > in the IETF. There is no functional reason that Internet protocols > should need leap seconds. > > I suggest that the IETF plan to move to Internet Time in 2015, > immediately after the next ITU meeting. Internet time would be TAI > plus the number of leap seconds that have accumulated up to the next > ITU decision point. So if UTC drops leap seconds at the next meeting > the two series will be in sync, otherwise there will be a divergence. > > > > -- > Website: http://hallambaker.com/ > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --------------070605050807040804070505 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Phillip,

      For those who are interested in the proceedings, they took place yesterday at the ITU's Radio Advisory Group (RAG).  The United States introduced the proposal to do away with leap seconds.  They were not, shall we say, universally supported.  Those in favor were largely in line with what you wrote below, Phillip.  Those opposed were not clear that there really was a problem to solve, and wanted more time to consult.  The matter was referred back to the study group for further consideration, as well as broader consultation, and will be taken up again at the next RAG (approximately two years from now). 

      If you have a TIES account at the ITU, you can listen to the proceedings by going to the following link and moving to time index 1:43:15 or so.

      http://www.itu.int/ibs/ITU-R/RA12/links/1-20120119-1400-en.smil

      Regards,

      Eliot

      On 1/20/12 3:20 PM, Phillip Hallam-Baker wrote:
      If we are ever going to get a handle on Internet time we need to get rid of the arbitrary correction factors introduced by leap seconds.

      The problems caused by leap seconds are that they make it impossible for two machines to know if they are referring to the same point in future time and quite often introduce errors in the present.

      1) No machine can determine the number of seconds between two arbitrary UTC dates in the future since there may be a leap second announced.

      2) If Machine A is attempting to synchronize with machine B on a future point in time, they cannot do so unless they know that they have the same view of leap seconds. If a leap second is announced and only one makes the correction, an error is introduced.

      3) In practice computer systems rarely apply leap seconds at the correct time in any case. There is thus a jitter introduced around the introduction of leap seconds as different machines get an NTP fix at different points in time.

      4) Even though it is possible to represent leap seconds correctly in standard formats, doing so is almost certain to exercise code paths that should be avoided.


      Since the ITU does not look like sorting this out, I suggest we do so in the IETF. There is no functional reason that Internet protocols should need leap seconds. 

      I suggest that the IETF plan to move to Internet Time in 2015, immediately after the next ITU meeting. Internet time would be TAI plus the number of leap seconds that have accumulated up to the next ITU decision point. So if UTC drops leap seconds at the next meeting the two series will be in sync, otherwise there will be a divergence.



      --
      Website: http://hallambaker.com/



      _______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
      --------------070605050807040804070505-- From vesely@tana.it Fri Jan 20 07:03:46 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A189121F8575; Fri, 20 Jan 2012 07:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.621 X-Spam-Level: X-Spam-Status: No, score=-4.621 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 RQPRJ9OLN4nF; Fri, 20 Jan 2012 07:03:46 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id C382321F856C; Fri, 20 Jan 2012 07:03:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1327071823; bh=dEQxPmhhpUe5MrZuNuDj6ei7zuuGpSn+ot/NnSh5ZXg=; l=844; h=Message-ID:Date:From:MIME-Version:To:CC: Content-Transfer-Encoding; b=KjmdKb6JjmJl1eQTgqYmMnyB1r62hRpf6l6hIi6cq93SX0SRKBS15w+09t5EnXUJZ 7lGWTOktgFsRk0PbQhpBAJv0ppNBe8zzx9hfqTUIk2Ut40Zbm9sS/bv6xbu/+j4Op0 eshtvftNFuOhqacqBa5E5EX8Xj+DJXT+78TrKkXY= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 20 Jan 2012 16:03:43 +0100 id 00000000005DC039.000000004F19824F.0000033C Message-ID: <4F19824E.9020101@tana.it> Date: Fri, 20 Jan 2012 16:03:42 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ietf-action@ietf.org Subject: Please remove draft-ordogh-spam-reporting-using-imap-kleansed from I-D repository Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Zoltan Ordogh , apps discuss , ietf X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 15:03:46 -0000 Dear IETF Secretariat, I hereby ask that draft-ordogh-spam-reporting-using-imap-kleansed be removed from the I-D repository. I submitted it on 10 Jan 2012, in a clumsy attempt to speed up a discussion about a similarly named I-D, draft-ordogh-spam-reporting-using-imap. The editing I carried out was based on previous writing about, both privately and on IETF lists. However, I hadn't obtained the author's permission to alter the boilerplate-type of the original document. Thus, the document I posted bears "wrong" copyright information. In particular, unwitting editors may derive their own work from this document if they just abide by its boilerplate text, while the original post did not imply a handoff of change control. I apologize for any inconveniences that my action might have caused. Regards Alessandro Vesely From tbray@textuality.com Fri Jan 20 07:13:44 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4968921F855F for ; Fri, 20 Jan 2012 07:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 tBPZvkJQTyDk for ; Fri, 20 Jan 2012 07:13:43 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 877DF21F855D for ; Fri, 20 Jan 2012 07:13:43 -0800 (PST) Received: by obbwc12 with SMTP id wc12so1009799obb.31 for ; Fri, 20 Jan 2012 07:13:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.121.101 with SMTP id lj5mr6666768obb.39.1327072423160; Fri, 20 Jan 2012 07:13:43 -0800 (PST) Received: by 10.182.226.105 with HTTP; Fri, 20 Jan 2012 07:13:43 -0800 (PST) X-Originating-IP: [24.104.44.194] In-Reply-To: References: Date: Fri, 20 Jan 2012 07:13:43 -0800 Message-ID: Subject: Re: ITC copped out on UTC again From: Tim Bray To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 15:13:44 -0000 One consequence of your proposal, if adopted, is that there will need to be a specification of the canonical Internet-time-to-Sidereal-time function, so that in the long run, the time that your computer says it is will correspond with what you observe looking out the window. The Internet will be around long enough that this will indeed become a problem. I'd want to look at that specification before getting passionate pro or contra in this argument. -T On Fri, Jan 20, 2012 at 6:20 AM, Phillip Hallam-Baker wrote: > If we are ever going to get a handle on Internet time we need to get rid of > the arbitrary correction factors introduced by leap seconds. > > The problems caused by leap seconds are that they make it impossible for two > machines to know if they are referring to the same point in future time and > quite often introduce errors in the present. > > 1) No machine can determine the number of seconds between two arbitrary UTC > dates in the future since there may be a leap second announced. > > 2) If Machine A is attempting to synchronize with machine B on a future > point in time, they cannot do so unless they know that they have the same > view of leap seconds. If a leap second is announced and only one makes the > correction, an error is introduced. > > 3) In practice computer systems rarely apply leap seconds at the correct > time in any case. There is thus a jitter introduced around the introduction > of leap seconds as different machines get an NTP fix at different points in > time. > > 4) Even though it is possible to represent leap seconds correctly in > standard formats, doing so is almost certain to exercise code paths that > should be avoided. > > > Since the ITU does not look like sorting this out, I suggest we do so in the > IETF. There is no functional reason that Internet protocols should need leap > seconds. > > I suggest that the IETF plan to move to Internet Time in 2015, immediately > after the next ITU meeting. Internet time would be TAI plus the number of > leap seconds that have accumulated up to the next ITU decision point. So if > UTC drops leap seconds at the next meeting the two series will be in sync, > otherwise there will be a divergence. > > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From fanf2@hermes.cam.ac.uk Fri Jan 20 07:13:51 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAF421F861C for ; Fri, 20 Jan 2012 07:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.989 X-Spam-Level: X-Spam-Status: No, score=-4.989 tagged_above=-999 required=5 tests=[AWL=-0.990, BAYES_50=0.001, 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 WIIRD+N33D38 for ; Fri, 20 Jan 2012 07:13:50 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 2D12721F85C5 for ; Fri, 20 Jan 2012 07:13:49 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:57752) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1RoG9z-00063K-rm (Exim 4.72) (return-path ); Fri, 20 Jan 2012 15:13:47 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RoG9z-0005eU-JM (Exim 4.67) (return-path ); Fri, 20 Jan 2012 15:13:47 +0000 Date: Fri, 20 Jan 2012 15:13:47 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Nick Hilliard Subject: Re: ITC copped out on UTC again In-Reply-To: <4F197D14.7080807@inex.ie> Message-ID: References: <4F197D14.7080807@inex.ie> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Phillip Hallam-Baker , IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 15:13:51 -0000 Nick Hilliard wrote: > > Your arguments in favour of abolishing leap seconds are all good. But can > you please do us all a favour and provide a similarly lucid list of reasons > that an apologist would use to say that leap seconds should be kept. I agree that leap seconds are a horrible bodge that would be best got rid of. The reasons to keep them mainly revolve around systems that require UT1, i.e. the angle of rotation of the Earth, and the protocols that disseminate UT1. These include: Astronomical systems Space and satellite ground stations Time broadcast standards Many protocols and software implementations rely on the guarantee that DUT1 (the difference between UTC and UT1) is less than 0.9s. For instance many time broadcast formats don't have space for larger values of DUT1. Many instruments that point at the sky rely on the fact that DUT1 < 0.9s for establishing an initial rough aim. For more examples see http://futureofutc.org/preprints At a more philosophical level a lot of people find it difficult to accept the idea of decoupling time from Earth rotation, to the extent that they say it is obvious nonsense or foolishness, even though the rate error is only one second every year or two. However UT1 is slowing down quadratically, so the time scales will diverge increasingly rapidly. We can paper over this difference by adjusting time zones every few hundred years. In fact time zone adjustments will work further into the future than leap seconds. But speculating about what will happen that far into the future is foolish. Numbers for divergence between UTC and TAI: http://www.ucolick.org/~sla/leapsecs/dutc.html#dutctable Tony. -- f.anthony.n.finch http://dotat.at/ Sole, Lundy, Fastnet, Irish Sea, Shannon: West 5 to 7, occasionally gale 8 later in Irish Sea. Moderate or rough, occasionally very rough except in Lundy and Irish Sea. Occasional rain or drizzle. Good, occasionally poor. From marshall.eubanks@gmail.com Fri Jan 20 07:14:30 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2623D21F8629 for ; Fri, 20 Jan 2012 07:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.476 X-Spam-Level: X-Spam-Status: No, score=-103.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, 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 Dy0phjnd5QT0 for ; Fri, 20 Jan 2012 07:14:29 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80F1121F85C0 for ; Fri, 20 Jan 2012 07:14:29 -0800 (PST) Received: by ggnr5 with SMTP id r5so355038ggn.31 for ; Fri, 20 Jan 2012 07:14:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SAd2xbigfSSK7IGtP+Ff8TQLgG89/qEG/5mAnYtNMXM=; b=olT/V1rU6hWbjCGXJPXsZgdwnDIEkUTumm9r88HgGjCNmWdw+fVv9I4eUxQWX3z99A JvCKxJqKK9+BDucFqOjM2lJDCXotHhxpju+b6lf1bAjwiQXyPB3QYorRzImXov9DcKek h6lflAjRdq7T7NbQaUcdE0mgGv7975uz3cm5Q= MIME-Version: 1.0 Received: by 10.182.75.65 with SMTP id a1mr26974061obw.32.1327072468965; Fri, 20 Jan 2012 07:14:28 -0800 (PST) Received: by 10.182.79.102 with HTTP; Fri, 20 Jan 2012 07:14:28 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Jan 2012 10:14:28 -0500 Message-ID: Subject: Re: ITC copped out on UTC again From: Marshall Eubanks To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 15:14:30 -0000 The solution is simple - move to TAI. That is the _true_ time, what the master clocks actually keep. UTC is just a variant for creatures living on the surface of the Earth. On Fri, Jan 20, 2012 at 9:20 AM, Phillip Hallam-Baker wrote: > If we are ever going to get a handle on Internet time we need to get rid of > the arbitrary correction factors introduced by leap seconds. > > The problems caused by leap seconds are that they make it impossible for two > machines to know if they are referring to the same point in future time and > quite often introduce errors in the present. > > 1) No machine can determine the number of seconds between two arbitrary UTC > dates in the future since there may be a leap second announced. Not true for TAI. > > 2) If Machine A is attempting to synchronize with machine B on a future > point in time, they cannot do so unless they know that they have the same > view of leap seconds. If a leap second is announced and only one makes the > correction, an error is introduced. Not true for TAI > > 3) In practice computer systems rarely apply leap seconds at the correct > time in any case. There is thus a jitter introduced around the introduction > of leap seconds as different machines get an NTP fix at different points in > time. Not an issue for TAI > > 4) Even though it is possible to represent leap seconds correctly in > standard formats, doing so is almost certain to exercise code paths that > should be avoided. > Not an issue for TAI Note, also, that the ITU proposal is not to _remove_ leap seconds, but to stop _issuing_ them (i.e., it could be rescinded fairly easily if in say 20 years someone agitated strongly to bring leap seconds back). > > Since the ITU does not look like sorting this out, I suggest we do so in the > IETF. There is no functional reason that Internet protocols should need leap > seconds. > > I suggest that the IETF plan to move to Internet Time in 2015, immediately > after the next ITU meeting. Internet time would be TAI plus the number of > leap seconds that have accumulated up to the next ITU decision point. So if > UTC drops leap seconds at the next meeting the two series will be in sync, > otherwise there will be a divergence. Makes no sense to me. Please don't continue to create more time scales that are "TAI plus some arbitrary constant." I believe that would make at least 4 separate ones (ET/TDT/TT, UTC, GPS internal time, plus this), which would be IMO at least 4 too many. If there is to be an internet time, it should simply be TAI. Then, the conversion to UTC is just an addition, and there would be no reason to have the messy interpolation during a leap second. just to change the addend. Regards Marshall > > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From marshall.eubanks@gmail.com Fri Jan 20 07:19:02 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9045521F85DB for ; Fri, 20 Jan 2012 07:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.477 X-Spam-Level: X-Spam-Status: No, score=-103.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, 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 uEg9+W9LN8gE for ; Fri, 20 Jan 2012 07:19:01 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C3F2721F85C0 for ; Fri, 20 Jan 2012 07:19:01 -0800 (PST) Received: by obbwc12 with SMTP id wc12so1017963obb.31 for ; Fri, 20 Jan 2012 07:18:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+SF0H9JUP/3brpgfR4OU3SYT+dwovkkBCWkZu7zF+IM=; b=GbieNU+3L02WoVdxADBxV1VfK3TQn6LMZTfSq7wDsFEgJ2Jf51OwqDvP4sOvnQ6CeX u0kaIbkNx/+riA6XYv+zvJnwYswGyicwd1P6jgACin6Bhg5wtm/lvOC6To7+Ooi/O7g5 PC/CqFq8cZwQnIFWQzwc3fZ8CF7mxUrGCsum0= MIME-Version: 1.0 Received: by 10.182.222.102 with SMTP id ql6mr27082342obc.2.1327072739729; Fri, 20 Jan 2012 07:18:59 -0800 (PST) Received: by 10.182.79.102 with HTTP; Fri, 20 Jan 2012 07:18:59 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Jan 2012 10:18:59 -0500 Message-ID: Subject: Re: ITC copped out on UTC again From: Marshall Eubanks To: Tim Bray Content-Type: text/plain; charset=ISO-8859-1 Cc: Phillip Hallam-Baker , IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 15:19:02 -0000 On Fri, Jan 20, 2012 at 10:13 AM, Tim Bray wrote: > One consequence of your proposal, if adopted, is that there will need > to be a specification of the canonical Internet-time-to-Sidereal-time > function, so that in the long run, the time that your computer says it > is will correspond with what you observe looking out the window. The > Internet will be around long enough that this will indeed become a > problem. > > I'd want to look at that specification before getting passionate pro > or contra in this argument. -T The people who really care about this (i.e., astronomers) already use TAI to do it. I have written such code (more than once), the first thing you do is to find UT1 - TAI, then proceed with various rotations from there. 50 years ago, using UTC as an approximation to UT1 when you didn't happen to have a multi-million dollar, multi-ton, mainframe in your pocket made sense. Today, when that same power (or, actually, more) is in your smart phone (if not your toaster), it doesn't. Regards Marshall > > On Fri, Jan 20, 2012 at 6:20 AM, Phillip Hallam-Baker wrote: >> If we are ever going to get a handle on Internet time we need to get rid of >> the arbitrary correction factors introduced by leap seconds. >> >> The problems caused by leap seconds are that they make it impossible for two >> machines to know if they are referring to the same point in future time and >> quite often introduce errors in the present. >> >> 1) No machine can determine the number of seconds between two arbitrary UTC >> dates in the future since there may be a leap second announced. >> >> 2) If Machine A is attempting to synchronize with machine B on a future >> point in time, they cannot do so unless they know that they have the same >> view of leap seconds. If a leap second is announced and only one makes the >> correction, an error is introduced. >> >> 3) In practice computer systems rarely apply leap seconds at the correct >> time in any case. There is thus a jitter introduced around the introduction >> of leap seconds as different machines get an NTP fix at different points in >> time. >> >> 4) Even though it is possible to represent leap seconds correctly in >> standard formats, doing so is almost certain to exercise code paths that >> should be avoided. >> >> >> Since the ITU does not look like sorting this out, I suggest we do so in the >> IETF. There is no functional reason that Internet protocols should need leap >> seconds. >> >> I suggest that the IETF plan to move to Internet Time in 2015, immediately >> after the next ITU meeting. Internet time would be TAI plus the number of >> leap seconds that have accumulated up to the next ITU decision point. So if >> UTC drops leap seconds at the next meeting the two series will be in sync, >> otherwise there will be a divergence. >> >> >> >> -- >> Website: http://hallambaker.com/ >> >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From nick@inex.ie Fri Jan 20 07:27:42 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D037421F8540 for ; Fri, 20 Jan 2012 07:27:42 -0800 (PST) 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 hcgXte6QzMPZ for ; Fri, 20 Jan 2012 07:27:42 -0800 (PST) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1B18421F84FC for ; Fri, 20 Jan 2012 07:27:41 -0800 (PST) X-Envelope-To: ietf@ietf.org Received: from cupcake.internal.acquirer.com (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q0KFSpPV042397 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 20 Jan 2012 15:28:51 GMT (envelope-from nick@inex.ie) Message-ID: <4F1987E9.2060102@inex.ie> Date: Fri, 20 Jan 2012 15:27:37 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Tony Finch Subject: Re: ITC copped out on UTC again References: <4F197D14.7080807@inex.ie> In-Reply-To: X-Enigmail-Version: 1.3.4 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker , IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 15:27:42 -0000 On 20/01/2012 15:13, Tony Finch wrote: > We can paper over this difference by adjusting time zones every few > hundred years. In fact time zone adjustments will work further into the > future than leap seconds. But speculating about what will happen that far > into the future is foolish. it's also a valid concern. Abolishing leap seconds kicks the can down the road as far as this is concerned. And while it's tempting to push this sort of decision down on future generations, they're not going to love us for it in a couple of hundred years if they need to adjust by an hour to get solar time in sync with UTC again. Of course, you can talk about this and say that it's a theoretical nicety, but it will also break the tie between TAI and UTC at that stage, which invalidates most of Phillip's arguments to some degree or other - not to a degree that affects us here and now, but that will affect humankind in the future. That's assuming that we haven't reverted to hunting with spears by that stage. I'm not arguing the point either way, btw. Just pointing out that there's a lot more to this argument than Phillip's clear and well-articulated reasons why leap seconds should be abolished. Nick From marshall.eubanks@gmail.com Fri Jan 20 07:32:08 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8CB21F85A1 for ; Fri, 20 Jan 2012 07:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.479 X-Spam-Level: X-Spam-Status: No, score=-103.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, 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 i-t0h03wG6ps for ; Fri, 20 Jan 2012 07:32:07 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F75021F859F for ; Fri, 20 Jan 2012 07:32:07 -0800 (PST) Received: by obbwc12 with SMTP id wc12so1034062obb.31 for ; Fri, 20 Jan 2012 07:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=deUO1E9KQxfpxU/U0BpHthCRq+1dgj0GoyMZnwnq2ts=; b=qPqX6KamUNQwlm8BZhmqcQheovcruywcXgpFVsVr/GVSR2YIjb/96BZn8LBAK4X36U y8Aii+tpOOg+BG8dx/2tDrLw4Igo/cNeNAM8skqVbT1Gr6+glcLonXuU880OZsaxp+o3 HvNSUywARkNTfoiXu2TGhbnv1bXCvtf5ugfxY= MIME-Version: 1.0 Received: by 10.182.222.102 with SMTP id ql6mr27123712obc.2.1327073527159; Fri, 20 Jan 2012 07:32:07 -0800 (PST) Received: by 10.182.79.102 with HTTP; Fri, 20 Jan 2012 07:32:07 -0800 (PST) In-Reply-To: References: <4F197D14.7080807@inex.ie> Date: Fri, 20 Jan 2012 10:32:07 -0500 Message-ID: Subject: Re: ITC copped out on UTC again From: Marshall Eubanks To: Tony Finch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Phillip Hallam-Baker , IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 15:32:08 -0000 On Fri, Jan 20, 2012 at 10:13 AM, Tony Finch wrote: > Nick Hilliard wrote: >> >> Your arguments in favour of abolishing leap seconds are all good. =A0But= can >> you please do us all a favour and provide a similarly lucid list of reas= ons >> that an apologist would use to say that leap seconds should be kept. > > I agree that leap seconds are a horrible bodge that would be best got rid > of. The reasons to keep them mainly revolve around systems that require > UT1, i.e. the angle of rotation of the Earth, and the protocols that > disseminate UT1. > > These include: > Astronomical systems > Space and satellite ground stations > Time broadcast standards > All of these are computer controlled now-a-days, and have been for some time. Even in the 1980's, the computer systems used UT1, not UTC. > Many protocols and software implementations rely on the guarantee that > DUT1 (the difference between UTC and UT1) is less than 0.9s. For instance > many time broadcast formats don't have space for larger values of DUT1. > > Many instruments that point at the sky rely on the fact that DUT1 < > 0.9s for establishing an initial rough aim. Not so much the professional ones. > > For more examples see http://futureofutc.org/preprints Look at Daniel Gambis' survey Preprint-668 (~ 75% in favor of not changing anything). > > At a more philosophical level a lot of people find it difficult to accept > the idea of decoupling time from Earth rotation, to the extent that they > say it is obvious nonsense or foolishness, even though the rate error is > only one second every year or two. However UT1 is slowing down > quadratically, so the time scales will diverge increasingly rapidly. Yes. Note that for the same reason leap seconds will, in a century or so, s= tart to come very frequently. > > We can paper over this difference by adjusting time zones every few > hundred years. In fact time zone adjustments will work further into the > future than leap seconds. But speculating about what will happen that far > into the future is foolish. > > Numbers for divergence between UTC and TAI: > http://www.ucolick.org/~sla/leapsecs/dutc.html#dutctable My actual proposal, if I were to make one, would be to keep UTC, but to make TAI "Internet time" and try and move most electronic things to TAI, keeping UTC only for civil time. Note that time is tricky and slippery and _any_ change, even this one, will have some painful consequences, for somebody, and past experience is that some of those won't be found until the change is made. Regards Marshall > > Tony. > -- > f.anthony.n.finch =A0 =A0http://dotat.at/ > Sole, Lundy, Fastnet, Irish Sea, Shannon: West 5 to 7, occasionally gale = 8 > later in Irish Sea. Moderate or rough, occasionally very rough except in = Lundy > and Irish Sea. Occasional rain or drizzle. Good, occasionally poor. > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From fanf2@hermes.cam.ac.uk Fri Jan 20 07:49:03 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C768221F863E for ; Fri, 20 Jan 2012 07:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.451, 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 qocpshDdrIwR for ; Fri, 20 Jan 2012 07:49:03 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 02DA721F8655 for ; Fri, 20 Jan 2012 07:49:03 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:42900) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1RoGi5-0005Id-Xc (Exim 4.72) (return-path ); Fri, 20 Jan 2012 15:49:01 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RoGi5-0003Qq-Bn (Exim 4.67) (return-path ); Fri, 20 Jan 2012 15:49:01 +0000 Date: Fri, 20 Jan 2012 15:49:01 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Nick Hilliard Subject: Re: ITC copped out on UTC again In-Reply-To: <4F1987E9.2060102@inex.ie> Message-ID: References: <4F197D14.7080807@inex.ie> <4F1987E9.2060102@inex.ie> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Phillip Hallam-Baker , IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 15:49:03 -0000 Nick Hilliard wrote: > > Abolishing leap seconds kicks the can down the road as far as this is > concerned. And while it's tempting to push this sort of decision down > on future generations, they're not going to love us for it in a couple > of hundred years if they need to adjust by an hour to get solar time in > sync with UTC again. Yes. > Of course, you can talk about this and say that it's a theoretical > nicety, but it will also break the tie between TAI and UTC at that > stage, which invalidates most of Phillip's arguments to some degree or > other - not to a degree that affects us here and now, but that will > affect humankind in the future. No, a timezone change (or rather a series of timezone changes) doesn't affect the relationship between UTC and TAI. The changes don't even need global co-ordination. Tony. -- f.anthony.n.finch http://dotat.at/ Sole, Lundy, Fastnet, Irish Sea, Shannon: West 5 to 7, occasionally gale 8 later in Irish Sea. Moderate or rough, occasionally very rough except in Lundy and Irish Sea. Occasional rain or drizzle. Good, occasionally poor. From fanf2@hermes.cam.ac.uk Fri Jan 20 07:52:28 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447A421F8599 for ; Fri, 20 Jan 2012 07:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.395, 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 lFzQqKYJXKf9 for ; Fri, 20 Jan 2012 07:52:27 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 7570921F8592 for ; Fri, 20 Jan 2012 07:52:27 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:43866) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1RoGlO-0000mg-X8 (Exim 4.72) (return-path ); Fri, 20 Jan 2012 15:52:26 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RoGlO-00043I-5u (Exim 4.67) (return-path ); Fri, 20 Jan 2012 15:52:26 +0000 Date: Fri, 20 Jan 2012 15:52:26 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Marshall Eubanks Subject: Re: ITC copped out on UTC again In-Reply-To: Message-ID: References: <4F197D14.7080807@inex.ie> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Phillip Hallam-Baker , IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 15:52:28 -0000 Marshall Eubanks wrote: > > My actual proposal, if I were to make one, would be to keep UTC, but to > make TAI "Internet time" and try and move most electronic things to TAI, > keeping UTC only for civil time. This doesn't actually fix the problems that Phill listed, and it conflicts with standards such as POSIX. Tony. -- f.anthony.n.finch http://dotat.at/ Faeroes, South-east Iceland: Southwesterly 5 or 6, becoming cyclonic 7 to severe gale 9, occasionally storm 10. Very rough or high, occasionally very high in Faeroes. Rain or squally showers. Good, occasionally poor. From nick@inex.ie Fri Jan 20 07:56:32 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EF521F84D2 for ; Fri, 20 Jan 2012 07:56:32 -0800 (PST) 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 7QdL2gPY6nKc for ; Fri, 20 Jan 2012 07:56:31 -0800 (PST) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 8B19C21F84C8 for ; Fri, 20 Jan 2012 07:56:31 -0800 (PST) X-Envelope-To: ietf@ietf.org Received: from cupcake.internal.acquirer.com (inet-gw.acquirer.com [87.198.142.10]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q0KFvfl6042807 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 20 Jan 2012 15:57:42 GMT (envelope-from nick@inex.ie) Message-ID: <4F198EAB.2010700@inex.ie> Date: Fri, 20 Jan 2012 15:56:27 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Tony Finch Subject: Re: ITC copped out on UTC again References: <4F197D14.7080807@inex.ie> <4F1987E9.2060102@inex.ie> In-Reply-To: X-Enigmail-Version: 1.3.4 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker , IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 15:56:32 -0000 On 20/01/2012 15:49, Tony Finch wrote: > No, a timezone change (or rather a series of timezone changes) doesn't > affect the relationship between UTC and TAI. The changes don't even need > global co-ordination. you could deal with this using TZ changes, but that's turning it into someone else's problem. Not so much kicking the can down the road as pushing the problem up the political stack (not particularly wanting to mix metaphors). And fixing the problem at a political level requires some sort of semi-coordinated global legislation. Nick From fanf2@hermes.cam.ac.uk Fri Jan 20 07:59:16 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF8621F84DC for ; Fri, 20 Jan 2012 07:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=0.351, 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 KLoU0TcDfsvV for ; Fri, 20 Jan 2012 07:59:16 -0800 (PST) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) by ietfa.amsl.com (Postfix) with ESMTP id D98BF21F84D2 for ; Fri, 20 Jan 2012 07:59:15 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:34464) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1RoGrw-0005An-Sg (Exim 4.72) (return-path ); Fri, 20 Jan 2012 15:59:12 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RoGrw-0005LB-Ra (Exim 4.67) (return-path ); Fri, 20 Jan 2012 15:59:12 +0000 Date: Fri, 20 Jan 2012 15:59:12 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Nick Hilliard Subject: Re: ITC copped out on UTC again In-Reply-To: <4F198EAB.2010700@inex.ie> Message-ID: References: <4F197D14.7080807@inex.ie> <4F1987E9.2060102@inex.ie> <4F198EAB.2010700@inex.ie> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Phillip Hallam-Baker , IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 15:59:16 -0000 Nick Hilliard wrote: > > you could deal with this using TZ changes, but that's turning it into > someone else's problem. Not so much kicking the can down the road as > pushing the problem up the political stack (not particularly wanting to mix > metaphors). And fixing the problem at a political level requires some sort > of semi-coordinated global legislation. Yes, that's exactly what the ITU-R is doing here. Remember it is a UN treaty organization. Tony. -- f.anthony.n.finch http://dotat.at/ Faeroes, South-east Iceland: Southwesterly 5 or 6, becoming cyclonic 7 to severe gale 9, occasionally storm 10. Very rough or high, occasionally very high in Faeroes. Rain or squally showers. Good, occasionally poor. From cos@mip.polyamory.org Fri Jan 20 10:04:50 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4E721F86B2 for ; Fri, 20 Jan 2012 10:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 EiY84yOAG6W7 for ; Fri, 20 Jan 2012 10:04:49 -0800 (PST) Received: from mip.polyamory.org (mip.polyamory.org [199.201.145.10]) by ietfa.amsl.com (Postfix) with ESMTP id C261921F869C for ; Fri, 20 Jan 2012 10:04:49 -0800 (PST) Received: by mip.polyamory.org (Postfix, from userid 1002) id 3D29810760; Fri, 20 Jan 2012 13:04:41 -0500 (EST) Date: Fri, 20 Jan 2012 13:04:41 -0500 From: Ofer Inbar To: IETF Discussion Mailing List Subject: Re: ITC copped out on UTC again Message-ID: <20120120180441.GH341@mip.aaaaa.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 18:04:50 -0000 If the main problem with leap seconds is their future unpredictability, isn't there a compromise option between the status quo and no more leap seconds? Couldn't they come up with a fixed schedule for leap seconds for many centuries at a time, based on current predictions of approximately how many will be needed each century? That should be good enough to prevent real human-noticeable drift between UTC and perceived day/night time. If a correction is needed because current predictions turn out to be wrong, it seems that could be done very rarely, with centuries of lead time in changes to the schedule. Was anything like this considered at the international level? [ I know this is not something the IETF can decide, of course ] -- Cos From mcr@sandelman.ca Fri Jan 20 10:13:59 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85B721F8650 for ; Fri, 20 Jan 2012 10:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.454 X-Spam-Level: X-Spam-Status: No, score=-1.454 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 uN3LA2LpBwbH for ; Fri, 20 Jan 2012 10:13:59 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 66D8021F864F for ; Fri, 20 Jan 2012 10:13:59 -0800 (PST) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 66D8F34466; Fri, 20 Jan 2012 13:11:55 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 2FF8E9845F; Fri, 20 Jan 2012 13:13:58 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 24FFD9845D; Fri, 20 Jan 2012 13:13:58 -0500 (EST) From: Michael Richardson To: Phillip Hallam-Baker Subject: Re: ITC copped out on UTC again In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Fri, 20 Jan 2012 13:13:58 -0500 Message-ID: <6010.1327083238@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 18:13:59 -0000 >>>>> "Phillip" == Phillip Hallam-Baker writes: Phillip> If we are ever going to get a handle on Internet time we Phillip> need to get rid of the arbitrary correction factors Phillip> introduced by leap seconds. Phillip> The problems caused by leap seconds are that they make it Phillip> impossible for two machines to know if they are referring Phillip> to the same point in future time and quite often introduce Phillip> errors in the present. Can you tell me which protocols use future timestamps in an moving form (not stored at rest in a certificate in a DANE RR, for instance), which care about discrepancies of less than 1 minute? I'm asking for information. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From warren@kumari.net Fri Jan 20 10:16:09 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4C521F8675 for ; Fri, 20 Jan 2012 10:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 S+vtlv4tEkiB for ; Fri, 20 Jan 2012 10:16:09 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 0645721F8646 for ; Fri, 20 Jan 2012 10:16:09 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 2D53D1B402A0; Fri, 20 Jan 2012 13:16:08 -0500 (EST) Subject: Re: [IETF] Re: ITC copped out on UTC again Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <20120120180441.GH341@mip.aaaaa.org> Date: Fri, 20 Jan 2012 13:16:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120120180441.GH341@mip.aaaaa.org> To: Ofer Inbar X-Mailer: Apple Mail (2.1084) Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 18:16:09 -0000 On Jan 20, 2012, at 1:04 PM, Ofer Inbar wrote: > If the main problem with leap seconds is their future > unpredictability, isn't there a compromise option between the status > quo and no more leap seconds? Couldn't they come up with a fixed > schedule for leap seconds for many centuries at a time, based on > current predictions of approximately how many will be needed each > century? >=20 > That should be good enough to prevent real human-noticeable drift > between UTC and perceived day/night time. If a correction is needed > because current predictions turn out to be wrong, it seems that could > be done very rarely, with centuries of lead time in changes to the > schedule. Was anything like this considered at the international = level? >=20 > [ I know this is not something the IETF can decide, of course ] So, many of these discussions and suggestions seem to be at best = addressing a symptom (time is diverging) versus the actual issue (the = planet is slowing down) -- this feels to me like a bandaid over a gaping = wound. So, my proposal is that, at the next meeting, we all face counter to the = rotation and blow really hard -- Lord knows that we generate enough hot = air, maybe we can finally put some of it to good use. I'm considering proposing a bar BOF so that we can determine just how = long we would need to blow for. Obviously different folk generate vastly = different amounts of hot air, and so factors like this would need to be = taken into consideration, etc. W > -- Cos > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 From tglassey@earthlink.net Fri Jan 20 10:25:10 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954B921F8617 for ; Fri, 20 Jan 2012 10:25:09 -0800 (PST) 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 1uT8Hks4zd30 for ; Fri, 20 Jan 2012 10:25:09 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id BAAC921F85EC for ; Fri, 20 Jan 2012 10:25:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=mHmRUeCuO2SMa65jDhtJy9nv9UcuesIc9EPIligFmG9IiOS/9HmOXYqfszW7gcMn; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Opacus-Archived:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [216.171.124.254] (helo=[192.168.0.4]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RoJ96-0001ns-NQ; Fri, 20 Jan 2012 13:25:04 -0500 Message-ID: <4F19B17C.20904@earthlink.net> Date: Fri, 20 Jan 2012 10:25:00 -0800 From: todd glassey User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Michael Richardson Subject: Re: ITC copped out on UTC again References: <6010.1327083238@marajade.sandelman.ca> In-Reply-To: <6010.1327083238@marajade.sandelman.ca> X-Opacus-Archived: none X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec793c47c52ea71b153d67be9ac68dd99102350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 216.171.124.254 Cc: Phillip Hallam-Baker , IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 18:25:10 -0000 On 1/20/2012 10:13 AM, Michael Richardson wrote: > >>>>>> "Phillip" == Phillip Hallam-Baker writes: > Phillip> If we are ever going to get a handle on Internet time we > Phillip> need to get rid of the arbitrary correction factors > Phillip> introduced by leap seconds. > > Phillip> The problems caused by leap seconds are that they make it > Phillip> impossible for two machines to know if they are referring > Phillip> to the same point in future time and quite often introduce > Phillip> errors in the present. BULL. Sorry Phillip - but this is ONLY about the need to create something that is stronger than the word of the systems administrator. The issue is that NTP is broken. Both in its design and its use processes today. The architecture of the time-sychronization process was specifically designed to not produce evidence. What is produces is uncorrelated time data. > > Can you tell me which protocols use future timestamps in an moving form > (not stored at rest in a certificate in a DANE RR, for instance), which > care about discrepancies of less than 1 minute? > > I'm asking for information. Power use tokens, any number of FIX type events which create timestamps representing financial information. Any number of others too. > -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. From clint.chaplin@gmail.com Fri Jan 20 11:15:19 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D0721F864E for ; Fri, 20 Jan 2012 11:15:19 -0800 (PST) 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 K+Q5lMZwGGgC for ; Fri, 20 Jan 2012 11:15:18 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4D721F864C for ; Fri, 20 Jan 2012 11:15:18 -0800 (PST) Received: by eekc1 with SMTP id c1so398258eek.31 for ; Fri, 20 Jan 2012 11:15:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZE2i7r4XQsHBUNmAPDHe7rDmqsVg1stgkiUukc+9iqw=; b=ueCaIN1eIxiPDJr1HCWQGKnQVjkaFBiXkIRMFrH4BLnSkc5EKHI2BjWitOMZw4CuKX wglmAfzAu3aRjnIZePpY3tqT7CPQRwTkZFtsc23WxbtmxFugXB7A0xlvIgYL8b2hYNAV bb0zlBpf/GIv2peFdNbuN1of70uqb/wPlZKdk= MIME-Version: 1.0 Received: by 10.14.40.79 with SMTP id e55mr3712900eeb.26.1327086917408; Fri, 20 Jan 2012 11:15:17 -0800 (PST) Received: by 10.213.112.148 with HTTP; Fri, 20 Jan 2012 11:15:17 -0800 (PST) In-Reply-To: <20120120180441.GH341@mip.aaaaa.org> References: <20120120180441.GH341@mip.aaaaa.org> Date: Fri, 20 Jan 2012 11:15:17 -0800 Message-ID: Subject: Re: ITC copped out on UTC again From: Clint Chaplin To: Ofer Inbar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 19:15:19 -0000 The earth's rate of rotation is not uniform, and the rate of change of that rotation is not uniform, either. For instance, I believe, one of the major earthquakes recently caused a change in the earth's rotation because of conservation of angular momentum. ice cap melting may cause similar changes. So, predicting future rates and rate of change is not possible. On Fri, Jan 20, 2012 at 10:04 AM, Ofer Inbar wrote: > If the main problem with leap seconds is their future > unpredictability, isn't there a compromise option between the status > quo and no more leap seconds? =A0Couldn't they come up with a fixed > schedule for leap seconds for many centuries at a time, based on > current predictions of approximately how many will be needed each > century? > > That should be good enough to prevent real human-noticeable drift > between UTC and perceived day/night time. =A0If a correction is needed > because current predictions turn out to be wrong, it seems that could > be done very rarely, with centuries of lead time in changes to the > schedule. =A0Was anything like this considered at the international level= ? > > [ I know this is not something the IETF can decide, of course ] > =A0-- Cos > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --=20 Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization (US) SISA From randy_presuhn@mindspring.com Fri Jan 20 11:16:05 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4451F21F8684 for ; Fri, 20 Jan 2012 11:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 RBAYOMk2XqE5 for ; Fri, 20 Jan 2012 11:16:04 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id B93B621F8646 for ; Fri, 20 Jan 2012 11:16:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=SSTFMqTarV+kadNBnkFwqjlUlDgv0zSGs+EPVK8o6uGFIgzZx2237IgVaoL3O3YN; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.30.226.142] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RoJwS-0003ao-2O for ietf@ietf.org; Fri, 20 Jan 2012 14:16:04 -0500 Message-ID: <005101ccd7a8$784b9a80$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "IETF Discussion Mailing List" References: <6010.1327083238@marajade.sandelman.ca> Subject: Re: ITC copped out on UTC again Date: Fri, 20 Jan 2012 11:19:44 -0800 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88874e73e997ea5cd0f6a708f5093ca1c2c99d860f76b7f07b2350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.226.142 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 19:16:05 -0000 Hi - > From: "Michael Richardson" > To: "Phillip Hallam-Baker" > Cc: "IETF Discussion Mailing List" > Sent: Friday, January 20, 2012 10:13 AM > Subject: Re: ITC copped out on UTC again ... > Can you tell me which protocols use future timestamps in an moving form > (not stored at rest in a certificate in a DANE RR, for instance), which > care about discrepancies of less than 1 minute? The disman Scheduling MIB (RFC 3231) has future timestamps. They are defined as dates / times, with provision for how discontinuities in civil time (whether due to "summer time", time zone changes, or leap seconds) are to be handled. This definition makes it unlikely that a sane developer would internally represent them as computed intervals. Leap second handling is a big non-issue in SNMP-land, as far as I know. Randy From brian.e.carpenter@gmail.com Fri Jan 20 11:27:03 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C88E21F8598 for ; Fri, 20 Jan 2012 11:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.573 X-Spam-Level: X-Spam-Status: No, score=-103.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, 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 I+ljiORF0pnt for ; Fri, 20 Jan 2012 11:27:03 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF6BD21F8587 for ; Fri, 20 Jan 2012 11:27:02 -0800 (PST) Received: by eekc1 with SMTP id c1so403920eek.31 for ; Fri, 20 Jan 2012 11:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZG7WGAucG9N6hw3vlZXP6m+GAGQFhvjtkb+geA0YE6k=; b=KBQe8/bWVC0biHZIf5HDvGkglJG3NSeueI97hhOuH3WXFIvcsKWapQt33vuo5Tv3MF DglRNUNS6zquFnXg71mS73U8PYJq5zotrkQUtosM1fiEFRPjPtoQfK5g1ieXITePkdSQ jYf7LeS6apoALAWOCujsyqFSzE8SR+s1xpzKQ= Received: by 10.14.123.79 with SMTP id u55mr3756982eeh.120.1327087622131; Fri, 20 Jan 2012 11:27:02 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id y12sm15159175eeb.11.2012.01.20.11.26.59 (version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 11:27:01 -0800 (PST) Message-ID: <4F19BFF4.7000102@gmail.com> Date: Sat, 21 Jan 2012 08:26:44 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Phillip Hallam-Baker Subject: Re: ITC copped out on UTC again References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 19:27:03 -0000 On 2012-01-21 03:20, Phillip Hallam-Baker wrote: > If we are ever going to get a handle on Internet time we need to get rid of > the arbitrary correction factors introduced by leap seconds. Time is and always will be an arbitrary measurement scheme, and the only thing that makes sense for the Internet is to use the same arbitrary scheme as everybody else. We just have to suck up the resulting inconveniences, as GPS has to. It would be unthinkable to go it alone. Alternatively we could revert to the Julian (365.25 day) calendar, which was considerably more convenient for programmers, or perhaps to one of the old Iranian (360 day) calendars, which are convenient in some ways but do require occasional leap months. Brian From hallam@gmail.com Fri Jan 20 11:51:10 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE7421F8650 for ; Fri, 20 Jan 2012 11:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.334 X-Spam-Level: X-Spam-Status: No, score=-3.334 tagged_above=-999 required=5 tests=[AWL=0.264, 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 8Sazhd0Twe79 for ; Fri, 20 Jan 2012 11:51:09 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 587B121F8679 for ; Fri, 20 Jan 2012 11:51:09 -0800 (PST) Received: by obbwc12 with SMTP id wc12so1347773obb.31 for ; Fri, 20 Jan 2012 11:51:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=56/fQUhCzOeoJFqUH/WJWk8endpX1CHTJiOWqXzJ990=; b=si9Iom7THICWlkRLNt/SEk6zk4/iyfaTtHH0x1CIvgoJxormtR0I9F/JfF9yh19PfL zgJTFkMKVhifxobz3VEVh/24CghSOu9KXZPMJyvTvYDTQA0mr6zU7Is3NyxzzTM6dWNb b4P3C45CYIiM4BlQ5bLkTOxJqNIpmvMgiNqLw= MIME-Version: 1.0 Received: by 10.182.113.97 with SMTP id ix1mr27967854obb.41.1327089068936; Fri, 20 Jan 2012 11:51:08 -0800 (PST) Received: by 10.182.11.169 with HTTP; Fri, 20 Jan 2012 11:51:08 -0800 (PST) In-Reply-To: References: <4F197D14.7080807@inex.ie> Date: Fri, 20 Jan 2012 14:51:08 -0500 Message-ID: Subject: Re: ITC copped out on UTC again From: Phillip Hallam-Baker To: Marshall Eubanks Content-Type: multipart/alternative; boundary=f46d0447f2a68a0f0404b6fb0057 Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 19:51:10 -0000 --f46d0447f2a68a0f0404b6fb0057 Content-Type: text/plain; charset=ISO-8859-1 If I was designing a protocol from scratch that required accurate time, I would indeed use TAI. In fact I am planning to do exactly that. The problem here is fear of the unknown. A small clique that has a very narrow set of interests (and not ones I find very important) has by tradition and inertia been left to decide this issue according to what suits them. Proposing to introduce a third scheme and even more confusion is a bad technical strategy but possibly an effective political strategy. It is like threatening civil disobedience, once someone decides that they care enough to risk breaking the system it becomes much harder to defend the status quo. I agree with Brian's points about the fact that time is an arbitrary quantity. One relativity is considered, time becomes a mindbendlingly complex notion. The poles are moving at a different speed relative to the equator for a start. And the orbit of the earth is chaotic. Oh the fun people can have if they want to try to issue correction factors. Add to that the fact that the prime meridian is located on a tectonic plate that is essentially floating on a sea of molten magma. Let time be time and let people who want to tie physical phenomena to time work out the relevant correction factors. On Fri, Jan 20, 2012 at 10:32 AM, Marshall Eubanks < marshall.eubanks@gmail.com> wrote: > On Fri, Jan 20, 2012 at 10:13 AM, Tony Finch wrote: > > Nick Hilliard wrote: > >> > >> Your arguments in favour of abolishing leap seconds are all good. But > can > >> you please do us all a favour and provide a similarly lucid list of > reasons > >> that an apologist would use to say that leap seconds should be kept. > > > > I agree that leap seconds are a horrible bodge that would be best got rid > > of. The reasons to keep them mainly revolve around systems that require > > UT1, i.e. the angle of rotation of the Earth, and the protocols that > > disseminate UT1. > > > > These include: > > Astronomical systems > > Space and satellite ground stations > > Time broadcast standards > > > > All of these are computer controlled now-a-days, and have been for > some time. Even in the 1980's, the computer systems used > UT1, not UTC. > > > Many protocols and software implementations rely on the guarantee that > > DUT1 (the difference between UTC and UT1) is less than 0.9s. For instance > > many time broadcast formats don't have space for larger values of DUT1. > > > > Many instruments that point at the sky rely on the fact that DUT1 < > > 0.9s for establishing an initial rough aim. > > Not so much the professional ones. > > > > > For more examples see http://futureofutc.org/preprints > > Look at Daniel Gambis' survey > > Preprint-668 > > (~ 75% in favor of not changing anything). > > > > > At a more philosophical level a lot of people find it difficult to accept > > the idea of decoupling time from Earth rotation, to the extent that they > > say it is obvious nonsense or foolishness, even though the rate error is > > only one second every year or two. However UT1 is slowing down > > quadratically, so the time scales will diverge increasingly rapidly. > > Yes. Note that for the same reason leap seconds will, in a century or so, > start > to come very frequently. > > > > > We can paper over this difference by adjusting time zones every few > > hundred years. In fact time zone adjustments will work further into the > > future than leap seconds. But speculating about what will happen that far > > into the future is foolish. > > > > Numbers for divergence between UTC and TAI: > > http://www.ucolick.org/~sla/leapsecs/dutc.html#dutctable > > My actual proposal, if I were to make one, would be to keep UTC, but > to make TAI "Internet time" and try and > move most electronic things to TAI, keeping UTC only for civil time. > > Note that time is tricky and slippery and _any_ change, even this one, > will have some painful consequences, for somebody, and past > experience is that some of those won't be found until the change is made. > > Regards > Marshall > > > > > Tony. > > -- > > f.anthony.n.finch http://dotat.at/ > > Sole, Lundy, Fastnet, Irish Sea, Shannon: West 5 to 7, occasionally gale > 8 > > later in Irish Sea. Moderate or rough, occasionally very rough except in > Lundy > > and Irish Sea. Occasional rain or drizzle. Good, occasionally poor. > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > -- Website: http://hallambaker.com/ --f46d0447f2a68a0f0404b6fb0057 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If I was designing a protocol from scratch that required accurate time, I w= ould indeed use TAI. In fact I am planning to do exactly that.

      The problem here is fear of the unknown. A small clique that has a v= ery narrow set of interests (and not ones I find very important) has by tra= dition and inertia been left to decide this issue according to what suits t= hem. Proposing to introduce a third scheme and even more confusion is a bad= technical strategy but possibly an effective political strategy. It is lik= e threatening civil disobedience, once someone decides that they care enoug= h to risk breaking the system it becomes much harder to defend the status q= uo.


      I agree with Brian's points about th= e fact that time is an arbitrary quantity. One relativity is considered, ti= me becomes a mindbendlingly complex notion. The poles are moving at a diffe= rent speed relative to the equator for a start. And the orbit of the earth = is chaotic. Oh the fun people can have if they want to try to issue correct= ion factors.

      Add to that the fact that the prime meridian is located= on a tectonic plate that is essentially floating on a sea of molten magma.= =A0


      Let time be time and let people= who want to tie physical phenomena to time work out the relevant correctio= n factors.



      On Fri, J= an 20, 2012 at 10:32 AM, Marshall Eubanks <marshall.eubanks@gmail.com> wrote:
      On Fri, Jan 20, 2012 at 10= :13 AM, Tony Finch <dot@dotat.at>= wrote:
      > Nick Hilliard <nick@inex.ie>= wrote:
      >>
      >> Your arguments in favour of abolishing leap seconds are all good. = =A0But can
      >> you please do us all a favour and provide a similarly lucid list o= f reasons
      >> that an apologist would use to say that leap seconds should be kep= t.
      >
      > I agree that leap seconds are a horrible bodge that would be best got = rid
      > of. The reasons to keep them mainly revolve around systems that requir= e
      > UT1, i.e. the angle of rotation of the Earth, and the protocols that > disseminate UT1.
      >
      > These include:
      > Astronomical systems
      > Space and satellite ground stations
      > Time broadcast standards
      >

      All of these are computer controlled now-a-days, and have been for some time. Even in the 1980's, the computer systems used
      UT1, not UTC.

      > Many protocols and software implementations rely on the guarantee that=
      > DUT1 (the difference between UTC and UT1) is less than 0.9s. For insta= nce
      > many time broadcast formats don't have space for larger values of = DUT1.
      >
      > Many instruments that point at the sky rely on the fact that DUT1 <=
      > 0.9s for establishing an initial rough aim.

      Not so much the professional ones.

      >
      > For more examples see http://futureofutc.org/preprints

      Look at Daniel Gambis' survey

      Preprint-668

      (~ 75% in favor of not changing anything).

      >
      > At a more philosophical level a lot of people find it difficult to acc= ept
      > the idea of decoupling time from Earth rotation, to the extent that th= ey
      > say it is obvious nonsense or foolishness, even though the rate error = is
      > only one second every year or two. However UT1 is slowing down
      > quadratically, so the time scales will diverge increasingly rapidly.
      Yes. Note that for the same reason leap seconds will, in a century or= so, start
      to come very frequently.

      >
      > We can paper over this difference by adjusting time zones every few > hundred years. In fact time zone adjustments will work further into th= e
      > future than leap seconds. But speculating about what will happen that = far
      > into the future is foolish.
      >
      > Numbers for divergence between UTC and TAI:
      > http://www.ucolick.org/~sla/leapsecs/dutc.html#dutctable

      My actual proposal, if I were to make one, would be to keep UTC, but<= br> to make TAI "Internet time" and try and
      move most electronic things to TAI, keeping UTC only for civil time.

      Note that time is tricky and slippery and _any_ change, even this one,
      will have some painful consequences, for somebody, and =A0past
      experience is that some of those won't be found until the change is mad= e.

      Regards
      Marshall

      >
      > Tony.
      > --
      > f.anthony.n.finch =A0<      dot@dotat.at<= /a>> =A0http://dotat.at/<= /a>
      > Sole, Lundy, Fastnet, Irish Sea, Shannon: West 5 to 7, occasionally ga= le 8
      > later in Irish Sea. Moderate or rough, occasionally very rough except = in Lundy
      > and Irish Sea. Occasional rain or drizzle. Good, occasionally poor.
      > ________________________= _______________________
      > Ietf mailing list
      >       Ietf@ietf.org
      > https://www.ietf.org/mailman/listinfo/ietf



      --
      = Website: http://hallambaker.com/
      --f46d0447f2a68a0f0404b6fb0057-- From david.black@emc.com Thu Jan 19 14:54:51 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01A721F85D0; Thu, 19 Jan 2012 14:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.833 X-Spam-Level: X-Spam-Status: No, score=-108.833 tagged_above=-999 required=5 tests=[AWL=1.766, 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 5uEN0QJ1scK3; Thu, 19 Jan 2012 14:54:50 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id EFC2621F85C9; Thu, 19 Jan 2012 14:54:49 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0JMsYFH024105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jan 2012 17:54:39 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 19 Jan 2012 17:54:15 -0500 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0JMsDwv006681; Thu, 19 Jan 2012 17:54:13 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub31.corp.emc.com ([128.222.70.171]) with mapi; Thu, 19 Jan 2012 17:54:13 -0500 From: To: Date: Thu, 19 Jan 2012 17:54:12 -0500 Subject: Gen-ART review of draft-daboo-webdav-sync-07 Thread-Topic: Gen-ART review of draft-daboo-webdav-sync-07 Thread-Index: AczWywMBbl5mbsctTV2kg2BDvHgIIwAMK4XA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7CF1011@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC94C9@MX14A.corp.emc.com> <250FD273F8360ED86D73260F@cyrus.local> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B9F@MX14A.corp.emc.com> <4F184A85.60604@stpeter.im> In-Reply-To: <4F184A85.60604@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Fri, 20 Jan 2012 14:36:57 -0800 Cc: gen-art@ietf.org, arnaud.quillaud@oracle.com, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 22:54:51 -0000 SGkgUGV0ZXIsDQoNClllcywgdGhlIG5ldyAtMDcgb2YgdGhpcyBkcmFmdCBpcyBmaW5lLCBhcyBp dCByZXNvbHZlcyBpc3N1ZXMgWzFdIGFuZCBbMl0gYXMgYWdyZWVkDQp3aXRoIHRoZSBhdXRob3Jz LCBhbmQgYWxzbyByZXNvbHZlcyBpc3N1ZSBbM10gYnkgY2hhbmdpbmcgUkZDIDU4NDIgZnJvbSBh IG5vcm1hdGl2ZQ0KcmVmZXJlbmNlIHRvIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZS4gVGhhdCBj aGFuZ2UgaXMgZmluZSB3aXRoIG1lLCBhcyB0aGUgcmVmZXJlbmNlcw0KdG8gUkZDIDU4NDIgYXJl IGFsbCBmb3IgZXhhbXBsZXMgdGhhdCBleHBsYWluIHNvbWUgb2YgdGhlIHN5bmNocm9uaXphdGlv biBmdW5jdGlvbmFsaXR5DQotIGl0IGlzIG5vdCBuZWNlc3NhcnkgdG8gaW1wbGVtZW50IGFueSBv ZiB0aGUgcmVxdWVzdHMgbGlzdGVkIGFzIGJlaW5nIHNwZWNpZmllZCBpbg0KUkZDIDU4NDIgaW4g b3JkZXIgdG8gaW1wbGVtZW50IHRoZSBzeW5jaHJvbml6YXRpb24gZnVuY3Rpb25hbGl0eS4NCg0K VGhhbmtzLA0KLS1EYXZpZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IFBldGVyIFNhaW50LUFuZHJlIFttYWlsdG86c3RwZXRlckBzdHBldGVyLmltXQ0KPiBTZW50OiBU aHVyc2RheSwgSmFudWFyeSAxOSwgMjAxMiAxMTo1MyBBTQ0KPiBUbzogQmxhY2ssIERhdmlkDQo+ IENjOiBjeXJ1c0BkYWJvby5uYW1lOyBhcm5hdWQucXVpbGxhdWRAb3JhY2xlLmNvbTsgZ2VuLWFy dEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogR2VuLUFSVCByZXZpZXcg b2YgZHJhZnQtZGFib28td2ViZGF2LXN5bmMtMDYNCj4gDQo+IEhpIERhdmlkLA0KPiANCj4gVGhl IHRleHQgY2hhbmdlcyB0aGF0IEN5cnVzIHByb3Bvc2VkIGhhdmUgYmVlbiBpbmNvcnBvcmF0ZWQg aW50byBhDQo+IHJldmlzZWQgSS1EOg0KPiANCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1kYWJvby13ZWJkYXYtc3luYy0wNw0KPiANCj4gUGxlYXNlIGxldCB1cyBr bm93IGlmIHRoZSBuZXcgdmVyc2lvbiBhY2N1cmF0ZWx5IHJlZmxlY3RzIHlvdXINCj4gZGlzY3Vz c2lvbiB3aXRoIHRoZSBhdXRob3JzLg0KPiANCj4gVGhhbmtzIQ0KPiANCj4gUGV0ZXINCj4gDQo+ IE9uIDEvMi8xMiAxMjo1NSBQTSwgZGF2aWQuYmxhY2tAZW1jLmNvbSB3cm90ZToNCj4gPiBIaSBD eXJ1cywNCj4gPg0KPiA+IFRoZSBwcm9wb3NlZCBjaGFuZ2VzIGZvciB0aGUgdHdvIG1ham9yIGlz c3VlcyBsb29rIGdvb2QgdG8gbWU6DQo+ID4NCj4gPiBbMV0gSSdtIHBsZWFzZWQgdGhhdCB0aGUg Y29uY2VybiBhYm91dCBhZGRpbmcgZWxlbWVudHMgdHVybmVkIG91dCB0byBiZSBhIHdvcmRpbmcg aXNzdWUuDQo+ID4NCj4gPiBbMl0gWW91ciBwcm9wb3NlZCBuZXcgdGV4dCBpcyBmaW5lIC0gaXQg cHJvdmlkZXMgYWRlcXVhdGUgbm90aWNlL3dhcm5pbmcgYWJvdXQgcG9zc2libGUNCj4gPiBjb2xs ZWN0aW9uIGluY29uc2lzdGVuY3ksIHNvIEknbSBvayB3aXRoIG5vdCBwcm92aWRpbmcgcHNldWRv LWNvZGUuDQo+ID4NCj4gPiBJJ2xsIGxlYXZlIHRoZSBEb3ducmVmIGlzc3VlIChbM10pIGZvciB5 b3UgYW5kIFBldGVyIHRvIHdvcmsgb3V0IHdpdGggdGhlIElFU0csIGFuZCBJJ20NCj4gPiBmaW5l IHdpdGggY29udGludWVkIHVzZSBvZiB5b3VyIG5hbWUgaW4gdGhlIGV4YW1wbGVzIGlmIHRoYXQn cyBjb21tb24gcHJhY3RpY2UuDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gLS1EYXZpZA0KPiA+DQo+ ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEN5cnVzIERhYm9vIFtt YWlsdG86Y3lydXNAZGFib28ubmFtZV0NCj4gPj4gU2VudDogTW9uZGF5LCBKYW51YXJ5IDAyLCAy MDEyIDI6NDQgUE0NCj4gPj4gVG86IEJsYWNrLCBEYXZpZDsgYXJuYXVkLnF1aWxsYXVkQG9yYWNs ZS5jb207IGdlbi1hcnRAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmcNCj4gPj4gQ2M6IHN0cGV0ZXJA c3RwZXRlci5pbQ0KPiA+PiBTdWJqZWN0OiBSZTogR2VuLUFSVCByZXZpZXcgb2YgZHJhZnQtZGFi b28td2ViZGF2LXN5bmMtMDYNCj4gPj4NCj4gPj4gSGkgRGF2aWQsDQo+ID4+IFRoYW5rIHlvdSBm b3IgeW91ciByZXZpZXcuIENvbW1lbnRzIGlubGluZToNCj4gPj4NCj4gPj4gLS1PbiBEZWNlbWJl ciAyNywgMjAxMSAxMTowNzo0OSBQTSAtMDUwMCBkYXZpZC5ibGFja0BlbWMuY29tIHdyb3RlOg0K PiA+Pg0KPiA+Pj4gWzFdIC1NYWpvci0gU2VjdGlvbiAzLjUgZG9lcyBub3QgYXBwZWFyIHRvIGNv dmVyIHRoZSBjYXNlIHJlcG9ydGluZyBhZGRlZA0KPiA+Pj4gZWxlbWVudHMgb24gYSBzdWJzZXF1 ZW50IHN5bmNocm9uaXphdGlvbi4gIFRoZSBwcm9ibGVtIG1heSBiZSB0aGF0IHRoZQ0KPiA+Pj4g d29yZCAiY2hhbmdlZCIgYXMgdXNlZCBpbiBTZWN0aW9uIDMuNS4xIGlzIGFzc3VtZWQgdG8gY292 ZXIgYWRkaW5nIGFuDQo+ID4+PiBlbGVtZW50IC0gaWYgc28sIHRoYXQncyBub3QgYSBnb29kIGFz c3VtcHRpb24sIGFuZCB0aGUgYWRkaXRpb24gY2FzZQ0KPiA+Pj4gc2hvdWxkIGJlIGV4cGxpY2l0 bHkgY2FsbGVkIG91dCBpbiB0aGUgdGl0bGUgYW5kIGJvZHkgb2YgU2VjdGlvbiAzLjUuMS4NCj4g Pj4NCj4gPj4gVGhlIGZpcnN0IHNlbnRlbmNlIG9mIDMuNS4xIGlzOg0KPiA+Pg0KPiA+PiAgICAg QSBtZW1iZXIgVVJMIE1VU1QgYmUgcmVwb3J0ZWQgYXMgY2hhbmdlZCBpZiBpdCBoYXMgYmVlbiBt YXBwZWQgYXMgYQ0KPiA+PiAgICAgbWVtYmVyIG9mIHRoZSB0YXJnZXQgY29sbGVjdGlvbiBzaW5j ZSB0aGUgcmVxdWVzdCBzeW5jLXRva2VuIHdhcw0KPiA+PiAgICAgZ2VuZXJhdGVkLg0KPiA+Pg0K PiA+PiBUaGUgdGVybSAibWFwcGVkIiBpbXBsaWVzIGNyZWF0aW9uL2FkZGl0aW9uIG9mIGEgbmV3 IHJlc291cmNlIGluIHRoaXMgY2FzZS4NCj4gPj4gVGhhdCBtYXkgbm90IGJlIG9idmlvdXMgdG8g YW55b25lIHdobyBpcyBub3QgaW50aW1hdGVseSBmYW1pbGlhciB3aXRoDQo+ID4+IFdlYkRBViB0 ZXJtaW5vbG9neSBoZXJlLCBzbyBJIHByb3Bvc2UgY2hhbmdpbmcgdGhhdCB0bzoNCj4gPj4NCj4g Pj4gICAgIEEgbWVtYmVyIFVSTCBNVVNUIGJlIHJlcG9ydGVkIGFzIGNoYW5nZWQgaWYgaXQgaGFz IGJlZW4gbmV3bHkgbWFwcGVkIGFzDQo+ID4+ICAgICBhIG1lbWJlciBvZiB0aGUgdGFyZ2V0IGNv bGxlY3Rpb24gc2luY2UgdGhlIHJlcXVlc3Qgc3luYy10b2tlbiB3YXMNCj4gPj4gICAgIGdlbmVy YXRlZCAoZS5nLiwgd2hlbiBhIG5ldyByZXNvdXJjZSBoYXMgYmVlbiBjcmVhdGVkIGFzIGEgY2hp bGQgb2YgdGhlDQo+ID4+ICAgICBjb2xsZWN0aW9uKS4NCj4gPj4NCj4gPj4+IFsyXSAtTWFqb3It IFRoZSBvcGVyYXRpb25zIHRvIHJldHJpZXZlIGNoYW5nZWQgbWVtYmVycyBvZiBhIGNvbGxlY3Rp b24NCj4gPj4+IGFyZSBub3QgYXRvbWljIHdydCB0aGUgb3BlcmF0aW9uIHRoYXQgb2J0YWlucyBh IHJlcG9ydCBvbiB3aGF0IGhhcw0KPiA+Pj4gY2hhbmdlZDsgY29sbGVjdGlvbiBjaGFuZ2VzIGNh biBvY2N1ciBiZXR3ZWVuIHJldHJpZXZpbmcgdGhlIHJlcG9ydCBhbmQNCj4gPj4+IHJldHJpZXZp bmcgdGhlIGNoYW5nZWQgZWxlbWVudHMgb3Igd2hpbGUgcmV0cmlldmluZyB0aGUgY2hhbmdlZCBl bGVtZW50cy4NCj4gPj4+IEZvciB0aGlzIHJlYXNvbiwgc2ltcGx5IG9idGFpbmluZyBhIGNoYW5n ZSByZXBvcnQgYW5kIHRoZW4gcmV0cmlldmluZyB0aGUNCj4gPj4+IGVsZW1lbnRzIHRoYXQgaGF2 ZSBjaGFuZ2VkIGFjY29yZGluZyB0byB0aGUgcmVwb3J0IG1heSBub3QgcmVzdWx0IGluIGENCj4g Pj4+IGNvbnNpc3RlbnQgKGUuZy4sIGFzIG9mIGEgcG9pbnQgaW4gdGltZSkgY29weSBvZiBhIGNv bGxlY3Rpb24uICBJIGJlbGlldmUNCj4gPj4+IHRoYXQgdGhpcyBhYnNlbmNlIG9mIGF0b21pY2l0 eSBpcyBhIFdlYkRBViAiZmVhdHVyZSIsIGFzIG9wcG9zZWQgdG8gYQ0KPiA+Pj4gImJ1ZyIsIGJ1 dCBJIGJlbGlldmUgdGhhdCB0aGlzIGJlaGF2aW9yIGFuZCB3aGF0IHRvIGRvIGFib3V0IGl0IHNo b3VsZCBiZQ0KPiA+Pj4gZGlzY3Vzc2VkIGluIHRoZSBkcmFmdC4gIEkgc3VnZ2VzdCB0aGUgZm9s bG93aW5nLCBwb3NzaWJseSB0byB0aGUgZW5kIG9mDQo+ID4+PiBzZWN0aW9uIDMuMQ0KPiA+Pj4N Cj4gPj4+IGkpIEFkZCBhIHNlbnRlbmNlIG9yIHR3byB0byB3YXJuIHRoYXQgb2J0YWluaW5nIGEg Y2hhbmdlIHJlcG9ydCBhbmQgdGhlbg0KPiA+Pj4gcmV0cmlldmluZyB0aGUgY2hhbmdlZCBlbGVt ZW50cyBtYXkgbm90IHJlc3VsdCBpbiBhIGNvbnNpc3RlbnQgbG9jYWwNCj4gPj4+IHZlcnNpb24g b2YgdGhlIGNvbGxlY3Rpb24gaWYgbm90aGluZyBlbHNlIGlzIGRvbmUgYmVjYXVzZSBjaGFuZ2Vz IG1heQ0KPiA+Pj4gaGF2ZSBvY2N1cnJlZCBpbiB0aGUgaW50ZXJpbS4NCj4gPj4+DQo+ID4+PiBp aSBBZGQgYSBkaXNjdXNzaW9uIG9mIGhvdyB0byBlbnN1cmUgdGhhdCBhIGxvY2FsIGNvcHkgb2Yg dGhlIGNvbGxlY3Rpb24NCj4gPj4+IGlzIGNvbnNpc3RlbnQuIFRoZSBiYXNpYyBpZGVhIGlzIHRv IHJlLXByZXNlbnRlZCB0aGUgc3luYyB0b2tlbiBmb3IgdGhhdA0KPiA+Pj4gY29weSB0byB0aGUg c2VydmVyIGFmdGVyIHRoZSBjaGFuZ2VkIGVsZW1lbnRzIGhhdmUgYmVlbiByZXRyaWV2ZWQ7IHRo ZQ0KPiA+Pj4gbG9jYWwgY29weSBpcyBjb25zaXN0ZW50IGlmIHRoZSBzZXJ2ZXIgcmVwb3J0cyB0 aGF0IHRoZXJlIGhhdmUgYmVlbiBubw0KPiA+Pj4gY2hhbmdlcy4gIFNvbWUgcHNldWRvLWNvZGUg bWF5IGhlbHAsIGUuZy46DQo+ID4+Pg0KPiA+Pj4gCUdldFN5bmNDb2xsZWN0aW9uUmVwb3J0KGlu IHRva2VuLCBvdXQgbmV3dG9rZW4sIG91dCByZXBvcnQpOw0KPiA+Pj4gCXdoaWxlIChSZXBvcnRI YXNDaGFuZ2VkSXRlbXMocmVwb3J0KSB7DQo+ID4+PiAJCUdldENoYW5nZWRJdGVtcyhyZXBvcnQp DQo+ID4+PiAJCXRva2VuID0gbmV3dG9rZW47DQo+ID4+PiAJCUdldFN5bmNDb2xsZWN0aW9uUmVw b3J0KGluIHRva2VuLCBvdXQgbmV3dG9rZW4sIG91dCByZXBvcnQpOw0KPiA+Pj4gCX0NCj4gPj4+ DQo+ID4+PiBBY3R1YWwgY29kZSBzaG91bGQgaW5jbHVkZSBhIGNvdW50ZXIgdGhhdCBjb3VudHMg dGhlIG51bWJlciBvZiBpdGVyYXRpb25zDQo+ID4+PiBvZiB0aGUgd2hpbGUgbG9vcCBhbmQgZXhp dHMgd2l0aCBhbiBlcnJvciBpZiB0aGUgbnVtYmVyIG9mIGl0ZXJhdGlvbnMNCj4gPj4+IGV4Y2Vl ZHMgc29tZSBsaW1pdDsgdGhhdCBlcnJvciBleGl0IGltcGxpZXMgdGhhdCB0aGUgY29sbGVjdGlv biBpcw0KPiA+Pj4gKGN1cnJlbnRseSkgY2hhbmdpbmcgdG9vIHJhcGlkbHkgdG8gb2J0YWluIGEg Y29uc2lzdGVudCBsb2NhbCB2ZXJzaW9uLg0KPiA+Pg0KPiA+PiBHb29kIHBvaW50LiBJIGFncmVl IHRoYXQgdGhpcyBkZXNlcnZlcyBzb21lIGFkZGl0aW9uYWwgdGV4dCB0byBjbGFyaWZ5IHRoaXMN Cj4gPj4gc2l0dWF0aW9uLiBIb3dldmVyLCBJIHdvdWxkIHJhdGhlciBub3QgZ28gaW50byB0b28g bXVjaCBkZXRhaWwgb2YgaG93DQo+ID4+IGNsaWVudHMgInJlLXN5bmMiIGluIGNhc2VzIGxpa2Ug dGhpcyBhcyB0aGVyZSBhcmUgYSBidW5jaCBvZiBkaWZmZXJlbnQgd2F5cw0KPiA+PiB0aGF0IGNv dWxkIGhhcHBlbiBlYWNoIG9mIHdoaWNoIGRlcGVuZHMgb24gZXhhY3RseSB3aGF0IHRoZSBjbGll bnQgaXMNCj4gPj4gdHJ5aW5nIHRvIGRvIChlLmcuLCBpbiBhIGxvdCBvZiBjYXNlcyBjbGllbnRz IHdpbGwgYmUgZG9pbmcgdHdvLXdheSBzeW5jcw0KPiA+PiBzbyB3aWxsIG5lZWQgdG8gcmVjb25j aWxlIHNlcnZlciBhbmQgbG9jYWwgY2hhbmdlcyB3aXRoaW4gdGhlIGxvb3AgeW91DQo+ID4+IHBy b3Bvc2UgYWJvdmUgLSB0aGUgZGV0YWlscyBvZiB0aGF0IGFyZSBub3QgaW4gc2NvcGUgZm9yIHRo aXMNCj4gPj4gc3BlY2lmaWNhdGlvbikuIFdoYXQgSSBwcm9wb3NlIGlzIHRoZSBhZGRpdGlvbiBv ZiB0aGUgZm9sbG93aW5nIHBhcmFncmFwaA0KPiA+PiB0byB0aGUgZW5kIG9mIFNlY3Rpb24gMy4x Og0KPiA+Pg0KPiA+PiAgICAgVHlwaWNhbGx5LCBhIGNsaWVudCB3aWxsIHVzZSB0aGUgc3luY2hy b25pemF0aW9uIHJlcG9ydCB0byByZXRyaWV2ZSB0aGUNCj4gPj4gICAgIGxpc3Qgb2YgY2hhbmdl cywgYW5kIHdpbGwgZm9sbG93IHRoYXQgd2l0aCByZXF1ZXN0cyB0byByZXRyaWV2ZSB0aGUNCj4g Pj4gICAgIGNvbnRlbnQgb2YgY2hhbmdlZCByZXNvdXJjZXMuIEl0IGlzIHBvc3NpYmxlIHRoYXQg YWRkaXRpb25hbCBjaGFuZ2VzIHRvDQo+ID4+ICAgICB0aGUgY29sbGVjdGlvbiBjb3VsZCBvY2N1 ciBiZXR3ZWVuIHRoZSB0aW1lIG9mIHRoZSBzeW5jaHJvbml6YXRpb24NCj4gPj4gICAgIHJlcG9y dCBhbmQgcmVzb3VyY2UgY29udGVudCByZXRyaWV2YWwsIHdoaWNoIGNvdWxkIHJlc3VsdCBpbiBh bg0KPiA+PiAgICAgaW5jb25zaXN0ZW50IHZpZXcgb2YgdGhlIGNvbGxlY3Rpb24uIFdoZW4gY2xp ZW50cyB1c2UgdGhpcyBtZXRob2Qgb2YNCj4gPj4gICAgIHN5bmNocm9uaXphdGlvbiwgdGhleSBu ZWVkIHRvIGJlIGF3YXJlIHRoYXQgc3VjaCBhZGRpdGlvbmFsIGNoYW5nZXMNCj4gPj4gICAgIGNv dWxkIG9jY3VyLCBhbmQgdHJhY2sgdGhlbSB0aHJvdWdoIG5vcm1hbCBtZWFucyAoZS5nLiwgZGlm ZmVyZW5jZXMNCj4gPj4gICAgIGJldHdlZW4gdGhlIEVUYWcgdmFsdWVzIHJldHVybmVkIGluIHRo ZSBzeW5jaHJvbml6YXRpb24gcmVwb3J0IGFuZA0KPiA+PiAgICAgdGhvc2UgcmV0dXJuZWQgd2hl biBhY3R1YWxseSBmZXRjaGluZyByZXNvdXJjZSBjb250ZW50KSwgY29uZGl0aW9uYWwNCj4gPj4g ICAgIHJlcXVlc3RzIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUsIG9yIHJlcGVhdGluZyB0aGUg c3luY2hyb25pemF0aW9uDQo+ID4+ICAgICBwcm9jZXNzIHVudGlsIG5vIGNoYW5nZXMgYXJlIHJl dHVybmVkLg0KPiA+Pg0KPiA+Pj4gWzNdIC1NaW5vci0gaWRuaXRzIDIuMTIuMTIgIHJlcG9ydHMg YSBEb3ducmVmIHRvIFJGQyA1ODQyLiAgUGxlYXNlDQo+ID4+PiBjb25zdWx0IHlvdXIgQXJlYSBE aXJlY3RvciAoUGV0ZXIgU2FpbnQtQW5kcmUpIHRvIGRldGVybWluZSB3aGF0IHRvIGRvDQo+ID4+ PiBhYm91dCB0aGlzIERvd25yZWYgKGl0IHJlcXVpcmVzIGF0dGVudGlvbiwgYnV0IG1heSBub3Qg cmVxdWlyZSBjaGFuZ2VzIHRvDQo+ID4+PiB0aGUgZHJhZnQpLg0KPiA+Pg0KPiA+PiBXb3JraW5n IHdpdGggSUVTRyBvbiB0aGlzIG9uZS4NCj4gPj4NCj4gPj4+IE5pdDogSSBzdWdnZXN0IG5vdCB1 c2luZyB0aGUgYXV0aG9yJ3Mgb3duIG5hbWUgKGN5cnVzZGFib28pIGluIHRoZQ0KPiA+Pj4gZXhh bXBsZXMuICBTb21lb25lIG1heSBjb3B5IHRoZSBjb2RlIGZyb20gdGhlIHJlc3VsdGluZyBSRkMu DQo+ID4+DQo+ID4+IFRoaXMgaGFzIGJlZW4gY29tbW9uIHByYWN0aWNlIGluIG1vc3Qgb2YgdGhl IG90aGVyIENhbERBVi9DYXJkREFWIFJGQ3MgSQ0KPiA+PiBoYXZlIHdvcmtlZCBvbiBhbmQgaGFz IG5vdCBiZWVuIHRoZSBzb3VyY2Ugb2YgYW55IHByb2JsZW1zLCBzbyBJIHdvdWxkDQo+ID4+IHJh dGhlciBsZWF2ZSB0aGlzIHVuY2hhbmdlZC4gSWYgdGhlcmUgaXMgYW4gb2ZmaWNpYWwgSUVURiBw b2xpY3kgb24gdXNpbmcNCj4gPj4gInJlYWwgbmFtZXMiIGluIGV4YW1wbGVzLCB0aGVuIEkgd291 bGQgYmUgaGFwcHkgdG8gY2hhbmdlIHRvIGZvbGxvdyB0aGF0LA0KPiA+PiBidXQgSSBhbSBub3Qg YXdhcmUgb2YgYW55dGhpbmcgbGlrZSB0aGF0Lg0KPiA+Pg0KPiA+Pj4gTml0OiBpZG5pdHMgMi4x Mi4xMiByZXBvcnRzIHRoYXQgZHJhZnQtaWV0Zi12Y2FyZGRhdi1jYXJkZGF2IGhhcyBiZWVuDQo+ ID4+PiBwdWJsaXNoZWQgYXMgUkZDIDYzNTI7IHRoZSBSRkMgRWRpdG9yIHdpbGwgY29ycmVjdCB0 aGlzIGlmIGEgbmV3IHZlcnNpb24NCj4gPj4+IG9mIHRoZSBkcmFmdCBpcyBub3QgcmVxdWlyZWQg Zm9yIG90aGVyIHJlYXNvbnMuDQo+ID4+DQo+ID4+IEZpeGVkIGluIG15IHdvcmtpbmcgY29weS4N Cj4gPj4NCj4gPj4NCj4gPj4gLS0NCj4gPj4gQ3lydXMgRGFib28NCj4gPj4NCj4gPg0KPiANCg0K From david.black@emc.com Thu Jan 19 16:10:46 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E7E21F86F4; Thu, 19 Jan 2012 16:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.886 X-Spam-Level: X-Spam-Status: No, score=-108.886 tagged_above=-999 required=5 tests=[AWL=1.713, 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 L4CLdJHhqqSz; Thu, 19 Jan 2012 16:10:46 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id E166C21F86F2; Thu, 19 Jan 2012 16:10:45 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0K0AZDZ016597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jan 2012 19:10:36 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 19 Jan 2012 19:10:27 -0500 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.222.70.169]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0K0APxC012700; Thu, 19 Jan 2012 19:10:26 -0500 Received: from mx14a.corp.emc.com ([169.254.1.99]) by mxhub29.corp.emc.com ([128.222.70.169]) with mapi; Thu, 19 Jan 2012 19:10:25 -0500 From: To: , , , Date: Thu, 19 Jan 2012 19:10:24 -0500 Subject: Gen-ART review of draft-ietf-marf-redaction-05 Thread-Topic: Gen-ART review of draft-ietf-marf-redaction-05 Thread-Index: AczQCujbMXhqirD5Sk6EB1sS2KVtOQG/Hm+w Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7CF1028@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A7B80D63@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Fri, 20 Jan 2012 14:36:57 -0800 Cc: presnick@qualcomm.com, david.black@emc.com, marf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 00:10:46 -0000 Based on discussion with the authors, the -05 version of this draft resolve= s the issues raised in the Gen-ART review of the -04 version. An important eleme= nt of the approach taken to issue [1] has been to explain why the security requir= ements for redaction are significantly weaker than the strength of the secure hash= es that are suggested by the draft. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Tuesday, January 10, 2012 9:44 PM > To: ietf@cybernothing.org; Murray S. Kucherawy; gen-art@ietf.org; ietf@ie= tf.org > Cc: Black, David; marf@ietf.org; presnick@qualcomm.com > Subject: Gen-ART review of draft-ietf-marf-redaction-04 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on Gen-= ART, please > see the FAQ at . >=20 > Please resolve these comments along with any other Last Call comments you= may receive. >=20 > Document: draft-ietf-marf-redaction-04 > Reviewer: David L. Black > Review Date: January 10, 2012 > IETF LC End Date: January 18, 2011 > IESG Telechat Date: January 19, 2011 >=20 > Summary: This draft is on the right track but has open issues, described = in the review. >=20 > This draft specifies a method for redacting information from email abuse = reports > (e.g., hiding the local part [user] of an email address), while still all= owing > correlation of the redacted information across related abuse reports from= the same > source. The draft is short, clear, and well written. >=20 > There are two open issues: >=20 > [1] The first open issue is the absence of security guidance to ensure th= at this > redaction technique effectively hides the redacted information. The reda= ction > technique is to concatenate a secret string (called the "redaction key") = to the > information to be redacted, apply "any hashing/digest algorithm", convert= the output > to base64 and use that base64 string to replace the redacted information. >=20 > There are two important ways in which this technique could fail to effect= ively hide > the redacted information: > - The secret string may inject insufficient entropy. > - The hashing/digest algorithm may be weak. >=20 > To take an extreme example, if the secret string ("redaction key") consis= ts of a > single ASCII character, and a short email local part is being redacted, t= hen the > output is highly vulnerable to dictionary and brute force attacks because= only 6 bits > of entropy are added (the result may look secure, but it's not). Beyond = this extreme > example, this is a potentially real concern - e.g., applying the rule of = thumb that > ASCII text contains 4-5 bits of entropy per character, the example in App= endix A > uses a "redaction key" of "potatoes" that injects at most 40 bits of entr= opy - > is that sufficient for email redaction purposes? >=20 > To take a silly example, if a CRC is used as the hash with that sort of s= hort input, > the result is not particularly difficult to invert. >=20 > I suggest a couple of changes: > 1) Change "any hashing/digest algorithm" to require use of a secure hash,= and > explain what is meant by "secure hash" in the security considerations se= ction. > 2) Require a minimum length of the "redaction key" string, and strongly s= uggest > (SHOULD) that it be randomly generated (e.g., by running sufficient outp= ut > of an entropy-rich random number generator through a base64 converter). >=20 > For the latter change, figure out the amount of entropy that should be us= ed > for redaction - the recommended string length will be larger because prin= table > ASCII is not entropy-dense (at best it's good for 6 bits of entropy in ea= ch > 8-bit character, and human-written text such as this message has signific= antly > less). >=20 > From a pure security perspective, use of HMAC with specified secure hashe= s > (SHA2-family) and an approach of hashing the "redaction key" down to a bi= nary > key for HMAC would be a stronger approach. I suggest that authors conside= r > approach, but there may be practical usage concerns that suggest not ado= pting it. >=20 > [2] The second open issue is absence of security considerations for the r= edaction > key. The security considerations section needs to caution that the redac= tion key > is a secret key that must be managed and protected as a secret key. Disc= losure > of a redaction key removes the redaction from all reports that used that = key. > As part of this, guidance should be provided on when and how to change th= e > redaction key in order to limit the effects of loss of secrecy for a sing= le > redaction key. >=20 > Editorial Nit: I believe that "anonymization" is a better description of = what > this draft is doing (as opposed to "redaction"), particularly as the resu= lt is > intended to be correlatable via string match across reports from the same= source. >=20 > idnits 2.12.13 didn't find any nits. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From zordogh@rim.com Thu Jan 19 14:10:33 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1927321F86B1; Thu, 19 Jan 2012 14:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.887 X-Spam-Level: X-Spam-Status: No, score=-4.887 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 EliqQplfk4zW; Thu, 19 Jan 2012 14:10:31 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7227921F86DC; Thu, 19 Jan 2012 14:10:30 -0800 (PST) X-AuditID: 0a41282f-b7f9d6d000002fe5-57-4f1894cd07d8 Received: from XHT105CNC.rim.net (xht105cnc.rim.net [10.65.12.216]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 56.41.12261.DC4981F4; Thu, 19 Jan 2012 22:10:21 +0000 (GMT) Received: from XCT107CNC.rim.net (10.65.161.207) by XHT105CNC.rim.net (10.65.12.216) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 19 Jan 2012 17:10:21 -0500 Received: from XMB107ACNC.rim.net ([fe80::f1d2:c1d5:f469:3f83]) by XCT107CNC.rim.net ([fe80::b815:71ef:9f8f:e07c%16]) with mapi id 14.01.0339.001; Thu, 19 Jan 2012 17:10:20 -0500 From: Zoltan Ordogh To: John C Klensin , Alessandro Vesely Subject: FW: [apps-discuss] Spam reporting over IMAP Thread-Topic: [apps-discuss] Spam reporting over IMAP Thread-Index: AczO/5w0zIm+SpJ7RGmLza1UzvIy+ADJcaFQADFelgAACKZQAAC4je8QAD4ANWA= Date: Thu, 19 Jan 2012 22:10:19 +0000 Message-ID: <1DE983233DBBEB4A81F18FABD8208D76226DA413@XMB107ACNC.rim.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.251] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsXC5chzQ/fsFAl/gy03ZCxWv1zBZvFs43wW i9ZLf9gsJt79yeLA4rFkyU8mj8srXzN7nNjFG8Ac1cBok5iXl1+SWJKqkJJanGyr5JOanpij EFCUWZaYXKngklmcnJOYmZtapKSQmWKrZKKkUJCTmJyam5pXYquUWFCQmpeiZMelgAFsgMoy 8xRS85LzUzLz0m2VPIP9dS0sTC11DZXsdJFAwj/ujIP/epgLPidUTFvxhbGB8aBvFyMnh4SA icTJi4+YIWwxiQv31rN1MXJxCAn0MknsOXKaFcJZzihx7uRxRghnG6NE17Y77F2MHBxsAqoS c67GgnSLCHhJTLt7lQ3EZhbwlFh3/yITiC0MtGH+nSfsEDWmEktnXoCy/STWzDsOZrMAjdm0 /jkriM0L1Lv+5j0WEJtRQFZi99nrTBAzxSVuPZnPBHGpgMSSPeehrhaVePn4HyuErSjxpHEz C0S9nsSNqVOg7tGWWLbwNTPEfEGJkzOfgNUICchIPJ9yiX0Co9gsJCtmIWmfhaR9FpL2BYws qxgFczOKDcwMkvOS9Yoyc/XyUks2MYKTiIb+Dsa+vVqHGAU4GJV4eEP7JfyFWBPLiitzDzFK cDArifA29AGFeFMSK6tSi/Lji0pzUosPMVoAQ2IisxR3cj4wweWVxBsbGKBwlMR5NdXv+QkJ pANTUnZqakFqEUwrEwenVAPjhQfsn9P+zWa7NS0s6/SziA+a9YVueyfJC2UXcL+1Fl0RoXpq nS1Xs8OTSd/zZhXOY3Y4VL16cuXX0t0vPrE/FJ1sdmBm7/vDQiZf3t/nrJip5fX6qvO87vkd jzIyjSc8W1owfWNucAoTt7Uzk3fDjy8H9R+VfBBYzeektlqkZjvTXr0plaY8SizFGYmGWsxF xYkAW7VcJTsDAAA= X-Mailman-Approved-At: Fri, 20 Jan 2012 14:38:03 -0800 Cc: ietf , "apps-discuss@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 22:10:33 -0000 Hi all, I would like to address the issues that involve SM, Alessandro and John firs= t. I understand the confusion has risen because my name is listed as an author= on draft-ordogh-spam-reporting-using-imap-kleansed-00. I would like to make it clear that while draft-ordogh-spam-reporting-using-i= map-kleansed-00 bears my name and I am listed as the author of this, I was n= ot involved - nor consulted - on its development. I am of course happy to wo= rk with anyone who wishes to progress either draft as long as the work gets= done in IETF. As I said before, if there is no interest to keep the work in= IETF, while not desirable, it is perfectly fine; the work will happen in OM= A EVVM. I noticed that a declaration has been made on draft-ordogh-spam-reporting-us= ing-imap-kleansed-00. This simple fact should answer SM's question. Alessandro said he emailed Sarah and got no response. I asked Sarah and she= told me she have not received any emails from Alessandro. The only thing I= can add here is that RIM has very strict spam filters in place. The sender= or the recipient will not know what happened to an email. If you do not get= a response within a reasonable timeframe, please email the person again (wi= th a different subject and body, to ensure that there's absolutely nothing i= n the mail that might trigger a spam filter). BTW, since I am bound by RIM's= policies as Sarah, this holds true for my emails as well. Speaking of IT policies. Regarding John's concern about the disclaimer in the email message. It is an= IT policy in RIM, there is nothing I can do about it as it is beyond my con= trol. Since the emails are sent to a public mailing list, all information in= the email can be considered public - in which case I believe that disclaime= r does not apply. If I accidently put some information into that email that= was not meant to be public, I will have to follow up on it and you will kno= w. Next, I try to do my best to address John's other comments below (2 through= 4). > -----Original Message----- > From: John C Klensin [mailto:john-ietf@jck.com] > Sent: January 14, 2012 12:40 PM > To: Alessandro Vesely; Zoltan Ordogh > Cc: ietf; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Spam reporting over IMAP > > > > --On Saturday, January 14, 2012 14:32 +0100 Alessandro Vesely wrote: > > >... > >> A bit later, a liaison statement was sent from OMA to IETF, seeking > >> collaboration and a "home" for the draft; as required by RFC3975. > > > > I assume you're still talking about SREP. I read a reply by John > > Klensin, whom I consider a sort of IETF guru, and it didn't prospect > > a bright future for the draft. I posted a "kleansed" version trying > > to address some of those concerns, in an attempt to improve the > > chances that APPSAWG will adopt it. Somewhat arbitrarily, I changed > > the IPR qualification of the document too. In fact, I had the > > impression that the IPR was that way because OMA SpamRep was being > > mentioned, albeit not being specified, and also because that was one > > of the points raised. > > > I hope my editing was correct, but your approval as author is needed. > >... > > Alessandro, Zoltan, > > Guru or not (some would certainly dispute that), this is strictly a > personal comment and personal opinion. Just to clarify my view of this (o= ther may have different opinions)... > > (1) I think SM's question, and anything else having to do with the IRP > status of this document (or pair of documents) has to be > completely clear. The IETF could certainly decide to process > the document even if the technology were encumbered (has happened many > times before), but uncertainty is pretty much a showstopper. > Alessandro's concerns about distribution disclaimers on email messages tha= t discuss the topic only reinforce my concern in this area. > [Z=D6r] I addressed this above. > (2) Similarly, both of you, and RIM and OMA, need to understand that > handing something like this off to IETF, especially for > standards-track processing, is a handoff of change control. The IETF > can modify (we hope improve) things as it likes, even after approval > of the first version of the document as a Proposed Standard. Joint owners= hip/ change control arrangements are possible, but they are very hard and ti= me-consuming to negotiate and perhaps, due to some bad experience, likely to= get harder. > [Z=D6r] I think I understand your concern. The draft contains one possible s= olution - one that fulfills the requirements set and was 'good enough' for O= MA. It is not a draft from OMA. It is an individual contribution; OMA merely= endorses it because it fulfills the requirement they need. I am fairly conf= ident that if IETF can find a more efficient solution than the one in my dra= ft, one that fulfills the requirement OMA needs, then OMA will be more than= happy to discard my draft - even as a whole if need be - and go with the mo= re efficient solution instead. The only concern I would expect OMA to raise= in this case is the schedule (the availability of a fairly stable draft). I= said already that I am happy to work with either document. I can also say t= hat while I would not be particularly happy about discarding my draft consid= ering the amount of time I invested in writing it and doing the legwork in O= MA, I would not make a big deal out of discarding it in favor of a more effi= cient solution that achieves the objectives set. These statements, as a whole, should re-assure that it is not a simple hando= ff of change control. Rather, an initial draft (including its imperfections)= to kick off the work in IETF - a work entirely owned by IETF, as laid out i= n RFC3975. It is unfortunate that there was no response to the liaison state= ment sent from OMA to IETF; these things could have been clarified long ago. > (3) The leadership of AppAWG, and the ADs, will do as they think > appropriate, but, if I were making the rules, no one would spend > energy trying to sort out the differences between a pair of competing > documents. I suggest that the two of you get together, offlist, and > see if you can reach clear agreement on a single draft that supercedes > both documents. That is a matter of courtesy to those of us you are askin= g to consider the work and is quite independent of the IPR concerns (althoug= h they do interact). [Z=D6r] I am not asking anyone to discuss the merits of either draft; in fac= t, I left out all technical discussions - on purpose. What I would like to f= igure whether IETF is interested on working on this topic - which is the sam= e thing that was asked in the liaison statement. I mean, I can work offline= with Alessandro and come up with a nice, consolidated draft - but that woul= d not solve anything because in the end, we would have to ask the same quest= ions afterwards; a draft supported by only two participants won't make it in= to a standards-track RFC. Ergo, more support to work on this topic (not a sp= ecific draft) would be needed. And, this is exactly what I am trying to figu= re out. > > All three of those issues are administrative, not technical. > They should be easily solved. My personal preferences is that the > AppsAWG, and the apps-discuss list, spend no more time on this until/unles= s they are resolved. YMMD, of course. [Z=D6r] From my perspective, these administrative issues have been addressed= . > > (4) The core of my previous comments was a technical concern, not an > administrative one. [Z=D6r] Again, I would like to leave technical discussions out, for now at l= east, especially because the draft in question may change substantially (may= be even thrown out) once the work starts. > Even if one ignores the security concerns, the > stability issues for normative references, and so on, many of us believe t= hat the IMAP protocol has become far too complicated, with too many options= and features. > That complexity increases the requirements on IMAP servers that wish > to support a wide range of clients and applications and on clients that wi= sh to support a reasonable range of features but > work with servers that may not support all of them. Whatever > the advantages, too much code and too many code paths are not > conducive to very high quality, bug- free, implementations. > [Z=D6r] That is my understanding as well. After Lemonade concluded its work,= there were rumors about IMAP5 - which, I understand, would have removed the= unused things from the specifications, consolidated must-haves into the bas= e spec, and tidied up the loose ends a bit. Unfortunately it did not happen,= so we have to work with what we have - and however undesirable the situatio= n is. Sooner or later, IETF will have to face this problem and deal with thi= s issue, irrespective of any newly proposed extensions. If you ask me, the s= ooner it happens, the better. The problem has been identified already, which= is always a good sign because it indicates that people know exactly what ne= eds to be done. The only thing I am unsure of is: "What's keeping IETF from= taking an action?". Standards evolve and soon, it will have been 10 years s= ince IMAP4 was released. But, I believe that this discussion is more or less= irrelevant to the original topic in question; this is not why I am knocking= on the IETF door. OMA has decided to use IMAP4 already. > This proposal seems to me to take IMAP into a whole new area. > I'm not questions whether or not that is possible because I'd be > certain it would be, even without the assertiosn that there are > implementations out there. I am questioning whether there is a strong > enough case to be made that this belongs in IMAP to justify further > clutter in the protocol and even lower odds of seeing high-quality > clients. I observe that probably the best general-purpose --as > distinct from, e.g., specialized for mobile > devices-- IMAP client out there is now quite old, largely > unmaintained, and has not picked up on any of the new features > added in the last several years. Neither version of the > document really addresses that issue. Some of the comments from the > two of you about why it is hard and/or expensive to do it in other > ways certainly have merit, but need, IMO, to be balanced off against other= considerations including the above. > That balance won't be easy to find especially since, as I am sure you > both know, there is no community agreement about the degree to which > it is appropriate to make normal, desired, email work worse in order > to provide better facilities for spam-handling, especially spam-handling a= t or after the final delivery MTA. [Z=D6r] I cannot possibly comment on what gets picked up, what does not get= picked up (or why) in individual client or server implementations, or, in v= arious services. All I can say is that there is a hole, OMA is trying to fil= l it in and one possible solution has been created - and now I am trying to= find out whether there's interest in working on this topic. > > Bottom line: I think we should see a single draft that really > addresses all of the technical issues, including the design tradeoffs > and security topics, _and_ addresses the IPR/administrative one in a way w= ith which we can all be comfortable before being asked to decide whether App= sAWG should > take this up. If asked to make a decision without such a draft > having been posted, I would vote "no". > > john [Z=D6r] There is nothing I can add here that I have not said already. I have= received a good deal of comments offline. I plan on addressing those, uploa= ding a revision, checking in with Alessandro and addressing the rest of the= comments later either as a new draft of an update. Comments, new draft, comments, new drafts. Isn't it already a "work being do= ne" in IETF driven by interest of individuals? Feels like normal IETF proced= ure to me. Just a thought. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From bob.hinden@gmail.com Fri Jan 20 15:20:46 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EB321F860F for ; Fri, 20 Jan 2012 15:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, 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 9zg+zBAajyN0 for ; Fri, 20 Jan 2012 15:20:45 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 902C721F85F3 for ; Fri, 20 Jan 2012 15:20:45 -0800 (PST) Received: by iaae16 with SMTP id e16so1798508iaa.31 for ; Fri, 20 Jan 2012 15:20:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=NdTnhATbHpYGfQJc8wrkMzZzIdUqntPEfxuTx+YrsHc=; b=xJlWG/xJ5aR/i93MS40CVe9JaFetl415iG7sB/VzkM44uUL7YfaPG194pay7N6h4rO tjuvPCOIjRRek14q4CfkRtYWZafndFOL6wPZ7F7Qh8MCS8PuGn3tsds60XSgjMwY9+Km e6ymnb+sZmYU2xofpjnJNIxzIFqrfsrVn8Wx0= Received: by 10.50.77.226 with SMTP id v2mr506704igw.12.1327101645217; Fri, 20 Jan 2012 15:20:45 -0800 (PST) Received: from [10.0.0.27] (c-69-181-250-158.hsd1.ca.comcast.net. [69.181.250.158]) by mx.google.com with ESMTPS id or1sm7246314igc.3.2012.01.20.15.20.43 (version=SSLv3 cipher=OTHER); Fri, 20 Jan 2012 15:20:44 -0800 (PST) Subject: Re: ITC copped out on UTC again Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4F19BFF4.7000102@gmail.com> Date: Fri, 20 Jan 2012 15:20:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <63214274-98D4-423E-8E66-136E0285C23B@gmail.com> References: <4F19BFF4.7000102@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: Phillip Hallam-Baker , Bob Hinden , IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 23:20:46 -0000 Brian, On Jan 20, 2012, at 11:26 AM, Brian E Carpenter wrote: > On 2012-01-21 03:20, Phillip Hallam-Baker wrote: >> If we are ever going to get a handle on Internet time we need to get = rid of >> the arbitrary correction factors introduced by leap seconds. >=20 > Time is and always will be an arbitrary measurement scheme, and the = only > thing that makes sense for the Internet is to use the same arbitrary = scheme > as everybody else. We just have to suck up the resulting = inconveniences, > as GPS has to. It would be unthinkable to go it alone. +1 >=20 > Alternatively we could revert to the Julian (365.25 day) calendar, = which > was considerably more convenient for programmers, or perhaps to one of = the > old Iranian (360 day) calendars, which are convenient in some ways but = do > require occasional leap months. Or a lunar calendar. Some years, it would be nice to have an extra = month :-) Bob From presnick@qualcomm.com Fri Jan 20 17:47:34 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B370B11E8072 for ; Fri, 20 Jan 2012 17:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.528 X-Spam-Level: X-Spam-Status: No, score=-106.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 icpwJDFMI8pS for ; Fri, 20 Jan 2012 17:47:34 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 1442A11E8071 for ; Fri, 20 Jan 2012 17:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327110454; x=1358646454; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F1A188B.4010404@qualcomm.com>|Date:=20Fr i,=2020=20Jan=202012=2019:44:43=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Bob=20Hinden=20|CC:=20Brian=20E=20Carpenter=20,=20Phillip=20Hallam-Baker=0D=0A=09,=20IETF=20Discussion=20Mailing=20List=20|Subject:=20Re:=20ITC=20copped=20out=20on=20UTC=20ag ain|References:=20=09<4F19BFF4.7000102@gma il.com>=20<63214274-98D4-423E-8E66-136E0285C23B@gmail.com >|In-Reply-To:=20<63214274-98D4-423E-8E66-136E0285C23B@gm ail.com>|Content-Type:=20text/plain=3B=20charset=3D"ISO-8 859-1"=3B=20format=3Dflowed|Content-Transfer-Encoding:=20 7bit|X-Originating-IP:=20[172.30.48.1]; bh=mj5Is1eEe/LfFcwUyrKZYh1voPxJp7BOo+1mhxF79Qg=; b=VZEwioUB9VAkx/8iksMftIemmcLZO03jkvz7t+cCGATunLjf0o0RmKJx o4br9PcrMcVkT2LoLK8KZxe1FyePwtBmSa2wv75XE9R+CcL7pBjmWAkP/ 9F5y3H5xAW3Hk0NG5kdH928wPzBCAO/wmZSRcmR+rTEGCjnvL5QKvs3C8 w=; X-IronPort-AV: E=McAfee;i="5400,1158,6595"; a="156836642" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine01.qualcomm.com with ESMTP; 20 Jan 2012 17:47:33 -0800 X-IronPort-AV: E=Sophos;i="4.71,542,1320652800"; d="scan'208";a="157123444" Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 20 Jan 2012 17:47:33 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 20 Jan 2012 17:44:46 -0800 Message-ID: <4F1A188B.4010404@qualcomm.com> Date: Fri, 20 Jan 2012 19:44:43 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Bob Hinden Subject: Re: ITC copped out on UTC again References: <4F19BFF4.7000102@gmail.com> <63214274-98D4-423E-8E66-136E0285C23B@gmail.com> In-Reply-To: <63214274-98D4-423E-8E66-136E0285C23B@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: Phillip Hallam-Baker , IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 01:47:34 -0000 On 1/20/12 5:20 PM, Bob Hinden wrote: >> Alternatively we could revert to the Julian (365.25 day) calendar, which >> was considerably more convenient for programmers, or perhaps to one of the >> old Iranian (360 day) calendars, which are convenient in some ways but do >> require occasional leap months. >> > Or a lunar calendar. Some years, it would be nice to have an extra month:-) > I hear there are some nice folks at Johns Hopkins with a plan. :-) http://henry.pha.jhu.edu/calendar.html pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From daedulus@btconnect.com Sat Jan 21 11:53:33 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB2221F84D0 for ; Sat, 21 Jan 2012 11:53:33 -0800 (PST) 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 avUQBirqTQ8u for ; Sat, 21 Jan 2012 11:53:32 -0800 (PST) Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id DDEB321F84C4 for ; Sat, 21 Jan 2012 11:53:31 -0800 (PST) Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2bthomr09.btconnect.com with SMTP id GAF62109; Sat, 21 Jan 2012 19:53:27 +0000 (GMT) Message-ID: <003e01ccd86e$0bc89a40$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Alessandro Vesely" References: <4F19824E.9020101@tana.it> Subject: Re: Please remove draft-ordogh-spam-reporting-using-imap-kleansed fromI-D repository Date: Sat, 21 Jan 2012 19:53:59 +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-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0302.4F1B17B6.0081, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.21.185116:17:7.586, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, __PHISH_PHRASE5, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_1800_1899, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020C.4F1B17B7.0093,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: ietf X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 19:53:33 -0000 Alessandro You could, of course, issue an updated version which simply says that its predecessor should not have been filed for the reasons you give in the e-mail. No need to include any other text whatsoever (except, of course, the relevant boiler plate). That seems simpler to me than asking the system to do something rather unusual that it may not have a mechanism to do. In future, there could always be another version moving the process forward in the appropriate direction. Tom Petch ----- Original Message ----- From: "Alessandro Vesely" To: Cc: "Zoltan Ordogh" ; "apps discuss" ; "ietf" Sent: Friday, January 20, 2012 4:03 PM Subject: Please remove draft-ordogh-spam-reporting-using-imap-kleansed fromI-D repository > Dear IETF Secretariat, > > I hereby ask that draft-ordogh-spam-reporting-using-imap-kleansed be > removed from the I-D repository. I submitted it on 10 Jan 2012, in a > clumsy attempt to speed up a discussion about a similarly named I-D, > draft-ordogh-spam-reporting-using-imap. The editing I carried out was > based on previous writing about, both privately and on IETF lists. > However, I hadn't obtained the author's permission to alter the > boilerplate-type of the original document. Thus, the document I > posted bears "wrong" copyright information. In particular, unwitting > editors may derive their own work from this document if they just > abide by its boilerplate text, while the original post did not imply a > handoff of change control. > > I apologize for any inconveniences that my action might have caused. > > Regards > Alessandro Vesely > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > > From Henning.Schulzrinne@fcc.gov Sun Jan 22 08:10:22 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE92321F8484 for ; Sun, 22 Jan 2012 08:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 XrJnoXlViQFK for ; Sun, 22 Jan 2012 08:10:22 -0800 (PST) Received: from dmz-mail4.fcc.gov (dmz-mail4.fcc.gov [65.207.43.156]) by ietfa.amsl.com (Postfix) with ESMTP id 34FA921F84C9 for ; Sun, 22 Jan 2012 08:10:21 -0800 (PST) Received: from P2PXCAS02.fccnet.win.fcc.gov (2002:a587:f018::a587:f018) by GBPXCAS02V.fccnet.win.fcc.gov (2002:a587:6689::a587:6689) with Microsoft SMTP Server (TLS) id 14.1.218.12; Sun, 22 Jan 2012 11:08:46 -0500 Received: from P2PXMB13.fccnet.win.fcc.gov ([fe80::6593:6526:65f8:66b7]) by p2pxcas02.fccnet.win.fcc.gov ([fe80::2d69:114:8552:212f%13]) with mapi id 14.01.0218.012; Sun, 22 Jan 2012 11:09:45 -0500 From: Henning Schulzrinne To: "ietf@ietf.org" Subject: Interested in giving a talk at the FCC? Thread-Topic: Interested in giving a talk at the FCC? Thread-Index: AczZIAWGv101/0KGSDGvyPot2XKt/Q== Date: Sun, 22 Jan 2012 16:09:43 +0000 Message-Id: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.64] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 16:11:40 -0000 If you=92re interested in giving a seminar to technical staff and/or econom= ists at the US Federal Communications Commission (FCC), please let me know.= The FCC won=92t be able to pay for travel, so we=92d likely schedule any t= alks when you are in the DC area. Also, if you know of any colleagues the C= ommission staff should hear from, feel free to suggest them. I won=92t make any promises that I=92ll be able to accommodate all or even = most offers, but this is an experiment to see if we can broaden the perspec= tives heard at the FCC. Most FCC staff are generalists, so topics should be= accessible and of interest to this community. (In general, the FCC deals w= ith many aspects of wired and wireless communications, and is interested in= applications, as well as lower layers. Examples of topics of particular in= terest are spectrum-related issues, increasing broadband availability, secu= rity/privacy, IPv6, PSTN-transition issues, public safety and accessibility= . Thus, if you=92re interested, please get in touch with me with a rough desc= ription of what you'd talk about. If there=92s local interest in your topic= , I will get back to you to work out details. There is no deadline as such,= so consider this a standing offer. Henning ------ Henning Schulzrinne CTO, FCC 7C252, (202) 418-1544 From lear@cisco.com Sun Jan 22 08:17:45 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33F421F8489 for ; Sun, 22 Jan 2012 08:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.526 X-Spam-Level: X-Spam-Status: No, score=-110.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 r8hzo3jYs-w9 for ; Sun, 22 Jan 2012 08:17:45 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2606A21F845F for ; Sun, 22 Jan 2012 08:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=545; q=dns/txt; s=iport; t=1327249063; x=1328458663; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=InhA3UAyr5FgbIUT+t3jr3mDmyNlTZke2D1SV0v7Akc=; b=YCgpiQwcEOMbf2h35NuYbQJBtbsCFwRVuFIGgJJ/Beo0ktWL6kpkYR2g tu4FISwMewckFzTzFHoriPPykjmNVpsf5e06S7FGPG9KW6ahw6Nawo0JK U/9160oLAITuvQXwj3XdzN9c36RdShmwoPbnff9JTomsSMzh9hEYO7ecW w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJw1HE+Q/khN/2dsb2JhbABDhQmpG4EFgXIBAQEEEgEQVQEQCw4KAgIFDAoLAgIJAwIBAgFFBg0BBwEBHqFBAYxjkHCBL4dPghKBFgSVGZJP X-IronPort-AV: E=Sophos;i="4.71,552,1320624000"; d="scan'208";a="64307200" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 22 Jan 2012 16:17:42 +0000 Received: from dhcp-10-55-88-113.cisco.com (dhcp-10-55-88-113.cisco.com [10.55.88.113]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q0MGHfAD029361; Sun, 22 Jan 2012 16:17:42 GMT Message-ID: <4F1C36A5.7000806@cisco.com> Date: Sun, 22 Jan 2012 17:17:41 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Michael Richardson Subject: Re: ITC copped out on UTC again References: <6010.1327083238@marajade.sandelman.ca> In-Reply-To: <6010.1327083238@marajade.sandelman.ca> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker , IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 16:17:45 -0000 On 1/20/12 7:13 PM, Michael Richardson wrote: > Can you tell me which protocols use future timestamps in an moving > form (not stored at rest in a certificate in a DANE RR, for instance), > which care about discrepancies of less than 1 minute? iCal, for one, which can be used for recurring events that have nothing to do with computers. Also relevant, would be the POSIX 1003.1 TZ offset variable that takes into account seconds. I mention it because it can be used to correct for seconds, should the need ever arise. Eliot From tglassey@earthlink.net Sun Jan 22 09:56:53 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A2D21F843A for ; Sun, 22 Jan 2012 09:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] 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 b9UtxY5JJumt for ; Sun, 22 Jan 2012 09:56:52 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id AF89021F842B for ; Sun, 22 Jan 2012 09:56:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=HpITFtTN3xCUyGjtaMxyyjeCgDMrgkaSBBGYwqOAPQ1hX33QjOPvf4YpPCTqc0mt; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.100]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Rp1ep-00059n-4G; Sun, 22 Jan 2012 12:56:47 -0500 Message-ID: <4F1C4DDD.1090903@earthlink.net> Date: Sun, 22 Jan 2012 09:56:45 -0800 From: todd glassey User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Tim Bray , IETF Discussion Mailing List Subject: Re: ITC copped out on UTC again References: In-Reply-To: X-Opacus-Archived: none X-Opacus-Archived: none X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec799cc104b0ed931f989097b96469f9b82a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 17:56:54 -0000 On 1/20/2012 7:13 AM, Tim Bray wrote: > One consequence of your proposal, if adopted, is that there will need > to be a specification of the canonical Internet-time-to-Sidereal-time > function, No actually there isn't such a need Tim. Its one of the problems we face here in the timekeeping world. In fact let me respond as a professional timekeeper since it appears as I am the only one here. > so that in the long run, the time that your computer says it > is will correspond with what you observe looking out the window. OK - I disagree. Global time should not be local time. If people are too stupid to deal with that wait another 30 yeas and those idiots will all be gone... as in dead - and the new crop of talent will have grown up with the fact that time is mutable. The issue of the Internet being around you cite below also pertains to space based commerce, so in designing a system that only works on this planet you repeat the previous mistake. The > Internet will be around long enough that this will indeed become a > problem. So again the issue here is that protocols and software today are implemented to need this support. That is the way were designed, i.e. in a manner which specifically causes this thing now being identified as a problem. > > On Fri, Jan 20, 2012 at 6:20 AM, Phillip Hallam-Baker wrote: >> If we are ever going to get a handle on Internet time we need to get rid of >> the arbitrary correction factors introduced by leap seconds. OK I can see this. Why cannot the Internet track TAI and a TAI to real-world offset table be kept and published by NIST, NPL, PTB, NRC, NITC or how about from NTP.ORG for instance... its their protocol right? Seems simple to make the client-side of the NTP implementation totally responsible for the time conversion if its even necessary. That's a reference port change and not a protocol change per se as well meaning it doesnt take the IETF to approve that at all. >> >> The problems caused by leap seconds are that they make it impossible for two >> machines to know if they are referring to the same point in future time and >> quite often introduce errors in the present. No... they just require something more than the limited use time synchronization tools around today like NTP for instance. >> >> 1) No machine can determine the number of seconds between two arbitrary UTC >> dates in the future since there may be a leap second announced. >> >> 2) If Machine A is attempting to synchronize with machine B on a future >> point in time, they cannot do so unless they know that they have the same >> view of leap seconds. If a leap second is announced and only one makes the >> correction, an error is introduced. Yes but is a failing of NTP... not leap seconds. >> >> 3) In practice computer systems rarely apply leap seconds at the correct >> time in any case. What you mean is that the time-keepers rarely apply the leap second properly. Time in the production world comes from automated sources in most instance so this is a non-issue. >> There is thus a jitter introduced around the introduction >> of leap seconds as different machines get an NTP fix at different points in >> time. Oh that's funny. Jitter introduced into a system which is not attesting to anything, or otherwise tied to most global commerce. What could this 'jitter' actually do? >> >> 4) Even though it is possible to represent leap seconds correctly in >> standard formats, doing so is almost certain to exercise code paths that >> should be avoided. >> >> >> Since the ITU does not look like sorting this out, I suggest we do so in the >> IETF. There is no functional reason that Internet protocols should need leap >> seconds. I suggest that this may cause a rift between the IETF and other Global Standards Orgs and that its something that shouldn't happen here. I also suggest that this is outside the IETF's charter or scope of operations and that it can be fixed inside the NTP working group as a design issue before being submitted to the IETF for cannonization. >> >> I suggest that the IETF plan to move to Internet Time in 2015, immediately >> after the next ITU meeting. I suggest that Internet Time should be pure TAI and simply be a standardized counter of offset (TAI offset) from the EPOCH and that anyone supplying time to the world will need a method of specifying whether its adjusted for Earth Offsets and Time of Day or whether its pure TAI. Internet time would be TAI plus the number of >> leap seconds that have accumulated up to the next ITU decision point. NO - Again - the Internet Time should be pure TAI. Securities Trading Time should be pure TAI. Financial Transaction Time should be pure TAI. So if >> UTC drops leap seconds at the next meeting the two series will be in sync, >> otherwise there will be a divergence. It is OK for them to be different values. >> >> >> >> -- >> Website: http://hallambaker.com/ >> >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. From tglassey@earthlink.net Sun Jan 22 11:38:36 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E33521F8582 for ; Sun, 22 Jan 2012 11:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] 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 HKXYvITw+Ipu for ; Sun, 22 Jan 2012 11:38:35 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4321221F84E7 for ; Sun, 22 Jan 2012 11:38:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=RfNiz/I+Hlr+p0D/4bzqp7ryoFfXU43WZfwJjkNGND9yKISp/6iJNIxV/as6AAlo; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Opacus-Archived:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.66] (helo=[192.168.1.100]) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Rp3FI-0007p5-So; Sun, 22 Jan 2012 14:38:33 -0500 Message-ID: <4F1C65B6.9080102@earthlink.net> Date: Sun, 22 Jan 2012 11:38:30 -0800 From: todd glassey User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "t.petch" Subject: Re: Please remove draft-ordogh-spam-reporting-using-imap-kleansed fromI-D repository References: <4F19824E.9020101@tana.it> <003e01ccd86e$0bc89a40$4001a8c0@gateway.2wire.net> In-Reply-To: <003e01ccd86e$0bc89a40$4001a8c0@gateway.2wire.net> X-Opacus-Archived: none X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79a627bbc26b9a890b6d81b5ddebebc335350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.66 Cc: ietf , Alessandro Vesely X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2012 19:38:36 -0000 On 1/21/2012 10:53 AM, t.petch wrote: > Alessandro > > You could, of course, issue an updated version which simply says that its > predecessor should not have been filed for the reasons you give in the e-mail. > No need to include any other text whatsoever (except, of course, the relevant > boiler plate). Tom No actually he cant. That will complicate the matter since the IETF publishing manner has specifically been set up to destroy the ability to recall anything. The license to use per the copyright statement is irrevocable even through the revisions process. That's right - it was published with a set of specific rights use statements which are factually wrong and now the IETF is stuck with that - unless a recall practice is put in place immediately like all other publications houses have. Todd > > That seems simpler to me than asking the system to do something rather unusual > that it may not have a mechanism to do. In future, there could always be > another version moving the process forward in the appropriate direction. > > Tom Petch > > ----- Original Message ----- > From: "Alessandro Vesely" > To: > Cc: "Zoltan Ordogh" ; "apps discuss" ; > "ietf" > Sent: Friday, January 20, 2012 4:03 PM > Subject: Please remove draft-ordogh-spam-reporting-using-imap-kleansed fromI-D > repository > > >> Dear IETF Secretariat, >> >> I hereby ask that draft-ordogh-spam-reporting-using-imap-kleansed be >> removed from the I-D repository. I submitted it on 10 Jan 2012, in a >> clumsy attempt to speed up a discussion about a similarly named I-D, >> draft-ordogh-spam-reporting-using-imap. The editing I carried out was >> based on previous writing about, both privately and on IETF lists. >> However, I hadn't obtained the author's permission to alter the >> boilerplate-type of the original document. Thus, the document I >> posted bears "wrong" copyright information. In particular, unwitting >> editors may derive their own work from this document if they just >> abide by its boilerplate text, while the original post did not imply a >> handoff of change control. >> >> I apologize for any inconveniences that my action might have caused. >> >> Regards >> Alessandro Vesely >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> >> > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > -- Todd S. Glassey This is from my personal email account and any materials from this account come with personal disclaimers. Further I OPT OUT of any and all commercial emailings. From mcr@sandelman.ca Sun Jan 22 18:27:05 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC35B21F84E7 for ; Sun, 22 Jan 2012 18:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.339 X-Spam-Level: X-Spam-Status: No, score=-0.339 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_20=-0.74, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_63=0.6] 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 3gRViAIw2yWL for ; Sun, 22 Jan 2012 18:27:04 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5361A21F84D0 for ; Sun, 22 Jan 2012 18:27:04 -0800 (PST) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 9E9C43448A for ; Sun, 22 Jan 2012 21:24:58 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id C04C79845F; Sun, 22 Jan 2012 21:27:02 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id B829E9845E for ; Sun, 22 Jan 2012 21:27:02 -0500 (EST) From: Michael Richardson To: IETF Discussion Mailing List Subject: Re: ITC copped out on UTC again In-Reply-To: <4F1C36A5.7000806@cisco.com> References: <6010.1327083238@marajade.sandelman.ca> <4F1C36A5.7000806@cisco.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 22 Jan 2012 21:27:02 -0500 Message-ID: <13039.1327285622@marajade.sandelman.ca> Sender: mcr@sandelman.ca X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 02:27:06 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Eliot" =3D=3D Eliot Lear writes: >> Can you tell me which protocols use future timestamps in an >> moving form (not stored at rest in a certificate in a DANE RR, >> for instance), which care about discrepancies of less than 1 >> minute? Eliot> iCal, for one, which can be used for recurring events that Eliot> have nothing to do with computers. Also relevant, would be Forgive me for being dense, but I don't understand how this is relevant. iCal, as far as I can understand, stores start/end dates in human form. For instance, from RF2445: BEGIN:VTIMEZONE TZID:US-Eastern LAST-MODIFIED:19870101T000000Z BEGIN:STANDARD DTSTART:19971026T020000 RDATE:19971026T020000 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST END:STANDARD BEGIN:DAYLIGHT DTSTART:19971026T020000 I don't see seconds-since-epoch anywhere here, I see years since guy-was-nailed-to-cross here. As such, that number is assumed to already be adjusted for leap-seconds, so it's a non-issue. What I'm looking for is a protocol where a hostA says to hostB, "lets meet behind the red-router for a 4.2s tryst 27.563456years from now"=20=20 it's important that the period of time until the meeting be large, and the precision of the meeting be small enough so that the uncertainty due to leap-seconds exceed the precision of the meeting time. We do not know how many/when leap seconds will be inserted in the next hundred years, but based upon one every 2-3 years, it would be around one hundred years before the accumulated uncertainty due to whether it was one every 2 years or one every 3 years, begins to exceed 1 minute. I've heard statements about financial systems, and I've obtained the FIX specifications from http://fixprotocol.org. (The copyright permits redistribution, but fixprotocol.org makes you register to get the .zip file... ) and as far as I can see in my naivety, few timestamps in this protocol are likely to exceed 1 year, and none of them would seem to need a precision of less than 1 minute. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUATxzFdoqHRg3pndX9AQLSHAQA3EIqL3owPZTg1o5hJIcZuSqvg/ztPKRj wfcFeyqodpUm0HYXcpwCas7AGE9ykp1s67qOoQYePMT2FRPF4bAZgLwIlbNy0zg4 Qddgaw8B5i5lndtt5UON2NPqPsXSMwxO9fGVFLl95a/JBhF9cGCj7VXMyh0oJc3C 2htIA7kEEpY= =DLds -----END PGP SIGNATURE----- --=-=-=-- From vesely@tana.it Mon Jan 23 01:52:27 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B535921F8650 for ; Mon, 23 Jan 2012 01:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.626 X-Spam-Level: X-Spam-Status: No, score=-4.626 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 WA5zk+HwCnUM for ; Mon, 23 Jan 2012 01:52:26 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8CF21F8621 for ; Mon, 23 Jan 2012 01:52:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1327312344; bh=lSBXsfecg+D/15MStCGxtClIZWYZazwOsJTD1SA1pAU=; l=1575; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=T+GWDmge8LhC2zW07L0cyQOxtPcl0DDHdBWVnLHwgXI2O4pbeVuRBjwiGGdtfluAN noZrk9ittGcMt5bYQU72U9ijMaB+R8dn9DYeXZQfi7fcdH2k0Q5ckRvzC5Y2lVMCJ5 /jKVc/0S8j3yOLuKsZYrjMJBhF8KVYXBEpGsi65Y= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 23 Jan 2012 10:52:24 +0100 id 00000000005DC048.000000004F1D2DD8.00000232 Message-ID: <4F1D2DD7.6090103@tana.it> Date: Mon, 23 Jan 2012 10:52:23 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: ITC copped out on UTC again References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 09:52:27 -0000 > The solution is simple - move to TAI. That is the _true_ time, what > the master clocks actually keep. UTC is just a variant for creatures > living on the surface of the Earth. Being one of those creatures, I voted for keeping leap seconds. UTC seems to fit the global Internet quite nicely, although it has some problems. When we'll inhabit faraway planets and use some other time reference, we'll be facing /more/ problems, not less. >> The problems caused by leap seconds are that they make it impossible for two >> machines to know if they are referring to the same point in future time and >> quite often introduce errors in the present. >> >> 1) No machine can determine the number of seconds between two arbitrary UTC >> dates in the future since there may be a leap second announced. > > Not true for TAI. TAI is computed after averaging several clocks, so it is not known in advance either. Both UTC and TAI are labels, albeit the latter is smoother. >> 2) If Machine A is attempting to synchronize with machine B on a future >> point in time, they cannot do so unless they know that they have the same >> view of leap seconds. If a leap second is announced and only one makes the >> correction, an error is introduced. > > Not true for TAI The problem is still ill-defined for faraway or accelerated machines, according to relativity. For practical purposes, the divergence of their timekeeping is likely, unless they are well connected to a common time reference. In that case, they can as well connect to one another, no? From lear@cisco.com Mon Jan 23 02:05:55 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C428521F85C6 for ; Mon, 23 Jan 2012 02:05:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.527 X-Spam-Level: X-Spam-Status: No, score=-110.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 YeN6R1C5Xk5Q for ; Mon, 23 Jan 2012 02:05:55 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id E849121F867D for ; Mon, 23 Jan 2012 02:05:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1533; q=dns/txt; s=iport; t=1327313155; x=1328522755; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=4ZM7MbJiPvc3/ZVmp9Pp7rhWUpuTQU4cq6nzv1HCutQ=; b=cinpYybUUhTcizXHS+8EPx14Mbr+m4rtDhJowXtfJ2Tn/h1YUDoMpGUC tC/PNYn/MJ4p7E8ajf3YWonFmUMonl+RSlEvDJ+4aSK7u2Na6riwKF6hO HfLbK7Yk8is4LinsJyaGxANSyd3TzupHG0ksVAl/00vAK5JBGoTORrOhM 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHQwHU+Q/khR/2dsb2JhbABChQmpHYEFgXIBAQEEEgEQVQEQCw4KAgIFFgsCAgkDAgECAUUGDQEFAgEBHqIbAYxjkHeBL4lhgRYElRmSTw X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="64354318" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 23 Jan 2012 10:05:52 +0000 Received: from ams3-vpn-dhcp6436.cisco.com (ams3-vpn-dhcp6436.cisco.com [10.61.89.35]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0NA5pYb001123; Mon, 23 Jan 2012 10:05:52 GMT Message-ID: <4F1D30FE.5040406@cisco.com> Date: Mon, 23 Jan 2012 11:05:50 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Michael Richardson Subject: Re: ITC copped out on UTC again References: <6010.1327083238@marajade.sandelman.ca> <4F1C36A5.7000806@cisco.com> <13039.1327285622@marajade.sandelman.ca> In-Reply-To: <13039.1327285622@marajade.sandelman.ca> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 10:05:55 -0000 On 1/23/12 3:27 AM, Michael Richardson wrote: >>>>>> "Eliot" == Eliot Lear writes: > >> Can you tell me which protocols use future timestamps in an > >> moving form (not stored at rest in a certificate in a DANE RR, > >> for instance), which care about discrepancies of less than 1 > >> minute? > > Eliot> iCal, for one, which can be used for recurring events that > Eliot> have nothing to do with computers. Also relevant, would be > > Forgive me for being dense, but I don't understand how this is relevant. You're right, but you asked the wrong, though. To begin with, protocols don't care about anything. It's the people running the applications and services using the protocols that care. We can't say how iCal is being used everywhere. It is entirely possible that someone is using the format for something akin to cron(8). And as to the example you mention, let's look carefully: > > iCal, as far as I can understand, stores start/end dates in human form. > For instance, from RF2445: > BEGIN:VTIMEZONE > TZID:US-Eastern > LAST-MODIFIED:19870101T000000Z > BEGIN:STANDARD > DTSTART:19971026T020000 YYYYMMDD HHMMSS Note the "SS" at the end. I'll also note that the TZ database handles leap seconds but can also be used to adjust against UTC in some way. Note I'm not suggesting this, and I'm really glad we have a few years to think about it. Good time to have the dialog, however... Eliot From tjc@ecs.soton.ac.uk Mon Jan 23 02:37:13 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADE121F8543 for ; Mon, 23 Jan 2012 02:37:13 -0800 (PST) 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.001, BAYES_00=-2.599, HTML_MESSAGE=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 nTzV65FAOFRg for ; Mon, 23 Jan 2012 02:37:12 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 0466221F8532 for ; Mon, 23 Jan 2012 02:37:11 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q0NAb577015828 for ; Mon, 23 Jan 2012 10:37:05 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q0NAb577015828 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1327315025; bh=cYOEW4Ks+SvX7eb+4sPJ2lrpsss=; h=From:Mime-Version:Subject:Date:In-Reply-To:To:References; b=Vy2utGFtOtIZiw8pBdbI1WyRP1UJQQAZxEtYMraIfuX9f38KXDfqYEHGp7XRSa5G1 tc51vNKZeN1iZ1TiTRkHyhb8TiL7xGstAZ53KKixKASAYJ30e2CwjWdMjJ3dc6B52O 0Jriv6DC2CPPXIHpal4eQ3rX675Eq5mFoTMHuUmQ= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP id o0MAb50543759116Gu ret-id none; Mon, 23 Jan 2012 10:37:05 +0000 Received: from ip-205-220.eduroam.soton.ac.uk (ip-205-220.eduroam.soton.ac.uk [152.78.205.220]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q0NAb0VT022496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 23 Jan 2012 10:37:00 GMT From: Tim Chown Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_E0F4B994-A575-463B-A948-07A185F76AB4" Subject: Re: primary Paris hotel booking Date: Mon, 23 Jan 2012 10:37:12 +0000 In-Reply-To: <12CD270E-7726-4452-95BE-88D2EE15C088@apple.com> To: IETF Discussion References: <34EF3F99-10DE-4B6B-92A7-2DD255412A0C@lucidvision.com> <20120103194826.69AEA21F84AD@ietfa.amsl.com> <0A4FD46C-F43E-46A7-BA1D-B7684632DED8@standardstrack.com> <4F0374BB.8020102@gmail.com> <12CD270E-7726-4452-95BE-88D2EE15C088@apple.com> <49FE98CD-3E02-4A99-BA94-AA2BD902CBB2@ecs.soton.ac.uk> Message-ID: X-Mailer: Apple Mail (2.1251.1) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o0MAb5054375911600; tid=o0MAb50543759116Gu; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q0NAb577015828 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 10:37:13 -0000 --Apple-Mail=_E0F4B994-A575-463B-A948-07A185F76AB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20 Jan 2012, at 00:37, Stuart Cheshire wrote: >=20 > Good suggestion Brian. >=20 > I just called our corporate travel department and got the same rate as = IETF, including free Internet and breakfast, and "cancel by 6 PM on = check-in day". Nice if you have such a department :) I booked a room by fax and the email confirmation took 11 days to = arrive, so don't expect a quick turnaround. Tim= --Apple-Mail=_E0F4B994-A575-463B-A948-07A185F76AB4 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
      On 20 Jan 2012, at 00:37, Stuart Cheshire wrote:

      Good suggestion Brian.

      I just called our corporate travel department and got the same rate as IETF, including free Internet and breakfast, and "cancel by 6 PM on check-in day".

      Nice if you have such a department :)

      I booked a room by fax and the email confirmation took 11 days to arrive, so don't expect a quick turnaround.

      Tim
      --Apple-Mail=_E0F4B994-A575-463B-A948-07A185F76AB4-- From fanf2@hermes.cam.ac.uk Mon Jan 23 04:14:58 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3ECE21F8715 for ; Mon, 23 Jan 2012 04:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.283 X-Spam-Level: X-Spam-Status: No, score=-6.283 tagged_above=-999 required=5 tests=[AWL=0.316, 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 OKRusx802Lj3 for ; Mon, 23 Jan 2012 04:14:57 -0800 (PST) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [131.111.8.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEE521F8712 for ; Mon, 23 Jan 2012 04:14:57 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:40733) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1RpInX-0004hm-EG (Exim 4.72) (return-path ); Mon, 23 Jan 2012 12:14:55 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RpInX-0005da-BB (Exim 4.67) (return-path ); Mon, 23 Jan 2012 12:14:55 +0000 Date: Mon, 23 Jan 2012 12:14:55 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Clint Chaplin Subject: Re: ITC copped out on UTC again In-Reply-To: Message-ID: References: <20120120180441.GH341@mip.aaaaa.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870024-995099827-1327320895=:505" Sender: Tony Finch Cc: Ofer Inbar , IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 12:14:58 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1870870024-995099827-1327320895=:505 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Clint Chaplin wrote: > On Fri, Jan 20, 2012 at 10:04 AM, Ofer Inbar wrote: > > If the main problem with leap seconds is their future > > unpredictability, isn't there a compromise option between the status > > quo and no more leap seconds? =A0Couldn't they come up with a fixed > > schedule for leap seconds for many centuries at a time, based on > > current predictions of approximately how many will be needed each > > century? > The earth's rate of rotation is not uniform, and the rate of change of > that rotation is not uniform, either. > > So, predicting future rates and rate of change is not possible. Even so, the current state of the art is that leap seconds could be scheduled three years in advance and keep within the |DUT1| < 0.9s limit. That would make it easier to cope with leap seconds tables as part of routine software updates, whereas with the current 6 month warning many systems need to treat the data as dynamic, and this in turn causes bootstrap problems. Tony. --=20 f.anthony.n.finch http://dotat.at/ Fair Isle, Faeroes: Northwesterly 5 to 7, occasionally gale 8 for a time in north Faeroes, becoming variable 4, then southeasterly 4 or 5 in south late= r. Rough or very rough. Wintry showers. Good, occasionally poor. --1870870024-995099827-1327320895=:505-- From Ray.Bellis@nominet.org.uk Mon Jan 23 04:34:15 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7AD21F8710 for ; Mon, 23 Jan 2012 04:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.957 X-Spam-Level: X-Spam-Status: No, score=-8.957 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_20=-0.74, 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 DNy1wsXaNCT7 for ; Mon, 23 Jan 2012 04:34:14 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5953721F8709 for ; Mon, 23 Jan 2012 04:34:08 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=0jniwgdQsti2BAhELSyiSB1ju172h/Rvu2pTdKypMGerbZOZz0AHNTIA YOTKMfKx9DoZTuZQ29MO1R3XpRUu8nq4Vl/h991eXJXX3qjz37lgPmYqm Mj4c2opoZFWThZp; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1327322049; x=1358858049; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20ITC=20copped=20out=20on=20UTC=20again |Date:=20Mon,=2023=20Jan=202012=2012:34:06=20+0000 |Message-ID:=20|To:=20IETF=20Discussion=20Mailing=20List=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<95b19ac2-c6bc-45d1-9447-d68fa5e0f21b> |In-Reply-To:=20|References:=20=0D=0A=20< 20120120180441.GH341@mip.aaaaa.org>=0D=0A=20=0D=0A=20; bh=gH3ppF9LOPT3QPjCz7vg15PNon4DWLDmpqlxddXCV2o=; b=3xBXC2BgWAl78l6mkeRH4HfpqyRr/TojfK6AqnLJ08BLiT+CE8ZnnA59 Wd7wgsngcCdR0SQ0yObZ2iXl9IY4+h9t3NkqeLC+6kHaaZ7P1RfU+Nxaj qXb//EwKydkftR6; X-IronPort-AV: E=Sophos;i="4.71,555,1320624000"; d="scan'208";a="30808852" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 23 Jan 2012 12:34:07 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Mon, 23 Jan 2012 12:34:06 +0000 From: Ray Bellis To: IETF Discussion Mailing List Subject: Re: ITC copped out on UTC again Thread-Topic: ITC copped out on UTC again Thread-Index: AQHM137P36pdS5sgO0G2GdDqycNLopYVjPiAgAATuoCABEGLgIAABVwA Date: Mon, 23 Jan 2012 12:34:06 +0000 Message-ID: References: <20120120180441.GH341@mip.aaaaa.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: <95b19ac2-c6bc-45d1-9447-d68fa5e0f21b> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 12:34:15 -0000 Just curious, but I've often used the formulation: day =3D (now - now % 86400) where "now" is the output of "gmtime()" of equivalent to calculate the numb= er of days since the epoch. How is this affected (or not) by the presence of leap seconds, and/or any p= roposal to remove them. Ray From fanf2@hermes.cam.ac.uk Mon Jan 23 05:26:28 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D26621F8735 for ; Mon, 23 Jan 2012 05:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.287, 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 vk6o9MBGZ1FW for ; Mon, 23 Jan 2012 05:26:27 -0800 (PST) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by ietfa.amsl.com (Postfix) with ESMTP id 7A32921F871E for ; Mon, 23 Jan 2012 05:26:27 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:54281) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1RpJuk-00062l-qu (Exim 4.72) (return-path ); Mon, 23 Jan 2012 13:26:26 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RpJuk-0001Gt-9r (Exim 4.67) (return-path ); Mon, 23 Jan 2012 13:26:26 +0000 Date: Mon, 23 Jan 2012 13:26:26 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Brian E Carpenter Subject: Re: ITC copped out on UTC again In-Reply-To: <4F19BFF4.7000102@gmail.com> Message-ID: References: <4F19BFF4.7000102@gmail.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: Phillip Hallam-Baker , IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 13:26:28 -0000 Brian E Carpenter wrote: > > Time is and always will be an arbitrary measurement scheme, and the only > thing that makes sense for the Internet is to use the same arbitrary > scheme as everybody else. We just have to suck up the resulting > inconveniences, as GPS has to. It would be unthinkable to go it alone. Most of the above is correct, but the difficulty with UTC is not arbitrary. There are two important ways of measuring time: either as a precisely uniform series of SI seconds (which has been possible only since the invention of atomic clocks) or as the angle of the earth relative to the sun (the traditional way). The Earth is not a uniform or stable oscillator so we cannot easily predict the exact relation between atomic time and earth time. UTC is a bodge that tries to accommodate these conflicting forms of time in one timescale. Yes, the length of the second and our notations for time and date are arbitrary, but it is not possible to replace them with a new rational arrangement that would make something like UTC less vexing, because there is no standard unit of time that evenly divides the unpredictably variable length of the day. Tony. -- f.anthony.n.finch http://dotat.at/ North Utsire, South Utsire: Southerly or southeasterly 5 to 7, decreasing 4 at times. Moderate or rough. Wintry showers. Good, occasionally poor. From fanf2@hermes.cam.ac.uk Mon Jan 23 05:32:04 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0632221F85CD for ; Mon, 23 Jan 2012 05:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 vffcsNvyP0SH for ; Mon, 23 Jan 2012 05:32:02 -0800 (PST) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6A321F85AF for ; Mon, 23 Jan 2012 05:32:02 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:57820) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1RpK09-0001YJ-Y1 (Exim 4.72) (return-path ); Mon, 23 Jan 2012 13:32:01 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1RpK09-0002M8-Gi (Exim 4.67) (return-path ); Mon, 23 Jan 2012 13:32:01 +0000 Date: Mon, 23 Jan 2012 13:32:01 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Ray Bellis Subject: Re: ITC copped out on UTC again In-Reply-To: Message-ID: References: <20120120180441.GH341@mip.aaaaa.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 13:32:04 -0000 Ray Bellis wrote: > day = (now - now % 86400) > > where "now" is the output of "gmtime()" of equivalent to calculate the > number of days since the epoch. > > How is this affected (or not) by the presence of leap seconds, and/or > any proposal to remove them. It is not affected because it is guaranteed to work by POSIX's definition of "seconds since the epoch", which ignores leap seconds. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15 Tony. -- f.anthony.n.finch http://dotat.at/ Shannon, South Rockall: Variable 4, becoming cyclonic, then southwesterly, 5 to 7, perhaps gale 8 later in south Rockall. Rough. Occasional rain. Moderate or good. From julian.reschke@gmx.de Mon Jan 23 08:04:59 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F1621F871C for ; Mon, 23 Jan 2012 08:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.544 X-Spam-Level: X-Spam-Status: No, score=-103.544 tagged_above=-999 required=5 tests=[AWL=-0.945, 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 iML2ynHcRBDj for ; Mon, 23 Jan 2012 08:04:59 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E3A0B21F86DC for ; Mon, 23 Jan 2012 08:04:58 -0800 (PST) Received: (qmail invoked by alias); 23 Jan 2012 15:58:18 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp069) with SMTP; 23 Jan 2012 16:58:18 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+5VW4MwUu5haBx+PEK/sVEJ7CkiOmQQyCqbjcBUC ET4NQJ00tthf0g Message-ID: <4F1D8391.3080009@gmx.de> Date: Mon, 23 Jan 2012 16:58:09 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> In-Reply-To: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: The IESG , oauth@ietf.org, IETF-Announce X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 16:04:59 -0000 On 2012-01-23 16:46, The IESG wrote: > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard > ... Please see my comments in which I think have not been addressed. Best regards, Julian From julian.reschke@gmx.de Mon Jan 23 09:39:18 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E3E21F8661 for ; Mon, 23 Jan 2012 09:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.413 X-Spam-Level: X-Spam-Status: No, score=-103.413 tagged_above=-999 required=5 tests=[AWL=-0.814, 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 ajCWWNK1HYok for ; Mon, 23 Jan 2012 09:39:18 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9FF4B21F862A for ; Mon, 23 Jan 2012 09:39:17 -0800 (PST) Received: (qmail invoked by alias); 23 Jan 2012 17:39:15 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp059) with SMTP; 23 Jan 2012 18:39:15 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+vNLNbPiKvpHsb50YBBPBVBDJTqwH2tg4cwQpM4s bFMryQN0c3ZL/7 Message-ID: <4F1D9B40.9070901@gmx.de> Date: Mon, 23 Jan 2012 18:39:12 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Mike Jones Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> <4E1F6AAD24975D4BA5B168042967394366375F80@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366375F80@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: The IESG , "ietf@ietf.org" , "oauth@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 17:39:18 -0000 On 2012-01-23 18:24, Mike Jones wrote: > As editor of the Oauth Bearer spec, I believe that these comments have been well understood and considered by the working group. I do understand that the working group's consensus position is different than Julian's. See these notes documenting that this is the case: > > https://www.ietf.org/mail-archive/web/oauth/current/msg08113.html > https://www.ietf.org/mail-archive/web/oauth/current/msg08116.html > https://www.ietf.org/mail-archive/web/oauth/current/msg08121.html > ... We are going in circles; see . I can only recommend that people who want to know what's going on read the complete mail thread. Also I'd like to point out that I *did* recommend to go to IETF LC despite these issues because I believe that more review from outside the WG is needed here. Best regards, Julian From marshall.eubanks@gmail.com Mon Jan 23 10:03:37 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403CB21F86B6 for ; Mon, 23 Jan 2012 10:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.495 X-Spam-Level: X-Spam-Status: No, score=-103.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, 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 UHYuvBGialES for ; Mon, 23 Jan 2012 10:03:35 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7620421F86C1 for ; Mon, 23 Jan 2012 10:03:35 -0800 (PST) Received: by obbwc12 with SMTP id wc12so3999119obb.31 for ; Mon, 23 Jan 2012 10:03:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AEA43W4YVt8Rz7xbsW8nim+wIDbRDzO7RoGwuP22c6A=; b=Eh7dwpROUPjN0yxtpIebCbZcfJr63J/ym9TQTCrcP0pQa5MopM9BMzR4U+bohi3Qso ObKo4Yl5MmfrQZd9R/GkfLi6kPklafXhuMXqjjrHcobJxMBTxylFV7bDIy87O2q/2VdS CH8sZzoWUx3zTXczNl+GHXZo1kNiHmnrQk//c= MIME-Version: 1.0 Received: by 10.182.47.10 with SMTP id z10mr8769993obm.19.1327341815120; Mon, 23 Jan 2012 10:03:35 -0800 (PST) Received: by 10.182.79.102 with HTTP; Mon, 23 Jan 2012 10:03:35 -0800 (PST) In-Reply-To: <4F1D2DD7.6090103@tana.it> References: <4F1D2DD7.6090103@tana.it> Date: Mon, 23 Jan 2012 13:03:35 -0500 Message-ID: Subject: Re: ITC copped out on UTC again From: Marshall Eubanks To: Alessandro Vesely Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 18:03:37 -0000 On Mon, Jan 23, 2012 at 4:52 AM, Alessandro Vesely wrote: >> The solution is simple - move to TAI. That is the _true_ time, what >> the master clocks actually keep. UTC is just a variant for creatures >> living on the surface of the Earth. > > Being one of those creatures, I voted for keeping leap seconds. =A0UTC > seems to fit the global Internet quite nicely, although it has some > problems. =A0When we'll inhabit faraway planets and use some other time > reference, we'll be facing /more/ problems, not less. > >>> The problems caused by leap seconds are that they make it impossible fo= r two >>> machines to know if they are referring to the same point in future time= and >>> quite often introduce errors in the present. >>> >>> 1) No machine can determine the number of seconds between two arbitrary= UTC >>> dates in the future since there may be a leap second announced. >> >> Not true for TAI. > > TAI is computed after averaging several clocks, so it is not known in > advance either. =A0Both UTC and TAI are labels, albeit the latter is > smoother. That is a dodge. While no time system is known perfectly in real time, there are a number of clocks slaved to TAI that can be used to realize TIA in real time to much better than microsecond accuracy (and, of course, that is how we get real time UTC). In any case, the use case being mentioned is about the difference between arbitrary, but specified, epochs, which is independent of the actual errors in the time system being used. > >>> 2) If Machine A is attempting to synchronize with machine B on a future >>> point in time, they cannot do so unless they know that they have the sa= me >>> view of leap seconds. If a leap second is announced and only one makes = the >>> correction, an error is introduced. >> >> Not true for TAI > > The problem is still ill-defined for faraway or accelerated machines, > according to relativity. =A0For practical purposes, the divergence of > their timekeeping is likely, unless they are well connected to a > common time reference. =A0In that case, they can as well connect to one > another, no? It's not ill defined at all, as long as GR and SR are correct. Both make very precise predictions about the difference between measurements made between clocks keeping proper time (i.e., freely running clocks). Einstein synchronization can always be done between such clocks. It is true that a sufficiently distributed set of clocks (say, Earth, Mars and Venus) will not agree on the simultaneity of remote events, but that lack of simultaneity can be exquisitely calculated, and even used for navigation (see, e.g., the Sagnac effect). And, of course, this is also orthogonal to the problem at hand, as UTC, GPS time, TT, all also experience from the same issues, and it has nothing to do with leap seconds. Regards Marshall > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From barryleiba.mailing.lists@gmail.com Mon Jan 23 10:31:58 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E52321F84C9; Mon, 23 Jan 2012 10:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.876 X-Spam-Level: X-Spam-Status: No, score=-102.876 tagged_above=-999 required=5 tests=[AWL=0.101, 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 ROn-nhPcIlJ0; Mon, 23 Jan 2012 10:31:57 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B36D21F84A1; Mon, 23 Jan 2012 10:31:56 -0800 (PST) Received: by yenm3 with SMTP id m3so1500821yen.31 for ; Mon, 23 Jan 2012 10:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rxBfFtbQLKSr67GTCam3tv6BZbEUZOKBn0oEndnGj8w=; b=uA5cPh+FLrbZc8PGMRb81QjP/7oSgw55bBwE66quLaYFdtl91Aaa3A+MkT/o/xpYcn YKeucT3Jks/XDaI0iAQQIARPpnT6B7XFQErrWpvE8b6k0zMYuf1WwgEeY6A7A3cAmehM ZKDMiowPMglkf0KQKoQF2DPEP2G6Nr8jiUO0Y= MIME-Version: 1.0 Received: by 10.236.139.193 with SMTP id c41mr13056450yhj.24.1327343516549; Mon, 23 Jan 2012 10:31:56 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.136.20 with HTTP; Mon, 23 Jan 2012 10:31:56 -0800 (PST) In-Reply-To: <20120123154409.15089.51253.idtracker@ietfa.amsl.com> References: <20120123154409.15089.51253.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2012 13:31:56 -0500 X-Google-Sender-Auth: 0KHqhPT1FcIgtmj5WU_4h9C_LiM Message-ID: Subject: Re: Last Call: (The OAuth 2.0 Authorization Protocol) to Proposed Standard From: Barry Leiba To: ietf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 18:31:58 -0000 > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol' > =A0 as a Proposed Standard There are some downrefs in this document that need to be called out in the Last Call notice, which weren't. * There is a normative reference to RFC 1750, which will be updated to point to RFC 4086 before publication. * There is a normative reference to RFC 2246 (TLS 1.0), which has been obsoleted by RFC 4346 (TLS 1.1). The document uses this reference to note that TLS 1.0 is, at this writing, the most widely deployed version. The working group believes it is necessary to note that, and that the reference be normative. * There is a normative reference to Informational RFC 2818 (HTTP over TLS). * There is a normative reference to Informational RFC 4627 (application/json Media Type). * There is a normative reference to Informational RFC 4949 (Internet Security Glossary). This is an allowed downref. Barry, document shepherd From stpeter@stpeter.im Mon Jan 23 10:35:02 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214EA21F86DA; Mon, 23 Jan 2012 10:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.654 X-Spam-Level: X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=-0.055, 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 fNZv8ZIR5W1g; Mon, 23 Jan 2012 10:35:01 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA8421F8588; Mon, 23 Jan 2012 10:35:01 -0800 (PST) Received: from dhcp-64-101-72-124.cisco.com (unknown [64.101.72.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4629C40058; Mon, 23 Jan 2012 11:44:40 -0700 (MST) Message-ID: <4F1DA853.3020401@stpeter.im> Date: Mon, 23 Jan 2012 11:34:59 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Barry Leiba Subject: Re: Last Call: (The OAuth 2.0 Authorization Protocol) to Proposed Standard References: <20120123154409.15089.51253.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, oauth@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 18:35:02 -0000 On 1/23/12 11:31 AM, Barry Leiba wrote: >> The IESG has received a request from the Web Authorization Protocol WG >> (oauth) to consider the following document: >> - 'The OAuth 2.0 Authorization Protocol' >> as a Proposed Standard > > There are some downrefs in this document that need to be called out in > the Last Call notice, which weren't. > > * There is a normative reference to RFC 1750, which will be updated to > point to RFC 4086 before publication. > > * There is a normative reference to RFC 2246 (TLS 1.0), which has been > obsoleted by RFC 4346 (TLS 1.1). The document uses this reference to > note that TLS 1.0 is, at this writing, the most widely deployed > version. The working group believes it is necessary to note that, and > that the reference be normative. > > * There is a normative reference to Informational RFC 2818 (HTTP over TLS). > > * There is a normative reference to Informational RFC 4627 > (application/json Media Type). The last two are already in the downref registry: http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry Peter -- Peter Saint-Andre https://stpeter.im/ From richard@shockey.us Mon Jan 23 10:37:17 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255BB21F851D for ; Mon, 23 Jan 2012 10:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.288 X-Spam-Level: X-Spam-Status: No, score=-100.288 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, 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 zyy3wLSb0JtJ for ; Mon, 23 Jan 2012 10:37:16 -0800 (PST) Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 782B821F850D for ; Mon, 23 Jan 2012 10:37:16 -0800 (PST) Received: (qmail 23189 invoked by uid 0); 23 Jan 2012 18:37:14 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy1.bluehost.com with SMTP; 23 Jan 2012 18:37:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=syR1/DFUtYVAFbstnB76krR0gbxC2Dm7xoRmXVocd2Y=; b=g3eL7byzRljxtEYwDOopf8Roh4OY3xW8id5hk+R+ErA0CDkAd8ElFytAPr/A8odSWaCc1P4rrnUqpHI9mRELOWfjBAYCmn0fhPhprbmaX2yhzVSNz+ckWugCT7FCXZ1m; Received: from [173.66.41.162] (helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RpOlW-0003gV-8O; Mon, 23 Jan 2012 11:37:14 -0700 From: "Richard Shockey" To: "'Henning Schulzrinne'" , References: In-Reply-To: Subject: RE: Interested in giving a talk at the FCC? Date: Mon, 23 Jan 2012 13:37:13 -0500 Message-ID: <013b01ccd9fe$06f91710$14eb4530$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczZIAWGv101/0KGSDGvyPot2XKt/QA3JyNQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.41.162 authed with richard@shockey.us} Cc: dispatch@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 18:37:17 -0000 I'd like to whole heartedly endorse this suggestion and encourage a variety of IETF Subject matter experts to give talks relevant to the FCC. I personally help arrange two seminars at the FCC at the invitation of Doug Sicker, Henning's predecessor as CTO The first on was a tutorial on SIP and the second on MPLS. As a rule these kinds of talks should be vendor/policy neutral. -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Sunday, January 22, 2012 11:10 AM To: ietf@ietf.org Subject: Interested in giving a talk at the FCC? If you're interested in giving a seminar to technical staff and/or economists at the US Federal Communications Commission (FCC), please let me know. The FCC won't be able to pay for travel, so we'd likely schedule any talks when you are in the DC area. Also, if you know of any colleagues the Commission staff should hear from, feel free to suggest them. I won't make any promises that I'll be able to accommodate all or even most offers, but this is an experiment to see if we can broaden the perspectives heard at the FCC. Most FCC staff are generalists, so topics should be accessible and of interest to this community. (In general, the FCC deals with many aspects of wired and wireless communications, and is interested in applications, as well as lower layers. Examples of topics of particular interest are spectrum-related issues, increasing broadband availability, security/privacy, IPv6, PSTN-transition issues, public safety and accessibility. Thus, if you're interested, please get in touch with me with a rough description of what you'd talk about. If there's local interest in your topic, I will get back to you to work out details. There is no deadline as such, so consider this a standing offer. Henning ------ Henning Schulzrinne CTO, FCC 7C252, (202) 418-1544 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From sm@resistor.net Mon Jan 23 11:11:10 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B183B21F86B6 for ; Mon, 23 Jan 2012 11:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.627 X-Spam-Level: X-Spam-Status: No, score=-102.627 tagged_above=-999 required=5 tests=[AWL=-0.028, 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 wbfiZesmYzs9 for ; Mon, 23 Jan 2012 11:11:07 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFC521F86B0 for ; Mon, 23 Jan 2012 11:11:07 -0800 (PST) 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 q0NJB06i015178 for ; Mon, 23 Jan 2012 11:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327345865; i=@resistor.net; bh=KtrAXL5CfeUjCkTCixxrO+rS6dvRcg2QbETnWwtmiOs=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=i5Dki2d/Hty/PNwauCSAelhDAS5AcpC65TLMHRIfrfmVMu6pgIO2/XPnhurA4x1wO EPTmPvmXyGABQHG3vEwpM6UoNEVQKgiJnsHUeDrSXwm6ia49/ACzgFf+wz6BeC89BF kOQPRMuj+0EKYKsxZjtJAk/JSxjjma7HPTNl8WDo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327345865; i=@resistor.net; bh=KtrAXL5CfeUjCkTCixxrO+rS6dvRcg2QbETnWwtmiOs=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=KvanN6tgZ0tMd+3cO7l4aXTZ43x2h644/NDatUKsgnuBoYtYv2TnOD18ST16VccKG 4nwTrrMg+BR25vWJdF0f4NSFMUlDxpl2RDhV+Hoz4spgqXrTtkLF33/nxFGMmrDxp4 fT0ob9864jexcU3XgTo6xKbSOqiBalHFxD14HcIg= Message-Id: <6.2.5.6.2.20120123103439.0a87a228@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 23 Jan 2012 11:04:17 -0800 To: ietf@ietf.org From: SM Subject: Re: Last Call: (xNAME RCODE and Status Bits Clarification) to Proposed Standard In-Reply-To: <20120123182317.28636.48689.idtracker@ietfa.amsl.com> References: <20120123182317.28636.48689.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 19:11:10 -0000 At 10:23 23-01-2012, The IESG wrote: >The IESG has received a request from the DNS Extensions WG (dnsext) to >consider the following document: >- 'xNAME RCODE and Status Bits Clarification' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may be From the Introduction Section: "This document clarifies, in the case of such redirected queries, how the RCODE and status bits correspond to the initial query cycle (where the (first) xNAME was detected) and subsequent or final query cycles." From Section 2.1: "[RFC1035] states that the AA bit is to be set based on whether the server providing the answer with the first owner name in the answer section is authoritative. This specification of the AA bit has not been changed. This specification of the AA bit has not been changed." And Section 2.2: "[RFC4035] unambiguously states that the AD bit is to be set in a DNS response header only if the DNSSEC enabled server believes all RRs in the answer and authority sections of that response to be authentic. This specification of the AD bit has not been changed." It is not clear to me what is being clarified about the status bits. In Section 3: "The RCODE in the ultimate DNS response MUST BE set based on the final query cycle leading to that response." Shouldn't the "BE" be lowercased? The status of the memo suggests sending comments to namedroppers@ops.ietf.org. Is that IETF mailing list still being used by DNSEXT? Regards, -sm From kpfleming@digium.com Mon Jan 23 12:04:15 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1601A21F86C4 for ; Mon, 23 Jan 2012 12:04:15 -0800 (PST) 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 zoypQJp5kjWw for ; Mon, 23 Jan 2012 12:04:14 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id F3AE321F86AB for ; Mon, 23 Jan 2012 12:04:13 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RpQ7h-0002fJ-9V for ietf@ietf.org; Mon, 23 Jan 2012 14:04:13 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 45BF5D8006 for ; Mon, 23 Jan 2012 14:04:13 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz+jSR4781fX for ; Mon, 23 Jan 2012 14:04:10 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id A9521D8002 for ; Mon, 23 Jan 2012 14:04:10 -0600 (CST) Message-ID: <4F1DBD3A.5070304@digium.com> Date: Mon, 23 Jan 2012 14:04:10 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: IETF Discussion Mailing List Subject: Room sharing in Paris? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 20:04:15 -0000 Is there an appropriate list/wiki/etc. to discuss possible room sharing arrangements? I'm not going to be able to register for the event until I get this worked out, so I can use the meeting-specific attendees list for that purpose. If there is no such place, I'll state here that I'm interested in discussing sharing a double room for IETF 83 in Paris from March 25th through 31st. Contact me off-line to discuss. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From ynir@checkpoint.com Mon Jan 23 12:42:31 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0267E21F85BD for ; Mon, 23 Jan 2012 12:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, 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 DXMkCnuDnrDR for ; Mon, 23 Jan 2012 12:42:30 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D154B21F85B9 for ; Mon, 23 Jan 2012 12:42:29 -0800 (PST) X-CheckPoint: {4F1DC338-3-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q0NKgOWQ031752; Mon, 23 Jan 2012 22:42:24 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 23 Jan 2012 22:42:24 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 23 Jan 2012 22:42:23 +0200 From: Yoav Nir To: "Kevin P. Fleming" Date: Mon, 23 Jan 2012 22:42:22 +0200 Subject: Re: Room sharing in Paris? Thread-Topic: Room sharing in Paris? Thread-Index: AczaD4J6wXFwNYaeQemHTOOWe93PbA== Message-ID: <2C925966-0BC0-4135-93D0-CF86F0412FF7@checkpoint.com> References: <4F1DBD3A.5070304@digium.com> In-Reply-To: <4F1DBD3A.5070304@digium.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US 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 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 20:42:31 -0000 Hi Kevin You can register at https://www.ietf.org/meeting/register.html You can hold off on paying until early March. That will give you the ability to edit the meeting wiki: https://www.ietf.org/registration/MeetingWiki/wiki/ietf83 You can easily add a page there for what you're looking for. Alternatively, you can register to the 83attendees list, and ask there. Not= e, however, that there are currently about 290 people on the list, and ther= e has been no traffic. That's less than a third of the people going to the = meeting https://www.ietf.org/mailman/listinfo/83attendees On Jan 23, 2012, at 10:04 PM, Kevin P. Fleming wrote: > Is there an appropriate list/wiki/etc. to discuss possible room sharing=20 > arrangements? I'm not going to be able to register for the event until I= =20 > get this worked out, so I can use the meeting-specific attendees list=20 > for that purpose. >=20 > If there is no such place, I'll state here that I'm interested in=20 > discussing sharing a double room for IETF 83 in Paris from March 25th=20 > through 31st. Contact me off-line to discuss. >=20 > --=20 > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpflemin= g > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf >=20 > Scanned by Check Point Total Security Gateway. From kpfleming@digium.com Mon Jan 23 13:08:11 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FA721F86A0 for ; Mon, 23 Jan 2012 13:08:11 -0800 (PST) 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 6G4L4ir4RXKg for ; Mon, 23 Jan 2012 13:08:10 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB2621F869C for ; Mon, 23 Jan 2012 13:08:09 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RpR7Z-0003hE-Gd; Mon, 23 Jan 2012 15:08:09 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 80395D8004; Mon, 23 Jan 2012 15:08:09 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBfTFP4GTO9Q; Mon, 23 Jan 2012 15:08:09 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 04318D8002; Mon, 23 Jan 2012 15:08:09 -0600 (CST) Message-ID: <4F1DCC38.2070309@digium.com> Date: Mon, 23 Jan 2012 15:08:08 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Yoav Nir Subject: Re: Room sharing in Paris? References: <4F1DBD3A.5070304@digium.com> <2C925966-0BC0-4135-93D0-CF86F0412FF7@checkpoint.com> In-Reply-To: <2C925966-0BC0-4135-93D0-CF86F0412FF7@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Discussion Mailing List X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 21:08:11 -0000 On 01/23/2012 02:42 PM, Yoav Nir wrote: > Hi Kevin > > You can register at https://www.ietf.org/meeting/register.html > You can hold off on paying until early March. Of course, I should have realized that. > That will give you the ability to edit the meeting wiki: > https://www.ietf.org/registration/MeetingWiki/wiki/ietf83 > > You can easily add a page there for what you're looking for. I've created the page: https://www.ietf.org/registration/MeetingWiki/wiki/83roomsharing Let's see what happens :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From ron.even.tlv@gmail.com Tue Jan 24 03:17:56 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BAE21F8526; Tue, 24 Jan 2012 03:17:56 -0800 (PST) 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=[AWL=-1.380, BAYES_00=-2.599, GB_I_LETTER=-2, GB_SUMOF=5, 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 zd3XawgJNfI1; Tue, 24 Jan 2012 03:17:55 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D279821F8516; Tue, 24 Jan 2012 03:17:54 -0800 (PST) Received: by eekc1 with SMTP id c1so1839752eek.31 for ; Tue, 24 Jan 2012 03:17:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=AGYIsiajWsPvAKMv617hQueNlHsg9BGequ4gi4WSVJU=; b=oCdBBRac4icHl4RUEeFBGW3ajUeUi8Jg8v/5tx4PVBJjUhD5gH154jT99nFPNxsnPb Gt8Gc3ZA7fTC03Rz/81QHAqq5slJQs9ByV4chAMn2g/hgUbwPWFHV/PJxeDv2YL5DVM0 C5OeS5bQnEgb8/ZHBc+KtiWXA0ABq9CWjsAqI= Received: by 10.14.2.16 with SMTP id 16mr4405130eee.103.1327403874011; Tue, 24 Jan 2012 03:17:54 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id w46sm34553222eeb.0.2012.01.24.03.17.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Jan 2012 03:17:52 -0800 (PST) From: "Roni Even" To: Subject: Gen-ART LC review of draft-harkins-ipsecme-spsk-auth-06 Date: Tue, 24 Jan 2012 13:13:55 +0200 Message-ID: <4f1e9360.46310e0a.0365.6835@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B0_01CCDA9A.0C5BBFE0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv4QaPRVpsdKx61SZSFiZ0ojWfylg== Content-Language: en-us Cc: gen-art@ietf.org, 'IETF-Discussion list' X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 11:17:56 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B0_01CCDA9A.0C5BBFE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-harkins-ipsecme-spsk-auth-06 Reviewer: Roni Even Review Date:2012-1-24 IETF LC End Date: 2012-2-14 IESG Telechat date: Summary: This draft is ready for publication as an Experimental RFC. Major issues: Minor issues: Nits/editorial comments: 1. Section 2 bullet 3 "Securty"? 2. In section 4.1 "The inverse function is defined such that the sum of an element and its inverse is "0":" . This looks like a zero to me and I assume you meant the letter "o" ------=_NextPart_000_00B0_01CCDA9A.0C5BBFE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

      I am the = assigned Gen-ART reviewer for this draft. For background on Gen-ART, = please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq= >.

       

      Please resolve these comments along with any other = Last Call comments you may receive.

       =

      Document: = draft-harki= ns-ipsecme-spsk-auth-06

      Reviewer: = Roni Even=

      Review = Date:2012–1–24

      IETF LC = End Date: 2012–2–14

      IESG = Telechat date:

       =

      Summary: = This draft is ready for publication as an Experimenta= l RFC.

       =

      Major = issues:

       =

       =

      Minor = issues:

       =

       =

      Nits/editor= ial comments:

       =

      1.       = Section 2 = bullet 3 “Securty”?

      2.       = In section = 4.1 “The inverse function is defined such that the sum of an = element and  its inverse is "0":” . This looks like = a zero to me and I assume you meant the letter = “o”

       =

       

      ------=_NextPart_000_00B0_01CCDA9A.0C5BBFE0-- From stephen.farrell@cs.tcd.ie Tue Jan 24 07:06:41 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3991921F8646; Tue, 24 Jan 2012 07:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.286, 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 kms5gnvHffwh; Tue, 24 Jan 2012 07:06:40 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E89921F8638; Tue, 24 Jan 2012 07:06:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D668C171D15; Tue, 24 Jan 2012 15:06:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1327417599; bh=sA+ugQ1NuCVFPq BNwJSHsTR71jDsoOfbh+MR1EKI2tg=; b=HMX+oR74o/fALoZNS8S4gQQ2kqEBu2 4jCMql3XT4OnQKGfOQC5SMBeelWlv6C3U7M/Zy/pcFtw1mcfOFygynI0zAjDn0VX DM4DHCWsuXmMwnVwLMa+1a9T3zEXLTA3wMz1WnGmfAf9Q/8+C/hJfIq/8qFZukWS LjK18HJIhocCSTYirQj1UW2TXDbz/jzXkzEf3P3j3nFjzBggIzw2rHZTzmy832vC x1nm2PsEqK5LYKpfoa865QF9K63CFSy7gQl4+XWg7S/V0dFMrUQ8Jz7V1N3IxMkF tSsTsocfFH//XfEX3iONRJU2OOR/TU+6lKT/Bg8D78wU38sP3Gdm142Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 2lZhsqgULZr6; Tue, 24 Jan 2012 15:06:39 +0000 (GMT) Received: from [10.1.1.138] (wifi.ist.utl.pt [193.136.128.57]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A6AA7171C04; Tue, 24 Jan 2012 15:06:38 +0000 (GMT) Message-ID: <4F1EC8FD.2020307@cs.tcd.ie> Date: Tue, 24 Jan 2012 15:06:37 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: REVISED Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard References: <20120124150006.1521.19292.idtracker@ietfa.amsl.com> In-Reply-To: <20120124150006.1521.19292.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: The IESG , oauth@ietf.org, IETF-Announce X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 15:06:41 -0000 Folks, The OAuth bearer and base last calls had to be re-done since I forgot to include some downref information. Other than adding a day to IETF LC, there should be no other difference. Sorry about that. S On 01/24/2012 03:00 PM, The IESG wrote: > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-02-07. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This specification describes how to use bearer tokens in HTTP > requests to access OAuth 2.0 protected resources. Any party in > possession of a bearer token (a "bearer") can use it to get access to > the associated resources (without demonstrating possession of a > cryptographic key). To prevent misuse, bearer tokens need to be > protected from disclosure in storage and in transport. > > > * There is a normative reference to RFC 2246 (TLS 1.0), which has been > obsoleted by RFC 5246 (TLS 1.2). The document uses this reference to > note that TLS 1.0 is, at this writing, the most widely deployed > version. The working group believes it is necessary to note that, and > that the reference be normative. > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > From Michael.Jones@microsoft.com Mon Jan 23 09:24:39 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E195621F8661; Mon, 23 Jan 2012 09:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 upHBp3N502iT; Mon, 23 Jan 2012 09:24:39 -0800 (PST) Received: from VA3EHSOBE010.bigfish.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 41B1721F865F; Mon, 23 Jan 2012 09:24:39 -0800 (PST) Received: from mail144-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE010.bigfish.com (10.7.40.12) with Microsoft SMTP Server id 14.1.225.22; Mon, 23 Jan 2012 17:24:30 +0000 Received: from mail144-va3 (localhost [127.0.0.1]) by mail144-va3-R.bigfish.com (Postfix) with ESMTP id AE9F1120357; Mon, 23 Jan 2012 17:24:32 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail144-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail144-va3 (localhost.localdomain [127.0.0.1]) by mail144-va3 (MessageSwitch) id 1327339470375874_15246; Mon, 23 Jan 2012 17:24:30 +0000 (UTC) Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.243]) by mail144-va3.bigfish.com (Postfix) with ESMTP id 5561520046; Mon, 23 Jan 2012 17:24:30 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 23 Jan 2012 17:24:27 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0247.005; Mon, 23 Jan 2012 09:24:25 -0800 From: Mike Jones To: "ietf@ietf.org" Subject: RE: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: AQHM2ejbNGzL+7cc6EiU4F3vKE4/fpYaMdvw Date: Mon, 23 Jan 2012 17:24:24 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366375F80@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> In-Reply-To: <4F1D8391.3080009@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Tue, 24 Jan 2012 09:25:42 -0800 Cc: Julian Reschke , The IESG , "oauth@ietf.org" , IETF-Announce X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 17:24:40 -0000 As editor of the Oauth Bearer spec, I believe that these comments have been= well understood and considered by the working group. I do understand that= the working group's consensus position is different than Julian's. See th= ese notes documenting that this is the case: https://www.ietf.org/mail-archive/web/oauth/current/msg08113.html https://www.ietf.org/mail-archive/web/oauth/current/msg08116.html https://www.ietf.org/mail-archive/web/oauth/current/msg08121.html Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ulian Reschke Sent: Monday, January 23, 2012 7:58 AM To: ietf@ietf.org Cc: The IESG; oauth@ietf.org; IETF-Announce Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard On 2012-01-23 16:46, The IESG wrote: > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard ... Please see my comments in which I think have not been addressed. Best regards, Julian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Mon Jan 23 10:45:03 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4834721F868A; Mon, 23 Jan 2012 10:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.19 X-Spam-Level: X-Spam-Status: No, score=-5.19 tagged_above=-999 required=5 tests=[AWL=1.409, 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 sXMskgsKQNjH; Mon, 23 Jan 2012 10:45:02 -0800 (PST) Received: from TX2EHSOBE003.bigfish.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC8821F8681; Mon, 23 Jan 2012 10:45:02 -0800 (PST) Received: from mail80-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Mon, 23 Jan 2012 18:44:53 +0000 Received: from mail80-tx2 (localhost [127.0.0.1]) by mail80-tx2-R.bigfish.com (Postfix) with ESMTP id C9622300288; Mon, 23 Jan 2012 18:44:54 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail80-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail80-tx2 (localhost.localdomain [127.0.0.1]) by mail80-tx2 (MessageSwitch) id 1327344293172313_27425; Mon, 23 Jan 2012 18:44:53 +0000 (UTC) Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.242]) by mail80-tx2.bigfish.com (Postfix) with ESMTP id DD2B9280075; Mon, 23 Jan 2012 18:44:51 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 23 Jan 2012 18:44:55 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0247.005; Mon, 23 Jan 2012 10:44:36 -0800 From: Mike Jones To: "ietf@ietf.org" , "iesg@ietf.org" Subject: RE: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: AQHM2ejbNGzL+7cc6EiU4F3vKE4/fpYaMdvwgAAYAzA= Date: Mon, 23 Jan 2012 18:44:35 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436637843C@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> <4E1F6AAD24975D4BA5B168042967394366375F80@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366375F80@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Tue, 24 Jan 2012 09:25:43 -0800 Cc: "oauth@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 18:45:03 -0000 Resending including iesg@ietf.org, per the advice of Cindy Morgan of the IE= SG Secretariat... -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Monday, January 23, 2012 9:24 AM To: ietf@ietf.org Cc: Julian Reschke; The IESG; oauth@ietf.org; IETF-Announce Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard As editor of the Oauth Bearer spec, I believe that these comments have been= well understood and considered by the working group. I do understand that= the working group's consensus position is different than Julian's. See th= ese notes documenting that this is the case: https://www.ietf.org/mail-archive/web/oauth/current/msg08113.html https://www.ietf.org/mail-archive/web/oauth/current/msg08116.html https://www.ietf.org/mail-archive/web/oauth/current/msg08121.html Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ulian Reschke Sent: Monday, January 23, 2012 7:58 AM To: ietf@ietf.org Cc: The IESG; oauth@ietf.org; IETF-Announce Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard On 2012-01-23 16:46, The IESG wrote: > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard ... Please see my comments in which I think have not been addressed. Best regards, Julian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From ben@nostrum.com Mon Jan 23 14:24:13 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5858B21F8737; Mon, 23 Jan 2012 14:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, SPF_PASS=-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 BlIplXZVqHci; Mon, 23 Jan 2012 14:24:12 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B50BD21F872D; Mon, 23 Jan 2012 14:24:12 -0800 (PST) Received: from dn3-53.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q0NMO45m049781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Jan 2012 16:24:04 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Gen-ART LC Review of draft-ietf-avtcore-srtp-vbr-audio-04 Date: Mon, 23 Jan 2012 16:24:02 -0600 Message-Id: <36F1DB21-7CC7-49D2-A249-B0DE7EFE7106@nostrum.com> To: draft-ietf-avtcore-srtp-vbr-audio.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 24 Jan 2012 09:25:42 -0800 Cc: "gen-art@ietf.org Review Team" , The IETF X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 22:24:13 -0000 I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at = . Please resolve these comments along with any other Last Call comments = you may receive. Document: draft-ietf-avtcore-srtp-vbr-audio-04 Reviewer: Ben Campbell Review Date: 2012-01-23 IETF LC End Date: 2012-01-23 Summary: This draft is ready for publication as a proposed standard. Note: I performed a gen-art review on revision 3 of this draft in a = previous last call. My understanding is that the draft has been last = called again due to the change from BCP to PS. I had no substantive = concerns in that version, and see no new substantive concerns in this = version. Major issues: None Minor issues: None Nits/editorial comments: -- The draft status still says BCP -- section 5, 1st paragraph, 2nd to last sentence: "...but the amount of = padding needed to hide the variation in packet size will depend on the=20= codec), codec and the sophistication of the attacker),... " Perhaps we should just assume the attacker is reasonably sophisticated = by current standards? I assume you don't expect an implementer to guess = how sophisticated a potential attack may be in advance--unless that is = somehow a function of the value of the content?= From richard@shockey.us Tue Jan 24 12:35:15 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0F111E809D for ; Tue, 24 Jan 2012 12:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.851 X-Spam-Level: X-Spam-Status: No, score=-98.851 tagged_above=-999 required=5 tests=[AWL=-0.957, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 4KUXiau7s6pl for ; Tue, 24 Jan 2012 12:35:15 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 2827E11E809B for ; Tue, 24 Jan 2012 12:35:15 -0800 (PST) Received: (qmail 20509 invoked by uid 0); 24 Jan 2012 20:28:35 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy8.bluehost.com with SMTP; 24 Jan 2012 20:28:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=k577J0Fl1PtfGdH7EgVtkPLu+sHrNVWTLk7qyyTtgNw=; b=W0yir1Cx+GkiFSCUEWefdz8YD6j21fXp2NHhXC74F68uIEcKRLNPXNo2InyHxnkI9ULlq3hfH5/R1+o3Asv55HmBeyAotPzkPRO6YGvrvZ6GQztINQmQI76TaIxzC1c/; Received: from [173.66.41.162] (helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Rpmyp-0008CE-4H; Tue, 24 Jan 2012 13:28:35 -0700 From: "Richard Shockey" To: , , Subject: FYI : Canada's CRTC mandates all IP Interconnection for voice. Date: Tue, 24 Jan 2012 15:28:33 -0500 Message-ID: <00fc01ccdad6$bf28f250$3d7ad6f0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FD_01CCDAAC.D652EA50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acza1r5eb73JA2MmQeS1U+mk/++X0w== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.41.162 authed with richard@shockey.us} X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 20:35:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00FD_01CCDAAC.D652EA50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In this decision, the Commission decides that it is in the public interest to establish a set of principles to facilitate IP voice network interconnections between network operators while allowing market forces to shape the details of the arrangements. Specifically, in areas where a carrier provides IP voice interconnection to an affiliate, a division of its operations, or an unrelated service provider, the carrier must negotiate a similar arrangement with any other carrier that requests such an arrangement. Within six months of a formal request, an arrangement is to be concluded. http://www.crtc.gc.ca/eng/com100/2012/r120119.htm Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org ------=_NextPart_000_00FD_01CCDAAC.D652EA50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

       

      In this decision, the = Commission decides that it is in the public interest to establish a set = of principles to facilitate IP voice network interconnections between = network operators while allowing market forces to shape the details of = the arrangements. Specifically, in areas where a carrier provides IP = voice interconnection to an affiliate, a division of its operations, or = an unrelated service provider, the carrier must negotiate a similar = arrangement with any other carrier that requests such an arrangement. = Within six months of a formal request, an arrangement is to be = concluded.

       

      http://www.crt= c.gc.ca/eng/com100/2012/r120119.htm

       

      Richard = Shockey
      Shockey Consulting
      Chairman of the Board of Directors SIP = Forum
      PSTN Mobile: +1 703.593.2683
      <mailto:richard(at)shockey.us>
      skype= -linkedin-facebook: rshockey101
      http//www.sipforum.org

       

      ------=_NextPart_000_00FD_01CCDAAC.D652EA50-- From kpfleming@digium.com Tue Jan 24 13:53:49 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4402E11E8085 for ; Tue, 24 Jan 2012 13:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.491 X-Spam-Level: X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 SPBnSAUUUlYQ for ; Tue, 24 Jan 2012 13:53:48 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6273811E8079 for ; Tue, 24 Jan 2012 13:53:48 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RpoJH-0003Eu-Ts for ietf@ietf.org; Tue, 24 Jan 2012 15:53:47 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id E301DD8004 for ; Tue, 24 Jan 2012 15:53:47 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlvRGDpg70aR for ; Tue, 24 Jan 2012 15:53:47 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 6CD61D8002 for ; Tue, 24 Jan 2012 15:53:47 -0600 (CST) Message-ID: <4F1F286A.1020101@digium.com> Date: Tue, 24 Jan 2012 15:53:46 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: FYI : Canada's CRTC mandates all IP Interconnection for voice. References: <00fc01ccdad6$bf28f250$3d7ad6f0$@us> In-Reply-To: <00fc01ccdad6$bf28f250$3d7ad6f0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 21:53:49 -0000 On 01/24/2012 02:28 PM, Richard Shockey wrote: > /In this decision, the Commission decides that it is in the public > interest to establish a set of principles to facilitate IP voice network > interconnections between network operators while allowing market forces > to shape the details of the arrangements. Specifically, in areas where a > carrier provides IP voice interconnection to an affiliate, a division of > its operations, or an unrelated service provider, the carrier must > negotiate a similar arrangement with any other carrier that requests > such an arrangement. Within six months of a formal request, an > arrangement is to be concluded./ > > http://www.crtc.gc.ca/eng/com100/2012/r120119.htm I think that your subject is a bit misleading. This decision does not 'outlaw' non-IP interconnection, nor does it obligate a carrier that is not currently IP-interconnected (if such a carrier exists) to become so connected. It only levels the playing field and ensures that all IP-interconnected carriers make IP interconnection available to any other carrier that is interested in it, not just the 'chosen few'. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From richard@shockey.us Tue Jan 24 14:27:45 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A1711E8079 for ; Tue, 24 Jan 2012 14:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.992 X-Spam-Level: X-Spam-Status: No, score=-99.992 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 nkYeU5nXC4k3 for ; Tue, 24 Jan 2012 14:27:45 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 229541F0C35 for ; Tue, 24 Jan 2012 14:27:45 -0800 (PST) Received: (qmail 25087 invoked by uid 0); 24 Jan 2012 22:27:44 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 24 Jan 2012 22:27:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:To:From; bh=pT6WjDAaH6FVztxRXWL6+vHggVHXhLe55ARGC8ghnOU=; b=msMj/sFdIkyF7TnzUheAlK0T2Ev/Fquh8+nCW7ZuNWNZvoZlW2Xw4wHk94FM2BVhpJoyDntMlPATqh3payp8XZYOKSuV2BwB6FH52qHiJZ/2tqRBVMkUhCQYC7dpJZrd; Received: from [173.66.41.162] (helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Rpoq7-0004IM-H9; Tue, 24 Jan 2012 15:27:43 -0700 From: "Richard Shockey" To: "'Kevin P. Fleming'" , References: <00fc01ccdad6$bf28f250$3d7ad6f0$@us> <4F1F286A.1020101@digium.com> In-Reply-To: <4F1F286A.1020101@digium.com> Subject: RE: FYI : Canada's CRTC mandates all IP Interconnection for voice. Date: Tue, 24 Jan 2012 17:27:41 -0500 Message-ID: <015c01ccdae7$63ea45e0$2bbed1a0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acza4qhrShwMubseSvGztNzGrizEDQAAuGTg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.41.162 authed with richard@shockey.us} X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 22:27:46 -0000 I didn't suggest that. It's clear in the Canadian Order that if you provide SIP interconnection to anyone you have to make it available to everyone. But as you correctly point out, I doubt such carriers either exist or will exist much longer. It does create a more level playing field. This Order clearly sidestepped the issue of a shot clock for full TDM retirement, though a review of the Order is suggested for 2014. I thought Paragraph 69-70 on establishing a Canadian carrier ENUM database personally amusing. The larger issue for our community is the existing NNI profiles have not been updated in years and there is still a huge gap analysis that needs to be undertaken that may require further IETF RAI work. I haven't seen that started yet. We haven't heard the last of this by any means. -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Kevin P. Fleming Sent: Tuesday, January 24, 2012 4:54 PM To: ietf@ietf.org Subject: Re: FYI : Canada's CRTC mandates all IP Interconnection for voice. On 01/24/2012 02:28 PM, Richard Shockey wrote: > /In this decision, the Commission decides that it is in the public > interest to establish a set of principles to facilitate IP voice network > interconnections between network operators while allowing market forces > to shape the details of the arrangements. Specifically, in areas where a > carrier provides IP voice interconnection to an affiliate, a division of > its operations, or an unrelated service provider, the carrier must > negotiate a similar arrangement with any other carrier that requests > such an arrangement. Within six months of a formal request, an > arrangement is to be concluded./ > > http://www.crtc.gc.ca/eng/com100/2012/r120119.htm I think that your subject is a bit misleading. This decision does not 'outlaw' non-IP interconnection, nor does it obligate a carrier that is not currently IP-interconnected (if such a carrier exists) to become so connected. It only levels the playing field and ensures that all IP-interconnected carriers make IP interconnection available to any other carrier that is interested in it, not just the 'chosen few'. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From kpfleming@digium.com Tue Jan 24 14:30:11 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F7C11E809A for ; Tue, 24 Jan 2012 14:30:11 -0800 (PST) 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=0.081, 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 Xa8hXbNJRAao for ; Tue, 24 Jan 2012 14:30:10 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id CA30711E8097 for ; Tue, 24 Jan 2012 14:30:10 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RposU-0003kX-7B; Tue, 24 Jan 2012 16:30:10 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 3B6B5D8005; Tue, 24 Jan 2012 16:30:10 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkBgId4QRyCu; Tue, 24 Jan 2012 16:30:09 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id E16E3D8004; Tue, 24 Jan 2012 16:30:09 -0600 (CST) Message-ID: <4F1F30F1.50309@digium.com> Date: Tue, 24 Jan 2012 16:30:09 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Richard Shockey Subject: Re: FYI : Canada's CRTC mandates all IP Interconnection for voice. References: <00fc01ccdad6$bf28f250$3d7ad6f0$@us> <4F1F286A.1020101@digium.com> <015c01ccdae7$63ea45e0$2bbed1a0$@us> In-Reply-To: <015c01ccdae7$63ea45e0$2bbed1a0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 22:30:11 -0000 On 01/24/2012 04:27 PM, Richard Shockey wrote: > I didn't suggest that. It's clear in the Canadian Order that if you provide > SIP interconnection to anyone you have to make it available to everyone. Right, but 'mandates all IP interconnection for voice' certainly seems (to me) to imply that non-IP-interconnection for voice would no longer be allowed. It wasn't your intent to make that claim, but you know how message subjects get taken out of context :) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From mnot@mnot.net Tue Jan 24 15:18:47 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9431C21F84DA; Tue, 24 Jan 2012 15:18:47 -0800 (PST) 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=[AWL=-4.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 StlGBR0dQ3Th; Tue, 24 Jan 2012 15:18:46 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id D2BA021F84D7; Tue, 24 Jan 2012 15:18:46 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.240.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1165F22E25C; Tue, 24 Jan 2012 18:18:39 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard From: Mark Nottingham Date: Wed, 25 Jan 2012 10:18:36 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <4D97B96E-4186-4B63-A254-013D803FD459@mnot.net> References: <4F1D847A.6060404@gmx.de> To: IETF Discussion X-Mailer: Apple Mail (2.1251.1) Cc: OAuth WG X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 23:18:47 -0000 My comments were made in: = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03805.html Most of them (excepting the nits) haven't been addressed in the drafts. Regards, Begin forwarded message: > Subject: [OAUTH-WG] Last Call: = (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed = Standard > Date: Mon, 23 Jan 2012 07:46:43 -0800 > From: The IESG > Reply-To: ietf@ietf.org > To: IETF-Announce > CC: oauth@ietf.org >=20 >=20 > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This specification describes how to use bearer tokens in HTTP > requests to access OAuth 2.0 protected resources. Any party in > possession of a bearer token (a "bearer") can use it to get access = to > the associated resources (without demonstrating possession of a > cryptographic key). To prevent misuse, bearer tokens need to be > protected from disclosure in storage and in transport. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Tue Jan 24 15:24:06 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D966B11E80A0 for ; Tue, 24 Jan 2012 15:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.441 X-Spam-Level: X-Spam-Status: No, score=-103.441 tagged_above=-999 required=5 tests=[AWL=-0.842, 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 5JVD3jMxf6X6 for ; Tue, 24 Jan 2012 15:24:06 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B875511E809B for ; Tue, 24 Jan 2012 15:24:05 -0800 (PST) Received: (qmail invoked by alias); 24 Jan 2012 23:24:04 -0000 Received: from p5DCC2B6A.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.43.106] by mail.gmx.net (mp028) with SMTP; 25 Jan 2012 00:24:04 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+XfokYg2GXmtZex/QIvMdvr6dE14RR6CtUtd/Hzx /ySMTdF+SONJ+n Message-ID: <4F1F3D84.1030300@gmx.de> Date: Wed, 25 Jan 2012 00:23:48 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> In-Reply-To: <4F1D8391.3080009@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: The IESG , oauth@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 23:24:07 -0000 On 2012-01-23 16:58, Julian Reschke wrote: > On 2012-01-23 16:46, The IESG wrote: >> >> The IESG has received a request from the Web Authorization Protocol WG >> (oauth) to consider the following document: >> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' >> as a Proposed Standard >> ... > > Please see my comments in > > which I think have not been addressed. > ... In an off-list conversation I heard that what I said before may not be as clear as it could be. So... 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme. 2) In the IANA considerations, it references the registration procedure defined in (now -18, but that doesn't matter here). 3) That document recommends in : o The parsing of challenges and credentials is defined by this specification, and cannot be modified by new authentication schemes. When the auth-param syntax is used, all parameters ought to support both token and quoted-string syntax, and syntactical constraints ought to be defined on the field value after parsing (i.e., quoted-string processing). This is necessary so that recipients can use a generic parser that applies to all authentication schemes. 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has been mentioned that it might not have ignored it if it had UPPERCASE requirements, but in HTTPbis we try to restrict BCP14 keywords to the actual protocol, not on recommendations on other specs. 5) The registration requirement for a new scheme is "IETF review", which RFC 5226 defines in as: IETF Review - (Formerly called "IETF Consensus" in [IANA-CONSIDERATIONS]) New values are assigned only through RFCs that have been shepherded through the IESG as AD- Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The intention is that the document and proposed assignment will be reviewed by the IESG and appropriate IETF WGs (or experts, if suitable working groups no longer exist) to ensure that the proposed assignment will not negatively impact interoperability or otherwise extend IETF protocols in an inappropriate or damaging manner. In this case the WG exists (it's HTTPbis), and the OAuth got two reviews from HTTPbis pointing out the problem -- from Mark Nottingham, the WG chair, and myself, one of the authors. And yes, I believe the way OAuth defines the syntax *will* impact interoperability. Also, I haven't seen any explanation why OAuth can not follow the recommendation from HTTPbis. Hope this clarifies things, Julian From mnot@mnot.net Tue Jan 24 15:36:46 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9E021F84FC; Tue, 24 Jan 2012 15:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.266 X-Spam-Level: X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=-2.667, 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 chVduA0TifiU; Tue, 24 Jan 2012 15:36:45 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 70EA321F84EA; Tue, 24 Jan 2012 15:36:32 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.240.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BC94922E1EB; Tue, 24 Jan 2012 18:36:30 -0500 (EST) Subject: Re: secdir review of draft-nottingham-http-new-status-03 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Wed, 25 Jan 2012 10:36:27 +1100 Content-Transfer-Encoding: 7bit Message-Id: <004F97D3-E825-4BD5-A761-1F047AAFB7AE@mnot.net> References: To: Stephen Hanna X-Mailer: Apple Mail (2.1251.1) Cc: "draft-nottingham-http-new-status@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 23:36:46 -0000 On 14/01/2012, at 6:59 AM, Stephen Hanna wrote: > I do have a question about the issues raised in Appendix B. > These are all legitimate issues. However, it seems to me > that having status code 511 should help with these. A > browser or non-browser application could recognize status > code 511 as an indication that a captive portal is in use > and avoid capturing favicons, looking for P3P files, and > doing other things that should wait until after the captive > portal is blocking access. When the original website stops > returning 511, such activities could resume. I may be wrong > in suggesting these ideas but if not it would be good to > note them here. I've added a note linking the issues to 511 more explicitly. Thanks, -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Tue Jan 24 15:36:49 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F1A11E80A0; Tue, 24 Jan 2012 15:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.885 X-Spam-Level: X-Spam-Status: No, score=-104.885 tagged_above=-999 required=5 tests=[AWL=-2.286, 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 SmOL45xjf34N; Tue, 24 Jan 2012 15:36:49 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id DF17911E809A; Tue, 24 Jan 2012 15:36:48 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.240.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E2B2322E257; Tue, 24 Jan 2012 18:36:46 -0500 (EST) Subject: Re: secdir review of draft-nottingham-http-new-status-03 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: Date: Wed, 25 Jan 2012 10:36:45 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F109383.1090505@gmx.de> To: Stephen Hanna X-Mailer: Apple Mail (2.1251.1) Cc: Julian Reschke , "draft-nottingham-http-new-status@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 23:36:50 -0000 Sorry for the delay in responding; just back from holiday. On 14/01/2012, at 8:26 AM, Stephen Hanna wrote: > Julian, >=20 > I'm sure that in your view one sentence is adequate to explain > all the security implications of each status code. However, > you may want to consider that some readers may not have quite > the same deep grasp of the matter that you do. Therefore, > I think it would be wise to provide more explanation. Here's an > example for section 7.2 on status code 429 (Too Many Requests): >=20 > Section 7.2 429 Too Many Requests >=20 > While status code 429 can be helpful in figuring out why a > server is not responding to requests, it can also be harmful. > When a server is under attack or simply receiving a very > large number of requests from a single party, responding > to each of these requests with a 429 status code will consume > resources that could be better used in other ways. Therefore, > a server in such circumstances may choose to send a 429 status > code only the first time a client exceeds its limit and > ignore subsequent requests from this client until its limit > is no longer exceeded. Other approaches may also be employed. >=20 > As you can see, I described security problems that could occur > with this status code and explained how those problems can be > avoided or mitigated. While it's true that these problems > could occur when a more generic status code is used to handle > the case of "too many requests", that does not mean that they > are not relevant to this document. On the contrary, the fact > that this document is providing more detailed status codes > gives us the opportunity and one can argue the obligation to > provide more detailed security analysis relevant to these more > detailed status codes. I'm really not sure I agree; the original text is: Servers are not required to use the 429 status code; when limiting resource usage, it may be more appropriate to just drop connections, or take other steps. If someone implementing a server doesn't understand that, I don't know = that using more words really helps; it does, however, make it harder to = find the words in the spec that *will* help. -- Mark Nottingham http://www.mnot.net/ From Michael.Jones@microsoft.com Tue Jan 24 15:43:51 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A3311E809D; Tue, 24 Jan 2012 15:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.803 X-Spam-Level: X-Spam-Status: No, score=-3.803 tagged_above=-999 required=5 tests=[AWL=-0.204, 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 xRn8S77AzaBC; Tue, 24 Jan 2012 15:43:50 -0800 (PST) Received: from AM1EHSOBE002.bigfish.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 3F17E11E809A; Tue, 24 Jan 2012 15:43:50 -0800 (PST) Received: from mail106-am1-R.bigfish.com (10.3.201.253) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 24 Jan 2012 23:43:49 +0000 Received: from mail106-am1 (localhost [127.0.0.1]) by mail106-am1-R.bigfish.com (Postfix) with ESMTP id 3E03C260170; Tue, 24 Jan 2012 23:43:49 +0000 (UTC) X-SpamScore: -29 X-BigFish: VS-29(zz9371I542M1432N9a6kzz1202hzz8275ch1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail106-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail106-am1 (localhost.localdomain [127.0.0.1]) by mail106-am1 (MessageSwitch) id 132744862714790_3183; Tue, 24 Jan 2012 23:43:47 +0000 (UTC) Received: from AM1EHSMHS005.bigfish.com (unknown [10.3.201.254]) by mail106-am1.bigfish.com (Postfix) with ESMTP id F3533180045; Tue, 24 Jan 2012 23:43:46 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS005.bigfish.com (10.3.207.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 24 Jan 2012 23:43:46 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0247.005; Tue, 24 Jan 2012 15:43:29 -0800 From: Mike Jones To: Mark Nottingham , IETF Discussion Subject: RE: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: Acza8M46CiZXQaFIS8+eLGD1eeXM3QAARP1w Date: Tue, 24 Jan 2012 23:43:29 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366380009@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: OAuth WG X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 23:43:51 -0000 (Resending now that I'm a member of the ietf@ietf.org list so that my respo= nse will be sent.) -----Original Message----- From: Mike Jones=20 Sent: Tuesday, January 24, 2012 3:35 PM To: 'Mark Nottingham'; IETF Discussion Cc: OAuth WG Subject: RE: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard For those on the ietf@ietf.org list, you can find my responses as editor to= Mark's useful apps area feedback at these locations: http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html http://www.ietf.org/mail-archive/web/oauth/current/msg08075.html As editor, I attempted to apply all of Mark's recommendations, other than t= hose that were contrary to working group consensus positions that had alrea= dy been established via discussions on the working group mailing list. Whe= re his recommendations were not adopted, reasons were given in my responses= on behalf of the working group cited above. Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ark Nottingham Sent: Tuesday, January 24, 2012 3:19 PM To: IETF Discussion Cc: OAuth WG Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard My comments were made in: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03805.html Most of them (excepting the nits) haven't been addressed in the drafts. Regards, Begin forwarded message: > Subject: [OAUTH-WG] Last Call: (The O= Auth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard > Date: Mon, 23 Jan 2012 07:46:43 -0800 > From: The IESG > Reply-To: ietf@ietf.org > To: IETF-Announce > CC: oauth@ietf.org >=20 >=20 > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits=20 > final comments on this action. Please send substantive comments to the=20 > ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may=20 > be sent to iesg@ietf.org instead. In either case, please retain the=20 > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This specification describes how to use bearer tokens in HTTP > requests to access OAuth 2.0 protected resources. Any party in > possession of a bearer token (a "bearer") can use it to get access to > the associated resources (without demonstrating possession of a > cryptographic key). To prevent misuse, bearer tokens need to be > protected from disclosure in storage and in transport. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 -- Mark Nottingham http://www.mnot.net/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Tue Jan 24 15:45:22 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A1F11E809D; Tue, 24 Jan 2012 15:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.795 X-Spam-Level: X-Spam-Status: No, score=-3.795 tagged_above=-999 required=5 tests=[AWL=-0.196, 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 xIOo9PnfX4E8; Tue, 24 Jan 2012 15:45:21 -0800 (PST) Received: from DB3EHSOBE003.bigfish.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7F311E80C0; Tue, 24 Jan 2012 15:45:21 -0800 (PST) Received: from mail18-db3-R.bigfish.com (10.3.81.242) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 24 Jan 2012 23:45:18 +0000 Received: from mail18-db3 (localhost [127.0.0.1]) by mail18-db3-R.bigfish.com (Postfix) with ESMTP id D710A4202EE; Tue, 24 Jan 2012 23:45:18 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail18-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail18-db3 (localhost.localdomain [127.0.0.1]) by mail18-db3 (MessageSwitch) id 1327448716651305_28226; Tue, 24 Jan 2012 23:45:16 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.248]) by mail18-db3.bigfish.com (Postfix) with ESMTP id 900534C004A; Tue, 24 Jan 2012 23:45:16 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 24 Jan 2012 23:45:15 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0247.005; Tue, 24 Jan 2012 15:45:13 -0800 From: Mike Jones To: Mike Jones , "ietf@ietf.org" , "iesg@ietf.org" Subject: RE: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: AQHM2ejbNGzL+7cc6EiU4F3vKE4/fpYaMdvwgAAYAzCAAeZz0A== Date: Tue, 24 Jan 2012 23:45:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366380029@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> <4E1F6AAD24975D4BA5B168042967394366375F80@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436637843C@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436637843C@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 23:45:22 -0000 (Resending now that I'm a member of the ietf@ietf.org list so that my note = will appear there.) -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Monday, January 23, 2012 9:24 AM To: ietf@ietf.org Cc: Julian Reschke; The IESG; oauth@ietf.org; IETF-Announce Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard As editor of the Oauth Bearer spec, I believe that these comments have been= well understood and considered by the working group. I do understand that= the working group's consensus position is different than Julian's. See th= ese notes documenting that this is the case: https://www.ietf.org/mail-archive/web/oauth/current/msg08113.html https://www.ietf.org/mail-archive/web/oauth/current/msg08116.html https://www.ietf.org/mail-archive/web/oauth/current/msg08121.html Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ulian Reschke Sent: Monday, January 23, 2012 7:58 AM To: ietf@ietf.org Cc: The IESG; oauth@ietf.org; IETF-Announce Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard On 2012-01-23 16:46, The IESG wrote: > > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard ... Please see my comments in which I think have not been addressed. Best regards, Julian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Tue Jan 24 16:03:18 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D00821F85D7; Tue, 24 Jan 2012 16:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[AWL=-0.189, 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 TQWOi+AmReoS; Tue, 24 Jan 2012 16:03:17 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id C1ED121F8596; Tue, 24 Jan 2012 16:03:17 -0800 (PST) Received: from mail179-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Wed, 25 Jan 2012 00:03:17 +0000 Received: from mail179-ch1 (localhost [127.0.0.1]) by mail179-ch1-R.bigfish.com (Postfix) with ESMTP id 2F4FC260194; Wed, 25 Jan 2012 00:03:17 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-FB-SS: 13, Received-SPF: pass (mail179-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail179-ch1 (localhost.localdomain [127.0.0.1]) by mail179-ch1 (MessageSwitch) id 13274497977629_28206; Wed, 25 Jan 2012 00:03:17 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail179-ch1.bigfish.com (Postfix) with ESMTP id F16F7180046; Wed, 25 Jan 2012 00:03:16 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 25 Jan 2012 00:03:16 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0247.005; Tue, 24 Jan 2012 16:03:15 -0800 From: Mike Jones To: "ietf@ietf.org" Subject: RE: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: Acza9LphO1mPc9gpRTC5FQtXgyb9wg== Date: Wed, 25 Jan 2012 00:03:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366380094@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: The IESG , "oauth@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 00:03:18 -0000 Per the discussion at http://www.ietf.org/mail-archive/web/oauth/current/ms= g08040.html, the working group's rationale for supporting quoted-string but= not token syntax for these parameters, and for requiring that backslash ('= \') quoting not be used when producing them is as follows: "Once again, the current text reflects a consensus decision of the working = group. It was viewed that requiring support for multiple ways of doing the= same thing unnecessarily complicated implementations without any compensat= ing benefit; better to support one syntax for each semantic operation and r= equire all implementations to use it." Despite Julian's remarks below, the syntax in the Bearer spec *is* compatib= le with standard parameter parsers, and so no interoperability problems are= created by restricting the parameter syntax to a subset of the syntax allo= wed by HTTPbis. No non-standard code is needed to use parameters in the ma= nner described in the Bearer spec. The current text is the result of thorough and informed discussion among th= e working group, and reflects the best consensus available as I understand = it in my role as editor, attempting to accurately represent the working gro= up's decisions and rationale. Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J= ulian Reschke Sent: Tuesday, January 24, 2012 3:24 PM To: ietf@ietf.org Cc: The IESG; oauth@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard On 2012-01-23 16:58, Julian Reschke wrote: > On 2012-01-23 16:46, The IESG wrote: >> >> The IESG has received a request from the Web Authorization Protocol=20 >> WG >> (oauth) to consider the following document: >> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' >> as a Proposed Standard ... > > Please see my comments in > > which I think have not been addressed. > ... In an off-list conversation I heard that what I said before may not be as c= lear as it could be. So... 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme. 2) In the IANA considerations, it references the registration procedure def= ined in (now -18, but that doesn't matter here). 3) That document recommends in : o The parsing of challenges and credentials is defined by this specification, and cannot be modified by new authentication schemes. When the auth-param syntax is used, all parameters ought to support both token and quoted-string syntax, and syntactical constraints ought to be defined on the field value after parsing (i.e., quoted-string processing). This is necessary so that recipients can use a generic parser that applies to all authentication schemes. 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has been m= entioned that it might not have ignored it if it had UPPERCASE requirements= , but in HTTPbis we try to restrict BCP14 keywords to the actual protocol, = not on recommendations on other specs. 5) The registration requirement for a new scheme is "IETF review", which RF= C 5226 defines in as: IETF Review - (Formerly called "IETF Consensus" in [IANA-CONSIDERATIONS]) New values are assigned only through RFCs that have been shepherded through the IESG as AD- Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The intention is that the document and proposed assignment will be reviewed by the IESG and appropriate IETF WGs (or experts, if suitable working groups no longer exist) to ensure that the proposed assignment will not negatively impact interoperability or otherwise extend IETF protocols in an inappropriate or damaging manner. In this case the WG exists (it's HTTPbis), and the OAuth got two reviews fr= om HTTPbis pointing out the problem -- from Mark Nottingham, the WG chair,= and myself, one of the authors. And yes, I believe the way OAuth defines the syntax *will* impact interoper= ability. Also, I haven't seen any explanation why OAuth can not follow the recommend= ation from HTTPbis. Hope this clarifies things, Julian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From julian.reschke@gmx.de Tue Jan 24 16:19:28 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6FE21F862F for ; Tue, 24 Jan 2012 16:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.458 X-Spam-Level: X-Spam-Status: No, score=-103.458 tagged_above=-999 required=5 tests=[AWL=-0.859, 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 LSPLQpewB16E for ; Tue, 24 Jan 2012 16:19:27 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 90ACF21F861C for ; Tue, 24 Jan 2012 16:19:26 -0800 (PST) Received: (qmail invoked by alias); 25 Jan 2012 00:19:25 -0000 Received: from p5DCC2B6A.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.43.106] by mail.gmx.net (mp027) with SMTP; 25 Jan 2012 01:19:25 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+8EXdxkGm8eWzdgG72aTFQQKnIszhaoyp6NWIqJE O/qELnxkCapN9G Message-ID: <4F1F4A7B.9090408@gmx.de> Date: Wed, 25 Jan 2012 01:19:07 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Mike Jones Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard References: <4E1F6AAD24975D4BA5B168042967394366380094@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366380094@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" , "ietf@ietf.org" , The IESG X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 00:19:28 -0000 On 2012-01-25 01:03, Mike Jones wrote: > Per the discussion at http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html, the working group's rationale for supporting quoted-string but not token syntax for these parameters, and for requiring that backslash ('\') quoting not be used when producing them is as follows: > > "Once again, the current text reflects a consensus decision of the working group. It was viewed that requiring support for multiple ways of doing the same thing unnecessarily complicated implementations without any compensating benefit; better to support one syntax for each semantic operation and require all implementations to use it." Mike, you continue to ignore that WWW-Authenticate needs to be processed by generic parsers, as a single instance can contain challenges for different schemes. If you disagree with the text below: o The parsing of challenges and credentials is defined by this specification, and cannot be modified by new authentication schemes. When the auth-param syntax is used, all parameters ought to support both token and quoted-string syntax, and syntactical constraints ought to be defined on the field value after parsing (i.e., quoted-string processing). This is necessary so that recipients can use a generic parser that applies to all authentication schemes. (which is from the text defining the registry you are using), then please come over to the HTTPbis WG and ask for a change. It's work-in-progress. > Despite Julian's remarks below, the syntax in the Bearer spec *is* compatible with standard parameter parsers, and so no interoperability problems are created by restricting the parameter syntax to a subset of the syntax allowed by HTTPbis. No non-standard code is needed to use parameters in the manner described in the Bearer spec. That is not true. Using standard components will cause recipients to accept invalid field instances, which *is* an interoperability problem. This has happened before: RFC 2617 states that the realm parameter needs to be quoted, but we see that all browsers accept the token form as well (). That's not a surprise because it's the natural thing to do with a generic parser. Please don't add to the mess. In particular when there really is no reason to do so. All I heard from you is: "we prefer it that way". I'm sorry, but that's not sufficient. > ... Best regards, Julian From mrex@sap.com Tue Jan 24 16:29:00 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D9321F8541; Tue, 24 Jan 2012 16:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.142 X-Spam-Level: X-Spam-Status: No, score=-10.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 B-3N9UoA9xT9; Tue, 24 Jan 2012 16:29:00 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 24CAD21F8540; Tue, 24 Jan 2012 16:28:59 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0P0Swgv023555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jan 2012 01:28:58 +0100 (MET) From: Martin Rex Message-Id: <201201250028.q0P0SwiS000165@fs4113.wdf.sap.corp> Subject: Re: [OAUTH-WG] Last Call: (The To: Michael.Jones@microsoft.com (Mike Jones) Date: Wed, 25 Jan 2012 01:28:58 +0100 (MET) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366380094@TK5EX14MBXC284.redmond.corp.microsoft.com> from "Mike Jones" at Jan 25, 12 00:03:15 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: oauth@ietf.org, ietf@ietf.org, iesg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 00:29:01 -0000 Mike Jones wrote: > > Per the discussion at > http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html, > the working group's rationale for supporting quoted-string but > not token syntax for these parameters, and for requiring that > backslash ('\') quoting not be used when producing them [...] I'm slightly confused... Instead of inappropriately re-specifying the WWW-Authenticate:, how about referencing the original specification an rules, and then add your desired requirements for *creation* of the contents on top of that, so that oauth-bearer can permit recipients to reject stuff that doesn't fit the additional "send-requirements" when processing the request. I would assume that pretty much all authentication schemes will effectively require subsetting of what can be conveyed to what they can parse, and further subset this to what they can successfully verify, and reject everything else -- without having to rewrite the WWW-Authenticate syntax. -Martin From Michael.Jones@microsoft.com Tue Jan 24 16:52:30 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F3121F847B; Tue, 24 Jan 2012 16:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.781 X-Spam-Level: X-Spam-Status: No, score=-3.781 tagged_above=-999 required=5 tests=[AWL=-0.182, 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 TVV73AkIrWQ3; Tue, 24 Jan 2012 16:52:30 -0800 (PST) Received: from DB3EHSOBE005.bigfish.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9794521F8478; Tue, 24 Jan 2012 16:52:29 -0800 (PST) Received: from mail72-db3-R.bigfish.com (10.3.81.242) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 25 Jan 2012 00:52:28 +0000 Received: from mail72-db3 (localhost [127.0.0.1]) by mail72-db3-R.bigfish.com (Postfix) with ESMTP id 78C4922024D; Wed, 25 Jan 2012 00:52:28 +0000 (UTC) X-SpamScore: -40 X-BigFish: VS-40(zz9371I148cM542M1432N98dKzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail72-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail72-db3 (localhost.localdomain [127.0.0.1]) by mail72-db3 (MessageSwitch) id 1327452746637940_8243; Wed, 25 Jan 2012 00:52:26 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.243]) by mail72-db3.bigfish.com (Postfix) with ESMTP id 8E1DF420048; Wed, 25 Jan 2012 00:52:26 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 25 Jan 2012 00:52:26 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0247.005; Tue, 24 Jan 2012 16:52:25 -0800 From: Mike Jones To: "mrex@sap.com" Subject: RE: [OAUTH-WG] Last Call: (The Thread-Topic: [OAUTH-WG] Last Call: (The Thread-Index: AQHM2vhYmAz+4G7gQ0GW7eeS0JEwvZYcPXxg Date: Wed, 25 Jan 2012 00:52:24 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943663801ED@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366380094@TK5EX14MBXC284.redmond.corp.microsoft.com> from "Mike Jones" at Jan 25, 12 00:03:15 am <201201250028.q0P0SwiS000165@fs4113.wdf.sap.corp> In-Reply-To: <201201250028.q0P0SwiS000165@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" , "ietf@ietf.org" , "iesg@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 00:52:31 -0000 Thanks for asking, Martin. That's effectively what the spec does already. = It restricts the input values of these parameters to be quoted strings con= taining no backslashes. As long as that syntax restriction remains in place, it wouldn't actually m= atter whether the BNF for "scope", "error", "error_description", and "error= _uri" continues to be defined as "quoted-string", is defined as "token / qu= oted-string", per HTTPbis, or defined by referencing the HTTPbis "auth-para= m" definition and containing no parameter-specific BNF declarations. The m= eaning of the spec would remain the same. It's written the way it is, at present, because it would seem to be clearer= to implementers what the restrictions are by using the "quoted-string" BNF= production, rather than by imposing the restriction only in prose. But if= deleting the BNF definitions and leaving the syntax restrictions in the pr= ose would resolve this issue for people, I'm pretty sure the working group = would be fine with that, as it would be a non-normative change. Best wishes, -- Mike -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Tuesday, January 24, 2012 4:29 PM To: Mike Jones Cc: ietf@ietf.org; iesg@ietf.org; oauth@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The Mike Jones wrote: >=20 > Per the discussion at > http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html, > the working group's rationale for supporting quoted-string but not=20 > token syntax for these parameters, and for requiring that backslash=20 > ('\') quoting not be used when producing them [...] I'm slightly confused... Instead of inappropriately re-specifying the WWW-Authenticate:, how about r= eferencing the original specification an rules, and then add your desired r= equirements for *creation* of the contents on top of that, so that oauth-be= arer can permit recipients to reject stuff that doesn't fit the additional = "send-requirements" when processing the request. I would assume that pretty much all authentication schemes will effectively= require subsetting of what can be conveyed to what they can parse, and fur= ther subset this to what they can successfully verify, and reject everythin= g else -- without having to rewrite the WWW-Authenticate syntax. -Martin From Michael.Jones@microsoft.com Tue Jan 24 17:03:52 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077C221F8603; Tue, 24 Jan 2012 17:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.775 X-Spam-Level: X-Spam-Status: No, score=-3.775 tagged_above=-999 required=5 tests=[AWL=-0.176, 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 y4pzhbQXw20Y; Tue, 24 Jan 2012 17:03:45 -0800 (PST) Received: from DB3EHSOBE002.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 49B5F21F85EF; Tue, 24 Jan 2012 17:03:38 -0800 (PST) Received: from mail64-db3-R.bigfish.com (10.3.81.246) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 25 Jan 2012 01:03:37 +0000 Received: from mail64-db3 (localhost [127.0.0.1]) by mail64-db3-R.bigfish.com (Postfix) with ESMTP id 19587202D6; Wed, 25 Jan 2012 01:03:37 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail64-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail64-db3 (localhost.localdomain [127.0.0.1]) by mail64-db3 (MessageSwitch) id 1327453415813637_4689; Wed, 25 Jan 2012 01:03:35 +0000 (UTC) Received: from DB3EHSMHS019.bigfish.com (unknown [10.3.81.253]) by mail64-db3.bigfish.com (Postfix) with ESMTP id C29874C0046; Wed, 25 Jan 2012 01:03:35 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS019.bigfish.com (10.3.87.119) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 25 Jan 2012 01:03:35 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0247.005; Tue, 24 Jan 2012 17:03:33 -0800 From: Mike Jones To: Julian Reschke Subject: RE: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: Acza9LphO1mPc9gpRTC5FQtXgyb9wgARUdSAABClghA= Date: Wed, 25 Jan 2012 01:03:32 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436638022F@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B168042967394366380094@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F1F4A7B.9090408@gmx.de> In-Reply-To: <4F1F4A7B.9090408@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "oauth@ietf.org" , "ietf@ietf.org" , The IESG X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 01:03:52 -0000 Typically "interoperability" is only meaningfully defined over legal inputs= to a protocol. There is no expectation of interoperability when values ou= tside those specified as being legal by a protocol are used. The case you cite below of implementations that "accept invalid field insta= nces" is then, almost by definition, not an interoperability problem, as wh= at you're concerned about is the behavior of implementations when sent ille= gal inputs - not the behavior of implementations when producing and consumi= ng legal protocol values. I believe that that's the key distinction that is causing you to look at th= is issue differently than much of the working group. Cheers, -- Mike -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Tuesday, January 24, 2012 4:19 PM To: Mike Jones Cc: ietf@ietf.org; The IESG; oauth@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard On 2012-01-25 01:03, Mike Jones wrote: > Per the discussion at http://www.ietf.org/mail-archive/web/oauth/current/= msg08040.html, the working group's rationale for supporting quoted-string b= ut not token syntax for these parameters, and for requiring that backslash = ('\') quoting not be used when producing them is as follows: > > "Once again, the current text reflects a consensus decision of the workin= g group. It was viewed that requiring support for multiple ways of doing t= he same thing unnecessarily complicated implementations without any compens= ating benefit; better to support one syntax for each semantic operation and= require all implementations to use it." Mike, you continue to ignore that WWW-Authenticate needs to be processed by= generic parsers, as a single instance can contain challenges for different= schemes. If you disagree with the text below: o The parsing of challenges and credentials is defined by this specification, and cannot be modified by new authentication schemes. When the auth-param syntax is used, all parameters ought to support both token and quoted-string syntax, and syntactical constraints ought to be defined on the field value after parsing (i.e., quoted-string processing). This is necessary so that recipients can use a generic parser that applies to all authentication schemes. (which is from the text defining the registry you are using), then please c= ome over to the HTTPbis WG and ask for a change. It's work-in-progress. > Despite Julian's remarks below, the syntax in the Bearer spec *is* compat= ible with standard parameter parsers, and so no interoperability problems a= re created by restricting the parameter syntax to a subset of the syntax al= lowed by HTTPbis. No non-standard code is needed to use parameters in the = manner described in the Bearer spec. That is not true. Using standard components will cause recipients to accept= invalid field instances, which *is* an interoperability problem. This has happened before: RFC 2617 states that the realm parameter needs to= be quoted, but we see that all browsers accept the token form as well (). That's not a surpris= e because it's the natural thing to do with a generic parser. Please don't add to the mess. In particular when there really is no reason = to do so. All I heard from you is: "we prefer it that way". I'm sorry, but = that's not sufficient. > ... Best regards, Julian From derhoermi@gmx.net Tue Jan 24 18:14:12 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA48D11E80A5 for ; Tue, 24 Jan 2012 18:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=-1.533, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] 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 PmjXt6Bve3UX for ; Tue, 24 Jan 2012 18:14:12 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 98C3A11E8086 for ; Tue, 24 Jan 2012 18:14:11 -0800 (PST) Received: (qmail invoked by alias); 25 Jan 2012 02:14:09 -0000 Received: from dslb-094-222-155-127.pools.arcor-ip.net (EHLO HIVE) [94.222.155.127] by mail.gmx.net (mp070) with SMTP; 25 Jan 2012 03:14:09 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/iEsl6xNzirjiOEnuZRUC/6pe5bk7xZFHs3rJfku Gf5xMnIGkgmVu8 From: Bjoern Hoehrmann To: Mike Jones Subject: Re: [OAUTH-WG] Last Call: (The Date: Wed, 25 Jan 2012 03:14:26 +0100 Message-ID: <2rkuh71k7eh4h1ciu15p6b2sss77u6qhtp@hive.bjoern.hoehrmann.de> References: <4E1F6AAD24975D4BA5B168042967394366380094@TK5EX14MBXC284.redmond.corp.microsoft.com> from "Mike Jones" at Jan 25, 12 00:03:15 am <201201250028.q0P0SwiS000165@fs4113.wdf.sap.corp> <4E1F6AAD24975D4BA5B1680429673943663801ED@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943663801ED@TK5EX14MBXC284.redmond.corp.microsoft.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" , "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 02:14:13 -0000 * Mike Jones wrote: >Thanks for asking, Martin. That's effectively what the spec does >already. It restricts the input values of these parameters to be quoted >strings containing no backslashes. Most XML parsers do not tell you, and most XML generators do not allow you to control, the difference between and . You could make a specification that says the value of the y attribute on the x element must not be z, but it stops there. The difference be- tween the two XML elements is in the lexical space, not in the value space, the attribute value in both cases is "z", it's just encoded in a different form. Try writing a C function `int example(int i)` that returns `1` when it is called like `example(00)` but returns `0` for `example(0)`. Without some hack you can't do that because the C specification defines that it does not matter whether you write `0` or `00` for an int. Same problem, just as the C specification does not give you an interface to tell the two inputs apart, the HTTP specification does not give you an interface that allows you to tell `x` and `"x"` apart in this particular case. If the draft said "When using WWW-Authenticate: Bearer ... then the header name must be written `wWw-authenTICate`, same problem. HTTP says case does not matter, and if another specification says "Yes, it does" then it is overriding the underlying specification, to some degree anyway. This is not always wrong, you might have coding guidelines for example that tell you to write `example( 0 )` instead of `example(0)` and that may work well with limited scope, but with coding guidelines people are typically aware that they impose limits on formally equivalent things, along with the understanding that if someone ignored the restriction the code would work just as well, but that does not seem to be quite the case here. If I make another scheme, WWW-Authenticate: Example, and say all the parameters must be tokens, not quoted strings, and the tokens must not contain "q" characters, but they are case-insensitive so you can use "Q" to the same effect, would that be just as well? If you want to keep the distinction, you should offer an argument why this is something individual schemes should regulate (since having the same rules for all schemes is much simpler). -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From d3e3e3@gmail.com Tue Jan 24 19:47:08 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A4211E80AE for ; Tue, 24 Jan 2012 19:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.325 X-Spam-Level: X-Spam-Status: No, score=-104.325 tagged_above=-999 required=5 tests=[AWL=-0.726, BAYES_00=-2.599, 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 4t7mmNrWAC-Y for ; Tue, 24 Jan 2012 19:47:07 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4737A11E80A5 for ; Tue, 24 Jan 2012 19:47:07 -0800 (PST) Received: by lahl5 with SMTP id l5so905710lah.31 for ; Tue, 24 Jan 2012 19:47:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=tCjFXS3d8cxzx+M6jTHG2Ln99cjtNpM25caRiNBMCIs=; b=OwHg253FCtOcNKdl1EySRvxnn7ZFndDlCN1pmOf6cGg5KKt5OWipyAh78FgkNu2a1V dsCKTCiiGm1ms15OpnUNUGa1bUOWgMlq6p7K5lFwr1MpWVLIRjOOojnuaiYL+RzVs0e6 eTgj2Io7tVTuIn8B9LM6EX5/hcdShO6GY+Ylk= Received: by 10.112.44.101 with SMTP id d5mr3917766lbm.40.1327463226250; Tue, 24 Jan 2012 19:47:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.100.131 with HTTP; Tue, 24 Jan 2012 19:46:45 -0800 (PST) In-Reply-To: <6.2.5.6.2.20120123103439.0a87a228@resistor.net> References: <20120123182317.28636.48689.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120123103439.0a87a228@resistor.net> From: Donald Eastlake Date: Tue, 24 Jan 2012 22:46:45 -0500 Message-ID: Subject: Re: Last Call: (xNAME RCODE and Status Bits Clarification) to Proposed Standard To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 03:47:08 -0000 Hi, On Mon, Jan 23, 2012 at 2:04 PM, SM wrote: > At 10:23 23-01-2012, The IESG wrote: >> >> The IESG has received a request from the DNS Extensions WG (dnsext) to >> consider the following document: >> - 'xNAME RCODE and Status Bits Clarification' >> =A0 as a Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may b= e > > > From the Introduction Section: > > > =A0"This document clarifies, in the case of such redirected queries, > =A0 how the RCODE and status bits correspond to the initial query > =A0 cycle (where the (first) xNAME was detected) and subsequent or > =A0 final query cycles." > > From Section 2.1: > > =A0"[RFC1035] states that the AA bit is to be set based on whether the > =A0 server providing the answer with the first owner name in the answer > =A0 section is authoritative. =A0This specification of the AA bit has not > =A0 been changed. =A0This specification of the AA bit has not been change= d." Actually, the last sentence above is not duplicated in the draft. > And Section 2.2: > > =A0"[RFC4035] unambiguously states that the AD bit is to be set in a DNS > =A0 response header only if the DNSSEC enabled server believes all RRs in > =A0 the answer and authority sections of that response to be authentic. > =A0 This specification of the AD bit has not been changed." > > It is not clear to me what is being clarified about the status bits. This draft brings together the aspects of the AA, AD, and RCODE bits related to xNAME RR query cycles and expresses them clearly and succinctly. As such it has been approved by the DNSEXT WG. I do not believe that text has to make a change to be a clarification. > In Section 3: > > =A0 =A0"The RCODE in the ultimate DNS response > =A0 =A0 MUST BE set based on the final query cycle leading to that > =A0 =A0 response." > > Shouldn't the "BE" be lowercased? Yes, thanks for pointing this out. "BE" should probably be lowercase. > The status of the memo suggests sending comments to > namedroppers@ops.ietf.org. =A0Is that IETF mailing list still being used = by > DNSEXT? That was the mailing list at the time of the -00 personal draft version. Sorry I missed updating the mailing list reference somewhere along the way. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street,=A0Milford, MA 01757 USA =A0d3e3e3@gmail.com > Regards, > -sm From mrex@sap.com Tue Jan 24 19:48:57 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C76C21F8444; Tue, 24 Jan 2012 19:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.144 X-Spam-Level: X-Spam-Status: No, score=-10.144 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 WEHkD5qixb4c; Tue, 24 Jan 2012 19:48:56 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 651A021F8319; Tue, 24 Jan 2012 19:48:56 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0P3mnCp016880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jan 2012 04:48:54 +0100 (MET) From: Martin Rex Message-Id: <201201250348.q0P3mmLt011370@fs4113.wdf.sap.corp> Subject: Re: [OAUTH-WG] Last Call: (The To: derhoermi@gmx.net (Bjoern Hoehrmann) Date: Wed, 25 Jan 2012 04:48:48 +0100 (MET) In-Reply-To: <2rkuh71k7eh4h1ciu15p6b2sss77u6qhtp@hive.bjoern.hoehrmann.de> from "Bjoern Hoehrmann" at Jan 25, 12 03:14:26 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: oauth@ietf.org, ietf@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 03:48:57 -0000 Bjoern Hoehrmann wrote: > > * Mike Jones wrote: > >Thanks for asking, Martin. That's effectively what the spec does > >already. It restricts the input values of these parameters to be quoted > > the HTTP specification does not give you an interface > that allows you to tell `x` and `"x"` apart in this particular case. If > the draft said "When using WWW-Authenticate: Bearer ... then the header > name must be written `wWw-authenTICate`, same problem. HTTP says case > does not matter, and if another specification says "Yes, it does" then > it is overriding the underlying specification, to some degree anyway. Of course, what oaep-bearer could _not_ "define to not exist" (no matter how much anyone (group) might desire this), is those transformations, and their complexity, that are permitted on HTTP that headerfield, e.g. through "middle-boxes", such as client-side HTTP proxies or server-side reverse-proxies between the original creator and the final consumer, as well as permitted side-effects of other application components sharing the same client (like a browser). -Martin From sm@resistor.net Tue Jan 24 22:20:04 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FCD21F85FB for ; Tue, 24 Jan 2012 22:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.602 X-Spam-Level: X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 kGS5eA1xX8QY for ; Tue, 24 Jan 2012 22:20:02 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D18321F847B for ; Tue, 24 Jan 2012 22:20:01 -0800 (PST) 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 q0P6JsnI029175 for ; Tue, 24 Jan 2012 22:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327472399; i=@resistor.net; bh=VmNuQjNWKCCFJz9SPFm2mcSfv+SY9yt/rbsvZD3Dt3Q=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=fyST9CuHaQsPoqfpH7E1bWF6PxMSuawGnikG4x0+2Jz51w1/2EseYPB7TJ18DjBHw mGQ+jsLOYaX/Me9f9Dl0YjQm2YyTR4Wb7wdfRamSZQR7fLtEu4LIhE3HFXsd+SnkYd ESwdcmJRJM8wInaXKhFnmEtAsuxo41RvnruYHzGU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327472399; i=@resistor.net; bh=VmNuQjNWKCCFJz9SPFm2mcSfv+SY9yt/rbsvZD3Dt3Q=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=ElGg/kQAv+6GWJyZlIJNmiMA2D+Ps4BzcKvzt8Yc9TDhn0Mgmvr2s5IBuK+UEX+8X 4JW1VPAFOHfSOIpFuV79P1fnCdlvVJQpFPFxcsqKLPd09GctFhvBXdNcHVOanb7QMn ge7aWGiN1OrwRDkYqwxxuaw3H6oPnNMqRCPPrP44= Message-Id: <6.2.5.6.2.20120124071152.09ad9ab8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 24 Jan 2012 18:43:06 -0800 To: ietf@ietf.org From: SM Subject: Re: Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard In-Reply-To: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 06:20:04 -0000 At 07:46 23-01-2012, The IESG wrote: >The IESG has received a request from the Web Authorization Protocol WG >(oauth) to consider the following document: >- 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may be From Section 2.3: 'When sending the access token in the HTTP request URI, the client adds the access token to the request URI query component as defined by Uniform Resource Identifier (URI) [RFC3986] using the "access_token" parameter.' This draft standardizes the URI query parameter to be used. There isn't any mention of whether it is reserving the parameter. The draft mentions that: 'Because of the security weaknesses associated with the URI method (see Section 4), including the high likelihood that the URL containing the access token will be logged, it SHOULD NOT be used unless it is impossible to transport the access token in the "Authorization" request header field or the HTTP request entity-body.' The security weakness is well-known. It might be good to label Section 2.3 as deprecated. I note that a "platform" using OAuth 2.0 does not mention the above security consideration. As for Section 3, it seems that the text reflects a consensus decision of the working group which is at odds with a recommendation in the specifications from HTTPbis: "As for your assertion that the specs are in conflict, yes, the Bearer spec includes a different decision than a RECOMMENDED clause in the HTTPbis spec (which was added after the Bearer text was already in place). However, it is not violating any MUST clauses in the HTTPbis spec." The thread of the discussion is at http://www.ietf.org/mail-archive/web/oauth/current/msg08051.html The informative reference for RFC 2616 can be removed. Regards, S. Moonesamy From msk@cloudmark.com Tue Jan 24 22:59:47 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C9121F8615 for ; Tue, 24 Jan 2012 22:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 mlLSjbFpjDE5 for ; Tue, 24 Jan 2012 22:59:46 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id C496E21F8671 for ; Tue, 24 Jan 2012 22:59:46 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 24 Jan 2012 22:59:46 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 24 Jan 2012 22:59:46 -0800 From: "Murray S. Kucherawy" To: Donald Eastlake , SM Date: Tue, 24 Jan 2012 22:59:44 -0800 Subject: RE: Last Call: (xNAME RCODE and Status Bits Clarification) to Proposed Standard Thread-Topic: Last Call: (xNAME RCODE and Status Bits Clarification) to Proposed Standard Thread-Index: AczbFAoBzvXzF9ABSNWoPYafnyMS9wAGbT3g Message-ID: References: <20120123182317.28636.48689.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120123103439.0a87a228@resistor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 06:59:47 -0000 > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of D= onald Eastlake > Sent: Tuesday, January 24, 2012 7:47 PM > To: SM > Cc: ietf@ietf.org > Subject: Re: Last Call: (xNAME > RCODE and Status Bits Clarification) to Proposed Standard >=20 > > It is not clear to me what is being clarified about the status bits. >=20 > This draft brings together the aspects of the AA, AD, and RCODE bits > related to xNAME RR query cycles and expresses them clearly and > succinctly. As such it has been approved by the DNSEXT WG. I do not > believe that text has to make a change to be a clarification. I made the same point in my review of this for AppsDir, and it got a simila= r response. In short, I also find the current presentation a bit awkward. To fix it, I= believe Section 2 should be dropped, and the references for the definition= s of AA and AD should be moved to the current Section 4. No details are lo= st, the document becomes simpler, and simpler is better. I appreciate any working group's time spent developing and reviewing someth= ing, but the fact that DNSEXT approved it this way doesn't mean it can't be= improved. -MSK From julian.reschke@gmx.de Wed Jan 25 00:37:20 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B7821F849C for ; Wed, 25 Jan 2012 00:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.436 X-Spam-Level: X-Spam-Status: No, score=-103.436 tagged_above=-999 required=5 tests=[AWL=-0.837, 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 OzDsugtyJqBO for ; Wed, 25 Jan 2012 00:37:19 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id AAE5921F849A for ; Wed, 25 Jan 2012 00:37:18 -0800 (PST) Received: (qmail invoked by alias); 25 Jan 2012 08:37:16 -0000 Received: from p5DCC2B6A.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.43.106] by mail.gmx.net (mp028) with SMTP; 25 Jan 2012 09:37:16 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18yjQMTS20ySdb7+WU0dmS7DOM+2ETFbnxufYgUGt 1zHSufEtVqf1Y5 Message-ID: <4F1FBF3A.4090808@gmx.de> Date: Wed, 25 Jan 2012 09:37:14 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann Subject: Re: [OAUTH-WG] Last Call: (The References: <4E1F6AAD24975D4BA5B168042967394366380094@TK5EX14MBXC284.redmond.corp.microsoft.com> from "Mike Jones" at Jan 25, 12 00:03:15 am <201201250028.q0P0SwiS000165@fs4113.wdf.sap.corp> <4E1F6AAD24975D4BA5B1680429673943663801ED@TK5EX14MBXC284.redmond.corp.microsoft.com> <2rkuh71k7eh4h1ciu15p6b2sss77u6qhtp@hive.bjoern.hoehrmann.de> In-Reply-To: <2rkuh71k7eh4h1ciu15p6b2sss77u6qhtp@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "oauth@ietf.org" , "ietf@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 08:37:20 -0000 On 2012-01-25 03:14, Bjoern Hoehrmann wrote: > ... +1 > ... > If you want to keep the distinction, you should offer an argument why > this is something individual schemes should regulate (since having the > same rules for all schemes is much simpler). > ... Exactly. I've been asking this many times, but I'm not getting any answers except "we prefer it this way". Best regards, Julian From Michael.Jones@microsoft.com Wed Jan 25 00:37:34 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F8721F84A3; Wed, 25 Jan 2012 00:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.769 X-Spam-Level: X-Spam-Status: No, score=-3.769 tagged_above=-999 required=5 tests=[AWL=-0.170, 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 h-LXWB8hHbzT; Wed, 25 Jan 2012 00:37:33 -0800 (PST) Received: from DB3EHSOBE002.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 09EE521F84B8; Wed, 25 Jan 2012 00:37:30 -0800 (PST) Received: from mail55-db3-R.bigfish.com (10.3.81.250) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 25 Jan 2012 08:37:29 +0000 Received: from mail55-db3 (localhost [127.0.0.1]) by mail55-db3-R.bigfish.com (Postfix) with ESMTP id D340D4035C; Wed, 25 Jan 2012 08:37:29 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eK542M1432N98dKzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail55-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail55-db3 (localhost.localdomain [127.0.0.1]) by mail55-db3 (MessageSwitch) id 1327480647607054_23266; Wed, 25 Jan 2012 08:37:27 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.253]) by mail55-db3.bigfish.com (Postfix) with ESMTP id 8F3D84E0045; Wed, 25 Jan 2012 08:37:27 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 25 Jan 2012 08:37:25 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0247.005; Wed, 25 Jan 2012 00:37:23 -0800 From: Mike Jones To: Eran Hammer , Julian Reschke , "ietf@ietf.org" Subject: RE: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: AczbPI44ucw8FyvfTTSWdvUFZixqdQ== Date: Wed, 25 Jan 2012 08:37:22 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: The IESG , "oauth@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 08:37:34 -0000 Eran, do I then correctly understand that you've changed your mind on the p= osition you took in http://www.ietf.org/mail-archive/web/oauth/current/msg0= 7698.html, which was: "All I agree with is to limit the scope character-set= in the v2 spec to the subset of ASCII allowed in HTTP header quoted-string= , excluding " and \ so no escaping is needed, ever."? I ask this, because = if I correctly understand your statement that you agree with Julian, you ar= e now taking the position that you are OK with recipients being required to= perform escape processing for the scope (and other) parameters and with th= em being required to accept them either as tokens or as quoted strings. This raises a question I'd like to ask John Bradley, William Mills, Phil Hu= nt, and Justin Richter: Since all of you replied with a +1 to Eran's origi= nal statement, are you still in agreement with it, or are you now possibly = reconsidering your position, as Eran apparently has. I'm asking, because y= our messages have been part of the basis upon which I've been taking the po= sition as editor that the working group consensus is that no quoting may oc= cur. (The other reason that I believed, as editor, that this was a consens= us position is that this syntax restriction has been present in every Beare= r draft, as it was in OAuth 2.0 draft 10, which was the basis of the first = Bearer draft.) If that's not the actual working group consensus (or it's n= ot anymore), it would be good to know that now. Finally, I'd like to respond publicly to a comment made to me in a private = note sent to me about the current discussions. In it, the sender (an IETF = "old hand") observed that it could appear from the strength of my responses= to Julian's feedback that I might be trying to defend a particular persona= l view of how these issues should be resolved. I responded to him that the= irony here is that I'm not trying to representing a personal position. Ra= ther, I'm truly trying to do what I believe an IETF editor is supposed to d= o, which is to represent the working group's positions. I'm quite open to the working group making it clear that its position has c= hanged with respect to Julian's comments and equally open to the working gr= oup standing behind the text in the current draft. If the chairs would lik= e to help bring this issue to successful closure, I would highly welcome th= eir participation as well. Personally, I'd mostly just like to see the spec finished! -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer Sent: Tuesday, January 24, 2012 10:24 PM To: Julian Reschke; ietf@ietf.org Cc: The IESG; oauth@ietf.org Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard I fully agree with Julian's perspective. I believe there is sufficient feed= back requiring further review of this issue. If the editor cannot facilitat= e a path forward, I request the chairs to intervene.=20 I will make sure this feedback is fully applied to the MAC token specificat= ion in the next draft. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Julian Reschke > Sent: Tuesday, January 24, 2012 3:24 PM > To: ietf@ietf.org > Cc: The IESG; oauth@ietf.org > Subject: Re: [OAUTH-WG] Last Call: =20 > (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed=20 > Standard >=20 > On 2012-01-23 16:58, Julian Reschke wrote: > > On 2012-01-23 16:46, The IESG wrote: > >> > >> The IESG has received a request from the Web Authorization Protocol=20 > >> WG > >> (oauth) to consider the following document: > >> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > >> as a Proposed Standard ... > > > > Please see my comments in > > > > which I think have not been addressed. > > ... >=20 > In an off-list conversation I heard that what I said before may not be=20 > as clear as it could be. >=20 > So... >=20 > 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme= . >=20 > 2) In the IANA considerations, it references the registration=20 > procedure defined in=20 > 2.3> > (now -18, but that doesn't matter here). >=20 > 3) That document recommends in > : >=20 > o The parsing of challenges and credentials is defined by this > specification, and cannot be modified by new authentication > schemes. When the auth-param syntax is used, all parameters ought > to support both token and quoted-string syntax, and syntactical > constraints ought to be defined on the field value after parsing > (i.e., quoted-string processing). This is necessary so that > recipients can use a generic parser that applies to all > authentication schemes. >=20 > 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has=20 > been mentioned that it might not have ignored it if it had UPPERCASE=20 > requirements, but in HTTPbis we try to restrict BCP14 keywords to the=20 > actual protocol, not on recommendations on other specs. >=20 > 5) The registration requirement for a new scheme is "IETF review",=20 > which RFC > 5226 defines in as: >=20 > IETF Review - (Formerly called "IETF Consensus" in > [IANA-CONSIDERATIONS]) New values are assigned only through > RFCs that have been shepherded through the IESG as AD- > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > intention is that the document and proposed assignment will > be reviewed by the IESG and appropriate IETF WGs (or > experts, if suitable working groups no longer exist) to > ensure that the proposed assignment will not negatively > impact interoperability or otherwise extend IETF protocols > in an inappropriate or damaging manner. >=20 > In this case the WG exists (it's HTTPbis), and the OAuth got two=20 > reviews from HTTPbis pointing out the problem -- from Mark=20 > Nottingham, the WG chair, and myself, one of the authors. >=20 > And yes, I believe the way OAuth defines the syntax *will* impact=20 > interoperability. >=20 > Also, I haven't seen any explanation why OAuth can not follow the=20 > recommendation from HTTPbis. >=20 > Hope this clarifies things, >=20 > Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From daedulus@btconnect.com Wed Jan 25 06:11:02 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77CC21F86E3 for ; Wed, 25 Jan 2012 06:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] 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 xc6y3-y7I6zD for ; Wed, 25 Jan 2012 06:11:02 -0800 (PST) Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by ietfa.amsl.com (Postfix) with ESMTP id D2A3721F86DF for ; Wed, 25 Jan 2012 06:11:01 -0800 (PST) Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2beaomr10.btconnect.com with SMTP id FYJ85432; Wed, 25 Jan 2012 14:10:44 +0000 (GMT) Message-ID: <009a01ccdb62$d1646f80$4001a8c0@gateway.2wire.net> From: "t.petch" To: "todd glassey" References: <4F19824E.9020101@tana.it> <003e01ccd86e$0bc89a40$4001a8c0@gateway.2wire.net> <4F1C65B6.9080102@earthlink.net> Subject: Re: Please remove draft-ordogh-spam-reporting-using-imap-kleansed fromI-D repository Date: Wed, 25 Jan 2012 14:11:10 +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-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4F200D63.00A4, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.25.133016:17:7.944, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, __PHISH_PHRASE5, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, MULTIPLE_RCPTS, RDNS_SUSP, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4F200D64.00FB,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: ietf , Alessandro Vesely X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 14:11:03 -0000 ----- Original Message ----- From: "todd glassey" To: "t.petch" Cc: "Alessandro Vesely" ; "ietf" Sent: Sunday, January 22, 2012 8:38 PM > On 1/21/2012 10:53 AM, t.petch wrote: > > Alessandro > > > > You could, of course, issue an updated version which simply says that its > > predecessor should not have been filed for the reasons you give in the e-mail. > > No need to include any other text whatsoever (except, of course, the relevant > > boiler plate). > > Tom > No actually he cant. That will complicate the matter since the IETF > publishing manner has specifically been set up to destroy the ability to > recall anything. The license to use per the copyright statement is > irrevocable even through the revisions process. Yes, you are right. The I-D has now vanished from the 'current' archive but is still accessible through the expired archive; mmm. It is very difficult to eliminate something from the Internet, so I think my suggestion of a later version explaining what happened could be valuable as belt and braces, reckoning people are more likely to retrieve it than an earlier version; or perhaps it would just draw people's attention to what should never have been:-( I dunno - IPR is so complicated. Tom Petch > That's right - it was published with a set of specific rights use > statements which are factually wrong and now the IETF is stuck with that > - unless a recall practice is put in place immediately like all other > publications houses have. > > > Todd > > > > > That seems simpler to me than asking the system to do something rather unusual > > that it may not have a mechanism to do. In future, there could always be > > another version moving the process forward in the appropriate direction. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Alessandro Vesely" > > To: > > Cc: "Zoltan Ordogh" ; "apps discuss" ; > > "ietf" > > Sent: Friday, January 20, 2012 4:03 PM > > Subject: Please remove draft-ordogh-spam-reporting-using-imap-kleansed fromI-D > > repository > > > > > >> Dear IETF Secretariat, > >> > >> I hereby ask that draft-ordogh-spam-reporting-using-imap-kleansed be > >> removed from the I-D repository. I submitted it on 10 Jan 2012, in a > >> clumsy attempt to speed up a discussion about a similarly named I-D, > >> draft-ordogh-spam-reporting-using-imap. The editing I carried out was > >> based on previous writing about, both privately and on IETF lists. > >> However, I hadn't obtained the author's permission to alter the > >> boilerplate-type of the original document. Thus, the document I > >> posted bears "wrong" copyright information. In particular, unwitting > >> editors may derive their own work from this document if they just > >> abide by its boilerplate text, while the original post did not imply a > >> handoff of change control. > >> > >> I apologize for any inconveniences that my action might have caused. > >> > >> Regards > >> Alessandro Vesely > >> _______________________________________________ > >> Ietf mailing list > >> Ietf@ietf.org > >> https://www.ietf.org/mailman/listinfo/ietf > >> > >> > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > > > -- > Todd S. Glassey > This is from my personal email account and any materials from this > account come with personal disclaimers. > > Further I OPT OUT of any and all commercial emailings. > > From amorris@amsl.com Wed Jan 25 07:42:23 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DC321F852E; Wed, 25 Jan 2012 07:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[AWL=-1.262, BAYES_50=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 52y0Z-iYewnT; Wed, 25 Jan 2012 07:42:22 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:123a::1:14]) by ietfa.amsl.com (Postfix) with ESMTP id C907621F8531; Wed, 25 Jan 2012 07:42:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C3F9112C9EA; Wed, 25 Jan 2012 07:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrZXXlHAQcDP; Wed, 25 Jan 2012 07:42:22 -0800 (PST) Received: from [192.168.0.191] (c-76-102-55-37.hsd1.ca.comcast.net [76.102.55.37]) by c8a.amsl.com (Postfix) with ESMTPSA id 8402512C9DC; Wed, 25 Jan 2012 07:42:22 -0800 (PST) From: Alexa Morris Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: T-Shirt Design Contest for IETF 83 Paris Date: Wed, 25 Jan 2012 07:41:56 -0800 Message-Id: <1BD9C39B-DCC2-4978-BAD2-8802CAC015F7@amsl.com> To: ietf-announce@ietf.org, IETF-Discussion list Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 15:42:23 -0000 As there is no Host for the IETF 83, the IAOC has decided to conduct a = T-Shirt Design Contest to develop a unique t-shirt for the Paris = meeting. The plan is for the community to submit designs, and for the = community to select the winner. We will arrange for shirts to be = produced in Paris and take orders via an online system prior to the = meeting. T-shirts will cost approximately $25 USD. We will stop taking = orders at least 10 days prior to the meeting so that we can get the = shirts produced. While we may have a small number of additional shirts = available for purchase onsite, attendees should not depend on that = possibility.=20 Note that we will only be able to sell t-shirts to actual IETF 83 = attendees. The t-shirts are going to be printed in Paris, and carrying = them back and then shipping them (or shipping them from Paris) would be = costly and difficult.=20 Also, in the interest of expediency, the system used to purchase = t-shirts will be very similar to our social event ticket system. Because = of the way the system works, only people who have registered for the = meeting will be able to purchase a t-shirt -- they will need their = registration number, just as they do when they purchase a social ticket.=20= Timeline: 17 February -- Design Submission Deadline 20 - 24 February --Community votes to select winning design 27 February -- Winner announced Submission Details: Designs should be delivered as EPS or Adobe Illustrator files. A t-shirt = template is available for download here: = ietf.org/meeting/83/t-shirt-contest-template.eps. Your submission should = include t-shirt color, and the design for both front and back of the = shirt. You are welcome to include your signature as a part of the = design. Please note: designs should include the IETF logo, but cannot = include any company logos. Like an Internet-Draft, a t-shirt design = submission is authored by individuals.=20 Designs are to be submitted to: tshirtcontest@ietf.org The IETF logo can be found here: http://www.ietf.org/logo/ietf-logo.eps We look forward to receiving your creative designs. Note: in addition = to glory, the winner of the contest will get a free t-shirt. Good luck! -Alexa ---------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From Michael.Jones@microsoft.com Tue Jan 24 15:35:16 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4E321F84FC; Tue, 24 Jan 2012 15:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.350, 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 RGwWy2d79-vI; Tue, 24 Jan 2012 15:35:16 -0800 (PST) Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id D6D6E21F84EA; Tue, 24 Jan 2012 15:35:15 -0800 (PST) Received: from mail193-tx2-R.bigfish.com (10.9.14.242) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 24 Jan 2012 23:35:15 +0000 Received: from mail193-tx2 (localhost [127.0.0.1]) by mail193-tx2-R.bigfish.com (Postfix) with ESMTP id 6C0B64009C; Tue, 24 Jan 2012 23:35:15 +0000 (UTC) X-SpamScore: -29 X-BigFish: VS-29(zz9371I542M1432N9a6kzz1202hzz8275ch1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail193-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail193-tx2 (localhost.localdomain [127.0.0.1]) by mail193-tx2 (MessageSwitch) id 1327448114278752_29372; Tue, 24 Jan 2012 23:35:14 +0000 (UTC) Received: from TX2EHSMHS039.bigfish.com (unknown [10.9.14.238]) by mail193-tx2.bigfish.com (Postfix) with ESMTP id 345C43E0049; Tue, 24 Jan 2012 23:35:14 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS039.bigfish.com (10.9.99.139) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 24 Jan 2012 23:35:13 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0247.005; Tue, 24 Jan 2012 15:35:08 -0800 From: Mike Jones To: Mark Nottingham , IETF Discussion Subject: RE: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: Acza8M46CiZXQaFIS8+eLGD1eeXM3Q== Date: Tue, 24 Jan 2012 23:35:07 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436637FFB2@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Wed, 25 Jan 2012 10:24:34 -0800 Cc: OAuth WG X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 23:35:16 -0000 For those on the ietf@ietf.org list, you can find my responses as editor to= Mark's useful apps area feedback at these locations: http://www.ietf.org/mail-archive/web/oauth/current/msg08040.html http://www.ietf.org/mail-archive/web/oauth/current/msg08075.html As editor, I attempted to apply all of Mark's recommendations, other than t= hose that were contrary to working group consensus positions that had alrea= dy been established via discussions on the working group mailing list. Whe= re his recommendations were not adopted, reasons were given in my responses= on behalf of the working group cited above. Best wishes, -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ark Nottingham Sent: Tuesday, January 24, 2012 3:19 PM To: IETF Discussion Cc: OAuth WG Subject: Re: [OAUTH-WG] Last Call: (The= OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard My comments were made in: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg03805.html Most of them (excepting the nits) haven't been addressed in the drafts. Regards, Begin forwarded message: > Subject: [OAUTH-WG] Last Call: (The O= Auth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard > Date: Mon, 23 Jan 2012 07:46:43 -0800 > From: The IESG > Reply-To: ietf@ietf.org > To: IETF-Announce > CC: oauth@ietf.org >=20 >=20 > The IESG has received a request from the Web Authorization Protocol WG > (oauth) to consider the following document: > - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits=20 > final comments on this action. Please send substantive comments to the=20 > ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may=20 > be sent to iesg@ietf.org instead. In either case, please retain the=20 > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This specification describes how to use bearer tokens in HTTP > requests to access OAuth 2.0 protected resources. Any party in > possession of a bearer token (a "bearer") can use it to get access to > the associated resources (without demonstrating possession of a > cryptographic key). To prevent misuse, bearer tokens need to be > protected from disclosure in storage and in transport. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 -- Mark Nottingham http://www.mnot.net/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Tue Jan 24 22:24:04 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8E221F865B for ; Tue, 24 Jan 2012 22:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 Si7B9wI8SohK for ; Tue, 24 Jan 2012 22:24:03 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 92CFC21F8674 for ; Tue, 24 Jan 2012 22:24:03 -0800 (PST) Received: (qmail 17705 invoked from network); 25 Jan 2012 06:24:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jan 2012 06:23:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 24 Jan 2012 23:23:57 -0700 From: Eran Hammer To: Julian Reschke , "ietf@ietf.org" Date: Tue, 24 Jan 2012 23:23:51 -0700 Subject: RE: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: Acza70cEhZRkpgsWT3eanhkQYYblkgAOmHSA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB9682E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20120123154643.16223.44509.idtracker@ietfa.amsl.com> <4F1D8391.3080009@gmx.de> <4F1F3D84.1030300@gmx.de> In-Reply-To: <4F1F3D84.1030300@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 25 Jan 2012 10:24:34 -0800 Cc: The IESG , "oauth@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 06:24:04 -0000 I fully agree with Julian's perspective. I believe there is sufficient feed= back requiring further review of this issue. If the editor cannot facilitat= e a path forward, I request the chairs to intervene.=20 I will make sure this feedback is fully applied to the MAC token specificat= ion in the next draft. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Julian Reschke > Sent: Tuesday, January 24, 2012 3:24 PM > To: ietf@ietf.org > Cc: The IESG; oauth@ietf.org > Subject: Re: [OAUTH-WG] Last Call: (T= he > OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard >=20 > On 2012-01-23 16:58, Julian Reschke wrote: > > On 2012-01-23 16:46, The IESG wrote: > >> > >> The IESG has received a request from the Web Authorization Protocol > >> WG > >> (oauth) to consider the following document: > >> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > >> as a Proposed Standard ... > > > > Please see my comments in > > > > which I think have not been addressed. > > ... >=20 > In an off-list conversation I heard that what I said before may not be as= clear > as it could be. >=20 > So... >=20 > 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme= . >=20 > 2) In the IANA considerations, it references the registration procedure > defined in 2.3> > (now -18, but that doesn't matter here). >=20 > 3) That document recommends in > : >=20 > o The parsing of challenges and credentials is defined by this > specification, and cannot be modified by new authentication > schemes. When the auth-param syntax is used, all parameters ought > to support both token and quoted-string syntax, and syntactical > constraints ought to be defined on the field value after parsing > (i.e., quoted-string processing). This is necessary so that > recipients can use a generic parser that applies to all > authentication schemes. >=20 > 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has been > mentioned that it might not have ignored it if it had UPPERCASE > requirements, but in HTTPbis we try to restrict BCP14 keywords to the act= ual > protocol, not on recommendations on other specs. >=20 > 5) The registration requirement for a new scheme is "IETF review", which = RFC > 5226 defines in as: >=20 > IETF Review - (Formerly called "IETF Consensus" in > [IANA-CONSIDERATIONS]) New values are assigned only through > RFCs that have been shepherded through the IESG as AD- > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > intention is that the document and proposed assignment will > be reviewed by the IESG and appropriate IETF WGs (or > experts, if suitable working groups no longer exist) to > ensure that the proposed assignment will not negatively > impact interoperability or otherwise extend IETF protocols > in an inappropriate or damaging manner. >=20 > In this case the WG exists (it's HTTPbis), and the OAuth got two reviews = from > HTTPbis pointing out the problem -- from Mark Nottingham, the WG chair, > and myself, one of the authors. >=20 > And yes, I believe the way OAuth defines the syntax *will* impact > interoperability. >=20 > Also, I haven't seen any explanation why OAuth can not follow the > recommendation from HTTPbis. >=20 > Hope this clarifies things, >=20 > Julian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Jan 25 07:38:43 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DE221F85A1 for ; Wed, 25 Jan 2012 07:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 jDNYQKESSUN0 for ; Wed, 25 Jan 2012 07:38:43 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 490B521F859F for ; Wed, 25 Jan 2012 07:38:43 -0800 (PST) Received: (qmail 13847 invoked from network); 25 Jan 2012 15:32:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jan 2012 15:32:03 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 25 Jan 2012 08:31:59 -0700 From: Eran Hammer To: Mike Jones , Julian Reschke , "ietf@ietf.org" Date: Wed, 25 Jan 2012 08:31:52 -0700 Subject: RE: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: AczbPI44ucw8FyvfTTSWdvUFZixqdQAOHCww Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB9686E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 25 Jan 2012 10:24:34 -0800 Cc: The IESG , "oauth@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 15:38:43 -0000 Didn't change my view. I'm expanding it to say that we should restrict the = encoding but at the same time reuse the exact same syntax as the default he= ader. It's bad for the web if developers write custom parsers just for Bear= er that will break on any other scheme. For example: WWW-Authenticate: Bearer realm=3D"example", OTHER-SCHEME param=3Dsomethi= ng Is a valid header but one that will cause clients written to the Bearer spe= c to fail. EHL > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Wednesday, January 25, 2012 12:37 AM > To: Eran Hammer; Julian Reschke; ietf@ietf.org > Cc: The IESG; oauth@ietf.org > Subject: RE: [OAUTH-WG] Last Call: (T= he > OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard >=20 > Eran, do I then correctly understand that you've changed your mind on the > position you took in http://www.ietf.org/mail- > archive/web/oauth/current/msg07698.html, which was: "All I agree with is = to > limit the scope character-set in the v2 spec to the subset of ASCII allow= ed in > HTTP header quoted-string, excluding " and \ so no escaping is needed, > ever."? I ask this, because if I correctly understand your statement tha= t you > agree with Julian, you are now taking the position that you are OK with > recipients being required to perform escape processing for the scope (and > other) parameters and with them being required to accept them either as > tokens or as quoted strings. >=20 > This raises a question I'd like to ask John Bradley, William Mills, Phil = Hunt, and > Justin Richter: Since all of you replied with a +1 to Eran's original st= atement, > are you still in agreement with it, or are you now possibly reconsidering= your > position, as Eran apparently has. I'm asking, because your messages have > been part of the basis upon which I've been taking the position as editor= that > the working group consensus is that no quoting may occur. (The other > reason that I believed, as editor, that this was a consensus position is = that > this syntax restriction has been present in every Bearer draft, as it was= in > OAuth 2.0 draft 10, which was the basis of the first Bearer draft.) If t= hat's not > the actual working group consensus (or it's not anymore), it would be goo= d > to know that now. >=20 > Finally, I'd like to respond publicly to a comment made to me in a privat= e note > sent to me about the current discussions. In it, the sender (an IETF "ol= d > hand") observed that it could appear from the strength of my responses to > Julian's feedback that I might be trying to defend a particular personal = view > of how these issues should be resolved. I responded to him that the iron= y > here is that I'm not trying to representing a personal position. Rather,= I'm > truly trying to do what I believe an IETF editor is supposed to do, which= is to > represent the working group's positions. >=20 > I'm quite open to the working group making it clear that its position has > changed with respect to Julian's comments and equally open to the working > group standing behind the text in the current draft. If the chairs would= like to > help bring this issue to successful closure, I would highly welcome their > participation as well. >=20 > Personally, I'd mostly just like to see the spec finished! >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer > Sent: Tuesday, January 24, 2012 10:24 PM > To: Julian Reschke; ietf@ietf.org > Cc: The IESG; oauth@ietf.org > Subject: Re: [OAUTH-WG] Last Call: (T= he > OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard >=20 > I fully agree with Julian's perspective. I believe there is sufficient fe= edback > requiring further review of this issue. If the editor cannot facilitate a= path > forward, I request the chairs to intervene. >=20 > I will make sure this feedback is fully applied to the MAC token specific= ation > in the next draft. >=20 > EHL >=20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Julian Reschke > > Sent: Tuesday, January 24, 2012 3:24 PM > > To: ietf@ietf.org > > Cc: The IESG; oauth@ietf.org > > Subject: Re: [OAUTH-WG] Last Call: > > (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed > > Standard > > > > On 2012-01-23 16:58, Julian Reschke wrote: > > > On 2012-01-23 16:46, The IESG wrote: > > >> > > >> The IESG has received a request from the Web Authorization Protocol > > >> WG > > >> (oauth) to consider the following document: > > >> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > > >> as a Proposed Standard ... > > > > > > Please see my comments in > > > archive/web/oauth/current/msg08120.html> > > > which I think have not been addressed. > > > ... > > > > In an off-list conversation I heard that what I said before may not be > > as clear as it could be. > > > > So... > > > > 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication > scheme. > > > > 2) In the IANA considerations, it references the registration > > procedure defined in > > > 2.3> > > (now -18, but that doesn't matter here). > > > > 3) That document recommends in > > : > > > > o The parsing of challenges and credentials is defined by this > > specification, and cannot be modified by new authentication > > schemes. When the auth-param syntax is used, all parameters oug= ht > > to support both token and quoted-string syntax, and syntactical > > constraints ought to be defined on the field value after parsing > > (i.e., quoted-string processing). This is necessary so that > > recipients can use a generic parser that applies to all > > authentication schemes. > > > > 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has > > been mentioned that it might not have ignored it if it had UPPERCASE > > requirements, but in HTTPbis we try to restrict BCP14 keywords to the > > actual protocol, not on recommendations on other specs. > > > > 5) The registration requirement for a new scheme is "IETF review", > > which RFC > > 5226 defines in as: > > > > IETF Review - (Formerly called "IETF Consensus" in > > [IANA-CONSIDERATIONS]) New values are assigned only throug= h > > RFCs that have been shepherded through the IESG as AD- > > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > > intention is that the document and proposed assignment wil= l > > be reviewed by the IESG and appropriate IETF WGs (or > > experts, if suitable working groups no longer exist) to > > ensure that the proposed assignment will not negatively > > impact interoperability or otherwise extend IETF protocols > > in an inappropriate or damaging manner. > > > > In this case the WG exists (it's HTTPbis), and the OAuth got two > > reviews from HTTPbis pointing out the problem -- from Mark > > Nottingham, the WG chair, and myself, one of the authors. > > > > And yes, I believe the way OAuth defines the syntax *will* impact > > interoperability. > > > > Also, I haven't seen any explanation why OAuth can not follow the > > recommendation from HTTPbis. > > > > Hope this clarifies things, > > > > Julian > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Wed Jan 25 07:42:24 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AD721F855B for ; Wed, 25 Jan 2012 07:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 3trwNesF2Ec3 for ; Wed, 25 Jan 2012 07:42:24 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 41CD121F854A for ; Wed, 25 Jan 2012 07:42:24 -0800 (PST) Received: (qmail 20087 invoked from network); 25 Jan 2012 15:35:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jan 2012 15:35:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Wed, 25 Jan 2012 08:35:41 -0700 From: Eran Hammer To: "eran@hammer-lahav.net" , Mike Jones , Julian Reschke , "ietf@ietf.org" Date: Wed, 25 Jan 2012 08:35:35 -0700 Subject: RE: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Topic: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Thread-Index: AczbPI44ucw8FyvfTTSWdvUFZixqdQAOHCwwAAB24UA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AAB9686F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453AAB9686E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AAB9686E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 25 Jan 2012 10:24:34 -0800 Cc: The IESG , "oauth@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 15:42:24 -0000 And by 'restrict the encoding' I meant limit the allowed character-set in t= he value to remove the need for encoding (but encoding which results in a v= alid value - as unnecessary as it may be - is still allowed). EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer > Sent: Wednesday, January 25, 2012 7:32 AM > To: Mike Jones; Julian Reschke; ietf@ietf.org > Cc: The IESG; oauth@ietf.org > Subject: Re: [OAUTH-WG] Last Call: (T= he > OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard >=20 > Didn't change my view. I'm expanding it to say that we should restrict th= e > encoding but at the same time reuse the exact same syntax as the default > header. It's bad for the web if developers write custom parsers just for > Bearer that will break on any other scheme. For example: >=20 > WWW-Authenticate: Bearer realm=3D"example", OTHER-SCHEME > param=3Dsomething >=20 > Is a valid header but one that will cause clients written to the Bearer s= pec to > fail. >=20 > EHL >=20 > > -----Original Message----- > > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > > Sent: Wednesday, January 25, 2012 12:37 AM > > To: Eran Hammer; Julian Reschke; ietf@ietf.org > > Cc: The IESG; oauth@ietf.org > > Subject: RE: [OAUTH-WG] Last Call: > > (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed > > Standard > > > > Eran, do I then correctly understand that you've changed your mind on > > the position you took in http://www.ietf.org/mail- > > archive/web/oauth/current/msg07698.html, which was: "All I agree with > > is to limit the scope character-set in the v2 spec to the subset of > > ASCII allowed in HTTP header quoted-string, excluding " and \ so no > > escaping is needed, ever."? I ask this, because if I correctly > > understand your statement that you agree with Julian, you are now > > taking the position that you are OK with recipients being required to > > perform escape processing for the scope (and > > other) parameters and with them being required to accept them either > > as tokens or as quoted strings. > > > > This raises a question I'd like to ask John Bradley, William Mills, > > Phil Hunt, and Justin Richter: Since all of you replied with a +1 to > > Eran's original statement, are you still in agreement with it, or are > > you now possibly reconsidering your position, as Eran apparently has. > > I'm asking, because your messages have been part of the basis upon > > which I've been taking the position as editor that the working group > > consensus is that no quoting may occur. (The other reason that I > > believed, as editor, that this was a consensus position is that this > > syntax restriction has been present in every Bearer draft, as it was > > in OAuth 2.0 draft 10, which was the basis of the first Bearer draft.) > > If that's not the actual working group consensus (or it's not anymore),= it > would be good to know that now. > > > > Finally, I'd like to respond publicly to a comment made to me in a > > private note sent to me about the current discussions. In it, the > > sender (an IETF "old > > hand") observed that it could appear from the strength of my responses > > to Julian's feedback that I might be trying to defend a particular > > personal view of how these issues should be resolved. I responded to > > him that the irony here is that I'm not trying to representing a > > personal position. Rather, I'm truly trying to do what I believe an > > IETF editor is supposed to do, which is to represent the working group'= s > positions. > > > > I'm quite open to the working group making it clear that its position > > has changed with respect to Julian's comments and equally open to the > > working group standing behind the text in the current draft. If the > > chairs would like to help bring this issue to successful closure, I > > would highly welcome their participation as well. > > > > Personally, I'd mostly just like to see the spec finished! > > > > -- Mike > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Eran Hammer > > Sent: Tuesday, January 24, 2012 10:24 PM > > To: Julian Reschke; ietf@ietf.org > > Cc: The IESG; oauth@ietf.org > > Subject: Re: [OAUTH-WG] Last Call: > > (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed > > Standard > > > > I fully agree with Julian's perspective. I believe there is sufficient > > feedback requiring further review of this issue. If the editor cannot > > facilitate a path forward, I request the chairs to intervene. > > > > I will make sure this feedback is fully applied to the MAC token > > specification in the next draft. > > > > EHL > > > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > > Behalf Of Julian Reschke > > > Sent: Tuesday, January 24, 2012 3:24 PM > > > To: ietf@ietf.org > > > Cc: The IESG; oauth@ietf.org > > > Subject: Re: [OAUTH-WG] Last Call: > > > > > > (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed > > > Standard > > > > > > On 2012-01-23 16:58, Julian Reschke wrote: > > > > On 2012-01-23 16:46, The IESG wrote: > > > >> > > > >> The IESG has received a request from the Web Authorization > > > >> Protocol WG > > > >> (oauth) to consider the following document: > > > >> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' > > > >> as a Proposed Standard ... > > > > > > > > Please see my comments in > > > > > archive/web/oauth/current/msg08120.html> > > > > which I think have not been addressed. > > > > ... > > > > > > In an off-list conversation I heard that what I said before may not > > > be as clear as it could be. > > > > > > So... > > > > > > 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication > > scheme. > > > > > > 2) In the IANA considerations, it references the registration > > > procedure defined in > > > > > 2.3> > > > (now -18, but that doesn't matter here). > > > > > > 3) That document recommends in > > > : > > > > > > o The parsing of challenges and credentials is defined by this > > > specification, and cannot be modified by new authentication > > > schemes. When the auth-param syntax is used, all parameters o= ught > > > to support both token and quoted-string syntax, and syntactica= l > > > constraints ought to be defined on the field value after parsi= ng > > > (i.e., quoted-string processing). This is necessary so that > > > recipients can use a generic parser that applies to all > > > authentication schemes. > > > > > > 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has > > > been mentioned that it might not have ignored it if it had UPPERCASE > > > requirements, but in HTTPbis we try to restrict BCP14 keywords to > > > the actual protocol, not on recommendations on other specs. > > > > > > 5) The registration requirement for a new scheme is "IETF review", > > > which RFC > > > 5226 defines in as: > > > > > > IETF Review - (Formerly called "IETF Consensus" in > > > [IANA-CONSIDERATIONS]) New values are assigned only thro= ugh > > > RFCs that have been shepherded through the IESG as AD- > > > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The > > > intention is that the document and proposed assignment w= ill > > > be reviewed by the IESG and appropriate IETF WGs (or > > > experts, if suitable working groups no longer exist) to > > > ensure that the proposed assignment will not negatively > > > impact interoperability or otherwise extend IETF protoco= ls > > > in an inappropriate or damaging manner. > > > > > > In this case the WG exists (it's HTTPbis), and the OAuth got two > > > reviews from HTTPbis pointing out the problem -- from Mark > > > Nottingham, the WG chair, and myself, one of the authors. > > > > > > And yes, I believe the way OAuth defines the syntax *will* impact > > > interoperability. > > > > > > Also, I haven't seen any explanation why OAuth can not follow the > > > recommendation from HTTPbis. > > > > > > Hope this clarifies things, > > > > > > Julian > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From ve7jtb@ve7jtb.com Wed Jan 25 08:33:46 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD0821F85E9; Wed, 25 Jan 2012 08:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 b6BhniCxinAI; Wed, 25 Jan 2012 08:33:45 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 53C7B21F8574; Wed, 25 Jan 2012 08:33:45 -0800 (PST) Received: by yhnn12 with SMTP id n12so2673510yhn.31 for ; Wed, 25 Jan 2012 08:33:44 -0800 (PST) Received: by 10.236.85.230 with SMTP id u66mr26111255yhe.83.1327509223013; Wed, 25 Jan 2012 08:33:43 -0800 (PST) Received: from [192.168.1.213] ([190.22.13.148]) by mx.google.com with ESMTPS id y58sm1543351yhi.17.2012.01.25.08.33.38 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 Jan 2012 08:33:40 -0800 (PST) Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_48621B5C-1B04-4989-8790-1373A2A47AC5"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Wed, 25 Jan 2012 13:33:36 -0300 Message-Id: <72C55AEA-2165-4950-8C3D-6F7694FB8F05@ve7jtb.com> References: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1251.1) X-Gm-Message-State: ALoCoQm93VfSd+8zfsFCFGexYVa88KIoT6VW6u5deYyZTYQtbSumi1e79KlYRggeTn+o8dOiw4be X-Mailman-Approved-At: Wed, 25 Jan 2012 10:24:34 -0800 Cc: Julian Reschke , "oauth@ietf.org" , "ietf@ietf.org" , Eran Hammer , The IESG X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 16:33:46 -0000 --Apple-Mail=_48621B5C-1B04-4989-8790-1373A2A47AC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Eran agreed to move the restriction on production rules into the core = spec. That was what I was agreeing with. I don't quite understand Eran's new position if he has one. I am in favour of restricting the input, however it is possible I am = missing something in this long thread. John B. On 2012-01-25, at 5:37 AM, Mike Jones wrote: > Eran, do I then correctly understand that you've changed your mind on = the position you took in = http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html, which = was: "All I agree with is to limit the scope character-set in the v2 = spec to the subset of ASCII allowed in HTTP header quoted-string, = excluding " and \ so no escaping is needed, ever."? I ask this, because = if I correctly understand your statement that you agree with Julian, you = are now taking the position that you are OK with recipients being = required to perform escape processing for the scope (and other) = parameters and with them being required to accept them either as tokens = or as quoted strings. >=20 > This raises a question I'd like to ask John Bradley, William Mills, = Phil Hunt, and Justin Richter: Since all of you replied with a +1 to = Eran's original statement, are you still in agreement with it, or are = you now possibly reconsidering your position, as Eran apparently has. = I'm asking, because your messages have been part of the basis upon which = I've been taking the position as editor that the working group consensus = is that no quoting may occur. (The other reason that I believed, as = editor, that this was a consensus position is that this syntax = restriction has been present in every Bearer draft, as it was in OAuth = 2.0 draft 10, which was the basis of the first Bearer draft.) If that's = not the actual working group consensus (or it's not anymore), it would = be good to know that now. >=20 > Finally, I'd like to respond publicly to a comment made to me in a = private note sent to me about the current discussions. In it, the = sender (an IETF "old hand") observed that it could appear from the = strength of my responses to Julian's feedback that I might be trying to = defend a particular personal view of how these issues should be = resolved. I responded to him that the irony here is that I'm not trying = to representing a personal position. Rather, I'm truly trying to do = what I believe an IETF editor is supposed to do, which is to represent = the working group's positions. >=20 > I'm quite open to the working group making it clear that its position = has changed with respect to Julian's comments and equally open to the = working group standing behind the text in the current draft. If the = chairs would like to help bring this issue to successful closure, I = would highly welcome their participation as well. >=20 > Personally, I'd mostly just like to see the spec finished! >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Eran Hammer > Sent: Tuesday, January 24, 2012 10:24 PM > To: Julian Reschke; ietf@ietf.org > Cc: The IESG; oauth@ietf.org > Subject: Re: [OAUTH-WG] Last Call: = (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed = Standard >=20 > I fully agree with Julian's perspective. I believe there is sufficient = feedback requiring further review of this issue. If the editor cannot = facilitate a path forward, I request the chairs to intervene.=20 >=20 > I will make sure this feedback is fully applied to the MAC token = specification in the next draft. >=20 > EHL >=20 >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf=20 >> Of Julian Reschke >> Sent: Tuesday, January 24, 2012 3:24 PM >> To: ietf@ietf.org >> Cc: The IESG; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Last Call: = =20 >> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed=20 >> Standard >>=20 >> On 2012-01-23 16:58, Julian Reschke wrote: >>> On 2012-01-23 16:46, The IESG wrote: >>>>=20 >>>> The IESG has received a request from the Web Authorization Protocol=20= >>>> WG >>>> (oauth) to consider the following document: >>>> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens' >>>> as a Proposed Standard ... >>>=20 >>> Please see my comments in >>> >>> which I think have not been addressed. >>> ... >>=20 >> In an off-list conversation I heard that what I said before may not = be=20 >> as clear as it could be. >>=20 >> So... >>=20 >> 1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication = scheme. >>=20 >> 2) In the IANA considerations, it references the registration=20 >> procedure defined in=20 >> > 2.3> >> (now -18, but that doesn't matter here). >>=20 >> 3) That document recommends in >> = : >>=20 >> o The parsing of challenges and credentials is defined by this >> specification, and cannot be modified by new authentication >> schemes. When the auth-param syntax is used, all parameters = ought >> to support both token and quoted-string syntax, and syntactical >> constraints ought to be defined on the field value after = parsing >> (i.e., quoted-string processing). This is necessary so that >> recipients can use a generic parser that applies to all >> authentication schemes. >>=20 >> 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has=20= >> been mentioned that it might not have ignored it if it had UPPERCASE=20= >> requirements, but in HTTPbis we try to restrict BCP14 keywords to the=20= >> actual protocol, not on recommendations on other specs. >>=20 >> 5) The registration requirement for a new scheme is "IETF review",=20 >> which RFC >> 5226 defines in as: >>=20 >> IETF Review - (Formerly called "IETF Consensus" in >> [IANA-CONSIDERATIONS]) New values are assigned only = through >> RFCs that have been shepherded through the IESG as AD- >> Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The >> intention is that the document and proposed assignment = will >> be reviewed by the IESG and appropriate IETF WGs (or >> experts, if suitable working groups no longer exist) to >> ensure that the proposed assignment will not negatively >> impact interoperability or otherwise extend IETF = protocols >> in an inappropriate or damaging manner. >>=20 >> In this case the WG exists (it's HTTPbis), and the OAuth got two=20 >> reviews from HTTPbis pointing out the problem -- from Mark=20 >> Nottingham, the WG chair, and myself, one of the authors. >>=20 >> And yes, I believe the way OAuth defines the syntax *will* impact=20 >> interoperability. >>=20 >> Also, I haven't seen any explanation why OAuth can not follow the=20 >> recommendation from HTTPbis. >>=20 >> Hope this clarifies things, >>=20 >> Julian >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_48621B5C-1B04-4989-8790-1373A2A47AC5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAx MjUxNjMzMzdaMCMGCSqGSIb3DQEJBDEWBBTQQ7HU45TUn2z5d5MT6e2pWcTWrjCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQB0AqHS/EqS9ChRfNvz8Gj162cLWVn2IoL1xKrMENmQs1vmGzeHPNHi1Vxc/jFJmNGDZS7fM+fL OsaWWTHMeoUCp1/ZQM8JngoetBK6L9OWxkQtJOouzfIx+mZ9XJR4QtKMM+yrQ2z/FuveUr5/0Cnw vOksfQwjCFiOOXb6/vfnglCp+/B+51RMVZ8FIiehTlztatddBsO8C+gCIPWdCSp9MsopcyLhbRRR KecxwieJYtD0ptiyFh/0ZsEgTKoC40y+QBNtGnSw6CJFAPqAUYmcZRP9CLGY0rFxIJA3wN/NlZ1e 0F5lchtupjy5/ashjwtQjgyxbok5QTLo8QWG3dCIAAAAAAAA --Apple-Mail=_48621B5C-1B04-4989-8790-1373A2A47AC5-- From wmills@yahoo-inc.com Wed Jan 25 09:49:26 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9739321F84A1 for ; Wed, 25 Jan 2012 09:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.468 X-Spam-Level: X-Spam-Status: No, score=-17.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 LwZF3K+hLmeY for ; Wed, 25 Jan 2012 09:49:25 -0800 (PST) Received: from nm8.bullet.mail.ac4.yahoo.com (nm8.bullet.mail.ac4.yahoo.com [98.139.52.205]) by ietfa.amsl.com (Postfix) with SMTP id 122DC21F8625 for ; Wed, 25 Jan 2012 09:49:24 -0800 (PST) Received: from [98.139.52.189] by nm8.bullet.mail.ac4.yahoo.com with NNFMP; 25 Jan 2012 17:49:21 -0000 Received: from [98.139.52.173] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 25 Jan 2012 17:49:21 -0000 Received: from [127.0.0.1] by omp1056.mail.ac4.yahoo.com with NNFMP; 25 Jan 2012 17:49:21 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 287837.46795.bm@omp1056.mail.ac4.yahoo.com Received: (qmail 74524 invoked by uid 60001); 25 Jan 2012 17:49:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1327513760; bh=gzWvvwpvBEFGEHDdOLdphMSF+bEnwd5p2fAuLCdUO8k=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=VgQ5uOOIz273f6LnhTkcixrznWODoPD3qYjnHAZETUIUTI5nR4Fb2zPCCFpLE+YW7rTRhKtkcSD5a0BmoNzoH7rCjRHrH0VMGJU0UMBPueOI/Qr9vlTS7Tj69+l8Ji1CB3S8LVoag5bocS0aOP7oaCtNht1rdRyfzcpDBGlqHfg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dBNWB4YUSiStwkEDHEP4CTuh4Le84YGPsFdpB0zrK6KbbWVabR71w085oIUenxZ1TDv7/bYcGIQCsjCp1j77z0OVXyWP1npvxz2iugDGjngIFuscyvBE35U4VBaLYekX4G5XiVeRZt/DLr2Q2m80SlAwg64CG+r5Ysz1UzWPHhA=; X-YMail-OSG: R6REnA4VM1mGWbbIDreIWQ2ceqjq48XsgO0KaHvTCTLYakp YvwksBUWVtDEl5s4b.QEwIZ1IQKHA5Zp.azg6H5mWs8qIKbW3WKcSKEoxz_g 01oafz6maog_.1lncOTVETqoXClXHUZ_tadT2D6aurFA5lFLD4_Jg9GAc5Yn aWiQ2qSHERofHV..XZWzeLV8_lVBtAnyLzdxMC1vP1YBtAkoSxFCSb60XrJ7 .1EAO6wBOafMVvJ4oxgRUY98xTJ2yzhQ9lRpNBJaH39ZUgQwM0zMDrzAsC_t 8ZcLFVkoZDv0riGuQiYphuUUlDGQiBt3lAJqEBhtR25z0MhnXA1o05OrK17a .g34l2bF6M.685i5QOoXHvIB6_IJD1mt2dh6YyvWGmjcyt2.Gx3MG9SR1zzb HJsKuttziZKHTmFHTLuAT2qWUJQ-- Received: from [99.31.212.42] by web31806.mail.mud.yahoo.com via HTTP; Wed, 25 Jan 2012 09:49:19 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.338427 References: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> Message-ID: <1327513759.74454.YahooMailNeo@web31806.mail.mud.yahoo.com> Date: Wed, 25 Jan 2012 09:49:19 -0800 (PST) From: William Mills Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard To: Mike Jones , Eran Hammer , Julian Reschke , "ietf@ietf.org" In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1055047407-1216978258-1327513759=:74454" X-Mailman-Approved-At: Wed, 25 Jan 2012 10:24:34 -0800 Cc: The IESG , "oauth@ietf.org" X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 17:49:26 -0000 ---1055047407-1216978258-1327513759=:74454 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable What I was +1 to there is that it makes sense to limit the character set, a= nd I still think limiting the character set is the right thing to do.=A0 = =0A=0A=0AI have said before in other threads, and still believe, that all o= f the definition for things like scope need to be in the OAuth2 base spec a= nd should be included by reference in all profiles like Bearer and MAC.=A0= =A0 =0A=0A=0AI also find the argument that we need to make sure that this s= tuff is parse-able by generic HTTP header parsers to be a compelling one, b= ecause the more implementers can lean on extant working parsers the more li= kely they are to be successful, i.e. let's make sure that PHP can just pars= e this stuff by default and then we do input validation.=0A=0A-bill=0A=0A= =0A=0A________________________________=0A From: Mike Jones =0ATo: Eran Hammer ; Julian Reschke ; "ietf@ietf.org" =0ACc: The IESG ; "oauth@ietf.org" =0ASent: Wednesday, January 25,= 2012 12:37 AM=0ASubject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Propo= sed Standard=0A =0AEran, do I then correctly understand that you've changed= your mind on the position you took in http://www.ietf.org/mail-archive/web= /oauth/current/msg07698.html, which was: "All I agree with is to limit the = scope character-set in the v2 spec to the subset of ASCII allowed in HTTP h= eader quoted-string, excluding " and \ so no escaping is needed, ever."?=A0= I ask this, because if I correctly understand your statement that you agre= e with Julian, you are now taking the position that you are OK with recipie= nts being required to perform escape processing for the scope (and other) p= arameters and with them being required to accept them either as tokens or a= s quoted strings.=0A=0AThis raises a question I'd like to ask John Bradley,= William Mills, Phil Hunt, and Justin Richter:=A0 Since all of you replied = with a +1 to Eran's original statement, are you still in agreement with it,= or are you now possibly reconsidering your position, as Eran apparently ha= s.=A0 I'm asking, because your messages have been part of the basis upon wh= ich I've been taking the position as editor that the working group consensu= s is that no quoting may occur.=A0 (The other reason that I believed, as ed= itor, that this was a consensus position is that this syntax restriction ha= s been present in every Bearer draft, as it was in OAuth 2.0 draft 10, whic= h was the basis of the first Bearer draft.)=A0 If that's not the actual wor= king group consensus (or it's not anymore), it would be good to know that n= ow.=0A=0AFinally, I'd like to respond publicly to a comment made to me in a= private note sent to me about the current discussions.=A0 In it, the sende= r (an IETF "old hand") observed that it could appear from the strength of m= y responses to Julian's feedback that I might be trying to defend a particu= lar personal view of how these issues should be resolved.=A0 I responded to= him that the irony here is that I'm not trying to representing a personal = position.=A0 Rather, I'm truly trying to do what I believe an IETF editor i= s supposed to do, which is to represent the working group's positions.=0A= =0AI'm quite open to the working group making it clear that its position ha= s changed with respect to Julian's comments and equally open to the working= group standing behind the text in the current draft.=A0 If the chairs woul= d like to help bring this issue to successful closure, I would highly welco= me their participation as well.=0A=0APersonally, I'd mostly just like to se= e the spec finished!=0A=0A=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 -- Mike= =0A=0A-----Original Message-----=0AFrom: oauth-bounces@ietf.org [mailto:oau= th-bounces@ietf.org] On Behalf Of Eran Hammer=0ASent: Tuesday, January 24, = 2012 10:24 PM=0ATo: Julian Reschke; ietf@ietf.org=0ACc: The IESG; oauth@iet= f.org=0ASubject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Stand= ard=0A=0AI fully agree with Julian's perspective. I believe there is suffic= ient feedback requiring further review of this issue. If the editor cannot = facilitate a path forward, I request the chairs to intervene. =0A=0AI will = make sure this feedback is fully applied to the MAC token specification in = the next draft.=0A=0AEHL=0A=0A=0A> -----Original Message-----=0A> From: oau= th-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf =0A> Of Julia= n Reschke=0A> Sent: Tuesday, January 24, 2012 3:24 PM=0A> To: ietf@ietf.org= =0A> Cc: The IESG; oauth@ietf.org=0A> Subject: Re: [OAUTH-WG] Last Call: =0A> (The OAuth 2.0 Authorization Protoco= l: Bearer Tokens) to Proposed =0A> Standard=0A> =0A> On 2012-01-23 16:58, J= ulian Reschke wrote:=0A> > On 2012-01-23 16:46, The IESG wrote:=0A> >>=0A> = >> The IESG has received a request from the Web Authorization Protocol =0A>= >> WG=0A> >> (oauth) to consider the following document:=0A> >> - 'The OAu= th 2.0 Authorization Protocol: Bearer Tokens'=0A> >> as a Proposed Standard ...=0A> >=0A> > Please see my comments= in=0A> > =0A> > which I think have not been addressed.=0A> > ...=0A> =0A> In an of= f-list conversation I heard that what I said before may not be =0A> as clea= r as it could be.=0A> =0A> So...=0A> =0A> 1) draft-ietf-oauth-v2-bearer-15 = defines a new HTTP authentication scheme.=0A> =0A> 2) In the IANA considera= tions, it references the registration =0A> procedure defined in =0A> 2.3>=0A> (= now -18, but that doesn't matter here).=0A> =0A> 3) That document recommend= s in=0A> :=0A> =0A>=A0 =A0 o=A0 The parsing of challenges and credentials is = defined by this=0A>=A0 =A0 =A0 =A0 specification, and cannot be modified by= new authentication=0A>=A0 =A0 =A0 =A0 schemes.=A0 When the auth-param synt= ax is used, all parameters ought=0A>=A0 =A0 =A0 =A0 to support both token a= nd quoted-string syntax, and syntactical=0A>=A0 =A0 =A0 =A0 constraints oug= ht to be defined on the field value after parsing=0A>=A0 =A0 =A0 =A0 (i.e.,= quoted-string processing).=A0 This is necessary so that=0A>=A0 =A0 =A0 =A0= recipients can use a generic parser that applies to all=0A>=A0 =A0 =A0 =A0= authentication schemes.=0A> =0A> 4) draft-ietf-oauth-v2-bearer-15 ignores = this recommendation. It has =0A> been mentioned that it might not have igno= red it if it had UPPERCASE =0A> requirements, but in HTTPbis we try to rest= rict BCP14 keywords to the =0A> actual protocol, not on recommendations on = other specs.=0A> =0A> 5) The registration requirement for a new scheme is "= IETF review", =0A> which RFC=0A> 5226 defines in as:=0A> =0A>=A0 =A0 =A0 =A0 IETF Review - (Formerly = called "IETF Consensus" in=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 [IANA-CONSIDERATI= ONS]) New values are assigned only through=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 R= FCs that have been shepherded through the IESG as AD-=0A>=A0 =A0 =A0 =A0 = =A0 =A0 =A0 Sponsored or IETF WG Documents [RFC3932] [RFC3978].=A0 The=0A>= =A0 =A0 =A0 =A0 =A0 =A0 =A0 intention is that the document and proposed ass= ignment will=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 be reviewed by the IESG and app= ropriate IETF WGs (or=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 experts, if suitable w= orking groups no longer exist) to=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 ensure tha= t the proposed assignment will not negatively=0A>=A0 =A0 =A0 =A0 =A0 =A0 = =A0 impact interoperability or otherwise extend IETF protocols=0A>=A0 =A0 = =A0 =A0 =A0 =A0 =A0 in an inappropriate or damaging manner.=0A> =0A> In thi= s case the WG exists (it's HTTPbis), and the OAuth got two =0A> reviews fro= m HTTPbis pointing out the problem=A0 -- from Mark =0A> Nottingham, the WG = chair, and myself, one of the authors.=0A> =0A> And yes, I believe the way = OAuth defines the syntax *will* impact =0A> interoperability.=0A> =0A> Also= , I haven't seen any explanation why OAuth can not follow the =0A> recommen= dation from HTTPbis.=0A> =0A> Hope this clarifies things,=0A> =0A> Julian= =0A> _______________________________________________=0A> OAuth mailing list= =0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinfo/oauth=0A_____= __________________________________________=0AOAuth mailing list=0AOAuth@iet= f.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth=0A=0A=0A_______________= ________________________________=0AOAuth mailing list=0AOAuth@ietf.org=0Aht= tps://www.ietf.org/mailman/listinfo/oauth ---1055047407-1216978258-1327513759=:74454 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
      What I was +1 to there is that it makes sense to limit the character set,= and I still think limiting the character set is the right thing to do.&nbs= p;

      I have said befo= re in other threads, and still believe, that all of the definition for thin= gs like scope need to be in the OAuth2 base spec and should be included by = reference in all profiles like Bearer and MAC.  

      I also find the argument that we ne= ed to make sure that this stuff is parse-able by generic HTTP header parser= s to be a compelling one, because the more implementers can lean on extant = working parsers the more likely they are to be successful, i.e. let's make = sure that PHP can just parse this stuff by default and then we do input validation.

      -bill=

      From: Mike Jones <Michael.Jones@micr= osoft.com>
      To: Eran= Hammer <eran@hueniverse.com>; Julian Reschke <julian.reschke@gmx.= de>; "ietf@ietf.org" <ietf@ietf.org>
      Cc: The IESG <iesg@ietf.org>; "oauth@ietf.org= " <oauth@ietf.org>
      Sent: Wednesday, January 25, 2012 12:37 AM
      Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Pro= tocol: Bearer Tokens) to Proposed Standard

      =0AEran, = do I then correctly understand that you've changed your mind on the positio= n you took in http://www.ietf.org/mail-archive/web/oauth/current/msg07698.h= tml, which was: "All I agree with is to limit the scope character-set in th= e v2 spec to the subset of ASCII allowed in HTTP header quoted-string, excl= uding " and \ so no escaping is needed, ever."?  I ask this, because i= f I correctly understand your statement that you agree with Julian, you are= now taking the position that you are OK with recipients being required to = perform escape processing for the scope (and other) parameters and with the= m being required to accept them either as tokens or as quoted strings.
      <= br>This raises a question I'd like to ask John Bradley, William Mills, Phil= Hunt, and Justin Richter:  Since all of you replied with a +1 to Eran= 's original statement, are you still in agreement with it, or are you now p= ossibly reconsidering your position, as Eran apparently has.  I'm asking, because your messages have been part of the basis u= pon which I've been taking the position as editor that the working group co= nsensus is that no quoting may occur.  (The other reason that I believ= ed, as editor, that this was a consensus position is that this syntax restr= iction has been present in every Bearer draft, as it was in OAuth 2.0 draft= 10, which was the basis of the first Bearer draft.)  If that's not th= e actual working group consensus (or it's not anymore), it would be good to= know that now.

      Finally, I'd like to respond publicly to a comment m= ade to me in a private note sent to me about the current discussions. = In it, the sender (an IETF "old hand") observed that it could appear from = the strength of my responses to Julian's feedback that I might be trying to= defend a particular personal view of how these issues should be resolved.&= nbsp; I responded to him that the irony here is that I'm not trying to representing a personal position.  Rather, I'm truly trying to do = what I believe an IETF editor is supposed to do, which is to represent the = working group's positions.

      I'm quite open to the working group makin= g it clear that its position has changed with respect to Julian's comments = and equally open to the working group standing behind the text in the curre= nt draft.  If the chairs would like to help bring this issue to succes= sful closure, I would highly welcome their participation as well.

      Pe= rsonally, I'd mostly just like to see the spec finished!

        = ;              -- Mike
      -----Original Message-----
      From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer
      Sent: Tuesday, January 24, 2012 10:24 PM
      To: Julian Reschke; = ietf@ietf= .org
      Cc: The IESG; oauth@ietf.org
      Subject: Re: [OAUTH-WG] Last Call:= <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Pro= tocol: Bearer Tokens) to Proposed Standard

      I fully agree with Julian= 's perspective. I believe there is sufficient feedback requiring further re= view of this issue. If the editor cannot facilitate a path forward, I reque= st the chairs to intervene.

      I will make sure this feedback is fully= applied to the MAC token specification in the next draft.

      EHL

      > -----Original Message-----
      > From: oauth-bounces@= ietf.org [mailto:oauth-bounces@ietf.org] On Beha= lf
      > Of Julian Reschke
      > Sent: Tuesday, January 24, 2012 3:24 = PM
      > To: ietf@ietf.org
      > Cc: The IESG; oauth@ietf.org
      > Subject: = Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt>
      >= ; (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed
      >= ; Standard
      >
      > On 2012-01-23 16:58, Julian Reschke wrote:
      &= gt; > On 2012-01-23 16:46, The IESG wrote:
      > >>
      > >= > The IESG has received a request from the Web Authorization Protocol > >> WG
      > >> (oauth) to consider the following docum= ent:
      > >> - 'The OAuth 2.0 Authorization Protocol: Bearer Token= s'
      > >> <draft-ietf-oauth-v2-bearer-15.txt> as a Proposed Standard ...
      > >
      > > Please see my comments in
      > &= gt; <https://www.ietf.org/mail-archive/web/oauth/cu= rrent/msg08120.html>
      > > which I think have not been addres= sed.
      > > ...
      >
      > In an off-list conversation I heard = that what I said before may not be
      > as clear as it could be.
      >= ;
      > So...
      >
      > 1) draft-ietf-oauth-v2-bearer-15 defines = a new HTTP authentication scheme.
      >
      > 2) In the IANA considera= tions, it references the registration
      > procedure defined in
      >= ; <http://tools.ietf.org/html/draft-ietf-httpbis-p7= -auth-17#section-
      > 2.3>
      > (now -18, but that doesn't ma= tter here).
      >
      > 3) That document recommends in
      > <http://tools.ietf.org/html/draft-ietf-httpbis-p7-au= th-17#section-2.3.1>:
      >
      >    o  The par= sing of challenges and credentials is defined by this
      >    =     specification, and cannot be modified by new authentication>        schemes.  When the auth-param syntax= is used, all parameters ought
      >        to suppor= t both token and quoted-string syntax, and syntactical
      >   =     constraints ought to be defined on the field value after par= sing
      >        (i.e., quoted-string processing).&n= bsp; This is necessary so that
      >        recipient= s can use a generic parser that applies to all
      >      =   authentication schemes.
      >
      > 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has
      >= been mentioned that it might not have ignored it if it had UPPERCASE
      &= gt; requirements, but in HTTPbis we try to restrict BCP14 keywords to the <= br>> actual protocol, not on recommendations on other specs.
      > > 5) The registration requirement for a new scheme is "IETF review", > which RFC
      > 5226 defines in <http://tools.ietf.org/html/r= fc5226#section-4.1> as:
      >
      >        = IETF Review - (Formerly called "IETF Consensus" in
      >    &nb= sp;         [IANA-CONSIDERATIONS]) New values are assig= ned only through
      >              RF= Cs that have been shepherded through the IESG as AD-
      >    &= nbsp;         Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
      >          &= nbsp;   intention is that the document and proposed assignment will>              be reviewed by the IE= SG and appropriate IETF WGs (or
      >          &= nbsp;   experts, if suitable working groups no longer exist) to
      >= ;              ensure that the proposed = assignment will not negatively
      >          &n= bsp;   impact interoperability or otherwise extend IETF protocols
      &= gt;              in an inappropriate or = damaging manner.
      >
      > In this case the WG exists (it's HTTPbis)= , and the OAuth got two
      > reviews from HTTPbis pointing out the prob= lem  -- from Mark
      > Nottingham, the WG chair, and myself, one o= f the authors.
      >
      > And yes, I believe the way OAuth defines the syntax *will* impact
      > interoperability.
      >
      &g= t; Also, I haven't seen any explanation why OAuth can not follow the
      &g= t; recommendation from HTTPbis.
      >
      > Hope this clarifies things= ,
      >
      > Julian
      > _________________________________________= ______
      > OAuth mailing list
      > OAuth@ietf.org
      > https://www.ie= tf.org/mailman/listinfo/oauth
      ______________________________________= _________
      OAuth mailing list
      OAuth@ietf.org
      https://www.ietf.org/mailm= an/listinfo/oauth


      __________________________________________= _____
      OAuth mailing list
      OAuth@ietf.org
      https://www.ietf.org/m= ailman/listinfo/oauth


      ---1055047407-1216978258-1327513759=:74454-- From stpeter@stpeter.im Wed Jan 25 13:26:12 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B8121F856A; Wed, 25 Jan 2012 13:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.719 X-Spam-Level: X-Spam-Status: No, score=-102.719 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 pThOpjE565aQ; Wed, 25 Jan 2012 13:26:11 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9A15B21F8568; Wed, 25 Jan 2012 13:26:11 -0800 (PST) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 872D740058; Wed, 25 Jan 2012 14:35:56 -0700 (MST) Message-ID: <4F207370.2010507@stpeter.im> Date: Wed, 25 Jan 2012 14:26:08 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Mike Jones Subject: Re: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard References: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436638188B@TK5EX14MBXC284.redmond.corp.microsoft.com> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "oauth@ietf.org" , "ietf@ietf.org" , Eran Hammer , The IESG X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:26:12 -0000 (see http://tools.ietf.org/wg/oauth/charters ) On 1/25/12 1:37 AM, Mike Jones wrote: > Eran, do I then correctly understand that you've changed your mind on > the position you took in > http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html, > which was: "All I agree with is to limit the scope character-set in > the v2 spec to the subset of ASCII allowed in HTTP header > quoted-string, excluding " and \ so no escaping is needed, ever."? I > ask this, because if I correctly understand your statement that you > agree with Julian, you are now taking the position that you are OK > with recipients being required to perform escape processing for the > scope (and other) parameters and with them being required to accept > them either as tokens or as quoted strings. > > This raises a question I'd like to ask John Bradley, William Mills, > Phil Hunt, and Justin Richter: Since all of you replied with a +1 to > Eran's original statement, are you still in agreement with it, or are > you now possibly reconsidering your position, as Eran apparently has. > I'm asking, because your messages have been part of the basis upon > which I've been taking the position as editor that the working group > consensus is that no quoting may occur. (The other reason that I > believed, as editor, that this was a consensus position is that this > syntax restriction has been present in every Bearer draft, as it was > in OAuth 2.0 draft 10, which was the basis of the first Bearer > draft.) If that's not the actual working group consensus (or it's > not anymore), it would be good to know that now. Yes, input from those (and other) OAuth WG participants would be helpful. > Finally, I'd like to respond publicly to a comment made to me in a > private note sent to me about the current discussions. In it, the > sender (an IETF "old hand") observed that it could appear from the > strength of my responses to Julian's feedback that I might be trying > to defend a particular personal view of how these issues should be > resolved. I responded to him that the irony here is that I'm not > trying to representing a personal position. Rather, I'm truly trying > to do what I believe an IETF editor is supposed to do, which is to > represent the working group's positions. And that's just what a document editor should be doing. > I'm quite open to the working group making it clear that its position > has changed with respect to Julian's comments and equally open to the > working group standing behind the text in the current draft. If the > chairs would like to help bring this issue to successful closure, I > would highly welcome their participation as well. In my role as Tech Advisor, I have reviewed the discussion threads to date. Julian has pointed out text from the specifications being worked on in the HTTPbis WG. I concur with Julian's assessment: it would cause interoperability issues for individual authentication schemes to special-case the rules about parsing of challenges and credentials. However, I think it might be acceptable (as Martin Rex suggested) for such schemes to make recommendations about the actual data that is conveyed, without special-casing the parsing rules as such (if the OAuth WG wishes to go down that path, then further discussion with the HTTPbis WG would probably be helpful so that we get the layering right and set a good example for future schemes). > Personally, I'd mostly just like to see the spec finished! I think we can all agree on that. :) Peter -- Peter Saint-Andre https://stpeter.im/ From adam@nostrum.com Wed Jan 25 13:36:00 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBEE11E8098; Wed, 25 Jan 2012 13:36:00 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-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 kByVcQUxcqYx; Wed, 25 Jan 2012 13:35:59 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 69B7621F8637; Wed, 25 Jan 2012 13:35:59 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q0PLZww6072081 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 15:35:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F2075BE.5070201@nostrum.com> Date: Wed, 25 Jan 2012 15:35:58 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> In-Reply-To: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010506060102000406040900" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sieve@ietf.org, The IESG , IETF-Announce X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:36:00 -0000 This is a multi-part message in MIME format. --------------010506060102000406040900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Just to make sure I understand the sequence of events: 1. August 21, 2007: Huawei files a patent (CN 200710076523.4) on using SIP for SIEVE notifications. The inventor is listed as a single Huawei employee. 2. August 30, 2007: That same Huawei employee and two additional authors publish an IETF draft ( draft-melnikov-sieve-notify-sip-message-00) on using SIP for SIEVE notifications. 3. September 2007 - September 2011: The SIEVE working group discusses and improves the IETF draft. 4. October 6, 2011: The IESG approves the IETF draft for publication as an RFC. 5. December 14th, 2011: Huawei files an IPR disclosure with the IETF informing it of patent CN 200710076523.4 Is that correct? Am I leaving anything out? /a On 1/25/12 2:17 PM, The IESG wrote: > The IESG has received a request from the Sieve Mail Filtering Language WG > (sieve) to consider the following document: > - 'Sieve Notification Mechanism: SIP MESSAGE' > as a Proposed Standard > > Last calls were earlier issued on version -05 of this document and this > document was approved by the IESG on 2011-10-06. Subsequently, > an IPR disclosure statement for this draft was submitted. > This Second Last Call is intended to determine whether the community > is still comfortable with publication of this document in light of the IPR statement. > The relevant IPR statement is available at: > > https://datatracker.ietf.org/ipr/1658/ > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-02-08. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes a profile of the Sieve extension for > notifications, to allow notifications to be sent over SIP MESSAGE. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/1658/ > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce --------------010506060102000406040900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Just to make sure I understand the sequence of events:
      1. August 21, 2007: Huawei files a patent (CN 200710076523.4) on using SIP for SIEVE notifications. The inventor is listed as a single Huawei employee.

      2. August 30, 2007: That same Huawei employee and two additional authors publish an IETF draft ( draft-melnikov-sieve-notify-sip-message-00) on using SIP for SIEVE notifications.

      3. September 2007 - September 2011: The SIEVE working group discusses and improves the IETF draft.

      4. October 6, 2011: The IESG approves the IETF draft for publication as an RFC.

      5. December 14th, 2011: Huawei files an IPR disclosure with the IETF informing it of patent CN 200710076523.4

      Is that correct? Am I leaving anything out?

      /a


      On 1/25/12 2:17 PM, The IESG wrote: 
      The IESG has received a request from the Sieve Mail Filtering Language WG
(sieve) to consider the following document:
- 'Sieve Notification Mechanism: SIP MESSAGE'
  <draft-ietf-sieve-notify-sip-message-08.txt> as a Proposed Standard

Last calls were earlier issued on version -05 of this document and this
document was approved by the IESG on 2011-10-06. Subsequently,
an IPR disclosure statement for this draft was submitted.
This Second Last Call is intended to determine whether the community
is still comfortable with publication of this document in light of the IPR statement.
The relevant IPR statement is available at:

https://datatracker.ietf.org/ipr/1658/

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-02-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document describes a profile of the Sieve extension for
   notifications, to allow notifications to be sent over SIP MESSAGE.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/


The following IPR Declarations may be related to this I-D:

   http://datatracker.ietf.org/ipr/1658/



_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

      --------------010506060102000406040900-- From adrian@olddog.co.uk Wed Jan 25 13:51:03 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A38D11E80A6; Wed, 25 Jan 2012 13:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 TXzq9mBsDjSb; Wed, 25 Jan 2012 13:51:02 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 68A8611E8098; Wed, 25 Jan 2012 13:51:01 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0PLoxMV018421; Wed, 25 Jan 2012 21:50:59 GMT Received: from 950129200 (ixe-nat1.juniper.net [193.110.54.36]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0PLotqK018404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Jan 2012 21:50:57 GMT From: "Adrian Farrel" To: "'Adam Roach'" , References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> In-Reply-To: <4F2075BE.5070201@nostrum.com> Subject: RE: Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard Date: Wed, 25 Jan 2012 21:50:52 -0000 Message-ID: <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_033A_01CCDBAB.6BB38740" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ1rN/Cv+EkJDjjOH92vFKPRcb57QJJd//OlLmvmbA= Content-Language: en-gb Cc: 'The IESG' , sieve@ietf.org, 'IETF-Announce' X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:51:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_033A_01CCDBAB.6BB38740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please also see US patent 20090204681 visible at http://ip.com/patapp/US20090204681 In my opinion, this second last call should be suspended until this significant breach of the IETF's IPR policy set out in BCP79 has been resolved. While it is important to find out what the IETF community's view of this situation is, there are two questions: 1. What does the WG think about the I-D being IPR encumbered and do they want to develop an alternate solution that is not encumbered? 2. How will the IETF handle the breach of IPR policy? I believe the document should be returned to the working group who are the main victims of the disruptive behaviour by the author. Thanks, Adrian From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Adam Roach Sent: 25 January 2012 21:36 To: ietf@ietf.org Cc: sieve@ietf.org; The IESG; IETF-Announce Subject: Re: Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard Just to make sure I understand the sequence of events: 1. August 21, 2007: Huawei files a patent (CN 200710076523.4) on using SIP for SIEVE notifications. The inventor is listed as a single Huawei employee. 2. August 30, 2007: That same Huawei employee and two additional authors publish an IETF draft ( draft-melnikov-sieve-notify-sip-message-00) on using SIP for SIEVE notifications. 3. September 2007 - September 2011: The SIEVE working group discusses and improves the IETF draft. 4. October 6, 2011: The IESG approves the IETF draft for publication as an RFC. 5. December 14th, 2011: Huawei files an IPR disclosure with the IETF informing it of patent CN 200710076523.4 Is that correct? Am I leaving anything out? /a On 1/25/12 2:17 PM, The IESG wrote: The IESG has received a request from the Sieve Mail Filtering Language WG (sieve) to consider the following document: - 'Sieve Notification Mechanism: SIP MESSAGE' as a Proposed Standard Last calls were earlier issued on version -05 of this document and this document was approved by the IESG on 2011-10-06. Subsequently, an IPR disclosure statement for this draft was submitted. This Second Last Call is intended to determine whether the community is still comfortable with publication of this document in light of the IPR statement. The relevant IPR statement is available at: https://datatracker.ietf.org/ipr/1658/ The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1658/ _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ------=_NextPart_000_033A_01CCDBAB.6BB38740 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

      Please also see US patent = 20090204681 visible at  http://ip.com/patapp/US2009020468= 1

       

      In my opinion, this second = last call should be suspended until this significant breach of the = IETF's IPR policy set out in BCP79 has been = resolved.

       

      While it is important to find = out what the IETF community's view of this situation is, there are two = questions:

       

      1. What does the WG think = about the I-D being IPR encumbered and do they want to develop an = alternate solution that is not encumbered?

       

      2. How will the IETF handle = the breach of IPR policy?

       

      I believe the document should = be returned to the working group who are the main victims of the = disruptive behaviour by the author.

       

      Thanks,

      Adrian

       

      From: = ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of = Adam Roach
      Sent: 25 January 2012 21:36
      To: = ietf@ietf.org
      Cc: sieve@ietf.org; The IESG; = IETF-Announce
      Subject: Re: Second Last Call: = <draft-ietf-sieve-notify-sip-message-08.txt> (Sieve Notification = Mechanism: SIP MESSAGE) to Proposed = Standard

       

      Just to make sure I = understand the sequence of events:

      1. August 21, 2007: = Huawei files a patent (CN 200710076523.4) on using SIP for SIEVE = notifications. The inventor is listed as a single Huawei = employee.
      2. August 30, 2007: = That same Huawei employee and two additional authors publish an IETF = draft ( draft-melnikov-sieve-notify-sip-message-00) on using SIP for = SIEVE notifications.
      3. September 2007 - = September 2011: The SIEVE working group discusses and improves the IETF = draft.
      4. October 6, 2011: The = IESG approves the IETF draft for publication as an = RFC.
      5. December 14th, 2011: = Huawei files an IPR disclosure with the IETF informing it of patent CN = 200710076523.4


      Is that correct? = Am I leaving anything out?

      /a


      On 1/25/12 2:17 PM, The = IESG wrote: 

       
      The =
IESG has received a request from the Sieve Mail Filtering Language =
WG
      (sieve) to consider the following =
document:
      - 'Sieve Notification Mechanism: SIP =
MESSAGE'
        =
<draft-ietf-sieve-notify-sip-message-08.txt> as a Proposed =
Standard
       
      Last calls =
were earlier issued on version -05 of this document and =
this
      document was approved by the IESG on =
2011-10-06. Subsequently,
      an IPR disclosure =
statement for this draft was submitted.
      This Second =
Last Call is intended to determine whether the =
community
      is still comfortable with publication of =
this document in light of the IPR statement.
      The =
relevant IPR statement is available =
at:
       
      https://datatracker.ietf.=
org/ipr/1658/
       
      The =
IESG plans to make a decision in the next few weeks, and =
solicits
      final comments on this action. Please send =
substantive comments to the
      ietf@ietf.org mailing lists by =
2012-02-08. Exceptionally, comments may be
      sent to =
iesg@ietf.org instead. In either =
case, please retain the
      beginning of the Subject =
line to allow automated =
sorting.
       
      Abstract
       
       
         This document =
describes a profile of the Sieve extension =
for
         =
notifications, to allow notifications to be sent over SIP =
MESSAGE.
       
       
       
       
      The =
file can be obtained via
      http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/=

       
      IESG discussion =
can be tracked via
      http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/=

       
       
      The following IPR Declarations may be related to this =
I-D:
       
         http://datatracker.ietf.or=
g/ipr/1658/
       
      &nb=
sp;
       
      _________________________=
______________________
      IETF-Announce mailing =
list
      IETF-Announce@ietf.org
      https://www.=
ietf.org/mailman/listinfo/ietf-announce
       
      ------=_NextPart_000_033A_01CCDBAB.6BB38740-- From stpeter@stpeter.im Wed Jan 25 14:04:11 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D7011E8098; Wed, 25 Jan 2012 14:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.717 X-Spam-Level: X-Spam-Status: No, score=-102.717 tagged_above=-999 required=5 tests=[AWL=-0.118, 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 fIlawElRT7qr; Wed, 25 Jan 2012 14:04:11 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E6A0F11E807A; Wed, 25 Jan 2012 14:04:10 -0800 (PST) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4257F40058; Wed, 25 Jan 2012 15:13:56 -0700 (MST) Message-ID: <4F207C59.6070705@stpeter.im> Date: Wed, 25 Jan 2012 15:04:09 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk Subject: Re: Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> In-Reply-To: <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Sieve mailing list , ietf@ietf.org, IESG IESG X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 22:04:12 -0000 +1 On 1/25/12 2:50 PM, Adrian Farrel wrote: > Please also see US patent 20090204681 visible at > http://ip.com/patapp/US20090204681 > > > > In my opinion, this second last call should be suspended until this > significant breach of the IETF's IPR policy set out in BCP79 has been > resolved. > > > > While it is important to find out what the IETF community's view of this > situation is, there are two questions: > > > > 1. What does the WG think about the I-D being IPR encumbered and do they > want to develop an alternate solution that is not encumbered? > > > > 2. How will the IETF handle the breach of IPR policy? > > > > I believe the document should be returned to the working group who are > the main victims of the disruptive behaviour by the author. > > > > Thanks, > > Adrian > > > > *From:*ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] *On Behalf > Of *Adam Roach > *Sent:* 25 January 2012 21:36 > *To:* ietf@ietf.org > *Cc:* sieve@ietf.org; The IESG; IETF-Announce > *Subject:* Re: Second Last Call: > (Sieve Notification > Mechanism: SIP MESSAGE) to Proposed Standard > > > > Just to make sure I understand the sequence of events: > > 1. August 21, 2007: Huawei files a patent (CN 200710076523.4) on using > SIP for SIEVE notifications. The inventor is listed as a single > Huawei employee. > 2. August 30, 2007: That same Huawei employee and two additional > authors publish an IETF draft ( > draft-melnikov-sieve-notify-sip-message-00) on using SIP for SIEVE > notifications. > 3. September 2007 - September 2011: The SIEVE working group discusses > and improves the IETF draft. > 4. October 6, 2011: The IESG approves the IETF draft for publication as > an RFC. > 5. December 14th, 2011: Huawei files an IPR disclosure with the IETF > informing it of patent CN 200710076523.4 > > > Is that correct? Am I leaving anything out? > > /a > > > On 1/25/12 2:17 PM, The IESG wrote: > > > > The IESG has received a request from the Sieve Mail Filtering Language WG > > (sieve) to consider the following document: > > - 'Sieve Notification Mechanism: SIP MESSAGE' > > as a Proposed Standard > > > > Last calls were earlier issued on version -05 of this document and this > > document was approved by the IESG on 2011-10-06. Subsequently, > > an IPR disclosure statement for this draft was submitted. > > This Second Last Call is intended to determine whether the community > > is still comfortable with publication of this document in light of the IPR statement. > > The relevant IPR statement is available at: > > > > https://datatracker.ietf.org/ipr/1658/ > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2012-02-08. Exceptionally, comments may be > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document describes a profile of the Sieve extension for > > notifications, to allow notifications to be sent over SIP MESSAGE. > > > > > > > > > > The file can be obtained via > > http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/ > > > > IESG discussion can be tracked via > > http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/ > > > > > > The following IPR Declarations may be related to this I-D: > > > > http://datatracker.ietf.org/ipr/1658/ > > > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From tnadeau@lucidvision.com Wed Jan 25 14:05:52 2012 Return-Path: X-Original-To: ietf@ietfa.amsl.com Delivered-To: ietf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0487E11E80A6; Wed, 25 Jan 2012 14:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HTML_MESSAGE=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 P0JYTHDNsdgw; Wed, 25 Jan 2012 14:05:51 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id D5EB411E807A; Wed, 25 Jan 2012 14:05:49 -0800 (PST) Received: from [192.168.1.94] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 1540D2061BC7; Wed, 25 Jan 2012 17:05:49 -0500 (EST) Subject: Re: Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_C4ED6030-4854-4019-BCFC-9CF0133DD12A" From: Thomas Nadeau In-Reply-To: <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> Date: Wed, 25 Jan 2012 17:05:48 -0500 Message-Id: References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1251.1) Cc: sieve@ietf.org, 'The IESG' , ietf@ietf.org, 'IETF-Announce' X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 22:05:52 -0000 --Apple-Mail=_C4ED6030-4854-4019-BCFC-9CF0133DD12A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Agree %100. On Jan 25, 2012, at 4:50 PM, Adrian Farrel wrote: > Please also see US patent 20090204681 visible at = http://ip.com/patapp/US20090204681 > =20 > In my opinion, this second last call should be suspended until this = significant breach of the IETF's IPR policy set out in BCP79 has been = resolved. > =20 > While it is important to find out what the IETF community's view of = this situation is, there are two questions: > =20 > 1. What does the WG think about the I-D being IPR encumbered and do = they want to develop an alternate solution that is not encumbered? > =20 > 2. How will the IETF handle the breach of IPR policy? > =20 > I believe the document should be returned to the working group who are = the main victims of the disruptive behaviour by the author. > =20 > Thanks, > Adrian > =20 > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf = Of Adam Roach > Sent: 25 January 2012 21:36 > To: ietf@ietf.org > Cc: sieve@ietf.org; The IESG; IETF-Announce > Subject: Re: Second Last Call: = (Sieve Notification = Mechanism: SIP MESSAGE) to Proposed Standard > =20 > Just to make sure I understand the sequence of events: > August 21, 2007: Huawei files a patent (CN 200710076523.4) on using = SIP for SIEVE notifications. The inventor is listed as a single Huawei = employee. > August 30, 2007: That same Huawei employee and two additional authors = publish an IETF draft ( draft-melnikov-sieve-notify-sip-message-00) on = using SIP for SIEVE notifications. > September 2007 - September 2011: The SIEVE working group discusses and = improves the IETF draft. > October 6, 2011: The IESG approves the IETF draft for publication as = an RFC. > December 14th, 2011: Huawei files an IPR disclosure with the IETF = informing it of patent CN 200710076523.4 >=20 > Is that correct? Am I leaving anything out? >=20 > /a >=20 >=20 > On 1/25/12 2:17 PM, The IESG wrote: > =20 > The IESG has received a request from the Sieve Mail Filtering Language = WG > (sieve) to consider the following document: > - 'Sieve Notification Mechanism: SIP MESSAGE' > as a Proposed Standard > =20 > Last calls were earlier issued on version -05 of this document and = this > document was approved by the IESG on 2011-10-06. Subsequently, > an IPR disclosure statement for this draft was submitted. > This Second Last Call is intended to determine whether the community > is still comfortable with publication of this document in light of the = IPR statement. > The relevant IPR statement is available at: > =20 > https://datatracker.ietf.org/ipr/1658/ > =20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-02-08. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > =20 > Abstract > =20 > =20 > This document describes a profile of the Sieve extension for > notifications, to allow notifications to be sent over SIP MESSAGE. > =20 > =20 > =20 > =20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/ > =20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/ > =20 > =20 > The following IPR Declarations may be related to this I-D: > =20 > http://datatracker.ietf.org/ipr/1658/ > =20 > =20 > =20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > =20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --Apple-Mail=_C4ED6030-4854-4019-BCFC-9CF0133DD12A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Agree %100.


      On Jan = 25, 2012, at 4:50 PM, Adrian Farrel wrote:

      From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org= ] On Behalf Of Adam = Roach
      Sent: 25= January 2012 21:36
      To: ietf@ietf.org
      Cc: sieve@ietf.org; The IESG; = IETF-Announce
      Subject: Re: Second Last Call: = <draft-ietf-sieve-notify-sip-message-08.txt> (Sieve Notification = Mechanism: SIP MESSAGE) to Proposed = Standard
      Just to = make sure I understand the sequence of = events:
      1. August 21, 2007: Huawei files a patent (CN = 200710076523.4) on using SIP for SIEVE notifications. The inventor is = listed as a single Huawei employee.
      2. August 30, 2007: That = same Huawei employee and two additional authors publish an IETF draft ( = draft-melnikov-sieve-notify-sip-message-00) on using SIP for SIEVE = notifications.
      3. September 2007 - September 2011: The SIEVE = working group discusses and improves the IETF = draft.
      4. December 14th, 2011: Huawei files = an IPR disclosure with the IETF informing it of patent CN = 200710076523.4
      The IESG has received a = request from the Sieve Mail Filtering Language WG
      (sieve) to consider the following =
document:
      - 'Sieve Notification =
Mechanism: SIP MESSAGE'
        =
<draft-ietf-sieve-notify-sip-message-08.txt> as a Proposed =
Standard
       
      Last calls were earlier issued on version -05 of this =
document and this
      document was approved =
by the IESG on 2011-10-06. Subsequently,
      an IPR disclosure statement for this draft was =
submitted.
      This Second Last Call is =
intended to determine whether the community
      is still comfortable with publication of this document =
in light of the IPR statement.
      The =
relevant IPR statement is available at:
       
       
      The IESG plans to make =
a decision in the next few weeks, and solicits
      final comments on this action. Please send substantive =
comments to the
      ietf@ietf.org mailing lists by 2012-02-08. =
Exceptionally, comments may be
      sent to iesg@ietf.org instead. In either case, please retain =
the
      beginning of the Subject line to allow =
automated sorting.
       
       
         =
This document describes a profile of the Sieve extension =
for
         notifications, =
to allow notifications to be sent over SIP MESSAGE.
       
       
       
      The file can be =
obtained via
       
      IESG discussion can be tracked via
       
       
      The following IPR =
Declarations may be related to this I-D:
       
         =
 
       
      IETF-Announce mailing list
      Ietf@ietf.org
      
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jan 2012 22:30:32 -0000

At 13:35 25-01-2012, Adam Roach wrote:
>Just to make sure I understand the sequence of events:
>August 21, 2007: Huawei files a patent (CN 200710076523.4) on using 
>SIP for SIEVE notifications. The inventor is listed as a single 
>Huawei employee.
>
>August 30, 2007: That same Huawei employee and two additional 
>authors publish an IETF draft ( 
>draft-melnikov-sieve-notify-sip-message-00) on using SIP for SIEVE 
>notifications.

The time taken to file the two IPR disclosures is troubling given the 
amount of Note Well advertising.

I would like to thank the Pete Resnick for dealing with the problem 
openly instead of taking the politically expedient route.

At 13:50 25-01-2012, Adrian Farrel wrote:
>2. How will the IETF handle the breach of IPR policy?

That's the uncomfortable question.  Some alternatives are:

  (a) Ask the company not to participate in the IETF for X period

  (b) Take action against the individual(s) responsible for the
      breach

  (c) Ask the individual(s) involved for an explanation

  (d) Do nothing

>I believe the document should be returned to the working group who 
>are the main victims of the disruptive behaviour by the author.

There aren't any victims here.  Before making a statement, it is up 
to the person to ask the question instead of assuming the answer.

Regards,
-sm 


From dworley@avaya.com  Wed Jan 25 14:39:55 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAC521F8577; Wed, 25 Jan 2012 14:39:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.863
X-Spam-Level: 
X-Spam-Status: No, score=-102.863 tagged_above=-999 required=5 tests=[AWL=-0.264, 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 T1F-qRcHtUmc; Wed, 25 Jan 2012 14:39:54 -0800 (PST)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5570421F857A; Wed, 25 Jan 2012 14:39:53 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAFmEIE+HCzI1/2dsb2JhbAA7B65EgQWBcgEBAQECARIoPQIFCwIBCA0IIQULMiUCBAENBQgah1qcTZtHiHUiDAgCARkICgMCAwGDY4JsYwSIP5JYjHY
X-IronPort-AV: E=Sophos;i="4.71,570,1320642000"; d="scan'208";a="228593134"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 25 Jan 2012 17:39:44 -0500
Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 25 Jan 2012 17:26:04 -0500
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Wed, 25 Jan 2012 17:39:44 -0500
From: "Worley, Dale R (Dale)" 
To: "adrian@olddog.co.uk" , 'Adam Roach' , "ietf@ietf.org" 
Date: Wed, 25 Jan 2012 17:39:43 -0500
Subject: RE: Second Last Call:	 (Sieve	Notification Mechanism: SIP MESSAGE) to Proposed Standard
Thread-Topic: Second Last Call:	 (Sieve	Notification Mechanism: SIP MESSAGE) to Proposed Standard
Thread-Index: AQJ1rN/Cv+EkJDjjOH92vFKPRcb57QJJd//OlLmvmbCAAA3hQA==
Message-ID: 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com>, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>
In-Reply-To: <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sieve@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jan 2012 22:39:55 -0000

> From: Adrian Farrel [adrian@olddog.co.uk]
>=20
> In my opinion, this second last call should be suspended until this
> significant breach of the IETF's IPR policy set out in BCP79 has been
> resolved.
> [...]
> I believe the document should be returned to the working group who are
> the main victims of the disruptive behaviour by the author.

If the facts are as outlined by Adam Roach, this is the only thing to do.

Dale

From stpeter@stpeter.im  Wed Jan 25 14:43:26 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3592E11E80B9 for ; Wed, 25 Jan 2012 14:43:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.686
X-Spam-Level: 
X-Spam-Status: No, score=-102.686 tagged_above=-999 required=5 tests=[AWL=-0.087, 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 oDG0SWYDGuiP for ; Wed, 25 Jan 2012 14:43:25 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8C25811E8098 for ; Wed, 25 Jan 2012 14:43:25 -0800 (PST)
Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5773640058; Wed, 25 Jan 2012 15:53:11 -0700 (MST)
Message-ID: <4F20858C.9080209@stpeter.im>
Date: Wed, 25 Jan 2012 15:43:24 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: SM 
Subject: Re: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <6.2.5.6.2.20120125134606.0b285800@resistor.net>
In-Reply-To: <6.2.5.6.2.20120125134606.0b285800@resistor.net>
X-Enigmail-Version: 1.3.4
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Adrian Farrel , ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jan 2012 22:43:26 -0000

Hi SM!

On 1/25/12 3:27 PM, SM wrote:

> At 13:50 25-01-2012, Adrian Farrel wrote:
>> 2. How will the IETF handle the breach of IPR policy?
> 
> That's the uncomfortable question.  Some alternatives are:
> 
>  (a) Ask the company not to participate in the IETF for X period

We all participate as individuals.

>  (b) Take action against the individual(s) responsible for the
>      breach

Perhaps.

>  (c) Ask the individual(s) involved for an explanation

Always a good idea. Ask questions first.

>  (d) Do nothing

That seems like a bad idea.

>> I believe the document should be returned to the working group who are
>> the main victims of the disruptive behaviour by the author.
> 
> There aren't any victims here.  Before making a statement, it is up to
> the person to ask the question instead of assuming the answer.

Causing the WG (and IESG, and general IETF community) to consider these
matters is taking time from many people who I'm sure have better things
to do. I for one consider that to be disruptive.

Peter

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



From ajs@anvilwalrusden.com  Wed Jan 25 15:00:35 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B86321F85E6 for ; Wed, 25 Jan 2012 15:00:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.658
X-Spam-Level: 
X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=-0.059, 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 fsLedU4PeRSP for ; Wed, 25 Jan 2012 15:00:34 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF0B21F85DB for ; Wed, 25 Jan 2012 15:00:34 -0800 (PST)
Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9BD7A1ECB41F for ; Wed, 25 Jan 2012 23:00:33 +0000 (UTC)
Date: Wed, 25 Jan 2012 18:00:32 -0500
From: Andrew Sullivan 
To: ietf@ietf.org
Subject: Re: Last Call:  (xNAME RCODE and	Status Bits Clarification) to Proposed Standard
Message-ID: <20120125230031.GK9730@mail.yitter.info>
References: <20120123182317.28636.48689.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120123103439.0a87a228@resistor.net>  
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jan 2012 23:00:35 -0000

On Tue, Jan 24, 2012 at 10:59:44PM -0800, Murray S. Kucherawy wrote:
> 
> In short, I also find the current presentation a bit awkward.  To fix it, I believe Section 2 should be dropped, and the references for the definitions of AA and AD should be moved to the current Section 4.  No details are lost, the document becomes simpler, and simpler is better.
> 

Rather than moving to Section 4, could we rename section 2, adding
some explanatory text as to why it's _not_ changing the interpretation
of those bits, and then make the statements that are already there?

The reason it's structured this way is because actual fielded
implementations had mistakes around these things.  We wanted to make
clear that the spec isn't wrong.  (In the DNS, it's not always good to
trust the RFCs.  It turns out that quite often, despite what one might
like, you get uninteroperable behaviour when you follow the RFC, and
interoperable behaviour when you look at the implementations.  Yes,
this is a Bad Thing.  No, I don't know what to do about it.)

I do understand the bafflement this section is causing as it stands,
however, because it seems not to be doing anything to these bits at
all.  That's actually the clarification, however, and so I want to
make it explicit.

Best,

Andrew (as document shepherd)

-- 
Andrew Sullivan
ajs@anvilwalrusden.com

From presnick@qualcomm.com  Wed Jan 25 15:06:37 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573EB21F8631; Wed, 25 Jan 2012 15:06:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.557
X-Spam-Level: 
X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 l8iWctoAFkL5; Wed, 25 Jan 2012 15:06:36 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id A0C7321F862D; Wed, 25 Jan 2012 15:06:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327532796; x=1359068796; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F208AEF.5060406@qualcomm.com>|Date:=20We d,=2025=20Jan=202012=2017:06:23=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20"Worley,=20Dale=20R=20(Dale)" =20|CC:=20"adrian@olddog.co.uk"=20,=20'Adam=20Roach'=0D=0A=09,=20"ietf@ietf.org"=20,=20"sieve@ietf .org"=0D=0A=09|Subject:=20Re:=20Second=20 Last=20Call:=09=0D=0A=20(Sieve=09Notification=20Mechanism:=20SIP=20MES SAGE)=20to=20Proposed=20Standard|References:=20<201201252 01714.3903.82295.idtracker@ietfa.amsl.com>=09<4F2075BE.50 70201@nostrum.com>,=09<033901ccdbab$6bae0900$430a1b00$@ol ddog.co.uk>=20|In-Reply-To:=20|Content-Type:=20text/plain=3B=20charset=3D"ISO-8859 -1"=3B=20format=3Dflowed|Content-Transfer-Encoding:=207bi t|X-Originating-IP:=20[172.30.48.1]; bh=B7wQBDpCDOcWYdzJwmVfcIHKAdxG7PRCOqPq5kMrdiQ=; b=CB3G6v9ItjJQFHm2s79U9PDszpGpgUkqv8S1nehtumYCIMUW3L/u36e+ Mmt135aoq7MnD7An/QvvqdT6ez4b14nmii+hdn0J+Q1e4XSYNCZMq2oRg B3+Maaw56vPCQw9nhpPs0HJZzNtMjlHS3beLb00Jer2NktnwTlpHoBoPU M=;
X-IronPort-AV: E=McAfee;i="5400,1158,6600"; a="155623226"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 25 Jan 2012 15:06:36 -0800
X-IronPort-AV: E=Sophos;i="4.71,568,1320652800"; d="scan'208";a="157173473"
Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 25 Jan 2012 15:06:34 -0800
Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 25 Jan 2012 15:06:25 -0800
Message-ID: <4F208AEF.5060406@qualcomm.com>
Date: Wed, 25 Jan 2012 17:06:23 -0600
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: "Worley, Dale R (Dale)" 
Subject: Re: Second Last Call:	 (Sieve	Notification Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com>	<4F2075BE.5070201@nostrum.com>, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.48.1]
Cc: "sieve@ietf.org" , "adrian@olddog.co.uk" , "ietf@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jan 2012 23:06:37 -0000

On 1/25/12 4:39 PM, Worley, Dale R (Dale) wrote:
>> From: Adrian Farrel [adrian@olddog.co.uk]
>>
>> In my opinion, this second last call should be suspended until this
>> significant breach of the IETF's IPR policy set out in BCP79 has been
>> resolved.
>> [...]
>> I believe the document should be returned to the working group who are
>> the main victims of the disruptive behaviour by the author.
>>      
> If the facts are as outlined by Adam Roach, this is the only thing to do.
>    

I apologize for not making this clear in the Last Call text:

Before posting this Last Call (and the similar one for 
draft-ietf-sieve-convert), the documents *were* returned to the SIEVE WG 
to review the situation. With minimal complaint from the WG and no 
indication that the WG wished to change their decision on the documents, 
the chairs asked that I simply put it to the entire community as a Last 
Call. So I believe anything other than "go ahead with publication as is" 
will be done only if that is the consensus of the IETF community as a 
whole. The SIEVE chairs and I will be monitoring the discussion.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From msk@cloudmark.com  Wed Jan 25 15:09:19 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E11C21F84EE for ; Wed, 25 Jan 2012 15:09:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level: 
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 Xw+y9Z41LESX for ; Wed, 25 Jan 2012 15:09:18 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id DB7D45E8001 for ; Wed, 25 Jan 2012 15:09:18 -0800 (PST)
Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 25 Jan 2012 15:09:18 -0800
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 25 Jan 2012 15:09:18 -0800
From: "Murray S. Kucherawy" 
To: "ietf@ietf.org" 
Date: Wed, 25 Jan 2012 15:09:17 -0800
Subject: RE: Last Call:  (xNAME RCODE and	Status Bits Clarification) to Proposed Standard
Thread-Topic: Last Call:  (xNAME RCODE and	Status Bits Clarification) to Proposed Standard
Thread-Index: AczbtSrgSwaGLLsGS2ODVucKETi3ewAANB7A
Message-ID: 
References: <20120123182317.28636.48689.idtracker@ietfa.amsl.com> <6.2.5.6.2.20120123103439.0a87a228@resistor.net>   <20120125230031.GK9730@mail.yitter.info>
In-Reply-To: <20120125230031.GK9730@mail.yitter.info>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Jan 2012 23:09:19 -0000

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of A=
ndrew Sullivan
> Sent: Wednesday, January 25, 2012 3:01 PM
> To: ietf@ietf.org
> Subject: Re: Last Call:  (xNAME
> RCODE and Status Bits Clarification) to Proposed Standard
>=20
> Rather than moving to Section 4, could we rename section 2, adding some
> explanatory text as to why it's _not_ changing the interpretation of
> those bits, and then make the statements that are already there?
> [...]
> I do understand the bafflement this section is causing as it stands,
> however, because it seems not to be doing anything to these bits at
> all.  That's actually the clarification, however, and so I want to make
> it explicit.

That would be far better than what's there now.  Without the context you ju=
st gave, it does indeed seem rather awkward and a prime candidate for simpl=
ification.

Thanks,
-MSK


From presnick@qualcomm.com  Wed Jan 25 17:41:06 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E65211E80CD; Wed, 25 Jan 2012 17:41:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.558
X-Spam-Level: 
X-Spam-Status: No, score=-106.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 EoOR2qT441Gy; Wed, 25 Jan 2012 17:41:05 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 177CC11E80AC; Wed, 25 Jan 2012 17:41:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327542065; x=1359078065; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: x-originating-ip; z=Message-ID:=20<4F20AF20.40103@qualcomm.com>|Date:=20Wed, =2025=20Jan=202012=2019:40:48=20-0600|From:=20Pete=20Resn ick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Adam=20Roach=20|CC:=20,=20,=20The=20IE SG=20,=0D=0A=09IETF-Announce=20< ietf-announce@ietf.org>|Subject:=20Re:=20Second=20Last=20 Call:=20=0D =0A=20(Sieve=20Notification=20Mechanism:=20SIP=20MESSAGE) =20to=20Proposed=20Standard|References:=20<20120125201714 .3903.82295.idtracker@ietfa.amsl.com>=20<4F2075BE.5070201 @nostrum.com>|In-Reply-To:=20<4F2075BE.5070201@nostrum.co m>|Content-Type:=20multipart/alternative=3B=0D=0A=09bound ary=3D"------------010602010108090808070707" |X-Originating-IP:=20[172.30.39.5]; bh=WfQM7uxvTaHp6jHW8qf00HwyQ2sGHONE0aybSgMjoqU=; b=g/MY8HQtkYjHv+ygmR3JxpH6xb+c0aMcqYanArW0Z8VQp9Veh4AYKTuQ rMQhtdeL+cShLSYUrdCxOwck/Dk4GHBJwL4ZhCPt//4qfiRBHFvFQGXCM nSlRYENzHVgSmVCfG+/l34ShuVYs5nXqPO30ibitCpdty5aID1lRGhcC7 E=;
X-IronPort-AV: E=McAfee;i="5400,1158,6600"; a="155653546"
Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine02.qualcomm.com with ESMTP; 25 Jan 2012 17:40:51 -0800
X-IronPort-AV: E=Sophos;i="4.71,568,1320652800";  d="scan'208,217";a="119012305"
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 25 Jan 2012 17:40:51 -0800
Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 25 Jan 2012 17:40:51 -0800
Message-ID: <4F20AF20.40103@qualcomm.com>
Date: Wed, 25 Jan 2012 19:40:48 -0600
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Adam Roach 
Subject: Re: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com>
In-Reply-To: <4F2075BE.5070201@nostrum.com>
Content-Type: multipart/alternative; boundary="------------010602010108090808070707"
X-Originating-IP: [172.30.39.5]
Cc: The IESG , sieve@ietf.org, ietf@ietf.org, IETF-Announce 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 01:41:06 -0000

--------------010602010108090808070707
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 1/25/12 3:35 PM, Adam Roach wrote:
> Just to make sure I understand the sequence of events:
>
>    1. August 21, 2007: Huawei files a patent (CN 200710076523.4) on
>       using SIP for SIEVE notifications. The inventor is listed as a
>       single Huawei employee.
>
>    2. August 30, 2007: That same Huawei employee and two additional
>       authors publish an IETF draft (
>       draft-melnikov-sieve-notify-sip-message-00) on using SIP for
>       SIEVE notifications.
>

Correct, except let's call it an "Internet Draft" for precision's sake.

>    3. September 2007 - September 2011: The SIEVE working group
>       discusses and improves the IETF draft.
>

The draft appears to have been adopted by the WG in December 2008 as 
draft-ietf-sieve-notify-sip-message-00, but otherwise correct.

(See: 
http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/history/ 
)

>    4. October 6, 2011: The IESG approves the IETF draft for
>       publication as an RFC.
>
>    5. December 14th, 2011: Huawei files an IPR disclosure with the
>       IETF informing it of patent CN 200710076523.4
>

Correct.

The dates for the -convert draft (also just re-last called) were 
slightly different, but the circumstances were largely the same.

pr

> On 1/25/12 2:17 PM, The IESG wrote:
>> The IESG has received a request from the Sieve Mail Filtering Language WG
>> (sieve) to consider the following document:
>> - 'Sieve Notification Mechanism: SIP MESSAGE'
>>      as a Proposed Standard
>>
>> Last calls were earlier issued on version -05 of this document and this
>> document was approved by the IESG on 2011-10-06. Subsequently,
>> an IPR disclosure statement for this draft was submitted.
>> This Second Last Call is intended to determine whether the community
>> is still comfortable with publication of this document in light of the IPR statement.
>> The relevant IPR statement is available at:
>>
>> https://datatracker.ietf.org/ipr/1658/
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@ietf.org  mailing lists by 2012-02-08. Exceptionally, comments may be
>> sent toiesg@ietf.org  instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>     This document describes a profile of the Sieve extension for
>>     notifications, to allow notifications to be sent over SIP MESSAGE.
>>
>>
>>
>>
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/
>>
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/
>>
>>
>> The following IPR Declarations may be related to this I-D:
>>
>>     http://datatracker.ietf.org/ipr/1658/
>>
>>      

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


--------------010602010108090808070707
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit




  


On 1/25/12 3:35 PM, Adam Roach wrote:

      
  
Just to make sure I understand the sequence of events:
      
  
        
    
      1. August 21, 2007: Huawei files a patent (CN 200710076523.4) on
using SIP for SIEVE notifications. The inventor is listed as a single
Huawei employee.
        
      
        
    
        2. 
    
      2. August 30, 2007: That same Huawei employee and two additional
authors publish an IETF draft (
      
draft-melnikov-sieve-notify-sip-message-00) on using SIP for SIEVE
notifications.
        
    
        3. 
  
      

      

      
Correct, except let's call it an "Internet Draft" for precision's sake.
      

      

      
  
        
    
      1. September 2007 - September 2011: The SIEVE working group
discusses and improves the IETF draft.
        
    
        2. 
  
      

      

      
The draft appears to have been adopted by the WG in December 2008 as
draft-ietf-sieve-notify-sip-message-00, but otherwise correct.
      

      
(See:
      http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/history/
)
      

      

      
  
        
    
      1. October 6, 2011: The IESG approves the IETF draft for
publication as an RFC.
        
      
        
    
        2. 
    
      2. December 14th, 2011: Huawei files an IPR disclosure with the
IETF informing it of patent CN 200710076523.4
        3. 
  
      

      

      
Correct.
      

      
The dates for the -convert draft (also just re-last called) were
slightly different, but the circumstances were largely the same.
      

      
pr
      

      

      
  
        
  
      
On 1/25/12 2:17 PM, The IESG wrote:
  
      
    
      The IESG has received a request from the Sieve Mail Filtering Language WG
(sieve) to consider the following document:
- 'Sieve Notification Mechanism: SIP MESSAGE'
  <draft-ietf-sieve-notify-sip-message-08.txt> as a Proposed Standard

Last calls were earlier issued on version -05 of this document and this
document was approved by the IESG on 2011-10-06. Subsequently,
an IPR disclosure statement for this draft was submitted.
This Second Last Call is intended to determine whether the community
is still comfortable with publication of this document in light of the IPR statement.
The relevant IPR statement is available at:

https://datatracker.ietf.org/ipr/1658/

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-02-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document describes a profile of the Sieve extension for
   notifications, to allow notifications to be sent over SIP MESSAGE.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/


The following IPR Declarations may be related to this I-D:

   http://datatracker.ietf.org/ipr/1658/

    
      
  
      

      

      

      -- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
      



--------------010602010108090808070707--

From adam@nostrum.com  Wed Jan 25 19:44:19 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5942221F8634; Wed, 25 Jan 2012 19:44:19 -0800 (PST)
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, HTML_MESSAGE=0.001, SPF_PASS=-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 rRnX1lrQUW7k; Wed, 25 Jan 2012 19:44:18 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id BB2CB21F8623; Wed, 25 Jan 2012 19:44:15 -0800 (PST)
Received: from hydra-en0.roach.at (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q0Q3iDCB027339 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 21:44:14 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <4F20CC0D.7080502@nostrum.com>
Date: Wed, 25 Jan 2012 21:44:13 -0600
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: adrian@olddog.co.uk
Subject: Re: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>
In-Reply-To: <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>
Content-Type: multipart/alternative; boundary="------------080001000700090806090408"
Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism)
Cc: sieve@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 03:44:19 -0000

This is a multi-part message in MIME format.
--------------080001000700090806090408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 1/25/12 15:50, Jan 25, Adrian Farrel wrote:
>
> Please also see US patent 20090204681 visible at 
> http://ip.com/patapp/US20090204681
>
Well, at least U.S. patent application. And, for that matter, 
International Application PCT/CN2008/072066:

   http://www.wipo.int/patentscope/search/en/WO2009024088

The geographic scope of the intended patent protection for this 
invention appears to be broader than was revealed by the IPR disclosure.

/a

--------------080001000700090806090408
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    On 1/25/12 15:50, Jan 25, Adrian Farrel wrote:
    
      
      
      
      
      
      
      
      
      
      
        
      Please also see US patent 20090204681 visible at
             http://ip.com/patapp/US20090204681
          
      
      
      
    
      
    Well, at least U.S. patent application. And, for that matter,
    International Application PCT/CN2008/072066:
      
    
      
      http://www.wipo.int/patentscope/search/en/WO2009024088
      
    
      
    The geographic scope of the intended patent protection for this
    invention appears to be broader than was revealed by the IPR
    disclosure.
      
    
      
    /a
      
  


--------------080001000700090806090408--

From sm@resistor.net  Wed Jan 25 20:53:39 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37D921F859E; Wed, 25 Jan 2012 20:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.62
X-Spam-Level: 
X-Spam-Status: No, score=-102.62 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 fI7W3muyekuJ; Wed, 25 Jan 2012 20:53:38 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A893C21F859B; Wed, 25 Jan 2012 20:53:38 -0800 (PST)
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 q0Q4rU9u027776; Wed, 25 Jan 2012 20:53:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327553617; i=@resistor.net; bh=sNYyDvrEhnaFfqYgD4yL9jikXh4IQIJxK5RZFaQ5XPU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=yJX7gYm6psjtXZgt/xE1CkhAxzNZSN5E3POu2Bomz9+qZvkUP+MkL9qAt52M7mibw /1ua/1NdezHuMeoAMHBi+nwMPvu69pJgzRWkVeHyboZEBJtzASRHtaToazgB+EWAv/ h5gNcQfGJyRsdjFw6O194hMoVOB1Vl57axIef5GE=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327553617; i=@resistor.net; bh=sNYyDvrEhnaFfqYgD4yL9jikXh4IQIJxK5RZFaQ5XPU=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=nuk5bIaiacq+AwVaWS7evn1bBBGqetWtU6O0YJheHghzhcKuvb/vkmk65KBD3tCbD f1rqCvRkcLiXf6DDpjmgEmtuoFT9H1BmGzk6mdlYOfz5rb/q8xkF6pT7COFVM6qEuI G/SpRLwM6MKn5Bk6Lhrv7fF12acmDyxpLPPPhAGI=
Message-Id: <6.2.5.6.2.20120125181850.0995e2d0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 25 Jan 2012 20:41:54 -0800
To: Pete Resnick 
From: SM 
Subject: Violation of IETF process (was: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard)
In-Reply-To: <4F20AF20.40103@qualcomm.com>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <4F20AF20.40103@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: sieve@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 04:53:39 -0000

At 17:40 25-01-2012, Pete Resnick wrote:
>Correct, except let's call it an "Internet Draft" for precision's sake.

What this thread is actually about is a violation of IETF process 
(BCP) or IETF policy (Failure to comply with patent disclosure 
requirements is a violation of IETF policy, and the potential legal 
consequences to companies are considerable).

For context:

   "Qian Sun is apparently no longer an active IETF participant, and his
    co-workers who are active IETF participants asked their company to
    disclose against the two documents as soon as they discovered what
    had happened. That's where were are now."

Regards,
-sm 


From adrian@olddog.co.uk  Wed Jan 25 21:49:04 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6290021F8600; Wed, 25 Jan 2012 21:49:04 -0800 (PST)
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 l5aMNwq3LTKG; Wed, 25 Jan 2012 21:49:03 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 8099421F85FF; Wed, 25 Jan 2012 21:49:03 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0Q5n1NH017854;  Thu, 26 Jan 2012 05:49:01 GMT
Received: from 950129200 (50-76-52-225-ip-static.hfc.comcastbusiness.net [50.76.52.225]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0Q5muCO017829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Jan 2012 05:48:59 GMT
From: "Adrian Farrel" 
To: "'SM'" , "'Pete Resnick'" 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com>	<4F2075BE.5070201@nostrum.com> <4F20AF20.40103@qualcomm.com> <6.2.5.6.2.20120125181850.0995e2d0@resistor.net>
In-Reply-To: <6.2.5.6.2.20120125181850.0995e2d0@resistor.net>
Subject: RE: Violation of IETF process (was: Second Last Call:	 (Sieve Notification	Mechanism: SIP MESSAGE) to Proposed Standard)
Date: Thu, 26 Jan 2012 05:48:55 -0000
Message-ID: <03de01ccdbee$33ce28b0$9b6a7a10$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ1rN/Cv+EkJDjjOH92vFKPRcb57QJJd//OAalY3MwBxFrssZSeyD0w
Content-Language: en-gb
Cc: sieve@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 05:49:04 -0000

All that is great.

Why is Qian Sun still listed on the front page as an author. Wouldn't it be more
appropriate to move the name to the Acknowledgements section where the text
could read...

Some of the text of this document was provided by Qian Sun who violated IETF IPR
process by not disclosing related IPR that he had also authored and so is not
listed as a named author of this document.

Adrian

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of SM
> Sent: 26 January 2012 04:42
> To: Pete Resnick
> Cc: sieve@ietf.org; ietf@ietf.org
> Subject: Violation of IETF process (was: Second Last Call:
 sip-message-08.txt> (Sieve Notification Mechanism: SIP MESSAGE) to Proposed
> Standard)
> 
> At 17:40 25-01-2012, Pete Resnick wrote:
> >Correct, except let's call it an "Internet Draft" for precision's sake.
> 
> What this thread is actually about is a violation of IETF process
> (BCP) or IETF policy (Failure to comply with patent disclosure
> requirements is a violation of IETF policy, and the potential legal
> consequences to companies are considerable).
> 
> For context:
> 
>    "Qian Sun is apparently no longer an active IETF participant, and his
>     co-workers who are active IETF participants asked their company to
>     disclose against the two documents as soon as they discovered what
>     had happened. That's where were are now."
> 
> Regards,
> -sm
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


From dhc@dcrocker.net  Wed Jan 25 22:12:58 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532FD5E8002; Wed, 25 Jan 2012 22:12:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.67
X-Spam-Level: 
X-Spam-Status: No, score=-6.67 tagged_above=-999 required=5 tests=[AWL=-0.071,  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 e01KwhBhNbHI; Wed, 25 Jan 2012 22:12:57 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 160245E8001; Wed, 25 Jan 2012 22:12:57 -0800 (PST)
Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0Q6CoUk027481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 22:12:55 -0800
Message-ID: <4F20EEDD.5040605@dcrocker.net>
Date: Wed, 25 Jan 2012 22:12:45 -0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: [sieve] Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>
In-Reply-To: <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>
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, 25 Jan 2012 22:12:56 -0800 (PST)
Cc: sieve@ietf.org, 'The IESG' , 'IETF-Announce' 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 06:12:58 -0000

On 1/25/2012 1:50 PM, Adrian Farrel wrote:
> I believe the document should be returned to the working group who are the main
> victims of the disruptive behaviour by the author.


The working group might be the closest and could reasonably have the highest 
sense of frustration -- Pete's later posting notwithstanding -- but forgive my 
noting that they are not the main victims.

Variously the IETF and the Internet community are the main victims.  The IETF 
for the rather sustained violation of its policies and the Internet community 
for the delay in being able to use a mechanism that presumably would be useful.

Somehow, an apology does not seem sufficient.  Something more substantial is 
warranted.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From sm@resistor.net  Thu Jan 26 00:02:04 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0ABA11E8083; Thu, 26 Jan 2012 00:02:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.619
X-Spam-Level: 
X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 JRklKlBgkn8x; Thu, 26 Jan 2012 00:02:02 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9613311E8075; Thu, 26 Jan 2012 00:02:02 -0800 (PST)
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 q0Q81tu7001865; Thu, 26 Jan 2012 00:01:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327564921; i=@resistor.net; bh=3NyfV2Hx8FASqeKNnTIjj6bRYBJ8WeVkMtyXtQtGIZw=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=0DF4pQdOhowivAmONBj2NFqhCDt7I/Yo0EtUwa48YAmmuabz7CaVxtzedU/WjHHfT eVl3JKLkeK4vEMssCDwrGK55Gx6WQobFCJ7EizAoSoaHI4qsrFSfpqBlex8lpKmX+E +O3qhq27XxHqHglKYVAqdUQpGtN7CYYc6FT1kMMU=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327564921; i=@resistor.net; bh=3NyfV2Hx8FASqeKNnTIjj6bRYBJ8WeVkMtyXtQtGIZw=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=FnPkwuUGptVVF5ExB3HgwDL7OY0jU00nJvPtejLG1cs5ybYNuoyVsVCBxzqBpDOAz wgcWd4MqrsdaNlBut0rlxEoWF4GZ4A8rtevofFpX57Sn2UZmfDNf8RYfgK/a4QigQ6 FfFOgWrL0Ca6M5iu35BKNJGT4816JcjxgebyW3Sc=
Message-Id: <6.2.5.6.2.20120125215449.0c092680@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 25 Jan 2012 23:57:36 -0800
To: adrian@olddog.co.uk
From: SM 
Subject: RE: Violation of IETF process (was: Second Last Call:	 (Sieve Notification	Mechanism: SIP MESSAGE) to Proposed Standard)
In-Reply-To: <03de01ccdbee$33ce28b0$9b6a7a10$@olddog.co.uk>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <4F20AF20.40103@qualcomm.com> <6.2.5.6.2.20120125181850.0995e2d0@resistor.net> <03de01ccdbee$33ce28b0$9b6a7a10$@olddog.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: sieve@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 08:02:04 -0000

Hi Adrian,
At 21:48 25-01-2012, Adrian Farrel wrote:
>Why is Qian Sun still listed on the front page as an author. 
>Wouldn't it be more
>appropriate to move the name to the Acknowledgements section where the text
>could read...

As editorship is a WG Chair decision, it is up to the SIEVE WG Chairs 
to comment on why Qian Sun is still listed on the front page as an author.

>Some of the text of this document was provided by Qian Sun who 
>violated IETF IPR
>process by not disclosing related IPR that he had also authored and so is not
>listed as a named author of this document.

The above text does not mention company affiliation.

There is the following in the text in IPR statements:

   "Note: The individual submitting this template represents and
    warrants that he or she is authorized by the Patent Holder to
    agree to the above-selected licensing declaration."

The name provided in the IPR statement is "Director of licensing".

The violation has a negative impact on the IETF (see comment from 
Dave Crocker on this thread).  It raises questions which should not be asked.

Regards,
-sm 


From stefan.winter@restena.lu  Thu Jan 26 00:08:39 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8BCA11E8075; Thu, 26 Jan 2012 00:08:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.182
X-Spam-Level: 
X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.417,  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 sSozpH1+0yZS; Thu, 26 Jan 2012 00:08:37 -0800 (PST)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id A15DB21F8567; Thu, 26 Jan 2012 00:08:29 -0800 (PST)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id D4091106CB; Thu, 26 Jan 2012 09:08:28 +0100 (CET)
Received: from [IPv6:2001:a18:1:8:c920:9e2a:410d:d40d] (unknown [IPv6:2001:a18:1:8:c920:9e2a:410d:d40d]) by smtprelay.restena.lu (Postfix) with ESMTPS id C14F010691; Thu, 26 Jan 2012 09:08:28 +0100 (CET)
Message-ID: <4F2109F8.4060505@restena.lu>
Date: Thu, 26 Jan 2012 09:08:24 +0100
From: Stefan Winter 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Review of draft-ietf-radext-radsec
References: 
In-Reply-To: 
X-Enigmail-Version: 1.3.4
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3F474C2ACA5DD7A01FB6B5D2"
X-Virus-Scanned: ClamAV
Cc: radext@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 08:08:39 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig3F474C2ACA5DD7A01FB6B5D2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

comments inline.

> This is a review of "TLS Encryption for RADIUS" draft-ietf-radext-radse=
c.
>=20
> Overall, this draft was a pleasant to read, and it is clear that a lot
> of thought as well as implementation experience has gone into it.
>=20
> Kudos to the authors.

Thanks :-)

> General Issues
>=20
> There is a considerable amount of text relating to dynamic discovery in=

> this document, yet
> there is only an informational reference to it.

That's true. As I went through your comments below, I realised that
large parts of the texts you quoted should be moved to the
dynamic-discovery draft altogether as they are are very specific to that
draft.

I'm thinking of taking out all the snippets you mentioned below,
transfer them to dynamic-discovery and leaving nothing but a small
"pointer" paragraph in the RADIUS/TLS document.

This actually coincides with what we've experienced in deployment. While
in earlier times I considered TLS and dynamic discovery rather
intertwined, operations people tell me that these are two very distinct
things; most have no problem changing from UDP to TLS, while leaving
their servers behind a firewall and opening it only to the same known
peers as before; merely changing the transport. They do tend to have
more of a problem with opening the port to the world at large and move
away from hard-wired configurations of known peer addresses though.

So it's indeed best to keep both aspects nicely separated.

> Since inserting a normative reference to dynamic discovery could delay
> the publication of
> this document unnecessarily, my recommendation is to consolidate some o=
f
> the dynamic
> discovery material into a single section in which you can discuss the
> implications, while
> clearly indicating the status of the dynamic discovery work (e.g. still=

> under development, optional to
> implement along with RADSEC, etc.).
>=20
> For example, you might consider consolidating the following text from
> Sections 3.1 and 6
> and placing it prior to the current Section 3.1:
>=20
> Section 3.X:  Implications of Dynamic Peer Discovery
>=20
>    One mechanism to discover RADIUS over TLS peers dynamically via DNS
>    is specified in [I-D.ietf-radext-dynamic-discovery].  While this
> mechanism
>    is still under development and therefore is not a normative dependen=
cy of
>    RADIUS/TLS, the use of dynamic discovery has potential future
> implications that are
>    important to understand.

I'll add that to the text. Since the text about dynamic discovery would
be externalised to the other draft, how about if I add a sentence:

"Readers of this document who are considering the deployment of
DNS-based dynamic discovery are thus encouraged to read
[I-D.ietf-radext-dynamic-discovery] and follow its future development." ?=



Then, those who care can read up on it, while the others just read how
to do TLS instead of UDP.

>    If dynamic peer discovery as per
>    [I-D.ietf-radext-dynamic-discovery] is used, peer authentication
>    alone is not sufficient; the peer must also be authorised to perform=

>    user authentications.  In these cases, the trust fabric cannot depen=
d
>    on peer authentication methods like DNSSEC to identify RADIUS/TLS
>    nodes.  The nodes also need to be properly authorised.  Typically,
>    this can be achieved by adding appropriate authorisation fields into=

>    a X.509 certificate.  Such fields include SRV authority [RFC4985],
>    subjectAltNames, or a defined list of certificate fingerprints.
>    Operators of a RADIUS/TLS infrastructure should define their own
>    authorisation trust model and apply this model to the certificates.
>    The checks enumerated in Section 2.3 provide sufficient flexibility
>    for the implementation of authorisation trust models.
>=20
> [BA] I think you need to be more prescriptive here.  Are there specific=

> fields that a RADSEC TLS certificate should contain?  Having individual=

> implementations/deployments defining their own authorization schemes se=
ems
> like a bad idea.=20

That text is best moved out to dynamic-discovery anyway. But to address
your point: this was discussed numerous times in radext wg meetings. The
conclusion in the end was that it is hard to foresee how trust fabrics
are created by people in the wild, so it seemed like a bad idea to be
too prescriptive. E.g. in eduroam we've already been experimenting with
two (
1) subjectAltName:URI to contain a specific value
2) policyOID to distinguish "authorized eduroam" servers from others

Chances are that we might experiment with more, e.g. DNSSEC subtrees
with DANE records.

This goes together with the current discussion of making dynamic
discovery Experimental - then observe how trust models work, and be more
concrete if the document makes it to standards track.

>    In the case of dynamic peer discovery as per
>    [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be
>    able to accept connections from a large, not previously known, group=

>    of hosts, possibly the whole internet.  In this case, the server's
>    RADIUS/TLS port can not be protected from unauthorised connection
>    attempts with measures on the network layer, i.e. access lists and
>    firewalls.  This opens more attack vectors for Distributed Denial of=

>    Service attacks, just like any other service that is supposed to
>    serve arbitrary clients (like for example web servers).
>=20
>    In the case of dynamic peer discovery as per
>    [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only=

>    proof of authorisation for a connecting RADIUS/TLS nodes.  Special
>    care needs to be taken that certificates get verified properly
>    according to the chosen trust model (particularly: consulting CRLs,
>    checking critical extensions, checking subjectAltNames etc.) to
>    prevent unauthorised connections.

Both of these security considerations apply only to deployers of
dynamic-discovery; so they should be moved to dynamic-discovery.

>=20
> Other comments
>=20
> Section 1
>=20
>    One mechanism to discover RADIUS over TLS peers with DNS is specifie=
d in
>    [I-D.ietf-radext-dynamic-discovery].
>=20
> [BA] Recommend moving this to a section devoted to dynamic discovery.

Done in my working copy, by using your text above.

>=20
> Section 2.1
>=20
>    See
>    section Section 3.3 (4) and (5) for considerations regarding
>    separation of authentication, accounting and dynauth traffic.
>=20
> [BA] Recommend changing to:
>=20
>    "See Section 3.3 for considerations regarding separation of
>     authentication, accounting and dynamic authorisation traffic."

Done in my working copy.
>=20
> Section 2.3
>=20
>    4.  start exchanging RADIUS datagrams.  Note Section 3.3 (1) ).  The=

>        shared secret to compute the (obsolete) MD5 integrity checks and=

>        attribute encryption MUST be "radsec" (see Section 3.3 (2) ).
>=20
> Section 3.1
>=20
>    (3) If dynamic peer discovery as per
>    [I-D.ietf-radext-dynamic-discovery] is used, peer authentication
>    alone is not sufficient; the peer must also be authorised to perform=

>    user authentications.  In these cases, the trust fabric cannot depen=
d
>    on peer authentication methods like DNSSEC to identify RADIUS/TLS
>    nodes.  The nodes also need to be properly authorised.  Typically,
>    this can be achieved by adding appropriate authorisation fields into=

>    a X.509 certificate.  Such fields include SRV authority [RFC4985],
>    subjectAltNames, or a defined list of certificate fingerprints.
>    Operators of a RADIUS/TLS infrastructure should define their own
>    authorisation trust model and apply this model to the certificates.
>    The checks enumerated in Section 2.3 provide sufficient flexibility
>    for the implementation of authorisation trust models.
>=20
> As noted above, I'd suggest removing this material from Section 3.1 and=

> consolidating it with other dynamic-discovery material. =20

Moved out to dynamic-discovery.

>=20
> Section 3.3
>=20
>    Note well: it is not required for an implementation
>    to actually process these packet types.  It is sufficient that upon
>    receiving such a packet, an unconditional NAK is sent back to
>    indicate that the action is not supported.
>=20
> [BA] What Error-Cause attribute value should be included within the NAK=

> to make it
> clear that the action is not supported?  Error 406 "Unsupported Extensi=
on"?
> That is what RFC 5176 Section 3.5 seems to indicate.

Indeed. I'll update the text to that end. Note though that adding
Error-Cause is a MAY only in 5176, so it may very well be that an
implementation which doesn't support dynauth would still send only a
"naked" NAK, ignoring the MAY.

I've put the following text into my working copy:

(4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly
   allocated UDP port to signal that a peer RADIUS server does not
   support reception and processing of the packet types in [RFC5176].
   These packet types are listed as to be received in RADIUS/TLS
   implementations.  Note well: it is not required for an implementation
   to actually process these packet types.  It is sufficient that upon
   receiving such a packet, an unconditional NAK is sent back to
   indicate that the action is not supported.  The NAK MAY contain an
   attribute Error-Cause with the value 406 ("Unsupported Extension");
   see [RFC5176] for details.

>    There
>    is no RADIUS datagram to signal an Accounting NAK.  Clients may be
>    misconfigured to send Accounting packets to a RADIUS/TLS server whic=
h
>    does not wish to process their Accounting packet.  The server will
>    need to silently drop the packet.  The client will need to deduce
>    from the absence of replies that it is misconfigured; no negative
>    ICMP response will reveal this.
>=20
> [BA] This seems like a bad idea.  How about requiring implementations n=
ot
> supporting Accounting to respond with an Accounting-Response containing=

> Error-Cause attribute value 406?  Implementations receiving an
> Accounting-Response
> with this Error-Cause can be required to treat this like an ICMP respon=
se.

I'm slightly confused here. To my best knowledge, Error-cause is only
specified in the context of DynAuth (RFC5176). That attribute is listed
as only allowed in a NAK as per the attribute occurence table in 5176.

I would be hesitant to use Error-Cause in RADIUS Accounting packets -
unless the corresponding RFCs get updated to specify that this attribute
is now also to be used in Accounting semantics. And to be honest, I
would even be rather against such a change, and introduce a proper
Accounting-NAK packet type instead; but that's a different story.

The non-ability to indicate "No accounting please" has been discussed in
a radext wg meetint. The conclusion was that auth and acct are two
separate, unrelated items. RADIUS Accounting needs to be configured
differently and explicitly; so there is little risk that accounting
packets are sent "by chance" anyway. If they are sent to the wrong
place, that is an administrative error: misconfigured on the sender-side.=


> Section 4
>=20
>    As a consequence, the selection of transports to communicate from a
>    client to a server is a manual administrative action.  An automatic
>    fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down-
>    bidding attacks on the peer communication.
>=20
> [BA] If a fixed shared secret "radsec" is used alongside fallback to
> RADIUS/UDP,
> that seems more like a MUST NOT!!

That paragraph was also brought up in the AD review. It was not meant in
the way you perceived it; please see the thread of the AD review of this
document for an extensive explanation how it was really meant.

In any case, I take the point that the text is confusing for readers.

While resolving the AD comments, I agreed with Dan Romascanu to
reformulate this whole paragraph and move it to Security Considerations
instead. I'll follow up with the new text later today.

> Section 6
>=20
>    In the case of dynamic peer discovery as per
>    [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be
>    able to accept connections from a large, not previously known, group=

>    of hosts, possibly the whole internet.  In this case, the server's
>    RADIUS/TLS port can not be protected from unauthorised connection
>    attempts with measures on the network layer, i.e. access lists and
>    firewalls.  This opens more attack vectors for Distributed Denial of=

>    Service attacks, just like any other service that is supposed to
>    serve arbitrary clients (like for example web servers).
>=20
>    In the case of dynamic peer discovery as per
>    [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only=

>    proof of authorisation for a connecting RADIUS/TLS nodes.  Special
>    care needs to be taken that certificates get verified properly
>    according to the chosen trust model (particularly: consulting CRLs,
>    checking critical extensions, checking subjectAltNames etc.) to
>    prevent unauthorised connections.
>=20
>=20
> [BA] I'd recommend collecting this and other dynamic-discovery related
> material
> into a separate section prior to 3.1.

Moved out of the document, to go into dynamic-discovery.

> Appendix C. Assessment of Crypto-Agility Requirements
>=20
>=20
>    The RADIUS Crypto-Agility Requirements (link to RFC once issued here=
)
>    defines numerous classification criteria for protocols that strive t=
o
>    enhance the security of RADIUS.  It contains mandatory (M) and
>    recommended (R) criteria which crypto-agile protocols have to
>    fulfill.  The authors believe that the following assessment about th=
e
>    crypto-agility properties of RADIUS/TLS are true.
>=20
> [BA] The Crypto-Agility RFC is now published so you should reference th=
at.

Done now in my working copy.

Thanks for this extensive review, much appreciated!

Greetings,

Stefan Winter

--=20
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National=
e et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473


--------------enig3F474C2ACA5DD7A01FB6B5D2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8hCfwACgkQ+jm90f8eFWaZoACdFwkftP0j3ufU99CrE+ZgtMSC
bTAAn2UNJ2T0Tmd4a5FHuVpLDQkcYkIb
=DETq
-----END PGP SIGNATURE-----

--------------enig3F474C2ACA5DD7A01FB6B5D2--

From dave@cridland.net  Thu Jan 26 00:19:18 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C000111E80AD for ; Thu, 26 Jan 2012 00:19:18 -0800 (PST)
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 O+xnwBDadbW5 for ; Thu, 26 Jan 2012 00:19:18 -0800 (PST)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 198A311E8075 for ; Thu, 26 Jan 2012 00:19:18 -0800 (PST)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 69F901168087; Thu, 26 Jan 2012 08:19:14 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EnfuMP14y8P; Thu, 26 Jan 2012 08:19:11 +0000 (GMT)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id B60E71168067; Thu, 26 Jan 2012 08:19:11 +0000 (GMT)
Subject: Re: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <6.2.5.6.2.20120125134606.0b285800@resistor.net>
In-Reply-To: <6.2.5.6.2.20120125134606.0b285800@resistor.net>
MIME-Version: 1.0
Message-Id: <21749.1327565951.740855@puncture>
Date: Thu, 26 Jan 2012 08:19:11 +0000
From: Dave Cridland 
To: SM , Adrian Farrel , IETF-Discussion 
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 08:19:18 -0000

On Wed Jan 25 22:27:05 2012, SM wrote:
> That's the uncomfortable question.  Some alternatives are:
> 
>  (a) Ask the company not to participate in the IETF for X period
> 
>  (b) Take action against the individual(s) responsible for the
>      breach
> 
>  (c) Ask the individual(s) involved for an explanation
> 
>  (d) Do nothing

(e) The IETF formally demands a royalty free, reasonable and  
non-discriminatory license to the technology for anyone, for the  
purpose of implementing the specification.

Have Huawei made any statement about their IPR screw-up?

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From john-ietf@jck.com  Thu Jan 26 01:31:44 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E104521F869F; Thu, 26 Jan 2012 01:31:44 -0800 (PST)
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 cZUfuq6FxmyY; Thu, 26 Jan 2012 01:31:44 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3D29921F869D; Thu, 26 Jan 2012 01:31:44 -0800 (PST)
Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RqLck-00059A-3M; Thu, 26 Jan 2012 04:28:06 -0500
Date: Thu, 26 Jan 2012 04:31:34 -0500
From: John C Klensin 
To: Pete Resnick 
Subject: Re: Second Last Call:		(Sieve	Notifica tion Mechanism: SIP MESSAGE) to Proposed Standard
Message-ID: <9E8747DFE73501D34065351E@PST.JCK.COM>
In-Reply-To: <4F208AEF.5060406@qualcomm.com>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> ,	<033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: adrian@olddog.co.uk, sieve@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 09:31:45 -0000

--On Wednesday, January 25, 2012 17:06 -0600 Pete Resnick
 wrote:

>...
> Before posting this Last Call (and the similar one for
> draft-ietf-sieve-convert), the documents *were* returned to
> the SIEVE WG to review the situation. With minimal complaint
> from the WG and no indication that the WG wished to change
> their decision on the documents, the chairs asked that I
> simply put it to the entire community as a Last Call. So I
> believe anything other than "go ahead with publication as is"
> will be done only if that is the consensus of the IETF
> community as a whole. The SIEVE chairs and I will be
> monitoring the discussion.

Pete,

(responding to this message, but I've read the subsequent ones)

It seems to me that a key question here is whether the original
author's decision to not disclose was made in violation of
company policy or whether the sequence of posting the I-D,
getting the document through the WG and Last Call, and then
posting the disclosure is a matter of company policy.  If such
behavior became a pattern, the IETF's IPR policy would be
essentially dead.

I believe that "go ahead with publication as is" would be
equivalent to encouraging such a pattern to develop and is
consequently not acceptable.

Consequently, I believe that at least the following should be
required:

(1) Revision of the IPR statement so it identifies the
responsible individual by name, department, and title.  I do not
believe that the rather anonymous "Director of Licensing" is
compliant with the intent of the IPR disclosure rules.   I will
leave it to the lawyers to advise on whether a document issued
without the name (not just title) of a responsible individual
would even be held to be valid in the various jurisdictions in
which the patent might be recognized.

(2) A request to the company involved for someone who can
formally speak for that company to publicly clarify that this
sequence of behavior occurred in violation of company policy.
If there are internal rewards to individuals for filing and/or
being awarded patents, I assume that a decision that the actions
violate company policy would cause such awards to be withheld in
this case, even though the IETF would have no way to verify
whether or not that occurred.

(3) A request to the company involved to remove the reciprocity
clause from the license stated in the disclosure statement.  As
a show of good faith, they should agree to derive no benefit
from the patent other than what praise accrues from having it
awarded.

(4) Removal of the offending individual from the list of authors
to the acknowledgments with text similar to that suggested by
Adrian.  Unless the company involved is willing to provide the
clarification suggested in (2) above, and possibly the license
modification suggested in (3) above, all names of authors
associated with that company should be removed to the
acknowledgements and the company affiliation explicitly
identified there.  In either case, this should be viewed as a
response to a policy violation and not entangled with any more
general discussion of listed authors on I-Ds or RFCs.

(5) Unless the clarification suggested in (2) can be provided,
each IETF participant who is associated with the relevant
company and who is in an IETF-related leadership or
decision-making position (WG Chairs; Editors; IESG, IAB, IAOC,
Nomcom, members; etc.) should be asked to make a conscientious
personal review as to whether this type of action sufficiently
compromises his or her position that resignation or some other
action would be appropriate and, as appropriate, to review IETF
policies with whatever management chains are relevant.  I am
_not_ suggesting that anyone be asked to resign, only that they
engage in careful consideration of the issues and their
implications.

Just my opinion.
regards,

    john


From harald@alvestrand.no  Thu Jan 26 03:32:33 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D066221F867F; Thu, 26 Jan 2012 03:32:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.488
X-Spam-Level: 
X-Spam-Status: No, score=-110.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 bTuNO1Zq7jgl; Thu, 26 Jan 2012 03:32:33 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CFC5B21F864E; Thu, 26 Jan 2012 03:32:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 873DD39E149; Thu, 26 Jan 2012 12:32:31 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0+k-5YHScqS; Thu, 26 Jan 2012 12:32:31 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 0187839E04C; Thu, 26 Jan 2012 12:32:30 +0100 (CET)
Message-ID: <4F2139CE.3010508@alvestrand.no>
Date: Thu, 26 Jan 2012 12:32:30 +0100
From: Harald Alvestrand 
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16
MIME-Version: 1.0
To: John C Klensin 
Subject: Re: Second Last	Call:	 (Sieve	Notifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com>	<4F2075BE.5070201@nostrum.com>	, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>		<4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM>
In-Reply-To: <9E8747DFE73501D34065351E@PST.JCK.COM>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Pete Resnick , adrian@olddog.co.uk, sieve@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 11:32:34 -0000

John,

a worry I have with going out with such a massive demand set for this 
IPR code violation is that we'd be encouraging the other IPR behaviour 
we've seen: That of saying nothing.

The current Huawei people who caused this disclosure to be filed deserve 
our praise for doing the Right Thing now, even while the people in the 
past who did not deserve our condemnation.

On one point, however, I'm aligned:

On 01/26/2012 10:31 AM, John C Klensin wrote:
>
> (3) A request to the company involved to remove the reciprocity
> clause from the license stated in the disclosure statement.  As
> a show of good faith, they should agree to derive no benefit
> from the patent other than what praise accrues from having it
> awarded.
Indeed, this reciprocity clause is of the form that I used to complain 
to Cisco's IPR lawyer about Cisco making when I was at Cisco: It asserts 
the right of withdrawal of this license for *any* use of *any* patent 
against Huawei - that means that anyone who dares to depend on this 
license is effectively granting a license to *all* their patents to the 
holder of this patent.

The proper scope of reciprocity clauses is a fertile ground for debate 
(and nearly impossible to hold a debate on, unfortunately), but this 
type is one that I am not happy to see.

                       Harald


From stefan.winter@restena.lu  Thu Jan 26 04:36:02 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A261E21F8663; Thu, 26 Jan 2012 04:36:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.242
X-Spam-Level: 
X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.357,  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 Khy7vEnOksBj; Thu, 26 Jan 2012 04:36:02 -0800 (PST)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id B48E421F8659; Thu, 26 Jan 2012 04:36:01 -0800 (PST)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 1325F106CB; Thu, 26 Jan 2012 13:36:01 +0100 (CET)
Received: from [IPv6:2001:a18:1:8:d0e6:a4f2:93f:2654] (unknown [IPv6:2001:a18:1:8:d0e6:a4f2:93f:2654]) by smtprelay.restena.lu (Postfix) with ESMTPS id F1F2C106C2; Thu, 26 Jan 2012 13:36:00 +0100 (CET)
Message-ID: <4F2148AC.7080108@restena.lu>
Date: Thu, 26 Jan 2012 13:35:56 +0100
From: Stefan Winter 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: ietf@ietf.org, radext@ietf.org
Subject: Re: Review of draft-ietf-radext-radsec
References:  <4F2109F8.4060505@restena.lu>
In-Reply-To: <4F2109F8.4060505@restena.lu>
X-Enigmail-Version: 1.3.4
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE1D151C91639983533087B96"
X-Virus-Scanned: ClamAV
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 12:36:02 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE1D151C91639983533087B96
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi again,

>>    As a consequence, the selection of transports to communicate from a=

>>    client to a server is a manual administrative action.  An automatic=

>>    fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down-
>>    bidding attacks on the peer communication.
>>
>> [BA] If a fixed shared secret "radsec" is used alongside fallback to
>> RADIUS/UDP,
>> that seems more like a MUST NOT!!
>=20
> That paragraph was also brought up in the AD review. It was not meant i=
n
> the way you perceived it; please see the thread of the AD review of thi=
s
> document for an extensive explanation how it was really meant.

My working copy has the following text in Security Considerations now:

   If peer communication between two devices is configured for both
   RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using
   shared secret security),and where the RADIUS/UDP transport is the
   failover option if the TLS session cannot be established, a down-
   bidding attack can occur if an adversary can maliciously close the
   TCP connection, or prevent it from being established.  Situations
   where clients are configured in such a way are likely to occur during
   a migration phase from RADIUS/UDP to RADIUS/TLS.  By preventing the
   TLS session setup, the attacker can reduce the security of the packet
   payload from the selected TLS cipher suite packet encryption to the
   classic MD5 per-attribute encryption.  The situation should be
   avoided by disabling the weaker RADIUS/UDP transport as soon as the
   new RADIUS/TLS transport is established and tested.  Disabling can
   happen at either the RADIUS client or server side:

   o  Client side: de-configure the failover setup, leaving RADIUS/TLS
      as the only communication option

   o  Server side: de-configure the RADIUS/UDP client from the list of
      valid RADIUS clients

I hope that makes my intended statement clearer.

If I'm not mistaken, IETF LC period is now over. I plan to produce a new
-11 revision tomorrow to prepare the IESG review phase. It would be nice
if you could let me know whether the changes I did in the document
satisfactorily address your concerns.

Greetings,

Stefan Winter

>=20
> In any case, I take the point that the text is confusing for readers.
>=20
> While resolving the AD comments, I agreed with Dan Romascanu to
> reformulate this whole paragraph and move it to Security Considerations=

> instead. I'll follow up with the new text later today.
>=20
>> Section 6
>>
>>    In the case of dynamic peer discovery as per
>>    [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be
>>    able to accept connections from a large, not previously known, grou=
p
>>    of hosts, possibly the whole internet.  In this case, the server's
>>    RADIUS/TLS port can not be protected from unauthorised connection
>>    attempts with measures on the network layer, i.e. access lists and
>>    firewalls.  This opens more attack vectors for Distributed Denial o=
f
>>    Service attacks, just like any other service that is supposed to
>>    serve arbitrary clients (like for example web servers).
>>
>>    In the case of dynamic peer discovery as per
>>    [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the onl=
y
>>    proof of authorisation for a connecting RADIUS/TLS nodes.  Special
>>    care needs to be taken that certificates get verified properly
>>    according to the chosen trust model (particularly: consulting CRLs,=

>>    checking critical extensions, checking subjectAltNames etc.) to
>>    prevent unauthorised connections.
>>
>>
>> [BA] I'd recommend collecting this and other dynamic-discovery related=

>> material
>> into a separate section prior to 3.1.
>=20
> Moved out of the document, to go into dynamic-discovery.
>=20
>> Appendix C. Assessment of Crypto-Agility Requirements
>>
>>
>>    The RADIUS Crypto-Agility Requirements (link to RFC once issued her=
e)
>>    defines numerous classification criteria for protocols that strive =
to
>>    enhance the security of RADIUS.  It contains mandatory (M) and
>>    recommended (R) criteria which crypto-agile protocols have to
>>    fulfill.  The authors believe that the following assessment about t=
he
>>    crypto-agility properties of RADIUS/TLS are true.
>>
>> [BA] The Crypto-Agility RFC is now published so you should reference t=
hat.
>=20
> Done now in my working copy.
>=20
> Thanks for this extensive review, much appreciated!
>=20
> Greetings,
>=20
> Stefan Winter
>=20
>=20
>=20
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


--=20
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National=
e et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473


--------------enigE1D151C91639983533087B96
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8hSLAACgkQ+jm90f8eFWbFogCePqLVbDTi2lvg2/OpXcjSiKgK
5VIAn36jH/wlxEnPUALXPOIaJ8pMR2lh
=/83G
-----END PGP SIGNATURE-----

--------------enigE1D151C91639983533087B96--

From bob.hinden@gmail.com  Thu Jan 26 05:52:52 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD6321F85AA; Thu, 26 Jan 2012 05:52:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.572
X-Spam-Level: 
X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, 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 5F1EPSX+Pp0y; Thu, 26 Jan 2012 05:52:52 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 153E621F859B; Thu, 26 Jan 2012 05:52:52 -0800 (PST)
Received: by pbdu7 with SMTP id u7so266172pbd.31 for ; Thu, 26 Jan 2012 05:52:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=fQmL6GWsmjXqUMiYZ8sV+V8w+VDdA8wEIdFnkch0ccM=; b=hRjalfB59Op9sptQbHtLu88DWn51Ua32VHx1ySvCgUi3COgQC+nRjiw3RS8CWP6i+Z zMFSSKyQZ/g21jT40nteDb5GUbRbZ5Vh6eMjHy64g1w42HIjyrXyXSG0lhuw2hxQC6iD sNJXsn25qa9ypi0H1a6Svb8T7qN2P57P7b/+s=
Received: by 10.68.74.132 with SMTP id t4mr5460632pbv.22.1327585971889; Thu, 26 Jan 2012 05:52:51 -0800 (PST)
Received: from [172.240.6.218] (201.166.23.218.cable.dyn.cableonline.com.mx. [201.166.23.218]) by mx.google.com with ESMTPS id t5sm11491666pbn.3.2012.01.26.05.52.49 (version=SSLv3 cipher=OTHER); Thu, 26 Jan 2012 05:52:51 -0800 (PST)
Subject: Re: [sieve] Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Bob Hinden 
In-Reply-To: <4F20EEDD.5040605@dcrocker.net>
Date: Thu, 26 Jan 2012 07:52:47 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <20DB0302-3267-4928-95C0-D85F264E2876@gmail.com>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> <4F20EEDD.5040605@dcrocker.net>
To: dcrocker@bbiw.net
X-Mailer: Apple Mail (2.1084)
Cc: sieve@ietf.org, The IESG , Bob Hinden , ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 13:52:53 -0000

On Jan 26, 2012, at 12:12 AM, Dave CROCKER wrote:

>=20
>=20
> On 1/25/2012 1:50 PM, Adrian Farrel wrote:
>> I believe the document should be returned to the working group who =
are the main
>> victims of the disruptive behaviour by the author.
>=20
>=20
> The working group might be the closest and could reasonably have the =
highest sense of frustration -- Pete's later posting notwithstanding -- =
but forgive my noting that they are not the main victims.
>=20
> Variously the IETF and the Internet community are the main victims.  =
The IETF for the rather sustained violation of its policies and the =
Internet community for the delay in being able to use a mechanism that =
presumably would be useful.

+1

Bob


>=20
> Somehow, an apology does not seem sufficient.  Something more =
substantial is warranted.
>=20
> d/
> --=20
>=20
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


From john-ietf@jck.com  Thu Jan 26 06:08:19 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A587D21F8665; Thu, 26 Jan 2012 06:08:19 -0800 (PST)
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 Qf8tY5nbobu5; Thu, 26 Jan 2012 06:08:18 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id B94FE21F8630; Thu, 26 Jan 2012 06:08:18 -0800 (PST)
Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RqPwI-0005Ts-GC; Thu, 26 Jan 2012 09:04:34 -0500
Date: Thu, 26 Jan 2012 09:08:04 -0500
From: John C Klensin 
To: Harald Alvestrand 
Subject: Re: Second Last	Call:		(Sieve	Not ifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
Message-ID: 
In-Reply-To: <4F2139CE.3010508@alvestrand.no>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> ,	<033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM> <4F2139CE.3010508@alvestrand.no>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: Pete Resnick , adrian@olddog.co.uk, sieve@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 14:08:19 -0000

--On Thursday, January 26, 2012 12:32 +0100 Harald Alvestrand
 wrote:

> John,
> 
> a worry I have with going out with such a massive demand set
> for this IPR code violation is that we'd be encouraging the
> other IPR behaviour we've seen: That of saying nothing.

I understand this concern, but that takes us into lawyer
territory.  Since the courts, at least in some countries, have
ruled that patents are unenforceable if the technology was
pushed forward into standards in violation of disclosure rules
(that is a deliberately-vague summary, not an attempt to state
the legal situation), I don't know if companies would be better
off saying nothing, ever, until they ambushed someone in court,
or disclosing later.  If the IETF needs to make decisions on
that basis, I'd like us to get clear advice (if such a thing is
possible -- a combination about the situation, not the source of
advice) from Counsel.

> The current Huawei people who caused this disclosure to be
> filed deserve our praise for doing the Right Thing now, even
> while the people in the past who did not deserve our
> condemnation.

Absolutely.  While I recognize it as difficult, that is
precisely why I'd like to have Huawei clarify that those who did
not disclose in the past did so in violation of what I hope is
the company policy to conform to the rules of any standards body
in which their employees are participating.  If that is actually
the case (as I assume it is), then my proposed "demand set" is
not "massive": we adjust the authorship to remove the inventor,
we try to get the reciprocity clause narrowed or removed, and we
move on.  

The question of whether the IETF should accept and file a
disclosure statement that is "signed" only by title, especially
a title whose meaning is unclear outside the particular company,
ought to be largely separate from this discussion: it is really
an issue that I'd hope that the IETF Trust would discuss with
Counsel and then appropriately advise the Secretariat and the
community about how such statements should be handled.  If we
actually don't have any rules or guidance today, it may be
unreasonable to ask Huawei to amend their filing on that basis.

Note that removing the broad reciprocity provision from this
particular IPR disclosure /licensing statement ought to be less
problematic from Huawei's standpoint than potentially having the
patent (and potentially related ones) invalidated or rendered
unenforceable -- an action that would be completely outside our
control.

> On one point, however, I'm aligned:
> 
> On 01/26/2012 10:31 AM, John C Klensin wrote:
>> 
>> (3) A request to the company involved to remove the
>> reciprocity clause from the license stated in the disclosure
>> statement.  As a show of good faith, they should agree to
>> derive no benefit from the patent other than what praise
>> accrues from having it awarded.
> Indeed, this reciprocity clause is of the form that I used to
> complain to Cisco's IPR lawyer about Cisco making when I was
> at Cisco: It asserts the right of withdrawal of this license
> for *any* use of *any* patent against Huawei - that means that
> anyone who dares to depend on this license is effectively
> granting a license to *all* their patents to the holder of
> this patent.

> The proper scope of reciprocity clauses is a fertile ground
> for debate (and nearly impossible to hold a debate on,
> unfortunately), but this type is one that I am not happy to
> see.

While I agree, I think it is a separate discussion.  That
discussion probably needs to start with a core principle of the
IETF IPR policy that we do not constrain the conditions that can
be adopted and disclosed at all.  If we are not going to change
that, then Huawei (or Cisco, or many others) are certainly
permitted to insert such a clause.  If there is a problem in the
IETF, it is only that WGs may not have been sufficiently
diligent about evaluating the possible effects of such
provisions on the practice of potentially-standard technologies.


I think that, for this situation and any that might be similar
to it in the future, we need to concentrate on the particulars
of the situation and the degree to which it is appropriate for a
company to benefit from the inappropriate behavior of someone
who presumably works for them, is being sponsored by them to
participate in the IETF, etc.  I deliberately wrote my note so
that it could evolve into a general set of guidelines on such
issues should the community think that appropriate.

I'm also conflicted about the information (or lack thereof) that
we have available.  My personal sense of justice says that we
should really understand, for example, whether there is any
chance that the inventor was not aware of the patent
application.  Others have made similar suggestions.  On the
other hand, it is possible that trying to dig out and evaluate
that information would turn this situation into far more of a
judicial-like provision than I'm comfortable with.  Again,
advice from the Trust and Counsel would be very much in order if
it is feasible (and the reasons would be interesting and useful
information if it is not).

    john


    




From msk@cloudmark.com  Thu Jan 26 06:43:15 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F91D21F8622 for ; Thu, 26 Jan 2012 06:43:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level: 
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 L9NUNtcrXH9G for ; Thu, 26 Jan 2012 06:43:14 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id D095F21F861D for ; Thu, 26 Jan 2012 06:43:14 -0800 (PST)
Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 26 Jan 2012 06:43:13 -0800
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 26 Jan 2012 06:43:13 -0800
From: "Murray S. Kucherawy" 
To: IETF-Discussion 
Date: Thu, 26 Jan 2012 06:43:13 -0800
Subject: RE: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
Thread-Topic: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
Thread-Index: AczcAzqwcPgRAVVXS8Ok9GHzASP/4QANYeiw
Message-ID: 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <6.2.5.6.2.20120125134606.0b285800@resistor.net> <21749.1327565951.740855@puncture>
In-Reply-To: <21749.1327565951.740855@puncture>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 14:43:15 -0000

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of D=
ave Cridland
> Sent: Thursday, January 26, 2012 12:19 AM
> To: SM; Adrian Farrel; IETF-Discussion
> Subject: Re: Second Last Call:  08.txt> (Sieve Notification Mechanism: SIP MESSAGE) to Proposed
> Standard
>=20
> (e) The IETF formally demands a royalty free, reasonable and non-
> discriminatory license to the technology for anyone, for the purpose of
> implementing the specification.

Doesn't the IPR claim that was filed include one of those already?

-MSK

From msk@cloudmark.com  Thu Jan 26 06:43:49 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB6421F861D for ; Thu, 26 Jan 2012 06:43:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level: 
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 sbhXOAlZ+NLQ for ; Thu, 26 Jan 2012 06:43:49 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD2621F8603 for ; Thu, 26 Jan 2012 06:43:49 -0800 (PST)
Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 26 Jan 2012 06:43:48 -0800
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 26 Jan 2012 06:43:48 -0800
From: "Murray S. Kucherawy" 
To: "ietf@ietf.org" 
Date: Thu, 26 Jan 2012 06:43:48 -0800
Subject: RE: Violation of IETF process (was: Second Last	Call:  (Sieve	Notification	Mechanism: SIP MESSAGE) to Proposed Standard)
Thread-Topic: Violation of IETF process (was: Second Last	Call:  (Sieve	Notification	Mechanism: SIP MESSAGE) to Proposed Standard)
Thread-Index: AczcANLMHCJWTMDCQLGHbDEKx2t+cQAOATeg
Message-ID: 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <4F20AF20.40103@qualcomm.com> <6.2.5.6.2.20120125181850.0995e2d0@resistor.net> <03de01ccdbee$33ce28b0$9b6a7a10$@olddog.co.uk> <6.2.5.6.2.20120125215449.0c092680@resistor.net>
In-Reply-To: <6.2.5.6.2.20120125215449.0c092680@resistor.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 14:43:49 -0000

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of S=
M
> Sent: Wednesday, January 25, 2012 11:58 PM
> To: adrian@olddog.co.uk
> Cc: sieve@ietf.org; ietf@ietf.org
> Subject: RE: Violation of IETF process (was: Second Last Call:  ietf-sieve-notify-sip-message-08.txt> (Sieve Notification Mechanism:
> SIP MESSAGE) to Proposed Standard)
>=20
> The violation has a negative impact on the IETF (see comment from Dave
> Crocker on this thread).  It raises questions which should not be
> asked.

Oh, I don't agree with that last bit at all.


From msk@cloudmark.com  Thu Jan 26 06:50:05 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4EF21F8635 for ; Thu, 26 Jan 2012 06:50:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level: 
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 SRM772lC3Ft8 for ; Thu, 26 Jan 2012 06:50:05 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4922521F860E for ; Thu, 26 Jan 2012 06:50:05 -0800 (PST)
Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 26 Jan 2012 06:50:04 -0800
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 26 Jan 2012 06:50:04 -0800
From: "Murray S. Kucherawy" 
To: IETF-Discussion 
Date: Thu, 26 Jan 2012 06:50:04 -0800
Subject: RE: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
Thread-Topic: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
Thread-Index: AczcAzqwcPgRAVVXS8Ok9GHzASP/4QANYeiwAAA9b5A=
Message-ID: 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <6.2.5.6.2.20120125134606.0b285800@resistor.net> <21749.1327565951.740855@puncture> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 14:50:05 -0000

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of M=
urray S. Kucherawy
> Sent: Thursday, January 26, 2012 6:43 AM
> To: IETF-Discussion
> Subject: RE: Second Last Call:  08.txt> (Sieve Notification Mechanism: SIP MESSAGE) to Proposed
> Standard
>=20
> > (e) The IETF formally demands a royalty free, reasonable and non-
> > discriminatory license to the technology for anyone, for the purpose
> > of implementing the specification.
>=20
> Doesn't the IPR claim that was filed include one of those already?

Disregard; other posts in this thread since yours have educated me.

-MSK

From msk@cloudmark.com  Thu Jan 26 07:04:19 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739A721F859B for ; Thu, 26 Jan 2012 07:04:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level: 
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 SXHyUNV2s1JY for ; Thu, 26 Jan 2012 07:04:18 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5DADF21F8582 for ; Thu, 26 Jan 2012 07:04:18 -0800 (PST)
Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 26 Jan 2012 07:04:17 -0800
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 26 Jan 2012 07:04:17 -0800
From: "Murray S. Kucherawy" 
To: "ietf@ietf.org" 
Date: Thu, 26 Jan 2012 07:04:17 -0800
Subject: RE: Second	Last	Call:	 (Sieve	Not	ifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
Thread-Topic: Second	Last	Call:	 (Sieve	Not	ifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
Thread-Index: AczcM/3M+1bQMOQYSOGT10WBHRrstgABh52Q
Message-ID: 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com>	, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com>	<9E8747DFE73501D34065351E@PST.JCK.COM> <4F2139CE.3010508@alvestrand.no> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 15:04:19 -0000

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of J=
ohn C Klensin
> Sent: Thursday, January 26, 2012 6:08 AM
> To: Harald Alvestrand
> Cc: Pete Resnick; adrian@olddog.co.uk; sieve@ietf.org; ietf@ietf.org
> Subject: Re: Second Last Call:  08.txt> (Sieve Not ifica tion Mechanism: SIP MESSAGE) to Proposed
> Standard
>=20
> I'm also conflicted about the information (or lack thereof) that we
> have available.  My personal sense of justice says that we should
> really understand, for example, whether there is any chance that the
> inventor was not aware of the patent application.  Others have made
> similar suggestions.  On the other hand, it is possible that trying to
> dig out and evaluate that information would turn this situation into
> far more of a judicial-like provision than I'm comfortable with.
> Again, advice from the Trust and Counsel would be very much in order if
> it is feasible (and the reasons would be interesting and useful
> information if it is not).

As much as we try to bring to the attention of participants the contents of=
 BCPs 78 and 79, or The Tao of IETF, they are easy to overlook.  It's not i=
mpossible to conceive that someone writes a draft using XML, runs it throug=
h xml2rfc, and posts it without ever reading or even noticing the boilerpla=
te that it adds /and/ the documents it references.  That's a lot of reading=
 and, important as it is, people can get lost or even lazy.  The Note Well,=
 similarly, is actually a distillation of quite a lot of material that one =
needs to understand.

Thus, to my mind, it's entirely possible that this person simply didn't rea=
lize that a patent filing, possibly even with his own name on it, was germa=
ne to the IETF and its IPR policy.

And in a large corporation, I can similarly envision that the champion of s=
ome work into the IETF is not the same person, or even in the same group, a=
s the person making a patent filing on the same or related material, and in=
sufficient co-ordination exists between them.  I understand that part of wh=
at you're talking about is emphasizing the need to ensure such policies exi=
st, but I also understand that not every person or organization will have h=
ad the experience to know that it's important to establish such up front.

What I take away from this so far is that in the future I'll be far more li=
kely to ask "Are you totally sure this is IPR-claim-free?" when asked to su=
pport the advancement of some document (whether that's as a sponsoring AD s=
omeday, or a working group co-chair, or co-author, or editor, or even as an=
other participant).  It seems clear to me the BCPs and the draft boilerplat=
e will, alas, not always be sufficient.

-MSK

From adrian@olddog.co.uk  Thu Jan 26 07:26:03 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3934B21F869E; Thu, 26 Jan 2012 07:26:03 -0800 (PST)
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 HdDYmcZpYN-R; Thu, 26 Jan 2012 07:26:02 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCB921F869C; Thu, 26 Jan 2012 07:26:02 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0QFQ0eo016963;  Thu, 26 Jan 2012 15:26:00 GMT
Received: from 950129200 (50-76-52-225-ip-static.hfc.comcastbusiness.net [50.76.52.225]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0QFPv7q016951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Jan 2012 15:25:59 GMT
From: "Adrian Farrel" 
To: "'SM'" 
Subject: RE: Violation of IETF process (was: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard)
Date: Thu, 26 Jan 2012 15:25:55 -0000
Message-ID: <007f01ccdc3e$ce46a0c0$6ad3e240$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AczcPsfLBlK92TXNQSiBzRJyVE+x8A==
Content-Language: en-gb
Cc: sieve@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 15:26:03 -0000

> >Why is Qian Sun still listed on the front page as an author.
> >Wouldn't it be more
> >appropriate to move the name to the Acknowledgements section where the
> > text could read...
> 
> As editorship is a WG Chair decision, it is up to the SIEVE WG Chairs
> to comment on why Qian Sun is still listed on the front page as an author.
> 
> >Some of the text of this document was provided by Qian Sun who
> > violated IETF IPR process by not disclosing related IPR that he had
> > also authored and so is not listed as a named author of this document.
> 
> The above text does not mention company affiliation.

I have not made any statement about what the company has done.

> There is the following in the text in IPR statements:
> 
>    "Note: The individual submitting this template represents and
>     warrants that he or she is authorized by the Patent Holder to
>     agree to the above-selected licensing declaration."
> 
> The name provided in the IPR statement is "Director of licensing".

I don't view *disclosing* as a problem here. In fact disclosure is to be
encouraged.

My issue is with the individual. BCP 79 is very clear about individual
responsibilities wrt IPR that they are aware of.

It is the individual who breaks the IETF's IPR policy if they make contributions
when there is IPR that they are aware of that is not disclosed in a timely
fashion.

> The violation has a negative impact on the IETF (see comment from
> Dave Crocker on this thread).  It raises questions which should not be asked.

Questions that should not be asked should not, by definition, be asked.
I wonder if you are concerned about corporate and anti-trust issues.

AFAICS, this issue has nothing to do with that.

I do agree that sanctions applied to individuals should be proportionate and
should consider the circumstances. 

I am also interested in the discussion about whether moving an author's name
from the front page to the Acknowledgements (with an explanation) would have an
impact on discussions of IPR policy violation in court. This will need
professional legal advice - my feeling was that previous I-D versions would
still show the author as previously listed (including the revision of the I-D at
the time the IPR was disclosed), and that the note in the Acknowledgements
section and the discussion on IETF lists (e.g. the WG list) would provide
traceability on the reasoning.

But I come back to this point because I think it is important: the violation
here is of the individual contributor's responsibility under BCP79.

Cheers,
Adrian



From presnick@qualcomm.com  Thu Jan 26 08:10:48 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61BB21F8661; Thu, 26 Jan 2012 08:10:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.559
X-Spam-Level: 
X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 Ehfsvfv5JhCq; Thu, 26 Jan 2012 08:10:47 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 6567A21F8604; Thu, 26 Jan 2012 08:10:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327594247; x=1359130247; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F217A7C.6080908@qualcomm.com>|Date:=20Th u,=2026=20Jan=202012=2010:08:28=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20John=20C=20Klensin=20|CC:=20,=20,=20|Subject:=20Re:=20Second=20Last=09Cal l:=09=0D=0A =20(Sieve=09Notifica=09tion=20Mechanism:=20SIP=20MESSAGE) =20to=20Proposed=20Standard|References:=20<20120125201714 .3903.82295.idtracker@ietfa.amsl.com>=09<4F2075BE.5070201 @nostrum.com>=09,=09<033901ccdbab$6bae0900$430a1b00$@oldd og.co.uk>=09=09<4F208AEF.5060406@qualcomm .com>=20<9E8747DFE73501D34065351E@PST.JCK.COM> |In-Reply-To:=20<9E8747DFE73501D34065351E@PST.JCK.COM> |Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.48.1]; bh=s1p9ZSNgTQ8FhGxnCDIVkVUWprNeJN8aIIPLv+ZGzrQ=; b=BPB/rUi2xw6HTQia9U/Oc+83ZEEZVz3zbDKtd19D15oQyUulcceTurWT 1K8GrlDyCx5h0Yy4/r3mUkKZYzThlj4Q011ZCnbVUr9f15CDztjQKiWE/ CmZLsSaPL/XKCwXrUtScGlJDjkzU4PdlNItGYQfJgheKh9OP5bhXQfq0c s=;
X-IronPort-AV: E=McAfee;i="5400,1158,6600"; a="155798045"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 26 Jan 2012 08:10:40 -0800
X-IronPort-AV: E=Sophos;i="4.71,574,1320652800"; d="scan'208";a="157179713"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 26 Jan 2012 08:10:39 -0800
Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 26 Jan 2012 08:08:31 -0800
Message-ID: <4F217A7C.6080908@qualcomm.com>
Date: Thu, 26 Jan 2012 10:08:28 -0600
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: John C Klensin 
Subject: Re: Second Last	Call:	 (Sieve	Notifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com>	<4F2075BE.5070201@nostrum.com>	, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>		<4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM>
In-Reply-To: <9E8747DFE73501D34065351E@PST.JCK.COM>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.48.1]
Cc: adrian@olddog.co.uk, sieve@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 16:10:49 -0000

As I've mentioned to others, since I'm one of the people who will have 
to judge the consensus on this question, my comments will remain 
strictly based on the facts of the events as I know them and on the 
relevant IETF procedures. It is up to the IETF community to decide on 
what the appropriate course of action shall be. That said, I have some 
comments and questions:

On 1/26/12 3:31 AM, John C Klensin wrote:

> It seems to me that a key question here is whether the original
> author's decision to not disclose was made in violation of
> company policy or whether the sequence of posting the I-D,
> getting the document through the WG and Last Call, and then
> posting the disclosure is a matter of company policy.

We were told by the other company employees who facilitated the 
disclosures, at the time of the disclosures, that this was strictly an 
individual's failure to comply with the IETF IPR Policy, that the author 
in question claims not to have understood the IETF IPR Policy, and that 
the company proceeded to make these disclosures as soon as it discovered 
that this IPR existed. I have no information to contradict that claim.

> Consequently, I believe that at least the following should be
> required:
>
> (1) Revision of the IPR statement so it identifies the
> responsible individual by name, department, and title.  I do not
> believe that the rather anonymous "Director of Licensing" is
> compliant with the intent of the IPR disclosure rules.   I will
> leave it to the lawyers to advise on whether a document issued
> without the name (not just title) of a responsible individual
> would even be held to be valid in the various jurisdictions in
> which the patent might be recognized.
>    

Are you asking that the IPR statements be updated with the name, 
department, and title of the "Director of Licensing", or that of the 
author of the documents and patents in question? It seems to me that the 
former is a procedural question that is separate from the disposition of 
these particular documents, and seems like a reasonable requirement for 
any IPR disclosure. If you're asking for the latter, are you asking that 
the sanction against the author be a new obligation on the author? 
Section 6 of RFC 3979 clearly says, "A participant's obligation to make 
a disclosure is also considered satisfied if the IPR owner or the 
participant's employer or sponsor makes an appropriate disclosure in 
place of the participant doing so."

> (2) A request to the company involved for someone who can
> formally speak for that company to publicly clarify that this
> sequence of behavior occurred in violation of company policy.
> If there are internal rewards to individuals for filing and/or
> being awarded patents, I assume that a decision that the actions
> violate company policy would cause such awards to be withheld in
> this case, even though the IETF would have no way to verify
> whether or not that occurred.
>    

The IETF Chair has in the past sent messages to companies to inquire 
about their handling of IPR disclosures, so I imagine such a message 
could be sent if the IETF community desires it.

> (3) A request to the company involved to remove the reciprocity
> clause from the license stated in the disclosure statement.  As
> a show of good faith, they should agree to derive no benefit
> from the patent other than what praise accrues from having it
> awarded.
>    

I'll ask to bring this topic up with the IETF attorney. I am pretty sure 
we can *ask* that they do this as a show of good faith. I am also pretty 
certain that we can't negotiate the terms of a license agreement.

> (4) Removal of the offending individual from the list of authors
> to the acknowledgments with text similar to that suggested by
> Adrian.  Unless the company involved is willing to provide the
> clarification suggested in (2) above, and possibly the license
> modification suggested in (3) above, all names of authors
> associated with that company should be removed to the
> acknowledgements and the company affiliation explicitly
> identified there.  In either case, this should be viewed as a
> response to a policy violation and not entangled with any more
> general discussion of listed authors on I-Ds or RFCs.
>    

Of course, removal of individual document editors is well within the 
rights and responsibilities of the chairs, so if this is the consensus 
of the IETF, I am sure it can be done. I would like you to elaborate on 
the issue of the authors who are employees of the company but *not* the 
author of the patent in question. Are you saying that their names should 
be removed because, as co-workers of the author in question, they ought 
to have known (or been more diligent in confirming) that the IPR existed 
and therefore should be sanctioned for failing to comply with the IPR 
rules, or are you saying that this is a sanction that should be levied 
against the company and therefore its employees? I will note that RFC 
3979 does not put a responsibility on individual participants to go 
discover IPR that may exist, nor does it make any overt requirements of 
companies since it applies only to the individual participants in the 
IETF (caveat the recognitions in sections 6.6 and 7).

> (5) Unless the clarification suggested in (2) can be provided,
> each IETF participant who is associated with the relevant
> company and who is in an IETF-related leadership or
> decision-making position (WG Chairs; Editors; IESG, IAB, IAOC,
> Nomcom, members; etc.) should be asked to make a conscientious
> personal review as to whether this type of action sufficiently
> compromises his or her position that resignation or some other
> action would be appropriate and, as appropriate, to review IETF
> policies with whatever management chains are relevant.  I am
> _not_ suggesting that anyone be asked to resign, only that they
> engage in careful consideration of the issues and their
> implications.
>    

I believe this last one is outside of the scope of the decisions the 
IETF has to take regarding the disposition of the particular documents. 
It may indeed be reasonable for every IETF participant to review the 
policies and actions of their own employer as they relate to IETF 
participation and make a conscientious decision whether they can 
continue to participate in the IETF, whatever their role, given those 
policies and procedures.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From sm@resistor.net  Thu Jan 26 08:53:46 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360EF21F85C0; Thu, 26 Jan 2012 08:53:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.619
X-Spam-Level: 
X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 sChsI+53ZFVg; Thu, 26 Jan 2012 08:53:44 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E2621F85BD; Thu, 26 Jan 2012 08:53:43 -0800 (PST)
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 q0QGrZaB029089; Thu, 26 Jan 2012 08:53:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327596822; i=@resistor.net; bh=4bHfjVN59IGoV4GAq8SfGsSVqD7wE5Yi2FwXWgPiQLg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=iY5Ncpw8sPLmywiDtzH9OoUk7Wvu4OBiKKAp/QVcfXynkhu3xy29q4txwaJ1NMk8J xdtL0XBtid4NDRYkCG+DFvI/R4PzCTZcaLNFckDV0C3i8AdKNTPRhBqC65R0sDLwSg p/PRZcLKaU4sdN6fJdDnbzEGrp0BAqUjAVykX8Gw=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327596822; i=@resistor.net; bh=4bHfjVN59IGoV4GAq8SfGsSVqD7wE5Yi2FwXWgPiQLg=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Y7p3esm+6ZkXJXGMTF8I8yAQM71ZlMMtLwc39l11lYBNwiyzbtJtUl5BIlvPOW0GN zZ4OXOKkRogIEc6XSE4Q5bEloNBQjYH3yNK4C1BmU7591eE9icll2ASesQdR7Ii7av KF4ry7nKofShkVus4CNEiiYaCFHtlYHCYpKVdfNI=
Message-Id: <6.2.5.6.2.20120126073506.0b20a180@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 26 Jan 2012 08:51:14 -0800
To: adrian@olddog.co.uk
From: SM 
Subject: RE: Violation of IETF process (was: Second Last  Call:  (Sieve  Notification Mechanism: SIP MESSAGE) to Proposed Standard)
In-Reply-To: <007f01ccdc3e$ce46a0c0$6ad3e240$@olddog.co.uk>
References: <007f01ccdc3e$ce46a0c0$6ad3e240$@olddog.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: sieve@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 16:53:46 -0000

At 07:25 26-01-2012, Adrian Farrel wrote:
>I have not made any statement about what the company has done.

Ok.

>I don't view *disclosing* as a problem here. In fact disclosure is to be
>encouraged.

I too don't view disclosing as a problem here.  It is possible to 
compare the statement with other such statements and see the differences.

>My issue is with the individual. BCP 79 is very clear about individual
>responsibilities wrt IPR that they are aware of.

Yes.

>It is the individual who breaks the IETF's IPR policy if they make 
>contributions
>when there is IPR that they are aware of that is not disclosed in a timely
>fashion.

Yes.

>Questions that should not be asked should not, by definition, be asked.
>I wonder if you are concerned about corporate and anti-trust issues.

I am concerned that individuals who are sponsored by their company 
will end up being the escape goat.  I am concerned that the Note Well 
might end up being ignored.  If individuals do not understand the 
Note Well, it is unlikely that they will understand any future 
antitrust policy.

>I am also interested in the discussion about whether moving an author's name
>from the front page to the Acknowledgements (with an explanation) 
>would have an
>impact on discussions of IPR policy violation in court. This will need
>professional legal advice - my feeling was that previous I-D versions would

Yes.

>But I come back to this point because I think it is important: the violation
>here is of the individual contributor's responsibility under BCP79.

That is the point being discussed.

Regards,
-sm 


From sm@resistor.net  Thu Jan 26 09:34:56 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591BE21F8667; Thu, 26 Jan 2012 09:34:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.619
X-Spam-Level: 
X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 UbTTrThW4R-p; Thu, 26 Jan 2012 09:34:55 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E9E21F8661; Thu, 26 Jan 2012 09:34:54 -0800 (PST)
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 q0QHYlW1013941; Thu, 26 Jan 2012 09:34:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327599293; i=@resistor.net; bh=FZXzlmOaSWWS7ThwfOdR0BCc9144/yc53Ipe2hPr0gI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=Qyy1q7FC0vtuwvtZl9JFmDDS7DIw5iqDEy30JSGAt4MXHvIN0kYvxIDhf2QOJsu9T KzcVtdosB+uFmGjmgB77igWJWSvNdBeCmdReanfbhO9IPwdI5qm6AVxY9n3WESCDjC GPDfnHwpc9k9lNLvEWVkeWROHCF0hPN47RmiFue8=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327599293; i=@resistor.net; bh=FZXzlmOaSWWS7ThwfOdR0BCc9144/yc53Ipe2hPr0gI=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=pA53uPvxi1GKS7/t+do6S+Ryxg8RZtyCOtblYcW73enA6NgxWU/TROxHEa3yePZng idRcyaezqhx/vDImID8FQxrW8mnZKGwwMIz1/crXUZPb1445r6x50WLkVvsuvf1dDT xmwKl7/cRVOiSRuygNGDaa4O/74DF+L7GmD23RlU=
Message-Id: <6.2.5.6.2.20120126085545.0b1fa288@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 26 Jan 2012 09:15:00 -0800
To: Pete Resnick 
From: SM 
Subject: Re: Second Last	Call:	 (Sieve	Notifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
In-Reply-To: <4F217A7C.6080908@qualcomm.com>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM> <4F217A7C.6080908@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: sieve@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 17:34:56 -0000

Hi Pete,
At 08:08 26-01-2012, Pete Resnick wrote:
>As I've mentioned to others, since I'm one of the people who will 
>have to judge the consensus on this question, my comments will 
>remain strictly based on the facts of the events as I know them and 
>on the relevant IETF procedures. It is up to the IETF community

The status of the memo in the drafts have this statement:

   "This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79."

Have the authors been asked whether they have any issue with the above?

The is a question in the write-up: "Has an IPR disclosure related to 
this document been filed?"  Has the Document Shepherd been asked 
about that before the Second Last Call?

The minutes from the last WG session does not mention who chaired the 
session.  Did the WG Chair bring the Note Well to the attention of the WG?

Regards,
-sm 


From john-ietf@jck.com  Thu Jan 26 09:37:17 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A1721F84B9; Thu, 26 Jan 2012 09:37:17 -0800 (PST)
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 UULw1hBwuw57; Thu, 26 Jan 2012 09:37:16 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 05D2821F84AA; Thu, 26 Jan 2012 09:37:16 -0800 (PST)
Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1RqTCb-0005l9-4D; Thu, 26 Jan 2012 12:33:37 -0500
Date: Thu, 26 Jan 2012 12:37:06 -0500
From: John C Klensin 
To: Pete Resnick 
Subject: Re: Second Last	Call:	 (Sieve	Notifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
Message-ID: 
In-Reply-To: <4F217A7C.6080908@qualcomm.com>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> ,	<033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM> <4F217A7C.6080908@qualcomm.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: adrian@olddog.co.uk, sieve@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 17:37:17 -0000

--On Thursday, January 26, 2012 10:08 -0600 Pete Resnick
 wrote:

> As I've mentioned to others, since I'm one of the people who
> will have to judge the consensus on this question, my comments
> will remain strictly based on the facts of the events as I
> know them and on the relevant IETF procedures. It is up to the
> IETF community to decide on what the appropriate course of
> action shall be. That said, I have some comments and questions:
> 
> On 1/26/12 3:31 AM, John C Klensin wrote:
> 
>> It seems to me that a key question here is whether the
>> original author's decision to not disclose was made in
>> violation of company policy or whether the sequence of
>> posting the I-D, getting the document through the WG and Last
>> Call, and then posting the disclosure is a matter of company
>> policy.
> 
> We were told by the other company employees who facilitated
> the disclosures, at the time of the disclosures, that this was
> strictly an individual's failure to comply with the IETF IPR
> Policy, that the author in question claims not to have
> understood the IETF IPR Policy, and that the company proceeded
> to make these disclosures as soon as it discovered that this
> IPR existed. I have no information to contradict that claim.

Excellent.   I had hoped that was the situation.  It obviously
makes things much easier (and some of my earlier comments
irrelevant).   With all the effort we go to ("Note Well" and
otherwise) to be sure that people are informed about the policy,
I have trouble generating sympathy for someone who says "didn't
underatand", but that is another matter (and perhaps just my
problem).

>> Consequently, I believe that at least the following should be
>> required:
>> 
>> (1) Revision of the IPR statement so it identifies the
>> responsible individual by name, department, and title.  I do
>> not believe that the rather anonymous "Director of Licensing"
>> is compliant with the intent of the IPR disclosure rules.   I
>> will leave it to the lawyers to advise on whether a document
>> issued without the name (not just title) of a responsible
>> individual would even be held to be valid in the various
>> jurisdictions in which the patent might be recognized.
>>    
> 
> Are you asking that the IPR statements be updated with the
> name, department, and title of the "Director of Licensing", or
> that of the author of the documents and patents in question?

The former.

> It seems to me that the former is a procedural question that
> is separate from the disposition of these particular
> documents, and seems like a reasonable requirement for any IPR
> disclosure.

That is correct.  I believe I suggested in a later note that
this is an area to which it would be good if the Trust paid some
attention and advised the Secretariat and others accordingly.

>> (2) A request to the company involved for someone who can
>> formally speak for that company to publicly clarify that this
>> sequence of behavior occurred in violation of company policy.
>> If there are internal rewards to individuals for filing and/or
>> being awarded patents, I assume that a decision that the
>> actions violate company policy would cause such awards to be
>> withheld in this case, even though the IETF would have no way
>> to verify whether or not that occurred.
> 
> The IETF Chair has in the past sent messages to companies to
> inquire about their handling of IPR disclosures, so I imagine
> such a message could be sent if the IETF community desires it.

That was my assumption.  On the other hand, if it is already
clear that this was either a misunderstanding, a violation of
company policy, or both, it might not be necessary.

>> (3) A request to the company involved to remove the
>> reciprocity clause from the license stated in the disclosure
>> statement.  As a show of good faith, they should agree to
>> derive no benefit from the patent other than what praise
>> accrues from having it awarded.

> I'll ask to bring this topic up with the IETF attorney. I am
> pretty sure we can *ask* that they do this as a show of good
> faith. I am also pretty certain that we can't negotiate the
> terms of a license agreement.

I was only suggesting asking.  If they say "no", which they
obviously have the right to do, it is, as others have pointed
out, the WG's problem to consider what that is an issue.  If the
WG is indifferent on the issue, it seems to me that the relevant
AD has a problem, but that problem is _not_ bound to the
disclosure issue.

>> (4) Removal of the offending individual from the list of
>> authors to the acknowledgments with text similar to that
>> suggested by Adrian.  Unless the company involved is willing
>> to provide the clarification suggested in (2) above, and
>> possibly the license modification suggested in (3) above, all
>> names of authors associated with that company should be
>> removed to the acknowledgements and the company affiliation
>> explicitly identified there.  In either case, this should be
>> viewed as a response to a policy violation and not entangled
>> with any more general discussion of listed authors on I-Ds or
>> RFCs.

> Of course, removal of individual document editors is well
> within the rights and responsibilities of the chairs, so if
> this is the consensus of the IETF, I am sure it can be done. 

That was my assumption.

> I
> would like you to elaborate on the issue of the authors who
> are employees of the company but *not* the author of the
> patent in question. Are you saying that their names should be
> removed because, as co-workers of the author in question, they
> ought to have known (or been more diligent in confirming) that
> the IPR existed and therefore should be sanctioned for failing
> to comply with the IPR rules, or are you saying that this is a
> sanction that should be levied against the company and
> therefore its employees?

If the other authors from that company have already told us that
they were not aware of the patent application until very late in
the process and that they moved diligently toward getting an
appropriate disclosure filed as soon as they did find out, my
suggestion is moot.

I was concerned about the (thoroughly unlikely in this case)
possibility that the other authors from that company were
personally aware of the IPR but had been, e.g., advised that
they were not to make the disclosure because someone else would
take responsibility for it.

> I will note that RFC 3979 does not
> put a responsibility on individual participants to go discover
> IPR that may exist, nor does it make any overt requirements of
> companies since it applies only to the individual participants
> in the IETF (caveat the recognitions in sections 6.6 and 7).

Understood.  My separate concerns about the implications of that
policy should a company ever choose to deliberately hide
relevant IPR from IETF participants do not apply to this case
and should not be part of the discussion.
 
>> (5) Unless the clarification suggested in (2) can be provided,
>> each IETF participant who is associated with the relevant
>> company and who is in an IETF-related leadership or
>> decision-making position (WG Chairs; Editors; IESG, IAB, IAOC,
>> Nomcom, members; etc.) should be asked to make a conscientious
>> personal review as to whether this type of action sufficiently
>> compromises his or her position that resignation or some other
>> action would be appropriate and, as appropriate, to review
>> IETF policies with whatever management chains are relevant.
>> I am _not_ suggesting that anyone be asked to resign, only
>> that they engage in careful consideration of the issues and
>> their implications.

> I believe this last one is outside of the scope of the
> decisions the IETF has to take regarding the disposition of
> the particular documents. It may indeed be reasonable for
> every IETF participant to review the policies and actions of
> their own employer as they relate to IETF participation and
> make a conscientious decision whether they can continue to
> participate in the IETF, whatever their role, given those
> policies and procedures.

Complete agreement.  I would, for the record, make much the same
suggestion about behavior in other situations that appeared to
push the boundaries of codes of professional ethics of the
professional societies of which many of us are members.  Like
the IETF's IPR rules, those provisions are intended to be taken
seriously rather than as decoration that can be safely ignored.
The issue is an individual one, not an IETF one, and the current
issue is relevant only insofar as it should encourage all of us
--not just those involved in this document-- to take our various
personal and professional obligations seriously and to consider
the implications of circumstances in which various of them might
come into conflict.

best,
    john


From stpeter@stpeter.im  Thu Jan 26 09:40:23 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2095621F86C2 for ; Thu, 26 Jan 2012 09:40:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.647
X-Spam-Level: 
X-Spam-Status: No, score=-102.647 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 xtbVuo8mIJDQ for ; Thu, 26 Jan 2012 09:40:22 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8645B21F84D6 for ; Thu, 26 Jan 2012 09:40:22 -0800 (PST)
Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B593B40058; Thu, 26 Jan 2012 10:50:10 -0700 (MST)
Message-ID: <4F219004.4070601@stpeter.im>
Date: Thu, 26 Jan 2012 10:40:20 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: SM 
Subject: encouraging compliance with IPR disclosure rules
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM> <4F217A7C.6080908@qualcomm.com> <6.2.5.6.2.20120126085545.0b1fa288@resistor.net>
In-Reply-To: <6.2.5.6.2.20120126085545.0b1fa288@resistor.net>
X-Enigmail-Version: 1.3.4
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Pete Resnick , ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 17:40:23 -0000

[ - sieve@ietf.org ]

On 1/26/12 10:15 AM, SM wrote:
> Hi Pete,
> At 08:08 26-01-2012, Pete Resnick wrote:
>> As I've mentioned to others, since I'm one of the people who will have
>> to judge the consensus on this question, my comments will remain
>> strictly based on the facts of the events as I know them and on the
>> relevant IETF procedures. It is up to the IETF community
> 
> The status of the memo in the drafts have this statement:
> 
>   "This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79."
> 
> Have the authors been asked whether they have any issue with the above?
> 
> The is a question in the write-up: "Has an IPR disclosure related to
> this document been filed?"  Has the Document Shepherd been asked about
> that before the Second Last Call?
> 
> The minutes from the last WG session does not mention who chaired the
> session.  Did the WG Chair bring the Note Well to the attention of the WG?

In my opinion, we need to think more creatively about ways to encourage
compliance with the IPR disclosure rules. Tim Polk and I wrote an I-D on
the topic last year. Feedback would be welcome.

http://tools.ietf.org/html/draft-polk-ipr-disclosure-00

Peter

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



From dworley@avaya.com  Thu Jan 26 11:28:14 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A51F21F86DB for ; Thu, 26 Jan 2012 11:28:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.361
X-Spam-Level: 
X-Spam-Status: No, score=-103.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, 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 9Er68HN4sXet for ; Thu, 26 Jan 2012 11:28:14 -0800 (PST)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id ADEF221F855F for ; Thu, 26 Jan 2012 11:28:13 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAC2oIU+HCzI1/2dsb2JhbABCrk6BBYFyAQEBAQIBEigxDAIFCwIBCA0BByEFCzIlAQEEDgUIDA6HWpwum0WJGAsHFDAGBQQHBwMDgwOBRgmCUWMEiD+SWYx2
X-IronPort-AV: E=Sophos;i="4.71,575,1320642000"; d="scan'208";a="288248170"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Jan 2012 14:28:10 -0500
Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Jan 2012 14:14:26 -0500
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 26 Jan 2012 14:28:07 -0500
From: "Worley, Dale R (Dale)" 
To: Pete Resnick 
Date: Thu, 26 Jan 2012 14:25:33 -0500
Subject: RE: Second Last Call:	 (Sieve	Notification Mechanism: SIP MESSAGE) to Proposed Standard
Thread-Topic: Second Last Call:	 (Sieve	Notification Mechanism: SIP MESSAGE) to Proposed Standard
Thread-Index: Aczbtf5e2/6nChNpRf+hHzHIzTXhtgAqkcqQ
Message-ID: 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com>, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> , <4F208AEF.5060406@qualcomm.com>
In-Reply-To: <4F208AEF.5060406@qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ietf@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 19:28:14 -0000

> From: Pete Resnick [presnick@qualcomm.com]
>=20
> Before posting this Last Call (and the similar one for
> draft-ietf-sieve-convert), the documents *were* returned to the SIEVE WG
> to review the situation. With minimal complaint from the WG and no
> indication that the WG wished to change their decision on the documents,
> the chairs asked that I simply put it to the entire community as a Last
> Call. So I believe anything other than "go ahead with publication as is"
> will be done only if that is the consensus of the IETF community as a
> whole. The SIEVE chairs and I will be monitoring the discussion.

OK, that resolves all my objections.  The "higher pay grades" (IESG
and IAB) may have policy concerns, but that is not my expertise.

Dale

From presnick@qualcomm.com  Thu Jan 26 11:39:33 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636A421F8630 for ; Thu, 26 Jan 2012 11:39:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.56
X-Spam-Level: 
X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 yfKsblipAMb8 for ; Thu, 26 Jan 2012 11:39:32 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id B454D21F8629 for ; Thu, 26 Jan 2012 11:39:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327606772; x=1359142772; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F21ABF2.7040002@qualcomm.com>|Date:=20Th u,=2026=20Jan=202012=2013:39:30=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20"Worley,=20Dale=20R=20(Dale)" =20|CC:=20"ietf@ietf.org"=20|Subject:=20Re:=20Second=20Last=20Call:=09=0D=0A=20(Sieve=09Notif ication=20Mechanism:=20SIP=20MESSAGE)=20to=20Proposed=20S tandard|References:=20<20120125201714.3903.82295.idtracke r@ietfa.amsl.com>=09<4F2075BE.5070201@nostrum.com>,=09<03 3901ccdbab$6bae0900$430a1b00$@olddog.co.uk>=09,=09<4F208AEF.5060406@qualcomm.com>=20|In-Reply-To:=20|Content-Type:=20text/p lain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.39.5]; bh=JyCniYZsLsTADcNMGbAxDnTGpmEOrqq0TieM3bxYMrE=; b=CVE9q1DNglrwstLPls9ZxLeJRSBxx++jAFIx1n/87aW9TCZqRX/mU6ND c7wzE7+pjU+4umDHx7cpGUYDN07U6o0sPYFIBxpZo0fMU8EPKAC2z0ltp uXOvVFvDmGd5KM0vepfs3hF//ARM4GFS0LKK6tYe0yLFawI8KHMAuY6NC 8=;
X-IronPort-AV: E=McAfee;i="5400,1158,6601"; a="155863105"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 26 Jan 2012 11:39:32 -0800
X-IronPort-AV: E=Sophos;i="4.71,574,1320652800"; d="scan'208";a="245873325"
Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 26 Jan 2012 11:39:32 -0800
Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 26 Jan 2012 11:39:31 -0800
Message-ID: <4F21ABF2.7040002@qualcomm.com>
Date: Thu, 26 Jan 2012 13:39:30 -0600
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: "Worley, Dale R (Dale)" 
Subject: Re: Second Last Call:	 (Sieve	Notification Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com>	<4F2075BE.5070201@nostrum.com>, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>	, <4F208AEF.5060406@qualcomm.com> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.39.5]
Cc: "ietf@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 19:39:33 -0000

On 1/26/12 1:25 PM, Worley, Dale R (Dale) wrote:

> OK, that resolves all my objections.  The "higher pay grades" (IESG
> and IAB) may have policy concerns, but that is not my expertise.
>    

Just in case others are having similar thoughts:

The IESG and IAB are *not* the ones that get to make the decision about 
what ought to be done here. The community needs to come to a consensus 
about the right outcome and the leadership folks will judge that 
consensus and instantiate whatever actions need to be taken. It's 
certainly OK if you feel you don't have enough information yet to decide 
what the appropriate action is, but if you're a member of this 
community, it is your responsibility to contribute to the decision in 
the end. You may decide that the conversation on the list has concluded 
the way you like; you're not required to post just to say that you 
agree. But don't expect the leadership to make this decision for you. We 
will give guidance as needed, but it's your decision.

I'll post my understanding of the consensus as we go along. So far, I've 
seen a few suggestions about the disposition of the documents, sanctions 
on the author(s), and requests to be made to the employer of the 
author(s). But I've certainly not seen enough to declare a consensus yet.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From sm@resistor.net  Thu Jan 26 11:40:59 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA50421F8666 for ; Thu, 26 Jan 2012 11:40:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.618
X-Spam-Level: 
X-Spam-Status: No, score=-102.618 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 OhZUMfDLhCHM for ; Thu, 26 Jan 2012 11:40:57 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D22921F8630 for ; Thu, 26 Jan 2012 11:40:57 -0800 (PST)
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 q0QJenmB018037; Thu, 26 Jan 2012 11:40:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327606856; i=@resistor.net; bh=PdVvFCJUNomJAVypm/r7cK4zgtD5ZQESvcT0TTCE9D8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=gYJ4gKBYnNmWARMM5+0GSl6SY+m5mbcxamLj7hF/+3wzDjdcBOOl79zNtqrV7m+ix r8szESQEiY91PkSgLcd0rY1MM2pfXSpHEBWqEnDY9GiDngxyM2vfamga4DNVwZJU5s TLzi7ADqO6ZO+ttcJ95oOy1YdAOUnxcrhTM3m+fU=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327606856; i=@resistor.net; bh=PdVvFCJUNomJAVypm/r7cK4zgtD5ZQESvcT0TTCE9D8=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=xbmsiIp0nWg/hGdrhn4YnZE85TmCgtGJEh4ZgfIwrWHad5FfzJUJeb2d9Ev89+iXd JGGpcytSxnXIv5+VUECKV5Qi/y62lkjM8UjzEOrEowSGrL0ytPFv16Cv3YbQ4pjvDs 5hGGYDnCYTA3qJM3raG2l6jtuHGl/8F8BNeDPZx8=
Message-Id: <6.2.5.6.2.20120126100436.0b2262b8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 26 Jan 2012 11:01:16 -0800
To: Peter Saint-Andre 
From: SM 
Subject: Re: encouraging compliance with IPR disclosure rules
In-Reply-To: <4F219004.4070601@stpeter.im>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM> <4F217A7C.6080908@qualcomm.com> <6.2.5.6.2.20120126085545.0b1fa288@resistor.net> <4F219004.4070601@stpeter.im>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Pete Resnick , ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 19:40:59 -0000

Hi Peter,
At 09:40 26-01-2012, Peter Saint-Andre wrote:
>In my opinion, we need to think more creatively about ways to encourage
>compliance with the IPR disclosure rules. Tim Polk and I wrote an I-D on
>the topic last year. Feedback would be welcome.
>
>http://tools.ietf.org/html/draft-polk-ipr-disclosure-00

 From the draft:

   "To support the efficient development of IETF standards and
    avoid unnecessary delays, chairs and ADs should look for
    opportunities to promote awareness and compliance with the
    IETF's IPR policies."

WG Chairs interact with IETF participants more often than ADs.  It is 
not clear whether it is their responsibility to promote awareness and 
compliance.  The IESG could ask two WG Chairs, chosen at random, when 
it meets with the WG Chairs to comment on what they did to promote awareness.

Some points in the draft, such as the two-step approach to confirm 
compliance may help to catch issues before they become a concern.

Regards,
-sm 


From tglassey@earthlink.net  Thu Jan 26 11:54:18 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BA621F86DC for ; Thu, 26 Jan 2012 11:54:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.348
X-Spam-Level: 
X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=-0.749, 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 vfBSVAMSioGM for ; Thu, 26 Jan 2012 11:54:18 -0800 (PST)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 2B78021F862A for ; Thu, 26 Jan 2012 11:54:18 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=RmES6yDNXYLZXGeQ1uDq9iW9PjoCcmB5QPoNkxYIygq7q23uu68n/d8SXocMT2uD; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Opacus-Archived:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [67.180.133.66] (helo=[192.168.1.100]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RqVOj-0002ph-Oh for ietf@ietf.org; Thu, 26 Jan 2012 14:54:17 -0500
Message-ID: <4F21AF66.4050803@earthlink.net>
Date: Thu, 26 Jan 2012 11:54:14 -0800
From: todd glassey 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Violation of IETF process
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <4F20AF20.40103@qualcomm.com> <6.2.5.6.2.20120125181850.0995e2d0@resistor.net> <03de01ccdbee$33ce28b0$9b6a7a10$@olddog.co.uk> <6.2.5.6.2.20120125215449.0c092680@resistor.net>
In-Reply-To: <6.2.5.6.2.20120125215449.0c092680@resistor.net>
X-Opacus-Archived: none
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7972992e79c3a80b6cfb1663d0bf4e5b65350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 67.180.133.66
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 19:54:18 -0000

On 1/25/2012 11:57 PM, SM wrote:
> Hi Adrian,
> At 21:48 25-01-2012, Adrian Farrel wrote:
>> Why is Qian Sun still listed on the front page as an author. Wouldn't
>> it be more
>> appropriate to move the name to the Acknowledgements section where the
>> text
>> could read...
> 
> As editorship is a WG Chair decision, it is up to the SIEVE WG Chairs to
> comment on why Qian Sun is still listed on the front page as an author.
> 
>> Some of the text of this document was provided by Qian Sun who
>> violated IETF IPR
>> process by not disclosing related IPR that he had also authored and so
>> is not
>> listed as a named author of this document.
> 
> The above text does not mention company affiliation.
> 
> There is the following in the text in IPR statements:
> 
>   "Note: The individual submitting this template represents and
>    warrants that he or she is authorized by the Patent Holder to
>    agree to the above-selected licensing declaration."
> 
> The name provided in the IPR statement is "Director of licensing".
> 
> The violation has a negative impact on the IETF (see comment from Dave
> Crocker on this thread).  It raises questions which should not be asked.
> 
> Regards,
> -sm

It actually speaks to why total transparency is needed. Anytime anyone
submits anything they need to disclose who they are and who they
represent. What authority they have and this is a serious issue since it
has legal ramifications.

The IETF has long ignored these requirements by claiming it was too
upright for those types of controls to be needed and clearly that simply
is not true.

IMHO - this is the reason that anyone can ask anyone else who they are
representing here. The IETF has no "covert participation" exceptions as
far as I know and in the world if legally protect-able IP everything has
to be defined.


T

> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 


-- 
Todd S. Glassey
This is from my personal email account and any materials from this
account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.

From tglassey@earthlink.net  Thu Jan 26 12:41:56 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BF021F872E for ; Thu, 26 Jan 2012 12:41:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.241
X-Spam-Level: 
X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=-0.642, 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 26mLlGF3BZBX for ; Thu, 26 Jan 2012 12:41:55 -0800 (PST)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 5B39321F872D for ; Thu, 26 Jan 2012 12:41:55 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=EUoC3hKAMXMmgUO3EhySPTnC3C977Gp5YEKX+Gexpqzpj8Fy+OFBhBb76gFsHVVA; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Opacus-Archived:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [67.180.133.66] (helo=[192.168.1.100]) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RqW8o-0004jZ-RS; Thu, 26 Jan 2012 15:41:54 -0500
Message-ID: <4F21BA8F.6000303@earthlink.net>
Date: Thu, 26 Jan 2012 12:41:51 -0800
From: todd glassey 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: SM , IETF Discussion Mailing List 
Subject: Re: Second Last	Call:	 (Sieve	Notifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM> <4F217A7C.6080908@qualcomm.com> <6.2.5.6.2.20120126085545.0b1fa288@resistor.net>
In-Reply-To: <6.2.5.6.2.20120126085545.0b1fa288@resistor.net>
X-Opacus-Archived: none
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79c64cc02ea967bcf6a116a25bb24b82de350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 67.180.133.66
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 20:41:56 -0000

On 1/26/2012 9:15 AM, SM wrote:
> Hi Pete,
> At 08:08 26-01-2012, Pete Resnick wrote:
>> As I've mentioned to others, since I'm one of the people who will have
>> to judge the consensus on this question, my comments will remain
>> strictly based on the facts of the events as I know them and on the
>> relevant IETF procedures. It is up to the IETF community
> 
> The status of the memo in the drafts have this statement:
> 
>   "This Internet-Draft is submitted in full conformance with the
>    provisions of BCP 78 and BCP 79."
> 
> Have the authors been asked whether they have any issue with the above?

True it is important but the issue here again is the IP landscape and
transparency.

What if they say NO and they will not sign. How does the IETF deal with
this as a liability. The IETF says' Uh gee we are not responsible for
the fact  we intentionally and with direct participation created a
system which makes it impossible to retract or invalidate the use
license we issued to the world no matter what'

Its real clear that is the effect of the publishing process the issue is
what people think they are accountable for here.

Todd

> 
> The is a question in the write-up: "Has an IPR disclosure related to
> this document been filed?"  Has the Document Shepherd been asked about
> that before the Second Last Call?
> 
> The minutes from the last WG session does not mention who chaired the
> session.  Did the WG Chair bring the Note Well to the attention of the WG?
> 
> Regards,
> -sm
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 


-- 
Todd S. Glassey
This is from my personal email account and any materials from this
account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.

From kpfleming@digium.com  Thu Jan 26 12:52:47 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C83921F8666 for ; Thu, 26 Jan 2012 12:52:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.527
X-Spam-Level: 
X-Spam-Status: No, score=-106.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 54p3J-T6CZqy for ; Thu, 26 Jan 2012 12:52:44 -0800 (PST)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2F021F8646 for ; Thu, 26 Jan 2012 12:52:42 -0800 (PST)
Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RqWJE-0006i1-Qz for ietf@ietf.org; Thu, 26 Jan 2012 14:52:40 -0600
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id CECEFD8004 for ; Thu, 26 Jan 2012 14:52:40 -0600 (CST)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNHDZS7lvA+q for ; Thu, 26 Jan 2012 14:52:40 -0600 (CST)
Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 3868CD8002 for ; Thu, 26 Jan 2012 14:52:40 -0600 (CST)
Message-ID: <4F21BD17.3010201@digium.com>
Date: Thu, 26 Jan 2012 14:52:39 -0600
From: "Kevin P. Fleming" 
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Second Last	Call:	 (Sieve	Notifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> , <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM> <4F217A7C.6080908@qualcomm.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 20:52:47 -0000

On 01/26/2012 11:37 AM, John C Klensin wrote:
>
>
> --On Thursday, January 26, 2012 10:08 -0600 Pete Resnick
>   wrote:
>



>> We were told by the other company employees who facilitated
>> the disclosures, at the time of the disclosures, that this was
>> strictly an individual's failure to comply with the IETF IPR
>> Policy, that the author in question claims not to have
>> understood the IETF IPR Policy, and that the company proceeded
>> to make these disclosures as soon as it discovered that this
>> IPR existed. I have no information to contradict that claim.
>
> Excellent.   I had hoped that was the situation.  It obviously
> makes things much easier (and some of my earlier comments
> irrelevant).   With all the effort we go to ("Note Well" and
> otherwise) to be sure that people are informed about the policy,
> I have trouble generating sympathy for someone who says "didn't
> underatand", but that is another matter (and perhaps just my
> problem).

No, I don't think it's your problem. I've only been a mildly active 
participant in the IETF for a couple of years now, but the first time I 
read the Note Well it raised some question in my mind and made me go 
spend time reading the relevant BCPs and related documents until I 
understood my obligations. During that time, it was abundantly clear to 
me that if I did not understand any of these documents, the IETF had 
plenty of resources (this mailing list included) for me to utilize to 
ask my questions and get answers.

I would say that the more serious concern here is that the individual in 
question may not have understood the IPR policy, but believed that they 
*did* understand it, and so did not ask any questions about it. If they 
did not believe that they understood it, and did not ask any questions 
to achieve an acceptable level of understanding, that's a much more 
egregious situation.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

From rbarnes@bbn.com  Thu Jan 26 13:11:46 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D72821F85FC; Thu, 26 Jan 2012 13:11:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.153
X-Spam-Level: 
X-Spam-Status: No, score=-106.153 tagged_above=-999 required=5 tests=[AWL=0.446, 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 H-yABNsAwqV6; Thu, 26 Jan 2012 13:11:45 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B774121F85D4; Thu, 26 Jan 2012 13:11:45 -0800 (PST)
Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:62564) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RqWbg-0002fY-IU; Thu, 26 Jan 2012 16:11:44 -0500
From: Richard L. Barnes 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: Gen-ART review of draft-ietf-payload-rtp-klv-02
Date: Thu, 26 Jan 2012 16:11:43 -0500
Message-Id: <84A8BD83-8B84-4049-B9CF-1AB0E36211F9@bbn.com>
To: General Area Review Team , IETF-Discussion Discussion , draft-ietf-payload-rtp-klv.all@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 21:11:46 -0000

I am the assigned Gen-ART reviewer for this draft. For background on=20
Gen-ART, please see the FAQ at=20
.

Please resolve these comments along with any other Last Call comments=20
you may receive.

Document: draft-ietf-payload-rtp-klv-02
Reviewer: Richard Barnes
Review Date: 26 Jan 2011
IETF LC End Date: 27 Jan 2011
IESG Telechat date: (if known) -

Summary:=20
Mostly ready, with a couple of minor comments

=3D=3D=3D=3D=3D MINOR =3D=3D=3D=3D=3D

Section 6.1.: Given that the KLV format can carry a variety of data =
types, would it be helpful for this type to have one or more parameters =
to describe what types of KLVs might be in the stream?

Section 8, "appropriate caution and security practices": It could be =
helpful to note here that it is dangerous for implementations to accept =
active content from streams that lack authenticity or integrity =
protection, since this could make them vulnerable to attacks using =
spoofed packets.


=3D=3D=3D=3D=3D EDITORIAL =3D=3D=3D=3D=3D

Section 4: It would be helpful to note a little more explicitly that a =
KLVunit is a sequence of KLVs, without any overall framing (thus the =
requirement for the marker bit / timestamp to distinguish).

Section 4.2., last paragraph: It would be helpful to note explicitly =
what this paragraph implies: A receiver MUST consider a KLV unit to be =
completed when it receives either a packet with m=3D1 or a packet with a =
new timestamp.  In the former case, the packet payload is included in =
the KLVunit; in the latter case, it is not.

Section 4.3.1.1., "are left to each implementation": It could be helpful =
to point to some ways that KLV recovery is done, as guidance to =
implementors. (Provided this can be done without IPR concerns.)

Section 8, "The main security considerations ... alternatives may =
exist": This chunk of text doesn't really add anything beyond the normal =
security considerations for RTP.  Suggest just adding an appropriate =
reference to standard RTP security practices.

Section 8, "Receivers are encouraged to place limits...": Suggest =
changing "are encouraged to" to "SHOULD".



From sm@resistor.net  Thu Jan 26 13:25:57 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA5021F8646 for ; Thu, 26 Jan 2012 13:25:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.318
X-Spam-Level: 
X-Spam-Status: No, score=-102.318 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 H7wx5wTTRw8y for ; Thu, 26 Jan 2012 13:25:53 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9F021F8633 for ; Thu, 26 Jan 2012 13:25:53 -0800 (PST)
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 q0QLPlIw015134 for ; Thu, 26 Jan 2012 13:25:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327613152; i=@resistor.net; bh=x5ZguEnH95GQMlkTaL8ZJn5khu7OcvLXMZFyYO8rR+Q=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=lxPngrh6oGq67R0/FLlsmV2kZp2TiUnZL9iDGffpok+z9ES1ZHAK7vB4LtBwVsoRR NzvuLUFY9uL5zxHCHydnm3PmalTA4OROecByqiz88aZoYhhWK+F01LWLNvPCI+07/g kRnFPr7a/CxHTUCpFC655oTvprcCXFFGbJMfg3mE=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327613152; i=@resistor.net; bh=x5ZguEnH95GQMlkTaL8ZJn5khu7OcvLXMZFyYO8rR+Q=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=Yxr5SzOnq4SAzQN4L+JJGr6NH2xMn0ZeTsJlkv/eolgwzItoUmyGLxY/2w6eQk5ys Wre7jGlMS5HarNcf8HCOq7PpsnnGiDX+RK8qPxNQ9KuefHYRDbvcRS/zpXsdK1VIue vUyKPjudSkt5zWq14aAGuYGk6TKwbo5xA3EynVYE=
Message-Id: <6.2.5.6.2.20120126115633.0cd39770@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 26 Jan 2012 13:16:12 -0800
To: ietf@ietf.org
From: SM 
Subject: Re: Second Last Call:	 (Sieve	Notification Mechanism: SIP MESSAGE) to Proposed Standard
In-Reply-To: <4F21ABF2.7040002@qualcomm.com>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com>  <4F21ABF2.7040002@qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 21:25:57 -0000

At 11:39 26-01-2012, Pete Resnick wrote:
>Just in case others are having similar thoughts:
>
>The IESG and IAB are *not* the ones that get to make the decision 
>about what ought to be done here. The community needs to come to a 
>consensus about the right outcome and the leadership folks will 
>judge that consensus and instantiate whatever actions need to be 
>taken. It's certainly OK if you feel you don't have enough 
>information yet to decide what

I suggest not accepting any Internet-Draft submission until a 
decision has been taken.  It is left to the Working Group Chair to 
take action if there is any attempt to circumvent that.

I suggest that the IESG does not process any Internet-Drafts until a 
decision has been taken.

>  the appropriate action is, but if you're a member of this 
> community, it is your responsibility to contribute to the decision 
> in the end. You may decide that the conversation on the list has 
> concluded the way you like; you're not required to post just to say 
> that you agree. But don't expect the leadership to make this 
> decision for you. We will give guidance as needed, but it's your decision.

I have not seen any feedback from IETF participants affiliated with 
Huawei.  I'll highlight a comment made by John Klensin:

   (5) Unless the clarification suggested in (2) can be provided,
    each IETF participant who is associated with the relevant
    company and who is in an IETF-related leadership or
    decision-making position (WG Chairs; Editors; IESG, IAB, IAOC,
    Nomcom, members; etc.) should be asked to make a conscientious
    personal review as to whether this type of action sufficiently
    compromises his or her position that resignation or some other
    action would be appropriate and, as appropriate, to review IETF
    policies with whatever management chains are relevant.  I am
    _not_ suggesting that anyone be asked to resign, only that they
    engage in careful consideration of the issues and their
    implications."

There is an IAB member with an Huawei affiliation.

There is an IESG member with an Huawei affiliation.

There are two NomCom members with an Huawei affiliation.

Individuals with an Huawei affiliation are participating in multimob, 
paws, cdni, hybi, pce, armd, ccamp, csi, dhc, 6man, dnsext, v6ops, 
softwire, 6renum, xrblock, ospf, pcp, roll, opsawg, core, mpls, 
trill, pcn, bmwg, bfd, idr, pwe3, ppsp, decade, p2psip, dime, sieve, 
isis, avtcore, netext, 6lowpan, radext, l3vpn, l2vpn, ancp, ipsecme, 
mmusic, tictoc, grow, behave, forces, mboned, mif, geopriv, vcarddav, 
hokey, kitten, abfab, emu, karp, avtext and alto.

And a comment from Dave Crocker:

   "Somehow, an apology does not seem sufficient.  Something more
    substantial is warranted."

I agree with Dave that something more substantial is 
warranted.  Could these individuals share their thoughts about what 
action would be appropriate?

Regards,
-sm 


From mrex@sap.com  Thu Jan 26 13:29:45 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3DA21F8705; Thu, 26 Jan 2012 13:29:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.16
X-Spam-Level: 
X-Spam-Status: No, score=-10.16 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 4G87zg0pdF-q; Thu, 26 Jan 2012 13:29:44 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1DC21F8636; Thu, 26 Jan 2012 13:29:44 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0QLTgj2018710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jan 2012 22:29:42 +0100 (MET)
From: Martin Rex 
Message-Id: <201201262129.q0QLTgDN002510@fs4113.wdf.sap.corp>
Subject: Re: Second Last Call:   
To: presnick@qualcomm.com (Pete Resnick)
Date: Thu, 26 Jan 2012 22:29:42 +0100 (MET)
In-Reply-To: <4F217A7C.6080908@qualcomm.com> from "Pete Resnick" at Jan 26, 12 10:08:28 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: john-ietf@jck.com, adrian@olddog.co.uk, sieve@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 21:29:45 -0000

Pete Resnick wrote:
> 
> We were told by the other company employees who facilitated the 
> disclosures, at the time of the disclosures, that this was strictly an 
> individual's failure to comply with the IETF IPR Policy, that the author 
> in question claims not to have understood the IETF IPR Policy, and that 
> the company proceeded to make these disclosures as soon as it discovered 
> that this IPR existed. I have no information to contradict that claim.


Somehow that sounds unconvincing to me.  While I've never been through
the patent application process myself, from what I've heard, it is
non-trivial and usually taken care of by the company's legal department.

Normally, patent lawyers of a company's legal department should have
sufficient clue about participation in SDOs that they should know
to ask employees the right questions.


-Martin

From cyrus@daboo.name  Thu Jan 26 13:42:25 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803D821F86A7 for ; Thu, 26 Jan 2012 13:42:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.828
X-Spam-Level: 
X-Spam-Status: No, score=-100.828 tagged_above=-999 required=5 tests=[AWL=1.772, 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 mtKMqKwULtOm for ; Thu, 26 Jan 2012 13:42:24 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id C905521F8682 for ; Thu, 26 Jan 2012 13:42:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 5F29D20E1D0C; Thu, 26 Jan 2012 16:42:24 -0500 (EST)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSBKlzco7-3y; Thu, 26 Jan 2012 16:42:23 -0500 (EST)
Received: from vp0101wa-dhcp96.apple.com (unknown [17.224.23.96]) by daboo.name (Postfix) with ESMTPSA id 8D08420E1D01; Thu, 26 Jan 2012 16:42:22 -0500 (EST)
Date: Thu, 26 Jan 2012 13:42:46 -0800
From: Cyrus Daboo 
To: SM , ietf@ietf.org
Subject: Re: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
Message-ID: 
In-Reply-To: <6.2.5.6.2.20120126115633.0cd39770@resistor.net>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com>  <4F21ABF2.7040002@qualcomm.com> <6.2.5.6.2.20120126115633.0cd39770@resistor.net>
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=510
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 21:42:25 -0000

Hi SM,

--On January 26, 2012 1:16:12 PM -0800 SM  wrote:

> I have not seen any feedback from IETF participants affiliated with
> Huawei.  I'll highlight a comment made by John Klensin:

There is feedback along those lines on the SIEVE WG mailing list. Please 
see the thread started by Pete on this issue last year: 
. That 
thread covers all the WG debate on this issue up until the two recent last 
calls.

-- 
Cyrus Daboo


From cyrus@daboo.name  Thu Jan 26 13:44:10 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDA321F8745; Thu, 26 Jan 2012 13:44:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.418
X-Spam-Level: 
X-Spam-Status: No, score=-101.418 tagged_above=-999 required=5 tests=[AWL=1.181, 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 Fwe20TyvWgeQ; Thu, 26 Jan 2012 13:44:09 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id EAB8621F8633; Thu, 26 Jan 2012 13:44:08 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 87F6820E1D55; Thu, 26 Jan 2012 16:44:02 -0500 (EST)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 880eWLdfeZjw; Thu, 26 Jan 2012 16:44:01 -0500 (EST)
Received: from vp0101wa-dhcp96.apple.com (unknown [17.224.23.96]) by daboo.name (Postfix) with ESMTPSA id C175F20E1D48; Thu, 26 Jan 2012 16:44:00 -0500 (EST)
Date: Thu, 26 Jan 2012 13:44:26 -0800
From: Cyrus Daboo 
To: SM , Pete Resnick 
Subject: Re: Second Last Call:  (Sieve Notifica tion Mechanism: SIP MESSAGE) to Proposed Standard
Message-ID: <94D30033CC80C1031A15FD7A@vp0101wa-dhcp96.apple.com>
In-Reply-To: <6.2.5.6.2.20120126085545.0b1fa288@resistor.net>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com>	<9E8747DFE73501D34065351E@PST.JCK.COM> <4F217A7C.6080908@qualcomm.com> <6.2.5.6.2.20120126085545.0b1fa288@resistor.net>
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=531
Cc: sieve@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 21:44:10 -0000

Hi SM,

--On January 26, 2012 9:15:00 AM -0800 SM  wrote:

> The minutes from the last WG session does not mention who chaired the
> session.  Did the WG Chair bring the Note Well to the attention of the WG?

I was the chair present at that meeting. Apologies for not including that 
detail in the minutes. All the meetings I chair include the Note Well as 
the second slide in presentations I put together (which seems to be common 
practice), and indeed you can see that in the uploaded slides.

-- 
Cyrus Daboo


From mcr@sandelman.ca  Thu Jan 26 14:36:29 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1680921F8624 for ; Thu, 26 Jan 2012 14:36:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.555
X-Spam-Level: 
X-Spam-Status: No, score=-1.555 tagged_above=-999 required=5 tests=[AWL=0.399,  BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334]
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 V5r0WwvT2HUJ for ; Thu, 26 Jan 2012 14:36:28 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 90EDC21F85ED for ; Thu, 26 Jan 2012 14:36:28 -0800 (PST)
Received: from marajade.sandelman.ca (wlan203.sandelman.ca [209.87.252.203]) by relay.sandelman.ca (Postfix) with ESMTPS id 9257B34480 for ; Thu, 26 Jan 2012 17:34:20 -0500 (EST)
Received: by marajade.sandelman.ca (Postfix, from userid 179) id EC40298460; Thu, 26 Jan 2012 17:36:25 -0500 (EST)
Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id DBB9B9845E for ; Thu, 26 Jan 2012 17:36:25 -0500 (EST)
From: Michael Richardson 
To: "ietf@ietf.org" 
Subject: Re: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
In-Reply-To: <4F21ABF2.7040002@qualcomm.com>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com>, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> , <4F208AEF.5060406@qualcomm.com>  <4F21ABF2.7040002@qualcomm.com>
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 26 Jan 2012 17:36:25 -0500
Message-ID: <6842.1327617385@marajade.sandelman.ca>
Sender: mcr@sandelman.ca
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 22:36:29 -0000

--=-=-=
Content-Transfer-Encoding: quoted-printable


>>>>> "Pete" =3D=3D Pete Resnick  writes:
    Pete> decision about what ought to be done here. The community needs
    Pete> to come to a consensus about the right outcome and the
    Pete> leadership folks will judge that consensus and instantiate
    Pete> whatever actions need to be taken. It's certainly OK if you

At this point, I do not have a clear idea of what the set of outcomes
could be.  I think that they can include:
   1) not publishing the document.
   2) revising the document to remove/work-around the encumbered work
   3) some legal action to attend to anul the patent (which might or
      might not succeed).
   4) go ahead and publish things as they are.


I am concerned that the individual may be scapegoated here, but I also
do not buy that they didn't understand things.=20=20=20
The company spent money to file a patent, and they hired someone to do
this, and they certainly knew where the "invention" was documented.=20=20

There is a need for a consequence for not following the IPR.
I read the document, but not the patent, so I don't see what's so novel
about it all, and I also don't know how hard it would be to work around.

My preference is to some method to remove any value the patent might
have.=20

=2D-=20
]       He who is tired of Weird Al is tired of life!           |  firewall=
s  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net archit=
ect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri=
ver[
   Kyoto Plus: watch the video 
	               then sign the petition.=20


--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQCVAwUATyHVaYqHRg3pndX9AQKqwAQAymX6zCJ+riecfnfRjcBuHdX0P4c0AfvJ
9ApSxu5R+ptSaPx7h4uo0NgW4yrqHc/y+YRLRfRtOE4T5nRmST8RXeXF7bmZqY7J
zkeJ2wW0Fx5NNkt0Tlm0+t27+aVpzrkRNDtMF4qnLIgzmv9pBCjnDusrBwl1piFR
1vjcoKSeEbU=
=jCaE
-----END PGP SIGNATURE-----
--=-=-=--

From msk@cloudmark.com  Thu Jan 26 14:45:35 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A180B21F872D for ; Thu, 26 Jan 2012 14:45:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.587
X-Spam-Level: 
X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 yTmsyu5sGkhP for ; Thu, 26 Jan 2012 14:45:35 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF8321F8723 for ; Thu, 26 Jan 2012 14:45:35 -0800 (PST)
Received: from malice.corp.cloudmark.com (172.22.10.71) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 26 Jan 2012 14:45:34 -0800
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 26 Jan 2012 14:45:34 -0800
From: "Murray S. Kucherawy" 
To: "ietf@ietf.org" 
Date: Thu, 26 Jan 2012 14:45:33 -0800
Subject: RE: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
Thread-Topic: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
Thread-Index: AczcevhkmDyPwuO9TPCxUgpQCGeCRQAAE9Gg
Message-ID: 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com>, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> , <4F208AEF.5060406@qualcomm.com>  <4F21ABF2.7040002@qualcomm.com> <6842.1327617385@marajade.sandelman.ca>
In-Reply-To: <6842.1327617385@marajade.sandelman.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 22:45:35 -0000

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of M=
ichael Richardson
> Sent: Thursday, January 26, 2012 2:36 PM
> To: ietf@ietf.org
> Subject: Re: Second Last Call:  08.txt> (Sieve Notification Mechanism: SIP MESSAGE) to Proposed
> Standard
>=20
> At this point, I do not have a clear idea of what the set of outcomes
> could be.  I think that they can include:
>    1) not publishing the document.
>    2) revising the document to remove/work-around the encumbered work
>    3) some legal action to attend to anul the patent (which might or
>       might not succeed).
>    4) go ahead and publish things as they are.

I also thought about suggesting a DNP or a standing DISCUSS or something un=
til the license terms are made more IETF-friendly, unless the WG can find a=
 way to do equivalent work that is unencumbered, but then the WG might not =
have the energy left.

The document could be restricted to Experimental status, but that presumes =
the status matters as much as or more than the RFC number.  I don't know if=
 that's true or not in this case.

Those only cover the document though, and not the offender(s).  Still chewi=
ng on an opinion about that.

-MSK

From sant9442@gmail.com  Thu Jan 26 15:01:55 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BF721F8707 for ; Thu, 26 Jan 2012 15:01:55 -0800 (PST)
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 koUTfAjVDfqs for ; Thu, 26 Jan 2012 15:01:54 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E6CD321F86C2 for ; Thu, 26 Jan 2012 15:01:53 -0800 (PST)
Received: by ggnq4 with SMTP id q4so644111ggn.31 for ; Thu, 26 Jan 2012 15:01:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=zah50Ew5O/FgjJY7Y4IZia2i+ImD4qgRc+4JSL+6pyI=; b=IFgfp6yJKbc/A9EXHgnUwuXSIgEzxhi19hG+vSChCJGwyM04N0PxbN8LPt58QY4cfV vW8pJQ3bUcH7DdhghOSMfOam5iC00G6TtDraDj7es7aW2LST3DdD5d5taqPR4GZTelFr WyvthSQPrOb63YC1op5BpIlhf+RmdahvKVFDU=
Received: by 10.236.154.232 with SMTP id h68mr6782714yhk.51.1327618897729; Thu, 26 Jan 2012 15:01:37 -0800 (PST)
Received: from adsl-215-50-126.mia.bellsouth.net (99-3-147-93.lightspeed.miamfl.sbcglobal.net. [99.3.147.93]) by mx.google.com with ESMTPS id o9sm9433874yhk.20.2012.01.26.15.01.34 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jan 2012 15:01:36 -0800 (PST)
Message-ID: <4F21DB61.3000201@gmail.com>
Date: Thu, 26 Jan 2012 18:01:53 -0500
From: Hector 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: "ietf@ietf.org" 
Subject: Re: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com>	<4F2075BE.5070201@nostrum.com>, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>	, <4F208AEF.5060406@qualcomm.com>		<4F21ABF2.7040002@qualcomm.com> <6842.1327617385@marajade.sandelman.ca>
In-Reply-To: <6842.1327617385@marajade.sandelman.ca>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 23:01:55 -0000

Michael Richardson wrote:
>>>>>> "Pete" == Pete Resnick  writes:
>     Pete> decision about what ought to be done here. The community needs
>     Pete> to come to a consensus about the right outcome and the
>     Pete> leadership folks will judge that consensus and instantiate
>     Pete> whatever actions need to be taken. It's certainly OK if you
> 
> At this point, I do not have a clear idea of what the set of outcomes
> could be.  I think that they can include:
>    1) not publishing the document.
>    2) revising the document to remove/work-around the encumbered work
>    3) some legal action to attend to anul the patent (which might or
>       might not succeed).
>    4) go ahead and publish things as they are.
> 
> 
> I am concerned that the individual may be scapegoated here, but I also
> do not buy that they didn't understand things.   
> The company spent money to file a patent, and they hired someone to do
> this, and they certainly knew where the "invention" was documented.  
> 
> There is a need for a consequence for not following the IPR.
> I read the document, but not the patent, so I don't see what's so novel
> about it all, and I also don't know how hard it would be to work around.
> 
> My preference is to some method to remove any value the patent might
> have. 

+1.

Given the nature of the new 1996 timeline for patentability of prior 
art, the richness of technologies, the integration of technologies. 
e.g. the Markus Analysis does not apply as strong as it did which in 
short, says the following (paraphrasing from my old Westinghouse Chief 
Lawyer presentation to the Venture Group):

    - You can not take prior art A, B and create a patent D, unless
      there is a new and unique part C,

    - Given the first rule, parts A and B can not be restricted on
      existing systems and/or deny existing systems to implement what
      would be natural course of their existence.  IOW, if a Markus
      Analysis shows that Part C is a natural evolution of the existing
      systems, they can not denied adding it.

This is what has me to sleep like a baby with the new frivolous 
patents of prior arts that is now allowed.  Unfortunately, what has 
allowed the new patent era to exist is the less emphasis of performing 
the Markus Analysis by patent examiners.

Overall, the mere fact of submitting an IETF document, by definition, 
it means implementators are not subject to any sort of restrictions. 
As it is right now, when I see new I-D comes in, if it even smells 
like its has IPR related stuff, I totally 100% skip it. Ignore it. I 
don't bother with it.

In my view, the IETF should view new submissions in the same way.  So 
its not only a,

     "Are you totally sure this is IPR-claim-free?"

but also

     "Are you using IETF related parts?

Because if the I-D submitter is using existing IETF parts, then he/she 
must be aware that any IPR existing or in the future against anyone 
that exist using such parts or now also include future system that 
decides to use the new I-D.

In my view, Mr. Resnick, should consider the concept of the Markus 
Analysis.  If this I-D is allowed to go thru, how will it alter 
existing systems?  Will existing systems with all the parts, except 
the integration of the new by existing part, be denied the natural 
inclusion of the new part?

In other words, a system that has IETF technology SMTP and/or IMAP and 
SIEVE already in place, if they add an existing IETF technology SIP, 
will they be restricted?

There has to be something completely novel and not an IETF technology 
for it to hold any strength.   But if that is not the case, where each 
part is an IETF technology, the mere integration of all these IETF 
parts, by definition, must not have any sort of patent strength or for 
that matter, recognition.

-- 
Sincerely

Hector Santos
http://www.santronics.com
jabber: hector@jabber.isdg.net


From presnick@qualcomm.com  Thu Jan 26 15:06:10 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE1A21F86DE for ; Thu, 26 Jan 2012 15:06:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.561
X-Spam-Level: 
X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 ZGSxMwB1X5t7 for ; Thu, 26 Jan 2012 15:06:04 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 8C53821F86DC for ; Thu, 26 Jan 2012 15:06:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327619164; x=1359155164; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F21DC59.4040207@qualcomm.com>|Date:=20Th u,=2026=20Jan=202012=2017:06:01=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20"Murray=20S.=20Kucherawy"=20|CC:=20"ietf@ietf.org"=20 |Subject:=20Re:=20Second=20Last=20Call:=20=0D=0A=20(Sieve=20Notificati on=20Mechanism:=20SIP=20MESSAGE)=20to=20Proposed=20Standa rd|References:=20<20120125201714.3903.82295.idtracker@iet fa.amsl.com>=09<4F2075BE.5070201@nostrum.com>,=09<033901c cdbab$6bae0900$430a1b00$@olddog.co.uk>=09 ,=09<4F208AEF.5060406@qualcomm.com>=09=09 <4F21ABF2.7040002@qualcomm.com>=20<6842.1327617385@maraja de.sandelman.ca>=20|In-Reply-To:=20|Content-Type:=20text/plain=3B=20charset=3D"ISO-885 9-1"=3B=20format=3Dflowed|Content-Transfer-Encoding:=207b it|X-Originating-IP:=20[172.30.39.5]; bh=0UcoTBJSkDWggljEKHd4Hhgrjqjfmos9YQL3qJd0xhg=; b=ec/5lCriH4kRBd7wEA7GoBf8bcpl3RCAjUXl4DKQCubQY6LFsS11byLx uNSAa2oGnn4c++9iWCK8c41EJnDftuCBkyfoa3uq3Qa6/UzsYxBTW4AQB QAOY7x3tBdi4NYdRUclNrVBbDA4rcdzB2Aef2zt66fX0+ySh8mRrDSYOv g=;
X-IronPort-AV: E=McAfee;i="5400,1158,6601"; a="158240197"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP; 26 Jan 2012 15:06:04 -0800
X-IronPort-AV: E=Sophos;i="4.71,574,1320652800"; d="scan'208";a="154010674"
Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 26 Jan 2012 15:06:04 -0800
Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 26 Jan 2012 15:06:03 -0800
Message-ID: <4F21DC59.4040207@qualcomm.com>
Date: Thu, 26 Jan 2012 17:06:01 -0600
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: "Murray S. Kucherawy" 
Subject: Re: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com>	<4F2075BE.5070201@nostrum.com>, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>	, <4F208AEF.5060406@qualcomm.com>		<4F21ABF2.7040002@qualcomm.com> <6842.1327617385@marajade.sandelman.ca> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.39.5]
Cc: "ietf@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 23:06:10 -0000

On 1/26/12 4:45 PM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Michael Richardson
>> Sent: Thursday, January 26, 2012 2:36 PM
>> To: ietf@ietf.org
>> Subject: Re: Second Last Call:> 08.txt>  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed
>> Standard
>>
>> At this point, I do not have a clear idea of what the set of outcomes
>> could be.  I think that they can include:
>>     1) not publishing the document.
>>     2) revising the document to remove/work-around the encumbered work
>>      

Yes, certainly those are choices.

>>     3) some legal action to attend to anul the patent (which might or
>>        might not succeed).
>>      

I don't think this is something that we can do *as the IETF*. Certainly 
others are welcome to pursue that.

>>     4) go ahead and publish things as they are.
>>      
> I also thought about suggesting a DNP or a standing DISCUSS or something until the license terms are made more IETF-friendly, unless the WG can find a way to do equivalent work that is unencumbered, but then the WG might not have the energy left.
>
> The document could be restricted to Experimental status, but that presumes the status matters as much as or more than the RFC number.  I don't know if that's true or not in this case.
>    

These are also choices.

> Those only cover the document though, and not the offender(s).  Still chewing on an opinion about that.
>    

Other choices that involve both the document and the author(s) are 
similar to ones outlined by other folks:

- The author of the patent can be removed from the author list at the 
top of the document.
(In effect, this would be the IETF asking the WG chair to fire the 
document editor for failure to comply with IETF process. The result 
would be the author not getting the recognition as a document editor, 
though they would still appear in the Acknowledgments section.)

- Removal of posting rights of the author from the WG or IETF mailing 
lists, even perhaps via a PR Action for being "disruptive" of the IETF 
process.

Coincidentally, but not by chance, Adrian and I have been working on a 
draft to discuss such sanctions that we are just about to post. I hope 
that sparks some ideas as well.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From presnick@qualcomm.com  Thu Jan 26 15:11:43 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A3C21F8666 for ; Thu, 26 Jan 2012 15:11:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.561
X-Spam-Level: 
X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 KkGV7pPN2z7l for ; Thu, 26 Jan 2012 15:11:42 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 186A021F8646 for ; Thu, 26 Jan 2012 15:11:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327619501; x=1359155501; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F21DDAB.9030300@qualcomm.com>|Date:=20Th u,=2026=20Jan=202012=2017:11:39=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20IETF-Discussion=20list=20|Subject:=20Forthcoming=20draft:=20draft-farrre snickel-ipr-sanctions|Content-Type:=20text/plain=3B=20cha rset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.39.5]; bh=CP/bonDp2RBN3Db28CDB5zAZl2p6dLXGaTEOvAfbfiQ=; b=AKyK6kviFY6ftFC+faBirIumVCPZR5alQ1GZ1kQwyY5AOr3quoKbzNtM xxqAMDsdoqZ0rpqN/JgaNIFtunHjAJmwD7AHaA50i3gLk8+X5Gg7Sty3X jvCTzIXmek3DU/BGOXx5cbqc7uj+RyXo2Sw8CAqsO3QemaKr2RAe0jn84 8=;
X-IronPort-AV: E=McAfee;i="5400,1158,6601"; a="155926460"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 26 Jan 2012 15:11:41 -0800
X-IronPort-AV: E=Sophos;i="4.71,574,1320652800"; d="scan'208";a="157186942"
Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 26 Jan 2012 15:11:41 -0800
Received: from Macintosh-4.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 26 Jan 2012 15:11:40 -0800
Message-ID: <4F21DDAB.9030300@qualcomm.com>
Date: Thu, 26 Jan 2012 17:11:39 -0600
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: IETF-Discussion list 
Subject: Forthcoming draft: draft-farrresnickel-ipr-sanctions
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.39.5]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 23:11:43 -0000

Just a heads-up:

Adrian Farrel and I started work on a draft to focus discussion on 
sanctions that could be applied to violators of the IETF's IPR policy. 
Because of incidents like the present one, we've each been asked by WG 
chairs and others what can be done in response to such violations. We've 
centered our draft around sanctions that are available under current 
IETF procedures, not introducing new ones. The draft  should be 
available in the I-D repository soon. We think this could usefully 
become an RFC and we would welcome discussion.

Thanks,

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From adrian@olddog.co.uk  Thu Jan 26 15:21:25 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E125821F8627 for ; Thu, 26 Jan 2012 15:21:25 -0800 (PST)
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 x2dj-aX1OVSj for ; Thu, 26 Jan 2012 15:21:25 -0800 (PST)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id D401721F84E0 for ; Thu, 26 Jan 2012 15:21:24 -0800 (PST)
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0QNLN3N006605 for ; Thu, 26 Jan 2012 23:21:23 GMT
Received: from 950129200 (ns-visitor-nsrp.juniper.net [208.223.208.242]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0QNLKWn006583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 26 Jan 2012 23:21:22 GMT
From: "Adrian Farrel" 
To: "'IETF-Discussion list'" 
References: <4F21DDAB.9030300@qualcomm.com>
In-Reply-To: <4F21DDAB.9030300@qualcomm.com>
Subject: RE: Forthcoming draft: draft-farrresnickel-ipr-sanctions
Date: Thu, 26 Jan 2012 23:21:19 -0000
Message-ID: <016501ccdc81$37918f80$a6b4ae80$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJIK6minpi8u8Ic6J8K8S1rwTnFVZUoqiGw
Content-Language: en-gb
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 23:21:26 -0000

http://www.ietf.org/internet-drafts/draft-farrresnickel-ipr-sanctions-00.txt

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Pete
> Resnick
> Sent: 26 January 2012 23:12
> To: IETF-Discussion list
> Subject: Forthcoming draft: draft-farrresnickel-ipr-sanctions
> 
> Just a heads-up:
> 
> Adrian Farrel and I started work on a draft to focus discussion on
> sanctions that could be applied to violators of the IETF's IPR policy.
> Because of incidents like the present one, we've each been asked by WG
> chairs and others what can be done in response to such violations. We've
> centered our draft around sanctions that are available under current
> IETF procedures, not introducing new ones. The draft  should be
> available in the I-D repository soon. We think this could usefully
> become an RFC and we would welcome discussion.
> 
> Thanks,
> 
> pr
> 
> --
> Pete Resnick
> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


From rbarnes@bbn.com  Thu Jan 26 15:35:55 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4190521F8760 for ; Thu, 26 Jan 2012 15:35:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.265
X-Spam-Level: 
X-Spam-Status: No, score=-106.265 tagged_above=-999 required=5 tests=[AWL=0.334, 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 1qI7QiIFA6NE for ; Thu, 26 Jan 2012 15:35:54 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 75EEB21F875A for ; Thu, 26 Jan 2012 15:35:25 -0800 (PST)
Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:64192) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RqYqh-000Jes-52; Thu, 26 Jan 2012 18:35:23 -0500
Subject: Re: Forthcoming draft: draft-farrresnickel-ipr-sanctions
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" 
In-Reply-To: <4F21DDAB.9030300@qualcomm.com>
Date: Thu, 26 Jan 2012 18:35:22 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1DB386B5-47B1-4AB1-A60B-FFF4D6D40299@bbn.com>
References: <4F21DDAB.9030300@qualcomm.com>
To: Pete Resnick 
X-Mailer: Apple Mail (2.1084)
Cc: IETF-Discussion list 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 23:35:55 -0000

I appreciate that there need to be disincentives to infringing the IPR =
policy, but I'm a little wary of the idea of codifying a system of =
sanctions.  Mainly for the sorts of "gaming the system" thinking they =
engender:
-- Is the benefit of infringing worse than the cost of the sanction?
-- If it's not sanctionable, it must be ok!

Plus, if there are sanctions, then you need a judgement process to =
decide when the sanctions will be applied.  Is the IETF set up for that?

Rather than bright lines and clear sanctions, it seems like a general =
culture of conservatism, staying far away from things that could =
possibly be construed as violations, would be more in tune with the way =
other things work at the IETF.

No real answers here, just expressing a gut reaction.

--Richard



On Jan 26, 2012, at 6:11 PM, Pete Resnick wrote:

> Just a heads-up:
>=20
> Adrian Farrel and I started work on a draft to focus discussion on =
sanctions that could be applied to violators of the IETF's IPR policy. =
Because of incidents like the present one, we've each been asked by WG =
chairs and others what can be done in response to such violations. We've =
centered our draft around sanctions that are available under current =
IETF procedures, not introducing new ones. The draft  should be =
available in the I-D repository soon. We think this could usefully =
become an RFC and we would welcome discussion.
>=20
> Thanks,
>=20
> pr
>=20
> --=20
> Pete Resnick
> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: =
(858)651-1102
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


From adrian@olddog.co.uk  Thu Jan 26 15:46:46 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6B811E808A for ; Thu, 26 Jan 2012 15:46:46 -0800 (PST)
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 vF9QluDB4wiS for ; Thu, 26 Jan 2012 15:46:45 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2FD11E8072 for ; Thu, 26 Jan 2012 15:46:45 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0QNkbun018282;  Thu, 26 Jan 2012 23:46:37 GMT
Received: from 950129200 (ns-visitor-nsrp.juniper.net [208.223.208.242]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q0QNkZtS018276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Jan 2012 23:46:36 GMT
From: "Adrian Farrel" 
To: "'Richard L. Barnes'" 
References: <4F21DDAB.9030300@qualcomm.com> <1DB386B5-47B1-4AB1-A60B-FFF4D6D40299@bbn.com>
In-Reply-To: <1DB386B5-47B1-4AB1-A60B-FFF4D6D40299@bbn.com>
Subject: RE: Forthcoming draft: draft-farrresnickel-ipr-sanctions
Date: Thu, 26 Jan 2012 23:46:34 -0000
Message-ID: <016d01ccdc84$be098330$3a1c8990$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJIK6minpi8u8Ic6J8K8S1rwTnFVQJJ2Im4lRZhrMA=
Content-Language: en-gb
Cc: 'IETF-Discussion list' 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 23:46:46 -0000

Richard,

I think this is exactly the right situation for gut reactions.

The I-D specifically tries to stay away from being formulaic on the application
of sanctions. IMHO the circumstances are too complex to write code to handle.
Each application of sanctions will need human judgment.

We did (under some pressure :-) include an appendix to give some high-level
guidance on "things to think about".

Bright lines and sharp axes would be nice, but even civilized nations rarely
manage to achieve that in law systems. Unfortunate executions of innocent
bystanders is to be avoided.

But I do think the IETF can handle these decisions. They are no harder than
reaching rough consensus on intractable technical issues. And there seemed to me
(when writing the I-D) to be something of a swell of opinion that supports
applying sanctions.

Please continue to massage your gut, and react some more.

Cheers,
Adrian

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
Richard
> L. Barnes
> Sent: 26 January 2012 23:35
> To: Pete Resnick
> Cc: IETF-Discussion list
> Subject: Re: Forthcoming draft: draft-farrresnickel-ipr-sanctions
> 
> I appreciate that there need to be disincentives to infringing the IPR policy,
but
> I'm a little wary of the idea of codifying a system of sanctions.  Mainly for
the
> sorts of "gaming the system" thinking they engender:
> -- Is the benefit of infringing worse than the cost of the sanction?
> -- If it's not sanctionable, it must be ok!
> 
> Plus, if there are sanctions, then you need a judgement process to decide when
> the sanctions will be applied.  Is the IETF set up for that?
> 
> Rather than bright lines and clear sanctions, it seems like a general culture
of
> conservatism, staying far away from things that could possibly be construed as
> violations, would be more in tune with the way other things work at the IETF.
> 
> No real answers here, just expressing a gut reaction.
> 
> --Richard
> 
> 
> 
> On Jan 26, 2012, at 6:11 PM, Pete Resnick wrote:
> 
> > Just a heads-up:
> >
> > Adrian Farrel and I started work on a draft to focus discussion on sanctions
that
> could be applied to violators of the IETF's IPR policy. Because of incidents
like the
> present one, we've each been asked by WG chairs and others what can be done
> in response to such violations. We've centered our draft around sanctions that
> are available under current IETF procedures, not introducing new ones. The
draft
> should be available in the I-D repository soon. We think this could usefully
> become an RFC and we would welcome discussion.
> >
> > Thanks,
> >
> > pr
> >
> > --
> > Pete Resnick
> > Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


From sant9442@gmail.com  Thu Jan 26 16:07:22 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDC721F856C for ; Thu, 26 Jan 2012 16:07:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, 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 yQD23qNw1mIW for ; Thu, 26 Jan 2012 16:07:22 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC1A921F856A for ; Thu, 26 Jan 2012 16:07:21 -0800 (PST)
Received: by ghbg16 with SMTP id g16so607681ghb.31 for ; Thu, 26 Jan 2012 16:07:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=6eU10g69/PufdQKWOROwlJ+fCUJZxrJsVS3CzoKvrck=; b=aYOzk59OcUHu1l4Sd/rYK9PO2jEh36FYRVnSkc/DvNXAZLMTUN4hp9iPjPqLzWkVUH UpCIzRbruyHvFujWKg7F8euNyYbnj31ySgZtUI73T1BKh7BGY4ZZoyzzhTmjISjo7qgv 7lyupMkRTJQMI35Hu+09gAMxbrTaXj1eitA/0=
Received: by 10.236.189.68 with SMTP id b44mr6589870yhn.125.1327622841476; Thu, 26 Jan 2012 16:07:21 -0800 (PST)
Received: from adsl-215-50-126.mia.bellsouth.net (99-3-147-93.lightspeed.miamfl.sbcglobal.net. [99.3.147.93]) by mx.google.com with ESMTPS id z3sm9824935yhd.3.2012.01.26.16.07.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jan 2012 16:07:20 -0800 (PST)
Message-ID: <4F21EACA.8010404@gmail.com>
Date: Thu, 26 Jan 2012 19:07:38 -0500
From: Hector 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: IETF-Discussion list 
Subject: Re: Forthcoming draft: draft-farrresnickel-ipr-sanctions
References: <4F21DDAB.9030300@qualcomm.com>
In-Reply-To: <4F21DDAB.9030300@qualcomm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 00:07:23 -0000

Pete Resnick wrote:
> Just a heads-up:
> 
> Adrian Farrel and I started work on a draft to focus discussion on 
> sanctions that could be applied to violators of the IETF's IPR policy. 
> Because of incidents like the present one, we've each been asked by WG 
> chairs and others what can be done in response to such violations. We've 
> centered our draft around sanctions that are available under current 
> IETF procedures, not introducing new ones. The draft  should be 
> available in the I-D repository soon. We think this could usefully 
> become an RFC and we would welcome discussion.
> 
> Thanks,
> 
> pr

Personally, this may be addressing the wrong problem.

However, I do think that a document or change in existing documents 
has merit to strongly focus on the fundamental idea that the 
integration of IETF RFC published technology is not subject to any 
kind of IPR restriction now or in the future.

Thats really the key problem here and its 100% related to the changes 
to the patent laws and how that has negatively affected the IETF IPR 
model which is old dated.

To the layman, experts call it the new timeline. The problem is the 
simplistic ideas that integrating existing known parts where never 
patentability prior to 1996.  This was relaxed in 1996 with whats 
called "Software Methods" or "Business Methods."  But what really 
changed is the the due diligence was no longer the patent examiner to 
perform the full Markus Analysis. He looked for the obvious but much 
of the responsibility was expected to be done by the applicant.

This is important because it hits home with all the long time systems, 
especially the all the systems out there that use some and/or these 
IETF parts and there is no reason to not expect they could use other 
IETF parts in the future (i.e. SIP).

 From the patent standpoint:

    pre-1996  :  SIP+SIEVE patent WOULD be denied. The PATENT is on 
the new METHOD
                 unique in the SIP+SIEVE integration, not the 
integration itself.
                 And a PHYSICAL DEMO must exist. The IDEA itself is 
not enough.

    1996-~2009:  SIP+SIEVE patent MAY be denied.  The patent MAY 
includes the
                 integration and encompasses all METHODS of integration.

    ~2009+    :  Further relaxation, SIP+SIEVE patent WILL NOT be denied
                 Any prior art disputes must be added to patent.  The 
RIGHT
                 to challenge is not denied but its 100% the burden of 
others.

IOW, now this the patent was filed for SIP+SIEVE, the impact is ALL 
existing systems, based on the 2009+ laws, CAN NOT add SIP to their 
SMTP/IMAP system using SIEVE.

Thats the problem Pete.  In short, I can no longer even consider the 
idea of using SIP with SIEVE any more even if my integrated method is 
unique.

The IETF needs to begin to address this serious problem of people 
using IETF technology parts in some integrated method and makes a 
"Business Method" patent claim.

I guess, if there is any "sanctions" it would be a simple idea that 
once a discovery of a claim is made purely based in the integration of 
IETF parts with nothing novel in the claim, then the I-D and/or RPC 
would be PULLED and no longer be a IETF document for consideration 
without a 100% PUBLIC/FREE/OPEN usage declaration.

Its a tough issue, but I think it becomes simply to deal with once the 
strong idea that mere integration of IETF parts is not patentable 
material.

--
HLS

From sant9442@gmail.com  Thu Jan 26 16:23:51 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEB721F8666 for ; Thu, 26 Jan 2012 16:23:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level: 
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150,  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 XdapzizsqSN0 for ; Thu, 26 Jan 2012 16:23:50 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5287C21F8663 for ; Thu, 26 Jan 2012 16:23:50 -0800 (PST)
Received: by ggnq4 with SMTP id q4so671789ggn.31 for ; Thu, 26 Jan 2012 16:23:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=oFGQbunjW1PS7vfUP1GqweVV+L82GTeBNue4/CHVBmM=; b=aUUh20uuXJdV0JtlX2y2oTe2mMOwXoO0bkSoiKzM/YkL4eY121V355eX5IZNQEv/LG CmC0/7cKMUMRSUFE/OpDLx6qhIXB+Hz0487WE8igAMN2OKlXOtN7+ZvYM30w/HLEXzBq MuhPdBGMNNFEt7WaKMlwc4pqIFGM3kwDJW03o=
Received: by 10.101.141.9 with SMTP id t9mr2071153ann.42.1327623829951; Thu, 26 Jan 2012 16:23:49 -0800 (PST)
Received: from adsl-215-50-126.mia.bellsouth.net (99-3-147-93.lightspeed.miamfl.sbcglobal.net. [99.3.147.93]) by mx.google.com with ESMTPS id n32sm13746394ani.8.2012.01.26.16.23.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jan 2012 16:23:48 -0800 (PST)
Message-ID: <4F21EEA6.6080200@gmail.com>
Date: Thu, 26 Jan 2012 19:24:06 -0500
From: Hector 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: adrian@olddog.co.uk
Subject: Re: Forthcoming draft: draft-farrresnickel-ipr-sanctions
References: <4F21DDAB.9030300@qualcomm.com>	<1DB386B5-47B1-4AB1-A60B-FFF4D6D40299@bbn.com> <016d01ccdc84$be098330$3a1c8990$@olddog.co.uk>
In-Reply-To: <016d01ccdc84$be098330$3a1c8990$@olddog.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 'IETF-Discussion list' 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 00:23:51 -0000

I believe one "strong axe" is a fundamental one:

    The mere integration of IETF parts is not patentable material or
    one that allows an new I-D based on the integration that is not
    patent free.

Its is far to easy today under the extremely relaxed patent laws to 
apply for a patent purely based on the integration of existing parts 
and rather than just patent the unique METHOD added to the 
integration, it now covers ALL methods of integrating the parts.

In other words, the IETF IPR guidelines needs to be updated to cover 
the issue.  If this new "sanctions" I-D attempts to update the IPR 
guidelines, then that may be good.

But it needs to address the fundamental problem that existing systems 
can not be denied to add an IETF technology that MAY be very natural 
in its evolution.  I may have a system with IMAP and SIEVE, should 
IETF recognize an IPR claim purely based on adding SIP to this system? 
or should it recognize only the UNIQUE METHOD employed in the integration?

These are all Markus Analysis concepts once used by patent examiners 
and a very strong part of that analysis was that a patent claim COULD 
NOT deny existing systems implement what would be a natural concept in 
its system.

--
HLS

Adrian Farrel wrote:
> Richard,
> 
> I think this is exactly the right situation for gut reactions.
> 
> The I-D specifically tries to stay away from being formulaic on the application
> of sanctions. IMHO the circumstances are too complex to write code to handle.
> Each application of sanctions will need human judgment.
> 
> We did (under some pressure :-) include an appendix to give some high-level
> guidance on "things to think about".
> 
> Bright lines and sharp axes would be nice, but even civilized nations rarely
> manage to achieve that in law systems. Unfortunate executions of innocent
> bystanders is to be avoided.
> 
> But I do think the IETF can handle these decisions. They are no harder than
> reaching rough consensus on intractable technical issues. And there seemed to me
> (when writing the I-D) to be something of a swell of opinion that supports
> applying sanctions.
> 
> Please continue to massage your gut, and react some more.
> 
> Cheers,
> Adrian
> 
>> -----Original Message-----
>> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
> Richard
>> L. Barnes
>> Sent: 26 January 2012 23:35
>> To: Pete Resnick
>> Cc: IETF-Discussion list
>> Subject: Re: Forthcoming draft: draft-farrresnickel-ipr-sanctions
>>
>> I appreciate that there need to be disincentives to infringing the IPR policy,
> but
>> I'm a little wary of the idea of codifying a system of sanctions.  Mainly for
> the
>> sorts of "gaming the system" thinking they engender:
>> -- Is the benefit of infringing worse than the cost of the sanction?
>> -- If it's not sanctionable, it must be ok!
>>
>> Plus, if there are sanctions, then you need a judgement process to decide when
>> the sanctions will be applied.  Is the IETF set up for that?
>>
>> Rather than bright lines and clear sanctions, it seems like a general culture
> of
>> conservatism, staying far away from things that could possibly be construed as
>> violations, would be more in tune with the way other things work at the IETF.
>>
>> No real answers here, just expressing a gut reaction.
>>
>> --Richard
>>
>>
>>
>> On Jan 26, 2012, at 6:11 PM, Pete Resnick wrote:
>>
>>> Just a heads-up:
>>>
>>> Adrian Farrel and I started work on a draft to focus discussion on sanctions
> that
>> could be applied to violators of the IETF's IPR policy. Because of incidents
> like the
>> present one, we've each been asked by WG chairs and others what can be done
>> in response to such violations. We've centered our draft around sanctions that
>> are available under current IETF procedures, not introducing new ones. The
> draft
>> should be available in the I-D repository soon. We think this could usefully
>> become an RFC and we would welcome discussion.
>>> Thanks,
>>>
>>> pr
>>>
>>> --
>>> Pete Resnick
>>> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>>>
>>> _______________________________________________
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
> 

From eburger-l@standardstrack.com  Thu Jan 26 16:54:06 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7197411E8075 for ; Thu, 26 Jan 2012 16:54:04 -0800 (PST)
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 IS-Iz1woB9Wz for ; Thu, 26 Jan 2012 16:54:03 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 8E75311E8076 for ; Thu, 26 Jan 2012 16:54:03 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com;  h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=TN/Xa6wKgVoixqC4Dhcs3TpPsbLAEfwAs2aWMFKRpvRTcdFeZ7FGHwO48OK4Oaffz8OTstwMrttU3fWqHeem1PN2X1b6HflwGvOq6uIFCfd7EGZiZRLJZVxrG54QDSlZ;
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:55102 helo=[192.168.15.184]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Rqa4m-0005j6-Lw for ietf@ietf.org; Thu, 26 Jan 2012 16:54:01 -0800
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Forthcoming draft: draft-farrresnickel-ipr-sanctions
From: Eric Burger 
In-Reply-To: <016501ccdc81$37918f80$a6b4ae80$@olddog.co.uk>
Date: Thu, 26 Jan 2012 19:53:56 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <0A425A9D-634D-4E53-992C-C23884175234@standardstrack.com>
References: <4F21DDAB.9030300@qualcomm.com> <016501ccdc81$37918f80$a6b4ae80$@olddog.co.uk>
To: IETF-Discussion list 
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 00:54:06 -0000

Shall we also set up a formal committee to hear patent filing =
accusations, a jury of nomcom-eligible members to pass judgement on the =
claim, an appeals board for the party that feels the jury made the wrong =
decision, a process document for the IESG to hear the appeal from the =
appeals board, a process document for the IAB to hear the appeal from =
the IESG, a process document for the ISOC President to hear the appeal =
from the IAB, and a prayer to G-d if the ISOC President gets appealed?

Would it not be easier if we just did public flogging?  It is so much =
easier to do and so much more fun to watch.

On Jan 26, 2012, at 6:21 PM, Adrian Farrel wrote:

> =
http://www.ietf.org/internet-drafts/draft-farrresnickel-ipr-sanctions-00.t=
xt
>=20
>> -----Original Message-----
>> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf =
Of Pete
>> Resnick
>> Sent: 26 January 2012 23:12
>> To: IETF-Discussion list
>> Subject: Forthcoming draft: draft-farrresnickel-ipr-sanctions
>>=20
>> Just a heads-up:
>>=20
>> Adrian Farrel and I started work on a draft to focus discussion on
>> sanctions that could be applied to violators of the IETF's IPR =
policy.
>> Because of incidents like the present one, we've each been asked by =
WG
>> chairs and others what can be done in response to such violations. =
We've
>> centered our draft around sanctions that are available under current
>> IETF procedures, not introducing new ones. The draft  should be
>> available in the I-D repository soon. We think this could usefully
>> become an RFC and we would welcome discussion.
>>=20
>> Thanks,
>>=20
>> pr
>>=20
>> --
>> Pete Resnick
>> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: =
(858)651-1102
>>=20
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
>=20
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf


From stewe@stewe.org  Thu Jan 26 16:56:02 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F8C21F86EB for ; Thu, 26 Jan 2012 16:56:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.769
X-Spam-Level: 
X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[AWL=0.230,  BAYES_00=-2.599, J_CHICKENPOX_35=0.6]
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 gErnmvqAMl6s for ; Thu, 26 Jan 2012 16:56:01 -0800 (PST)
Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 4718721F86B2 for ; Thu, 26 Jan 2012 16:55:59 -0800 (PST)
Received: from [192.168.1.64] (unverified [71.202.147.60])  by stewe.org (SurgeMail 3.9e) with ESMTP id 17153-1743317  for multiple; Fri, 27 Jan 2012 01:55:58 +0100
User-Agent: Microsoft-MacOutlook/14.14.0.111121
Date: Thu, 26 Jan 2012 16:55:30 -0800
Subject: Re: Forthcoming draft: draft-farrresnickel-ipr-sanctions
From: Stephan Wenger 
To: Hector , IETF-Discussion list 
Message-ID: 
Thread-Topic: Forthcoming draft: draft-farrresnickel-ipr-sanctions
In-Reply-To: <4F21EACA.8010404@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Originating-IP: 71.202.147.60
X-Authenticated-User: stewe@stewe.org 
X-ORBS-Stamp: Your IP (71.202.147.60) was found in the spamhaus database. http://www.spamhaus.net
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 00:56:02 -0000

Dear Hector,

I'm not quite sure that your understanding of the US patent law and MPEP
rules is inline with most patent practitioners, or that your post
otherwise make all that much sense.

First, the thing you are talking about are known as "Markush Claim".  From
MPEP, 803.02: "A Markush-type claim recites alternatives in a format such
as "selected from the group consisting of A, B and C."  It deals with the
examiners reaction to situations where there are too many group members
(typically much more than three, A, B, C; those group members are not
sufficiently closely related to deal with them as a group, and where the
examiner would face a burden to examine the the claim because A, B, and C,
each in combination with the rest of the claim, would require a very
different Prior Art search for each A, B, and C.

Second, based on my very quick scanning over the patent application in
question here, your whole discussion does not appear to apply as the
application contains not a single Markush claim.

Third, the developments in patent law (more precisely here: US examination
rules, MPEP, re Markush claims) are US local.  Surely, you don't want to
tie the operating procedures of an international organization like the
IETF to a mere rule change in one legislation.
 
Fourth, your analysis below of what was/is patentable does not seem
correct.  AFAIK, nothing earth-shattering has changed with respect to
patentability of novel combinations of known subject matter.  Markush
claims are about a certain way to express selections, but there are many
other ways.  For example, I believe in bioscience it is now common
practice to avoid Markush claims and rather spell out all combinations in
dependent claims, and just absorb the excess claim fees.  (I have seen
biotech patents with more than 500 claims).

Fifth, and finally, your "idea of a sanction" would result in a major
policy change, essentially disallowing any IETF work moving forward that
is not "100% PUBLIC/FREE/OPEN".  This may or may not be a good idea, but
it's not the discussion we have here.

Best regards,
Stephan
 


On 1.26.2012 16:07 , "Hector"  wrote:

>Pete Resnick wrote:
>> Just a heads-up:
>> 
>> Adrian Farrel and I started work on a draft to focus discussion on
>> sanctions that could be applied to violators of the IETF's IPR policy.
>> Because of incidents like the present one, we've each been asked by WG
>> chairs and others what can be done in response to such violations.
>>We've 
>> centered our draft around sanctions that are available under current
>> IETF procedures, not introducing new ones. The draft  should be
>> available in the I-D repository soon. We think this could usefully
>> become an RFC and we would welcome discussion.
>> 
>> Thanks,
>> 
>> pr
>
>Personally, this may be addressing the wrong problem.
>
>However, I do think that a document or change in existing documents
>has merit to strongly focus on the fundamental idea that the
>integration of IETF RFC published technology is not subject to any
>kind of IPR restriction now or in the future.
>
>Thats really the key problem here and its 100% related to the changes
>to the patent laws and how that has negatively affected the IETF IPR
>model which is old dated.
>
>To the layman, experts call it the new timeline. The problem is the
>simplistic ideas that integrating existing known parts where never
>patentability prior to 1996.  This was relaxed in 1996 with whats
>called "Software Methods" or "Business Methods."  But what really
>changed is the the due diligence was no longer the patent examiner to
>perform the full Markus Analysis. He looked for the obvious but much
>of the responsibility was expected to be done by the applicant.
>
>This is important because it hits home with all the long time systems,
>especially the all the systems out there that use some and/or these
>IETF parts and there is no reason to not expect they could use other
>IETF parts in the future (i.e. SIP).
>
> From the patent standpoint:
>
>    pre-1996  :  SIP+SIEVE patent WOULD be denied. The PATENT is on
>the new METHOD
>                 unique in the SIP+SIEVE integration, not the
>integration itself.
>                 And a PHYSICAL DEMO must exist. The IDEA itself is
>not enough.
>
>    1996-~2009:  SIP+SIEVE patent MAY be denied.  The patent MAY
>includes the
>                 integration and encompasses all METHODS of integration.
>
>    ~2009+    :  Further relaxation, SIP+SIEVE patent WILL NOT be denied
>                 Any prior art disputes must be added to patent.  The
>RIGHT
>                 to challenge is not denied but its 100% the burden of
>others.
>
>IOW, now this the patent was filed for SIP+SIEVE, the impact is ALL
>existing systems, based on the 2009+ laws, CAN NOT add SIP to their
>SMTP/IMAP system using SIEVE.
>
>Thats the problem Pete.  In short, I can no longer even consider the
>idea of using SIP with SIEVE any more even if my integrated method is
>unique.
>
>The IETF needs to begin to address this serious problem of people
>using IETF technology parts in some integrated method and makes a
>"Business Method" patent claim.
>
>I guess, if there is any "sanctions" it would be a simple idea that
>once a discovery of a claim is made purely based in the integration of
>IETF parts with nothing novel in the claim, then the I-D and/or RPC
>would be PULLED and no longer be a IETF document for consideration
>without a 100% PUBLIC/FREE/OPEN usage declaration.
>
>Its a tough issue, but I think it becomes simply to deal with once the
>strong idea that mere integration of IETF parts is not patentable
>material.
>
>--
>HLS
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www.ietf.org/mailman/listinfo/ietf



From dhc@dcrocker.net  Thu Jan 26 17:20:02 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4BA21F8630 for ; Thu, 26 Jan 2012 17:20:02 -0800 (PST)
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 ETxenfOpqKGi for ; Thu, 26 Jan 2012 17:20:01 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9368C21F8627 for ; Thu, 26 Jan 2012 17:20:01 -0800 (PST)
Received: from [192.168.42.203] (mee0536d0.tmodns.net [208.54.5.238]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0R1JraK025503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jan 2012 17:20:01 -0800
Message-ID: <4F21FBB3.8050604@dcrocker.net>
Date: Thu, 26 Jan 2012 17:19:47 -0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: IETF-Discussion list 
Subject: Re: Forthcoming draft: draft-farrresnickel-ipr-sanctions
References: <4F21DDAB.9030300@qualcomm.com> <1DB386B5-47B1-4AB1-A60B-FFF4D6D40299@bbn.com>
In-Reply-To: <1DB386B5-47B1-4AB1-A60B-FFF4D6D40299@bbn.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]); Thu, 26 Jan 2012 17:20:01 -0800 (PST)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 01:20:02 -0000

On 1/26/2012 3:35 PM, Richard L. Barnes wrote:
> I appreciate that there need to be disincentives to infringing the IPR policy, but I'm a little wary of the idea of codifying a system of sanctions.  Mainly for the sorts of "gaming the system" thinking they engender:


It is likely that we have already been seeing gaming by organizations.  More 
than once and by more than one.

The reality is that people and companies that want to find ways to work around 
barriers they don't like will do that.  The belief that codification encourages 
this is, I believe, without empirical basis.[1]  What /is/ empirically 
demonstrated is that the IETF is in a poor position with respect to such actions 
that run contrary to our culture.

The IETF currently relies on a bit of mythology that worked well 20 years ago 
but is very skewed with respect to reality today.  The core of that mythology 
concerns individual contribution and it's important that we keep it, for all 
sorts of reasons.

What I believe is /not/ worth keeping -- and which we have already made 
piecemeal concessions to -- is that corporations in fact /do/ participate in the 
IETF and need to be treated as responsible participants.  (Note that the word 
responsible, here, has two interpretations.  I mean both of them.)

Organizations that do not adapt to a changed world experience the same fate as 
species that don't adapt.

The fear about codification that /does/ make sense to me is in making rules that 
are superficial, overly detailed, misdirected, excessively rigid, or the like. 
In other words, yes, we need to make changes carefully.  We need to formulate 
clear principles, proper procedures, adequate mechanisms for exceptions, etc., etc.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From barryleiba.mailing.lists@gmail.com  Thu Jan 26 17:50:18 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C0021F862B for ; Thu, 26 Jan 2012 17:50:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.931
X-Spam-Level: 
X-Spam-Status: No, score=-102.931 tagged_above=-999 required=5 tests=[AWL=0.046, 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 HQGUMPxlQHdm for ; Thu, 26 Jan 2012 17:50:17 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3A81D21F862F for ; Thu, 26 Jan 2012 17:50:17 -0800 (PST)
Received: by yhnn12 with SMTP id n12so631763yhn.31 for ; Thu, 26 Jan 2012 17:50:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=2gP27Hesl9eduIzJ0LZSUcAvnBizQf//MTA/J/619iE=; b=k5WY/CSKCdvH/Un9fMLSo3M7XCjxn2SWGGgOuCbxZnRhjfhXs+QY6k2jrE+YXtERb8 XtZxl1dQDntK4L7/MqwZ/Ht9DAX6rcrc661MXUOTFe0hZUa/hqpy0wMOR7IEesHXm5nG cE7V/Qvn6RvKB/J8o1ZNUKu2g736plH8ayMi8=
MIME-Version: 1.0
Received: by 10.236.133.210 with SMTP id q58mr7299184yhi.6.1327629016744; Thu, 26 Jan 2012 17:50:16 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.146.136.20 with HTTP; Thu, 26 Jan 2012 17:50:16 -0800 (PST)
In-Reply-To: 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com>  <4F21ABF2.7040002@qualcomm.com> <6842.1327617385@marajade.sandelman.ca> 
Date: Thu, 26 Jan 2012 20:50:16 -0500
X-Google-Sender-Auth: MguBEU-FxPV6zo5EamCFc1rBWb0
Message-ID: 
Subject: Re: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
From: Barry Leiba 
To: "ietf@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 01:50:18 -0000

On Thu, Jan 26, 2012 at 4:16 PM, SM  wrote:
> I have not seen any feedback from IETF participants affiliated with Huawe=
i.

Hi.
I'm affiliated with Huawei.  I'm a (recently added; see below)
co-editor on the two Sieve documents.  I'm a chair of three working
groups.

> I suggest that the IESG does not process any Internet-Drafts until a
> decision has been taken.

That seems excessive.  Shut down all document progress until we
resolve this issue?  I think that cure is far worse than the disease.

On Thu, Jan 26, 2012 at 12:37 PM, John C Klensin 
wrote:>> We were told by the other company employees who facilitated
>> the disclosures, at the time of the disclosures, that this was>> strictl=
y an individual's failure to comply with the IETF IPR>> Policy, that the au=
thor in question claims not to have>> understood the IETF IPR Policy, and t=
hat the company proceeded>> to make these disclosures as soon as it discove=
red that this>> IPR existed. I have no information to contradict that claim=
.>> Excellent. =A0 I had hoped that was the situation. =A0It obviously> mak=
es things much easier (and some of my earlier comments> irrelevant). =A0 Wi=
th all the effort we go to ("Note Well" and> otherwise) to be sure that peo=
ple are informed about the policy,> I have trouble generating sympathy for =
someone who says "didn't> underatand", but that is another matter (and perh=
aps just my> problem).
That is, indeed the situation.  Qian Sun, the original Huawei author,
got a new assignment in the company, and stopped participating in the
IETF a few years ago, after he and Alexey had started the documents.
I can't speak for him about why he didn't understand the disclosure
rules; as I understand it, he seems to have thought the patents didn't
need to be disclosed until the RFC was published.

> If the other authors from that company have already told us that
> they were not aware of the patent application until very late in
> the process and that they moved diligently toward getting an
> appropriate disclosure filed as soon as they did find out, my
> suggestion is moot.

Some time last year, Kepeng and I offered to work with Alexey to
finish the two docs, which had seen slow progress for some while.
Only when the documents were approved and in the RFC Editor queue did
Kepeng learn about Qian's patent applications.  He immediately alerted
me.  I asked the RFC Editor to stop publication (one was in AUTH48 at
the time), and alerted Pete Resnick and the Sieve chairs.  Kepeng
pushed Huawei's IP law department to expedite the disclosure, which
they turned around in two days for us.  I assure all of you that
Kepeng and I were blindsided by this.

> I was concerned about the (thoroughly unlikely in this case)
> possibility that the other authors from that company were> personally awa=
re of the IPR but had been, e.g., advised that> they were not to make the d=
isclosure because someone else would> take responsibility for it.
Unlikely in this case, yes.  I leave it to you whether you trust what
I say, but I can only repeat that we did not know, and acted very
quickly when we found out.
On Thu, Jan 26, 2012 at 5:45 PM, Murray S. Kucherawy  wr=
ote:
> I also thought about suggesting a DNP or a standing DISCUSS or something =
until
> the license terms are made more IETF-friendly

I am not a lawyer, but I don't think the license terms are at issue
here.  As I understand it, the terms that Huawei has been specifying
in its disclosures are defensive, and shouldn't restrict standards
implementations.  The issue we're discussing isn't the terms, but that
the disclosures weren't made when they should have been.

I can't speak officially for Huawei in general, but I can say that it
is Huawei's company policy that we *do* comply with the rules of the
organizations we participate in.  I can also say that starting a
couple of years ago, we have taken many opportunities to remind all of
our IETF participants of the disclosure requirements, and we have a
coordinator in place to help them if they need help.  And some of the
disclosures you're seeing now are due to a concerted effort to find
where we've missed, and to rectify the situations by disclosing now.

> The document could be restricted to Experimental status, but that presume=
s the
> status matters as much as or more than the RFC number. =A0I don't know if=
 that's
> true or not in this case.

That, too, strikes me as a cure that's worse than the disease.
"Experimental" isn't a punishment, and I think it would be a horrid
idea to use the document's status in that way.  Protocols are
Experimental or Standards Track for good reasons.  Documents are
Informational or not for good reasons.  Let's please not adulterate
the document status as a way of addressing personnel issues.  And by
altering the status or refusing to publish a completed document, we
affect the working group and the entire community of prospective
implementors.  If a protocol (or informational document or whatever)
was worth publishing in the first place, pulling it or reclassifying
it as a punishment does the community a disservice.

The reason to remove or reclassify a document is if the working group
(or the community) thinks that for that particular document, the
intellectual property issue really does affect whether the document
should be published, or what its classification should be,
irrespective of any punishment.

Barry

From presnick@qualcomm.com  Thu Jan 26 18:20:53 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1447121F872F for ; Thu, 26 Jan 2012 18:20:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.562
X-Spam-Level: 
X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 7At6f5u4XKzE for ; Thu, 26 Jan 2012 18:20:51 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id D191021F86C7 for ; Thu, 26 Jan 2012 18:20:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1327630848; x=1359166848; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F220972.8070802@qualcomm.com>|Date:=20Th u,=2026=20Jan=202012=2020:18:26=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20"Richard=20L.=20Barnes"=20|CC:=20IETF-Discussion=20list=20|Subject:=20Re:=20Forthcoming=20draft:=20draft-farrres nickel-ipr-sanctions|References:=20<4F21DDAB.9030300@qual comm.com>=20<1DB386B5-47B1-4AB1-A60B-FFF4D6D40299@bbn.com >|In-Reply-To:=20<1DB386B5-47B1-4AB1-A60B-FFF4D6D40299@bb n.com>|Content-Type:=20text/plain=3B=20charset=3D"ISO-885 9-1"=3B=20format=3Dflowed|Content-Transfer-Encoding:=207b it|X-Originating-IP:=20[172.30.48.1]; bh=Do+9krLl7nJqZTaoppSPOEF/qsDHryXWJX6wDxnkV3Q=; b=d99d5QbBd0D68EtltRZKDUAP5SqmDwUd5ztzj6ymTPa/gZIcAZlqLuVZ KQCmmWvKVSTp1dwZF70HYoelpRfxR5YggNbnlk+sfbD18T4DBCCTvDFcA iSVgELw1Zmyj/sqwNNN2U6lhSbcVS9YG5mBtG9hhmtkXWSoK+A5P4P4GE Q=;
X-IronPort-AV: E=McAfee;i="5400,1158,6601"; a="155965637"
Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 26 Jan 2012 18:20:48 -0800
X-IronPort-AV: E=Sophos;i="4.71,574,1320652800"; d="scan'208";a="157189228"
Received: from nasanexhc05.na.qualcomm.com ([172.30.48.2]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 26 Jan 2012 18:20:48 -0800
Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 26 Jan 2012 18:18:29 -0800
Message-ID: <4F220972.8070802@qualcomm.com>
Date: Thu, 26 Jan 2012 20:18:26 -0600
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: "Richard L. Barnes" 
Subject: Re: Forthcoming draft: draft-farrresnickel-ipr-sanctions
References: <4F21DDAB.9030300@qualcomm.com> <1DB386B5-47B1-4AB1-A60B-FFF4D6D40299@bbn.com>
In-Reply-To: <1DB386B5-47B1-4AB1-A60B-FFF4D6D40299@bbn.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.48.1]
Cc: IETF-Discussion list 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 02:20:53 -0000

Reinforcing some of what Adrian said:

On 1/26/12 5:35 PM, Richard L. Barnes wrote:

> I appreciate that there need to be disincentives to infringing the IPR policy, but I'm a little wary of the idea of codifying a system of sanctions.  Mainly for the sorts of "gaming the system" thinking they engender:
> -- Is the benefit of infringing worse than the cost of the sanction?
> -- If it's not sanctionable, it must be ok!
>    

This is a line we have worried about. Remember, this document came out 
of us being asked, "What can we do about these violations?" and our 
answer being, "You already have the tools in your bag. Apply them to the 
situation as you see fit." I'm pretty sure we *don't* want a "codified 
system of sanctions", and if the document is too far in that direction, 
I'd certainly be open to suggestions to make it less so.

> Plus, if there are sanctions, then you need a judgement process to decide when the sanctions will be applied.  Is the IETF set up for that?
>    

My view here is that you don't need a "judgment process"; you need 
judgment. That's what the bit in section 6 and the appendix are getting 
at: Members of the community and chairs and ADs have to take a look at 
the situation and decide what is appropriate to the situation. If 
someone is disrupting the process by making late disclosures, they can 
be sanctioned for it, and that sanction might amount to a chair saying, 
"Please try to contribute more productively to the WG by making these 
disclosures earlier", just as they would say to someone who is making 
obnoxious comments to a WG, "Please try to contribute more productively 
by sticking to the technical issues." Or they might fire the person as a 
document editor. Or they might initiate a PR Action. None of these are 
required, and most don't require much formal process. They do require 
some judgment on the part of the WG and chair.

> Rather than bright lines and clear sanctions, it seems like a general culture of conservatism, staying far away from things that could possibly be construed as violations, would be more in tune with the way other things work at the IETF.
>    

I couldn't agree more. As cited in the document, coming up with ways to 
make it more likely that people do the right thing is the topic of 
another document. This was strictly aimed at, "Are there things to do 
when the situation goes pear-shaped?"

> No real answers here, just expressing a gut reaction.
>    

Exceedingly helpful. Thanks.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From ted.ietf@gmail.com  Thu Jan 26 18:26:43 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80C421F86F0 for ; Thu, 26 Jan 2012 18:26:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.434
X-Spam-Level: 
X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=0.165,  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 Uj-mzTqmfhn2 for ; Thu, 26 Jan 2012 18:26:42 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D3D5A21F86EB for ; Thu, 26 Jan 2012 18:26:41 -0800 (PST)
Received: by yhnn12 with SMTP id n12so642311yhn.31 for ; Thu, 26 Jan 2012 18:26:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=T4s0oBX7thyfSJ9VSgvcPrnwPvS8g+kV8et6vtx6DRw=; b=ZZ7ZdJJcpbL7BfcMknuBEwcKU6+0+juLVzTkjSzCGlBZ7DKP5/nlC3cuFrPAPvpWRk 56JtP9UrpHynqNZ/83z1uGBe/Bsv3LL68ijcsOZKeplF3/akVpNa2tZUi9uMQLsiZ24e Mnkevy0tidrz5MjqOPcxrUwbMSgY4Jx13rZxc=
MIME-Version: 1.0
Received: by 10.236.154.232 with SMTP id h68mr7369602yhk.51.1327631201313; Thu, 26 Jan 2012 18:26:41 -0800 (PST)
Received: by 10.236.180.230 with HTTP; Thu, 26 Jan 2012 18:26:41 -0800 (PST)
In-Reply-To: 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com>  <4F21ABF2.7040002@qualcomm.com> <6842.1327617385@marajade.sandelman.ca>  
Date: Thu, 26 Jan 2012 18:26:41 -0800
Message-ID: 
Subject: Re: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
From: Ted Hardie 
To: Barry Leiba 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "ietf@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 02:26:43 -0000

On Thu, Jan 26, 2012 at 5:50 PM, Barry Leiba  wrot=
e:

> I am not a lawyer, but I don't think the license terms are at issue
> here. =A0As I understand it, the terms that Huawei has been specifying
> in its disclosures are defensive, and shouldn't restrict standards
> implementations. =A0The issue we're discussing isn't the terms, but that
> the disclosures weren't made when they should have been.
>

While I appreciate the recitation of unfortunate events that led us
here, I don't quite share the view that the license terms are not at
issue here.  The reason that we have an IPR rule that asks us to
declare what the terms of a license are is so that the working groups'
members can evaluate both the applicability of the potentially
encumbering patents and the terms of the license.

The later those are made clear, the harder it is for the working
group.  It may have to abandon a lot of work at a late stage, which is
difficult if deadlines are looming or, worse, code has been shipped.
A license which was an outright grant would have no impact on that,
so the lack of timely disclosure has a smaller overall impact.  It's
still bad form, but not really more.   For a royalty-bearing license,
there is an obvious cost; for a defensive license, there is a less
obvious, but potentially real, cost.  If example.com sues Huawei for
any reason, they lose this license and can no longer use the
technology the WG agreed to standardize with purchasing a FRAND
license on the other (less-specified) terms.

I have no advice on this particular case, but the general point seems
to me important.

regards,

Ted

From smb@cs.columbia.edu  Thu Jan 26 19:15:25 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4E121F864A for ; Thu, 26 Jan 2012 19:15:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.43
X-Spam-Level: 
X-Spam-Status: No, score=-5.43 tagged_above=-999 required=5 tests=[AWL=1.169,  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 0Uy5KRN9r0nL for ; Thu, 26 Jan 2012 19:15:24 -0800 (PST)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id B51F321F8646 for ; Thu, 26 Jan 2012 19:15:24 -0800 (PST)
Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q0R3FLaa020040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 26 Jan 2012 22:15:21 -0500 (EST)
Subject: Re: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: Steven Bellovin 
In-Reply-To: 
Date: Thu, 26 Jan 2012 22:15:21 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <66BF157F-0BC3-44ED-8D77-D162C14A3CB3@cs.columbia.edu>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com>  <4F21ABF2.7040002@qualcomm.com> <6842.1327617385@marajade.sandelman.ca>   
To: Ted Hardie 
X-Mailer: Apple Mail (2.1251.1)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8
Cc: Barry Leiba , "ietf@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 03:15:25 -0000

On Jan 26, 2012, at 9:26 41PM, Ted Hardie wrote:

> On Thu, Jan 26, 2012 at 5:50 PM, Barry Leiba  =
wrote:
>=20
>> I am not a lawyer, but I don't think the license terms are at issue
>> here.  As I understand it, the terms that Huawei has been specifying
>> in its disclosures are defensive, and shouldn't restrict standards
>> implementations.  The issue we're discussing isn't the terms, but =
that
>> the disclosures weren't made when they should have been.
>>=20
>=20
> While I appreciate the recitation of unfortunate events that led us
> here, I don't quite share the view that the license terms are not at
> issue here.  The reason that we have an IPR rule that asks us to
> declare what the terms of a license are is so that the working groups'
> members can evaluate both the applicability of the potentially
> encumbering patents and the terms of the license.


Yes, precisely.  This is spelled out quite explicitly in Sections 5.2 =
and 5.3
of RFC 3669, and Section 6.5 of 3979.

		--Steve Bellovin, https://www.cs.columbia.edu/~smb






From sant9442@gmail.com  Thu Jan 26 19:16:46 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0B221F86EB for ; Thu, 26 Jan 2012 19:16:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.199
X-Spam-Level: 
X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, 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 V7pAr3eTKiIi for ; Thu, 26 Jan 2012 19:16:45 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B29521F86DE for ; Thu, 26 Jan 2012 19:16:44 -0800 (PST)
Received: by yhnn12 with SMTP id n12so656436yhn.31 for ; Thu, 26 Jan 2012 19:16:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=HUfPCG0w0+9Zzc6Ajgmepl3CUY1XoIoQOjeinIymII4=; b=t1ewLqVA9bVkrwob1nVdl3HKyl3qd/DzBTWtPeWxdmGKzjYx45QwSe3nkoYxhgnaSf liCZzFHMv8nMLpe8xcGPZt9tL+T+loz5U+CUiE59hzl5HQ84dV9tuyok/BkzWBgKChBa oxm6JXMNXxuDUObQ8DILzyXEz3yQajaPm5a6g=
Received: by 10.236.139.132 with SMTP id c4mr7167976yhj.68.1327634204485; Thu, 26 Jan 2012 19:16:44 -0800 (PST)
Received: from adsl-215-50-126.mia.bellsouth.net (99-3-147-93.lightspeed.miamfl.sbcglobal.net. [99.3.147.93]) by mx.google.com with ESMTPS id 6sm2575737anp.14.2012.01.26.19.16.42 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jan 2012 19:16:43 -0800 (PST)
Message-ID: <4F22172E.60700@gmail.com>
Date: Thu, 26 Jan 2012 22:17:02 -0500
From: Hector 
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: IETF-Discussion list 
Subject: Re: Forthcoming draft: draft-farrresnickel-ipr-sanctions
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 03:16:46 -0000

Stephan Wenger wrote:
> Dear Hector,
> 
> I'm not quite sure that your understanding of the US patent law and MPEP
> rules is inline with most patent practitioners, or that your post
> otherwise make all that much sense.
> 
> First, the thing you are talking about are known as "Markush Claim".  From
> MPEP, 803.02: "A Markush-type claim recites alternatives in a format such
> as "selected from the group consisting of A, B and C."  It deals with the
> examiners reaction to situations where there are too many group members
> (typically much more than three, A, B, C; those group members are not
> sufficiently closely related to deal with them as a group, and where the
> examiner would face a burden to examine the the claim because A, B, and C,
> each in combination with the rest of the claim, would require a very
> different Prior Art search for each A, B, and C.

My experience come from three folds:

1) As a chemical engineer at Mobil R&D and recalling all the patent 
conflicts (and case history) with Exxon strictly based on the "left 
hand, right hand," twisting and mirroring of chemical and molecular 
structures;

2) Westinghouse training when I was part of a think tank (Advanced 
Ventures Division) where the charter was to "Bring back the light bulb 
business!" We had a "Card Blanc" to look at everything, to see what 
patents will stick, regardless of how simplistic and frivolous.  In 
order to not waste people time, especially the lawyers, I specifically 
recall the chief counsel presentations on Markush with a specific 
summarize outline on the two points:

    a) You can not patent an combination of prior arts.  One new 
unique part
       must exist.

    b) Very importantly, dealing with existing companies that already 
used the
       prior art and in natural evolution could use a new part.  In 
other words,
       you can not deny a company to grow.

3) Moving in my own business and having Reed-Smith as my legal counsel and
dealing with our technologies.  Main point here, much of our system is 
already integration of prior art, and what is not, we decided to use 
trade secrets instead. I was not allowed to patent ideas of the system 
that today I could using the new Patent TimeLine where prior art means 
less.

> Second, based on my very quick scanning over the patent application in
> question here, your whole discussion does not appear to apply as the
> application contains not a single Markush claim.

And thats by design because the trick is to claim Plausible 
Deniability because once upon a time, it was a criminal fine to 
intentional ignore prior art and if it were before a judge, he will 
quick toss the patent and will not accept ignorance.   That has 
changed under today's patent laws where now the applicant is allowed 
to update the patent and add the prior art claim.

> Third, the developments in patent law (more precisely here: US examination
> rules, MPEP, re Markush claims) are US local.  Surely, you don't want to
> tie the operating procedures of an international organization like the
> IETF to a mere rule change in one legislation.

+1, and the fact its global, makes it more difficult. But the problem 
is universal.

> Fourth, your analysis below of what was/is patentable does not seem
> correct.  AFAIK, nothing earth-shattering has changed with respect to
> patentability of novel combinations of known subject matter.  Markush
> claims are about a certain way to express selections, but there are many
> other ways.  For example, I believe in bioscience it is now common
> practice to avoid Markush claims and rather spell out all combinations in
> dependent claims, and just absorb the excess claim fees.  (I have seen
> biotech patents with more than 500 claims).

See above.  The approach today is not to claim specifics and encompass 
the basic integration to avoid the problems in the past.  Its goes 
along with the idea that beneficiary was generally not the inventor 
but rather the 2nd copy cat who was privy now to learn from the 
invention and business/market failures of the inventor.

> Fifth, and finally, your "idea of a sanction" would result in a major
> policy change, essentially disallowing any IETF work moving forward that
> is not "100% PUBLIC/FREE/OPEN".  This may or may not be a good idea, but
> it's not the discussion we have here.

I generally try to get away from specific issues and generally more 
interested in solving the overall problem that will serve all.  This 
case is more than likely typical of things to come and the IETF needs 
to be ready for it.

For one thing, the "Note Well" statement means nothing. Its not 
binding whatsoever and its most likely skipped by people.  Its #1 
problem is that it does nothing to address the lurkers. Of course not. 
  So simply reading a work group is just a good material to get ideas 
to patent and guess what?  I don't have to write a single note to the 
group or even write an I-D or anything like that.  So one question may be:

      Does becoming a list member to a working group qualifies you as 
part of the
      Note Well "awareness" regardless of your silent participation?

Second, my only point as a possible consideration is to look at how 
Markush is used as a model for the IETF.  In other words, all the 
parts in the case:

   SMTP
   IMAP
   SIEVE
   SIP

are already IETF sanctioned material and anyone can implement these 
technologies without any IPR related issue.

The problem is not the patent itself, that is already questionable, 
the problem is that the IETF needs to mold the industry mindset so 
that the basic idea of adding SIP to your current system using SIEVE 
is not IPR restricted.   I have no problem with the "Extra Part" that 
makes the integration patentable.  But combing the two MUST not be 
restricted simply because individually there are already unrestricted 
IETF technologies.

Finally, whether or not I am out of the loop of what you deem 
appropriate for the discussion, my only point and I won't waste any 
more time on this, is how I see the issue.  Its more a general problem 
and really not specific to this SIP+SIEVE issue and if the IETF 
doesn't deal with that, this is going to be a very common problem. 
Just consider, maybe I am not the norm, like to do I am, but today I 
will avoid any IETF I-D that even walks, talks and smells like there 
will be any IPR restrictions.

One last point is that my advisers has long recommended that I 
completely stay away from the IETF and especially the working groups 
and list forums, exactly for many of the reasons we see.  I am very 
careful of any I-D I did submit and avoided submitting I-D for ideas I 
felt had possibilities to be patentable material, especially under the 
new patent relaxations for "Business Methods" and less emphasis on 
Markush.  So in one view, maybe that is the outcome we want - for 
people to be more aware of what they are doing.  Don't submit 
something that you know can be problematic,

Anyway, thanks for your comments.

--
HLS


> On 1.26.2012 16:07 , "Hector"  wrote:
> 
>> Pete Resnick wrote:
>>> Just a heads-up:
>>>
>>> Adrian Farrel and I started work on a draft to focus discussion on
>>> sanctions that could be applied to violators of the IETF's IPR policy.
>>> Because of incidents like the present one, we've each been asked by WG
>>> chairs and others what can be done in response to such violations.
>>> We've 
>>> centered our draft around sanctions that are available under current
>>> IETF procedures, not introducing new ones. The draft  should be
>>> available in the I-D repository soon. We think this could usefully
>>> become an RFC and we would welcome discussion.
>>>
>>> Thanks,
>>>
>>> pr
>> Personally, this may be addressing the wrong problem.
>>
>> However, I do think that a document or change in existing documents
>> has merit to strongly focus on the fundamental idea that the
>> integration of IETF RFC published technology is not subject to any
>> kind of IPR restriction now or in the future.
>>
>> Thats really the key problem here and its 100% related to the changes
>> to the patent laws and how that has negatively affected the IETF IPR
>> model which is old dated.
>>
>> To the layman, experts call it the new timeline. The problem is the
>> simplistic ideas that integrating existing known parts where never
>> patentability prior to 1996.  This was relaxed in 1996 with whats
>> called "Software Methods" or "Business Methods."  But what really
>> changed is the the due diligence was no longer the patent examiner to
>> perform the full Markus Analysis. He looked for the obvious but much
>> of the responsibility was expected to be done by the applicant.
>>
>> This is important because it hits home with all the long time systems,
>> especially the all the systems out there that use some and/or these
>> IETF parts and there is no reason to not expect they could use other
>> IETF parts in the future (i.e. SIP).
>>
>> From the patent standpoint:
>>
>>    pre-1996  :  SIP+SIEVE patent WOULD be denied. The PATENT is on
>> the new METHOD
>>                 unique in the SIP+SIEVE integration, not the
>> integration itself.
>>                 And a PHYSICAL DEMO must exist. The IDEA itself is
>> not enough.
>>
>>    1996-~2009:  SIP+SIEVE patent MAY be denied.  The patent MAY
>> includes the
>>                 integration and encompasses all METHODS of integration.
>>
>>    ~2009+    :  Further relaxation, SIP+SIEVE patent WILL NOT be denied
>>                 Any prior art disputes must be added to patent.  The
>> RIGHT
>>                 to challenge is not denied but its 100% the burden of
>> others.
>>
>> IOW, now this the patent was filed for SIP+SIEVE, the impact is ALL
>> existing systems, based on the 2009+ laws, CAN NOT add SIP to their
>> SMTP/IMAP system using SIEVE.
>>
>> Thats the problem Pete.  In short, I can no longer even consider the
>> idea of using SIP with SIEVE any more even if my integrated method is
>> unique.
>>
>> The IETF needs to begin to address this serious problem of people
>> using IETF technology parts in some integrated method and makes a
>> "Business Method" patent claim.
>>
>> I guess, if there is any "sanctions" it would be a simple idea that
>> once a discovery of a claim is made purely based in the integration of
>> IETF parts with nothing novel in the claim, then the I-D and/or RPC
>> would be PULLED and no longer be a IETF document for consideration
>> without a 100% PUBLIC/FREE/OPEN usage declaration.
>>
>> Its a tough issue, but I think it becomes simply to deal with once the
>> strong idea that mere integration of IETF parts is not patentable
>> material.
>>
>> --
>> HLS
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
> 

From barryleiba@gmail.com  Thu Jan 26 19:28:38 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A6C21F85DD for ; Thu, 26 Jan 2012 19:28:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.632
X-Spam-Level: 
X-Spam-Status: No, score=-102.632 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, 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 XMpzHome7FlF for ; Thu, 26 Jan 2012 19:28:38 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 02A9D21F85D8 for ; Thu, 26 Jan 2012 19:28:37 -0800 (PST)
Received: by obbwc12 with SMTP id wc12so1516791obb.31 for ; Thu, 26 Jan 2012 19:28:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6xsqdJ4FnhnPzmn45IWMMFO5S/TzX7NEqZLJ7bVuqFo=; b=jmudYJBnkpiI8yGJ4fa9FGuFpFvcZ/GDDfyAc5LGt2ekrwmSoYlPTPD/5TFXfNEsMI iAd5cGuuBW6MOzoSmGa13qhy7yZipXP4ANorQAXdwIQ6OX5LZXyZpuG7DYY6y/1EFqi7 RGAfjZB3OUrJ7BCSxtFxuULj2U0eLQtN3Ir9s=
MIME-Version: 1.0
Received: by 10.182.121.101 with SMTP id lj5mr4773169obb.39.1327634917674; Thu, 26 Jan 2012 19:28:37 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.60.55.137 with HTTP; Thu, 26 Jan 2012 19:28:37 -0800 (PST)
In-Reply-To: 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com>  <4F21ABF2.7040002@qualcomm.com> <6842.1327617385@marajade.sandelman.ca>   
Date: Thu, 26 Jan 2012 22:28:37 -0500
X-Google-Sender-Auth: K2IhPC9AqsvINh9Vu2ipl8Y7NMY
Message-ID: 
Subject: Re: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
From: Barry Leiba 
To: Ted Hardie 
Content-Type: multipart/alternative; boundary=14dae93998f7a8d07a04b77a17de
Cc: "ietf@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 03:28:38 -0000

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

> I don't quite share the view that the license terms are not at
> issue here.  The reason that we have an IPR rule that asks us to
> declare what the terms of a license are is so that the working groups'
> members can evaluate both the applicability of the potentially
> encumbering patents and the terms of the license.

Yes, sorry: I was conflating this thread with the other one(s?) that are
specifically looking at how to address the late disclosures (for which the
issue really is how to deal with the failure to disclose, regardless of the
terms eventually offered).  This thread is about the Sieve documents in
question, so, yes, you're right that the terms are relevant.  I hadn't
meant to say we shouldn't think about that with respect to the two Sieve
documents.

Barry

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

> I don't quite share the view that the license terms are not at
      =
> issue here. =A0The reason that we have an IPR rule that asks us to
      =
> declare what the terms of a license are is so that the working groups&=
#39;
      
> members can evaluate both the applicability of the potentially
      >=
 encumbering patents and the terms of the license.

      Yes, sorry: I was=
 conflating this thread with the other one(s?) that are specifically lookin=
g at how to address the late disclosures (for which the issue really is how=
 to deal with the failure to disclose, regardless of the terms eventually o=
ffered). =A0This thread is about the Sieve documents in question, so, yes, =
you're right that the terms are relevant. =A0I hadn't meant to say =
we shouldn't think about that with respect to the two Sieve documents.<=
br>

      Barry
      

--14dae93998f7a8d07a04b77a17de--

From sm@resistor.net  Thu Jan 26 19:39:16 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65A321F8699 for ; Thu, 26 Jan 2012 19:39:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.612
X-Spam-Level: 
X-Spam-Status: No, score=-102.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 A0FbD2omwf9s for ; Thu, 26 Jan 2012 19:39:15 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C5721F8604 for ; Thu, 26 Jan 2012 19:39:15 -0800 (PST)
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 q0R3d6Cc026029; Thu, 26 Jan 2012 19:39:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327635551; i=@resistor.net; bh=puF49V6P4KJ2smQaKW4zhkiibiVesr2Vt3YrgCwS2Wo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=YozqRtWc7iGC1HChgvzvL9SWRuyP7mcfzioFMVhydLeNemOes6cn7rF0RJ/V9UIFF 1reOImf/xjgJTjHQlwtR6E8Qo0Ws93TWr2j130CIxm5JRti+Z3Ud6zeEvbtewvv3I7 51XoB6kilYxo6p0mEJmxzX/T1iEAXT0KZog6zVpI=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327635551; i=@resistor.net; bh=puF49V6P4KJ2smQaKW4zhkiibiVesr2Vt3YrgCwS2Wo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=cuno/t8SGHPoKyuUB/MrIUHiIcs9NG8Ho5y0CTIfUQq2w4bC4rOTI83PZCBJ6lQnt opx4A69iYm9JtCcciPXL4dK1CNRJpeA9Pt1qjHiDJdq89DjeNsV4lNUCkleMCGDb7w jo3V6CvvxgYl7DlYFjOX7HBa6dePERbycqc3X6DI=
Message-Id: <6.2.5.6.2.20120126185610.0aca5518@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 26 Jan 2012 19:16:26 -0800
To: Barry Leiba 
From: SM 
Subject: Re: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
In-Reply-To: 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com>  <4F21ABF2.7040002@qualcomm.com> <6842.1327617385@marajade.sandelman.ca>  
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 03:39:16 -0000

Hi Barry,
At 17:50 26-01-2012, Barry Leiba wrote:
>That seems excessive.  Shut down all document progress until we
>resolve this issue?  I think that cure is far worse than the disease.

It does not significantly affect document progress.

Thanks for the input.

Regards,
-sm  


From msk@cloudmark.com  Thu Jan 26 20:03:41 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA2C21F85D7 for ; Thu, 26 Jan 2012 20:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.588
X-Spam-Level: 
X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 hd8hDLq83SOj for ; Thu, 26 Jan 2012 20:03:41 -0800 (PST)
Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3A94221F85D8 for ; Thu, 26 Jan 2012 20:03:41 -0800 (PST)
Received: from spite.corp.cloudmark.com (172.22.10.72) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 26 Jan 2012 20:03:40 -0800
Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 26 Jan 2012 20:03:40 -0800
From: "Murray S. Kucherawy" 
To: "ietf@ietf.org" 
Date: Thu, 26 Jan 2012 20:03:40 -0800
Subject: RE: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
Thread-Topic: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
Thread-Index: AczclhFxVlZ9dCNFTPa60pOVF7FZzAAEiwkQ
Message-ID: 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com>  <4F21ABF2.7040002@qualcomm.com>	<6842.1327617385@marajade.sandelman.ca>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 04:03:41 -0000

> -----Original Message-----
> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of B=
arry Leiba
> Sent: Thursday, January 26, 2012 5:50 PM
> To: ietf@ietf.org
> Subject: Re: Second Last Call:  08.txt> (Sieve Notification Mechanism: SIP MESSAGE) to Proposed
> Standard
>=20
> > The document could be restricted to Experimental status, but that
> > presumes the status matters as much as or more than the RFC number.=A0I
> > don't know if that's true or not in this case.
>=20
> That, too, strikes me as a cure that's worse than the disease.
> "Experimental" isn't a punishment, and I think it would be a horrid
> idea to use the document's status in that way.  [...]

I think my suggestion was based on the premise of a past contentious workin=
g group whose outputs were reduced to Experimental by the IESG, and part of=
 the contention was objectionable IPR claims.  I think in retrospect that w=
as not quite right; the IPR claims were a problem with the personalities in=
 the room, but they were not direct causes of the status changes.  So proba=
bly not a well-founded suggestion in the end.

-MSK

From hsantos@isdg.net  Thu Jan 26 20:07:28 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A6921F85EA for ; Thu, 26 Jan 2012 20:07:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.074
X-Spam-Level: 
X-Spam-Status: No, score=-1.074 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_35=0.6, J_CHICKENPOX_43=0.6]
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 vmRJpc5vZy1i for ; Thu, 26 Jan 2012 20:07:28 -0800 (PST)
Received: from mail.catinthebox.net (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C912321F85CE for ; Thu, 26 Jan 2012 20:07:27 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1440; t=1327637237; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=QLyKoJrTkLH3ZVukq8k4vUQyGrQ=; b=r1M6xOA3jP/nN8ylkTFI bsCmeF6eMAkOZjDGJ1MRNTpXLT1EwCLlabyTtfxVNPuT1Hf4jSL8EusNQxFx1LCc GGhz9vlunGzctnKrVE0ahmopoYbCmNN7K2wLb/rUV9sbIOGMakJrUE/3TZUM7MAn QWlolMVWRfgVNpm57nHhhGo=
Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for ietf@ietf.org; Thu, 26 Jan 2012 23:07:17 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 839108040.59176.3972; Thu, 26 Jan 2012 23:07:16 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1440; t=1327637040; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=La0cSqo 3fMQZ0jWB36ubfGOKgv9Tk6ZFBMyJRX/w9WA=; b=mYvqc4l3xzW0vx8ptvhFlUO KKiR1JQ7Y3MtLq4qpox84ghfrVj+LaIMDUvrKnxEdkaP/fFx8wlovTedWC3Y8JRI 0JV0CsTV/fXJ26+VYMgF+s3DChOTs0m7XN82ipH21OCOMZ3W08BP+5NlfdsDiU+J dzdLEafjY7gOJc+EJTyA=
Received: by beta.winserver.com (Wildcat! SMTP Router v6.4.454.1) for ietf@ietf.org; Thu, 26 Jan 2012 23:04:00 -0500
Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 1438062829.10502.3820; Thu, 26 Jan 2012 23:03:59 -0500
Message-ID: <4F222304.70408@isdg.net>
Date: Thu, 26 Jan 2012 23:07:32 -0500
From: Hector Santos 
Organization: Santronics Software, Inc.
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Barry Leiba 
Subject: Re: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com>	<4F2075BE.5070201@nostrum.com>	<033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>		<4F208AEF.5060406@qualcomm.com>		<4F21ABF2.7040002@qualcomm.com>	<6842.1327617385@marajade.sandelman.ca>	 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "ietf@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 04:07:29 -0000

Barry Leiba wrote:

> I am not a lawyer, but I don't think the license terms are at issue
> here.  As I understand it, the terms that Huawei has been specifying
> in its disclosures are defensive, and shouldn't restrict standards
> implementations.  The issue we're discussing isn't the terms, but that
> the disclosures weren't made when they should have been.

Personally, that isn't the main problem.

Sure, if its their position its more of an defensive patent to combat 
the reality of dealing patent trolls, that is good news.

Unfortunately, Business Methods patents don't require the "unique 
part" in the integration of unrestricted parts and it covers the basic 
idea of just the integration. Thats a major conflict in an IETF 
environment which has untold thousands of parts.  So today, its 
SIP+SIEVE.  How about tomorrow with DKIM+SIP or in more general, 
RFC_X+RFC_Y?

My concern is that it should not be necessary to disclosed because the 
IETF parts are already public domain.  The idea of integration two of 
them, which is part for the course today MUST not open a can of worms 
where you are allowed to do this.

IOW, Barry, Are we opening that door that combing any two or more IETF 
technologies is ok to patent (not the method in combining) as long as 
they submit an IPR claim at the same thing of the I-D submission?


-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com



From bernard_aboba@hotmail.com  Thu Jan 26 21:16:05 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B92721F86FD; Thu, 26 Jan 2012 21:16:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 O1aRwIJ1R0Lm; Thu, 26 Jan 2012 21:16:04 -0800 (PST)
Received: from blu0-omc3-s14.blu0.hotmail.com (blu0-omc3-s14.blu0.hotmail.com [65.55.116.89]) by ietfa.amsl.com (Postfix) with ESMTP id 77C7E21F86F0; Thu, 26 Jan 2012 21:16:04 -0800 (PST)
Received: from BLU152-W4 ([65.55.116.73]) by blu0-omc3-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 26 Jan 2012 21:16:03 -0800
Message-ID: 
Content-Type: multipart/alternative; boundary="_579e820c-7f0a-464a-b50e-bbd6c7acd75b_"
X-Originating-IP: [75.94.72.66]
From: Bernard Aboba 
To: Stefan Winter , , 
Subject: RE: [radext] Review of draft-ietf-radext-radsec
Date: Thu, 26 Jan 2012 21:16:02 -0800
Importance: Normal
In-Reply-To: <4F2148AC.7080108@restena.lu>
References: , <4F2109F8.4060505@restena.lu>, <4F2148AC.7080108@restena.lu>
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Jan 2012 05:16:03.0398 (UTC) FILETIME=[C3C9E660:01CCDCB2]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 05:16:05 -0000

--_579e820c-7f0a-464a-b50e-bbd6c7acd75b_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Stefan said:
=20
My working copy has the following text in Security Considerations now:
=20
   If peer communication between two devices is configured for both
   RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using
   shared secret security)=2Cand where the RADIUS/UDP transport is the
   failover option if the TLS session cannot be established=2C a down-
   bidding attack can occur if an adversary can maliciously close the
   TCP connection=2C or prevent it from being established.  Situations
   where clients are configured in such a way are likely to occur during
   a migration phase from RADIUS/UDP to RADIUS/TLS.  By preventing the
   TLS session setup=2C the attacker can reduce the security of the packet
   payload from the selected TLS cipher suite packet encryption to the
   classic MD5 per-attribute encryption.  The situation should be
   avoided by disabling the weaker RADIUS/UDP transport as soon as the
   new RADIUS/TLS transport is established and tested.  Disabling can
   happen at either the RADIUS client or server side:
=20
   o  Client side: de-configure the failover setup=2C leaving RADIUS/TLS
      as the only communication option
=20
   o  Server side: de-configure the RADIUS/UDP client from the list of
      valid RADIUS clients
=20
I hope that makes my intended statement clearer.
=20
[BA] My issue is the use of a "well known" shared secret with RADIUS/UDP.=20
This could be fixed by requiring that a server supporting RADIUS/TLS MUST
check for a RADIUS/TLS connection before allowing use of the "well known"
shared secret.=20
 		 	   		  =

--_579e820c-7f0a-464a-b50e-bbd6c7acd75b_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





      
Stefan said:
       
      My working copy has the following text in Se=
curity Considerations now:
       
         If peer communication between two dev=
ices is configured for both
         RADIUS/TLS transport (using TLS security)=
 and RADIUS/UDP (using
         shared secret security)=2Cand where the RADIUS=
/UDP transport is the
         failover option if the TLS session cannot be es=
tablished=2C a down-
         bidding attack can occur if an adversary can mal=
iciously close the
         TCP connection=2C or prevent it from being establi=
shed.  Situations
         where clients are configured in such a way are like=
ly to occur during
         a migration phase from RADIUS/UDP to RADIUS/TLS.  =
By preventing the
         TLS session setup=2C the attacker can reduce the se=
curity of the packet
         payload from the selected TLS cipher suite packe=
t encryption to the
         classic MD5 per-attribute encryption.  The situat=
ion should be
         avoided by disabling the weaker RADIUS/UDP transport as=
 soon as the
         new RADIUS/TLS transport is established and tested.  Dis=
abling can
         happen at either the RADIUS client or server side:
          o  Client side: de-configure the failover setup=2C leaving RADIUS/TLS      as the only communication option
       
         o  Server side: de-conf=
igure the RADIUS/UDP client from the list of
            valid RADIUS clients<=
br> 
      I hope that makes my intended statement clearer.
       
      [BA] My is=
sue is the use of a "well known" shared secret with RADIUS/UDP. 
      This co=
uld be fixed by requiring that a server supporting RADIUS/TLS MUST
      check=
 for a RADIUS/TLS connection before allowing use of the "well known"
      sha=
red secret. 
       		 	   		  
      
=

--_579e820c-7f0a-464a-b50e-bbd6c7acd75b_--

From bernard_aboba@hotmail.com  Thu Jan 26 21:51:07 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB20121F85AC; Thu, 26 Jan 2012 21:51:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 Ny6tte1Xz1Kx; Thu, 26 Jan 2012 21:51:06 -0800 (PST)
Received: from blu0-omc3-s23.blu0.hotmail.com (blu0-omc3-s23.blu0.hotmail.com [65.55.116.98]) by ietfa.amsl.com (Postfix) with ESMTP id 80F2921F85AA; Thu, 26 Jan 2012 21:51:06 -0800 (PST)
Received: from BLU152-W62 ([65.55.116.72]) by blu0-omc3-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 26 Jan 2012 21:51:05 -0800
Message-ID: 
Content-Type: multipart/alternative; boundary="_d841b3fe-0081-4ebf-9a21-d3131e52919f_"
X-Originating-IP: [75.94.72.66]
From: Bernard Aboba 
To: Stefan Winter , 
Subject: RE: [radext] Review of draft-ietf-radext-radsec
Date: Thu, 26 Jan 2012 21:51:05 -0800
Importance: Normal
In-Reply-To: <4F2109F8.4060505@restena.lu>
References: , <4F2109F8.4060505@restena.lu>
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Jan 2012 05:51:05.0834 (UTC) FILETIME=[A8F02CA0:01CCDCB7]
Cc: radext@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 05:51:07 -0000

--_d841b3fe-0081-4ebf-9a21-d3131e52919f_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Stefan said:
"That's true. As I went through your comments below=2C I realised that
large parts of the texts you quoted should be moved to the
dynamic-discovery draft altogether as they are are very specific to that
draft.
=20
I'm thinking of taking out all the snippets you mentioned below=2C
transfer them to dynamic-discovery and leaving nothing but a small
"pointer" paragraph in the RADIUS/TLS document."

[BA] That's a great idea.=20
=20
Stefan said:

"Indeed. I'll update the text to that end. Note though that adding
Error-Cause is a MAY only in 5176=2C so it may very well be that an
implementation which doesn't support dynauth would still send only a
"naked" NAK=2C ignoring the MAY."

[BA] It's a MAY in RFC 5176 because existing implementations didn't
support Error-Cause at all.  However=2C in this particular case=2C since
you're requiring that RADIUS/TLS implementations support NAK in the
first place=2C you can also say that they SHOULD send an Error-Cause
attribute.  So I'd suggest that the MAY be stronger=2C so as to remove
a potential ambiguity about the meaning of the NAK. =20

   It is sufficient that upon
   receiving such a packet=2C an unconditional NAK is sent back to
   indicate that the action is not supported. =20

[BA] The problem is that a NAK does NOT mean that the action is
unsupported according to RFC 5176=2C unless there is an Error-Cause
attribute present that indicates that.=20

=20
Stefan said:
=20
"I'm slightly confused here. To my best knowledge=2C Error-cause is only
specified in the context of DynAuth (RFC5176). That attribute is listed
as only allowed in a NAK as per the attribute occurrence table in 5176."

[BA] While RFC 5176 only mentions use of Error-Cause in dynamic authorizati=
on
it can also be used in other contexts.  For example=2C Error-Cause is refer=
enced
in the following other RFCs:

RFC 3579:  Error-Cause use in Access-Challenge and Access-Reject (see Secti=
on 3.3)
RFC 5080:  Error-Cause in Access-Reject (See Section 2.6.1)

Stefan said:

"I would be hesitant to use Error-Cause in RADIUS Accounting packets -
unless the corresponding RFCs get updated to specify that this attribute
is now also to be used in Accounting semantics."

[BA] Apparently=2C Error-Cause is being sent in Accounting-Request packets=
=2C see:
http://lists.cistron.nl/pipermail/freeradius-users/2011-January/msg00255.ht=
ml

With respect to Accounting-Response=2C RFC 2866 does prohibit inclusion of=
=20
attributes relating to a service=2C but not attributes like Proxy-State or =
Vendor-Specific.
So I'd argue that Error-Cause fits within the category of attributes that w=
ould
be permissible -- an Informational attribute that can be ignored without da=
mage.

Stefan said:

"The non-ability to indicate "No accounting please" has been discussed in
a radext wg meeting. The conclusion was that auth and acct are two
separate=2C unrelated items. RADIUS Accounting needs to be configured
differently and explicitly=3B so there is little risk that accounting
packets are sent "by chance" anyway. If they are sent to the wrong
place=2C that is an administrative error: misconfigured on the sender-side.=
"

[BA] If a RADIUS over UDP packet is sent to the wrong place=2C an ICMP
message will result that the RADIUS Accounting client can act on=2C such
as by logging the error. =20

In this case=2C you are mandating that the RADIUS over TLS server ignore
the request=2C resulting in continuing connection attempts and retransmissi=
ons
by the RADIUS over TLS client=2C who doesn't receive evidence of the miscon=
figuration.
So I'd argue that RADIUS over TLS is creating a new problem.=20


 		 	   		  =

--_d841b3fe-0081-4ebf-9a21-d3131e52919f_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





      
Stefan said:
      "That's true. As I went through your comments bel=
ow=2C I realised that
      large parts of the texts you quoted should be move=
d to the
      dynamic-discovery draft altogether as they are are very specifi=
c to that
      draft.
       
      I'm thinking of taking out all the snippets you=
 mentioned below=2C
      transfer them to dynamic-discovery and leaving nothi=
ng but a small
      "pointer" paragraph in the RADIUS/TLS document."

      [=
BA] That's a great idea. 
       
      Stefan said:

      "Indeed. I'll update =
the text to that end. Note though that adding
      Error-Cause is a MAY only =
in 5176=2C so it may very well be that an
      implementation which doesn't s=
upport dynauth would still send only a
      "naked" NAK=2C ignoring the MAY."=


      [BA] It's a MAY in RFC 5176 because existing implementations didn't=

      support Error-Cause at all.  However=2C in this particular case=2C sinc=
e
      you're requiring that RADIUS/TLS implementations support NAK in thefirst place=2C you can also say that they SHOULD send an Error-Cause
      at=
tribute.  So I'd suggest that the MAY be stronger=2C so as to remove
      a p=
otential ambiguity about the meaning of the NAK.  

         It is sufficie=
nt that upon
         receiving such a packet=2C an unconditional NAK is sent =
back to
         indicate that the action is not supported.  

      [BA] The =
problem is that a NAK does NOT mean that the action is
      unsupported accor=
ding to RFC 5176=2C unless there is an Error-Cause
      attribute present tha=
t indicates that. 

       
      Stefan said:
       
      "I'm slightly confused =
here. To my best knowledge=2C Error-cause is only
      specified in the conte=
xt of DynAuth (RFC5176). That attribute is listed
      as only allowed in a N=
AK as per the attribute occurrence table in 5176."

      [BA] While RFC 51=
76 only mentions use of Error-Cause in dynamic authorization
      it can also=
 be used in other contexts.  For example=2C Error-Cause is referenced
      in=
 the following other RFCs:

      RFC 3579:  Error-Cause use in Access-Chal=
lenge and Access-Reject (see Section 3.3)
      RFC 5080:  Error-Cause in Acce=
ss-Reject (See Section 2.6.1)

      Stefan said:

      "I would be hesita=
nt to use Error-Cause in RADIUS Accounting packets -
      unless the correspo=
nding RFCs get updated to specify that this attribute
      is now also to be =
used in Accounting semantics."

      [BA] Apparently=2C Error-Cause is bei=
ng sent in Accounting-Request packets=2C see:
      http://lists.cistron.nl/pi=
permail/freeradius-users/2011-January/msg00255.html

      With respect to =
Accounting-Response=2C RFC 2866 does prohibit inclusion of 
      attributes r=
elating to a service=2C but not attributes like Proxy-State or Vendor-Speci=
fic.
      So I'd argue that Error-Cause fits within the category of attribute=
s that would
      be permissible -- an Informational attribute that can be ig=
nored without damage.

      Stefan said:

      "The non-ability to indica=
te "No accounting please" has been discussed in
      a radext wg meeting. The=
 conclusion was that auth and acct are two
      separate=2C unrelated items. =
RADIUS Accounting needs to be configured
      differently and explicitly=3B s=
o there is little risk that accounting
      packets are sent "by chance" anyw=
ay. If they are sent to the wrong
      place=2C that is an administrative err=
or: misconfigured on the sender-side."

      [BA] If a RADIUS over UDP pac=
ket is sent to the wrong place=2C an ICMP
      message will result that the R=
ADIUS Accounting client can act on=2C such
      as by logging the error.  
      In this case=2C you are mandating that the RADIUS over TLS server igno=
re
      the request=2C resulting in continuing connection attempts and retran=
smissions
      by the RADIUS over TLS client=2C who doesn't receive evidence =
of the misconfiguration.
      So I'd argue that RADIUS over TLS is creating a=
 new problem. 


       		 	   		  
      
=

--_d841b3fe-0081-4ebf-9a21-d3131e52919f_--

From narten@us.ibm.com  Thu Jan 26 21:53:39 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC77421F85AF for ; Thu, 26 Jan 2012 21:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.769
X-Spam-Level: 
X-Spam-Status: No, score=-108.769 tagged_above=-999 required=5 tests=[AWL=1.830, 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 Pz0CpFqajZzu for ; Thu, 26 Jan 2012 21:53:39 -0800 (PST)
Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id D94E421F85AC for ; Thu, 26 Jan 2012 21:53:38 -0800 (PST)
Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for  from ; Thu, 26 Jan 2012 22:53:36 -0700
Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted;  Thu, 26 Jan 2012 22:53:05 -0700
Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 4D0DF19D8050 for ; Thu, 26 Jan 2012 22:53:02 -0700 (MST)
Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q0R5r4xV170418 for ; Thu, 26 Jan 2012 22:53:04 -0700
Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q0R5r4ku024943 for ; Thu, 26 Jan 2012 22:53:04 -0700
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.192.143]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q0R5r3e3024926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jan 2012 22:53:03 -0700
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [127.0.0.1]) by rotala.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id q0R5r2a9005631 for ; Fri, 27 Jan 2012 00:53:02 -0500
Received: (from narten@localhost) by rotala.raleigh.ibm.com (8.14.4/8.14.4/Submit) id q0R5r2D5005597 for ietf@ietf.org; Fri, 27 Jan 2012 00:53:02 -0500
From: Thomas Narten 
Message-Id: <201201270553.q0R5r2D5005597@rotala.raleigh.ibm.com>
Date: Fri, 27 Jan 2012 00:53:02 -0500
To: ietf@ietf.org
Subject: Weekly posting summary for ietf@ietf.org
User-Agent: Heirloom mailx 12.5 7/5/10
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Content-Scanned: Fidelis XPS MAILER
x-cbid: 12012705-3270-0000-0000-00000386C442
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 05:53:39 -0000

Total of 153 messages in the last 7 days.
 
script run at: Fri Jan 27 00:53:02 EST 2012
 
    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
  5.88% |    9 |  6.46% |    87839 | michael.jones@microsoft.com
  6.54% |   10 |  5.25% |    71416 | sm@resistor.net
  5.23% |    8 |  5.86% |    79626 | presnick@qualcomm.com
  5.23% |    8 |  3.88% |    52770 | msk@cloudmark.com
  3.27% |    5 |  5.21% |    70891 | adrian@olddog.co.uk
  4.58% |    7 |  3.34% |    45456 | dot@dotat.at
  3.27% |    5 |  3.02% |    41061 | tglassey@earthlink.net
  2.61% |    4 |  3.31% |    44976 | sant9442@gmail.com
  3.27% |    5 |  2.65% |    36086 | stpeter@stpeter.im
  3.27% |    5 |  2.41% |    32713 | julian.reschke@gmx.de
  3.27% |    5 |  2.39% |    32460 | kpfleming@digium.com
  2.61% |    4 |  2.47% |    33602 | marshall.eubanks@gmail.com
  1.96% |    3 |  2.77% |    37645 | eran@hueniverse.com
  1.96% |    3 |  2.41% |    32763 | john-ietf@jck.com
  1.31% |    2 |  2.98% |    40501 | adam@nostrum.com
  1.96% |    3 |  2.11% |    28709 | richard@shockey.us
  1.96% |    3 |  1.97% |    26798 | lear@cisco.com
  1.96% |    3 |  1.91% |    26025 | barryleiba@computer.org
  1.31% |    2 |  2.28% |    31036 | stefan.winter@restena.lu
  1.96% |    3 |  1.62% |    22048 | mcr@sandelman.ca
  1.96% |    3 |  1.43% |    19412 | mnot@mnot.net
  1.96% |    3 |  1.34% |    18181 | nick@inex.ie
  1.31% |    2 |  1.91% |    25973 | hallam@gmail.com
  1.96% |    3 |  1.24% |    16863 | mrex@sap.com
  1.31% |    2 |  1.79% |    24396 | david.black@emc.com
  0.65% |    1 |  2.35% |    31950 | tnadeau@lucidvision.com
  0.65% |    1 |  2.12% |    28774 | wmills@yahoo-inc.com
  1.31% |    2 |  1.25% |    17046 | daedulus@btconnect.com
  1.31% |    2 |  0.96% |    13071 | rbarnes@bbn.com
  1.31% |    2 |  0.96% |    13056 | bob.hinden@gmail.com
  1.31% |    2 |  0.94% |    12784 | dhc@dcrocker.net
  1.31% |    2 |  0.94% |    12755 | dworley@avaya.com
  1.31% |    2 |  0.93% |    12579 | vesely@tana.it
  1.31% |    2 |  0.88% |    11898 | cyrus@daboo.name
  0.65% |    1 |  1.49% |    20203 | ve7jtb@ve7jtb.com
  0.65% |    1 |  1.39% |    18916 | zordogh@rim.com
  0.65% |    1 |  1.15% |    15589 | ron.even.tlv@gmail.com
  0.65% |    1 |  0.77% |    10535 | stewe@stewe.org
  0.65% |    1 |  0.61% |     8265 | narten@us.ibm.com
  0.65% |    1 |  0.61% |     8227 | tjc@ecs.soton.ac.uk
  0.65% |    1 |  0.60% |     8162 | hsantos@isdg.net
  0.65% |    1 |  0.59% |     7979 | d3e3e3@gmail.com
  0.65% |    1 |  0.58% |     7851 | stephen.farrell@cs.tcd.ie
  0.65% |    1 |  0.57% |     7782 | derhoermi@gmx.net
  0.65% |    1 |  0.55% |     7545 | eburger-l@standardstrack.com
  0.65% |    1 |  0.55% |     7523 | ted.ietf@gmail.com
  0.65% |    1 |  0.55% |     7500 | ray.bellis@nominet.org.uk
  0.65% |    1 |  0.54% |     7278 | tbray@textuality.com
  0.65% |    1 |  0.53% |     7247 | amorris@amsl.com
  0.65% |    1 |  0.50% |     6808 | harald@alvestrand.no
  0.65% |    1 |  0.50% |     6804 | ynir@checkpoint.com
  0.65% |    1 |  0.49% |     6720 | clint.chaplin@gmail.com
  0.65% |    1 |  0.49% |     6672 | smb@cs.columbia.edu
  0.65% |    1 |  0.47% |     6373 | warren@kumari.net
  0.65% |    1 |  0.47% |     6346 | ajs@anvilwalrusden.com
  0.65% |    1 |  0.46% |     6294 | henning.schulzrinne@fcc.gov
  0.65% |    1 |  0.45% |     6172 | randy_presuhn@mindspring.com
  0.65% |    1 |  0.45% |     6169 | brian.e.carpenter@gmail.com
  0.65% |    1 |  0.45% |     6157 | ben@nostrum.com
  0.65% |    1 |  0.45% |     6121 | dave@cridland.net
  0.65% |    1 |  0.39% |     5272 | cos@aaaaa.org
--------+------+--------+----------+------------------------
100.00% |  153 |100.00% |  1359669 | Total


From stefan.winter@restena.lu  Thu Jan 26 23:16:19 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5EF21F856D; Thu, 26 Jan 2012 23:16:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.287
X-Spam-Level: 
X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.313,  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 TukzruuH303X; Thu, 26 Jan 2012 23:16:19 -0800 (PST)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id D3B7A21F853B; Thu, 26 Jan 2012 23:16:18 -0800 (PST)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 8860C106CB; Fri, 27 Jan 2012 08:16:17 +0100 (CET)
Received: from [IPv6:2001:a18:1:8:230:5ff:fefe:5359] (unknown [IPv6:2001:a18:1:8:230:5ff:fefe:5359]) by smtprelay.restena.lu (Postfix) with ESMTPS id 7819E10691; Fri, 27 Jan 2012 08:16:17 +0100 (CET)
Message-ID: <4F224F36.9000102@restena.lu>
Date: Fri, 27 Jan 2012 08:16:06 +0100
From: Stefan Winter 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: radext@ietf.org, 'IETF Discussion Mailing List' 
Subject: Re: [radext] Review of draft-ietf-radext-radsec
References: , <4F2109F8.4060505@restena.lu>, <4F2148AC.7080108@restena.lu> 
In-Reply-To: 
X-Enigmail-Version: 1.3.4
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig40BDD5C13E24490DC67072D3"
X-Virus-Scanned: ClamAV
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 07:16:19 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig40BDD5C13E24490DC67072D3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

>    If peer communication between two devices is configured for both
>    RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using
>    shared secret security),and where the RADIUS/UDP transport is the
>    failover option if the TLS session cannot be established, a down-
>    bidding attack can occur if an adversary can maliciously close the
>    TCP connection, or prevent it from being established.  Situations
>    where clients are configured in such a way are likely to occur durin=
g
>    a migration phase from RADIUS/UDP to RADIUS/TLS.  By preventing the
>    TLS session setup, the attacker can reduce the security of the packe=
t
>    payload from the selected TLS cipher suite packet encryption to the
>    classic MD5 per-attribute encryption.  The situation should be
>    avoided by disabling the weaker RADIUS/UDP transport as soon as the
>    new RADIUS/TLS transport is established and tested.  Disabling can
>    happen at either the RADIUS client or server side:
> =20
>    o  Client side: de-configure the failover setup, leaving RADIUS/TLS
>       as the only communication option
> =20
>    o  Server side: de-configure the RADIUS/UDP client from the list of
>       valid RADIUS clients
> =20
> I hope that makes my intended statement clearer.
> =20
> [BA] My issue is the use of a "well known" shared secret with RADIUS/UD=
P.=20
> This could be fixed by requiring that a server supporting RADIUS/TLS MU=
ST
> check for a RADIUS/TLS connection before allowing use of the "well know=
n"
> shared secret.=20

Ah, I see. The spec does not mandate a fixed well-known shared secret
for RADIUS/UDP at all. It only specifies that when TLS transport is
used, security is provided on the transport layer, so the shared secret
that used to protect the RADIUS payload is useless is set to this fixed
term.

When using RADIUS/UDP, the shared secret is still chosen by the
administrator by configuration.

Would it help to clarify the first lines to read:

    If peer communication between two devices is configured for both
    RADIUS/TLS transport (i.e. TLS security on the transport layer,
    shared secret fixed to "radsec") and RADIUS/UDP (i.e. shared secret
    security with a secret manually configured by the administrator),
    and where the RADIUS/UDP transport is the failover option if the
    TLS session cannot be established, a down-bidding attack can occur
    if an adversary can maliciously close the TCP connection, or
    prevent it from being established.

Just to make sure people realise that RADIUS/UDP security is untouched
by this spec?

Greetings,

Stefan Winter

--=20
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National=
e et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473


--------------enig40BDD5C13E24490DC67072D3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8iTz8ACgkQ+jm90f8eFWbBfwCfcoBFq372k+Q7Yo14ZtuQvCyO
1nwAnjf8ICourZ1qKvAmNVRr2IzhId47
=aHu1
-----END PGP SIGNATURE-----

--------------enig40BDD5C13E24490DC67072D3--

From stefan.winter@restena.lu  Thu Jan 26 23:55:58 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3ED421F854C; Thu, 26 Jan 2012 23:55:58 -0800 (PST)
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]
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 hZGrmZgSnW5h; Thu, 26 Jan 2012 23:55:57 -0800 (PST)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7427221F854B; Thu, 26 Jan 2012 23:55:57 -0800 (PST)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id CCAC8106CB; Fri, 27 Jan 2012 08:55:56 +0100 (CET)
Received: from [IPv6:2001:a18:1:8:230:5ff:fefe:5359] (unknown [IPv6:2001:a18:1:8:230:5ff:fefe:5359]) by smtprelay.restena.lu (Postfix) with ESMTPS id BED76106C2; Fri, 27 Jan 2012 08:55:56 +0100 (CET)
Message-ID: <4F225888.9050601@restena.lu>
Date: Fri, 27 Jan 2012 08:55:52 +0100
From: Stefan Winter 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: radext@ietf.org, 'IETF Discussion Mailing List' 
Subject: Re: [radext] Review of draft-ietf-radext-radsec
References: , <4F2109F8.4060505@restena.lu> 
In-Reply-To: 
X-Enigmail-Version: 1.3.4
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8755B2B111B3152A1D96D22A"
X-Virus-Scanned: ClamAV
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 07:55:58 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig8755B2B111B3152A1D96D22A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

comments inline.

> "Indeed. I'll update the text to that end. Note though that adding
> Error-Cause is a MAY only in 5176, so it may very well be that an
> implementation which doesn't support dynauth would still send only a
> "naked" NAK, ignoring the MAY."
>=20
> [BA] It's a MAY in RFC 5176 because existing implementations didn't
> support Error-Cause at all.  However, in this particular case, since
> you're requiring that RADIUS/TLS implementations support NAK in the
> first place, you can also say that they SHOULD send an Error-Cause
> attribute.  So I'd suggest that the MAY be stronger, so as to remove
> a potential ambiguity about the meaning of the NAK. =20
>=20
>    It is sufficient that upon
>    receiving such a packet, an unconditional NAK is sent back to
>    indicate that the action is not supported. =20
>=20
> [BA] The problem is that a NAK does NOT mean that the action is
> unsupported according to RFC 5176, unless there is an Error-Cause
> attribute present that indicates that.=20

Okay, the argument for a SHOULD sunds very reasonable. I have updated my
working copy to that end.

> Stefan said:
> =20
> "I'm slightly confused here. To my best knowledge, Error-cause is only
> specified in the context of DynAuth (RFC5176). That attribute is listed=

> as only allowed in a NAK as per the attribute occurrence table in 5176.=
"
>=20
> [BA] While RFC 5176 only mentions use of Error-Cause in dynamic authori=
zation
> it can also be used in other contexts.  For example, Error-Cause is ref=
erenced
> in the following other RFCs:
>=20
> RFC 3579:  Error-Cause use in Access-Challenge and Access-Reject (see S=
ection 3.3)
> RFC 5080:  Error-Cause in Access-Reject (See Section 2.6.1)

Ok... 3579 defines it to be that way, simply pointing to dynauth; my
draft could do so, too, of course.
5080 lists that it is done elsewhere but doesn't reference a particular
RFC; looks to me like it could refer to RFC3579.

> Stefan said:
>=20
> "I would be hesitant to use Error-Cause in RADIUS Accounting packets -
> unless the corresponding RFCs get updated to specify that this attribut=
e
> is now also to be used in Accounting semantics."
>=20
> [BA] Apparently, Error-Cause is being sent in Accounting-Request packet=
s, see:
> http://lists.cistron.nl/pipermail/freeradius-users/2011-January/msg0025=
5.html

Interesting use. I don't recall "Error-Cause =3D Invite" being specified
anywhere; it's not in the list of enumerated Error-Cause reasons in the
IANA registry anyway.

And it's one message on the list that was never replied to. Looks to me
like it's one particular NAS sending weird things out-of-spec. I don't
really like that as an example to be honest.

> With respect to Accounting-Response, RFC 2866 does prohibit inclusion o=
f=20
> attributes relating to a service, but not attributes like Proxy-State o=
r Vendor-Specific.
> So I'd argue that Error-Cause fits within the category of attributes th=
at would
> be permissible -- an Informational attribute that can be ignored withou=
t damage.
>=20
> Stefan said:
>=20
> "The non-ability to indicate "No accounting please" has been discussed =
in
> a radext wg meeting. The conclusion was that auth and acct are two
> separate, unrelated items. RADIUS Accounting needs to be configured
> differently and explicitly; so there is little risk that accounting
> packets are sent "by chance" anyway. If they are sent to the wrong
> place, that is an administrative error: misconfigured on the sender-sid=
e."
>=20
> [BA] If a RADIUS over UDP packet is sent to the wrong place, an ICMP
> message will result that the RADIUS Accounting client can act on, such
> as by logging the error. =20
>=20
> In this case, you are mandating that the RADIUS over TLS server ignore
> the request, resulting in continuing connection attempts and retransmis=
sions
> by the RADIUS over TLS client, who doesn't receive evidence of the misc=
onfiguration.
> So I'd argue that RADIUS over TLS is creating a new problem.=20

I take your point only partially. It's true that NASes could act on
receipt of ICMP Port Unreachable, and they can't as per this spec.

I would like to note however that ICMP Port Unreachable is a *very*
coarse-grained way of NAKing accounting that is of little use anyway.

Consider classic RADIUS, and a proxy environment where a server provides
accounting services for some clients, but not for others (or even more
fine-grained: for some realms, but not for others - even if they arrive
via the same RADIUS client): a UDP port is either open or closed; it is
an entirely binary way of signalling whether a server processes
accounting for a given client or not.

It is not possible to signal to the misconfigured peer that *his* (or
only some of his) packets are unwanted, while others are.

That is the situation in classic RADIUS, and makes ICMP Port Unreachable
a very poor way of signalling this condition. That's why I don't have
any scruple sacrificing it. (That, and that the wg discussion also was
rather unimpressed about the consequences of this).

That being said, I can change the spec to "patch" the situation with
your suggestion of using Accounting-Response + Error-Cause. It may be
the adequate thing to do since this specification is going for
Experimental only.

In the long run though, I think this solution is inadequate; if
Accounting-NAK signalling is to be fixed, it should be fixed properly
(i.e. on a per-packet basis) for all transports, not just this one.
Maybe by updating 2866 with a consistent use of Error-Cause, or maybe by
adding an Accounting-NAK packet type, analogous to the dynauth NAKs.

It is definitely a useful thing to work on; but it's not for the
RAIDUS/TLS draft to decide. That would need a wg chartered item (luckily
radext is discussing rechartering right now; this might be worthwhile to
include...)

Please let me know if you'd prefer the Error-Cause "patch" to be in this
spec; I'll do as you say :-)

I promised my AD to publish the -11 revision for IESG review later
today; if our conversation didn't converge until then, there can always
be a -12. Probably necessary after the IESG review anyway :-)

Greetings,

Stefan Winter


>=20
>=20
>=20
>=20
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext


--=20
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National=
e et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473


--------------enig8755B2B111B3152A1D96D22A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8iWIwACgkQ+jm90f8eFWY1MwCeNAZpoZ/HOEQI/r6gC9VOwPfy
L6QAnis1pH43I8zIg/G5fEW7aLXey/gL
=Q7gL
-----END PGP SIGNATURE-----

--------------enig8755B2B111B3152A1D96D22A--

From daedulus@btconnect.com  Fri Jan 27 03:31:26 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6ECE21F8562 for ; Fri, 27 Jan 2012 03:31:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100,  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 Mf4zDcPiwCjr for ; Fri, 27 Jan 2012 03:31:25 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by ietfa.amsl.com (Postfix) with ESMTP id 34C8621F8541 for ; Fri, 27 Jan 2012 03:31:24 -0800 (PST)
Received: from host86-163-138-100.range86-163.btcentralplus.com (HELO pc6) ([86.163.138.100]) by c2beaomr08.btconnect.com with SMTP id FYW37168; Fri, 27 Jan 2012 11:31:19 +0000 (GMT)
Message-ID: <014901ccdcde$df75ee00$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Pete Resnick" 
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com>	<4F2075BE.5070201@nostrum.com>, <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>	, <4F208AEF.5060406@qualcomm.com>		<4F21ABF2.7040002@qualcomm.com><6842.1327617385@marajade.sandelman.ca> <4F21DC59.4040207@qualcomm.com>
Subject: Re: Second Last Call: (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
Date: Fri, 27 Jan 2012 11:31:42 +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-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4F228B05.00D1, actions=tag
X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.1.27.105414:17:7.586, ip=86.163.138.100, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __FRAUD_SUBJ_A, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, __C230066_P5, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=36/50, host=c2beaomr08.btconnect.com
X-Junkmail-Signature-Raw: score=suspect(1), refid=str=0001.0A0B0203.4F228B07.0108,ss=2,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine
X-Junkmail-IWF: false
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 11:31:26 -0000

----- Original Message -----
From: "Pete Resnick" 
To: "Murray S. Kucherawy" 
Cc: 
Sent: Friday, January 27, 2012 12:06 AM
> On 1/26/12 4:45 PM, Murray S. Kucherawy wrote:
> >> -----Original Message-----
> >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
Michael Richardson
> >> Sent: Thursday, January 26, 2012 2:36 PM
> >> To: ietf@ietf.org
> >> Subject: Re: Second Last Call: >> 08.txt>  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed
> >> Standard
> >>
> >> At this point, I do not have a clear idea of what the set of outcomes
> >> could be.  I think that they can include:
> >>     1) not publishing the document.
> >>     2) revising the document to remove/work-around the encumbered work
> >>
>
> Yes, certainly those are choices.
>
> >>     3) some legal action to attend to anul the patent (which might or
> >>        might not succeed).
> >>
>
> I don't think this is something that we can do *as the IETF*. Certainly
> others are welcome to pursue that.
>
> >>     4) go ahead and publish things as they are.
> >>
> > I also thought about suggesting a DNP or a standing DISCUSS or something
until the license terms are made more IETF-friendly, unless the WG can find a
way to do equivalent work that is unencumbered, but then the WG might not have
the energy left.
> >
> > The document could be restricted to Experimental status, but that presumes
the status matters as much as or more than the RFC number.  I don't know if
that's true or not in this case.
> >
>
> These are also choices.
>
> > Those only cover the document though, and not the offender(s).  Still
chewing on an opinion about that.
> >
>
> Other choices that involve both the document and the author(s) are
> similar to ones outlined by other folks:
>
> - The author of the patent can be removed from the author list at the
> top of the document.
> (In effect, this would be the IETF asking the WG chair to fire the
> document editor for failure to comply with IETF process. The result
> would be the author not getting the recognition as a document editor,
> though they would still appear in the Acknowledgments section.)
>
> - Removal of posting rights of the author from the WG or IETF mailing
> lists, even perhaps via a PR Action for being "disruptive" of the IETF
> process.

Pete

Whether or not this I-D is published as an RFC I see as an issue for the WG.  I
do not believe that I, nor many of those outside the WG, have the information on
which to make an informed decision.

On the individual in question, then yes, I believe that he should not be listed
as an author.

In the absence of any further explanatory communication from him, I would also
suspend his posting rights.

Tom Petch

> Coincidentally, but not by chance, Adrian and I have been working on a
> draft to discuss such sanctions that we are just about to post. I hope
> that sparks some ideas as well.
>
> pr
>
> --
> Pete Resnick
> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
>


From danielmaiax@gmail.com  Fri Jan 27 05:38:55 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF2521F854B for ; Fri, 27 Jan 2012 05:38:55 -0800 (PST)
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 s7-yrwYz92Xg for ; Fri, 27 Jan 2012 05:38:54 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7E521F851D for ; Fri, 27 Jan 2012 05:38:48 -0800 (PST)
Received: by yenm3 with SMTP id m3so847882yen.31 for ; Fri, 27 Jan 2012 05:38:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=hK1cB1KpOhBIdcnQdsQSJfVixaJwSFN1WIs5+sa8gU8=; b=eCnqnV28IxLcF/PzZ7ci5wYLZjN1V6r0RukzrxFA7L6QjolmCZYmf691lyhnCxkVuV Uwxjy+coQIyCQsnMbm/VUDsYkOA9dBSnj4AdPbgCZZI5Xp60aORCj8c59dsL2J6GEPwJ Owm7+YKbj6WN2x9d1MbhA/rtX6s/1Iufgzxg8=
Received: by 10.236.116.99 with SMTP id f63mr10678701yhh.119.1327671527680; Fri, 27 Jan 2012 05:38:47 -0800 (PST)
Received: from [192.168.1.102] (201-67-34-232.bsace703.dsl.brasiltelecom.net.br. [201.67.34.232]) by mx.google.com with ESMTPS id g32sm20162076ann.19.2012.01.27.05.38.45 (version=SSLv3 cipher=OTHER); Fri, 27 Jan 2012 05:38:47 -0800 (PST)
Message-ID: <4F22A8E1.1010905@gmail.com>
Date: Fri, 27 Jan 2012 11:38:41 -0200
From: Daniel Maia 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: ietf@ietf.org
Subject: unsubscribe
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 13:38:56 -0000

On 26/01/2012 17:54, ietf-request@ietf.org wrote:
> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/ietf
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send Ietf mailing list submissions to
> 	ietf@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/ietf
> or, via email, send a message with subject or body 'help' to
> 	ietf-request@ietf.org
>
> You can reach the person managing the list at
> 	ietf-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ietf digest..."
>
>
> Today's Topics:
>
>     1. Re: Second Last	Call:
>        	(Sieve	Notifica	tion
>        Mechanism: SIP MESSAGE) to Proposed Standard (John C Klensin)
>     2. encouraging compliance with IPR disclosure rules
>        (Peter Saint-Andre)
>     3. RE: Second Last Call:
>        	(Sieve	Notification
>        Mechanism: SIP MESSAGE) to Proposed Standard (Worley, Dale R (Dale))
>     4. Re: Second Last Call:
>        	(Sieve	Notification
>        Mechanism: SIP MESSAGE) to Proposed Standard (Pete Resnick)
>     5. Re: encouraging compliance with IPR disclosure rules (SM)
>     6. Re: Violation of IETF process (todd glassey)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 26 Jan 2012 12:37:06 -0500
> From: John C Klensin
> To: Pete Resnick
> Cc: adrian@olddog.co.uk, sieve@ietf.org, ietf@ietf.org
> Subject: Re: Second Last	Call:
> 		(Sieve	Notifica	tion
> 	Mechanism: SIP MESSAGE) to Proposed Standard
> Message-ID:
> Content-Type: text/plain; charset=us-ascii
>
>
>
> --On Thursday, January 26, 2012 10:08 -0600 Pete Resnick
>   wrote:
>
>> As I've mentioned to others, since I'm one of the people who
>> will have to judge the consensus on this question, my comments
>> will remain strictly based on the facts of the events as I
>> know them and on the relevant IETF procedures. It is up to the
>> IETF community to decide on what the appropriate course of
>> action shall be. That said, I have some comments and questions:
>>
>> On 1/26/12 3:31 AM, John C Klensin wrote:
>>
>>> It seems to me that a key question here is whether the
>>> original author's decision to not disclose was made in
>>> violation of company policy or whether the sequence of
>>> posting the I-D, getting the document through the WG and Last
>>> Call, and then posting the disclosure is a matter of company
>>> policy.
>> We were told by the other company employees who facilitated
>> the disclosures, at the time of the disclosures, that this was
>> strictly an individual's failure to comply with the IETF IPR
>> Policy, that the author in question claims not to have
>> understood the IETF IPR Policy, and that the company proceeded
>> to make these disclosures as soon as it discovered that this
>> IPR existed. I have no information to contradict that claim.
> Excellent.   I had hoped that was the situation.  It obviously
> makes things much easier (and some of my earlier comments
> irrelevant).   With all the effort we go to ("Note Well" and
> otherwise) to be sure that people are informed about the policy,
> I have trouble generating sympathy for someone who says "didn't
> underatand", but that is another matter (and perhaps just my
> problem).
>
>>> Consequently, I believe that at least the following should be
>>> required:
>>>
>>> (1) Revision of the IPR statement so it identifies the
>>> responsible individual by name, department, and title.  I do
>>> not believe that the rather anonymous "Director of Licensing"
>>> is compliant with the intent of the IPR disclosure rules.   I
>>> will leave it to the lawyers to advise on whether a document
>>> issued without the name (not just title) of a responsible
>>> individual would even be held to be valid in the various
>>> jurisdictions in which the patent might be recognized.
>>>
>> Are you asking that the IPR statements be updated with the
>> name, department, and title of the "Director of Licensing", or
>> that of the author of the documents and patents in question?
> The former.
>
>> It seems to me that the former is a procedural question that
>> is separate from the disposition of these particular
>> documents, and seems like a reasonable requirement for any IPR
>> disclosure.
> That is correct.  I believe I suggested in a later note that
> this is an area to which it would be good if the Trust paid some
> attention and advised the Secretariat and others accordingly.
>
>>> (2) A request to the company involved for someone who can
>>> formally speak for that company to publicly clarify that this
>>> sequence of behavior occurred in violation of company policy.
>>> If there are internal rewards to individuals for filing and/or
>>> being awarded patents, I assume that a decision that the
>>> actions violate company policy would cause such awards to be
>>> withheld in this case, even though the IETF would have no way
>>> to verify whether or not that occurred.
>> The IETF Chair has in the past sent messages to companies to
>> inquire about their handling of IPR disclosures, so I imagine
>> such a message could be sent if the IETF community desires it.
> That was my assumption.  On the other hand, if it is already
> clear that this was either a misunderstanding, a violation of
> company policy, or both, it might not be necessary.
>
>>> (3) A request to the company involved to remove the
>>> reciprocity clause from the license stated in the disclosure
>>> statement.  As a show of good faith, they should agree to
>>> derive no benefit from the patent other than what praise
>>> accrues from having it awarded.
>> I'll ask to bring this topic up with the IETF attorney. I am
>> pretty sure we can *ask* that they do this as a show of good
>> faith. I am also pretty certain that we can't negotiate the
>> terms of a license agreement.
> I was only suggesting asking.  If they say "no", which they
> obviously have the right to do, it is, as others have pointed
> out, the WG's problem to consider what that is an issue.  If the
> WG is indifferent on the issue, it seems to me that the relevant
> AD has a problem, but that problem is _not_ bound to the
> disclosure issue.
>
>>> (4) Removal of the offending individual from the list of
>>> authors to the acknowledgments with text similar to that
>>> suggested by Adrian.  Unless the company involved is willing
>>> to provide the clarification suggested in (2) above, and
>>> possibly the license modification suggested in (3) above, all
>>> names of authors associated with that company should be
>>> removed to the acknowledgements and the company affiliation
>>> explicitly identified there.  In either case, this should be
>>> viewed as a response to a policy violation and not entangled
>>> with any more general discussion of listed authors on I-Ds or
>>> RFCs.
>> Of course, removal of individual document editors is well
>> within the rights and responsibilities of the chairs, so if
>> this is the consensus of the IETF, I am sure it can be done.
> That was my assumption.
>
>> I
>> would like you to elaborate on the issue of the authors who
>> are employees of the company but *not* the author of the
>> patent in question. Are you saying that their names should be
>> removed because, as co-workers of the author in question, they
>> ought to have known (or been more diligent in confirming) that
>> the IPR existed and therefore should be sanctioned for failing
>> to comply with the IPR rules, or are you saying that this is a
>> sanction that should be levied against the company and
>> therefore its employees?
> If the other authors from that company have already told us that
> they were not aware of the patent application until very late in
> the process and that they moved diligently toward getting an
> appropriate disclosure filed as soon as they did find out, my
> suggestion is moot.
>
> I was concerned about the (thoroughly unlikely in this case)
> possibility that the other authors from that company were
> personally aware of the IPR but had been, e.g., advised that
> they were not to make the disclosure because someone else would
> take responsibility for it.
>
>> I will note that RFC 3979 does not
>> put a responsibility on individual participants to go discover
>> IPR that may exist, nor does it make any overt requirements of
>> companies since it applies only to the individual participants
>> in the IETF (caveat the recognitions in sections 6.6 and 7).
> Understood.  My separate concerns about the implications of that
> policy should a company ever choose to deliberately hide
> relevant IPR from IETF participants do not apply to this case
> and should not be part of the discussion.
>
>>> (5) Unless the clarification suggested in (2) can be provided,
>>> each IETF participant who is associated with the relevant
>>> company and who is in an IETF-related leadership or
>>> decision-making position (WG Chairs; Editors; IESG, IAB, IAOC,
>>> Nomcom, members; etc.) should be asked to make a conscientious
>>> personal review as to whether this type of action sufficiently
>>> compromises his or her position that resignation or some other
>>> action would be appropriate and, as appropriate, to review
>>> IETF policies with whatever management chains are relevant.
>>> I am _not_ suggesting that anyone be asked to resign, only
>>> that they engage in careful consideration of the issues and
>>> their implications.
>> I believe this last one is outside of the scope of the
>> decisions the IETF has to take regarding the disposition of
>> the particular documents. It may indeed be reasonable for
>> every IETF participant to review the policies and actions of
>> their own employer as they relate to IETF participation and
>> make a conscientious decision whether they can continue to
>> participate in the IETF, whatever their role, given those
>> policies and procedures.
> Complete agreement.  I would, for the record, make much the same
> suggestion about behavior in other situations that appeared to
> push the boundaries of codes of professional ethics of the
> professional societies of which many of us are members.  Like
> the IETF's IPR rules, those provisions are intended to be taken
> seriously rather than as decoration that can be safely ignored.
> The issue is an individual one, not an IETF one, and the current
> issue is relevant only insofar as it should encourage all of us
> --not just those involved in this document-- to take our various
> personal and professional obligations seriously and to consider
> the implications of circumstances in which various of them might
> come into conflict.
>
> best,
>      john
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 26 Jan 2012 10:40:20 -0700
> From: Peter Saint-Andre
> To: SM
> Cc: Pete Resnick, ietf@ietf.org
> Subject: encouraging compliance with IPR disclosure rules
> Message-ID:<4F219004.4070601@stpeter.im>
> Content-Type: text/plain; charset=UTF-8
>
> [ - sieve@ietf.org ]
>
> On 1/26/12 10:15 AM, SM wrote:
>> Hi Pete,
>> At 08:08 26-01-2012, Pete Resnick wrote:
>>> As I've mentioned to others, since I'm one of the people who will have
>>> to judge the consensus on this question, my comments will remain
>>> strictly based on the facts of the events as I know them and on the
>>> relevant IETF procedures. It is up to the IETF community
>> The status of the memo in the drafts have this statement:
>>
>>    "This Internet-Draft is submitted in full conformance with the
>>     provisions of BCP 78 and BCP 79."
>>
>> Have the authors been asked whether they have any issue with the above?
>>
>> The is a question in the write-up: "Has an IPR disclosure related to
>> this document been filed?"  Has the Document Shepherd been asked about
>> that before the Second Last Call?
>>
>> The minutes from the last WG session does not mention who chaired the
>> session.  Did the WG Chair bring the Note Well to the attention of the WG?
> In my opinion, we need to think more creatively about ways to encourage
> compliance with the IPR disclosure rules. Tim Polk and I wrote an I-D on
> the topic last year. Feedback would be welcome.
>
> http://tools.ietf.org/html/draft-polk-ipr-disclosure-00
>
> Peter
>


From arnt@gulbrandsen.priv.no  Fri Jan 27 00:01:29 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B212B21F8525; Fri, 27 Jan 2012 00:01:29 -0800 (PST)
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 n26Aco2nP5vP; Fri, 27 Jan 2012 00:01:28 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id C18A521F8522; Fri, 27 Jan 2012 00:01:28 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 49D96F8C438; Fri, 27 Jan 2012 08:01:26 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1327651285-609-608/10/10; Fri, 27 Jan 2012 08:01:25 +0000
Message-Id: <4F2259D5.5010805@gulbrandsen.priv.no>
Date: Fri, 27 Jan 2012 09:01:25 +0100
From: Arnt Gulbrandsen 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0
Mime-Version: 1.0
To: ietf@ietf.org, sieve@ietf.org
Subject: Re: [sieve] Second Last	Call:	 (Sieve	Notifica	tion Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM> <4F217A7C.6080908@qualcomm.com>
In-Reply-To: <4F217A7C.6080908@qualcomm.com>
Content-Type: text/plain; charset=iso-8859-1
X-Mailman-Approved-At: Fri, 27 Jan 2012 08:18:43 -0800
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 08:01:29 -0000

Pete Resnick wrote:
> We were told by the other company employees who facilitated the
> disclosures, at the time of the disclosures, that this was strictly an
> individual's failure to comply with the IETF IPR Policy, that the author
> in question claims not to have understood the IETF IPR Policy, and that
> the company proceeded to make these disclosures as soon as it discovered
> that this IPR existed. I have no information to contradict that claim.

Barry also said that company procedures have been improved to prevent
this particular type of failure in the future.

Speaking as Sieve WG member and sieve developer, I'm in favour of
treating this as a mishap (albeit a bad one), not an attempt at deception.

Arnt

From william.polk@nist.gov  Thu Jan 26 13:11:17 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0A521F86C2 for ; Thu, 26 Jan 2012 13:11:17 -0800 (PST)
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 rrw9+BfDpojT for ; Thu, 26 Jan 2012 13:11:16 -0800 (PST)
Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 5825521F85D4 for ; Thu, 26 Jan 2012 13:11:16 -0800 (PST)
Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 26 Jan 2012 16:11:08 -0500
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 26 Jan 2012 16:10:31 -0500
From: "Polk, William T." 
To: SM , Peter Saint-Andre 
Date: Thu, 26 Jan 2012 16:11:12 -0500
Subject: Re: encouraging compliance with IPR disclosure rules
Thread-Topic: encouraging compliance with IPR disclosure rules
Thread-Index: Aczcbu9wlhPyH5iBRBSMMvl8lYhOqg==
Message-ID: 
In-Reply-To: <6.2.5.6.2.20120126100436.0b2262b8@resistor.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.0.101115
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 27 Jan 2012 08:18:56 -0800
Cc: Pete Resnick , "ietf@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Jan 2012 21:11:17 -0000

Hi SM,

WG chairs are responsible for bringing their wg activities to successful
and timely completion.  My reading of the IETF policy documents indicates
they are *not* responsible for IPR compliance, and the draft Peter and I
wrote is not intended to change that.

However, IPR disclosure issues always have a negative impact on the
working group's progress.  IMHO, it is in the WG chairs interest to
encourage compliance with IPR rules so that it doesn't negatively impact
their wg activities.  I won't speak for other WG chairs, but I did not
have a strategy to promote IPR disclosure compliance when I was a chair,
and it bit me more than once.  The document suggests several strategies
that a proactive chair could employ to support that goal.

You are certainly correct that WG chairs interact with most IETF
participants more than ADs.  ADs are included in the text you quoted since
they handle publication of individual submissions on the IETF stream.  In
my version of a perfect world, the AD would not worry about IPR compliance
for WG documents since the WG chairs would have employed one or more of
these strategies to at least avoid accidental non-compliance.  However,
the AD might choose to run these strategies themselves to head off similar
problems with individual submissions.

Thanks,

Tim

On 1/26/12 2:01 PM, "SM"  wrote:

>Hi Peter,
>At 09:40 26-01-2012, Peter Saint-Andre wrote:
>>In my opinion, we need to think more creatively about ways to encourage
>>compliance with the IPR disclosure rules. Tim Polk and I wrote an I-D on
>>the topic last year. Feedback would be welcome.
>>
>>http://tools.ietf.org/html/draft-polk-ipr-disclosure-00
>
> From the draft:
>
>   "To support the efficient development of IETF standards and
>    avoid unnecessary delays, chairs and ADs should look for
>    opportunities to promote awareness and compliance with the
>    IETF's IPR policies."
>
>WG Chairs interact with IETF participants more often than ADs.  It is
>not clear whether it is their responsibility to promote awareness and
>compliance.  The IESG could ask two WG Chairs, chosen at random, when
>it meets with the WG Chairs to comment on what they did to promote
>awareness.
>
>Some points in the draft, such as the two-step approach to confirm
>compliance may help to catch issues before they become a concern.
>
>Regards,
>-sm 
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www.ietf.org/mailman/listinfo/ietf


From scott.brim@gmail.com  Fri Jan 27 09:41:57 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE60B21F8628 for ; Fri, 27 Jan 2012 09:41:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 zzkOMHKy2Dv4 for ; Fri, 27 Jan 2012 09:41:57 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 47CC321F8621 for ; Fri, 27 Jan 2012 09:41:57 -0800 (PST)
Received: by iagf6 with SMTP id f6so2921702iag.31 for ; Fri, 27 Jan 2012 09:41:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ZvTVundOCVF4ESpmesZGy+FaJegrbiB/up3O+3mXgNM=; b=LFWKCgrzTojRMUNXye6EK+nYqEbI7eDDIgbbWVjAkG7yA0wW0yHzKMJLE7OXTDltL2 0anwrgfEJ3VmBAC0I+cwno/ZJcH7iBYdt3OvrFyl9inI4q4VXTtgeaPExphoQ0h6qsEI kTUKgU3/msFr4xBcqnLl35d5CYDWvmyPfY/YU=
Received: by 10.43.51.66 with SMTP id vh2mr5811424icb.39.1327686116768; Fri, 27 Jan 2012 09:41:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.55.136 with HTTP; Fri, 27 Jan 2012 09:41:36 -0800 (PST)
In-Reply-To: <6.2.5.6.2.20120126100436.0b2262b8@resistor.net>
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM> <4F217A7C.6080908@qualcomm.com> <6.2.5.6.2.20120126085545.0b1fa288@resistor.net> <4F219004.4070601@stpeter.im> <6.2.5.6.2.20120126100436.0b2262b8@resistor.net>
From: Scott Brim 
Date: Fri, 27 Jan 2012 12:41:36 -0500
Message-ID: 
Subject: Re: encouraging compliance with IPR disclosure rules
To: SM 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Pete Resnick , ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 17:41:57 -0000

On Thu, Jan 26, 2012 at 14:01, SM  wrote:
> =A0"To support the efficient development of IETF standards and
> =A0 avoid unnecessary delays, chairs and ADs should look for
> =A0 opportunities to promote awareness and compliance with the
> =A0 IETF's IPR policies."
>
> WG Chairs interact with IETF participants more often than ADs. =A0It is n=
ot
> clear whether it is their responsibility to promote awareness and
> compliance.

Don't look for some kind of procedural responsibility.  WG Chairs
_want_ to ensure awareness and compliance as early as possible,
because if they don't do so they suffer: they suffer embarrassment and
sometimes failure of all their efforts when IPR is discovered late in
the process.  There's no need to assign responsibility to chairs or
IESG members, we already have plenty of feedback for them.

> Some points in the draft, such as the two-step approach to confirm
> compliance may help to catch issues before they become a concern.

Yup.  Ask early and often, directly and individually.  That clearly
makes the askees responsible, which will matter later.

Scott

From dhc@dcrocker.net  Fri Jan 27 10:14:55 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99ACD21F863F for ; Fri, 27 Jan 2012 10:14:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.601
X-Spam-Level: 
X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 sgrOBovSwjHn for ; Fri, 27 Jan 2012 10:14:54 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 53F4721F8642 for ; Fri, 27 Jan 2012 10:14:54 -0800 (PST)
Received: from [192.168.1.11] (adsl-67-124-148-117.dsl.pltn13.pacbell.net [67.124.148.117]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0RIEm3v012200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jan 2012 10:14:54 -0800
Message-ID: <4F22E993.3070607@dcrocker.net>
Date: Fri, 27 Jan 2012 10:14:43 -0800
From: Dave CROCKER 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Second Last Call:  (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk> <4F20CC0D.7080502@nostrum.com>
In-Reply-To: <4F20CC0D.7080502@nostrum.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, 27 Jan 2012 10:14:54 -0800 (PST)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 18:14:55 -0000

On 1/25/2012 7:44 PM, Adam Roach wrote:
> On 1/25/12 15:50, Jan 25, Adrian Farrel wrote:
> Well, at least U.S. patent application. And, for that matter, International
> Application PCT/CN2008/072066:
>
> http://www.wipo.int/patentscope/search/en/WO2009024088


Google Translate does an impressive job on the Claims for the patent, but not 
good enough, I think.

If there is anyone out there with the skills and motivation, an unofficial 
translation of the claims could be helpful.


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From hartmans@painless-security.com  Fri Jan 27 11:47:50 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1564921F85F3; Fri, 27 Jan 2012 11:47:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.394
X-Spam-Level: 
X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 P5kCoMQNpC+L; Fri, 27 Jan 2012 11:47:49 -0800 (PST)
Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6AB21F8510; Fri, 27 Jan 2012 11:47:49 -0800 (PST)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A9B42204AF; Fri, 27 Jan 2012 14:46:55 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 528A74690; Fri, 27 Jan 2012 14:47:42 -0500 (EST)
From: Sam Hartman 
To: radext@ietf.org,secdir@ietf.org,ietf@ietf.org
Subject: Security review of draft-ietf-radext-radsec
Date: Fri, 27 Jan 2012 14:47:42 -0500
Message-ID: 
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailman-Approved-At: Fri, 27 Jan 2012 11:51:11 -0800
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 19:47:50 -0000

Hi.  I'm not the secdir reviewer assigned to this draft, but felt that
this draft needed additional security review, so I decided to perform a
secdir-like review.

Overall, I think this is a much-needed specification and believe it is
mostly ready for publication as an experimental RFC. I'd say a bit more
clarity would be required if we wanted to move this to the standards
track.

General issues:

1) I'm reasonably sure that RADSEC MUST NOT be used with TLS versions
prior to 1.1. The concern I have is that RADSEC has long-lived TLS
connections under which an attacker could potentially observe ciphertext
generated from some plaintext before sending additional plaintext.  TLS
1.1 includes explicit IVs that prevent various attacks  that may happen
against earlier versions of TLS.
There are implementation work arounds that can also prevent these
attacks. However since all RADSEC implementations are required to
support TLS 1.1, I'd prefer to add a requirement that RADSEC
implementations MUST NOT negotiate TLS versions prior to 1.1 in order to
avoid this issue.

2) Section 2.3 implies that you need to do cert validation all the time,
even when you have a certificate fingerprint. I think it could more
clearly indicate that multiple ways of figuring out if you have the
right public key are provided.  It's also not clear to me from section
2.3 whether there is a mandatory-to-implement strategy. You SHOULD
support cert fingerprints. You MUST support cert path validation, but is
there a required name form to support? There are discussions of several
name forms but none seem mandatory. I see no discussion of RFC 6125,
which I would have expected to see here.  However, most of this is OK
for an experimental spec.  This is the big area where I'd expect to see
more clarity before this could move to the standards track.


From lberger@labn.net  Fri Jan 27 13:05:28 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C045721F867B for ; Fri, 27 Jan 2012 13:05:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.104
X-Spam-Level: 
X-Spam-Status: No, score=-98.104 tagged_above=-999 required=5 tests=[AWL=2.057, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, 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 YGEjvpIbVWYl for ; Fri, 27 Jan 2012 13:05:27 -0800 (PST)
Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id C8BBE21F8643 for ; Fri, 27 Jan 2012 13:05:27 -0800 (PST)
Received: (qmail 803 invoked by uid 0); 27 Jan 2012 21:05:26 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy3.bluehost.com with SMTP; 27 Jan 2012 21:05:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=17YK1bktXHgchMLfPToy43gulCnulu+Nw7tdm8hAJUM=;  b=z+4VuQXwjw5TuYmL/W1MopNifbZuooDU++eUs4UQjZNzSKEzQdINYPEQSyDowMu7vsTgKu7DycCSjnTnNc2nmQjRM3b7qixwd6mK/00MfgUHoDiO4V5zWPJYUABjHuUn;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Rqsz8-00023E-KL; Fri, 27 Jan 2012 14:05:26 -0700
Message-ID: <4F231193.406@labn.net>
Date: Fri, 27 Jan 2012 16:05:23 -0500
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: "Richard L. Barnes" 
Subject: Re: Forthcoming draft: draft-farrresnickel-ipr-sanctions
References: <4F21DDAB.9030300@qualcomm.com> <1DB386B5-47B1-4AB1-A60B-FFF4D6D40299@bbn.com>
In-Reply-To: <1DB386B5-47B1-4AB1-A60B-FFF4D6D40299@bbn.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: Pete Resnick , IETF-Discussion list 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 21:05:28 -0000

I agree there are many "gray area" cases that I think it would be best
to shy away from over specifying.  But what do we do when there is a
bright line violation of RFC3979?  IMO I think we should have consensus
on a very small set of repercussions for blatant violations of RFC3979.
 Even if the consensus is no repercussions.  (In which case we've
established that compliance with the IPR policy is optional.)

While I understand the desire for the WG chairs to deal with such cases
on an as-needed basis, it means that the WG chairs scope is being
expanded from managing the development of technical consensus to
enforcing  IPR disclosure rules (including needing to consider about
legal repercussions.)  I don't think this is a good idea.

Lou

On 1/26/2012 6:35 PM, Richard L. Barnes wrote:
> I appreciate that there need to be disincentives to infringing the IPR policy, but I'm a little wary of the idea of codifying a system of sanctions.  Mainly for the sorts of "gaming the system" thinking they engender:
> -- Is the benefit of infringing worse than the cost of the sanction?
> -- If it's not sanctionable, it must be ok!
> 
> Plus, if there are sanctions, then you need a judgement process to decide when the sanctions will be applied.  Is the IETF set up for that?
> 
> Rather than bright lines and clear sanctions, it seems like a general culture of conservatism, staying far away from things that could possibly be construed as violations, would be more in tune with the way other things work at the IETF.
> 
> No real answers here, just expressing a gut reaction.
> 
> --Richard
> 
> 
> 
> On Jan 26, 2012, at 6:11 PM, Pete Resnick wrote:
> 
>> Just a heads-up:
>>
>> Adrian Farrel and I started work on a draft to focus discussion on sanctions that could be applied to violators of the IETF's IPR policy. Because of incidents like the present one, we've each been asked by WG chairs and others what can be done in response to such violations. We've centered our draft around sanctions that are available under current IETF procedures, not introducing new ones. The draft  should be available in the I-D repository soon. We think this could usefully become an RFC and we would welcome discussion.
>>
>> Thanks,
>>
>> pr
>>
>> -- 
>> Pete Resnick
>> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>>
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
> 
> 
> 

From bernard_aboba@hotmail.com  Fri Jan 27 15:55:50 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C50B21F85C7; Fri, 27 Jan 2012 15:55:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.18
X-Spam-Level: 
X-Spam-Status: No, score=-102.18 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HTML_MESSAGE=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 F+gOmhJXlr7s; Fri, 27 Jan 2012 15:55:49 -0800 (PST)
Received: from blu0-omc3-s1.blu0.hotmail.com (blu0-omc3-s1.blu0.hotmail.com [65.55.116.76]) by ietfa.amsl.com (Postfix) with ESMTP id 03D6121F85D2; Fri, 27 Jan 2012 15:55:48 -0800 (PST)
Received: from BLU152-W47 ([65.55.116.74]) by blu0-omc3-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 27 Jan 2012 15:55:47 -0800
Message-ID: 
Content-Type: multipart/alternative; boundary="_951639fe-3bc0-49ed-a414-debe6639e541_"
X-Originating-IP: [131.107.0.118]
From: Bernard Aboba 
To: Stefan Winter , , 
Subject: RE: [radext] Review of draft-ietf-radext-radsec
Date: Fri, 27 Jan 2012 15:55:47 -0800
Importance: Normal
In-Reply-To: <4F225888.9050601@restena.lu>
References: , , <4F2109F8.4060505@restena.lu>, , <4F225888.9050601@restena.lu>
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Jan 2012 23:55:47.0939 (UTC) FILETIME=[30E54B30:01CCDD4F]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 23:55:50 -0000

--_951639fe-3bc0-49ed-a414-debe6639e541_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Stefan said:
=20
"Ok... 3579 defines it to be that way=2C simply pointing to dynauth=3B my
draft could do so=2C too=2C of course.
5080 lists that it is done elsewhere but doesn't reference a particular
RFC=3B looks to me like it could refer to RFC3579."

[BA] Yes.=20
=20
Stefan also said:
=20
"Interesting use. I don't recall "Error-Cause =3D Invite" being specified
anywhere=3B it's not in the list of enumerated Error-Cause reasons in the
IANA registry anyway.
=20
And it's one message on the list that was never replied to. Looks to me
like it's one particular NAS sending weird things out-of-spec."

[BA] Since the message was posted on the FreeRADIUS list=2C I was hoping
that Alan could enlighten us.  The meaning of "Error-Cause=3DInvite" wasn't
obvious to me (e.g. it didn't look like there was an error involved)=2C=20
and as you mentioned=2C "Invite" isn't in the list of enumerated Error-Caus=
e
values.=20
=20
Stefan said:=20
=20
"I would like to note however that ICMP Port Unreachable is a *very*
coarse-grained way of NAKing accounting that is of little use anyway...

That being said=2C I can change the spec to "patch" the situation with
your suggestion of using Accounting-Response + Error-Cause. It may be
the adequate thing to do since this specification is going for
Experimental only.

[BA] I agree that an ICMP Port Unreachable is not a useful way for a
RADIUS server to tell a RADIUS client that it can't process a particular
Accounting-Request.  However=2C it does allow the destination to indicate
that RADIUS accounting is not supported at all=2C in a way that can be
distinguished from a server or network failure.  That's the functionality
missing in RADIUS over TLS.=20

Stefan said:
=20
"In the long run though=2C I think this solution is inadequate=3B if
Accounting-NAK signalling is to be fixed=2C it should be fixed properly
(i.e. on a per-packet basis) for all transports=2C not just this one.
Maybe by updating 2866 with a consistent use of Error-Cause=2C or maybe by
adding an Accounting-NAK packet type=2C analogous to the dynauth NAKs.

It is definitely a useful thing to work on=3B but it's not for the
RAIDUS/TLS draft to decide. That would need a wg chartered item (luckily
radext is discussing rechartering right now=3B this might be worthwhile to
include...)"

[BA] I agree that ICMP Port Unreachable or an equivalent in RADIUS/TLS
is not a solution to the other problems you mention.

Stefan said:

"Please let me know if you'd prefer the Error-Cause "patch" to be in this
spec=3B I'll do as you say =3B)

[BA] Here is suggested text:

   (5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly
   allocated UDP port to signal that a peer RADIUS server does not
   support reception and processing of RADIUS Accounting packets.=20
   Since RADIUS/TLS does not utilize a separate port for Accounting
   packets=2C this mechanism is not available.  In the event that a=20
   client is misconfigured to send Accounting-Request packets to
   a RADIUS/TLS server which does not support accounting=2C the=20
   RADIUS/TLS server SHOULD reply with an Accounting-Response=20
   containing an Error-Cause attribute with value 406=20
   "Unsupported Extension".  A RADIUS/TLS accounting client=20
   receiving such an Accounting-Response SHOULD log the error. =20


=20
 		 	   		  =

--_951639fe-3bc0-49ed-a414-debe6639e541_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





      
Stefan said:
       
      "Ok... 3579 defines it to be that way=2C sim=
ply pointing to dynauth=3B my
      draft could do so=2C too=2C of course.
      =
5080 lists that it is done elsewhere but doesn't reference a particular
      =
RFC=3B looks to me like it could refer to RFC3579."

      [BA] Yes. 
       <=
br>Stefan also said:
       =3B
      "Interesting use. I don't recall "Error=
-Cause =3D Invite" being specified
      anywhere=3B it's not in the list of e=
numerated Error-Cause reasons in the
      IANA registry anyway.
       
      And i=
t's one message on the list that was never replied to. Looks to me
      like =
it's one particular NAS sending weird things out-of-spec."

      [BA] Sinc=
e the message was posted on the FreeRADIUS list=2C I was hoping
      that Ala=
n could enlighten us.  The meaning of "Error-Cause=3DInvite" wasn't
      obvi=
ous to me (e.g. it didn't look like there was an error involved)=2C 
      and=
 as you mentioned=2C "Invite" isn't in the list of enumerated Error-Causevalues. 
       
      Stefan said: 
       
      "I would like to note however that=
 ICMP Port Unreachable is a *very*
      coarse-grained way of NAKing accounti=
ng that is of little use anyway...

      That being said=2C I can change t=
he spec to "patch" the situation with
      your suggestion of using Accountin=
g-Response + Error-Cause. It may be
      the adequate thing to do since this =
specification is going for
      Experimental only.

      [BA] I agree that a=
n ICMP Port Unreachable is not a useful way for a
      RADIUS server to tell =
a RADIUS client that it can't process a particular
      Accounting-Request.  =
However=2C it does allow the destination to indicate
      that RADIUS account=
ing is not supported at all=2C in a way that can be
      distinguished from a=
 server or network failure.  That's the functionality
      missing in RADIUS =
over TLS. 

      Stefan said:
       
      "In the long run though=2C I think t=
his solution is inadequate=3B if
      Accounting-NAK signalling is to be fixe=
d=2C it should be fixed properly
      (i.e. on a per-packet basis) for all tr=
ansports=2C not just this one.
      Maybe by updating 2866 with a consistent =
use of Error-Cause=2C or maybe by
      adding an Accounting-NAK packet type=
=2C analogous to the dynauth NAKs.

      It is definitely a useful thing t=
o work on=3B but it's not for the
      RAIDUS/TLS draft to decide. That would=
 need a wg chartered item (luckily
      radext is discussing rechartering rig=
ht now=3B this might be worthwhile to
      include...)"

      [BA] I agree t=
hat ICMP Port Unreachable or an equivalent in RADIUS/TLS
      is not a soluti=
on to the other problems you mention.

      Stefan said:

      "Please le=
t me know if you'd prefer the Error-Cause "patch" to be in this
      spec=3B =
I'll do as you say =3B)

      [BA] Here is suggested text:

         (5) R=
ADIUS/UDP [RFC2865] u=
ses negative ICMP responses to a newly
   allocated UDP port to signal that a peer RADIUS server does not
   support reception and processing of RADIUS Accounting packets. 
         Si=
nce RADIUS/TLS does not utilize a separate port for Accounting
         packet=
s=2C this mechanism is not available.  In the event that a 
         client is=
 misconfigured to send Accounting-Request packets to
         a RADIUS/TLS ser=
ver which does not support accounting=2C the 
         RADIUS/TLS server SHOUL=
D reply with an Accounting-Response 
         containing an Error-Cause attrib=
ute with value 406 
         "Unsupported Extension".  A RADIUS/TLS accounting=
 client 
         receiving such an Accounting-Response SHOULD log the error. =
 


       
       		 	   		  
      
=

--_951639fe-3bc0-49ed-a414-debe6639e541_--

From alexey.melnikov@isode.com  Sat Jan 28 06:15:52 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011FA21F855B for ; Sat, 28 Jan 2012 06:15:52 -0800 (PST)
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 kInd-w06wWmz for ; Sat, 28 Jan 2012 06:15:51 -0800 (PST)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 90F4021F8503 for ; Sat, 28 Jan 2012 06:15:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1327760149; d=isode.com; s=selector; i=@isode.com; bh=XfOXnyRpbN3tlt+Kj0Dlh28YZ9WuzlXwDhvBuZdHyt8=; 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=Nlrkyvpr0G+OpltPrS6rg8Adh3nXBhUZlYaXgQARZT+bY/y5HnuPCYGSmCvml2S14cxjM+ ZxH1563rkPVRsBSLeJ3PuTC9Zv3SlqDpjOrYWa1EfdDnfI4RdQJazAu8jOcN4Gg0VKwXKz KABDPHKYTBWLX9QM9U8A3CSQ1wu2GRU=;
Received: from [188.29.1.112] (188.29.1.112.threembb.co.uk [188.29.1.112])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Sat, 28 Jan 2012 14:15:47 +0000
Message-ID: <4F23FFAA.8050707@isode.com>
Date: Sat, 28 Jan 2012 14:01:15 +0000
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
To: Barry Leiba 
Subject: Re: Second Last Call:   (Sieve Notification Mechanism: SIP MESSAGE) to Proposed Standard
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com>  <4F21ABF2.7040002@qualcomm.com> <6842.1327617385@marajade.sandelman.ca>  
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "ietf@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Jan 2012 14:15:52 -0000

On 27/01/2012 01:50, Barry Leiba wrote:
  [...]
> On Thu, Jan 26, 2012 at 12:37 PM, John C Klensin  
> wrote:>> We were told by the other company employees who facilitated
>>> the disclosures, at the time of the disclosures, that this was>>  strictly an individual's failure to comply with the IETF IPR>>  Policy, that the author in question claims not to have>>  understood the IETF IPR Policy, and that the company proceeded>>  to make these disclosures as soon as it discovered that this>>  IPR existed. I have no information to contradict that claim.>>  Excellent.   I had hoped that was the situation.  It obviously>  makes things much easier (and some of my earlier comments>  irrelevant).   With all the effort we go to ("Note Well" and>  otherwise) to be sure that people are informed about the policy,>  I have trouble generating sympathy for someone who says "didn't>  underatand", but that is another matter (and perhaps just my>  problem).
> That is, indeed the situation.  Qian Sun, the original Huawei author,
> got a new assignment in the company, and stopped participating in the
> IETF a few years ago, after he and Alexey had started the documents.
> I can't speak for him about why he didn't understand the disclosure
> rules; as I understand it, he seems to have thought the patents didn't
> need to be disclosed until the RFC was published.

I just want to add that I was not aware of the fact that Qian Sun has 
filed patent applications, he didn't tell me.
(Not that it makes much difference, but in the interest of historical 
accuracy: In one case I started the draft by myself and Qian Sun offered 
to help with finishing it. In another case Qian Sun wrote a draft based 
on text from my other RFC and was bugging me to help out.)
>> If the other authors from that company have already told us that
>> they were not aware of the patent application until very late in
>> the process and that they moved diligently toward getting an
>> appropriate disclosure filed as soon as they did find out, my
>> suggestion is moot.
> Some time last year, Kepeng and I offered to work with Alexey to
> finish the two docs, which had seen slow progress for some while.
> Only when the documents were approved and in the RFC Editor queue did
> Kepeng learn about Qian's patent applications.  He immediately alerted
> me.  I asked the RFC Editor to stop publication (one was in AUTH48 at
> the time), and alerted Pete Resnick and the Sieve chairs.  Kepeng
> pushed Huawei's IP law department to expedite the disclosure, which
> they turned around in two days for us.  I assure all of you that
> Kepeng and I were blindsided by this.

I obviously believe you :-). As much as I hate the whole situation, I am 
glad that this happened before the document got published as an RFC, not 
after.
>> I was concerned about the (thoroughly unlikely in this case)
>> possibility that the other authors from that company were>  personally aware of the IPR but had been, e.g., advised that>  they were not to make the disclosure because someone else would>  take responsibility for it.
> Unlikely in this case, yes.  I leave it to you whether you trust what
> I say, but I can only repeat that we did not know, and acted very
> quickly when we found out.


From randy@qualcomm.com  Sat Jan 28 08:59:01 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F1921F84E1 for ; Sat, 28 Jan 2012 08:59:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.234
X-Spam-Level: 
X-Spam-Status: No, score=-101.234 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_06_12=1.069, MIME_8BIT_HEADER=0.3,  MIME_QP_LONG_LINE=1.396, 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 41npSW1OHQjV for ; Sat, 28 Jan 2012 08:59:00 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0168621F84C2 for ; Sat, 28 Jan 2012 08:58:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1327769939; x=1359305939; h=message-id:x-mailer:x-priority:date:to:from:subject: mime-version:content-type:content-transfer-encoding: x-random-sig-tag:x-originating-ip; z=Message-ID:=20 |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|X-Priority:=202 =20(High)|Date:=20Fri,=2027=20Jan=202012=2023:56:00=20-08 00|To:=20|From:=20Randall=20Gellens=20|Subject:=20Le=20Meridien=20Etoile=20for =20$149=20(=20=3D?iso-8859-1?Q?=3DA4115?=3D=20)=20per=20n ight.|MIME-Version:=201.0|Content-Type:=20text/plain=3B =20charset=3D"iso-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=20quoted-printable |X-Random-Sig-Tag:=201.0b28|X-Originating-IP:=20[172.30.4 8.1]; bh=42cHUIaIEMO0IJSHiWp4N+tbSfOiXHh0GtNMiKhExfw=; b=Or9P03nS7a4bP0dQWS7niXwyWHbanFqy1rV2sNc6hGidBAz4p0+mF4nD EbefqtY16qYNdlc1wuQ1NqgQqyVPzlZxi17H/b4RAIXG70kSK39ylaYbh WoapunCq/H7Dv5QhxPqONogjnvqLR8f74CDVOGmlxYzOxu8wJUKIMFDuZ s=;
X-IronPort-AV: E=McAfee;i="5400,1158,6602"; a="156372679"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 28 Jan 2012 08:58:59 -0800
X-IronPort-AV: E=Sophos;i="4.71,585,1320652800"; d="scan'208";a="193029130"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 28 Jan 2012 08:58:59 -0800
Received: from loud.pensive.org (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sat, 28 Jan 2012 08:58:58 -0800
Message-ID: 
X-Mailer: Eudora for Mac OS X
X-Priority: 2 (High)
Date: Fri, 27 Jan 2012 23:56:00 -0800
To: 
From: Randall Gellens 
Subject: Le Meridien Etoile for $149 ( =?iso-8859-1?Q?=A4115?= ) per night.
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.48.1]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Jan 2012 16:59:01 -0000

I just learned that rooms at Le Meridien Etoile=20
are available for $149 (=A4115) per night through=20
TravelZoo.  Book by Feb 1, but likely to sell out=20
before then, so if interested, recommend booking=20
soon.  Also available is an Executive room (only=20
difference is free Internet and more modern=20
interior) for $199 (=A4154) per night.  Rooms in=20
between (deluxe and Urban) are also available.=20
The rate also says "includes free upgrade" which=20
I believe means that if you booked an "Urban=20
room" you would be eligible on a space-available=20
basis an upgrade to an Executive and hence free=20
Internet.

Non-refundable/changeable, and only available for=20
first half of week.  But I figure even switching=20
rates  midway through the way is a lot cheaper,=20
and in my experience hotels let you stay in the=20
same room, and combine multiple reservations into=20
one on check-in.

http://www.travelzoo.com/hotels/international/-149-Paris-Upgraded-Room-at-4-=
Star-Hotel-50-Off-1177644/

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Our greatest fear is that the Internet will become a vehicle of free
distribution of information.  --Ken Wasch, President of the Software
                           Publishers' Association, 5 September 1995

From tglassey@earthlink.net  Sat Jan 28 10:22:40 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E156821F8533 for ; Sat, 28 Jan 2012 10:22:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.861
X-Spam-Level: 
X-Spam-Status: No, score=-1.861 tagged_above=-999 required=5 tests=[AWL=-1.862, BAYES_50=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 AXhMYQuprm3X for ; Sat, 28 Jan 2012 10:22:40 -0800 (PST)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2CD21F8508 for ; Sat, 28 Jan 2012 10:22:40 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=P6+nQ5ebBc39+0QP2vSuaSCsOnihx8Ea6Ldp1oclyiHRq0C1VhpAlS59e1oflRzH; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Opacus-Archived:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [67.180.133.66] (helo=[192.168.1.100]) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RrCv9-0004qc-Ki for ietf@ietf.org; Sat, 28 Jan 2012 13:22:39 -0500
Message-ID: <4F243CED.5020708@earthlink.net>
Date: Sat, 28 Jan 2012 10:22:37 -0800
From: todd glassey 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: IETF Discussion Mailing List 
Subject: License Disclosure Protocol - a Research and then Standards Track Proposal
X-Opacus-Archived: none
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79b51dd2b6df5a7839c336f04b02cc285a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 67.180.133.66
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Jan 2012 18:22:41 -0000

Folks - FIRST OFF THANKS FOR READING THIS -

I want to propose a new thing here that we as technologists can provide
the world with and that is a uniform method of disclosing the RIGHTS TO
USE status with any Internet based service.

You say what would that pertain to? The answer is that there are many
protocols in use today which just assume (by the design that they make
no provisions for using their services - in re the licensing and that
this is a problem).

This  newly emerged need is VERY important in fighting delivery access
and control processing.

What I want to propose is that there are use licenses attached to things
like DNS Name Conversions which can be used to attack the spammers of
the world in courts and to also provide better protection from Internet
abuse since these will pertain to routing as well.

I am pretty sure this will be a somewhat unpopular idea but it is an
important idea and one which really needs to happen formally whether you
take this commentary from me or not.

Therefore - I suggest that the IETF WG open a 'research project' to
formally look into how a licensing and control protocol for disclosing
licensing to end-users could be implemented and how that would be used
with existing protocols including the IPv6 forward routing controls.


Todd

-- 
Todd S. Glassey
This is from my personal email account and any materials from this
account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.

From sm@resistor.net  Sat Jan 28 11:51:02 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB79321F8508 for ; Sat, 28 Jan 2012 11:51:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.61
X-Spam-Level: 
X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, 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 7Fn-HDJMptpE for ; Sat, 28 Jan 2012 11:51:01 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6B521F84EC for ; Sat, 28 Jan 2012 11:50:56 -0800 (PST)
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 q0SJooZH017239 for ; Sat, 28 Jan 2012 11:50:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327780255; i=@resistor.net; bh=pqZDAakPk+jFuPyTtmjMh1QuTpOcqBDc1WYC2ZuqiFc=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=P9wDmxD0BzKLV19uyiUlTJo9eUnNzYYnami5OlpkLP0B+VsAKQhCfnCm1O9hajo2m fYeJ8Q+DH3Oag1YmlfSlKhKl2T5tOwEKvSCnaUkA/Pd7FlyRCqvEDNXCR6PUEWybAZ n2gg8nODKY0B/rbyrVv8xcAx4yEfub4nxhcs0lTI=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327780255; i=@resistor.net; bh=pqZDAakPk+jFuPyTtmjMh1QuTpOcqBDc1WYC2ZuqiFc=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=RUtrNURtH/PqdusIGHvhWTb72V9KUg6xprFSrggBspAvh5g6qoyDy85d8qmMetwLq 8ZolvvlIDj0U8S5tpx+sXfGER3S6xXKUstvlOrbS51KgmiDn+y242LtZEakNUwSgs5 3rZJAgBGzQXsfbwiWUqbeSpZUZm8Y3lEtCpLezFI=
Message-Id: <6.2.5.6.2.20120128113650.0ac81c08@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 28 Jan 2012 11:50:34 -0800
To: IETF-Discussion list 
From: SM 
Subject: Re: Forthcoming draft: draft-farrresnickel-ipr-sanctions
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Jan 2012 19:51:03 -0000

At 17:19 26-01-2012, Dave CROCKER wrote:
>What I believe is /not/ worth keeping -- and which we have already 
>made piecemeal concessions to -- is that corporations in fact /do/ 
>participate in the IETF and need to be treated as responsible 
>participants.  (Note that the word responsible, here, has two 
>interpretations.  I mean both of them.)

http://blog.mocality.co.ke/2012/01/13/google-what-were-you-thinking/

Regards,
-sm


From wwwrun@ietfa.amsl.com  Fri Jan 27 14:51:39 2012
Return-Path: 
X-Original-To: ietf@ietf.org
Delivered-To: ietf@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 30) id 9EF1C21F85F3; Fri, 27 Jan 2012 14:51:37 -0800 (PST)
From: NomCom Chair 
To: IETF Announcement list 
Subject: Nomcom 2011-2012: IESG Appointments 
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <20120127225138.9EF1C21F85F3@ietfa.amsl.com>
Date: Fri, 27 Jan 2012 14:51:37 -0800 (PST)
X-Mailman-Approved-At: Sat, 28 Jan 2012 14:10:25 -0800
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 22:51:40 -0000

Hi all,

The 2011-2012 IETF Nominating committee is pleased to announce
the selection of the IESG members whose two year terms start at
IETF83.

The Nomcom has selected the following persons to serve as Area
Directors in the open IESG positions and they have been confirmed
by the IAB (in its role as the confirming body):

Applications: Barry Leiba
Internet: Brian Haberman
Operations and Management: Benoit Claise
Real-time Applications and Infrastructure: Gonzalo Camarillo
Routing: Stewart Bryant
Security: Sean Turner
Transport: Martin Stiemerling

We would like to express our sincere gratitude to the incumbents
who are not returning for their outstanding service, the many
highly qualified members of the community who offered to serve,
the community for their assistance in this process, and the
individuals named above for agreeing to serve the community on
the IESG.

Suresh Krishnan
Chair, NomCom 2011-2012
nomcom-chair@ietf.org
suresh.krishnan@ericsson.com

From wwwrun@ietfa.amsl.com  Fri Jan 27 14:59:18 2012
Return-Path: 
X-Original-To: ietf@ietf.org
Delivered-To: ietf@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 30) id 53C5121F865A; Fri, 27 Jan 2012 14:59:18 -0800 (PST)
From: NomCom Chair 
To: IETF Announcement list 
Subject: Nomcom 2011-2012: IAOC Appointment 
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <20120127225918.53C5121F865A@ietfa.amsl.com>
Date: Fri, 27 Jan 2012 14:59:18 -0800 (PST)
X-Mailman-Approved-At: Sat, 28 Jan 2012 14:10:25 -0800
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jan 2012 22:59:18 -0000

Hi all, 

The 2011-2012 IETF Nominating Committee is pleased to announce
the selection of an individual to serve on the IETF
Administrative Oversight Committee (IAOC) for a two year term
starting at IETF83.

The Nomcom has selected Marshall Eubanks as an IAOC member,
and this selection has been confirmed by the IESG in its role as
the confirming body.

We would like to express our sincere gratitude to Marshall for
agreeing to serve, to the many highly qualified members of the
community who offered to serve, and to the community for their
assistance in this process.

Suresh Krishnan
Chair, NomCom 2011-2012
nomcom-chair@ietf.org
suresh.krishnan@ericsson.com

From sra@hactrn.net  Fri Jan 27 21:02:42 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AD721F84F9 for ; Fri, 27 Jan 2012 21:02:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.52
X-Spam-Level: 
X-Spam-Status: No, score=-101.52 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_20=-0.74, 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 PMhWdY393C-l for ; Fri, 27 Jan 2012 21:02:40 -0800 (PST)
Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by ietfa.amsl.com (Postfix) with ESMTP id 18E7121F84A3 for ; Fri, 27 Jan 2012 21:02:33 -0800 (PST)
Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id CF68428471; Sat, 28 Jan 2012 05:02:29 +0000 (UTC)
Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 98A9717711; Sat, 28 Jan 2012 00:02:29 -0500 (EST)
Date: Sat, 28 Jan 2012 00:02:29 -0500
From: Rob Austein 
To: Terry Manderson 
Subject: Re: Last Call:  (The RPKI/Router Protocol) to Proposed Standard
In-Reply-To: 
References:  
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Message-Id: <20120128050229.98A9717711@thrintun.hactrn.net>
X-Mailman-Approved-At: Sat, 28 Jan 2012 14:10:15 -0800
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Jan 2012 05:02:42 -0000

At Wed, 21 Dec 2011 17:43:23 -0800, Terry Manderson wrote:
> 
> Apologies for my lack of attention to date on this topic, so speaking only
> for myself here.

Similar apologies for not having answered this more promptly.  Somehow
we missed seeing this until our AD asked us about it.

Please see draft-ietf-sidr-rpki-rtr-25, just posted, which we hope
addresses most of your concerns (there are a few points on which I
think we're just going to have to agree to disagree).

> Starting with the document structure, I see no reference to a set of
> requirements. The introduction is rather vague, and if anywhere that is
> where I would expect to see such a requirements description. This means for
> the rest of document I found myself asking "why" on many levels.

Motivation was discussed at some length in the SIDR WG.  We hadn't
thought it necessary to discuss this in the draft, but -25 adds a bit
of text on this.

In brief, though, for ietf@ietf.org readers who weren't tracking the
WG: the primary goal of this protocol was to make it possible to run
BGP origin authentication based on RPKI data on currently shipping
router hardware, rather than having to wait for bigger processors,
crypto accelerators, etcetera.  So we wanted a simple protocol that
would let us do all the heavy lifting (RPKI data collection,
certificate checking, computation of deltas from previous data, etc)
somewhere off the router, and feed the router only what it needs.

> When I got to the end of the document I felt that the protocol borders on a
> wheel re-invention exercise. When you think about a router simply being a
> client to a cache that is providing RIB access tokens for a route using a
> mechanism that is a secure, stable, scalable, known (by both vendors and
> operators), and is extensible, I'm more likely to swing to RADIUS in doing
> such a service with nicely structured AV-Pairs and sane timers for
> reauth/retry etc. Even the SME's know radius for their WPA enterprise kit.

RADIUS doesn't have a bulk transfer operation, and bulk transfer of
data is the main task of this protocol, particularly at start-up.

You are certainly entitled to your opinion, but it comes a bit late.
This work was done in the public view, with regular progress reports
to the SIDR WG, and we have multiple interoperable implementations
including several of the major router vendors.  So, with all due
respect, I don't think the folks who have put work into this will be
all that interested in abandoning running code at this point.

> Glossary:
> 
> Global RPKI: 
> I disagree with this definition for two reasons. 1) I'm not aware of a
> unified definition for 'distributed system' so this is all rather vague.

The term has been used to describe DNS for decades.  Also see:

  http://en.wikipedia.org/wiki/Distributed_computing

> Perhaps you could say 'published at a disparate set of systems'.

I don't find that any clearer.  Readers who can't understand the words
"distributed set" aren't likely to understand "disparate set" either.

> 2) Limiting
> the servers to be "at" the "IANA, RIRs, NIRs, and ISPs" is also premature.
> It's not clear to me that these entities will run their own repositories,
> nor are they going to be the only repository operators in the lifecycle of
> the RPKI.

This is essentially the same list as appears in section 1.1 of
draft-ietf-sidr-arch, with the term "LIR" replaced by "ISP".

I suppose we could add "or other service providers".

> Cache:
> The words surrounding the fetch/refresh mechanisms of the RPKI is limiting.
> Both draft-ietf-sidr-repos-struct and draft-ietf-sidr-res-certs allow for
> other (future) retrieval mechanisms as defined by the repository operator
> beyond RSYNC (loosely documented in RFC5781).

Terry, you've made it quite clear that you disagree with the SIDR WG's
decision to make rsync the mandatory-to-implement RPKI retrieval
protocol, but you lost that argument a long time ago, and I fail to
see the point of bringing it up here yet again.

> Last sentence. "Trusting this cache further is a matter between the provider
> of the cache and a relying party". In my mind the Relying Party was the one
> that did the RPKI validation - would this not be better stated as "Trusting
> this cache further is a matter between the provider of the cache and the
> router operator".

If a router is making decisions based on data given to it by a server,
the router is the relying party in that relationship.  That the server
in question was itself the relying party in another relationship does
not change this.

The picture here is not all that different from the way that some
vendors have chosen to implement DNSSEC.  It's a two-tier security
relationship: an end-to-end relationship between the publisher of
signed objects and the validator of those signed objects, then a
separate security relationship between the entity that validated the
signed objects and the end entity that actually uses the data.

> Deployment Structure:
> 
> Why repeat the definition of "Global RPKI"? It's superfluous.

Because it's not a definition?

I agree that the text here is similar to the definition, but this
section is trying to describe the roles in the system.

> Local Cache: Again. 'Relying party' seems to be borrowed from the
> CA/identity world. Unless you redefine that term here it seems as if the
> "router" is making RPKI validation decisions. Which it is not. The router is
> acting more like a NAS (See Radius, 2865) when talking to a local cache.
> 
> The definition of "routers" seems to get this right - eg "a client of the
> cache".

See above.  "Relying party" is a security relationship term, not just
a PKI term.

> Operational Overview
> 
> when you first use "ROA", please expand the TLA, and provide a reference.

Done.

> Serial Query
> 
> I don't remember seeing a recommendation for how often a client (router)
> sends a serial query. Is there a Min/Max? Surely doing it every second would
> be excessive..

Maximum is covered in section 6.2: the router must send a Serial or
Reset Query no less frequently than once per hour.

Minimum is a good question.  We had been assuming that, as this is an
in-POP relationship with cache and router operated by the same party,
there would likely be a knob in the router (router guys live for
knobs) and setting it would be a matter of local policy.  If you want
your router to beat up your cache server every minute, who am I to
stop you?

We needed to set a maximum because that affects the architecture of
the cache (how long does it need to hold onto old data -- given the
potential size of the data sets involved, one might implement the
cache very differently if one needed to hold old data for a week
rather than an hour).

> IPv4 Prefix:
> 
> "and nothing prohibits the existence of two identical
>    route: or route6: objects in the IRR."
> 
> Why even mention the IRR here? It just doesn't seem at all relevant. (and
> isn't defined)

Good catch.  Done.

> " IPvX PDUs" expand to IPv4 or IPv6. Globing into one is a misdirection
> under a heading of 'IPv4 Prefix'
> 
> IPv6 Prefix
> 
> Some text here to say that the IPv6 data structure follows the same
> semantics as the IPv4 data structure would be good.. or alternatively
> restructure the document to Semantics, then describe the IPv4 and IPv6 data
> structures as subheadings to Prefix PDUs.

Done.

> Error Report
> 
> What is "excessive length" of a PDU? at what point do you say "o.k, now I
> can truncate".

Too long to be any valid PDU other than an Error Report.  Done.

> Fields of a PDU
> 
> For all types, instead of using "ordinal" can you use the exact description
> of the number? eg unsigned integer? For me I always relate ordinals to set
> theory.

Done.

> PDU type, the e,g is incomplete shouldn't it be "IPv4 Prefix = 4" with a
> forward reference to the IANA Considerations section?

I think this is a matter of stylistic preference.

> Serial Number. "for example via rcynic", Is not defined and implementation
> specific!

Please read the words "for example".

I suppose we could add a reference, but the last time we did that
somebody objected to having a reference pointing to the source code
for a particular implementation.

> and there is a typo "completing an rigorously validated"..while
> there, consider why you use the term 'rigorously'..

Sigh.  Next time, please be explicit about the typo you're seeing, our
eyes repeatedly bounced off the "an" here until after we'd posting
version -25.  It's not worth yet another rev just to fix that.

> are there situations when a validation is less rigorous? If so
> explain.

I suspect that my co-author was trying to say that one can't just
retrieve the data, pull the ASNs and prefixes out of the ROAs, and
feed them into the router, one has to do the RPKI validation first.

I guess we can remove the word if it offends you, but it seems
harmless.

> Session ID
> 
> What is the risk of a cache server starting/restarting with the same session
> ID and serial number as before, but with different cache contents? Is this
> an entropy concern? Just thinking of a potential scenario where a router is
> cache-wedged. Is this at all probable? and why not - some words here to
> cover this would be good.

We added several paragraphs on exactly this topic sometime around IETF
Last Call, I suspect the version you reviewed did not have that text.
I think we've addressed this point, please check the current text and
let us know if there's a further issue here.

> Flags
> 
> Can you reword the binary choice here? Do you actually need to delve into
> 'right to announce'? This is really about RIB entry behaviors yeah?

The semantics here are closely related to ROAs, which, as you no doubt
recall, are Route Origin Authorizations, so the text here follows that
model.

With all due respect, I do not think that a discussion of RIB entry
behavior here would be simpler.

> Expand "IPvX".

Done.

> Start or Restart:
> 
> I think the terms in when a router needs to send a serial query or a reset
> query need to be tighter. Saying MAY here is too loose. I would much prefer
> to see a structure where if the router does not have a recorded serial for a
> cache from a previous session, the router MUST send a reset query. Logically
> you assume that to be the case, so be specific.

I think this is a stylistic matter again.  The router MAY do two
things here, one of which is only applicable if it has data from a
previous broken session.

The only real difference I see here between the current formulation
and the MUST formulation you prefer is that, as currently written, the
router could chose not to send anything at all initially; this option
doesn't seem particularly useful, so I don't mind removing it, but
neither do I see the difference between the current text and your
suggested change as a big deal.

> Thereafter the router MAY send a reset query, and SHOULD send a serial
> query. I suspect this is what the vendors (who have chimed in on the list)
> have coded.
>
> This then corroborates section 4 where you suggest the router only send
> serial queries for efficiency.

Section 6.2 already says that the typical exchange is for the cache to
send a Serial Notify, in the expectation that the router will schedule
an immediate Serial Query.  We didn't make it any stronger than that
because the folks implementing the router side of this expressed
concern at the notion that the cache could tell them to do something
(read: they understand that the notification mechanism will help speed
convergence, but they're worried that the dinky CPUs they're stuck
with in some of the relevant hardware will be swamped if they try too
hard, which is why routers are allowed to ignore notifications and
caches are rate-limited in sending them).

> Transport:
> 
> MiTM is Man in the middle as I and many others know it. 'Monkey/piggy/pickle
> in the middle' is a child's ball game.

Monkey-in-the-middle is a common non-sexist variant of this term.
Welcome to the 21st century.

> " Therefore, as of this document, there is no mandatory to
>    implement transport which provides authentication and integrity
>    protection."
> 
> if this is the case.. then why? what is the gain?

OK, this is the elephant in the living room.

The basic problem is that the implementers and the IETF live on
different planets.  As discussed in section 7, it is pretty much
impossible to find any channel security technology which is
implemented on conventional servers (Linux, BSD, ...), is implemented
on routers, and is acceptable to the IETF security folks.

As further discussed in Section 7, the long term plan is TCP-AO, and
there are people out there implementing that now, but it's going to be
a few years before that's usable.  In the meantime, we're stuck with
ad-hoc pairings of what particular platforms support.  Some routers
support SSH clients, some don't.  Some server platforms support
TCP-MD5, some don't, the IETF doesn't like TCP-MD5, and at least one
that sort-of-supports TCP-MD5 only supports it for incoming
connections.  Some routers support IPsec transit but can't terminate
it.  And so forth.  It's a horrible mess.

So, as discussed at some length in the SIDR WG, after talking both to
people who knew the current router and server platforms and to the
SIDR WG's security advisor, we came up with the compromise you see in
the draft: the path forward is TCP-AO, but since we don't have that
yet, there's this raft of other channel security mechanisms one is
allowed to use for now.  We expect to deprecate everything but TCP-AO
once TCP-AO is readily available.

Nobody is happy with this, but it's the least bad compromise we could
find between what the IETF would prefer and reality in the field.

> why not then make the router fetch the signed objects and do the
> validation internal - this again seems to be the 'missing
> requirements' problem.

See "currently shipping routing hardware", above.

> SSH Transport
> 
> State up front that you MUST use SSHv2. (instead hinting in the third
> paragraph)

Done.

> TLS Transport
> "Man in The Middle (MiTM)" please.

Above.

> Router Cache setup
> 
> "When a more preferred cache becomes available, if resources allow, it
>    would be prudent for the client to start fetching from that cache."
> 
> How does the client (I assume router) know when to do this as cache's are
> not synchronized?? How does a router tell if any particular cache has more
> current data over another cache? what if two caches contradict each other?

The document repeatedly states that the router has an ordered
preference list of the caches it uses.  The text you quote here
doesn't say "has more current data", it says "becomes available", ie,
it stops rejecting connection attempts, signalling errors, or
otherwise failing to be useful.

> Error codes
> 
> 6: Withdrawal of Unknown Record (fatal), why drop the session? (which
> presumably causes a restart) to a cache, assuming the cache is corrupt,
> which will then send another Unknown Record, which is fatal... (repeat)??
> 
> Why not mark the cache as corrupt at the client?

This is one of several loss-of-synchronization problems.  The
assumption is that the router may have (somehow) lost synchronization
with the cache.  We don't really know which party is confused at this
point, all we know is that the session itself is no longer useful
because the router and cache are not communicating clearly.  So the
router's data isn't necessarily corrupt.

The router won't necessarily restart with this cache right away
either, it has several options: it might try another cache, it switch
to another set of data it has already loaded, or might try a reset
query to this cache.

> Security Considerations:
> 
> Transport Security. There are multiple valid options for a root trust anchor
> including the structure from the IAB aligning it to the IANA. Perhaps
> instead of saying " the IANA root trust anchor" say "Global RPKI root trust
> anchor". Otherwise you might accidently find your validated cache only
> covers unallocated and reserved blocks.

I think you're saying that using the term IANA here is politically
incorrect.


Thanks for the review!

From sm@resistor.net  Sat Jan 28 22:53:44 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E5E21F855F for ; Sat, 28 Jan 2012 22:53:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.61
X-Spam-Level: 
X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, 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 K+6n4wHzxTRC for ; Sat, 28 Jan 2012 22:53:42 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B154921F849A for ; Sat, 28 Jan 2012 22:53:42 -0800 (PST)
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 q0T6rTo5014288; Sat, 28 Jan 2012 22:53:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327820016; i=@resistor.net; bh=xcOW2Bw+gXa2e4aORIDZZs3aRsD2KHdBEcPPWkgQxn0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=WYJiQqkYq2RBQ2zGQuFjXMb4rvhUAvx2VA0sUbs5ypozpaLvF51X38kHjffEo6vyX kEh2pmzpJeGGD70HT0KNlZHcDFZV5Fb6m9xPxNI7ADII8Vp9taD3EJ7TfUD2QeoUtI XN2TzBTz65wQFWLNWvk7atAW+OxiJRYUte9IDrX8=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327820016; i=@resistor.net; bh=xcOW2Bw+gXa2e4aORIDZZs3aRsD2KHdBEcPPWkgQxn0=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=S1kTlq3TVc/4Zk/bW2sK2aN1kTgbH7cKrDYua0W6Fs8P8+lq6/R5XO9R9JRcBxHMy TNlXAigtb5vqF8oITDOWbsw+VuL3BN0G0lBdbeYKlZ97EaRWk6x5zf473Sm0OJrDxa OHXiAd6te4WGOGWinOvFVJij0mZnSxXzDvq20BHk=
Message-Id: <6.2.5.6.2.20120128200753.0ab5c6f8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 28 Jan 2012 22:33:40 -0800
To: Rob Austein 
From: SM 
Subject: Re: Last Call:  (The RPKI/Router Protocol) to Proposed Standard
In-Reply-To: <20120128050229.98A9717711@thrintun.hactrn.net>
References:   <20120128050229.98A9717711@thrintun.hactrn.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jan 2012 06:53:44 -0000

Hi Rob,
At 21:02 27-01-2012, Rob Austein wrote:
>You are certainly entitled to your opinion, but it comes a bit late.
>This work was done in the public view, with regular progress reports
>to the SIDR WG, and we have multiple interoperable implementations
>including several of the major router vendors.  So, with all due
>respect, I don't think the folks who have put work into this will be
>all that interested in abandoning running code at this point.

I should have guessed that the above argument would be used. :-)  It 
is somewhat unfortunate that Huawei did not get the opportunity to 
send Last Call comments as Cisco Systems and Juniper Networks Inc did.

With all due respect, I have to object to the argument of "comes a 
bit late" or "work was done in the public view" as reviews end up 
being a waste of time then.  I don't think that is what you meant.  I 
don't think that my position materially affects your draft at the moment.

>Monkey-in-the-middle is a common non-sexist variant of this term.
>Welcome to the 21st century.

I suggest using the "sexist" variant.  It's a well-known term and it 
is commonly used in RFCs.  If the SIDR Working Group consensus is to 
be extremely politically correct (Section 3.2 of RFC 4041), I suggest 
using "carbon-based-lifeform-in-the-middle".

>The basic problem is that the implementers and the IETF live on
>different planets.  As discussed in section 7, it is pretty much
>impossible to find any channel security technology which is
>implemented on conventional servers (Linux, BSD, ...), is implemented
>on routers, and is acceptable to the IETF security folks.

If I use this argument in future, I'll add you in the credits.

Hats off for the arguments. :-)

Regards,
-sm 


From tglassey@earthlink.net  Sun Jan 29 04:57:27 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3AA21F84E2 for ; Sun, 29 Jan 2012 04:57:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.174
X-Spam-Level: 
X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=-1.064, BAYES_05=-1.11]
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 xO416vqoWeFJ for ; Sun, 29 Jan 2012 04:57:26 -0800 (PST)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id AAB0221F84A6 for ; Sun, 29 Jan 2012 04:57:26 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=qSp7UqYOpvm1lSD8zDCWH0/dA0KTHirybBy5kJXvc3+5LsqQr40Oj4iOyjoG6kNW; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Opacus-Archived:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [67.180.133.66] (helo=[192.168.1.100]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RrUJx-0006vs-PO for ietf@ietf.org; Sun, 29 Jan 2012 07:57:25 -0500
Message-ID: <4F254233.9020409@earthlink.net>
Date: Sun, 29 Jan 2012 04:57:23 -0800
From: todd glassey 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: IETF Discussion Mailing List 
Subject: Commentary about IETF protocols which do not provide IP protection in their use.
X-Opacus-Archived: none
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7986923ef3734602e571d4397897ea7c69350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 67.180.133.66
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jan 2012 12:57:27 -0000

Today virtually no IETF protocols take into account US or any other
countries copyright laws with regard to Internet based content. Content
like domain names, DNS events, and BGP4 routes are also in addition to
the obvious publication events like a websites content, are in fact also
IP impinged.

So the question is what happens when a priority provide with a peering
relationship claims (c) against a set of Internet Routes... it is coming
I think.

That said - I am proposing that there is a need to figure out now with
regard to IETF projects whether the content flowing through the
technology will have legal impact attached to it and in those instances
provide the  proper information management and IP noticing controls.

Yes I am very sure this annoys the anarchists and anti-intellectual
property people here and you folks have done a great job up until now,
except you have failed to change the world. That said - the win hear is
in not fighting in changing the laws by going to war with the
superpowers - they will just hire technologists to replace us as a class
and much sooner than you think too...

If we don't put both proper IP controls into our processes and into the
actual work product so that its use can also respect the same laws we
built the IP to operate under the Government's trying to enforce those
laws will make official changes in who represents their interest in the
IETF and what effect the IETF has on there routing.

What I am telling you is that ISOC has no where near enough power to
protect the IETF from IP fraud complaints at a national level. And if
they were stupid enough to try - which they might, it would be
catastrophic. My take is formal pull out of the DNS Root because all of
the peering contracts say nothing about whose root must be used. Its
that simple. Governments will tell foreign carriers that their route
copyrights are now enforceable and that's it. If the carriers want to
serve in that country they will pay.

This is serious stuff. The world Internet is changing - the wild west is
dying out, and accountable at the content level is happening today.
Rather than trying to stop that we need to make it possible for our
masters to meet their goals through our work or we need to make public
disclosure who's goals as individuals we serve.

Disclosure is key - and disclose everywhere. No vapor - no vacuum no lies.

Todd

-- 
Todd S. Glassey
This is from my personal email account and any materials from this
account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.

From vinayakh@gmail.com  Sun Jan 29 06:34:04 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20CF21F84A3 for ; Sun, 29 Jan 2012 06:34:04 -0800 (PST)
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 Pd5PFZRlxiTC for ; Sun, 29 Jan 2012 06:34:03 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD2C821F8493 for ; Sun, 29 Jan 2012 06:34:03 -0800 (PST)
Received: by vbbfr13 with SMTP id fr13so2370658vbb.31 for ; Sun, 29 Jan 2012 06:34:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wEDFCq6tumx1iSp+uERPz5iBfS1l63dyxxOLV8vQkPo=; b=JF3I5/LOMX5PwUUr3f+Mfj06YT1Jo698lv4640HDsOuekBXLSkEEW7pY2Irx52//v0 jzeqDMATXOYBbyD6atdcQEDGl+cHC8s4z0C/OVBbrx0YV8cbYJvIyOiutmaaplNp+Lwh uqvLZfvgUWifWgk+IjCiDJ69LAIZ4dKdMCydA=
MIME-Version: 1.0
Received: by 10.52.94.75 with SMTP id da11mr6230846vdb.111.1327847641444; Sun, 29 Jan 2012 06:34:01 -0800 (PST)
Received: by 10.52.184.197 with HTTP; Sun, 29 Jan 2012 06:34:01 -0800 (PST)
In-Reply-To: <4F254233.9020409@earthlink.net>
References: <4F254233.9020409@earthlink.net>
Date: Sun, 29 Jan 2012 20:04:01 +0530
Message-ID: 
Subject: Re: Commentary about IETF protocols which do not provide IP protection in their use.
From: Vinayak Hegde 
To: todd glassey 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: IETF Discussion Mailing List 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jan 2012 14:34:04 -0000

On Sun, Jan 29, 2012 at 6:27 PM, todd glassey  wrot=
e:
> Today virtually no IETF protocols take into account US or any other
> countries copyright laws with regard to Internet based content. Content
> like domain names, DNS events, and BGP4 routes are also in addition to
> the obvious publication events like a websites content, are in fact also
> IP impinged.

I think it is bad to integrate copyright policy into protocols. for
example how do you take into account if submarine cables transit into
territorial waters of another country are the countries copyright
policies to be applied to the content if so how ?

Also please do not club everything - Trademarks, Copyright and patents
under the same umbrella. They are very different things. Please read
http://www.gnu.org/philosophy/not-ipr.html for more information.

> So the question is what happens when a priority provide with a peering
> relationship claims (c) against a set of Internet Routes... it is coming
> I think.
>
> That said - I am proposing that there is a need to figure out now with
> regard to IETF projects whether the content flowing through the
> technology will have legal impact attached to it and in those instances
> provide the =A0proper information management and IP noticing controls.
>
> Yes I am very sure this annoys the anarchists and anti-intellectual
> property people here and you folks have done a great job up until now,
> except you have failed to change the world. That said - the win hear is
> in not fighting in changing the laws by going to war with the
> superpowers - they will just hire technologists to replace us as a class
> and much sooner than you think too...

Who is they ?

> If we don't put both proper IP controls into our processes and into the
> actual work product so that its use can also respect the same laws we
> built the IP to operate under the Government's trying to enforce those
> laws will make official changes in who represents their interest in the
> IETF and what effect the IETF has on there routing.

IETF has processes in place for patenst More reading:
See the work of the IPR group.
http://tools.ietf.org/wg/ipr/

For example see http://tools.ietf.org/html/rfc3669 - RFC 3669

> What I am telling you is that ISOC has no where near enough power to
> protect the IETF from IP fraud complaints at a national level. And if
> they were stupid enough to try - which they might, it would be
> catastrophic. My take is formal pull out of the DNS Root because all of
> the peering contracts say nothing about whose root must be used. Its
> that simple. Governments will tell foreign carriers that their route
> copyrights are now enforceable and that's it. If the carriers want to
> serve in that country they will pay.
>
> This is serious stuff. The world Internet is changing - the wild west is
> dying out, and accountable at the content level is happening today.
> Rather than trying to stop that we need to make it possible for our
> masters to meet their goals through our work or we need to make public
> disclosure who's goals as individuals we serve.

Who are our master here ? There are people working for governments,
commercial enterprises and self-employed on this lists. I think
generalisation of their agendas is not possible. Can you please
qualify your statements ?

> Disclosure is key - and disclose everywhere. No vapor - no vacuum no lies=
.

Please read the links above.

-- Vinayak

From ron.even.tlv@gmail.com  Sun Jan 29 08:16:11 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5205F21F85D6; Sun, 29 Jan 2012 08:16:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level: 
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300,  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 kPtOC54Jfx01; Sun, 29 Jan 2012 08:16:10 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99C9021F84F2; Sun, 29 Jan 2012 08:16:09 -0800 (PST)
Received: by eekc1 with SMTP id c1so1120922eek.31 for ; Sun, 29 Jan 2012 08:16:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=WYSormq6lbpbsacTzXyCb3cOnSeGC6kaptnshZSRJiU=; b=gZEcKQS6Qp/Zg7RnM67lUwEiJPER5gUaI6oUq4u+7X9D+j1ZpYEIGIMEq18txuqJX8 DY/GL7kqwecwjy+KoY9qVy3g9XcRWrxf3cH3OXdFe0PcMh7jTgcTV4mpnzlqL1o2hiii X6aFCnbRyYuLT0LrFtdCsAjHCsKCSUt7e7vQM=
Received: by 10.14.4.85 with SMTP id 61mr4565711eei.58.1327853768783; Sun, 29 Jan 2012 08:16:08 -0800 (PST)
Received: from windows8d787f9 (bzq-109-67-208-29.red.bezeqint.net. [109.67.208.29]) by mx.google.com with ESMTPS id n17sm60281363eei.3.2012.01.29.08.16.05 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jan 2012 08:16:06 -0800 (PST)
From: "Roni Even" 
To: 
Subject: Gen-ART LC review of draft-ietf-dnsext-ecdsa-04
Date: Sun, 29 Jan 2012 18:12:17 +0200
Message-ID: <4f2570c6.11840e0a.6db6.09c6@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CCDEB1.8A43D260"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AczeoMS8V6J8c6/bTomW2ZcdP/nCOw==
Content-Language: en-us
Cc: gen-art@ietf.org, 'IETF-Discussion list' 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jan 2012 16:16:11 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01CCDEB1.8A43D260
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
.

Please resolve these comments along with any other Last Call comments you
may receive.

 

Document: draft-ietf-dnsext-ecdsa-04

Reviewer: Roni Even

Review Date:2012-1-29

IETF LC End Date: 2012-2-7

IESG Telechat date:

 

Summary: This draft is almost ready for publication as an Informational RFC.

 

Major issues:

 

The first IANA action is to update
http://www.iana.org/assignments/ds-rr-types/ds-rr-types.txt which requires
standard action for adding values.

 

 

Minor issues:

The important note in section 6 talks about the values in the examples. I am
wondering why not update the document with the correct values after the IANA
assignments by the RFC editor.

 

Nits/editorial comments:

 

 


------=_NextPart_000_0001_01CCDEB1.8A43D260
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


      I am the =
assigned Gen-ART reviewer for this draft. For background on Gen-ART, =
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq=
>.
      Please resolve these =
comments along with any other Last Call comments you may =
receive.
       =

      Document: =
draft-ietf-=
dnsext-ecdsa-04
      Reviewer: =
Roni Even
      Review =
Date:2012–1–29
      IETF LC =
End Date: 2012–2–7
      IESG =
Telechat date:
       =

      Summary: =
This draft is almost ready for publication as an Information=
al RFC.
       =

      Major =
issues:
       =

      The first =
IANA action is to update http=
://www.iana.org/assignments/ds-rr-types/ds-rr-types.txt which =
requires standard action for adding values.=

       =

       =

      Minor =
issues:
      The =
important note in section 6 talks about the values in the examples. I am =
wondering why not update the document with the correct values after the =
IANA assignments by the RFC editor.
       =

      Nits/editor=
ial comments:
       =

       
      
------=_NextPart_000_0001_01CCDEB1.8A43D260--


From sm@resistor.net  Sun Jan 29 08:18:25 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B1C21F84FB for ; Sun, 29 Jan 2012 08:18:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.61
X-Spam-Level: 
X-Spam-Status: No, score=-102.61 tagged_above=-999 required=5 tests=[AWL=-0.011, 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 1q3ORxO9Zg8m for ; Sun, 29 Jan 2012 08:18:23 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E6021F84FA for ; Sun, 29 Jan 2012 08:18:23 -0800 (PST)
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 q0TGIHsN019041 for ; Sun, 29 Jan 2012 08:18:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1327853901; i=@resistor.net; bh=OV1Yhx4VKAToOafVaU57VSJ1vgfyN3Spls0GwrmnL0A=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=aBFX9AYhx5nvzE+xcWBLz5UrmAk7BL/Gte99MQU58Ec37u16wy0/XsV4CE1JX0aoN 9VDN3SKhUdvhNDZR1xrNmrdpBM6TdVW2Z128op5bna/mEjH8BpPG2FHzj8Y6MES+lJ 0vahM2fJIY4I8PSnAtb3+FKwLjetARDDOgGX2qV4=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1327853901; i=@resistor.net; bh=OV1Yhx4VKAToOafVaU57VSJ1vgfyN3Spls0GwrmnL0A=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=BUtAvBl/kY5hANMQ9FIZeeN96Cp1npXYKqGsip5axtW1Drde2eN4Fci1sPwsCTfba bQa3cDQUuFzDyAtzMI/ktiVwcKkER6xhgPABRd23M4kYL0+rCOqlQuuGM+C9TM6d7W HR7hExtde/tv+cmWQTjZasQ/Y4XiaIq+uo82PBX0=
Message-Id: <6.2.5.6.2.20120129014535.09e25c28@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 29 Jan 2012 07:42:56 -0800
To: ietf@ietf.org
From: SM 
Subject: Re: Last Call:  (The RPKI/Router Protocol) to Proposed Standard
In-Reply-To: <20120128050229.98A9717711@thrintun.hactrn.net>
References:   <20120128050229.98A9717711@thrintun.hactrn.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jan 2012 16:18:25 -0000

Hello,

I received a comment about the following comment I made previously ( 
http://www.ietf.org/mail-archive/web/ietf/current/msg71561.html ):

   "It is somewhat unfortunate that Huawei did not get the opportunity to
    send Last Call comments as Cisco Systems and Juniper Networks Inc did."

There is a message posted on behalf of Juniper Networks Inc at 
http://www.ietf.org/mail-archive/web/ietf/current/msg71186.html

There is a message posted on behalf of Cisco Systems at 
http://www.ietf.org/mail-archive/web/ietf/current/msg71192.html

In my opinion the opportunity for the IETF Last Call to be turned 
into a solicitation for *company* support did not last long.

Regards,
-sm


From alexey.melnikov@isode.com  Sun Jan 29 08:38:04 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB1B21F84DF; Sun, 29 Jan 2012 08:38:04 -0800 (PST)
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 xplDmnZa7p+t; Sun, 29 Jan 2012 08:38:03 -0800 (PST)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1677C21F84E6; Sun, 29 Jan 2012 08:38:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1327855081; d=isode.com; s=selector; i=@isode.com; bh=2hS2GFyX98c6SaJMNY1/b74IIXoTxIZDxSbheb8Xvz4=; 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=waJ//w4ideY1RfhPuGb8vQihJfe7LgXKql5Oaei6k7s9QHOcZR2oQN+OPZivBUSnDL11eI OjTv+atLhdFchcbdcNQcoLd1byBPIXH88c/6QEyNg9y1V2s/6dvZ0EJOa523FYuMvu71KN gazNeZUwL53p9EZaVHQTBLKx03JS/SY=;
Received: from [188.29.114.61] (188.29.114.61.threembb.co.uk [188.29.114.61])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Sun, 29 Jan 2012 16:37:55 +0000
Message-ID: <4F2575CE.9040001@isode.com>
Date: Sun, 29 Jan 2012 16:37:34 +0000
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
To: General Area Review Team , IETF-Discussion Discussion , draft-ietf-oauth-v2-bearer.all@tools.ietf.org
Subject: Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jan 2012 16:38:04 -0000

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
.

Please resolve these comments along with any other Last Call comments 
you may receive.

Document: draft-ietf-oauth-v2-bearer-15.txt
Reviewer: Alexey Melnikov
Review Date: 29 Jan 2012
IETF LC End Date: 7 Feb 2012
IESG Telechat date: (if known) -

Summary: Mostly ready, with a couple of things that should be addressed.

Major Issues:

I have 2 issues in section 3:

3.  The WWW-Authenticate Response Header Field

    If the protected resource request does not include authentication
    credentials or does not contain an access token that enables access
    to the protected resource, the resource server MUST include the HTTP
    "WWW-Authenticate" response header field; it MAY include it in
    response to other conditions as well.  The "WWW-Authenticate" header
    field uses the framework defined by HTTP/1.1, Part 7
    [I-D.ietf-httpbis-p7-auth] as follows:

    challenge       = "Bearer" [ 1*SP 1#param ]

    param           = realm / scope /
                      error / error-desc / error-uri /
                      auth-param

    scope           = "scope" "=" quoted-string
    error           = "error" "=" quoted-string
    error-desc      = "error_description" "=" quoted-string
    error-uri       = "error_uri" "=" quoted-string

1). I am agreeing with Julian about redefinition of ABNF from HTTPBis 
documents. I believe there is a proposal to fix that but the new draft 
hasn't been posted yet.

2). My 2nd major issue is about the following paragraph:

    The "scope" attribute is a space-delimited list of scope values
    indicating the required scope of the access token for accessing the
    requested resource.  In some cases, the "scope" value will be used
    when requesting a new access token with sufficient scope of access to
    utilize the protected resource.  The "scope" attribute MUST NOT
    appear more than once.  The "scope" value is intended for
    programmatic use and is not meant to be displayed to end users.

I don't think this provide enough information about what this is,
how it is to be used and which values are allowed. As this is not meant 
to be displayed to end users, then you need to say what values are 
allowed and which entity can allocate them. Is there a registry for 
these tokens, e.g. an IANA registry?


Minor Issues:

1).
2.2.  Form-Encoded Body Parameter

    When sending the access token in the HTTP request entity-body, the
    client adds the access token to the request body using the
    "access_token" parameter.  The client MUST NOT use this method unless
    all of the following conditions are met:

    o  The HTTP request entity-body is single-part.

    o  The entity-body follows the encoding requirements of the
       "application/x-www-form-urlencoded" content-type as defined by
       HTML 4.01 [W3C.REC-html401-19991224].

    o  The HTTP request entity-header includes the "Content-Type" header
       field set to "application/x-www-form-urlencoded".

I would combine the first and the third bullet into a single statement,
because they seem to be a bit confusing while being read separately.
(I.e., is it possible to have Content-Type of 
"application/x-www-form-urlencoded" with something which is multipart?)

2).
Section "3.1.  Error Codes"

I recommend creating an IANA registry for these or explain why one is 
not needed.

3).
4.2.  Threat Mitigation

    To protect against token disclosure, confidentiality protection MUST
    be applied using TLS [RFC5246] with a ciphersuite that provides
    confidentiality and integrity protection.  This requires that the
    communication interaction between the client and the authorization
    server, as well as the interaction between the client and the
    resource server, utilize confidentiality and integrity protection.
    Since TLS is mandatory to implement and to use with this
    specification, it is the preferred approach for preventing token
    disclosure via the communication channel.  For those cases where the
    client is prevented from observing the contents of the token, token
    encryption MUST be applied in addition to the usage of TLS
    protection.  As a further defense against token disclosure, the
    client MUST validate the TLS certificate chain when making requests
    to protected resources.

and

    To deal with token capture and replay, the following recommendations
    are made: First, the lifetime of the token MUST be limited; one means
    of achieving this is by putting a validity time field inside the
    protected part of the token.  Note that using short-lived (one hour
    or less) tokens reduces the impact of them being leaked.  Second,
    confidentiality protection of the exchanges between the client and
    the authorization server and between the client and the resource
    server MUST be applied.  As a consequence, no eavesdropper along the
    communication path is able to observe the token exchange.
    Consequently, such an on-path adversary cannot replay the token.
    Furthermore, when presenting the token to a resource server, the
    client MUST verify the identity of that resource server, as per
    Representation and Verification of Domain-Based Application Service
    Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
    Certificates in the Context of Transport Layer Security (TLS)
    [RFC6125].

Firstly, I would move the RFC 6125 reference to the first paragraph 
quoted above (but see below). Secondly, you should either normatively 
reference RFC 2818 (HTTP over TLS) instead of RFC 6125, or you need to 
provide more information about how RFC 6125 is to be used, because it 
has several options which need to be described (use of SRV-IDs, URI-IDs, 
DNS-IDs, use of wildcards). I suspect you should just reference RFC 2818.


Nits:

2.2.  Form-Encoded Body Parameter

    o  The content to be encoded in the entity-body MUST consist entirely
       of ASCII characters.

ASCII needs a reference.


ID-nits reports:

   == The document seems to lack the recommended RFC 2119 boilerplate, 
even if
      it appears to use RFC 2119 keywords -- however, there's a 
paragraph with
      a matching beginning. Boilerplate error?

      (The document does seem to have the reference to RFC 2119 which the
      ID-Checklist requires).
   == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 
'SHOULD',
      or 'RECOMMENDED' is not an accepted usage according to RFC 2119. 
Please
      use uppercase 'NOT' together with RFC 2119 keywords (if that is 
what you
      mean).

and:

      Found 'MUST not' in this paragraph:

      o  Stated that bearer tokens MUST not be stored in cookies that can
      be sent in the clear in the Threat Mitigation section.

From mnot@mnot.net  Sun Jan 29 15:50:10 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B14D21F84F2; Sun, 29 Jan 2012 15:50:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.021
X-Spam-Level: 
X-Spam-Status: No, score=-105.021 tagged_above=-999 required=5 tests=[AWL=-2.422, 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 bwrCu5iXCRxg; Sun, 29 Jan 2012 15:50:09 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id C71CC21F84DE; Sun, 29 Jan 2012 15:50:07 -0800 (PST)
Received: from mnot-mini.mnot.net (unknown [118.209.240.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6D3D822E247; Sun, 29 Jan 2012 18:50:05 -0500 (EST)
Subject: Re: secdir review of draft-nottingham-http-new-status-03
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Mark Nottingham 
In-Reply-To: 
Date: Mon, 30 Jan 2012 10:50:02 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0EEB0CDF-6D05-4EA7-9244-CA80C03BD11D@mnot.net>
References:  <4F109383.1090505@gmx.de>  
To: Stephen Hanna 
X-Mailer: Apple Mail (2.1251.1)
Cc: Julian Reschke , "draft-nottingham-http-new-status@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jan 2012 23:50:10 -0000

I haven't heard any further response. After a reminder from a Security =
AD, I took another look at the spec.

E.g., the current Security Considerations for 428:

> The 428 status code is optional; clients cannot rely upon its use to =
prevent "lost update" conflicts.

Like many of the status codes, that's already a risk inherent in using =
HTTP today; we're effectively just noting that we can't force =
implementations to use the new status code retroactively, so they can't =
use the publication of this document as a magical flag day.

As such, not much more can be said; the only way that people can further =
mitigate the risks of lost updates is to have a private, out-of-band =
agreement to use 429, and I *don't* think that's something we should be =
encouraging.=20

For 429, I've changed to:

> When a server is under attack or just receiving a very large number of =
requests from a single party, responding to each with a 429 status code =
will consume resources.
>=20
> Therefore, servers are not required to use the 429 status code; when =
limiting resource usage, it may be more appropriate to just drop =
connections, or take other steps.


431 says:

> Servers are not required to use the 431 status code; when under =
attack, it may be more appropriate to just drop connections, or take =
other steps.


What else should be said here? This specification is not a treatise on =
dealing with denial-of-service attacks; all that it notes is that =
servers aren't required to use the status code.

Finally, 511 says:

> In common use, a response carrying the 511 status code will not come =
from the origin server indicated in the request's URL. This presents =
many security issues; e.g., an attacking intermediary may be inserting =
cookies into the original domain's name space, may be observing cookies =
or HTTP authentication credentials sent from the user agent, and so on. =
However, these risks are not unique to the 511 status code; in other =
words, a captive portal that is not using this status code introduces =
the same issues.=20

Are there other specific threats you're aware of here?=20

Regards,



On 25/01/2012, at 10:36 AM, Mark Nottingham wrote:

> Sorry for the delay in responding; just back from holiday.
>=20
>=20
> On 14/01/2012, at 8:26 AM, Stephen Hanna wrote:
>=20
>> Julian,
>>=20
>> I'm sure that in your view one sentence is adequate to explain
>> all the security implications of each status code. However,
>> you may want to consider that some readers may not have quite
>> the same deep grasp of the matter that you do. Therefore,
>> I think it would be wise to provide more explanation. Here's an
>> example for section 7.2 on status code 429 (Too Many Requests):
>>=20
>> Section 7.2  429 Too Many Requests
>>=20
>>  While status code 429 can be helpful in figuring out why a
>>  server is not responding to requests, it can also be harmful.
>>  When a server is under attack or simply receiving a very
>>  large number of requests from a single party, responding
>>  to each of these requests with a 429 status code will consume
>>  resources that could be better used in other ways. Therefore,
>>  a server in such circumstances may choose to send a 429 status
>>  code only the first time a client exceeds its limit and
>>  ignore subsequent requests from this client until its limit
>>  is no longer exceeded. Other approaches may also be employed.
>>=20
>> As you can see, I described security problems that could occur
>> with this status code and explained how those problems can be
>> avoided or mitigated. While it's true that these problems
>> could occur when a more generic status code is used to handle
>> the case of "too many requests", that does not mean that they
>> are not relevant to this document. On the contrary, the fact
>> that this document is providing more detailed status codes
>> gives us the opportunity and one can argue the obligation to
>> provide more detailed security analysis relevant to these more
>> detailed status codes.
>=20
> I'm really not sure I agree; the original text is:
>=20
>   Servers are not required to use the 429 status code; when
>   limiting resource usage, it may be more appropriate to just drop
>   connections, or take other steps.
>=20
> If someone implementing a server doesn't understand that, I don't know =
that using more words really helps; it does, however, make it harder to =
find the words in the spec that *will* help.
>=20
>=20
> --
> Mark Nottingham   http://www.mnot.net/
>=20
>=20
>=20

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




From Michael.Jones@microsoft.com  Sun Jan 29 21:20:32 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9123921F855B; Sun, 29 Jan 2012 21:20:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.763
X-Spam-Level: 
X-Spam-Status: No, score=-3.763 tagged_above=-999 required=5 tests=[AWL=-0.164, 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 uWJFu+xa3LyS; Sun, 29 Jan 2012 21:20:31 -0800 (PST)
Received: from DB3EHSOBE006.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBAF21F8470; Sun, 29 Jan 2012 21:20:24 -0800 (PST)
Received: from mail35-db3-R.bigfish.com (10.3.81.234) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 30 Jan 2012 05:20:23 +0000
Received: from mail35-db3 (localhost [127.0.0.1])	by mail35-db3-R.bigfish.com (Postfix) with ESMTP id 116573C038A; Mon, 30 Jan 2012 05:20:23 +0000 (UTC)
X-SpamScore: -35
X-BigFish: VS-35(zz9371I542Mc1dM111aLzz1202hzz1033IL8275dhz2fhc1bhc31hc1ah2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail35-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail35-db3 (localhost.localdomain [127.0.0.1]) by mail35-db3 (MessageSwitch) id 1327900821603647_29556; Mon, 30 Jan 2012 05:20:21 +0000 (UTC)
Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.236])	by mail35-db3.bigfish.com (Postfix) with ESMTP id 8EFD1220045; Mon, 30 Jan 2012 05:20:21 +0000 (UTC)
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 30 Jan 2012 05:20:20 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0247.005; Sun, 29 Jan 2012 21:20:16 -0800
From: Mike Jones 
To: Alexey Melnikov , "oauth@ietf.org" , General Area Review Team , IETF-Discussion Discussion , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" 
Subject: RE: Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt
Thread-Topic: Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt
Thread-Index: AQHM3qRqPCVQxATPKE+KKj7te0rjepYkPTlg
Date: Mon, 30 Jan 2012 05:20:15 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <4F2575CE.9040001@isode.com>
In-Reply-To: <4F2575CE.9040001@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.36]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 05:20:32 -0000

Thanks for your useful feedback, Alexey.  Below, I'll respond to each of yo=
ur comments.  I've also added the OAuth working group to the thread, so the=
y are aware of them as well and can participate in the discussion.

About your first issue with the WWW-Authenticate ABNF, I am already working=
 with Julian, Mark Nottingham, and the chairs to resolve this issue.  Expec=
t to see a proposal for review by the working group shortly.

About your comments on scope:  OAuth 2.0 (both the Core and Bearer specs) i=
s designed to be deployed in diverse and non-interoperable application cont=
exts, meeting a variety of application needs.  In those various settings, w=
hich are often distinct and potentially non-interoperable, parameters such =
as scope, realm, etc. may have very different meanings.  This is not a bug;=
 it is a feature, because it allows the OAuth pattern to meet the needs of =
numerous, often distinct, application environments.  For that reason, a reg=
istry of scope (or realm) parameters would be ill-advised and counterproduc=
tive.  It's perfectly OK and expected for a scope value such as "email" to =
have one meaning in one application context and a different meaning in a di=
fferent, but distinct application context.  Trying to impose a single meani=
ng on particular scope values across distinct application contexts is both =
unnecessary and could break many existing deployments.  That being said, we=
 fully expect interoperability profiles to emerge that define interoperable=
 sets of scope values within particular application contexts.  (The OpenID =
Connect specifications are one such set of profiles.)  But these meanings w=
ill always be context-specific - not global in scope.

About your first minor issue, I'll reorder the bullets so the statement abo=
ut the entity-body being single part is followed by the statement about it =
using application/x-www-form-urlencoded, so they will be read together.

About your second minor issue on error codes, the error codes registry alre=
ady exists, but is in the OAuth Core spec.  See http://tools.ietf.org/html/=
draft-ietf-oauth-v2-23#section-11.4.

About your third minor issue on RFC 6125 versus RFC 2818, you'll find that,=
 per the history entries, a previous reference to RFC 2818 was changed to R=
FC 6125 in draft 14 at the request of Security Area Director Stephen Farrel=
l.  If you'd like to see this reference reintroduced, I'd request that you =
work with Stephen on specific alternative proposed wording that is acceptab=
le to both of you.

Finally, I'll address both of your nits in the manner you suggested.

				Thanks again,
				-- Mike

-----Original Message-----
From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Ale=
xey Melnikov
Sent: Sunday, January 29, 2012 8:38 AM
To: General Area Review Team; IETF-Discussion Discussion; draft-ietf-oauth-=
v2-bearer.all@tools.ietf.org
Subject: Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt

I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR=
T, please see the FAQ at .

Please resolve these comments along with any other Last Call comments you m=
ay receive.

Document: draft-ietf-oauth-v2-bearer-15.txt
Reviewer: Alexey Melnikov
Review Date: 29 Jan 2012
IETF LC End Date: 7 Feb 2012
IESG Telechat date: (if known) -

Summary: Mostly ready, with a couple of things that should be addressed.

Major Issues:

I have 2 issues in section 3:

3.  The WWW-Authenticate Response Header Field

    If the protected resource request does not include authentication
    credentials or does not contain an access token that enables access
    to the protected resource, the resource server MUST include the HTTP
    "WWW-Authenticate" response header field; it MAY include it in
    response to other conditions as well.  The "WWW-Authenticate" header
    field uses the framework defined by HTTP/1.1, Part 7
    [I-D.ietf-httpbis-p7-auth] as follows:

    challenge       =3D "Bearer" [ 1*SP 1#param ]

    param           =3D realm / scope /
                      error / error-desc / error-uri /
                      auth-param

    scope           =3D "scope" "=3D" quoted-string
    error           =3D "error" "=3D" quoted-string
    error-desc      =3D "error_description" "=3D" quoted-string
    error-uri       =3D "error_uri" "=3D" quoted-string

1). I am agreeing with Julian about redefinition of ABNF from HTTPBis docum=
ents. I believe there is a proposal to fix that but the new draft hasn't be=
en posted yet.

2). My 2nd major issue is about the following paragraph:

    The "scope" attribute is a space-delimited list of scope values
    indicating the required scope of the access token for accessing the
    requested resource.  In some cases, the "scope" value will be used
    when requesting a new access token with sufficient scope of access to
    utilize the protected resource.  The "scope" attribute MUST NOT
    appear more than once.  The "scope" value is intended for
    programmatic use and is not meant to be displayed to end users.

I don't think this provide enough information about what this is, how it is=
 to be used and which values are allowed. As this is not meant to be displa=
yed to end users, then you need to say what values are allowed and which en=
tity can allocate them. Is there a registry for these tokens, e.g. an IANA =
registry?


Minor Issues:

1).
2.2.  Form-Encoded Body Parameter

    When sending the access token in the HTTP request entity-body, the
    client adds the access token to the request body using the
    "access_token" parameter.  The client MUST NOT use this method unless
    all of the following conditions are met:

    o  The HTTP request entity-body is single-part.

    o  The entity-body follows the encoding requirements of the
       "application/x-www-form-urlencoded" content-type as defined by
       HTML 4.01 [W3C.REC-html401-19991224].

    o  The HTTP request entity-header includes the "Content-Type" header
       field set to "application/x-www-form-urlencoded".

I would combine the first and the third bullet into a single statement, bec=
ause they seem to be a bit confusing while being read separately.
(I.e., is it possible to have Content-Type of "application/x-www-form-urlen=
coded" with something which is multipart?)

2).
Section "3.1.  Error Codes"

I recommend creating an IANA registry for these or explain why one is not n=
eeded.

3).
4.2.  Threat Mitigation

    To protect against token disclosure, confidentiality protection MUST
    be applied using TLS [RFC5246] with a ciphersuite that provides
    confidentiality and integrity protection.  This requires that the
    communication interaction between the client and the authorization
    server, as well as the interaction between the client and the
    resource server, utilize confidentiality and integrity protection.
    Since TLS is mandatory to implement and to use with this
    specification, it is the preferred approach for preventing token
    disclosure via the communication channel.  For those cases where the
    client is prevented from observing the contents of the token, token
    encryption MUST be applied in addition to the usage of TLS
    protection.  As a further defense against token disclosure, the
    client MUST validate the TLS certificate chain when making requests
    to protected resources.

and

    To deal with token capture and replay, the following recommendations
    are made: First, the lifetime of the token MUST be limited; one means
    of achieving this is by putting a validity time field inside the
    protected part of the token.  Note that using short-lived (one hour
    or less) tokens reduces the impact of them being leaked.  Second,
    confidentiality protection of the exchanges between the client and
    the authorization server and between the client and the resource
    server MUST be applied.  As a consequence, no eavesdropper along the
    communication path is able to observe the token exchange.
    Consequently, such an on-path adversary cannot replay the token.
    Furthermore, when presenting the token to a resource server, the
    client MUST verify the identity of that resource server, as per
    Representation and Verification of Domain-Based Application Service
    Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
    Certificates in the Context of Transport Layer Security (TLS)
    [RFC6125].

Firstly, I would move the RFC 6125 reference to the first paragraph quoted =
above (but see below). Secondly, you should either normatively reference RF=
C 2818 (HTTP over TLS) instead of RFC 6125, or you need to provide more inf=
ormation about how RFC 6125 is to be used, because it has several options w=
hich need to be described (use of SRV-IDs, URI-IDs, DNS-IDs, use of wildcar=
ds). I suspect you should just reference RFC 2818.


Nits:

2.2.  Form-Encoded Body Parameter

    o  The content to be encoded in the entity-body MUST consist entirely
       of ASCII characters.

ASCII needs a reference.


ID-nits reports:

   =3D=3D The document seems to lack the recommended RFC 2119 boilerplate, =
even if
      it appears to use RFC 2119 keywords -- however, there's a paragraph w=
ith
      a matching beginning. Boilerplate error?

      (The document does seem to have the reference to RFC 2119 which the
      ID-Checklist requires).
   =3D=3D Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'S=
HOULD',
      or 'RECOMMENDED' is not an accepted usage according to RFC 2119.=20
Please
      use uppercase 'NOT' together with RFC 2119 keywords (if that is what =
you
      mean).

and:

      Found 'MUST not' in this paragraph:

      o  Stated that bearer tokens MUST not be stored in cookies that can
      be sent in the clear in the Threat Mitigation section.
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



From stefan.winter@restena.lu  Mon Jan 30 00:16:19 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AD621F860B; Mon, 30 Jan 2012 00:16:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.407
X-Spam-Level: 
X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192,  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 i8svGZ6h37oH; Mon, 30 Jan 2012 00:16:17 -0800 (PST)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 5C53121F85B4; Mon, 30 Jan 2012 00:16:17 -0800 (PST)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 920F710584; Mon, 30 Jan 2012 09:16:16 +0100 (CET)
Received: from [IPv6:2001:a18:1:8:2d20:ef00:5856:5dcc] (unknown [IPv6:2001:a18:1:8:2d20:ef00:5856:5dcc]) by smtprelay.restena.lu (Postfix) with ESMTPS id 8766410581; Mon, 30 Jan 2012 09:16:16 +0100 (CET)
Message-ID: <4F2651CC.2030406@restena.lu>
Date: Mon, 30 Jan 2012 09:16:12 +0100
From: Stefan Winter 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: radext@ietf.org
Subject: Re: [radext] Security review of draft-ietf-radext-radsec
References: 
In-Reply-To: 
X-Enigmail-Version: 1.3.5
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA734C262E16C49F78C0C72F7"
X-Virus-Scanned: ClamAV
Cc: ietf@ietf.org, secdir@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 08:16:19 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA734C262E16C49F78C0C72F7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

> Hi.  I'm not the secdir reviewer assigned to this draft, but felt that
> this draft needed additional security review, so I decided to perform a=

> secdir-like review.
>=20
> Overall, I think this is a much-needed specification and believe it is
> mostly ready for publication as an experimental RFC. I'd say a bit more=

> clarity would be required if we wanted to move this to the standards
> track.

Thanks for the review!

> General issues:
>=20
> 1) I'm reasonably sure that RADSEC MUST NOT be used with TLS versions
> prior to 1.1. The concern I have is that RADSEC has long-lived TLS
> connections under which an attacker could potentially observe ciphertex=
t
> generated from some plaintext before sending additional plaintext.  TLS=

> 1.1 includes explicit IVs that prevent various attacks  that may happen=

> against earlier versions of TLS.
> There are implementation work arounds that can also prevent these
> attacks. However since all RADSEC implementations are required to
> support TLS 1.1, I'd prefer to add a requirement that RADSEC
> implementations MUST NOT negotiate TLS versions prior to 1.1 in order t=
o
> avoid this issue.

That's a very useful comment, thanks! TLS 1.1 was marked as
minimum-required to prevent these attacks (IIRC). But of course it might
happen that even though both sides *support* TLS 1.1, they don't
actually negotiate it.

I've added corresponding text in my working copy, which will become -12
soon:

       *  Support for TLS v1.1 [RFC4346] or later (e.g.  TLS 1.2
          [RFC5246] ]) is REQUIRED.  To prevent known attacks on TLS
          versions prior to 1.1, implementations MUST NOT negotiate TLS
          versions prior to 1.1.


> 2) Section 2.3 implies that you need to do cert validation all the time=
,
> even when you have a certificate fingerprint. I think it could more
> clearly indicate that multiple ways of figuring out if you have the
> right public key are provided.  It's also not clear to me from section
> 2.3 whether there is a mandatory-to-implement strategy. You SHOULD
> support cert fingerprints. You MUST support cert path validation, but i=
s
> there a required name form to support? There are discussions of several=

> name forms but none seem mandatory. I see no discussion of RFC 6125,
> which I would have expected to see here.  However, most of this is OK
> for an experimental spec.  This is the big area where I'd expect to see=

> more clarity before this could move to the standards track.

Agreed that there's a bit of an option bloat in the cert validation
sections, and that there should be more guidance for standards track if
the spec gets there.

There's one thing I'd like to fix for the current document though. It
was not really my intention to enforce e.g. 5280 checks when
fingerprint-based operation is in place. My role-model existing
deployment of fingerprint-based validation is SAML2 metadata. There, an
entity can get identified by its fingerprint alone; regardless of other
properties of the certificate (e.g. it doesn't matter whether the
certificate is expired, or what CA it comes from - so lang as the
configured fingerprint matches the incoming cert's fingerprint, it's fine=
).

In the SAML world, that mode of operation seems to be popular; I
wouldn't want to preclude that same model of operation here.

I'll reformulate that section to make clearer that PKIX-style cert
validation is one thing, and that manually configured fingerprints is
another (and TLS-PSK is yet another thing, of course). How about this:


   3.  Peer authentication can be performed in any of the following
       three operation models:

       *  TLS with X.509 certificates using PKIX trust models (this
          model is mandatory to implement):

          +  Implementations MUST allow to configure a list of trusted
             Certification Authorities for incoming connections.

          +  Certificate validation MUST include the verification rules
             as per [RFC5280].

          +  Implementations SHOULD indicate their trusted Certification
             Authorities as per section 7.4.4 (server side) and x.y.z
             ["Trusted CA Indication"] (client side) of [RFC5246] (see
             Section 3.2)

          +  Peer validation always includes a check on whether the
             locally configured expected DNS name or IP address of the
             server that is contacted matches its presented certificate.
             DNS names and IP addresses can be contained in the Common
             Name (CN) or subjectAltName entries.  For verification,
             only one of these entries is to be considered.  The
             following precedence applies: for DNS name validation,
             subjectAltName:DNS has precedence over CN; for IP address
             validation, subjectAltName:iPAddr has precedence over CN.

          +  Implementations SHOULD allow to configure a set of
             acceptable values for subjectAltName:URI.

       *  TLS with X.509 certificates using certificate fingerprints
          (this model is optional to implement): Implementations SHOULD
          allow to configure a list of trusted certificates, identified
          via certificate fingerprint.  Implementations MUST support
          SHA-1 as the hash algorithm.

       *  TLS using TLS-PSK (this model is optional to implement)

(note that some changed to this text might occur due to pending
DISCUSSes and COMMENTs in the IESG review).

Greetings,

Stefan Winter

>=20
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext


--=20
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National=
e et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473


--------------enigA734C262E16C49F78C0C72F7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8mUdAACgkQ+jm90f8eFWbIVQCeOrY9k9ajivBwl1gnMPhfTvcQ
FfkAn11WQGdvc6IVg02OSqIbO1/OeoXR
=XtZR
-----END PGP SIGNATURE-----

--------------enigA734C262E16C49F78C0C72F7--

From shanna@juniper.net  Mon Jan 30 07:07:17 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED4D21F84B4; Mon, 30 Jan 2012 07:07:17 -0800 (PST)
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 TxgN45vQng+P; Mon, 30 Jan 2012 07:07:16 -0800 (PST)
Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id B17C621F8656; Mon, 30 Jan 2012 07:07:03 -0800 (PST)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTyayF1mWRGpM48dvFicRe1F4qA/LCRJV@postini.com; Mon, 30 Jan 2012 07:07:15 PST
Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jan 2012 07:05:35 -0800
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 30 Jan 2012 10:05:34 -0500
From: Stephen Hanna 
To: Mark Nottingham 
Date: Mon, 30 Jan 2012 10:05:32 -0500
Subject: RE: secdir review of draft-nottingham-http-new-status-03
Thread-Topic: secdir review of draft-nottingham-http-new-status-03
Thread-Index: Acze4L0XIuPltSeBT2qfJxuKVa0I5AAfSypQ
Message-ID: 
References:  <4F109383.1090505@gmx.de>   <0EEB0CDF-6D05-4EA7-9244-CA80C03BD11D@mnot.net>
In-Reply-To: <0EEB0CDF-6D05-4EA7-9244-CA80C03BD11D@mnot.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629
Cc: Julian Reschke , "draft-nottingham-http-new-status@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 15:07:17 -0000

Mark,

I don't want to rehash the discussion that we've already had.
Clearly, you prefer brevity while I would prefer education in
this instance.

I can live with your text for status codes 428, 429, and 431. For
511, I don't think it's adequate to just say that big security
issues already exist. You should at least give some suggestions
for how to deal with them. For example, you could point out that
most user agents include some indication of whether the server
has been authenticated. For captive portals, this indication will
generally not be displayed so the user receives some warning
that the response did not come from the requested URL.

Thanks,

Steve

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: Sunday, January 29, 2012 6:50 PM
> To: Stephen Hanna
> Cc: Julian Reschke; draft-nottingham-http-new-status@tools.ietf.org;
> secdir@ietf.org; ietf@ietf.org
> Subject: Re: secdir review of draft-nottingham-http-new-status-03
>=20
> I haven't heard any further response. After a reminder from a Security
> AD, I took another look at the spec.
>=20
> E.g., the current Security Considerations for 428:
>=20
> > The 428 status code is optional; clients cannot rely upon its use to
> prevent "lost update" conflicts.
>=20
> Like many of the status codes, that's already a risk inherent in using
> HTTP today; we're effectively just noting that we can't force
> implementations to use the new status code retroactively, so they can't
> use the publication of this document as a magical flag day.
>=20
> As such, not much more can be said; the only way that people can
> further mitigate the risks of lost updates is to have a private, out-
> of-band agreement to use 429, and I *don't* think that's something we
> should be encouraging.
>=20
> For 429, I've changed to:
>=20
> > When a server is under attack or just receiving a very large number
> of requests from a single party, responding to each with a 429 status
> code will consume resources.
> >
> > Therefore, servers are not required to use the 429 status code; when
> limiting resource usage, it may be more appropriate to just drop
> connections, or take other steps.
>=20
>=20
> 431 says:
>=20
> > Servers are not required to use the 431 status code; when under
> attack, it may be more appropriate to just drop connections, or take
> other steps.
>=20
>=20
> What else should be said here? This specification is not a treatise on
> dealing with denial-of-service attacks; all that it notes is that
> servers aren't required to use the status code.
>=20
> Finally, 511 says:
>=20
> > In common use, a response carrying the 511 status code will not come
> from the origin server indicated in the request's URL. This presents
> many security issues; e.g., an attacking intermediary may be inserting
> cookies into the original domain's name space, may be observing cookies
> or HTTP authentication credentials sent from the user agent, and so on.
> However, these risks are not unique to the 511 status code; in other
> words, a captive portal that is not using this status code introduces
> the same issues.
>=20
> Are there other specific threats you're aware of here?
>=20
> Regards,
>=20
>=20
>=20
> On 25/01/2012, at 10:36 AM, Mark Nottingham wrote:
>=20
> > Sorry for the delay in responding; just back from holiday.
> >
> >
> > On 14/01/2012, at 8:26 AM, Stephen Hanna wrote:
> >
> >> Julian,
> >>
> >> I'm sure that in your view one sentence is adequate to explain
> >> all the security implications of each status code. However,
> >> you may want to consider that some readers may not have quite
> >> the same deep grasp of the matter that you do. Therefore,
> >> I think it would be wise to provide more explanation. Here's an
> >> example for section 7.2 on status code 429 (Too Many Requests):
> >>
> >> Section 7.2  429 Too Many Requests
> >>
> >>  While status code 429 can be helpful in figuring out why a
> >>  server is not responding to requests, it can also be harmful.
> >>  When a server is under attack or simply receiving a very
> >>  large number of requests from a single party, responding
> >>  to each of these requests with a 429 status code will consume
> >>  resources that could be better used in other ways. Therefore,
> >>  a server in such circumstances may choose to send a 429 status
> >>  code only the first time a client exceeds its limit and
> >>  ignore subsequent requests from this client until its limit
> >>  is no longer exceeded. Other approaches may also be employed.
> >>
> >> As you can see, I described security problems that could occur
> >> with this status code and explained how those problems can be
> >> avoided or mitigated. While it's true that these problems
> >> could occur when a more generic status code is used to handle
> >> the case of "too many requests", that does not mean that they
> >> are not relevant to this document. On the contrary, the fact
> >> that this document is providing more detailed status codes
> >> gives us the opportunity and one can argue the obligation to
> >> provide more detailed security analysis relevant to these more
> >> detailed status codes.
> >
> > I'm really not sure I agree; the original text is:
> >
> >   Servers are not required to use the 429 status code; when
> >   limiting resource usage, it may be more appropriate to just drop
> >   connections, or take other steps.
> >
> > If someone implementing a server doesn't understand that, I don't
> know that using more words really helps; it does, however, make it
> harder to find the words in the spec that *will* help.
> >
> >
> > --
> > Mark Nottingham   http://www.mnot.net/
> >
> >
> >
>=20
> --
> Mark Nottingham   http://www.mnot.net/
>=20
>=20


From julian.reschke@gmx.de  Mon Jan 30 07:10:08 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8778121F8542 for ; Mon, 30 Jan 2012 07:10:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.077
X-Spam-Level: 
X-Spam-Status: No, score=-104.077 tagged_above=-999 required=5 tests=[AWL=-1.478, 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 ZaV-V02F11rp for ; Mon, 30 Jan 2012 07:10:08 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 92BF321F84F7 for ; Mon, 30 Jan 2012 07:10:07 -0800 (PST)
Received: (qmail invoked by alias); 30 Jan 2012 15:10:06 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 30 Jan 2012 16:10:06 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19Fn5J0hdtFV55ezJqcoEBytfYjWN+XhDLNwycmHK X0hThGd6TQIVZs
Message-ID: <4F26B2C4.9010808@gmx.de>
Date: Mon, 30 Jan 2012 16:09:56 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Stephen Hanna 
Subject: Re: secdir review of draft-nottingham-http-new-status-03
References:  <4F109383.1090505@gmx.de>   <0EEB0CDF-6D05-4EA7-9244-CA80C03BD11D@mnot.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "draft-nottingham-http-new-status@tools.ietf.org" , Mark Nottingham , "ietf@ietf.org" , "secdir@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 15:10:08 -0000

On 2012-01-30 16:05, Stephen Hanna wrote:
> Mark,
>
> I don't want to rehash the discussion that we've already had.
> Clearly, you prefer brevity while I would prefer education in
> this instance.
>
> I can live with your text for status codes 428, 429, and 431. For
> 511, I don't think it's adequate to just say that big security
> issues already exist. You should at least give some suggestions
> for how to deal with them. For example, you could point out that
> most user agents include some indication of whether the server
> has been authenticated. For captive portals, this indication will
> generally not be displayed so the user receives some warning
> that the response did not come from the requested URL.

Are you referring to HTTPS?

Best regards, Julian

From shanna@juniper.net  Mon Jan 30 07:22:42 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D01C121F8530; Mon, 30 Jan 2012 07:22:39 -0800 (PST)
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 4pu9uqRzm8BA; Mon, 30 Jan 2012 07:22:39 -0800 (PST)
Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 47DF021F8518; Mon, 30 Jan 2012 07:22:29 -0800 (PST)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTya1tFTh75tJUxYl12LmBvFtwA+U+FYl@postini.com; Mon, 30 Jan 2012 07:22:39 PST
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jan 2012 07:22:07 -0800
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 30 Jan 2012 10:22:06 -0500
From: Stephen Hanna 
To: Julian Reschke 
Date: Mon, 30 Jan 2012 10:22:05 -0500
Subject: RE: secdir review of draft-nottingham-http-new-status-03
Thread-Topic: secdir review of draft-nottingham-http-new-status-03
Thread-Index: AczfYUO3oKpAesuPQqeen+7Xx1BFdgAAZu8w
Message-ID: 
References:  <4F109383.1090505@gmx.de>   <0EEB0CDF-6D05-4EA7-9244-CA80C03BD11D@mnot.net>  <4F26B2C4.9010808@gmx.de>
In-Reply-To: <4F26B2C4.9010808@gmx.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EXCLAIMER-MD-CONFIG: fa292fd1-9837-42fa-9560-006eca2aed31
Cc: "draft-nottingham-http-new-status@tools.ietf.org" , Mark Nottingham , "ietf@ietf.org" , "secdir@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 15:22:42 -0000

Yes

-Steve

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Monday, January 30, 2012 10:10 AM
> To: Stephen Hanna
> Cc: Mark Nottingham; draft-nottingham-http-new-status@tools.ietf.org;
> secdir@ietf.org; ietf@ietf.org
> Subject: Re: secdir review of draft-nottingham-http-new-status-03
>=20
> On 2012-01-30 16:05, Stephen Hanna wrote:
> > Mark,
> >
> > I don't want to rehash the discussion that we've already had.
> > Clearly, you prefer brevity while I would prefer education in
> > this instance.
> >
> > I can live with your text for status codes 428, 429, and 431. For
> > 511, I don't think it's adequate to just say that big security
> > issues already exist. You should at least give some suggestions
> > for how to deal with them. For example, you could point out that
> > most user agents include some indication of whether the server
> > has been authenticated. For captive portals, this indication will
> > generally not be displayed so the user receives some warning
> > that the response did not come from the requested URL.
>=20
> Are you referring to HTTPS?
>=20
> Best regards, Julian

From hartmans@painless-security.com  Mon Jan 30 03:42:19 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228C021F8559; Mon, 30 Jan 2012 03:42:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.345
X-Spam-Level: 
X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 twGvAVNqPUsF; Mon, 30 Jan 2012 03:42:18 -0800 (PST)
Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id AF59421F84EB; Mon, 30 Jan 2012 03:42:18 -0800 (PST)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A1C92203C0; Mon, 30 Jan 2012 06:41:21 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8A60A4690; Mon, 30 Jan 2012 06:42:05 -0500 (EST)
From: Sam Hartman 
To: Stefan Winter 
Subject: Re: [radext] Security review of draft-ietf-radext-radsec
References:  <4F2651CC.2030406@restena.lu>
Date: Mon, 30 Jan 2012 06:42:05 -0500
In-Reply-To: <4F2651CC.2030406@restena.lu> (Stefan Winter's message of "Mon, 30 Jan 2012 09:16:12 +0100")
Message-ID: 
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailman-Approved-At: Mon, 30 Jan 2012 07:32:40 -0800
Cc: radext@ietf.org, ietf@ietf.org, secdir@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 11:42:19 -0000

Your proposed direction for trust validation semes like a major
improvement to me.

From julian.reschke@gmx.de  Mon Jan 30 08:09:07 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1624421F86B7 for ; Mon, 30 Jan 2012 08:09:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.02
X-Spam-Level: 
X-Spam-Status: No, score=-104.02 tagged_above=-999 required=5 tests=[AWL=-1.421, 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 tuZqycjTwvSl for ; Mon, 30 Jan 2012 08:09:06 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id EE89421F864B for ; Mon, 30 Jan 2012 08:09:05 -0800 (PST)
Received: (qmail invoked by alias); 30 Jan 2012 16:09:04 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 30 Jan 2012 17:09:04 +0100
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1//hA9f/9j/IHz89cZ85ZvK5jB+2wNljL5v1oqVOV bwP6H/QfIHuIlp
Message-ID: <4F26C097.1040209@gmx.de>
Date: Mon, 30 Jan 2012 17:08:55 +0100
From: Julian Reschke 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Stephen Hanna 
Subject: Re: secdir review of draft-nottingham-http-new-status-03
References:  <4F109383.1090505@gmx.de>   <0EEB0CDF-6D05-4EA7-9244-CA80C03BD11D@mnot.net>  <4F26B2C4.9010808@gmx.de> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "draft-nottingham-http-new-status@tools.ietf.org" , Mark Nottingham , "ietf@ietf.org" , "secdir@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 16:09:07 -0000

Well,

a) this doesn't help for non-HTTPS traffic, anb

b) in case of a captive portal intercepting https traffic, we would 
expect a certificate error, no?

Anyway; this is not a security consideration specific to 511, but 
applies to captive portals in general, no matter whether the new status 
code is used or not. As such, it *could* be added to Appendix B.

Best regards, Julian

On 2012-01-30 16:22, Stephen Hanna wrote:
> Yes
>
> -Steve
>
>> -----Original Message-----
>> From: Julian Reschke [mailto:julian.reschke@gmx.de]
>> Sent: Monday, January 30, 2012 10:10 AM
>> To: Stephen Hanna
>> Cc: Mark Nottingham; draft-nottingham-http-new-status@tools.ietf.org;
>> secdir@ietf.org; ietf@ietf.org
>> Subject: Re: secdir review of draft-nottingham-http-new-status-03
>>
>> On 2012-01-30 16:05, Stephen Hanna wrote:
>>> Mark,
>>>
>>> I don't want to rehash the discussion that we've already had.
>>> Clearly, you prefer brevity while I would prefer education in
>>> this instance.
>>>
>>> I can live with your text for status codes 428, 429, and 431. For
>>> 511, I don't think it's adequate to just say that big security
>>> issues already exist. You should at least give some suggestions
>>> for how to deal with them. For example, you could point out that
>>> most user agents include some indication of whether the server
>>> has been authenticated. For captive portals, this indication will
>>> generally not be displayed so the user receives some warning
>>> that the response did not come from the requested URL.
>>
>> Are you referring to HTTPS?
>>
>> Best regards, Julian
>


From Michael.Jones@microsoft.com  Mon Jan 30 11:43:14 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590E921F85D2; Mon, 30 Jan 2012 11:43:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.758
X-Spam-Level: 
X-Spam-Status: No, score=-3.758 tagged_above=-999 required=5 tests=[AWL=-0.160, 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 BWmf39VQ-fqb; Mon, 30 Jan 2012 11:43:13 -0800 (PST)
Received: from DB3EHSOBE001.bigfish.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id CD9BA21F850D; Mon, 30 Jan 2012 11:43:12 -0800 (PST)
Received: from mail99-db3-R.bigfish.com (10.3.81.230) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 30 Jan 2012 19:43:11 +0000
Received: from mail99-db3 (localhost [127.0.0.1])	by mail99-db3-R.bigfish.com (Postfix) with ESMTP id 1877E1A02E7; Mon, 30 Jan 2012 19:43:11 +0000 (UTC)
X-SpamScore: -19
X-BigFish: VS-19(zzc85fhzz1202hzz1033IL8275eh8275bh8275dha1495iz2fhc1bhc31hc1ahc1bhc31hc1ah2a8h668h839h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail99-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail99-db3 (localhost.localdomain [127.0.0.1]) by mail99-db3 (MessageSwitch) id 1327952588724882_26700; Mon, 30 Jan 2012 19:43:08 +0000 (UTC)
Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.231])	by mail99-db3.bigfish.com (Postfix) with ESMTP id A9DB81C0278; Mon, 30 Jan 2012 19:43:08 +0000 (UTC)
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 30 Jan 2012 19:43:07 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0247.005; Mon, 30 Jan 2012 11:42:34 -0800
From: Mike Jones 
To: "oauth@ietf.org" , "ietf@ietf.org" , "iesg@ietf.org" 
Subject: OAuth 2.0 Bearer Token Specification Draft -16
Thread-Topic: OAuth 2.0 Bearer Token Specification Draft -16
Thread-Index: Aczfh0f3Dd/+wXTgQaiZVcyGxsaUGw==
Date: Mon, 30 Jan 2012 19:42:33 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436638D04A@TK5EX14MBXC284.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.71]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436638D04ATK5EX14MBXC284r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 19:43:14 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436638D04ATK5EX14MBXC284r_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Draft 16 of the OAuth 2.0 Bearer Token Specification has been published.  This version contains=
 a proposed resolution to the auth-param syntax issue that has been reviewe=
d by Julian Reschke, Mark Nottingham, and the OAuth WG chairs.  It also add=
resses the Gen-ART review comments by Alexey Melnikov.

It contains the following changes:

  *   Use the HTTPbis auth-param syntax for Bearer challenge attributes.
  *   Dropped the sentence "The realm value is intended for programmatic us=
e and is not meant to be displayed to end users".
  *   Reordered form-encoded body parameter description bullets for better =
readability.
  *   Added [USASCII] reference.

The draft is available at:

*         http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16
A HTML-formatted version is available at:

*         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-16.html

                                                            -- Mike


--_000_4E1F6AAD24975D4BA5B16804296739436638D04ATK5EX14MBXC284r_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable









      

      Draft 16 of the 
OAuth 2.0 Bearer Token Specification has been published.  This ver=
sion contains a proposed resolution to the auth-param syntax issue that has=
 been reviewed by Julian Reschke, Mark Nottingham, and the OAuth WG chairs.=
  It also addresses the Gen-ART review
 comments by Alexey Melnikov.
      

       
      

      It contains the following changes:
      

        

      • 
Use the HTTPbis auth-param syntax for Bearer chall=
enge attributes.

      • 
Dropped the sentence "The
realm val=
ue is intended for programmatic use and is not meant to be displayed to end=
 users".

      • 
Reordered form-encoded body parameter description =
bullets for better readability.

      • 
Added [USASCII] reference.

      

       
      

      The draft is available at:
      

      ·        
http://tools.ietf.org/html/draft-ietf-oauth-v2-bea=
rer-16
      

      A HTML-formatted version is available at:=

      

      ·        
http://self-issued.info/docs/draft-ietf-oau=
th-v2-bearer-16.html
      

       
      

              &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p; -- Mike
      

       
      

      



--_000_4E1F6AAD24975D4BA5B16804296739436638D04ATK5EX14MBXC284r_--

From tglassey@earthlink.net  Mon Jan 30 12:15:06 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B1211E809A; Mon, 30 Jan 2012 12:15:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level: 
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=-0.925, 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 vysvG+wXUPwA; Mon, 30 Jan 2012 12:15:05 -0800 (PST)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id D381511E8091; Mon, 30 Jan 2012 12:15:01 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=rpCSvc/jL0ovGmtYN2/wFKtR+9uoyeAyQVLJqLN1DMY5bkiNK2VcT9/HOt2e1gM0; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Opacus-Archived:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [216.171.124.254] (helo=[192.168.0.4]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Rrxcz-00085E-8p; Mon, 30 Jan 2012 15:15:01 -0500
Message-ID: <4F26FA41.20109@earthlink.net>
Date: Mon, 30 Jan 2012 12:14:57 -0800
From: todd glassey 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: ietf@ietf.org, chair@IETF.org
Subject: IPR issues = Re: Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt
References: <4F2575CE.9040001@isode.com> <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com>
X-Opacus-Archived: none
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7924e9424bbbad48e03eea99092f5ba661350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 216.171.124.254
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 20:15:06 -0000

On 1/29/2012 9:20 PM, Mike Jones wrote:
> Thanks for your useful feedback, Alexey.  Below, I'll respond to each of your comments.  I've also added the OAuth working group to the thread, so they are aware of them as well and can participate in the discussion.
> 
> About your first issue with the WWW-Authenticate ABNF, I am already working with Julian, Mark Nottingham, and the chairs to resolve this issue.  Expect to see a proposal for review by the working group shortly.
> 
> About your comments on scope:  OAuth 2.0 (both the Core and Bearer specs) is designed to be deployed in diverse and non-interoperable application contexts, meeting a variety of application needs.  In those various settings, which are often distinct and potentially non-interoperable, parameters such as scope, realm, etc. may have very different meanings.  This is not a bug; it is a feature, because it allows the OAuth pattern to meet the needs of numerous, often distinct, application environments.  For that reason, a registry of scope (or realm) parameters would be ill-advised and counterproductive.  It's perfectly OK and expected for a scope value such as "email" to have one meaning in one application context and a different meaning in a different, but distinct application context.  Trying to impose a single meaning on particular scope values across distinct application contexts is both unnecessary and could break many existing deployments.  That being said, we fully expec
t i
>  nteroperability profiles to emerge that define interoperable sets of scope values within particular application contexts.  (The OpenID Connect specifications are one such set of profiles.)  But these meanings will always be context-specific - not global in scope.
> 
> About your first minor issue, I'll reorder the bullets so the statement about the entity-body being single part is followed by the statement about it using application/x-www-form-urlencoded, so they will be read together.
> 
> About your second minor issue on error codes, the error codes registry already exists, but is in the OAuth Core spec.  See http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-11.4.
> 
> About your third minor issue on RFC 6125 versus RFC 2818, you'll find that, per the history entries, a previous reference to RFC 2818 was changed to RFC 6125 in draft 14 at the request of Security Area Director Stephen Farrell.  If you'd like to see this reference reintroduced, I'd request that you work with Stephen on specific alternative proposed wording that is acceptable to both of you.
> 
> Finally, I'll address both of your nits in the manner you suggested.
> 


The entire OA program looks like what I proposed to Cisco back when I
was working on the CARE project in the DB team in Customer Support.

You be happy to know that OA in and of itself is both covered by earlier
IPR notices regarding my Location Based Services and the new patent
which the Chair has not posted from my January 2012 IPR filings.

As to these two new Jan 2012 briefs - the patent application for the
controls which this would tied to was done in December of 2011.

Todd Glassey
> 


-- 
Todd S. Glassey
This is from my personal email account and any materials from this
account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.

From tglassey@earthlink.net  Mon Jan 30 12:25:40 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E5411E80B0 for ; Mon, 30 Jan 2012 12:25:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.039
X-Spam-Level: 
X-Spam-Status: No, score=-3.039 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_50=0.001, GB_I_LETTER=-2]
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 4GHdonSt3+tp for ; Mon, 30 Jan 2012 12:25:39 -0800 (PST)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id BF2E711E8091 for ; Mon, 30 Jan 2012 12:25:39 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=KK8OCxX3Pd5YVFrOREeRJCgOZXMRD5KDwVLWkCzMS5iJiPDtGhJHLTsTEr9qqOQL; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Opacus-Archived:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [216.171.124.254] (helo=[192.168.0.4]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RrxnH-0001UT-0D for ietf@ietf.org; Mon, 30 Jan 2012 15:25:39 -0500
Message-ID: <4F26FCBF.6080507@earthlink.net>
Date: Mon, 30 Jan 2012 12:25:35 -0800
From: todd glassey 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: IETF Discussion Mailing List 
Subject: IPR statement... Intentionally creating derivatives which infringe on protected IP creates numerous claims and grounds for pain we don't need here.
X-Opacus-Archived: none
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7955407d070aa1866e0148bb61fe0351f7350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 216.171.124.254
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 20:25:40 -0000

The IETF has long hidden its (c) and patent violations IMHO under the
guise of its broken standards process and its time to pay for that. Here
is the case law that says NO NO NO...

This is copied from a specific IP website as an informational post. It
is specific to the willingness to infringe on patents and the legal
issues since this clearly is a joint-development consortia and not a
standards org.

In fact let me ask, when was the last time a standard itself was issued?
You see my point???

So here is the language -

1)	Willfulness is a question of fact and involves a determination as to
an infringer’s state of mind. Pall Corp. v. Micron Separations, Inc., 66
F.3d 1211, 1221 (Fed.Cir.1995) (willfulness is a question of fact that
involves elements of intent, reasonableness, and belief); Graco, Inc. v.
Binks Mfg. Co., 60 F.3d 785, 792 (Fed.Cir.1995) (same); Electro Medical
Sys., S.A. v. Cooper Life Sciences, Inc., 34 F.3d 1048, 1056
(Fed.Cir.1994); Read Corp. v. Portec, Inc., 970 F.2d 816, 828
(Fed.Cir.1992); Stickle v. Heublein, Inc., 716 F.2d 1550, 1565
(Fed.Cir.1983) (intent and reasonable beliefs are the primary focus of a
willful infringement inquiry).

2)	Specifically, in determining the question of willfulness, the primary
consideration is whether the infringer acted in disregard of the
infringed patent with no reasonable basis to believe it had a right to
do the acts in question. In the world of 2011/2012 this takes on a whole
new light in the legal context too.

3)	Pall Corp., 66 F.3d at 1221 (factfinder should examine whether the
infringer deliberately disregarded the property rights of the patentee);
Ortho Pharmaceutical Corp. v. Smith, 959 F.2d 936, 944 (Fed.Cir.1992)
(the focus of a willfulness inquiry should be on whether the infringer
had no reasonable belief for thinking it had a legal right to continue
its conduct).

So in this case what would they have to prove - that the IETF was
informed and it intentionally continued development of a intellectual
property which could not be implemented without the license of the
patent holder?

One who has actual notice of a patent owner’s rights has an affirmative
duty to respect those rights. Read Corp., 970 F.2d at 828 (citing
Rolls-Royce, Ltd. v. GTE Valeron Corp., 800 F.2d 1101, 1109
(Fed.Cir.1986)); Avia Group, Int’l, Inc. v. L.A. Gear California, Inc.,
853 F.2d 1557, 1566 (Fed.Cir.1988).

The issue of willfulness “rests on a determination of the infringer’s
state of mind,” Mahurkar v. C.R. Bard, Inc., 79 F.3d 1572, 1579
(Fed.Cir.1996), and “includes elements of intent, reasonableness, and
belief,” Pall Corp., 66 F.3d at 1221. Among the grounds for a
willfulness finding are “[t]he extent to which the infringer disregarded
the property rights of the patentee, the deliberateness of the tortious
acts, or other manifestations of unethical or injurious commercial
conduct.” Hoechst Celanese Corp. v. BP Chems. Ltd., 78 F.3d 1575, 1583
(Fed.Cir.), cert. denied, 117 S.Ct. 275, 136 L.Ed.2d 198 (1996). No
hard-and-fast rules govern the willfulness determination, which should
be made after evaluating all the relevant circumstances. Graco, Inc. v.
Binks Mfg. Co., 60 F.3d 785, 792 (Fed.Cir.1995). Willful infringement
must be proven by clear and convincing evidence. Pall Corp., 66 F.3d at
1221; In re Hayes Microcomputer Prods., Inc. Patent Litig., 982 F.2d
1527, 1543 (Fed.Cir.1992).

So... we should take notice about these issues as a new hurdle. The
research part of the IETF has nothing to do with production standards -
they are joint development agreements to specifically take a protocol
model and implement it as code...

If you would like to get the IETF's lawyers to formally - and on their
legal letterhead swear this is not true - which based on the case law
cited - they are not going to get anywhere near I bet, then  OK.
Otherwise everyone now has a new problem with the IETF and that is that
the participants and their sponsors are liable for this damage per these
standards.

Todd Glassey
-- 
Todd S. Glassey
This is from my personal email account and any materials from this
account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.

From tglassey@earthlink.net  Mon Jan 30 12:35:21 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA4711E80C1 for ; Mon, 30 Jan 2012 12:35:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.166
X-Spam-Level: 
X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=-0.567, 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 E7tHdmuEmY5U for ; Mon, 30 Jan 2012 12:35:20 -0800 (PST)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD2311E80C0 for ; Mon, 30 Jan 2012 12:35:20 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=sAzslAvQxybjUNnj5FDUt535ysANdsXlyZIMvTBZTOBQYOOc5yLVriPk7Bwn7nQ5; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Opacus-Archived:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [216.171.124.254] (helo=[192.168.0.4]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Rrxwe-0001dE-4e for ietf@ietf.org; Mon, 30 Jan 2012 15:35:20 -0500
Message-ID: <4F26FF04.1030406@earthlink.net>
Date: Mon, 30 Jan 2012 12:35:16 -0800
From: todd glassey 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: encouraging compliance with IPR disclosure rules
References: <20120125201714.3903.82295.idtracker@ietfa.amsl.com> <4F2075BE.5070201@nostrum.com> <033901ccdbab$6bae0900$430a1b00$@olddog.co.uk>  <4F208AEF.5060406@qualcomm.com> <9E8747DFE73501D34065351E@PST.JCK.COM> <4F217A7C.6080908@qualcomm.com> <6.2.5.6.2.20120126085545.0b1fa288@resistor.net> <4F219004.4070601@stpeter.im> <6.2.5.6.2.20120126100436.0b2262b8@resistor.net> 
In-Reply-To: 
X-Opacus-Archived: none
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec791f1dfedde554a6db3882691d7fa10f1a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 216.171.124.254
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 20:35:21 -0000

On 1/27/2012 9:41 AM, Scott Brim wrote:
> On Thu, Jan 26, 2012 at 14:01, SM  wrote:
>>  "To support the efficient development of IETF standards and
>>   avoid unnecessary delays, chairs and ADs should look for
>>   opportunities to promote awareness and compliance with the
>>   IETF's IPR policies."
>>
>> WG Chairs interact with IETF participants more often than ADs.  It is not
>> clear whether it is their responsibility to promote awareness and
>> compliance.
> 
> Don't look for some kind of procedural responsibility.  WG Chairs
> _want_ to ensure awareness and compliance as early as possible,
> because if they don't do so they suffer: they suffer embarrassment and
> sometimes failure of all their efforts when IPR is discovered late in
> the process.  There's no need to assign responsibility to chairs or
> IESG members, we already have plenty of feedback for them.
> 
>> Some points in the draft, such as the two-step approach to confirm
>> compliance may help to catch issues before they become a concern.
> 
> Yup.  Ask early and often, directly and individually.  That clearly
> makes the askees responsible, which will matter later.
> 
> Scott

Assuming all the i's are dotted and the t's crossed Scott something
which functionally seems rarely to happen. How do you deal with the
issues of being liable under the 9th Circuit Model for "Willful
Infringement" - the IETF doesnt build ANYTHING that can exist without
its implemented process - and since in many instances these violate
patent protections in place how is it that the IETF gets to set the law
aside...

I am betting it doesnt. Nor do the sponsors of those hammered here under
that. For that reason I think we need both controls that allow
unpublishing of documents and recall of Licensing Rights in a matter
where we find something wrong or outside the process happened.

Unless it is of course the plan and practice of the IETF to destroy the
US Government's copyright protections... as well as its patent process.
So I ask, is that the intent here?

Todd
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 


-- 
Todd S. Glassey
This is from my personal email account and any materials from this
account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.

From chair@IETF.org  Mon Jan 30 13:35:29 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F42F11E80A2 for ; Mon, 30 Jan 2012 13:35:29 -0800 (PST)
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 Kus8OtlMKkjy for ; Mon, 30 Jan 2012 13:35:28 -0800 (PST)
Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:123a::1:14]) by ietfa.amsl.com (Postfix) with ESMTP id A9D9811E809F for ; Mon, 30 Jan 2012 13:35:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 4CF2A12CA13; Mon, 30 Jan 2012 13:35:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq+pQzgVkDyd; Mon, 30 Jan 2012 13:35:28 -0800 (PST)
Received: from [192.168.2.104] (pool-96-241-165-215.washdc.fios.verizon.net [96.241.165.215]) by c8a.amsl.com (Postfix) with ESMTPSA id E269A12C6E0; Mon, 30 Jan 2012 13:35:27 -0800 (PST)
Subject: Re: IPR issues = Re: Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: IETF Chair 
In-Reply-To: <4F26FA41.20109@earthlink.net>
Date: Mon, 30 Jan 2012 16:35:27 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <92C4DBD9-A224-4A2B-9151-FCC7FFF125D3@IETF.org>
References: <4F2575CE.9040001@isode.com> <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F26FA41.20109@earthlink.net>
To: todd glassey 
X-Mailer: Apple Mail (2.1084)
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 21:35:29 -0000

> You be happy to know that OA in and of itself is both covered by =
earlier
> IPR notices regarding my Location Based Services and the new patent
> which the Chair has not posted from my January 2012 IPR filings.

The Secretariat processed your IPR statement in three business days.  =
The Secretariat aims to process them in two business days, but the extra =
day is no where close to the blocking action implied by your note.

I was not even aware of your IPR statement until this message arrived in =
my mailbox.  Your IPR statement, like almost all IPR statement postings, =
was processed by the Secretariat with no action of any sort by me.

Russ


From ogud@ogud.com  Mon Jan 30 13:53:48 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AC311E80B0; Mon, 30 Jan 2012 13:53:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.437
X-Spam-Level: 
X-Spam-Status: No, score=-106.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 f+CgZOuU+5jj; Mon, 30 Jan 2012 13:53:47 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 31B6011E80BF; Mon, 30 Jan 2012 13:53:31 -0800 (PST)
Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q0ULrRvr003917; Mon, 30 Jan 2012 16:53:28 -0500 (EST) (envelope-from ogud@ogud.com)
Message-ID: <4F271155.9080001@ogud.com>
Date: Mon, 30 Jan 2012 16:53:25 -0500
From: Olafur Gudmundsson 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Roni Even 
Subject: Re: Gen-ART LC review of draft-ietf-dnsext-ecdsa-04
References: <4f2570c6.11840e0a.6db6.09c6@mx.google.com>
In-Reply-To: <4f2570c6.11840e0a.6db6.09c6@mx.google.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4
Cc: draft-ietf-dnsext-ecdsa.all@tools.ietf.org, gen-art@ietf.org, 'IETF-Discussion list' 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 21:53:48 -0000

On 29/01/2012 11:12, Roni Even wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> .
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-dnsext-ecdsa-04
>
> Reviewer: Roni Even
>
> Review Date:2012–1–29
>
> IETF LC End Date: 2012–2–7
>
> IESG Telechat date:
>
> Summary: This draft is almost ready for publication as an Informational RFC.
>
> Major issues:
>
> The first IANA action is to update
> http://www.iana.org/assignments/ds-rr-types/ds-rr-types.txt which
> requires standard action for adding values.
>

Grrrrrr, my fault, overlooked that the editors put this text in the
header of the document.
WG LC was for standards track document.

Please treat this document as standards track.

> Minor issues:
>
> The important note in section 6 talks about the values in the examples.
> I am wondering why not update the document with the correct values after
> the IANA assignments by the RFC editor.

Yes, once we have the IANA assigned values we will furnish the 
RFC-editor with better examples.


>
> Nits/editorial comments:
>
>
>
thanks for the review

	Olafur (document pusher)

From tglassey@earthlink.net  Mon Jan 30 14:05:18 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60D321F85B4 for ; Mon, 30 Jan 2012 14:05:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.024
X-Spam-Level: 
X-Spam-Status: No, score=-3.024 tagged_above=-999 required=5 tests=[AWL=-0.425, 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 u1r7kWuIVMc4 for ; Mon, 30 Jan 2012 14:05:17 -0800 (PST)
Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 921E121F85AC for ; Mon, 30 Jan 2012 14:05:17 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=uGoB0IwQb3ylTd9Ep0br4GTOZxW1kWT3gG9wWgdgzYv0ku/bHx2I6QeG1N/rdR3S; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Opacus-Archived:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [216.171.124.254] (helo=[192.168.0.4]) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RrzLh-00042G-9Z; Mon, 30 Jan 2012 17:05:17 -0500
Message-ID: <4F271419.1070208@earthlink.net>
Date: Mon, 30 Jan 2012 14:05:13 -0800
From: todd glassey 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Vinayak Hegde 
Subject: Re: Commentary about IETF protocols which do not provide IP protection in their use.
References: <4F254233.9020409@earthlink.net> 
In-Reply-To: 
X-Opacus-Archived: none
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7998d2bb254477e5d4e278ef844796c06c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 216.171.124.254
Cc: IETF Discussion Mailing List 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 22:05:18 -0000

On 1/29/2012 6:34 AM, Vinayak Hegde wrote:
> On Sun, Jan 29, 2012 at 6:27 PM, todd glassey  wrote:
>> Today virtually no IETF protocols take into account US or any other
>> countries copyright laws with regard to Internet based content. Content
>> like domain names, DNS events, and BGP4 routes are also in addition to
>> the obvious publication events like a websites content, are in fact also
>> IP impinged.
> 
> I think it is bad to integrate copyright policy into protocols. for
> example how do you take into account if submarine cables transit into
> territorial waters of another country are the countries copyright
> policies to be applied to the content if so how ?

This pertains to something totally outside of our issue. The issue is
whether it is legally actionable to attack something for intentional
infringement and under US and international law the answer is yes.

> 
> Also please do not club everything - Trademarks, Copyright and patents
> under the same umbrella. They are very different things. Please read
> http://www.gnu.org/philosophy/not-ipr.html for more information.\

GNU's philosophy is the ideas of the people that wrote that policy - it
is NOT law. As such the idea that it protects this group is part of the
problem.

> 
>> So the question is what happens when a priority provide with a peering
>> relationship claims (c) against a set of Internet Routes... it is coming
>> I think.
>>
>> That said - I am proposing that there is a need to figure out now with
>> regard to IETF projects whether the content flowing through the
>> technology will have legal impact attached to it and in those instances
>> provide the  proper information management and IP noticing controls.
>>
>> Yes I am very sure this annoys the anarchists and anti-intellectual
>> property people here and you folks have done a great job up until now,
>> except you have failed to change the world. That said - the win hear is
>> in not fighting in changing the laws by going to war with the
>> superpowers - they will just hire technologists to replace us as a class
>> and much sooner than you think too...
> 
> Who is they ?

The people who come to realize that the IETF isnt actually responsible
for anything... its standards are trailing edge, it has no real license
possible for code to be created through its process, and its basically
an exercise set up as a bolt on for an academic-style operation IMHO. I
think its amusing how many people have made this their life too...

Scary!
> 
>> If we don't put both proper IP controls into our processes and into the
>> actual work product so that its use can also respect the same laws we
>> built the IP to operate under the Government's trying to enforce those
>> laws will make official changes in who represents their interest in the
>> IETF and what effect the IETF has on there routing.
> 
> IETF has processes in place for patenst More reading:
> See the work of the IPR group.
> http://tools.ietf.org/wg/ipr/

Which also fails to take into account that the IETF is a collective
development group and NOT a standards org. For the history of the IETF
its standards used to be trailing edge meaning that they IP was already
in place when they created the standards so these issues were moot.
Today it is IMHO being used by many to lead their infringements. That
has to change.

> 
> For example see http://tools.ietf.org/html/rfc3669 - RFC 3669
> 
>> What I am telling you is that ISOC has no where near enough power to
>> protect the IETF from IP fraud complaints at a national level. And if
>> they were stupid enough to try - which they might, it would be
>> catastrophic. My take is formal pull out of the DNS Root because all of
>> the peering contracts say nothing about whose root must be used. Its
>> that simple. Governments will tell foreign carriers that their route
>> copyrights are now enforceable and that's it. If the carriers want to
>> serve in that country they will pay.
>>
>> This is serious stuff. The world Internet is changing - the wild west is
>> dying out, and accountable at the content level is happening today.
>> Rather than trying to stop that we need to make it possible for our
>> masters to meet their goals through our work or we need to make public
>> disclosure who's goals as individuals we serve.
> 
> Who are our master here ? There are people working for governments,
> commercial enterprises and self-employed on this lists. I think
> generalisation of their agendas is not possible. Can you please
> qualify your statements ?

Considering I have a patent matter in the courts now, I speak from first
hand experience here.

> 
>> Disclosure is key - and disclose everywhere. No vapor - no vacuum no lies.
> 
> Please read the links above.

I have - my commentary stands.

Todd

> 
> -- Vinayak
> 


-- 
Todd S. Glassey
This is from my personal email account and any materials from this
account come with personal disclaimers.

Further I OPT OUT of any and all commercial emailings.

From fcorella@pomcor.com  Mon Jan 30 14:12:23 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB67411E80AE for ; Mon, 30 Jan 2012 14:12:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.638
X-Spam-Level: 
X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96]
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 MUfDqoShHxMm for ; Mon, 30 Jan 2012 14:12:21 -0800 (PST)
Received: from nm36-vm6.bullet.mail.ne1.yahoo.com (nm36-vm6.bullet.mail.ne1.yahoo.com [98.138.229.118]) by ietfa.amsl.com (Postfix) with SMTP id 93F4421F85C0 for ; Mon, 30 Jan 2012 14:12:21 -0800 (PST)
Received: from [98.138.90.57] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 30 Jan 2012 22:12:21 -0000
Received: from [98.138.89.175] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 30 Jan 2012 22:12:21 -0000
Received: from [127.0.0.1] by omp1031.mail.ne1.yahoo.com with NNFMP; 30 Jan 2012 22:12:21 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 103820.2612.bm@omp1031.mail.ne1.yahoo.com
Received: (qmail 62145 invoked by uid 60001); 30 Jan 2012 22:12:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1327961541; bh=Ngp78hgh//x++m+bX3KrZXbEqiFHwA5LxvLv6qtGZvk=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=YyIrv0mS7gx/8kAZpHQ8ivn1vvksJsJM/ALI71OCsHqMSv0iWXTNl/z+RD3pKANngiE1vbtM/pZwWDYhVKrvubz0tBFNjFbRZ+4tEbDXJSKqtHO8rOY2+t+P1fpvUFEsppJSy5EJ1rAOFRC5F/Dapfj9HU5ZYhEIi9EeD3MZIag=
X-YMail-OSG: Gi2r374VM1lgEYyDH4A.L9CUVLMNuW93cPejKBqXZ9oXkrn 5XC9vV2e.VSeKfOSDNQrOI0GPzx0ML2XKTQ2lNO8ei8oGRuEjsziWYPHtrcb Si6nJSc0nXR2xRZMIAR55W1Tolkn0g8HMbR.ku737C31zV0lJ3cR7W4QzM0D ZTSn8WLOoNKF5_jbZRE2sD6tLuUzTJzlcDy8eapqFoo_aGqmGWJrmAOCkJPK jch2WdlNME1qByPWY2DEZNzboJBUl6.p0oi4uJeuXQY.j6HS3kvx.vuSCCxn 1dnL_R8RLdP8DST511Dh32G3Hl4YEkzAYyFezfYnJ0cp1sJRTSFD1Fy.ssGf U0ZqL9PUWwIIFLuHjxwv9aOjTmXzgYeoYbhxX1wFFzngHyCupe1D7RdS3QUp E8c5DXmcK6XpzHuZOzpNz3qNGYWUcOcJVjTuFc1CQRmsJDAZnrWVkcDM4UFe 9vD60Ceu3e_75f2xMOCMw9xlkIiIh6pSkX9H3FIl.5UPEip8XsaayEkvoygu MC9VfsR4ZOLbFJiYYeYkF0ZRO1ZbqM0cf.85GC3ekSWZKV9T.kklmdVRvZjO Cz5gK1i_7u8e2yJyK.uOdLCfeHd.7sH2xhPpu84EQZpP75YjxyIa1N8MMKcb 7HPfKhWYDhtkbPFkKUWYjk0TvpFLAxNUsr2VbeCBFJ0ENO1C5hXY.eu0vhKD kUzEzPPyOAdB_Q2xgYUsF8W8C
Received: from [174.65.117.33] by web125504.mail.ne1.yahoo.com via HTTP; Mon, 30 Jan 2012 14:12:20 PST
X-RocketYMMF: francisco_corella
X-Mailer: YahooMailWebService/0.8.116.331537
Message-ID: <1327961540.19904.YahooMailNeo@web125504.mail.ne1.yahoo.com>
Date: Mon, 30 Jan 2012 14:12:20 -0800 (PST)
From: Francisco Corella 
Subject: Re: REVISED Last Call:  (The OAuth 2.0 Authorization Protocol) to Proposed Standard
To: "ietf@ietf.org" 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="318864283-1064204366-1327961540=:19904"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Francisco Corella 
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 22:12:23 -0000

--318864283-1064204366-1327961540=:19904
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

This document has the following issues:=0A=0A1. Section 10.11, in connectio=
n with phishing attacks, notes that=0A"wide deployment of this and similar =
protocols may cause end-users to=0Abecome inured to the practice of being r=
edirected to websites where=0Athey are asked to enter their passwords".=A0 =
That begs the question:=0Awhy should this protocol be proposed as an Intern=
et standard?=0A=0A2. As observed by John Bradley in=0Ahttp://www.thread-saf=
e.com/2012/01/problem-with-oauth-for-authentication.html=0Aif the implicit =
flow is used for third-party login (as in "Login with=0AFacebook") and if a=
ccess tokens are bearer tokens, a relying party can=0Aobtain an access toke=
n from a legitimate user and use it to=0Aimpersonate the user by presenting=
 it to another relying party.=0A=0A3. In the authorization code flow, if th=
e client's redirection=0Aendpoint is not protected by TLS, a man-in-the-mid=
dle attack allows=0Athe attacker to capture the authorization code and use =
it to=0Aimpersonate the user by presenting it to the client, thus getting=
=0Aaccess to the protected resources, and to the user's account at the=0Acl=
ient if OAuth is used for third-party login.=A0 Section 3.1.2.1 does=0Anot =
require the use of TLS.=A0 On the other hand, section 10.5 requires=0ATLS "=
if the client relies on the authorization code for its own=0Aresource owner=
 authentication", i.e. in the third-party login case.=0AThe distinction bet=
ween the third-party login case and the general=0Acase is a spurious one, w=
hose practical result is to let social sites=0Asuch as Facebook get away wi=
th telling client developers to use http=0Arather than https, as Facebook d=
oes in its developer documentation at=0Ahttp://developers.facebook.com/docs=
/authentication/.=A0 Client=0Adevelopers will read the Facebook instruction=
s rather than the OAuth=0Aspecification, and will not even be aware of the =
need to use TLS,=0Awhether or not they are using OAuth for third-party logi=
n.=0A=0A4. In the security considerations section, subsection 10.12 points =
out=0Aa vulnerability in the protocol that allows an attacker to cause a=0A=
victim to unwittingly log in to the attacker's account instead of the=0Avic=
tim's account.=A0 The third paragraph provides a countermeasure and=0Arequi=
res clients to implement it.=A0 But client developers, if they read=0Athe s=
ecurity considerations at all, are unlikely to understand the=0Acountermeas=
ure, which is barely sketched out.=A0 I don't see why the=0Acountermeasure =
is not incorporated into the protocol description to=0Aeliminate the vulner=
ability.=0A=0A5. Without a secure registration method, the protocol can pro=
vide no=0Asecurity.=A0 Section 2 does not explain how registration can be m=
ade=0Asecure.=A0 It suggest the use of a self-issued assertion by the clien=
t,=0Awhich of course would provide no security.=A0 It also suggests the use=
=0Aof a client description and logo.=A0 Even if the client uses a TLS=0Acer=
tificate to authenticate during registration, the description and=0Alogo ar=
e likely to be self-asserted, since I don't know of any CA that=0Acertifies=
 descriptions and logos.=A0 Then nothing prevents a malicious=0Aclient from=
 using during registration a valid certificate issued to=0Aitself, together=
 with a description and logo of a different client=0Athat the malicious cli=
ent will be able to impersonate.=0A=0A6. This protocol has adverse privacy =
implications when used for=0Athird-party login, as the identity provider is=
 informed of the user's=0Alogins.=A0 This is aggravated by the fact that, w=
hereas with OpenID the=0Auser can choose an identity provider of her choice=
, with OAuth the=0Auser can only use identity providers that the relying pa=
rty has=0Apreregistered with.=A0 Some relying parties only give the choice =
of signing=0Ain with Facebook.=0A=0A7. The preregistration requirement rein=
forces the monopoly that=0AFacebook currently has in social networking, sin=
ce any competitors=0Aface the hurdle of convincing relying parties to regis=
ter with them.=0A=0A8. The preregistration requirement gives unprecedented =
power to=0AFacebook over clients, since Facebook can revoke a client's=0Are=
gistration at its sole discretion.=0A=0A9. Indirectly, the preregistration =
requirement also gives=0Aunprecedented power to Facebook over Web users, by=
 making it necessary=0Ato have a Facebook account for tasks such as logging=
 in to clients or=0Acommenting on blogs.=A0 A user's registration, like a c=
lient=0Aregistration, can be revoked by Facebook at any time at Facebook's=
=0Asole discretion.=A0 Without the preregistration requirement, users would=
=0Abe free to log in or comment via OAuth using identity providers of=0Athe=
ir choice.=0A=0AFrancisco=0A
--318864283-1064204366-1327961540=:19904
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


      This document has the=
 following issues:

      1. Section 10.11, in connection with phishing att=
acks, notes that
      "wide deployment of this and similar protocols may caus=
e end-users to
      become inured to the practice of being redirected to webs=
ites where
      they are asked to enter their passwords".  That begs the=
 question:
      why should this protocol be proposed as an Internet standard?=


      2. As observed by John Bradley in
      http://www.thread-safe.com/201=
2/01/problem-with-oauth-for-authentication.html
      if the implicit flow is =
used for third-party login (as in "Login with
      Facebook") and if access t=
okens are bearer tokens, a relying party can
      obtain an access token from=
 a legitimate user and use it to
      impersonate the user by presenting it t=
o another relying party.

      3. In the authorization code flow, if
 the client's redirection
      endpoint is not protected by TLS, a man-in-the=
-middle attack allows
      the attacker to capture the authorization code and=
 use it to
      impersonate the user by presenting it to the client, thus get=
ting
      access to the protected resources, and to the user's account at the=

      client if OAuth is used for third-party login.  Section 3.1.2.1 do=
es
      not require the use of TLS.  On the other hand, section 10.5 req=
uires
      TLS "if the client relies on the authorization code for its ownresource owner authentication", i.e. in the third-party login case.
      The=
 distinction between the third-party login case and the general
      case is =
a spurious one, whose practical result is to let social sites
      such as Fa=
cebook get away with telling client developers to use http
      rather than h=
ttps, as Facebook does in its developer documentation at
      http://develope=
rs.facebook.com/docs/authentication/.  Client
      developers
 will read the Facebook instructions rather than the OAuth
      specification=
, and will not even be aware of the need to use TLS,
      whether or not they=
 are using OAuth for third-party login.

      4. In the security considera=
tions section, subsection 10.12 points out
      a vulnerability in the protoc=
ol that allows an attacker to cause a
      victim to unwittingly log in to th=
e attacker's account instead of the
      victim's account.  The third pa=
ragraph provides a countermeasure and
      requires clients to implement it.&=
nbsp; But client developers, if they read
      the security considerations at=
 all, are unlikely to understand the
      countermeasure, which is barely ske=
tched out.  I don't see why the
      countermeasure is not incorporated =
into the protocol description to
      eliminate the vulnerability.

      5. =
Without a secure registration method, the protocol can provide no
      securi=
ty.  Section 2 does not explain how registration can be
 made
      secure.  It suggest the use of a self-issued assertion by the=
 client,
      which of course would provide no security.  It also sugges=
ts the use
      of a client description and logo.  Even if the client us=
es a TLS
      certificate to authenticate during registration, the descriptio=
n and
      logo are likely to be self-asserted, since I don't know of any CA =
that
      certifies descriptions and logos.  Then nothing prevents a mal=
icious
      client from using during registration a valid certificate issued =
to
      itself, together with a description and logo of a different clientthat the malicious client will be able to impersonate.

      6. This prot=
ocol has adverse privacy implications when used for
      third-party login, a=
s the identity provider is informed of the user's
      logins.  This is =
aggravated by the fact that, whereas with OpenID the
      user can choose an =
identity provider of her choice, with OAuth the
      user can only use
 identity providers that the relying party has
      preregistered with. =
 Some relying parties only give the choice of signing
      in with Facebook.<=
br>
      7. The preregistration requirement reinforces the monopoly that
      F=
acebook currently has in social networking, since any competitors
      face t=
he hurdle of convincing relying parties to register with them.

      8. Th=
e preregistration requirement gives unprecedented power to
      Facebook over=
 clients, since Facebook can revoke a client's
      registration at its sole =
discretion.

      9. Indirectly, the preregistration requirement also give=
s
      unprecedented power to Facebook over Web users, by making it necessary=

      to have a Facebook account for tasks such as logging in to clients orcommenting on blogs.  A user's registration, like a client
      regist=
ration, can be revoked by Facebook at any time at Facebook's
      sole discre=
tion.  Without the preregistration requirement, users
 would
      be free to log in or comment via OAuth using identity providers o=
f
      their choice.

      Francisco
      
--318864283-1064204366-1327961540=:19904--

From mnot@mnot.net  Mon Jan 30 14:49:26 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B91621F8757; Mon, 30 Jan 2012 14:49:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.895
X-Spam-Level: 
X-Spam-Status: No, score=-104.895 tagged_above=-999 required=5 tests=[AWL=-2.296, 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 gY0B9gmAlBDP; Mon, 30 Jan 2012 14:49:25 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id E458221F8748; Mon, 30 Jan 2012 14:49:24 -0800 (PST)
Received: from mnot-mini.mnot.net (unknown [118.209.240.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CB32A22E258; Mon, 30 Jan 2012 17:49:16 -0500 (EST)
Subject: Re: secdir review of draft-nottingham-http-new-status-03
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=us-ascii
From: Mark Nottingham 
In-Reply-To: 
Date: Tue, 31 Jan 2012 09:49:13 +1100
Content-Transfer-Encoding: 7bit
Message-Id: <8BCAB2A2-C9A8-463E-8C8C-E17FC8A2C461@mnot.net>
References:  <4F109383.1090505@gmx.de>   <0EEB0CDF-6D05-4EA7-9244-CA80C03BD11D@mnot.net> 
To: Stephen Hanna 
X-Mailer: Apple Mail (2.1251.1)
Cc: Julian Reschke , "draft-nottingham-http-new-status@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 22:49:26 -0000

On 31/01/2012, at 2:05 AM, Stephen Hanna wrote:

> Mark,
> 
> I don't want to rehash the discussion that we've already had.
> Clearly, you prefer brevity while I would prefer education in
> this instance.
> 
> I can live with your text for status codes 428, 429, and 431. For
> 511, I don't think it's adequate to just say that big security
> issues already exist. You should at least give some suggestions
> for how to deal with them. For example, you could point out that
> most user agents include some indication of whether the server
> has been authenticated. For captive portals, this indication will
> generally not be displayed so the user receives some warning
> that the response did not come from the requested URL.

Based upon other feedback, I've already added:

   Also, note that captive portals using this status code on an SSL or
   TLS connection (commonly, port 443) will generate a certificate error
   on the client.

to Section 7.4; does that address your concern?

Regards,


> 
> Thanks,
> 
> Steve
> 
>> -----Original Message-----
>> From: Mark Nottingham [mailto:mnot@mnot.net]
>> Sent: Sunday, January 29, 2012 6:50 PM
>> To: Stephen Hanna
>> Cc: Julian Reschke; draft-nottingham-http-new-status@tools.ietf.org;
>> secdir@ietf.org; ietf@ietf.org
>> Subject: Re: secdir review of draft-nottingham-http-new-status-03
>> 
>> I haven't heard any further response. After a reminder from a Security
>> AD, I took another look at the spec.
>> 
>> E.g., the current Security Considerations for 428:
>> 
>>> The 428 status code is optional; clients cannot rely upon its use to
>> prevent "lost update" conflicts.
>> 
>> Like many of the status codes, that's already a risk inherent in using
>> HTTP today; we're effectively just noting that we can't force
>> implementations to use the new status code retroactively, so they can't
>> use the publication of this document as a magical flag day.
>> 
>> As such, not much more can be said; the only way that people can
>> further mitigate the risks of lost updates is to have a private, out-
>> of-band agreement to use 429, and I *don't* think that's something we
>> should be encouraging.
>> 
>> For 429, I've changed to:
>> 
>>> When a server is under attack or just receiving a very large number
>> of requests from a single party, responding to each with a 429 status
>> code will consume resources.
>>> 
>>> Therefore, servers are not required to use the 429 status code; when
>> limiting resource usage, it may be more appropriate to just drop
>> connections, or take other steps.
>> 
>> 
>> 431 says:
>> 
>>> Servers are not required to use the 431 status code; when under
>> attack, it may be more appropriate to just drop connections, or take
>> other steps.
>> 
>> 
>> What else should be said here? This specification is not a treatise on
>> dealing with denial-of-service attacks; all that it notes is that
>> servers aren't required to use the status code.
>> 
>> Finally, 511 says:
>> 
>>> In common use, a response carrying the 511 status code will not come
>> from the origin server indicated in the request's URL. This presents
>> many security issues; e.g., an attacking intermediary may be inserting
>> cookies into the original domain's name space, may be observing cookies
>> or HTTP authentication credentials sent from the user agent, and so on.
>> However, these risks are not unique to the 511 status code; in other
>> words, a captive portal that is not using this status code introduces
>> the same issues.
>> 
>> Are there other specific threats you're aware of here?
>> 
>> Regards,
>> 
>> 
>> 
>> On 25/01/2012, at 10:36 AM, Mark Nottingham wrote:
>> 
>>> Sorry for the delay in responding; just back from holiday.
>>> 
>>> 
>>> On 14/01/2012, at 8:26 AM, Stephen Hanna wrote:
>>> 
>>>> Julian,
>>>> 
>>>> I'm sure that in your view one sentence is adequate to explain
>>>> all the security implications of each status code. However,
>>>> you may want to consider that some readers may not have quite
>>>> the same deep grasp of the matter that you do. Therefore,
>>>> I think it would be wise to provide more explanation. Here's an
>>>> example for section 7.2 on status code 429 (Too Many Requests):
>>>> 
>>>> Section 7.2  429 Too Many Requests
>>>> 
>>>> While status code 429 can be helpful in figuring out why a
>>>> server is not responding to requests, it can also be harmful.
>>>> When a server is under attack or simply receiving a very
>>>> large number of requests from a single party, responding
>>>> to each of these requests with a 429 status code will consume
>>>> resources that could be better used in other ways. Therefore,
>>>> a server in such circumstances may choose to send a 429 status
>>>> code only the first time a client exceeds its limit and
>>>> ignore subsequent requests from this client until its limit
>>>> is no longer exceeded. Other approaches may also be employed.
>>>> 
>>>> As you can see, I described security problems that could occur
>>>> with this status code and explained how those problems can be
>>>> avoided or mitigated. While it's true that these problems
>>>> could occur when a more generic status code is used to handle
>>>> the case of "too many requests", that does not mean that they
>>>> are not relevant to this document. On the contrary, the fact
>>>> that this document is providing more detailed status codes
>>>> gives us the opportunity and one can argue the obligation to
>>>> provide more detailed security analysis relevant to these more
>>>> detailed status codes.
>>> 
>>> I'm really not sure I agree; the original text is:
>>> 
>>>  Servers are not required to use the 429 status code; when
>>>  limiting resource usage, it may be more appropriate to just drop
>>>  connections, or take other steps.
>>> 
>>> If someone implementing a server doesn't understand that, I don't
>> know that using more words really helps; it does, however, make it
>> harder to find the words in the spec that *will* help.
>>> 
>>> 
>>> --
>>> Mark Nottingham   http://www.mnot.net/
>>> 
>>> 
>>> 
>> 
>> --
>> Mark Nottingham   http://www.mnot.net/
>> 
>> 
> 

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




From Michael.Jones@microsoft.com  Mon Jan 30 15:44:33 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FBC11E80F5; Mon, 30 Jan 2012 15:44:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.753
X-Spam-Level: 
X-Spam-Status: No, score=-3.753 tagged_above=-999 required=5 tests=[AWL=-0.154, 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 sbCQn-basZ6q; Mon, 30 Jan 2012 15:44:32 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 35A1B11E80F3; Mon, 30 Jan 2012 15:44:31 -0800 (PST)
Received: from mail196-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Mon, 30 Jan 2012 23:44:30 +0000
Received: from mail196-ch1 (localhost [127.0.0.1])	by mail196-ch1-R.bigfish.com (Postfix) with ESMTP id 3A37F1001DE; Mon, 30 Jan 2012 23:44:30 +0000 (UTC)
X-SpamScore: -31
X-BigFish: VS-31(zz9371I542M1432Nzz1202hzz1033IL8275eh8275bh8275dha1495iz2fhc1bhc31hc1ah2a8h668h839h944h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail196-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail196-ch1 (localhost.localdomain [127.0.0.1]) by mail196-ch1 (MessageSwitch) id 1327967067958276_25145; Mon, 30 Jan 2012 23:44:27 +0000 (UTC)
Received: from CH1EHSMHS006.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.233])	by mail196-ch1.bigfish.com (Postfix) with ESMTP id DC425380048;	Mon, 30 Jan 2012 23:44:27 +0000 (UTC)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 30 Jan 2012 23:44:27 +0000
Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0247.005; Mon, 30 Jan 2012 15:44:01 -0800
From: Mike Jones 
To: Franklin Tse , "oauth@ietf.org" , "ietf@ietf.org" , "iesg@ietf.org" 
Subject: RE: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -16
Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -16
Thread-Index: Aczfh0f3Dd/+wXTgQaiZVcyGxsaUGwARn6gAAAk13wA=
Date: Mon, 30 Jan 2012 23:44:00 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436638D3D7@TK5EX14MBXC284.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739436638D04A@TK5EX14MBXC284.redmond.corp.microsoft.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.37]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 23:44:34 -0000

I suspect that's up to the RFC editor.  There are no normative uses of thes=
e specifications because Bearer uses the HTTPbis specifications.

				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of F=
ranklin Tse
Sent: Monday, January 30, 2012 12:07 PM
To: oauth@ietf.org; ietf@ietf.org; iesg@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -16

Hello,

Just noticed that RFC2616 and RFC2617 are put under Informative References =
but are only referenced in Document History. Will they be removed before pu=
blication as an RFC?

Regards,
Franklin

--------------------------------------------------
From: "Mike Jones" 
Date: Tuesday, 31 January, 2012 03:42
To: ; ; 
Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -16

> Draft 16 of the OAuth 2.0 Bearer Token Specification has been published.  This version contai=
ns a proposed resolution to the auth-param syntax issue that has been revie=
wed by Julian Reschke, Mark Nottingham, and the OAuth WG chairs.  It also a=
ddresses the Gen-ART review comments by Alexey Melnikov.
>=20
> It contains the following changes:
>=20
>  *   Use the HTTPbis auth-param syntax for Bearer challenge attributes.
>  *   Dropped the sentence "The realm value is intended for programmatic u=
se and is not meant to be displayed to end users".
>  *   Reordered form-encoded body parameter description bullets for better=
 readability.
>  *   Added [USASCII] reference.
>=20
> The draft is available at:
>=20
> *         http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-16
> A HTML-formatted version is available at:
>=20
> *         http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-16.html
>=20
>                                                            -- Mike
>=20
>



> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



From cgrundemann@gmail.com  Mon Jan 30 15:58:04 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D524911E8100 for ; Mon, 30 Jan 2012 15:58:02 -0800 (PST)
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 dLkzDvzyiW0N for ; Mon, 30 Jan 2012 15:58:00 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 895B911E80FF for ; Mon, 30 Jan 2012 15:58:00 -0800 (PST)
Received: by pbdy7 with SMTP id y7so115498pbd.31 for ; Mon, 30 Jan 2012 15:58:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=PX8RSiCIi4MKnb7uifnzggrPAkIiRe7DwVVbUABKb+s=; b=tgMp9AxPwgpkRmycW7+Bkm7wIpSB1WZWCmPWQdMqsbbReC6BuqHyovdpiS+WfB56DB ebR61QTYY1zTh4NBKPZ3Or6wi+Ur02C7Za8o/NRMs6BkyB3Cg6I7yIxHX2MQETsH9OOj RPfHz/qBoGUSCpWRwitFG1XIKCVs2gG6lyBvY=
MIME-Version: 1.0
Received: by 10.68.141.111 with SMTP id rn15mr45341933pbb.76.1327967880338; Mon, 30 Jan 2012 15:58:00 -0800 (PST)
Received: by 10.143.60.13 with HTTP; Mon, 30 Jan 2012 15:58:00 -0800 (PST)
In-Reply-To: <20120130230332.4239.59749.idtracker@ietfa.amsl.com>
References: <20120130230332.4239.59749.idtracker@ietfa.amsl.com>
Date: Mon, 30 Jan 2012 16:58:00 -0700
Message-ID: 
Subject: Re: Last Call:  (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Chris Grundemann 
To: ietf@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jan 2012 23:58:04 -0000

I still fully support this draft and encourage the IESG to move it forward.

Thanks,
~Chris


On Mon, Jan 30, 2012 at 16:03, The IESG  wrote:
>
> The IESG has received a request from an individual submitter to consider =
the following document:
> - 'IANA Reserved IPv4 Prefix for Shared CGN Space'
> =A0 as a BCP
>
> On its December 15, 2011 telechat, the IESG reviewed version 10 of this
> document and requested various changes. These changes are reflected in
> the draft version 14 and the IESG now solicits community input on the
> changed text only. Please send substantive comments to the ietf@ietf.org
> mailing lists by 2012-02-16. Exceptionally, comments may be sent to
> iesg@ietf.org instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
> =A0This document requests the allocation of an IPv4 /10 address block to
> =A0be used as Shared Address Space to accommodate the needs of Carrier
> =A0Grade Network Address Translation (CGN) devices. =A0It is anticipated
> =A0that Service Providers will use this Shared Address Space to number
> =A0the interfaces that connect CGN devices to Customer Premise Equipment
> =A0(CPE).
>
> =A0Shared Address Space is distinct from RFC1918 private address space
> =A0because it is intended for use on Service Provider networks.
> =A0However, it may be used as RFC 1918 private address space in certain
> =A0circumstances. =A0Details are provided in the text of this document.
>
> =A0As this document proposes the allocation of an additional special-use
> =A0IPv4 address block, it updates RFC 5735.
>
> The following text captures the most salient change between version 10 an=
d 14 of this document:
>
> =A0Shared Address Space is IPv4 address space designated for Service
> =A0 =A0 Provider use with the purpose of facilitating CGN deployment. =A0=
Also,
> =A0 =A0 Shared Address Space can be used as additional [RFC1918] space wh=
en
> =A0 =A0 at least one of the following conditions is true:
>
> =A0 =A0 o =A0Shared Address Space is not also used on the Service Provide=
r side
> =A0 =A0 =A0 =A0of the CPE.
>
> =A0 =A0 o =A0CPE routers behave correctly when using the same address blo=
ck on
> =A0 =A0 =A0 =A0both the internal and external interfaces.
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-reques=
t/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-reques=
t/
>
>
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce



--=20
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.theIPv6experts.net
www.coisoc.org

From brian.e.carpenter@gmail.com  Mon Jan 30 17:51:25 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86AC01F0C48 for ; Mon, 30 Jan 2012 17:51:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.413
X-Spam-Level: 
X-Spam-Status: No, score=-103.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, 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 dUVHGngbc6bp for ; Mon, 30 Jan 2012 17:51:24 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 963001F0C44 for ; Mon, 30 Jan 2012 17:51:24 -0800 (PST)
Received: by werm10 with SMTP id m10so4484354wer.31 for ; Mon, 30 Jan 2012 17:51:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aHBr3YimW8WtL04ncz/EzbKqW4dINeXMPsrnihTXzic=; b=X7rgl/LSowmqSdX6vMw2zuqttySqDHTWjHYBHKlTqaNts7GXz4sRKycNRInr+CEJBv MOPdHWPD8lSG7QMl1Q+cPkSQeqsB5YtY8HH29zK9ujTsQo5l1XeyKiPbbZ3+vSIfLf5k 8x/VRKP5cHNMDYUGj3k35j0FOM7VS4YaX9Rdg=
Received: by 10.216.139.97 with SMTP id b75mr137848wej.0.1327974683689; Mon, 30 Jan 2012 17:51:23 -0800 (PST)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id q7sm34141639wix.5.2012.01.30.17.51.21 (version=SSLv3 cipher=OTHER); Mon, 30 Jan 2012 17:51:23 -0800 (PST)
Message-ID: <4F274916.1020902@gmail.com>
Date: Tue, 31 Jan 2012 14:51:18 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Last Call:  (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
References: <20120130230332.4239.59749.idtracker@ietfa.amsl.com>
In-Reply-To: <20120130230332.4239.59749.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 01:51:25 -0000

Hi,

>      Shared Address Space is IPv4 address space designated for Service
>      Provider use with the purpose of facilitating CGN deployment.  Also,
>      Shared Address Space can be used as additional [RFC1918] space when
>      at least one of the following conditions is true:
> 
>      o  Shared Address Space is not also used on the Service Provider side
>         of the CPE.
> 
>      o  CPE routers behave correctly when using the same address block on
>         both the internal and external interfaces.

I see that this change is in response to an IESG comment, but I think it's
a mistake. Encouraging sites to use yet more ambiguous address space based
on conditions that they may not even understand, or that may change when they
switch ISPs or replace CPEs, seems wrong.

    Brian

From alexey.melnikov@isode.com  Tue Jan 31 02:33:46 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DBF21F8598; Tue, 31 Jan 2012 02:33:46 -0800 (PST)
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 MacxjZXKurAQ; Tue, 31 Jan 2012 02:33:45 -0800 (PST)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0566F21F8456; Tue, 31 Jan 2012 02:33:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1328006023; d=isode.com; s=selector; i=@isode.com; bh=wymAVhwEHKfcP6NkNNrsdP98i5LC6+9c9122TL72YGM=; 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=YMiGNeogKBq/nO7j/gY9Qu22ttPm4GzouC+7uKFW3qgrQNwZLF69l4a//QvZUtcSErWacq iTT+MlssW0DkUCb4seE3T6+1jjEIgu84OWChvd4dtH8wYUfq/k1R3xcsA82axc2FkHoFAD X888fCT/IXJN8YCTsxr976pT2sW35HU=;
Received: from [188.29.102.51] (188.29.102.51.threembb.co.uk [188.29.102.51])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Tue, 31 Jan 2012 10:33:39 +0000
Message-ID: <4F27C37C.1090008@isode.com>
Date: Tue, 31 Jan 2012 10:33:32 +0000
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
To: Mike Jones 
Subject: Re: Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt
References: <4F2575CE.9040001@isode.com> <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: General Area Review Team , "oauth@ietf.org" , "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" , IETF-Discussion Discussion 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 10:33:46 -0000

On 30/01/2012 05:20, Mike Jones wrote:
> Thanks for your useful feedback, Alexey.
Hi Mike,
>    Below, I'll respond to each of your comments.  I've also added the O=
Auth working group to the thread, so they are aware of them as well and c=
an participate in the discussion.
>
> About your first issue with the WWW-Authenticate ABNF, I am already wor=
king with Julian, Mark Nottingham, and the chairs to resolve this issue. =
 Expect to see a proposal for review by the working group shortly.
Ok, I will have a look.
> About your comments on scope:  OAuth 2.0 (both the Core and Bearer spec=
s) is designed to be deployed in diverse and non-interoperable applicatio=
n contexts, meeting a variety of application needs.  In those various set=
tings, which are often distinct and potentially non-interoperable, parame=
ters such as scope, realm, etc. may have very different meanings.  This i=
s not a bug; it is a feature, because it allows the OAuth pattern to meet=
 the needs of numerous, often distinct, application environments.  For th=
at reason, a registry of scope (or realm) parameters would be ill-advised=
 and counterproductive.  It's perfectly OK and expected for a scope value=
 such as "email" to have one meaning in one application context and a dif=
ferent meaning in a different, but distinct application context.  Trying =
to impose a single meaning on particular scope values across distinct app=
lication contexts is both unnecessary and could break many existing deplo=
yments.  That being said, we fully expect
> interoperability profiles to emerge that define interoperable sets of s=
cope values within particular application contexts.  (The OpenID Connect =
specifications are one such set of profiles.)  But these meanings will al=
ways be context-specific - not global in scope.
The way "scope" is currently defined in the document is completely=20
useless. You don't have a single example in the document. You don't say=20
how the semantics of the value differs from realm. You don't say that=20
its values are deployment specific and can be profiled in future=20
documents. Please say something about these issues in the document (your =

explanation above would work.)
> About your first minor issue, I'll reorder the bullets so the statement=
 about the entity-body being single part is followed by the statement abo=
ut it using application/x-www-form-urlencoded, so they will be read toget=
her.
Ok.
> About your second minor issue on error codes, the error codes registry =
already exists, but is in the OAuth Core spec.  Seehttp://tools.ietf.org/=
html/draft-ietf-oauth-v2-23#section-11.4.
Can you please make this clear in the document (by adding a reference)?
> About your third minor issue on RFC 6125 versus RFC 2818, you'll find t=
hat, per the history entries, a previous reference to RFC 2818 was change=
d to RFC 6125 in draft 14 at the request of Security Area Director Stephe=
n Farrell.  If you'd like to see this reference reintroduced, I'd request=
 that you work with Stephen on specific alternative proposed wording that=
 is acceptable to both of you.
Ok, I can work with Stephen and Peter Saint-Andre (RFC 6125 co-author) on=
 some text.

> Finally, I'll address both of your nits in the manner you suggested.
These are fixed in -16, thanks.
>
> 				Thanks again,
> 				-- Mike
>
> -----Original Message-----
> From:ietf-bounces@ietf.org  [mailto:ietf-bounces@ietf.org] On Behalf Of=
 Alexey Melnikov
> Sent: Sunday, January 29, 2012 8:38 AM
> To: General Area Review Team; IETF-Discussion Discussion;draft-ietf-oau=
th-v2-bearer.all@tools.ietf.org
> Subject: Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt
>
> I am the assigned Gen-ART reviewer for this draft. For background on Ge=
n-ART, please see the FAQ at.
>
> Please resolve these comments along with any other Last Call comments y=
ou may receive.
>
> Document: draft-ietf-oauth-v2-bearer-15.txt
> Reviewer: Alexey Melnikov
> Review Date: 29 Jan 2012
> IETF LC End Date: 7 Feb 2012
> IESG Telechat date: (if known) -
>
> Summary: Mostly ready, with a couple of things that should be addressed=
=2E
>
> Major Issues:
>
> I have 2 issues in section 3:
>
> 3.  The WWW-Authenticate Response Header Field
>
>      If the protected resource request does not include authentication
>      credentials or does not contain an access token that enables acces=
s
>      to the protected resource, the resource server MUST include the HT=
TP
>      "WWW-Authenticate" response header field; it MAY include it in
>      response to other conditions as well.  The "WWW-Authenticate" head=
er
>      field uses the framework defined by HTTP/1.1, Part 7
>      [I-D.ietf-httpbis-p7-auth] as follows:
>
>      challenge       =3D "Bearer" [ 1*SP 1#param ]
>
>      param           =3D realm / scope /
>                        error / error-desc / error-uri /
>                        auth-param
>
>      scope           =3D "scope" "=3D" quoted-string
>      error           =3D "error" "=3D" quoted-string
>      error-desc      =3D "error_description" "=3D" quoted-string
>      error-uri       =3D "error_uri" "=3D" quoted-string
>
> 1). I am agreeing with Julian about redefinition of ABNF from HTTPBis d=
ocuments. I believe there is a proposal to fix that but the new draft has=
n't been posted yet.
>
> 2). My 2nd major issue is about the following paragraph:
>
>      The "scope" attribute is a space-delimited list of scope values
>      indicating the required scope of the access token for accessing th=
e
>      requested resource.  In some cases, the "scope" value will be used=

>      when requesting a new access token with sufficient scope of access=
 to
>      utilize the protected resource.  The "scope" attribute MUST NOT
>      appear more than once.  The "scope" value is intended for
>      programmatic use and is not meant to be displayed to end users.
>
> I don't think this provide enough information about what this is, how i=
t is to be used and which values are allowed. As this is not meant to be =
displayed to end users, then you need to say what values are allowed and =
which entity can allocate them. Is there a registry for these tokens, e.g=
=2E an IANA registry?
>
>
> Minor Issues:
>
> 1).
> 2.2.  Form-Encoded Body Parameter
>
>      When sending the access token in the HTTP request entity-body, the=

>      client adds the access token to the request body using the
>      "access_token" parameter.  The client MUST NOT use this method unl=
ess
>      all of the following conditions are met:
>
>      o  The HTTP request entity-body is single-part.
>
>      o  The entity-body follows the encoding requirements of the
>         "application/x-www-form-urlencoded" content-type as defined by
>         HTML 4.01 [W3C.REC-html401-19991224].
>
>      o  The HTTP request entity-header includes the "Content-Type" head=
er
>         field set to "application/x-www-form-urlencoded".
>
> I would combine the first and the third bullet into a single statement,=
 because they seem to be a bit confusing while being read separately.
> (I.e., is it possible to have Content-Type of "application/x-www-form-u=
rlencoded" with something which is multipart?)
>
> 2).
> Section "3.1.  Error Codes"
>
> I recommend creating an IANA registry for these or explain why one is n=
ot needed.
>
> 3).
> 4.2.  Threat Mitigation
>
>      To protect against token disclosure, confidentiality protection MU=
ST
>      be applied using TLS [RFC5246] with a ciphersuite that provides
>      confidentiality and integrity protection.  This requires that the
>      communication interaction between the client and the authorization=

>      server, as well as the interaction between the client and the
>      resource server, utilize confidentiality and integrity protection.=

>      Since TLS is mandatory to implement and to use with this
>      specification, it is the preferred approach for preventing token
>      disclosure via the communication channel.  For those cases where t=
he
>      client is prevented from observing the contents of the token, toke=
n
>      encryption MUST be applied in addition to the usage of TLS
>      protection.  As a further defense against token disclosure, the
>      client MUST validate the TLS certificate chain when making request=
s
>      to protected resources.
>
> and
>
>      To deal with token capture and replay, the following recommendatio=
ns
>      are made: First, the lifetime of the token MUST be limited; one me=
ans
>      of achieving this is by putting a validity time field inside the
>      protected part of the token.  Note that using short-lived (one hou=
r
>      or less) tokens reduces the impact of them being leaked.  Second,
>      confidentiality protection of the exchanges between the client and=

>      the authorization server and between the client and the resource
>      server MUST be applied.  As a consequence, no eavesdropper along t=
he
>      communication path is able to observe the token exchange.
>      Consequently, such an on-path adversary cannot replay the token.
>      Furthermore, when presenting the token to a resource server, the
>      client MUST verify the identity of that resource server, as per
>      Representation and Verification of Domain-Based Application Servic=
e
>      Identity within Internet Public Key Infrastructure Using X.509 (PK=
IX)
>      Certificates in the Context of Transport Layer Security (TLS)
>      [RFC6125].
>
> Firstly, I would move the RFC 6125 reference to the first paragraph quo=
ted above (but see below). Secondly, you should either normatively refere=
nce RFC 2818 (HTTP over TLS) instead of RFC 6125, or you need to provide =
more information about how RFC 6125 is to be used, because it has several=
 options which need to be described (use of SRV-IDs, URI-IDs, DNS-IDs, us=
e of wildcards). I suspect you should just reference RFC 2818.
>
>
> Nits:
>
> 2.2.  Form-Encoded Body Parameter
>
>      o  The content to be encoded in the entity-body MUST consist entir=
ely
>         of ASCII characters.
>
> ASCII needs a reference.
>
>
> ID-nits reports:
>
>     =3D=3D The document seems to lack the recommended RFC 2119 boilerpl=
ate, even if
>        it appears to use RFC 2119 keywords -- however, there's a paragr=
aph with
>        a matching beginning. Boilerplate error?
>
>        (The document does seem to have the reference to RFC 2119 which =
the
>        ID-Checklist requires).
>     =3D=3D Using lowercase 'not' together with uppercase 'MUST', 'SHALL=
', 'SHOULD',
>        or 'RECOMMENDED' is not an accepted usage according to RFC 2119.=

> Please
>        use uppercase 'NOT' together with RFC 2119 keywords (if that is =
what you
>        mean).
>
> and:
>
>        Found 'MUST not' in this paragraph:
>
>        o  Stated that bearer tokens MUST not be stored in cookies that =
can
>        be sent in the clear in the Threat Mitigation section.
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
>




From olaf@NLnetLabs.nl  Tue Jan 31 07:59:22 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC5F21F8517; Tue, 31 Jan 2012 07:59:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level: 
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.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 mOLpHx6v8U2v; Tue, 31 Jan 2012 07:59:21 -0800 (PST)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2476E21F8539; Tue, 31 Jan 2012 07:59:20 -0800 (PST)
Received: from [192.168.1.129] ([173.226.66.170]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q0VFxAcR022360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 Jan 2012 16:59:12 +0100 (CET) (envelope-from olaf@NLnetLabs.nl)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1328025555; bh=sU36pK0fOwNICtO9bs4CnB0WyZEIc6JeHa9FWNzmREc=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=uqv9Pkf3o8ioLDKN0qBZXhKx75xZm0K6bMtQ1GZzcTW/+3CfAXvtzri+jIV21Z8So jUuCXJfZX76jXcufm+bcr0se8jqHwqYv4uNCtbMsMs4MJmFL0eneVl/bnhrN7rAti0 uRFPdtCuBsIQCK6twFkxlH4i496sBX7QR0jgSFxc=
Subject: Re: T-Shirt Design Contest for IETF 83 Paris
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: multipart/signed; boundary="Apple-Mail=_A2333169-754D-466F-B8C9-AB4153977A5E"; protocol="application/pgp-signature"; micalg=pgp-sha1
From: Olaf Kolkman 
In-Reply-To: <1BD9C39B-DCC2-4978-BAD2-8802CAC015F7@amsl.com>
Date: Tue, 31 Jan 2012 10:59:09 -0500
Message-Id: <56ED8BDC-B5A5-4931-9020-63DF2548C127@NLnetLabs.nl>
References: <1BD9C39B-DCC2-4978-BAD2-8802CAC015F7@amsl.com>
To: Alexa Morris 
X-Mailer: Apple Mail (2.1251.1)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Tue, 31 Jan 2012 16:59:13 +0100 (CET)
Cc: IETF-Discussion list , ietf-announce@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 15:59:22 -0000

--Apple-Mail=_A2333169-754D-466F-B8C9-AB4153977A5E
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii



I hope a T-Shirt will feature my favorite French hero.... Super Dupont

http://en.wikipedia.org/wiki/Superdupont

--Olaf

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
http://www.nlnetlabs.nl/











     


--Apple-Mail=_A2333169-754D-466F-B8C9-AB4153977A5E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)

iQIcBAEBAgAGBQJPKA/NAAoJEFRqER47aqpkBEgP/0Wmwiyilh/J1jZMXT8/mvID
YukEJ3brPXbu4Pfwnl4md23N+2UMNVy4DhsJTI4/6dvxMpMXu7gNHPnR7On4VR+r
KN3u28oc00Au6EEI4qsragZgGBH0oDSO+qVcJlJOlM1saPrfmpougLVukd4l9wds
hwxH/NZtFTPQ09xJICZZvk+RBwM5SFpnyOM0hGpPVITrOsIkElWaUZ+2DRMXSKuB
hizEavgpWaB/vOQdrvTp9R/yVQxJ35QQLmW0M+3Ll87GHPYyn6PK3OyU9r35GJ/n
PznsdNciYGtCA2o50R+zJY4YpcofRhaBhjRAwo6TZDlt72zsZxkgY0dNwg4qPB5E
Sau0W78GiHLIiGFTYSHga5tIKUmvxdhyRKTOULvnxxP22Od2h2eHpH4tw8HVbuWu
v5gLRF9d3I5bGciloKoPnqadB8xrIWMpm8Mb34g3kg+2STJd43/zk5Ur8rNQgL4h
hZREJWW3iTLlPoXPW04BeplpsXYNGnac3fXqk0EnUSoq/Rg0ImJY3FV5kvYiiTYW
7UFvcZFJKbm1kfp9csTH2tf6jLnZFr1sH29GRteUEgO7uPKiCC27HWMANHLuhcvK
Bze0ykBZy4ZQUeO98r4cZVfEbelDbNzTnIz+j1tjz3AzqE6m+HFpDdpaoa0oSDVG
pkHNYP/eR66h1z3b/AQ2
=g2ak
-----END PGP SIGNATURE-----

--Apple-Mail=_A2333169-754D-466F-B8C9-AB4153977A5E--

From wesley.george@twcable.com  Tue Jan 31 09:20:02 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E619621F85E5 for ; Tue, 31 Jan 2012 09:20:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.471
X-Spam-Level: 
X-Spam-Status: No, score=-0.471 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
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 IcingZDSdQiX for ; Tue, 31 Jan 2012 09:20:02 -0800 (PST)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id F033921F85DB for ; Tue, 31 Jan 2012 09:20:01 -0800 (PST)
X-SENDER-IP: 10.136.163.11
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.71,596,1320642000"; d="scan'208";a="315441578"
Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 31 Jan 2012 12:19:06 -0500
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Tue, 31 Jan 2012 12:19:45 -0500
From: "George, Wes" 
To: "ietf@ietf.org" 
Date: Tue, 31 Jan 2012 12:19:44 -0500
Subject: RE: Last Call:  (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Thread-Topic: Last Call:  (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Thread-Index: Aczfo3TH+sRwNSP1TCuW3loAn4+bAwAmIMNQ
Message-ID: 
References: <20120130230332.4239.59749.idtracker@ietfa.amsl.com>
In-Reply-To: <20120130230332.4239.59749.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 17:20:03 -0000

I've been recommending this direction (that this is basically just more pri=
vate space, no magic) for some time, so I support the change.

However, I strongly believe that the document should formally update RFC191=
8, not just 5735, especially now that it specifically says that in certain =
circumstances the space can be used as 1918 space. Having the linkage betwe=
en the documents (from 1918 to this one, instead of just in the other direc=
tion) is quite important, IMO.

Wes George


> -----Original Message-----
> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.o=
rg]
> On Behalf Of The IESG
> Sent: Monday, January 30, 2012 6:04 PM
> To: IETF-Announce
> Subject: Last Call:  (=
IANA
> Reserved IPv4 Prefix for Shared Address Space) to BCP
>
>
> The IESG has received a request from an individual submitter to consider =
the
> following document:
> - 'IANA Reserved IPv4 Prefix for Shared CGN Space'
>   as a BCP
>
> On its December 15, 2011 telechat, the IESG reviewed version 10 of this
> document and requested various changes. These changes are reflected in
> the draft version 14 and the IESG now solicits community input on the
> changed text only. Please send substantive comments to the ietf@ietf.org
> mailing lists by 2012-02-16. Exceptionally, comments may be sent to
> iesg@ietf.org instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>   This document requests the allocation of an IPv4 /10 address block to
>   be used as Shared Address Space to accommodate the needs of Carrier
>   Grade Network Address Translation (CGN) devices.  It is anticipated
>   that Service Providers will use this Shared Address Space to number
>   the interfaces that connect CGN devices to Customer Premise Equipment
>   (CPE).
>
>   Shared Address Space is distinct from RFC1918 private address space
>   because it is intended for use on Service Provider networks.
>   However, it may be used as RFC 1918 private address space in certain
>   circumstances.  Details are provided in the text of this document.
>
>   As this document proposes the allocation of an additional special-use
>   IPv4 address block, it updates RFC 5735.
>
> The following text captures the most salient change between version 10 an=
d 14
> of this document:
>
>   Shared Address Space is IPv4 address space designated for Service
>      Provider use with the purpose of facilitating CGN deployment.  Also,
>      Shared Address Space can be used as additional [RFC1918] space when
>      at least one of the following conditions is true:
>
>      o  Shared Address Space is not also used on the Service Provider sid=
e
>         of the CPE.
>
>      o  CPE routers behave correctly when using the same address block on
>         both the internal and external interfaces.
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-reques=
t/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-reques=
t/
>
>
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

From marshall.eubanks@gmail.com  Tue Jan 31 09:35:05 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8001611E8085 for ; Tue, 31 Jan 2012 09:35:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.515
X-Spam-Level: 
X-Spam-Status: No, score=-103.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, 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 g6qms1U6HqNI for ; Tue, 31 Jan 2012 09:35:04 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC02811E8080 for ; Tue, 31 Jan 2012 09:35:04 -0800 (PST)
Received: by obbwd15 with SMTP id wd15so239377obb.31 for ; Tue, 31 Jan 2012 09:35:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=7vLJEjuw7rbHweOXlQAlhLWu58hZ06BNbjv6bjPySS0=; b=RT2K32caoRVAvoO/RmQEoaRMe4nCu8VTVPye7hwph/3/AFW1090TJYquz2oUqz+rQh 1NZ94kddViupmUQpQIgvNd+seXLyrJi9ye4CMNCEe+TLS8ySK6UIzNgwH6IpCvuExisf P43qNr8mHicY2kOT928sGDSNuBmhqjxkgS0jg=
MIME-Version: 1.0
Received: by 10.182.47.10 with SMTP id z10mr36101772obm.19.1328031304343; Tue, 31 Jan 2012 09:35:04 -0800 (PST)
Received: by 10.182.52.134 with HTTP; Tue, 31 Jan 2012 09:35:04 -0800 (PST)
In-Reply-To: <56ED8BDC-B5A5-4931-9020-63DF2548C127@NLnetLabs.nl>
References: <1BD9C39B-DCC2-4978-BAD2-8802CAC015F7@amsl.com> <56ED8BDC-B5A5-4931-9020-63DF2548C127@NLnetLabs.nl>
Date: Tue, 31 Jan 2012 12:35:04 -0500
Message-ID: 
Subject: Re: T-Shirt Design Contest for IETF 83 Paris
From: Marshall Eubanks 
To: Olaf Kolkman 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: IETF-Discussion list 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 17:35:05 -0000

On Tue, Jan 31, 2012 at 10:59 AM, Olaf Kolkman  wrote:
>
>
> I hope a T-Shirt will feature my favorite French hero.... Super Dupont
>

And, for myself, I think that Hubert Bonisseur de La Bath (AKA OSS
117) would be perfect proxy IETFer. I can imagine
the line at the mike now.

Regards
Marshall


> http://en.wikipedia.org/wiki/Superdupont
>
> --Olaf
>
> ________________________________________________________
>
> Olaf M. Kolkman =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0NLnet Labs
> http://www.nlnetlabs.nl/
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>

From jnc@mercury.lcs.mit.edu  Tue Jan 31 09:40:19 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805D411E80E3 for ; Tue, 31 Jan 2012 09:40:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.8
X-Spam-Level: 
X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[AWL=1.800, 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 BXSZei2KfrPf for ; Tue, 31 Jan 2012 09:40:18 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id C1FF211E8080 for ; Tue, 31 Jan 2012 09:40:18 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0032318C0DD; Tue, 31 Jan 2012 12:40:17 -0500 (EST)
To: ietf@ietf.org
Subject: RE: Last Call:  (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Message-Id: <20120131174018.0032318C0DD@mercury.lcs.mit.edu>
Date: Tue, 31 Jan 2012 12:40:17 -0500 (EST)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Cc: jnc@mercury.lcs.mit.edu
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 17:40:19 -0000

    > From: "George, Wes" 

    > I've been recommending this direction (that this is basically just more
    > private space, no magic)

Is that wise? I thought (IIRC, and maybe I'm spacing) the whole reason for
allocating this space was that 1918 space _couldn't_ easily be used for CGN
because there were too many conflicting usages. So, now we're making more 1918
space? This is a good idea... how? If we need more 1918 space, let's do so
deliberately, and not kill the usefulness of this space for CGN. (Unless, of
course...)

	Noel

From wesley.george@twcable.com  Tue Jan 31 09:59:03 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1453121F8625 for ; Tue, 31 Jan 2012 09:59:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.971
X-Spam-Level: 
X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[AWL=0.492,  BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 xTlgKgiUY6yT for ; Tue, 31 Jan 2012 09:59:02 -0800 (PST)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 78DEC21F8622 for ; Tue, 31 Jan 2012 09:59:02 -0800 (PST)
X-SENDER-IP: 10.136.163.13
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.71,597,1320642000"; d="scan'208";a="331710559"
Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 31 Jan 2012 12:58:36 -0500
Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Tue, 31 Jan 2012 12:59:01 -0500
From: "George, Wes" 
To: Noel Chiappa , "ietf@ietf.org" 
Date: Tue, 31 Jan 2012 12:59:00 -0500
Subject: RE: Last Call:  (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Thread-Topic: Last Call:  (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Thread-Index: AczgP20Fchbvuqo2SkyqieklET+8KAAAYMFg
Message-ID: 
References: <20120131174018.0032318C0DD@mercury.lcs.mit.edu>
In-Reply-To: <20120131174018.0032318C0DD@mercury.lcs.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 17:59:03 -0000

> From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]
>
> Is that wise? I thought (IIRC, and maybe I'm spacing) the whole reason fo=
r
> allocating this space was that 1918 space _couldn't_ easily be used for C=
GN
> because there were too many conflicting usages.
[WEG] yes, but the general sense I got from the ensuing discussion was that=
 no one expects anyone to actually adhere to that advice (ie MUST NOT be us=
ed as substitute for 1918 space), and as soon as the space is released, it'=
ll be "cats and dogs living together, mass hysteria..." because everyone an=
d their cousin will start using it as 1918-bis anyway, no matter whether th=
e IETF wags their fingers at them or not.

> So, now we're making more 1918 space? This is a good idea... how? If we n=
eed more 1918 space, let's do so
> deliberately, and not kill the usefulness of this space for CGN. (Unless,=
 of
> course...)
>
[WEG] I think it provides a window of opportunity - get in before the place=
 gets busy. Hopefully by the time people have really adopted the space for =
1918-type uses, working IPv4 CGN will be of less relevance... or at least t=
hat's what I'm telling myself. This just acknowledges what people believe t=
o be the case instead of trying to deny that it'll happen.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable propri=
etary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the u=
se of the individual or entity to which it is addressed. If you are not the=
 intended recipient of this E-mail, you are hereby notified that any dissem=
ination, distribution, copying, or action taken in relation to the contents=
 of and attachments to this E-mail is strictly prohibited and may be unlawf=
ul. If you have received this E-mail in error, please notify the sender imm=
ediately and permanently delete the original and any copy of this E-mail an=
d any printout.

From Jean-Francois.TremblayING@videotron.com  Tue Jan 31 09:59:32 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3234821F8635 for ; Tue, 31 Jan 2012 09:59:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 zIe-6VSLOjwi for ; Tue, 31 Jan 2012 09:59:31 -0800 (PST)
Received: from mx01.videotron.com (mx01.videotron.com [24.201.243.152]) by ietfa.amsl.com (Postfix) with ESMTP id 98DBF21F8627 for ; Tue, 31 Jan 2012 09:59:31 -0800 (PST)
In-Reply-To: <20120131174018.0032318C0DD@mercury.lcs.mit.edu>
To: ietf@ietf.org
Subject: RE: Last Call: 	(IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
MIME-Version: 1.0
X-KeepSent: CC24D42E:650FA7C3-85257996:00627C8B; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006
Message-ID: 
From: Jean-Francois.TremblayING@videotron.com
Date: Tue, 31 Jan 2012 12:59:25 -0500
X-MIMETrack: Serialize by Router on DOMMSG01/SRV/GVL(Release 8.5.2FP2|March 22, 2011) at 01/31/2012 12:59:25, Serialize complete at 01/31/2012 12:59:25
Content-Type: multipart/alternative; boundary="=_alternative 0062D30D85257996_="
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 17:59:32 -0000

Message en plusieurs parties au format MIME
--=_alternative 0062D30D85257996_=
Content-Type: text/plain; charset="US-ASCII"

> I thought (IIRC, and maybe I'm spacing) the whole reason for
> allocating this space was that 1918 space _couldn't_ easily be used for 
CGN
> because there were too many conflicting usages. So, now we're making 
more 1918
> space? This is a good idea... how? If we need more 1918 space, let's do 
so
> deliberately, and not kill the usefulness of this space for CGN. 
(Unless, of
> course...)
>                Noel

+1 on this and Brian's comment. 

While I still support this draft, the wording in section 4 is probably too 
soft and reduces a lot the usefulness of this adressing space. 

/JFT

--=_alternative 0062D30D85257996_=
Content-Type: text/html; charset="US-ASCII"



      > I thought (IIRC, and maybe I'm spacing) the whole
reason for
      
> allocating this space was that 1918 space _couldn't_ easily be used
for CGN
      
> because there were too many conflicting usages. So, now we're making
more 1918
      
> space? This is a good idea... how? If we need more 1918 space, let's
do so
      
> deliberately, and not kill the usefulness of this space for CGN. (Unless,
of
      
> course...)
      
>                  Noel      

      

      +1 on this and Brian's comment. 

      

      While I still support this draft, the wording in section
4 is probably too soft and reduces a lot the usefulness of this adressing
space. 

      

      /JFT

      
--=_alternative 0062D30D85257996_=--

From presnick@qualcomm.com  Tue Jan 31 11:16:01 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A05E11E8097 for ; Tue, 31 Jan 2012 11:16:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.566
X-Spam-Level: 
X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 P-JV+atnQZtm for ; Tue, 31 Jan 2012 11:16:00 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 886CD11E8072 for ; Tue, 31 Jan 2012 11:16:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1328037360; x=1359573360; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F283D7F.2040207@qualcomm.com>|Date:=20Tu e,=2031=20Jan=202012=2013:14:07=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20"George,=20Wes"=20|CC:=20Noel=20Chiappa=20,=20"ietf@ietf.org"=20|Subject:=20R e:=20Last=20Call:=20=0D=0A=20(IANA=20Reserved=20IPv4=20Prefix =20for=20Shared=20Address=20Space)=20to=20BCP|References: =20<20120131174018.0032318C0DD@mercury.lcs.mit.edu>=20|In-Reply-To:=20|Content-Type: =20text/plain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Df lowed|Content-Transfer-Encoding:=207bit|X-Originating-IP: =20[172.30.48.1]; bh=rDmXPnEsMLHIrQJWIyMYsy0AQpkMkSCcmMVhti1aueM=; b=p9eElxfF16+AxdNRlKH7m0ok/+XxFq7SO403QOaMT9SKURyBQtLW2lU7 mBlKcvFVe5aLIQc1O4eImS92q4tnPCB+xa5tKZx5f3VxUzkl5lfX/eSYD VyB/A0KtTip9NR56jze5w9TPB8ElJmwZknMvQfJSO6tm4MbSjz7OldTnl E=;
X-IronPort-AV: E=McAfee;i="5400,1158,6606"; a="159397807"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 31 Jan 2012 11:15:59 -0800
X-IronPort-AV: E=Sophos;i="4.71,596,1320652800"; d="scan'208";a="193295028"
Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 31 Jan 2012 11:15:59 -0800
Received: from Macintosh-4.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Tue, 31 Jan 2012 11:14:09 -0800
Message-ID: <4F283D7F.2040207@qualcomm.com>
Date: Tue, 31 Jan 2012 13:14:07 -0600
From: Pete Resnick 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: "George, Wes" 
Subject: Re: Last Call:  (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
References: <20120131174018.0032318C0DD@mercury.lcs.mit.edu> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.48.1]
Cc: Noel Chiappa , "ietf@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 19:16:01 -0000

On 1/31/12 11:59 AM, George, Wes wrote:
>> From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]
>>
>> Is that wise? I thought (IIRC, and maybe I'm spacing) the whole reason for
>> allocating this space was that 1918 space _couldn't_ easily be used for CGN
>> because there were too many conflicting usages.
>>      
> [WEG] yes, but the general sense I got from the ensuing discussion was that no one expects anyone to actually adhere to that advice (ie MUST NOT be used as substitute for 1918 space), and as soon as the space is released, it'll be "cats and dogs living together, mass hysteria..." because everyone and their cousin will start using it as 1918-bis anyway, no matter whether the IETF wags their fingers at them or not.
>    

Speaking as one of the bozos^h^h^h^h^h ADs whose comments (and suggested 
text) ended the document up here, let me suggest the slightly less 
pessimistic view from Wes's, and the reason that I think this 
*shouldn't* specifically update 1918:

This *is* a special use address block that is akin to 1918. It is 
non-routable address space, just like 1918. But unlike 1918, this block 
is defined as "might be used by your ISP on your outside interface". So, 
people using it inside their networks (which, I agree with Wes, will 
happen, and like everything else on the net, will be done stupidly by 
some) have been told that this is *not* private use space and that they 
use it at their own risk and their CGN service might stop working if 
they use it in a way not described in this document. But I'd hate for us 
to allocate space to "CGNs only" when it's obvious that this can be used 
for a whole class of these sorts of things, and can be used by other 
people who build sane equipment that understands "shared" addresses can 
appear on two different interfaces. These aren't "private" addresses a 
la 1918, they're "shared", so it's not an addition to that space. Let's 
properly document what it is we're doing, giving people fair warnings.

pr

-- 
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


From jnc@mercury.lcs.mit.edu  Tue Jan 31 11:33:47 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2BD11E8089 for ; Tue, 31 Jan 2012 11:33:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.699
X-Spam-Level: 
X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=0.900,  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 rUDk0P-nwmgy for ; Tue, 31 Jan 2012 11:33:42 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id ECEAB11E8080 for ; Tue, 31 Jan 2012 11:33:41 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 72C2A18C0DB; Tue, 31 Jan 2012 14:33:41 -0500 (EST)
To: ietf@ietf.org
Subject: Re: Last Call:  (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Message-Id: <20120131193341.72C2A18C0DB@mercury.lcs.mit.edu>
Date: Tue, 31 Jan 2012 14:33:41 -0500 (EST)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Cc: jnc@mercury.lcs.mit.edu
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 19:33:47 -0000

    > From: Pete Resnick 

    > I'd hate for us to allocate space to "CGNs only" when it's obvious
    > that this can be used for a whole class of these sorts of things,
    > and can be used by other people who build sane equipment that
    > understands "shared" addresses can appear on two different
    > interfaces. These aren't "private" addresses a la 1918, they're
    > "shared", so it's not an addition to that space.

Ah. That makes sense.

Now, as long as the document clearly says all that... :-)

	Noel

From brian.e.carpenter@gmail.com  Tue Jan 31 11:38:40 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D374711E811F for ; Tue, 31 Jan 2012 11:38:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.53
X-Spam-Level: 
X-Spam-Status: No, score=-103.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, 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 CyFSv4x4HoTA for ; Tue, 31 Jan 2012 11:38:40 -0800 (PST)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED65411E8112 for ; Tue, 31 Jan 2012 11:38:39 -0800 (PST)
Received: by wibhm9 with SMTP id hm9so354512wib.31 for ; Tue, 31 Jan 2012 11:38:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NT/CUYtcBIctSbj8sG050SgchtE9b5IqK8hi5oysSVg=; b=v2o1AsrfOHQeWYZAqZay3qkJUTDM2asACAvFsXT46fY04BvRYjm+tS2e7aDl2UpZVA V7iPMI+sSE+CTv/QddGNrDWilJ/ECbEZeBXgxQkbQJzmT+MxIbnKFHalJNzreGyo5BRG n5ZYsCNQZ7CxR/2ez3v0VBf34pFzTVv+V5euE=
Received: by 10.180.24.105 with SMTP id t9mr36676670wif.19.1328038718994; Tue, 31 Jan 2012 11:38:38 -0800 (PST)
Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id di5sm66017708wib.3.2012.01.31.11.38.35 (version=SSLv3 cipher=OTHER); Tue, 31 Jan 2012 11:38:38 -0800 (PST)
Message-ID: <4F28432E.6090209@gmail.com>
Date: Wed, 01 Feb 2012 08:38:22 +1300
From: Brian E Carpenter 
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Pete Resnick 
Subject: Re: Last Call:  (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
References: <20120131174018.0032318C0DD@mercury.lcs.mit.edu>	 <4F283D7F.2040207@qualcomm.com>
In-Reply-To: <4F283D7F.2040207@qualcomm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Noel Chiappa , "ietf@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 19:38:41 -0000

Hi Pete,

On 2012-02-01 08:14, Pete Resnick wrote:
> On 1/31/12 11:59 AM, George, Wes wrote:
>>> From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]
>>>
>>> Is that wise? I thought (IIRC, and maybe I'm spacing) the whole
>>> reason for
>>> allocating this space was that 1918 space _couldn't_ easily be used
>>> for CGN
>>> because there were too many conflicting usages.
>>>      
>> [WEG] yes, but the general sense I got from the ensuing discussion was
>> that no one expects anyone to actually adhere to that advice (ie MUST
>> NOT be used as substitute for 1918 space), and as soon as the space is
>> released, it'll be "cats and dogs living together, mass hysteria..."
>> because everyone and their cousin will start using it as 1918-bis
>> anyway, no matter whether the IETF wags their fingers at them or not.

I have no doubt that this space will be (mis)used as additional
private ambiguous address space. But IMHO the text should make it
clear that this is the wrong way to use it and give the reasons
why - basically the same information as in the new text, but stated
exactly the other way round. For example

     Shared Address Space is IPv4 address space designated for Service
     Provider use with the purpose of facilitating CGN deployment.
     Shared Address Space is not intended to be used as additional [RFC1918]
     space, because either or both of the following issues might arise:

     o  Shared Address Space could also be used on the Service Provider side
        of the CPE, with overlapping subnet or host addresses.

     o  Some CPE routers behave incorrectly when using the same address block on
        both the internal and external interfaces.

> Speaking as one of the bozos^h^h^h^h^h ADs whose comments (and suggested
> text) ended the document up here, let me suggest the slightly less
> pessimistic view from Wes's, and the reason that I think this
> *shouldn't* specifically update 1918:
> 
> This *is* a special use address block that is akin to 1918. It is
> non-routable address space, just like 1918. But unlike 1918, this block
> is defined as "might be used by your ISP on your outside interface". So,
> people using it inside their networks (which, I agree with Wes, will
> happen, and like everything else on the net, will be done stupidly by
> some) have been told that this is *not* private use space and that they
> use it at their own risk and their CGN service might stop working if
> they use it in a way not described in this document. But I'd hate for us
> to allocate space to "CGNs only" when it's obvious that this can be used
> for a whole class of these sorts of things, and can be used by other
> people who build sane equipment that understands "shared" addresses can
> appear on two different interfaces. These aren't "private" addresses a
> la 1918, they're "shared", so it's not an addition to that space. Let's
> properly document what it is we're doing, giving people fair warnings.

Exactly, hence my suggested text above.

   Brian

From Francis.Dupont@fdupont.fr  Tue Jan 31 13:09:36 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D91C21F867A; Tue, 31 Jan 2012 13:09:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level: 
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025,  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 C0VPteDOqRDX; Tue, 31 Jan 2012 13:09:35 -0800 (PST)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id B34C721F8679; Tue, 31 Jan 2012 13:09:34 -0800 (PST)
Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q0VL9TKU093344; Tue, 31 Jan 2012 22:09:29 +0100 (CET) (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201201312109.q0VL9TKU093344@givry.fdupont.fr>
From: Francis Dupont 
To: Olaf Kolkman 
Subject: Re: T-Shirt Design Contest for IETF 83 Paris 
In-reply-to: Your message of Tue, 31 Jan 2012 10:59:09 EST. <56ED8BDC-B5A5-4931-9020-63DF2548C127@NLnetLabs.nl> 
Date: Tue, 31 Jan 2012 22:09:29 +0100
Sender: Francis.Dupont@fdupont.fr
Cc: IETF-Discussion list , ietf-announce@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Jan 2012 21:09:36 -0000

 In your previous mail you wrote:

>  I hope a T-Shirt will feature my favorite French hero.... Super Dupont
>  
>  http://en.wikipedia.org/wiki/Superdupont

+1 (I should not have to explain why :-)

Thanks

Francis.Dupont@fdupont.fr

From terry.manderson@icann.org  Tue Jan 31 16:14:15 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC20021F84DD for ; Tue, 31 Jan 2012 16:14:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.299
X-Spam-Level: 
X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 gtZCOuAv5RZx for ; Tue, 31 Jan 2012 16:14:14 -0800 (PST)
Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7A14C21F84DE for ; Tue, 31 Jan 2012 16:14:14 -0800 (PST)
Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 31 Jan 2012 16:14:14 -0800
From: Terry Manderson 
To: Rob Austein 
Date: Tue, 31 Jan 2012 16:14:08 -0800
Subject: Re: Last Call:  (The RPKI/Router Protocol) to Proposed Standard
Thread-Topic: Last Call:  (The RPKI/Router Protocol) to Proposed Standard
Thread-Index: AczdfZPjYs44mqS2Q7+VE59s5lkvbgC+NZae
Message-ID: 
In-Reply-To: <20120128050229.98A9717711@thrintun.hactrn.net>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ietf@ietf.org" 
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Feb 2012 00:14:16 -0000

On 28/01/12 3:02 PM, "Rob Austein"  wrote:

> At Wed, 21 Dec 2011 17:43:23 -0800, Terry Manderson wrote:
>>
>> Apologies for my lack of attention to date on this topic, so speaking on=
ly
>> for myself here.
>
> Similar apologies for not having answered this more promptly.  Somehow
> we missed seeing this until our AD asked us about it.
>
> Please see draft-ietf-sidr-rpki-rtr-25, just posted, which we hope
> addresses most of your concerns (there are a few points on which I
> think we're just going to have to agree to disagree).

I will read -25 soon and raise any concerns should they remain.

>
[..]

> RADIUS doesn't have a bulk transfer operation, and bulk transfer of
> data is the main task of this protocol, particularly at start-up.

Is that function of the protocol now highlighted in -25?

>
> You are certainly entitled to your opinion, but it comes a bit late.
> This work was done in the public view, with regular progress reports
> to the SIDR WG, and we have multiple interoperable implementations
> including several of the major router vendors.  So, with all due
> respect, I don't think the folks who have put work into this will be
> all that interested in abandoning running code at this point.

My example was to highlight that without the rationale for why *this*
protocol was desiired any number of options would/could seem perfectly
reasonable and attractive.

>
>> Glossary:
>>
>> Global RPKI:
>> I disagree with this definition for two reasons. 1) I'm not aware of a
>> unified definition for 'distributed system' so this is all rather vague.
>
> The term has been used to describe DNS for decades.  Also see:
>
>   http://en.wikipedia.org/wiki/Distributed_computing

Citing wikipedia - the end is nigh!

>
>> Perhaps you could say 'published at a disparate set of systems'.
>
> I don't find that any clearer.  Readers who can't understand the words
> "distributed set" aren't likely to understand "disparate set" either.
>

I guess we remain in disagreement :).

>> 2) Limiting
>> the servers to be "at" the "IANA, RIRs, NIRs, and ISPs" is also prematur=
e.
>> It's not clear to me that these entities will run their own repositories=
,
>> nor are they going to be the only repository operators in the lifecycle =
of
>> the RPKI.
>
> This is essentially the same list as appears in section 1.1 of
> draft-ietf-sidr-arch, with the term "LIR" replaced by "ISP".
>
> I suppose we could add "or other service providers".

I think that would satisfy me.

>
>> Cache:
>> The words surrounding the fetch/refresh mechanisms of the RPKI is limiti=
ng.
>> Both draft-ietf-sidr-repos-struct and draft-ietf-sidr-res-certs allow fo=
r
>> other (future) retrieval mechanisms as defined by the repository operato=
r
>> beyond RSYNC (loosely documented in RFC5781).
>
> Terry, you've made it quite clear that you disagree with the SIDR WG's
> decision to make rsync the mandatory-to-implement RPKI retrieval
> protocol, but you lost that argument a long time ago, and I fail to
> see the point of bringing it up here yet again.

That wasn't the intent Rob, please re-read the paragraph for the reality
that I think this document still needs to be flexible SHOULD a future
retrieval mechanism develop. If you still think that it shouldn't be
flexible - then we remain in disagreement.

>
>> Last sentence. "Trusting this cache further is a matter between the prov=
ider
>> of the cache and a relying party". In my mind the Relying Party was the =
one
>> that did the RPKI validation - would this not be better stated as "Trust=
ing
>> this cache further is a matter between the provider of the cache and the
>> router operator".
>
> If a router is making decisions based on data given to it by a server,
> the router is the relying party in that relationship.  That the server
> in question was itself the relying party in another relationship does
> not change this.
>
> The picture here is not all that different from the way that some
> vendors have chosen to implement DNSSEC.  It's a two-tier security
> relationship: an end-to-end relationship between the publisher of
> signed objects and the validator of those signed objects, then a
> separate security relationship between the entity that validated the
> signed objects and the end entity that actually uses the data.

I think then we remain in disagreement on the phrasing, spelling out
precisely that the relying party identified here has a trust relationship
only with the cache, and not the larger RPKI is important.

>
>> Deployment Structure:
>>
>> Why repeat the definition of "Global RPKI"? It's superfluous.
>
> Because it's not a definition?
>
> I agree that the text here is similar to the definition, but this
> section is trying to describe the roles in the system.

Then I think the text needs work.

>
>> Local Cache: Again. 'Relying party' seems to be borrowed from the
>> CA/identity world. Unless you redefine that term here it seems as if the
>> "router" is making RPKI validation decisions. Which it is not. The route=
r is
>> acting more like a NAS (See Radius, 2865) when talking to a local cache.
>>
>> The definition of "routers" seems to get this right - eg "a client of th=
e
>> cache".
>
> See above.  "Relying party" is a security relationship term, not just
> a PKI term.
>
>> Operational Overview
>>
>> when you first use "ROA", please expand the TLA, and provide a reference=
.
>
> Done.
>

Thanks.

>> Serial Query
>>
>> I don't remember seeing a recommendation for how often a client (router)
>> sends a serial query. Is there a Min/Max? Surely doing it every second w=
ould
>> be excessive..
>
> Maximum is covered in section 6.2: the router must send a Serial or
> Reset Query no less frequently than once per hour.
>
> Minimum is a good question.  We had been assuming that, as this is an
> in-POP relationship with cache and router operated by the same party,
> there would likely be a knob in the router (router guys live for
> knobs) and setting it would be a matter of local policy.  If you want
> your router to beat up your cache server every minute, who am I to
> stop you?
>
> We needed to set a maximum because that affects the architecture of
> the cache (how long does it need to hold onto old data -- given the
> potential size of the data sets involved, one might implement the
> cache very differently if one needed to hold old data for a week
> rather than an hour).

Thus some recommendation text would be helpful.

>
>> IPv4 Prefix:
>>
>> "and nothing prohibits the existence of two identical
>>    route: or route6: objects in the IRR."
>>
>> Why even mention the IRR here? It just doesn't seem at all relevant. (an=
d
>> isn't defined)
>
> Good catch.  Done.

Thanks

>
>> " IPvX PDUs" expand to IPv4 or IPv6. Globing into one is a misdirection
>> under a heading of 'IPv4 Prefix'
>>
>> IPv6 Prefix
>>
>> Some text here to say that the IPv6 data structure follows the same
>> semantics as the IPv4 data structure would be good.. or alternatively
>> restructure the document to Semantics, then describe the IPv4 and IPv6 d=
ata
>> structures as subheadings to Prefix PDUs.
>
> Done.

Thanks

>
>> Error Report
>>
>> What is "excessive length" of a PDU? at what point do you say "o.k, now =
I
>> can truncate".
>
> Too long to be any valid PDU other than an Error Report.  Done.

Thanks

>
>> Fields of a PDU
>>
>> For all types, instead of using "ordinal" can you use the exact descript=
ion
>> of the number? eg unsigned integer? For me I always relate ordinals to s=
et
>> theory.
>
> Done.

Thanks

>
>> PDU type, the e,g is incomplete shouldn't it be "IPv4 Prefix =3D 4" with=
 a
>> forward reference to the IANA Considerations section?
>
> I think this is a matter of stylistic preference.

Yep. I can let that be.

>
>> Serial Number. "for example via rcynic", Is not defined and implementati=
on
>> specific!
>
> Please read the words "for example".
>
> I suppose we could add a reference, but the last time we did that
> somebody objected to having a reference pointing to the source code
> for a particular implementation.

Do you need the example? Perhaps just remove it. (I may have missed it, but
I don't recall seeing bind, or any other reference code base mentioned in
any of the DNS documents.)

>
>> and there is a typo "completing an rigorously validated"..while
>> there, consider why you use the term 'rigorously'..
>
> Sigh.  Next time, please be explicit about the typo you're seeing, our
> eyes repeatedly bounced off the "an" here until after we'd posting
> version -25.  It's not worth yet another rev just to fix that.

ok. Sorry I wasn't explicit at the time.

>
>> are there situations when a validation is less rigorous? If so
>> explain.
>
> I suspect that my co-author was trying to say that one can't just
> retrieve the data, pull the ASNs and prefixes out of the ROAs, and
> feed them into the router, one has to do the RPKI validation first.
>
> I guess we can remove the word if it offends you, but it seems
> harmless.

I just want it to be clear that there is only one level of validation as pe=
r
the various RPKI object validation rules.

>
>> Session ID
>>
>> What is the risk of a cache server starting/restarting with the same ses=
sion
>> ID and serial number as before, but with different cache contents? Is th=
is
>> an entropy concern? Just thinking of a potential scenario where a router=
 is
>> cache-wedged. Is this at all probable? and why not - some words here to
>> cover this would be good.
>
> We added several paragraphs on exactly this topic sometime around IETF
> Last Call, I suspect the version you reviewed did not have that text.
> I think we've addressed this point, please check the current text and
> let us know if there's a further issue here.

I will read.

>
>> Flags
>>
>> Can you reword the binary choice here? Do you actually need to delve int=
o
>> 'right to announce'? This is really about RIB entry behaviors yeah?
>
> The semantics here are closely related to ROAs, which, as you no doubt
> recall, are Route Origin Authorizations, so the text here follows that
> model.
>
> With all due respect, I do not think that a discussion of RIB entry
> behavior here would be simpler.
>

fine.

>> Expand "IPvX".
>
> Done.
>

Thanks

>> Start or Restart:
>>
>> I think the terms in when a router needs to send a serial query or a res=
et
>> query need to be tighter. Saying MAY here is too loose. I would much pre=
fer
>> to see a structure where if the router does not have a recorded serial f=
or a
>> cache from a previous session, the router MUST send a reset query. Logic=
ally
>> you assume that to be the case, so be specific.
>
> I think this is a stylistic matter again.  The router MAY do two
> things here, one of which is only applicable if it has data from a
> previous broken session.
>
> The only real difference I see here between the current formulation
> and the MUST formulation you prefer is that, as currently written, the
> router could chose not to send anything at all initially; this option
> doesn't seem particularly useful, so I don't mind removing it, but
> neither do I see the difference between the current text and your
> suggested change as a big deal.

Perhaps choose whichever has the lower chance of confusion for the router.

>
>> Thereafter the router MAY send a reset query, and SHOULD send a serial
>> query. I suspect this is what the vendors (who have chimed in on the lis=
t)
>> have coded.
>>
>> This then corroborates section 4 where you suggest the router only send
>> serial queries for efficiency.
>
> Section 6.2 already says that the typical exchange is for the cache to
> send a Serial Notify, in the expectation that the router will schedule
> an immediate Serial Query.  We didn't make it any stronger than that
> because the folks implementing the router side of this expressed
> concern at the notion that the cache could tell them to do something
> (read: they understand that the notification mechanism will help speed
> convergence, but they're worried that the dinky CPUs they're stuck
> with in some of the relevant hardware will be swamped if they try too
> hard, which is why routers are allowed to ignore notifications and
> caches are rate-limited in sending them).

ok.

>
>> Transport:
>>
>> MiTM is Man in the middle as I and many others know it. 'Monkey/piggy/pi=
ckle
>> in the middle' is a child's ball game.
>
> Monkey-in-the-middle is a common non-sexist variant of this term.
> Welcome to the 21st century.

Going back to a gender-neutral section of a professional writing text from
my MBA, it highlights that arbitrarily changing the linguistic definition o=
f
certain gender inclusive scenarios is poor form. If the language where
'Men-in-The-Middle" or "A-Man-in-The-Middle", then certainly change it.

Otherwise Man-in-the-middle is perfectly gender ambiguous. - But that may
also be my style and I will let the RFC Editor handle as appropriate.

>
>> " Therefore, as of this document, there is no mandatory to
>>    implement transport which provides authentication and integrity
>>    protection."
>>
>> if this is the case.. then why? what is the gain?
>
> OK, this is the elephant in the living room.
>

[..]

>
> Nobody is happy with this, but it's the least bad compromise we could
> find between what the IETF would prefer and reality in the field.
>

O.K.

>> why not then make the router fetch the signed objects and do the
>> validation internal - this again seems to be the 'missing
>> requirements' problem.
>
> See "currently shipping routing hardware", above.
>
>> SSH Transport
>>
>> State up front that you MUST use SSHv2. (instead hinting in the third
>> paragraph)
>
> Done.
>

Thanks.

>> TLS Transport
>> "Man in The Middle (MiTM)" please.
>
> Above.
>
>> Router Cache setup
>>
>> "When a more preferred cache becomes available, if resources allow, it
>>    would be prudent for the client to start fetching from that cache."
>>
>> How does the client (I assume router) know when to do this as cache's ar=
e
>> not synchronized?? How does a router tell if any particular cache has mo=
re
>> current data over another cache? what if two caches contradict each othe=
r?
>
> The document repeatedly states that the router has an ordered
> preference list of the caches it uses.  The text you quote here
> doesn't say "has more current data", it says "becomes available", ie,
> it stops rejecting connection attempts, signalling errors, or
> otherwise failing to be useful.

o.k.

>
>> Error codes
>>
>> 6: Withdrawal of Unknown Record (fatal), why drop the session? (which
>> presumably causes a restart) to a cache, assuming the cache is corrupt,
>> which will then send another Unknown Record, which is fatal... (repeat)?=
?
>>
>> Why not mark the cache as corrupt at the client?
>
> This is one of several loss-of-synchronization problems.  The
> assumption is that the router may have (somehow) lost synchronization
> with the cache.  We don't really know which party is confused at this
> point, all we know is that the session itself is no longer useful
> because the router and cache are not communicating clearly.  So the
> router's data isn't necessarily corrupt.
>
> The router won't necessarily restart with this cache right away
> either, it has several options: it might try another cache, it switch
> to another set of data it has already loaded, or might try a reset
> query to this cache.

o.k.

>
>> Security Considerations:
>>
>> Transport Security. There are multiple valid options for a root trust an=
chor
>> including the structure from the IAB aligning it to the IANA. Perhaps
>> instead of saying " the IANA root trust anchor" say "Global RPKI root tr=
ust
>> anchor". Otherwise you might accidently find your validated cache only
>> covers unallocated and reserved blocks.
>
> I think you're saying that using the term IANA here is politically
> incorrect.

No. I'm saying that while discussions are underway, precisely which trust
anchor covers what is still on the table. At this stage one option has
IANA's RPKI CA being authoritative for only unallocated and reserved INRs.
It may be that there is a unified trust anchor above that, known loosely as
the global trust anchor. However tying the document to one particular TA
might result in a gross inaccuracy. Ultimately then, if the global trust
anchor is the IANA TA, you haven't lost.

Cheers
Terry


From fcorella@pomcor.com  Tue Jan 31 20:53:25 2012
Return-Path: 
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A22A11E80C9 for ; Tue, 31 Jan 2012 20:53:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.204
X-Spam-Level: 
X-Spam-Status: No, score=-0.204 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_50=0.001, HTML_MESSAGE=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 8dWGHWh+SJha for ; Tue, 31 Jan 2012 20:53:24 -0800 (PST)
Received: from nm28-vm3.bullet.mail.ne1.yahoo.com (nm28-vm3.bullet.mail.ne1.yahoo.com [98.138.91.158]) by ietfa.amsl.com (Postfix) with SMTP id 8535711E80BE for ; Tue, 31 Jan 2012 20:53:24 -0800 (PST)
Received: from [98.138.90.56] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 01 Feb 2012 04:53:21 -0000
Received: from [98.138.87.3] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 01 Feb 2012 04:53:21 -0000
Received: from [127.0.0.1] by omp1003.mail.ne1.yahoo.com with NNFMP; 01 Feb 2012 04:53:21 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 398609.37163.bm@omp1003.mail.ne1.yahoo.com
Received: (qmail 47325 invoked by uid 60001); 1 Feb 2012 04:53:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1328072001; bh=IKE37+un2W9gpDnnKDDwBjIfki5CryDoXkvWXIkGHks=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=ajL86Q7+bFUbPbszmYAt4n5ct6hDKASiuy1bao3wYP2TUSZulWfNnDukX00Rf+Zrindle2QzdcR8KeoNwG9DrLWenCuHlAG/Y0/6WAjxqENytnubqdR6ouJr17yZvyTMtvUmDo5g4XxrdZ7UO/ImbK3b69wNvYVjoN4PAjvOKK0=
X-YMail-OSG: a6MHB84VM1mQQwDm5wSvM6mYaDhKVjLP92Ma0XpYY.d5LT4 Nu7lQ5bdl41GWyBpRqK55UQuE0fj3uoYZHTI0uGE6CL3haRqJWWecJh3dvrw st3IUncdbOAlMyQsJWZqquZ8yJPrD4b0NH6wOgcQZcN2A.5V5jENMA8Yz0VD l7nPhvTlSibiUjH7BUJm3GnwA8wosrQMqvO0nYifljKGFsZoTp92JkUDEkve XpQmdGA5x_e4mE6ckSIFGXybyV8fyVsNSrHkitzxFa_51m5cxB1uQ0G25YWm 2exYApIiSf7dDZvcWas7bVNmTh9e_pJ2B4UCQXt_B_HrjBWJNThi5OOBhbn. UF0JnrYYh8bLnX98EX8Ncv_RFfNjW3l0tRTvmRpVKhsZzxzOOITOLCI5QuQ7 U9igScnkXAUKZcBh71Duxfgv.bbVJSGExmO_xsAvIEusmbnQDPFwz_S.4pY0 MdzuNfwh2QA--
Received: from [174.65.117.33] by web125501.mail.ne1.yahoo.com via HTTP; Tue, 31 Jan 2012 20:53:20 PST
X-RocketYMMF: francisco_corella
X-Mailer: YahooMailWebService/0.8.116.331537
Message-ID: <1328072000.47240.YahooMailNeo@web125501.mail.ne1.yahoo.com>
Date: Tue, 31 Jan 2012 20:53:20 -0800 (PST)
From: Francisco Corella 
Subject: REVISED Last Call:  (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
To: "ietf@ietf.org" 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="329289550-979433935-1328072000=:47240"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Francisco Corella 
List-Id: IETF-Discussion 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Feb 2012 04:53:25 -0000

--329289550-979433935-1328072000=:47240
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

The bearer token protocol described in the document referenced in the=0Asub=
ject line is vulnerable to the following attack by a malicious=0Aresource s=
erver.=0A=0AThere are two resource servers S1 and S2, S1 hosting a resource=
 R1,=0Aand S2 hosting a resource R2.=A0 Servers are not entitled to access=
=0Aresources that they do not host.=A0 S1 is malicious.=A0 The client obtai=
ns=0Aa broadly scoped access token that allows access to both resources.=0A=
The client uses the access token to obtain resource R1 from server S1.=0AMa=
licious server S1 then presents the access token received from the=0Aclient=
 to server S2 and gains access to resource R2, which it is not=0Aentitled t=
o access.=0A=0AIncluding the identity of the intended recipients in the tok=
en, as=0Arecommended in Section 4.2, does not help, since the intended=0Are=
cipients of the broadly scoped token include both R1 and R2.=0A=0AFrancisco
--329289550-979433935-1328072000=:47240
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


      The bearer token prot=
ocol described in the document referenced in the
      subject line is vulnera=
ble to the following attack by a malicious
      resource server.

      There=
 are two resource servers S1 and S2, S1 hosting a resource R1,
      and S2 ho=
sting a resource R2.  Servers are not entitled to access
      resources =
that they do not host.  S1 is malicious.  The client obtains
      a=
 broadly scoped access token that allows access to both resources.
      The c=
lient uses the access token to obtain resource R1 from server S1.
      Malici=
ous server S1 then presents the access token received from the
      client to=
 server S2 and gains access to resource R2, which it is not
      entitled to =
access.

      Including the identity of the intended recipients in the tok=
en, as
      recommended in Section 4.2, does not help, since the
 intended
      recipients of the broadly scoped token include both R1 and R2.=


      Francisco

      
--329289550-979433935-1328072000=:47240--