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

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 25 Oct 2021 18:51:09 +0200

Unfortunately there were no additional comments or any discussion on these issues I created below. Is there no interest in this anymore or is this maybe the wrong list to have this discussion?

Mirja

> On 13. Aug 2021, at 14:03, Mirja Kuehlewind <[email-masked]> 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
> [email-masked]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Oct 2021 14:41:53 -0400

Mirja Kuehlewind <[email-masked]> wrote:
    > Unfortunately there were no additional comments or any discussion on
    > these issues I created below. Is there no interest in this anymore or
    > is this maybe the wrong list to have this discussion?

I certainly missed your original query.
So yes, maybe wrong list.
I'd use gendispatch.

I'll go read your issues.

    >> 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.
    >>
    >> _______________________________________________ rfc-interest mailing
    >> list [email-masked]

    > _______________________________________________ rfc-interest mailing
    > list [email-masked]

---

From: Larry Masinter <[email-masked]>
Date: Mon, 25 Oct 2021 13:12:08 -0700

We already have links to other documents which are called out as "Normative" and "Informative".

If something is "see also", is that in lieu of adding it as an Informative Reference?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Oct 2021 16:52:42 -0400

> If something is "see also", is that in lieu of adding it as an

that works fine for backwards references.

When I have document RFCXXXX, and I write RFCXXXX+1 that says "See Also"
RFCXXXX, then that updates the meta-data on RFCXXXX to point -> XXXX+1.

Likely, RFCXXXX+1 references RFCXXXX normatively.
But not all normative references are See Also.

{For instance, back in 199x, I'd have expected TLS 1.0 to put a See Also
forward reference for HTTP/1.0.}

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

---

From: Larry Masinter <[email-masked]>
Date: Mon, 25 Oct 2021 14:44:05 -0700

> RFCXXXX, then that updates the meta-data on RFCXXXX to point -> XXXX+1.

"see also" has the reverse meaning. (reminds me of "go to" vs "come from").
These are cases where A "updates" B by inserting a "See Also A" into "B".

Still, by just adding these as another category of References, or an
"Updates" annotation on a Normative reference,  it gives you
a place to say more.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Oct 2021 11:06:04 +1300

Regards
    Brian Carpenter
    Thinking of the IETF standards process: https://xkcd.com/2530/

> So yes, maybe wrong list.

This is not necessarily an IETF issue, although it relates to some
standards track issues.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Oct 2021 11:08:13 +1300

Mirja,

I have no comments. I'd like this draft to advance ASAP, but I fear you may have to wait for the RSWG/RSAB to be operational.

Regards
    Brian

On 26-Oct-21 05:51, Mirja Kuehlewind wrote:
>> 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.