Sorry for the top post. Interesting to see 'use case doc' still being discussed.
As one of the authors of the use case doc, the mixed messages I received, which was followed up with post Yoko ietf email from Jeff, the inclination was to drop the doc, unless authors wants it to be published. As none of other co-authors showed any interest or lack there of, it is not prudent to push further a WG document. Addressing Alvaro's comments require time and effort to resolve. Unless WG is subscribed to publishing it, not worth anybody's time, either to edit or review. Having said the above, all the existing SBFD documents NEED to clearly state the problem statement, what the ID is trying to solve and outline the requirement and also state, which 'use case' the solution is trying to solve. For a reader to understand the ID, there needs to be a context and details pertaining to what it is trying to solve. Presently they do not as they are referencing and relying on use case doc. Cheers Sam Sent from my iPhone > On Dec 8, 2015, at 8:50 AM, Alvaro Retana (aretana) <[email protected]> wrote: > > 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. >
