Mohamed Boucadair has entered the following ballot position for
draft-ietf-bfd-optimizing-authentication-30: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi Mahesh, Ashesh, Ankur, Manav, and Jeffrey,

Thanks for the effort put into this specification.

Thanks also to Jürgen Schönwälder for a review of an early version and to Jeff
for the follow-up (especially the clarification about the struggle about the
"performance" language).

Please find below some few comments:

# Confusing note

CURRENT:
   RFC XXXX, where XXXX is the number assigned to this document at the
   time of publication.

Please note that you are using RFC XXXX to refer to two distinct documents:

         "RFC XXXX: Optimizing BFD Authentication.";

and

    "RFC XXXX: Meticulous Keyed ISAAC for BFD Authentication.";

# Redundant behavior

Section 3
   The contents of an Up packet MUST NOT change aside from the
   Authentication Section without strong authentication.

Vs.

Section 6:
   In this specification, the contents of an Up packet MUST NOT change
   aside from the Authentication Section without strong authentication.

Keep the normative language in one place.

# Not only for configuration but also for state reporting

Section 8.1

OLD:
   The YANG 1.1 [RFC7950] model defined in this document augments the
   "ietf-bfd" module to configuration relevant to the management of
   the feature defined in this document.

NEW:
   The YANG 1.1 [RFC7950] model defined in this document augments the
   "ietf-bfd" module to add data nodes relevant to the management of
   the feature defined in this document.

# Add identities, not algos per se

Section 8.1

OLD:
   In particular, it adds crypto
   algorithms that are described in this model, and in Meticulous Keyed
   ISAAC for BFD Authentication [I-D.ietf-bfd-secure-sequence-numbers].

NEW:
In particular, it adds identities for crypto
   algorithms that are described in this model, and in Meticulous Keyed
   ISAAC for BFD Authentication [I-D.ietf-bfd-secure-sequence-numbers].

# Feature

Consider this change in Section 8.1

OLD:
   It adds a feature statement to enable optimized authentication.

NEW:
   It adds a feature to indicate optimized authentication.

# YANG terminology

CURRENT:
   This YANG module imports YANG Key Chain [RFC8177], A YANG Data Model
   for Routing Management (NMDA version) [RFC8349], and YANG Data Model
   for Bidirectional Forwarding Detection (BFD) [RFC9314].

This should reason about importing the various modules, not data models. Please
refer to 8407bis which says:

“Likewise, "YANG module" should be used when using terms related to YANG module
specifications (e.g., augmentation or deviation).“

# Consistency

Section 8.3 has:

CURRENT: prefix "bfdoa";

I suggest to be consistent with the pattern used so far for BFD (bfd-ip-mh,
bfd-ip-sh, bfd-lag, etc.).

NEW: prefix bfd-oa;

# Feature Description

OLD:
       description
         "When enabled, this implementation supports optimized
          authentication as described in this document.";

NEW:
    description
      "Indicates that the implementation supports optimized
       authentication.";

Please note also that the module will live outside the document. You may add a
reference statement.

# Redundant default statement

OLD:
         default "60";
         description
           "Interval of time after which strong authentication
            should be utilized to prevent an on-path-attacker attack.
            Default is 1 minute.

NEW:
         default "60";
         description
           "Interval of time after which strong authentication
            should be utilized to prevent an on-path-attacker attack.

# Not maintained by IANA

OLD:
   name:         ietf-bfd-opt-auth
   namespace:    urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth
   prefix:       bfdoa
   reference:    RFC XXXX

NEW:
   name:         ietf-bfd-opt-auth
   namespace:    urn:ietf:params:xml:ns:yang:ietf-bfd-opt-auth
   prefix:       bfd-oa
   maintained by IANA? N
   reference:    RFC XXXX

# Security template

Please update 10.2 to follow the template in RFC8407bis.

Cheers,
Med



Reply via email to