Subject: [dtn] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-26: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 23 Oct 2020 18:23:46 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dtn-bpbis-26: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[Retaining (1) as placeholder for ongoing discussions; (11) is new]

(1) It's not clear to me that we should be defining new
(near-)application-layer protocols on the standards track without
mandatory security mechanisms.  Even draft-ietf-dtn-bpsec defines a
"BPSec threat model" that is largly the same as the RFC 3552 threat
model, in which the network is completely untrusted and to provide
end-to-end communications we must supply additional security mechanisms,
yet BPSec is not required to implement or use.  I could perhaps see room
for allowing waypoint nodes that do not act as endpoints to remain
security-unaware, but the justification for security-unaware endpoints
seems quite lacking.

(11) The ABNF for the "dtn" URI scheme does not seem to allow for a URI
of "dtn:none".  We may need to consult the ART ADs to determine how
problematic this is, as this is a bit outside my area of expertise.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 4.1.5.1

   The second item of the array SHALL be the applicable CBOR
   representation of the scheme-specific part (SSP) of the EID, defined
   as noted in the specification for the EID's URI scheme.

I think this would be in the document that makes the registration in the
"URI scheme code numbers for Bundle Protocol" registry, which is not
necessarily the same document that has the specification for the EID's
URI scheme.  (E.g., that seems to be the case for the "ipn" scheme
already, since we are leaving RFC 6260 as the reference for the URI
scheme registration but have the scheme code number for it in this
document.)

Section 4.1.5.1.1

[I note that the way the ABNF is currently written will cause endpoint
ID URIs to have a trailing slash.  This is not inherently problematic,
of course, but may not be aesthetically preferred to everyone.]

Section 4.2.2

   of the bundle sequence count never be reset to zero. Note that, in
   general, the creation of two distinct bundles with the same source
   node ID and bundle creation timestamp may result in unexpected
   network behavior and/or suboptimal performance. The combination of
   source node ID and bundle creation timestamp serves to identify a
   single transmission request, enabling it to be acknowledged by the
   receiving application (provided the source node ID is not the null
   endpoint ID).

Similar text appeared up in Section 4.1.7 already; we may not need it in
both places.

Section 5.2

Technically the text we have about source node ID being the "EID of a
singleton endpoint whose only member is" is still accurate/workable even
though we have nailed down more tightly the definition of "node ID",
though we might consider just saying "node ID" here to make things a bit
more deterministic.

Section 5.4

   forward the bundle.  In that event, processing proceeds from Step 4
   of Section 5.4.  The minimum number of times a given node will

