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

[Mark Nottingham <[e-mail]>]

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 <[e-mail]> wrote:
> 
> On 14-Aug-21 13:17, Mark Nottingham wrote:
>> 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 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 <[e-mail]> wrote:
>>> 
>>> 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
>>> 
>>> On 14-Aug-21 02:00, Robert Sparks 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.
>>>> 
>>>> 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
>>>>> [e-mail]
>>>>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>>>> 
>>>> _______________________________________________
>>>> rfc-interest mailing list
>>>> [e-mail]
>>>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>>>> 
>>> 
>>> _______________________________________________
>>> rfc-interest mailing list
>>> [e-mail]
>>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>> 
> 

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

_______________________________________________
rfc-interest mailing list
[e-mail]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest