On 9/25/15, 1:02 PM, "aldrin ietf" <[email protected]<mailto:[email protected]>> wrote:
Sam: Hi! How are you? Haven’t read the review comments, but would like to respond to general comments. - Whether to stop Use case document to proceed further or nor, is the comment specific to this document or general comment applicable to all use case documents? My opinion is general, but there are also specific reasons applicable to this document. - If use you think use case documents has limited purposes, then it should be discouraged at the beginning and shouldn’t even be adopted in the first place. It is not prudent to invest time, for individual/group, for the things which are going to be dropped. The work shouldn’t be discouraged! Use cases clearly serve as motivation for problems to be solved, which is important to frame and scope the work to be done in any WG. However, I think that the usefulness in many cases stops there: once the solution has been developed. There are specific actions being taken, but as you can imagine one size doesn’t fit all. As an example, take a look at the charter for detnet [1] (still not approved). In there it is clear that the work on use cases (for example) is important to guide the WG and help newcomers, but that it may not be published. Note that the work is not changing, the expectations for publication are — those are two very different things. [1] https://datatracker.ietf.org/doc/charter-ietf-detnet/ Coming back to this specific document.. I’m asking the WG to consider not publishing, not telling it what to do. In fact, if you look at the WG charter, even though there is a specific Milestone, the WG is chartered to “define a mechanism..” (not to produce use cases). Nonetheless, because the work has already been done, the WG can make the decision whether it still wants to publish or not. - I do not think use case has to document requirements explicitly. If it has to, then what should requirement document contain? If the plan is to merge both, this should be discussed across, not just BFD, to get an agreement. I see there are lot of use case, requirement docs in various WG’s. It’s interesting that you mention a requirements document because there isn’t one. That is exactly one of the points I’m trying to make: the solution that addresses the use cases is S-BFD (as documented in draft-ietf-bfd-seamless-base [2]), but how do we know the solution in fact solves the use cases without clear requirements? To me, the bottom line is this: if we’re going to publish this document, let’s make it valuable by clearly stating what is needed in each use case that BFD can’t do. [2] That draft in fact says so in the Introduction: "This document extends BFD to provide solutions to use cases listed in [I-D.ietf-bfd-seamless-use-case].” Thanks! Alvaro.
