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

[Zaheduzzaman Sarker <[e-mail]>]

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 <[e-mail]> on behalf of [e-mail] <[e-mail]>
Sent: Friday, December 10, 2021 8:01 PM
To: 'Rick Taylor'; 'Birrane, Edward J.'; [e-mail]
Subject: Re: [dtn] Status of AUTH48 Documents (and a request)

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

Scott

-----Original Message-----
From: dtn <[e-mail]> On Behalf Of Rick Taylor
Sent: Friday, December 10, 2021 9:57 AM
To: Birrane, Edward J. <[e-mail]>; [e-mail]
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.

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

Cheers,

Rick

> -----Original Message-----
> From: dtn [mailto:[e-mail]] On Behalf Of Birrane, Edward J.
> Sent: 10 December 2021 17:30
> To: [e-mail]
> Subject: [dtn] Status of AUTH48 Documents (and a request)
>
> DTNWG,
>
>   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
> 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://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)
>
> ---
>
>   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://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-
> 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://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-a99f849331d291b1&q=1&e=0-b5df77b7d50bdea14e8ba1213d70fdc5&u=https%3A%2F%2Fwww.rfc-%2F
> 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
>
>
>
> _______________________________________________
> dtn mailing list
> [e-mail]
> 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
[e-mail]
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
[e-mail]
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