Subject: [Gen-art] Gen-ART review of draft-ietf-tsvwg-2960bis

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 16 May 2007 16:53:22 -0500

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tsvwg-2960bis-04.txt
Reviewer: Vijay K. Gurbani
Review Date: 16 May 2007
IESG Telechat date: 17 May 2007

Summary: This draft is ready for publication as a Proposed
Standard RFC.  I do have some comments, though.

Overall, a very nicely written document given the rather staid
subject matter that will appeal to the most pedantic of us
protocol folks.  Here are some nits, comments, and feedback
in the order that I read the draft:

1) In the top-left boiler plate on the first page (where it
  says "Network Working Group"), you may want to consider
  inserting "Obsoletes: 2960 (if approved)"

2) In S1.3.1 consider:
    s/against security attacks/against synchronization attacks
  The term "security" is too broad, and I believe that you are
  trying to prevent the likelihood of TCP SYN attacks in SCTP here.

3) While reading S1.2, it would help if some more text was
  devoted to interpreting the concept of an association.  In other
  words, in TCP we have a connection between a pair of hosts.  We
  can have multiple connections between the same pair of hosts,
  each connection opened by a different process on the host.
  Typically, a connection opened by one process on host A to
  host B is not shared by another process oh host A.

  When I translate that to SCTP, does that mean that I can have
  multiple associations between hosts, each association opened
  up by a different process on the host?  Or is the model that
  I have only one association between the hosts, but each pairing
  of a source process and destination process is represented as
  a pair of unidirectional streams within the one association?

4) S1.5: Please consider putting this section somewhere in the
  beginning.  Since the sub-sections that preceeded S1.5 use
  the abbreciations quite a bit, introducing the user to the
  abbreviations first should help readability.

5) Nit: S3, page 16: s/Section 6.10for/Section 6.10 for

6) Nit: S3.3.2.1: the text under the figure for IPv6 address
  parameter - s/128 bit/128 bits

7) S3.3.5, second paragraph: the text says that the parameter
  field contains an opaque data structure understood only by
  the sender.  I think it will add more clarity to insert the
  following text at the end of the last paragraph in the section:

  OLD:
  The Sender-specific Heartbeat Info field should normally include
  information about the sender's current time when this HEARTBEAT
  chunk is sent and the destination transport address to which this
  HEARTBEAT is sent (see Section 8.3).

  NEW:
  The Sender-specific Heartbeat Info field should normally include
  information about the sender's current time when this HEARTBEAT
  chunk is sent and the destination transport address to which this
  HEARTBEAT is sent (see Section 8.3).  This information is simply
  reflected back by the receiver in the HEARTBEAT ACK message (see
  Section 3.3.6).

8) Nit: S4 -
  s/description of all special cases should be found in the text/
  description of all special cases are found in the text.

  The phrase "should be" seems non-comittal; i.e., are all special
  cases mentioned in the document or not?  I presume they are.

9) S5.1.2, in the IMPLEMENTATION NOTE, it says that "when the
  implementation does not control the source IP address that is
  used for transmitting" - do such cases arise at all?  I
  thought that the IP layer, especially given rfc3484, will
  always know which source IP address to put in an outgoing
  IP datagram.

  Could it be that you meant "when the *ULP* does not control the
  source IP address that is used for transmitting"?

  Also, since I bring up rfc3484, I do not know if it has any
  bearing on the discussion in this section.  If the author has
  reached a conclusion that it does not, then that is fine with me.

10) At various places, the suggested SCTP protocol parameter
  values defined in S15 are used (c.f. S5.1.{3,4} and look for
  'Valid.Cookie.Life' and 'Max.Init.Retransmits').  It may be
  a good idea to either provide S15 at the beginning of the
  text, or to have a forward pointer to S15 on the first occurrence
  of the use of a protocol parameter defined in S15.  This way,
  the reader is alerted where to find the default values for
  these parameters.

11) Nit - S7.1, first bullet item:
  s/upper layer otherwise/upper layer to do otherwise

12) S10.1, API defined in G): What happens when stream id is
  not provided in a RECEIVE?  Is data for *all* streams
  retrieved?  Or data from stream 0 only (following the sematics
  for SEND, where if stream id is not specified, then stream 0
  is assumed.)

  I think this may have a bearing on S10.2 A).  When data
  arrives at a SCTP layer on a host, the SCTP informs the ULP
  of the stream id that the data arrived on.  I presume that the
  ULP then simply uses that stream id in the RECEIVE.  Yes?

