IETF Logo Mail Archive

Re: [MBONED] Ben Campbell's No Objection on draft-ietf-mboned-mtrace-v2-22: (with COMMENT)

Ben Campbell <ben@nostrum.com> Thu, 25 January 2018 05:08 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F82D12D775; Wed, 24 Jan 2018 21:08:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 LTBOSEtuDBVH; Wed, 24 Jan 2018 21:08:56 -0800 (PST)
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 57C1B124B17; Wed, 24 Jan 2018 21:08:56 -0800 (PST)
Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0P58pVf075710 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 Jan 2018 23:08:52 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <3EF565B7-7CDE-40E4-B8E4-B6186360F8B9@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_7539DB45-3867-42F5-906F-14D91908F57A"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 24 Jan 2018 23:08:50 -0600
In-Reply-To: <266F15CD-B02D-4C95-876F-1AFF72815D9E@ieee.org>
Cc: draft-ietf-mboned-mtrace-v2@ietf.org, mboned@ietf.org, mboned-chairs@ietf.org, The IESG <iesg@ietf.org>
To: Hitoshi Asaeda <asaeda@ieee.org>
References: <151676024609.24084.1626968972000954311.idtracker@ietfa.amsl.com> <266F15CD-B02D-4C95-876F-1AFF72815D9E@ieee.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/73BrAX09Ezou9FZrwpXiKMFwnoY>
Subject: Re: [MBONED] Ben Campbell's No Objection on draft-ietf-mboned-mtrace-v2-22: (with COMMENT)
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2018 05:08:58 -0000


> On Jan 24, 2018, at 8:25 PM, Hitoshi Asaeda <asaeda@ieee.org> wrote:
> 
> Hi Ben,
> 
> Thanks for your review and comments.
> 
>> 2018/01/24 11:17, Ben Campbell <ben@nostrum.com> wrote:
>> 
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-mboned-mtrace-v2-22: 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-mboned-mtrace-v2/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> -3.1. Length: "Length SHOULD NOT exceed the available MTU"
>> How does that interact with the previous "MUST NOT be fragmented" requirement?
> 
> If the length exceeds the available MTU, the packet is considered invalid and is discarded. This sounds “SHOULD NOT”, and it is done in accordance with the requirement that the packet MUST NOT be fragmented.

I guess my confusion is that these two requirements seem like opposite sides of the same coin, so it seems odd for them to be at different requirement levels. Can you envision situations where it might make sense to violate the SHOULD NOT?

> 
>> -2: There are lower case versions of the 2119 keywords. Unless those were meant
>> to be capitalized, please consider using the boilerplate from 8174.
> 
> Yes, we’ll do for the next revision. Thanks.
> 
> Best regards,
> --
> Hitoshi Asaeda
> 
> 
> 
>

v2.23.0 | Report a Bug | By Email