Subject: [dtn] IANA section on bpbis

From: "Marc Blanchet" <[email-masked]>
Date: Mon, 21 Oct 2019 10:53:33 -0400

Please find my comments on the IANA section of bpbis. PDF and txt to 
help see the comments.

Regards, Marc.

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Tue, 22 Oct 2019 22:22:57 +0000

Hi, Marc.  Thanks for putting so much time and care into these proposals.

You suggest that that section 10.6 should simply be removed because there is already a registry of URI schemes.  Certainly a registry of URI schemes exists, but numeric codes identifying those schemes are not part of that registry's definition.  Do you propose that we request that URI scheme type code (which BPbis requires) be added as another column of the URI schemes registry?  If not, how else would you propose that we proceed?

You are correct that the "dtn" URI scheme is already registered.  The purpose of adding that scheme definition in the BPbis specification is to provide a better reference, since the current reference is simply to RFC5050, which does not actually include any formal definition of the "dtn" scheme.  Are you saying that no formal definition of the "dtn" scheme is needed?

All of your other proposals seem fine to me.  Magnus, do you agree?

Scott

-----Original Message-----
From: Marc Blanchet <[email-masked]> 
Sent: Monday, October 21, 2019 7:54 AM
To: [email-masked]; Burleigh, Scott C (US 312B) <[email-masked]>
Cc: DTN WG <[email-masked]>
Subject: [EXTERNAL] IANA section on bpbis

Please find my comments on the IANA section of bpbis. PDF and txt to help see the comments.

Regards, Marc.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 23 Oct 2019 09:51:27 +0000

Hi,

I think there are two reasons for having the BPbis document perform IANA actions
on the dtn URI scheme registration. 

First is to change the provisional regisrration to a permanent one. Secondly to
provide a good reference to where the URI is actually defined properly. 

I would change the heading of the section 10.7 to remove "new" and change the
first sentence to say update the registration. 

Cheers

Magnus

On Tue, 2019-10-22 at 22:22 +0000, Burleigh, Scott C (US 312B) wrote:
> You suggest that that section 10.6 should simply be removed because there is
> already a registry of URI schemes.  Certainly a registry of URI schemes
> exists, but numeric codes identifying those schemes are not part of that
> registry's definition.  Do you propose that we request that URI scheme type
> code (which BPbis requires) be added as another column of the URI schemes
> registry?  If not, how else would you propose that we proceed?
> 
> You are correct that the "dtn" URI scheme is already registered.  The purpose
> of adding that scheme definition in the BPbis specification is to provide a
> better reference, since the current reference is simply to RFC5050, which does
> not actually include any formal definition of the "dtn" scheme.  Are you
> saying that no formal definition of the "dtn" scheme is needed?
> 
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 23 Oct 2019 11:23:50 +0000

Hi,

I have reviewed your proposal Marc. I think most of it works but there are  few
things I do wonder over or think should be addressed. 

10.6: This is a BP specific registry. As this encodes the URI schemes into the
protocol in a short form. This is not the same as the URI scheme registry. 

Thus, I don't see how it can be skipped. 

But, maybe the name of the registry should be "Bundle Protocol URI Scheme Type
Registry".

10.7 I already responded seperately to Scott's question. But, I think the WG do
need to update the IANA Registration of the DTN URI scheme considering that it
is provisional and lacks a correct reference to its actual syntactical
definition. 

Cheers

Magnus Westerlund

---

From: "Marc Blanchet" <[email-masked]>
Date: Wed, 23 Oct 2019 13:45:17 +0200

Magnus and Scott,
  all fine, please proceed!

  Scott, please make sure to review not only the IANA Considerations 
section, but also the text in the referred sections so everything is in 
sync.

Marc.

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Wed, 23 Oct 2019 22:35:11 +0000

On re-reading these proposals for merging registries more closely, I realize that they actually constitute significant changes to the BPv7 protocol specification.  Notably, the proposal to merge the bit flag values for bundle processing control flags would require that each BPv7 primary block contain a 3-byte control flags field -- rather than a 2-byte field -- to accommodate 6 bits of BPv6 class of service indication that the WG has agreed not to include in the BP specification; we will be wasting 1 byte of every bundle to preserve bit flag position compatibility with RFC 5050.

Also the block numbers assigned to extension blocks are changed for compatibility with RFC 5050; not a huge deal, but this will temporarily break all existing implementations of BPv7.  (The other changes are less disruptive.)

I can certainly go ahead and make all these changes, but I want to confirm with the WG that this is what we want to do.

Scott

-----Original Message-----
From: Marc Blanchet <[email-masked]> 
Sent: Wednesday, October 23, 2019 4:45 AM
To: Magnus Westerlund <[email-masked]>; Burleigh, Scott C (US 312B) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [dtn] IANA section on bpbis

Magnus and Scott,

  Scott, please make sure to review not only the IANA Considerations section, but also the text in the referred sections so everything is in sync.

Marc.

