Forgot attachment.

<= p class=3DMsoNormal>From: Joachimpillai, Damascene M
Sent: Friday,= August 01, 2014 7:56 AM
To: forces@ietf.org; 'draft-ietf-forces-= packet-parallelization@tools.ietf.org'
Subject: draft-ietf-forces= -packet-parallelization; Publication Started

Folks,=

Attached is the "easy writeup" for this document.

Regards,

= --_000_689CE984BDBA8B4CAF3EA6E2CDC5CACB013BB0C6E1FHDP1LUMXC7V3_-- --_004_689CE984BDBA8B4CAF3EA6E2CDC5CACB013BB0C6E1FHDP1LUMXC7V3_ Content-Type: text/plain; name="writeup-packet parallelizationtxt.txt" Content-Description: writeup-packet parallelizationtxt.txt Content-Disposition: attachment; filename="writeup-packet parallelizationtxt.txt"; size=1361; creation-date="Wed, 30 Jul 2014 13:09:46 GMT"; modification-date="Wed, 30 Jul 2014 13:09:46 GMT" Content-Transfer-Encoding: base64 MS4gU3VtbWFyeQ0KDQpUaGUgZG9jdW1lbnQgc2hlcGhlcmQgaXMgRGFtYXNjZW5lIEpvYWNoaW1w aWxsYWkgPGRqQHZlcml6b24uY29tPg0KVGhlIHJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IgaXMg QWRyaWFuIEZhcnJlbCA8YWRyaWFuQG9sZGRvZy5jby51az4NCg0KVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgaG93IHBhY2tldCBwYXJhbGxlbGl6YXRpb24sIGEgZmVhdHVyZSBwcmVzZW50IGluIG1h bnkNCm5ldHdvcmtpbmcgZGV2aWNlcywgaXMgc3VwcG9ydGVkIGJ5IHRoZSBGb3JDRVMgbW9kZWwu IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0d28gbmV3IA0KTEZCcyB0aGF0IHByb3ZpZGUgc3VwcG9y dCBmb3IgcGFyYWxsZWxpemF0aW9uIGFuZCBhIG5ldyBjb3JlIExGQiB0byBub3RpZnkgdGhlIA0K RkUncyBjYXBhYmlsaXR5IHRvIHBhcmFsbGVsaXplIHBhY2tldCBwcm9jZXNzaW5nLg0KDQoyLiBS ZXZpZXcgYW5kIENvbnNlbnN1cw0KDQpUaGUgZG9jdW1lbnQgaGFzIGhhZCBhIG51bWJlciBvZiBp dGVyYXRpb25zIGJhc2VkIG9uIGNvbW1lbnRzIGFuZCBkaXNjdXNzaW9ucyBib3RoIGluDQptZWV0 aW5ncyBhbmQgdGhlIG1haWxpbmcgbGlzdC4gVGhlIExGQiBkZWZpbml0aW9ucyBhbmQgZGVzY3Jp cHRpb25zIGhhdmUgYmVlbiByZXZpZXdlZCBhbmQgYXJlIHN0cmFpZ2h0Zm9yd2FyZC4NCkF0IGxl YXN0IG9uZSBpbXBsZW1lbnRhdGlvbiBoYXMgdmFsaWRhdGVkIHNvbWUgb2YgdGhlIGZlYXR1cmVz IGRlc2NyaWJlZCBpbiB0aGUgZG9jdW1lbnQuICANCldlIGJlbGlldmUgdGhlIHdvcmtpbmcgZ3Jv dXAgaXMgc29saWRseSBiZWhpbmQgdGhpcyBkb2N1bWVudC4gDQoNCjMuIEludGVsbGVjdHVhbCBQ cm9wZXJ0eQ0KDQpUaGUgYXV0aG9yIGhhcyBjb25maXJtZWQgY29uZm9ybWFuY2Ugd2l0aCBCQ1Ag NzgvNzkuIA0KVGhlcmUgaXMgb25seSBvbmUga25vd24gSVBSIGRpc2Nsb3N1cmUgb24gdGhlIGRv Y3VtZW50Lg0KDQo0LiBPdGhlciBQb2ludHMNCg0KYS4gRmlndXJlIDEgc2hvd3MgcGFja2V0cyBp biB0aGUgc3BsaXQgd2hpbGUgdGhlIGF1dGhvcnMgZGVmaW5lIHRoZW0gYXMgY2h1bmtzLiBTdWdn ZXN0IHRvIGNoYW5nZSB0aGUgIlAiIHRvICJDMSwgQzIgLi4uIENOIiBpbiB0aGUgZmlndXJlIHRv IGJlIGFjY3VyYXRlLg0KDQpiLiBSdW5uaW5nIGlkbml0cyBzdWdnZXN0cyB0aGF0IHRoZXJlIGlz IGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkM1ODEwIGJ1dCB0aGVyZSBpcyBubyBleHBsaWNp dCByZWZlcmVuY2UgaW4gdGhlIGRvY3VtZW50Lg0KDQpjLiBVc2Ugc3BlbGwgY2hlY2tlciB0b29s LiBUaGVyZSBhcmUgYSBmZXcgc3BlbGwgZXJyb3JzLCBlLmcuIHMvdGFzbHMvdGFza3M= --_004_689CE984BDBA8B4CAF3EA6E2CDC5CACB013BB0C6E1FHDP1LUMXC7V3_-- From nobody Fri Aug 8 04:10:55 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A301A0AF4; Fri, 8 Aug 2014 01:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsS5zNMi8qB8; Fri, 8 Aug 2014 01:14:41 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9461A0AB6; Fri, 8 Aug 2014 01:14:40 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.148.186]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s788DwW9021867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2014 01:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1407485664; x=1407572064; bh=xL/YZBEOf8djot7Xtw/UdDIjkTmjpeLgRo5zJ4mHxAM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=NUNnzfVQLplRVLanKb+XY54eceQOj3SBcqTxvASnxc6u29Q1oRjSjYXWSEHowv47D h/Yd1I86ChakdIwnpdBuHNHl4HQpXWswYTP+0gXRKl7kC2apwxKOvb3zZp91NkvRPC 09yGVKyem3EQ6Y01A8eR8+btgHgiOn5OG/RAw0KA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1407485664; x=1407572064; i=@elandsys.com; bh=xL/YZBEOf8djot7Xtw/UdDIjkTmjpeLgRo5zJ4mHxAM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=rfcoboyI62c4yihEf02spziSTBZ6kKjw6XsEOzkgCy9hfZ/iKTRrbF7fyBikdnTEi uHoZEYd48PjHOwqAbaG3teAaetkFqHXy1bpz7Lbn/P9RxzNG8n+fTlcsZIFGRauyq3 IRQmixY4naGm0aLmI+8glSKhSPHBkWYC7NydOyS4= Message-Id: <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 08 Aug 2014 00:34:36 -0700 To: forces@ietf.org, iesg@ietf.org From: S Moonesamy In-Reply-To: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> References: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/forces/VxmcVbx_cmTO83brczI-X_uEj18 X-Mailman-Approved-At: Fri, 08 Aug 2014 04:10:53 -0700 Cc: Evangelos Haleplidis Subject: Re: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 08:14:43 -0000 Hello, [Cc to iesg@ as it may be better not to have this discussion on the mailing list mentioned in the announcement] At 12:59 30-07-2014, The IESG wrote: >The IESG has received a request from the Forwarding and Control Element >Separation WG (forces) to consider the following document: >- 'ForCES Protocol Extensions' > as Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2014-08-13. Exceptionally, comments may be >sent to iesg@ietf.org instead. In either case, please retain the I took a quick look at draft-ietf-forces-protoextension-04. In Section 5: "A a new sub-registry for EXTENDEDRESULT-TLV Result Values needs to be created. The codes 0x00-0xff are mirrored from the RESULT-TLV Result Values sub-registry and must not be allocated. The codes 0x100-0x200 are reserved for private use as described earlier and the codes 0x200-0xffffffff are reserved for future use; these codes will be allocated on First Come First Served basis and require specification as well approval of an expert review." The assignment requirements for the new sub-registry are: (a) First Come First Served (b) Specification Required (c) Expert Review Could the working group explain what the above means? I took a quick look at the mailing list archives ( http://www.ietf.org/mail-archive/web/forces/current/maillist.html ) from December 6, 2012 to August 1, 2014. There was a comment from Joel on 9 June ( http://www.ietf.org/mail-archive/web/forces/current/msg04825.html ). There was a WGLC on June 17 ( http://www.ietf.org/mail-archive/web/forces/current/msg04828.html ). The Last Call was sent out on June 30 ( http://www.ietf.org/mail-archive/web/forces/current/msg04875.html ). According to the Shepherd write-up: "The extensions are straightforward, and there was no difficulty in coming to consensus on all points described. There were suggested extensions for earlier versions of the document that were not included based on discussions in the WG for the sake of simplicity. At least one implementation has validated some of the features described in the document. We believe the working group is solidly behind this document." Given that the Forces mailing list archive does not show any review (excluding the one from the Area Director) or significant comments during that period I fail to understand how the document shepherd determined that the "working group is solidly behind this document". The "coming to consensus" looks like nobody in the working group said anything substantive above the draft. This proposed "Proposed Standard" is supposed to reflect the consensus of the IETF. I don't see how the IESG can make such a determination given the silent Working Group Last Call and Last Call. I found it hard to believe that all the members of the IESG attended the working group sessions to get a sense of whether the working group is solidly behind this document. I glanced at the blue sheets for a working group session ( http://www.ietf.org/proceedings/88/bluesheets/bluesheets-88-forces-01.pdf ) and it showed that there was only one Area Director attending that session. I'll highlight a few points from RFC 2418: "Decisions reached during a face-to-face meeting about topics or issues which have not been discussed on the mailing list, or are significantly different from previously arrived mailing list consensus MUST be reviewed on the mailing list." "The Chair should make sure that discussions on the list are summarized and that the outcome is well documented (to avoid repetition)." "As a general practice, the Working Group Chair and Document Editor positions are filled by different individuals to help ensure that the resulting documents accurately reflect the consensus of the working group and that all processes are followed." "Once that a WG has determined at least rough consensus exists within the WG for the advancement of a document the following ...". My summary is: (a) There hasn't been any noteworthy discussion on the mailing list. (b) The write-up mentions "consensus" whereas the public record only shows silence. (c) There isn't any mention on the mailing list that there was even rough consensus within the working group for the advancement of the document. The most appropriate boilerplate text for this (intended) Proposed Standard would be: "It represents the consensus of the IESG. It has received review by the IESG and a few directorates and has been approved for publication by the Internet Engineering Steering Group (IESG)." Regards, S. Moonesamy From nobody Fri Aug 8 04:44:02 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484941B2A86 for ; Fri, 8 Aug 2014 04:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VR73hp1CuFa for ; Fri, 8 Aug 2014 04:43:59 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9974E1B2A71 for ; Fri, 8 Aug 2014 04:43:57 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id hy4so8060960vcb.41 for ; Fri, 08 Aug 2014 04:43:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LwWVsiYOoG2p7Hj4scja5x1+WeTlT4iBFHKjQgaNTCI=; b=hS7Ek2Ok8q/xCW3Y7DaF+2dXMKBbHPIAyYAWELr1Y+vrnrX8rNihQh/aZG0uGD+Woi Lc5Sk5bCIyF/F0DcPEO3StGiWaMSLSsPEDZZbBMChKxnyQsaXEACr7F5RjzOX0rFZ8QQ kWV2jWgrh4PAFmPj6M0/bHVsWeKtRp+Jsqywjo7mwIjh5rqA475zhtYs0OF0dFkB3RZN f3aD/W6M09KWZwVa7g6TgHsg+Pie80kjqWmJd6k5irOhEDg29M5vnhgzgHJDiMdlt8aP dm4tTbGWIatGvO1q4TjBJFcBigDJcvYZv5g2iu/tXeGYUlFOnAvI2QrxHV9mpOyylvDG xlWQ== X-Gm-Message-State: ALoCoQmwBdrTJMcXsIcx9JTxhfEyuMoiYJrZTTCOnHFbdIkkCqO7n1Tu55MRixF82Na9k0RtjGsu X-Received: by 10.220.97.5 with SMTP id j5mr21618780vcn.16.1407498236515; Fri, 08 Aug 2014 04:43:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.49.228 with HTTP; Fri, 8 Aug 2014 04:43:36 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> References: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> From: Jamal Hadi Salim Date: Fri, 8 Aug 2014 07:43:36 -0400 Message-ID: To: S Moonesamy Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/73pGweLAtzftpbi-3sCWqb2jEog Cc: "forces@ietf.org" , The IESG , Evangelos Haleplidis Subject: Re: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 11:44:01 -0000 Hi SM, On Fri, Aug 8, 2014 at 3:34 AM, S Moonesamy wrote: > I took a quick look at draft-ietf-forces-protoextension-04. In Section 5: > > "A a new sub-registry for EXTENDEDRESULT-TLV Result Values needs to be > created. The codes 0x00-0xff are mirrored from the RESULT-TLV Result > Values sub-registry and must not be allocated. The codes 0x100-0x200 > are reserved for private use as described earlier and the codes > 0x200-0xffffffff are reserved for future use; these codes will be > allocated on First Come First Served basis and require specification > as well approval of an expert review." > > The assignment requirements for the new sub-registry are: > > (a) First Come First Served > > (b) Specification Required > > (c) Expert Review > > Could the working group explain what the above means? > 0x200-0xffffffff are reserved for future use to be allocated on FCFS using expert review. Codes 0x100-0x200 are available free to use by a deployment as long there is agreement between two inter-operating sides on their semantics. Suggestions on how this could be clarified? > "The extensions are straightforward, and there was no difficulty in coming > to consensus on all points described. There were suggested extensions for > earlier versions of the document that were not included based on > discussions > in the WG for the sake of simplicity. At least one implementation has > validated some of the features described in the document. > We believe the working group is solidly behind this document." > > Given that the Forces mailing list archive does not show any review > (excluding the one from the Area Director) or significant comments during > that period I fail to understand how the document shepherd determined that > the "working group is solidly behind this document". The "coming to > consensus" looks like nobody in the working group said anything substantive > above the draft. > It is a small draft with very simple updates. There was some controversy on earlier versions of the draft. Those controversies were removed. There was really nothing to disagree on. > This proposed "Proposed Standard" is supposed to reflect the consensus of > the IETF. I don't see how the IESG can make such a determination given the > silent Working Group Last Call and Last Call. I found it hard to believe > that all the members of the IESG attended the working group sessions to get > a sense of whether the working group is solidly behind this document. I > glanced at the blue sheets for a working group session ( > http://www.ietf.org/proceedings/88/bluesheets/bluesheets-88-forces-01.pdf ) > and it showed that there was only one Area Director attending that session. > On 99% of our meetings only our relevant area director attends. There has been the odd occasion where we had both ADs attend. Why is presence of only one AD an issue? As far as i remember, the AD has *never* missed a single meeting or is unaware of a single decision we reached on this or other documents. Other individual IESG members get to decide during the publication process. > I'll highlight a few points from RFC 2418: > > "Decisions reached during a face-to-face meeting about topics > or issues which have not been discussed on the mailing list, > or are significantly different from previously arrived mailing > list consensus MUST be reviewed on the mailing list." > > "The Chair should make sure that discussions on the list are > summarized and that the outcome is well documented (to avoid > repetition)." > > "As a general practice, the Working Group Chair and Document Editor > positions are filled by different individuals to help ensure that > the resulting documents accurately reflect the consensus of the > working group and that all processes are followed." > > "Once that a WG has determined at least rough consensus exists within > the WG for the advancement of a document the following ...". > > My summary is: > > (a) There hasn't been any noteworthy discussion on the mailing list. > > (b) The write-up mentions "consensus" whereas the public record > only shows silence. > > (c) There isn't any mention on the mailing list that there was > even rough consensus within the working group for the > advancement of the document. > > The most appropriate boilerplate text for this (intended) Proposed Standard > would be: > > "It represents the consensus of the IESG. It has received review > by the IESG and a few directorates and has been approved for > publication by the Internet Engineering Steering Group (IESG)." > Look at the minutes, listen to the audio and review the slides. This is a chartered WG item. Volunteers put time into it and folks implemented. There is no controversy to merit any discussions. The mailing list does not capture all the discussions. Here's a cutnpaste on the last time the draft was discussed at the meetings (IETF 88). ------ Protocol Update (13:31): Slides: http://tools.ietf.org/agenda/88/slides/slides-88-forces-4.pdf http://www.ietf.org/proceedings/88/slides/slides-88-forces-4.pdf Draft: http://tools.ietf.org/html/draft-jhs-forces-protoextenstion-01 Jamal Hadi Salim - There was strong resistance so far against table append. Agreed to remove table append. Jamal plans to write another document in the future to cover table append vs replace vs exclusivity. -Table Range Query looks solid from implementation experience. A single success(to get/delete) is considered an overall success.. -Extended Result TLV Add an 8-bit field for result causes Rick Taylor: 2 Qs What encoding for strings? UTF-8 Prefer integer code rather than natural language string result. -Large Sparse Data Sparse data TLV has 16 bit length. This is too small since ILVs have 32-bit lengths. There is a mismatch. Q: Convert the count from bytes to words for a "new" TLV? Joel Halpern: TLV meaning mixing is a bad idea. So answer is No, since this change of meaning is surprising. Better off: Don't solve this problem, please. Rick Taylor: Can't change length based on type. Rich G?: Length is length is length Weiming Wang: Is this a question of efficiency? Designed the ILV - may need large I. ------- Discussions are useful - but not when they are unnecessary (aka Australian Parliament Bike Shed). cheers, jamal > Regards, > S. Moonesamy > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From nobody Fri Aug 8 12:26:59 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F071A0175 for ; Fri, 8 Aug 2014 12:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DtzJUgpUrd8 for ; Fri, 8 Aug 2014 12:26:53 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3271A00A8 for ; Fri, 8 Aug 2014 12:26:53 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id hq11so8948652vcb.10 for ; Fri, 08 Aug 2014 12:26:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iZXRSLftVfDMjsLRINsvBl63zXI7XJpTsJtHJCYIDgg=; b=fQmPyaDjGr1pAt5qQyPM5ODAhHui2Zr1kI70QteBthIGHfSFQzrzflPomakjS1g9om KTk9yF1zbLw510LRgVwto4wPl/9N9m4R5DQMf7f4lOO+W6PMEHNLcAPXoGSkEzyPx8uL d1vUmfpYrdGy3kD/NliEPv61zksRfDaTXDR90ldlipjni+ZJlM4BRDmJgm2PP21FznHe BYz68QbzZMVeSE/5J1NfF/vgH3NHr5ovSly9MGqIqlV/h8t99SPCKTzM+tb+HFcNvPAP 3U0C8+RHsu4u7fU9fjFHlNRhIdK0Jf5N1KO1EONS7OsrQ+hzDvPwwPvsw35mTFuDOeaF N1pg== X-Gm-Message-State: ALoCoQnIS9+j4qHYTUFyXsM5FYmbNkNDYM85l14GJqqyl/sh9lkf6Rl4SAMWgM165z7Hx5QbA0xR X-Received: by 10.221.56.5 with SMTP id wa5mr23372594vcb.25.1407526012779; Fri, 08 Aug 2014 12:26:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.49.228 with HTTP; Fri, 8 Aug 2014 12:26:32 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20140808085335.0c04e2b0@elandnews.com> References: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> <6.2.5.6.2.20140808085335.0c04e2b0@elandnews.com> From: Jamal Hadi Salim Date: Fri, 8 Aug 2014 15:26:32 -0400 Message-ID: To: S Moonesamy Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/7RPOoEOHfwTP6OkEmxbjgu8-LpQ Cc: "forces@ietf.org" , The IESG , Evangelos Haleplidis Subject: Re: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 19:26:56 -0000 SM, On Fri, Aug 8, 2014 at 1:17 PM, S Moonesamy wrote: > Hi Jamal, > > At 04:43 08-08-2014, Jamal Hadi Salim wrote: >> >> 0x200-0xffffffff are reserved for future use to be allocated on FCFS >> using expert review. >> Codes 0x100-0x200 are available free to use by a deployment as >> long there is agreement between two inter-operating sides on their >> semantics. >> Suggestions on how this could be clarified? > > > My question was about the assignment requirements. :-) I'll explain; let's > say I would like to request a code point from that sub-registry. What do I > have to do to get that code point? Would I, for example, have to contact a > Designated Expert when the sub-registry policy is "First Come First > Served"?. The (IETF) definition for "First Come First Served" is: > > "Assignments are made to anyone on a first come, first served basis. > There is no substantive review of the request, other than to ensure > that it is well-formed and doesn't duplicate an existing assignment." > > What does IANA need to see in the specification to assign that code point to > me? Do I have to bother the Routing Area Director to sponsor a RFC for me > to get that code point? > If two people ask for the same code - then fcfs is used. The expert is consulted always. If that intent in the doc is not clear - help us come with better wording. Feel free to mutilate the paragraph we have;-> > My point was that the IESG members are making a determination of IETF > Consensus. Let's assume that I am objecting to publication on consensus > grounds. I believe it would be within the realm of your rights to object, but please dont work on assumptions. It is better to get insight. >It would be questionable if the other Area Directors say that "we > took the relevant Area Director's word, we did not see any comments on > ietf@ietf.org, we believe that there is IETF Consensus". > I think the general trend is to give the AD the benefit of doubt. If there are loopholes to be closed , i think that is a separate discussion. > > I did put in some time to comment about this draft. :-) Sorry if we missed your earlier comments; there is still room to resolve any thing you brought up in the past that was missed. (Re)send either private mail or email to the list. >As I mentioned in > my previous message, there isn't anything substantive to show that there > were volunteers who reviewed this chartered WG item. > > The message at > http://www.ietf.org/mail-archive/web/forces/current/msg04880.html mentions > that: > > > "There was some controversy on earlier versions of the draft." > > The above quoted paragraph mentions that: > > > "There is no controversy to merit any discussions." > > I cannot tell whether there was controversy or not. When this document was published as a WG document those controversial issues were removed. So this document, as articulated by the shepherd, has no controversy. Does that make sense? I pointed to one meetings minutes but if you go backwards, things will make more sense. Again: This is a simple document to a simple update (as you acknowledge). My comment on bike-shedding was more to make the point that we shouldnt have discussions just because we can. >May I ask who > implemented this specification? > Perhaps the question is motivated because you see some technical flaw in the spec? It would help to point what that is so we can either provide clarification or fix something. [Example, the comments from the security directorate tried to point out to some possible security issues. We provided clarification.] To satisfy your curiosity: I can only vaguely respond that there are implementations that run in real serious deployments that have implemented the majority of the spec - ongoing with implementation to complete the spec. > > Thanks for the above extract of the minutes. > That is a sample space of one meeting (i only looked at the minutes for that meeting because you posted the meeting bluesheets). There were controversies on the original individual draft. That was the tail end of the discussions. *Not everything* happens on lists. That is why we need meetings and a water fountain. There was more than one meeting where discussions happened in regards to the eventual draft. But lets look at the meeting you brought up: I am pretty sure if you listened to the audio of just that one meeting you will get a better feeling of what the minute taker missed. And if you attended that meeting, you will get even better view. And if you participated earlier even more sense. > The IESG could describe my messages about the draft as the Australian > Parliament Bike Shed in response to my point about: > > > "Decisions reached during a face-to-face meeting about topics > or issues which have not been discussed on the mailing list, > or are significantly different from previously arrived mailing > list consensus MUST be reviewed on the mailing list." > > > It would also have to respond to the point about the determination of > consensus by the WG Chair or Document Shepherd. > > I note that there was a comment about another draft from this working group: > > "I notice that the Adrian's AD review commented about the lack of working > group review, while the shepherd writeup comments that the working group > had a solid consensus on this draft. On the surface, those comments seem > to conflict." > > The bottom line is that the IESG would be approving a boilerplate which is > misleading as the average reader would believe that some minima of the > process details have been followed. > Well, I hope there is clarity in my comments. cheers, jamal From nobody Fri Aug 8 12:29:31 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32FCA1A017A; Fri, 8 Aug 2014 10:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.708 X-Spam-Level: X-Spam-Status: No, score=0.708 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, J_CHICKENPOX_72=0.6, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCfMaRCBoMvd; Fri, 8 Aug 2014 10:19:09 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 896B31A0046; Fri, 8 Aug 2014 10:19:09 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.148.186]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s78HINYZ020250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2014 10:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1407518324; x=1407604724; bh=63/xFY0H1ySBu0GCvXD7quKORFgEzbqFP/hbGUHbj7A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hL2wW22FmAkp5duleJhGHdXd/PiMDriHvE/VF+/aqvshps7UG3c8r0kmGjscBlPjZ 2DLSIKyQ8fLxdCdoYcsioBuxWzixSL0UlHV0zonmLO5bDwTuOKuMQD8Mn6solWCTq3 LX4l4RwDQIWEQwZ5HHUTwc0E/v9VKuNg40Vzrk1w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1407518324; x=1407604724; i=@elandsys.com; bh=63/xFY0H1ySBu0GCvXD7quKORFgEzbqFP/hbGUHbj7A=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=CMYKiuFy2rVX5xoCjNMR2XnP8bJUT7Wh8ySO755YsTVNTM4IQEpmSLrTxvxy9VMHp h8XLzwd/ii5KFqG60H08Xo7Z3PMz9wT4iGOZxmRTLxGjfumeCPXYNfAYG+RJT/Rzfv R/B+LKUlyQjCvARk7vopt1NDzsC/l4yiudTsL8I0= Message-Id: <6.2.5.6.2.20140808085335.0c04e2b0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 08 Aug 2014 10:17:01 -0700 To: Jamal Hadi Salim From: S Moonesamy In-Reply-To: References: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/forces/JWzNH2tP6Rw6BE-6fO3k03udlp8 X-Mailman-Approved-At: Fri, 08 Aug 2014 12:29:29 -0700 Cc: forces@ietf.org, iesg@ietf.org, Evangelos Haleplidis Subject: Re: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 17:19:11 -0000 Hi Jamal, At 04:43 08-08-2014, Jamal Hadi Salim wrote: >0x200-0xffffffff are reserved for future use to be allocated on FCFS >using expert review. >Codes 0x100-0x200 are available free to use by a deployment as >long there is agreement between two inter-operating sides on their >semantics. >Suggestions on how this could be clarified? My question was about the assignment requirements. :-) I'll explain; let's say I would like to request a code point from that sub-registry. What do I have to do to get that code point? Would I, for example, have to contact a Designated Expert when the sub-registry policy is "First Come First Served"?. The (IETF) definition for "First Come First Served" is: "Assignments are made to anyone on a first come, first served basis. There is no substantive review of the request, other than to ensure that it is well-formed and doesn't duplicate an existing assignment." What does IANA need to see in the specification to assign that code point to me? Do I have to bother the Routing Area Director to sponsor a RFC for me to get that code point? >It is a small draft with very simple updates. Yes. >There was some controversy on earlier versions of the draft. >Those controversies were removed. There was really nothing to disagree on. [snip] >On 99% of our meetings only our relevant area director >attends. There has been >the odd occasion where we had both ADs attend. >Why is presence of only one AD an issue? As far as i remember, the AD >has *never* >missed a single meeting or is unaware of a single decision we reached on >this or other documents. >Other individual IESG members get to decide during the publication process. My point was that the IESG members are making a determination of IETF Consensus. Let's assume that I am objecting to publication on consensus grounds. It would be questionable if the other Area Directors say that "we took the relevant Area Director's word, we did not see any comments on ietf@ietf.org, we believe that there is IETF Consensus". >Look at the minutes, listen to the audio and review the slides. [snip] >This is a chartered WG item. Volunteers put time into it and folks >implemented. There is no controversy to merit any discussions. >The mailing list does not capture all the discussions. I did put in some time to comment about this draft. :-) As I mentioned in my previous message, there isn't anything substantive to show that there were volunteers who reviewed this chartered WG item. The message at http://www.ietf.org/mail-archive/web/forces/current/msg04880.html mentions that: "There was some controversy on earlier versions of the draft." The above quoted paragraph mentions that: "There is no controversy to merit any discussions." I cannot tell whether there was controversy or not. May I ask who implemented this specification? >Here's a cutnpaste on the last time the draft was discussed >at the meetings (IETF 88). > >------ >Protocol Update (13:31): >Slides: http://tools.ietf.org/agenda/88/slides/slides-88-forces-4.pdf > http://www.ietf.org/proceedings/88/slides/slides-88-forces-4.pdf >Draft: http://tools.ietf.org/html/draft-jhs-forces-protoextenstion-01 >Jamal Hadi Salim > - There was strong resistance so far against table append. > Agreed to remove table append. > Jamal plans to write another document in the future to cover > table append vs replace vs exclusivity. > -Table Range Query looks solid from implementation experience. > A single success(to get/delete) is considered an overall success.. > -Extended Result TLV > Add an 8-bit field for result causes > Rick Taylor: 2 Qs > What encoding for strings? UTF-8 > Prefer integer code rather than natural language > string result. > -Large Sparse Data > Sparse data TLV has 16 bit length. This is too > small since ILVs have 32-bit lengths. There is a mismatch. > Q: Convert the count from bytes to words for a "new" TLV? > Joel Halpern: TLV meaning mixing is a bad idea. > So answer is No, since this change of meaning is surprising. > Better off: Don't solve this problem, please. > Rick Taylor: Can't change length based on type. > Rich G?: Length is length is length > Weiming Wang: Is this a question of efficiency? > Designed the ILV - may need large I. >------- > >Discussions are useful - but not when they are unnecessary >(aka Australian Parliament Bike Shed). Thanks for the above extract of the minutes. The IESG could describe my messages about the draft as the Australian Parliament Bike Shed in response to my point about: "Decisions reached during a face-to-face meeting about topics or issues which have not been discussed on the mailing list, or are significantly different from previously arrived mailing list consensus MUST be reviewed on the mailing list." It would also have to respond to the point about the determination of consensus by the WG Chair or Document Shepherd. I note that there was a comment about another draft from this working group: "I notice that the Adrian's AD review commented about the lack of working group review, while the shepherd writeup comments that the working group had a solid consensus on this draft. On the surface, those comments seem to conflict." The bottom line is that the IESG would be approving a boilerplate which is misleading as the average reader would believe that some minima of the process details have been followed. Regards, S. Moonesamy From nobody Fri Aug 8 12:42:30 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3021A017F; Fri, 8 Aug 2014 12:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZNiTkL9-ixj; Fri, 8 Aug 2014 12:42:28 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A841A0084; Fri, 8 Aug 2014 12:42:27 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id pn19so5015026lab.10 for ; Fri, 08 Aug 2014 12:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Y9fQH3kUQzWPaokoebmO/1JbcCMJB0W7a4KYqxG7APs=; b=p0C07lfXyltaEgafbN2xvF9/FSPI71RP7dN9EQ+BMJJP4SpXDc9/X6xwRKTSsganBR 1yoBgPi0KPNK3HIluJ43WUbRdtvIGFJx4b95ltLwzY48ZD5xC1l2Dy6ZUUWFZSs/hw/j LkufSI6gtjsHmUXurrekfa7gUolwzxmU6FKS6AqDzIUSu6hLoKZMy5r1WcKjwGL/Nn39 kCtF5rNby0rwyxqES5ug5ppcAXJNppkDUie0fhljvL71LzOVk4FGnO5O1HxoBu5qZVGH 2VWEWTOVGHcZz0yumYjDsoX5VZrSn020BYytg7k9dytFgwesLML9lEq2R4h+Z19ckUll 9bxg== MIME-Version: 1.0 X-Received: by 10.112.158.161 with SMTP id wv1mr16069680lbb.8.1407526945885; Fri, 08 Aug 2014 12:42:25 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.8.46 with HTTP; Fri, 8 Aug 2014 12:42:25 -0700 (PDT) In-Reply-To: References: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> <6.2.5.6.2.20140808085335.0c04e2b0@elandnews.com> Date: Fri, 8 Aug 2014 15:42:25 -0400 X-Google-Sender-Auth: wLCM3m2i0_7TfI3Ud26HcLCtAiY Message-ID: From: Barry Leiba To: Jamal Hadi Salim Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/on7L2oaJ80iOsEmtrKfJejk5Tis Cc: "forces@ietf.org" , S Moonesamy , Evangelos Haleplidis , The IESG Subject: Re: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 19:42:29 -0000 >> My question was about the assignment requirements. :-) I'll explain; let's >> say I would like to request a code point from that sub-registry. What do I >> have to do to get that code point? Would I, for example, have to contact a >> Designated Expert when the sub-registry policy is "First Come First >> Served"?. The (IETF) definition for "First Come First Served" is: >> >> "Assignments are made to anyone on a first come, first served basis. >> There is no substantive review of the request, other than to ensure >> that it is well-formed and doesn't duplicate an existing assignment." >> >> What does IANA need to see in the specification to assign that code point to >> me? Do I have to bother the Routing Area Director to sponsor a RFC for me >> to get that code point? > > If two people ask for the same code - then fcfs is used. The expert is > consulted always. > If that intent in the doc is not clear - help us come with better wording. That is not FCFS; that is Expert Review, or perhaps Specification Required. You can (actually, should) then give instructions to the designated expert about what she should consider in her review. Confusing registration policies are one of the biggest problems we have with IANA considerations. Read RFC 5226 -- or, better, read draft-leiba-cotton-iana-5226bis, and look at Section 4 carefully. If you want to require a specification, then use "Specification Required"; a designated expert will be appointed to review the specifications and approve (or not) the registrations. If you want an expert to review registration requests, but you do *not* require a specification, then use "Expert Review". In either case, provide instructions to the expert, saying what factors to consider in the review, and when it is and is not appropriate to deny or push back on a request. If you really do want everyone who asks for a registration to get it, with no review at all, then "First Come First Served" is your guy. But remember that there is only the barest sanity check made for that (IANA will make sure the request has the required information and doesn't appear to be spam), and there is no technical review whatsoever. Please do not mix multiple policy names in the same sentence, thinking that saying more words helps. The terms are already defined in 5226 (and 5226bis); use them. Barry From nobody Fri Aug 8 13:05:31 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71101A0657 for ; Fri, 8 Aug 2014 13:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RPpcq6jQVPs for ; Fri, 8 Aug 2014 13:05:07 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EB1A1A04B7 for ; Fri, 8 Aug 2014 13:04:57 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id hq11so9002534vcb.38 for ; Fri, 08 Aug 2014 13:04:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=G6AMUrrrWpa+IuxlmE/tm2sbMKseaJbvvxa3djWeHJg=; b=dO9lne5bXnKFnwEH9j0f5GKu0bNrQ42cZ25KR620eDNKVKYTPAUCxq3bIevzZHKh5n fHxTuD0T+9OyTE/F1xv8C9hAHEOHngVgeRMU6XYt0QJvBCzYxsdJA/RTytjEbRWWqpin Cm1j3riC2jBF1kaaabhYUh37rGUU+W2Mz+AaIfeHMwtKEEj4jxkXEDSQig2LsSvcuQL3 Z1Kyx7NL31UkI2R0CR9z7KsDk20BYm5mWI6kftDIlPFm9Z4coHeO9WPweuF1I/hmSxBG /+WFnZaUeuPndgMWupNzW7aXFFwYvtiCRzqGqkMWTABGL+sK/mTWCV2+g094Q84cJWVR 9kHA== X-Gm-Message-State: ALoCoQl6xOwcuUaFcopHZiilsR9/5d/9KLSM1A9UPpq3iAd5diAYQOhrKAfozlciA+1Lah1/ZvZk X-Received: by 10.52.135.133 with SMTP id ps5mr8116380vdb.33.1407528296386; Fri, 08 Aug 2014 13:04:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.49.228 with HTTP; Fri, 8 Aug 2014 13:04:36 -0700 (PDT) In-Reply-To: References: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> <6.2.5.6.2.20140808085335.0c04e2b0@elandnews.com>

From: Jamal Hadi Salim Date: Fri, 8 Aug 2014 16:04:36 -0400 Message-ID: To: Barry Leiba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/2kXPSuZA5lqVi5Pprq2-CEPZumo Cc: "forces@ietf.org" , S Moonesamy , Evangelos Haleplidis , The IESG Subject: Re: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 20:05:11 -0000 On Fri, Aug 8, 2014 at 3:42 PM, Barry Leiba wrote: >> If two people ask for the same code - then fcfs is used. The expert is >> consulted always. >> If that intent in the doc is not clear - help us come with better wording. > > That is not FCFS; that is Expert Review, or perhaps Specification > Required. You can (actually, should) then give instructions to the > designated expert about what she should consider in her review. > > Confusing registration policies are one of the biggest problems we > have with IANA considerations. Read RFC 5226 -- or, better, read > draft-leiba-cotton-iana-5226bis, and look at Section 4 carefully. If > you want to require a specification, then use "Specification > Required"; a designated expert will be appointed to review the > specifications and approve (or not) the registrations. If Specification Required implicitly also means expert review is needed then that is what we need. I thought you had to explicitly state each. Thanks for the detail - I will update the doc. cheers, jamal From nobody Fri Aug 8 13:08:22 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C711A03F8; Fri, 8 Aug 2014 13:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DSL=1.129, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T596TL2u4htP; Fri, 8 Aug 2014 13:08:16 -0700 (PDT) Received: from execdsl.com (remote.shinkuro.com [50.56.68.178]) by ietfa.amsl.com (Postfix) with ESMTP id A2BBD1A038C; Fri, 8 Aug 2014 13:08:16 -0700 (PDT) Received: from dummy.name; Fri, 08 Aug 2014 20:08:15 +0000 Message-ID: <53E52E16.7080704@stevecrocker.com> Date: Fri, 08 Aug 2014 16:07:50 -0400 From: Joel User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jamal Hadi Salim , Barry Leiba References: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> <6.2.5.6.2.20140808085335.0c04e2b0@elandnews.com>

In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/forces/eppacPd_iy7BbHFbm07_8Mtw2Oo Cc: "forces@ietf.org" , S Moonesamy , Evangelos Haleplidis , The IESG Subject: Re: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 20:08:18 -0000 Yes, I believe that "Specification Required" as per RFC 5226 does what we want in terms of the registry. Yours, Joel On 8/8/14, 4:04 PM, Jamal Hadi Salim wrote: > On Fri, Aug 8, 2014 at 3:42 PM, Barry Leiba wrote: > >>> If two people ask for the same code - then fcfs is used. The expert is >>> consulted always. >>> If that intent in the doc is not clear - help us come with better wording. >> >> That is not FCFS; that is Expert Review, or perhaps Specification >> Required. You can (actually, should) then give instructions to the >> designated expert about what she should consider in her review. >> >> Confusing registration policies are one of the biggest problems we >> have with IANA considerations. Read RFC 5226 -- or, better, read >> draft-leiba-cotton-iana-5226bis, and look at Section 4 carefully. If >> you want to require a specification, then use "Specification >> Required"; a designated expert will be appointed to review the >> specifications and approve (or not) the registrations. > > If Specification Required implicitly also means expert review is needed > then that is what we need. I thought you had to explicitly state each. > Thanks for the detail - I will update the doc. > > cheers, > jamal > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > From nobody Fri Aug 8 13:20:17 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB7C1B2845 for ; Fri, 8 Aug 2014 13:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5jPPY8UQCz0 for ; Fri, 8 Aug 2014 13:20:11 -0700 (PDT) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995DE1B27E8 for ; Fri, 8 Aug 2014 13:20:08 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id la4so9078136vcb.9 for ; Fri, 08 Aug 2014 13:20:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8cqThzJGC0dqFUB1JmkptMFLfE/LRWdTkWw4FThV4Yk=; b=Aq4/jVEkDyI5arliAyvTmirb5DlIk0zMDDAfzORv/11woVW6i0cbFCEic5UaSnjGor uf/yRU7cGIwT0e+fnWpS7XGFeId+xRdK5wTtT9vv5zCSYhf5Tkz+htKhBsu+PaN6x0WR 0NGASJNDEBQ5kxtqMyHSo59ammrq4bQRkDRUWRUoC+5qwWggR03OkS1wTpVck4lnZeeJ DzOyfO1D/q9BIekPpjympfLgCyZxN7OfLFlRqKVwpLxhn0pZ9nmsarXFavHBZeIgsxes PEsxFsb8DLEVBu53OJySRWiSIazqcQR14RlgCQGQlR6MsSfH4z/XL3MZcC/0tV9Xaodf WtuQ== X-Gm-Message-State: ALoCoQl14969UAN0UMQuxuY6ylx1/K7vBXevauWJN8bfb7ASUKhHpaU+VzVeF8mKr7UxWkx8PSJW X-Received: by 10.52.137.2 with SMTP id qe2mr8306875vdb.11.1407529207810; Fri, 08 Aug 2014 13:20:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.49.228 with HTTP; Fri, 8 Aug 2014 13:19:47 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20140808123121.0c41a5b8@elandnews.com> References: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> <6.2.5.6.2.20140808085335.0c04e2b0@elandnews.com> <6.2.5.6.2.20140808123121.0c41a5b8@elandnews.com> From: Jamal Hadi Salim Date: Fri, 8 Aug 2014 16:19:47 -0400 Message-ID: To: S Moonesamy Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/IOW6rMGwiBuULJMSQSVumYqZEjY Cc: "forces@ietf.org" , The IESG , Evangelos Haleplidis Subject: Re: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 20:20:12 -0000 SM, On Fri, Aug 8, 2014 at 3:49 PM, S Moonesamy wrote: > Hi Jamal, > > At 12:26 08-08-2014, Jamal Hadi Salim wrote: >> >> If two people ask for the same code - then fcfs is used. The expert is >> consulted always. >> If that intent in the doc is not clear - help us come with better wording. >> Feel free to mutilate the paragraph we have;-> > > > I prefer to leave that to one to the Area Directors while I peck on the > process issue. :-) > Barry Leiba provided clarity ;-> > >> I believe it would be within the realm of your rights to object, but >> please dont work on assumptions. It is better to get insight. > > > If the above means listening to higher authority, such as what is said by an > Area Director, well, you know ... :-) > Authority should always be questioned. There are limits (such as challenging the AD on authority of whether the world is round instead of being so obviously flat). But micro-managing an AD's trust managing a WG is not a scalable solution. > I was referring to my first message which you responded to. To be fair, > your responsiveness is better than what I am used to in the IETF. > Ok, sorry - I was scratching my head trying to remember a discussion. > The above paragraph does not name any implementations or provide any public > information about the real serious deployments issues. > We dont want to name any implementations - unless process requires us to. There are some implementations that were named in the past (two interop RFCs were published, but they dont apply to this spec). > I did not listen to the audio. The IESG may be able to use that to justify > its decision. However, that can be challenged. > My point on not making assumptions is that your sample space is very limited to reach a conclusion that there was no consensus. If you really want to make that claim fairly then you need to do more homework (or as i pointed to get insight). There are a lot of factors involved other than looking at who posted on the list. cheers, jamal From nobody Fri Aug 8 13:21:24 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A541A03DF; Fri, 8 Aug 2014 12:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYm81VejRZzP; Fri, 8 Aug 2014 12:52:03 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E6D1A03CD; Fri, 8 Aug 2014 12:52:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.148.186]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s78JpkNS024039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2014 12:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1407527519; x=1407613919; bh=ew2gBxl14Ed0E645bukA08cuZV+C+2+mVKeNC+bbsXI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=DprDGPqbrm8Uyr3X8U/1VTnVLuvNbPoGv6Dre+LytB2/pLSfD1hTgZd1MLBUsg3OQ wOHo57DehnNBUzCOO+SbBtzvCt98OYewxdvQ89nZWGC9jQPKDTpe8pHUFKMAlUyZbu 1jxR6pN2C8eWyu4m1X480PVt83hQV6kArjinPg0M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1407527519; x=1407613919; i=@elandsys.com; bh=ew2gBxl14Ed0E645bukA08cuZV+C+2+mVKeNC+bbsXI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=zaEnR7TJUr97r0okCsWoy+WVr6WU2Sbju7rD4foE1WAtbBbsZwBs3lpWwBtDXu54/ SIZqtcOO1E8IkXjqSPCLD+ckxkXNJPn6pCVhBJQ8uazoiMDZDLggaMMeNbPU2hzKps vct9WOkh8PkbN5f3Zl4/3B7rhZ5VYdyACTCC6Ol4= Message-Id: <6.2.5.6.2.20140808123121.0c41a5b8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 08 Aug 2014 12:49:17 -0700 To: Jamal Hadi Salim From: S Moonesamy In-Reply-To: References: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> <6.2.5.6.2.20140808085335.0c04e2b0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/forces/Ql7SjLC_edFHIfhYJ3JZT8gqOJ8 X-Mailman-Approved-At: Fri, 08 Aug 2014 13:21:16 -0700 Cc: forces@ietf.org, iesg@ietf.org, Evangelos Haleplidis Subject: Re: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 19:52:05 -0000 Hi Jamal, At 12:26 08-08-2014, Jamal Hadi Salim wrote: >If two people ask for the same code - then fcfs is used. The expert is >consulted always. >If that intent in the doc is not clear - help us come with better wording. >Feel free to mutilate the paragraph we have;-> I prefer to leave that to one to the Area Directors while I peck on the process issue. :-) >I believe it would be within the realm of your rights to object, but >please dont work on assumptions. It is better to get insight. If the above means listening to higher authority, such as what is said by an Area Director, well, you know ... :-) >I think the general trend is to give the AD the benefit of doubt. If there >are loopholes to be closed , i think that is a separate discussion. Ok. >Sorry if we missed your earlier comments; there is still room to resolve any >thing you brought up in the past that was missed. (Re)send either private mail >or email to the list. I was referring to my first message which you responded to. To be fair, your responsiveness is better than what I am used to in the IETF. >When this document was published as a WG document those controversial >issues were removed. So this document, as articulated by the shepherd, >has no controversy. Does that make sense? That makes sense. >I pointed to one meetings minutes but if you go backwards, things will >make more sense. >Again: >This is a simple document to a simple update (as you acknowledge). >My comment on bike-shedding was more to make the point that >we shouldnt have discussions just because we can. I agree that we shouldn't have discussions just because we can. >Perhaps the question is motivated because you see some technical flaw >in the spec? It would help to point what that is so we can either >provide clarification or fix something. [Example, the comments from >the security directorate tried to point out to some possible security issues. >We provided clarification.] I was homing on the process angle. >To satisfy your curiosity: >I can only vaguely respond that there are implementations that >run in real serious deployments that have implemented the majority >of the spec - ongoing with implementation to complete the spec. The above paragraph does not name any implementations or provide any public information about the real serious deployments issues. >*Not everything* happens on lists. That is why we need meetings >and a water fountain. >There was more than one meeting where discussions happened >in regards to the eventual draft. But lets look at the meeting you brought up: >I am pretty sure if you listened to the audio of just that one meeting >you will get a better feeling of what the minute taker missed. >And if you attended that meeting, you will get even better view. >And if you participated earlier even more sense. I did not listen to the audio. The IESG may be able to use that to justify its decision. However, that can be challenged. I'll raise the process issue on ietf@ietf.org. >Well, I hope there is clarity in my comments. There is. Thanks for the diligent response. Regards, S. Moonesamy From nobody Fri Aug 8 13:34:48 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0511A0A88; Fri, 8 Aug 2014 13:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3O437HzPML7; Fri, 8 Aug 2014 13:34:40 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA1581A0109; Fri, 8 Aug 2014 13:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1407530080; x=1439066080; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=82HCbc3S8WDvBt1YTau3VKcYs0+AC9ORHUaq2usnFAA=; b=yh8bBiXfEKxiZEAeV47BOA93Bm/jNNnsiqaEdfFQx2tDRytzr4jymPVL y09j3sjgN2J7qnqI1Yyym4iGVprPb5kU1i+55G/IeBV6KsW7jtLeHO3fv aV3uYSuI8ze90t/ixdLcgGiy8XPzll/kN+j7za+1Mz7MJo532bzekhTRC 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7524"; a="148489908" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 08 Aug 2014 13:34:40 -0700 X-IronPort-AV: E=Sophos;i="5.01,827,1400050800"; d="scan'208";a="728222085" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Aug 2014 13:34:40 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 8 Aug 2014 13:34:39 -0700 Message-ID: <53E5345E.4010907@qti.qualcomm.com> Date: Fri, 8 Aug 2014 15:34:38 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: S Moonesamy References: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> <6.2.5.6.2.20140808085335.0c04e2b0@elandnews.com> <6.2.5.6.2.20140808123121.0c41a5b8@elandnews.com> In-Reply-To: <6.2.5.6.2.20140808123121.0c41a5b8@elandnews.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/forces/t8bXR3ENCUCTnmvNQYLPmAacAtU Cc: forces@ietf.org, iesg@ietf.org, Evangelos Haleplidis Subject: Re: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 20:34:42 -0000 A couple of points about the discussion of the writeup and coming to consensus: On 8/8/14 2:49 PM, S Moonesamy wrote: > At 12:26 08-08-2014, Jamal Hadi Salim wrote: > >> When this document was published as a WG document those controversial >> issues were removed. So this document, as articulated by the shepherd, >> has no controversy. Does that make sense? > > That makes sense. Sure, but do keep in mind that the writeup is there to help out the IESG during Last Call and IESG Review. If there was a big controversy about going with technology A and the WG fought it out, but in the end decided that technology B solved the same problem as A and was uncontroversial, the shepherd needs to decide if there's some chance that someone will bring up A again, either in Last Call or in IESG Review. If so, it might be a good idea to mention in the writeup, "We had a big controversy about technology A in that some people thought that it killed kittens, but in the end we went with technology B, which solved the same problem and created extra-cuddly kittens". Simply saying, "No controversy about B" is OK, but it doesn't give us much to go on if A gets brought up again. Either way, it's a judgment call. >> *Not everything* happens on lists. That is why we need meetings >> and a water fountain. >> There was more than one meeting where discussions happened >> in regards to the eventual draft. But lets look at the meeting you >> brought up: >> I am pretty sure if you listened to the audio of just that one meeting >> you will get a better feeling of what the minute taker missed. >> And if you attended that meeting, you will get even better view. >> And if you participated earlier even more sense. Let's be very careful here. Yes, lots of stuff does get done at face-to-face meetings, and by design teams, and sometimes by the water fountain or at a bar. But in the end, *all* of those things need to make it to the list. We've got to have written documentation *somewhere* about the decisions that were made, and folks who were not able to show up in person need to be able to review (and possibly challenge) them. If all we're talking about is a "feeling" and a "sense" of the discussion being missed, that's OK. But if the minute taker is missing the essence of what decision was made and why, that's not good. We *must* be able to find out that information, and (at least given our procedures now) it must be on the mailing list. You didn't say that any of the actions and decisions were missing from the minutes, but I think that's what SM heard. > I did not listen to the audio. The IESG may be able to use that to > justify its decision. However, that can be challenged. > > I'll raise the process issue on ietf@ietf.org. And let's not do that unless we know that a process issue actually exists. No, the IESG does not go back and listen to the audio to justify decisions. Like everyone else, we try to rely on the mailing list, what's in the document, and what's in the writeup. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Fri Aug 8 15:01:53 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E101A00B0 for ; Fri, 8 Aug 2014 15:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD_zryBvXVZO for ; Fri, 8 Aug 2014 15:01:50 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F791A00BE for ; Fri, 8 Aug 2014 15:01:50 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id ik5so9160602vcb.34 for ; Fri, 08 Aug 2014 15:01:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gOvDT+2jkujsw8k01/FC+pOmyu62GU0q2bf91sCRiKE=; b=AEGA9X+bUMGCF4t8MAJMBqPRaRgMsdZlmc9G3h9yOmAzKK+YYOY3mulWAkVuhduuHT mioO5BLVAsgbA7qAABdXSHzkdF27GXrJw9Sy7YDlpHk5Q4lIEukNQE7BadvKFaXceX0f +sa1bJcXle0lFvUZO5wvhQ44r33cNd4sPht6PzSBsLqRn5sWJv9FyPHV92QsNL42RoN8 53zVNxbuiEgSpI7f5nj4s6N0Rr4XngYUbAv1aeGHRb29LLHQJf3Ol58bavX3NN12ABHT qUPvaOWXh6YPScqZvnhZgFLfc2NbXVhNLrOtnuTumQrIgQViQRMEwh2GsagLgAGCCqP7 QrfA== X-Gm-Message-State: ALoCoQlTbcbfE1Ak81umC/XxPmP2SuBx9zn+RdwlHpq/uCjb8axZa7/TpGSpUG8o2QPj2/TbK4mC X-Received: by 10.52.156.100 with SMTP id wd4mr8522251vdb.39.1407535309709; Fri, 08 Aug 2014 15:01:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.49.228 with HTTP; Fri, 8 Aug 2014 15:01:29 -0700 (PDT) In-Reply-To: <53E5345E.4010907@qti.qualcomm.com> References: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> <6.2.5.6.2.20140808085335.0c04e2b0@elandnews.com> <6.2.5.6.2.20140808123121.0c41a5b8@elandnews.com> <53E5345E.4010907@qti.qualcomm.com> From: Jamal Hadi Salim Date: Fri, 8 Aug 2014 18:01:29 -0400 Message-ID: To: Pete Resnick Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/0-8ouajLHv9F9Slt_mhNTHERhgw Cc: "forces@ietf.org" , S Moonesamy , Evangelos Haleplidis , The IESG Subject: Re: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 22:01:52 -0000 On Fri, Aug 8, 2014 at 4:34 PM, Pete Resnick wrote: > Sure, but do keep in mind that the writeup is there to help out the IESG > during Last Call and IESG Review. If there was a big controversy about going > with technology A and the WG fought it out, but in the end decided that > technology B solved the same problem as A and was uncontroversial, the > shepherd needs to decide if there's some chance that someone will bring up A > again, either in Last Call or in IESG Review. If so, it might be a good idea > to mention in the writeup, "We had a big controversy about technology A in > that some people thought that it killed kittens, but in the end we went with > technology B, which solved the same problem and created extra-cuddly > kittens". Simply saying, "No controversy about B" is OK, but it doesn't give > us much to go on if A gets brought up again. Either way, it's a judgment > call. > In this case it was a toss up, I think. The original document was an individual contribution. As author, I wouldnt say i was ecstatic about some things we removed. But we need to make progress. We cant keep debating things that could be resolved later. To quote the last meeting discussion: ----- There was strong resistance so far against table append. Agreed to remove table append. Jamal plans to write another document in the future to cover table append vs replace vs exclusivity. ----- So there is intent to later publish a mininal informational document. Infact our implementation already has some of those original idea. In retrospect we could have stated that history - but i believe the shepherd was refering to the current document (or its 4th revision when he did the writeup). > > Let's be very careful here. Yes, lots of stuff does get done at face-to-face > meetings, and by design teams, and sometimes by the water fountain or at a > bar. But in the end, *all* of those things need to make it to the list. > We've got to have written documentation *somewhere* about the decisions that > were made, and folks who were not able to show up in person need to be able > to review (and possibly challenge) them. If all we're talking about is a > "feeling" and a "sense" of the discussion being missed, that's OK. But if > the minute taker is missing the essence of what decision was made and why, > that's not good. We *must* be able to find out that information, and (at > least given our procedures now) it must be on the mailing list. > > You didn't say that any of the actions and decisions were missing from the > minutes, but I think that's what SM heard. > I think i was being defensive to the statement there was "no consensus". I may have even felt a little offended but i realize it was meant with good intention. cheers, jamal From nobody Fri Aug 8 15:04:30 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102651A00F1; Fri, 8 Aug 2014 14:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKvrWbUutFG9; Fri, 8 Aug 2014 14:46:52 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C521A00E6; Fri, 8 Aug 2014 14:46:52 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.133.192]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s78LkWx1017018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2014 14:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1407534405; x=1407620805; bh=Tck3M0bNjCESYN1EZ8PasLhh+HcnkiZfDJl6xjSjnYg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=RxxlMgxNJzqskKB/X1MUa8bREh3omsZDf1lGqbR1fSMwunjtKDqDDV5pe3A1Q69MJ jEOxR/WeTKZQFR25eriDDKyOoskbU/sx5h+bZjgvzcVyWyonzIbO1CvEcye14Jm/fw VOzTCZCwTK5cWCDZaMjYBGjxdRgT99iJNi/530JI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1407534405; x=1407620805; i=@elandsys.com; bh=Tck3M0bNjCESYN1EZ8PasLhh+HcnkiZfDJl6xjSjnYg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Y07sJ3Wgmf8Wf/yufR07ghl/LSV2pOE9iWacLTuFhZnGYoyU0h5o2leG+povUXQ0Q 6qFK3+jM4mhUW5ltTrA+7whwa8qyRBbmVTqqz2S3e8a0lWjwZwZRPirsX6jvQSPk8Q CDnN91zuQF4QQ0y1r0GBMT94Y4BECjNpxUxuNImo= Message-Id: <6.2.5.6.2.20140808134003.0c7f36c0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 08 Aug 2014 14:42:38 -0700 To: Pete Resnick From: S Moonesamy In-Reply-To: <53E5345E.4010907@qti.qualcomm.com> References: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> <6.2.5.6.2.20140808085335.0c04e2b0@elandnews.com> <6.2.5.6.2.20140808123121.0c41a5b8@elandnews.com> <53E5345E.4010907@qti.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/forces/_mkQ78nvHuFsZAs0ow2fp-e2eFY X-Mailman-Approved-At: Fri, 08 Aug 2014 15:04:29 -0700 Cc: forces@ietf.org, iesg@ietf.org, Evangelos Haleplidis Subject: Re: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 21:46:54 -0000 Hi Pete, At 13:34 08-08-2014, Pete Resnick wrote: >Let's be very careful here. Yes, lots of stuff does get done at >face-to-face meetings, and by design teams, and sometimes by the >water fountain or at a bar. But in the end, *all* of those things >need to make it to the list. We've got to have written documentation >*somewhere* about the decisions that were made, and folks who were >not able to show up in person need to be able to review (and >possibly challenge) them. If all we're talking about is a "feeling" >and a "sense" of the discussion being missed, that's OK. But if the >minute taker is missing the essence of what decision was made and >why, that's not good. We *must* be able to find out that >information, and (at least given our procedures now) it must be on >the mailing list. > >You didn't say that any of the actions and decisions were missing >from the minutes, but I think that's what SM heard. My point is, as you mentioned above: "We *must* be able to find out that information, and (at least given our procedures now) it must be on the mailing list". I looked at the Forces mailing list archive to get a sense of the discussion. I found the following messages: I-d-announce: http://www.ietf.org/mail-archive/web/forces/current/msg04727.html http://www.ietf.org/mail-archive/web/forces/current/msg04791.html http://www.ietf.org/mail-archive/web/forces/current/msg04821.html http://www.ietf.org/mail-archive/web/forces/current/msg04822.html http://www.ietf.org/mail-archive/web/forces/current/msg04874.html Other: http://www.ietf.org/mail-archive/web/forces/current/msg04765.html http://www.ietf.org/mail-archive/web/forces/current/msg04768.html http://www.ietf.org/mail-archive/web/forces/current/msg04823.html http://www.ietf.org/mail-archive/web/forces/current/msg04824.html http://www.ietf.org/mail-archive/web/forces/current/msg04825.html WGLC: http://www.ietf.org/mail-archive/web/forces/current/msg04827.html http://www.ietf.org/mail-archive/web/forces/current/maillist.html http://www.ietf.org/mail-archive/web/forces/current/msg04846.html http://www.ietf.org/mail-archive/web/forces/current/msg04848.html AD Review: http://www.ietf.org/mail-archive/web/forces/current/msg04866.html http://www.ietf.org/mail-archive/web/forces/current/msg04868.html Last Call: http://www.ietf.org/mail-archive/web/forces/current/msg04875.html The discussion was mainly between the author and the Document Shepherd. There was a comment from Joel. There wasn't any decisions taken to the mailing list. There isn't anything on ietf@ietf.org. Would a person who has not been attending the face-to-face meetings be able to understand the decisions? I don't think so (see URLs provided above). Would that person be able to find out whether there has actually been public review and some level of agreement? What the person would find is the above URLs and agreement between the author, the Document Shepherd and some directorate reviews. This is what that IESG might also be looking at as it decides whether there is IETF Consensus. You (used in a general sense) only have formal reviews on which to base the decision. >And let's not do that unless we know that a process issue actually >exists. No, the IESG does not go back and listen to the audio to >justify decisions. Like everyone else, we try to rely on the mailing >list, what's in the document, and what's in the writeup. There are some points such as what is explained above which might not be apparent. The process issue is that the documentation does not show the decisions and actions. What the IESG would be approving is, in my opinion, lazy consensus. It is possible to challenge that IESG decision. Regards, S. Moonesamy From nobody Fri Aug 8 15:04:32 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47741A00FC; Fri, 8 Aug 2014 15:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X6UZhEWbcbR; Fri, 8 Aug 2014 15:02:39 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 111D81A00B0; Fri, 8 Aug 2014 15:02:39 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.133.192]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s78M2N3V016421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2014 15:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1407535356; x=1407621756; bh=3/DvnELnp0iIbjP2XPMsdU4SJBgKsiNcFcaUthBjGF0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LnlWIZR5XU0+mRYfckPmE81t02x8PZSAJ7dCJ4FxDEH05kg/nJR9Jr4qMa10thWsh S3XJ2kN2mKLUot7Wd6CnrJ9nlX9z3tLh66nyaTftQLsJXlrj83xZ1BdSKK59Rd0mnC 5E8F9uwoRkd4DFI1jkmT+oKdV8/XBuwXi6293U7M= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1407535356; x=1407621756; i=@elandsys.com; bh=3/DvnELnp0iIbjP2XPMsdU4SJBgKsiNcFcaUthBjGF0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=a/6SgfcW3ZwQWJpOPhTHUTqqZJKkwGAr2jfTp1QOWou11wJuJmZqpNenxA8n8NNtS mnJv2pw7i8TB0wgqwb/3/S55cuDWWG/GcrCR4t8szYs6CDamh3THL1XEmrrNprLlXR H90faaAZ4qryxq6XWa4c7Wj8yOI+My4IoH6rRjc8= Message-Id: <6.2.5.6.2.20140808145328.0c7eb038@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 08 Aug 2014 14:57:31 -0700 To: Jamal Hadi Salim From: S Moonesamy In-Reply-To: References: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> <6.2.5.6.2.20140808085335.0c04e2b0@elandnews.com> <6.2.5.6.2.20140808123121.0c41a5b8@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/forces/fKjFUQK2HKnJJiGiLi_qscbUS_U X-Mailman-Approved-At: Fri, 08 Aug 2014 15:04:29 -0700 Cc: forces@ietf.org, iesg@ietf.org, Evangelos Haleplidis Subject: Re: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 22:02:40 -0000 Hi Jamal, At 13:19 08-08-2014, Jamal Hadi Salim wrote: >My point on not making assumptions is that your sample space is very >limited to reach a conclusion that there was no consensus. If you really >want to make that claim fairly then you need to do more homework >(or as i pointed to get insight). There are a lot of factors involved other >than looking at who posted on the list. There is a message from Pete Resnick to which I replied to. I would prefer if we take up the discussion about consensus on that exchange if you are okay with that. Regards, S. Moonesamy From nobody Sat Aug 9 03:51:31 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA901B279B; Sat, 9 Aug 2014 03:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_-8Khcwj258; Sat, 9 Aug 2014 03:51:22 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA2E1A0944; Sat, 9 Aug 2014 03:51:21 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s79AotVx030214; Sat, 9 Aug 2014 11:50:55 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s79AosS1030205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 9 Aug 2014 11:50:55 +0100 From: "Adrian Farrel" To: "'Jamal Hadi Salim'" , "'S Moonesamy'" References: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> <6.2.5.6.2.20140808085335.0c04e2b0@elandnews.com> <6.2.5.6.2.20140808123121.0c41a5b8@elandnews.com> In-Reply-To: Date: Sat, 9 Aug 2014 11:50:53 +0100 Message-ID: <04cb01cfb3bf$caff2d00$60fd8700$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDiL9AuGE3Nm4dhKnJMf9oU5vuUigIxPLbYAhLfbCcCV9VYGwHAvsZiAbQLWnsB59kA451DWOBg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20868.006 X-TM-AS-Result: No--38.809-10.0-31-10 X-imss-scan-details: No--38.809-10.0-31-10 X-TMASE-MatchedRID: 0lhM5bBmjEMzx9GDMr0HvzYTypjB3iDVuikHZcC6ceATVJPv0YKEKV+O 7YeE+Ud6BKN4guY70ZOgglhSgkQaQNkWd3+i9ZzZcFEiuPxHjsW7nrAU9KQxUUjnVDI1hWXOahd Ff2zEfm/qQpuIwOcB2/wAT3yl/pHZn8kT944y5fcUEm127/0kJmf9vAkCKmbvxSZxKZrfThMVCm GfOIJfSvYrKgP0B8KDumDQSzzA2nXY082Moc1wRgXysW33GYMpGSqdEmeD/nUifM7JMNHW69SP5 jpwwgA2KRB1OPnOkxYUvQxLb123uja3IVISEcRn2Hdvv/MGE3W36GGfwjLoZdp1biJhIyNRcBa4 5GbRMhpFXcm/C/kiiUpcnw0m8ogTBVwP6b8+JkgX2N9OpwN26AXLIdcukLJWJLfQYoCQHFYvc8s yVBJ2ZMthHzHGYwphi3bTLY4XhM7HSssK+vO2mXlMlWV+Ir67uoYFb0nRiqMoDMZ3xV44iPiGJE hc+Gshwdv6PN2fgBauB6WcjahkUY6vrd50xb7zMIiU395I8H26QCTCuzfiVYBjCscjOitaX/bMp fGNHn2z9GaPyzCFobEsjT+pHjpB90+rNXcoVNdPuMJi/ZAk8TNzwULQwTBPMyPDUbCgtMHP5CAU vjYQxDm45ONnVPIGdvkciu9FqkVJZBjs6jQn0rMjW/sniEQKEsPHM6iHL3YhvFjBsLEZNPLSEIh ToRX28aWLEzVqNwAWcpBHc6fDRhgHZ8655DOPgxsfzkNRlfKx5amWK2anSPoLR4+zsDTtAqYBE3 k9Mpw= Archived-At: http://mailarchive.ietf.org/arch/msg/forces/G9EyFwOStkay4AldzCvGtO4UTgk Cc: forces@ietf.org, 'The IESG' , 'Evangelos Haleplidis' Subject: Re: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 10:51:25 -0000 Let me pick an email in the middle of the thread and then top-post :-) I would prefer that in questions of whether there was consensus, the = debate was addressed by the other WG chair (not the one who is an author = of this document). I would prefer that questions about what the shepherd write-up says were = addressed by the document shepherd. I think that the questions raised in this thread are valuable but need = context. The Shepherd write-up is primarily a communication between the document = shepherd and the responsible AD (me). I am capable of following up on = issues that are unclear or seem like fudge. i can do that publically or = privately. I can require that the write-up is updated or leave it = fallow. Any passer-by who reads the write-up and has concerns can raise = them to me or on the public list (as has happened). Shepherd write-ups do not call consensus nor should they claim = consensus. They should report facts (what happened, what was seen on the = list, etc.). I don't think you could appeal a shepherd write-up for what = it says about consensus although you might make counter claims to the = responsible AD. The ForCES working group is winding down and close to closing. It has a = few more documents to push out and nearly all of the work has been done = on these. Getting anything out of the working group at this stage beyond = absence of dissent will be impractical. As AD I am choosing between: - shut the WG and have only ISE RFCs on ForCES - shut the WG and allow AD Sponsored RFCs on ForCES - let the WG wrap up what is in hand. I choose the latter for efficiency and best hope of document review. Cheers, Adrian > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Jamal Hadi = Salim > Sent: 08 August 2014 21:20 > To: S Moonesamy > Cc: forces@ietf.org; The IESG; Evangelos Haleplidis > Subject: Re: [forces] Last Call: = (ForCES > Protocol Extensions) to Proposed Standard >=20 > SM, >=20 > On Fri, Aug 8, 2014 at 3:49 PM, S Moonesamy = wrote: > > Hi Jamal, > > > > At 12:26 08-08-2014, Jamal Hadi Salim wrote: > >> > >> If two people ask for the same code - then fcfs is used. The expert = is > >> consulted always. > >> If that intent in the doc is not clear - help us come with better = wording. > >> Feel free to mutilate the paragraph we have;-> > > > > > > I prefer to leave that to one to the Area Directors while I peck on = the > > process issue. :-) > > >=20 > Barry Leiba provided clarity ;-> >=20 > > > >> I believe it would be within the realm of your rights to object, = but > >> please dont work on assumptions. It is better to get insight. > > > > > > If the above means listening to higher authority, such as what is = said by an > > Area Director, well, you know ... :-) > > >=20 > Authority should always be questioned. There are limits (such as = challenging the > AD on authority of whether the world is round instead of being so > obviously flat). > But micro-managing an AD's trust managing a WG is not a scalable = solution. >=20 >=20 > > I was referring to my first message which you responded to. To be = fair, > > your responsiveness is better than what I am used to in the IETF. >=20 > Ok, sorry - I was scratching my head trying to remember a discussion. >=20 >=20 > > The above paragraph does not name any implementations or provide any > public > > information about the real serious deployments issues. > > >=20 >=20 > We dont want to name any implementations - unless process requires us = to. > There are some implementations that were named in the past (two = interop > RFCs were published, but they dont apply to this spec). >=20 > > I did not listen to the audio. The IESG may be able to use that to = justify > > its decision. However, that can be challenged. > > >=20 > My point on not making assumptions is that your sample space is very > limited to reach a conclusion that there was no consensus. If you = really > want to make that claim fairly then you need to do more homework > (or as i pointed to get insight). There are a lot of factors involved = other > than looking at who posted on the list. >=20 > cheers, > jamal From nobody Sat Aug 9 06:47:48 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F021B2813 for ; Sat, 9 Aug 2014 06:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s49kUOWkzKMo for ; Sat, 9 Aug 2014 06:47:35 -0700 (PDT) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA0E1B27F5 for ; Sat, 9 Aug 2014 06:46:17 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wp18so4848591obc.20 for ; Sat, 09 Aug 2014 06:46:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=n//osSdCVNsMhfFF7aN6DiTPdNvXh0L24dZOiJqvh7Y=; b=J5IvcQgW2IkTo7+kx5KPG6puTKWd4UtaCqe5PpTnWiCHPatZEe8K/Og6D5S8wPWkpC hJRcjT3wmkSKxKX1ewHUijBMNNL9T1v9B86s+G7sei6R6YTBzoZ3ZQfvCxy6YlkxhGgt /+N0Emige0gUptcZTQyBN2vgwUZESJLMkctBdmG3VZGtrKB3+79Lknepx43msqU7e8mx lZI6FYH+T9qN3aqAWdjCnNkPIL++VJliE4uYIAy4ITJY2dk+lQ+Jj8MvdzTJLEqXpu23 VS6PTzd59Y4OIGhivTXiuNAPE7lu5ewfLAybYIlIJoAY45zy0ykWjUQa3xxYCS9NVVJq F1wA== X-Gm-Message-State: ALoCoQlCMhGcUG0MzXP4bBvi/OyXDgilgtfTZB9vaPGQhMM+MZM28Sgo4jDJ9vxNwjPBYtCpssiN X-Received: by 10.60.41.65 with SMTP id d1mr2191237oel.76.1407591976529; Sat, 09 Aug 2014 06:46:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.210.19 with HTTP; Sat, 9 Aug 2014 06:45:56 -0700 (PDT) From: Jamal Hadi Salim Date: Sat, 9 Aug 2014 09:45:56 -0400 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/Jo7mhrUcrEdEX92G7a4hyhx6gVY Subject: [forces] Adoption of ForCES Inter-FE LFB X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 13:47:45 -0000 As per meeting discussion, there was agreement to adopt http://tools.ietf.org/html/draft-joachimpillai-forces-interfelfb-04 as the WG document for the inter FE chartered work. If there are any objections or suggestions please raise them on the list (dont send me or DJ private email). Silence implies consent. I am actually re-factoring code of an earlier implementation right now as we speak. Based on that we will publish the new WG document. cheers, jamal From nobody Sat Aug 9 10:10:11 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05071A065D; Sat, 9 Aug 2014 09:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.242 X-Spam-Level: X-Spam-Status: No, score=0.242 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.668, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIUFUXZFxw0y; Sat, 9 Aug 2014 09:33:04 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A3E1A064B; Sat, 9 Aug 2014 09:33:03 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.133.192]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s79GWe97005784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Aug 2014 09:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1407601977; x=1407688377; bh=P3UKV/4WmOLKKRHEAHMMTDSHc4TcgGv/f+U1vdaYDsc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=F3K2mOGwuSs8tTxC1ZOA7kdkKdp9ksDbQN7CDiRCrGxTRWQqRENqZ9oZz21muAwAj /K58ARWwEG88uzSCIqt9xcNAeHqDphMZcOA0qX1YIk886DmXXR+fz+4VKmecbm71sn nkSjKvaNFaTObBMa0ne2Lt8tSUm1XHGVw4l2nooY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1407601977; x=1407688377; i=@elandsys.com; bh=P3UKV/4WmOLKKRHEAHMMTDSHc4TcgGv/f+U1vdaYDsc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Po+txt+smcOf+VrbOwzrrh8Wk6VfDfHKyw17UVBi4/qV4MazsZHz4NN1dQBTmcoEO XY2V0/gTytkJsM6PL4j0WKpcWwjPqQPSD4YtfaM7AGiCV9fGU1mlMWParMW15VG7cm GmLJGEoYYsEpn616lXITwJU9atTvSowNHsSVPRn0= Message-Id: <6.2.5.6.2.20140809074914.0d75d2d8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 09 Aug 2014 09:28:49 -0700 To: , Jamal Hadi Salim From: S Moonesamy In-Reply-To: <04cb01cfb3bf$caff2d00$60fd8700$@olddog.co.uk> References: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> <6.2.5.6.2.20140808085335.0c04e2b0@elandnews.com> <6.2.5.6.2.20140808123121.0c41a5b8@elandnews.com> <04cb01cfb3bf$caff2d00$60fd8700$@olddog.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/forces/vTBkI1gEsfli_5J3X37T8kI4OGE X-Mailman-Approved-At: Sat, 09 Aug 2014 10:10:08 -0700 Cc: forces@ietf.org, iesg@ietf.org, Evangelos Haleplidis Subject: Re: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 16:33:08 -0000 Hi Adrian, At 03:50 09-08-2014, Adrian Farrel wrote: >Let me pick an email in the middle of the thread and then top-post :-) Ok. :-) >I would prefer that in questions of whether there was consensus, the >debate was addressed by the other WG chair (not the one who is an >author of this document). >I would prefer that questions about what the shepherd write-up says >were addressed by the document shepherd. Ok. >I think that the questions raised in this thread are valuable but >need context. > >The Shepherd write-up is primarily a communication between the >document shepherd and the responsible AD (me). I am capable of >following up on issues that are unclear or seem like fudge. i can do >that publically or privately. I can require that the write-up is >updated or leave it fallow. Any passer-by who reads the write-up and >has concerns can raise them to me or on the public list (as has happened). Ok. >Shepherd write-ups do not call consensus nor should they claim >consensus. They should report facts (what happened, what was seen on >the list, etc.). I don't think you could appeal a shepherd write-up >for what it says about consensus although you might make counter >claims to the responsible AD. It would be very difficult to appeal a Shepherd write-up. For what it is worth, it has never been done before. >The ForCES working group is winding down and close to closing. It >has a few more documents to push out and nearly all of the work has >been done on these. Getting anything out of the working group at >this stage beyond absence of dissent will be impractical. As AD I am >choosing between: >- shut the WG and have only ISE RFCs on ForCES >- shut the WG and allow AD Sponsored RFCs on ForCES >- let the WG wrap up what is in hand. >I choose the latter for efficiency and best hope of document review. Ok. Regards, S. Moonesamy From nobody Sun Aug 10 11:49:55 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42441A00D2 for ; Sun, 10 Aug 2014 11:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iy-9RLWn5dgr for ; Sun, 10 Aug 2014 11:49:50 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5FE1A00BA for ; Sun, 10 Aug 2014 11:49:49 -0700 (PDT) Received: by mail-oi0-f43.google.com with SMTP id u20so5012308oif.2 for ; Sun, 10 Aug 2014 11:49:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=jD1UKi5G12n+oMLpIudBEZyUAbAph9HkTHg6qKzdUiI=; b=XB3ToqiXcR+FgnHXOsUUm5VmxBjdK789/HxRtqXYM11R8v0taOrXNWZGn4J8F9046n gPeH41SXHW5f2xeRF2ZeMtI/mDcHd4lvVLR5zUm7sYJSEyiHqiKSk+6ONmuG9UEXQiBD 8fPbI3eCovBLn0JseOcnb1zl8+fpYlA58G9eYQS23Bd+vj/C8PH1OSZ7tlVgqHESsjT2 Ai7K7HBLj8G9fhwflYxtwRGrq8myR9PehEiF7YYs9NvGtvQ78F4hoHyQpKeJZeBLlXLX 8DhjmmKLhObpAX9rcgBMHU+bjIcZTexqLuKYgMeUu9VbjF6cWJonYaVCuraB/r9BS2jI aTuA== X-Gm-Message-State: ALoCoQm2yaLdjZW9GNRD1zKnvJ0p+bT2YsTtbdrgNtnL1Ou+ws8qDpkRe4QX/Ytz1KnW9b689Mtv X-Received: by 10.60.123.19 with SMTP id lw19mr44760135oeb.22.1407696589276; Sun, 10 Aug 2014 11:49:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.210.19 with HTTP; Sun, 10 Aug 2014 11:49:29 -0700 (PDT) In-Reply-To: References: From: Jamal Hadi Salim Date: Sun, 10 Aug 2014 14:49:29 -0400 Message-ID: To: "forces@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/1pRP4RBCUz0yRaoWD1CIKs3Im7s Subject: Re: [forces] Adoption of ForCES Inter-FE LFB X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2014 18:49:52 -0000 It turns out my message was a little confusing. The meeting decided on the current draft revision. In my post I indicated an upcoming version of the draft. I would prefer for it to be based on the next version. For that reason, I would like to withdraw the posting and wait until we issue the new update in the next weeks. Sorry about that. cheers, jamal On Sat, Aug 9, 2014 at 9:45 AM, Jamal Hadi Salim wrote: > As per meeting discussion, there was agreement to adopt > http://tools.ietf.org/html/draft-joachimpillai-forces-interfelfb-04 > as the WG document for the inter FE chartered work. > > If there are any objections or suggestions please raise them > on the list (dont send me or DJ private email). > Silence implies consent. > > I am actually re-factoring code of an earlier implementation > right now as we speak. Based on that we will publish the new WG document. > > cheers, > jamal From nobody Mon Aug 11 05:09:58 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5261A0670; Mon, 11 Aug 2014 05:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRBW7cXCgP3A; Mon, 11 Aug 2014 05:09:49 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187A41A066D; Mon, 11 Aug 2014 05:09:48 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id at20so9120260iec.8 for ; Mon, 11 Aug 2014 05:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TURpZVW3KQs9OnNiL9iLCvYAGO6t0WbaX/kfvMH8h+4=; b=mrPtKhxbHEKGx6+0nknvzN3RT4CR6GR2DE/9qyWQlnmWIwgHSAsFeZEddwzQ5t36GK grkRyyIpIypA321a1Af4OJPI4XhwEQK3NKmM5CQXs8N6PB4l4V//d8CyeBemgJ5udFb/ dwIIoN62CHzBxl1wr+/R5OlGuhFBiR0Byak5n77NqukBhxDJGvXI+R+otruRPKGKBONE wJO4zkWadkkQU7I0wkGyrrMHeBpUC4EY6wxR6osOYqmAbvIaHUoMqk59s4buYohjVwBZ R3YvkfN6uRN+Mfch2aJnFFo1qiclz89EiW6NLCSYS9FsS/tLRrJBNttUwlJBBywWsSFX GfDg== MIME-Version: 1.0 X-Received: by 10.50.43.225 with SMTP id z1mr28632490igl.17.1407758988371; Mon, 11 Aug 2014 05:09:48 -0700 (PDT) Received: by 10.107.7.211 with HTTP; Mon, 11 Aug 2014 05:09:48 -0700 (PDT) Received: by 10.107.7.211 with HTTP; Mon, 11 Aug 2014 05:09:48 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20140809074914.0d75d2d8@elandnews.com> References: <20140730195955.15689.21201.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140807225945.0cedd5e0@resistor.net> <6.2.5.6.2.20140808085335.0c04e2b0@elandnews.com> <6.2.5.6.2.20140808123121.0c41a5b8@elandnews.com> <04cb01cfb3bf$caff2d00$60fd8700$@olddog.co.uk> <6.2.5.6.2.20140809074914.0d75d2d8@elandnews.com> Date: Mon, 11 Aug 2014 08:09:48 -0400 Message-ID: From: Evangelos Haleplidis To: S Moonesamy Content-Type: multipart/alternative; boundary=089e010d8dd66e7aa10500596e31 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/I_F2U4Fm5w8V4WsP5jlGDoYGUYM Cc: forces@ietf.org, iesg@ietf.org, Evangelos Haleplidis Subject: Re: [forces] Last Call: (ForCES Protocol Extensions) to Proposed Standard X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 12:09:51 -0000 --089e010d8dd66e7aa10500596e31 Content-Type: text/plain; charset=UTF-8 Greetings, Apologies for the late reply but I'm currently in vacations and will be for another two weeks with tentative access and time to read emails. Regarding the shepherd writeup, I was, as Jamal noted, referring to the latest document version, where all of the issues that were controversial and were in fact challenged, specifically by Joel, removed. In hindsight, I should probably have included them in the writeup. But it was not an issue of A or B, rather of A or not A, and choosing not A to achieve consensus (Jamal did note that he was not actually happy with some of the removed items) Now in regards to consensus, after resolving these issues there was no more conflicts or objections, I thought that the wg did not object anymore to the new version, taken into account that these changes are small and make sense to be included in the protocol. With regards, Evangelos Haleplidis On Aug 9, 2014 8:10 PM, "S Moonesamy" wrote: > Hi Adrian, > At 03:50 09-08-2014, Adrian Farrel wrote: > >> Let me pick an email in the middle of the thread and then top-post :-) >> > > Ok. :-) > > I would prefer that in questions of whether there was consensus, the >> debate was addressed by the other WG chair (not the one who is an author of >> this document). >> I would prefer that questions about what the shepherd write-up says were >> addressed by the document shepherd. >> > > Ok. > > I think that the questions raised in this thread are valuable but need >> context. >> >> The Shepherd write-up is primarily a communication between the document >> shepherd and the responsible AD (me). I am capable of following up on >> issues that are unclear or seem like fudge. i can do that publically or >> privately. I can require that the write-up is updated or leave it fallow. >> Any passer-by who reads the write-up and has concerns can raise them to me >> or on the public list (as has happened). >> > > Ok. > > Shepherd write-ups do not call consensus nor should they claim consensus. >> They should report facts (what happened, what was seen on the list, etc.). >> I don't think you could appeal a shepherd write-up for what it says about >> consensus although you might make counter claims to the responsible AD. >> > > It would be very difficult to appeal a Shepherd write-up. For what it is > worth, it has never been done before. > > The ForCES working group is winding down and close to closing. It has a >> few more documents to push out and nearly all of the work has been done on >> these. Getting anything out of the working group at this stage beyond >> absence of dissent will be impractical. As AD I am choosing between: >> - shut the WG and have only ISE RFCs on ForCES >> - shut the WG and allow AD Sponsored RFCs on ForCES >> - let the WG wrap up what is in hand. >> I choose the latter for efficiency and best hope of document review. >> > > Ok. > > Regards, > S. Moonesamy > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces > --089e010d8dd66e7aa10500596e31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Greetings,

