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

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 13 Aug 2021 14:03:10 +0200

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
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Robert Sparks <[email-masked]>
Date: Fri, 13 Aug 2021 09:00:30 -0500

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.

RjS

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Aug 2021 08:58:03 +1200

Robert, you say

> Instead of pursuing a change to the published metadata at this time,

It occurs to me that changing the *metadata* for a published RFC,
and changing it back at the end of an experiment, is not a problem.
But we can never change the text of a published RFC. It's unfortunate
that the current "Updates:" is both metadata and immutable text. Of
course, an "Update Considerations" section (and its evil twin
"Extension Considerations") would be part of the immutable text.

What is wrong with a pure metadata experiment, which is reversible?
Continue to use immutable "Updates" in the text, but split it into
two in the metadata?

Regards
   Brian Carpenter

>> 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).
>> 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.

---

From: Robert Sparks <[email-masked]>
Date: Fri, 13 Aug 2021 16:43:12 -0500

Inline.

> What is wrong with a pure metadata experiment, which is reversible?

Is it really? History in places that we put things on the web seems to 
matter.

If we were to create new document relationships in the datatracker or at 
the RFC editor's site, I expect a good bit of pushback on taking them 
away later.

But more importantly:

> two

I don't think we know that it's two...

So, do we _lose_ anything by trying to see if we can agree on what we 
mean in the prose first?

>   in the metadata?

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 13 Aug 2021 15:15:08 -0700

> 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

> > 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).
> >
> > 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.
> >

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 14 Aug 2021 02:02:07 +0200

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

-- 
---
[email-masked]

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 14 Aug 2021 11:17:58 +1000

Where does "the metadata" live?

If it's in the XML, it's immutable.

If it's in the published text and HTML but not in the XML, that implies that it's collected somewhere else, or it's truly ephemeral.

Just a thought: Maybe we should consider creating an IANA RFC metadata registry?

Cheers,

> On 14 Aug 2021, at 6:58 am, Brian E Carpenter <[email-masked]> wrote:
> 
> Robert, you say
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Larry Masinter <[email-masked]>
Date: Fri, 13 Aug 2021 18:20:31 -0700

