Subject: [Tsvwg] WGLC for draft-ietf-tsvwg-addip-sctp-17 starts NOW

From: "James M. Polk" <[email-masked]>
Date: Tue, 28 Nov 2006 20:41:42 -0600

TSVWG

The WGLC for

	draft-ietf-tsvwg-addip-sctp-17.txt

starts today, November 28th, 2006, and ends on or after December 13th, 2006 
- depending on the level of comments to the TSVWG list at that time.

All that wish to make comments about this document (pro, con, any necessary 
edits or changes, etc), please make them ASAP.

This document is targetted at becoming a (Proposed) Standards Track RFC 
if/once approved.
cheers,

James
Lars
Magnus
	IETF TSVWG co-chairs

---

From: Lars Eggert <[email-masked]>
Date: Wed, 29 Nov 2006 18:30:39 -0800

Summary: Not ready. This document describes a complex mechanism and
   probably has all the required details, but the presentation is
   extremely hard to follow (no useful introduction, no logical  
thread to
   help the reader along, etc.) There are also a few technical issues
   (see below) as well as problems with the IANA actions. This requires
   a significant overhaul.

   (Most nits found by a tool, didn't check.)

Section 1., paragraph 0:
 > 1.  Introduction

   The introduction needs work. It attempts to explain what these
   extensions do and what they can be used for, but the bullets in
   Section 3 are much clearer on the former and the latter would benefit
   from a clearer description of some use cases.

Section 2., paragraph 1:
 >    The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,

   Nit: s/keywords/key words/ to make idnits happy

Section 3., paragraph 0:
 > 3.  Additional Chunks and Parameters

   This section mixes specification of the format of the chunks with
   processing of such chunks, which is the topic of Section 4. Recommend
   to move processing-related text to the appropriate sections in  
Section
   4 and make Section 3 purely about the chunk formats.

Section 3.1., paragraph 4:

 >    It should be noted that the ASCONF Chunk format requires the  
receiver
 >    to report to the sender if it does not understand the ASCONF  
Chunk.
 >    This is accomplished by setting the upper bits in the chunk  
type as
 >    described in RFC2960 [RFC2960] section 3.2.  Note: that the  
upper two
 >    bits in the ASCONF Chunk are set to one.  As defined in RFC2960
 >    [RFC2960] section 3.2, setting these upper bits in this manner  
will
 >    cause the receiver that does not understand this chunk to skip the
 >    chunk and continue processing, but report in an Operation Error  
Chunk
 >    using the 'Unrecognized Chunk Type' cause of error.

   Since this paragraph is specific to the ASCONF chunk, move it to
   3.1.1. Use RFC2119 language instead of paraphrasing it ("requires the
   receiver"). Also, the last sentence apparently implies that the  
sender
   MUST abort when it receives the error chunk?

Section 3.1.1., paragraph 5:
 >    Address Parameter : 8 or 20 bytes (depending on type)

   What type?

Section 3.1.1., paragraph 7:
 >    Note: the host name address parameter is NOT allowed and MUST be
 >    ignored if received in any ASCONF message.

   s/is NOT allowed/MUST NOT be sent/

Section 3.2.1, paragraph 7:
 >    Any parameter that appears where it is not allowed (for example a
 >    0xC002 parameter appearing within an INIT or INIT-ACK) MAY be
 >    responded to with an ABORT by the receiver of the invalid  
parameter.

   What should happen if the receiver doesn't abort? Ignore it? What is
   the guideline for aborting vs. ignoring?

Section 3.2.1., paragraph 3:
 >    This is an opaque integer assigned by the sender to identify each
 >    request parameter.  It is in host byte order and is only  
meaningful
 >    to the sender.  The receiver of the ASCONF Chunk will copy this 32
 >    bit value into the ASCONF Response Correlation ID field of the
 >    ASCONF-ACK response parameter.  The sender of the ASCONF can  
use this
 >    same value in the ASCONF-ACK to find which request the response is
 >    for.

   If it is only meaningful to the sender, why does it matter whether it
   is host byte-order or not? (Also elsewhere.)

Section 3.3.2.1, paragraph 1:
 >    An example TLV requesting that the IPv4 address 10.1.1.1 be  
added to
 >    the association would look as follows:

   Use the IANA example block 192.0.2.0/24. (Also elsewhere.)

Section 3.2.6., paragraph 4:
 >    The Adaptation Layer Indication parameter may appear in INIT or  
INIT-
 >    ACK chunk and SHOULD be passed to the receivers upper layer  
protocol.
 >    This parameter MUST NOT appear in an ASCONF Chunk.

   Why "SHOULD be passed" and not MUST? When wouldn't you pass it? Also,
   rephrase "MUST not appear" in the usual "MUST not send and MUST  
ignore
   on receive" way.

Section 3.2.7., paragraph 1:
 >    This parameter is used at startup to identify any additional
 >    extensions that the sender supports.  The sender MUST support both
 >    the sending and the receiving of any chunk types listed within the
 >    Supported Extensions Parameter.

   Define "at startup" and "used."

Section 3.3.4., paragraph 1:
 >    This error is to be included in an ABORT that is generated due  
to the
 >    reception of an ASCONF-ACK that was not expected but is larger  
than
 >    the current sequence number (see Section 4.3 Rule D0 ).  Note:  
that a
 >    sequence number is larger than the last acked sequence number  
if it
 >    is either the next sequence or no more than 2^^31-1 greater  
than the
 >    current sequence number.

   What if the sequence number is smaller, because it has wrapped? Also,
   nit: s/acked/ACKed/

Section 4., paragraph 0:
 > 4.  Procedures

   This needs a careful check for RFC2119 terms. There are, for example,
   a lot of lowercase shoulds that should be MUSTs IMO. I'll highlight
   some below, but there are more. There are also some uppercase terms
   that should be lowercase. Also, some state diagram or two may help
   digest the very detailed procedures described below.

Section 4.1., paragraph 1:
 >    When an endpoint has an ASCONF signaled change to be sent to the
 >    remote endpoint it should do the following:

   s/should/MUST/

Section 4.1., paragraph 2:
 >    A1)  Create an ASCONF Chunk as defined in Section 3.1.1.  The  
chunk
 >       should contain all of the TLV(s) of information necessary to be
 >       sent to the remote endpoint, and unique correlation  
identities for
 >       each request.

   s/should/MUST/

Section 4.1., paragraph 3:
 >    A2)  A serial number should be assigned to the Chunk.  The serial
 >       number should be a monotonically increasing number.  The serial
 >       number MUST be initialized at the start of the association  
