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
[email protected]
https://www1.ietf.org/mailman/listinfo/pmtud
_______________________________________________
pmtud mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pmtud