Let me urge you to rethink your approach. I sympathize with the goal of clarity, but updating the RFC format is the last place to make updates (to the meaning of what 'updates' means.

It would be fine if the IETF / RFC Editor group were to add repositories with multiple, additional, external metadata, including categorization of the relationships between any subsets of RFCs, and tried to engage RFC authors and the IESG in experiments about what would be necessary to add clarity to the relation between documents beyond a few (confusing) bits.  

The problem is not the markup, it's that the actual, real situation is always ambiguous. If you add three possibilities a fourth and fifth will appear.

In the end, you're in a Humpty Dumpty world where a word means whatever it is that the people you care about think it means.

For fields in a form, for metadata standards, the bedrock is stability. You don't one set of documents that Updates mean one thing and another set where it doesn't. This is a long-standing problem in designing standard forms and standard ontologies.

---

From: Larry Masinter <[email-masked]>
Date: Fri, 13 Aug 2021 18:31:18 -0700

> Just a thought: Maybe we should consider creating an IANA RFC metadata

Why choose a standard when you can make your own?

Cf (using as an ironic but well intended reference, please click ) https://www.zotero.org/styles

--
https://LarryMasinter.net (Aka The Naysayer of Dublin)

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Aug 2021 15:09:55 +1200

> Where does "the metadata" live?

As far as I can tell, they live in https://www.rfc-editor.org/rfc/rfc-index.xml, and its companion /rfc-index.xsd, with a rendered version in /rfc-index.txt

You will see, for example, that <see-also> is already implemented. I think it would be ten minutes work to add the other suggestions in draft-kuehlewind-update-tag to the schema.

I do agree with Robert's argument that we need to experiment, but I don't 
want to see debris from the experiment in published RFCs. I would suggest 
doing an experimental enhancement of rfc-index.xml. Try it out first on say ten recent RFCs which contain "Updates:".

If that seems to work we could experiment with an RFC Metadata section in 
the final draft, to be deleted by the RFC Editor (like the Implementation 
Status section).
Apart from that, the IESG has been asking for years that drafts explain exactly what they update in earlier RFCs. This isn't really new at all; the only new bit would
be to clarify whether the update is Amends, Extends or occasionally See Also.

    Brian

P.S. Question to the RFC Editor: Is there a reason that https://www.rfc-editor.org/info/rfc29 does not show "See also: RFC 28"? RFC 29's meta-data 
include
 <see-also>
   <doc-id>RFC0028</doc-id>
 </see-also>

> If it's in the published text and HTML but not in the XML, that implies 
that it's collected somewhere else, or it's truly ephemeral.

>>>> 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.
>>>> 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

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 14 Aug 2021 13:51:01 +1000

That seems reasonable, although I'd think we shouldn't modify rfc-index.xml itself during an experiment, since many others are likely to rely upon that format.

Cheers,

> On 14 Aug 2021, at 1:09 pm, Brian E Carpenter <[email-masked]> wrote:
>

---

From: "John Levine" <[email-masked]>
Date: 14 Aug 2021 00:01:35 -0400

>As far as I can tell, they live in https://www.rfc-editor.org/rfc/rfc-index.xml, and its companion /rfc-index.xsd, with a rendered version in /rfc-index.txt

They actually live in a database maintained by the RPC.  Those two files are generated
by scripts from the database.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Aug 2021 16:11:46 +1200

> by scripts from the database.

That makes sense. It wouldn't prevent experimental variants of the xsd and xml, I suppose.

   Brian

---

From: Larry Masinter <[email-masked]>
Date: Fri, 13 Aug 2021 22:21:26 -0700

This is a road we've been down before: 
    https://www.w3.org/2001/tag/doc/versioning-html/
https://www.w3.org/2005/05/tr-versions
https://www.w3.org/2001/tag/2011/12/evolution/Overview.html

I think one might have more luck defining relationships between Standards STD n and Versions of them, and BCPs, which contain References to RFCs ( rather than between RFCs newer to older).  While RFC NNNN doesn't change STD MMM and BCP MMM can (and should).  You could experiment with more meta-data-driven relationships.    Probably you would have to define metadata for intent to update a Standard or BCP, especially when a Standard makes use of a RFCbis.

Larry
--
https://LarryMasinter.net https://interlisp.org

> -----Original Message-----
> From: rfc-interest <[email-masked]> On Behalf Of Mark
> Nottingham
> Sent: Friday, August 13, 2021 8:51 PM
> To: Brian E Carpenter <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [rfc-i] Next steps for draft-kuehlewind-update-tag
> 
> That seems reasonable, although I'd think we shouldn't modify rfc-index.xml
> itself during an experiment, since many others are likely to rely upon that
> format.
> 
> Cheers,
> 
> 
> > As far as I can tell, they live in
> > https://www.rfc-editor.org/rfc/rfc-index.xml, and its companion
> > /rfc-index.xsd, with a rendered version in /rfc-index.txt
> >
> > You will see, for example, that <see-also> is already implemented. I think it
> would be ten minutes work to add the other suggestions in draft-
> kuehlewind-update-tag to the schema.
> >
> > I do agree with Robert's argument that we need to experiment, but I
> > don't want to see debris from the experiment in published RFCs. I
> > would suggest doing an experimental enhancement of rfc-index.xml. Try it
> out first on say ten recent RFCs which contain "Updates:".
> >
> > If that seems to work we could experiment with an RFC Metadata section
> > in the final draft, to be deleted by the RFC Editor (like the
> > Implementation Status section).
> > Apart from that, the IESG has been asking for years that drafts
> > explain exactly what they update in earlier RFCs. This isn't really new at all;
> the only new bit would be to clarify whether the update is Amends, Extends
> or occasionally See Also.
> >
> >    Brian
> >
> > P.S. Question to the RFC Editor: Is there a reason that
> > https://www.rfc-editor.org/info/rfc29 does not show "See also: RFC
> > 28"? RFC 29's meta-data include <see-also>
> >   <doc-id>RFC0028</doc-id>
> > </see-also>
> >
> >
> >>
> >>> But we can never change the text of a published RFC. It's
> >>> unfortunate that the current "Updates:" is both metadata and
> >>> immutable text. Of course, an "Update Considerations" section (and
> >>> its evil twin "Extension Considerations") would be part of the immutable
> text.
> >>>
> >>>> I plan to put together a draft on this topic, but will not be able
> >>>> to
> > do
> >>>> 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
> >>>> 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.
> >>>>
> >>>> RjS
> >>>>
> >>> moving this discussion back to the rfc-interest mailing list (with
> gendispatch in bbc only for this initial information).
> >>>>>
> >>>>> 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 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
> >>>>> Please let us know if you have any thoughts and provide input on
> >>>>> these
> >>> issues by email or on GitHub!
> >>>>>
> >>>>> Mirja
> >>>>>
> >>>>>
> >>>>>
> >>>>>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 14 Aug 2021 11:45:20 -0400

> prose in that section says. If it turns out that the text to put there

I can live with this as a compromise.

I am happy with Extends, Amends and See Also.
If additional terms are needed, then great.
If these don't serve well, then we'll fix them.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Sat, 14 Aug 2021 12:00:57 -0400

> https://www.zotero.org/styles

I browsed through this, and I have no idea how it helps us.