[rfc-i] Next steps for draft-kuehlewind-update-tag

Toerless Eckert tte at cs.fau.de
Fri Aug 13 17:02:07 PDT 2021


Certainly curious what Robert comes up with.

I think the most simple first step is just to start making explicit
suggestions for documents in IETF last-call with Update tags as to how
 one would like to see their "Updates" tag be explained in the text and hopefully
establish useful patterns. I certainly will try to come up
with good verbal explanations of the Updates on any drafts/RFC i'll co-author...

Cheers
    toerless

On Fri, Aug 13, 2021 at 03:15:08PM -0700, Eric Rescorla wrote:
> On Fri, Aug 13, 2021 at 7:00 AM Robert Sparks <rjsparks at nostrum.com> wrote:
> 
> > I plan to put together a draft on this topic, but will not be able to do
> > so until a couple of weeks from now. This is one of the things I
> > intended to say in that draft:
> >
> > Instead of pursuing a change to the published metadata at this time, I
> > strongly suggest focusing the experiment on whether the desired
> > improvement in clarity can be achieved with prose. For the first
> > experiment, add a "Updates Consideration" near the beginning to any
> > document that might have used the new tags whether it uses the Updates
> > tag or not. Have the IESG ensure there is IETF consensus on what the
> > prose in that section says. If it turns out that the text to put there
> > becomes obvious and is easy to mechanically create, then we know what we
> > need to do with the metadata. If we continue to have long discussions
> > during evaluation about what the section should say, we know we need to
> > do something more than pursue this particular classification scheme.
> >
> > I think running that for a year and reporting on what was learned would
> > be a great help to this conversation.
> >
> > To be clear, this only addresses one part of the problem that I think
> > really underlies the discomfort you are working to relieve. If your
> > initial reaction is "but nobody's going to see that section", you're
> > feeling one of the other problems. Working this one out first is important.
> >
> 
> As I mentioned previously, I think the right answer here is just to stop
> digging, but if people really feel we should do something, then what Robert
> suggested seems better than creating new metadata fields which we then have
> to argue over.
> 
> -Ekr
> 
> 
> > RjS
> >
> > On 8/13/21 7:03 AM, Mirja Kuehlewind wrote:
> > > Hi all,
> > >
> > > Based on the latest discussion at the gendispatch meeting, I’m moving
> > this discussion back to the rfc-interest mailing list (with gendispatch in
> > bbc only for this initial information).
> > >
> > > Also based on the discuss at the gendispatch meeting, I opened a couple
> > of issues on GitHub:
> > >
> > > #13 Run this as an experiment or propose as BCP?
> > > https://github.com/mirjak/draft-kuehlewind-update-tag/issues/13
> > >
> > > #14 Limit to IETF stream for now?
> > > https://github.com/mirjak/draft-kuehlewind-update-tag/issues/14
> > >
> > > #15 Do we need "see also”?
> > > https://github.com/mirjak/draft-kuehlewind-update-tag/issues/15
> > >
> > > #16 How many tags to use?
> > > https://github.com/mirjak/draft-kuehlewind-update-tag/issues/16
> > >
> > > Please klick on these links to see a bit more description for each
> > issue. Feel free to comment on GitHub or here by email. If you reply by
> > email, if possible please reply separately per issue and adjust the subject
> > line accordingly.
> > >
> > > The impression I got from the meeting, is that many/most people agree
> > that there is _a_ problem but there is a lot of different views how to
> > address it (see issue #16 above). I don’t think there is one best solution
> > at this point and as such this draft is proposing one of them as a way
> > forward.
> > >
> > > However, given there is no clear single path forward I also got the
> > impression that people would be more happy with starting an experiment
> > rather than picking one approach and go for BCP right away. How the
> > experiment might exactly look like needs a bit more work (see issue #13),
> > however, if people think that's the right way forward, I'm happy to work on
> > more details.
> > >
> > > If we run this an experiment, I think it actually could be nice to start
> > it now (and potentially only for the IETF stream; see issue #14) and then
> > reevaluate as soon as the new RFC editor model and another discussion venue
> > for these kind of works is in place.
> > >
> > > Please let us know if you have any thoughts and provide input on these
> > issues by email or on GitHub!
> > >
> > > Mirja
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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


-- 
---
tte at cs.fau.de


More information about the rfc-interest mailing list