Re: [tsvwg] Murray Kucherawy's No Objection on draft-ietf-tsvwg-datagram-plpmtud-17: (with COMMENT)

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 03 April 2020 07:10 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EC83A12B3; Fri, 3 Apr 2020 00:10:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 YvqOTD3xSGfb; Fri, 3 Apr 2020 00:10:04 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 433B23A12B0; Fri, 3 Apr 2020 00:10:03 -0700 (PDT)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 6504A1B003C3; Fri, 3 Apr 2020 08:09:52 +0100 (BST)
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tsvwg-datagram-plpmtud@ietf.org, tsvwg-chairs@ietf.org, tsvwg@ietf.org, Wesley Eddy <wes@mti-systems.com>
References: <158567197145.28499.17719634613395272227@ietfa.amsl.com> <48d8f4fa-2478-8200-c082-1d9f46b2530d@erg.abdn.ac.uk> <CAL0qLwaOOm6Btdi2wsO3TpdRxTmPaXkWy5Rn8YsoqiOOfkpd6Q@mail.gmail.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <3f73e422-a721-0865-35dc-3b64dd153d9f@erg.abdn.ac.uk>
Date: Fri, 3 Apr 2020 08:09:51 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <CAL0qLwaOOm6Btdi2wsO3TpdRxTmPaXkWy5Rn8YsoqiOOfkpd6Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------B05FA71B310796D6D4ED1E67"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/8C5Ntv-4qR3PXDTyoCV-eDV2kyE>
Subject: Re: [tsvwg] Murray Kucherawy's No Objection on draft-ietf-tsvwg-datagram-plpmtud-17: (with COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Apr 2020 07:10:07 -0000

On 02/04/2020 18:03, Murray S. Kucherawy wrote:
> On Thu, Apr 2, 2020 at 5:19 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk 
> <mailto:gorry@erg.abdn.ac.uk>> wrote:
>
>>>       Section 3:
>>>     * In bullet 2, "On request, a DPLPMTUD sender is REQUIRED to be able to
>>>     transmit a packet  ..."
>>>     -- I read this as "If I ask you to do X, you MUST be
>>>     able to do X", versus "you MUST do X".  Was that the intent?
>>>>>     GF - I think so, no change.
>
>
> In that case I suggest mentioning, or referencing, something about why 
> you might not transmit said packet even though you're capable of it.
>
> At base, I think it's an odd use of normative language to say you are 
> required to be capable of something and then provide no guidance, as 
> it compels no action.  I think more commonly you would say you SHOULD 
> transmit, and then discuss in what circumstances you would opt not to 
> do so.
>
> (Reminder: This is not a blocking comment; feel free to ignore it.)
>
> -MSK

Helpful, now I understand what I thought and you understood differ. We 
need to change this.

The "on request" was intended to indicate a specific request to the API 
to over-ride the default dending behaviour that would prevent sending 
packets larger than the PLPMTU. For example, we needed to make this 
change in FreeBSD because the previous options were either to fragment a 
large packet or fail to send.

Would this work:

OLD:

Probe packets: On request, a DPLPMTUD sender is REQUIRED to be
         able to transmit a packet larger than the PLMPMTU.
         This is used to send a probe packet.  ...

NEW:

Probe packets: The network interface below PL is REQUIRED to provide
         a way to transmit a probe packet that is larger than the PLMPMTU. ...


Gorry