Re: [dtn-interest] [irsg] IRSG review of draft-irtf-dtnrg-tcp-clayer-06.txt

["Eggert, Lars" <[e-mail]>]

Hi,

could we see the new revision submitted soon?

Thanks,
Lars

On Jul 31, 2013, at 20:16, "Eggert, Lars" <[e-mail]> wrote:

> The ID submission tool is open again.
> 
> Lars
> 
> On Jul 28, 2013, at 13:18, Dirk Kutscher <[e-mail]> wrote:
> 
>> Hi Simon,
>> 
>> Very good -- I agree with what you proposed in your reply -- looking forward to the new revision.
>> 
>> Best regards,
>> Dirk
>> 
>> 
>>> -----Original Message-----
>>> From: Simon Perreault [mailto:[e-mail]]
>>> Sent: Mittwoch, 17. Juli 2013 13:33
>>> To: Dirk Kutscher
>>> Cc: Internet Research Steering Group ([e-mail]); draft-irtf-dtnrg-tcp-
>>> [e-mail]; [e-mail]
>>> Subject: Re: IRSG review of draft-irtf-dtnrg-tcp-clayer-06.txt
>>> 
>>> Thanks for your very detailed review! I agree with almost all your proposed
>>> changes. I'll publish a new revision.
>>> 
>>> Le 2013-07-16 22:41, Dirk Kutscher a écrit :
>>>> - section 3:
>>>> <comment>
>>>> The protocol overview needs to say that a TCPCL can be used to
>>>> transmit several bundles, but that multiple bundles MUST be
>>>> transmitted consecutively (i.e., no inter-leaving of bundle
>>>> segments). In addition, I think, you also have to say that the
>>>> blocks of a particular bundle MUST be sent sequentially (no change
>>>> of block order).
>>>> </comment>
>>> 
>>> Agreed. I would also add that interleaving can be accomplished with bundle
>>> fragmentation.
>>> 
>>>> - section 3:
>>>> <oldtext>
>>>> This protocol provides bundle conveyance over a TCP connection and
>>>> specifies the encapsulation of bundles as well as procedures for TCP
>>>> connection setup and teardown.
>>>> </oldtext>
>>>> 
>>>> <comment>
>>>>  "The service of this protocol is the transmission of DTN bundles
>>>>   over TCP. This document specifies the encapsulation of bundles,
>>>>   procedures for TCP setup and teardown, and a set of messages and
>>>>   node requirements."?
>>>> </comment>
>>> 
>>> Agreed.
>>> 
>>>> - section 3.1:
>>>> 
>>>> <comment>
>>>> The first paragraph is not very clear. You want to say that there
>>>> are different specific messages for sending and receiving
>>>> operations (in addition to connection setup/teardown).  TCPCL is
>>>> symmetric, i.e., both sides can start sending data segments in a
>>>> connection, and one side's bundle transfer does not have to
>>>> complete before the other side can start sending data segments on
>>>> its own. Hence, the protocol allows for a bi-directional mode of
>>>> communication.
>>>> </comment>
>>> 
>>> Agreed.
>>> 
>>>> - section 3.2:
>>>> 
>>>> <oldtext>
>>>> Note that the sending node may transmit multiple
>>>> DATA_SEGMENT messages without necessarily waiting for the
>>>> corresponding ACK_SEGMENT responses.  This enables pipelining of
>>>> messages on a channel.
>>>> </oldtext>
>>>> 
>>>> <comment>
>>>> This is a too important property to just mention it on the side of
>>>> an example description. You should mention this in the protocol
>>>> overview. You should also mention that there is no explicit flow
>>>> control on the TCPCL layer.
>>>> </comment>
>>> 
>>> Agreed.
>>> 
>>>> - section 3.2:
>>>> 
>>>> <oldtext>
>>>>  However, interleaving data segments from different bundles is not
>>>>  allowed.
>>>> </oldtext>
>>>> 
>>>> <comment>
>>>> Again, this is too important to not mention it earlier.
>>>> </comment>
>>> 
>>> Agreed.
>>> 
>>>> -section 4:
>>>> 
>>>> <oldtext>
>>>> The manner in which a bundle node makes the decision to establish
>>>> such a connection is implementation-dependent.
>>>> </oldtext>
>>>> 
>>>> <comment>
>>>> I think you want to say that the implementation can decide, possibly
>>>> case-by-case, at runtime (unless it is fixed). Perhaps better so
>>>> say: "It is up to the implementation to decide how and when
>>>> connection setup is triggered. For example..."
>>>> </comment>
>>> 
>>> Agreed.
>>> 
>>>> -section 4:
>>>> <oldtext>
>>>> Therefore, the node MUST retry
>>>> the connection setup only after some delay and it SHOULD use a
>>>> (binary) exponential backoff mechanism to increase this delay in case
>>>> of repeated failures.
>>>> </oldtext>
>>>> 
>>>> <comment>
>>>> You should specify what is meant by "some delay". Is it completely
>>>> up to the implementation? Do you want to RECOMMEND a minimum
>>> delay?
>>>> </comment>
>>> 
>>> How about recommending 1 second minimum?
>>> 
>>>> - section 4.1:
>>>> 
>>>> <oldtext>
>>>> magic:  A four byte field that always contains the byte sequence 0x64
>>>>      0x74 0x6e 0x21, i.e., the text string "dtn!".
>>>> </oldtext>
>>>> 
>>>> 
>>>> <newtext>
>>>> magic:  A four byte field that always contains the byte sequence 0x64
>>>>      0x74 0x6e 0x21, i.e., the text string "dtn!" in US-ASCII.
>>>> </newtext>
>>> 
>>> Agreed.
>>> 
>>>> - section 4.1:
>>>> 
>>>> <oldtext>
>>>> version:  A one byte field value containing the current version of
>>>>      the protocol.
>>>> </oldtext>
>>>> 
>>>> 
>>>> <newtext>
>>>> version:  A one byte field value containing the value 3 (current version of
>>>>      the protocol).
>>>> </newtext>
>>> 
>>> Agreed.
>>> 
>>>> - section 5.2
>>>> 
>>>> <oldtext>
>>>> However, a node MUST be able to receive a bundle that has been
>>>> transmitted in any segment size.
>>>> </oldtext>
>>>> 
>>>> <comment>
>>>> 
>>>> How feasible is this, for example for constrained devices? Even if a
>>>> node does not intend to store and reassemble bundles, there may be
>>>> certain limits for the maximum size of segments that it can
>>>> receive. Has there been a discussion to make this
>>>> negotiable/configurable? How should a node react if it cannot
>>>> receive/process any more bytes for a transmitted segment?
>>>> </comment>
>>> 
>>> The intent here is not to override a node's intrinsic limitation on bundle sizes.
>>> The intent is that if a node is able to receive, over TCP, a bundle of size X with
>>> segment size Y, then it MUST also be able to do it with any segment size <= X.
>>> I'll adjust the text.
>>> 
>>>> - section 5.2
>>>> 
>>>> <oldtext>
>>>> Following the message header, the length field is an SDNV containing
>>>> the number of bytes of bundle data that are transmitted in this
>>>> segment.  Following this length is the actual data contents.
>>>> </oldtext>
>>>> 
>>>> 
>>>> <comment>
>>>> This should be mentioned earlier in section 5.2  </comment>
>>> 
>>> Agreed.
>>> 
>>>> - section 5.3
>>>> 
>>>> <oldtext>
>>>> To transmit an acknowledgment, a node first transmits a message
>>>> header with the ACK_SEGMENT type code and all flags set to zero, then
>>>> transmits an SDNV containing the cumulative length of the received
>>>> segment(s) of the current bundle.
>>>> </oldtext>
>>>> 
>>>> 
>>>> <newtext>
>>>> To transmit an acknowledgment, a node first transmits a message
>>>> header with the ACK_SEGMENT type code and all flags set to zero,
>>>> then transmits an SDNV containing the cumulative length in bytes of
>>>> the received segment(s) of the current bundle.
>>>> </newtext>
>>> 
>>> Agreed.
>>> 
>>>> - section 5.4
>>>> 
>>>> <oldtext>
>>>> Note: If a bundle transmission if aborted in this way, the receiver
>>>> may not receive a segment with the 'E' flag set to '1' for the
>>>> aborted bundle.  The beginning of the next bundle is identified by
>>>> the 'S' bit set to '1', indicating the start of a new bundle.
>>>> </oldtext>
>>>> 
>>>> <comment>
>>>> 
>>>> Should this be turned into a general rule? I.e.: "if a receiver
>>>> receives a segment for a new bundle without having seen the final
>>>> segment of a previous bundle, it SHOULD disregard all segments of
>>>> the incompletely received bundle."
>>> 
>>> I don't think so. The received segments are valid. The receiver can do
>>> whatever it wants with them.
>>> 
>>>> (wording may need some work)
>>>> 
>>>> It's probably good to use "SHOULD" here, because the node may
>>>> already have forwarded the segments...
>>>> </comment>
>>>> 
>>>> 
>>>> - section 6.1
>>>> 
>>>> <oldtext>
>>>> The format of the shutdown message is as follows:
>>>> 
>>>>                      1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
>>>>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>> |  0x5  |0|0|R|D| reason (opt)  | reconnection delay (opt)      |
>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>> 
>>>>             Figure 8: Format of bundle shutdown messages
>>>> 
>>>> </oldtext>
>>>> 
>>>> <comment>
>>>> Is it really efficient to have variable length messages here by
>>>> making the reason code optional? How about always requiring it and
>>>> then allow for a default value (0x00)?
>>>> </comment>
>>> 
>>> I think it's a backward compatibility wart that we need to live with.
>>> That is, earlier versions of the protocol did not send those two fields.
>>> (not 100% sure)
>>> 
>>>> - section 6.1
>>>> 
>>>> <oldtext>
>>>> If either node terminates a connection prematurely in this manner, it
>>>> SHOULD send a SHUTDOWN message and MUST indicate a reason code
>>> unless
>>>> the incoming connection did not include the magic string.
>>>> </oldtext>
>>>> 
>>>> <comment>
>>>> Why not send a reason like "illegal syntax"?
>>>> </comment>
>>> 
>>> Wasn't there talks of a draft registering a bunch of additional reason codes?
>>> 
>>>> - section 6.7
>>>> 
>>>> <comment>
>>>> 
>>>> Regarding the peer entity authentication issue, I think you have to
>>>> use a stronger statement, like "a node SHALL NO" use the endpoint
>>>> identifier conveyed in the TCPCL connection message to derive a peer
>>>> node's entity unless it can ascertain it via other means."
>>> 
>>> Agreed.
>>> 
>>>> If it is possible to do that through the Bundle Security Protocol,
>>>> you could be a bit more specific on how the Bundle Authentication
>>>> Block would be used. I assume one TCPCL peer node would become a
>>>> security source in an RFC 6257 sense?
>>>> 
>>>> BTW, you are using the term "Bundle Authentication Header" -- I
>>>> think it's "Bundle Authentication Block".
>>>> 
>>>> In general, it could be worthwhile stating that TCPCL does not
>>>> provide any security services and that RFC 6257's mechanisms should
>>>> be used.
>>> 
>>> Agreed.
>>> 
>>>> BTW, is the use of TLS for TCPCL defined or excluded? You may want
>>>> to say something about why it's not applicable
>>>> </comment>
>>> 
>>> Why wouldn't it be applicable? I think we *want* it to be applicable!
>>> 
>>>> - section 10.2
>>>> 
>>>> <oldtext>
>>>> [RFC6256]  Eddy, W. and E. Davies, "Using Self-Delimiting Numeric
>>>>            Values in Protocols", RFC 6256, May 2011.
>>>> </oldtext>
>>>> 
>>>> <comment>
>>>>  Isn't that a normative reference for this spec?
>>>> </comment>
>>> 
>>> No, because that's an informational RFC.
>>> 
>>>> EDITORIAL COMMENTS
>>>> ------------------
>>>> 
>>>> General:
>>>> 
>>>> - make usage and capitalization of Bundle Protocol (sometimes referred
>>>> to as "Bundling Protocol", "bundle protocol" etc.) consistent
>>> 
>>> Agreed.
>>> 
>>>> - section 2.1
>>>> <oldtext>
>>>>   Bundle payload --  A bundle payload (or simply "payload") is the
>>>>      application data whose conveyance to the bundle's destination is
>>>>      the purpose for the transmission of a given bundle.
>>>> </oldtext>
>>>> 
>>>> <comment>
>>>>   IMO this can be said in a clearer way: "... application
>>>>   data that is transmitted to a BP application at a Bundle
>>>>   Endpoint"?
>>>> </comment>
>>> 
>>> We should just remove this and refer to RFC 5050 section 3.1.
>>> 
>>>> - section 2.1:
>>>> <oldtext>
>>>> Bundle node --  A bundle node (or simply a "node") is any entity that
>>>>      can send and/or receive bundles.  The particular instantiation
>>>>      of this entity is deliberately unconstrained, allowing for
>>>>      implementations in software libraries, long-running processes,
>>>>      or even hardware.  One component of the bundle node is the
>>>>      implementation of a convergence layer adapter.
>>>> </oldtext>
>>>> 
>>>> <comment>
>>>>   I don't think the second sentence ("The particular
>>>>   instantiation...") is really needed.  This holds for most network
>>>>   elements these days.
>>>> </comment>
>>> 
>>> We should just remove this and refer to RFC 5050 section 3.1.
>>> 
>>>> - section 2.1:
>>>> <oldtext>
>>>> Convergence layer adapter --  A convergence layer adapter (CLA) sends
>>>>      and receives bundles utilizing the services of some 'native'
>>>>      link, network, or internet protocol.  This document describes
>>>>      the manner in which a CLA sends and receives bundles when using
>>>>      the TCP protocol for inter-node communication.
>>>> </oldtext>
>>>> 
>>>> <comment>
>>>>    Does it make make sense to define "Convergence Layer" first,
>>>>    before defining CLA? Is the CLA definition needed at all
>>>>    (assuming CL is defined)?
>>>> </comment>
>>> 
>>> We should just remove this and refer to RFC 5050 section 3.1.
>>> 
>>>> - section 2.2:
>>>> <oldtext>
>>>> TCPCL Connection --  [...] The lifetime of a TCPCL connection is one-to-one
>>>>      with the lifetime of an underlying TCP connection.
>>>> 	[...]
>>>> </oldtext>
>>>> 
>>>> <comment>
>>>>    "The lifetime of a TCPCL connection is bound to the
>>>>    lifetime of the underlying TCP connection."?
>>>> </comment>
>>> 
>>> Agreed.
>>> 
>>>> -section 4:
>>>> 
>>>> <oldtext>
>>>> Once a TCP connection is established, each node MUST immediately
>>>> transmit a contact header over the TCP connection.  The format of the
>>>> contact header is described in Section 4.1).
>>>> </oldtext>
>>>> 
>>>> <newtext>
>>>> Once a TCP connection is established, each node MUST immediately
>>>> transmit a contact header over the TCP connection.  The format of the
>>>> contact header is described in Section 4.1.
>>>> </newtext>
>>> 
>>> Agreed.
>>> 
>>>> - section 4.1:
>>>> 
>>>> <oldtext>
>>>> local EID:  An octet string containing the EID of some singleton
>>>>      endpoint in which the sending node is a member, in the canonical
>>>>      format of <scheme name>:<scheme-specific part>.  A eight byte
>>>>      EID is shown the clarity of the figure.
>>>> </oldtext>
>>>> 
>>>> 
>>>> <newtext>
>>>> local EID:  An octet string containing the EID of some singleton
>>>>      endpoint in which the sending node is a member, in the canonical
>>>>      format of <scheme name>:<scheme-specific part>.  A eight byte
>>>>      EID is shown for clarity of the figure.
>>>> </newtext>
>>> 
>>> Agreed.
>>> 
>>>> - section 4.2:
>>>> 
>>>> 
>>>> <oldtext>
>>>>      The reactive fragmentation enabled parameter is set to true iff
>>>>      the corresponding flag is set in both contact headers.
>>>> 
>>>>      The bundle refusal capability may only be used iff both peers
>>>>      indicate support for it in their contact header and segment
>>>>      acknowledgement has been enabled.
>>>> </oldtext>
>>>> 
>>>> 
>>>> <newtext>
>>>>      The reactive fragmentation enabled parameter is set to true iff
>>>>      the corresponding flag is set in both contact headers.
>>>> 
>>>>      The bundle refusal capability is set to true if the
>>>>      corresponding flag is set in both contact headers and if
>>>>      segment acknowledgment has been enabled.
>>>> </newtext>
>>>> 
>>>> <comment>
>>>> I'd raher use the same or similar wording to not irritate the implementer.
>>>> </comment>
>>> 
>>> Agreed.
>>> 
>>>> - section 5.1
>>>> 
>>>> <oldtext>
>>>> Table 2: TCPCL Header Types
>>>> </oldtext>
>>>> 
>>>> 
>>>> <newtext>
>>>> Table 2: TCPCL Message Types
>>>> </newtext>
>>> 
>>> Agreed.
>>> 
>>>> - section 5
>>>> 
>>>> <comment>
>>>> For the different subsections for the individual messages, please
>>>> use the message type names from table 2 in the headings, for
>>>> example: "Bundle Data Transmission (DATA_SEGMENT)". Also, I'd
>>>> recommend to align the order of the subsections with the order of
>>>> message types in table 2.
>>>> </comment>
>>> 
>>> Agreed.
>>> 
>>>> <comment>
>>>> I would also recommend to use a consistent structure for each of
>>>> the subsections, i.e., perhaps
>>>>   - purpose
>>>>   - syntax
>>>>   - procedures / node requirements
>>>> </comment>
>>> 
>>> Agreed.
>>> 
>>>> - section 5.3
>>>> 
>>>> <oldtext>
>>>> If so, then
>>>> the receiver MUST transmit a bundle acknowledgment header when it
>>>> successfully receives each data segment.
>>>> </oldtext>
>>>> 
>>>> 
>>>> <oldtext>
>>>> If so, then
>>>> the receiver MUST transmit a bundle acknowledgment message when it
>>>> successfully receives each data segment.
>>>> </oldtext>
>>> 
>>> Agreed.
>>> 
>>>> - section 5.6
>>>> 
>>>> <oldtext>
>>>> If no message (keepalive or other) has been received for at least
>>>> twice the keepalive interval, then either party may terminate the
>>>> session by transmitting a one byte message type code of SHUTDOWN (as
>>>> described in Table 2) and closing the TCP connection.
>>>> </oldtext>
>>>> 
>>>> 
>>>> <newtext>
>>>> If no message (keepalive or other) has been received for at least
>>>> twice the keepalive interval, then either party MAY terminate the
>>>> session by transmitting a one byte SHUTDOWN message  (as
>>>> described in Table 2) and by closing the TCP connection.
>>>> </newtext>
>>> 
>>> Agreed.
>>> 
>>>> - section 6.1
>>>> 
>>>> <oldtext>
>>>> In case acknowledgments have been
>>>> negotiated, it is advisable to acknowledge all received data segments
>>>> first and then shut down the connection.
>>>> </oldtext>
>>>> 
>>>> 
>>>> <newtext>
>>>> In case acknowledgments have been
>>>> negotiated, a node SHOULD  acknowledge all received data segments
>>>> first and then shut down the connection.
>>>> </newtext>
>>> 
>>> Agreed.
>>> 
>>>> - section 6.1
>>>> 
>>>> <oldtext>
>>>> This may, for example, be used to notify
>>>> that the node is currently not capable of or willing to communicate.
>>>> </oldtext>
>>>> 
>>>> <newtext>
>>>> This may, for example, be used to notify
>>>> that the node is currently not able or willing to communicate.
>>>> </newtext>
>>> 
>>> Agreed.
>>> 
>>>> - section 10.2
>>>> 
>>>> <oldtext>
>>>> [refs.dtnsecurity]
>>>>            Symington, S., Farrell, S., and H. Weiss, "Bundle Security
>>>>            Protocol Specification", Internet Draft, work in progress
>>>>            draft-irtf-dtnrg-bundle-security-03.txt, April 2007.
>>>> </oldtext>
>>>> 
>>>> <comment>
>>>>   This is RFC 6257.
>>>> </comment>
>>> 
>>> Agreed.
>>> 
>>> Simon
> 
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-interest