Apologies for the late reply but I'm currently in vacati= ons and will be for another two weeks with tentative access and time to rea= d emails.

Regarding the shepherd writeup, I was, as Jamal noted, refer= ring to the latest document version, where all of the issues that were cont= roversial and were in fact challenged, specifically by Joel, removed. In hi= ndsight, I should probably have included them in the writeup. But it was no= t an issue of A or B, rather of A or not A, and choosing not A to achieve c= onsensus (Jamal did note that he was not actually happy with some of the re= moved items)

Now in regards to consensus,=C2=A0 after resolving these iss= ues there was no more conflicts or objections, I thought that the wg did no= t object anymore to the new version, taken into account that these changes = are small and make sense to be included in the protocol.

With regards,
Evangelos Haleplidis

On Aug 9, 2014 8:10 PM, "S Moonesamy" = <sm+ietf@elandsys.com> = wrote:

Hi Adrian,
At 03:50 09-08-2014, Adrian Farrel wrote:

Let me pick an email in the middle of the thread and then top-post :-)

Ok. :-)

I would prefer that in questions of whether there was consensus, the debate= was addressed by the other WG chair (not the one who is an author of this = document).
I would prefer that questions about what the shepherd write-up says were ad= dressed by the document shepherd.

Ok.

I think that the questions raised in this thread are valuable but need cont= ext.

