Inline On Wed, Mar 28, 2018 at 12:57 PM, Jeffrey Haas <jh...@pfrc.org> wrote:
> Authors, > > Several comments on the draft in no particular order: > > --- > > The document header says "BFD Authentication". You should include the word > "optimizing" somewhere in that. :-) [AM] Addressed :) > > --- > > The NULL Auth TLV has a recommended Authentication Type of 0. While this > seems like a good idea, it's problematic in a few regards. > > RFC 5880 defines the bfd.AuthType variable. This is basically set using > the > received AuthType in the packet when authentication is received. E.g.: > > : Authentication Present (A) > : > : Set to 1 if authentication is in use on this session (bfd.AuthType > : is nonzero), or 0 if not. > > Further, section 6.8.6 contains the following: > > : If the A bit is set and no authentication is in use (bfd.AuthType > : is zero), the packet MUST be discarded. > > My recommendation is to remove the AuthType of 0 and replace it with a TBD > to be assigned by IANA. This impacts the IANA Considerations section. [AM] Good catch! I'll make the change. > > --- > > Section 3 notes a "Reserved" field. It notes "multiple keys". This seems > to > be missing text describing how it's intended to be used. > > [AM] This is a copy-paste error. It should read "This byte MUST be set to zero on transmit and ignored on receipt." --- > > > There are also a few other issues that require attention, which are largely > operational considerations: > > How do you go about enabling the optimized procedures? Is it expected to > be > via configuration? [AM] The intention is to be configuration-based (as is with other authentication methods). > > What are the yang model considerations? (See prior point.) > [AM] I'll let Mahesh comment on this. > > -- Jeff >
