Acee,

As best I can tell, your yang doctor review wasn't sent to other list aliases 
which is why I didn't respond to it.  If it was, I can't find it in my inbox. 
I'm copying the text from your review here:

> The following issues have to be addressed:
> 
>    1. The first use of the acronym ISAAC should be expanded in the YANG data
>         module (and also the draft).

As noted elsewhere, it doesn't really have a canonical expansion.

>    2. The prefix should be "bfdmki" for "BFD Meticulously Keyed ISAAC" rather 
> than
>       "bfdmia" for "BFD Missing In Action". I guess this refers to the 
> selection of the
>        YANG data module prefix? 

I've changed this to bfd-mki keeping the hyphenation that we see in other 
modules.

-mia was originally "meticulous isaac authentication" from before the "keyed" 
word entered the text.

>    3. The identities optimized-md5-meticulous-keyed-isaac and
>       optimized-md5-meticulous-keyed-isaac must be removed from
>       ietf-bfd-opt-auth.yang as they are now in this YANG data module.

It'll be removed in that module in next post.

>    4. The "Security Considerations" section of the draft is missing the
>       YANG boilerplate for the YANG model described in the draft.

I've added what I'm hoping is an appropriate distillation of the current 
practice.  Please take a look in the pull request for -25 or otherwise wait for 
-25's publication.


> 
> Consider:
> 
>    1. Should each optimized authentication method have its own YANG feature 
> rather
>       than a single one for "optimized-auth? If not, maybe keep a single YANG 
> model
>       ietf-bfd-opt-auth.yang with a reference to this draft (as long as both 
> drafts progress
>       together).
> 

I think the best comparison is the generic IETF keychain model.  We don't have 
individual features for each new authentication method as a matter of course.  
For similar reasons, I think the current proposal for a single feature is 
appropriate.

https://github.com/mjethanandani/bfd-secure-sequence-numbers/pull/49


And similar to the IETF keychain model, if some portions of the keychain schema 
need to be conditionally augmented for a specific new mechanism, adding a 
feature at the time of the definition of that new mechanism is when it's 
appropriate to do so.

-- Jeff

Reply via email to