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

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Tue, 10 October 2006 20:57 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOf4-0004mw-RH; Tue, 10 Oct 2006 16:57:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOf3-0004ml-4O; Tue, 10 Oct 2006 16:57:13 -0400
Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXOf1-0006IX-La; Tue, 10 Oct 2006 16:57:13 -0400
Received: from [192.168.1.100] (p508FD18A.dip.t-dialin.net [80.143.209.138]) by ilsa.franken.de (Postfix) with ESMTP id 02F0C245CF; Tue, 10 Oct 2006 22:57:09 +0200 (CEST) (KNF account authenticated via SMTP-AUTH)
In-Reply-To: <E05CFB40-21C8-4D31-99E8-9BCA43A8C1BD@netlab.nec.de>
References: <451B9B8F.8000607@ericsson.com> <E05CFB40-21C8-4D31-99E8-9BCA43A8C1BD@netlab.nec.de>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <A2CF9A9D-E08B-488B-BAF6-1BB07D720C33@lurchi.franken.de>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Subject: Re: [pmtud] Re: [Tsvwg] Working group last call on draft-ietf-tsvwg-sctp-padding-01
Date: Tue, 10 Oct 2006 22:57:31 +0200
To: Lars Eggert <lars.eggert@netlab.nec.de>, "James M. Polk" <jmpolk@cisco.com>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, Path MTU Discovery WG <pmtud@ietf.org>, tsvwg <tsvwg@ietf.org>
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>
Errors-To: pmtud-bounces@ietf.org

Hi Lars, hi James,

see my comments in-line.

After the IANA issue is resolved, I'll resubmit an updated version.

Best regards
Michael

On Oct 10, 2006, at 2:02 PM, Lars Eggert wrote:

> 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.
I'll add a reference and will point out the bandwidth waste issue.
>
>
> Section 2., paragraph 1:
> >    The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL  
> NOT",
>
>   Nit: s/keywords/key words/ to make idnits happy
OK.
>
>
> 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.)
Yes, it can be empty. You are right. You can add between 4 and 2^16  
bytes
in steps of 4 bytes. And yes, you can have more than one chunk.
I'll make all this explicit.
>
>
> 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")
OK.
>
>
> 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")
OK.
>
>
> 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/
OK.
>
>
> Section 4., paragraph 1:
> >    This parameter is used to pad an INIT chunk to an arbitrary size.
>
>   See comment on "arbitrary size" above.
OK. I'll make it explicit.
>
>
> 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?
This section is written like the one for SCTP-AUTH which was  
suggested by
James. I thought, that the IANA section gets deleted when IANA has done
its job. Isn't that right? James?
>
> -- 
> Lars Eggert                                     NEC Network  
> Laboratories
>
>
> _______________________________________________
> pmtud mailing list
> pmtud@ietf.org
> https://www1.ietf.org/mailman/listinfo/pmtud


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