Meticulous Keyed ISAAC for BFD Optimized Authentication
draft-ietf-bfd-secure-sequence-numbers-27

[Ballot comment]
Thanks for the work done in this document even if no implementations are planned, hence my ABSTAIN (also for the use of "optimized" rather than "lightweight").

See previous ballot at:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/13nhp2RXGGU50Jd5W6yl4WUNEVs/

[Ballot comment]
Update:  Many thanks to the authors for the tremendous amount of work done to address my discuss.  [Note:  I've left my comments below as I wrote them initially, just for historical purposes.]


Thanks to Rich Salz for their secdir review.

Section 1:  Please mention earlier in the specification that this technique can only be used in conjunction with draft-ietf-bfd-optimizing-authentication.  As it stands, there is no use for this specification without that specification.

Section 1:  Please add a little bit more explanation to remind the reader why these normally fast hashes are too slow/hard.  Please address both speed of the transmission and capability of the device performing the hashes.

Section 1, Paragraph 3 and many other places: significant cryptanalysis/some cryptanalysis (2 documented efforts over 30 years is hardly 'significant').  I'm not sure who the authors are trying to convince.

Section 2:  Please define CSPRNG (I don't care where).  This draft currently makes the assumption that everyone knows what a CSPRNG is. [Note:  even though RFC 4086 is a decade younger than ISAAC, it is not considered to be up-to-date]

Section 4.1, sequence number and Section 6, para 1:  It is unclear to me how an unprotected sequence number prevents a replay attack.  Certainly the attacker can change the sequence number, or replay a packet with a modified sequence number.  The only protection against replay attacks for this system is via the Auth Key.  The sequence number is merely helpful for the recipient to attempt to determine the place on the table (and that only works if the packet hasn't been replayed).

Section 4.2 and 4.3:  These sections are merely repeats of sections in draft-ietf-bfd-optimizing-authentication?

Section 6, 'The Auth key field:  Where the sequence number is merely an index into the table of 256 values, no?  The sequence number is not part of the seeding of ISAAC.

Section 7:  Some of the state variables defined here have been used earlier in the specification.  Consider moving this section up to a place before the variables are used.

Section 8, para 2:  Multiple Secret Keys:  If this specification doesn't want to explain how they are used, then one should say they are 'out of scope'.  Please put the 'MUST NOT' sentence second in the paragraph (and remove the 'however'.  This puts the requirement where it will be more easily seen (i.e. don't bury the lead).

Section 8, para 3:  This could easily be put in Security Considerations.

Section 8:  How are the per party secret keys generated, distributed, protected?  If that is in scope, please describe.  If it is out of scope, please add appropriate guidance to Security Considerations. 

Section 9, para 8,9,&10:  Starting a paragraph with 'However' isn't clear.  Remove the 'However', add the word 'state' to variables, and combine the paragraphs/sentences.  Remove the last paragraph, or move it into Section 10.

Section 10, para 1:  This is the very first mention of 'Your Discriminator' field.  No where in the previous sections is this field discussed, defined.  In addition My Discriminator and Your Discriminator changes depending on perspective.  Does the sending and receiving systems use the same field (presumably with different values)?

Section 10:  In addition to ISAAC, a system is required to have a second CSPRNG to generate session seeds?

Section 11.2, para 1:  This paragraph is not about multiple keys, but about key distribution. Please rename this to 'Secret Key Distribution' (if indeed this section is about Secret Keys).  What keys are being discussed here?  The Secret Key?  Are you saying that distribution of the Secret Key (aka password) is out of scope? 

Section 11.2, para 2:  The discussion of multiple keys needs to be defined to be out of scope too (again?).

Section 12:  I thought that draft-ietf-optimizing-authentication required that 'strong' authentication was used periodically, see Section 5.  'Thousands of packets' doesn't seem to be what was being proposed in that draft.  Please make these estimation of number of packets (currently thousands and hundreds) more realistic.

Section 15:  Please add a section about CSPRNGs.  Describe the requirements for strength and assurance.  There are multiple mentions of CSPRNG for all the various fields used in BFD (Session Seeds, Secret Keys, Sequence Numbers).  What are the consequences of using a sub par PRNG?  What are the mitigations? 

Section 15:  If the Secret Key is basically a password (see Section 10 test vectors) please explain how that generation should be accomplished.  Also please explain why a PBKDF isn't used to distribute what little entropy is in that password.  Or alternatively, explain how a PBKDF could be used.  Note:  since this is virtually the only value not transmitted across the network in the clear, it is the only unknown value to the attacker on the network.

Section 15.1, last paragraph:  Please tone down the 'analyzed for almost 3 decades' language.  I'm also curious about the perceived ineffectiveness of AES (which is commonly a standard cell in most CPUs).  The choice of AES in a stream cipher mode might have been just as quick, and certainly has almost 3 decades of real analysis.

Section 15.1.1, last paragraph:  More accurately, this technique prevents the attacker from spoofing UP packets.  It absolutely does not do anything to protect availability, injection of spoofed packets can take down a link (the definition of availability, right?).  If there is an ability to modify/block packets will destroy the link in very little time.  Please correct.

Section 15.1.2:  Are you recommending that the keys used for keyed MD5, keyed SHA1, and ISAAC be the same (aka the Secret Key)?  Please change this.  Any leak of any one of these keys (the ISAAC version is specified to be a password) would result in the attacker being able to construct any BFD packet, for any purpose.

[Ballot comment]
The shepherd report states that there are "no implementations and no known plans to implement."  Why publish this document if there no plans to run the experiment?

====
I support the DISCUSS position of Deb Cooley.

Thank you to Mallory Knodel for the GENART review.

** idnits reports:
  == The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords -- however, there's a paragraph with
    a matching beginning. Boilerplate error?

[Ballot comment]
If there are no implementations and no plans to implement, why are we publishing this?

In Section 3.1, "is fully use" doesn't parse. Given that it talks about the computation taking noticeable time, I thought this wasn't a simple typo of "is fully used" (i.e. consumed), but Section 11.1 suggests that it might be. Should this be something like "becomes active" or more explicitly "after a packet is received which falls into the current page"? Do we really wait for all values on one page to have been consumed before beginning computation of the next page when "the next page calculation is complex, and there is a long period of time available before the next page is needed"?

I do appreciate the discussion in the Security Considerations of why the potential attacks are likely irrelevant, and would suggest copying similar language into draft-ietf-bfd-optimizing-authentication.

===NITS FOLLOW===
Section 3.1, "of design" => "by design"?
Section 10, "Where the" => "The"
Section 15.1.1, "infeasibe" => "infeasible"

[Ballot comment]
I support the DISCUSS position of Deb Cooley.

Thank you to Mallory Knodel for the GENART review.

** idnits reports:
  == The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords -- however, there's a paragraph with
    a matching beginning. Boilerplate error?

[Ballot discuss]
Discuss:  A discuss is merely the start of a conversation.  The terseness of this review reflects on my history (37 years as a security evaluator).  I believe it is possible to get this draft to publication, but it will take real work (I'm happy to help). This is a list of the areas that I believe are poorly specified:

1. operating situation:  Fast networks speeds combined with inadequate CPU capability will drive the solution which is practical.  Please explain this.

        2.  Use of previously unheard of 30 year old algorithms:  In this particular case, because the security requirements are rudimentary at best, this is ok.  But the draft needs to reduce the language leading the reader to overestimate the strength or assurance provided by this algorithm.  This includes 'significant evaluation', 'strong authentication', etc.  Security Considerations needs to state clearly that this algorithm is approved only for this use case, under these operating conditions (speed of network, capability of CPU) and no others.

3.  key management:  There is very little information in this draft that outlines how various keys (per party Secret keys, per session seeds, initial sequence numbers) are handled.  This includes generation, distribution, storage, and removal.  While there are many references to a 'cryptographically strong pseudo-number generator', it is never defined.  The test data in Section 10 apparently encourages operators to use a password as a Secret Key without any further processing (no pbkdf required, apparently).  There is no mention in the Security Considerations to caution the implementer on what care needs to be taken with respect to these values, and their handling. 

My comments below may point back to this discuss.

[Ballot comment]

Thanks to Rich Salz for their secdir review.

Section 1:  Please mention earlier in the specification that this technique can only be used in conjunction with draft-ietf-bfd-optimizing-authentication.  As it stands, there is no use for this specification without that specification.

Section 1:  Please add a little bit more explanation to remind the reader why these normally fast hashes are too slow/hard.  Please address both speed of the transmission and capability of the device performing the hashes.

Section 1, Paragraph 3 and many other places: significant cryptanalysis/some cryptanalysis (2 documented efforts over 30 years is hardly 'significant').  I'm not sure who the authors are trying to convince.

Section 2:  Please define CSPRNG (I don't care where).  This draft currently makes the assumption that everyone knows what a CSPRNG is. [Note:  even though RFC 4086 is a decade younger than ISAAC, it is not considered to be up-to-date]

Section 4.1, sequence number and Section 6, para 1:  It is unclear to me how an unprotected sequence number prevents a replay attack.  Certainly the attacker can change the sequence number, or replay a packet with a modified sequence number.  The only protection against replay attacks for this system is via the Auth Key.  The sequence number is merely helpful for the recipient to attempt to determine the place on the table (and that only works if the packet hasn't been replayed).

Section 4.2 and 4.3:  These sections are merely repeats of sections in draft-ietf-bfd-optimizing-authentication?

Section 6, 'The Auth key field:  Where the sequence number is merely an index into the table of 256 values, no?  The sequence number is not part of the seeding of ISAAC.

Section 7:  Some of the state variables defined here have been used earlier in the specification.  Consider moving this section up to a place before the variables are used.

Section 8, para 2:  Multiple Secret Keys:  If this specification doesn't want to explain how they are used, then one should say they are 'out of scope'.  Please put the 'MUST NOT' sentence second in the paragraph (and remove the 'however'.  This puts the requirement where it will be more easily seen (i.e. don't bury the lead).

Section 8, para 3:  This could easily be put in Security Considerations.

Section 8:  How are the per party secret keys generated, distributed, protected?  If that is in scope, please describe.  If it is out of scope, please add appropriate guidance to Security Considerations. 

Section 9, para 8,9,&10:  Starting a paragraph with 'However' isn't clear.  Remove the 'However', add the word 'state' to variables, and combine the paragraphs/sentences.  Remove the last paragraph, or move it into Section 10.

Section 10, para 1:  This is the very first mention of 'Your Discriminator' field.  No where in the previous sections is this field discussed, defined.  In addition My Discriminator and Your Discriminator changes depending on perspective.  Does the sending and receiving systems use the same field (presumably with different values)?

Section 10:  In addition to ISAAC, a system is required to have a second CSPRNG to generate session seeds?

Section 11.2, para 1:  This paragraph is not about multiple keys, but about key distribution. Please rename this to 'Secret Key Distribution' (if indeed this section is about Secret Keys).  What keys are being discussed here?  The Secret Key?  Are you saying that distribution of the Secret Key (aka password) is out of scope? 

Section 11.2, para 2:  The discussion of multiple keys needs to be defined to be out of scope too (again?).

Section 12:  I thought that draft-ietf-optimizing-authentication required that 'strong' authentication was used periodically, see Section 5.  'Thousands of packets' doesn't seem to be what was being proposed in that draft.  Please make these estimation of number of packets (currently thousands and hundreds) more realistic.

Section 15:  Please add a section about CSPRNGs.  Describe the requirements for strength and assurance.  There are multiple mentions of CSPRNG for all the various fields used in BFD (Session Seeds, Secret Keys, Sequence Numbers).  What are the consequences of using a sub par PRNG?  What are the mitigations? 

Section 15:  If the Secret Key is basically a password (see Section 10 test vectors) please explain how that generation should be accomplished.  Also please explain why a PBKDF isn't used to distribute what little entropy is in that password.  Or alternatively, explain how a PBKDF could be used.  Note:  since this is virtually the only value not transmitted across the network in the clear, it is the only unknown value to the attacker on the network.

Section 15.1, last paragraph:  Please tone down the 'analyzed for almost 3 decades' language.  I'm also curious about the perceived ineffectiveness of AES (which is commonly a standard cell in most CPUs).  The choice of AES in a stream cipher mode might have been just as quick, and certainly has almost 3 decades of real analysis.

Section 15.1.1, last paragraph:  More accurately, this technique prevents the attacker from spoofing UP packets.  It absolutely does not do anything to protect availability, injection of spoofed packets can take down a link (the definition of availability, right?).  If there is an ability to modify/block packets will destroy the link in very little time.  Please correct.

Section 15.1.2:  Are you recommending that the keys used for keyed MD5, keyed SHA1, and ISAAC be the same (aka the Secret Key)?  Please change this.  Any leak of any one of these keys (the ISAAC version is specified to be a password) would result in the attacker being able to construct any BFD packet, for any purpose.

[Ballot comment]
Hi Jeff, all,

Thanks for addressing the DISCUSS/COMMENT points [1]. I trust that you will move 8177 to be listed as normative, though.

Cheers,
Med

[1] https://github.com/mjethanandani/bfd-secure-sequence-numbers/pull/49 and https://github.com/bfd-wg/optimized-auth/pull/73/

[Ballot discuss]
Hi Alan DeKok, Mahesh, Sonal, Ashesh, and Jeff,

Thanks also to Yingzhen Qu for an OPSDIR review of an early version and to the authors for the follow-up.

# DISCUSS

I don’t understand the need for the YANG module as these identities are also defined in draft-ietf-bfd-optimizing-authentication.

Any reason why this is defined?

Cheers,
Med

[Ballot comment]
# Internet AD comments for draft-ietf-bfd-secure-sequence-numbers-24
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S3.1

* "and the numbers produced by it are secure"

  Claiming "are secure" seems a bit imprecise.  Perhaps "are sufficiently
  secure for the BFD authentication purposes here" or something?

### S8

* "makes these attacks unfeasable"

  Should this be more like "computationally infeasible" or
  "computationally intractable" or something?

## Nits

### S1

* "therefore define a Optimized" ->
  "therefore defines an Optimized"

### S3.1

* "rates of hundred of packets per second" ->
  "rates of hundreds of packets per second" ?

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-bfd-secure-sequence-numbers-23
CC @evyncke

Thank you for the work put into this document. I find the idea smart and useful.

Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Reshad Rahman for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I am puzzled though by `No implementations and no known plans to implement.` ... It also claims that there is no YANG module while there is one.

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Update to RFC 5880

As the section 2 contains `this document describes an experimental update to BFD [RFC5880].`, then I think that there is a need for an "Update" tag.

[Ballot comment]

## COMMENTS (non-blocking)

### No implementation plans ?

Per shepherd's write-up: `No implementations and no known plans to implement.` ... This is rather sad for a set of 3 I-Ds.

### Use of optimized

Like Gorry, I would prefer "lightweight" rather than "optimized" (the latter being a little unclear about which part is optimized).

### Abstract

s/This document describes a *new* BFD/This document describes a BFD/

### Section 1

Even if obvious, s/it is possible for an attacker/it is possible for an *on-path* attacker/

### Section 1.1

BIG thank you for the explanation about "meticulous" :-)

### Sectin 2

Please consider rewriting `existing document` as this I-D will be a RFC once published and this sentence will flip sense.

### Section 3

The SEC ADs will have a better view of course, but why `Auth Keys` as they are more suitable terms such as "nonces" or "cookies" (like TCP cookies)?

### Section 3.1

Who is the "we" in `so we explain why ISAAC was chosen` ? The authors ? The WG ? The IETF community ? Please rephrase to avoid using "we".

Possible typo in `the internal state un an irreversible fashion`

s/secret key/shared key/ ?

The page size of 256 sequence number is not really justified, I would naively have expected a much larger "page". Rate of 100's of pps is rather low level.

### Section 4

Unsure how to address my comment, but I had to read twice the subsection to understand the role of "opt mode". A leading text would make the reading task easier.

Also, why using a full octet for just 1 bit of information?

### Section 4.3

The figure 3 should be clearer that the "auth key" is 20 octets long.

Also, the text is about "Auth Key/Digest" and not about "Hash"

### Section 6

It is unclear whether the procedure applies to all BFD packets or only to the non-Up ones.

[Ballot comment]
Thank you for preparing this I-D, and the careful text around how
this provides an experimental change to BFD.

The I-D seems related to I-D.ietf-bfd-optimizing-authentication.
Whereas the current I-D in general is carefully constructed around
the wording of security properties, the words here do not explain
"optimizing" or "optimized" - which appear not to relate to security
properties. For example, the following text states:

    "When the bfd.SessionState value is Up, packets MAY use an
      optimized authentication method (Optimizing BFD Authentication..."

- As noted to the Editors of I-D.ietf-bfd-optimizing-authentication,
I do wonder if this would be better described as lightweight/reduced processing
requirements.

I do not have any additional transport-related comments for this I-D.

Best wishes,
Gorry

[Ballot comment]
This document is one of a 3 document set from the BFD WG that enhances BFD authentication mechanism. The suggested order for reviewing them is as follows:

1) draft-ietf-bfd-optimizing-authentication (specifies extension to BFD auth with an optimized auth mechanism)
2) draft-ietf-bfd-secure-sequence-numbers (specifies an optimized auth mechanism based on meticulously keyed ISAAC that uses (1))
3) draft-ietf-bfd-stability (is not an auth mechanism but uses the auth sequence numbers for monitoring loss of BFD packets)

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-bfd-secure-sequence-numbers-22. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions which we must complete.

First, in the BFD Authentication Types registry in the Bidirectional Forwarding Detection (BFD) Parameters registry group located at:

https://www.iana.org/assignments/bfd-parameters/

two new registrations will be made as follows:

Address: [ TBD-at-Registration ]
BFD Authentication Type Name: Optimized MD5 Meticulous Keyed ISAAC Authentication
Reference: [ RFC-to-be ]

Address: [ TBD-at-Registration ]
BFD Authentication Type Name: Optimized SHA-1 Meticulous Keyed ISAAC Authentication
Reference: [ RFC-to-be ]

IANA notes that the authors suggest values of 7 and 8 for these registrations.

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the ns registry in the IETF XML Registry group located at:

https://www.iana.org/assignments/xml-registry/

a single new namespace will be registered as follows:

ID: yang:ietf-bfd-met-keyed-isaac
URI: urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-isaac
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this also requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

Third, in the YANG Module Names registry on the YANG Parameters registry group located at:

https://www.iana.org/assignments/yang-parameters/

a single new YANG module will be registered as follows:

Name: ietf-bfd-met-keyed-isaac
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-met-keyed-isaac
Prefix: bfdmia
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-08-18):

