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:dtn-bounces@ietf.org] On Behalf Of Birrane, Edward J.
> Sent: 10 December 2021 17:30
> To: dtn@ietf.org
> 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).
> 
>   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
> 
> 
> 
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn