Re: [Iasa20] draft-ietf-iasa2-consolidated-upd-06

Ted Hardie <ted.ietf@gmail.com> Fri, 08 March 2019 16:40 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: iasa20@ietfa.amsl.com
Delivered-To: iasa20@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0BA1313A1 for <iasa20@ietfa.amsl.com>; Fri, 8 Mar 2019 08:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 tylX-YljLAb7 for <iasa20@ietfa.amsl.com>; Fri, 8 Mar 2019 08:40:33 -0800 (PST)
Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D6A1313BA for <iasa20@ietf.org>; Fri, 8 Mar 2019 08:40:28 -0800 (PST)
Received: by mail-it1-x143.google.com with SMTP id z124so22217701itc.2 for <iasa20@ietf.org>; Fri, 08 Mar 2019 08:40:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2r2qFb9fE17d5k3t3FZ0yF89Hv3VlN9SKOQdvtan3GE=; b=mewYkkYRlsJCHZD4mGXpxeEf6FEqYBUcsPQdlAcNzUVLPKtXBPGBxyGSOnQSP198fo MrnkOM8sXF89pZuYmMuTmKnCiwfowv8vBUBKrPWbGFZ8IqUpL+CBr3DGO8LwFIMNGNsK d1rWchkHYVCzJ+J0dN3yb1nxunyzigLU45OZ30KdnJ6ONpdi06jOSgn5tZJM/POlHRq2 oe2dmApCtBtTmD+/2vfkfjCm9AEwSRDtV7d8E7tBHx3Hjr/fwiPKAgbk5X9hSuMchJck zr0Z5/BMkdTLt95jSDiDWu1QYqDov3sw+7G/f3vz5UOZGXkn6rNGIwAm2o6Sj0dWWUKW ZqOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2r2qFb9fE17d5k3t3FZ0yF89Hv3VlN9SKOQdvtan3GE=; b=FKNXRLZFu+YfpkvgbNp7j9SImS+0AtxZdMbJu6L+Q6V5SCqM0iB7Wiu44ZQFOJPr2X Qf0fwu8SDb4Ak64Flca0gmkEzkmicvMykDBcSwqLw95L1oVfFcniQtz1jFsR6a68A2wz FmpRYBEFY0fZkBRqf5kzfVba3PfA/elJ5E8aFx2rP4WSF0aJ2J/0Ge2Fv8CAHAjaE3vC yMoyO66wR7b1Yz7g1yjTlAOeySqqfmd3S3Udctr10wS0h4tGsjSxpIutY4m/ohLuVyQ8 gEjXKN7qEYhDzSIHLoaax9KEOwzeD24klpWtmTDvcCj28HzTJXtDhamIJ/d02fR45hQv KNpg==
X-Gm-Message-State: APjAAAVJZ2ZehoVEWQ2lwauP+wFQ0o672VHcbOWUk+Uwu998G49VZb4S UGjRcy+InieO3b6E2bYVHpShvkU4n7wG+lt44NfsFoaBDR8=
X-Google-Smtp-Source: APXvYqzmYryGvJbdzLf4HRacJR0rLqwldWBGUcA/WNgVgXpNLMZ0iif+iw6ASMd3tb3IcZd6WOFkJtAVJJPs70c2W5o=
X-Received: by 2002:a02:ec4:: with SMTP id 187mr10370392jae.11.1552063227209; Fri, 08 Mar 2019 08:40:27 -0800 (PST)
MIME-Version: 1.0
References: <A7B72177ABB2B2F0BEE7763B@PSB> <567462F2-46E3-445E-BDA3-493DA7AD31CC@cooperw.in> <4faec579-e4dd-f138-4c96-f26d9945c307@gmail.com> <3AC01BB5-613D-474C-B8AE-A85D8F264A83@cooperw.in> <CD6FB2CD65EAEA39265FFD0F@PSB>
In-Reply-To: <CD6FB2CD65EAEA39265FFD0F@PSB>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Fri, 08 Mar 2019 08:40:00 -0800
Message-ID: <CA+9kkMBD_5GQ-w_HyF2RbBx6vbGzQ5pTJjcn63-dvJPqy2u5rw@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: Alissa Cooper <alissa@cooperw.in>, Brian E Carpenter <brian.e.carpenter@gmail.com>, IASA 2 WG <iasa20@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000053ad4c058397e1fe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/9tjZgUD57plZyq_Zt7ujeGPP1_8>
Subject: Re: [Iasa20] draft-ietf-iasa2-consolidated-upd-06
X-BeenThere: iasa20@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions relating to reorganising the IETF administrative structures in the so called “IASA 2.0” project. <iasa20.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iasa20>, <mailto:iasa20-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iasa20/>
List-Post: <mailto:iasa20@ietf.org>
List-Help: <mailto:iasa20-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iasa20>, <mailto:iasa20-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Mar 2019 16:40:37 -0000

Comments in-line.

On Thu, Mar 7, 2019 at 4:56 PM John C Klensin <john-ietf@jck.com> wrote:

>
>
> --On Thursday, March 7, 2019 16:52 -0500 Alissa Cooper
> <alissa@cooperw.in> wrote:
>
> > Hi Brian,
> >
> >> On Mar 7, 2019, at 2:46 PM, Brian E Carpenter
> >> <brian.e.carpenter@gmail.com> wrote:
> >>
> >> On 08-Mar-19 06:12, Alissa Cooper wrote:
> >>> Thanks. I still don't think this is quite right because
> >>> there is no basis for this working group to obsolete or
> >>> render historic RFC 3929 simply because it mentions the IETF
> >>> Executive Director. It seems that RFC 3929 should be treated
> >>> in Section 2 the same as the other documents in that section.
> >>
> >> There's a more general issue: tracking down all "open"
> >> Experimental RFCs and deciding which of them need to be
> >> closed off as Historic or Obsolete or both. <joke>No doubt
> >> the IESG will be doing this in its copious free time.</joke>
> >> But for the present, doesn't it make more sense to clear both
> >> 3929 and 4633 up right away? I agree that it's outside the
> >> WG's mandate, strictly interpreted, but if the IESG consents,
> >> is that really a problem?
> >
> > Yes. The point of charters is to scope working groups' work.
> > This working group is chartered to to document the normative
> > changes to IETF administrative structures and processes
> > necessary to effectuate the change to IASA 2.0. Obsoleting
> > documents about other things because they are out of date is
> > not within the charter.
>
> Alissa,
>
> I was in the process of putting together a discussion of the
> IETF's history with making things Historic and then Brian's note
> arrived and I concluded that maybe I was missing your main point
> and I discarded that note.  We may have a small difference of
> opinion about what it means to "scope working groups' work",
> which I want to try to summarize below.
>
> However, I, and I assume most WG participants, am much more
> interested in getting this work finished than in arguing so, if
> you are putting on your Responsible AD hat and telling me to
> change this, I will certainly do so.
>
> To me, there are two closely-related principles for charters and
> limits on the scope of a WG's work:
>
> (1) To be sure enough that the community is aware of what the WG
> is doing so that IETF participants who are skilled in the topic
> area(s) and materially concerned can either participate or
> otherwise follow the WG's efforts and, in particular, are not
> blindsided at IETF LC time or later.
>
> (2) To lower the odds that the WG will go off in the weeds in a
> major way, in particular by exceeding its competence and/or
> taking up time that detracts from the overall planned schedule
> or other tasks, and giving people who believe it is doing that a
> basis for raising objections.
>
> However, I think it is also important to keep some perspective
> and flexibility on charters and scope if those principles are
> not grossly violated.  One of the hallmarks of the IETF (and the
> network specification development mechanisms long before it) has
> been that it is far more important to get the right things to
> happen and get the right things done than to go looking for
> rules to interpret and enforce narrowly.  Some of us have even
> argued in other contexts that, in addition to technical
> advantages, much of the reason why the core technology for
> modern networking is TCP/IP and related protocols as specified
> by the IETF and its predecessor rather than, e.g., OSI, is
> precisely that focus on getting the right things done rather
> that spending disproportionate energy figuring out the letter of
> the are and enforcing them.
>
> So, in this particular case, the WG, working well within its
> scope, discovered some now-problematic phrasing in 3929.   In
> the process of figuring out how to fix that, it was observed
> that the document was almost certainly no longer relevant.  The
> conclusion, as I understood it, was that getting it off the list
> of things that people were expected to read and understand would
> be a more efficient fix than patching a phrase in a seriously
> old document and perhaps creating confusion about whether the
> specified experiment was still alive and relevant.  That is not
> exceeding the WG's task area or competence, because almost
> anyone could spot the relative obsolescence of the spec and the
> problem was discovered in the process of doing the WG's work.
> It didn't take extra time or effort.  Ted (the author), who
> appears to be following the WG's work, didn't stand up and say
> "no, no, that experiment is still active and the document is
> still alive" and neither did anyone else.  I assume any such
> substantive objection would have immediately killed the "make
> Historic" plan.
>

Actually, the issue was raised by Robert, who was surprised at the
deprecation.  In my follow-up to Brian's message, I said this:

I don't see how the lack of experimental deadline makes it this WG's job to
>> decide--can you clarify your thinking?  In this document's case, it is hard
>> to call the experiment done when it has never been exercised.  We can say
>> that the threat of it has been useful, but that the actual methods are "not
>> proven" (in the Scots legal sense).
>>
>> My take on why they were included was more that they included the phrase
>> "IETF Executive Director"; the doc says that specific methods require
>> telling the IETF Executive Director something (e.g. that you volunteer to
>> serve).  The working group concluded that this didn't mean the new
>> Executive Director, but meant the Secretariat role that used that term
>> before.  I personally would fix that with an erratum, rather than
>> deprecation or obsolescence.
>>
>> I may, of course, have a slight bias here.
>>
>
If that was not clear that I thought that the document is still live; I
apologize.  As far as I can tell, the idea of this has helped, but the
methods have not been tested.  As a result, I don't think the document is
past its useful life.  Patching it seems sufficient.

Ted


>
> So, yes, the decision could be to just patch the document
> because making it Historic is not strictly within the WG's scope
> but I don't see any possible harm that could result from just
> getting 3929 off everyone's radar and out of the way.   In
> addition, now that the problem has been identified and with a
> nod to Brian's joke, do you really want to either get a request
> for a WG or an individual submission to make 3929 Historic?
> While I certainly would not want to advocate a hunting
> expedition to identify and consider all of outstanding
> Experimental documents and figure out which ones should be
> Historic and/or Obsolete, in this case, the hard work of
> identifying a relevant document and even writing an appropriate
> sentence has been done already.
>
> best,
>     john
>
> _______________________________________________
> iasa20 mailing list
> iasa20@ietf.org
> https://www.ietf.org/mailman/listinfo/iasa20
>