From: The IESG
To: IETF-Announce
CC: Reshad Rahman , bfd-chairs@ietf.org, draft-ietf-bfd-secure-sequence-numbers@ietf.org, ketant.ietf@gmail.com, rrahman@cisco.com, rtg-bfd@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Meticulous Keyed ISAAC for BFD Optimized Authentication) to Experimental RFC


The IESG has received a request from the Bidirectional Forwarding Detection
WG (bfd) to consider the following document: - 'Meticulous Keyed ISAAC for
BFD Optimized Authentication'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-08-18. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes a new BFD Optimized Authentication Mode,
  Meticulous Keyed ISAAC Authentication.  This mode can be used to
  authenticate BFD packets with less CPU time cost than using MD5 or
  SHA1, with the tradeoff of decreased security.  This mechanism cannot
  be used to signal state changes, but it can be used to maintain a
  session in the the "Up" state.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bfd-secure-sequence-numbers/



No IPR declarations have been submitted directly on this I-D.

Review of draft-ietf-bfd-secure-sequence-numbers-22
=======================================================================================

Authors have addressed AD-review comments @
https://mailarchive.ietf.org/arch/msg/rtg-bfd/2jnbFMQkrTsgwAJ0qzRRbWzczgs/

Shepherding co-chair then asked for comments on the updates, see
https://mailarchive.ietf.org/arch/msg/rtg-bfd/dvdro7nBOEu8WKr2Y0VKOz7jZCA/

