Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)

John C Klensin <john-ietf@jck.com> Sat, 20 July 2019 04:08 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7CE12004C for <ietf@ietfa.amsl.com>; Fri, 19 Jul 2019 21:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.104
X-Spam-Level:
X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtFWnnk70n9s for <ietf@ietfa.amsl.com>; Fri, 19 Jul 2019 21:08:38 -0700 (PDT)
Received: from bsa3.jck.com (unknown [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A767E120044 for <ietf@ietf.org>; Fri, 19 Jul 2019 21:08:38 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1hogfk-00009G-IH; Sat, 20 Jul 2019 00:08:36 -0400
Date: Sat, 20 Jul 2019 00:08:31 -0400
From: John C Klensin <john-ietf@jck.com>
To: john heasley <heas@shrubbery.net>
cc: ietf@ietf.org
Subject: Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)
Message-ID: <7FF2DA2F2DC64741DA8B5747@JcK-HP5.jck.com>
In-Reply-To: <20190719190534.GG38674@shrubbery.net>
References: <F2D5DCCF-4051-444B-9522-9E11F9F93005@fugue.com> <869599E9-7571-4677-AB9A-961027549C54@network-heretics.com> <144ff436-a7a2-22f7-7b06-4d0b3bcfefac@joelhalpern.com> <20190719041456.GL33367@vurt.meerval.net> <254fc5f6-3576-a62f-b84f-a7c5d29b0055@joelhalpern.com> <a1561aa7-5f41-0e2a-1892-cfb587196ac0@gmail.com> <C3D53639-C2C0-42CE-9708-99294091E012@puck.nether.net> <a17a8648-14c8-1889-4ee3-86996ff6281e@gmail.com> <3B0C189A-D56B-430F-82FF-19DE0DC788DE@puck.nether.net> <BA80E73F53C26B9191294131@JcK-HP5.jck.com> <20190719190534.GG38674@shrubbery.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/cpibEiH-r79O5pFd4BkB-_zM_No>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2019 04:08:40 -0000


--On Friday, 19 July, 2019 19:05 +0000 john heasley
<heas@shrubbery.net> 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.  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.