Re: [C431] [AD - Zahed Sarker] [EXT] AUTH48 [RV]: RFC 9173 <draft-ietf-dtn-bpsec-default-sc-11.txt> NOW AVAILABLE

[Rebecca VanRheenen <[e-mail]>]

Hi Ed,

Thank you for the reply! We updated the document accordingly. All of our questions have now been addressed.

Please contact us with any further updates or with your approval of the document in its current form.  We need approvals from each author prior to moving forward in the publication process.

________________

The updated XML file is here:
 https://www.rfc-editor.org/authors/rfc9173.xml

The updated output files are here:
 https://www.rfc-editor.org/authors/rfc9173.txt
 https://www.rfc-editor.org/authors/rfc9173.pdf
 https://www.rfc-editor.org/authors/rfc9173.html

These diff files show all changes made during AUTH48:
 https://www.rfc-editor.org/authors/rfc9173-auth48diff.html (all AUTH48 changes)
 https://www.rfc-editor.org/authors/rfc9173-auth48rfcdiff.html (all AUTH48 changes side by side)

The other diff files are here:
 https://www.rfc-editor.org/authors/rfc9173-diff.html
 https://www.rfc-editor.org/authors/rfc9173-rfcdiff.html

For the AUTH48 status of this document, please see:
 https://www.rfc-editor.org/auth48/rfc9173


Thank you,
RFC Editor/rv



> On Dec 4, 2021, at 8:19 AM, Birrane, Edward J. <[e-mail]> wrote:
> 
> Rebecca,
> 
>  No worries at all!
> 
> For question 7, I agree with the edits that have been made.
> 
>  For question 10, I agree that the text can be improved and think that your recommendation of:
> 
> "The bundle creation time is set to 0, indicating lack of an accurate clock, with a sequence number of 40."
> 
>  Is what we should use.
> 
> -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 / (C) 443-690-8272
> 
> -----Original Message-----
> From: Rebecca VanRheenen <[e-mail]> 
> Sent: Friday, December 3, 2021 5:07 PM
> To: Birrane, Edward J. <[e-mail]>; White, Alex <[e-mail]>; Heiner, Sarah E. <[e-mail]>
> Cc: [e-mail]; RFC Editor <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [AD - Zahed Sarker] [EXT] AUTH48 [RV]: RFC 9173 <draft-ietf-dtn-bpsec-default-sc-11.txt> NOW AVAILABLE
> 
> APL external email warning: Verify sender [e-mail] before clicking links or attachments 
> 
> Hi Ed,
> 
> Thank you for the reply. We updated the document accordingly. We have two more followup comments/questions below. We appreciate your patience as we work through these!
> 
> (FYI - adding the C431 mailing list.)
> 
> 
>>> 7)
>>>>> b) The <sourcecode> blocks in the following sections now have lines that are too long (note that <sourcecode> does not outdent like <artwork> does). Please review and let us know how to best adjust/wrap the lines so that they they fit the 69-character limit for the txt output.
>>>>> 
>>>>> A.1.3.2
>>>>> A.1.3.3
>>>>> A.4.3.2
>>>>> 
>>>>> Note: there are some issues with long lines in the HTML and PDF files that appear outside of <sourcecode>.  For example, see Appendix A.1.1.3.  We have filed a bug report here: <https://trac.ietf.org/trac/xml2rfc/ticket/687>.  Perhaps these should be included as <sourcecode>?  See the example in Appendix A.4.5.
>>>> 
>>>> EJB33b: This change will be applied in a forthcoming updated .xml file.
>>> 
>>> The updated file has three lines in <sourcecode> that are still too long. See below. The first is the hex value of the payload in Appendix A.1.1.2; the last two are in Figure 26 in Appendix A.4.3.3. Please review and let us know how to best adjust/wrap the lines so that they they fit.
>>> 
>>> /a/inc-work/rfc9173.xml(2124): Warning: Too long line found (L1668), 4 characters longer than 72 characters: 
>>>  0x526561647920746f2067656e657261746520612033322d62797465207061796c6f6164.
>>> /a/inc-work/rfc9173.xml(3143): Warning: Too long line found (L2456), 1 characters longer than 72 characters: 
>>>    h'81010101820282020182820106820307818182015830f75fe4c37f76f046165855
>>> /a/inc-work/rfc9173.xml(3143): Warning: Too long line found (L2457), 1 characters longer than 72 characters: 
>>>      bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b325527de8aefb
>> 
>> EJB_REPLY7:  For each of these, please wrap so that each line of hex is an even number (2 hex characters == 1 byte). Otherwise, I would wrap the smallest amount possible.
> 
> We believe we did this correctly, but please double-check. 
> 
> 
>>> 10) The following is from the cluster-wide questions:
>>> 
>>>>> 5)  Should the expansion of the acronym "DTN" be "Delay-Tolerant 
>>>>> Networking" or "Delay-Tolerant Networks"?  We note that the title of RFC 
>>>>> 4838 is "Delay-Tolerant Networking Architecture", the expansion of the 
>>>>> WG name is "Delay/Disruption Tolerant Networking", and the expansion of 
>>>>> the RG name is "Delay-Tolerant Networking".
>>>> 
>>>> 	I know this is a controversial topic.  Without expecting to prevail, I will state my preference for "Delay-Tolerant Networking". My reasoning is that (a) it's cleaner and simpler and (b) I think it's actually more accurate.  As has been pointed out from time to time, an IP router could fairly readily be modified to simply cache outbound datagrams pending repair of a network partition, instead of simply discarding them; that sort of disruption tolerance is relatively trivial.  The reason that DTN initially drew the attention of DARPA, I think, was that it addressed the less trivially managed effects of disruption, i.e., large increases in round-trip time.  Tolerance of large and variable round-trip times is fundamental to the concept of DTN, regardless of whether those long round-trip times are attributable to transient link outages or to large signal propagation latencies.  The essence of DTN is ditching the client/server, query/response model of communications - because the round-
>>>> trip delays can be too large to make that model workable - and turning instead to an asynchronous model as implemented by "bundling", AMA, LTP, etc.  Its ability to function successfully over interplanetary signal propagation latencies is what enables DTN to function successfully over disrupted terrestrial links as well; disruption is only one of the possible circumstances in which the client/server model fails.
>>> 
>>> We updated the expansion of DTN from "Delay-Tolerant Networks” to "Delay-Tolerant Networking” in the first sentence below and updated “a DTN” to “DTN” in the second sentence. We do not think any changes are needed for other instances of “DTN”. Please confirm that this is correct.
>>> 
>>> Original:
>>>  The delayed and disrupted nature of DTNs complicates the process of
>>>  key management because there might not be reliable, timely round-trip
>>>  exchange between security sources, security verifiers, and security
>>>  acceptors in the network. 
>>>  …
>>>  Also, key revocation or key
>>>  verification mechanisms that rely on access to a centralized
>>>  authority (such as a certificate authority) might similarly fail in
>>>  the stressing conditions of a DTN.
>>> 
>>> Updated:
>>>  The delayed and disrupted nature of Delay-Tolerant Networking (DTN)
>>>  complicates the process of key management because there might not be
>>>  reliable, timely, round-trip exchange between security sources,
>>>  security verifiers, and security acceptors in the network. 
>>>  …
>>>  Also, key revocation or key
>>>  verification mechanisms that rely on access to a centralized
>>>  authority (such as a certificate authority) might similarly fail in
>>>  the stressing conditions of DTN.
>> 
>> 
>> EJB_REPLY10: Section A.1.1.1 uses the term "DTN creation time" which is not a defined term. I suggest removing that as follows:
>> 
>> OLD:
>> The bundle creation time uses a DTN creation time of 0 indicating lack of an accurate clock...
>> 
>> NEW:
>> The bundle creation time is set to 0 indicating lack of an accurate clock...
>> 
>> I agree with all other uses of DTN in the document.
> 
> We updated the sentence with "DTN creation time” in A.1.1.1 as you suggest. Are any changes needed for the last part of the sentence (i.e., "and a sequence number of 40”)?
> 
> Original:
>   The bundle creation time uses a DTN
>   creation time of 0 indicating lack of an accurate clock and a
>   sequence number of 40.
> 
> Current:
>   The bundle creation time is set to 0
>   indicating lack of an accurate clock and a sequence number of 40.
> 
> Perhaps:
>   The bundle creation time is set to 0,
>   indicating lack of an accurate clock, and the sequence number is set to 40.
> 
> Or:
>   The bundle creation time is set to 0,
>   indicating lack of an accurate clock, with a sequence number of 40.
> 
> 
> ________________
> 
> 
> The updated XML file is here:
>  https://www.rfc-editor.org/authors/rfc9173.xml
> 
> The updated output files are here:
>  https://www.rfc-editor.org/authors/rfc9173.txt
>  https://www.rfc-editor.org/authors/rfc9173.pdf
>  https://www.rfc-editor.org/authors/rfc9173.html
> 
> These diff files show all changes made during AUTH48:
>  https://www.rfc-editor.org/authors/rfc9173-auth48diff.html (all AUTH48 changes)
>  https://www.rfc-editor.org/authors/rfc9173-auth48rfcdiff.html (all AUTH48 changes side by side)
> 
> The other diff files are here:
>  https://www.rfc-editor.org/authors/rfc9173-diff.html
>  https://www.rfc-editor.org/authors/rfc9173-rfcdiff.html
> 
> For the AUTH48 status of this document, please see:
>  https://www.rfc-editor.org/auth48/rfc9173
> 
> 
> Thank you,
> RFC Editor/rv
> 
> 
> 
> 
> 
>> On Dec 3, 2021, at 9:36 AM, Birrane, Edward J. <[e-mail]> wrote:
>> 
>> Rebecca,
>> 
>> Thank you!  My replies to the remaining questions are in-line below, and prefaced with EJB_REPLY# where # corresponds to this e-mail's enumeration of questions and the use of _REPLY helps to disambiguate from my prior comments.
>> 
>> 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 / (C) 443-690-8272
>> 
>> -----Original Message-----
>> From: Rebecca VanRheenen <[e-mail]> 
>> Sent: Thursday, December 2, 2021 10:32 PM
>> To: Birrane, Edward J. <[e-mail]>; White, Alex <[e-mail]>; Heiner, Sarah E. <[e-mail]>; [e-mail]
>> Cc: RFC Editor <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
>> Subject: [AD - Zahed Sarker] Re: [EXT] AUTH48 [RV]: RFC 9173 <draft-ietf-dtn-bpsec-default-sc-11.txt> NOW AVAILABLE
>> 
>> APL external email warning: Verify sender [e-mail] before clicking links or attachments 
>> 
>> Ed and Zahed*,
>> 
>> Ed, thank you for the updated XML file. We have updated the document per replies to both the document-specific and cluster-wide questions. We also have some followup questions below.
>> 
>> *Zahed, as AD, please review the following changes and let us know if you approve. These changes are best viewed in one of these diff files: https://www.rfc-editor.org/authors/rfc9173-auth48diff.html or https://www.rfc-editor.org/authors/rfc9173-auth48rfcdiff.html (side-by-side diff that shows spacing changes).
>> 
>> - Added text in Section 3.3.3
>> - Change to item #5 in Section 3.7
>> - Added text in Section 4.3.4
>> - Changes throughout Appendix A
>> 
>> 
>> Followup questions for authors:
>> 
>> 1)
>>>>> 4) <!-- [rfced] Section 3.3.2: Please confirm that the citation to RFC 5649 is correct here for "authenticated encryption function (KW-AE)". We ask because we do not see "KW-AE" in that document, although we do see "AES", "key wrap", and "encryption".
>>>>> 
>>>>> Original:
>>>>> This optional parameter contains the output of the AES key wrap
>>>>> authenticated encryption function (KW-AE) as defined in [RFC5649].
>>>>> -->
>>>> 
>>>> EJB4: The term KW-AE is used by the documents cited by RFC5649. Since KW-AE is only ever used in the 2 paragraphs citing RFC5649, it can be replaced as follows in both instances.
>>>> 
>>>> OLD:
>>>> 
>>>> ... This optional parameter contains the output of the AES key wrap authenticated encryption function (KW-AE) as defined in [RFC5649].  Specifically, this parameter holds the cipher text produced when running the KW-AE algorithm with the...
>>>> 
>>>> NEW:
>>>> 
>>>> ...This optional parameter contains the output of the AES key wrap function as defined in [RFC5649].  Specifically, this parameter holds the cipher text produced when running this key wrap algorithm with the...
>>> 
>>> UPDATE #1: Question 4: (please use this instead of the response below to EJB4)
>>> 
>>> The citation for RFC5649 is not the correct citation. The correct citation is RFC3394.  The update should read as follows:
>>> 
>>> OLD:
>>> ... This optional parameter contains the output of the AES key wrap authenticated encryption function (KW-AE) as defined in [RFC5649].  Specifically, this parameter holds the cipher text produced when running the KW-AE algorithm with the...
>>> 
>>> NEW:
>>> ...This optional parameter contains the output of the AES key wrap function as defined in [RFC3394].  Specifically, this parameter holds the cipher text produced when running this key wrap algorithm with the...
>> 
>> Note that we also made this change in Section 4.3.3.
>> 
>> We also added RFC 3394 to the normative references. Please let us know if it should be informative instead.
>> 
>> 
>> EJB_REPLY1:  I concur with the change and the reference to RFC3394 (just like RFC5649 that it replaced) should be normative.
>> 
>> 
>> 
>> 2)
>>> 5) <!-- [rfced] Section 3.3.4: The table in this section lists the default values for "SHA Variant" and "Integrity Scope Flags". We see that the default for "SHA Variant" is also mentioned in the text Section 3.3.1, but the the default for "Integrity Scope Flags" is not mentioned in the text in Section 3.3.3. Is it sufficient for the default to only be found in the table?
>>> 
>>> Note that the same occurs in the table in Section 4.3.5. The default for "AES Variant" is mentioned in the text but not the default for "AAD Scope Flags".
>>> -->
>>> 
>>> EJB5: It would be better if the default value is present in the text in both sections, rather than simply in the table. The text to use in each case is:
>>> 
>>> "When not provided, implementations SHOULD assume a value of 7 (indicating all assigned fields), unless an alternate default is established by local security policy at the security source,  verifier, or acceptor of this integrity service."
>> 
>> We added the text you provided in Sections 3.3.3 and 4.3.5. Please confirm that the placement we chose is appropriate.
>> 
>> 
>> EJB_REPLY2: I am fine with this placement.
>> 
>> 
>> 3)
>>> 11) <!-- [rfced] Sections 3.8.1 and 4.8.1: Would it be helpful to readers to add a citation for "NIST AES-KW algorithm" here? If so, please let us know which reference to use.
>>> 
>>> Original:
>>> The HMAC key MAY be included as a security parameter in which case
>>> it MUST be wrapped using the NIST AES-KW algorithm and the results
>>> of the wrapping added as the wrapped key security parameter for
>>> the BIB.
>>> ...
>>> The encryption key MAY be included as a security parameter in
>>> which case it MUST be wrapped using the NIST AES-KW algorithm and
>>> the results of the wrapping added as the wrapped key security
>>> parameter for the BCB.
>>> -->
>>> 
>>> EJB11: For consistency, we should continue referring to AES key rap through RFC5649. Suggest in both examples above that we perform the following substitution:
>>> 
>>> OLD:
>>> 
>>> MUST be wrapped using the NIST AES-KW algorithm..
>>> 
>>> NEW:
>>> 
>>> MUST be wrapped using the AES key wrap function as defined in [RFC5649]...
>> 
>> We have updated this as suggested, but based on the updated response to the question above about KW-AE (which seems similar to AES-KW), we would like to confirm that RFC 5649 should be cited here. Or should RFC 3394?
>> 
>> Also, please review other instance of “AES-KW” and let us know if these should also be updated.
>> 
>> EJB_REPLY3: There should be no references to RFC5649 - they should all be updated to RFC3394. The term AES-KW refers to "AES Key Wrap" and should be defined on first use. The citation for this should be RFC3394.
>> 
>> 
>> 4)
>>> 18) <!-- [rfced] Section 5: In addition to the values in the IANA Considerations section, we see definitions of the Integrity Scope flags in Section 3.3.3 and ADD Scope flags in Section 4.3.4, which have slightly different descriptions.  
>>> Should these descriptions exactly match the descriptions in IANA registry in Section 3.3.3 and 4.3.4?  Is "Include" intended to be part of the registered description?  
>>> 
>>> In addition, should "flag" be part of the description, or is it implied since it is part of the BPSec BIB-HMAC-SHA2 Integrity Scope Flags registry?  Should the Descriptions match - for example, should "Include target header flag" be "Include target header" or "Include primary block" be "Include primary block flag"?
>>> Note that this question also applies to the "BPSec BCB-AES-GCM AAD Scope Flags" registry.  
>>> 
>>> -->
>>> 
>>> EJB18: The descriptions of flags in both 3.3.3 and 4.3.4 should match the descriptions in the IANA Considerations section for clarity. In both cases, the construct used should be "Include <item> flag".  So, "Include primary block flag", "Include target header flag", and so on.
>>> 
>> 
>> We have updated the flag descriptions in Sections 3.3.3 and 4.3.4. 
>> 
>> In addition, we updated "Include primary block” to "Include primary block flag” (i.e., added “flag”) in Sections 5.2 and 5.3. Prior to publication, we will request that IANA update the entries in both the "BPSec BIB-HMAC-SHA2 Integrity Scope Flags” and "BPSec BCB-AES-GCM AAD Scope Flags” registries accordingly (see https://www.iana.org/assignments/bundle/).
>> 
>> EJB_REPLY4: Thank you!
>> 
>> 
>> 5)
>>> 22) <!-- [rfced] May we remove the "Example X" in the following table and figure titles as "Example X" appears in the section titles? 
>>> 
>>> For example:
>>> 
>>> Current:
>>> A.1.  Example 1: Simple Integrity
>>> Table 11: Example 1: Original Bundle
>>> Table 12: Example 1: Resulting Bundle
>>> Figure 3: Example 1: Configuration, Parameters, and Results
>>> Figure 4: Example 1: BIB Abstract Security Block (CBOR Diagnostic Notation)
>>> Figure 5: Example 1: BIB (CBOR Diagnostic Notation)
>>> 
>>> Perhaps:
>>> A.1.  Example 1: Simple Integrity
>>> Table 11: Original Bundle
>>> Table 12: Resulting Bundle
>>> Figure 3: Configuration, Parameters, and Results
>>> Figure 4: BIB Abstract Security Block (CBOR Diagnostic Notation)
>>> Figure 5: BIB (CBOR Diagnostic Notation)
>>> -->
>>> 
>>> EJB22: Because the appendix is so large and because the figures/tables look very similar example-to-example, we felt there was value is adding which example was which to the description. Perhaps if we used the construction (Example X) at the end it would seem cleaner, such as:
>>> 
>>> Table 11: Original Bundle (Example 1)
>>> Table 12: Resulting Bundle (Example 1)
>>> Figure 3: Configuration, Parameters, and Results (Example 1)
>> 
>> Understood. We are concerned that adding (Example X) at the end would look odd for cases that already include a parenthetical, such as Figures 6 and 7 below, so we believe the original may be better. Another option would be to replace the second colon (“:”) with a dash; does this look cleaner by avoiding the double colon? We will go with your preference here. Examples with the dash replacing second colon:
>> 
>> A.1.  Example 1: Simple Integrity
>> Figure 1: Example 1 - Original Bundle
>> Figure 2: Primary Block (CBOR Diagnostic Notation)
>> Figure 3: Payload Block (CBOR Diagnostic Notation)
>> Figure 4: Example 1 - Resulting Bundle
>> Figure 5: Example 1 - Configuration, Parameters, and Results
>> Figure 6: Example 1 - BIB Abstract Security Block (CBOR Diagnostic Notation)
>> Figure 7: Example 1 - BIB (CBOR Diagnostic Notation)
>> 
>> EJB_REPLY5: I agree that the dash ("-") looks much cleaner and we should use that.
>> 
>> 
>> 6)
>>> 32) <!-- [rfced] Terminology
>>> 
>>> a) We note inconsistencies in the terms below throughout the text.  Should these be uniform? If so, please let us know which form is preferred.
>>> 
>>> AES/GCM vs. AES-GCM
>>> Examples: "AES-GCM cipher suite" and "AES/GCM cipher"
>>> 
>>> security parameter vs. security context parameter
>>> 
>>> EJB32a: The term AES-GCM should be used.  Similarly the term "security context parameter" should be used.
>> 
>> We updated all instances of "security parameter” to "security context parameter”, except for the instances in <sourcecode> in the following sections as it would make the lines too long. Please review and let us know if you would like to keep these as is or make any changes.
>> 
>> A.1.3.2
>> A.2.3.2
>> A.3.3.2
>> A.3.4.2
>> A.4.4.2
>> 
>> EJB_REPLY6: I am fine with these changes, as I believe that Security Parameters and Security Results are clear in this context as belonging to the security context.
>> 
>> 
>> 7)
>>> b) The <sourcecode> blocks in the following sections now have lines that are too long (note that <sourcecode> does not outdent like <artwork> does). Please review and let us know how to best adjust/wrap the lines so that they they fit the 69-character limit for the txt output.
>>> 
>>> A.1.3.2
>>> A.1.3.3
>>> A.4.3.2
>>> 
>>> Note: there are some issues with long lines in the HTML and PDF files that appear outside of <sourcecode>.  For example, see Appendix A.1.1.3.  We have filed a bug report here: <https://trac.ietf.org/trac/xml2rfc/ticket/687>.  Perhaps these should be included as <sourcecode>?  See the example in Appendix A.4.5.
>>> 
>>> EJB33b: This change will be applied in a forthcoming updated .xml file.
>> 
>> The updated file has three lines in <sourcecode> that are still too long. See below. The first is the hex value of the payload in Appendix A.1.1.2; the last two are in Figure 26 in Appendix A.4.3.3. Please review and let us know how to best adjust/wrap the lines so that they they fit.
>> 
>> /a/inc-work/rfc9173.xml(2124): Warning: Too long line found (L1668), 4 characters longer than 72 characters: 
>>  0x526561647920746f2067656e657261746520612033322d62797465207061796c6f6164.
>> /a/inc-work/rfc9173.xml(3143): Warning: Too long line found (L2456), 1 characters longer than 72 characters: 
>>    h'81010101820282020182820106820307818182015830f75fe4c37f76f046165855
>> /a/inc-work/rfc9173.xml(3143): Warning: Too long line found (L2457), 1 characters longer than 72 characters: 
>>      bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b325527de8aefb
>> 
>> EJB_REPLY7:  For each of these, please wrap so that each line of hex is an even number (2 hex characters == 1 byte). Otherwise, I would wrap the smallest amount possible.
>> 
>> 
>> 8)
>>> 3) Please review whether any of the notes in this document (i.e., text
>>> prefaced with "NOTE:" or "NOTES:") should be in the <aside> element. The
>>> <aside> element is defined as "a container for content that is semantically
>>> less important or tangential to the content that surrounds it"
>>> (see https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-aside-2).
>>> 
>>> EJB33c: The NOTE(s) in sections 3.2, 4.2, the first NOTE of section 4.4, and the first NOTE of Appendix A can be used in the <aside> element. If having one NOTE be in <aside> and the other not be in <aside> in section 4.4 looks odd, then both notes in section 4.4 can be kept as-is.
>> 
>> We used <aside> with the notes in Sections 3.2 and 4.2. We also used <aside> for the new note added to Section 3.3.3. Please let us know if this is incorrect.
>> 
>> We left the notes in Section 4.4 and Appendix A as is. 
>> 
>> 
>> EJB_REPLY8:  I agree with these.   However please note (no pun intended) that the NOTE in 3.3.3 uses names for flags which you have otherwise updated. Could you make sure that terms such as Primary Block Flag and Target Header Flag be updated as per item #4 above?
>> 
>> 
>> 
>> 9) In text like the following, the encoding was put into <sourcecode> in the updated XML file that we received. Should the period at the end be retained, or should it be deleted? We believe it should be deleted as it is not actually part of the sourcecode, but we would like to confirm before making that change.
>> 
>> Original:
>>  The CBOR encoding of the primary block is
>>  0x88070000820282010282028202018202820201820018281a000f4240.
>> 
>> Current:
>>  The CBOR encoding of the primary block is:
>> 
>>  0x88070000820282010282028202018202820201820018281a000f4240.
>> 
>> Perhaps (period removed):
>>  The CBOR encoding of the primary block is:
>> 
>>  0x88070000820282010282028202018202820201820018281a000f4240
>> 
>> 
>> EJB_REPLY9: We should delete the period.
>> 
>> 
>> 10) The following is from the cluster-wide questions:
>> 
>>>> 5)  Should the expansion of the acronym "DTN" be "Delay-Tolerant 
>>>> Networking" or "Delay-Tolerant Networks"?  We note that the title of RFC 
>>>> 4838 is "Delay-Tolerant Networking Architecture", the expansion of the 
>>>> WG name is "Delay/Disruption Tolerant Networking", and the expansion of 
>>>> the RG name is "Delay-Tolerant Networking".
>>> 
>>> 	I know this is a controversial topic.  Without expecting to prevail, I will state my preference for "Delay-Tolerant Networking". My reasoning is that (a) it's cleaner and simpler and (b) I think it's actually more accurate.  As has been pointed out from time to time, an IP router could fairly readily be modified to simply cache outbound datagrams pending repair of a network partition, instead of simply discarding them; that sort of disruption tolerance is relatively trivial.  The reason that DTN initially drew the attention of DARPA, I think, was that it addressed the less trivially managed effects of disruption, i.e., large increases in round-trip time.  Tolerance of large and variable round-trip times is fundamental to the concept of DTN, regardless of whether those long round-trip times are attributable to transient link outages or to large signal propagation latencies.  The essence of DTN is ditching the client/server, query/response model of communications - because the round-
>>> trip delays can be too large to make that model workable - and turning instead to an asynchronous model as implemented by "bundling", AMA, LTP, etc.  Its ability to function successfully over interplanetary signal propagation latencies is what enables DTN to function successfully over disrupted terrestrial links as well; disruption is only one of the possible circumstances in which the client/server model fails.
>> 
>> We updated the expansion of DTN from "Delay-Tolerant Networks” to "Delay-Tolerant Networking” in the first sentence below and updated “a DTN” to “DTN” in the second sentence. We do not think any changes are needed for other instances of “DTN”. Please confirm that this is correct.
>> 
>> Original:
>>  The delayed and disrupted nature of DTNs complicates the process of
>>  key management because there might not be reliable, timely round-trip
>>  exchange between security sources, security verifiers, and security
>>  acceptors in the network. 
>>  …
>>  Also, key revocation or key
>>  verification mechanisms that rely on access to a centralized
>>  authority (such as a certificate authority) might similarly fail in
>>  the stressing conditions of a DTN.
>> 
>> Updated:
>>  The delayed and disrupted nature of Delay-Tolerant Networking (DTN)
>>  complicates the process of key management because there might not be
>>  reliable, timely, round-trip exchange between security sources,
>>  security verifiers, and security acceptors in the network. 
>>  …
>>  Also, key revocation or key
>>  verification mechanisms that rely on access to a centralized
>>  authority (such as a certificate authority) might similarly fail in
>>  the stressing conditions of DTN.
>> 
>> 
>> EJB_REPLY10: Section A.1.1.1 uses the term "DTN creation time" which is not a defined term. I suggest removing that as follows:
>> 
>> OLD:
>> The bundle creation time uses a DTN creation time of 0 indicating lack of an accurate clock...
>> 
>> NEW:
>> The bundle creation time is set to 0 indicating lack of an accurate clock...
>> 
>> I agree with all other uses of DTN in the document.
>> 
>> 
>> 11) The following is also from the cluster-wide questions:
>> 
>>>> 9)  Please let us know how to make the capitalization of "block processing control flags" and "bundle processing control flags" 
>>>> consistent across the cluster. Although more instances are lowercase, 
>>>> there is a mix of capitalization styles.
>>>> 
>>>> Should shortened versions of the term (i.e., "processing flags") be 
>>>> corrected to "processing control flags"?
>>> 
>>> 	I think the lower-case usage is appropriate, and unfortunately I think in both cases it is clearer to write out the entire term wherever it appears: block processing control flags, bundle processing control flags.
>> 
>> First, should any updates be made to "processing flags” in this sentence? Should this read "processing control flags” or “block and bundle processing control flags”?
>> 
>> Current:
>>  The BPv7 bundle has no special processing flags, and no CRC is
>>  provided because the primary block is expected to be protected by an
>>  integrity service BIB using the BIB-HMAC-SHA2 security context.
>> 
>> 
>> EJB_REPLY11a: I agree that the term "block and bundle processing control flags" is clearer in this instance.
>> 
>> 
>> Second, we updated "block processing flags” to "block processing control flags” in <sourcecode> in Figures 3 and 14. In Figure 3, we adjusted the alignment of the “/“ characters accordingly, but the “/“ characters in Figure 14 were not aligned in the original so we left these as is. Please review these carefully.
>> 
>> EJB_REPLY11b: For all figures, where practical, the rightmost "/" characters should be aligned. Could this be corrected in Figures 12, 14, 18, 21, 26, 29, 
>> 
>> ________________
>> 
>> 
>> The updated XML file is here:
>>  https://www.rfc-editor.org/authors/rfc9173.xml
>> 
>> The updated output files are here:
>>  https://www.rfc-editor.org/authors/rfc9173.txt
>>  https://www.rfc-editor.org/authors/rfc9173.pdf
>>  https://www.rfc-editor.org/authors/rfc9173.html
>> 
>> These diff files show all changes made during AUTH48:
>>  https://www.rfc-editor.org/authors/rfc9173-auth48diff.html (all AUTH48 changes)
>>  https://www.rfc-editor.org/authors/rfc9173-auth48rfcdiff.html (all AUTH48 changes side by side)
>> 
>> The other diff files are here:
>>  https://www.rfc-editor.org/authors/rfc9173-diff.html
>>  https://www.rfc-editor.org/authors/rfc9173-rfcdiff.html
>> 
>> For the AUTH48 status of this document, please see:
>>  https://www.rfc-editor.org/auth48/rfc9173
>> 
>> 
>> Thank you,
>> RFC Editor/rv
>> 
>> 
>> 
>> 
>> 
>>> On Dec 1, 2021, at 7:38 AM, Birrane, Edward J. <[e-mail]> wrote:
>>> 
>>> Rebecca,
>>> 
>>> Thank you for your patience.  
>>> 
>>> I have 4 updates and the new .XML file is attached to this e-mail.
>>> 
>>> UPDATE #1: Question 4: (please use this instead of the response below to EJB4)
>>> 
>>> The citation for RFC5649 is not the correct citation. The correct citation is RFC3394.  The update should read as follows:
>>> 
>>> OLD:
>>> ... This optional parameter contains the output of the AES key wrap authenticated encryption function (KW-AE) as defined in [RFC5649].  Specifically, this parameter holds the cipher text produced when running the KW-AE algorithm with the...
>>> 
>>> NEW:
>>> ...This optional parameter contains the output of the AES key wrap function as defined in [RFC3394].  Specifically, this parameter holds the cipher text produced when running this key wrap algorithm with the...
>>> 
>>> 
>>> UPDATE #2: Question 24:
>>> This remains addressed in the attached .xml file, but it was addressed by removing the string interpretation of the payload. It is not needed for the examples in the appendix.
>>> 
>>> 
>>> UPDATE #3: Clarification for special case of primary block
>>> 
>>> The spec is silent on the (clearly) incorrect use of flags when the security target is the primary block. The text should be updated to explicitly state that when the security target is the primary block, certain flag settings are nonsensical and should be prohibited.
>>> 
>>> The following text should be added at the end of Section 3.3.3
>>> 
>>> OLD:
>>> 
>>> NEW:
>>> NOTE: When the security target is the primary block, both the Primary Block Flag and Target Header Flag MUST be set to 0.  Setting the Primary Block Flag to 1 in this case would include the contents of the primary block twice in the integrity calculation. Setting the Target Header Flag to 1 in this case has no meaning because the primary block does not have a block header. 
>>> 
>>> 
>>> UPDATE #4: Clarification for special case of primary block.
>>> 
>>> Clarify the text in section 3.7 to account for primary block as a security target.
>>> 
>>> OLD:
>>> The canonical form of the security target block-type-specific data MUST be calculated and appended to the IPPT.
>>> 
>>> NEW:
>>> The canonical form of the security target MUST be calculated and appended to the IPPT. If the security target is the primary block, this is the canonical form of the primary block. Otherwise, this is the canonical form of the block-type-specific data of the security target. 
>>> 
>>> 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 / (C) 443-690-8272
>>> 
>>> 
>>> -----Original Message-----
>>> From: Rebecca VanRheenen <[e-mail]> 
>>> Sent: Tuesday, November 30, 2021 12:50 PM
>>> To: Birrane, Edward J. <[e-mail]>
>>> Cc: RFC Editor <[e-mail]>; White, Alex <[e-mail]>; Heiner, Sarah E. <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
>>> Subject: Re: [EXT] AUTH48 [RV]: RFC 9173 <draft-ietf-dtn-bpsec-default-sc-11.txt> NOW AVAILABLE
>>> 
>>> APL external email warning: Verify sender [e-mail] before clicking links or attachments 
>>> 
>>> Hi Ed,
>>> 
>>> Thank you for the update. We will wait to receive the updated XML before applying the changes in your email below (i.e., responses to questions 1-23, 25-31, 32a-32f, 33a, and 33c).
>>> 
>>> Sincerely,
>>> RFC Editor/rv
>>> 
>>> 
>>> 
>>>> On Nov 29, 2021, at 6:56 PM, Birrane, Edward J. <[e-mail]> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> We have 2 sets of responses to the questions below.
>>>> 
>>>> Set 1: Responses in-line to this e-mail
>>>> ---
>>>> For questions 1-23, 25-31, 32a-32f, 33a, and 33c the responses are in-line in the e-mail below, and prefaced with EJB#: where # is the number of the question being answered.
>>>> 
>>>> Set 2: Responses soon to be coming in a revised .xml file. 
>>>> ---
>>>> For questions 24 and 33b we will provide an updated .xml file, since these questions affect hex values and spacing.  Additionally, in the provided .xml file we correct an error in the hex values in this document that stemmed from a misreading of BPSec regarding the encoding of security results. The ambiguous text in BPSec has been clarified as part of AUTH48 for that document and we are correcting some hex values in the informative appendix of this document.
>>>> 
>>>> The .xml file will be sent in the next day or two as we review and confirm those changes.
>>>> 
>>>> -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 / (C) 443-690-8272
>>>> 
>>>> -----Original Message-----
>>>> From: [e-mail] <[e-mail]>
>>>> Sent: Tuesday, November 23, 2021 5:36 PM
>>>> To: Birrane, Edward J. <[e-mail]>; White, Alex 
>>>> <[e-mail]>; Heiner, Sarah E. <[e-mail]>
>>>> Cc: [e-mail]; Birrane, Edward J. 
>>>> <[e-mail]>; [e-mail]; 
>>>> [e-mail]; [e-mail]; 
>>>> [e-mail]
>>>> Subject: [EXT] Re: AUTH48 [RV]: RFC 9173 
>>>> <draft-ietf-dtn-bpsec-default-sc-11.txt> NOW AVAILABLE
>>>> 
>>>> APL external email warning: Verify sender [e-mail] before 
>>>> clicking links or attachments
>>>> 
>>>> Authors,
>>>> 
>>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are  also in the XML file.
>>>> 
>>>> 1) <!-- [rfced] We have updated the document title as shown below; abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide"). Note that we will expand "BPSec" as decided in the cluster-wide questions; for now, we have included the expansion used in the abstract.
>>>> 
>>>> Also, would it be helpful to adjust the order of the the title as shown under the "Perhaps" heading below?
>>>> 
>>>> Original:
>>>> BPSec Default Security Contexts
>>>> 
>>>> Current:
>>>> Bundle Protocol Security Protocol (BPSec) Default Security Contexts
>>>> 
>>>> Perhaps:
>>>> Default Security Contexts for the Bundle Protocol Security Protocol 
>>>> (BPSec)
>>>> -->
>>>> 
>>>> EJB1: Based on the decision for the cluster-wide question, I believe we should title this: "Default Security Contexts for Bundle Protocol Security (BPSec).
>>>> 
>>>> 
>>>> 2) <!-- [rfced] Sections 3.2 and 4.2: Would the suggested text below be an improvement here?
>>>> 
>>>> Original:
>>>> Security target other fields
>>>> ...
>>>> BIB other fields
>>>> ...
>>>> BCB other fields
>>>> 
>>>> Perhaps:
>>>> Other fields of the security target
>>>> ...
>>>> Other fields of the BIB
>>>> ...
>>>> Other fields of the BCB
>>>> -->
>>>> 
>>>> EJB2: Concur. This edit is easier to read.
>>>> 
>>>> 
>>>> 3) <!-- [rfced] Section 3.2: Does "itself" here refer to "determination"? Would this sentence be more clear without "itself"?
>>>> 
>>>> Original:
>>>> The determination of which optional types of information were
>>>> used when constructing the IPPT MUST, itself, always be included
>>>> in the IPPT.  
>>>> 
>>>> Perhaps:
>>>> The determination of which optional types of information were
>>>> used when constructing the IPPT MUST always be included
>>>> in the IPPT.  
>>>> -->
>>>> 
>>>> EJB3: Yes, itself refers to the determination. Concur that the proposed edit is more clear.
>>>> 
>>>> 
>>>> 4) <!-- [rfced] Section 3.3.2: Please confirm that the citation to RFC 5649 is correct here for "authenticated encryption function (KW-AE)". We ask because we do not see "KW-AE" in that document, although we do see "AES", "key wrap", and "encryption".
>>>> 
>>>> Original:
>>>> This optional parameter contains the output of the AES key wrap
>>>> authenticated encryption function (KW-AE) as defined in [RFC5649].
>>>> -->
>>>> 
>>>> EJB4: The term KW-AE is used by the documents cited by RFC5649. Since KW-AE is only ever used in the 2 paragraphs citing RFC5649, it can be replaced as follows in both instances.
>>>> 
>>>> OLD:
>>>> 
>>>> ... This optional parameter contains the output of the AES key wrap authenticated encryption function (KW-AE) as defined in [RFC5649].  Specifically, this parameter holds the cipher text produced when running the KW-AE algorithm with the...
>>>> 
>>>> NEW:
>>>> 
>>>> ...This optional parameter contains the output of the AES key wrap function as defined in [RFC5649].  Specifically, this parameter holds the cipher text produced when running this key wrap algorithm with the...
>>>> 
>>>> 
>>>> 5) <!-- [rfced] Section 3.3.4: The table in this section lists the default values for "SHA Variant" and "Integrity Scope Flags". We see that the default for "SHA Variant" is also mentioned in the text Section 3.3.1, but the the default for "Integrity Scope Flags" is not mentioned in the text in Section 3.3.3. Is it sufficient for the default to only be found in the table?
>>>> 
>>>> Note that the same occurs in the table in Section 4.3.5. The default for "AES Variant" is mentioned in the text but not the default for "AAD Scope Flags".
>>>> -->
>>>> 
>>>> EJB5: It would be better if the default value is present in the text in both sections, rather than simply in the table. The text to use in each case is:
>>>> 
>>>> "When not provided, implementations SHOULD assume a value of 7 (indicating all assigned fields), unless an alternate default is established by local security policy at the security source,  verifier, or acceptor of this integrity service."
>>>> 
>>>> 
>>>> 6) <!-- [rfced] Section 3.6: Is "a guess" correct here? Please review the suggested text below and let us know if it accurately conveys the intended meaning.
>>>> 
>>>> Original:
>>>> This regularity can lead to practical side-
>>>> channel attacks whereby an attacker could produce known plain text
>>>> and a guess at an HMAC tag and observe the behavior of a verifier.
>>>> 
>>>> Perhaps:
>>>> This regularity can lead to practical side-
>>>> channel attacks whereby an attacker could produce known plain text,
>>>> guess at an HMAC tag, and observe the behavior of a verifier.
>>>> -->
>>>> 
>>>> EJB6: Concur. The edit is clearer and preserves the intent.
>>>> 
>>>> 
>>>> 7) <!-- [rfced] Section 3.6: We updated "attacher-" to "attacker-" here as we believe that was the the intent.
>>>> 
>>>> Original:
>>>> With a modest number of trials, a side-channel attack could produce
>>>> an HMAC tag for attacher-provided plain text without the attacker
>>>> ever knowing the HMAC key.
>>>> -->
>>>> 
>>>> EJB7: Correct. The intent was to use the word "attacker".
>>>> 
>>>> 
>>>> 8) <!-- [rfced] Sections 3.7 and 4.7: Please confirm that "performed" is the correct word choice here. Note that this sentence appears twice in the document.
>>>> 
>>>> Original:
>>>> In all cases, the canonical form of any portion of an extension block
>>>> MUST be performed as described in [I-D.ietf-dtn-bpsec].  
>>>> -->
>>>> 
>>>> EJB8: This is not the correct word choice. I recommend the following.
>>>> 
>>>> OLD:
>>>> 
>>>> In all cases, the canonical form of any portion of an extension block MUST be performed as described in [I-D.ietf-dtn-bpsec]. 
>>>> 
>>>> NEW:
>>>> 
>>>> In all cases, the canonical form of any portion of an extension block MUST be created as described in [I-D.ietf-dtn-bpsec].
>>>> 
>>>> 
>>>> 9) <!-- [rfced] Sections 3.8.1 and 4.8.1: For parallel structure with the other items in the series, we would like to add a verb before "through some other key..." in these sentences. Would "obtained", "procured", or something else work best here?
>>>> 
>>>> Original:
>>>> The key can be generated specifically for this
>>>> integrity service, given as part of local security policy, or
>>>> through some other key management mechanism as discussed in
>>>> Section 3.5.
>>>> ...
>>>> The key might be generated specifically
>>>> for this encryption, given as part of local security policy, or
>>>> through some other key management mechanism as discussed in
>>>> Section 4.5.
>>>> 
>>>> Perhaps (generated..., given..., obtained...):
>>>> The key can be generated specifically for this
>>>> integrity service, given as part of local security policy, or
>>>> obtained through some other key management mechanism as discussed in
>>>> Section 3.5.
>>>> ...
>>>> The key might be generated specifically
>>>> for this encryption, given as part of local security policy, or
>>>> obtained through some other key management mechanism as discussed in
>>>> Section 4.5.
>>>> -->
>>>> 
>>>> EJB9: The proposed use of the word obtained makes the text clearer and preserves the original intent.
>>>> 
>>>> 
>>>> 10) <!-- [rfced] Section 3.8.1 and 4.8.2: Should "actions" read "action"
>>>> (singular) here? Only one bullet appears after these introductory sentences (though the bullet in Section 4.8.2 contains two sentences).
>>>> 
>>>> Original:
>>>> Upon successful hash generation the following actions MUST occur.
>>>> ...
>>>> Upon successful decryption the following actions MUST occur.
>>>> -->
>>>> 
>>>> EJB10: concur. The singular "action" should be used in these cases.
>>>> 
>>>> 
>>>> 11) <!-- [rfced] Sections 3.8.1 and 4.8.1: Would it be helpful to readers to add a citation for "NIST AES-KW algorithm" here? If so, please let us know which reference to use.
>>>> 
>>>> Original:
>>>> The HMAC key MAY be included as a security parameter in which case
>>>> it MUST be wrapped using the NIST AES-KW algorithm and the results
>>>> of the wrapping added as the wrapped key security parameter for
>>>> the BIB.
>>>> ...
>>>> The encryption key MAY be included as a security parameter in
>>>> which case it MUST be wrapped using the NIST AES-KW algorithm and
>>>> the results of the wrapping added as the wrapped key security
>>>> parameter for the BCB.
>>>> -->
>>>> 
>>>> EJB11: For consistency, we should continue referring to AES key rap through RFC5649. Suggest in both examples above that we perform the following substitution:
>>>> 
>>>> OLD:
>>>> 
>>>> MUST be wrapped using the NIST AES-KW algorithm..
>>>> 
>>>> NEW:
>>>> 
>>>> MUST be wrapped using the AES key wrap function as defined in [RFC5649]...
>>>> 
>>>> 
>>>> 12) <!-- [rfced] Section 3.8.2: FYI: We added a citation to [RFC9172] here after "BPSec specification".
>>>> 
>>>> Original:
>>>> This security service is removed from the bundle at the security
>>>> acceptor as required by the BPSec specification. 
>>>> 
>>>> Updated:
>>>> This security service is removed from the bundle at the security
>>>> acceptor as required by the BPSec specification [RFC9172].
>>>> -->
>>>> 
>>>> EJB12: Concur.
>>>> 
>>>> 
>>>> 13) <!-- [rfced] Section 4.4: Is "see below" descriptive enough to help readers find the information? For example, would something like "see Section X"
>>>> be more helpful?
>>>> 
>>>> Original:
>>>> therefore, no additional logic is required to handle padding or
>>>> overflow caused by the encryption in most cases (see below).
>>>> -->
>>>> 
>>>> EJB13: The phrase (see below) can be removed. It references the next bullet point.
>>>> 
>>>> 
>>>> 14) <!-- [rfced] Note that we used <superscript> for "2^64" and "2^32" in Section 4.5. There is no change in the text output, but the superscript appears in the html and pdf outputs.
>>>> 
>>>> Current text: 
>>>> The total number of AES blocks
>>>> processed with a single key for AES-GCM is recommended to be less
>>>> than 2^64, as described in Appendix B of [AES-GCM].
>>>> ... 
>>>> The total number of invocations
>>>> of the authenticated encryption function with a single key for AES-
>>>> GCM is required to not exceed 2^32, as described in Section 8.3 of
>>>> [AES-GCM].
>>>> -->
>>>> 
>>>> EJB14: Concur.
>>>> 
>>>> 
>>>> 15) <!-- [rfced] Section 4.6: FYI: We updated "Chapter" to "Section" here as we see "Section" used for [AES-GCM] elsewhere in the document.
>>>> 
>>>> Original:
>>>> Methods of generating unique IV values are provided in Chapter 8
>>>> of [AES-GCM]. 
>>>> -->
>>>> 
>>>> EJB15: Section is the correct term, so changing chapter to section is the right thing to do.
>>>> 
>>>> 
>>>> 16) <!-- [rfced] Section 4.7.1: Is the word "Similarly" needed here? This sentence appears immediately after Table 7, and we are unsure what is being compared with the word "Similarly".
>>>> 
>>>> Original:
>>>> Similarly, the cipher text used during decryption MUST be calculated
>>>> as the single, definite-length CBOR byte string representing the
>>>> block-type-specific data field excluding the CBOR byte string
>>>> identifying byte and optional CBOR byte string length field.
>>>> -->
>>>> 
>>>> EJB16: The term similarly may be removed.
>>>> 
>>>> 
>>>> 17) <!-- [rfced] Sections 4.8.1 and 4.8.2: Please confirm that "inputs are prepared for input" is correct here.
>>>> 
>>>> Original:
>>>> During encryption, four inputs are prepared for input to the AES/GCM
>>>> cipher: the encryption key, the IV, the security target plain text to
>>>> be encrypted, and any additional authenticated data. 
>>>> ...
>>>> During decryption, five inputs are prepared for input to the AES/GCM
>>>> cipher: the decryption key, the IV, the security target cipher text
>>>> to be decrypted, any additional authenticated data, and the
>>>> authentication tag generated from the original encryption. 
>>>> -->
>>>> 
>>>> EJB17: The term "inputs" may be replaced with "data elements" if this current usage is confusing.
>>>> 
>>>> 
>>>> 18) <!-- [rfced] Section 5: In addition to the values in the IANA Considerations section, we see definitions of the Integrity Scope flags in Section 3.3.3 and ADD Scope flags in Section 4.3.4, which have slightly different descriptions.  
>>>> Should these descriptions exactly match the descriptions in IANA registry in Section 3.3.3 and 4.3.4?  Is "Include" intended to be part of the registered description?  
>>>> 
>>>> In addition, should "flag" be part of the description, or is it implied since it is part of the BPSec BIB-HMAC-SHA2 Integrity Scope Flags registry?  Should the Descriptions match - for example, should "Include target header flag" be "Include target header" or "Include primary block" be "Include primary block flag"?
>>>> Note that this question also applies to the "BPSec BCB-AES-GCM AAD Scope Flags" registry.  
>>>> 
>>>> -->
>>>> 
>>>> EJB18: The descriptions of flags in both 3.3.3 and 4.3.4 should match the descriptions in the IANA Considerations section for clarity. In both cases, the construct used should be "Include <item> flag".  So, "Include primary block flag", "Include target header flag", and so on.
>>>> 
>>>> 
>>>> 19) <!-- [rfced] Do "Integrity Scope Flags" and "AAD Scope Flags" here refer to the IANA registries or to the flags themselves?  Does "changes" mean "additions"?  
>>>> 
>>>> Original:
>>>> *  Ensure that any changes to the Integrity Scope Flags clearly state
>>>>   how new assignments interact with existing flags and how the
>>>>   inclusion of new assignments affects the construction of the IPPT
>>>>   value.
>>>> 
>>>> *  Ensure that any changes to the AAD Scope Flags clearly state how
>>>>   new assignments interact with existing flags and how the inclusion
>>>>   of new assignments affects the construction of the AAD input to
>>>>   the BCB-AES-GCM mechanism.
>>>> 
>>>> Perhaps (refers to registry):
>>>> *  Ensure that any changes to the "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" 
>>>>   registry clearly state how new assignments interact with existing flags 
>>>>   and how the inclusion of new assignments affects the construction of the IPPT 
>>>>   value.
>>>> 
>>>> *  Ensure that any changes to the "BPSec BCB-AES-GCM AAD Scope Flags" 
>>>>   registry clearly state how new assignments interact with existing flags 
>>>>   and how the inclusion of new assignments affects the construction of the AAD
>>>>   input to the BCB-AES-GCM mechanism.
>>>> 
>>>> Or (refers to flags themselves):
>>>> *  Ensure that any changes to the integrity scope flags clearly state
>>>>   how new assignments interact with existing flags and how the
>>>>   inclusion of new assignments affects the construction of the IPPT
>>>>   value.
>>>> 
>>>> *  Ensure that any changes to the AAD scope flags clearly state how
>>>>   new assignments interact with existing flags and how the inclusion
>>>>   of new assignments affects the construction of the AAD input to
>>>>   the BCB-AES-GCM mechanism.
>>>> -->
>>>> 
>>>> EJB19: The intent is "refers to registry" and the proposed text  "Perhaps (refers to registry):" is clarifying and preserves the original intent.
>>>> 
>>>> 
>>>> 20) <!-- [rfced] This document expands "BPA" as "bundle processing agent". We updated the expansion to be "Bundle Protocol Agent" to match the other documents in the cluster (note s/processing/protocol).  Please let us know if any corrections are needed.
>>>> 
>>>> Original: 
>>>>   If a fragment includes an encrypted
>>>>   target block, but not its BCB, then a receiving bundle processing
>>>>   agent (BPA) will not know that the target block has been
>>>>   encrypted.
>>>> -->
>>>> 
>>>> EJB20: Concur. The expansion of BPA should be as standardized across the cluster.
>>>> 
>>>> 
>>>> 21) <!-- [rfced] We lowercased "Integrity Scope Flags" and "AAD Scope Flags" here as the lowercase form is used elsewhere in the document.
>>>> 
>>>> Original:
>>>>   A security block can be cryptographically bound to a bundle by
>>>>   setting the Integrity Scope Flags (for BIB-HMAC-SHA2) or the AAD
>>>>   Scope Flags (for BCB-AES-GCM) to include the bundle primary block.
>>>> -->
>>>> 
>>>> EJB21: Concur.
>>>> 
>>>> 
>>>> 22) <!-- [rfced] May we remove the "Example X" in the following table and figure titles as "Example X" appears in the section titles? 
>>>> 
>>>> For example:
>>>> 
>>>> Current:
>>>> A.1.  Example 1: Simple Integrity
>>>> Table 11: Example 1: Original Bundle
>>>> Table 12: Example 1: Resulting Bundle  Figure 3: Example 1: 
>>>> Configuration, Parameters, and Results  Figure 4: Example 1: BIB 
>>>> Abstract Security Block (CBOR Diagnostic Notation)  Figure 5: Example 
>>>> 1: BIB (CBOR Diagnostic Notation)
>>>> 
>>>> Perhaps:
>>>> A.1.  Example 1: Simple Integrity
>>>> Table 11: Original Bundle
>>>> Table 12: Resulting Bundle
>>>> Figure 3: Configuration, Parameters, and Results  Figure 4: BIB 
>>>> Abstract Security Block (CBOR Diagnostic Notation)  Figure 5: BIB 
>>>> (CBOR Diagnostic Notation)
>>>> -->
>>>> 
>>>> EJB22: Because the appendix is so large and because the figures/tables look very similar example-to-example, we felt there was value is adding which example was which to the description. Perhaps if we used the construction (Example X) at the end it would seem cleaner, such as:
>>>> 
>>>> Table 11: Original Bundle (Example 1)
>>>> Table 12: Resulting Bundle (Example 1) Figure 3: Configuration, 
>>>> Parameters, and Results (Example 1)
>>>> 
>>>> 
>>>> 23) <!-- [rfced] Appendix A: FYI - We have updated "EndpointID" to "Endpoint ID"
>>>> here to correspond with the form used in [RFC9171]. Please let us know any objections.
>>>> 
>>>> Original:
>>>> NOTE: Examples in this section use the "ipn" URI scheme for
>>>> EndpointID naming, as defined in [I-D.ietf-dtn-bpbis].
>>>> -->
>>>> 
>>>> EJB23:  No Objections
>>>> 
>>>> 
>>>> 24) <!-- [rfced] Section A.1.1.2: Please review "Ready Generate a 32 byte payload"
>>>> here. Should this read "Ready to generate a 32-byte payload"?
>>>> 
>>>> Original:
>>>> The sample payload is a 32 byte string whose value
>>>> is "Ready Generate a 32 byte payload".
>>>> ...
>>>> The hex value of the payload
>>>> "Ready Generate a 32 byte payload" is
>>>> 0x52656164792047656e657261746520612033322062797465207061796c6f6164.
>>>> -->
>>>> 
>>>> EJB24: This will be addressed in a forthcoming .xml file.
>>>> 
>>>> 
>>>> 25) <!-- [rfced] Please confirm that "The BIB wrapping this abstract security block" is correct. Or should this read "The BIB wrapping of this abstract security block" (includes "of") or something else? Note that these sentences appear in several sections in Appendix A.
>>>> 
>>>> Original:
>>>> The BIB wrapping this abstract security block is as follows.
>>>> ...
>>>> The BCB wrapping this abstract security block is as follows.
>>>> -->
>>>> 
>>>> EJB25: The preferred term is "The complete xx is as follows."
>>>> 
>>>> OLD:
>>>> The BIB wrapping this abstract security block is as follows.
>>>> NEW:
>>>> The complete BIB is as follows.
>>>> 
>>>> OLD: 
>>>> The BCB wrapping this abstract security block is as follows.
>>>> NEW:
>>>> The complete BCB is as follows.
>>>> 
>>>> 
>>>> 26) <!-- [rfced] This document introduces BCBs as "Block Confidentiality Blocks".  However, the Appendicies refer to "Bundle Confidentiality Block" for block type 12.  Please review and let us know if "Block Confidentiality" was intended in the Appendicies.
>>>> 
>>>> Figures 9, 15, and 23:
>>>> Bundle Confidentiality Block          |   12
>>>> 
>>>> Appendicies A.2.3,, A.3.4, and A.4.4: 
>>>> Section title: Bundle Confidentiality Block
>>>> 
>>>> 
>>>> Similarly, BIBs is introduced as "Block Integrity Blocks", but the Appendicies refer to "Bundle Integrity Block" for block type 11.  Please review and let us know if "Block Integrity Block" was intended in the Appendicies.  
>>>> 
>>>> Figures 4, 15, and 23:
>>>> Bundle Integrity Block                |   11
>>>> 
>>>> Appendicies A.1.3, A.3.3, and A.4.3:
>>>> Section title: Bundle Integrity Block
>>>> 
>>>> See the IANA descriptions here: 
>>>> <https://www.iana.org/assignments/bundle/bundle.xhtml#block-types>
>>>> -->
>>>> 
>>>> EJB26: The correct term for BCB is Block Confidentiality Block. The correct term for BIB is Block Integrity Block. 
>>>> 
>>>> 
>>>> 27) <!-- [rfced] Section A.2.3: Please review "and uses AES key wrap..." here and let us know if any updates are needed.
>>>> 
>>>> Original:
>>>> In this example, a BCB is used to encrypt the payload block and uses
>>>> AES key wrap to transmit the symmetric key.
>>>> 
>>>> Perhaps:
>>>> In this example, a BCB is used to encrypt the payload block, and
>>>> AES key wrap is used to transmit the symmetric key.
>>>> 
>>>> Or:
>>>> In this example, a BCB is used to encrypt the payload block; the BCB uses
>>>> AES key wrap to transmit the symmetric key.
>>>> -->
>>>> 
>>>> EJB27: key wrap does not transmit anything - so I think the better text would be as follows:
>>>> 
>>>> OLD:
>>>> In this example, a BCB is used to encrypt the payload block and uses AES key wrap to transmit the symmetric key.
>>>> 
>>>> NEW:
>>>> In this example, a BCB is used to encrypt the payload block, and AES key wrap is used to encode the symmetric key prior to its inclusion in the BCB.
>>>> 
>>>> 
>>>> 28) <!-- [rfced] Section A.3.1.2: Should "is as" here read simply "is"?
>>>> 
>>>> Original:
>>>> The use of this block is as
>>>> recommended because the bundle source does not have an accurate clock
>>>> (as indicated by the DTN time of 0).
>>>> -->
>>>> 
>>>> EJB28: Yes - this behavior is as recommended by RFC9171. However, no meaning is lost be simply replacing "is as" with "is".
>>>> 
>>>> 
>>>> 29) <!-- [rfced] Section A.4.3: Would updating this sentence as follows improve readability of "payload block block-type-specific data"?
>>>> 
>>>> Original:
>>>> The IPPT contains the payload block block-type-
>>>> specific data, primary block data, the payload block header, and the
>>>> BIB header.  
>>>> 
>>>> Perhaps:
>>>> The IPPT contains the block-type-specific data of the payload block, 
>>>> the primary block data, the payload block header, and the
>>>> BIB header.  
>>>> -->
>>>> 
>>>> EJB29: Yes, with the caveat that there is a cluster-wide decision on the term used for block-type-specific data and we should be conformant to that.
>>>> 
>>>> 
>>>> 30) <!-- [rfced] It is ok to acknowledge Brian Sipos here, but we wonder if Brian Sipos were mentioned in the Acknowledgements section?  
>>>> 
>>>> Original:  
>>>> For informational purposes, Brian Sipos has kindly provided an  
>>>> expression of the IPPT and AAD structures using the Concise Data  
>>>> Definition Language (CDDL). That CDDL expression is presented below.  
>>>> 
>>>> Perhaps (with second block of text appearing in Acknowledgments section):  
>>>> For informational purposes, this section contains an  
>>>> expression of the IPPT and AAD structures using the Concise Data  
>>>> Definition Language (CDDL).  
>>>> 
>>>> Acknowledgements section: 
>>>> Brian Sipos has kindly provided the CDDL expression in Appendix B.  
>>>> -->
>>>> 
>>>> EJB30: Concur.  This should move to the acknowledgements section.
>>>> 
>>>> 
>>>> 31) <!-- [rfced] Please review the "Inclusive Language" portion of the 
>>>> online Style Guide 
>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>>>> and let us know if any changes are needed. 
>>>> 
>>>> In addition, please consider whether "traditional" should be updated 
>>>> for clarity (one instance in this document in Section 6.1).  While the 
>>>> NIST website (see
>>>> <https://www.nist.gov/nist-research-library/nist-technical-series-publ
>>>> ications-author-instructions#table1>)
>>>> indicates that this term is potentially biased, it is also ambiguous.
>>>> "Traditional" is a subjective term, as it is not the same for everyone.
>>>> -->
>>>> 
>>>> EJB31: The term "traditional" may simply be replaced with "other" in the one instance it appears in this document.
>>>> 
>>>> 
>>>> 32) <!-- [rfced] Terminology
>>>> 
>>>> a) We note inconsistencies in the terms below throughout the text.  Should these be uniform? If so, please let us know which form is preferred.
>>>> 
>>>> AES/GCM vs. AES-GCM
>>>> Examples: "AES-GCM cipher suite" and "AES/GCM cipher"
>>>> 
>>>> security parameter vs. security context parameter
>>>> 
>>>> EJB32a: The term AES-GCM should be used.  Similarly the term "security context parameter" should be used.
>>>> 
>>>> 
>>>> b) Please review the capitalization of the following terms in the "CBOR Encoding Type" column of the tables in Sections 3.3.4, 3.4, 4.3.5, and 4.4.2. Do you prefer to use the capitalized or lowercase form?
>>>> 
>>>> unsigned integer vs. Unsigned Integer
>>>> 
>>>> byte string vs. Byte String
>>>> 
>>>> EJB32b: We should use the CBOR encoding type capitalization strategy used by RFC9171. Generally, this should be a cluster-wide decision.
>>>> 
>>>> 
>>>> c) We see "key encryption key" "key-ecrypting key", and "key-encrypting-key" in this document. Are these the same thing? If so, may we update to "key encryption key" as that form is more common in the RFC series? We could also expand the first instance in text and use the acronym "KEK" after.
>>>> 
>>>> Note that we see "key encryption key" in RFC-to-be 9172.
>>>> 
>>>> EJB32c: We should use key encryption key, we should expand the first 
>>>> instance in text and use the acronym KEK after,
>>>> 
>>>> 
>>>> d) FYI: We expanded "CRC" as "Cyclic Redundancy Check".  Please let us know if this is incorrect. 
>>>> 
>>>> EJB32d: This is correct and should follow the expansion in RFC-to-be 9171.
>>>> 
>>>> 
>>>> e) Note that we have updated the text to use "CRC type" (i.e., lowercase "type") consistently in this document.  This is consistent with what has been done in the rest of the cluster as well.  Please let us know if any updates are needed.
>>>> 
>>>> s/CRC Type/CRC type
>>>> 
>>>> EJB32e: We should be consistent with the rest of the cluster.
>>>> 
>>>> 
>>>> f) We will update to consistently use the form on the right unless we hear objection.
>>>> 
>>>> cipher text / ciphertext
>>>> plain text / plaintext
>>>> 
>>>> EJB32f: It is OK to use the form on the right.
>>>> -->
>>>> 
>>>> EJB: Comments on 32a-f appear above as EJB32a - EJB32f. 
>>>> 
>>>> 
>>>> 33) <!-- [rfced] XML Formatting
>>>> 
>>>> a) We updated <artwork> to <sourcecode> in Appendicies A and B, using type="cbor-diag" and type="cddl".  Please review and let us know if any updates are needed.  See <https://www.rfc-editor.org/materials/sourcecode-types.txt> for details about the existing types.  If the list does not contain an applicable type, then feel free to suggest a new one.  Also, note that it is acceptable not to set leave the "type" attribute. 
>>>> 
>>>> EJB33a: The formatting change is correct.
>>>> 
>>>> 
>>>> b) The <sourcecode> blocks in the following sections now have lines that are too long (note that <sourcecode> does not outdent like <artwork> does). Please review and let us know how to best adjust/wrap the lines so that they they fit the 69-character limit for the txt output.
>>>> 
>>>> A.1.3.2
>>>> A.1.3.3
>>>> A.4.3.2
>>>> 
>>>> Note: there are some issues with long lines in the HTML and PDF files that appear outside of <sourcecode>.  For example, see Appendix A.1.1.3.  We have filed a bug report here: <https://trac.ietf.org/trac/xml2rfc/ticket/687>.  Perhaps these should be included as <sourcecode>?  See the example in Appendix A.4.5.
>>>> 
>>>> EJB33b: This change will be applied in a forthcoming updated .xml file.
>>>> 
>>>> 
>>>> c) FYI: In a number of instances, we updated <ul empty="true"> to <ul> to produce bullets in the list for the ease of the reader.
>>>> 
>>>> 3) Please review whether any of the notes in this document (i.e., text
>>>> prefaced with "NOTE:" or "NOTES:") should be in the <aside> element. The
>>>> <aside> element is defined as "a container for content that is semantically
>>>> less important or tangential to the content that surrounds it"
>>>> (see https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-aside-2).
>>>> 
>>>> EJB33c: The NOTE(s) in sections 3.2, 4.2, the first NOTE of section 4.4, and the first NOTE of Appendix A can be used in the <aside> element. If having one NOTE be in <aside> and the other not be in <aside> in section 4.4 looks odd, then both notes in section 4.4 can be kept as-is.
>>>> 
>>>> -->
>>>> 
>>>> EJB33: The responses to 33a-33c are included above as EJB33a: - EJB33c:
>>>> 
>>>> Thank you.
>>>> 
>>>> RFC Editor
>>>> 
>>>> 
>>>> On Nov 23, 2021, at 2:26 PM, [e-mail] wrote:
>>>> 
>>>> *****IMPORTANT*****
>>>> 
>>>> Updated 2021/11/23
>>>> 
>>>> RFC Author(s):
>>>> --------------
>>>> 
>>>> Instructions for Completing AUTH48
>>>> 
>>>> Your document has now entered AUTH48.  Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC.  
>>>> If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>>> 
>>>> You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval.
>>>> 
>>>> Planning your review
>>>> ---------------------
>>>> 
>>>> Please review the following aspects of your document:
>>>> 
>>>> *  RFC Editor questions
>>>> 
>>>> Please review and resolve any questions raised by the RFC Editor  
>>>> that have been included in the XML file as comments marked as
>>>> follows:
>>>> 
>>>> <!-- [rfced] ... -->
>>>> 
>>>> These questions will also be sent in a subsequent email.
>>>> 
>>>> *  Changes submitted by coauthors
>>>> 
>>>> Please ensure that you review any changes submitted by your  
>>>> coauthors.  We assume that if you do not speak up that you  agree to 
>>>> changes submitted by your coauthors.
>>>> 
>>>> *  Content
>>>> 
>>>> Please review the full content of the document, as this cannot  
>>>> change once the RFC is published.  Please pay particular attention to:
>>>> - IANA considerations updates (if applicable)
>>>> - contact information
>>>> - references
>>>> 
>>>> *  Copyright notices and legends
>>>> 
>>>> Please review the copyright notice and legends as defined in  RFC 
>>>> 5378 and the Trust Legal Provisions  (TLP – 
>>>> https://trustee.ietf.org/license-info/).
>>>> 
>>>> *  Semantic markup
>>>> 
>>>> Please review the markup in the XML file to ensure that elements of  
>>>> content are correctly tagged.  For example, ensure that <sourcecode>  
>>>> and <artwork> are set correctly.  See details at  
>>>> <https://xml2rfc.tools.ietf.org/xml2rfc-doc.html>.
>>>> 
>>>> *  Formatted output
>>>> 
>>>> Please review the PDF, HTML, and TXT files to ensure that the  
>>>> formatted output, as generated from the markup in the XML file, is  
>>>> reasonable.  Please note that the TXT will have formatting  
>>>> limitations compared to the PDF and HTML.
>>>> 
>>>> 
>>>> Submitting changes
>>>> ------------------
>>>> 
>>>> To submit changes, please reply to this email with one of the following, using ‘REPLY ALL’ as all the parties CC’ed on this message need to see your changes:
>>>> 
>>>> An update to the provided XML file
>>>> — OR —
>>>> An explicit list of changes in this format
>>>> 
>>>> Section # (or indicate Global)
>>>> 
>>>> OLD:
>>>> old text
>>>> 
>>>> NEW:
>>>> new text
>>>> 
>>>> You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient.
>>>> 
>>>> We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes.  Information about stream managers can be found in the FAQ.  Editorial changes do not require approval from a stream manager.
>>>> 
>>>> 
>>>> Approving for publication
>>>> --------------------------
>>>> 
>>>> To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication.  Please use ‘REPLY ALL’, as all the parties CC’ed on this message need to see your approval.
>>>> 
>>>> 
>>>> Files
>>>> -----
>>>> 
>>>> The files are available here:
>>>> https://www.rfc-editor.org/authors/rfc9173.xml
>>>> https://www.rfc-editor.org/authors/rfc9173.html
>>>> https://www.rfc-editor.org/authors/rfc9173.pdf
>>>> https://www.rfc-editor.org/authors/rfc9173.txt
>>>> 
>>>> Diff file of the text:
>>>> https://www.rfc-editor.org/authors/rfc9173-diff.html
>>>> https://www.rfc-editor.org/authors/rfc9173-rfcdiff.html (side by 
>>>> side)
>>>> 
>>>> Diff of the XML: 
>>>> https://www.rfc-editor.org/authors/rfc9173-xmldiff1.html
>>>> 
>>>> Tracking progress
>>>> -----------------
>>>> 
>>>> The details of the AUTH48 status of your document are here:
>>>> https://www.rfc-editor.org/auth48/rfc9173
>>>> 
>>>> Please let us know if you have any questions.  
>>>> 
>>>> Thank you for your cooperation,
>>>> 
>>>> RFC Editor
>>>> 
>>>> --------------------------------------
>>>> RFC9173 (draft-ietf-dtn-bpsec-default-sc-11)
>>>> 
>>>> Title            : BPSec Default Security Contexts
>>>> Author(s)        : E.J. Birrane, A. White, S. Heiner
>>>> WG Chair(s)      : Edward J. Birrane, Rick Taylor
>>>> Area Director(s) : Martin Duke, Zaheduzzaman Sarker
>>> 
>>> <rfc9173_edited.xml>
>> 
>