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

[Randall Stewart <[e-mail]>]

Vijay:

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



Vijay K. Gurbani wrote:
> 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.


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.



> 
> 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?
> 
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




> 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


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


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