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

[Magnus Westerlund <[e-mail]>]

On Wed, 2020-10-28 at 01:40 +0000, Burleigh, Scott C (US 312B) wrote:
> Responses in-line below.
> 
> Scott
> 
> -----Original Message-----
> From: Benjamin Kaduk via Datatracker <[e-mail]> 
> Sent: Friday, October 23, 2020 6:24 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; Fred
> Templin <[e-mail]>; [e-mail]
> Subject: [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-26: (with
> DISCUSS and COMMENT)
> 
> 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://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
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> 
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
>  
> 
> 
> 
> ----------------------------------------------------------------------
> 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.
> 
> 	Agreed.  Please see revisions to section 9.0 of draft -27, language
> provided by Ran Atkinson.
> 
> (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.
> 
> 	Good point.  Revisions are noted in 4.1.5.1.1 of draft -27.

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