Re: [Iasa20] draft-ietf-iasa2-rfc2418bis-01.txt

John C Klensin <john-ietf@jck.com> Mon, 22 October 2018 19:56 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 10398130EAF; Mon, 22 Oct 2018 12:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 s1z0VZ4-LpzC; Mon, 22 Oct 2018 12:56:03 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A987130E85; Mon, 22 Oct 2018 12:56:02 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1gEgIx-000Ppq-Fo; Mon, 22 Oct 2018 15:55:59 -0400
Date: Mon, 22 Oct 2018 15:55:53 -0400
From: John C Klensin <john-ietf@jck.com>
To: Joseph Lorenzo Hall <joe@cdt.org>
cc: "Livingood, Jason" <Jason_Livingood@comcast.com>, "Scott O. Bradner" <sob@sobco.com>, IETF Discussion Mailing List <ietf@ietf.org>, IASA 2 WG <iasa20@ietf.org>
Subject: Re: [Iasa20] draft-ietf-iasa2-rfc2418bis-01.txt
Message-ID: <541E68A8540C1AB8D39A96E4@PSB>
In-Reply-To: <CABtrr-UdUaZpoy8JroUL8oNkibc=F8hJ1ksnmvar0a1x3VCNrQ@mail.gmail.com>
References: <4915CD062D28D607D3D4AD44@PSB> <8906b727-f9c3-e7e1-164b-f7b88e48e74b@gmail.com> <1C77C07809EFB402E3E10907@PSB> <DE6E9C0D-C46B-4010-9E6D-8438DE687275@sobco.com> <2A42A5D2-9785-4350-92A5-0FDFD54AD17F@cable.comcast.com> <9A5B610BA33D4336A91409DA@PSB> <CABtrr-UdUaZpoy8JroUL8oNkibc=F8hJ1ksnmvar0a1x3VCNrQ@mail.gmail.com>
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
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/XGec-YN8N-7ylMiFcMIbkR6qPso>
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: Mon, 22 Oct 2018 19:56:16 -0000

For clarification, which kinds of updates?   Updating a document
to reflect different organizational structure clearly is in
scope.  Whether replacing the document (rather than updating it
with a new document) is in scope seems to me to be simply a
different choice as long as the replacement document meets two
conditions:

(1) It does not leave a lot of loose ends in terms of references
to the original document, existing updates to the original
document, or other things that would create confusion and best
and contradictory requirements at worst.

(2) It does not make "any changes to anything related to the
oversight or steering of the standards process as currently
conducted by the IESG and IAB, the appeal chain, the confirming
bodies for existing IETF
and IAB appointments, the IRTF, or ISOC's memberships in other
organizations."  (quoting from the last paragraph of the charter
at https://datatracker.ietf.org/doc/charter-ietf-iasa2/ )

My main difficulty with the 2814bis I-D is that it seems to
create issues with both (1) and (2) above.  My main difficulty
with 5377bis is that it _may_ be a problem with (2).   Both also
contain a number of errors, some at the nit-picking level and
others not, but those are not scope issues.

Watch for draft-klensin-iasa2-2418upd-5377upd-00, which should
provide a better idea of what I have in mind as a
clearly-in-scope alternative than my ranting.

   best,
     john


--On Monday, October 22, 2018 15:35 -0400 Joseph Lorenzo Hall
<joe@cdt.org> wrote:

> These kinds of updates are not in scope for this WG, it seems
> to me.
> 
> On Mon, Oct 22, 2018 at 2:01 PM John C Klensin
> <john-ietf@jck.com> wrote:
> 
>> Jason,
>> 
>> For perspective, I think there is a longstanding problem with
>> IETF procedural work.   I don't know how typical I am, but, in
>> recent years, I've ended up with very little time to spend on
>> IETF work.  Both personal preferences and my perceptions of
>> the best interests of the Internet lead me to try to spend as
>> large a portion of that time as possible on substantive work
>> rather than procedures.  So, although I'm on the WG mailing
>> list, I looked at the WG Charter and early discussions,
>> accepted the explanation that this was about a largely
>> technical change from the original "ISOC activity" model and
>> corresponding IASA structure to a semi-separate LLC and the
>> things that implies and the promise in the charter that the
>> effort would have no effect one IETF procedures, and have not
>> been paying in-depth attention.   I'm still not convinced
>> that the changes are worth the trouble but, if the IESG and
>> those who are active in the WG are convinced --and convinced
>> you can get it right-- my attitude has been "go for it and
>> I'll go spend my time on substantive technical work".
>> 
>> However, that approach is conditioned on the WG being able to
>> get all of it right.  Whether to adjust the terminology of
>> 2418 by update or replacement is a matter of taste and I'm
>> happy to defer to the WG's consensus taste... However, if the
>> WG manages to demonstrate that it can't produce an update to
>> 2418 without unintended side effects or pushing the
>> boundaries of the contract with the community implied by the
>> charter, at least without significantly more effort than has
>> been invested so far, then, as I see it, the balance changes
>> from "WG choice" to "better go the update" route.   And,
>> fwiw, while it is late in your process, you are, IMO at
>> least, far better off finding that out now than getting the
>> same feedback during IETF Last Call (potentially including
>> appeals from the Last Call itself because the document fell
>> outside the WG Charter into areas that would have drawn
>> people who would have participated more actively in the WG
>> effort had changes to IETF procedures been on the agenda).
>> 
>> So, while I should have been doing other things, I've spent
>> much of today looking at another document or two that might
>> have been candidates for the "update" approach.  For better
>> or worse, I've found the same sort of issues that I found
>> with 2418bis: changes that should have been made if the
>> document was to be a replacement, a substantive error or two,
>> q0uestions about whether IETF procedures for document
>> approval were being changes, and difficulties with
>> longstanding rules about replacement ("obsoleting")
>> documents.   In at least one case, the document has cleared
>> WGLC but, given those issues, is clearly not ready for IETF
>> LC.
>> 
>> IMO, two documents with problems of this sort, including one
>> that the WG was prepared to sign off on, takes the substantive
>> part of the replace vs. update choice out of the realms of
>> both "WG preference" and "isolated example".
>> 
>> So, too bad this is late.  And too bad it is going to require
>> more work.  However, it seems to me that we are better of
>> catching these things now rather than later... and I hope that
>> it does not suggest that we need to ask ourselves fundamental
>> questions about the quality of the WG process in assembling
>> and reviewing other documents.
>> 
>> I sincerely hope you can avoid blaming the messengers.
>> 
>> best,
>>    john
>> 
>> 
>> 
>> 
>> --On Monday, October 22, 2018 14:23 +0000 "Livingood, Jason"
>> <Jason_Livingood@comcast.com> wrote:
>> 
>> > We debated the update tactic some months ago. It seemed
>> > whatever path we took, we might be criticized but we had to
>> > pick one. This is very nearly the final document in that
>> > long list, so it is interesting that its really only one of
>> > the last few to see this issue raised. Of course it seems
>> > quite possible we'll now spend more time debating it on
>> > email lists that it'd take to produce the document updates.
>> > ;-)
>> 
>> 
>> 
>>