On 12/8/15, 10:10 AM, "Carlos Pignataro (cpignata)" <[email protected]>
wrote:

Carlos:

Hi!

>
>> On Dec 8, 2015, at 9:36 AM, Alvaro Retana (aretana) <[email protected]>
>>wrote:
>> 
>> On 12/6/15, 4:09 AM, "Santosh P K" <[email protected]> wrote:
>> 
>>. . .
>>
>> 
>> 
>> 
>>> 
>>> Major:
>>> 1. Section 1. (Introduction) says that "This document extends BFD to
>>> provide solutions to use cases listed in
>>> [I-D.ietf-bfd-seamless-use-case]."  Maybe it's just me, but I fail to
>>>see
>>> how all the use cases are satisfied - in part because the requirements
>>>in
>>> I-D.ietf-bfd-seamless-use-case are not clear (see my review for that
>>> document), and in part because this document isn't explicit about how
>>>the
>>> specification solves the use cases.  For example, how does this
>>>document
>>> provide a solution for the use case in section 3.6. (BFD for Anycast
>>> Address)?
>>> 2. Normative References
>>> o I-D.ietf-bfd-multipoint should clearly be Normative because of the
>>>new
>>> bfd.SessionType state variable
>>> o I-D.ietf-bfd-generic-crypto-auth should also be Normative because of
>>> how the Security Considerations are written: pointing to is as a
>>>"MUST".
>>> Given that (as far as I can tell) there aren't implementations of
>>> I-D.ietf-bfd-generic-crypto-auth, we could end up with a Normative
>>> reference that blocks the publication of this document.  I want to
>>> suggest that the comments be reworded as a suggestion or pointer to
>>> potential solutions, not as a mandate to use them.  [Disclaimer: we
>>>will
>>> still need the SecDir to review.]
>>> 
>>> [SPK] Carlos has replied to these comments and I am waiting for
>>> confirmation on these comments.
>> 
>> Unless I missed something, Carlos [1] didn't reply to #1: how are the
>>use
>> cases satisfied?  I'm looking forward to an updated version of
>> I-D.ietf-bfd-seamless-use-case which may help.
>> 
>> FWIW, I agree with his comments related to the references.  And still
>> think that both should be Normative.  BTW, I don't think that changing
>>the
>> "MUST" to "SHOULD" when referring to I-D.ietf-bfd-generic-crypto-auth
>> changed that need.
>
>What¹s your (Alvar, Jeff) view on whether this doc should define
>bfd.SessionType and not multipoint?
>
>Seems to me that it is probably best (although an almost negligible
>preference) to define it here and have multipoint referencing s-bfd.

Either way works for me.

Alvaro.

Reply via email to