Subject: [dtn] Status of AUTH48 Documents (and a request)

From: "Birrane, Edward J." <[email-masked]>
Date: Fri, 10 Dec 2021 17:30:16 +0000

DTNWG,

  I wanted to report on the status of cluster C431 (https://www.rfc-editor.org/cluster_info.php?cid=C431). This is the collection of BPv7, BPSec, TCPCLv4, and BPSec Default Security Contexts.

  There have been several editorial changes made to ensure that terminology is consistent across these documents, to resolve any ambiguities, and to adjust language as needed for clarity.  Changes are re-reviewed to ensure that there is no change to the technical meaning of the specs (though language may be adjusted to ensure that the technical intent is communicated correctly). 

  Current versions of documents can be found at:

https://www.rfc-editor.org/authors/rfc9171.html  (BPv7)
https://www.rfc-editor.org/authors/rfc9172.html  (BPSec)
https://www.rfc-editor.org/authors/rfc9173.html  (BPSec Default Security Contexts)
https://www.rfc-editor.org/authors/rfc9174.html  (DTN TCPCLv4) 

---

  In the review of these documents, one edit is being considered for RFC-to-be 9171 (BPv7) as follows:

Bpbis-31 Section 4.1 (https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bpbis#section-4.1) stated the following:

To ensure that blocks are always in canonical  representation when they are transmitted and received, the CBOR  representations of the values of all fields in all blocks must conform to the rules for Canonical CBOR as specified in [RFC8949].

Two changes are being made to the above sentence:

1. RFC8949 obsoletes the term "Canonical CBOR" (or suggests it be replaced with the term 'Old Canonical CBOR').  Instead, the text is updated to say "core deterministic encoding requirements as specified in [RFC8949], except that indefinite-length items are not prohibited." Which is the more correct statement of intent.

2. This sentence is believed to have been intended as normative and, thus, "must" is being changed to "MUST". 

The new proposed sentence (from https://www.rfc-editor.org/authors/rfc9171.html#name-bundle-structure) being:

"To ensure that blocks are always in canonical representation when they are transmitted and received, the CBOR encodings of the values of all fields in all blocks MUST conform to the core deterministic encoding requirements as specified in [RFC8949], except that indefinite-length items are not prohibited."

To be transparent in working through these edits, Rick and I wanted to make sure that we agree that the statement "all blocks must conform to..." was intended to be normative and, thus, we should change must to MUST. We are fairly confident this was the case, as bpbis-27 and bpbis-28 used SHALL and only in bpbis-30 and bpbis-31 was it changed to lowercase must as part of other edits to the sentence.

However, I would like some confirmation from the working group that this is the case.

-Ed

---
Edward J. Birrane, III, Ph.D. (he/him/his)
Chief Engineer, Space Constellation Networking
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 10 Dec 2021 18:48:54 +0100

Hi Ed,

On 2021-12-10, at 18:30, Birrane, Edward J. <[email-masked]> wrote:
> 
> "To ensure that blocks are always in canonical representation when they are transmitted and received, the CBOR encodings of the values of all fields in all blocks MUST conform to the core deterministic encoding requirements as specified in [RFC8949], except that indefinite-length items are not prohibited.”

So you still provide for different representations for all arrays, maps, and (byte or text) strings?  I’m not sure I know what “canonical” means (or really: is trying to achieve) here, but maybe you want to be more specific about *where* the indefinite length encoding is permissible (and maybe even *require* it in those places, so there is only one, er, “canonical”, form).

Grüße, Carsten

---

From: Rick Taylor <[email-masked]>
Date: Fri, 10 Dec 2021 17:57:20 +0000

Hi Ed,

Speaking personally I think the s/must/MUST/ change is correct, and I admit that I always took it as MUST anyway.  I remember there were several passes of the document to resolve the capitalisation of canonical text, and various IESG reviews that debated the order of some of the descriptive versus normative text, so I'm not surprised it got missed.

Re the CBOR encoding, referring to the RFC8949 is a valid improvement.

Cheers,

Rick

> -----Original Message-----
> From: dtn [mailto:[email-masked]] On Behalf Of Birrane, Edward J.
> Sent: 10 December 2021 17:30
> To: [email-masked]
> Subject: [dtn] Status of AUTH48 Documents (and a request)
> 
> DTNWG,
> 
>   I wanted to report on the status of cluster C431 (https://www.rfc-
> editor.org/cluster_info.php?cid=C431). This is the collection of BPv7, BPSec,
> TCPCLv4, and BPSec Default Security Contexts.
> 
>   There have been several editorial changes made to ensure that terminology
> is consistent across these documents, to resolve any ambiguities, and to
> adjust language as needed for clarity.  Changes are re-reviewed to ensure
> that there is no change to the technical meaning of the specs (though
> language may be adjusted to ensure that the technical intent is
> communicated correctly).
> 
> To ensure that blocks are always in canonical  representation when they are
> transmitted and received, the CBOR  representations of the values of all
> fields in all blocks must conform to the rules for Canonical CBOR as specified
> in [RFC8949].
> 
> 1. RFC8949 obsoletes the term "Canonical CBOR" (or suggests it be replaced
> with the term 'Old Canonical CBOR').  Instead, the text is updated to say
> "core deterministic encoding requirements as specified in [RFC8949], except
> that indefinite-length items are not prohibited." Which is the more correct
> statement of intent.
> 
> The new proposed sentence (from https://www.rfc-
> editor.org/authors/rfc9171.html#name-bundle-structure) being:
> 
> "To ensure that blocks are always in canonical representation when they are
> transmitted and received, the CBOR encodings of the values of all fields in all
> blocks MUST conform to the core deterministic encoding requirements as
> specified in [RFC8949], except that indefinite-length items are not
> prohibited."
> 
> To be transparent in working through these edits, Rick and I wanted to make
> sure that we agree that the statement "all blocks must conform to..." was
> intended to be normative and, thus, we should change must to MUST. We
> are fairly confident this was the case, as bpbis-27 and bpbis-28 used SHALL
> and only in bpbis-30 and bpbis-31 was it changed to lowercase must as part
> of other edits to the sentence.
> 
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn

---

From: "Birrane, Edward J." <[email-masked]>
Date: Fri, 10 Dec 2021 18:11:47 +0000

Carsten,

  A few items:

- There are no maps defined for any field of any block in the bundle protocol.
- There are many instances where arrays are defined, but in each instance the exact number of array elements is also provided with the exception of the bundle itself, which is an indefinite-length array of blocks.
- The are two instances of byte string which either specify the size of the byte string (as in CRC) or require that the byte string be definite length (as in the block-type-specific data field of an extension block).

Perhaps your point is that saying "a CBOR array of length X" does not explicitly say "a definite-length encoding of a CBOR array of length X". Which makes sense.

To that point, perhaps the more concise statement for 9171 would be "except that an indefinite-length array item is allowed to represent the array of blocks in the bundle..."

-Ed

---

> From: Carsten Bormann <[email-masked]>
> Sent: Friday, December 10, 2021 12:49 PM
> To: Birrane, Edward J. <[email-masked]>
> Cc: [email-masked]
> Subject: [EXT] Re: [dtn] Status of AUTH48 Documents (and a request)
> 
> APL external email warning: Verify sender [email-masked] before clicking links
> or attachments
> 
> Hi Ed,
> 
> > "To ensure that blocks are always in canonical representation when they
> are transmitted and received, the CBOR encodings of the values of all fields
> in all blocks MUST conform to the core deterministic encoding requirements
> as specified in [RFC8949], except that indefinite-length items are not
> prohibited.”
> 
> So you still provide for different representations for all arrays, maps, and
> (byte or text) strings?  I’m not sure I know what “canonical” means (or really:
> is trying to achieve) here, but maybe you want to be more specific about
> *where* the indefinite length encoding is permissible (and maybe even
> *require* it in those places, so there is only one, er, “canonical”, form).
> 
> Grüße, Carsten

---

From: "Sipos, Brian J." <[email-masked]>
Date: Fri, 10 Dec 2021 18:53:41 +0000

All,
I agree with making the deterministic encoding a normative statement and I expect that current encoders are already adhering to this.
BPv7 can, and other specs do, make a blanket statement like that and leave a specific hole for the (currently one) exceptional case. The document can say, as you have said, that "... core deterministic encoding requirements as specified in [RFC8949], except where indefinite-length items are required (i.e. the bundle container array)."

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Birrane, Edward J.
Sent: Friday, December 10, 2021 1:12 PM
To: Carsten Bormann <[email-masked]>
Cc: [email-masked]
Subject: Alert-Verify-Sender: Re: [dtn] [EXT] Re: Status of AUTH48 Documents (and a request)

APL external email warning: Verify sender [email-masked] before clicking links or attachments 

Carsten,

  A few items:

-Ed

---
Edward J. Birrane, III, Ph.D. (he/him/his) Chief Engineer, Space Constellation Networking Space Exploration Sector Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

> APL external email warning: Verify sender [email-masked] before clicking 
> links or attachments
> 
> Hi Ed,
> 
> On 2021-12-10, at 18:30, Birrane, Edward J. 
> <[email-masked]>
> wrote:
> >
> are transmitted and received, the CBOR encodings of the values of all 
> fields in all blocks MUST conform to the core deterministic encoding 
> requirements as specified in [RFC8949], except that indefinite-length 
> items are not prohibited.”
> 
> So you still provide for different representations for all arrays, 
> maps, and (byte or text) strings?  I’m not sure I know what “canonical” means (or really:

---

From: <[email-masked]>
Date: Fri, 10 Dec 2021 11:01:13 -0800

Hi, Ed.  Yes, absolutely, the intent was that this provision of the
specification would be normative.  MUST was intended.

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Rick Taylor
Sent: Friday, December 10, 2021 9:57 AM
To: Birrane, Edward J. <[email-masked]>; [email-masked]
Subject: Re: [dtn] Status of AUTH48 Documents (and a request)

Hi Ed,

Speaking personally I think the s/must/MUST/ change is correct, and I admit
that I always took it as MUST anyway.  I remember there were several passes
of the document to resolve the capitalisation of canonical text, and various
IESG reviews that debated the order of some of the descriptive versus
normative text, so I'm not surprised it got missed.

Cheers,

Rick

> editor.org/cluster_info.php?cid=C431). This is the collection of BPv7, 
> BPSec, TCPCLv4, and BPSec Default Security Contexts.
> 
>   There have been several editorial changes made to ensure that 
> terminology is consistent across these documents, to resolve any 
> ambiguities, and to adjust language as needed for clarity.  Changes 
> are re-reviewed to ensure that there is no change to the technical 
> meaning of the specs (though language may be adjusted to ensure that 
> the technical intent is communicated correctly).
> 
> https://www.rfc-editor.org/authors/rfc9173.html  (BPSec Default 
> Security
> Contexts)
>   In the review of these documents, one edit is being considered for 
> RFC-to- be 9171 (BPv7) as follows:
> 
> Bpbis-31 Section 4.1 
> (https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
> bpbis#section-4.1) stated the following:
> 
> To ensure that blocks are always in canonical  representation when 
> they are transmitted and received, the CBOR  representations of the 
> values of all fields in all blocks must conform to the rules for 
> Canonical CBOR as specified in [RFC8949].
> 
> 1. RFC8949 obsoletes the term "Canonical CBOR" (or suggests it be 
> replaced with the term 'Old Canonical CBOR').  Instead, the text is 
> updated to say "core deterministic encoding requirements as specified 
> in [RFC8949], except that indefinite-length items are not prohibited." 
> Which is the more correct statement of intent.
> 
> "To ensure that blocks are always in canonical representation when 
> they are transmitted and received, the CBOR encodings of the values of 
> all fields in all blocks MUST conform to the core deterministic 
> encoding requirements as specified in [RFC8949], except that 
> indefinite-length items are not prohibited."
> 
> To be transparent in working through these edits, Rick and I wanted to 
> make sure that we agree that the statement "all blocks must conform 
> to..." was intended to be normative and, thus, we should change must 
> to MUST. We are fairly confident this was the case, as bpbis-27 and 
> bpbis-28 used SHALL and only in bpbis-30 and bpbis-31 was it changed 
> to lowercase must as part of other edits to the sentence.
> 
> Edward J. Birrane, III, Ph.D. (he/him/his) Chief Engineer, Space 
> Constellation Networking Space Exploration Sector Johns Hopkins 
> Applied Physics Laboratory

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Sun, 12 Dec 2021 08:35:04 +0000

Thanks for the discussions/opinions so far. I see that the substitution of “must” with “MUST” was the intention that got a bit derailed during edits. This has somehow slipped number of review processes.

Lets take Ed’s email for confirmation as the beginning of a 2 weeks consensus call for the change proposed. Please send your opinion(s) about this change.

BR
Zahed
________________________________
From: dtn <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Friday, December 10, 2021 8:01 PM
To: 'Rick Taylor'; 'Birrane, Edward J.'; [email-masked]
Subject: Re: [dtn] Status of AUTH48 Documents (and a request)

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Rick Taylor
Sent: Friday, December 10, 2021 9:57 AM
To: Birrane, Edward J. <[email-masked]>; [email-masked]
Subject: Re: [dtn] Status of AUTH48 Documents (and a request)

Hi Ed,

Cheers,

Rick

>   I wanted to report on the status of cluster C431 (https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-a99f849331d291b1&q=1&e=0-b5df77b7d50bdea14e8ba1213d70fdc5&u=https%3A%2F%2Fwww.rfc-%2F
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-d0ad53aa416de7bb&q=1&e=0-b5df77b7d50bdea14e8ba1213d70fdc5&u=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9171.html  (BPv7)
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-42b8f56cc71abb8b&q=1&e=0-b5df77b7d50bdea14e8ba1213d70fdc5&u=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9172.html  (BPSec)
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-ff249ae229c704ab&q=1&e=0-b5df77b7d50bdea14e8ba1213d70fdc5&u=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9173.html  (BPSec Default
> Security
> Contexts)
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-771c90eb2e2fe70f&q=1&e=0-b5df77b7d50bdea14e8ba1213d70fdc5&u=https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9174.html  (DTN TCPCLv4)
>
> ---
>
> (https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-07d401f2b04efab7&q=1&e=0-b5df77b7d50bdea14e8ba1213d70fdc5&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dtn-
> The new proposed sentence (from https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-a99f849331d291b1&q=1&e=0-b5df77b7d50bdea14e8ba1213d70fdc5&u=https%3A%2F%2Fwww.rfc-%2F
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-42555888626f4ec7&q=1&e=0-b5df77b7d50bdea14e8ba1213d70fdc5&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdtn

_______________________________________________
dtn mailing list
[email-masked]
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-42555888626f4ec7&q=1&e=0-b5df77b7d50bdea14e8ba1213d70fdc5&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdtn

_______________________________________________
dtn mailing list
[email-masked]
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-42555888626f4ec7&q=1&e=0-b5df77b7d50bdea14e8ba1213d70fdc5&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdtn

---

From: [email-masked]
Date: Mon, 13 Dec 2021 08:40:25 +0100

All,

I would be in favour of the statement "except that an indefinite-length 
array item is allowed to represent the array of blocks in the bundle..." 
with a clear understanding that the array of bundle blocks is the only 
indefinite-length item in any bundle (i.e., also future extension blocks). 
This would allow to use the break stop code to reliably identify the end 
of a bundle in a stream of bytes.

(Maybe even 'allowed' it to weak in this case and could be replaced by 
'mandatory'.)

Regards,
Felix

From:   "Sipos, Brian J." <[email-masked]>
To:     "Birrane, Edward J." <[email-masked]>, "Carsten 
Bormann" <[email-masked]>
Cc:     "[email-masked]" <[email-masked]>
Date:   10/12/2021 19:54
Subject:        Re: [dtn] Alert-Verify-Sender: Re: [EXT] Re: Status of 
AUTH48 Documents (and a request)
Sent by:        "dtn" <[email-masked]>

All,
I agree with making the deterministic encoding a normative statement and I 
expect that current encoders are already adhering to this.
BPv7 can, and other specs do, make a blanket statement like that and leave 
a specific hole for the (currently one) exceptional case. The document can 
say, as you have said, that "... core deterministic encoding requirements 
as specified in [RFC8949], except where indefinite-length items are 
required (i.e. the bundle container array)."

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Birrane, Edward J.
Sent: Friday, December 10, 2021 1:12 PM
To: Carsten Bormann <[email-masked]>
Cc: [email-masked]
Subject: Alert-Verify-Sender: Re: [dtn] [EXT] Re: Status of AUTH48 
Documents (and a request)

APL external email warning: Verify sender [email-masked] before 
clicking links or attachments 

Carsten,

  A few items:

- There are no maps defined for any field of any block in the bundle 
protocol.
- There are many instances where arrays are defined, but in each instance 
the exact number of array elements is also provided with the exception of 
the bundle itself, which is an indefinite-length array of blocks.
- The are two instances of byte string which either specify the size of 
the byte string (as in CRC) or require that the byte string be definite 
length (as in the block-type-specific data field of an extension block).

Perhaps your point is that saying "a CBOR array of length X" does not 
explicitly say "a definite-length encoding of a CBOR array of length X". 
Which makes sense.

To that point, perhaps the more concise statement for 9171 would be 
"except that an indefinite-length array item is allowed to represent the 
array of blocks in the bundle..."

-Ed

---
Edward J. Birrane, III, Ph.D. (he/him/his) Chief Engineer, Space 
Constellation Networking Space Exploration Sector Johns Hopkins Applied 
Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

> > they
> items are not prohibited.?
> 
> maps, and (byte or text) strings?  I?m not sure I know what ?canonical? 
means (or really:
> *require* it in those places, so there is only one, er, ?canonical?, 
form).

_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn
[attachment "smime.p7s" deleted by Felix Flentge/esoc/ESA] 
_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn

---

From: [email-masked]
Date: Mon, 13 Dec 2021 08:43:52 +0100

All,

sorry, please disregard my comment, I have just realised it is nonsense 
(the break stop code could help a bit but, of course, it would not be 
reliable).

Regards,
Felix

From:   [email-masked]
To:     "Sipos, Brian J." <[email-masked]>, "Carsten Bormann" 
<[email-masked]>, "Birrane, Edward J." <[email-masked]>
Cc:     "[email-masked]" <[email-masked]>
Date:   13/12/2021 08:40
Subject:        Re: [dtn] Alert-Verify-Sender: Re: [EXT] Re: Status of 
AUTH48 Documents (and a request)
Sent by:        "dtn" <[email-masked]>

All, 

Regards,
Felix 

All,

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Birrane, Edward J.
Sent: Friday, December 10, 2021 1:12 PM
To: Carsten Bormann <[email-masked]>
Cc: [email-masked]
Subject: Alert-Verify-Sender: Re: [dtn] [EXT] Re: Status of AUTH48 

Carsten,

 A few items:

-Ed

---

form).

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Dec 2021 08:44:42 +0100

On 2021-12-13, at 08:40, [email-masked] wrote:
> 
> (Maybe even 'allowed' it to weak in this case and could be replaced by 'mandatory'.) 

Maybe not with that wording, but…
Is there a reason for allowing both definite and indefinite length at that level?

Grüße, Carsten

---

From: <[email-masked]>
Date: Mon, 13 Dec 2021 15:07:54 -0800

Most of the arrays in a bundle are best encoded with definite lengths, but I think an argument can be made that using an indefinite-length array as the overall structure of a bundle simplifies implementations in a useful way.

The reason for this is that extension blocks may be added to and removed from a bundle as the bundle makes its way toward its destination.  If bundles were definite-length arrays, then the length of that array would need to be re-computed and re-encoded immediately before transmission at every forwarding point.

Certainly this is doable, but it's a little bit of additional work and one more place where errors in implementation can be introduced.  It's not clear to me that it would offer any compensating advantages.

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Carsten Bormann
Sent: Sunday, December 12, 2021 11:45 PM
To: [email-masked]
Cc: Sipos, Brian J. <[email-masked]>; [email-masked]; Birrane, Edward J. <[email-masked]>
Subject: Re: [dtn] Alert-Verify-Sender: Re: [EXT] Re: Status of AUTH48 Documents (and a request)

Grüße, Carsten