13) In S11.2.2, it is stated that "A widely implemented BSD
  Sockets API extension exists for applications to request IP
  security services..."  Can you please provide a reference?
  Within the IETF archives, I was able to find two documents, one
  of which is an expired I-D:
  1) http://tools.ietf.org/html/draft-mcdonald-simple-ipsec-api-01
  2) http://tools.ietf.org/html/rfc2367

  Any other reference beyond the above will be extremely helpful
  for implementers.

That's it.

Thanks.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Randall Stewart <[email-masked]>
Date: Thu, 17 May 2007 13:09:16 -0400

Vijay:

Thanks for your review.. I am going to answer some of
your comments in-line here... see below.. but before
I go through this.. let me make sure you understand my
constraints as editor.

The BIS document for 2960 was setup by Scott/Allison in such
a way that it would be a "restricted" edit of 2960. This was
designed to keep a "food fight" from happening when we opened
the document that would get us in a situation where everyone
wanted to change everything :-)

With that in mind, I was restricted in the BIS document in
ONLY applying changes identified in RFC4460 (the SCTP errata document)
that showed up at various SCTP inter-op's.

The general rule that I and the WG was under, is that::
a) Only change things that were documented and agreed to by
    the wg in RFC4460.. i.e. apply all changes from 4460 to
    the BIS.
b) Any other changes had to be in the scope of what was changed in 4460
    i.e. if section X was changed to do foo in 4460.. but we failed
    to change section Y which also addressed foo.. then that was ok..
c) other changes, outside of spelling and grammar is off-limits.

Now with that in mind, understand that some of the points you
make violate that restriction and address areas of the original
RFC2960 that I was restricted from editing. Please keep this in
mind as I give you my comments back...

Lars: I will be asking for your advice throughout this
reply to know what I can and cannot change...

>  inserting "Obsoletes: 2960 (if approved)"

This is a failure on my part to get the right XML widgets
in place.. Cullen has helped me do that.. so its now in the
XML like its supposed to be .. good catch :-D

>  trying to prevent the likelihood of TCP SYN attacks in SCTP here.

You are correct.. but understand this violates my restrictions..
I will leave this up to Lars to tell me if I can make this change.
Lars?

>  a pair of unidirectional streams within the one association?

This again violates the editing rules. Furthermore the state machine
in the document answers this question if you look at it.. yes its
the same as TCP.. but i.e. multiple connections between a
pair of hosts... There is a very nice mathematical description
of this in the appendix in the add-ip draft. I don't see adding
a section here is a good idea.. since even though its like TCP
the editing rules and  my general thoughts run against this.

I can just as well share a file descriptor between two processes
either by fork, or by sending the fd across.. and thus your second
part of the first paragraph is not true. It is true however
that two hosts can create one unique association between two
ports and a set of addresses... like TCP .. but I think the
mathematical description in add-ip does a much better job
of explaining this.. and is best left as an appendix there so
that we do not constrain future design..

>  abbreviations first should help readability.

Lars: here is another change violating my editing constraints
moving the text is easy in the xml.. should I do it?
If this is allowable, then maybe both 1.4 and 1.5 should
be moved to follow 1.1..

But this IS a violation of my editing constraints.. so I leave
this up to you...

> 5) Nit: S3, page 16: s/Section 6.10for/Section 6.10 for
This is an xml glitch.. I will gladly fix it :-D

>  parameter - s/128 bit/128 bits

Done

>  reflected back by the receiver in the HEARTBEAT ACK message (see

Lars: This again violates the editing constraints I have no
problem personally with this.. but ??

>  cases mentioned in the document or not?  I presume they are.

This is a grammar glitch that was even in 2960.. consider it fixed.

>  reached a conclusion that it does not, then that is fine with me.

No, there are some cases where this is a true statement... besides
being unchanged form 2960 nor addressed by 4460..

>  the reader is alerted where to find the default values for

I don't see a problem with a forward reference.. say at the
first "param".. Valid.Cookie.Life... but once again this
violates my editing constraints, Lars?

>  s/upper layer otherwise/upper layer to do otherwise
no problem.. grammar glitch.

>  ULP then simply uses that stream id in the RECEIVE.  Yes?

Yes, when you do a receive.. you get the first message on
whatever stream. The ULP cannot control what stream data
arrives on.. at least not in the socket api. The API here is
mythical anyway as it says in the top of the section.. no one
uses this (or at least few).. they implement in general
the draft-...sctpsocket-xx.txt document.

I don't see the need to further describe an API that is really
best defined in the other document.. and... again this violates
my editing constraints..

>  2) http://tools.ietf.org/html/rfc2367

