Re: [dtn] [EXTERNAL] Alexey Melnikov's Discuss on draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)

["Alexey Melnikov" <[e-mail]>]

Hi Scott,

Thank you for your responses. My replies below:

On Fri, Feb 7, 2020, at 5:19 PM, Burleigh, Scott C (US 312B) wrote:
> Thanks.  Some responses in-line below.
> 
> Scott
> 
> -----Original Message-----
> From: Alexey Melnikov via Datatracker <[e-mail]> 
> Sent: Friday, February 7, 2020 6:09 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Fred Templin 
> <[e-mail]>; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]
> Subject: [EXTERNAL] Alexey Melnikov's Discuss on 
> draft-ietf-dtn-bpbis-22: (with DISCUSS and COMMENT)
> 
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-dtn-bpbis-22: Discuss
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I am looking forward for this document to be finished and approved as 
> an RFC.
> Before I can recommend this, I have several DISCUSS points and comments 
> that I would like to address:
> 
> 1) Routing decisions, discovery of endpoints to contact for forwarding 
> and retry strategies are listed as out-of-scope for this document. This 
> is not sufficient for writing an interoperable implementation, unless 
> there is a separate document that provides such details.
> 
> **********
> 	(From my February 6 , 8:56 AM response)
> 
> Absolutely, we anticipate that over time a wide variety of strategies 
> for topology discovery and route selection will be developed to support 
> BP forwarding in a variety of operational scenarios.  Most 
> implementations to date have simply used static routing tables, just to 
> enable interoperability testing.  One published standard for BP routing 
> does exist, but it's not yet an IETF standard: the Schedule-Aware 
> Bundle Routing "Blue Book" published by the Consultative Committee for 
> Space Data Systems (https://public.ccsds.org/Pubs/734x3b1.pdf) is 
> currently in operational use on-board the International Space Station.  
> SABR was developed in the context of version 6 of the Bundle Protocol, 
> not the current draft, but it is equally applicable to BPv7 since the 
> representation of endpoint IDs has not changed.
> 
> BP typically relies on the retry strategies of the transport 
> ("convergence layer") protocols it runs over, in hop-by-hop fashion, as 
> end-to-end retransmission is suboptimal in a delay-tolerant network.  
> One element of retry strategy that is identified in the BP draft, 
> though, is this: as noted in Step 5 of section 5.4, failure in 
> transmission at the convergence layer may cause the bundle protocol 
> agent to initiate another attempt to forward the bundle, possibly using 
> a different route and/or different transport protocol.
> 
> In addition, a "custody transfer" mechanism for retry at the bundle 
> layer itself is defined in the Bundle-in-Bundle Encapsulation protocol 
> specification, a separate Internet Draft that we hope to advance to 
> IESG review soon.  (The most recent edition of that draft expired a 
> couple of days ago, and I haven't yet had time to re-post it.)
> 
> As noted in section 8, three implementations of BPv7 have been 
> announced to date, and two of those implementations -- PyDTN and uPCN 
> -- have been shown to be interoperable.
> 
> **********
> 
> Below I describe 3 relevant places in the text and suggest some 
> possible ways of addressing my DISCUSS:
> 
> 5.4. Bundle Forwarding
> 
>    Step 2: The bundle protocol agent MUST determine whether or not
>    forwarding is contraindicated (that is, rendered inadvisable) for
>    any of the reasons listed in Figure 4. In particular:
> 
>      . The bundle protocol agent MAY choose either to forward the
>         bundle directly to its destination node(s) (if possible) or to
>         forward the bundle to some other node(s) for further
>         forwarding. The manner in which this decision is made may
>         depend on the scheme name in the destination endpoint ID and/or
> 
> Lack of this information (how node to forward to are discovered) would 
> prevent interoperability. (By comparison, SMTP specification which has 
> somewhat similar design contains information about how next nodes to 
> forward to are selected.)
> 
> 		This information is provided in other documents, such as the CCSDS 
> Schedule-Aware Bundle Routing standard.

Adding a reference here would address my concern about the above paragraph.

> I think you need to create a new section in this document specifying 
> requirements on URI scheme documents and include this as a MUST level 
> requirement there. (If you already have a document that does this, you 
> can just normatively point to it.)
> 
> 		Can you please explain what you mean by "requirements on URI scheme 
> documents"?
> 		I don't know of any requirements on URI scheme documents that are 
> implied by this specification.  Can you give an example?

When a new URI scheme is registered for use with DTN (to get a new scheme specific number), a document describing this registration needs to be written. Let's imagine that I want to use "mailto:" URIs with DTN. In the document describing use of mailto: with DTN I would describe how routing is going to be performed. This might be something like this:

   When "mailto:" URIs are used with BPv7, SMTP protocol [RFC 5321] would be used for convergence layer. Location of the next node is done by using standard SMTP mechanism which is use of MX DNS records on the domain extracted from the right hand side of mailto: address.

(The above text happens to cover both routing and discovery of a next node to forward to by referencing SMTP.)


So the section with requirements on use of URI schemes with DTN would have something like:

When registering a new URI scheme with BPv7, the document registering the URI scheme MUST describe how URIs are used for next forwarding node location discovery. Such document MUST also define whether the URI scheme depends on any specific convergence layer(s).

Does this help?

>         on other state but in any case is beyond the scope of this
>         document. If the BPA elects to forward the bundle to some other
>         node(s) for further forwarding but finds it impossible to
>         select any node(s) to forward the bundle to, then forwarding is
>         contraindicated.
> 
>      . Provided the bundle protocol agent succeeded in selecting the
>         node(s) to forward the bundle to, the bundle protocol agent
>         MUST subsequently select the convergence layer adapter(s) whose
>         services will enable the node to send the bundle to those
>         nodes.  The manner in which specific appropriate convergence
>         layer adapters are selected is beyond the scope of this
>         document.
> 
> Similar to the above: lack of description of how convergence layers are 
> discovered (for example this might include discovery using DNS or 
> something
> else) or, alternatively, a mandatory to implement convergence layer 
> would affect interoperability. I think you need to add this as a 
> requirement to section 7 ("Services Required of the Convergence Layer").
> 
> 		Adding a mandatory-to-implement convergence layer adapter in section 
> 7 is an excellent idea.
> 		A specification for the TCP convergence-layer adapter is being 
> proposed concurrently with the BPv7 and BPsec specifications.
> 		If the Working Group agrees, we can simply reference that 
> specification in section 7.

Great.

> Also having some (even non normative) information about which 
> convergence layer to select if multiple are available would be useful.
> 
>         If the agent finds it impossible to select any
>         appropriate convergence layer adapter(s) to use in forwarding
>         this bundle, then forwarding is contraindicated.
> 
>    Step 5: When all selected convergence layer adapters have informed
>    the bundle protocol agent that they have concluded their data
>    sending procedures with regard to this bundle, processing may depend
>    on the results of those procedures.  If completion of the data
>    sending procedures by all selected convergence layer adapters has
>    not resulted in successful forwarding of the bundle (an
>    implementation-specific determination that is beyond the scope of
>    this specification), then the bundle protocol agent MAY choose (in
>    an implementation-specific manner, again beyond the scope of this
>    specification) to initiate another attempt to forward the bundle.
> 
> Similar to the above: retries affect interoperability and should be 
> documented as description of a convergence layer document.
> I think you need to add this as a requirement to section 7 ("Services 
> Required of the Convergence Layer").
> 
> 		I think mandating implementation of TCPCL in section 7 would address 
> this issue.

Good.

>    In that event, processing proceeds from Step 4 of Section 5.4.
> 
> 2) As pointed out by Benjamin Schwartz:
> 
> In Section 5.4.2
> 
> Consistency: This section relies on the presence of a Previous Node 
> block, but nothing in the forwarding procedure instructs any agent to 
> add a Previous Node block.
> 
> 		Right, Ben Kaduk pointed this out as well.  Language will be added in 
> version 23 of the draft.
> 
> Correctness: If two nodes both opt to return failed bundles, how are 
> they to avoid a ping-pong loop?
> 
> 		But on what basis would you terminate the ping pong, since on one of 
> those cycles a way out of the loop might appear?
> 		I think the answer is that the bundle lifetime and hop count 
> mechanisms will eventually cause the bundle to be destroyed, stopping 
> the routing loop.

Fair enough. I agree that hop count should be sufficient. So it would be worth pointing this out in the document.

> 3) As pointed out by Benjamin Schwartz:
> 
> In Section 5.6
> 
> Error handling: What about CBOR parsing failures?
> 
> 		A CBOR parsing failure would constitute a malformation of the block; 
> Step 3 of 5.6 explains how block malformations are handled.

It was not clear to me that the current text covers this. Step 3 mostly talks about CRC. If the following text was supposed to cover invalid CBOR:

 If any block of the bundle is malformed according to this specification ...

then I suggest you clarify:

 If any block of the bundle is malformed according to this specification (including syntactically invalid CBOR) ...

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> **********************************************************************
> * Note, that I am conducting an experiment when people aspiring to be*
> * Area Directors get exposed to AD work ("AD shadowing experiment"). *
> * As a part of this experiment they get to review documents on IESG  *
> * telechats according to IESG Discuss criteria document and their    *
> * comments get relayed pretty much verbatim to relevant editors/WGs. *
> * As an AD I retain responsibility in defending their position when  *
> * I agree with it.                                                   *
> * Recipients of these reviews are encouraged to reply to me directly *
> * about perceived successes or failures of this experiment.          *
> **********************************************************************
> 
> I also have some comments on Benjamin's comments below marked with "[[Alexey]]:"
> 
> The following comments were provided by Benjamin Schwartz <[e-mail]>:
> 
> Benjamin would have balloted *DISCUSS* on this document. He wrote:
> This draft’s content seems sound but the text is difficult to 
> understand and needs some editorial improvements.
> 
> ## Abstract
> 
> Nit: Abstract should be before status.
> 
> 		The document was prepared using Joe Touch's  
> 2-Word-v2.0.template.dot, and it passes the idnits check. 

I wouldn't worry too much about this, this can be handled by RFC Editor. I just wanted to include Benjamin's comments pretty much verbatim.

> Nit: “specification for Bundle Protocol” -> “for the Bundle Protocol”.
> 
> 		Sure.
> 
> ## Section 1
> 
> Title: If this document doesn’t describe the operation, routing, or 
> management of bundles, maybe it doesn’t describe a complete protocol.  
> Consider retitling to “Bundle Protocol Version 7: Format and 
> Architecture”
> 
> [[Alexey]]: This relates to my DISCUSS points, but my DISCUSS position 
> is stronger than this statement.
> 
> 		Please see my response to the DISCUSS position.
> 		I would note that RFC 791 doesn't include procedures for making 
> routing decisions (absent source routing) or retrying transmissions.

But there are other documents that do. They are required to implement an interoperable system.

To give you an example of why specifying retry behaviour is important:

a) one system implements no retries. As you don't specify that it is illegal, it is legal.
b) another system always retries once and only once. Again, as you don't specify that it is illegal, it is legal.