(This is Section 5.4, so we could probably just say "proceeds from Step
4".)

   initiate another forwarding attempt for any single bundle in this
   event (a number which may be zero) is a node configuration parameter
   that MUST be exposed to other nodes in the network to the extent
   that this is required by the operating environment.

(This caveats for this "MUST" are vague enough that it may be better as
just a "must".)

Section 5.6

   has an attached CRC.  If any block of the bundle is malformed
   according to this specification (including syntactically invalid
   CBOR), or if any block has an attached CRC and the CRC computed for

(side note) I note that draft-ietf-cbor-7049bis introduces a new
hierarchical ladder of classes of (in)validity and "well-formed"-ness.  I
think this description stands alone just fine, but it could potentially
adopt the 7049bis terminology, too.

Section 5.7

   If this procedure results in reassembly of the entire original
   application data unit, processing of the fragmentary bundle whose
   payload has been replaced by the reassembled application data unit
   (whether this bundle or a previously received fragment) proceeds

(nit) this wording is a little awkward, since we don't define
"fragmentary bundles" until §5.8.

Section 9

I think we should have a brief note that "[t]his protocol makes use of
absolute timestamps for several purposes.  Provisions are included for
nodes without accurate clocks to retain most of the protocol
functionality, but nodes that are unaware that their clock is inaccurate
may exhibit unexpected behavior."

Section 10.7

We probably want to have a clause about "orignally documented in RFC
5050" the way that we do for the "ipn" scheme in Section 10.8.
And maybe also to have this document listed as the reference, since we
have a lot more text (befitting a permanent, rather than provisional,
scheme registration) about the scheme in this document.

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Wed, 28 Oct 2020 01:40:42 +0000

Responses in-line below.

Scott

-----Original Message-----
From: Benjamin Kaduk via Datatracker <[email-masked]> 
Sent: Friday, October 23, 2020 6:24 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Fred Templin <[email-masked]>; [email-masked]
Subject: [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-26: (with DISCUSS and COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to https://urldefense.us/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!PvBDto6Hs4WbVuu7!fwsY5qUvTPG119i9Li6hLuTzMEO1t1WM7w4jZF1omDrrlKh7UXDejoFmm0-SxQrqxFSiTjcaPUQ$
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://urldefense.us/v3/__https://datatracker.ietf.org/doc/draft-ietf-dtn-bpbis/__;!!PvBDto6Hs4WbVuu7!fwsY5qUvTPG119i9Li6hLuTzMEO1t1WM7w4jZF1omDrrlKh7UXDejoFmm0-SxQrqxFSikhMvBXo$ 

	Agreed.  Please see revisions to section 9.0 of draft -27, language provided by Ran Atkinson.

	Good point.  Revisions are noted in 4.1.5.1.1 of draft -27.

Section 4.1.5.1

	Okay.

Section 4.1.5.1.1

Section 4.2.2

Section 5.2

Section 5.4

	Okay.

	Okay.

Section 5.6

Section 5.7

	Okay.

Section 9

	Okay.

Section 10.7

	Actually the dtn scheme was not documented in RFC 5050.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 28 Oct 2020 08:10:18 +0000

On Wed, 2020-10-28 at 01:40 +0000, Burleigh, Scott C (US 312B) wrote:
> Cc: [email-masked]; [email-masked]; [email-masked]; Fred
> Templin <[email-masked]>; [email-masked]
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to 
> https://protect2.fireeye.com/v1/url?k=d875d15e-86d57f93-d87591c5-866132fe445e-c223f3e8e1668b11&q=1&e=8dccffdf-8a09-40aa-a341-1fb9818bccee&u=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html__%3B%21%21PvBDto6Hs4WbVuu7%21fwsY5qUvTPG119i9Li6hLuTzMEO1t1WM7w4jZF1omDrrlKh7UXDejoFmm0-SxQrqxFSiTjcaPUQ%24
https://protect2.fireeye.com/v1/url?k=a2fc906f-fc5c3ea2-a2fcd0f4-866132fe445e-639e251621e9c1a1&q=1&e=8dccffdf-8a09-40aa-a341-1fb9818bccee&u=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dtn-bpbis%2F__%3B%21%21PvBDto6Hs4WbVuu7%21fwsY5qUvTPG119i9Li6hLuTzMEO1t1WM7w4jZF1omDrrlKh7UXDejoFmm0-SxQrqxFSikhMvBXo%24

I think it is a no-go. This change makes it incompatible with the ABNF for URIs
in general (RFC3986). I think a potential fix is to reserve the "none" as a real
node name changing the dtn-uri to say:

OLD:
dtn-uri = "dtn:" ("none"/dtn-hier-part)

NEW: 

dtn-uri = "dtn:" ("//none" / dtn-hier-part)

Or somethign equivalent. I think it could be reserved in the node-name rule also
and that may look clearer. 

Although this is a compatibility impacting change the parser part would be fine
and none changed compared to before. So it is only BPv7 compatible
implementations that would do the special interpreation of none. 

Cheers

Magnus

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Wed, 28 Oct 2020 13:43:37 +0000

Magnus, I don't understand why this is a problem.  Isn't "dtn:none" simply a URI whose scheme is "dtn" and whose hier-part is the path-rootless "none"?  The leading characters "//" are prohibited when the path contains no authority, as is the case here.

Scott

-----Original Message-----
From: Magnus Westerlund <magnus.westerlund=[email-masked]> 
Sent: Wednesday, October 28, 2020 1:10 AM
To: Burleigh, Scott C (US 312B) <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-26: (with DISCUSS and COMMENT)

> draft-ietf-dtn-bpbis-26: Discuss

...

OLD:

NEW: 

Cheers

Magnus

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 30 Oct 2020 15:27:17 +0000

Hi Scott and Ben,

On Wed, 2020-10-28 at 13:43 +0000, Burleigh, Scott C (US 312B) wrote:
> Magnus, I don't understand why this is a problem.  Isn't "dtn:none" simply a
> URI whose scheme is "dtn" and whose hier-part is the path-rootless
> "none"?  The leading characters "//" are prohibited when the path contains no
> authority, as is the case here.

Sorry, didn't read the complete ABNF so I the missed the path aspect of it.

I think I understand what Ben discuss is about. So RFC 5050 are explicitly
talking about "dtn:none" as the null endpoint ID. However, the earlier versions
of the definition for the updated URI ABNF syntax in BPbis did not include that
aspect. I will note that RFC 5050 do not contain any ABNF for the "dtn" scheme
what I can find.

So thus "dtn:none" is within expected usage, but maybe what really is missing is
a discussion of the potential backwards compatibility issues due to the
tightening of the URI scheme syntax. Maybe Section 4.1.5.1.1 needs to have a
paragraph on what has been changed from the provisional registration. 

Cheers

Magnus 

> > Subject: [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-26:
> > (with
> > DISCUSS and COMMENT)
> >

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 30 Oct 2020 16:56:39 +0000

Ben, would Magnus's suggestion address your Discuss?

And is your other Discuss now addressed?

Scott

-----Original Message-----
From: Magnus Westerlund <[email-masked]> 
Sent: Friday, October 30, 2020 8:27 AM
To: [email-masked]; scott.c.burleigh=[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-26: (with DISCUSS and COMMENT)

Hi Scott and Ben,

Cheers

Magnus