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

["Marc Blanchet" <[e-mail]>]

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
>
> -----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]
>>> ----------------------------------------------------------------------