Warren wrote: > ... and I thought we should adopt this, have a very short discussion > on the results, and then quickly move to WGLC and publish it. Having > survey results (which show a number of issues, some obvious and some > surprising) as an OpsAWG document makes it clear that this is > something that we (the IETF and OpsAWG in particular) are actually > paying attention to, and are going to try and address. > > The survey results look kinda like a problem statement, and having it > published by OpsAWG gives it a good home, and helps make it clear > where discussions on the "solutions" are welcome.
Hmm - I would support adoption if the WG chairs intend to make this draft actually look like a problem statement, not just kinda. This could be done, by planning to add a small amount of material summarizing the problem at the end of the draft ... where Section 5 is already effectively a placeholder awaiting addition of that sort of material. I have a hard time supporting draft adoption for the sole purpose of rubber-stamping the draft with the WG's imprimatur, with effectively no work on the draft occurring in the WG. Thanks, --David (who has two drafts with operator co-authors) > -----Original Message----- > From: OPSAWG [mailto:[email protected]] On Behalf Of Warren Kumari > Sent: Thursday, January 08, 2015 3:00 PM > To: Juergen Schoenwaelder; Chris Grundemann; Warren Kumari; [email protected]; > [email protected] > Subject: Re: [OPSAWG] Call for Adoption: draft-opsawg-operators-ietf > > On Thu, Jan 8, 2015 at 2:26 AM, Juergen Schoenwaelder > <[email protected]> wrote: > > On Wed, Jan 07, 2015 at 11:13:10PM +0000, Chris Grundemann wrote: > >> On 1/7/15, 3:52 PM, "Juergen Schoenwaelder" > >> <[email protected]> wrote: > >> > >> >On Wed, Jan 07, 2015 at 05:18:12PM -0500, Warren Kumari wrote: > >> >> Dear OpsAWG, > >> >> > >> >> This starts a Call for Adoption for draft-opsawg-operators-ietf. > >> >> > >> >> The draft is available here: > >> >> https://datatracker.ietf.org/doc/draft-opsawg-operators-ietf/ > >> >> > >> > > >> >The I-D reports results from a survey. It is not a technical > >> >specification that a working group can work on. > >> > >> The work intended is to further analyze the results and the situation they > >> describe to identify additional solutions that may be actionable. These > >> potential actions may come from the IETF, the Operator communities around > >> the world, or possibly the ISOC. > >> > >> Simply reporting that we have found a set of problems is only part of the > >> goal for this document. From the abstract: > >> > >> "The primary purpose of doing this is to start a conversation which we > >> hope will lead to increases in the level of operational input and feedback > >> to the IETF standards making process." > >> > >> >My recommendation would be to change the title to be more specific > >> >that this document is a survey report and then to submit this document > >> >as an individual submission to the RFC editor for publication. I do > >> >not see that a WG process can add value to the survey report. > >> > >> We, the authors, considered that path (and had several ADs offer to > >> sponsor the I-D as well). We believe however that this is absolutly one > >> type of work the OpsAWG should take on: Building the intellectual capital > >> of the IETF by making it easier and more likely for implementors (read: > >> operators) to participate. > >> > > > > The survey report is one thing, possible actions to change the > > situation are another thing. I prefer to not mix those two together. > > For example, how do we determine that "making it easier and more > > likely for implementors (read: operators) to participate" has been > > achieved? I am not saying this discussion is not worthwhile, do not > > get me wrong on that. But I do not think that making this document a > > WG document is useful. My preference still is to publish the survey > > via the individual stream and discuss any possible actions to change > > the situation separately. OPSAWG should allocate time for this > > discussion, I do not think the survery report has to become an OPSAWG > > working group item for having this discussion. > > ... and I thought we should adopt this, have a very short discussion > on the results, and then quickly move to WGLC and publish it. Having > survey results (which show a number of issues, some obvious and some > surprising) as an OpsAWG document makes it clear that this is > something that we (the IETF and OpsAWG in particular) are actually > paying attention to, and are going to try and address. > > The survey results look kinda like a problem statement, and having it > published by OpsAWG gives it a good home, and helps make it clear > where discussions on the "solutions" are welcome. Concerns about the > lack of operator input are not new - there have been rumblings about > it for a long, long time; making it clear that we are actually taking > this seriously, and are trying to address the issue is important. IMO, > Independent Submissions does not give that impression - for various > reasons people have the idea that IS is a stream for non-IETF > documents, or things that someone somewhere thought were vaguely > interesting, and the IETF didn't care enough about to squash or > champion. > > > Much of this is not a technical argument, but rather a touchy feely, > marketing argument... > W > > > > > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > -- > 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 > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
