From nobody Wed Aug 5 06:23:21 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310481A1B6B; Wed, 5 Aug 2015 06:23:18 -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 KBehF24jdj_j; Wed, 5 Aug 2015 06:23:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 425B91A7023; Wed, 5 Aug 2015 06:23:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150805132314.30819.60042.idtracker@ietfa.amsl.com> Date: Wed, 05 Aug 2015 06:23:14 -0700 Archived-At: Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-destopt-09.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 13:23:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion Exposure Working Group of the IETF. Title : IPv6 Destination Option for Congestion Exposure (ConEx) Authors : Suresh Krishnan Mirja Kuehlewind Carlos Ralli Ucendo Filename : draft-ietf-conex-destopt-09.txt Pages : 12 Date : 2015-08-05 Abstract: Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-conex-destopt-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-conex-destopt-09 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 6 02:37:03 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070031B2B47; Thu, 6 Aug 2015 02:37:02 -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 2VR5iKV6KGK7; Thu, 6 Aug 2015 02:37:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 121D11B2B4D; Thu, 6 Aug 2015 02:36:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.3.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150806093659.27851.37172.idtracker@ietfa.amsl.com> Date: Thu, 06 Aug 2015 02:36:59 -0700 Archived-At: Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-tcp-modifications-09.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 09:37:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion Exposure Working Group of the IETF. Title : TCP modifications for Congestion Exposure Authors : Mirja Kuehlewind Richard Scheffenegger Filename : draft-ietf-conex-tcp-modifications-09.txt Pages : 20 Date : 2015-08-06 Abstract: Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-tcp-modifications/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-conex-tcp-modifications-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-conex-tcp-modifications-09 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 Mon Aug 17 10:30:40 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0987A1ACD9C; Mon, 17 Aug 2015 10:30:38 -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, 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 C-z74v6UXBaO; Mon, 17 Aug 2015 10:30:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C521ACD71; Mon, 17 Aug 2015 10:30:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150817173035.15286.4084.idtracker@ietfa.amsl.com> Date: Mon, 17 Aug 2015 10:30:35 -0700 Archived-At: Cc: conex@ietf.org Subject: [conex] Last Call: (IPv6 Destination Option for Congestion Exposure (ConEx)) to Experimental RFC X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 17:30:38 -0000 The IESG has received a request from the Congestion Exposure WG (conex) to consider the following document: - 'IPv6 Destination Option for Congestion Exposure (ConEx)' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-08-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Congestion Exposure (ConEx) is a mechanism by which senders inform the network about the congestion encountered by packets earlier in the same flow. This document specifies an IPv6 destination option that is capable of carrying ConEx markings in IPv6 datagrams. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1922/ From nobody Mon Aug 17 10:31:19 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3D91ACDB9; Mon, 17 Aug 2015 10:31:16 -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, 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 CSOCMh1xFzsL; Mon, 17 Aug 2015 10:31:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C85CA1ACD7B; Mon, 17 Aug 2015 10:31:14 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150817173114.19852.60397.idtracker@ietfa.amsl.com> Date: Mon, 17 Aug 2015 10:31:14 -0700 Archived-At: Cc: conex@ietf.org Subject: [conex] Last Call: (TCP modifications for Congestion Exposure) to Experimental RFC X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 17:31:16 -0000 The IESG has received a request from the Congestion Exposure WG (conex) to consider the following document: - 'TCP modifications for Congestion Exposure' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-08-31. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-conex-tcp-modifications/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-conex-tcp-modifications/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1922/ From nobody Thu Aug 20 01:10:03 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F0F1A6F0A; Thu, 20 Aug 2015 01:10:01 -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 VHNFx0yFVXsW; Thu, 20 Aug 2015 01:10:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 537C31A212A; Thu, 20 Aug 2015 01:10:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150820081000.20922.90763.idtracker@ietfa.amsl.com> Date: Thu, 20 Aug 2015 01:10:00 -0700 Archived-At: Cc: conex@ietf.org Subject: [conex] I-D Action: draft-ietf-conex-mobile-05.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 08:10:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion Exposure Working Group of the IETF. Title : Mobile Communication Congestion Exposure Scenario Authors : Dirk Kutscher Faisal Ghias Mir Rolf Winter Suresh Krishnan Ying Zhang Carlos J. Bernardos Filename : draft-ietf-conex-mobile-05.txt Pages : 25 Date : 2015-08-20 Abstract: This memo describes a mobile communications use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally similar to the 3GPP Evolved Packet System (EPS). The draft provides a brief overview of the architecture of these networks (both access and core networks), current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this, this memo suggests a set of requirements for ConEx mechanisms that particularly apply to these mobile networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-conex-mobile/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-conex-mobile-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-conex-mobile-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 20 07:34:57 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257951ACE32; Thu, 20 Aug 2015 07:34:56 -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, 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 NKQfyCKAuxzC; Thu, 20 Aug 2015 07:34:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA67E1ACE6C; Thu, 20 Aug 2015 07:34:53 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150820143453.9898.27495.idtracker@ietfa.amsl.com> Date: Thu, 20 Aug 2015 07:34:53 -0700 Archived-At: Cc: conex@ietf.org Subject: [conex] Last Call: (Mobile Communication Congestion Exposure Scenario) to Informational RFC X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 14:34:56 -0000 The IESG has received a request from the Congestion Exposure WG (conex) to consider the following document: - 'Mobile Communication Congestion Exposure Scenario' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-09-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes a mobile communications use case for congestion exposure (ConEx) with a particular focus on those mobile communication networks that are architecturally similar to the 3GPP Evolved Packet System (EPS). The draft provides a brief overview of the architecture of these networks (both access and core networks), current QoS mechanisms and then discusses how congestion exposure concepts could be applied. Based on this, this memo suggests a set of requirements for ConEx mechanisms that particularly apply to these mobile networks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-conex-mobile/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-conex-mobile/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/1922/ From nobody Wed Aug 26 13:20:00 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390341B3246; Wed, 26 Aug 2015 13:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 hWXKkrH1AtsB; Wed, 26 Aug 2015 13:19:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D6F31B3245; Wed, 26 Aug 2015 13:19:55 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7QKJsgT078660 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 26 Aug 2015 15:19:55 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <55DE1F65.5070106@nostrum.com> Date: Wed, 26 Aug 2015 15:19:49 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: General Area Review Team , draft-ietf-conex-destopt@ietf.org, "ietf@ietf.org" , conex@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [conex] Gen-art LC review: draft-ietf-conex-destopt-09 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 20:19:57 -0000 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-conex-destopt-09 Reviewer: Robert Sparks Review Date: 26 Aug 2015 IETF LC End Date: 31 Aug 2015 IESG Telechat date: 1 Oct 2015 Summary: On the right track with open issues Major issues: M1) This document claims to specify "the ConEx wire protocol in IPv6". But it reads more like "this document just defines an option, other documents will talk about how and when the option is used". The abstract-mech document requires that concrete ConEx specifications discuss the audit function explicitly, with several requirements for detail scattered through that document. In particular, it asks for a discussion of how the concrete protocol defends against a set of likely attacks against the audit function. This document is silent, and I think a side-effect of being processed in parallel with tcp-modifications, and suspect most of the thinking on meeting the requirements for discussing the audit function has concentrated there. However, nothing in _this_ document restricts its use to other transport extensions that have talked about these things. Should there be a statement that this option must not be used unless by a transport extension that's discussed how to use it? If not, then shouldn't this document talk about what happens if there's no transport header below to inform audit function behavior? Minor issues: m1) Figure 1 isn't right. I think what you want is: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length |X|L|E|C| res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ m2) There is confusion in two places in the document where you discuss where to put the CDO (at the end of page 5 and the end of page 7). The current text says the option MUST be the first option in whatever destination options block it appears in. That seems problematic. What if some other option also declares it MUST be the first option? I wonder if instead of trying to say "must be the first option in the block" you are trying only to say "If you use a CDO, use it in the destination options block that comes before an AH block, not the one that might come after". m3) Third paragraph of section 6: Should the last sentence end with "in a given stream." ? Nits/editorial comments: Introduction: Should "Due to space limitation" be "Due to space limitations in the IPV4 header"? Section 4: Right after the definition of Reserved, there is a line that says "foo". What should it say instead? The last sentence on page 6: I don't think it's the network node that you are saying must be aware. Perhaps you mean designers of network nodes? At the top of page 7, you have "They MAY log". You shouldn't use a 2119 MAY here - it's not part of the protocol. Similarly, in section 6, "MAY compare the two, and MAY log" should not use 2119. First paragraph of section 6: "natively" is not clear. Perhaps replacing "will not natively copy" with "will not normally copy"? Second paragraph of section 6: I suggest replacing "ignore any CDO" with "ignore any CDO in the outer header". Consider moving the description of the bits in the option type field, particularly the chg bit, earlier in the document. Right now, the first mention is in the security consideration section, and most of the definition doesn't happen until the IANA considerations. It would help if it were clear what that bit was going to be before you ever mention AH. From nobody Wed Aug 26 19:56:37 2015 Return-Path: X-Original-To: conex@ietfa.amsl.com Delivered-To: conex@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9951ACDE6; Wed, 26 Aug 2015 19:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ESkN89JB9s2A; Wed, 26 Aug 2015 19:56:31 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25FDA1A8A8B; Wed, 26 Aug 2015 19:56:31 -0700 (PDT) X-AuditID: c6180641-f792c6d00000686a-bb-55de127f0fef Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id DF.B7.26730.F721ED55; Wed, 26 Aug 2015 21:24:47 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0210.002; Wed, 26 Aug 2015 22:56:29 -0400 From: Suresh Krishnan To: Robert Sparks , General Area Review Team , "draft-ietf-conex-destopt@ietf.org" , "ietf@ietf.org" , "conex@ietf.org" Thread-Topic: Gen-art LC review: draft-ietf-conex-destopt-09 Thread-Index: AQHQ4DyWm48WNKikiUGJlz4OFxxbqw== Date: Thu, 27 Aug 2015 02:56:29 +0000 Message-ID: References: <55DE1F65.5070106@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyuXRPuG690L1Qg2VzpS0OXfvJaNG9+he7 xdVXn1ksnm2cz2JxbU4jmwOrx5IlP5k8Zu18whLAFMVlk5Kak1mWWqRvl8CV0bNCpaBTt6J3 wwa2BsZJKl2MnBwSAiYSS+fcZYGwxSQu3FvP1sXIxSEkcJRR4tner8wQznJGie51HUwgVWxA HRt2fgazRQReMEq8eh8FYgsLWEvMnvuEDSJuIzFx5k9GCFtPYuPft2BxFgFVibtHT4DZvAK+ Es/WvQKzhQS0JJoPLAa7ghHoiu+n1oDNZxYQl7j1ZD4TxHUCEkv2nGeGsEUlXj7+xwphK0nM eX2NGaJeR2LB7k9sELa2xLKFr5khdglKnJz5hGUCo8gsJGNnIWmZhaRlFpKWBYwsqxg5SotT y3LTjQw3MQJj4pgEm+MOxgWfLA8xCnAwKvHwLvh3N1SINbGsuDL3EKM0B4uSOK+0X16okEB6 YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbCGA8HVg3+DWaPDG7OVj12wdDk16+PW+++bpmTdPR3 Vv7yLQc/M7inVDxm4J13YW/kIUG9R9ucX23ReilbfffItwU+fDITMu98PleTu2RpwXtbgxXO 89znT4mL2y+7Vl3ywtOidR7sborai77W9bG/lH/ieYJBwLWQR/JBoeqDYGGXlqlrZ3kpsRRn JBpqMRcVJwIAapsBi2oCAAA= Archived-At: Subject: Re: [conex] Gen-art LC review: draft-ietf-conex-destopt-09 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 02:56:33 -0000 Hi Robert,=0A= Thanks a lot for your careful review. Please find responses inline.=0A= =0A= On 08/26/2015 04:20 PM, Robert Sparks wrote:=0A= > I am the assigned Gen-ART reviewer for this draft. The General Area=0A= > Review Team (Gen-ART) reviews all IETF documents being processed=0A= > by the IESG for the IETF Chair. Please treat these comments just=0A= > like any other last call comments.=0A= >=0A= > For more information, please see the FAQ at=0A= >=0A= > .=0A= >=0A= > Document: draft-ietf-conex-destopt-09=0A= > Reviewer: Robert Sparks=0A= > Review Date: 26 Aug 2015=0A= > IETF LC End Date: 31 Aug 2015=0A= > IESG Telechat date: 1 Oct 2015=0A= >=0A= > Summary: On the right track with open issues=0A= >=0A= > Major issues:=0A= >=0A= > M1) This document claims to specify "the ConEx wire protocol in IPv6".=0A= > But it reads more like "this document just defines an option, other=0A= > documents will talk about how and when the option is used". The=0A= > abstract-mech document requires that concrete ConEx specifications=0A= > discuss the audit function explicitly, with several requirements for=0A= > detail scattered through that document. In particular, it asks for a=0A= > discussion of how the concrete protocol defends against a set of=0A= > likely attacks against the audit function. This document is silent,=0A= > and I think a side-effect of being processed in parallel with=0A= > tcp-modifications, and suspect most of the thinking on meeting the=0A= > requirements for discussing the audit function has concentrated there.=0A= > However, nothing in _this_ document restricts its use to other=0A= > transport extensions that have talked about these things. Should=0A= > there be a statement that this option must not be used unless by a=0A= > transport extension that's discussed how to use it? If not, then=0A= > shouldn't this document talk about what happens if there's no=0A= > transport header below to inform audit function behavior?=0A= =0A= I will let Mirja take this one as she had some extensive discussions =0A= about the audit functionalities in the wg phase.=0A= =0A= >=0A= >=0A= > Minor issues:=0A= >=0A= > m1) Figure 1 isn't right. I think what you want is:=0A= >=0A= > 0 1 2=0A= > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4=0A= > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= > | Option Type | Option Length |X|L|E|C| res |=0A= > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= Will fix it. Not only that, I just noticed that the whole draft seems to = =0A= be off in the formatting department including left justified titles and =0A= a left justified third author. My locally rendered copy looks more =0A= normal with the figure rendered like in version -08.=0A= =0A= >=0A= > m2) There is confusion in two places in the document where you discuss=0A= > where to put the CDO (at the end of page 5 and the end of page 7). The=0A= > current text says the option MUST be the first option in whatever=0A= > destination options block it appears in. That seems problematic. What=0A= > if some other option also declares it MUST be the first option? I=0A= > wonder if instead of trying to say "must be the first option in the=0A= > block" you are trying only to say "If you use a CDO, use it in the=0A= > destination options block that comes before an AH block, not the one=0A= > that might come after".=0A= =0A= Will fix.=0A= =0A= >=0A= > m3) Third paragraph of section 6: Should the last sentence end with=0A= > "in a given stream." ?=0A= =0A= It should be more like "for a given set of tunnel endpoints".=0A= =0A= >=0A= > Nits/editorial comments:=0A= >=0A= > Introduction: Should "Due to space limitation" be "Due to space=0A= > limitations in the IPV4 header"?=0A= =0A= Yes. Will clarify.=0A= =0A= >=0A= > Section 4: Right after the definition of Reserved, there is a line=0A= > that says "foo". What should it say instead?=0A= =0A= Nothing. Looks like this was a typo introduced in -09.=0A= =0A= >=0A= > The last sentence on page 6: I don't think it's the network node that=0A= > you are saying must be aware. Perhaps you mean designers of network=0A= > nodes?=0A= =0A= It should be the auditor instead. Will fix.=0A= =0A= >=0A= > At the top of page 7, you have "They MAY log". You shouldn't use a=0A= > 2119 MAY here - it's not part of the protocol.Similarly, in section=0A= > 6, "MAY compare the two, and MAY log" should not use 2119.=0A= =0A= In case other bits are added in the future, these log entries can signal = =0A= the admins to take a closer look. In the second case we are using it to =0A= say the decapsulators are not required to do this but they can if they =0A= want to. Can you clarify a bit why you think this is not appropriate =0A= usage of RFC2119 language?=0A= =0A= >=0A= > First paragraph of section 6: "natively" is not clear. Perhaps=0A= > replacing "will not natively copy" with "will not normally copy"?=0A= =0A= Sounds good.=0A= =0A= >=0A= > Second paragraph of section 6: I suggest replacing "ignore any=0A= > CDO" with "ignore any CDO in the outer header".=0A= =0A= Sounds good.=0A= =0A= >=0A= > Consider moving the description of the bits in the option type field,=0A= > particularly the chg bit, earlier in the document. Right now, the=0A= > first mention is in the security consideration section, and most=0A= > of the definition doesn't happen until the IANA considerations.=0A= > It would help if it were clear what that bit was going to be before=0A= > you ever mention AH.=0A= =0A= Will do.=0A= =0A= Thanks=0A= Suresh=0A= =0A=