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


Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
pmtud mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pmtud

Reply via email to