[conex] Benoit Claise's No Objection on draft-ietf-conex-destopt-09: (with COMMENT)
"Benoit Claise" <bclaise@cisco.com> Thu, 01 October 2015 10:13 UTC
Return-Path: <bclaise@cisco.com>
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 7E40E1A1B2D; Thu, 1 Oct 2015 03:13:44 -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 TUjiAE7r7Kpd; Thu, 1 Oct 2015 03:13:43 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9221A1B25; Thu, 1 Oct 2015 03:13:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benoit Claise <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.4.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151001101343.18866.3379.idtracker@ietfa.amsl.com>
Date: Thu, 01 Oct 2015 03:13:43 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/conex/sux7zxu_SYsPIWsdwPszm7njJxw>
Cc: draft-ietf-conex-destopt.ad@ietf.org, sob@harvard.edu, conex@ietf.org, conex-chairs@ietf.org, draft-ietf-conex-destopt@ietf.org
Subject: [conex] Benoit Claise's No Objection on draft-ietf-conex-destopt-09: (with COMMENT)
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/conex/>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2015 10:13:44 -0000
Benoit Claise has entered the following ballot position for draft-ietf-conex-destopt-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-conex-destopt/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As mentiond by Scott in his OPS-DIR review: As an experiment this should have few operational concerns for any network not involved in the experiment but if the technology becomes standardized at some later time it will add somewhat to the complexity of configuring network devices (i.e. routers). Bottom line, technology-wise this ID seems ready to publish. But I do have some comments on the use of rfc 2119 terminology in the ID. I do not think I’ve seen a case where a document says SHOULD NOT and MAY in the same paragraph referring to the same thing: As with any destination option, an ingress tunnel endpoint will not natively copy the CDO when adding an encapsulating outer IP header. In general an ingress tunnel SHOULD NOT copy the CDO to the outer header as this would changed the number of bytes that would be counted. However, it MAY copy the CDO to the outer header in order to facilitate visibility by subsequent on-path ConEx functions if the configuration of the tunnel ingress and the ConEx nodes is co- ordinated. This trades off the performance of ConEx functions against that of tunnel processing. I suggest that this be reworded to say something like “SHOULD NOT unless xxx, in which case it MAY xxx” The next paragraph says An egress tunnel endpoint SHOULD ignore any CDO on decapsulation of an outer IP header. The information in any inner CDO will always be considered correct, even if it differs from any outer CDO. Therefore, the decapsulator can strip the outer CDO without comparison to the inner. Why is this a SHOULD rather than a MUST? imo, SHOULDs should only be used when there is a known reason that an otherwise MUST behavior might not be followed – in that case the reason should be explained
- [conex] Benoit Claise's No Objection on draft-iet… Benoit Claise