Systems a) and b) are not going to be interoperable.

I don't think you need to require a specific number of retries, but maybe specify that at least N retries should be attempted (unless the bundle expires before that) and maybe specify some minimum time period for retries.

> ## Section 4.1.3
> 
> Nit: It would be clearer to move the reserved and unassigned flags to 
> an IANA considerations section, here and throughout.
> 
> 		They appear in the IANA considerations section as well.
> 
> ## Section 4
> 
> Phrasing: “The last item of the array ... SHALL be a CBOR "break" stop 
> code.”
>  This seems like a misuse of the word “item”.  I would suggest “The 
> array SHALL be terminated by a CBOR “break” stop code.”  Similarly in 
> Section 4.2.1.
> 
> 		Good catch, will fix this.
> 
> ## Section 4.1.4
> 
> Clarity: The “(Boolean)” specifiers seem redundant.  What is a non-boolean flag?
> 
> Clarity: The two lists here seem redundant.  Can they be collapsed?
> 
> 		Okay.
> 
> Clarity: The phrasing “...the value of the "Transmit status report if 
> block can't be processed" flag in every canonical block…” suggests that 
> these flags should be named or numbered before attempting to describe 
> them.
> 
> ## Section 4.1.5.1
> 
> These two sentences seem contradictory:
> 
> * “Any scheme conforming to [URIREG] may be used in a bundle protocol 
> endpoint ID.” * “The first item of the array SHALL be the code number 
> identifying the endpoint's URI scheme [URI], as defined in the registry 
> of URI scheme code numbers”
> 
> Please rephrase.
> 
> 		Other reviewers have remarked on this as well; revision will appear 
> in version 23 of the draft.
> 
> [[Alexey]]: This is similar to Roman's DISCUSS.
> 
> ## Section 5.4.2
> 
> Consistency: This section relies on the presence of a Previous Node 
> block, but nothing in the forwarding procedure instructs any agent to 
> add a Previous Node block.
> 
> 		Yes, will be addressed in version 23.
> 
> Correctness: If two nodes both opt to return failed bundles, how are 
> they to avoid a ping-pong loop?
> 
> 		Please see my response to the DISCUSS item.
> 
> [[Alexey]]: I included these in the DISCUSS portion of my ballot.
> 
> ##Section 5.6
> 
> Error handling: What about CBOR parsing failures?
> 
> 		Please see my response to the DISCUSS item.
> 
> [[Alexey]]: I included these in the DISCUSS portion of my ballot.
> 
> ## Section 5.8
> 
> Clarity: The insistence, here and earlier, that a bundle is only 
> fragmented into two packets, and that this can then be performed 
> recursively, seems unhelpful.  Bundles can be fragmented into 
> arbitrarily many pieces, and this binary subdivision concept is not 
> actually present in the protocol.  I suggest removing it from the text 
> as well.
> 
> 		Why is this unhelpful?  It's the formal procedure by which bundles 
> are fragmented.  Let's not remove it.

I think saying that a bundle can only be fragmented into 2 pieces is a lie, because the algorithm says that it can be fragmented into more than 2. I found this text to be confusing as well. Just say that it can be fragmented into 2 or more non overlapping fragments.

> ## Section 6.1
> 
> Formatting: This table is excessive for a single value.
> 
> 		We anticipate additional values in the future.  Let's have the table.
> 
> Clarity: The text specifies the contents twice, which is unhelpful for 
> comprehension.
> 
> 		I think it's actually helpful.  The 3-line overview introduces the 
> concept of an administrative record and the last 3 paragraphs mandate 
> the representation.

Ok.

> ## Section 10
> 
> Formatting: The extra line breaks in the vertical dividers are 
> distracting. Please fill them in or remove the breaks if possible.
> 
> 		I am hoping this is something that the RFC editors handle.

Ok.

Best Regards,
Alexey