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

From: Lars Eggert <[email-masked]>
Date: Tue, 10 Oct 2006 14:02:34 +0200

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

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 10 Oct 2006 22:57:31 +0200

Hi Lars, hi James,

see my comments in-line.

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

Best regards
Michael

>   this option has the potential to waste bandwidth.
I'll add a reference and will point out the bandwidth waste issue.
>   Nit: s/keywords/key words/ to make idnits happy
OK.
>   (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.
>   Use RFC2119 language ("SHOULD set to zero / MUST ignore")
OK.
> >       This holds the Padding Data.  The Padding Data is ignored  
> by the
> >       receiver.
>
OK.
>
>
> Section 3., paragraph 8:
> >    this is also the required processing behavior for the PAD  
> chunk when
OK.
>   See comment on "arbitrary size" above.
OK. I'll make it explicit.
>   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-masked]
> https://www1.ietf.org/mailman/listinfo/pmtud

---

From: Vlad Yasevich <[email-masked]>
Date: Tue, 10 Oct 2006 17:10:28 -0400

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

Ahm...  I don't think that's right.  The top two bits of the chunk
type tell what to do with it.  PAD type is coded to be ignored if
unknown.

-vlad

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 11 Oct 2006 00:16:06 +0200

I found this when doing the change. Yes, you need to replace
the PAD chunk when it
by
any chunk type with the same upper two bits as the PAD chunk that

Best regards
Michael

---

From: Lars Eggert <[email-masked]>
Date: Wed, 11 Oct 2006 18:32:52 +0900

> type tell what to do with it.  PAD type is coded to be ignored if

Good catch - thanks!

Lars

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 13 Oct 2006 14:10:54 +0200

Hi,

The WG last call has concluded. There has been comments received. We 
will await an update of the document. However, as the comments are only 
editorial we plan to request publication of this document as soon as the 
update is available unless the changes become larger than indicated by 
the comments.

Best Regards

Magnus

Magnus Westerlund skrev:
> 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.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctp-padding-01.txt
> 
> Cheers
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> 

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Lars Eggert <[email-masked]>
Date: Sat, 14 Oct 2006 12:46:19 +0900

> its job. Isn't that right? James?

The IANA section customarily gets removed when all it has is "this  
document requires no IANA actions", purely to increase readability.  
Documents that require IANA actions do keep the section when published.

The same is true for SCTP-AUTH. I hadn't realized that has the same  
problem and I didn't see an email on the list about this, but the  
IANA section must remain in place there, too.

Lars

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 13 Oct 2006 23:51:12 -0500

>>its job. Isn't that right? James?

I have to find my message(s) that gave this impression, because I don't 
believe I should have said this, if I did (I'm sorry, and I know 
better).  I'm searching for the messages exchange we had about this...

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 14 Oct 2006 00:03:33 -0500

>IANA section must remain in place there, too.

SCTP-AUTH has a large and well written IANA section, and is not void of 
doing anything, so I'm confused by comparing what happens to Padding with 
what happens to AUTH.  Lars, can you explain your comments some more?

---

From: Lars Eggert <[email-masked]>
Date: Sat, 14 Oct 2006 14:06:45 +0900

On Oct 14, 2006, at 14:03, James M. Polk wrote:
> SCTP-AUTH has a large and well written IANA section, and is not  
> void of doing anything, so I'm confused by comparing what happens  
> to Padding with what happens to AUTH.  Lars, can you explain your  
> comments some more?

SCTP-AUTH currently says:

       NOTE to RFC-Editor:

       "RFCXXXX" is to be replaced by the RFC number you assign this
       document.

       The reference to sctp-parameters [7] should be removed from the
       "Normative References" section after the IANA section has been
       removed.

The IANA section should NOT be removed here either.

Lars

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 14 Oct 2006 00:11:47 -0500

round 3

>>its job. Isn't that right? James?

I believe stating where in IANA new parameters ought to go is a good thing 
- as it makes their job easier by them not having to guess where it is 
authors had in mind to register something, as I've been told many many 
times as a doc author (Allison trained me well).  There have been many a 
confusing time between IANA folks, ADs, shaephards and authors as to what 
has been intended and what was expected in the old Transport area, 
specifically around SIP, and RSVP vs. COPS parameters.  Writing an IANA 
section that simulates how the new parameters will appear in IANA has 
always gone over well with me (once I learned to do it this way).

I passed this advice along to Michael, and he promptly turned around a 
version of SCTP-AUTH that way (in a day, if I remember correctly).

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 14 Oct 2006 00:21:15 -0500

>The IANA section should NOT be removed here either.

I read the above as stating the reference (#7 in the references section) 
should be removed, not the IANA section, which is how I'm reading what you 
are implying you think the doc is asking to do.

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 14 Oct 2006 10:20:05 +0200

Hi James,

it seems that you both think that the IANA section will stay. So the
reference to the link should stay. I can make it an Informative  
Reference.
OK?

Best regards
Michael

On Oct 14, 2006, at 7:21 AM, James M. Polk wrote:

> I read the above as stating the reference (#7 in the references  
> section) should be removed, not the IANA section, which is how I'm  
> reading what you are implying you think the doc is asking to do.
>
>
>> Lars
>> --
>> Lars Eggert                                     NEC Network  
>> Laboratories
>>
>>
>>
>>
>

---

From: Lars Eggert <[email-masked]>
Date: Sat, 14 Oct 2006 18:51:58 +0900

> reading what you are implying you think the doc is asking to do.

The text above literally says that [7] is removed from the references  
section *after the IANA section has been removed*, which obviously  
implies that the IANA section is to be removed. I can see no other  
way to read this?

The IANA section should not be removed, for both SCTP-PAD or SCTP-AUTH.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Sat, 14 Oct 2006 18:52:43 +0900

On Oct 14, 2006, at 17:20, Michael Tuexen wrote:
> it seems that you both think that the IANA section will stay.

Yes, in Both PAD and AUTH.

> So the

OK.

Lars

---

From: Michael Tuexen <[email-masked]>
Date: Sat, 14 Oct 2006 13:12:55 +0200

Hi Lars,

OK, I change both as you want. Will resubmit the Padding ID later  
today. Still working on the SCTP-AUTH.

Best regards
Michael