On Sat, Jul 20, 2019 at 12:08 AM John C Klensin <john-ietf@xxxxxxx> wrote: > > > > --On Friday, 19 July, 2019 19:05 +0000 john heasley > <heas@xxxxxxxxxxxxx> wrote: > > > Fri, Jul 19, 2019 at 10:48:41AM -0400, John C Klensin: > >> and review only by > >> self-selected specialist groups. > > > > No one has said/suggested 'self-selected'. anyone can review > > any document. > > But "anyone can review any document" is completely consistent > with "self-selected". If we had a mechanism whereby people were > told which documents to review and were then required to do so, > that would still be consistent with "anyone can review any > document". But we don't do that. Even members of area review > teams who, in some cases, may draw assignments for documents for > review on a rotary basis, have volunteered for those teams and > are hence self-selected to some extent. So, yes, anyone can > review any document but for them to actually do so, they have to > decide that is worthwhile and then go do so. And that is the > very essence of "self-selected". > > Participation in WGs is much the same situation. In principle, > anyone can participate in any WG. The people who do so select > themselves -- we don't cast lots in the general IETF participant > population and then tell people which WGs they are required to > participate in. And we have a considerable history of a > relatively small group of people with common interests and > background forming a WG that draws on those interests and > background. Nothing prevents anyone else from participating in > the WG, but, if they are neither expert in the WG's subject > matter nor particularly interested in it, they typically don't. > > Or am I misunderstanding the point you are trying to make? > > > >> I don't see what value doing the > >> work in the IETF provides other than an apparent endorsement > > > > Because it is related to products of the ietf and that is > > where, presumably, the expertise for the given product lies. > > If you want to fix the pluggable optic MSA, I presume you > > would go to the IEEE - not my area of expertise, so don't > > bother correcting which group mangled it. > > But that is exactly what confused me about this. With the > understanding that I don't even know what a pluggable optic MSA > is, much less what is wrong with it, if it is an IEEE standard > and one wants to fix it, one takes it to the IEEE. Then one > goes through the IEEE's process for revising standards, a > process that requires several levels of review. Unless things > have changed a lot since I had significant contact with IEEE > standards, WG-level are publishing documents on their own and > indicating that those documents supercede the standards in > practice. > > But, as I understand it, that is precisely what these proposals > are about: allowing a WG to declare a piece of its work as ready > to go without review and validation by the rest of the IETF. Whoa, no no no - that's not the intent, but I think I now finally understand much more of the disconnect in this thread. When Job initially presented his idea it seemed to me (and still seems to me) that this would solve a bunch of very real needs, and I started playing with some ideas on how we could implement something like this. Unsurprisingly I was viewing this though the lens of my own experiences, and I really didn't intend marking a draft in this way as carrying as much weight as people seems to think it would. I suspect that much of this comes down to poor terminology, and people (me!) not reevaluating what the term means both to themselves others - I've been following the thread, but it was only when I chatted with some people here in Montreal that I finally realized that the term "stable" means much more "stable" to people than I was intending it to convey - I suspect that much of the disconnect here stems from this terminology issue -- the term "checkpoint" was suggested, and this is probably much closer to what I was intending. I wasn't intending marking a draft to allow "a WG to declare a piece of its work as ready to go without review and validation by the rest of the IETF." - as I'd initially said, these would still be drafts, and the "It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."" type disclaimer should definitely still apply -- a marked draft (at least in my mind, obviously I communicated this all poorly) would have much much *much* less standing than a draft which had passed WGLC - which is still not "ready to go without review and validation by the rest of the IETF." but rather "ready to go *for* review and validation by the rest of the IETF. A "marked" draft would mainly allow external people to see a *snapshot* of what the WG has currently agreed to in a document -- from the "Operators and the IETF" survey (https://tools.ietf.org/html/draft-opsawg-operators-ietf-00#section-2.2.2) lots of external people want to follow what the IETF is doing, but don't have the time or stomach to follow all the discussions The way in which we might "mark" a draft evolved over time: The first idea (chosen to be trivial to implement) would be a webpage with pointers to (regular) drafts. The (rough) implementation was that WG chairs could suggest to their ADs that a document should be a "Living Document", the AD would almost definitely) agree[0]. The chairs could then move this pointer to future versions of the draft if and when the WG agrees that a version has settled. The second iteration of the idea was "Hey, we could just use a tag in the datatracker" -- we currently have tags like "New", "Expires soon", etc -- we could have a new tag which could be applied by the chairs saying that this particular version reflects what the WG *currently* thinks... as someone who uses the datatracker almost every day, this seemed like a fine idea -- until it was pointed out to me that people outside the IETF have no idea what this datatracker is, nor how it would be used. The third (current) iteration was "Ooooh, we change a document name from draft-bob-foo-bar to draft-ietf-foo-bar - this indicates that a WG has decided it is worth working on. What if we use draft-ietf-foo-bar -> draft-stable-foo-bar (or stable-foo-bar or similar)? This follows an understood paradigm, etc..." -- I liked the term "stable", but I was viewing it much more as a stable development tree, not a release tree, and the term stable was clearly the wrong one.... draft-checkpoint-foo-bar would have been better (but still imperfect) representation of what I was intending it to mean. I was also thinking that a "draft-<some_sort_of_marker>-foo-bar" type document could / should include some sort of strong / visible boilerplate along the lines of: *********************************************************************************************************** * This document reflects the **current** views of the foo working group. It has not received * IETF review, it is not an RFC, it is not set in stone. It is a snapshot in time of the current * views, and is, like any ID, subject to change, etc. * It is inappropriate to use / refer to this as reference material or to cite this as anything other * than as "work in progress.". If you build a test / demo / PoC implementation from this, * understand that it is all subject to change, etc. *********************************************************************************************************** I really should have communicated what *I* thought a marking would be intending to convey; I did want others to be able to use this proposal to other use cases, but I really really don't think that it should ever imply that "a piece of its work as ready to go without review and validation by the rest of the IETF." I still think that there are real problems to solve, but I didn't expect or want this proposal to carry as much weight as people seem to think it may, nor did I want it to take up this much of the ietf@ lists time and energy. It's just an idea / proposal -- it is entirely possible that it is a bad one / simply won't work for us / needs major refinement -- I'd like to still discuss it, but this really isn't worth any animosity, etc. W > I > do believe that it may beentirely appropriate for some portions > of a WG's work to be handled that way, but I think that those > cases (the cases, not the details) should get consensus in the > IETF on a case by case basis. That is, of course, exactly what > we do by appointing Designated Experts or a Designated Expert > team review process for IANA registry modifications. In > general, the decision to create the registry and to use that > review model requires IETF consensus but individual entries do > not. Are there other things, such as operational advice that > stops short of Applicability Statements in particular WGs? I > don't know, but I assume the answer is probably yes. And, like > several others, I'd like to see a very specific proposal in I-Ds > form, not more of this somewhat wandering conversation. > > >> that can be presented as involving more than a working group. > > > > This seems like a claim that a LD with the aforementioned > > review process would affect the reputation of RFCs, which I > > reject. it is presented as involving the process and those > > whom the document type claims. RFC has a process, BCP has > > one, LD would have one, and PRETZEL would have one. BCP, mpov, > > carries far more weight than RFC. > > We probably need to agree to disagree about some or most of > that, including BCPs carrying more weight than "RFCs". I assume > when you say that, you means Standards Track RFCs. If not, I > probably agree, but, I think it takes us into the "not all RFCs > are standards" discussion. In any event, while I note your > opinion, many people who worry about procurement or conformance > would disagree with you. > > best, > john > > > > >> Exactly. And if I wanted to push parts of my i18n work > >> forward, > > > > which is what? What is your i18n work? I do not know. If it > > is definition of the wire formats, etc - no, that is not the > > goal here. Not mine, nor Job's. A 7525-like document about > > i18n would be, again mpov. > > > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