The Shepherd write-up is primarily a communication between the document she= pherd and the responsible AD (me). I am capable of following up on issues t= hat are unclear or seem like fudge. i can do that publically or privately. = I can require that the write-up is updated or leave it fallow. Any passer-b= y who reads the write-up and has concerns can raise them to me or on the pu= blic list (as has happened).

Ok.

Shepherd write-ups do not call consensus nor should they claim consensus. T= hey should report facts (what happened, what was seen on the list, etc.). I= don't think you could appeal a shepherd write-up for what it says abou= t consensus although you might make counter claims to the responsible AD.

It would be very difficult to appeal a Shepherd write-up. =C2=A0For what it= is worth, it has never been done before.

The ForCES working group is winding down and close to closing. It has a few= more documents to push out and nearly all of the work has been done on the= se. Getting anything out of the working group at this stage beyond absence = of dissent will be impractical. As AD I am choosing between:
- shut the WG and have only ISE RFCs on ForCES
- shut the WG and allow AD Sponsored RFCs on ForCES
- let the WG wrap up what is in hand.
I choose the latter for efficiency and best hope of document review.

Ok.

Regards,
S. Moonesamy
_______________________________________________
forces mailing list
forces@ietf.org = https://www.ietf.org/mailman/listinfo/forces

--089e010d8dd66e7aa10500596e31-- From nobody Mon Aug 18 15:59:02 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292081A0022; Mon, 18 Aug 2014 15:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v_9kms_NxuP; Mon, 18 Aug 2014 15:58:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 151F01A000A; Mon, 18 Aug 2014 15:58:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140818225855.18343.21570.idtracker@ietfa.amsl.com> Date: Mon, 18 Aug 2014 15:58:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/CdmZ94mQGpDzkAg_vUUnrRrylXA Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-protoextension-05.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 22:58:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : ForCES Protocol Extensions Author : Jamal Hadi Salim Filename : draft-ietf-forces-protoextension-05.txt Pages : 24 Date : 2014-08-18 Abstract: Experience in implementing and deploying ForCES architecture has demonstrated need for a few small extensions both to ease programmability and to improve wire efficiency of some transactions. This documents updates both RFC 5810 and RFC 7121 semantics to achieve that end goal. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-protoextension/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-protoextension-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-forces-protoextension-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 21 15:20:37 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A781A048F; Thu, 21 Aug 2014 15:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egqNK2We84bC; Thu, 21 Aug 2014 15:20:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3ACC1A0B0E; Thu, 21 Aug 2014 15:20:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140821222027.28156.26471.idtracker@ietfa.amsl.com> Date: Thu, 21 Aug 2014 15:20:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/forces/oYkKosccCrCj8mT6LHaX-Fr8muQ Cc: forces@ietf.org Subject: [forces] I-D Action: draft-ietf-forces-model-extension-04.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 22:20:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Forwarding and Control Element Separation Working Group of the IETF. Title : ForCES Model Extension Author : Evangelos Haleplidis Filename : draft-ietf-forces-model-extension-04.txt Pages : 30 Date : 2014-08-21 Abstract: Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES Network Element (ForCES NE). RFC5812 has defined the ForCES Model that provides a formal way to represent the capabilities, state, and configuration of forwarding elements within the context of the ForCES protocol, so that control elements (CEs) can control the FEs accordingly. More specifically, the model describes the logical functions that are present in a forwarding element (FE), what capabilities these functions support, and how these functions are or can be interconnected. RFC5812 has been around for two years and experience in its use has shown room for small extensions without a need to alter the protocol while retaining backward compatibility with older xml libraries. This document updates RFC5812 and extends the model to allow complex datatypes for metadata, optional default values for datatypes, optional access types for structures and fixes an issue with Logical Functional Block (LFB) inheritance. The document also introduces two new features a new event condition BecomesEqualTo and LFB properties. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-forces-model-extension/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-forces-model-extension-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-forces-model-extension-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 21 15:31:27 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950EC1A0B74 for ; Thu, 21 Aug 2014 15:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pG1k2_k2kTKK for ; Thu, 21 Aug 2014 15:31:23 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F67B1A0719 for ; Thu, 21 Aug 2014 15:31:23 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so9744322wgh.29 for ; Thu, 21 Aug 2014 15:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=aQneD19T8w+W0PYpbB1USqa04vnWIGHeeWlhw9aOeuo=; b=IvG+nmjHOjy1mEskMD13p4sZNwARHv1aceGkvzP4gLlQAWtmsGeVt0iM+Ht9eDdXsJ wfIb1/UbrQR0R7jxqZIu3BSEB12ca9fVd0mPehiEJyUnWF6yc790ytW+WwZaMNlNToPJ S/LMCRwG/QkqWEnxI4XS99lSOheaNEYJbumNjNJTBctiOc407pFt3CdBu8S2IgC5EVBl pqrlVk9uuxH2DP8yrEZ1Ts8V0l2A/nesJi1pscuFcTy5Z/O4BawC+IGwgoLBXyfXQPa0 AklLiutSi2JKvXLoc/pXcnNl9oEh3F60+qObT1Smkqsz9fk216axnAdBfZ7FtxCufvjl yoog== X-Received: by 10.180.84.165 with SMTP id a5mr3523580wiz.40.1408660282050; Thu, 21 Aug 2014 15:31:22 -0700 (PDT) Received: from EhalepXPS ([150.140.255.138]) by mx.google.com with ESMTPSA id eb4sm24330106wic.16.2014.08.21.15.31.19 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Aug 2014 15:31:21 -0700 (PDT) From: "Haleplidis Evangelos" To: References: <20140821222027.28156.26471.idtracker@ietfa.amsl.com> In-Reply-To: <20140821222027.28156.26471.idtracker@ietfa.amsl.com> Date: Fri, 22 Aug 2014 01:31:22 +0300 Message-ID: <008301cfbd8f$a5042900$ef0c7b00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+9jiTzzJ6DJkeUR2+2LaoHq4Qc5AAAOjFg Content-Language: el Archived-At: http://mailarchive.ietf.org/arch/msg/forces/vv8kn8vQuioYnTyg-M7WzXd_OS4 Subject: Re: [forces] I-D Action: draft-ietf-forces-model-extension-04.txt X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 22:31:25 -0000 Greetings to the list, This is an update on the model extension draft, based on the excellent review from Ben Campbell (Gen-Art reviewer). This new draft addressed all comments that needed to be addressed. Regards, Evangelos Haleplidis. > -----Original Message----- > From: forces [mailto:forces-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, August 22, 2014 1:20 AM > To: i-d-announce@ietf.org > Cc: forces@ietf.org > Subject: [forces] I-D Action: draft-ietf-forces-model-extension-04.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Forwarding and Control Element > Separation Working Group of the IETF. > > Title : ForCES Model Extension > Author : Evangelos Haleplidis > Filename : draft-ietf-forces-model-extension-04.txt > Pages : 30 > Date : 2014-08-21 > > Abstract: > Forwarding and Control Element Separation (ForCES) defines an > architectural framework and associated protocols to standardize > information exchange between the control plane and the forwarding > plane in a ForCES Network Element (ForCES NE). RFC5812 has defined > the ForCES Model that provides a formal way to represent the > capabilities, state, and configuration of forwarding elements within > the context of the ForCES protocol, so that control elements (CEs) > can control the FEs accordingly. More specifically, the model > describes the logical functions that are present in a forwarding > element (FE), what capabilities these functions support, and how > these functions are or can be interconnected. > > RFC5812 has been around for two years and experience in its use has > shown room for small extensions without a need to alter the protocol > while retaining backward compatibility with older xml libraries. > This document updates RFC5812 and extends the model to allow complex > datatypes for metadata, optional default values for datatypes, > optional access types for structures and fixes an issue with Logical > Functional Block (LFB) inheritance. The document also introduces > two > new features a new event condition BecomesEqualTo and LFB > properties. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-forces-model-extension/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-forces-model-extension-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-forces-model-extension-04 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > forces mailing list > forces@ietf.org > https://www.ietf.org/mailman/listinfo/forces From nobody Mon Aug 25 15:31:09 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AAF01A03F3 for ; Mon, 25 Aug 2014 15:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2NIkatb_3up for ; Mon, 25 Aug 2014 15:31:04 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8596D1A03F0 for ; Mon, 25 Aug 2014 15:31:02 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7PMV0o5011978; Mon, 25 Aug 2014 23:31:00 +0100 Received: from 950129200 ([66.129.246.4]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id s7PMUvvb011949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Aug 2014 23:30:59 +0100 From: "Adrian Farrel" To: Date: Mon, 25 Aug 2014 23:30:57 +0100 Message-ID: <055001cfc0b4$3f3b2240$bdb166c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/AtDtozAT+vPO+T8OhbRWTyCRa9w== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20906.002 X-TM-AS-Result: No--12.364-10.0-31-10 X-imss-scan-details: No--12.364-10.0-31-10 X-TMASE-MatchedRID: 5jrCzlkkxksmMPeO88gK4MRS0pbiOfKb1Ga2L87qPQLIvQIyugvKdS7s reQJNnc7J6qGh86ry3Rf5o2DgzRHJqfKQy6fQnXCW7gz/Gbgpl4ZbpN+hw0KeybWR/bc1Fpu7dY Ge1mPXuclwVsmr/YIwUJ0IOaBXZ9CaXCfGZQxX8UP+h/WmwyDER9fNWA7SFWqCTU081fTUYJYHU JOS1uh7gAOLcBDJ5DFov5NxY7uq93C5KNFPL+ydH9NanCUA4Veu56wFPSkMVFb8pv4L0h+Iqotg acS0y4ttMYCdshxeH7cJrW3ohVKce+Tp/XbD9PcSEQN/D/3cG4KTXXD5Aduy+mGwXz0UoMoo8WM kQWv6iV95l0nVeyiuDrm2CwlZwVRIAcCikR3vq8t26D+bss0Y7tyG6giJSq4hjz7g4UoY7Ycqi5 YV+/9hcw+CP4d1ZfG Archived-At: http://mailarchive.ietf.org/arch/msg/forces/qinoH46Ad4Go8OxpjWUgOCnAhHQ Cc: forces@ietf.org Subject: [forces] AD review of draft-ietf-forces-packet-parallelization X-BeenThere: forces@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: ForCES WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 22:31:06 -0000 Hi authors, I have done my usual AD review on receiving a publication request for your draft. I have a question, a request, and a suggestion. I'll put the document into "Revised I-D" state until we have resolved these issues. Thanks for the work, Adrian --- Is this really standards track and not experimental? The reason I ask is because it sounds (to me) that packet parallelization is quite an advanced feature that may have some "interesting" behavioral characteristics. If you tell me that, "this is stable, we know what we are doing, the implementations that exist are really being deployed" then I'll be happy. If you say "we have an implementation and are seeing how it behaves" then perhaps you should consider whether this is an experiment. This is a topic for discussion. You don't have to make a change until we have covered the ground and understand what we are dealing with. --- The IANA Considerations section needs some work. Please: - Name the registries where you are requesting code points. - Please request allocations (i.e. don't write descriptive text) - the values you are asking for appear to come from the Standards Action space: why mention FCFS? - Do you *need* the values you are asking for (18-20 and x10), are you suggesting them, or do you not actually care? You need to make this clear in your text. --- Some comments from the document shepherd are recorded in the write-up and should get some attention from the authors. Additionally, there is some English that could benefit from a quick re-read and some polish. From nobody Fri Aug 29 15:54:24 2014 Return-Path: X-Original-To: forces@ietfa.amsl.com Delivered-To: forces@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839961A0705 for ; Fri, 29 Aug 2014 15:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ym0NzsPa2rJd for ; Fri, 29 Aug 2014 15:54:21 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55C11A003A for ; Fri, 29 Aug 2014 15:54:20 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u57so2824358wes.5 for ; Fri, 29 Aug 2014 15:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=HpAsH5VkNo1MldrTspu1JQdwfkaXCjRz4F3qBxWJB5k=; b=AW37BrJx5BLIUZIKfWm6Cp8NQGdq1JrwBrehKq79jy9mY+YnrISQ9e1R20dapcJJiL O3R111D3+lpIX1PLaGS7bX1eZ3/ipFCmwCln+5Vl/FPHDyXIZd5EqLiZQh1/ezZ7h2+y xcm0HenNlIUiMyvk1bbCV2mZ9rJTGjm2XqRSO9W7igMulxNm3hRwzxGmj3w0jTptT4zl NnCzPrGWrEA/XMNr8IK3phI/oxnj9MlgmPxHbbts6OCAIx5Rsy90sQKIzu7VX7MFOBIi OjOGmq1f78drdGJbdkKESkiD3nSdDFHwt0v8U+QKvjnD7KDj3q2eI6aLnkANUqZLcPi7 mwAg== X-Received: by 10.180.12.239 with SMTP id b15mr6684198wic.75.1409352859531; Fri, 29 Aug 2014 15:54:19 -0700 (PDT) Received: from EhalepXPS ([213.249.12.91]) by mx.google.com with ESMTPSA id hm5sm3164114wjb.2.2014.08.29.15.54.15 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 29 Aug 2014 15:54:18 -0700 (PDT) From: "Haleplidis Evangelos" To: ,