Some nits need to be addressed, they were mentioned @
https://mailarchive.ietf.org/arch/msg/rtg-bfd/aeaBX7ZFDlupcxpjydgRttHaCtE/

Review of draft-ietf-bfd-secure-sequence-numbers-20
=======================================================================================
## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
Strong consensus of a few individuals.
The initial revision of this document is from 2017. Goal was to address
concerns expressed by Security Area on the work to optimize BFD authentication
(draft-ietf-bfd-optimizing-authentication). There have not been many comments
on this document specifically, but there have been many discussions on what this
document provides in the context of draft-ietf-bfd-optimizing-authentication.
Revision 9 of this document is the first one which mentions use of ISAAC.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
No controversy on this document.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
No implementations and no known plans to implement.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
No and no.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written and ready.
The authors have addressed all review comments.
https://mailarchive.ietf.org/arch/msg/rtg-bfd/d8V4BhioRGXmwGDZgqcO-rG9O7o/

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Secdir review @ https://mailarchive.ietf.org/arch/msg/rtg-bfd/9ieykoBqnSf4vJfLvRpmtkaERDw/
The comments have been addressed afaik, but I couldn't find a response. I've requested the authors to respond.

Opsdir review @ https://mailarchive.ietf.org/arch/msg/ops-dir/vb21FUcQ9kuPxR8pBW-wc72axS8/

