[rfc-i] List-Unsubscribe

johnfaltermeier <johnfaltermeier@email.com> Sat, 29 February 2020 19:59 UTC

Return-Path: <rfc-interest-bounces@rfc-editor.org>
X-Original-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Delivered-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2E03A124E for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Sat, 29 Feb 2020 11:59:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, MIME_HTML_MOSTLY=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mail.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 s-dKNzajPb-S for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Sat, 29 Feb 2020 11:59:46 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425953A124B for <rfc-interest-archive-SieQuei0be@ietf.org>; Sat, 29 Feb 2020 11:59:46 -0800 (PST)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id 23649F406F3; Sat, 29 Feb 2020 11:59:29 -0800 (PST)
X-Original-To: rfc-interest@rfc-editor.org
Delivered-To: rfc-interest@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id F0C01F406F3 for <rfc-interest@rfc-editor.org>; Sat, 29 Feb 2020 11:59:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Authentication-Results: rfcpa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mail.com
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPiFsV7iDier for <rfc-interest@rfc-editor.org>; Sat, 29 Feb 2020 11:59:25 -0800 (PST)
Received: from mout.gmx.com (mout.gmx.com [74.208.4.200]) by rfc-editor.org (Postfix) with ESMTPS id 16017F40463 for <rfc-interest@rfc-editor.org>; Sat, 29 Feb 2020 11:59:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mail.com; s=dbd5af2cbaf7; t=1583006380; bh=NW+0S2h/Ci/asLY7SDeKgIScdVRcDe5qYETibpYkdz4=; h=X-UI-Sender-Class:Date:Subject:From:To; b=6vUZGIzv/CrJh5tygX9X/ZIF8it/ucsh90Jm+7GvByqwmsBsH3M3e/uunRZoGYfRB T86o4QIiFy6ylknBgfLe7LqM9bXbD6Pzc3unXDYnEpukJeHbZoEgwzEm0PCo259xfh qO5XuFHUgzot/UwanfCtE8mqtk2W15G/vSj3pWuY=
X-UI-Sender-Class: 214d933f-fd2f-45c7-a636-f5d79ae31a79
Received: from [IPv6:2607:fb90:1c3f:ca8a:0:1c:56fd:dc01] ([172.58.110.188]) by mail.gmx.com (mrgmxus003 [74.208.5.15]) with ESMTPSA (Nemesis) id 0LhgZD-1jlv472aLR-00mvAk for <rfc-interest@rfc-editor.org>; Sat, 29 Feb 2020 20:59:40 +0100
Date: Sat, 29 Feb 2020 11:59:30 -0800
Message-ID: <kwn0l39mwxvb1ffvdfv7wqhl.1583006370206@email.android.com>
Importance: normal
From: johnfaltermeier <johnfaltermeier@email.com>
To: rfc-interest@rfc-editor.org
MIME-Version: 1.0
X-Provags-ID: V03:K1:6Bg2wBXpWkKyYTHfql9j7xcVZtTMUVIOEbMgianJsRR+Rl41cQp c7yf92kn6OuEmw1CdNrkzscB6YjCQNwhQbYjBNt9FP7EJCdohQqnjwQVV5KZAwdX4D4Ou9T RTby7rq1choEF8hz6S0t4xaPUTuHDC8FTMqZrsm0shAsEiwejIheXuRKI7/pIM0eqAh+Mbc PgdHQln0kSNw1q4JTWvUg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:vtnsVsO6qls=:rfbnhwf/ZVbLbbF79E9r4L mfc1pxMz/3PZqpjK2PMmad3hbRRrBmzzuUcn1IsevZDG4j+1blVeBKAJ/vg88FYMxyN6TMTLH rYxBOnNBGzVkpNjwOWloAoAv3uf8soBYcb2qDY6H0m29bkjp5L+zlGG96pOY41qrv4hg1Z9yb riMygehqgxhMc/ouSHVPLKnyNHlTJNXSdiyV8WVxiO2cDiV8is+wkAKhG4ejjZOUvSMamB8r5 aUFw3LHpVOcFVkuk/inwxVPnVOAGYsrL3XlSK6L1VcwDVmLUfax1u+qymiK3comLRuq+FGOEb rFT+DzudSVd8aCoZxihW0eWf2+jJS/yo5xfSAt1isjukrxQHv6iDT+xuopsA1wG5Hk7+tnCYk 3NU9FCWgT+Gp9qtic8JXvA1Fiyd/5Xr9NaRwC58YrNkX/atdjVwb//hnNbov03ZrqJyErK6di MD0fKN0ClvmrU/7Feb/Y1Nj1wMlITKY0+SLj07tjQw6xkcNbMWF08WIdERgGFg82vGKKT8Cgw DdPjXtx43fsVY3wWGUm6oWKiRdzTz7QLqaLqCA3EvljgiKZpXk2NbcYt1o28OKQcAyjYkefwE gkrHtIhvdIHyJT8StoShPmrm63DpWRYHUP+R3qAE+tChYCjfGVG+Qvf+Cf1eUFHWGB0DJGreD KOpXAQsGsPVsIVkn55CprNfh31GO2joYpfkTwDGwRWQYqX0sz5IvRrMjNA9HwhybfFcZptB+H 1gS/WtSkuyU0PGvnfGVT+sMTydF4v0+PkWNa8oc/QK8STpDmGmGbuhgxroCDJC11vvUKCPUOS z7pQL7VonceHv1lb2xAIK0KtCI5gpgyr87WKbH+l9hwF6ZTzQ4hCmK4E0zLOtYOaMH2ZLdR1S 9S+7ylIMemq1zvwPBIhEhqacnkBa/hF+N46yd9U7/i8GbM5Pj+A/cWTsqOSaEz/qhVplnwniA yyFvDNSMUTiVcB0Qv9xPQ9Oqt71JmJdXerp0AWiGb195xVwsy99+ccmnlSrKQkiwB30BYMBqi L/pzP8wY2Wc4JlGEeo4OGQe0iZkem3e/UTueMd3Zey04gyY7f1nOw776ECGX40cQv/rlldAjd 7oHnTqt1atmpBxgycUo4RATKLM2BzTCtlMogqTQsL2Xkh+lMO3vEtMhg9TphQs774K1F6aWoy 2KzFhXZ8CgwQZBqHdDceLsnGSTVxiv1f+ZYPy6+WrKWFv5mOfqCOZAzc+ar5Y/nlJNgXjH1Np HYLixAIWfwY33niJb
Subject: [rfc-i] List-Unsubscribe
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0447053574947087915=="
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: "rfc-interest" <rfc-interest-bounces@rfc-editor.org>

