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

[Zaheduzzaman Sarker <[e-mail]>]

I haven’t noticed any objection on substitution of “must" with “MUST” in section 4.1 of (tobe) RFC9171. Hence, concluding we are fine with this change.

//Zahed

> On 12 Dec 2021, at 09:35, Zaheduzzaman Sarker <zaheduzzaman.sarker=[e-mail]> wrote:
> 
> 
> 
> 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] <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 ( <applewebdata://60875271-01EF-4C0B-94B1-6E60E2840EB4>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 <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 <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 <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 <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 
> > ( <applewebdata://60875271-01EF-4C0B-94B1-6E60E2840EB4>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 <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 <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 <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 <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=7223aa52-a08f-4d25-9b81-da502c7d9833&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdtn
> 
>