Rtgdir review @ https://mailarchive.ietf.org/arch/msg/rtg-dir/pZLg4723nk9pVquZ0hdqVv4Fek8/

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])?

Experimental as indicated on title page.

    Why is this the proper type
    of RFC?

  Here are the reasons why this document is on the
  Experimental track:

  *  In the initial stages of the document, there were significant
      participation and reviews from the working group.  Since then,
      there has been considerable changes to the document, e.g. the use
      of ISAAC, allowing for ISAAC bootstrapping when a BFD session
      comes up etc.  These changes did not get
      significant review from the working group and therefore does not
      meet the bar set in Section 4.1.1 of [RFC2026]

  *  There are no known implementations (even proof-of-concept) or
      implementation plans.  As a result, we do not currently know if
      there will be interop issues with legacy implementations or what
      exactly are the performance benefits of the optimization method.

  *  The work in this document could become very valuable in the
      future, especially if the need for deploying BFD authentication at
      scale becomes a reality.

    Do all Datatracker state attributes correctly reflect this intent?
Yes.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
Yes.
https://mailarchive.ietf.org/arch/msg/rtg-bfd/tB3E6nl6N4w7wGIPMXsDF2gDdiE/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such?
Yes.

    If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
N/A.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
None.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
None.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
No, this is an experimental document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
No IANA Considerations in this document since the relevant IANA Considerations are in draft-ietf-bfd-optimizing-authentication

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Review of draft-ietf-bfd-secure-sequence-numbers-22
=======================================================================================

Authors have addressed AD-review comments @
https://mailarchive.ietf.org/arch/msg/rtg-bfd/2jnbFMQkrTsgwAJ0qzRRbWzczgs/

Shepherding co-chair then asked for comments on the updates, see
https://mailarchive.ietf.org/arch/msg/rtg-bfd/dvdro7nBOEu8WKr2Y0VKOz7jZCA/

Some nits were mentioned @
https://mailarchive.ietf.org/arch/msg/rtg-bfd/aeaBX7ZFDlupcxpjydgRttHaCtE/

Review of draft-ietf-bfd-secure-sequence-numbers-20
=======================================================================================
## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
Strong consensus of a few individuals.
The initial revision of this document is from 2017. Goal was to address
concerns expressed by Security Area on the work to optimize BFD authentication
(draft-ietf-bfd-optimizing-authentication). There have not been many comments
on this document specifically, but there have been many discussions on what this
document provides in the context of draft-ietf-bfd-optimizing-authentication.
Revision 9 of this document is the first one which mentions use of ISAAC.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
No controversy on this document.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
No implementations and no known plans to implement.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
No and no.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written and ready.
The authors have addressed all review comments.
https://mailarchive.ietf.org/arch/msg/rtg-bfd/d8V4BhioRGXmwGDZgqcO-rG9O7o/

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Secdir review @ https://mailarchive.ietf.org/arch/msg/rtg-bfd/9ieykoBqnSf4vJfLvRpmtkaERDw/
The comments have been addressed afaik, but I couldn't find a response. I've requested the authors to respond.

Opsdir review @ https://mailarchive.ietf.org/arch/msg/ops-dir/vb21FUcQ9kuPxR8pBW-wc72axS8/

Rtgdir review @ https://mailarchive.ietf.org/arch/msg/rtg-dir/pZLg4723nk9pVquZ0hdqVv4Fek8/

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])?

Experimental as indicated on title page.

    Why is this the proper type
    of RFC?

  Here are the reasons why this document is on the
  Experimental track:

  *  In the initial stages of the document, there were significant
      participation and reviews from the working group.  Since then,
      there has been considerable changes to the document, e.g. the use
      of ISAAC, allowing for ISAAC bootstrapping when a BFD session
      comes up etc.  These changes did not get
      significant review from the working group and therefore does not
      meet the bar set in Section 4.1.1 of [RFC2026]

  *  There are no known implementations (even proof-of-concept) or
      implementation plans.  As a result, we do not currently know if
      there will be interop issues with legacy implementations or what
      exactly are the performance benefits of the optimization method.

  *  The work in this document could become very valuable in the
      future, especially if the need for deploying BFD authentication at
      scale becomes a reality.

    Do all Datatracker state attributes correctly reflect this intent?
Yes.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
Yes.
https://mailarchive.ietf.org/arch/msg/rtg-bfd/tB3E6nl6N4w7wGIPMXsDF2gDdiE/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such?
Yes.

    If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
