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

Hitoshi Asaeda <asaeda@ieee.org> Thu, 25 January 2018 05:51 UTC

Return-Path: <asaeda@ieee.org>
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 0FF1F120713 for <mboned@ietfa.amsl.com>; Wed, 24 Jan 2018 21:51:08 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.com
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 MHBmU7rBieCL for <mboned@ietfa.amsl.com>; Wed, 24 Jan 2018 21:51:06 -0800 (PST)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 95739129C6E for <mboned@ietf.org>; Wed, 24 Jan 2018 21:51:03 -0800 (PST)
Received: by mail-pg0-x22d.google.com with SMTP id n17so4419603pgf.10 for <mboned@ietf.org>; Wed, 24 Jan 2018 21:51:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3ucg1DqYxSoArqQlpzp2a+yqB9aWifz0J7eGF3Mokyo=; b=CWyqLhK03T71yBKjVg7od7fEIUY/V8gaY2oDltr2NHXQJCK8GytmWI9ItGLBcj0jCs KVpavpp+MxkcdCa3hzI4OT1UBvkEO5LAioKtkqMlpJhS8VhFpAm2vVKNq2eVMaGJQsaa yyV/3sc9g3Zm8sOoO2dG2iqk80PF5O/f9C8XP30x6p7EmRd/AlXEad+LN3WFIP+eOtmm 2RiWx4xBDKZYFRwyy25HsUYJ0m7pUHaKV3OGQ1OjiMSqQU6lXVofHyjjA7mTqVFR0jPp s/GZpJzxb2za62UU8Wk8r/JmxuSOEQpF9c7U104l0Wo1x+sQYI0Nl2Z3PteKQLBJ8Yi7 hmEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3ucg1DqYxSoArqQlpzp2a+yqB9aWifz0J7eGF3Mokyo=; b=kMfFQcZbNHAnVYRTuZTgz/Ql/V5l/X9/kIyqOMiODt5nrq/hxHNYljWmY/ul93AtDR gG+XA7cDf9Lgm3hDZIUeKewXr0KzhFdib9/uxWz1iLCmorC+o/C2ZJuY0QwounINJqxC D43kBxMA9uLu3RcrJlRqt87AwoKpqL/9K1MP8WtuMa6dj1VXP7LYLnMXt5eK9PxTS1vh nNlVQNl0Yw9NtwA9LWzWFqeczWs+zWr11gEPNj3VwyK7u77OpVsCFLJo5taLThuC0iIJ VMtY126ubMPUfg2UVOQg9aXeZY+hi/NPIASWJXcWV5ZidYrFKGPdRnjF2HivPySqIEHe BlsA==
X-Gm-Message-State: AKwxytd9EYrD7JRwdlb1W4fML8pfuFTrgxAEBkt+mEM/o1KGs0eP1YdS SiMKhPETchodmeEBbhYTDlXyoA==
X-Google-Smtp-Source: AH8x2249Rz5qSti86YKGV70r2x0xgz86RHLNYvDqNIVyvVdVih/g6gFH+OYtqWYxOkg/vc3IT55JZw==
X-Received: by 10.98.231.11 with SMTP id s11mr15064200pfh.174.1516859463035; Wed, 24 Jan 2018 21:51:03 -0800 (PST)
Received: from ?IPv6:2001:200:e103:1000:20be:bc0c:2388:b6af? ([2001:200:e103:1000:20be:bc0c:2388:b6af]) by smtp.gmail.com with ESMTPSA id i14sm2784136pgv.40.2018.01.24.21.51.01 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 24 Jan 2018 21:51:02 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Hitoshi Asaeda <asaeda@ieee.org>
In-Reply-To: <3EF565B7-7CDE-40E4-B8E4-B6186360F8B9@nostrum.com>
Date: Thu, 25 Jan 2018 14:51:00 +0900
Cc: draft-ietf-mboned-mtrace-v2@ietf.org, mboned@ietf.org, mboned-chairs@ietf.org, The IESG <iesg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EDB0F79F-2EEE-42FE-BAE8-6C24C26645EA@ieee.org>
References: <151676024609.24084.1626968972000954311.idtracker@ietfa.amsl.com> <266F15CD-B02D-4C95-876F-1AFF72815D9E@ieee.org> <3EF565B7-7CDE-40E4-B8E4-B6186360F8B9@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/LWwaA8MI6y3mE-yywtRx_rpx7J4>
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:51:08 -0000

Hi Ben,

> 2018/01/25 14:08, Ben Campbell <ben@nostrum.com> wrote:
> 
>> 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?

I see. Then, simply changing the sentence from
    "however the entire Mtrace2 packet length SHOULD NOT exceed the available MTU."
to
    "however the entire Mtrace2 packet length should not exceed the available MTU."
makes sense?

(Yes, we’ll consider 8174 in the revision entirely.)

>> 
>>> -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

Best regards,
--
Hitoshi Asaeda