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

[Michael Tuexen <[e-mail]>]

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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pmtud


_______________________________________________
pmtud mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pmtud