N/A.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
None.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
None.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
No, this is an experimental document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
No IANA Considerations in this document since the relevant IANA Considerations are in draft-ietf-bfd-optimizing-authentication

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Review of draft-ietf-bfd-secure-sequence-numbers-20
=======================================================================================
## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
Strong consensus of a few individuals.
The initial revision of this document is from 2017. Goal was to address
concerns expressed by Security Area on the work to optimize BFD authentication
(draft-ietf-bfd-optimizing-authentication). There have not been many comments
on this document specifically, but there have been many discussions on what this
document provides in the context of draft-ietf-bfd-optimizing-authentication.
Revision 9 of this document is the first one which mentions use of ISAAC.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
No controversy on this document.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
No implementations and no known plans to implement.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
No and no.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written and ready.
The authors have addressed all review comments.
https://mailarchive.ietf.org/arch/msg/rtg-bfd/d8V4BhioRGXmwGDZgqcO-rG9O7o/

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Secdir review @ https://mailarchive.ietf.org/arch/msg/rtg-bfd/9ieykoBqnSf4vJfLvRpmtkaERDw/
The comments have been addressed afaik, but I couldn't find a response. I've requested the authors to respond.

Opsdir review @ https://mailarchive.ietf.org/arch/msg/ops-dir/vb21FUcQ9kuPxR8pBW-wc72axS8/

Rtgdir review @ https://mailarchive.ietf.org/arch/msg/rtg-dir/pZLg4723nk9pVquZ0hdqVv4Fek8/

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])?

Experimental as indicated on title page.

    Why is this the proper type
    of RFC?

  Here are the reasons why this document is on the
  Experimental track:

  *  In the initial stages of the document, there were significant
      participation and reviews from the working group.  Since then,
      there has been considerable changes to the document, e.g. the use
      of ISAAC, allowing for ISAAC bootstrapping when a BFD session
      comes up etc.  These changes did not get
      significant review from the working group and therefore does not
      meet the bar set in Section 4.1.1 of [RFC2026]

  *  There are no known implementations (even proof-of-concept) or
      implementation plans.  As a result, we do not currently know if
      there will be interop issues with legacy implementations or what
      exactly are the performance benefits of the optimization method.

  *  The work in this document could become very valuable in the
      future, especially if the need for deploying BFD authentication at
      scale becomes a reality.

    Do all Datatracker state attributes correctly reflect this intent?
Yes.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
Yes.
https://mailarchive.ietf.org/arch/msg/rtg-bfd/tB3E6nl6N4w7wGIPMXsDF2gDdiE/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such?
Yes.

    If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
N/A.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
None.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
None.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
No, this is an experimental document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
No IANA Considerations in this document since the relevant IANA Considerations are in draft-ietf-bfd-optimizing-authentication

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

=======================================================================================
Update May 5th 2025 on draft-ietf-bfd-secure-sequence-numbers-20

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
Strong consensus of a few individuals.
The initial revision of this document is from 2017. Goal was to address
concerns expressed by Security Area on the work to optimize BFD authentication
(draft-ietf-bfd-optimizing-authentication). There have not been many comments
on this document specifically, but there have been many discussions on what this
document provides in the context of draft-ietf-bfd-optimizing-authentication.
Revision 9 of this document is the first one which mentions use of ISAAC.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
No controversy on this document.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
No implementations and no known plans to implement.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
No and no.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written and ready.
The authors have addressed all review comments.
https://mailarchive.ietf.org/arch/msg/rtg-bfd/d8V4BhioRGXmwGDZgqcO-rG9O7o/

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Secdir review @ https://mailarchive.ietf.org/arch/msg/rtg-bfd/9ieykoBqnSf4vJfLvRpmtkaERDw/
The comments have been addressed afaik, but I couldn't find a response. I've requested the authors to respond.

Opsdir review @ https://mailarchive.ietf.org/arch/msg/ops-dir/vb21FUcQ9kuPxR8pBW-wc72axS8/

Rtgdir review @ https://mailarchive.ietf.org/arch/msg/rtg-dir/pZLg4723nk9pVquZ0hdqVv4Fek8/

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])?

Experimental as indicated on title page.

    Why is this the proper type
    of RFC?

  Here are the reasons why this document is on the
  Experimental track:

  *  In the initial stages of the document, there were significant
      participation and reviews from the working group.  Since then,
      there has been considerable changes to the document, e.g. the use
      of ISAAC, allowing for ISAAC bootstrapping when a BFD session
      comes up etc.  These changes did not get
      significant review from the working group and therefore does not
      meet the bar set in Section 4.1.1 of [RFC2026]

  *  There are no known implementations (even proof-of-concept) or
      implementation plans.  As a result, we do not currently know if
      there will be interop issues with legacy implementations or what
      exactly are the performance benefits of the optimization method.

  *  The work in this document could become very valuable in the
      future, especially if the need for deploying BFD authentication at
      scale becomes a reality.

    Do all Datatracker state attributes correctly reflect this intent?
Yes.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
Yes.
https://mailarchive.ietf.org/arch/msg/rtg-bfd/tB3E6nl6N4w7wGIPMXsDF2gDdiE/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such?
Yes.

    If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
N/A.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
None.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
None.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
No, this is an experimental document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
No IANA Considerations in this document since the relevant IANA Considerations are in draft-ietf-bfd-optimizing-authentication

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

=======================================================================================
=======================================================================================
Update December 31st 2024 on draft-ietf-bfd-secure-sequence-numbers-18

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
Strong consensus of a few individuals.
The initial revision of this document is from 2017. Goal was to address
concerns expressed by Security Area on the work to optimize BFD authentication
(draft-ietf-bfd-optimizing-authentication). There have not been many comments
on this document specifically, but there have been many discussions on what this
document provides in the context of draft-ietf-bfd-optimizing-authentication.
Revision 9 of this document is the first one which mentions use of ISAAC.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
No controversy on this document.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
No implementations and no known plans to implement.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
No and no.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written and nearly ready.
There are some comments to be addressed before the document is handed off to
the responsible AD:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/d8V4BhioRGXmwGDZgqcO-rG9O7o/

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None. Note that SECDIR review is pending.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])?

Experimental as indicated on title page.

    Why is this the proper type
    of RFC?

Main reasons:
- No known implementations
- Not a lot of reviews on the latest revisions of the document

    Do all Datatracker state attributes correctly reflect this intent?
Yes.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
Yes. Waiting for response from 2 co-authors.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such?
Yes.

    If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
N/A.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
None.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
None.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
No, this is an experimental document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
No IANA Considerations in this document since the relevant IANA Considerations are in draft-ietf-bfd-optimizing-authentication

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

=======================================================================================

Previous writeup from 2024-06-14.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Standards Track as indicated on title page.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
This document describes a security enhancement for the sequence number used in BFD control packets.

