Thanks Alvaro for the response — please see inline. > On Dec 8, 2015, at 11:14 AM, Alvaro Retana (aretana) <[email protected]> > wrote: > > On 12/8/15, 10:12 AM, "Carlos Pignataro (cpignata)" <[email protected] > <mailto:[email protected]>> > wrote: > > Hi! > >> >>> On Dec 8, 2015, at 9:40 AM, [email protected] wrote: >>> >>> On Tue, Dec 08, 2015 at 02:36:29PM +0000, Alvaro Retana (aretana) wrote: >>>> On 12/6/15, 4:09 AM, "Santosh P K" <[email protected]> wrote: >>>> 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. >>> >>> My understanding is that the use case draft is unlikely to proceed. >>> With >>> your blessing even. How do you want the text here adjusted? >> >> How about: >> >> OLD: >> This document >> extends BFD to provide solutions to use cases listed in >> [I-D.ietf-bfd-seamless-use-case]. >> >> NEW: >> >> <null> >> >> ? > > No. > > I would prefer if the document said something about what problem it > solves. Vs just extending BFD because we can.
I thought that was already clear from the Intro/Abstract, even if quite concise. If needed, a bit of text modeled after the shepherd write-up can complete: This document defines a simplified mechanism to use Bidirectional Forwarding Detection (BFD) with large portions of negotiation aspects eliminated, thus providing benefits such as quick provisioning as well as improved control and flexibility to network nodes initiating the path monitoring. > Which is why I suggested > rewording I-D.ietf-bfd-seamless-use-case to be clear about what is > expected in each scenario [1] (but we got bogged down on my comments about > publication and paid no attention to what could be done to move > forward..even now that the WG has indicated that it doesn't mind if the > document is published.. <sigh> But that is a different story.). > What is holding the decision on publication of I-D.ietf-bfd-seamless-use-case? Based on your decision tree below, it is all pending on that decision. > If I-D.ietf-bfd-seamless-use-case is updated, then we can keep the "OLD" > text above. With the caveat that there are some use cases described there > for which it is not clear to me how this document applies. My original > comments mentioned section 3.6. (BFD for Anycast Address) as an example. > > If I-D.ietf-bfd-seamless-use-case is not updated, then I would like to see > a set of use cases included in this document as justification. I disagree with this approach. (and I disagree with the concept of having to publish text to “justify” publication, and with use cases, but not in a use-case document) This would basically mean (exaggeration just for effect :-): “let’s not publish the use-cases document. Instead, let’s publish the use use-cases in the middle of a protocol document, so that we confuse both use cases and protocol" > I suspect > that would be a sub-set of what is already there; one of my comments > related to I-D.ietf-bfd-seamless-use-case was that "not all the use cases > seem to add new requirements, they are just examples of different > instances of expressing the same need". > > Thanks! > > Alvaro. > > [1] > https://mailarchive.ietf.org/arch/msg/rtg-bfd/kin3Me4WrKbe9WljhkSfkKvsefA > <https://mailarchive.ietf.org/arch/msg/rtg-bfd/kin3Me4WrKbe9WljhkSfkKvsefA>
signature.asc
Description: Message signed with OpenPGP using GPGMail