I believe this text comes from Vern Paxson.. I don't know
the API nor as this changed from the original RFC2960.
I.e. it violates my editing constraints.

If we wanted to change this... we would need to loop in
Vern to find out what he was referring to.. he may have got
this from Steve B.. can't remember.. its has been years ago :-D

Lars:

I have changed all I feel I can within my constraints as editor and
I leave all the rest of the questions in here up to you...

Thanks for you review... and Lar's the ball is
in your court ;-D

R

-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)

---

From: Lars Eggert <[email-masked]>
Date: Mon, 21 May 2007 10:46:06 +0200

> reply to know what I can and cannot change...

As far as I remember, the motivation for wanting to tightly scope  
which modifications were OK going from RFC2960 to tsvwg-2960bis was  
to prevent tsvwg-2960bis from becoming SCTP version 2. The idea was  
that 2960bis would roll in bugfixes and errata items, and after six  
months could progress to Draft Standard, which would not be possible  
if new functions were being added.

That said, I haven't seen anything in Vijay's comments that I would  
interpret as changing the technical details of SCTP. All his review  
comments seem to ask for clarifications about the text of the  
document, which IMO is OK for tsvwg-2960bis.

I may have missed something - if you think that addressing a comment  
would change the operation of SCTP, please let me know. Otherwise,  
it's up to your discretion as editor whether you want to address the  
comments or not.

Lars

---

From: Randall Stewart <[email-masked]>
Date: Mon, 21 May 2007 09:36:57 -0400

As long as you give me an editing green light then..

I will go back over the comments in a bit more
detail.. seems like there is one I disagreed with.. but
all the rest are fine :-D

R

Lars Eggert wrote:
> As far as I remember, the motivation for wanting to tightly scope which 
> modifications were OK going from RFC2960 to tsvwg-2960bis was to prevent 
> tsvwg-2960bis from becoming SCTP version 2. The idea was that 2960bis 
> would roll in bugfixes and errata items, and after six months could 
> progress to Draft Standard, which would not be possible if new functions 
> were being added.
> 
> comments seem to ask for clarifications about the text of the document, 
> which IMO is OK for tsvwg-2960bis.
> 
> would change the operation of SCTP, please let me know. Otherwise, it's 
> up to your discretion as editor whether you want to address the comments 
> or not.
> 
> Lars
> 
>

---

From: Randall Stewart <[email-masked]>
Date: Thu, 31 May 2007 16:24:53 -0400

Vijay:

Ok I have gone through all your comments and corrected
them with two exceptions noted below..

>  reached a conclusion that it does not, then that is fine with me.

I will not change anything in section 5.1.2. There ARE implementation
situations where the implementation (not the application) cannot
control the source address. The wording here was added just due
to such situations. In such a case the wording is valid.
As to rfc3484, sctp had a document that discussed these issues
long before that draft ever appeared.. we let the draft slip
by the wayside long ago.. we have discussed revising it.. since
you also have issues with src addr selection on v4 too.. (we actually
had two documents).. bottom line is I think a separate document
is probably appropriate to discuss such issues.

>  ULP then simply uses that stream id in the RECEIVE.  Yes?
SCTP's api in most implementations do NOT let you control
what stream you receive from next. The API document is
coming soon to the IESG.. and this as more details.

The section in the RFC is as it says:

    The primitives and notifications described in this section should be
    used as a guideline for implementing SCTP.

At one time (in the original go 2960 discussion) this said "mythical" :-D

No one implements this API instead they use the sockets document.
 From your comments I can't derive a change to be made here other
than the fact that the API confuses you :-D (which it does
me also :-D)

If you want a specific wording change, I will make it.. but as
I said I think you are better to hold your comments for the
sockets api document... when it comes up :-D