Re: [dtn] [EXTERNAL] IANA section on bpbis

["Burleigh, Scott C (US 312B)" <[e-mail]>]

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 <[e-mail]> 
Sent: Wednesday, October 23, 2019 4:11 PM
To: Burleigh, Scott C (US 312B) <[e-mail]>
Cc: [e-mail]; [e-mail]
Subject: Re: [EXTERNAL] [dtn] IANA section on bpbis

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.


>
> Scott
>
> -----Original Message-----
> From: Marc Blanchet <[e-mail]>
> Sent: Wednesday, October 23, 2019 4:45 AM
> To: Magnus Westerlund <[e-mail]>; Burleigh, 
> Scott C (US 312B) <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: [EXTERNAL] Re: [dtn] IANA section on bpbis
>
> 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.
>
> 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.
>>
>>
>> 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
>>
>>
>> ----------------------------------------------------------------------
>> Networks, Ericsson Research
>> ----------------------------------------------------------------------
>> Ericsson AB                 | Phone  [phone]
>> Torshamnsgatan 23           | Mobile [phone]
>> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>> ----------------------------------------------------------------------