[rfc-i] Feedback solicited: Update tags draft

[d3e3e3 at gmail.com (Donald Eastlake)]

I think this change is a great idea. The new tags are so much clearer
and more straightforward than "Updates" that the only reason I see for
an update tag is due to documents that are in process or the like, say
anything in WG Last Call or a later stage (IETF Last Call for non-WG
drafts). But if people really want, I wouldn't object to a period of
up to a year when new document (those in a state before publication
requested) could use either Updates or the new tags.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3 at gmail.com

On Fri, Feb 28, 2020 at 8:34 AM Mirja Kuehlewind <ietf at 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 at 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 at 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 at rfc-editor.org
> >>>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> rfc-interest mailing list
> >>>> rfc-interest at rfc-editor.org
> >>>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> >>
> >> _______________________________________________
> >> rfc-interest mailing list
> >> rfc-interest at rfc-editor.org
> >> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> > _______________________________________________
> > rfc-interest mailing list
> > rfc-interest at rfc-editor.org
> > https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest