[Speaking as an author]
On 5/22/26 16:08, [email protected] wrote:
1) <!-- [rfced] FYI - We have updated the title as shown below to expand "BFD".
Please review and let us know any objections.
Current:
Meticulous Keyed ISAAC for Bidirectional Forwarding
Detection (BFD) Optimized Authentication
-->
Accepted.
2) <!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use onhttps://www.rfc-editor.org/search.
-->
I have nothing further to add.
3) <!-- [rfced] Please review whether any of the notes in this document
should be in the <aside> element. It is defined as "a container for
content that is semantically less important or tangential to the
content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
I am unclear what notes we're discussing. The RFC Editor markup on what
we're reviewing?
4) <!-- [rfced] May we rephrase the sentence below as follows for clarity?
Original:
An instance of ISAAC is created for transmission and one for
reception.
Perhaps:
Two instances of ISAAC are created: one for transmission and one for
reception.
-->
The new version is clearer.
5) <!-- [rfced] Would it be helpful for readers to have the definition list in
Section 7 reformatted as two subsections after Section 7?
Perhaps:
7. Procedures for BFD Authentication using Meticulous Keyed ISAAC,
ISAAC Format
...
7.1. Transmission Using Meticulous Keyed ISAAC Authentication, ISAAC Format
The Auth Type field MUST be set to one of two values...
7.2. Receipt Using Meticulous Keyed ISAAC Authentication, ISAAC Format
If the received BFD Control packet does not contain an Authentication
Section...
-->
Splitting these into subsections might be better.
6) <!-- [rfced] FYI - We have removed the lone quotation mark from this
sentence. If there was an intended quote here, let us know and
we will update the text.
Original:
That is, there is no "length field which indicates how
long the Secret Key is, and there is no trailing zero or NUL byte
which indicates the end of the Secret Key.
Current:
That is, there is no length field that indicates how
long the Secret Key is and there is no trailing zero or NUL byte
that indicates the end of the Secret Key.
-->
I think this is fine.
7) <!-- [rfced] Some author comments are present in the XML. Please confirm
that no updates related to these comments are outstanding. Note that the
comments will be deleted prior to publication.
-->
Removing the author comments is fine.
8) <!-- [rfced] The following citation refers to Section 10 of RFC 5880,
which is the References section. Please review and let us know
how this sentence should be updated to include the correct
section number.
Current:
For security, each implementation SHOULD randomize their discriminator
fields at the start of a session, as discussed in [RFC5880], Section
10.
-->
Section 9 (Security Considerations) is the appropriate reference.
9) <!-- [rfced] Would you like to make use of <sup> for superscript in this
document? In the HTML and PDF outputs, it will appear as superscript. In the
text output, <sup> generates a^b, which was used in the original document.
-->
As long as all formats make it clear that mathematical exponentiation is
being used, this would be good.
10) <!--[rfced] We have received guidance from Benoit Claise and the YANG
Doctors that "YANG module" and "YANG data model" are preferred.
We have updated the text to use these forms. Please review.
-->
This question should be directed to Mahesh.
11) <!-- [rfced] RFC 8177 does not use the term "IETF Keychain Model" (it
does use "YANG key chain model"). Please let us know how we
should update this sentence (or if any updates are needed).
Current:
This YANG module adds two identities defined in this document to the
IETF Keychain Model [RFC8177].
Perhaps:
This YANG module adds two identities defined in this document to the
YANG key chain model described in [RFC8177].
-->
The update is fine.
12) <!--[rfced] The YANG module (Section 13) has been updated as shown
below per the formatting option of pyang. Please let us know of
any concerns.
- Removed the quote marks from the prefix "bfd-mki"
- Removed the quote marks from the revision date
-->
This question is for Mahesh, but I believe it is fine.
13) <!--[rfced] We have updated "SHA1" to "SHA-1" throughout this document
for consistency with the companion document. This includes the
following Auth Type registered with IANA (note that we will
communicate this change to them, if agreeable). Please let us know
of any objection.
Current (Section 14.4):
8: Optimized SHA-1 Meticulous Keyed ISAAC Authentication
-->
For the text updates, I think this is fine.
It would be good to get external review to ensure that the YANG uses,
which are currently "sha1", are consistent with how this cipher is
referenced in other IETF YANG work. Mahesh, and perhaps the SEC-ADs
might have suggestions.
14) <!-- [rfced] We have a few questions regarding this sentence.
a) RFC 8439 uses "ChaCha" rather than "CHACHA". May we update as
follows? Also, is this a list of three items as shown below?
Current:
Alternative solutions could be AES with hardware acceleration in
Output Feedback Mode (OFB) (FIPS 197, SP 800-38A), or CHACHA
in software [RFC8439], or other well-understood techniques.
Perhaps:
Alternative solutions could be AES with hardware acceleration in
Output Feedback Mode (OFB) (see FIPS 197 and SP 800-38A), ChaCha in
software [RFC8439], or other well-understood techniques.
Consistency with the referenced RFC is best here.
b) Would you like to add citations for "FIPS 197" and "NIST SP
800-38A" in this sentence with corresponding entries in the
Informative References section?
-->
I have no specific references to add for these. Perhaps the SEC-ADs
might have appropriate references.
15) <!-- [rfced] May we rephrase the sentence below for readability and to
specify
what is being protected?
Original:
Meticulously Keyed ISAAC authentication protects vs. the spoofing of
BFD Up packets and keeping the BFD session Up when it would otherwise
be reset.
Perhaps:
Meticulously Keyed ISAAC authentication protects the session against the
spoofing of BFD Up packets and keeps the BFD session Up when it would
otherwise be reset.
-->
This seems better.
16) <!--[rfced] *AD, we note that the YANG Security Considerations
(Section 15.2 in this document) varies from the template
in Section 3.7.1 of RFC 9907. We updated the first
three paragraphs in this document to match the template. Please
review and also provide guidance for the following questions:
a) Paragraph 4 from the template is missing in this document. Should
"There are no particularly sensitive writable data nodes." be included
in this document to address this?
b) Paragraph 5 from the template is missing in this document. Should
"There are no particularly sensitive readable data nodes." be included
in this document to address this?
c) Paragraph 6 from the template is missing in this document. Should
"There are no particularly sensitive RPC or action operations." be
included in this document to address this?
d) Paragraph 4 in this document almost matches paragraph 8 in the
template (which begins with "The YANG module defines a set of
identities, types, and groupings."). Note that "types" and "groupings"
haven been omitted. Please let us know if this is okay or if any
updates are needed for consistency with the template.
-->
17) <!-- [rfced] For the "[ISAAC_]" reference, we recommend changing the
citation
tag since "[ISAAC]" and "[ISAAC_]" may be easily confused. May we update
"[ISAAC_]" to "[ISAAC+]" or "[ISAAC-Plus]"?
-->
This question to be answered by Alan and the SEC-ADs.
18) <!-- [rfced] Terminology
a) Please review the following terms and let us know how we should update
for consistency. If there are no objections, we will use the form on
the right.
Sequence number vs. sequence number vs. Sequence Number
secret key vs. secret Key vs. Secret Key
b) Throughout the text, we note the following variances.
Are these forms okay as is, or are any updates needed for
consistency? Please review.
BFD Optimized Authentication
BFD Optimized Authentication Mode
BFD optimized authentication modes
Optimized BFD
Optimized BFD authentication modes
Optimized Authentication Mode field
Optimized Authentication mode
Optimization Mode
We are looking for consistency using RFC 5880 for the sequence number
capitalization.
For the optimized authentication, consistency vs. the impending RFC 9985
is our goal here.
The nouns above perhaps cover slightly different contexts requiring
editorial judgment:
- BFD Optimized Authentication is the broad set of procedures we are
specifying.
- BFD Optimized Authentication Mode is a form of BFD Authentication
(c.f. RFC 5880) that may be selected, and is implemented by this
specification.
- Optimized BFD in most of the contexts above are likely forms of BFD
Optimized Authentication. I do see in the current document that this
manifests primarily in the PDU format (section 4.1) as a bare-named
field lacking the BFD designation. In that context, the BFD is
redundant. However, if consistency makes for cleaner reading we can
consider expanding the full name. It is important that the forms be
consistent between this RFC-to-be and RFC 9985-to-be.
Meticulous Keyed ISAAC Authentication
Meticulously Keyed ISAAC authentication
The forms of the second sentence above can be changed to "Meticulous
Keyed".
Meticulous Keyed ISAAC authentication mode
There is a single use of this in the document. The trailing "mode" can
perhaps be dropped, as long as the context is clear.
Meticulous Keyed ISAAC Auth Type
This form is appropriate.
Meticulous Keyed ISAAC
Meticulous keyed ISAAC
The forms I see these in are paired to the sha-1 and md-5 forms of the
mode. We are looking for consistency for those pairings. The
capitalization for keyed can match the other instances.
Meticulous Keyed ISAAC Keyed
[Note: Is the second "Keyed" correct here? There are 4 instances.]
These instances look like a search and replace issue. I believe the
intention here is that each of these instances is intended to be
"Meticulous Keyed ISAAC, ISAAC format". This should be audited by Alan.
Meticulous Keyed ISAAC MD5 Authentication Format
There are three distinct formats we're trying to get consistency with.
These are identified by the subsections of section 4. They are the MD5,
SHA-1, and ISAAC formats.
Meticulous Keyed ISAAC Authentication Format
I think this is intended to be the ", ISAAC format".
ISAAC authentication format
Ditto.
Optimized MD5 Meticulous Keyed ISAAC Authentication
[Note: Are any of the instances above referring to this
Auth Type, which is registered with IANA? Please let us
know if any updates are needed for consistency.]
-->
The instance of this and the SHA-1 entry likely should be the ", MD5
format" and ", SHA-1 format" forms.
19) <!-- [rfced] FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
-->
At first glance, these all seem fine. I'll finish a deeper audit as part
of final approval.
20) <!-- [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. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
I believe nothing is applicable here.
Thanks!
-- Jeff
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