Working Group Summary:
Initial version of the document is from February 2017. Goal was to address concerns expressed by Security Area on the work to optimize BFD authentication (draft-ietf-bfd-optimizing-authentication).
There have not been many comments on this draft specifically, but there have been many discussions on what this draft provides in the context of draft-ietf-bfd-optimizing-authentication.
One action which has been postponed is updating the BFD YANG model to enable this functionality, this is needed also for  draft-ietf-bfd-optimizing-authentication (although the latter requires a -bis of the BFD YANG document due to the new auth-type) 

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
The document is well-written, concise and technically accurate, but requires some editorial changes before being forwarded to the IESG.

Personnel:

Who is the Document Shepherd?
Reshad Rahman, BFD co-chair.

Who is the Responsible Area Director?
Martin Vigoureux is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The shepherd has gone through the document, email archive and meeting minutes. Comments have been addressed.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
None.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
This document arose from Security Area review of draft-ietf-bfd-optimizing-authentication.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
No IPR disclosure

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
WG consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
1 comment about the document data being 106 days in the past.
4 warnings about missing references for [O], [S], [A] and [H1] (mentioned but not defined). I think if e.g. <> is used instead of [] this warnings will go away.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A

(13) Have all references within this document been identified as either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
No protocol extensions which require a registry.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
N/A

COMMENTS

This document updates RFC5880. This is missing from the title page header.

Abstract
s/a security enhancements/a security enhancement/
Suggestion: “This document describes a security enhancement for the sequence number used in BFD control packets”.

Requirements Language
Please put this later in the document, e.g. after introduction. Add RFC8174, and add it as normative reference.

Introduction
Don’t use Authentication TLV, instead use “Authentication Section”. E.g.
s/in BFD authentication TLVs/in the BFD authentication section/


s/pseudo-random sequence numbers on the frame/pseudo-random sequence numbers in BFD control packets/
I’m not sure I understood the last sentence starting with “Further security may be ….”. What is “resetting un-encrypted sequence”? Does it mean that when the sequence numbers rolls over, it’s reset to a pseudo-random number?

Section 2
Rename to “Theory of operation”
Suggest splitting the  1st sentence, e.g.
  Instead of inserting a monotonically, sometimes occasionally, increasing
  sequence number in BFD control packets, a hash is inserted instead.
  The hash is computed, using a shared key, on the sequence number. That
  computed hash is then inserted into the sequence number field of the
  packet.

In the following sentence, the part “used in computing an authenticated packet” is referring to computing the SHA1/MD5 hash/digest for the packet? That sentence should be clarified then.
                                                                  In
  case of BFD Authentication [I-D.ietf-bfd-optimizing-authentication],
  the sequence number used in computing an authenticated packet would
  be this new computed hash.

Also, when referring to the optimization draft, better to use e.g. “optimized BFD authentication” than “BFD authentication”. The latter implies per-RFC5880 BFD authentication.

s/psuedo/pseudo/
s/ scope of this draft/ scope of this document/
s/seuquence/sequence/

Not clear to me what the following means.
                              Note: The first sequence number can
  be obtained using the same logic as the My Discriminator value.

The diagram reads well for regular authentication. For secure sequence number, I think the diagram would gain clarity from an ordered list of steps on the sender and receiver. The current list before the diagram is useful,  I believe the sender steps would start at “H1:” and the receiver steps at hash’. And yes, hash’ needs an explanation. On the receiver side, for validating that ’s’ is a good sequence number, the range has to be checked as mentioned in the previous paragraph.

Section 5
s/ stabiluty/ stability/
s/admistratively/administratively/
s/Sequential nature/The sequential nature/

=======================================================================================
Update May 5th 2025 on draft-ietf-bfd-secure-sequence-numbers-20

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
Strong consensus of a few individuals.
The initial revision of this document is from 2017. Goal was to address
concerns expressed by Security Area on the work to optimize BFD authentication
(draft-ietf-bfd-optimizing-authentication). There have not been many comments
on this document specifically, but there have been many discussions on what this
document provides in the context of draft-ietf-bfd-optimizing-authentication.
Revision 9 of this document is the first one which mentions use of ISAAC.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
No controversy on this document.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
No implementations and no known plans to implement.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
No and no.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written and ready.
The authors have addressed all review comments.
https://mailarchive.ietf.org/arch/msg/rtg-bfd/d8V4BhioRGXmwGDZgqcO-rG9O7o/

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

Secdir review @ https://mailarchive.ietf.org/arch/msg/rtg-bfd/9ieykoBqnSf4vJfLvRpmtkaERDw/
The comments have been addressed afaik, but I couldn't find a response. I've requested the authors to respond.

Opsdir review @ https://mailarchive.ietf.org/arch/msg/ops-dir/vb21FUcQ9kuPxR8pBW-wc72axS8/

Rtgdir review @ https://mailarchive.ietf.org/arch/msg/rtg-dir/pZLg4723nk9pVquZ0hdqVv4Fek8/

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])?

Experimental as indicated on title page.

    Why is this the proper type
    of RFC?

  Here are the reasons why this document is on the
  Experimental track:

  *  In the initial stages of the document, there were significant
      participation and reviews from the working group.  Since then,
      there has been considerable changes to the document, e.g. the use
      of ISAAC, allowing for ISAAC bootstrapping when a BFD session
      comes up etc.  These changes did not get
      significant review from the working group and therefore does not
      meet the bar set in Section 4.1.1 of [RFC2026]

  *  There are no known implementations (even proof-of-concept) or
      implementation plans.  As a result, we do not currently know if
      there will be interop issues with legacy implementations or what
      exactly are the performance benefits of the optimization method.

  *  The work in this document could become very valuable in the
      future, especially if the need for deploying BFD authentication at
      scale becomes a reality.

    Do all Datatracker state attributes correctly reflect this intent?
Yes.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
Yes.
https://mailarchive.ietf.org/arch/msg/rtg-bfd/tB3E6nl6N4w7wGIPMXsDF2gDdiE/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such?
Yes.

    If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
N/A.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
None.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
None.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
No, this is an experimental document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
No IANA Considerations in this document since the relevant IANA Considerations are in draft-ietf-bfd-optimizing-authentication

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

=======================================================================================
=======================================================================================
Update December 31st 2024 on draft-ietf-bfd-secure-sequence-numbers-18

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
Strong consensus of a few individuals.
The initial revision of this document is from 2017. Goal was to address
concerns expressed by Security Area on the work to optimize BFD authentication
(draft-ietf-bfd-optimizing-authentication). There have not been many comments
on this document specifically, but there have been many discussions on what this
document provides in the context of draft-ietf-bfd-optimizing-authentication.
Revision 9 of this document is the first one which mentions use of ISAAC.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
No controversy on this document.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
No implementations and no known plans to implement.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
No and no.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written and nearly ready.
There are some comments to be addressed before the document is handed off to
the responsible AD:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/d8V4BhioRGXmwGDZgqcO-rG9O7o/

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None. Note that SECDIR review is pending.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])?