-------- Original message --------From: rfc-interest-request@rfc-editor.org Date: 2/29/2020  6:12 AM  (GMT-08:00) To: rfc-interest@rfc-editor.org Subject: rfc-interest Digest, Vol 184, Issue 13 Send rfc-interest mailing list submissions to	rfc-interest@rfc-editor.orgTo subscribe or unsubscribe via the World Wide Web, visit	https://www.rfc-editor.org/mailman/listinfo/rfc-interestor, via email, send a message with subject or body 'help' to	rfc-interest-request@rfc-editor.orgYou can reach the person managing the list at	rfc-interest-owner@rfc-editor.orgWhen replying, please edit your Subject line so it is more specificthan "Re: Contents of rfc-interest digest..."Today's Topics:   1. Re: Feedback solicited: Update tags draft (Donald Eastlake)   2. Re: Feedback solicited: Update tags draft (Suresh Krishnan)   3. Re: Feedback solicited: Update tags draft (Suresh Krishnan)   4. Re: Feedback solicited: Update tags draft (Eric Rescorla)   5. Re: Feedback solicited: Update tags draft (Carsten Bormann)----------------------------------------------------------------------Message: 1Date: Fri, 28 Feb 2020 15:41:30 -0500From: Donald Eastlake <d3e3e3@gmail.com>To>To: Mirja Kuehlewind <ietf@kuehlewind.net>Cc>Cc: Robert Sparks <rjsparks@nostrum.com>om>, RFC Interest	<rfc-interest@rfc-editor.org>Subjectubject: Re: [rfc-i] Feedback solicited: Update tags draftMessage-ID:	<CAF4+nEFdPMVMYhev3YxdU2-7kAfnNvh3jEec4EJfUyXZ-mQXEg@mail.gmail.com>Content-Typet-Type: text/plain; charset="UTF-8"I think this change is a great idea. The new tags are so much clearerand more straightforward than "Updates" that the only reason I see foran update tag is due to documents that are in process or the like, sayanything in WG Last Call or a later stage (IETF Last Call for non-WGdrafts). But if people really want, I wouldn't object to a period ofup to a year when new document (those in a state before publicationrequested) could use either Updates or the new tags.Thanks,Donald=============================== Donald E. Eastlake 3rd   +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.comOn Fri, Feb 28, 2020 at 8:34 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:>> Thanks everybody! As noted in the draft if updates should be continued or not is an open discussion point. Thanks for your feedback. We?d definitely happy to get even more opinions on this!>> Mirja>>>> > On 27. Feb 2020, at 22:30, Robert Sparks <rjsparks@nostrum.com> wrote:> >> >> > On 2/27/20 2:44 PM, Paul Kyzivat wrote:> >> Stephen,> >>> >> On 2/26/20 7:08 PM, Stephen Farrell wrote:> >>>> >>>> >>> On 26/02/2020 23:52, Suresh Krishnan wrote:> >>>> Now with a link to the draft :-)> >>>>> >>>> https://tools.ietf.org/html/draft-kuehlewind-update-tag-01> >>>> >>> Best of luck with it. You may need it;-)> >>>> >>> I'd be very supportive of defining these new tags. I'm> >>> not at all keen on discontinuing the use of UPDATEs> >>> until this new stuff has been shown to work and to have> >>> been adopted by authors/WGs. So allow some overlap (e.g.> >>> 3 years) after which these new tags are discontinued> >>> unless UPDATEs is instead discontinued. Or something> >>> like that.> >>>> >>> If you wanted to do this with no overlap, I'd be against> >>> it.> >>> >> I don't understand your logic here. Either this is a good change or it isn't.> >> > I disagree that you can conclude that decision without some actual runtime experience. We know that Updates _mostly_ works, and I think it would be a mistake to make a knife-switch cutover to disallowing its use. If edge cases arise that the thinking so far hasn't anticipated, it would be needed as a good fallback. An informed IESG (or other stream manager) can manage its use as experience with the other proposed relationships is gathered.> >> > My own opinion: I'm not yet convinced this attempt at refining the meaning of updates will help.> >> > In earlier versions of this conversation, I've championed that we hold updates to mean what this draft calls "Amends", and that we have other mechanics (through References and text) to cover the other two semantics. Pulling these into the metadata will create some new places judgement calls will have to be made. Examples (not intended to be exhaustive):> >> >  - it's not the same thing to accept 100 informative references as it is to accept 100 "See Also" relationship links> >> > - what happens when someone asks for a See Also link to something that's not an RFC or Internet-Draft?> >> > If we proceed with this idea, we need to leave room for such things to be discovered and reasonably worked through.> >> >> If it is (and I think so), then why can't the change be mandated, by forbidding the publication of new docs using the old tags? The checking could be implemented in IdNits.> >> >>> >>     Thanks,> >>     Paul> >>> >>> Cheers,> >>> S.> >>>> >>>>> >>>> Thanks Suresh> >>>>> >>>>> >>>>> On Feb 26, 2020, at 4:07 PM, Suresh Krishnan> >>>>> <suresh.krishnan@gmail.com> wrote:> >>>>>> >>>>> Hi all, Mirja and I wrote a draft defining new tags for defining> >>>>> relations between RFCs. One of the ongoing areas of confusion> >>>>> within the RFC Series is when and how RFCs interact with each> >>>>> other. What does it mean to have one document update another? Is> >>>>> information being added, or is existing information being changed?> >>>>>> >>>>>> >>>>> Asking the question of how to indicate relationships in the> >>>>> metadata for the documents has come up a few times (one example:> >>>>> ?Subject: Proposed IESG Statement on the use of the ?Updates?> >>>>> header? [0]), though generally in the context of IETF stream> >>>>> documents only. When we wrote the draft we were aiming it solely> >>>>> for use in the IETF Stream but we realized it might have wider> >>>>> applicability.> >>>>>> >>>>> We would ideally like to see relationships between RFCs more> >>>>> clearly defined in such a way as to apply regardless of document> >>>>> stream. We have introduced this draft already to the stream> >>>>> managers of the IAB, the IRTF and the Independent streams and would> >>>>> like to hear what the community thinks about this proposal. Thanks> >>>>> to everyone on rfc-i who as already commented. We would love to get> >>>>> some feedback specifically about but not limited to> >>>>>> >>>>> * Do you have any concerns about the guidance as proposed in this> >>>>> draft? * Do you have any concerns about doing this series? wide?> >>>>>> >>>>> Regards Suresh and Mirja> >>>>>> >>>>> NOTE: Even though we are both sitting members of the IESG, we have> >>>>> written this draft solely as members of the community and we will> >>>>> no longer be IESG members if and when this draft progresses :-)> >>>>>> >>>>> [0]> >>>>> https://mailarchive.ietf.org/arch/msg/ietf/-1u_1-peHKAmUDuLyGAJYu0fPCE/> >>>>> >>>>>> >>>> _______________________________________________ rfc-interest mailing> >>>> list rfc-interest@rfc-editor.org> >>>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest> >>>>> >>>>> >>>> _______________________________________________> >>>> rfc-interest mailing list> >>>> rfc-interest@rfc-editor.org> >>>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest> >>> >> _______________________________________________> >> rfc-interest mailing list> >> rfc-interest@rfc-editor.org> >> https://www.rfc-editor.org/mailman/listinfo/rfc-interest> > _______________________________________________> > rfc-interest mailing list> > rfc-interest@rfc-editor.org> > https://www.rfc-editor.org/mailman/listinfo/rfc-interest>> _______________________________________________> rfc-interest mailing list> rfc-interest@rfc-editor.org> https://www.rfc-editor.org/mailman/listinfo/rfc-interest------------------------------Message: 2Date: Sat, 29 Feb 2020 03:40:40 -0500From: Suresh Krishnan <suresh.krishnan@gmail.com>To>To: Julian Reschke <julian.reschke@gmx.de>Cc>Cc: rfc-interest@rfc-editor.orgSubject: Re: [rfc-i] Feedback solicited: Update tags draftMessage-ID: <C53901FC-05E9-4126-BE1E-6732B2ACF20A@gmail.com>Content-Typet-Type: text/plain;	charset=us-ascii> On Feb 27, 2020, at 3:56 PM, Julian Reschke <julian.reschke@gmx.de> wrote:> > On 27.02.2020 00:52, Suresh Krishnan wrote:>> Now with a link to the draft :-)>> >> https://tools.ietf.org/html/draft-kuehlewind-update-tag-01>> >> Thanks>> Suresh> > You may want to mention that this requires changes to the xml2rfc> vocabulary (RFC 7991).Thanks Julian. Will add this in the next revision.RegardsSuresh------------------------------Message: 3Date: Sat, 29 Feb 2020 03:48:28 -0500From: Suresh Krishnan <suresh.krishnan@gmail.com>To>To: Eric Rescorla <ekr@rtfm.com>Cc>Cc: RFC Interest <rfc-interest@rfc-editor.org>Subjectubject: Re: [rfc-i] Feedback solicited: Update tags draftMessage-ID: <AB0B3305-FCEC-48E6-A916-B86245CD1C3E@gmail.com>Content-Typet-Type: text/plain;	charset=us-asciiHi Ekr,> On Feb 28, 2020, at 9:23 AM, Eric Rescorla <ekr@rtfm.com> wrote:> > At present, I am not in favor of these changes.> > We already spend quite a bit of time debating which tags should apply when compared to the (IMO marginal) value of these tags, and this seems likely to make that worse. > > The "amended" tag in particular seems like a workaround for our refusal to simply update RFCs when they are wrong. The first rule of holes to stop digging.The option to bis the RFCs will still exist and the IESG can still guide people to do that. The goal of the Amended tag is to point implementers to other RFCs that are mandatory to implement. Right now Updates is being used both for optional extensions as well as for mandatory changes and the goal is to disambiguate this.RegardsSuresh------------------------------Message: 4Date: Sat, 29 Feb 2020 05:50:36 -0800From: Eric Rescorla <ekr@rtfm.com>To>To: Suresh Krishnan <suresh.krishnan@gmail.com>Cc>Cc: RFC Interest <rfc-interest@rfc-editor.org>Subjectubject: Re: [rfc-i] Feedback solicited: Update tags draftMessage-ID:	<CABcZeBMCZfSxTXUj0+Kuy2QJi+vJHcPpWjydobTD4ztuzTR2rQ@mail.gmail.com>Content-Typet-Type: text/plain; charset="utf-8"On Sat, Feb 29, 2020 at 12:48 AM Suresh Krishnan <suresh.krishnan@gmail.com>wrote:> Hi Ekr,>> > On Feb 28, 2020, at 9:23 AM, Eric Rescorla <ekr@rtfm.com> wrote:> >> > At present, I am not in favor of these changes.> >> > We already spend quite a bit of time debating which tags should apply> when compared to the (IMO marginal) value of these tags, and this seems> likely to make that worse.> >> > The "amended" tag in particular seems like a workaround for our refusal> to simply update RFCs when they are wrong. The first rule of holes to stop> digging.>> The option to bis the RFCs will still exist and the IESG can still guide> people to do that. The goal of the Amended tag is to point implementers to> other RFCs that are mandatory to implement. Right now Updates is being used> both for optional extensions as well as for mandatory changes and the goal> is to disambiguate this.>I'm not talking about -bising the RFC. I'm talking about re-publishingwith the same RFC #.More generally, I don't really understand what you think "mandatory"means.Consider two cases:1. We publish an RFC X with a clear mistake. For instance, it allocates   two code points, A and B, and then in the text it says A=1 and   B=2 but in the IANA considerations it says A=1, B=1.2. We publish an RFC X with an algorithm we later determine to be bad.   For instance it says to use a parameter 2 but we later determine   that 2 is bad and 3 would be better.In the former case, I would argue that the RFC correctly read had thecode points A=1 B=2 and thus in order to be conformant with RFC X, youneed to adopt B=2.However, what would you say in the latter case?  Older implementationscontinue to be conformant with RFC X, but just not with RFC Y, whichyou publish later. So, what does "mandatory" mean in this case? Theproblem here, as usual, is the failure to have some way to refer tothe concept of the protocol rather than the concept of the RFC.-Ekr-------------- next part --------------An HTML attachment was scrubbed...URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20200229/f0257e93/attachment-0001.html>------------------------------Message: 5Date: Sat, 29 Feb 2020 15:12:34 +0100From: Carsten Bormann <cabo@tzi.org>To>To: Eric Rescorla <ekr@rtfm.com>Cc>Cc: Suresh Krishnan <suresh.krishnan@gmail.com>om>, RFC Interest	<rfc-interest@rfc-editor.org>Subjectubject: Re: [rfc-i] Feedback solicited: Update tags draftMessage-ID: <49F70083-5388-49CA-8A5D-54324C04538C@tzi.org>Content-Typet-Type: text/plain;	charset=utf-8On 2020-02-29, at 14:50, Eric Rescorla <ekr@rtfm.com> wrote:> > However, what would you say in the latter case?  Older implementations> continue to be conformant with RFC X, but just not with RFC Y, We would need boilerplate in each RFC that includes potential future amendments.Gr??e, Carsten------------------------------Subject: Digest Footer_______________________________________________rfc-interest mailing listrfc-interest@rfc-editor.orghttps://www.rfc-editor.org/mailman/listinfo/rfc-interest------------------------------End of rfc-interest Digest, Vol 184, Issue 13*********************************************
_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest