[rfc-i] Feedback solicited: Update tags draft

stephen.farrell at cs.tcd.ie (Stephen Farrell) Thu, 27 February 2020 00:08 UTC

From: "stephen.farrell at cs.tcd.ie"
Date: Thu, 27 Feb 2020 00:08:27 +0000
Subject: [rfc-i] Feedback solicited: Update tags draft
In-Reply-To: <179BB23D-825A-4177-B656-1B396903C7D8@gmail.com>
References: <447718E1-D2EF-41B1-94DD-AB121EAA79BB@gmail.com> <179BB23D-825A-4177-B656-1B396903C7D8@gmail.com>
Message-ID: <1ed2a16b-3b0f-4783-4db6-bc354582c435@cs.tcd.ie>


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.

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
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x5AB2FAF17B172BEA.asc
Type: application/pgp-keys
Size: 10715 bytes
Desc: not available
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20200227/647170c1/attachment-0001.skr>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20200227/647170c1/attachment-0001.asc>