On 9/29/15, 12:07 PM, "Sam Aldrin" <[email protected]> wrote:
Sam: Hi! >Hi Jeff and Alvaro, > >Inline for my comments. > >> On Sep 29, 2015, at 8:43 AM, Jeffrey Haas <[email protected]> wrote: >> >> Sam (and to a bigger extent, Alvaro), >> >> On Fri, Sep 25, 2015 at 11:48:19AM -0700, aldrin ietf wrote: >>>> 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. >>> >>> If that is the case, it shouldn¹t even be a WG document right? >>> Also, the deliverable was tracked as part of milestone isn¹t it? >>> Does that mean, milestones truly doesn¹t reflect the deliverable but >>>only Charter does? >>> >>> Do not know all the semantics of the IETF WG processes. Clarification >>>helps. >> >> Adopting the document within the WG basically means the working group >>"owns" >> the document and that we're motivated to get work on it done. This >>includes >> things like tracking it via a milestone. >> >> Not all WG documents will be published as RFCs. >> >> The bigger question to argue IETF-wide is when we have these short-lived >> documents, should we just start in something like a wiki especially if >>the >> information is to be maintained long-term? Possibly. But as other >>people >> have noted in different forums, the "IETF workflow" moves around the >> publication life-cycle of Internet-Drafts. >> >> I'm not completely sold on the maintenance of the use cases long-term >>in the >> wiki. In my opinion, the primary purpose of use case documents is to >>help >> clarify and move forward protocol work. Ideally a portion of the use >>cases >> are clear in the actual protocol documentation, just not their >>individual >> breakdowns. > >I¹d like to see that clarified across IETF, at the lease RTG area which I >am focussed on. This ³change² has been brewing in the IESG for a while, where many ADs have been expressing their opinion about the need (or lack thereof) for publishing some short-lived documents which have already met their useful lifetime. However, there is no one-size-fits-all statement that can be made. For example, use cases may inform the community of work that should be done later or of issues to be addressed elsewhere ‹ I think a good example of may be the documentation of the use cases that are seriously affected by multicast issues in wireless networks (which the IEEE may solve). Note that even though the different ADs express their opinion about the lack of need to publish documents, the ballots are always ³No Objection² ‹ this (in my case) is due to the fact that if the document got to the IESG for publication then it already has WG and IETF consensus. However, we have been making some explicit changes in some charters ‹ I pointed you before to the detnet charter as an example. All this comes back to me asking the WG to *consider* not publishing (vs just deciding myself). I (personally) still think we don¹t need to publish this document, but if the WG has a different opinion then I¹m ok with being on the rough side of the consensus. The other reason for making the ³change² slowly and not just issuing a wide-reaching statement is that, as Jeff mentioned above, the work moves around IDs/RFCs ‹ we (as a community) are not ready and/or don¹t have the tools to consistently move sustaining documents somewhere else (as in a Wiki). For now, it is a case-by-case consideration. At least in my case I will continue to ask the WGs I¹m responsible for to *consider* not publishing short-lived documents. [As I said above, I can be in the rough.] >Secondly, would like to see what the definition of short lived documents >are. >Why are problem statement, requirements etc, which are short lived and >more or less like use case document as well, made as RFC¹s? In general, I think that those other types of documents also fit the short-lived definition. Another example of a short-lived document is an implementation report. These are used to reflect the current implementation status of an ID, and is used in many cases to prove that the required implementations do exist and how they comply with the RFC-to-be. Not only is the lifetime limited, but if an implementation comes later (or changes), then it is not documented anywhere. The idr WG is not publishing implementation reports anymore, they are being put on a wiki. The first draft to go through this is ADD_PATH [1] [2]. :-) Thanks! Alvaro. [1] https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths-implementation/ [2] https://tools.ietf.org/wg/idr/trac/wiki/draft-ietf-idr-add-paths%20implemen tations