to the
 >       same value as the Initial TSN and every time a new ASCONF  
Chunk is
 >       created it is incremented by one after assigning the serial  
number
 >       to the newly created chunk .

   First it says "should be monotonically increasing" and then it has a
   MUST clause that forces monotonicity.

Section 4.1., paragraph 11:
 >    If the T-4 RTO timer expires the endpoint should do the following:

   s/should/MUST/

Section 4.2., paragraph 1:
 >    When an endpoint receives an ASCONF Chunk from the remote peer
 >    special procedures MAY be needed to identify the association the
 >    ASCONF Chunk is associated with.  To properly find the association
 >    the following procedures should be followed:

   s/MAY/may/ s/should/SHOULD/

Section 4.2., paragraph 19:
 >    E7)  While processing the ASCONF Chunks in the SCTP packet, if the
 >       response packet will exceed the PMTU of the return path, the
 >       receiver MUST stop adding addtional ASCONF-ACK's into the  
response

   Nit: s/addtional ASCONF-ACK's/additional ASCONF-ACKs/

Section 4.2., paragraph 21:
 >    Note: These rules have been presented with the assumption that the
 >    implementation is caching old ASCONF-ACK's in case of loss of SCTP

   Nit: s/ASCONF-ACK's/ASCONF-ACKs/

Section 4.3., paragraph 2:
 >    F0)  If an endpoint receives an ASCONF-ACK that is greater than or
 >       equal to the next serial number to be used but no ASCONF  
Chunk is
 >       outstanding the endpoint MUST ABORT the association.  Note:  
that a
 >       sequence number is greater than if it is no more than 2^^31-1
 >       larger than the current sequence number (using serial  
arithmetic).

   What's "serial arithmetic?" Also, define this business with serial
   numbers, wrapping and comparing them once. It currently pops up in a
   number of places in the document.

Section 4.4., paragraph 3:
 >    The request to set an address as the primary path is an option the
 >    receiver SHOULD perform.  It is considered advice to the  
receiver of
 >    the best destination address to use in sending SCTP packets (in  
the
 >    requesters view).  If a request arrives that asks the receiver  
to set

   Nit: s/requesters/requester's/

Section 4.5., paragraph 1:
 >    In the normal case a single ASCONF is sent in a packet and a  
single
 >    reply ASCONF-ACK is received.  However, in the event of the  
loss of
 >    an SCTP packet containing either an ASCONF or ASCONF-ACK it is
 >    allowable for a sender to bundle additional ASCONF's in the

   Nit: s/ASCONF's/ASCONFs/

Section 4.5., paragraph 2:
 >    retransmission.  In bundling multiple ASCONF's the following rules

   Nit: s/ASCONF's/ASCONFs/

Section 2., paragraph 0:
 >    MUST be followed:
 >    1.  Previously transmitted ASCONF Chunks MUST be left unchanged.
 >    2.  Each SCTP packet containing ASCONF Chunks MUST be bundled
 >        starting with the smallest ASCONF Serial Number first in the
 >        packet (closest to the Chunk header) and preceeding in  
sequential

   Nit: s/preceeding/preceding/

Section 3., paragraph 0:
 >    3.  All ASCONF's within the packet MUST be adjacent to each other

   Nit: s/ASCONF's/ASCONFs/

Section 3., paragraph 1:
 >        i.e. no other chunk type must seperate the ASCONF's.

   Nit: s/seperate/separate/
   Nit: s/ASCONF's./ASCONFs./

Section 4., paragraph 0:
 >    4.  Each new ASCONF's lookup address MUST be populated as if the
 >        previous ASCONF's had been processed and accepted.

   Nit: s/ASCONF's/ASCONF/

Section 6., paragraph 0:
 > 6.  IANA considerations

   IANA cannot determine what to do with this document without digging
   through it in its entirety. Please move all IANA actions from the
   remainder of the document into this section.

Appendix A., paragraph 0:
 > Appendix A.  Abstract Address Handling

   If this appendix is non-normative, add a statement. Also, a shorter
   textual summary of this appendix may really improve the introduction.