On 23 Oct 2019, at 13:23, Magnus Westerlund wrote:
> Hi,
>
> I have reviewed your proposal Marc. I think most of it works but there 
> are  few things I do wonder over or think should be addressed.
>
>

---

From: "Marc Blanchet" <[email-masked]>
Date: Thu, 24 Oct 2019 01:11:13 +0200

On 24 Oct 2019, at 0:35, Burleigh, Scott C (US 312B) wrote:

> On re-reading these proposals for merging registries more closely, I 
> realize that they actually constitute significant changes to the BPv7 
> protocol specification.  Notably, the proposal to merge the bit flag 
> values for bundle processing control flags would require that each 
> BPv7 primary block contain a 3-byte control flags field -- rather than 
> a 2-byte field -- to accommodate 6 bits of BPv6 class of service 
> indication that the WG has agreed not to include in the BP 
> specification; we will be wasting 1 byte of every bundle to preserve 
> bit flag position compatibility with RFC 5050.

I think one byte is not a big deal. It also provides more room for 
future assignments. Considering that I’ve seen DTN bundle payloads 
containing non-compressed XML or deployments sending Video over RTP over 
DTN, I think this one byte is not an issue.

>
> Also the block numbers assigned to extension blocks are changed for 
> compatibility with RFC 5050; not a huge deal, but this will 
> temporarily break all existing implementations of BPv7.  (The other 
> changes are less disruptive.)

well. In fact, the proposed numbers by the author in an internet-draft 
are never garanteed until IANA creates/updates the registry when the RFC 
is in the RFC-editor queue (i.e. after IESG approval). Changing an enum 
value in an implementation is a question of one minute. There is to my 
knowledge no deployment of BP7 yet, nor commercial products of BP7. 
However, having a coherent set of enum values for both BP6 and BP7 is to 
me a great advantage for implementations.

>
> I can certainly go ahead and make all these changes, but I want to 
> confirm with the WG that this is what we want to do.

let’s see what others think.

Marc, as individual.

> To: Magnus Westerlund <[email-masked]>; Burleigh, 
> Scott C (US 312B) <[email-masked]>
> section, but also the text in the referred sections so everything is 
> in sync.
>
> Marc.
>
>> need to update the IANA Registration of the DTN URI scheme 
>> considering
>> that it

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Thu, 24 Oct 2019 05:00:33 +0000

Personally, I don't see a coherent set of enum values for the two specifications as a significant advantage, as mapping between the two should be trivial and is in any case a very minor aspect of gatewaying between the protocols.  But I will of course go with whatever the WG decides.

Scott

-----Original Message-----
From: Marc Blanchet <[email-masked]> 
Sent: Wednesday, October 23, 2019 4:11 PM
To: Burleigh, Scott C (US 312B) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [EXTERNAL] [dtn] IANA section on bpbis

> bit flag position compatibility with RFC 5050.

I think one byte is not a big deal. It also provides more room for future assignments. Considering that I’ve seen DTN bundle payloads containing non-compressed XML or deployments sending Video over RTP over DTN, I think this one byte is not an issue.

> changes are less disruptive.)

well. In fact, the proposed numbers by the author in an internet-draft are never garanteed until IANA creates/updates the registry when the RFC is in the RFC-editor queue (i.e. after IESG approval). Changing an enum value in an implementation is a question of one minute. There is to my knowledge no deployment of BP7 yet, nor commercial products of BP7. 
However, having a coherent set of enum values for both BP6 and BP7 is to me a great advantage for implementations.

Marc, as individual.

>> I have reviewed your proposal Marc. I think most of it works but 
>> there are  few things I do wonder over or think should be addressed.
>>
>>

---

From: "Marc Blanchet" <[email-masked]>
Date: Thu, 24 Oct 2019 08:47:56 +0200

On 24 Oct 2019, at 7:00, Burleigh, Scott C (US 312B) wrote:

> Personally, I don't see a coherent set of enum values for the two 
> specifications as a significant advantage, as mapping between the two 
> should be trivial and is in any case a very minor aspect of gatewaying 
> between the protocols.

sure. the other advantage of having a common registry is that it is a 
single place to look for semantics with values already defined, 
targeting more consistency between the different versions.  if we end up 
with BP7.1 with slight changes, the common registry will be a bigger 
win.

Marc.

> But I will of course go with whatever the WG decides.
>
> Scott
>
> containing non-compressed XML or deployments sending Video over RTP 
> over DTN, I think this one byte is not an issue.
>
>>
> are never garanteed until IANA creates/updates the registry when the 
> RFC is in the RFC-editor queue (i.e. after IESG approval). Changing an 
> enum value in an implementation is a question of one minute. There is 
> to my knowledge no deployment of BP7 yet, nor commercial products of 
> BP7.
> However, having a coherent set of enum values for both BP6 and BP7 is 
> to me a great advantage for implementations.
>
>>
>>> 10.6: This is a BP specific registry. As this encodes the URI 
>>> schemes
>>> into the
>>> 10.7 I already responded seperately to Scott's question. But, I 
>>> think
>>> the WG do