AD review of draft-ietf-rddp-sctp-04

   The latest -04 revision has addressed a lot of my initial  
comments. There
   is just one major one left on the sequencing stuff.


Section 5.1., paragraph 3:

 >    We define a adaptation indication which MUST appear in the INIT or
 >    INIT-ACK with the following format as defined in [ADDIP-Draft] [6]

   Nit: s/[ADDIP-Draft] [6]/[6]/


Section 0, paragraph 1:

 >    DDP Segments are as defined in [DDP] [3].  The DDP Segment Chunk
 >    serves the same purpose as the MPA Upper Layer PDU (MULPDU) in  
that
 >    it carries DDP Segments over a reliable protocol with added
 >    sequencing information.

   Nit: s/[DDP] [3]/[3]/


Section 6.1., paragraph 2:

 >    The Payload Data Chunks for a given session, when sequenced by  
their
 >    DDP-SSN, MUST follow one of the patterns defined in this section.

   The sequence patterns in the remainder of this section don't
   include any DDP-SSNs? How can compliance thus be established?
   (See next comment.)


Section 6.2., paragraph 3:

 >       Passive Side sends a DDP Stream Session Accept message.

   Text above says this section describes a valid message exchange
   based on DDP-SSNs. I'd thus have expected this section to talk
   about DDP-SSNs, e.g., saying "active Side sends a DDP Stream Session
   Initiate message with DDP-SSN zero", "passive Side sends a DDP Stream
   Session Accept message with DDP-SSN zero" and so on. Am I making  
sense?
   (Same for Sections 6.3, 6.4 and 6.5.)


Section 6.2., paragraph 4:

 >       Each side may then send zero or more DDP Segments with  
increasing
 >       DDP-SSNs, subject to various layers of flow control.

   What does "various layers of flow control" mean? What happens
   when the DDP-SSN wraps? It's no longer increasing then.


Section 10., paragraph 5:

 >    The receiver MAY perform a validity check on received DDP-SSNs to
 >    ensure that any gap could be accounted for by unreceived Data  
Chunks.
 >    Implementations are SHOULD NOT allocate resources on the  
assumption
 >    that DDP-SSNs are valid without first performing such a validity
 >    check.  An invalid DDP-SSN MAY result in termination of the DDP
 >    Stream.

   Nit: s/are SHOULD NOT/SHOULD NOT/


Section 12., paragraph 1:

 >    This document defines a new SCTP Adaptation Layer Indication
 >    codepoint.  [ADDIP-Draft] [6] creates the registry from which this
 >    codepoint is to be assigned.  Any unallocated codepoint may be
 >    assigned.  The value of one is suggested.

   Nit: s/[ADDIP-Draft] [6]/[6]/


Section 13., paragraph 1:

 >    Any direct placement of memory could pose a significant  
security risk
 >    if adequate local controls are not provided.  These threats are
 >    addressed in the appropriate DDP [DDP-Draft] [3], RDMA [RDMA- 
Draft]
 >    [4] or Security [RDMA-Security] [5] drafts.  This document does  
not
 >    add any additional security risks over those found in RFC2960 [2].

   Nit: s/[DDP-Draft] [3]/[3]/
   Nit: s/[RDMA-Draft] [4]/[4]/
   Nit: s/[RDMA-Security] [5]/[5]/

-- 
Lars Eggert                                     NEC Network Laboratories

_______________________________________________
rddp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rddp