Experimental as indicated on title page.

    Why is this the proper type
    of RFC?

Main reasons:
- No known implementations
- Not a lot of reviews on the latest revisions of the document

    Do all Datatracker state attributes correctly reflect this intent?
Yes.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
Yes. Waiting for response from 2 co-authors.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such?
Yes.

    If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
N/A.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
None.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
None.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
No, this is an experimental document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
No IANA Considerations in this document since the relevant IANA Considerations are in draft-ietf-bfd-optimizing-authentication

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

=======================================================================================

Previous writeup from 2024-06-14.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Standards Track as indicated on title page.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
This document describes a security enhancement for the sequence number used in BFD control packets.

Working Group Summary:
Initial version of the document is from February 2017. Goal was to address concerns expressed by Security Area on the work to optimize BFD authentication (draft-ietf-bfd-optimizing-authentication).
There have not been many comments on this draft specifically, but there have been many discussions on what this draft provides in the context of draft-ietf-bfd-optimizing-authentication.
One action which has been postponed is updating the BFD YANG model to enable this functionality, this is needed also for  draft-ietf-bfd-optimizing-authentication (although the latter requires a -bis of the BFD YANG document due to the new auth-type) 

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
The document is well-written, concise and technically accurate, but requires some editorial changes before being forwarded to the IESG.

Personnel:

Who is the Document Shepherd?
Reshad Rahman, BFD co-chair.

Who is the Responsible Area Director?
Martin Vigoureux is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The shepherd has gone through the document, email archive and meeting minutes. Comments have been addressed.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
None.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
This document arose from Security Area review of draft-ietf-bfd-optimizing-authentication.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
No IPR disclosure

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
WG consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
1 comment about the document data being 106 days in the past.
4 warnings about missing references for [O], [S], [A] and [H1] (mentioned but not defined). I think if e.g. <> is used instead of [] this warnings will go away.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A

(13) Have all references within this document been identified as either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
No protocol extensions which require a registry.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
N/A

COMMENTS

This document updates RFC5880. This is missing from the title page header.

Abstract
s/a security enhancements/a security enhancement/
Suggestion: “This document describes a security enhancement for the sequence number used in BFD control packets”.

Requirements Language
Please put this later in the document, e.g. after introduction. Add RFC8174, and add it as normative reference.

Introduction
Don’t use Authentication TLV, instead use “Authentication Section”. E.g.
s/in BFD authentication TLVs/in the BFD authentication section/


s/pseudo-random sequence numbers on the frame/pseudo-random sequence numbers in BFD control packets/
I’m not sure I understood the last sentence starting with “Further security may be ….”. What is “resetting un-encrypted sequence”? Does it mean that when the sequence numbers rolls over, it’s reset to a pseudo-random number?

Section 2
Rename to “Theory of operation”
Suggest splitting the  1st sentence, e.g.
  Instead of inserting a monotonically, sometimes occasionally, increasing
  sequence number in BFD control packets, a hash is inserted instead.
  The hash is computed, using a shared key, on the sequence number. That
  computed hash is then inserted into the sequence number field of the
  packet.

In the following sentence, the part “used in computing an authenticated packet” is referring to computing the SHA1/MD5 hash/digest for the packet? That sentence should be clarified then.
                                                                  In
  case of BFD Authentication [I-D.ietf-bfd-optimizing-authentication],
  the sequence number used in computing an authenticated packet would
  be this new computed hash.

Also, when referring to the optimization draft, better to use e.g. “optimized BFD authentication” than “BFD authentication”. The latter implies per-RFC5880 BFD authentication.

s/psuedo/pseudo/
s/ scope of this draft/ scope of this document/
s/seuquence/sequence/

Not clear to me what the following means.
                              Note: The first sequence number can
  be obtained using the same logic as the My Discriminator value.

The diagram reads well for regular authentication. For secure sequence number, I think the diagram would gain clarity from an ordered list of steps on the sender and receiver. The current list before the diagram is useful,  I believe the sender steps would start at “H1:” and the receiver steps at hash’. And yes, hash’ needs an explanation. On the receiver side, for validating that ’s’ is a good sequence number, the range has to be checked as mentioned in the previous paragraph.

Section 5
s/ stabiluty/ stability/
s/admistratively/administratively/
s/Sequential nature/The sequential nature/

=======================================================================================
Update December 31st 2024 on draft-ietf-bfd-secure-sequence-numbers-18

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
Strong consensus of a few individuals.
The initial revision of this document is from 2017. Goal was to address
concerns expressed by Security Area on the work to optimize BFD authentication
(draft-ietf-bfd-optimizing-authentication). There have not been many comments
on this document specifically, but there have been many discussions on what this
document provides in the context of draft-ietf-bfd-optimizing-authentication.
Revision 9 of this document is the first one which mentions use of ISAAC.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
No controversy on this document.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
No implementations and no known plans to implement.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
No and no.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is clearly written and nearly ready.
There are some comments to be addressed before the document is handed off to
the responsible AD:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/d8V4BhioRGXmwGDZgqcO-rG9O7o/

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

None. Note that SECDIR review is pending.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])?

Experimental as indicated on title page.

    Why is this the proper type
    of RFC?

Main reasons:
- No known implementations
- Not a lot of reviews on the latest revisions of the document

    Do all Datatracker state attributes correctly reflect this intent?
Yes.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
Yes. Waiting for response from 2 co-authors.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such?
Yes.

    If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
N/A.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)
None.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
None.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
None.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
None.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
No, this is an experimental document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
No IANA Considerations in this document since the relevant IANA Considerations are in draft-ietf-bfd-optimizing-authentication

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

=======================================================================================

Previous writeup from 2024-06-14.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Standards Track as indicated on title page.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
This document describes a security enhancement for the sequence number used in BFD control packets.

Working Group Summary:
Initial version of the document is from February 2017. Goal was to address concerns expressed by Security Area on the work to optimize BFD authentication (draft-ietf-bfd-optimizing-authentication).
There have not been many comments on this draft specifically, but there have been many discussions on what this draft provides in the context of draft-ietf-bfd-optimizing-authentication.
One action which has been postponed is updating the BFD YANG model to enable this functionality, this is needed also for  draft-ietf-bfd-optimizing-authentication (although the latter requires a -bis of the BFD YANG document due to the new auth-type) 

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
The document is well-written, concise and technically accurate, but requires some editorial changes before being forwarded to the IESG.

Personnel:

Who is the Document Shepherd?
Reshad Rahman, BFD co-chair.

