From discuss-bounces@apps.ietf.org Tue Sep 04 11:09:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISa0V-0007mz-EP; Tue, 04 Sep 2007 11:07:59 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IRrFU-0002pM-2T for discuss-confirm+ok@megatron.ietf.org; Sun, 02 Sep 2007 11:20:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRrFT-0002pE-P7 for discuss@apps.ietf.org; Sun, 02 Sep 2007 11:20:27 -0400 Received: from sam.opera.com ([213.236.208.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRrFS-0001eg-35 for discuss@apps.ietf.org; Sun, 02 Sep 2007 11:20:27 -0400 Received: from nimisha.oslo.opera.com (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by sam.opera.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l82FKB4s008271 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sun, 2 Sep 2007 15:20:16 GMT Date: Sun, 02 Sep 2007 17:19:53 +0200 To: "Stefanos Harhalakis" , "Alexey Melnikov" Subject: Re: HTTPBis BOF followup - should RFC 2965 (cookie) be in scope for the WG? From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 References: <46BDE53B.1070404@isode.com> <46D332AD.5070702@isode.com> <200708282004.49749.v13@priest.com> <200708282044.10419.v13@priest.com> Message-ID: In-Reply-To: <200708282044.10419.v13@priest.com> User-Agent: Opera Mail/9.20 (Win32) X-Virus-Scanned: ClamAV 0.91.1/4131/Sun Sep 2 08:47:51 2007 on sam.opera.com X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sam.opera.com id l82FKB4s008271 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Tue, 04 Sep 2007 11:07:58 -0400 Cc: Apps Discuss , HTTP Working Group X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello Stefanos, On Tue, 28 Aug 2007 19:44:10 +0200, Stefanos Harhalakis = =20 wrote: > > On Tuesday 28 August 2007, Stefanos Harhalakis wrote: >> On Monday 27 August 2007, Alexey Melnikov wrote: >> >> I don't know if I'm supposed to vote, but I'd suggest 1 (No). The =20 >> rationale >> can be summarized in the question: "Why yes?". > > Sorry for replying to self but I'd like to change that to 4: > Discuss it in the list first. > > Then, maybe vote for '3'. > > After reading the minutes (again), I understand that this will only =20 > change > RFC 2695 to 'become' the Netscape doc. So, I don't actually see it as a= =20 > hi > priority issue, thinking that a well accepted document already exists > (Netscape) and there is no confusion. Also, shouldn't this become a new= =20 > RFC > that will replace 2695? I think you misunderstand the intention of my I-D =20 draft-pettersen-cookie-v2 , and my presentation at the BoF. The intention of the draft is to fix security and privacy issues in both = =20 the Netscape spec and RFC 2965 (the "cookie monster bug") by changing the= =20 domain and path semantics, so that the issues with Netscape and RFC 2965 = =20 cannot occur, and as a result obsoleting Netscape and RFC 2965 cookies. I have also posted two other drafts suggesting candidates for intermediat= e =20 workarounds that I believe will reduce the problem in the existing =20 specifications. For more information about the background please see my articles http://my.opera.com/yngve/blog/show.dml/267415 http://my.opera.com/yngve/blog/show.dml/388840 --=20 Sincerely, Yngve N. Pettersen =A0 ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From discuss-bounces@apps.ietf.org Tue Sep 04 17:06:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISfa7-0001aJ-Ek; Tue, 04 Sep 2007 17:05:07 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ISfa7-0001aD-2o for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 17:05:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISfa6-0001a5-G2 for discuss@apps.ietf.org; Tue, 04 Sep 2007 17:05:06 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISfa4-00057s-Sz for discuss@apps.ietf.org; Tue, 04 Sep 2007 17:05:06 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 58F3C142213; Tue, 4 Sep 2007 14:05:04 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4ORJ1E3KW-a; Tue, 4 Sep 2007 14:05:02 -0700 (PDT) Received: from [10.1.1.107] (unknown [157.22.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 61AF3142202; Tue, 4 Sep 2007 14:05:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <58F2EB70-4A11-4C0B-B517-A782520A6EDB@osafoundation.org> Content-Type: multipart/alternative; boundary=Apple-Mail-18-179304657 To: Apps Discuss , Lisa Dusseault's Chairs Subject: Lisa's Apps Area Activity for August 2007 From: Lisa Dusseault Date: Tue, 4 Sep 2007 14:05:02 -0700 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-18-179304657 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Document Status and Progress Active Documents: my action - draft-adolf-dvb-urn (Informational): need to do AD evaluation - draft-creed-ogc-urn (Informational): need to do AD evaluation - draft-mealling-epc-urn (Informational): discussing design space with author - draft-wilde-sms-uri (Proposed Standard): discussing extended features on Apps Discuss - draft-ietf-sieve-3028bis: IESG Evaluation, work with Cullen and doc shepherd on multiple redirect issues - draft-saintandre-rfc4622bis: Finished IETF Last Call; I need to read reviews and do writeup for IESG Evaluation phase. - draft-ietf-imapext-sort: Confirming that this is done now that unicasemap is done. Stalled or waiting on other - draft-snell-atompub-bidi (Proposed Standard): Sent to ITU for review of bidi character handling. - draft-saintandre-jabberid: In IETF Last Call - draft-ietf-sieve-body: Finished IETF Last Call, waiting for revision (Philip). - draft-crocker-rfc4234bis: Finished IESG Evaluation, waiting for author to resolve LWSP issue raised in IETF Last Call and IESG Evaluation (Dave or Paul) - draft-snell-atompub-feature: Dissent on mailing list about required features indicates that this core building block piece for AtomPub probably shouldn't be done as an Individual document. This will probably be put in stasis until an AtomPub WG gets formed to progress it, or some similar action. - draft-hartman-webauth-phishing: New critical reviews received post- IETF-Last-Call. Author will revise and discuss on ietf-http-auth mailing list. - draft-montemurro-gsma-imei-urn: IESG Evaluation phase, waiting for author to select a way to deal with Cullen's DISCUSS on whether to register just two URNs or an allocatable delegated namespace of arbitrarily many URNs. - draft-goodwin-iso-urn (Informational): AUTH48 changes were too substantial. Waiting for authors to confirm that next action is to rerun IETF Last Call. Finished processing - RFC queue and new RFCs - draft-crispin-collation-unicasemap: Completed IESG Evaluation, pushing to RFC Ed queue - draft-ietf-lemonade-rfc2192bis: Completed IESG Eval and pushed to RFC Ed queue. - RFC 5013: The Dublin Core Metadata Element Set - RFC 5034: The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism - RFC 4954: SMTP Service Extension for Authentication - RFC 4946: Atom License Extension ... 12 sponsored or shepherded documents in RFC queue including above two just added. WG quick status WIDEX: Closed. USEFOR: quiet during August SIEVE: processing several active documents IMAPEXT: Quiescent, waiting on busy authors. ATOMPUB: Basically finished! CALSIFY: Finishing RFC2445bis and doing work on iTIP --Apple-Mail-18-179304657 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Document = Status and Progress

Active Documents: my action
=A0-=A0draft-adolf-dvb-urn (Informational): need = to do AD evaluation
=A0- draft-mealling-epc-urn = (Informational): discussing design space with author
=A0-=A0draft-wilde-sms-uri (Proposed Standard): = discussing extended features on Apps Discuss
-=A0draft-ietf-sieve-3028bis:=A0IESG Evaluation,=A0 = work with Cullen and doc shepherd on multiple redirect issues
=A0- draft-saintandre-rfc4622bis: Finished IETF Last = Call; I need to read reviews and do writeup for IESG Evaluation = phase.
=A0- draft-ietf-imapext-sort:=A0 = Confirming that this is done now that unicasemap is done.

Stalled or = waiting on other
=A0- = draft-snell-atompub-bidi (Proposed Standard): Sent to ITU for review of = bidi character handling.
=A0- = draft-saintandre-jabberid: In IETF Last Call
=A0-=A0draft-ietf-sieve-body: Finished IETF Last = Call, waiting for revision (Philip).
=A0- = draft-crocker-rfc4234bis: Finished IESG Evaluation, waiting for author = to resolve LWSP issue raised in IETF Last Call and IESG Evaluation (Dave = or Paul)
=A0- = draft-snell-atompub-feature: Dissent on mailing list about required = features indicates that this core building block piece for AtomPub = probably shouldn't be done as an Individual document.=A0 This will = probably be put in stasis until an AtomPub WG gets formed to progress = it, or some similar action.

Finished = processing - RFC queue and new RFCs
=A0- = draft-ietf-lemonade-rfc2192bis: Completed IESG Eval and pushed to RFC Ed = queue.
=A0- RFC 5013:=A0=A0The Dublin = Core Metadata Element Set
=A0- RFC = 5034:=A0=A0The Post Office Protocol (POP3)=A0Simple Authentication and = Security Layer (SASL) Authentication Mechanism
=A0- RFC 4954:=A0SMTP Service Extension for = Authentication
=A0- RFC 4946:=A0Atom License = Extension

=A0... 12 = sponsored or shepherded documents in RFC queue including above two just = added.

WG quick status
WIDEX: = Closed.
USEFOR: quiet during = August
SIEVE: processing several active = documents
IMAPEXT: Quiescent, waiting on = busy authors.
ATOMPUB: Basically = finished!
CALSIFY: Finishing RFC2445bis = and doing work on iTIP

= --Apple-Mail-18-179304657-- From discuss-bounces@apps.ietf.org Tue Sep 04 17:49:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISgEw-0004Im-Uz; Tue, 04 Sep 2007 17:47:18 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ISgEv-0004Ic-Kd for discuss-confirm+ok@megatron.ietf.org; Tue, 04 Sep 2007 17:47:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ISgEv-0004IU-BA for discuss@apps.ietf.org; Tue, 04 Sep 2007 17:47:17 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ISgEt-0006CD-T2 for discuss@apps.ietf.org; Tue, 04 Sep 2007 17:47:17 -0400 Received: from [192.168.0.6] (adsl-67-124-150-100.dsl.pltn13.pacbell.net [67.124.150.100]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l84Lkv67018411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2007 14:46:58 -0700 Message-ID: <46DDD1E0.6040304@dcrocker.net> Date: Tue, 04 Sep 2007 14:45:04 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Lisa's Apps Area Activity for August 2007 X-Priority: 2 (High) References: <58F2EB70-4A11-4C0B-B517-A782520A6EDB@osafoundation.org> In-Reply-To: <58F2EB70-4A11-4C0B-B517-A782520A6EDB@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Apps Discuss , Lisa Dusseault's Chairs , iesg X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa Dusseault wrote: > - draft-crocker-rfc4234bis: Finished IESG Evaluation, waiting for > author to resolve LWSP issue raised in IETF Last Call and IESG > Evaluation (Dave or Paul) The document authors have a number of problems with this Discuss from Lisa and efforts to clarify things privately have not been productive. Since this is being distributed publicly, I am obligated to comment on it: Simply put, there is not "LWSP issue". The ABNF document has been in use a very long time and is formally accurate in in specification. Over its 10+ year history, there have been a few examples of misreading the ABNF specification. If that qualifies as a basis for mandating change, then we need to review quite a few other specifications. In any event, there is a Discuss from Lisa that has stalled progress of the ABNF document, but the Discuss causes its own problems: One is that we do not perceive any community consensus that any change -- nevermind no normative change -- is required for the document. At most, there might be some community interest in having commentary added, but that leads to the next problem. We do not have any idea what will resolve Lisa's Discuss. Lisa has provided no criteria for its closure, other than suggesting that we talk with one individual. We are not aware the mere act of being vocal about an issue empowers a single community member to control resolution of a Discuss. In effect, that would seem to be a delegation of the Discuss. Is that allowed? If Lisa has requirements on this topic, she needs to state what they are in terms of her own understandings and requirements, not in terms of the unspecified needs of another. We should remember that this is an extremely well-vetted document, both in long history and recent review. Since the document's authors do not believe that the current process issues will alter the use of ABNF, we do not have much incentive to spend energy on the issue. (A sour grapes muttering in response might claim that my writing this note -- and it is perhaps the third of its type I've send on the topic -- is more work than resolving the topic, but I'll note that that cannot be known, since there is now way of knowing what will resolve it.) Lisa has stated that her Discuss really is on behalf of an IESG consensus that some text needs to be added. Perhaps I missed the IESG minutes about this consensus? It would be useful to get a citation to it. In any event, if the IESG has consensus about the need to added commentary to an RFC before it is published, then this is an IESG requirement, not an IESG assessment of a community consensus. Further there is a well-established and frequently-used mechanism for it. IESG Notes are not exactly... noteworthy. And for reference, the document authors have repeatedly stated their friendly willingness to add such text. Or text that is produced by a community consensus process. But since we do not, ourselves, understand what will satisfy Lisa in this matter, we do not feel qualified to lead the effort to resolve it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Wed Sep 05 15:02:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT079-0001N1-PU; Wed, 05 Sep 2007 15:00:35 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IT078-0001Mg-45 for discuss-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 15:00:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT077-0001MY-Qp for discuss@apps.ietf.org; Wed, 05 Sep 2007 15:00:33 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IT076-0002zk-B0 for discuss@apps.ietf.org; Wed, 05 Sep 2007 15:00:33 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 5 Sep 2007 20:00:28 +0100 Message-ID: <46DEFCF6.2090101@isode.com> Date: Wed, 05 Sep 2007 20:01:10 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: HTTP Working Group Subject: Re: HTTPBis BOF followup - should RFC 2817/2818 be in scope for the WG? References: <46BDE42A.2040808@isode.com> In-Reply-To: <46BDE42A.2040808@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Alexey Melnikov wrote: > Hi folks, > Answers to this question during the BOF were not conclusive, so I > would like to poll mailing list members on whether revision of RFC > 2817 (Upgrading to TLS Within HTTP/1.1) and RFC 2818 (HTTP Over TLS) > should be in scope for the proposed WG. > > Question: Should RFC 2817 and/or RFC 2818 revision be in scope for the > WG? > > Please chose one of the following answers: > > 1). No > 2). Yes, only add RFC 2818bis to the charter > 3). Yes, only add RFC 2817bis to the charter > 4). Yes, add both RFC 2817bis and RFC 2818bis to the charter > 5). Maybe (this includes "yes, but when the WG completes the currently > proposed milestones" and "yes, but this should be done in another WG") > 6). I have another opinion, which is .... > > Please send answers to the mailing list, or directly to me *and* Mark > Nottingham . > And of course feel free to ask clarifying questions/correct list of > answers. I've reviewed replies with Mark and here are the results: RFC 2818 and/or RFC 2817 No (neither) - 1 person RFC 2818bis only - 1 person RFC 2817bis only - none Maybe - 7 people So consensus seems to be in favor of "Maybe". Based on the poll results I would recommend not to change the proposed Charter to say anything about RFC 2817 or RFC 2818. From discuss-bounces@apps.ietf.org Wed Sep 05 15:05:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT09m-0003ey-PD; Wed, 05 Sep 2007 15:03:18 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IT09l-0003et-H4 for discuss-confirm+ok@megatron.ietf.org; Wed, 05 Sep 2007 15:03:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IT09l-0003el-7W for discuss@apps.ietf.org; Wed, 05 Sep 2007 15:03:17 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IT09j-00033h-W6 for discuss@apps.ietf.org; Wed, 05 Sep 2007 15:03:17 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 5 Sep 2007 20:03:14 +0100 Message-ID: <46DEFD9E.8030006@isode.com> Date: Wed, 05 Sep 2007 20:03:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: HTTP Working Group Subject: Re: HTTPBis BOF followup - should RFC 2965 (cookie) be in scope for the WG? References: <46BDE53B.1070404@isode.com> In-Reply-To: <46BDE53B.1070404@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Alexey Melnikov wrote: > Hi folks, > Answers to this question during the BOF were not conclusive, so I > would like to poll mailing list members on whether revision of RFC > 2965 (HTTP State Management Mechanism) should be in scope for the > proposed WG. > > Question: Should RFC 2965 revision be in scope for the WG? > > Please chose one of the following answers: > > 1). No > 2). Yes > 3). Maybe (this includes "yes, but when the WG completes the currently > proposed milestones" and "yes, but this should be done in another WG") > 4). I have another opinion, which is .... > > Please send answers to the mailing list, or directly to me *and* Mark > Nottingham . > And of course feel free to ask clarifying questions/correct list of > answers. I've reviewed replies with Mark and here are the results: No - 2 people Yes - 2 people (or 4 people, as 2 replied "Yes/Maybe") Maybe - 7 people (or 5 people if you exclude the 2 who said yes/maybe) So consensus seems to be in favor of "Maybe" with very slight bias toward Yes. From discuss-bounces@apps.ietf.org Thu Sep 06 20:46:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITRxf-0004Cu-8B; Thu, 06 Sep 2007 20:44:39 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITRxd-0004Co-Sm for discuss-confirm+ok@megatron.ietf.org; Thu, 06 Sep 2007 20:44:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITRxd-0004Cg-JE for discuss@apps.ietf.org; Thu, 06 Sep 2007 20:44:37 -0400 Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITRxc-0001CX-8e for discuss@apps.ietf.org; Thu, 06 Sep 2007 20:44:37 -0400 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id 33A9D2761 for ; Fri, 7 Sep 2007 00:44:33 +0000 (GMT) Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID625LigaSh3216Xo2; Fri, 07 Sep 2007 00:44:33 -0000 X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID625LigaSh3216Xo2 Received: from [10.1.1.107] ([157.22.41.236]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Sep 2007 18:44:32 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Apps Discuss From: Lisa Dusseault Subject: Issues around sponsoring individual documents Date: Thu, 6 Sep 2007 17:44:32 -0700 X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 07 Sep 2007 00:44:32.0837 (UTC) FILETIME=[41AE4F50:01C7F0E8] X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org The Applications area does not have a lot of attendees or WGs (I oversee five, and of those five, three are within a document or two of closing). Much of the current work is being done as individual submissions (abbreviated IS in this email) [0]. I'd like to get some input on how IS's should be handled. I have many opinions on IS tradeoffs, having written several and sponsored more, but I'm trying to phrase these questions without entirely presupposing my own answers, and to reflect conflicted opinions and the criticisms I've heard. (BTW, I'm sure I can follow the advice of "Use your judgement" if anybody decides to say that, but it doesn't really inform that judgement does it? ) Is an IS that defines a new protocol for the Standards Track fine in general? Is an IS that extends a standard protocol developed in a WG fine in general? Is an IS that obsoletes a standard protocol developed in a WG fine in general? Do IS's suffer from less review? Is that a problem? Whose responsibility is it to get sufficient review? Is it mostly well-connected individuals that can use the IS track, knowing an AD to do the sponsoring? Or mostly individuals with a lot of time on their hands? An IS can have a non-AD document shepherd. Does encouraging that improve the situation or make IS publishing even more dependent on the author's connections? Should I limit time spent sponsoring IS's? [1] IESG work plus IS work could consume 30 hours a week, or 40, or 50... Assuming I limit the potentially endless amount of work devoted to IS's, do I limit it algorithmically (e.g. first come first served), as a matter of pure taste, or other? How should I prioritize IS sponsoring work? Which documents get my attention first? [2] When there's a question of consensus for an IS document, should I just drop the document? Assuming I try to determine consensus how do I do so without an official owning WG -- consensus calls to the IETF discuss list? Choose a related list and hope people are paying attention? Do I need to ensure there's a quorum? How would appeals against IS documents affect answers to these issues? (Usually individual ADs take the first stab at handling appeals, formal or informal, against WG chair decisions. When there's no WG chair involved with a doc, I guess the appeal would go straight to the whole IESG...) Does sponsoring many IS documents give an AD, and the IESG as a whole, too much power? Are we discouraging legitimate WGs by encouraging IS's? What other purposes do WG's serve besides simply publishing documents, that are not met by IS's? [3] If we turned down ISs in Apps, would the proposed work die, go elsewhere or ... ? Would that be bad? Lisa [0] Note "Independent Submission" is a different thing, an I-D that goes through the RFC Editor to RFC and never gets an IETF last call, so it's marked as not an IETF document [1] So far I have been sponsoring nearly every document I'm asked to, not really limiting. However I can see time limiting becoming required. [2] My current practice is to do WG-related work first, then IS- sponsoring work in rotation. Note that with WG-related work, the WG chair does some work which I have to do with IS documents. IS documents are usually more work for me than WG products. [3] I'll take a first stab at this one: - creating buy-in among potential implementors, - developing relationships that can lead to more interop work than otherwise, - choosing document editors that can reflect or build consensus, strongarm them if necessary From discuss-bounces@apps.ietf.org Thu Sep 06 21:36:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITSk2-0005oJ-3G; Thu, 06 Sep 2007 21:34:38 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITSk0-0005oC-6O for discuss-confirm+ok@megatron.ietf.org; Thu, 06 Sep 2007 21:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITSjz-0005o4-So for discuss@apps.ietf.org; Thu, 06 Sep 2007 21:34:35 -0400 Received: from mailhost.jlc.net ([199.201.159.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITSjy-0002R3-LH for discuss@apps.ietf.org; Thu, 06 Sep 2007 21:34:35 -0400 Received: by mailhost.jlc.net (Postfix, from userid 104) id CEED523F0F0; Thu, 6 Sep 2007 21:34:34 -0400 (EDT) Date: Thu, 6 Sep 2007 21:34:34 -0400 From: John Leslie To: Lisa Dusseault Subject: Re: Issues around sponsoring individual documents Message-ID: <20070907013434.GD80806@verdi> References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa Dusseault wrote: > > Is an IS that defines a new protocol for the Standards Track fine in > general? I'd describe them as "necessary, rather than "fine". > Is an IS that extends a standard protocol developed in a WG fine in > general? This falls a bit short of "fine". Such extensions deserve formal review... > Is an IS that obsoletes a standard protocol developed in a WG fine in > general? I doubt there's any other practical way. (These do seem to attract enough review...) > Do IS's suffer from less review? Yes. > Is that a problem? Not necessarily. > Whose responsibility is it to get sufficient review? Yours, I suppose... (That's why we pay you the big bucks, right?) > Is it mostly well-connected individuals that can use the IS track, > knowing an AD to do the sponsoring? Or mostly individuals with a lot > of time on their hands? A bit of both... The latter particularly need significant review. > An IS can have a non-AD document shepherd. Does encouraging that > improve the situation or make IS publishing even more dependent on > the author's connections? It certainly improves life for the AD... > Should I limit time spent sponsoring IS's? [1] IESG work plus IS > work could consume 30 hours a week, or 40, or 50... Yes. (Alas, we have rather a backlog of apparea work which seems to have no way of proceeding except via ISs...) > Assuming I limit the potentially endless amount of work devoted to > IS's, do I limit it algorithmically (e.g. first come first served), > as a matter of pure taste, or other? No algorithm can yield reasonable results. You have to "use your judgment". ;^) > How should I prioritize IS sponsoring work? Which documents get my > attention first? [2] Clearly the updates to mainstream, high-usage RFCs are squeaking petty loudly... > When there's a question of consensus for an IS document, should I > just drop the document? Bad idea... This situation is exactly where we need WG-style process. > Assuming I try to determine consensus how do I do so without an > official owning WG -- consensus calls to the IETF discuss list? > Choose a related list and hope people are paying attention? > Do I need to ensure there's a quorum? You can always _try_ a consensus call an the apparea list... (TANSTAA quorum.) > How would appeals against IS documents affect answers to these > issues? At all costs, please avoid considering suicide! (Obviously, appeals are a sign of some serious malfunction.) > (Usually individual ADs take the first stab at handling appeals, > formal or informal, against WG chair decisions. When there's no > WG chair involved with a doc, I guess the appeal would go straight > to the whole IESG...) I don't read our process documents that way. Even when your own action is being appealed, an AD should make the first attempt at resolution. > Does sponsoring many IS documents give an AD, and the IESG as a > whole, too much power? Perhaps, but I think of it as rather too many headaches. > Are we discouraging legitimate WGs by encouraging IS's? No. I believe WGs are being discouraged for other reasons. > What other purposes do WG's serve besides simply publishing > documents, that are not met by IS's? [3] - review - polishing details - discussion on a better targeted mailing list - ability to schedule physical meetings if necessary - etc... > If we turned down ISs in Apps, would the proposed work die, go > elsewhere or ... ? Would that be bad? Mostly go elsewhere, with "die" a close second. IMHO, it is bad because solutions get delayed -- often until some half-assed idea takes hold by IETF inaction. -- John Leslie From discuss-bounces@apps.ietf.org Thu Sep 06 22:06:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITTCi-0003kl-Sq; Thu, 06 Sep 2007 22:04:16 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITTCh-0003il-Nb for discuss-confirm+ok@megatron.ietf.org; Thu, 06 Sep 2007 22:04:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITTCh-0003id-Dk for discuss@apps.ietf.org; Thu, 06 Sep 2007 22:04:15 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITTCg-00038P-4x for discuss@apps.ietf.org; Thu, 06 Sep 2007 22:04:15 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 888121EE24F; Thu, 6 Sep 2007 22:04:09 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuVQC3WGCIyW; Thu, 6 Sep 2007 22:04:05 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 945701EE249; Thu, 6 Sep 2007 22:04:00 -0400 (EDT) Message-ID: <46E0B18D.6030805@cs.utk.edu> Date: Thu, 06 Sep 2007 22:03:57 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Issues around sponsoring individual documents References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> In-Reply-To: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa Dusseault wrote: > > The Applications area does not have a lot of attendees or WGs (I > oversee five, and of those five, three are within a document or two of > closing). Much of the current work is being done as individual > submissions (abbreviated IS in this email) [0]. I'd like to get some > input on how IS's should be handled. I have many opinions on IS > tradeoffs, having written several and sponsored more, but I'm trying > to phrase these questions without entirely presupposing my own > answers, and to reflect conflicted opinions and the criticisms I've > heard. > > (BTW, I'm sure I can follow the advice of "Use your judgement" if > anybody decides to say that, but it doesn't really inform that > judgement does it? ) > > Is an IS that defines a new protocol for the Standards Track fine in > general? > Is an IS that extends a standard protocol developed in a WG fine in > general? > Is an IS that obsoletes a standard protocol developed in a WG fine in > general? None of the above. All of them are acceptable according to process, but that doesn't mean that they're fine in general. I see two cases where ISes are appropriate vehicles for standards actions: 1. The proposal is simple and noncontroversial, and there is already a significant and identifiable community in the IETF (or close to it) that can competently evaluate it. There's really no need for a WG to refine the proposal because the proposal is simple enough that its effects are easily understood. (examples include some - not all - proposals for new email headers, new MIME types, that sort of thing) 2. Careful analysis reveals that the proposal only affects a narrow and well-identified group of people, and those people have already reached consensus on the proposal. So there's no need to spin up a WG that consists only of that set of people. > Do IS's suffer from less review? Is that a problem? > Whose responsibility is it to get sufficient review? Yes they do, in general. It's not a problem as long as the process is used only for cases like the ones I mention above. generally, having the IS process seems like a good thing, but it does require AD/IESG discretion to prevent it from being used as a end-run around the full WG process. > Is it mostly well-connected individuals that can use the IS track, > knowing an AD to do the sponsoring? Or mostly individuals with a lot > of time on their hands? It's not an either-or. Both sets of individuals enjoy an advantage. A well-connected individual with a lot of time on his hands enjoys an even greater advantage. :) IMHO, there's nothing wrong with the standards process having a lower barrier for simple, uncontroversial, easy to analyze proposals, than it has for proposals that require more deliberation by a WG and/or by IESG. However if a well-connected individual can somehow use this lower barrier to get his IS adopted as a standard before a less well-connected individual or industry group can get his/their IS on a similar topic submitted to IESG (or before they can get a WG formed to work on that problem), that might be a problem. > An IS can have a non-AD document shepherd. Does encouraging that > improve the situation or make IS publishing even more dependent on the > author's connections? Offhand I think the more people available to shepherd a document, the wider the set of authors who might obtain sponsors. > Should I limit time spent sponsoring IS's? [1] IESG work plus IS work > could consume 30 hours a week, or 40, or 50... Yes. WG proposals should take precedence over ISs, and you should probably set limits on the time you spend doing IESG work. Otherwise it will eat your life (it did mine). I don't think that we should expect ADs or IESG to evaluate IS proposals within strict time limits like we do for WG proposals. > Assuming I limit the potentially endless amount of work devoted to > IS's, do I limit it algorithmically (e.g. first come first served), > as a matter of pure taste, or other? > How should I prioritize IS sponsoring work? Which documents get my > attention first? [2] I think if I were doing it, I'd basically use a rough FIFO order so that old proposals would definitely get looked at. but within a set of documents submitted within a particular time-slot, I'd use a greedy algorithm - the documents that involve the least work for the AD would get handled first. after that, the documents that are harder to review or provide feedback for, but which seemed to have the most benefit for the community would get processed. > When there's a question of consensus for an IS document, should I just > drop the document? > Assuming I try to determine consensus how do I do so without an > official owning WG -- consensus calls to the IETF discuss list? > Choose a related list and hope people are paying attention? > Do I need to ensure there's a quorum? I don't think such documents should be dropped immediately. But neither do I think the AD needs to spend a lot of effort sorting them out. Basically I'd try to make it up to the IS author and those who commented on it to try to reach a compromise by themselves. Give them, say, a 4 week timeout. After that timeout, one of two things happens: (1) the parties are in agreement that this (perhaps updated) document is the way forward. (2) the parties couldn't fully agree but the author argues that the (perhaps updated) document has rough community consensus (the objections notwithstanding) and meets the quality requirements for standards-track outlined in RFC2026 or wherever. If the document was updated, a new Last Call is needed. After that Last Call (if any) the AD re-evaluates the situation and makes a recommendation to the full IESG to either drop the document (requiring the author to re-apply for IS action after some time) or approve it as-is (despite objections if any). > How would appeals against IS documents affect answers to these issues? > (Usually individual ADs take the first stab at handling appeals, > formal or informal, against WG chair decisions. When there's no WG > chair involved with a doc, I guess the appeal would go straight to the > whole IESG...) > Does sponsoring many IS documents give an AD, and the IESG as a whole, > too much power? AD and IESG discretion is needed to keep this from happening. But should IESG decide that the way to make progress in IETF is to do as much as possible with ISes and avoid forming working groups, it's hard to know what the best remedy is. Basically I think that it might be wise to have more formal criteria for what makes a valid IS, and to make approval of an IS subject to appeal if those criteria are violated. > Are we discouraging legitimate WGs by encouraging IS's? I think that there are cases where ISs are used to process things that really need more discussion and review, because many in industry see our WG process is seen as burdensome...and sometimes, subject to input from the "wrong" people. but that might be more indicative of problems with our WG process than of problems with our IS process. > What other purposes do WG's serve besides simply publishing documents, > that are not met by IS's? [3] Assuming that IETF can artract a wide enough set of interested parties, WGs are much better than non-WGs at determining requirements, avoiding output that harms valid interests, and review and refinement of nontrivial specifications. Also, there are processes required of WGs to ensure fairness that can't be applied to individuals. > If we turned down ISs in Apps, would the proposed work die, go > elsewhere or ... ? Would that be bad? What would happen, and whether that would be bad, depends on the specific work. Keith From discuss-bounces@apps.ietf.org Fri Sep 07 06:39:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITbD7-0006cv-Ry; Fri, 07 Sep 2007 06:37:13 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITbD7-0006cp-01 for discuss-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 06:37:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITbD6-0006ch-Mf for discuss@apps.ietf.org; Fri, 07 Sep 2007 06:37:12 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITbD4-0004zC-Ou for discuss@apps.ietf.org; Fri, 07 Sep 2007 06:37:12 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id l87Ab6kv003468 for ; Fri, 7 Sep 2007 19:37:07 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 6368_47a54f5a_5d2e_11dc_89cd_0014221fa3c9; Fri, 07 Sep 2007 19:37:06 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:40308) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 7 Sep 2007 19:34:05 +0900 Message-Id: <6.0.0.20.2.20070907185910.08c04300@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 07 Sep 2007 19:36:49 +0900 To: Lisa Dusseault , Apps Discuss From: Martin Duerst Subject: Re: Issues around sponsoring individual documents In-Reply-To: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org At 09:44 07/09/07, Lisa Dusseault wrote: > >The Applications area does not have a lot of attendees or WGs (I >oversee five, and of those five, three are within a document or two >of closing). Much of the current work is being done as individual >submissions (abbreviated IS in this email) [0]. I'd like to get some >input on how IS's should be handled. I have many opinions on IS >tradeoffs, having written several and sponsored more, but I'm trying >to phrase these questions without entirely presupposing my own >answers, and to reflect conflicted opinions and the criticisms I've >heard. I think the main case for IS is that there is less overhead. There are cases where something started as an IS, but there was controversy, so a WG was founded (LTRU, which I'm co-chairing). Without controversy, it wouldn't have needed a WG, because two predecessor documents (RFC 1766 and RFC 3066) were done as ISes. >(BTW, I'm sure I can follow the advice of "Use your judgement" if >anybody decides to say that, but it doesn't really inform that >judgement does it? ) > >Is an IS that defines a new protocol for the Standards Track fine in >general? Protocol is a very wide term. Something major like mail, HTTP, Atom, Jabber,... most probably no, but there are minor protocols that could easily be done by IS. >Is an IS that extends a standard protocol developed in a WG fine in >general? In most cases, yes. One of the goals of good protocol design is to make this possible. Things are often done on the mailing list of the former WG, or are done even while the WG is still around, but preferring to work on the main pieces, and not taking on a draft because they think it's uncontroversial and can be done as an IS. >Is an IS that obsoletes a standard protocol developed in a WG fine in >general? If that protocol is dead anyway, it will be difficult to find a WG chair and WG members,... I think there is another question that you may want to pose here: Is an IS that moves a Proposed/Draft Standard developed in a WG fine in general? And I would say yes to that question. The URI spec is definitely a good example. >Do IS's suffer from less review? Is that a problem? Some probably do. But there are very thin WGs, and there are WGs with lots of members but rarely anybody reading a document. More review is always better, but never easy to get. >Whose responsibility is it to get sufficient review? Mostly the author's. >Is it mostly well-connected individuals that can use the IS track, >knowing an AD to do the sponsoring? Or mostly individuals with a lot >of time on their hands? Time is needed both for WG drafts and for individual drafts. Connections are good, but they serve more to reduce the inhibition threshold. The first and foremost thing you need as an IS sumbmitter is to know that this can actually be done, and that happens mostly through connections. >An IS can have a non-AD document shepherd. Does encouraging that >improve the situation or make IS publishing even more dependent on >the author's connections? I think it's a good idea. It can definitely take off some load from the AD. But it may not always work out, or not always the same way. For draft-duerst-archived-at, the main thing that my shepheard did was to submit it as an IS when I didn't have the time to do so. After that, he wasn't reachable by email for a while. >Should I limit time spent sponsoring IS's? [1] IESG work plus IS >work could consume 30 hours a week, or 40, or 50... You definitely have to be careful with your load! I'm not sure why you say "IESG work plus IS work", after all, ISes also go for IESG approval. I'd written "WG work and IS work". The Application Area had lots more WGs a few years ago. You may scare off a few people by telling them that you won't accept a draft unless it comes through a WG, but you may then just get more WGs. Other Areas have some semi-standing WGs for extensions and updates and other ongoing work. We could have a "standing Email WG" and a "standing HTTP WG" and so on, but I don't think that would decrease your workload or would significantly improve the quality of what's now published via ISes. >Assuming I limit the potentially endless amount of work devoted to >IS's, do I limit it algorithmically (e.g. first come first served), >as a matter of pure taste, or other? >How should I prioritize IS sponsoring work? Which documents get my >attention first? [2] I think a major point is weeding out stuff that's not yet ready or doesn't really fit in your area, and so on. >When there's a question of consensus for an IS document, should I >just drop the document? That very much depends on the nature of the stuff, and the nature of the non-consensus. >Assuming I try to determine consensus how do I do so without an >official owning WG -- consensus calls to the IETF discuss list? There is a Last Call anyway, so I would only use the IETF list in very special situations. >Choose a related list and hope people are paying attention? Related lists are definitely a good thing. If there is no related list, that may be a sign that it doesn't belong in the IETF. But you shouldn't have to do that. The submitter (or shepherd) should come to you and give you pointers to discussions on such lists that already took place. >Do I need to ensure there's a quorum? There are no quora for WGs, so why would there be for ISes? I think one good check I'd use is whether there was discussion. In many ways, discussion with some degree of disagreement is better than no discussion, because it shows you that people have read the document, and have thought things through and hashed them out. >How would appeals against IS documents affect answers to these >issues? (Usually individual ADs take the first stab at handling >appeals, formal or informal, against WG chair decisions. When >there's no WG chair involved with a doc, I guess the appeal would go >straight to the whole IESG...) If it smells like appeals, it definitely smells like WG. >Does sponsoring many IS documents give an AD, and the IESG as a >whole, too much power? I don't think so. People can always complain during IETF Last Call, and if something is controversial, it will need a WG. Having ISes as a ligthweight process is a great advantage of the IETF, even if for you personally, ISes are more work than WG drafts. >Are we discouraging legitimate WGs by encouraging IS's? There is a wide spectrum where you can have it both ways. Which way you want it is mostly your call (and Chris', unless you are ready to have 10 WGs and don't mind if he only has 5 :-). >What other purposes do WG's serve besides simply publishing >documents, that are not met by IS's? [3] Besides what you say below, I think WGs are crucial for document suites. I don't think something like e.g. the series of documents currently being worked on by EAI could be handled as ISes. >If we turned down ISs in Apps, would the proposed work die, go >elsewhere or ... ? Would that be bad? If you think it belongs elsewhere, you should turn it down. Although I think you as an AD can sponsor just about any IS, I'd use "does it fall into the IETF work area" and "does it fall into the Application Area" as main criteria. Regards, Martin.s >Lisa > >[0] Note "Independent Submission" is a different thing, an I-D that >goes through the RFC Editor to RFC and never gets an IETF last call, >so it's marked as not an IETF document > >[1] So far I have been sponsoring nearly every document I'm asked to, >not really limiting. However I can see time limiting becoming required. > >[2] My current practice is to do WG-related work first, then IS- sponsoring work in rotation. Note that with WG-related work, the WG >chair does some work which I have to do with IS documents. IS >documents are usually more work for me than WG products. > >[3] I'll take a first stab at this one: > - creating buy-in among potential implementors, > - developing relationships that can lead to more interop work than >otherwise, > - choosing document editors that can reflect or build consensus, >strongarm them if necessary > > > > > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Fri Sep 07 07:31:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITc29-00063s-49; Fri, 07 Sep 2007 07:29:57 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITc28-00063m-Ej for discuss-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 07:29:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITc28-00062b-4d for discuss@apps.ietf.org; Fri, 07 Sep 2007 07:29:56 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITc26-0005xi-KC for discuss@apps.ietf.org; Fri, 07 Sep 2007 07:29:56 -0400 X-IronPort-AV: E=Sophos;i="4.20,220,1186351200"; d="scan'208";a="152493347" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Sep 2007 13:29:36 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l87BTWHJ005999; Fri, 7 Sep 2007 13:29:32 +0200 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp4722.cisco.com [10.61.82.113]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l87BTNgX004897; Fri, 7 Sep 2007 11:29:27 GMT Message-ID: <46E1360E.6010001@cisco.com> Date: Fri, 07 Sep 2007 13:29:18 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Issues around sponsoring individual documents References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> In-Reply-To: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7034; t=1189164572; x=1190028572; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Issues=20around=20sponsoring=20individual=20documents |Sender:=20; bh=Na6DfiZuLsssDgMnAG8qbb0erpQ6KWg4MlNo/Hgtte4=; b=IO/x1axb0s4U3Hw7nHbAU0pIdvDUjA0spFYwBL/0O79y4At6QJ0utAaK6K1zl3QPNEeVPE0W TFAB9CwGB9jBHLHV9jg+8fBHsmHi2v1s7+gkxzUlrBzoW/amHk8HAqUr; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hello Lisa, First let me say that I appreciate your openness in raising this issue. Obviously you're in the role because we do trust your judgment (nyeh nyeh nyeh ;-). That having been said: > > Is an IS that defines a new protocol for the Standards Track fine in > general? It Depends. Could you imagine DKIM going forward as an individual submission? I couldn't. We could never get the community to agree to it. Let's return to the purpose of WGs in the first place. They exist, in my opinion, as a convenience for area directors. You use them as a tool to drive consensus. It's a very heavy weight process which should be avoided when it can be. In spite of what I write below, however, I largely agree with Keith in terms of applicability of ISes. And so the standard (ahem) I would apply were I in your shoes (ouch) would be the following six questions: 1. Is this work appropriate to standardize? Is it important enough and is it in an area in which we have competence? If no, stop here and kill. 2. Will there be more than one or two implementors? If no, stop here and kill. Without sufficient intent from implementors, you probably don't have a viable specification, with or without a working group. Otherwise you're now to the point where you or a stuckee probably have to read the whole thing. So... 3. Are you confident that the community would agree with the approach taken? If not, perhaps a BoF? 4. Would the work benefit from working group review through forging of consensus through compromise and dialog? If yes, create a working group. Otherwise.. 5. Is the work ready for advancement? You have the right and responsibility to say, sometimes, "yes, this is improtant, but no this is not of sufficient quality that I believe it should be advanced, because...", followed by "take the following actions to improve the document and come back to me..." Some people say a WG can help here, but I'm not convinced. 6. Otherwise, sure, go ahead. But again, use your judgment. I can't envision all the exigencies. I take the tact that individual submissions should have the same priority as working group submissions once you've answered yes to both (1) and (2), with the understanding that you will then prioritize your work so as not to consume more than a reasonable amount of time on the AD job. The last thing we want is for ADs to burn out. If this means that documents are not put out fast enough, let's deal with that problem separately. To answer (3) and (4) there's no reason why you couldn't really on a group of advisors you trust. Call them document shepherds or whatever. If after last call you judge there not to be consensus there is no reason you couldn't send the thing to a working group to go get fixed. This will of course depend on the authors' wishes to a great extent. If they don't want to go through the pain of a working group, it's very hard to push something through in those circumstances. > Is an IS that extends a standard protocol developed in a WG fine in > general? Same answer as above. > Is an IS that obsoletes a standard protocol developed in a WG fine in > general? Same answer as above. > > Do IS's suffer from less review? Is that a problem? > Whose responsibility is it to get sufficient review? Joint between you and the authors. > > Is it mostly well-connected individuals that can use the IS track, > knowing an AD to do the sponsoring? Or mostly individuals with a lot > of time on their hands? How does one answer this? > An IS can have a non-AD document shepherd. Does encouraging that > improve the situation or make IS publishing even more dependent on the > author's connections? In an informal sense, yes. No reason for you not to have help. > > Should I limit time spent sponsoring IS's? [1] IESG work plus IS work > could consume 30 hours a week, or 40, or 50... You should limit the time you put into the IESG, but prioritize what is important, be it IS or WG. > > Assuming I limit the potentially endless amount of work devoted to > IS's, do I limit it algorithmically (e.g. first come first served), > as a matter of pure taste, or other? I'm going to presume from this line of questioning that you receive a lot of garbage. If the abstract looks stupid, unimportant, or otherwise indicates that the doc is not appropriate for the IETF, trust that the rest of the document is as well and say so and move on. > How should I prioritize IS sponsoring work? Which documents get my > attention first? [2] See above. > > When there's a question of consensus for an IS document, should I just > drop the document? No. If it's important figure out what to do. Perhaps that's a working group. Perhaps that's a set of clearly defined changes. Perhaps you have to drop it, but if it really is important, others will be willing to offer alternatives, given the chance. > Assuming I try to determine consensus how do I do so without an > official owning WG -- consensus calls to the IETF discuss list? > Choose a related list and hope people are paying attention? Yes. Consensus calls to the IETF discuss list, as well as anywhere else the info comes from. But you might want to draw people's attention to something you think is important. > Do I need to ensure there's a quorum? You don't need a quorum, but you'd better be very sure of yourself without one. I think it's a good idea for people to step and say, "this is a good idea" or "this is a bad idea" or "here is what would make this a good idea". Absent that, you should be conservative. > > How would appeals against IS documents affect answers to these issues? > (Usually individual ADs take the first stab at handling appeals, > formal or informal, against WG chair decisions. When there's no WG > chair involved with a doc, I guess the appeal would go straight to the > whole IESG...) If someone questions your consensus call that's a pretty easy appeal to handle. Also, your peers should give you advice about consensus before you make the call. > Does sponsoring many IS documents give an AD, and the IESG as a whole, > too much power? No. You still should heavily weight community consensus. And the IAB needs to pay attention. > > Are we discouraging legitimate WGs by encouraging IS's? Since a WG is a heavy weight tool for you, who cares? > What other purposes do WG's serve besides simply publishing documents, > that are not met by IS's? [3] > If we turned down ISs in Apps, would the proposed work die, go > elsewhere or ... ? Would that be bad? It Depends. If it's bad work, no. If it's work that's not appropriate for the IETF, no. If it's unimportant, no. Otherwise, yes. Eliot From discuss-bounces@apps.ietf.org Fri Sep 07 08:33:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITczu-0004NV-20; Fri, 07 Sep 2007 08:31:42 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITczs-0004NQ-PG for discuss-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 08:31:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITczs-0004NI-Fh for discuss@apps.ietf.org; Fri, 07 Sep 2007 08:31:40 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITczq-0007la-LY for discuss@apps.ietf.org; Fri, 07 Sep 2007 08:31:40 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1ITczp-0004x8-Ea; Fri, 07 Sep 2007 08:31:37 -0400 Date: Fri, 07 Sep 2007 08:31:36 -0400 From: John C Klensin To: Lisa Dusseault , Apps Discuss Subject: Re: Issues around sponsoring individual documents Message-ID: <42BF3C35C26E061411718788@p3.JCK.COM> In-Reply-To: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.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-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa, We've discussed aspects of this topic fairly extensively off-list, starting many months ago. I will try to avoid repeating that discussion here, but the summary is that I believe the growth of work being done in nominal ISs is a healthy adaptation to some evolution in the Applications Area. Some of our subject matter has gotten fairly specialized and we are seeing input from fewer generalists who have really put in the work to understand subject matter and context. At least some of the IS work has developed because of a perception that the WG process can actually produce less useful review because it introduces a lot of noise and opinions from people who don't know much about the subject matter and who are unwilling to actually read and study drafts (rather than, e.g., responding loudly to what they perceive as happening on mailing list threads). The review effort for 2821bis and 2822bis is fairly symptomatic in this regard, with a number of comments early in the process from people who had either not bothered to study the drafts, had not understood or accepted the constraints on an effort to move existing documents to Draft, or wanted to use the revision effort as a platform for completely revising the Internet email model. While the level of attention being paid to the work has waxed and waned (something that can also happen in a WG), I believe that we have actually gotten better input and review than might have been the case with a WG, especially had that WG drifted off into needing to educate a larger population or dispose of irrelevant concerns. I think that, if we have a problem, it is not having more variations than either "WG" or single-model Individual Submission process. But, even today, we don't have a single model for the latter: we have IS efforts that are really individual work; efforts that are the result of a self-selected but closed design team; efforts that are widely publicized to the IETF community and discussed on public, IETF-based, lists but not organized as WGs, and so on. I also believe that the true measure of the size of the Applications Area is better reflected in the amount of work we are getting out than in a count of WGs. Some comments on your specific questions below, but I'm largely in agreement with John Leslie and Martin Duerst and won't repeat their remarks. --On Thursday, 06 September, 2007 17:44 -0700 Lisa Dusseault wrote: >... > (BTW, I'm sure I can follow the advice of "Use your judgement" > if anybody decides to say that, but it doesn't really inform > that judgement does it? ) "Use your judgment" is, in fact, probably the right answer. I hope this discussion provides you the information and calibration you need. > Is an IS that defines a new protocol for the Standards Track > fine in general? > Is an IS that extends a standard protocol developed in a WG > fine in general? > Is an IS that obsoletes a standard protocol developed in a WG > fine in general? In each case, I don't think there is an "in general". I think you need to monitor the situations and the amount and quality of review. I think it is also important that we not automatically assume that having a WG implies extensive and competent review from diverse parties. Often that is that case, and perhaps it is a reasonable presumption in the absence of evidence to the contrary. But there have certainly been WGs --and particular documents coming out of otherwise well-behaved WGs-- in which there has been evidence that no careful, competent, and disinterested review occurs. > Do IS's suffer from less review? Is that a problem? > Whose responsibility is it to get sufficient review? The responsibility ought to lie with the authors and proposers. I believe that it is their responsibility to convince you, the IESG, and whatever portion of the community is interested and relevant that there is sufficient interest and review to justify standardization. Regardless of how it is developed, one of the requirements for an IETF standards-track document must be that people --other than the developers and, where relevant, the firms for which they work-- actually care whether there is a standard in the area and what it contains. One key difference between WG-produced and individual submission documents is that, because WGs go through a formal qualification and chartering process, there is a presumption that their work is relevant, appropriate for standardization, and has been reviewed. None of those presumptions automatically apply to an IS document; the authors of such documents need to convince the community that those criteria are met. On the other hand, none of them are automatically true of a WG product, but it is up to those who are convinced that one or more criteria have not been met to demonstrate that. > Is it mostly well-connected individuals that can use the IS > track, knowing an AD to do the sponsoring? Or mostly > individuals with a lot of time on their hands? I hope not. John's and Martin's comments are relevant here, but I would also point out that people who are well-connected also often have a much easier time getting WGs approved and through the system. Unfortunately, there is little or no substitute for experience in the IETF (not the same thing as being well-connected, but highly correlated often the more important of the two) as an aid to getting things through the system. >... > Should I limit time spent sponsoring IS's? [1] IESG work plus > IS work could consume 30 hours a week, or 40, or 50... > > Assuming I limit the potentially endless amount of work > devoted to IS's, do I limit it algorithmically (e.g. first > come first served), as a matter of pure taste, or other? > How should I prioritize IS sponsoring work? Which documents > get my attention first? [2] I think you have to look at subject matter and depth of support. My observation above about a variety of mechanisms being subsumed under "individual submissions" is important here. In most cases, if some individual shows up and says "I have this pet idea and I think it should be an IETF standard", you should send him or her away until and unless they can demonstrate support in the community for both the idea and for standardizing it. Put differently, use your own judgment, but remember that no idea has a right to be standardized, whether as an individual submission or via a WG. For this, and for several of your other questions, I think the burden is on the proposer to convince you that the idea is appropriate for standardization, that there is sufficient interest, that adequate review has occurred, and that an appropriate degree of consensus has been achieved. > How would appeals against IS documents affect answers to these > issues? (Usually individual ADs take the first stab at > handling appeals, formal or informal, against WG chair > decisions. When there's no WG chair involved with a doc, I > guess the appeal would go straight to the whole IESG...) No, the individual AD still takes the first stab. Agreeing to sponsor an IS doesn't automatically make you an advocate of any issue involving it. And the second step, according to the procedures, is a discussion with the IETF Chair. > Does sponsoring many IS documents give an AD, and the IESG as > a whole, too much power? Not in and of itself. Consistent bad judgment might, but this is not the only topic around which bad judgment can result in a concentration of power in the IESG. And, if the community doesn't have a way to deal with bad judgment by ADs, the problem to be solved isn't one of too many IS documents. > Are we discouraging legitimate WGs by encouraging IS's? Occasionally, probably so. We are also discouraging illegitimate WGs, would-be WGs that waste a lot of time and never get organized, WGs with such a high noise:signal ratio that it is impossible to get work done or evaluate consensus, and so on. The bottom line is that either the individual submission process or the WG one can be abused. >... john From discuss-bounces@apps.ietf.org Fri Sep 07 11:17:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITfYG-0000Ru-H0; Fri, 07 Sep 2007 11:15:20 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITfYF-0000Ro-6G for discuss-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 11:15:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITfYE-0000Rf-T1 for discuss@apps.ietf.org; Fri, 07 Sep 2007 11:15:18 -0400 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITfYD-00033C-DW for discuss@apps.ietf.org; Fri, 07 Sep 2007 11:15:18 -0400 Received: from pc6 (1Cust140.tnt30.lnd3.gbr.da.uu.net [62.188.122.140]) by astro.systems.pipex.net (Postfix) with SMTP id 4A22AE000492; Fri, 7 Sep 2007 16:15:13 +0100 (BST) Message-ID: <029c01c7f158$a61a3560$0601a8c0@pc6> From: "tom.petch" To: "Apps Discuss" , "Lisa Dusseault" References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> Subject: Re: Issues around sponsoring individual documents Date: Fri, 7 Sep 2007 15:42:33 +0200 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-Spam-Score: -100.9 (---------------------------------------------------) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa After perusing your e-mail, I am suffering from question overload. I think that IS suffer from too little review and, as such, damage the IETF. Sometimes, the first I am aware of them is when they are approved by the IESG; sometimes, they come to my attention when a Last Call discussion on the main IETF list highlights a deficiency which could have been fixed long before Last Call; sometimes such a Last Call discussion refers back to an approved RFC which now turns out to have a deficiency. Of course, any of this can happen with any I-D from any source but IS appear to contribute more than their share. I have put time and effort into trying to find if and where these I-Ds get discussed prior to Last Call and, apart from URI, have largely failed. I do receive and mostly look at each and every I-D announcement but do not always realise from the title and description whether or not I whould be interested. I often see posts which are concerned that the IESG have too much power, and in general, I disagree, but this is one area where is seems that they do, severally and collectively. This is a general, cross-area, comment and should not be taken as specific to the Apps area, or to you personally. Tom Petch ----- Original Message ----- From: "Lisa Dusseault" To: "Apps Discuss" Sent: Friday, September 07, 2007 2:44 AM Subject: Issues around sponsoring individual documents > > The Applications area does not have a lot of attendees or WGs (I > oversee five, and of those five, three are within a document or two > of closing). Much of the current work is being done as individual > submissions (abbreviated IS in this email) [0]. I'd like to get some > input on how IS's should be handled. I have many opinions on IS > tradeoffs, having written several and sponsored more, but I'm trying > to phrase these questions without entirely presupposing my own > answers, and to reflect conflicted opinions and the criticisms I've > heard. > > (BTW, I'm sure I can follow the advice of "Use your judgement" if > anybody decides to say that, but it doesn't really inform that > judgement does it? ) > > Is an IS that defines a new protocol for the Standards Track fine in > general? > Is an IS that extends a standard protocol developed in a WG fine in > general? > Is an IS that obsoletes a standard protocol developed in a WG fine in > general? > > Do IS's suffer from less review? Is that a problem? > Whose responsibility is it to get sufficient review? > > Is it mostly well-connected individuals that can use the IS track, > knowing an AD to do the sponsoring? Or mostly individuals with a lot > of time on their hands? > An IS can have a non-AD document shepherd. Does encouraging that > improve the situation or make IS publishing even more dependent on > the author's connections? > > Should I limit time spent sponsoring IS's? [1] IESG work plus IS > work could consume 30 hours a week, or 40, or 50... > > Assuming I limit the potentially endless amount of work devoted to > IS's, do I limit it algorithmically (e.g. first come first served), > as a matter of pure taste, or other? > How should I prioritize IS sponsoring work? Which documents get my > attention first? [2] > > When there's a question of consensus for an IS document, should I > just drop the document? > Assuming I try to determine consensus how do I do so without an > official owning WG -- consensus calls to the IETF discuss list? > Choose a related list and hope people are paying attention? > Do I need to ensure there's a quorum? > > How would appeals against IS documents affect answers to these > issues? (Usually individual ADs take the first stab at handling > appeals, formal or informal, against WG chair decisions. When > there's no WG chair involved with a doc, I guess the appeal would go > straight to the whole IESG...) > Does sponsoring many IS documents give an AD, and the IESG as a > whole, too much power? > > Are we discouraging legitimate WGs by encouraging IS's? > What other purposes do WG's serve besides simply publishing > documents, that are not met by IS's? [3] > If we turned down ISs in Apps, would the proposed work die, go > elsewhere or ... ? Would that be bad? > > Lisa > > [0] Note "Independent Submission" is a different thing, an I-D that > goes through the RFC Editor to RFC and never gets an IETF last call, > so it's marked as not an IETF document > > [1] So far I have been sponsoring nearly every document I'm asked to, > not really limiting. However I can see time limiting becoming required. > > [2] My current practice is to do WG-related work first, then IS- > sponsoring work in rotation. Note that with WG-related work, the WG > chair does some work which I have to do with IS documents. IS > documents are usually more work for me than WG products. > > [3] I'll take a first stab at this one: > - creating buy-in among potential implementors, > - developing relationships that can lead to more interop work than > otherwise, > - choosing document editors that can reflect or build consensus, > strongarm them if necessary > > > > > > > From discuss-bounces@apps.ietf.org Fri Sep 07 12:00:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITgEa-00087X-Pv; Fri, 07 Sep 2007 11:59:04 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITd0D-0004fJ-SA for discuss-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 08:32:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITd0D-0004fB-If for discuss@apps.ietf.org; Fri, 07 Sep 2007 08:32:01 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITd0C-0007lr-09 for discuss@apps.ietf.org; Fri, 07 Sep 2007 08:32:01 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A5FE8198659; Fri, 7 Sep 2007 15:31:58 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 349E7198658; Fri, 7 Sep 2007 15:31:58 +0300 (EEST) Message-ID: <46E144BF.1010909@piuha.net> Date: Fri, 07 Sep 2007 15:31:59 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Issues around sponsoring individual documents References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> In-Reply-To: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-Mailman-Approved-At: Fri, 07 Sep 2007 11:59:04 -0400 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa, You already got excellent feedback, but a couple of additional notes below: First, you know but the readers of this list might not know that there's an ION on this topic: http://www.ietf.org/IESG/content/ions/ion-ad-sponsoring.html The ION talks about, among other things, what factors the AD should consider when thinking about sponsoring a document (Section 5) and in what situations requiring all work to come from WGs is problematic (Section 6). > Do IS's suffer from less review? Is that a problem? > Whose responsibility is it to get sufficient review? > > Is it mostly well-connected individuals that can use the IS track, > knowing an AD to do the sponsoring? The AD should not accept proposals only from his or her friends; they can come from anybody and the same criteria should be used to judge all proposals. However, the ability to make such submissions is not perhaps widely enough known. > Does encouraging that improve the situation or make IS publishing even > more dependent on the author's connections? In my experience, having a shepherd does help. You get one more additional pair of eyes looking at the document, plus you can delegate some of the discussion during Last Call or with other reviewers to the shepherd. However, I don't always find a shepherd for individual submissions even if I want to. That's fine, too. > Should I limit time spent sponsoring IS's? > How should I prioritize IS sponsoring work? There's really no other answer than use your judgment. Work important for the Internet should get priority. Documents with many problems can consume a lot of time; in practice I at least also give priority for good and/or small documents that do not take a lot of my time. (My bar for sponsoring, say, a bug fix document to an existing RFC where the WG no longer exists is very low.) > When there's a question of consensus for an IS document, should I just > drop the document? > Assuming I try to determine consensus how do I do so without an > official owning WG -- consensus calls to the IETF discuss list? > Choose a related list and hope people are paying attention? The ION says that all individual documents (even Experimental ones) should go through IETF Last Call, because no last call was performed in a WG. So the minimum bar is review on the IETF discuss list. However, acceptance through silence is not a good option for this type of documents, as there is no guarantee that no one outside the authors and the AD has read them. As a result, it is often useful to solicit review from specific experts or lists, and make sure you get that review. > How would appeals against IS documents affect answers to these issues? The same rules apply. In this case there is no WG chair action to appeal. However, just as your actions in AD review can be appealed for regular documents, they can also be appealed for these documents. > Are we discouraging legitimate WGs by encouraging IS's? > What other purposes do WG's serve besides simply publishing documents, > that are not met by IS's? [3] > If we turned down ISs in Apps, would the proposed work die, go > elsewhere or ... ? Would that be bad? Both tools should be used for their appropriate purpose. There's a middleground where you could do something either in a WG or as an individual submission. If you find that your area has a significant number of individual submissions that could or perhaps even should be WG documents instead, maybe you need more working groups :-) For instance, some areas have area working groups that also deliver documents (bug fixes, architectural discussion documents, small extensions, etc). A protocol set that has a lot of maintenance issues could get a maintenance working group to deal with it instead of sending documents directly to you. Jari From discuss-bounces@apps.ietf.org Fri Sep 07 12:00:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITgEa-00087c-TO; Fri, 07 Sep 2007 11:59:04 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITfob-0001yu-Rp for discuss-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 11:32:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITfob-0001ym-I9 for discuss@apps.ietf.org; Fri, 07 Sep 2007 11:32:13 -0400 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITfoa-0003Sh-CJ for discuss@apps.ietf.org; Fri, 07 Sep 2007 11:32:13 -0400 Received: by an-out-0708.google.com with SMTP id d26so81651and for ; Fri, 07 Sep 2007 08:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=sWL+tsJoHpZRxv+/DpSaR8Uz9VvoVEkeZEZcibeo9Q4=; b=rsRb2v/rIuhrl7apiK58LeajZlX4/PQQgS+XTi1smX2g6rycLei7EWyCA6YRYvRG5SqElFSFSIGrmMYw+1NUl6cuTJucI2jnMuctaOouAca/cZB/aZLvIL3CW1lINMqPUP0yMjzClpF1Yqx8O9b36TANDVtDh0Ts4aWPJjf0x70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=Gr/Ha0jyceTlBts08PabHcCO751ys6J85KIVVlnLKnBKMVOQY+0DRDZfcMBOwuU4hEDpp98ixVrWNCguxmODFY05+tzz2AwUwOMfh6nVEgjJmbabA7UbobIbF2bT4u9iKj3An8CNNRNN9PaJ0CY+97eJptmnELhtZ0s4f4fdUQY= Received: by 10.100.106.5 with SMTP id e5mr2242070anc.1189179131875; Fri, 07 Sep 2007 08:32:11 -0700 (PDT) Received: from ?192.168.1.2? ( [67.181.218.96]) by mx.google.com with ESMTPS id 3sm910296wrs.2007.09.07.08.32.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Sep 2007 08:32:10 -0700 (PDT) Message-ID: <46E16EF7.5060907@gmail.com> Date: Fri, 07 Sep 2007 08:32:07 -0700 From: James M Snell User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Issues around sponsoring individual documents References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> In-Reply-To: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 X-Mailman-Approved-At: Fri, 07 Sep 2007 11:59:04 -0400 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa, Having written several IS drafts, one of which reached Proposed Standard status and another Experimental RFC, and another that I believe might have helped to motivate this particular note from you, I'd have to say that I think individual submissions are an important part of the process if handled properly. IS's can suffer from less review. The only way they can succeed is if there is an existing community that is interested enough to provide adequate review and if the author(s) of the spec are willing to active engage and respond to that community. In the case of the Atom-related specifications that I have produced, I have been fortunate in that the existing WG has been very willing to provide adequate feedback and the chairs have been very willing to put up with discussion about non-chartered topics. Controversies that have come up have been dealt with openly and honestly and the result has been very positive overall. I think the burden to demonstrate that standards track IS's have had adequate review falls on the author(s) and the AD who chooses to sponsor it. If the AD does not want to sponsor the draft, then so be it. The author(s) have the option of pursuing the creation of a formal WG if they think the work is important enough. Alternatively, the author(s) can choose to take another path such as publishing as an Informational or Experimental RFC, or publishing outside the IETF entirely. I would suggest that IS's that have a demonstrated record of being discussed and hashed out within an existing community such as a WG should be given priority in the queue. Doing so should encourage spec author(s) to take their IS's to the community and helps to address the concerns you are raising. If the community shows an interest, and if the author(s) demonstrate a willingness to listen and respond to the community, then the IS should be allowed to progress. - James Lisa Dusseault wrote: > > The Applications area does not have a lot of attendees or WGs (I oversee > five, and of those five, three are within a document or two of > closing). Much of the current work is being done as individual > submissions (abbreviated IS in this email) [0]. I'd like to get some > input on how IS's should be handled. I have many opinions on IS > tradeoffs, having written several and sponsored more, but I'm trying to > phrase these questions without entirely presupposing my own answers, and > to reflect conflicted opinions and the criticisms I've heard. > > (BTW, I'm sure I can follow the advice of "Use your judgement" if > anybody decides to say that, but it doesn't really inform that judgement > does it? ) > > Is an IS that defines a new protocol for the Standards Track fine in > general? > Is an IS that extends a standard protocol developed in a WG fine in > general? > Is an IS that obsoletes a standard protocol developed in a WG fine in > general? > > Do IS's suffer from less review? Is that a problem? > Whose responsibility is it to get sufficient review? > > Is it mostly well-connected individuals that can use the IS track, > knowing an AD to do the sponsoring? Or mostly individuals with a lot of > time on their hands? > An IS can have a non-AD document shepherd. Does encouraging that > improve the situation or make IS publishing even more dependent on the > author's connections? > > Should I limit time spent sponsoring IS's? [1] IESG work plus IS work > could consume 30 hours a week, or 40, or 50... > > Assuming I limit the potentially endless amount of work devoted to IS's, > do I limit it algorithmically (e.g. first come first served), as a > matter of pure taste, or other? > How should I prioritize IS sponsoring work? Which documents get my > attention first? [2] > > When there's a question of consensus for an IS document, should I just > drop the document? > Assuming I try to determine consensus how do I do so without an official > owning WG -- consensus calls to the IETF discuss list? Choose a related > list and hope people are paying attention? > Do I need to ensure there's a quorum? > > How would appeals against IS documents affect answers to these issues? > (Usually individual ADs take the first stab at handling appeals, formal > or informal, against WG chair decisions. When there's no WG chair > involved with a doc, I guess the appeal would go straight to the whole > IESG...) > Does sponsoring many IS documents give an AD, and the IESG as a whole, > too much power? > > Are we discouraging legitimate WGs by encouraging IS's? > What other purposes do WG's serve besides simply publishing documents, > that are not met by IS's? [3] > If we turned down ISs in Apps, would the proposed work die, go elsewhere > or ... ? Would that be bad? > > Lisa > > [0] Note "Independent Submission" is a different thing, an I-D that goes > through the RFC Editor to RFC and never gets an IETF last call, so it's > marked as not an IETF document > > [1] So far I have been sponsoring nearly every document I'm asked to, > not really limiting. However I can see time limiting becoming required. > > [2] My current practice is to do WG-related work first, then > IS-sponsoring work in rotation. Note that with WG-related work, the WG > chair does some work which I have to do with IS documents. IS documents > are usually more work for me than WG products. > > [3] I'll take a first stab at this one: > - creating buy-in among potential implementors, > - developing relationships that can lead to more interop work than > otherwise, > - choosing document editors that can reflect or build consensus, > strongarm them if necessary > > > > > > > > From discuss-bounces@apps.ietf.org Fri Sep 07 12:02:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITgG3-0000kN-7B; Fri, 07 Sep 2007 12:00:35 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITgG0-0000cZ-1q for discuss-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 12:00:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITgFz-0000cL-Mg for discuss@apps.ietf.org; Fri, 07 Sep 2007 12:00:31 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITgFy-00044Q-7I for discuss@apps.ietf.org; Fri, 07 Sep 2007 12:00:31 -0400 Received: from [192.168.0.6] (adsl-68-122-40-236.dsl.pltn13.pacbell.net [68.122.40.236]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l87G0AQF019824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Sep 2007 09:00:10 -0700 Message-ID: <46E17515.6040509@dcrocker.net> Date: Fri, 07 Sep 2007 08:58:13 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Issues around sponsoring individual documents References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> <42BF3C35C26E061411718788@p3.JCK.COM> In-Reply-To: <42BF3C35C26E061411718788@p3.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John C Klensin wrote: > but the summary is that I > believe the growth of work being done in nominal ISs is a > healthy adaptation to some evolution in the Applications Area. +1 to all of John's summary comments. They do such a nice job about the question that they probably should be published on a page somewhere. >> (BTW, I'm sure I can follow the advice of "Use your judgement" >> if anybody decides to say that, but it doesn't really inform >> that judgement does it? ) > > "Use your judgment" is, in fact, probably the right answer. Obtaining the support of an AD is an important part of the filtering process for IETF work, whether as a WG or an IS. That should not change. Although I think that John did not quite say it this way, I would suggest using 3 questions: 1. Import: Is the work worthy of sponsoring and spending time on? 2. Process: Is there a strong reason for pressing to have the work incur the administrative effort and protracted schedule of an IETF working group? What is it? 3. Support: Is the work already being done diligently without a formal working group or is there a good indication it will be? That is, are there adequate indications of current (or likely) community need and participation to make it likely that the document a) will be (or has been) developed with consensus and b) will be used by the community? Good work can happen outside an IETF working group. Bad work can happen inside one. So the most useful way to decide whether to sponsor some work is to consider import (quality and impact) and support questions rather than process questions. >> Is an IS that defines a new protocol for the Standards Track >> fine in general? >> Is an IS that extends a standard protocol developed in a WG >> fine in general? >> Is an IS that obsoletes a standard protocol developed in a WG >> fine in general? > > In each case, I don't think there is an "in general". I think > you need to monitor the situations and the amount and quality of > review. I think it is also important that we not automatically > assume that having a WG implies extensive and competent review +1. Perhaps a heuristic -- along with my #3, above, is to consider the complexity and risk of the work. That said, one can argue that working groups actually increase risk. (Yes, I'm serious. Note John's comments about uninformed participation. I'll also note that working groups have a habit of expanding scope and functionality of the work and that that is usually detrimental to its timeline and utility, IMO.) >> Do IS's suffer from less review? Is that a problem? >> Whose responsibility is it to get sufficient review? > > The responsibility ought to lie with the authors and proposers. > I believe that it is their responsibility to convince you, the > IESG, and whatever portion of the community is interested and +1. Perhaps more ought to lie with authors and proposers for working groups, but it's clear that an IS places (or should place) more burden on them. > One key difference > between WG-produced and individual submission documents is that, > because WGs go through a formal qualification and chartering > process, there is a presumption that their work is relevant, > appropriate for standardization, and has been reviewed. It also has the considerable benefit of being required to state its goals and deliverables explicitly (and clearly?) None of > those presumptions automatically apply to an IS document; Not automatically but I would claim that *all* good work should contain statements about this in the document. >> Should I limit time spent sponsoring IS's? [1] IESG work plus >> IS work could consume 30 hours a week, or 40, or 50... >> >> Assuming I limit the potentially endless amount of work >> devoted to IS's, do I limit it algorithmically (e.g. first >> come first served), as a matter of pure taste, or other? >> How should I prioritize IS sponsoring work? Which documents >> get my attention first? [2] > > I think you have to look at subject matter and depth of support. > My observation above about a variety of mechanisms being > subsumed under "individual submissions" is important here. +2 Focus on the nature, quality and importance of the work, not on whether it is formally a wg. Productivity and utility, rather than formality. In > most cases, if some individual shows up and says "I have this > pet idea and I think it should be an IETF standard", you should > send him or her away until and unless they can demonstrate > support in the community for both the idea and for standardizing > it. +1. But then, this is exactly the type of shepherding role that ADs provide for wg formation, too, I think. >> Does sponsoring many IS documents give an AD, and the IESG as >> a whole, too much power? > > Not in and of itself. Consistent bad judgment might, but this > is not the only topic around which bad judgment can result in a > concentration of power in the IESG. And, if the community > doesn't have a way to deal with bad judgment by ADs, the problem > to be solved isn't one of too many IS documents. Interesting topic. >> Are we discouraging legitimate WGs by encouraging IS's? > > Occasionally, probably so. We are also discouraging > illegitimate WGs, would-be WGs that waste a lot of time and > never get organized, WGs with such a high noise:signal ratio +1. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Fri Sep 07 16:02:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITk0g-0005tM-1E; Fri, 07 Sep 2007 16:00:58 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITk0f-0005tD-59 for discuss-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 16:00:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITk0e-0005t3-Rk for discuss@apps.ietf.org; Fri, 07 Sep 2007 16:00:56 -0400 Received: from gateout01.mbox.net ([165.212.64.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITk0d-0002OQ-GU for discuss@apps.ietf.org; Fri, 07 Sep 2007 16:00:56 -0400 Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gateout01.mbox.net (Postfix) with ESMTP id 1228515D1; Fri, 7 Sep 2007 20:00:52 +0000 (GMT) Received: from GW1.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.34P) with ESMTP id XID658Ligua10083Xo1; Fri, 07 Sep 2007 20:00:52 -0000 X-USANET-Source: 165.212.116.254 IN ldusseault@commerce.net GW1.EXCHPROD.USA.NET X-USANET-MsgId: XID658Ligua10083Xo1 Received: from [10.1.4.102] ([157.22.41.20]) by GW1.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Sep 2007 14:00:51 -0600 In-Reply-To: <46E16EF7.5060907@gmail.com> References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> <46E16EF7.5060907@gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/alternative; boundary=Apple-Mail-1-434654064 Message-Id: <4B7EAB5B-B6A5-44FE-AE66-4B302B70C4B1@commerce.net> From: Lisa Dusseault Subject: Re: Issues around sponsoring individual documents Date: Fri, 7 Sep 2007 13:00:51 -0700 To: James M Snell X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 07 Sep 2007 20:00:51.0323 (UTC) FILETIME=[CA7B24B0:01C7F189] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-1-434654064 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Sep 7, 2007, at 8:32 AM, James M Snell wrote: > Having written several IS drafts, one of which reached Proposed > Standard > status and another Experimental RFC, and another that I believe might > have helped to motivate this particular note from you,... Yes, but this wasn't the only one! Efforts by Dave Crocker and John Klensin are also prompting this line of questioning. But Paul's request added to yours to publish the Atom feature advertisement spec did prompt finishing the email to send it. I asked Paul if he'd be document shepherd for that spec, by the way, to do the work of determining what consensus was for which features to include, to write the doc shepherd's overview & help the process along. I'm not sure he thought that was inappropriate or just not something he had the time to do, but he declined. thanks, Lisa --Apple-Mail-1-434654064 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Sep 7, 2007, at = 8:32 AM, James M Snell wrote:

Having written several IS = drafts, one of which reached Proposed Standard

status and another = Experimental RFC, and another that I believe might

have helped to motivate this = particular note from you,...



Yes, but this wasn't the = only one!=A0 Efforts by Dave Crocker and John Klensin are also prompting = this line of questioning.=A0 But Paul's request added to yours to = publish the Atom feature advertisement spec did prompt finishing the = email to send it.=A0=A0

I asked Paul if he'd be = document shepherd for that spec, by the way, to do the work of = determining what consensus was for which features to include, to write = the doc shepherd's overview & help the process along.=A0 I'm not = sure he thought that was inappropriate or just not something he had the = time to do, but he declined.

thanks,
Lisa
<= /BODY>= --Apple-Mail-1-434654064-- From discuss-bounces@apps.ietf.org Fri Sep 07 16:22:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITkK6-0007Hj-Pa; Fri, 07 Sep 2007 16:21:02 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITkK5-0007HZ-Dz for discuss-confirm+ok@megatron.ietf.org; Fri, 07 Sep 2007 16:21:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITkK5-0007HQ-4S for discuss@apps.ietf.org; Fri, 07 Sep 2007 16:21:01 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITkK3-0002sx-KC for discuss@apps.ietf.org; Fri, 07 Sep 2007 16:21:01 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 13E63142224 for ; Fri, 7 Sep 2007 13:20:59 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYVvW6PLcwZ8 for ; Fri, 7 Sep 2007 13:20:53 -0700 (PDT) Received: from [10.1.4.102] (ip20.commerce.net [157.22.41.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 4AFF8142217 for ; Fri, 7 Sep 2007 13:20:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <4B7EAB5B-B6A5-44FE-AE66-4B302B70C4B1@commerce.net> References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> <46E16EF7.5060907@gmail.com> <4B7EAB5B-B6A5-44FE-AE66-4B302B70C4B1@commerce.net> Content-Type: multipart/alternative; boundary=Apple-Mail-5-435856563 Message-Id: <2FD3A323-C59E-4C50-87B9-145C3C2BBAC8@osafoundation.org> From: Lisa Dusseault Subject: Re: Issues around sponsoring individual documents Date: Fri, 7 Sep 2007 13:20:53 -0700 To: Apps Discuss X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-5-435856563 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Didn't mean to name names publicly! But as long as I am, I might as well characterize the ISs. Some are being run practically as if they are WG documents, with commentary on active WG or post-WG lists. James' and John's are in that category, as well as the IMAP i18n/collation docs. One is likely to become the standard extensibility discovery mechanism for a WG standard -- James'. Some are revising very widely used standards. John's and Dave's are in that category. Nearly half are URI scheme registrations, which must be IETF Consensus documents in order for the IANA registration to be allowed. Others register a single mail header, VCard property (Cullen's) or MIME type. A few are effectively from outside organizations including Odette, ISO, GSM, 3GPP and XMPP. One is attempting to describe requirements for future work, rather than define an implementable standard -- Sam's. Three ID authors requesting sponsoring have been fellow ADs (Sam, Cullen, Chris). Nine primary authors were people I've never met. Eight primary authors were people I have met at IETF meetings or elsewhere. IMO, most are good causes. Most are good quality. YMMV. Lisa On Sep 7, 2007, at 1:00 PM, Lisa Dusseault wrote: > > On Sep 7, 2007, at 8:32 AM, James M Snell wrote: > >> Having written several IS drafts, one of which reached Proposed >> Standard >> status and another Experimental RFC, and another that I believe might >> have helped to motivate this particular note from you,... > > > Yes, but this wasn't the only one! Efforts by Dave Crocker and > John Klensin are also prompting this line of questioning. But > Paul's request added to yours to publish the Atom feature > advertisement spec did prompt finishing the email to send it. > > I asked Paul if he'd be document shepherd for that spec, by the > way, to do the work of determining what consensus was for which > features to include, to write the doc shepherd's overview & help > the process along. I'm not sure he thought that was inappropriate > or just not something he had the time to do, but he declined. > > thanks, > Lisa --Apple-Mail-5-435856563 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Didn't mean to name names = publicly!=A0 But as long as I am, I might as well characterize the = ISs.

Some are = being run practically as if they are WG documents, with commentary on = active WG or post-WG lists.=A0 James' and John's are in that category, = as well as the IMAP i18n/collation docs.=A0
One is likely to = become the standard extensibility discovery mechanism for a WG standard = -- James'.
Some are revising very widely used standards.=A0 = John's and Dave's are in that category.
Nearly=A0half are URI = scheme registrations, which must be IETF Consensus documents in order = for the IANA registration to be allowed.=A0 Others register a single = mail header, VCard property (Cullen's) or MIME type.
A few are = effectively from outside organizations including Odette, ISO, GSM, 3GPP = and XMPP.
One is attempting to describe requirements for = future work, rather than define an implementable standard -- = Sam's.

Three = ID authors requesting sponsoring have been fellow ADs (Sam, Cullen, = Chris).
Nine primary authors were people I've never = met.
Eight primary authors were people I have met at IETF = meetings or elsewhere.

IMO, most are good causes.=A0= Most are good quality.=A0 YMMV.

Lisa

= On Sep 7, 2007, at 1:00 PM, Lisa Dusseault wrote:


On Sep 7, 2007, at 8:32 AM, James M Snell = wrote:

Having written several IS = drafts, one of which reached Proposed Standard
status and another Experimental RFC, and another that = I believe might
have helped to motivate this = particular note from you,...
=


Yes, but this wasn't the = only one!=A0 Efforts by Dave Crocker and John Klensin are also prompting = this line of questioning.=A0 But Paul's request added to yours to = publish the Atom feature advertisement spec did prompt finishing the = email to send it.=A0=A0

I asked Paul if he'd be = document shepherd for that spec, by the way, to do the work of = determining what consensus was for which features to include, to write = the doc shepherd's overview & help the process along.=A0 I'm not = sure he thought that was inappropriate or just not something he had the = time to do, but he declined.

thanks,
Lisa
<= /BLOCKQUOTE>

= --Apple-Mail-5-435856563-- From discuss-bounces@apps.ietf.org Sat Sep 08 07:20:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITyKg-0001g2-A7; Sat, 08 Sep 2007 07:18:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1ITyKe-0001fw-Ty for discuss-confirm+ok@megatron.ietf.org; Sat, 08 Sep 2007 07:18:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITyKe-0001fn-KN for discuss@apps.ietf.org; Sat, 08 Sep 2007 07:18:32 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITyKc-00072L-Ai for discuss@apps.ietf.org; Sat, 08 Sep 2007 07:18:32 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id l88BIOoG028369 for ; Sat, 8 Sep 2007 20:18:24 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 063e_3736faf4_5dfd_11dc_9376_0014221f2a2d; Sat, 08 Sep 2007 20:18:23 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:51902) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sat, 8 Sep 2007 20:07:07 +0900 Message-Id: <6.0.0.20.2.20070908104757.0783acd0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 08 Sep 2007 16:42:34 +0900 To: "tom.petch" , "Apps Discuss" , "Lisa Dusseault" From: Martin Duerst Subject: Re: Issues around sponsoring individual documents In-Reply-To: <029c01c7f158$a61a3560$0601a8c0@pc6> References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> <029c01c7f158$a61a3560$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.4 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Two additional comments, one on something Tom says below and one on James' situation. At 22:42 07/09/07, tom.petch wrote: >I have put time and effort into trying to find if and where these I-Ds get >discussed prior to Last Call and, apart from URI, have largely failed. I do >receive and mostly look at each and every I-D announcement but do not always >realise from the title and description whether or not I whould be interested. I think this is a valid point. The IETF discourages leaving any potentially instable pointers in documents, and this includes pointers to mailing lists, issues lists, and so on. For RFCs, this makes quite a bit of sense (although it may sometimes go too far), and it tends to affect Internet Drafts strongly. After all, everybody wants to publish Internet Drafts as RFCs, so they better conform to the rules for RFCs. For people with some basic knowlegde about IETF WGs, that's no problem for WG drafts. Take the group of letters appearing in the draft name after draft-ietf-, and work from there. However, for individual drafts, it is a problem. What I have been doing, at least for some drafts, is to add a special paragraph, ideally in the Abstract (because that goes out with the announcement), that may read something like this (taken from an actual draft of mine): [RFC Editor: Please remove this paragraph before publication.] This is a draft to update RFC 3987 and move towards IETF Draft Standard. For an issues list/change log and additional information, please see http://www.w3.org/International/iri-edit. I think we should incourage things like this more. As for the Atom-related drafts that James was working on, I think that's one situation where I could understand if the AD just told the author and the WG: Please make this a WG draft. I don't want to say that it has to be done that way, but if there is a WG anyway, and the draft is discussed anyway on the WG list, and is closely related to the actual WG work (e.g. an extension, or even a way to discover extensions), if I were an AD, I'd definitely think about trying to reduce my workload by having a WG chair do the shephearding ex officio, rather than politely asking him/her and being declined. Creating a WG is a huge overhead, but having a WG being formally responsible for a draft that they discuss anyway isn't too much overhead. Just an idea. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From discuss-bounces@apps.ietf.org Sat Sep 08 14:10:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU4jX-0005xF-PQ; Sat, 08 Sep 2007 14:08:39 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IU4jV-0005vA-Ax for discuss-confirm+ok@megatron.ietf.org; Sat, 08 Sep 2007 14:08:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU4jU-0005t6-UT for discuss@apps.ietf.org; Sat, 08 Sep 2007 14:08:36 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IU4jT-0004IT-E4 for discuss@apps.ietf.org; Sat, 08 Sep 2007 14:08:36 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 8 Sep 2007 19:08:33 +0100 Message-ID: <46E2E54A.2050406@isode.com> Date: Sat, 08 Sep 2007 19:09:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ietf@ietf.org, discuss@apps.ietf.org, ietf-http-wg@w3.org, ietf-http-auth@osafoundation.org, saag@mit.edu Subject: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This message is trying to summarize recent discussions on draft-hartman-webauth-phishing-05.txt. Several people voiced their support for the document (on IETF mailing list and in various other off-list discussions). Ekr doesn't think that the document should be published in the current form and he has some good technical points that need to be addressed. At least one more revision is needed to addressed recent comments from Ekr and SecDir review. It is quite clear that some people got confused about intended status of this document and whether it represents IETF consensus. Sam has clarified what was his intention, but another consensus call is needed to make sure people agree with Sam. Subsequent discussions and consensus calls on the document would happen on . Alexey, in my capacity of shepherd for draft-hartman-webauth-phishing From discuss-bounces@apps.ietf.org Sun Sep 09 12:01:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUPBm-0000yN-VV; Sun, 09 Sep 2007 11:59:10 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUPBl-0000sK-GV for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Sep 2007 11:59:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUPBl-0000qg-6a for discuss@apps.ietf.org; Sun, 09 Sep 2007 11:59:09 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUPBj-0008B3-Oi for discuss@apps.ietf.org; Sun, 09 Sep 2007 11:59:09 -0400 Received: from [192.168.0.6] (adsl-68-122-40-236.dsl.pltn13.pacbell.net [68.122.40.236]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l89Fwklc010984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Sep 2007 08:58:47 -0700 Message-ID: <46E417BF.9050707@dcrocker.net> Date: Sun, 09 Sep 2007 08:56:47 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Martin Duerst Subject: Re: Issues around sponsoring individual documents References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> <029c01c7f158$a61a3560$0601a8c0@pc6> <6.0.0.20.2.20070908104757.0783acd0@localhost> In-Reply-To: <6.0.0.20.2.20070908104757.0783acd0@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Apps Discuss , Lisa Dusseault X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Martin Duerst wrote: > At 22:42 07/09/07, tom.petch wrote: >> I have put time and effort into trying to find if and where these I-Ds get >> discussed prior to Last Call and, apart from URI, have largely failed. I do >> receive and mostly look at each and every I-D announcement but do not always >> realise from the title and description whether or not I whould be interested. > > I think this is a valid point. The IETF discourages leaving any potentially > instable pointers in documents, and this includes pointers to mailing Well, not really. Internet Drafts frequently state where to go for online discussion. Certainly all the drafts I've been involved in in recent years do this. And there is an established method of marking text that is to be removed prior to RFC publication. There was a suggestion to mandate having all Internet Drafts contain an email address for discussion, but it was not pursued. As I recall, the fact that the information can be ferreted out, for working group drafts, was the reason for not requiring it to be listed in every I-D. My own view is that the entire purpose of an I-D is for discussion, so the address ought to be mandated, to make sure that the problem you cite does not occur. It is easy information to provide and it saves potential contributors quite a bit of frustration. > As for the Atom-related drafts that James was working on, > I think that's one situation where I could understand if the AD > just told the author and the WG: Please make this a WG draft. It is common for "related" drafts to be outside the scope of the wg charter. The AD cannot simply instruct the wg to go beyond that scope. So it is not uncommon for an informal wg task to be pursued formally as an individual submission. > if I were an AD, I'd definitely think about trying to reduce > my workload by having a WG chair do the shephearding ex officio, > rather than politely asking him/her and being declined. Yup. > Creating a WG is a huge overhead, but having a WG being > formally responsible for a draft that they discuss anyway > isn't too much overhead. Just an idea. Given the need to modify the charter, it actually is very high overhead. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Sun Sep 09 14:31:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IURXC-0001IK-4t; Sun, 09 Sep 2007 14:29:26 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IURXB-0001I9-2w for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Sep 2007 14:29:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IURXA-0001I1-PM for discuss@apps.ietf.org; Sun, 09 Sep 2007 14:29:24 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IURX9-0003HN-8A for discuss@apps.ietf.org; Sun, 09 Sep 2007 14:29:24 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 9 Sep 2007 19:29:20 +0100 Message-ID: <46E43BA9.3080407@isode.com> Date: Sun, 09 Sep 2007 19:30:01 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Eric Rescorla Subject: Re: [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) References: <46E2E54A.2050406@isode.com> <20070908205337.82EC933C39@delta.rtfm.com> In-Reply-To: <20070908205337.82EC933C39@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ietf-http-auth@osafoundation.org, discuss@apps.ietf.org, saag@mit.edu, ietf@ietf.org, ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Eric Rescorla wrote: >Alexey wrote: > > >>This message is trying to summarize recent discussions on >>draft-hartman-webauth-phishing-05.txt. >> >>Several people voiced their support for the document (on IETF mailing >>list and in various other off-list discussions). Ekr doesn't think that >>the document should be published in the current form and he has some >>good technical points that need to be addressed. At least one more >>revision is needed to addressed recent comments from Ekr and SecDir review. >> >>It is quite clear that some people got confused about intended status of >>this document and whether it represents IETF consensus. Sam has >>clarified what was his intention, but another consensus call is needed >>to make sure people agree with Sam. >> >>Subsequent discussions and consensus calls on the document would happen >>on . >> >>Alexey, >>in my capacity of shepherd for draft-hartman-webauth-phishing >> >> >I object to this procedure. > >This document has already had an IETF Last Call, where it failed to >achieve consensus. > Ekr, I have to disagree with you. One objection about the document and one objection about the intended status doesn't constitute "failed consensus", considering there are at least 8 other people who are in favor of publishing the document. I can publish the list of reviewers, if you insist. >At this point, it doesn't need additional last >calls to "make sure that people agree with Sam", but rather to go back >to the authors to try to build support in the community. > I was probably not clear enough in my previous message: 1). The document needs more work. 2). The document needs more reviews. Discussions of future revisions should happen on ietf-http-auth@osafoundation.org 3). The document was effectively reset to pre-IETF LC state. >Not liking the result of the previous Last Call is not a sufficient basis for >issuing another one. > > This statement taken in isolation is certainly correct. However if the original LC didn't ask the right question, don't you think this makes answers meaningless? >At some point in the future, it may be appropriate to issue another >consensus call, but since this is not a WG mailing list--indeed, the >IESG has twice declined to charter a WG in this area--nor are you the >chair, it doesn't seem to me that you have standing to do that. When >that time comes, I would expect the IESG to designate an appropriate >time and place. > > I have support of the shepherding AD. Do you think this is insufficient? From discuss-bounces@apps.ietf.org Mon Sep 10 07:07:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUh55-0008Cd-82; Mon, 10 Sep 2007 07:05:27 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUh53-00085W-Ax for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 07:05:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUh52-00084l-NC for discuss@apps.ietf.org; Mon, 10 Sep 2007 07:05:25 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUh51-0000hd-8A for discuss@apps.ietf.org; Mon, 10 Sep 2007 07:05:24 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8AB5G2O000751; Mon, 10 Sep 2007 14:05:16 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 14:05:05 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 14:05:04 +0300 Received: from [172.21.35.195] (esdhcp035195.research.nokia.com [172.21.35.195]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8AB4qdJ002898; Mon, 10 Sep 2007 14:04:54 +0300 In-Reply-To: <46E417BF.9050707@dcrocker.net> References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> <029c01c7f158$a61a3560$0601a8c0@pc6> <6.0.0.20.2.20070908104757.0783acd0@localhost> <46E417BF.9050707@dcrocker.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-41-661690838; protocol="application/pkcs7-signature" Message-Id: <6C8ADE70-5028-4876-9AA7-6E3DB297481B@nokia.com> From: Lars Eggert Subject: Re: Issues around sponsoring individual documents Date: Mon, 10 Sep 2007 14:04:48 +0300 To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Sep 2007 11:05:04.0680 (UTC) FILETIME=[70D3F280:01C7F39A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Apps Discuss , Lisa Dusseault X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-41-661690838 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On 2007-9-9, at 18:56, ext Dave Crocker wrote: > Martin Duerst wrote: >> As for the Atom-related drafts that James was working on, >> I think that's one situation where I could understand if the AD >> just told the author and the WG: Please make this a WG draft. > > It is common for "related" drafts to be outside the scope of the wg > charter. The AD cannot simply instruct the wg to go beyond that > scope. So it is not uncommon for an informal wg task to be pursued > formally as an individual submission. The AD actually can, if the WG is interested, because the charter is negotiated between the AD and the WG, followed by an IESG approval. (If the WG - i.e., the expert community around a protocol - is not interested in a document, that should indicate that further questions may need to be asked about it before it should become an IS.) >> Creating a WG is a huge overhead, but having a WG being >> formally responsible for a draft that they discuss anyway >> isn't too much overhead. Just an idea. > > Given the need to modify the charter, it actually is very high > overhead. Not really. Minor recharterings to add well-defined work items aren't complicated. Lars --Apple-Mail-41-661690838 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA5MTAxMTA0NDhaMCMGCSqGSIb3DQEJBDEWBBTkbp5jpiiaJGV5 5/5n4xYe7aSI0jCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAi1l9pxmXR9t1tHsR3oslfxLPEdcdCi0seUrM8T8eito6KXPdYeR4 LR1hCJzfl6nsiZTNzmXTaQYV/3L43iepHgMB1/aRWNXKN3G7MECgI4BC7UgGjNLGv7ISNCsDCdgg 7SVKgj60a4IwqdS+v/lExX/POE8Hq1+Nh4cEB20s+IMOirQZWTaVDT5NIaZKAcL18mnJ2K4lYM+r xU+FbRuxFHwrbVKnveh/O+vU74WzMNzeuClHpbydP5GZbTOdoSH3Xmd0kNZmofPatF4hQevBvZiZ uGJMBieS/ZMRHbQZr5U5GAHh/ZubbVtILgjAlBaD4+u0iHRamapv14zXXy493AAAAAAAAA== --Apple-Mail-41-661690838-- From discuss-bounces@apps.ietf.org Mon Sep 10 07:19:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUhHB-0002bS-Pe; Mon, 10 Sep 2007 07:17:57 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUhHA-0002b5-Vw for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 07:17:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUhHA-0002ag-MA for discuss@apps.ietf.org; Mon, 10 Sep 2007 07:17:56 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUhH9-0000wO-7A for discuss@apps.ietf.org; Mon, 10 Sep 2007 07:17:56 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8ABHSmj007881; Mon, 10 Sep 2007 14:17:53 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 14:17:40 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 14:17:39 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 14:17:38 +0300 Received: from [172.21.35.195] (esdhcp035195.research.nokia.com [172.21.35.195]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8ABHX0X014300; Mon, 10 Sep 2007 14:17:33 +0300 In-Reply-To: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-42-662451505; protocol="application/pkcs7-signature" Message-Id: <549EFD98-2A83-4E57-994C-E52A40729152@nokia.com> From: Lars Eggert Subject: Re: Issues around sponsoring individual documents Date: Mon, 10 Sep 2007 14:17:28 +0300 To: ext Lisa Dusseault X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Sep 2007 11:17:39.0025 (UTC) FILETIME=[3273DC10:01C7F39C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-42-662451505 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, you've gotten a lot of good feedback already. My viewpoint differs a bit, in that I'm more hesitant about the widespread use of the IS path. An IS should be a rare exception, with the much more well- defined and -tested WG process the rule. Because people see the IS path as a shortcut - and even worse, an "insider" shortcut - the more you let them take it, the more requests you will get in the future. It starts to erode the process. Just say no. Or, actually, ask yourself if the gain from pushing something through as an IS is worth the pain in terms of extra management and maybe future work. If the gain is worth it *to you* (don't forget the IS path is at your discretion, and your judgement decides) then sure, go ahead. But in general, I'd encourage you to tell people to publish their documents through the appropriate working group, and if there isn't one, tell them to prepare a BOF. WGs have existed to only work on one or two documents (PMTUD, for example). WGs come with chairs and they come with an established management process, both of which reduce your workload (even more so with PROTO). Lars PS: Another alternative to IS is something like TSVWG (and now OPSAWG) to work in a more open fashion on documents and topics that maybe don't warrant their own WG. --Apple-Mail-42-662451505 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA5MTAxMTE3MjlaMCMGCSqGSIb3DQEJBDEWBBS1jr8p50Y4WzkD B7gflLMiCOZaqjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEASYoso9qBrjY9UKXZnBk+DMuTNT63PU7p+HXP7yEV68Gv8RMWFMTy YuLB9+JhepD+g/5eb02qrPD5vJDMTGc/y39xkXV0Crcq6Ge5GL6UUYeHZ6oJWOnVJn9r+OMnNeQQ YyrieY0dWrqUkKg67uBrmUYDCQQi8vOk5OjuY3EmVcXnjcQKwbTtI5NS/5Dga1kStr/MS/6hSAP+ uCTe7V/A2rjLjPr51vl4qtjqwJCIhy2o8WBVfmrn1qZD0LdsrfUt+Wy6b6a1dPo2P0nJlgyrlmtw uS3FxTqVFv/bxv7SqWYCszrjpA8f7vweod743vmaAP5C1nPc8b2/uJUFrnYP+QAAAAAAAA== --Apple-Mail-42-662451505-- From discuss-bounces@apps.ietf.org Mon Sep 10 10:28:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkEE-0008Tt-EC; Mon, 10 Sep 2007 10:27:06 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUkED-0008Ta-Cw for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 10:27:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkED-0008TR-2p for discuss@apps.ietf.org; Mon, 10 Sep 2007 10:27:05 -0400 Received: from sparkle.rodents.montreal.qc.ca ([216.46.5.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUkEB-00079n-EO for discuss@apps.ietf.org; Mon, 10 Sep 2007 10:27:04 -0400 Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id KAA03299; Mon, 10 Sep 2007 10:26:53 -0400 (EDT) From: der Mouse Message-Id: <200709101426.KAA03299@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 10 Sep 2007 10:14:07 -0400 (EDT) To: ietf-http-auth@osafoundation.org, discuss@apps.ietf.org, saag@mit.edu, ietf@ietf.org, ietf-http-wg@w3.org Subject: Re: [saag] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) In-Reply-To: <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > I really dislike the use of "fishing" with creative spelling in a > document prepared for an international standards organization. Perhaps unfortunately, that is *the* word for the behaviour in question, at least in English. It was not invented for the draft, and "com[ing] up with something [else]" would be *less* descriptive and would render the document cryptic to the people who's been working against phishing for years. Perhaps it's a bad word to use in other languages, but that should be addressed by the translator(s) in question, not by mangling the original. > [...], because it sends a number of very bad messages: > - it's ok for browser vendors to play fast and loose with security > related UI elements such as the lock icon and the URL bar (i.e., > have them controlled by the remote server) > - it's ok for domain vendors to sell domains that use IDN trickery > - it's ok for certificate vendors to sell certificates that seem to > be tied to some known entity but are in reality tied to a different > entity It appears they *are* OK, pragmatically; at least, the first and third - and quite possibly the second, for all I know - are continuing with no apparent backlash. > All of these are unacceptable and we as users of these services, > community members, engineers and IETF members should do what we can > to make sure that they don't happen. Ideally, yes. Let me know when you manage to get users to drop every major Web browser and every major cert vendor because they're insecure against these attacks - never mind when you find users competent to even understand the issue, much less evaluate Web browsers and cert vendors in these regards. In the meantime, I see nothing wrong (and much right) with a draft that addresses this problem - or at least tries to - in the world as it is, rather than the world as you, me, and a tiny minority of other people would like it to be. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse@rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From discuss-bounces@apps.ietf.org Mon Sep 10 10:59:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkiI-0008N9-Pq; Mon, 10 Sep 2007 10:58:10 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUkiH-0008N3-JX for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 10:58:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUkiH-0008Mv-A3 for discuss@apps.ietf.org; Mon, 10 Sep 2007 10:58:09 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUkiB-0008DX-OA for discuss@apps.ietf.org; Mon, 10 Sep 2007 10:58:09 -0400 Received: from [127.0.0.1] (helo=p2) by bs.jck.com with esmtp (Exim 4.34) id 1IUki8-000M3v-Jg; Mon, 10 Sep 2007 10:58:01 -0400 Date: Mon, 10 Sep 2007 10:57:58 -0400 From: John C Klensin To: Lars Eggert , ext Lisa Dusseault Subject: Re: Issues around sponsoring individual documents Message-ID: <0BDD887F6192620BD79F5C4D@[192.168.1.110]> In-Reply-To: <549EFD98-2A83-4E57-994C-E52A40729152@nokia.com> References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> <549EFD98-2A83-4E57-994C-E52A40729152@nokia.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Monday, September 10, 2007 2:17 PM +0300 Lars Eggert wrote: > Hi, > > you've gotten a lot of good feedback already. My viewpoint > differs a bit, in that I'm more hesitant about the widespread > use of the IS path. An IS should be a rare exception, with the > much more well-defined and -tested WG process the rule. Lars, I have to disagree, unless the WG process can be made both a lot more efficient and a lot lower noise. See my earlier note about this and please understand that the Apps area may be more subject to the noise factor than other areas... for several reasons, some good and some bad. > Because people see the IS path as a shortcut - and even worse, > an "insider" shortcut - the more you let them take it, the > more requests you will get in the future. Well, some of us don't see it primarily as a shortcut (although sometimes it might be) but as a more efficient way to get some kinds of work done. > It starts to erode > the process. Just say no. Or, actually, ask yourself if the > gain from pushing something through as an IS is worth the pain > in terms of extra management and maybe future work. If the > gain is worth it *to you* (don't forget the IS path is at your > discretion, and your judgement decides) then sure, go ahead. > But in general, I'd encourage you to tell people to publish > their documents through the appropriate working group, and if > there isn't one, tell them to prepare a BOF. Which, under most circumstances, immediately adds at least four to six months to the process without, in most cases, getting any incremental work done. It also tends to open up discussions about what problem should be solved. That is extremely useful in some cases and a total waste of time in others, but the length of time it takes seems to be independent of value. As costs rise and industry pressure for timely results increases, "go spend an extra six (or more) months organizing a WG and then take twice the time a WG should take, not due to tying down details but with trying to deal fairly with irrelevant noise" is going to be increasingly equivalent to "take that work outside the IETF". I don't think an IETF effort should take one day less time than it takes to get things right (separating me from some folks who favor "accept the tolerably good as long as it is timely") but I don't think it should take one week longer, either. I don't think that convincing people to go elsewhere is a desirable outcome. That is especially true when the issue at hand is revision/ advancement of existing IETF standards, where we know who most of the experts are, have mailing lists on which to "advertise" for participants, have constraints about what changes can be made, and really don't need to spend WG time reopening old issues. > WGs have existed > to only work on one or two documents (PMTUD, for example). WGs > come with chairs and they come with an established management > process, both of which reduce your workload (even more so with > PROTO). Having been an AD, although long ago, and watched the process for years, I question that generality of this assertion too. Sometimes they do, sometimes they don't. > PS: Another alternative to IS is something like TSVWG (and now > OPSAWG) to work in a more open fashion on documents and topics > that maybe don't warrant their own WG. Sure. But it is not clear to me that those groups really force the kind of topic-specific expert review that we assume that we get from "ordinary" WGs. If they do, that is fine. But, if they don't, we may delude ourselves by then using a shortcut community review process that is inappropriate to those groups. With the diversity of Apps such groups tend to be particularly inappropriate (been there, tried that). We have tried, or at least discussed, a number of other alternatives to "pure" individual submission handling in Apps. I've shared some of these with Lisa. They include special open directorate review meetings (perhaps more like SAAG than like TSVWG, but I'm not sure any more), extending the Apps Area review process (which seems to work well), open review sessions at IETF meetings (tried once with IDNAbis and something I would recommend based on that experience) and generally holding independent submission authors and advocates responsible for demonstrating that adequate review has occurred. One size does not fit all. regards, john From discuss-bounces@apps.ietf.org Mon Sep 10 11:31:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlCt-000415-OL; Mon, 10 Sep 2007 11:29:47 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUlCs-00040v-Hd for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 11:29:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlCs-00040j-7z for discuss@apps.ietf.org; Mon, 10 Sep 2007 11:29:46 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUlCq-0000ss-5N for discuss@apps.ietf.org; Mon, 10 Sep 2007 11:29:46 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8AFTGmM006057; Mon, 10 Sep 2007 18:29:41 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 18:29:31 +0300 Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Sep 2007 18:29:30 +0300 Received: from [172.21.35.195] (esdhcp035195.research.nokia.com [172.21.35.195]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8AFTMFG003997; Mon, 10 Sep 2007 18:29:29 +0300 In-Reply-To: <0BDD887F6192620BD79F5C4D@[192.168.1.110]> References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> <549EFD98-2A83-4E57-994C-E52A40729152@nokia.com> <0BDD887F6192620BD79F5C4D@[192.168.1.110]> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-47-677561662; protocol="application/pkcs7-signature" Message-Id: From: Lars Eggert Subject: Re: Issues around sponsoring individual documents Date: Mon, 10 Sep 2007 18:29:18 +0300 To: ext John C Klensin X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Sep 2007 15:29:30.0860 (UTC) FILETIME=[61CEE2C0:01C7F3BF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: Apps Discuss , ext Lisa Dusseault X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --Apple-Mail-47-677561662 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi, John, On 2007-9-10, at 17:57, ext John C Klensin wrote: > --On Monday, September 10, 2007 2:17 PM +0300 Lars Eggert > wrote: >> you've gotten a lot of good feedback already. My viewpoint >> differs a bit, in that I'm more hesitant about the widespread >> use of the IS path. An IS should be a rare exception, with the >> much more well-defined and -tested WG process the rule. > > Lars, I have to disagree, unless the WG process can be made both a > lot more efficient and a lot lower noise. See my earlier note > about this and please understand that the Apps area may be more > subject to the noise factor than other areas... for several > reasons, some good and some bad. I do agree that because APP produces standards that tend to get wider exposure outside the IETF, it's a tricky area, and progressing work can take a lot of effort. (TSV is comfortable wedged between INT and APP, so we are are a bit more sheltered.) >> Because people see the IS path as a shortcut - and even worse, >> an "insider" shortcut - the more you let them take it, the >> more requests you will get in the future. > > Well, some of us don't see it primarily as a shortcut (although > sometimes it might be) but as a more efficient way to get some > kinds of work done. Being flippant for a second, let's all use this more efficient way to get work done then! There is a tragedy-of-the-commons effect here - the IS procedure is only powerful if used sparingly, because otherwise the benefits go away. I completely agree with you that for important work that needs to happen on an aggressive timeline and is not controversial, it is a valid option that makes a lot of sense. But it comes at a price, namely, taking up a LOT more AD cycles than WG documents do. For special work items, IS is the right thing to do. But not everyone can be special. One rule of thumb that I've used in the past is "is this document as important as 3-5 WG documents?" Because that's my totally subjective measure of how much additional effort it takes. If the proponents asking for IS have a convincing answer, well, good. >> But in general, I'd encourage you to tell people to publish >> their documents through the appropriate working group, and if >> there isn't one, tell them to prepare a BOF. > > Which, under most circumstances, immediately adds at least four to > six months to the process without, in most cases, getting any > incremental work done. It also tends to open up discussions about > what problem should be solved. That is extremely useful in some > cases and a total waste of time in others, but the length of time > it takes seems to be independent of value. > > As costs rise and industry pressure for timely results increases, > "go spend an extra six (or more) months organizing a WG and then > take twice the time a WG should take, not due to tying down details > but with trying to deal fairly with irrelevant noise" is going to > be increasingly equivalent to "take that work outside the IETF". > I don't think an IETF effort should take one day less time than it > takes to get things right (separating me from some folks who favor > "accept the tolerably good as long as it is timely") but I don't > think it should take one week longer, either. I don't think that > convincing people to go elsewhere is a desirable outcome. That is > especially true when the issue at hand is revision/ advancement of > existing IETF standards, where we know who most of the experts are, > have mailing lists on which to "advertise" for participants, have > constraints about what changes can be made, and really don't need > to spend WG time reopening old issues. I'm all for streamlining the WG process, but that's a different discussion. IS lets you bypass some of the delays associated with having a WG, which makes it attractive, but the AD pays that cost in terms of cycles. That model doesn't scale. >> WGs have existed >> to only work on one or two documents (PMTUD, for example). WGs >> come with chairs and they come with an established management >> process, both of which reduce your workload (even more so with >> PROTO). > > Having been an AD, although long ago, and watched the process for > years, I question that generality of this assertion too. Sometimes > they do, sometimes they don't. Yes, I shouldn't have generalized this. But at least for me personally, the benefits of having shepherds and a well-defined process reduce the workload. >> PS: Another alternative to IS is something like TSVWG (and now >> OPSAWG) to work in a more open fashion on documents and topics >> that maybe don't warrant their own WG. > > Sure. But it is not clear to me that those groups really force the > kind of topic-specific expert review that we assume that we get > from "ordinary" WGs. If they do, that is fine. But, if they > don't, we may delude ourselves by then using a shortcut community > review process that is inappropriate to those groups. Oh, yes, having these catch-all WGs doesn't much help with getting documents adequately reviewed. It does help with the management aspect though. > With the diversity of Apps such groups tend to be particularly > inappropriate (been there, tried that). We have tried, or at least > discussed, a number of other alternatives to "pure" individual > submission handling in Apps. I've shared some of these with Lisa. > They include special open directorate review meetings (perhaps more > like SAAG than like TSVWG, but I'm not sure any more), extending > the Apps Area review process (which seems to work well), open > review sessions at IETF meetings (tried once with IDNAbis and > something I would recommend based on that experience) and generally > holding independent submission authors and advocates responsible > for demonstrating that adequate review has occurred. It may well be that a catch-all WG is the wrong model for APP. It's not a spectacular success in TSV, either, but it's better than any other alternative we though of. I only brought it up to bring it to Lisa's attention as an option to consider. Lars --Apple-Mail-47-677561662 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEGtxkLFHQu1g67hlmYfwPuIwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDEwNDE2MTE1NFoXDTA4MDEwNDE2MTE1 NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA26hjntVPZMiwh4d8tyuk9KiucvG92BVUGArk5zO1jhmq7tLFgU1mqcIg VGumfQqjkAzIuh83kxIiqBrB05Wvxp85apwt4sUCvzMe8mQWzZZZYp0rBzwpOj+VC5pxsMRYtYW+ BaTFBEmvFr7D7C7roZUk0lDppS5SZFs4SQbEe9ykB9aeUf1iTiw2+ikyP2+JEYto14WYCoxFWbms FbQ1uaaK+yn1WH2YHhyMfi0IOxuT0jtbsngjHJMpWIqq334zBhj+rPSUug47YBHr41FCDMHbbbjv WbyTyDYneOW3WY8LY8bGWVlAknQGB7lgduShe6e0RI/7SL/VE6X27lM9LwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQCx3nxxTg/WowobVTRXBiXUEEZj4LBiunWbuAnR0UbJIgijvq3JbiJvZo2gUGiW9LPaHSBz 4oxT1VR/S/6O0a4e87oV5cOQm6ReB68o9rDfUzxHTwoCfv2wwMwBrXyzQMjyQK4Lt8siV41gmZpm rSXMhjTJdd9uYYNoZKQLq+VM+TCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ a3GQsUdC7WDruGWZh/A+4jAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzA5MTAxNTI5MTlaMCMGCSqGSIb3DQEJBDEWBBRbJBHqPX0c6o+O EMB/vIHkzkcGxDCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEGtxkLFHQu1g67hlmYfwPuIw DQYJKoZIhvcNAQEBBQAEggEAkqS4EueoGbon7fek0xyiYZgfwyjA4DJsvTj9R8UaMVcPJwcIW7uc vDdLeVHW6g4/hJK7NRQFDIUy1HSOBSohRpoi9NjZcPk5LGhapaqjcFeZOwjxnMY72B9eXBoQfKNE SWvN8DwnhXg7M+kf/u91E2cNarhXexIXi/qDiFLfKmP6YTxC0VkBxClXRDuWs9QHiYt1mspYqLzV LYfqET0F1oBPgXXa1cJkemK/Y5Mnd8g0KxSTWAJ2A+8Y8NCnqNA31OKCPAVAKKnKKlAY5PrT/D3b Mj3NF9thZt/Kt/k5FnQWDg0Y1d0HenaIpaAAc8UyEKSLOcB2dy3xoIjTrmpoWAAAAAAAAA== --Apple-Mail-47-677561662-- From discuss-bounces@apps.ietf.org Mon Sep 10 11:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlU5-00075B-Sw; Mon, 10 Sep 2007 11:47:33 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IU7MW-0003jt-Pl for discuss-confirm+ok@megatron.ietf.org; Sat, 08 Sep 2007 16:57:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IU7MW-0003jk-FH for discuss@apps.ietf.org; Sat, 08 Sep 2007 16:57:04 -0400 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IU7MV-0002p3-6H for discuss@apps.ietf.org; Sat, 08 Sep 2007 16:57:04 -0400 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 82EC933C39; Sat, 8 Sep 2007 13:53:37 -0700 (PDT) Date: Sat, 08 Sep 2007 13:53:36 -0700 From: Eric Rescorla To: Alexey Melnikov Subject: Re: [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) In-Reply-To: <46E2E54A.2050406@isode.com> <86bqcc3nkk.wl%ekr@networkresonance.com> References: <46E2E54A.2050406@isode.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070908205337.82EC933C39@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Mon, 10 Sep 2007 11:47:32 -0400 Cc: ietf-http-auth@osafoundation.org, discuss@apps.ietf.org, saag@mit.edu, ietf@ietf.org, ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Alexey wrote: > This message is trying to summarize recent discussions on > draft-hartman-webauth-phishing-05.txt. > > Several people voiced their support for the document (on IETF mailing > list and in various other off-list discussions). Ekr doesn't think that > the document should be published in the current form and he has some > good technical points that need to be addressed. At least one more > revision is needed to addressed recent comments from Ekr and SecDir review. > > It is quite clear that some people got confused about intended status of > this document and whether it represents IETF consensus. Sam has > clarified what was his intention, but another consensus call is needed > to make sure people agree with Sam. > > Subsequent discussions and consensus calls on the document would happen > on . > > Alexey, > in my capacity of shepherd for draft-hartman-webauth-phishing I object to this procedure. This document has already had an IETF Last Call, where it failed to achieve consensus. At this point, it doesn't need additional last calls to "make sure that people agree with Sam", but rather to go back to the authors to try to build support in the community. Not liking the result of the previous Last Call is not a sufficient basis for issuing another one. At some point in the future, it may be appropriate to issue another consensus call, but since this is not a WG mailing list--indeed, the IESG has twice declined to charter a WG in this area--nor are you the chair, it doesn't seem to me that you have standing to do that. When that time comes, I would expect the IESG to designate an appropriate time and place. -Ekr From discuss-bounces@apps.ietf.org Mon Sep 10 11:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlU6-00076V-J3; Mon, 10 Sep 2007 11:47:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUWXG-0003QT-3R for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Sep 2007 19:49:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUWXF-0003QL-QD for discuss@apps.ietf.org; Sun, 09 Sep 2007 19:49:49 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUWXE-0001Pi-HZ for discuss@apps.ietf.org; Sun, 09 Sep 2007 19:49:49 -0400 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l89NmxZa003908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Sep 2007 16:48:59 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id l89NmdbV003547; Sun, 9 Sep 2007 16:48:39 -0700 (PDT) Date: Sun, 9 Sep 2007 16:48:39 -0700 From: Bill Manning To: Iljitsch van Beijnum Subject: Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) Message-ID: <20070909234839.GA2020@boreas.isi.edu> References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> User-Agent: Mutt/1.4.2.2i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@boreas.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Mon, 10 Sep 2007 11:47:32 -0400 Cc: ietf@ietf.org, discuss@apps.ietf.org, Marshall Eubanks , ietf-http-wg@w3.org, saag@mit.edu, ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, Sep 10, 2007 at 01:21:00AM +0200, Iljitsch van Beijnum wrote: > On 10-sep-2007, at 0:51, Marshall Eubanks wrote: > > >I tend to rely on Dictionaries to sort these things out - from > >Dictionary.com > > Dictionaries are useless, when in doubt they just add definitions. > For instance, try figuring out how many bytes there are in a megabyte > from a few dictionaries. > `When I use a word,' Humpty Dumpty said, in rather a scornful tone, `it means just what I choose it to mean -- neither more nor less.' --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From discuss-bounces@apps.ietf.org Mon Sep 10 11:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlU6-00076o-N2; Mon, 10 Sep 2007 11:47:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUYQH-0004Md-J6 for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Sep 2007 21:50:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUYQH-0004Lg-95 for discuss@apps.ietf.org; Sun, 09 Sep 2007 21:50:45 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUYQG-0004yT-0D for discuss@apps.ietf.org; Sun, 09 Sep 2007 21:50:45 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l8A1nDiV004852; Sun, 9 Sep 2007 18:49:13 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Sep 2007 18:50:39 -0700 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: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt) Date: Sun, 9 Sep 2007 18:47:58 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37013EDBE0@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt) Thread-Index: AcfzKj6eDFp6Aj4DQNKi/PQmpOaVfQAIVdHQ From: "Hallam-Baker, Phillip" To: "Iljitsch van Beijnum" , "Alexey Melnikov" X-OriginalArrivalTime: 10 Sep 2007 01:50:39.0347 (UTC) FILETIME=[FD24F430:01C7F34C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Mon, 10 Sep 2007 11:47:32 -0400 Cc: ietf-http-auth@osafoundation.org, discuss@apps.ietf.org, ietf-http-wg@w3.org, ietf@ietf.org, saag@mit.edu X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 > During the reading of this document, it occurred to me that=20 > HTTP digest authentication (RFC 2617) rather than the widely=20 > used practice of having security credentials be typed into an=20 > HTTP form would achieve 90% of the requirements all by=20 > itself.=20 Well maybe if people had listened to me then :-) But at this point fifteen years later Digest is not the way to go. First = Digest was designed under the express constraint of avoiding patent = encumberances. RSA and D-H were both off the table at the time. If I was to redo Digest today or expand its scope I would do it = differently. The main reason I would not is that SAML and WS-* both = provide an excellent solution. I very much like and support the = Cardspace idea of building into the O/S platform. I very much like the = OpenID concept of making the barrier to entry very low. I would like to = arrive at a happy combination of the existing proposals not see more = proposals put on the table at this point. From discuss-bounces@apps.ietf.org Mon Sep 10 11:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlU6-00076C-Ed; Mon, 10 Sep 2007 11:47:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUW6q-0004wY-Ej for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Sep 2007 19:22:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUW6q-0004wQ-5I for discuss@apps.ietf.org; Sun, 09 Sep 2007 19:22:32 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUW6m-0000xO-9j for discuss@apps.ietf.org; Sun, 09 Sep 2007 19:22:32 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l89NIYqS075023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Sep 2007 01:18:34 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) Date: Mon, 10 Sep 2007 01:21:00 +0200 To: Marshall Eubanks X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Mon, 10 Sep 2007 11:47:32 -0400 Cc: ietf@ietf.org, discuss@apps.ietf.org, ietf-http-wg@w3.org, saag@mit.edu, ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 10-sep-2007, at 0:51, Marshall Eubanks wrote: > I tend to rely on Dictionaries to sort these things out - from > Dictionary.com Dictionaries are useless, when in doubt they just add definitions. For instance, try figuring out how many bytes there are in a megabyte from a few dictionaries. From discuss-bounces@apps.ietf.org Mon Sep 10 11:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlU6-00075t-9v; Mon, 10 Sep 2007 11:47:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUUUn-0004uI-Sz for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Sep 2007 17:39:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUUUn-0004uA-JS for discuss@apps.ietf.org; Sun, 09 Sep 2007 17:39:09 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUUUl-0007dZ-OD for discuss@apps.ietf.org; Sun, 09 Sep 2007 17:39:09 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l89LZHTG073622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 9 Sep 2007 23:35:17 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <46E2E54A.2050406@isode.com> References: <46E2E54A.2050406@isode.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) Date: Sun, 9 Sep 2007 23:37:45 +0200 To: Alexey Melnikov X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-Mailman-Approved-At: Mon, 10 Sep 2007 11:47:32 -0400 Cc: ietf-http-auth@osafoundation.org, discuss@apps.ietf.org, saag@mit.edu, ietf@ietf.org, ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 8-sep-2007, at 20:09, Alexey Melnikov wrote: > This message is trying to summarize recent discussions on draft- > hartman-webauth-phishing-05.txt. > Several people voiced their support for the document (on IETF > mailing list and in various other off-list discussions). Ekr > doesn't think that the document should be published in the current > form and he has some good technical points that need to be > addressed. At least one more revision is needed to addressed recent > comments from Ekr and SecDir review. Here's an outsider review. What's an Ekr, btw? I really dislike the use of "fishing" with creative spelling in a document prepared for an international standards organization. The world certainly doesn't need more words that sound the same and differ in meaning only by the way they're written, and I'm not sure how prevalent this terminology is outside the US and/or the English speaking world. Please come up with something more descriptive. During the reading of this document, it occurred to me that HTTP digest authentication (RFC 2617) rather than the widely used practice of having security credentials be typed into an HTTP form would achieve 90% of the requirements all by itself. (More or less the same thing for S/MIME in mail.) The main part that's missing there is protection against a man in the middle. Obviously TLS goes through great pains to avoid men in the middle, but the document has no trouble throwing that out of the window: The attacker can also spoof trust markers such as the security lock, URL bar and other parts of the browser UI. And: Users do not typically understand certificates and cannot make informed decisions about whether the subject name in a certificate corresponds to the entity they are attempting to communicate with. As a consequence of this assumption, users will likely be fooled by strings either in website names or certificates that look visually similar but that are composed of different code points. Although I agree that a system that can work even under these assumptions would be great, I think it's harmful to adopt them in this way, because it sends a number of very bad messages: - it's ok for browser vendors to play fast and loose with security related UI elements such as the lock icon and the URL bar (i.e., have them controlled by the remote server) - it's ok for domain vendors to sell domains that use IDN trickery - it's ok for certificate vendors to sell certificates that seem to be tied to some known entity but are in reality tied to a different entity All of these are unacceptable and we as users of these services, community members, engineers and IETF members should do what we can to make sure that they don't happen. Last but not least, I'm guessing that "ben Laurie" is actually "Ben Laurie". From discuss-bounces@apps.ietf.org Mon Sep 10 11:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlU6-00076V-J3; Mon, 10 Sep 2007 11:47:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUWXG-0003QT-3R for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Sep 2007 19:49:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUWXF-0003QL-QD for discuss@apps.ietf.org; Sun, 09 Sep 2007 19:49:49 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUWXE-0001Pi-HZ for discuss@apps.ietf.org; Sun, 09 Sep 2007 19:49:49 -0400 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l89NmxZa003908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Sep 2007 16:48:59 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id l89NmdbV003547; Sun, 9 Sep 2007 16:48:39 -0700 (PDT) Date: Sun, 9 Sep 2007 16:48:39 -0700 From: Bill Manning To: Iljitsch van Beijnum Subject: Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) Message-ID: <20070909234839.GA2020@boreas.isi.edu> References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> User-Agent: Mutt/1.4.2.2i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@boreas.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Mon, 10 Sep 2007 11:47:32 -0400 Cc: ietf@ietf.org, discuss@apps.ietf.org, Marshall Eubanks , ietf-http-wg@w3.org, saag@mit.edu, ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, Sep 10, 2007 at 01:21:00AM +0200, Iljitsch van Beijnum wrote: > On 10-sep-2007, at 0:51, Marshall Eubanks wrote: > > >I tend to rely on Dictionaries to sort these things out - from > >Dictionary.com > > Dictionaries are useless, when in doubt they just add definitions. > For instance, try figuring out how many bytes there are in a megabyte > from a few dictionaries. > `When I use a word,' Humpty Dumpty said, in rather a scornful tone, `it means just what I choose it to mean -- neither more nor less.' --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From discuss-bounces@apps.ietf.org Mon Sep 10 11:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlU6-00076o-N2; Mon, 10 Sep 2007 11:47:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUYQH-0004Md-J6 for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Sep 2007 21:50:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUYQH-0004Lg-95 for discuss@apps.ietf.org; Sun, 09 Sep 2007 21:50:45 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUYQG-0004yT-0D for discuss@apps.ietf.org; Sun, 09 Sep 2007 21:50:45 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l8A1nDiV004852; Sun, 9 Sep 2007 18:49:13 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Sep 2007 18:50:39 -0700 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: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt) Date: Sun, 9 Sep 2007 18:47:58 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37013EDBE0@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt) Thread-Index: AcfzKj6eDFp6Aj4DQNKi/PQmpOaVfQAIVdHQ From: "Hallam-Baker, Phillip" To: "Iljitsch van Beijnum" , "Alexey Melnikov" X-OriginalArrivalTime: 10 Sep 2007 01:50:39.0347 (UTC) FILETIME=[FD24F430:01C7F34C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Mon, 10 Sep 2007 11:47:32 -0400 Cc: ietf-http-auth@osafoundation.org, discuss@apps.ietf.org, ietf-http-wg@w3.org, ietf@ietf.org, saag@mit.edu X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 > During the reading of this document, it occurred to me that=20 > HTTP digest authentication (RFC 2617) rather than the widely=20 > used practice of having security credentials be typed into an=20 > HTTP form would achieve 90% of the requirements all by=20 > itself.=20 Well maybe if people had listened to me then :-) But at this point fifteen years later Digest is not the way to go. First = Digest was designed under the express constraint of avoiding patent = encumberances. RSA and D-H were both off the table at the time. If I was to redo Digest today or expand its scope I would do it = differently. The main reason I would not is that SAML and WS-* both = provide an excellent solution. I very much like and support the = Cardspace idea of building into the O/S platform. I very much like the = OpenID concept of making the barrier to entry very low. I would like to = arrive at a happy combination of the existing proposals not see more = proposals put on the table at this point. From discuss-bounces@apps.ietf.org Mon Sep 10 11:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlU6-00076C-Ed; Mon, 10 Sep 2007 11:47:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUW6q-0004wY-Ej for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Sep 2007 19:22:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUW6q-0004wQ-5I for discuss@apps.ietf.org; Sun, 09 Sep 2007 19:22:32 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUW6m-0000xO-9j for discuss@apps.ietf.org; Sun, 09 Sep 2007 19:22:32 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l89NIYqS075023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Sep 2007 01:18:34 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) Date: Mon, 10 Sep 2007 01:21:00 +0200 To: Marshall Eubanks X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Mon, 10 Sep 2007 11:47:32 -0400 Cc: ietf@ietf.org, discuss@apps.ietf.org, ietf-http-wg@w3.org, saag@mit.edu, ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 10-sep-2007, at 0:51, Marshall Eubanks wrote: > I tend to rely on Dictionaries to sort these things out - from > Dictionary.com Dictionaries are useless, when in doubt they just add definitions. For instance, try figuring out how many bytes there are in a megabyte from a few dictionaries. From discuss-bounces@apps.ietf.org Mon Sep 10 11:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlU6-00075t-9v; Mon, 10 Sep 2007 11:47:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUUUn-0004uI-Sz for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Sep 2007 17:39:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUUUn-0004uA-JS for discuss@apps.ietf.org; Sun, 09 Sep 2007 17:39:09 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUUUl-0007dZ-OD for discuss@apps.ietf.org; Sun, 09 Sep 2007 17:39:09 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l89LZHTG073622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 9 Sep 2007 23:35:17 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <46E2E54A.2050406@isode.com> References: <46E2E54A.2050406@isode.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) Date: Sun, 9 Sep 2007 23:37:45 +0200 To: Alexey Melnikov X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-Mailman-Approved-At: Mon, 10 Sep 2007 11:47:32 -0400 Cc: ietf-http-auth@osafoundation.org, discuss@apps.ietf.org, saag@mit.edu, ietf@ietf.org, ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 8-sep-2007, at 20:09, Alexey Melnikov wrote: > This message is trying to summarize recent discussions on draft- > hartman-webauth-phishing-05.txt. > Several people voiced their support for the document (on IETF > mailing list and in various other off-list discussions). Ekr > doesn't think that the document should be published in the current > form and he has some good technical points that need to be > addressed. At least one more revision is needed to addressed recent > comments from Ekr and SecDir review. Here's an outsider review. What's an Ekr, btw? I really dislike the use of "fishing" with creative spelling in a document prepared for an international standards organization. The world certainly doesn't need more words that sound the same and differ in meaning only by the way they're written, and I'm not sure how prevalent this terminology is outside the US and/or the English speaking world. Please come up with something more descriptive. During the reading of this document, it occurred to me that HTTP digest authentication (RFC 2617) rather than the widely used practice of having security credentials be typed into an HTTP form would achieve 90% of the requirements all by itself. (More or less the same thing for S/MIME in mail.) The main part that's missing there is protection against a man in the middle. Obviously TLS goes through great pains to avoid men in the middle, but the document has no trouble throwing that out of the window: The attacker can also spoof trust markers such as the security lock, URL bar and other parts of the browser UI. And: Users do not typically understand certificates and cannot make informed decisions about whether the subject name in a certificate corresponds to the entity they are attempting to communicate with. As a consequence of this assumption, users will likely be fooled by strings either in website names or certificates that look visually similar but that are composed of different code points. Although I agree that a system that can work even under these assumptions would be great, I think it's harmful to adopt them in this way, because it sends a number of very bad messages: - it's ok for browser vendors to play fast and loose with security related UI elements such as the lock icon and the URL bar (i.e., have them controlled by the remote server) - it's ok for domain vendors to sell domains that use IDN trickery - it's ok for certificate vendors to sell certificates that seem to be tied to some known entity but are in reality tied to a different entity All of these are unacceptable and we as users of these services, community members, engineers and IETF members should do what we can to make sure that they don't happen. Last but not least, I'm guessing that "ben Laurie" is actually "Ben Laurie". From discuss-bounces@apps.ietf.org Mon Sep 10 11:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlU6-00076V-J3; Mon, 10 Sep 2007 11:47:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUWXG-0003QT-3R for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Sep 2007 19:49:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUWXF-0003QL-QD for discuss@apps.ietf.org; Sun, 09 Sep 2007 19:49:49 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUWXE-0001Pi-HZ for discuss@apps.ietf.org; Sun, 09 Sep 2007 19:49:49 -0400 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id l89NmxZa003908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Sep 2007 16:48:59 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id l89NmdbV003547; Sun, 9 Sep 2007 16:48:39 -0700 (PDT) Date: Sun, 9 Sep 2007 16:48:39 -0700 From: Bill Manning To: Iljitsch van Beijnum Subject: Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) Message-ID: <20070909234839.GA2020@boreas.isi.edu> References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> User-Agent: Mutt/1.4.2.2i X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@boreas.isi.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Mon, 10 Sep 2007 11:47:32 -0400 Cc: ietf@ietf.org, discuss@apps.ietf.org, Marshall Eubanks , ietf-http-wg@w3.org, saag@mit.edu, ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, Sep 10, 2007 at 01:21:00AM +0200, Iljitsch van Beijnum wrote: > On 10-sep-2007, at 0:51, Marshall Eubanks wrote: > > >I tend to rely on Dictionaries to sort these things out - from > >Dictionary.com > > Dictionaries are useless, when in doubt they just add definitions. > For instance, try figuring out how many bytes there are in a megabyte > from a few dictionaries. > `When I use a word,' Humpty Dumpty said, in rather a scornful tone, `it means just what I choose it to mean -- neither more nor less.' --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). From discuss-bounces@apps.ietf.org Mon Sep 10 11:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlU6-00076o-N2; Mon, 10 Sep 2007 11:47:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUYQH-0004Md-J6 for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Sep 2007 21:50:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUYQH-0004Lg-95 for discuss@apps.ietf.org; Sun, 09 Sep 2007 21:50:45 -0400 Received: from robin.verisign.com ([65.205.251.75]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUYQG-0004yT-0D for discuss@apps.ietf.org; Sun, 09 Sep 2007 21:50:45 -0400 Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id l8A1nDiV004852; Sun, 9 Sep 2007 18:49:13 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 9 Sep 2007 18:50:39 -0700 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: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt) Date: Sun, 9 Sep 2007 18:47:58 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37013EDBE0@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt) Thread-Index: AcfzKj6eDFp6Aj4DQNKi/PQmpOaVfQAIVdHQ From: "Hallam-Baker, Phillip" To: "Iljitsch van Beijnum" , "Alexey Melnikov" X-OriginalArrivalTime: 10 Sep 2007 01:50:39.0347 (UTC) FILETIME=[FD24F430:01C7F34C] X-Spam-Score: -4.0 (----) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Mon, 10 Sep 2007 11:47:32 -0400 Cc: ietf-http-auth@osafoundation.org, discuss@apps.ietf.org, ietf-http-wg@w3.org, ietf@ietf.org, saag@mit.edu X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 > During the reading of this document, it occurred to me that=20 > HTTP digest authentication (RFC 2617) rather than the widely=20 > used practice of having security credentials be typed into an=20 > HTTP form would achieve 90% of the requirements all by=20 > itself.=20 Well maybe if people had listened to me then :-) But at this point fifteen years later Digest is not the way to go. First = Digest was designed under the express constraint of avoiding patent = encumberances. RSA and D-H were both off the table at the time. If I was to redo Digest today or expand its scope I would do it = differently. The main reason I would not is that SAML and WS-* both = provide an excellent solution. I very much like and support the = Cardspace idea of building into the O/S platform. I very much like the = OpenID concept of making the barrier to entry very low. I would like to = arrive at a happy combination of the existing proposals not see more = proposals put on the table at this point. From discuss-bounces@apps.ietf.org Mon Sep 10 11:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlU6-00076C-Ed; Mon, 10 Sep 2007 11:47:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUW6q-0004wY-Ej for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Sep 2007 19:22:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUW6q-0004wQ-5I for discuss@apps.ietf.org; Sun, 09 Sep 2007 19:22:32 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUW6m-0000xO-9j for discuss@apps.ietf.org; Sun, 09 Sep 2007 19:22:32 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l89NIYqS075023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Sep 2007 01:18:34 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) Date: Mon, 10 Sep 2007 01:21:00 +0200 To: Marshall Eubanks X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Mon, 10 Sep 2007 11:47:32 -0400 Cc: ietf@ietf.org, discuss@apps.ietf.org, ietf-http-wg@w3.org, saag@mit.edu, ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 10-sep-2007, at 0:51, Marshall Eubanks wrote: > I tend to rely on Dictionaries to sort these things out - from > Dictionary.com Dictionaries are useless, when in doubt they just add definitions. For instance, try figuring out how many bytes there are in a megabyte from a few dictionaries. From discuss-bounces@apps.ietf.org Mon Sep 10 11:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUlU6-00075t-9v; Mon, 10 Sep 2007 11:47:34 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUUUn-0004uI-Sz for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Sep 2007 17:39:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUUUn-0004uA-JS for discuss@apps.ietf.org; Sun, 09 Sep 2007 17:39:09 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUUUl-0007dZ-OD for discuss@apps.ietf.org; Sun, 09 Sep 2007 17:39:09 -0400 Received: from [82.192.90.28] (nirrti.muada.com [82.192.90.28]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l89LZHTG073622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 9 Sep 2007 23:35:17 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <46E2E54A.2050406@isode.com> References: <46E2E54A.2050406@isode.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) Date: Sun, 9 Sep 2007 23:37:45 +0200 To: Alexey Melnikov X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-Mailman-Approved-At: Mon, 10 Sep 2007 11:47:32 -0400 Cc: ietf-http-auth@osafoundation.org, discuss@apps.ietf.org, saag@mit.edu, ietf@ietf.org, ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 8-sep-2007, at 20:09, Alexey Melnikov wrote: > This message is trying to summarize recent discussions on draft- > hartman-webauth-phishing-05.txt. > Several people voiced their support for the document (on IETF > mailing list and in various other off-list discussions). Ekr > doesn't think that the document should be published in the current > form and he has some good technical points that need to be > addressed. At least one more revision is needed to addressed recent > comments from Ekr and SecDir review. Here's an outsider review. What's an Ekr, btw? I really dislike the use of "fishing" with creative spelling in a document prepared for an international standards organization. The world certainly doesn't need more words that sound the same and differ in meaning only by the way they're written, and I'm not sure how prevalent this terminology is outside the US and/or the English speaking world. Please come up with something more descriptive. During the reading of this document, it occurred to me that HTTP digest authentication (RFC 2617) rather than the widely used practice of having security credentials be typed into an HTTP form would achieve 90% of the requirements all by itself. (More or less the same thing for S/MIME in mail.) The main part that's missing there is protection against a man in the middle. Obviously TLS goes through great pains to avoid men in the middle, but the document has no trouble throwing that out of the window: The attacker can also spoof trust markers such as the security lock, URL bar and other parts of the browser UI. And: Users do not typically understand certificates and cannot make informed decisions about whether the subject name in a certificate corresponds to the entity they are attempting to communicate with. As a consequence of this assumption, users will likely be fooled by strings either in website names or certificates that look visually similar but that are composed of different code points. Although I agree that a system that can work even under these assumptions would be great, I think it's harmful to adopt them in this way, because it sends a number of very bad messages: - it's ok for browser vendors to play fast and loose with security related UI elements such as the lock icon and the URL bar (i.e., have them controlled by the remote server) - it's ok for domain vendors to sell domains that use IDN trickery - it's ok for certificate vendors to sell certificates that seem to be tied to some known entity but are in reality tied to a different entity All of these are unacceptable and we as users of these services, community members, engineers and IETF members should do what we can to make sure that they don't happen. Last but not least, I'm guessing that "ben Laurie" is actually "Ben Laurie". From discuss-bounces@apps.ietf.org Mon Sep 10 12:44:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUmLv-0000Ts-2I; Mon, 10 Sep 2007 12:43:11 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUmLt-0000Tm-OL for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 12:43:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUmLt-0000Te-Ep for discuss@apps.ietf.org; Mon, 10 Sep 2007 12:43:09 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUmLs-0002k5-7q for discuss@apps.ietf.org; Mon, 10 Sep 2007 12:43:09 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 2D0F71EE262; Mon, 10 Sep 2007 12:43:07 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSTiUCAQKsjW; Mon, 10 Sep 2007 12:43:04 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 2CB2A1EE251; Mon, 10 Sep 2007 12:42:54 -0400 (EDT) Message-ID: <46E5740E.9090909@cs.utk.edu> Date: Mon, 10 Sep 2007 12:42:54 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: John C Klensin Subject: Re: Issues around sponsoring individual documents References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net> <549EFD98-2A83-4E57-994C-E52A40729152@nokia.com> <0BDD887F6192620BD79F5C4D@[192.168.1.110]> In-Reply-To: <0BDD887F6192620BD79F5C4D@[192.168.1.110]> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Apps Discuss , ext Lisa Dusseault X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> >> you've gotten a lot of good feedback already. My viewpoint >> differs a bit, in that I'm more hesitant about the widespread >> use of the IS path. An IS should be a rare exception, with the >> much more well-defined and -tested WG process the rule. > > Lars, I have to disagree, unless the WG process can be made both a lot > more efficient and a lot lower noise. See my earlier note about this > and please understand that the Apps area may be more subject to the > noise factor than other areas... for several reasons, some good and > some bad. Certainly the WG process needs to be made more efficient, and the noise reduced. I just don't see the IS process as a way to solve this problem. If not used judiciously the IS process will just further lower the quality of IETF's work. >> But in general, I'd encourage you to tell people to publish >> their documents through the appropriate working group, and if >> there isn't one, tell them to prepare a BOF. > > Which, under most circumstances, immediately adds at least four to six > months to the process without, in most cases, getting any incremental > work done. It also tends to open up discussions about what problem > should be solved. That is extremely useful in some cases and a total > waste of time in others, but the length of time it takes seems to be > independent of value. True enough. That discussion does take at least four to six months - independent of how difficult the problem actually is. You want to reserve WGs for the tasks where such discussions are useful and appropriate and will contribute to the quality of the overall effort. And really this four to six months is what it takes for a group of people with diverse backgrounds to begin to understand each other and start speaking in somewhat the same language. For new standards that need input from people with diverse backgrounds, this process is necessary - even though product development people will hate it. For established standards that just need revision, I agree that the process is usually not necessary and just wasteful. One exception would be when an established standard has seen widespread use outside its intended scope, and needs to be revised in light of the scope as newly understood. (Actually my impression is that if a WG is chartered to only develop "requirements" before needing re-chartering, then the WG takes about 12-18 months just to develop requirements. If the WG is chartered to do additional work, there's more incentive to get the requirements part done faster. And IMHO WGs should never be chartered to do "requirements", because this causes too many decisions to be carved in stone before their effects are understood. "design goals" would be much better. But somehow the "requirements" meme has stuck in IETF and won't go away.) Keith From discuss-bounces@apps.ietf.org Mon Sep 10 15:11:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUodS-0002MT-8o; Mon, 10 Sep 2007 15:09:26 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUodQ-0002MO-Js for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 15:09:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUodQ-0002MC-9c for discuss@apps.ietf.org; Mon, 10 Sep 2007 15:09:24 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUodO-0000Ws-TO for discuss@apps.ietf.org; Mon, 10 Sep 2007 15:09:24 -0400 Received: from pc6 (1Cust35.tnt29.lnd3.gbr.da.uu.net [62.188.120.35]) by ranger.systems.pipex.net (Postfix) with SMTP id 9FF6EE000718; Mon, 10 Sep 2007 20:09:14 +0100 (BST) Message-ID: <017301c7f3d4$d6e9a080$0601a8c0@pc6> From: "tom.petch" To: "der Mouse" , , , , , References: <46E2E54A.2050406@isode.com><8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <200709101426.KAA03299@Sparkle.Rodents.Montreal.QC.CA> Subject: Re: [saag] Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt) Date: Mon, 10 Sep 2007 16:45:36 +0200 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-Spam-Score: -102.6 (---------------------------------------------------) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org ----- Original Message ----- From: "der Mouse" To: ; ; ; ; Sent: Monday, September 10, 2007 4:14 PM Subject: Re: [saag] Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt) > > I really dislike the use of "fishing" with creative spelling in a > > document prepared for an international standards organization. > > Perhaps unfortunately, that is *the* word for the behaviour in > question, at least in English. It was not invented for the draft, and > "com[ing] up with something [else]" would be *less* descriptive and > would render the document cryptic to the people who's been working > against phishing for years. Perhaps it's a bad word to use in other > languages, but that should be addressed by the translator(s) in > question, not by mangling the original. > Stick the word in quotes which conveys the message that we know that this is not a good piece of terminology, but that we are pragmatic enough to recognise that using it will convey the right meaning to most people. But on the other strand under this Subject:, I am with those who think that the IETF has demonstrated an absence of consensus and that the proposed way forward to try and achieve it by other means in plain wrong. Tom Petch From discuss-bounces@apps.ietf.org Mon Sep 10 15:35:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUp1P-0000bH-0K; Mon, 10 Sep 2007 15:34:11 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUp1N-0000Xu-40 for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 15:34:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUp1M-0000Xm-Qm for discuss@apps.ietf.org; Mon, 10 Sep 2007 15:34:08 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUp1L-0001Xh-HS for discuss@apps.ietf.org; Mon, 10 Sep 2007 15:34:08 -0400 Received: from pc6 (1Cust35.tnt29.lnd3.gbr.da.uu.net [62.188.120.35]) by ranger.systems.pipex.net (Postfix) with SMTP id 64381E000453; Mon, 10 Sep 2007 20:09:22 +0100 (BST) Message-ID: <017401c7f3d4$d7a24220$0601a8c0@pc6> From: "tom.petch" To: "Lisa Dusseault" , "Apps Discuss" References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net><46E16EF7.5060907@gmail.com><4B7EAB5B-B6A5-44FE-AE66-4B302B70C4B1@commerce.net> <2FD3A323-C59E-4C50-87B9-145C3C2BBAC8@osafoundation.org> Subject: Re: Issues around sponsoring individual documents Date: Mon, 10 Sep 2007 20:02:10 +0200 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-Spam-Score: -104.0 (---------------------------------------------------) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org I said before on this Apps list that I saw some IS as potentially damaging: the sort of thing I had in mind is the I-D draft-hartman-webauth-phishing-05.txt, currently being discussed on the IETF main list. This has failed to achieve consensus and the document shepherd now proposes to seek consensus on a non-IETF list. OK, the list is public and publicised, but this topic is a really big one for Internet users and if the IETF cannot muster a Working Group to hammer the ideas into shape, then we should not be working on it - IMHO. And, by implication, no AD should be sponsoring it. This is about the tenth such discussion on the main IETF list that has grabbed my attention in 2007 - details vary, but all seem to say to me that 'this I-D should not have got this far in this state' - and almost all are IS. Ironically, one such I-D is draft-housley-tls-authz-extns which Sam Hartman sponsored and then didn't and then ... well, read the archives of the main list. Tom Petch ----- Original Message ----- From: "Lisa Dusseault" To: "Apps Discuss" Sent: Friday, September 07, 2007 10:20 PM Subject: Re: Issues around sponsoring individual documents > Didn't mean to name names publicly! But as long as I am, I might as > well characterize the ISs. > > Some are being run practically as if they are WG documents, with > commentary on active WG or post-WG lists. James' and John's are in > that category, as well as the IMAP i18n/collation docs. > One is likely to become the standard extensibility discovery > mechanism for a WG standard -- James'. > Some are revising very widely used standards. John's and Dave's are > in that category. > Nearly half are URI scheme registrations, which must be IETF > Consensus documents in order for the IANA registration to be > allowed. Others register a single mail header, VCard property > (Cullen's) or MIME type. > A few are effectively from outside organizations including Odette, > ISO, GSM, 3GPP and XMPP. > One is attempting to describe requirements for future work, rather > than define an implementable standard -- Sam's. > > Three ID authors requesting sponsoring have been fellow ADs (Sam, > Cullen, Chris). > Nine primary authors were people I've never met. > Eight primary authors were people I have met at IETF meetings or > elsewhere. > > IMO, most are good causes. Most are good quality. YMMV. > > Lisa > > On Sep 7, 2007, at 1:00 PM, Lisa Dusseault wrote: > > > > > On Sep 7, 2007, at 8:32 AM, James M Snell wrote: > > > >> Having written several IS drafts, one of which reached Proposed > >> Standard > >> status and another Experimental RFC, and another that I believe might > >> have helped to motivate this particular note from you,... > > > > > > Yes, but this wasn't the only one! Efforts by Dave Crocker and > > John Klensin are also prompting this line of questioning. But > > Paul's request added to yours to publish the Atom feature > > advertisement spec did prompt finishing the email to send it. > > > > I asked Paul if he'd be document shepherd for that spec, by the > > way, to do the work of determining what consensus was for which > > features to include, to write the doc shepherd's overview & help > > the process along. I'm not sure he thought that was inappropriate > > or just not something he had the time to do, but he declined. > > > > thanks, > > Lisa > > From discuss-bounces@apps.ietf.org Mon Sep 10 15:56:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpLZ-0000qY-SR; Mon, 10 Sep 2007 15:55:01 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUpLZ-0000qT-Cu for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 15:55:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUpLZ-0000qJ-3K for discuss@apps.ietf.org; Mon, 10 Sep 2007 15:55:01 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUpLX-00020o-Tf for discuss@apps.ietf.org; Mon, 10 Sep 2007 15:55:01 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 43BD01EE225; Mon, 10 Sep 2007 15:54:59 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaGcCu0M1Qhm; Mon, 10 Sep 2007 15:54:57 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 1933E1EE21A; Mon, 10 Sep 2007 15:54:53 -0400 (EDT) Message-ID: <46E5A10C.1040109@cs.utk.edu> Date: Mon, 10 Sep 2007 15:54:52 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "tom.petch" Subject: Re: Issues around sponsoring individual documents References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net><46E16EF7.5060907@gmail.com><4B7EAB5B-B6A5-44FE-AE66-4B302B70C4B1@commerce.net> <2FD3A323-C59E-4C50-87B9-145C3C2BBAC8@osafoundation.org> <017401c7f3d4$d7a24220$0601a8c0@pc6> In-Reply-To: <017401c7f3d4$d7a24220$0601a8c0@pc6> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org tom.petch wrote: > I said before on this Apps list that I saw some IS as potentially damaging: the > sort of thing I had in mind is the I-D draft-hartman-webauth-phishing-05.txt, > currently being discussed on the IETF main list. This has failed to achieve > consensus and the document shepherd now proposes to seek consensus on a non-IETF > list. OK, the list is public and publicised, but this topic is a really big one > for Internet users and if the IETF cannot muster a Working Group to hammer the > ideas into shape, then we should not be working on it - IMHO. And, by > implication, no AD should be sponsoring it. > I don't entirely agree with that. If the list is well-known, accepts input from anyone, and tries to reach consensus (rather than, say, trying to promote some organization's agenda), I don't see why the results of a discussion on said list shouldn't be given a fair amount of weight by an IETF AD when trying to estimate soundness and community support. Unfortunately I've seen a fair number of intentionally-biased lists outside of IETF (and a few inside of IETF). That said, list consensus (whether an IETF list or not) is not the same thing as IETF consensus. Even a chartered IETF working group should not assume that group consensus is a sufficient condition for adoption. Keith From discuss-bounces@apps.ietf.org Mon Sep 10 16:58:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUqJM-00082X-0I; Mon, 10 Sep 2007 16:56:48 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUqJK-00082M-WC for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 16:56:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUqJK-00081m-Jr for discuss@apps.ietf.org; Mon, 10 Sep 2007 16:56:46 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUqJJ-0004Q1-6n for discuss@apps.ietf.org; Mon, 10 Sep 2007 16:56:46 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id A53D914220F; Mon, 10 Sep 2007 13:56:44 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwe7FiowLv0e; Mon, 10 Sep 2007 13:56:39 -0700 (PDT) Received: from [192.168.1.100] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id B483A14220E; Mon, 10 Sep 2007 13:56:39 -0700 (PDT) In-Reply-To: <46E5A10C.1040109@cs.utk.edu> References: <76D1FAA9-6605-4D54-9DCC-068BC8242420@commerce.net><46E16EF7.5060907@gmail.com><4B7EAB5B-B6A5-44FE-AE66-4B302B70C4B1@commerce.net> <2FD3A323-C59E-4C50-87B9-145C3C2BBAC8@osafoundation.org> <017401c7f3d4$d7a24220$0601a8c0@pc6> <46E5A10C.1040109@cs.utk.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9020B307-2EFE-4199-BA32-BAED8FCBAC92@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Issues around sponsoring individual documents Date: Mon, 10 Sep 2007 13:56:37 -0700 To: Keith Moore X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Sep 10, 2007, at 12:54 PM, Keith Moore wrote: > tom.petch wrote: >> I said before on this Apps list that I saw some IS as potentially >> damaging: the >> sort of thing I had in mind is the I-D draft-hartman-webauth- >> phishing-05.txt, >> currently being discussed on the IETF main list. This has failed >> to achieve >> consensus and the document shepherd now proposes to seek consensus >> on a non-IETF >> list. OK, the list is public and publicised, but this topic is a >> really big one >> for Internet users and if the IETF cannot muster a Working Group >> to hammer the >> ideas into shape, then we should not be working on it - IMHO. >> And, by >> implication, no AD should be sponsoring it. >> > > I don't entirely agree with that. If the list is well-known, accepts > input from anyone, and tries to reach consensus (rather than, say, > trying to promote some organization's agenda), I don't see why the > results of a discussion on said list shouldn't be given a fair > amount of > weight by an IETF AD when trying to estimate soundness and community > support. Unfortunately I've seen a fair number of intentionally- > biased > lists outside of IETF (and a few inside of IETF). > > That said, list consensus (whether an IETF list or not) is not the > same > thing as IETF consensus. Even a chartered IETF working group > should not > assume that group consensus is a sufficient condition for adoption. Thanks, this pretty much states my intention and I believe Alexey's on discussing the hartman phishing draft :) The list is public and archived and listed on the IETF non-WG lists page. The fact that discussion will take place there is known now to the main IETF list. The result will be a bunch of input for Sam to revise his document, *not* an IETF consensus we can bash people over the head with :) Lisa From discuss-bounces@apps.ietf.org Mon Sep 10 19:32:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUsiP-0003AW-8e; Mon, 10 Sep 2007 19:30:49 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUsiN-0003AI-UH for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 19:30:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUsiN-0003AA-KX for discuss@apps.ietf.org; Mon, 10 Sep 2007 19:30:47 -0400 Received: from smtp.microsoft.com ([131.107.115.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUsiM-0008NL-EC for discuss@apps.ietf.org; Mon, 10 Sep 2007 19:30:47 -0400 Received: from tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.177.2; Mon, 10 Sep 2007 16:30:45 -0700 Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.70.14) by tk1-exhub-c102.redmond.corp.microsoft.com (157.56.116.113) with Microsoft SMTP Server id 8.1.177.1; Mon, 10 Sep 2007 16:29:34 -0700 Received: from tk5-exmlt-w600.wingroup.windeploy.ntdev.microsoft.com (157.54.70.135) by TK5-EXMLT-W602.wingroup.windeploy.ntdev.microsoft.com (157.54.70.14) with Microsoft SMTP Server (TLS) id 8.1.122.1; Mon, 10 Sep 2007 16:29:26 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80:0000:0000:0000:0000:5efe:10.255.255.2]) by tk5-exmlt-w600.wingroup.windeploy.ntdev.microsoft.com ([157.54.70.135]) with mapi; Mon, 10 Sep 2007 16:29:26 -0700 From: Paul Leach To: Alexey Melnikov , Eric Rescorla Date: Mon, 10 Sep 2007 16:29:24 -0700 Subject: RE: [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) Thread-Topic: [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) Thread-Index: AcfzD3vfxFQpumfXQdihbeQBR2+gcgA8rMtQ Message-ID: <042C7D611172EE4A98E7B9AF81D1178C7623734415@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: <46E2E54A.2050406@isode.com> <20070908205337.82EC933C39@delta.rtfm.com> <46E43BA9.3080407@isode.com> In-Reply-To: <46E43BA9.3080407@isode.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-Spam-Score: -108.0 (---------------------------------------------------) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: "ietf-http-auth@osafoundation.org" , "discuss@apps.ietf.org" , "saag@mit.edu" , "ietf@ietf.org" , "ietf-http-wg@w3.org" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org I've read the I-D and EKR's responses, and while I don't agree with all of = them I agree with enough of them that I think that the draft could use a fu= rther revision that takes them into consideration. From discuss-bounces@apps.ietf.org Mon Sep 10 23:47:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUwhI-0001pJ-3G; Mon, 10 Sep 2007 23:45:56 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IUqFL-0006qQ-A1 for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Sep 2007 16:52:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IUqFL-0006qF-0G for discuss@apps.ietf.org; Mon, 10 Sep 2007 16:52:39 -0400 Received: from currant.srv.cs.cmu.edu ([128.2.201.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IUqFJ-0004Hf-O9 for discuss@apps.ietf.org; Mon, 10 Sep 2007 16:52:38 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by currant.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id l8AKqZmM006409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2007 16:52:36 -0400 (EDT) Date: Mon, 10 Sep 2007 16:52:35 -0400 From: Jeffrey Hutzelman To: Eric Rescorla , Alexey Melnikov Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) Message-ID: <2FF98D1CD1230EA56262CB32@sirius.fac.cs.cmu.edu> In-Reply-To: <20070908205337.82EC933C39@delta.rtfm.com> References: <46E2E54A.2050406@isode.com> <20070908205337.82EC933C39@delta.rtfm.com> Originator-Info: login-token=Mulberry:01jx+E6vmH+V7bavxrwp20WSaRuxUWU/38lLJPxZ8=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-Mailman-Approved-At: Mon, 10 Sep 2007 23:45:54 -0400 Cc: ietf@ietf.org, saag@mit.edu, discuss@apps.ietf.org, ietf-http-wg@w3.org, ietf-http-auth@osafoundation.org, Jeffrey Hutzelman X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Saturday, September 08, 2007 01:53:36 PM -0700 Eric Rescorla wrote: > Alexey wrote: >> This message is trying to summarize recent discussions on >> draft-hartman-webauth-phishing-05.txt. >> >> Several people voiced their support for the document (on IETF mailing >> list and in various other off-list discussions). Ekr doesn't think that >> the document should be published in the current form and he has some >> good technical points that need to be addressed. At least one more >> revision is needed to addressed recent comments from Ekr and SecDir >> review. >> >> It is quite clear that some people got confused about intended status of >> this document and whether it represents IETF consensus. Sam has >> clarified what was his intention, but another consensus call is needed >> to make sure people agree with Sam. >> >> Subsequent discussions and consensus calls on the document would happen >> on . >> >> Alexey, >> in my capacity of shepherd for draft-hartman-webauth-phishing > > > I object to this procedure. shep> > This document has already had an IETF Last Call, where it failed to > achieve consensus. At this point, it doesn't need additional last > calls to "make sure that people agree with Sam", but rather to go back > to the authors to try to build support in the community. Not liking > the result of the previous Last Call is not a sufficient basis for > issuing another one. > > At some point in the future, it may be appropriate to issue another > consensus call, but since this is not a WG mailing list--indeed, the > IESG has twice declined to charter a WG in this area--nor are you the > chair, it doesn't seem to me that you have standing to do that. When > that time comes, I would expect the IESG to designate an appropriate > time and place. I think you're overreacting, possibly due to a misinterpretation of what Alexey said and/or of the current state of the document. My reading of the IESG evaluation record suggests that there are indeed some issues that the community feels need to be addressed before the document can move forward. Its current state is "IESG Evaluation::Revised ID Needed", which, along with the evaluation record, suggests that the responsible AD has asked the author and shepherd to get these issues resolved and submit a new document. I don't know what will happen once this is done, but unless the IESG feels we already have _rough_ consensus to publish the document _and_ there are no major changes, I would expect to see a new last call on the revised document. Of course, that last call may see renewed objections from the same individuals, or from others; that does not necessarily mean the last call "failed" -- remember, we operate on _rough_ consensus. Now, given that the responsible AD has asked for a new document, it seems to me that Alexey, as the shepherd of an individual submission, has quite a bit of latitude in how to get there and what it will take before he is willing to take the document back to the IESG. Given that this document is a group effort, it's entirely reasonable for Alexey to want to know that people contributing to the work agree with any changes Sam makes, and to issue consensus cals in an appropriate forum to do this. No one is laboring under the impression that such a call would serve to "override" the "failed" IETF LC. Instead, when Alexey in his role as shepherd believes the document is ready to go back to the IESG, he will inform Lisa of that fact, and the IESG will decide what to do next. -- Jeff -- Jeff From discuss-bounces@apps.ietf.org Tue Sep 11 08:48:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV58y-0004C7-1Z; Tue, 11 Sep 2007 08:47:04 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IV3mY-00026C-Gn for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 07:19:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IV3mY-000262-7H for discuss@apps.ietf.org; Tue, 11 Sep 2007 07:19:50 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IV3mW-0007dy-TM for discuss@apps.ietf.org; Tue, 11 Sep 2007 07:19:50 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.2) with ESMTP id md50007212400.msg for ; Tue, 11 Sep 2007 12:22:32 +0100 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 11 Sep 2007 12:19:39 +0100 From: "Debbie Garside" To: , "'Iljitsch van Beijnum'" References: <46E2E54A.2050406@isode.com><8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com><420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com><26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> <20070909234839.GA2020@boreas.isi.edu> Subject: RE: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt) Date: Tue, 11 Sep 2007 12:19:22 +0100 Message-ID: <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20070909234839.GA2020@boreas.isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfzPISBSDu20IiKR2a5/YMXUw05bQBKNACA X-Spam-Processed: mx1.nexbyte.net, Tue, 11 Sep 2007 12:22:32 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=177446d652=debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: discuss@apps.ietf.org X-MDAV-Processed: mx1.nexbyte.net, Tue, 11 Sep 2007 12:22:34 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-Mailman-Approved-At: Tue, 11 Sep 2007 08:47:02 -0400 Cc: ietf@ietf.org, discuss@apps.ietf.org, ietf-http-wg@w3.org, saag@mit.edu, ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Bill wrote: > `When I use a word,' Humpty Dumpty said, in rather a scornful tone, > `it means just what I choose it to mean -- neither more nor less.' There has been a discussion recently on LTRU as to whether a Terms and Definitions section should be introduced within RFCs - much like those within ISO Standards. Best regards Debbie Garside > -----Original Message----- > From: Bill Manning [mailto:bmanning@ISI.EDU] > Sent: 10 September 2007 00:49 > To: Iljitsch van Beijnum > Cc: ietf@ietf.org; discuss@apps.ietf.org; > ietf-http-wg@w3.org; saag@mit.edu; Alexey Melnikov; > ietf-http-auth@osafoundation.org > Subject: Re: Next step on web phishing > draft(draft-hartman-webauth-phishing-05.txt) > > On Mon, Sep 10, 2007 at 01:21:00AM +0200, Iljitsch van Beijnum wrote: > > On 10-sep-2007, at 0:51, Marshall Eubanks wrote: > > > > >I tend to rely on Dictionaries to sort these things out - from > > >Dictionary.com > > > > Dictionaries are useless, when in doubt they just add definitions. > > For instance, try figuring out how many bytes there are in > a megabyte > > from a few dictionaries. > > > > `When I use a word,' Humpty Dumpty said, in rather a scornful tone, > `it means just what I choose it to mean -- neither more nor less.' > > > --bill > > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or > otherwise). > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > > From discuss-bounces@apps.ietf.org Tue Sep 11 15:32:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBRG-0003aS-Ur; Tue, 11 Sep 2007 15:30:22 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVBRF-0003Wo-4C for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 15:30:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBRE-0003UJ-PW for discuss@apps.ietf.org; Tue, 11 Sep 2007 15:30:20 -0400 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVBRC-0004tA-33 for discuss@apps.ietf.org; Tue, 11 Sep 2007 15:30:20 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ML8DYK2FIO00ALEH@mauve.mrochek.com> for discuss@apps.ietf.org; Tue, 11 Sep 2007 12:30:15 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ML8D10E8SW003GRV@mauve.mrochek.com> for discuss@apps.ietf.org; Tue, 11 Sep 2007 12:30:03 -0700 (PDT) Message-id: <01ML8DYIHPJQ003GRV@mauve.mrochek.com> Date: Tue, 11 Sep 2007 12:04:01 -0700 (PDT) From: Ned Freed Subject: RE: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt) In-reply-to: "Your message dated Tue, 11 Sep 2007 12:19:22 +0100" <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110> MIME-version: 1.0 References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> <20070909234839.GA2020@boreas.isi.edu> <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110> To: Debbie Garside DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1189539014; h=Date: From:Subject:MIME-version; b=Av7JmOtySlE3J9Cj6co1PPja1BeWUc1HXfz+gs 30B25RyRjKJdF+kLMhGUCLifVKQanIFTMUn5lO3mQRmM+dsQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ietf@ietf.org, discuss@apps.ietf.org, 'Iljitsch van Beijnum' , ietf-http-wg@w3.org, bmanning@ISI.EDU, saag@mit.edu, ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > > `When I use a word,' Humpty Dumpty said, in rather a scornful tone, > > `it means just what I choose it to mean -- neither more nor less.' > There has been a discussion recently on LTRU as to whether a Terms and > Definitions section should be introduced within RFCs - much like those > within ISO Standards. And my response to this suggestion is the same as it was for the "IANA considerations" or "Internationalization considerations" section suggestions: By all means have a "terms and definitions" section or whatever in the document if there's a need for one, but don't make having one mandatory in all documents. We already have more than enough useless (from a technical content perspective) boilerplate in our documents. We don't need any more, and when such sections are always present but usually say "no such and such are present" they aren't helping. The last time this came up in the context of IANA considerations it was asserted that having such sections act as a useful check to make sure there are no needed definitions or considerations. The problem is people don't work this way. If the section is mandatory they'll add it when the document is first created. Sometimes they'll remember to keep it up to date and sometimes they won't. But when someone reviews the document they'll see that section and assume its presence means whatever has been checked. So the mandatory section approach can actually result in more errors and omissions, not less. It took me only a few minutes the last time we had one of these discussions to find a documentt (in the RFE Editor's queue, as I recall) where this had happened: A "there are no IANA considerations" section had been added early on but when the document acquired IANA considerations it wasn't updated. And nobody who reviewed the document caught it. Ned P.S. I've read a lot of ISO and CCITT specifications and I have found their terms and definitions material to be fairly hit or miss in terms of utility. From discuss-bounces@apps.ietf.org Tue Sep 11 16:13:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVC57-0006dL-Ef; Tue, 11 Sep 2007 16:11:33 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVC53-0006Yd-35 for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 16:11:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVC51-0006Vn-QR for discuss@apps.ietf.org; Tue, 11 Sep 2007 16:11:28 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVC50-0005h6-Jl for discuss@apps.ietf.org; Tue, 11 Sep 2007 16:11:27 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id DA83E1035D0; Tue, 11 Sep 2007 16:11:24 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEkug96Ucdqd; Tue, 11 Sep 2007 16:11:22 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id 858511034D9; Tue, 11 Sep 2007 16:11:06 -0400 (EDT) Message-ID: <46E6F657.4040204@cs.utk.edu> Date: Tue, 11 Sep 2007 16:11:03 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ned Freed Subject: Re: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt) References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> <20070909234839.GA2020@boreas.isi.edu> <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110> <01ML8DYIHPJQ003GRV@mauve.mrochek.com> In-Reply-To: <01ML8DYIHPJQ003GRV@mauve.mrochek.com> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ietf@ietf.org, discuss@apps.ietf.org, 'Iljitsch van Beijnum' , ietf-http-wg@w3.org, bmanning@ISI.EDU, saag@mit.edu, Debbie Garside , ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org >> There has been a discussion recently on LTRU as to whether a Terms and >> Definitions section should be introduced within RFCs - much like those >> within ISO Standards. >> > > And my response to this suggestion is the same as it was for the "IANA > considerations" or "Internationalization considerations" section suggestions: > By all means have a "terms and definitions" section or whatever in the document > if there's a need for one, but don't make having one mandatory in all > documents. > > We already have more than enough useless (from a technical content > perspective) boilerplate in our documents. +1 Actually I don't have so much of a problem with having such sections in drafts at review time, but I hate to see them clutter up published RFCs. There are a lot of times when these sections aren't applicable, and having them in the final document just interferes with readability. I also think that a Terms and Definitions section might encourage document authors to make up new terms when they're not necessary, which would also interfere with readability. (geeks love to create new language.) From discuss-bounces@apps.ietf.org Tue Sep 11 16:57:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCmF-0001xL-Qt; Tue, 11 Sep 2007 16:56:07 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVCmE-0001uh-QG for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 16:56:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCmE-0001tI-CX for discuss@apps.ietf.org; Tue, 11 Sep 2007 16:56:06 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVCmD-00077M-5F for discuss@apps.ietf.org; Tue, 11 Sep 2007 16:56:06 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 4AB991034D6; Tue, 11 Sep 2007 16:56:03 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQivNrcGHr2m; Tue, 11 Sep 2007 16:56:01 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id F0EE8103610; Tue, 11 Sep 2007 16:55:57 -0400 (EDT) Message-ID: <46E700DD.50802@cs.utk.edu> Date: Tue, 11 Sep 2007 16:55:57 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Ned Freed Subject: Re: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt) References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> <20070909234839.GA2020@boreas.isi.edu> <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110> <01ML8DYIHPJQ003GRV@mauve.mrochek.com> <46E6F657.4040204@cs.utk.edu> <01ML8GHD48YO00005F@mauve.mrochek.com> In-Reply-To: <01ML8GHD48YO00005F@mauve.mrochek.com> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ietf@ietf.org, discuss@apps.ietf.org, 'Iljitsch van Beijnum' , ietf-http-wg@w3.org, bmanning@ISI.EDU, saag@mit.edu, Debbie Garside , ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Ned Freed wrote: >>>> There has been a discussion recently on LTRU as to whether a Terms and >>>> Definitions section should be introduced within RFCs - much like those >>>> within ISO Standards. >>>> >>>> >>> And my response to this suggestion is the same as it was for the "IANA >>> considerations" or "Internationalization considerations" section suggestions: >>> By all means have a "terms and definitions" section or whatever in the document >>> if there's a need for one, but don't make having one mandatory in all >>> documents. >>> >>> We already have more than enough useless (from a technical content >>> perspective) boilerplate in our documents. >>> >> +1 >> > > >> Actually I don't have so much of a problem with having such sections in >> drafts at review time, but I hate to see them clutter up published >> RFCs. >> > > My position is the exact opposite. Full and complete review of drafts it of > paramount importance and anything thqt interferes with that is unacceptable. > And as I have pointed out, we have "running code" demonstrating that these > things are at best distracting and at worst actively interfere with proper > review. > > What's appropriate to appear in the final RFC is up to the RFC Editor. That's > what the word "editor" implies. If the RFC Editor deems it appropriate to > remove null sections that's fine, if they feel they should be retained that's > fine too. Someone reading an RFC to learn how to implement something has a > definite goal in mind and isn't going to be (or at least shouldn't be) > distracted by boilerplate in the same way a reviewer looking for issues - a far > more nebulous proposition - can be. > Well, I guess we do disagree here to some extent. For me, every sentence of a document that doesn't contribute to the technical knowledge that needs to be conferred, interferes with readability, and ultimately, interoperability. That applies to the copyright boilerplate, that applies to checkoff sections that are just there to get approval, it applies to information that is needed only by IANA. And I wasn't aware that our processes allowed the RFC Editor to delete, say, a meaningless IANA considerations section. (I've never checked to see whether has happened.) However I don't have a problem with IESG wanting additional supporting information to help it decide whether to approve documents and to decide what additional processing is needed. If the best place to put such information is in the I-D, fine; if the best place to put that information is in a separate form, that's also fine with me. (And I'd far prefer that we not impose unnecessary burdens on authors of early I-Ds - the fewer hoops they have to jump through, the better.) In general, I think that I-Ds and RFCs really serve very different purposes, and trying to make them be (almost) the same causes us to make less readable end product. I'd like to see more use of "NOTEs IN DRAFT" and similar devices to separate supporting material from material that belongs in the final publication. I'm concerned about readability throughout the document cycle, but am especially concerned about readability of our published documents - as many more people read them at this stage and those people have less context to aid them in sorting through the crap. Keith From discuss-bounces@apps.ietf.org Tue Sep 11 16:59:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCnY-0002Ki-VC; Tue, 11 Sep 2007 16:57:28 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVCnX-0002Iq-8F for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 16:57:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCnW-0002IF-T9 for discuss@apps.ietf.org; Tue, 11 Sep 2007 16:57:26 -0400 Received: from 132.nexbyte.net ([62.197.41.132] helo=mx1.nexbyte.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVCnV-00078r-F0 for discuss@apps.ietf.org; Tue, 11 Sep 2007 16:57:26 -0400 Received: from 145.nexbyte.net ([62.197.41.145]) by mx1.nexbyte.net (mx1.nexbyte.net [62.197.41.132]) (MDaemon PRO v9.6.2) with ESMTP id md50007214839.msg for ; Tue, 11 Sep 2007 22:00:07 +0100 Received: from CPQ86763045110 ([83.67.121.192]) by 145.nexbyte.net with MailEnable ESMTP; Tue, 11 Sep 2007 21:57:17 +0100 From: "Debbie Garside" To: , "'Keith Moore'" References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> <20070909234839.GA2020@boreas.isi.edu> <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110> <01ML8DYIHPJQ003GRV@mauve.mrochek.com> <46E6F657.4040204@cs.utk.edu> <01ML8GHD48YO00005F@mauve.mrochek.com> Subject: RE: Next step on web phishingdraft(draft-hartman-webauth-phishing-05.txt) Date: Tue, 11 Sep 2007 21:56:49 +0100 Message-ID: <012801c7f4b6$4b2faf70$0b00a8c0@CPQ86763045110> X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <01ML8GHD48YO00005F@mauve.mrochek.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Acf0tHbuUjgnFndgS1K93T2ZSOfPrwAASNWw X-Spam-Processed: mx1.nexbyte.net, Tue, 11 Sep 2007 22:00:07 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 62.197.41.145 X-Return-Path: prvs=177446d652=debbie@ictmarketing.co.uk X-Envelope-From: debbie@ictmarketing.co.uk X-MDaemon-Deliver-To: discuss@apps.ietf.org X-MDAV-Processed: mx1.nexbyte.net, Tue, 11 Sep 2007 22:00:08 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ietf@ietf.org, discuss@apps.ietf.org, 'Iljitsch van Beijnum' , ietf-http-wg@w3.org, bmanning@ISI.EDU, saag@mit.edu, ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: debbie@ictmarketing.co.uk List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Ned wrote: > Very good point. Having lots of slightly varying definitions > of various terms could be hugely harmful. I agree. Which is why a Terms and Definitions section is darn useful as is an overall Term Bank. However, I will not labour the point as I have long ago found that trying to sell Terminology standardization to industry is practically impossible - unless you rename it as Knowledge Management. Suffice to say, if I you were to write "Humpty Dumpty" and envisage a boiled egg and I, in interpreting your request, presented you with scrambled egg... You may be somewhat disappointed at breakfast! ;-) Best regards Debbie Garside > -----Original Message----- > From: Ned Freed [mailto:ned.freed@mrochek.com] > Sent: 11 September 2007 21:27 > To: Keith Moore > Cc: Ned Freed; Debbie Garside; ietf@ietf.org; > discuss@apps.ietf.org; 'Iljitsch van Beijnum'; > ietf-http-wg@w3.org; bmanning@ISI.EDU; saag@mit.edu; > ietf-http-auth@osafoundation.org > Subject: Re: Next step on web > phishingdraft(draft-hartman-webauth-phishing-05.txt) > > > > >> There has been a discussion recently on LTRU as to > whether a Terms > > >> and Definitions section should be introduced within RFCs - much > > >> like those within ISO Standards. > > >> > > > > > > And my response to this suggestion is the same as it was for the > > > "IANA considerations" or "Internationalization > considerations" section suggestions: > > > By all means have a "terms and definitions" section or > whatever in > > > the document if there's a need for one, but don't make having one > > > mandatory in all documents. > > > > > > We already have more than enough useless (from a technical content > > > perspective) boilerplate in our documents. > > +1 > > > Actually I don't have so much of a problem with having such > sections > > in drafts at review time, but I hate to see them clutter up > published > > RFCs. > > My position is the exact opposite. Full and complete review > of drafts it of paramount importance and anything thqt > interferes with that is unacceptable. > And as I have pointed out, we have "running code" > demonstrating that these things are at best distracting and > at worst actively interfere with proper review. > > What's appropriate to appear in the final RFC is up to the > RFC Editor. That's what the word "editor" implies. If the RFC > Editor deems it appropriate to remove null sections that's > fine, if they feel they should be retained that's fine too. > Someone reading an RFC to learn how to implement something > has a definite goal in mind and isn't going to be (or at > least shouldn't be) distracted by boilerplate in the same way > a reviewer looking for issues - a far more nebulous > proposition - can be. > > > There are a lot of times when these sections aren't applicable, and > > having them in the final document just interferes with readability. > > It depends on what sort of reading you're doing. > > > I also think that a Terms and Definitions section might encourage > > document authors to make up new terms when they're not necessary, > > which would also interfere with readability. (geeks love to create > > new language.) > > Very good point. Having lots of slightly varying definitions > of various terms could be hugely harmful. > > RFC 2119 is a case in point. While I have some small issues > with how RFC 2119 defines its terms, I've come to realize > that having consistent meanings for these terms is far more important. > > Ned > > > From discuss-bounces@apps.ietf.org Tue Sep 11 17:07:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCvN-0000qd-0m; Tue, 11 Sep 2007 17:05:33 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVCvK-0000g4-5u for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 17:05:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCvD-0000Vx-A3 for discuss@apps.ietf.org; Tue, 11 Sep 2007 17:05:23 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVCvC-0007JD-59 for discuss@apps.ietf.org; Tue, 11 Sep 2007 17:05:23 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 31708103648; Tue, 11 Sep 2007 17:05:20 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkyNCOm84XO5; Tue, 11 Sep 2007 17:05:18 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id E27C6103118; Tue, 11 Sep 2007 17:05:12 -0400 (EDT) Message-ID: <46E70307.3090909@cs.utk.edu> Date: Tue, 11 Sep 2007 17:05:11 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: debbie@ictmarketing.co.uk Subject: Re: Next step on web phishingdraft(draft-hartman-webauth-phishing-05.txt) References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> <20070909234839.GA2020@boreas.isi.edu> <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110> <01ML8DYIHPJQ003GRV@mauve.mrochek.com> <46E6F657.4040204@cs.utk.edu> <01ML8GHD48YO00005F@mauve.mrochek.com> <012801c7f4b6$4b2faf70$0b00a8c0@CPQ86763045110> In-Reply-To: <012801c7f4b6$4b2faf70$0b00a8c0@CPQ86763045110> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ned.freed@mrochek.com, ietf@ietf.org, discuss@apps.ietf.org, 'Iljitsch van Beijnum' , ietf-http-wg@w3.org, bmanning@ISI.EDU, saag@mit.edu, ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Oh, it's very useful to have consistent terminology. And if a document needs to use new terms, they should definitely be defined before use. I just don't want to encourage people to make up new terms (or more likely, whole new paradigms with their own lexicons) when existing ones will do. I'm reminded of recent work in NEA, but they're not the only ones. > I agree. Which is why a Terms and Definitions section is darn useful as is > an overall Term Bank. However, I will not labour the point as I have long > ago found that trying to sell Terminology standardization to industry is > practically impossible - unless you rename it as Knowledge Management. > From discuss-bounces@apps.ietf.org Wed Sep 12 12:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVVQO-0002fl-Vf; Wed, 12 Sep 2007 12:50:48 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVBa0-0004u4-B9 for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 15:39:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBa0-0004th-0Y for discuss@apps.ietf.org; Tue, 11 Sep 2007 15:39:24 -0400 Received: from talkeetna.isc-net.upenn.edu ([128.91.197.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVBZy-00055b-Rg for discuss@apps.ietf.org; Tue, 11 Sep 2007 15:39:23 -0400 Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 981A01CDC; Tue, 11 Sep 2007 15:39:22 -0400 (EDT) Date: Tue, 11 Sep 2007 15:39:22 -0400 From: Shumon Huque To: Paul Leach Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) Message-ID: <20070911193922.GA13450@isc.upenn.edu> References: <46E2E54A.2050406@isode.com> <20070908205337.82EC933C39@delta.rtfm.com> <46E43BA9.3080407@isode.com> <042C7D611172EE4A98E7B9AF81D1178C7623734415@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <042C7D611172EE4A98E7B9AF81D1178C7623734415@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-Mailman-Approved-At: Wed, 12 Sep 2007 12:50:47 -0400 Cc: "ietf-http-auth@osafoundation.org" , "discuss@apps.ietf.org" , "ietf-http-wg@w3.org" , "ietf@ietf.org" , "saag@mit.edu" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, Sep 10, 2007 at 04:29:24PM -0700, Paul Leach wrote: > I've read the I-D and EKR's responses, and while I don't agree with all of them I agree with enough of them that I think that the draft could use a further revision that takes them into consideration. > Would someone send a pointer to Eric Rescorla's critique of the draft? I couldn't find it, although I found comments by various other folks on the IETF draft tracker. --Shumon. From discuss-bounces@apps.ietf.org Wed Sep 12 12:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVVQP-0002g2-3O; Wed, 12 Sep 2007 12:50:49 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVCYh-0004nd-CC for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 16:42:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCYh-0004nU-1U for discuss@apps.ietf.org; Tue, 11 Sep 2007 16:42:07 -0400 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVCYf-0006qI-Nx for discuss@apps.ietf.org; Tue, 11 Sep 2007 16:42:07 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ML8GHFYYXC00AKLQ@mauve.mrochek.com> for discuss@apps.ietf.org; Tue, 11 Sep 2007 13:42:02 -0700 (PDT) Received: from mauve.mrFrom discuss-bounces@apps.ietf.org Wed Sep 12 12:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVVQO-0002fl-Vf; Wed, 12 Sep 2007 12:50:48 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVBa0-0004u4-B9 for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 15:39:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBa0-0004th-0Y for discuss@apps.ietf.org; Tue, 11 Sep 2007 15:39:24 -0400 Received: from talkeetna.isc-net.upenn.edu ([128.91.197.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVBZy-00055b-Rg for discuss@apps.ietf.org; Tue, 11 Sep 2007 15:39:23 -0400 Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 981A01CDC; Tue, 11 Sep 2007 15:39:22 -0400 (EDT) Date: Tue, 11 Sep 2007 15:39:22 -0400 From: Shumon Huque To: Paul Leach Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) Message-ID: <20070911193922.GA13450@isc.upenn.edu> References: <46E2E54A.2050406@isode.com> <20070908205337.82EC933C39@delta.rtfm.com> <46E43BA9.3080407@isode.com> <042C7D611172EE4A98E7B9AF81D1178C7623734415@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <042C7D611172EE4A98E7B9AF81D1178C7623734415@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-Mailman-Approved-At: Wed, 12 Sep 2007 12:50:47 -0400 Cc: "ietf-http-auth@osafoundation.org" , "discuss@apps.ietf.org" , "ietf-http-wg@w3.org" , "ietf@ietf.org" , "saag@mit.edu" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, Sep 10, 2007 at 04:29:24PM -0700, Paul Leach wrote: > I've read the I-D and EKR's responses, and while I don't agree with all of them I agree with enough of them that I think that the draft could use a further revision that takes them into consideration. > Would someone send a pointer to Eric Rescorla's critique of the draft? I couldn't find it, although I found comments by various other folks on the IETF draft tracker. --Shumon. From discuss-bounces@apps.ietf.org Wed Sep 12 12:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVVQP-0002g2-3O; Wed, 12 Sep 2007 12:50:49 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVCYh-0004nd-CC for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 16:42:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCYh-0004nU-1U for discuss@apps.ietf.org; Tue, 11 Sep 2007 16:42:07 -0400 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVCYf-0006qI-Nx for discuss@apps.ietf.org; Tue, 11 Sep 2007 16:42:07 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ML8GHFYYXC00AKLQ@mauve.mrochek.com> for discuss@apps.ietf.org; Tue, 11 Sep 2007 13:42:02 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ML884VNBDC00005F@mauve.mrochek.com> for discuss@apps.ietf.org; Tue, 11 Sep 2007 13:41:44 -0700 (PDT) Message-id: <01ML8GHD48YO00005F@mauve.mrochek.com> Date: Tue, 11 Sep 2007 13:27:15 -0700 (PDT) From: Ned Freed Subject: Re: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt) In-reply-to: "Your message dated Tue, 11 Sep 2007 16:11:03 -0400" <46E6F657.4040204@cs.utk.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1 References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> <20070909234839.GA2020@boreas.isi.edu> <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110> <01ML8DYIHPJQ003GRV@mauve.mrochek.com> <46E6F657.4040204@cs.utk.edu> To: Keith Moore DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1189543321; h=Date: From:Subject:MIME-version:Content-type; b=rQdb1JbJoDkKuo1+Kywicu3tD ggDU8I4Utr2F10cl7HP2xxvT1Ou3TmzHd/BWL0eDqRso3zJBlohjm9GYNFy4Q== X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-Mailman-Approved-At: Wed, 12 Sep 2007 12:50:47 -0400 Cc: Ned Freed , ietf@ietf.org, discuss@apps.ietf.org, 'Iljitsch van Beijnum' , ietf-http-wg@w3.org, bmanning@ISI.EDU, saag@mit.edu, Debbie Garside , ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > >> There has been a discussion recently on LTRU as to whether a Terms and > >> Definitions section should be introduced within RFCs - much like those > >> within ISO Standards. > >> > > > > And my response to this suggestion is the same as it was for the "IANA > > considerations" or "Internationalization considerations" section suggestions: > > By all means have a "terms and definitions" section or whatever in the document > > if there's a need for one, but don't make having one mandatory in all > > documents. > > > > We already have more than enough useless (from a technical content > > perspective) boilerplate in our documents. > +1 > Actually I don't have so much of a problem with having such sections in > drafts at review time, but I hate to see them clutter up published > RFCs. My position is the exact opposite. Full and complete review of drafts it of paramount importance and anything thqt interferes with that is unacceptable. And as I have pointed out, we have "running code" demonstrating that these things are at best distracting and at worst actively interfere with proper review. What's appropriate to appear in the final RFC is up to the RFC Editor. That's what the word "editor" implies. If the RFC Editor deems it appropriate to remove null sections that's fine, if they feel they should be retained that's fine too. Someone reading an RFC to learn how to implement something has a definite goal in mind and isn't going to be (or at least shouldn't be) distracted by boilerplate in the same way a reviewer looking for issues - a far more nebulous proposition - can be. > There are a lot of times when these sections aren't applicable, > and having them in the final document just interferes with readability. It depends on what sort of reading you're doing. > I also think that a Terms and Definitions section might encourage > document authors to make up new terms when they're not necessary, which > would also interfere with readability. (geeks love to createFrom discuss-bounces@apps.ietf.org Wed Sep 12 12:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVVQO-0002fl-Vf; Wed, 12 Sep 2007 12:50:48 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVBa0-0004u4-B9 for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 15:39:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVBa0-0004th-0Y for discuss@apps.ietf.org; Tue, 11 Sep 2007 15:39:24 -0400 Received: from talkeetna.isc-net.upenn.edu ([128.91.197.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVBZy-00055b-Rg for discuss@apps.ietf.org; Tue, 11 Sep 2007 15:39:23 -0400 Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 981A01CDC; Tue, 11 Sep 2007 15:39:22 -0400 (EDT) Date: Tue, 11 Sep 2007 15:39:22 -0400 From: Shumon Huque To: Paul Leach Subject: Re: [saag] [Ietf-http-auth] Next step on web phishing draft (draft-hartman-webauth-phishing-05.txt) Message-ID: <20070911193922.GA13450@isc.upenn.edu> References: <46E2E54A.2050406@isode.com> <20070908205337.82EC933C39@delta.rtfm.com> <46E43BA9.3080407@isode.com> <042C7D611172EE4A98E7B9AF81D1178C7623734415@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <042C7D611172EE4A98E7B9AF81D1178C7623734415@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-Mailman-Approved-At: Wed, 12 Sep 2007 12:50:47 -0400 Cc: "ietf-http-auth@osafoundation.org" , "discuss@apps.ietf.org" , "ietf-http-wg@w3.org" , "ietf@ietf.org" , "saag@mit.edu" X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On Mon, Sep 10, 2007 at 04:29:24PM -0700, Paul Leach wrote: > I've read the I-D and EKR's responses, and while I don't agree with all of them I agree with enough of them that I think that the draft could use a further revision that takes them into consideration. > Would someone send a pointer to Eric Rescorla's critique of the draft? I couldn't find it, although I found comments by various other folks on the IETF draft tracker. --Shumon. From discuss-bounces@apps.ietf.org Wed Sep 12 12:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVVQP-0002g2-3O; Wed, 12 Sep 2007 12:50:49 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVCYh-0004nd-CC for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 16:42:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVCYh-0004nU-1U for discuss@apps.ietf.org; Tue, 11 Sep 2007 16:42:07 -0400 Received: from dsl-66-59-230-40.static.linkline.com ([66.59.230.40] helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVCYf-0006qI-Nx for discuss@apps.ietf.org; Tue, 11 Sep 2007 16:42:07 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ML8GHFYYXC00AKLQ@mauve.mrochek.com> for discuss@apps.ietf.org; Tue, 11 Sep 2007 13:42:02 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ML884VNBDC00005F@mauve.mrochek.com> for discuss@apps.ietf.org; Tue, 11 Sep 2007 13:41:44 -0700 (PDT) Message-id: <01ML8GHD48YO00005F@mauve.mrochek.com> Date: Tue, 11 Sep 2007 13:27:15 -0700 (PDT) From: Ned Freed Subject: Re: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt) In-reply-to: "Your message dated Tue, 11 Sep 2007 16:11:03 -0400" <46E6F657.4040204@cs.utk.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1 References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> <20070909234839.GA2020@boreas.isi.edu> <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110> <01ML8DYIHPJQ003GRV@mauve.mrochek.com> <46E6F657.4040204@cs.utk.edu> To: Keith Moore DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1189543321; h=Date: From:Subject:MIME-version:Content-type; b=rQdb1JbJoDkKuo1+Kywicu3tD ggDU8I4Utr2F10cl7HP2xxvT1Ou3TmzHd/BWL0eDqRso3zJBlohjm9GYNFy4Q== X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-Mailman-Approved-At: Wed, 12 Sep 2007 12:50:47 -0400 Cc: Ned Freed , ietf@ietf.org, discuss@apps.ietf.org, 'Iljitsch van Beijnum' , ietf-http-wg@w3.org, bmanning@ISI.EDU, saag@mit.edu, Debbie Garside , ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > >> There has been a discussion recently on LTRU as to whether a Terms and > >> Definitions section should be introduced within RFCs - much like those > >> within ISO Standards. > >> > > > > And my response to this suggestion is the same as it was for the "IANA > > considerations" or "Internationalization considerations" section suggestions: > > By all means have a "terms and definitions" section or whatever in the document > > if there's a need for one, but don't make having one mandatory in all > > documents. > > > > We already have more than enough useless (from a technical content > > perspective) boilerplate in our documents. > +1 > Actually I don't have so much of a problem with having such sections in > drafts at review time, but I hate to see them clutter up published > RFCs. My position is the exact opposite. Full and complete review of drafts it of paramount importance and anything thqt interferes with that is unacceptable. And as I have pointed out, we have "running code" demonstrating that these things are at best distracting and at worst actively interfere with proper review. What's appropriate to appear in the final RFC is up to the RFC Editor. That's what the word "editor" implies. If the RFC Editor deems it appropriate to remove null sections that's fine, if they feel they should be retained that's fine too. Someone reading an RFC to learn how to implement something has a definite goal in mind and isn't going to be (or at least shouldn't be) distracted by boilerplate in the same way a reviewer looking for issues - a far more nebulous proposition - can be. > There are a lot of times when these sections aren't applicable, > and having them in the final document just interferes with readability. It depends on what sort of reading you're doing. > I also think that a Terms and Definitions section might encourage > document authors to make up new terms when they're not necessary, which > would also interfere with readability. (geeks love to createochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ML884VNBDC00005F@mauve.mrochek.com> for discuss@apps.ietf.org; Tue, 11 Sep 2007 13:41:44 -0700 (PDT) Message-id: <01ML8GHD48YO00005F@mauve.mrochek.com> Date: Tue, 11 Sep 2007 13:27:15 -0700 (PDT) From: Ned Freed Subject: Re: Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt) In-reply-to: "Your message dated Tue, 11 Sep 2007 16:11:03 -0400" <46E6F657.4040204@cs.utk.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1 References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> <20070909234839.GA2020@boreas.isi.edu> <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110> <01ML8DYIHPJQ003GRV@mauve.mrochek.com> <46E6F657.4040204@cs.utk.edu> To: Keith Moore DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1189543321; h=Date: From:Subject:MIME-version:Content-type; b=rQdb1JbJoDkKuo1+Kywicu3tD ggDU8I4Utr2F10cl7HP2xxvT1Ou3TmzHd/BWL0eDqRso3zJBlohjm9GYNFy4Q== X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-Mailman-Approved-At: Wed, 12 Sep 2007 12:50:47 -0400 Cc: Ned Freed , ietf@ietf.org, discuss@apps.ietf.org, 'Iljitsch van Beijnum' , ietf-http-wg@w3.org, bmanning@ISI.EDU, saag@mit.edu, Debbie Garside , ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org > >> There has been a discussion recently on LTRU as to whether a Terms and > >> Definitions section should be introduced within RFCs - much like those > >> within ISO Standards. > >> > > > > And my response to this suggestion is the same as it was for the "IANA > > considerations" or "Internationalization considerations" section suggestions: > > By all means have a "terms and definitions" section or whatever in the document > > if there's a need for one, but don't make having one mandatory in all > > documents. > > > > We already have more than enough useless (from a technical content > > perspective) boilerplate in our documents. > +1 > Actually I don't have so much of a problem with having such sections in > drafts at review time, but I hate to see them clutter up published > RFCs. My position is the exact opposite. Full and complete review of drafts it of paramount importance and anything thqt interferes with that is unacceptable. And as I have pointed out, we have "running code" demonstrating that these things are at best distracting and at worst actively interfere with proper review. What's appropriate to appear in the final RFC is up to the RFC Editor. That's what the word "editor" implies. If the RFC Editor deems it appropriate to remove null sections that's fine, if they feel they should be retained that's fine too. Someone reading an RFC to learn how to implement something has a definite goal in mind and isn't going to be (or at least shouldn't be) distracted by boilerplate in the same way a reviewer looking for issues - a far more nebulous proposition - can be. > There are a lot of times when these sections aren't applicable, > and having them in the final document just interferes with readability. It depends on what sort of reading you're doing. > I also think that a Terms and Definitions section might encourage > document authors to make up new terms when they're not necessary, which > would also interfere with readability. (geeks love to create new language.) Very good point. Having lots of slightly varying definitions of various terms could be hugely harmful. RFC 2119 is a case in point. While I have some small issues with how RFC 2119 defines its terms, I've come to realize that having consistent meanings for these terms is far more important. Ned From discuss-bounces@apps.ietf.org Wed Sep 12 12:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVVQP-0002gF-7k; Wed, 12 Sep 2007 12:50:49 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVD0A-0006aY-K3 for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 17:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVD0A-0006YI-60 for discuss@apps.ietf.org; Tue, 11 Sep 2007 17:10:30 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVD08-0007Nk-Nr for discuss@apps.ietf.org; Tue, 11 Sep 2007 17:10:30 -0400 Received: from centralmail4brm.Central.Sun.COM ([129.147.62.198]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8BLARxT015529 for ; Tue, 11 Sep 2007 21:10:27 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l8BLARmu024462 for ; Tue, 11 Sep 2007 15:10:27 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l8BLANH6029217; Tue, 11 Sep 2007 16:10:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l8BLALVa029216; Tue, 11 Sep 2007 16:10:21 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 11 Sep 2007 16:10:21 -0500 From: Nicolas Williams To: Ned Freed Subject: Required doc sections (Re: [saag] Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)) Message-ID: <20070911211021.GP28329@Sun.COM> References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> <20070909234839.GA2020@boreas.isi.edu> <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110> <01ML8DYIHPJQ003GRV@mauve.mrochek.com> <46E6F657.4040204@cs.utk.edu> <01ML8GHD48YO00005F@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ML8GHD48YO00005F@mauve.mrochek.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Wed, 12 Sep 2007 12:50:47 -0400 Cc: ietf@ietf.org, discuss@apps.ietf.org, 'Iljitsch van Beijnum' , Keith Moore , ietf-http-wg@w3.org, bmanning@isi.edu, saag@mit.edu, Debbie Garside , ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This thread has morphed into something else entirely. Please change the subject and move it to an appropriate list (I've set Reply-To: ietf@ietf.org; please respect it). For the record, things like IANA considerations sections should be required of I-Ds, even if to say that there aren' new language.) Very good point. Having lots of slightly varying definitions of various terms could be hugely harmful. RFC 2119 is a case in point. While I have some small issues with how RFC 2119 defines its terms, I've come to realize that having consistent meanings for these terms is far more important. Ned From discuss-bounces@apps.ietf.org Wed Sep 12 12:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVVQP-0002gF-7k; Wed, 12 Sep 2007 12:50:49 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVD0A-0006aY-K3 for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 17:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVD0A-0006YI-60 for discuss@apps.ietf.org; Tue, 11 Sep 2007 17:10:30 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVD08-0007Nk-Nr for discuss@apps.ietf.org; Tue, 11 Sep 2007 17:10:30 -0400 Received: from centralmail4brm.Central.Sun.COM ([129.147.62.198]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8BLARxT015529 for ; Tue, 11 Sep 2007 21:10:27 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l8BLARmu024462 for ; Tue, 11 Sep 2007 15:10:27 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l8BLANH6029217; Tue, 11 Sep 2007 16:10:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l8BLALVa029216; Tue, 11 Sep 2007 16:10:21 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 11 Sep 2007 16:10:21 -0500 From: Nicolas Williams To: Ned Freed Subject: Required doc sections (Re: [saag] Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)) Message-ID: <20070911211021.GP28329@Sun.COM> References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> <20070909234839.GA2020@boreas.isi.edu> <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110> <01ML8DYIHPJQ003GRV@mauve.mrochek.com> <46E6F657.4040204@cs.utk.edu> <01ML8GHD48YO00005F@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ML8GHD48YO00005F@mauve.mrochek.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Wed, 12 Sep 2007 12:50:47 -0400 Cc: ietf@ietf.org, discuss@apps.ietf.org, 'Iljitsch van Beijnum' , Keith Moore , ietf-http-wg@w3.org, bmanning@isi.edu, saag@mit.edu, Debbie Garside , ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This thread has morphed into something else entirely. Please change the subject and move it to an appropriate list (I've set Reply-To: ietf@ietf.org; please respect it). For the record, things like IANA considerations sections should be required of I-Ds, even if to say that there aren't any. A single such section gathering several such sub-sections should do ("Misc Considerations. This draft has no IANA considerations. This draft has no ..."). And some such sections might be removed by the RFC Editor, or not (e.g., remove IANA considerations sections that say there are no IANA considerations). Nico -- new language.) Very good point. Having lots of slightly varying definitions of various terms could be hugely harmful. RFC 2119 is a case in point. While I have some small issues with how RFC 2119 defines its terms, I've come to realize that having consistent meanings for these terms is far more important. Ned From discuss-bounces@apps.ietf.org Wed Sep 12 12:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVVQP-0002gF-7k; Wed, 12 Sep 2007 12:50:49 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVD0A-0006aY-K3 for discuss-confirm+ok@megatron.ietf.org; Tue, 11 Sep 2007 17:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVD0A-0006YI-60 for discuss@apps.ietf.org; Tue, 11 Sep 2007 17:10:30 -0400 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVD08-0007Nk-Nr for discuss@apps.ietf.org; Tue, 11 Sep 2007 17:10:30 -0400 Received: from centralmail4brm.Central.Sun.COM ([129.147.62.198]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l8BLARxT015529 for ; Tue, 11 Sep 2007 21:10:27 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l8BLARmu024462 for ; Tue, 11 Sep 2007 15:10:27 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l8BLANH6029217; Tue, 11 Sep 2007 16:10:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l8BLALVa029216; Tue, 11 Sep 2007 16:10:21 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 11 Sep 2007 16:10:21 -0500 From: Nicolas Williams To: Ned Freed Subject: Required doc sections (Re: [saag] Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)) Message-ID: <20070911211021.GP28329@Sun.COM> References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> <20070909234839.GA2020@boreas.isi.edu> <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110> <01ML8DYIHPJQ003GRV@mauve.mrochek.com> <46E6F657.4040204@cs.utk.edu> <01ML8GHD48YO00005F@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ML8GHD48YO00005F@mauve.mrochek.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Wed, 12 Sep 2007 12:50:47 -0400 Cc: ietf@ietf.org, discuss@apps.ietf.org, 'Iljitsch van Beijnum' , Keith Moore , ietf-http-wg@w3.org, bmanning@isi.edu, saag@mit.edu, Debbie Garside , ietf-http-auth@osafoundation.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org This thread has morphed into something else entirely. Please change the subject and move it to an appropriate list (I've set Reply-To: ietf@ietf.org; please respect it). For the record, things like IANA considerations sections should be required of I-Ds, even if to say that there aren't any. A single such section gathering several such sub-sections should do ("Misc Considerations. This draft has no IANA considerations. This draft has no ..."). And some such sections might be removed by the RFC Editor, or not (e.g., remove IANA considerations sections that say there are no IANA considerations). Nico -- t any. A single such section gathering several such sub-sections should do ("Misc Considerations. This draft has no IANA considerations. This draft has no ..."). And some such sections might be removed by the RFC Editor, or not (e.g., remove IANA considerations sections that say there are no IANA considerations). Nico -- From discuss-bounces@apps.ietf.org Wed Sep 12 13:37:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVW7j-0004UZ-55; Wed, 12 Sep 2007 13:35:35 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IVW7h-0004UU-RA for discuss-confirm+ok@megatron.ietf.org; Wed, 12 Sep 2007 13:35:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVW7h-0004UM-Gp for discuss@apps.ietf.org; Wed, 12 Sep 2007 13:35:33 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVW7g-00053t-5n for discuss@apps.ietf.org; Wed, 12 Sep 2007 13:35:33 -0400 X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1189618529!18224622!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.53] Received: (qmail 20700 invoked from network); 12 Sep 2007 17:35:30 -0000 Received: from sbcsmtp6.sbc.com (HELO mlph073.enaf.sfdc.sbc.com) (144.160.20.53) by server-11.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 12 Sep 2007 17:35:30 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l8CHZTpL009323 for ; Wed, 12 Sep 2007 13:35:29 -0400 Received: from mlph070.sfdc.sbc.com (mlph070.sfdc.sbc.com [144.155.224.139]) by mlph073.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l8CHZO56009273 for ; Wed, 12 Sep 2007 13:35:24 -0400 Received: from sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlph070.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l8CHZO45002539 for ; Wed, 12 Sep 2007 13:35:24 -0400 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by mlph070.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id l8CHZIRk002410 for ; Wed, 12 Sep 2007 13:35:18 -0400 Received: from [135.25.188.57] (unknown[135.25.188.57](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20070912173517gw10010gnee> (Authid: tony); Wed, 12 Sep 2007 17:35:18 +0000 Message-ID: <46E8230F.7080004@att.com> Date: Wed, 12 Sep 2007 13:34:07 -0400 From: Tony Hansen User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 Subject: Re: mandatory draft sections (was Next step on web phishing draft(draft-hartman-webauth-phishing-05.txt)) References: <46E2E54A.2050406@isode.com> <8B056441-7E57-46D4-9A2C-5BF7DE0297BF@muada.com> <420921CE-C4A9-49A8-9626-2BEAB70D7107@multicasttech.com> <26C12754-DA05-4545-84E8-2ECE136C5A2D@muada.com> <20070909234839.GA2020@boreas.isi.edu> <003101c7f465$9b90c9a0$0b00a8c0@CPQ86763045110> <01ML8DYIHPJQ003GRV@mauve.mrochek.com> <46E6F657.4040204@cs.utk.edu> <01ML8GHD48YO00005F@mauve.mrochek.com> In-Reply-To: <01ML8GHD48YO00005F@mauve.mrochek.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: saag@mit.edu, discuss@apps.ietf.org, ietf-http-auth@osafoundation.org, ietf@ietf.org, ietf-http-wg@w3.org X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org My viewpoint is somewhat in between. The sections need to be there, but only in the final draft(s) that are intended for Last Call. Prior to that, those sections don't need anything more than a "To Be Determined" notation. Prior to the Last Call, those sections usually don't add anything to the technical meat of the draft and aren't necessary. (Unless of course, the draft is dealing with IANA issues throughout.) During Last Calls, there are many people reviewing the drafts from many angles, including the protocol point of view and the IANA point of view and the internationalization point of view and .... Tony Hansen tony@att.com Ned Freed wrote: > >> Actually I don't have so much of a problem with having such sections in >> drafts at review time, but I hate to see them clutter up published >> RFCs. > > My position is the exact opposite. Full and complete review of drafts it of > paramount importance and anything thqt interferes with that is unacceptable. > And as I have pointed out, we have "running code" demonstrating that these > things are at best distracting and at worst actively interfere with proper > review. From discuss-bounces@apps.ietf.org Thu Sep 20 14:12:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYQUa-0004VZ-4Q; Thu, 20 Sep 2007 14:11:12 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IYQUY-0004Uf-Ee for discuss-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 14:11:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYQUY-0004UX-4l for discuss@apps.ietf.org; Thu, 20 Sep 2007 14:11:10 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYQUR-0005VX-VO for discuss@apps.ietf.org; Thu, 20 Sep 2007 14:11:10 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 72982142227; Thu, 20 Sep 2007 11:10:53 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7m7hRLBB7yL; Thu, 20 Sep 2007 11:10:49 -0700 (PDT) Received: from [192.168.1.100] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id E95C7142223; Thu, 20 Sep 2007 11:10:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6FE6A5ED-4E1C-4F61-A957-C7E4E00845A2@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Dates for architecture workshop Date: Thu, 20 Sep 2007 11:10:44 -0700 To: Apps Discuss X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Quick question. Are there any conflicts with the dates Feb 11 and 12 for an apps-related event? I know CalConnect is the week before. Lisa From discuss-bounces@apps.ietf.org Thu Sep 20 18:21:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYUOK-00067l-0Y; Thu, 20 Sep 2007 18:21:00 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IYUOJ-00067g-Pl for discuss-confirm+ok@megatron.ietf.org; Thu, 20 Sep 2007 18:20:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IYUOJ-00066x-7H for discuss@apps.ietf.org; Thu, 20 Sep 2007 18:20:59 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IYUOD-0003sD-1R for discuss@apps.ietf.org; Thu, 20 Sep 2007 18:20:59 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IYUO2-0007dT-9E; Thu, 20 Sep 2007 18:20:42 -0400 Date: Thu, 20 Sep 2007 18:20:41 -0400 From: John C Klensin To: Lisa Dusseault , Apps Discuss Subject: Re: Dates for architecture workshop Message-ID: In-Reply-To: <6FE6A5ED-4E1C-4F61-A957-C7E4E00845A2@osafoundation.org> References: <6FE6A5ED-4E1C-4F61-A957-C7E4E00845A2@osafoundation.org> 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-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Thursday, 20 September, 2007 11:10 -0700 Lisa Dusseault wrote: > Quick question. Are there any conflicts with the dates Feb 11 > and 12 for an apps-related event? I know CalConnect is the > week before. Lisa, According to their calendar at http://www.icann.org/meetings/, ICANN is meeting from the 10th - 15th in the Asia Pacific area. I try to avoid those meetings when possible, but it is often not possible. john From discuss-bounces@apps.ietf.org Sat Sep 22 12:44:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ84L-0001jz-Qx; Sat, 22 Sep 2007 12:43:01 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IZ84K-0001gn-0i for discuss-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 12:43:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ84J-0001eo-Fu for discuss@apps.ietf.org; Sat, 22 Sep 2007 12:42:59 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZ848-0001jx-7M for discuss@apps.ietf.org; Sat, 22 Sep 2007 12:42:54 -0400 Received: from [192.168.0.2] (adsl-67-127-57-71.dsl.pltn13.pacbell.net [67.127.57.71]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8MGgF8Q016848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Sep 2007 09:42:15 -0700 Message-ID: <46F545F1.1010806@bbiw.net> Date: Sat, 22 Sep 2007 09:42:25 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Apps Discuss Subject: Re: Use of LWSP in ABNF -- consensus call X-Priority: 2 (High) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org On 5/14/2007 Lisa Dusseault wrote: > The IESG reviewed > > for publication as Internet Standard and would like to know if there is > consensus to recommend against the use of LWSP in future specifications, > as it has caused problems recently in DKIM and could cause problems in > other places. > > Some discussion on this point already: > - http://www1.ietf.org/mail-archive/web/ietf/current/msg46048.html > - http://www1.ietf.org/mail-archive/web/discuss/current/msg00463.html > - http://mipassoc.org/pipermail/ietf-dkim/2007q1/007295.html > - > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=66440 > (in this tracker comment, Chris Newman recommended to remove LWSP, but > for backward-compatibility it's probably better to keep it and recommend > against use) Folks, The current situation with elevating the ABNF document to full Internet Standard is that Lisa has a Discuss hold on it, on behalf of an IESG view that a warning note should be attached. Acting as an individual contributor, Chris Newman has offered the following change to the document, as a possible means of resolving things: > OLD: > LWSP = *(WSP / CRLF WSP) > ; linear white space (past newline) > NEW: > LWSP = *(WSP / CRLF WSP) > ; Use of this linear-white-space rule permits > ; lines containing only white space that are no > ; longer legal in mail headers and have caused > ; interoperability problems in other contexts. > ; Do not use when defining mail headers and use > ; with caution in other contexts. The nature of the IETF process is such that there are no guarantees for what will resolve a Discuss, but the signs are good that a consensus on this list, for a note of this type, will suffice. The premise is that the discussion on this list, last May, had consensus to retain the LWSP construct and consensus to add a warning. The text that Chris is suggesting seems to accomplish this. In spite of saying "Do not use", the comment is non-normative, in formal IETF specification terms. Yet it does seem to adequately describe the problem and the way to deal with it. So, I'm going to ask for a consensus call on this modification, where the assumption is that the text is acceptable. All that is needed is for folk who *object* to speak up and state their reasons. If there is consensus *against* this change, we'll have to try something else. Absent a consensus *against* the wording change, we will propose it to Lisa and see if that resolves her Discuss. This consensus call closes on Sunday, 30 September. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From discuss-bounces@apps.ietf.org Sat Sep 22 12:53:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ8E9-0004a4-1Z; Sat, 22 Sep 2007 12:53:09 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IZ8E3-0004Yo-Ea for discuss-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 12:53:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZ8E3-0004YX-4X for discuss@apps.ietf.org; Sat, 22 Sep 2007 12:53:03 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZ8Dw-0001w4-Ud for discuss@apps.ietf.org; Sat, 22 Sep 2007 12:53:03 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 3CD7F1EE323; Sat, 22 Sep 2007 12:52:39 -0400 (EDT) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+6AhpSsBNTu; Sat, 22 Sep 2007 12:52:36 -0400 (EDT) Received: from lust.indecency.org (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 617A91EE2FD; Sat, 22 Sep 2007 12:52:03 -0400 (EDT) Message-ID: <46F54822.5090101@cs.utk.edu> Date: Sat, 22 Sep 2007 12:51:46 -0400 From: Keith Moore User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Dave Crocker Subject: Re: Use of LWSP in ABNF -- consensus call References: <46F545F1.1010806@bbiw.net> In-Reply-To: <46F545F1.1010806@bbiw.net> X-Enigmail-Version: 0.95.3 OpenPGP: id=E1473978 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Apps Discuss , Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org the proposed change seems reasonable to me. Keith > On 5/14/2007 Lisa Dusseault wrote: > >> The IESG reviewed >> >> for publication as Internet Standard and would like to know if there >> is consensus to recommend against the use of LWSP in future >> specifications, as it has caused problems recently in DKIM and could >> cause problems in other places. >> >> Some discussion on this point already: >> - http://www1.ietf.org/mail-archive/web/ietf/current/msg46048.html >> - http://www1.ietf.org/mail-archive/web/discuss/current/msg00463.html >> - http://mipassoc.org/pipermail/ietf-dkim/2007q1/007295.html >> - >> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=66440 >> (in this tracker comment, Chris Newman recommended to remove LWSP, >> but for backward-compatibility it's probably better to keep it and >> recommend against use) > > > Folks, > > The current situation with elevating the ABNF document to full > Internet Standard is that Lisa has a Discuss hold on it, on behalf of > an IESG view that a warning note should be attached. > > Acting as an individual contributor, Chris Newman has offered the > following change to the document, as a possible means of resolving > things: > > >> OLD: >> LWSP = *(WSP / CRLF WSP) >> ; linear white space (past newline) >> NEW: >> LWSP = *(WSP / CRLF WSP) >> ; Use of this linear-white-space rule permits >> ; lines containing only white space that are no >> ; longer legal in mail headers and have caused >> ; interoperability problems in other contexts. >> ; Do not use when defining mail headers and use >> ; with caution in other contexts. > > > The nature of the IETF process is such that there are no guarantees > for what will resolve a Discuss, but the signs are good that a > consensus on this list, for a note of this type, will suffice. > > The premise is that the discussion on this list, last May, had > consensus to retain the LWSP construct and consensus to add a > warning. The text that Chris is suggesting seems to accomplish this. > > In spite of saying "Do not use", the comment is non-normative, in > formal IETF specification terms. Yet it does seem to adequately > describe the problem and the way to deal with it. > > > > So, I'm going to ask for a consensus call on this > modification, where the assumption is that the text > is acceptable. > > All that is needed is for folk who *object* to speak up > and state their reasons. > > If there is consensus *against* this change, we'll have to > try something else. > > Absent a consensus *against* the wording change, we will > propose it to Lisa and see if that resolves her Discuss. > > This consensus call closes on Sunday, 30 September. > > > Thanks. > > d/ From discuss-bounces@apps.ietf.org Sat Sep 22 17:51:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZCpL-00042B-IQ; Sat, 22 Sep 2007 17:47:51 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IZCpK-00041D-Ji for discuss-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 17:47:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZCpK-0003yj-2Z for discuss@apps.ietf.org; Sat, 22 Sep 2007 17:47:50 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZCp8-00005u-Rk for discuss@apps.ietf.org; Sat, 22 Sep 2007 17:47:45 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZCoT-00037T-EQ for discuss@apps.ietf.org; Sat, 22 Sep 2007 21:46:57 +0000 Received: from 1cust43.tnt3.hbg2.deu.da.uu.net ([149.225.14.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Sep 2007 21:46:57 +0000 Received: from nobody by 1cust43.tnt3.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Sep 2007 21:46:57 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: discuss@apps.ietf.org From: "Frank Ellermann" Subject: Re: Use of LWSP in ABNF -- consensus call Date: Sat, 22 Sep 2007 23:46:39 +0200 Organization: http://purl.net/xyzzy Lines: 23 Message-ID: References: <46F545F1.1010806@bbiw.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust43.tnt3.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Dave Crocker wrote: >> LWSP =3D *(WSP / CRLF WSP) >> ; Use of this linear-white-space rule permits >> ; lines containing only white space that are no >> ; longer legal in mail headers and have caused >> ; interoperability problems in other contexts. >> ; Do not use when defining mail headers and use >> ; with caution in other contexts. [...] > consensus to retain the LWSP construct and consensus to add a=20 > warning. The text that Chris is suggesting seems to accomplish > this. The text is fine, and slightly stronger than my proposal in April: I'd prefer to put the prose in the security considerations, but that's only a matter of taste, I don't like long comments in ABNF. Frank From discuss-bounces@apps.ietf.org Sat Sep 22 20:52:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZFgR-0001Oy-7X; Sat, 22 Sep 2007 20:50:51 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IZFgP-0001Oc-Sx for discuss-confirm+ok@megatron.ietf.org; Sat, 22 Sep 2007 20:50:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZFgP-0001OR-J2 for discuss@apps.ietf.org; Sat, 22 Sep 2007 20:50:49 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZFgI-0004Bi-AM for discuss@apps.ietf.org; Sat, 22 Sep 2007 20:50:49 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IZFg0-0002Y9-32; Sat, 22 Sep 2007 20:50:24 -0400 Date: Sat, 22 Sep 2007 20:50:23 -0400 From: John C Klensin To: Dave Crocker , Apps Discuss Subject: Re: Use of LWSP in ABNF -- consensus call Message-ID: <9BF7C36E0E2900AA9252E3A5@p3.JCK.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-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org --On Saturday, 22 September, 2007 09:42 -0700 Dave Crocker wrote: > Folks, > > The current situation with elevating the ABNF document to full > Internet Standard is that Lisa has a Discuss hold on it, on > behalf of an IESG view that a warning note should be attached. > > Acting as an individual contributor, Chris Newman has offered > the following change to the document, as a possible means of > resolving things: > > >> OLD: >> LWSP = *(WSP / CRLF WSP) >> ; linear white space (past newline) >> NEW: >> LWSP = *(WSP / CRLF WSP) >> ; Use of this linear-white-space rule >> permits ; lines containing only white >> space that are no ; longer legal in >> mail headers and have caused ; >> interoperability problems in other >> contexts. ; Do not use when defining >> mail headers and use ; with caution in >> other contexts. > > >... > The premise is that the discussion on this list, last May, had > consensus to retain the LWSP construct and consensus to add a > warning. The text that Chris is suggesting seems to > accomplish this. > > In spite of saying "Do not use", the comment is non-normative, > in formal IETF specification terms. Yet it does seem to > adequately describe the problem and the way to deal with it. Since I'm opposed to "silence equals consent" mechanisms in general, I feel obligated to post a note about this. Although other possibilities would do equally well (and I have mixed feelings about the "syntax versus Security Considerations versus both" question), this change appears to me to be consistent with the conclusions reached last spring. I think it is more important to accept some reasonable change, such as this one, get the document published, and move on than to engage in a further lengthy debate about just which solution would be best in some abstract sense. I would _strongly_ suggest one small change, which is that the word "valid" replace "legal" whenever the latter occurs. We don't make laws around here. john From discuss-bounces@apps.ietf.org Sun Sep 23 10:12:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZS9X-0002vY-K0; Sun, 23 Sep 2007 10:09:43 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IZS9W-0002vP-CP for discuss-confirm+ok@megatron.ietf.org; Sun, 23 Sep 2007 10:09:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZS9W-0002vH-0K for discuss@apps.ietf.org; Sun, 23 Sep 2007 10:09:42 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZS9U-00084j-Ku for discuss@apps.ietf.org; Sun, 23 Sep 2007 10:09:41 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 23 Sep 2007 15:09:39 +0100 Message-ID: <46F673C5.9070106@isode.com> Date: Sun, 23 Sep 2007 15:10:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Dave Crocker Subject: Re: Use of LWSP in ABNF -- consensus call References: <46F545F1.1010806@bbiw.net> In-Reply-To: <46F545F1.1010806@bbiw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Apps Discuss , Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Dave Crocker wrote: > On 5/14/2007 Lisa Dusseault wrote: > >> The IESG reviewed >> >> for publication as Internet Standard and would like to know if there >> is consensus to recommend against the use of LWSP in future >> specifications, as it has caused problems recently in DKIM and could >> cause problems in other places. >> >> Some discussion on this point already: >> - http://www1.ietf.org/mail-archive/web/ietf/current/msg46048.html >> - http://www1.ietf.org/mail-archive/web/discuss/current/msg00463.html >> - http://mipassoc.org/pipermail/ietf-dkim/2007q1/007295.html >> - >> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&id=66440 >> (in this tracker comment, Chris Newman recommended to remove LWSP, >> but for backward-compatibility it's probably better to keep it and >> recommend against use) > > Folks, > > The current situation with elevating the ABNF document to full > Internet Standard is that Lisa has a Discuss hold on it, on behalf of > an IESG view that a warning note should be attached. > > Acting as an individual contributor, Chris Newman has offered the > following change to the document, as a possible means of resolving > things: > >> OLD: >> LWSP = *(WSP / CRLF WSP) >> ; linear white space (past newline) >> NEW: >> LWSP = *(WSP / CRLF WSP) >> ; Use of this linear-white-space rule permits >> ; lines containing only white space that are no >> ; longer legal in mail headers and have caused >> ; interoperability problems in other contexts. >> ; Do not use when defining mail headers and use >> ; with caution in other contexts. > I think this change is good enough, so I support it. From discuss-bounces@apps.ietf.org Mon Sep 24 04:56:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZjjH-0000D0-FF; Mon, 24 Sep 2007 04:55:47 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IZjjG-00007W-Au for discuss-confirm+ok@megatron.ietf.org; Mon, 24 Sep 2007 04:55:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZjjF-0008Oa-Tp for discuss@apps.ietf.org; Mon, 24 Sep 2007 04:55:45 -0400 Received: from anchor-internal-1.mail.demon.net ([195.173.56.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZjj6-0000Ea-LJ for discuss@apps.ietf.org; Mon, 24 Sep 2007 04:55:42 -0400 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id l8O8tFtf005127Mon, 24 Sep 2007 08:55:16 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1IZjil-000EK7-00; Mon, 24 Sep 2007 09:55:15 +0100 Date: Mon, 24 Sep 2007 09:55:15 +0100 From: "Clive D.W. Feather" To: John C Klensin Subject: Re: Use of LWSP in ABNF -- consensus call Message-ID: <20070924085515.GG47850@finch-staff-1.thus.net> References: <9BF7C36E0E2900AA9252E3A5@p3.JCK.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9BF7C36E0E2900AA9252E3A5@p3.JCK.COM> User-Agent: Mutt/1.5.3i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Apps Discuss , Dave Crocker , Paul Overell X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org John C Klensin said: > Although other possibilities would do equally well (and I have > mixed feelings about the "syntax versus Security Considerations > versus both" question), this change appears to me to be > consistent with the conclusions reached last spring. I think it > is more important to accept some reasonable change, such as this > one, get the document published, and move on than to engage in a > further lengthy debate about just which solution would be best > in some abstract sense. +1 strongly. > I would _strongly_ suggest one small change, which is that the > word "valid" replace "legal" whenever the latter occurs. We > don't make laws around here. +1 weakly. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From discuss-bounces@apps.ietf.org Thu Sep 27 08:44:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IashF-0001oS-DT; Thu, 27 Sep 2007 08:42:25 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IardE-0002Zu-2C for discuss-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 07:34:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IardD-0002Zm-Kz for discuss@apps.ietf.org; Thu, 27 Sep 2007 07:34:11 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IardB-00033j-9Q for discuss@apps.ietf.org; Thu, 27 Sep 2007 07:34:11 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5686120B72; Thu, 27 Sep 2007 13:33:31 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-90-46fb950b7cdf Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3455720B6C; Thu, 27 Sep 2007 13:33:31 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 13:33:31 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 13:33:30 +0200 Message-ID: <46FB950A.6020401@ericsson.com> Date: Thu, 27 Sep 2007 13:33:30 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Internet Area , ops-area@ietf.org, discuss@apps.ietf.org, routing-discussion@ietf.org, SAAG Subject: Guidelines for protocol designers using UDP X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Sep 2007 11:33:30.0993 (UTC) FILETIME=[3AE46610:01C800FA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Thu, 27 Sep 2007 08:42:24 -0400 Cc: tsvwg X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tsvwg List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Hi, In the TSVWG we have been developing a guidelines document for UDP. It is intended for protocol designers that consider using UDP in their protocol. We do hope that it will help remove some of the misconception that UDP is a simple protocol to use. It might look that way because most of the features necessary for being acceptable to deploy on the general internet needs to be specified by the one using UDP. It is also something that the Transport ADs already started using as help in explaining why and what to fix when we put a DISCUSS on your document that is using UDP. http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-03.txt So TSVWG is still working on this document but we are now considering it quite complete. So we are looking for feedback from you. Are there things that are unclear, missing, wrong, etc. Please provide your feedback to TSVWG (tsvwg@ietf.org). Thanks Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From discuss-bounces@apps.ietf.org Thu Sep 27 12:43:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IawRM-0005RL-Lc; Thu, 27 Sep 2007 12:42:16 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IawRL-0005QO-UV for discuss-confirm+ok@megatron.ietf.org; Thu, 27 Sep 2007 12:42:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IawRL-0005QF-Gi for discuss@apps.ietf.org; Thu, 27 Sep 2007 12:42:15 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IawRG-0003x2-3f for discuss@apps.ietf.org; Thu, 27 Sep 2007 12:42:15 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 9A2E3142207; Thu, 27 Sep 2007 09:41:59 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1swTmfzUoET; Thu, 27 Sep 2007 09:41:53 -0700 (PDT) Received: from [192.168.1.103] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 093E9142206; Thu, 27 Sep 2007 09:41:51 -0700 (PDT) In-Reply-To: References: <6FE6A5ED-4E1C-4F61-A957-C7E4E00845A2@osafoundation.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0EF132BF-F10B-4282-A94B-428E46FB38D2@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: Dates for architecture workshop Date: Thu, 27 Sep 2007 09:41:12 -0700 To: John C Klensin X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org I think that conflict is livable, and since the dates work well for CalConnect people and for me and Chris, I'd like to nail those dates down. Please put Feb 11/12 on your calendar if you're interested in participating. We haven't nailed down all the details yet, but here's the rough idea: - The topic is intended to be Apps area common architecture (some such pieces which already exist include SASL, LDAP, URLs, MIME types). Any topic should relate to more than one application. - We would like this to be a working meeting. We may break people out forcibly into twos or threes to actually write stuff (email, proposals, I-D text, etc) but we'll also have some discussion as a big group. - We would like participation to be open to people who aren't already Apps 'insiders' so we do not plan to issue formal invitations to a closed list of people. However, in order to limit attendance a little, we will ask for on-topic position papers, just a few pages, in advance of the meeting, as a condition of participation. - If you intend to participate, I'd appreciate an email any time to get a rough headcount. - The deadline for position papers is tentatively friday, Dec 14. That gives the IETF week and one week after for people who want to bounce ideas around for position papers. - We'll circulate the position papers in January so that people can read and comment in advance. More homework! - It will be in the Bay area. - We are going to look for a host, but if there are a few expenses not covered, we may ask for a few 100$ attendance fee. If we need to ask this we'll ask in advance of the actual meeting, but once we have a better idea how many people and what meeting space we need to obtain. Thanks, Lisa On Sep 20, 2007, at 3:20 PM, John C Klensin wrote: > > > --On Thursday, 20 September, 2007 11:10 -0700 Lisa Dusseault > wrote: > >> Quick question. Are there any conflicts with the dates Feb 11 >> and 12 for an apps-related event? I know CalConnect is the >> week before. > > Lisa, > > According to their calendar at http://www.icann.org/meetings/, > ICANN is meeting from the 10th - 15th in the Asia Pacific area. > I try to avoid those meetings when possible, but it is often not > possible. > > john > > > From discuss-bounces@apps.ietf.org Fri Sep 28 08:35:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbF24-0007bx-Vz; Fri, 28 Sep 2007 08:33:24 -0400 Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IbF23-0007UB-8a for discuss-confirm+ok@megatron.ietf.org; Fri, 28 Sep 2007 08:33:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbF22-0007TB-Uz for discuss@apps.ietf.org; Fri, 28 Sep 2007 08:33:22 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbF21-0006co-Kw for discuss@apps.ietf.org; Fri, 28 Sep 2007 08:33:22 -0400 Received: from [192.168.1.37] ([72.54.167.34]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8SCWpMx017717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Sep 2007 05:32:55 -0700 Message-ID: <46FC83E2.7030309@dcrocker.net> Date: Thu, 27 Sep 2007 21:32:34 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Lisa Dusseault Subject: Re: Dates for architecture workshop References: <6FE6A5ED-4E1C-4F61-A957-C7E4E00845A2@osafoundation.org> <0EF132BF-F10B-4282-A94B-428E46FB38D2@osafoundation.org> In-Reply-To: <0EF132BF-F10B-4282-A94B-428E46FB38D2@osafoundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Apps Discuss X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: discuss-bounces@apps.ietf.org Lisa Dusseault wrote: > - The topic is intended to be Apps area common architecture (some such > pieces which already exist include SASL, LDAP, URLs, MIME types). Any > topic should relate to more than one application. > - We would like this to be a working meeting. We may break people out > forcibly into twos or threes to actually write stuff (email, proposals, > I-D text, etc) but we'll also have some discussion as a big group. Lisa, I've re-read your note a few times and while I think I understand the concept of "common architecture" I am not understanding what you mean by "position papers". Can you clarify what sorts of architectural problems are motivating the event, what sorts of issues you are looking to have addressed, what sorts of follow-on actions you are seeking, etc.? Thanks. d/ ps. There is a reasonably strong argument that the most successful "common" architectures were not developed with the target of being "common" but rather for solving a specific problem. The broader applicability came from doing a good job of solving the problem in a way that was flexible or clean or somesuch. (Uh oh. Did I just write a position sentence?) -- Dave Crocker Brandenburg InternetWorking bbiw.net