Re: [RTG-DIR] RtgDir review: draft-ietf-trill-rbridge-bfd-05.txt

["John G. Scudder" <[e-mail]>]

Hi Donald,

Comments below only where I had something to say other than "OK". You can take that as read otherwise.

On Jun 11, 2012, at 4:48 PM, Donald Eastlake wrote:
...
>> Minor Issues:
...
>> 4. In two places text like the following appears:
>> 
>>  Is the M-bit in the TRILL Header non-zero? If so, discard the
>>  frame.  TRILL support of multi-destination BFD Echo is beyond the
>>  scope of this document.
>> 
>> If multi-destination doesn't make sense in the context of TRILL, it
>> is fine to exclude it by enforcing that the M-bit be zero. However,
>> I normally parse "beyond the scope of this document" to mean
>> something like "we may do it in the future but haven't worked it out
>> yet". By forcing the M-bit to be zero, you're placing
>> multi-destination *in* scope, inasmuch as you are actively
>> forbidding it from being supported.
>> 
>> Presumably the sentence about "beyond the scope" was meant to
>> justify this decision. Perhaps the comment about "scope" should be
>> dropped and a different justifying sentence used. (Or the sentence
>> omitted altogether.)
> 
> Multi-destination makes sense for TRILL. It is just not yet
> standardized, as far as I know, for BFD. Perhaps the "beyond the
> scope" verbage should be removed and a note added somewhere such as
> "(Multi-destination BFD is a work in progress [...].)"

By requiring the M-bit to be zero you effectively preclude the later introduction of multi-destination, do you not?

>> 5. Presumably the Security Area reviewer may raise this, but the
>> Security Considerations section seems to be misused. My
>> understanding (confirmed by referring to RFC 3552 Section 5) is that
>> the Security Considerations section is intended to be an analysis of
>> issues that arise from the operation of the protocol defined in the
>> rest of the document, including but not limited to the security
>> features of that protocol.
>> 
>> This document's Security Considerations section instead specifies
>> how authentication is to be done, though it doesn't provide an
>> analysis of it or of any broader issues. I presume the section
>> should be retitled (e.g., to "Authentication") and a proper Security
>> Considerations section added.
>> 
>> (This would probably be a "major issue" if I were the Security Area
>> reviewer, but I'm not.)
> 
> As far as I can tell (and I'm a member of the Security Directorate),
> the Security Area considers this a non-issue. However, I've got no
> problem with moving this material to a new "Default Authentication"
> section or the like.

OK.

(As an aside, if the Security Directorate considers this a non-issue, maybe it's time to revise RFC 3552? I say this as an occasional author of Security Considerations sections and not with regard to your draft.)

--John