Who is the Responsible Area Director?
Martin Vigoureux is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The shepherd has gone through the document, email archive and meeting minutes. Comments have been addressed.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
None.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
This document arose from Security Area review of draft-ietf-bfd-optimizing-authentication.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
No IPR disclosure

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
WG consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
1 comment about the document data being 106 days in the past.
4 warnings about missing references for [O], [S], [A] and [H1] (mentioned but not defined). I think if e.g. <> is used instead of [] this warnings will go away.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A

(13) Have all references within this document been identified as either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
No protocol extensions which require a registry.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
N/A

COMMENTS

This document updates RFC5880. This is missing from the title page header.

Abstract
s/a security enhancements/a security enhancement/
Suggestion: “This document describes a security enhancement for the sequence number used in BFD control packets”.

Requirements Language
Please put this later in the document, e.g. after introduction. Add RFC8174, and add it as normative reference.

Introduction
Don’t use Authentication TLV, instead use “Authentication Section”. E.g.
s/in BFD authentication TLVs/in the BFD authentication section/


s/pseudo-random sequence numbers on the frame/pseudo-random sequence numbers in BFD control packets/
I’m not sure I understood the last sentence starting with “Further security may be ….”. What is “resetting un-encrypted sequence”? Does it mean that when the sequence numbers rolls over, it’s reset to a pseudo-random number?

Section 2
Rename to “Theory of operation”
Suggest splitting the  1st sentence, e.g.
  Instead of inserting a monotonically, sometimes occasionally, increasing
  sequence number in BFD control packets, a hash is inserted instead.
  The hash is computed, using a shared key, on the sequence number. That
  computed hash is then inserted into the sequence number field of the
  packet.

In the following sentence, the part “used in computing an authenticated packet” is referring to computing the SHA1/MD5 hash/digest for the packet? That sentence should be clarified then.
                                                                  In
  case of BFD Authentication [I-D.ietf-bfd-optimizing-authentication],
  the sequence number used in computing an authenticated packet would
  be this new computed hash.

Also, when referring to the optimization draft, better to use e.g. “optimized BFD authentication” than “BFD authentication”. The latter implies per-RFC5880 BFD authentication.

s/psuedo/pseudo/
s/ scope of this draft/ scope of this document/
s/seuquence/sequence/

Not clear to me what the following means.
                              Note: The first sequence number can
  be obtained using the same logic as the My Discriminator value.

The diagram reads well for regular authentication. For secure sequence number, I think the diagram would gain clarity from an ordered list of steps on the sender and receiver. The current list before the diagram is useful,  I believe the sender steps would start at “H1:” and the receiver steps at hash’. And yes, hash’ needs an explanation. On the receiver side, for validating that ’s’ is a good sequence number, the range has to be checked as mentioned in the previous paragraph.

Section 5
s/ stabiluty/ stability/
s/admistratively/administratively/
s/Sequential nature/The sequential nature/

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Standards Track as indicated on title page.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
This document describes a security enhancement for the sequence number used in BFD control packets.

Working Group Summary:
Initial version of the document is from February 2017. Goal was to address concerns expressed by Security Area on the work to optimize BFD authentication (draft-ietf-bfd-optimizing-authentication).
There have not been many comments on this draft specifically, but there have been many discussions on what this draft provides in the context of draft-ietf-bfd-optimizing-authentication.
One action which has been postponed is updating the BFD YANG model to enable this functionality, this is needed also for  draft-ietf-bfd-optimizing-authentication (although the latter requires a -bis of the BFD YANG document due to the new auth-type) 

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?
The document is well-written, concise and technically accurate, but requires some editorial changes before being forwarded to the IESG.

Personnel:

Who is the Document Shepherd?
Reshad Rahman, BFD co-chair.

Who is the Responsible Area Director?
Martin Vigoureux is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The shepherd has gone through the document, email archive and meeting minutes. Comments have been addressed.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
None.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
This document arose from Security Area review of draft-ietf-bfd-optimizing-authentication.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
No IPR disclosure

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
WG consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
1 comment about the document data being 106 days in the past.
4 warnings about missing references for [O], [S], [A] and [H1] (mentioned but not defined). I think if e.g. <> is used instead of [] this warnings will go away.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A

(13) Have all references within this document been identified as either normative or informative?
Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
None

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
No protocol extensions which require a registry.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
N/A

COMMENTS

This document updates RFC5880. This is missing from the title page header.

Abstract
s/a security enhancements/a security enhancement/
Suggestion: “This document describes a security enhancement for the sequence number used in BFD control packets”.

Requirements Language
Please put this later in the document, e.g. after introduction. Add RFC8174, and add it as normative reference.

Introduction
Don’t use Authentication TLV, instead use “Authentication Section”. E.g.
s/in BFD authentication TLVs/in the BFD authentication section/


s/pseudo-random sequence numbers on the frame/pseudo-random sequence numbers in BFD control packets/
I’m not sure I understood the last sentence starting with “Further security may be ….”. What is “resetting un-encrypted sequence”? Does it mean that when the sequence numbers rolls over, it’s reset to a pseudo-random number?

Section 2
Rename to “Theory of operation”
Suggest splitting the  1st sentence, e.g.
  Instead of inserting a monotonically, sometimes occasionally, increasing
  sequence number in BFD control packets, a hash is inserted instead.
  The hash is computed, using a shared key, on the sequence number. That
  computed hash is then inserted into the sequence number field of the
  packet.

In the following sentence, the part “used in computing an authenticated packet” is referring to computing the SHA1/MD5 hash/digest for the packet? That sentence should be clarified then.
                                                                  In
  case of BFD Authentication [I-D.ietf-bfd-optimizing-authentication],
  the sequence number used in computing an authenticated packet would
  be this new computed hash.

Also, when referring to the optimization draft, better to use e.g. “optimized BFD authentication” than “BFD authentication”. The latter implies per-RFC5880 BFD authentication.

s/psuedo/pseudo/
s/ scope of this draft/ scope of this document/
s/seuquence/sequence/

Not clear to me what the following means.
                              Note: The first sequence number can
  be obtained using the same logic as the My Discriminator value.

The diagram reads well for regular authentication. For secure sequence number, I think the diagram would gain clarity from an ordered list of steps on the sender and receiver. The current list before the diagram is useful,  I believe the sender steps would start at “H1:” and the receiver steps at hash’. And yes, hash’ needs an explanation. On the receiver side, for validating that ’s’ is a good sequence number, the range has to be checked as mentioned in the previous paragraph.

Section 5
s/ stabiluty/ stability/
s/admistratively/administratively/
s/Sequential nature/The sequential nature/