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

[Benjamin Kaduk <[e-mail]>]

Hi Scott,

On Fri, Oct 30, 2020 at 04:56:39PM +0000, Burleigh, Scott C (US 312B) wrote:
> Ben, would Magnus's suggestion address your Discuss?

To be honest, I'm not sure whether Magnus's latest suggestion is to both
change the ABNF and add discussion of the potential backwards compatibility
issues, or to leave the ABNF as it is in the -27 and add such discussion.

The ABNF in the -27 addresses the issue that I was unsure about.  Though,
given that there apparently remains some uncertainty, I am adding the ART
ADs to the "to:" line on this message in an attempt to have some authority
(pun intended) present.  (Very brief summary for Barry and Murray: the URI
"dtn:none" has been in use since at least RFC 5050 and is explicitly used
in this document, but prior to the -27 the dtn-uri ABNF construction in
this document did not allow for a "dtn:none" URI value.  Magnus seems to be
proposing that this would more properly be expressed as "dtn://none" to
match the typical URI structure, while acknowledging that there would be
backward compatibility issues with making such a change.)

> And is your other Discuss now addressed?

Yes, Ran's text looks good.  I will go update my ballot position shortly.

Thanks,

Ben

> 
> -----Original Message-----
> From: Magnus Westerlund <[e-mail]> 
> Sent: Friday, October 30, 2020 8:27 AM
> To: [e-mail]; scott.c.burleigh=[e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-26: (with DISCUSS and COMMENT)
> 
> 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 
> 
> 
> 
> > 
> > Scott
> > 
> > -----Original Message-----
> > From: Magnus Westerlund <magnus.westerlund=[e-mail]> 
> > Sent: Wednesday, October 28, 2020 1:10 AM
> > To: Burleigh, Scott C (US 312B) <[e-mail]>; [e-mail]
> > ; [e-mail]
> > Cc: [e-mail]; [e-mail]; [e-mail]; 
> > [e-mail]
> > Subject: Re: [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dtn-bpbis-26:
> > (with DISCUSS and COMMENT)
> > 
> > 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
> > > 
> > > ----------------------------------------------------------------------
> > > DISCUSS:
> > > ----------------------------------------------------------------------
> > 
> > ...
> > 
> > > (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