Re: [dtn-interest] TCPCL

[Simon Perreault <[e-mail]>]

Thanks for the review! I'll communicate your fixes to the RFC Editor.

Thanks,
Simon

Le 2014-05-22 15:28, Velt, R. (Ronald) in 't a écrit :
> Hi,
>
> The Delay Tolerant Networking TCP Convergence Layer Protocol I-D (draft-irtf-dtnrg-tcp-clayer-09) has been with the RFC Editor for a while and is now in AUTH48 state. It may, therefore, be a tad late for comments, even if they are fairly minor ones. But perhaps not entirely too late. Maybe some of the perceived flaws mentioned below can, if confirmed, still be repaired.
>
>   - Page 3, 2nd paragraph: "Bundling Protocol" should be "Bundle Protocol"
>
> - Page 5, item "Connection Parameters":  "Section Section 4.2" should be "Section 4.2" (Probably already detected and dealt with by the RFC Editor)
>
> - Page 8, Figure 2, left-side part of the figure, under node A:
> * 1st DATA_SEGMENT: "Bundle Data 0..L1" should be "Bundle Data 0..(L1 - 1)"
> * 2nd DATA_SEGMENT: "Bundle Data L1..L2" should be "Bundle Data L1..(L1 + L2 - 1)"
> * 3rd DATA_SEGMENT: "Bundle Data L2..L3" should be "Bundle Data (L1 + L2)..(L1 + L2 + L3 - 1)"
>
> - Page 11, Section 4.2: The fourth paragraph of this section and following indented part discusses the effect of Contact Header Flags on parameter negotiation, but makes no mention of the LENGTH flag. The reader is kept in the dark w.r.t. the interpretation of this flag until section 5.5. For the sake of completeness, it could be stated that there is no parameter negotiation associated with the sending of LENGTH messages.
>
> - Page 14, 2nd paragraph, last sentence: Is this really stating that if a node is able to receive a segment of arbitrary size, then it MUST be able to receive segments of any size up to and including the bundle size? Or is the intended meaning that if a node is able to receive a segment of a certain size, it MUST be able to receive smaller segments as well? (In which case the "<= X" at the end of the sentence should be "<= Y").  (Not sure about this one!!)
>
> - Page 17,second paragraph under Figure 7, last sentence: "The receiver MUST be prepared for this ..." should be "The sender MUST be prepared for this ..." (I.e., the _sender_  of the LENGTH message and subsequent DATA_SEGMENT message, when _receiving_ a BUNDLE_REFUSE message).
>
> - Page 17, section 5.6, third paragraph:  "(as described in Table2, ..." => closing parenthesis missing. (Probably already detected and dealt with by the RFC Editor)
>
> - Throughout the document: a quantity of 8 bits is alternatingly referred to as "byte" or "octet". It would be better to pick one or the other and use the chosen term consistently.
>
> Thanks,
> Ronald in 't Velt
>
>
>
>
>
> Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.
>
>
>
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>