[pmtud] Re: [Tsvwg] Working group last call on draft-ietf-tsvwg-sctp-padding-01

Lars Eggert <lars.eggert@netlab.nec.de> Tue, 10 October 2006 12:02 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXGJl-0002ru-Qw; Tue, 10 Oct 2006 08:02:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXGJl-0002rm-5D; Tue, 10 Oct 2006 08:02:41 -0400
Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXGJj-0003Gl-Ji; Tue, 10 Oct 2006 08:02:41 -0400
Received: from localhost (localhost.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id A8C7F200C967; Tue, 10 Oct 2006 14:03:08 +0200 (CEST)
Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12278-10; Tue, 10 Oct 2006 14:03:08 +0200 (CEST)
Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 88704200C963; Tue, 10 Oct 2006 14:03:08 +0200 (CEST)
Received: from n-eggert.office ([10.1.1.112]) by mx1.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 14:02:38 +0200
Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id 4914C24B2D0; Tue, 10 Oct 2006 14:02:37 +0200 (CEST)
In-Reply-To: <451B9B8F.8000607@ericsson.com>
References: <451B9B8F.8000607@ericsson.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Message-Id: <E05CFB40-21C8-4D31-99E8-9BCA43A8C1BD@netlab.nec.de>
From: Lars Eggert <lars.eggert@netlab.nec.de>
Date: Tue, 10 Oct 2006 14:02:34 +0200
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.752.2)
X-OriginalArrivalTime: 10 Oct 2006 12:02:38.0936 (UTC) FILETIME=[FB575580:01C6EC63]
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21
Cc: Path MTU Discovery WG <pmtud@ietf.org>, tsvwg <tsvwg@ietf.org>
Subject: [pmtud] Re: [Tsvwg] Working group last call on draft-ietf-tsvwg-sctp-padding-01
X-BeenThere: pmtud@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Maximum Transmission Unit Discovery <pmtud.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pmtud>, <mailto:pmtud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pmtud>
List-Post: <mailto:pmtud@ietf.org>
List-Help: <mailto:pmtud-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pmtud>, <mailto:pmtud-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0541971683=="
Errors-To: pmtud-bounces@ietf.org

On Sep 28, 2006, at 11:53, Magnus Westerlund wrote:
> This announces the 2 week working group last call for "Padding  
> Chunk and Parameter for SCTP" with the intended status of Proposed  
> standard. Please provide any comments or reports of reviewing it  
> before the 13th of October.

Section 1., paragraph 1:
 >    This document defines a padding chunk and a padding parameter and
 >    describes the required receiver side procedures.  The padding  
chunk
 >    is used to pad an SCTP packet to an arbitrary size.  The padding
 >    parameter is used to pad an SCTP INIT chunk to an arbitrary size.
 >    The PAD chunk can be used for path MTU discovery.

   Cite draft-ietf-pmtud-method. Would maybe also point out that the  
only
   currently known use of this is for PMTUD, and that unreflected use of
   this option has the potential to waste bandwidth.


Section 2., paragraph 1:
 >    The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

   Nit: s/keywords/key words/ to make idnits happy


Section 3., paragraph 1:
 >    This chunk is used to pad an SCTP packet to an arbitrary size.

   "Arbitrary size" - not really, because the smallest amount a packet
   can be increased by is 4 bytes, assuming the padding data can be  
empty
   (can it?) Also, can there be more than one PAD chunk per SCTP packet?
   (Otherwise, can't pad to much more than 64KB.)


Section 3., paragraph 5:
 >    Flags: 1 byte (unsigned integer)
 >       Set to zero on transmit and ignored on receipt.

   Use RFC2119 language ("SHOULD set to zero / MUST ignore")


Section 3., paragraph 7:
 >    Padding Data: n bytes (unsigned integer)
 >       This holds the Padding Data.  The Padding Data is ignored by  
the
 >       receiver.

   Use RFC2119 language ("MUST be ignored")


Section 3., paragraph 8:
 >    this is also the required processing behavior for the PAD chunk  
when
 >    it is unknown by the receiver.

   Nit: s/the PAD chunk when it/any chunk type that/


Section 4., paragraph 1:
 >    This parameter is used to pad an INIT chunk to an arbitrary size.

   See comment on "arbitrary size" above.


Section 5., paragraph 3:
 >       The reference to sctp-parameters [3] should be removed from the
 >       "Normative References" section after the IANA section has been
 >       removed.

   Why would the IANA section be removed?

-- 
Lars Eggert                                     NEC Network Laboratories


_______________________________________________
pmtud mailing list
pmtud@ietf.org
https://www1.ietf.org/mailman/listinfo/pmtud