[rfc-i] rfc-interest Digest, Vol 196, Issue 22
daedulus at btconnect.com
Wed Feb 24 02:12:55 PST 2021
On 23/02/2021 17:15, John C Klensin wrote:
> Let me distinguish between two types of use contexts:
> (1) Trying to find relevant I-Ds, working with I-Ds, trying to
> build new documents, and so on. While there are design issues
> and matters of taste we could quibble about and debate endlessly
> (the issue of whether the home page for an I-D should show a
> page or two or the current /latest version or the whole thing is
> probably a good example). For me, apparently like you, the
> current datatracker setup is entirely satisfactory for that
> purpose. Moreover, even about those matters of taste that were
> decided in a way that does not match my preferences, I worry a
> bit about improvements because I'm used to doing things the way
> they are now and making things better might me extra work to
> readjust those habits. There are also things that I think
> would make it lots better. For example, I wish the IESG would
> strongly encourage a "Changes since the last version" appendix
> and that the datatracker would pick that information up and show
> the subsection for the most recent version on that first page --
> far more useful than the complete document, which is only a
> click away in any of several formats.
> (2) References from RFCs. These need to be, at least by
> default, exact. The flexibilities that are an advantage with
> the above can be a liability here. Why? Because it is not
> unusual for the substantive content of an I-D to change as work
> evolves and consensus emerges (or doesn't). If, for example,
> version NN of an I-D said "the outside of the bikeshed MUST be
> painted blue", version NN+1 said "the outside of the bikeshed
> MUST be painted lime green" and explained why, it would be very
> important if an RFC that referenced it for color choices point
> to the version the RFC's author intended and not some other
> version. Would it be important for the reader to find out that
> there is a later version in which things might have changed?
> Sometimes, but only the document author is likely to know.
I agree - references must be exact and must be preserved ad inf. I had
not picked up a suggestion, starting with Julian's original post, that
this was not the case, or about not to be the case. Both the styles of
reference he quotes have the version and date. And if I go to tools,
then the link takes me to the relevant version.
I agree absolutely about the value of a 'Changes' section. There is a
200pp I-D teas-yang-te which provides a framework for other routing I-D
to update, typically as 100 or so free-standing updates, although most
individual updates conform a small number of templates. (As one AD
commented, if teas-te were different, it would save a lot of work - I
suspect that the authors of teas-yang-te did not look ahead at the
consequences of their chosen structure). But more, teas-yang-te has
undergone several revolutions rendering all updating I-D invalid; one
such came in at revision 23, so any reference to -22 or earlier will be
technically valid but tells me that the referring I-D is useless. -26
has just been announced, no 'Changes', no email about differences, no
response to my e-mail asking what is different. Sigh. (-25 did contain
a technical flaw that passed unnoticed for many years and made it
unusable and that has been fixed)
Oddly, on tools v datatracker, tools tells me that teas-yang-rsvp-te is
up to -08 and references teas-te-22 ie is useless, while datatracker
tells me that teas-yang-rsvp-te is up to -09 and references
teas-yang-te-25 ie may or may not be useless depending on what is in -26.
And some wonder why I like datatracker!
> --On Tuesday, February 23, 2021 12:16 +0000 tom petch
> <daedulus at btconnect.com> wrote:
>> On 23/02/2021 03:41, John C Klensin wrote:
>>> --On Tuesday, February 23, 2021 01:39 +0100 Carsten Bormann
>>> <cabo at tzi.org> wrote:
>>>>> I am having trouble completely picturing just what you have
>>>>> in mind, but, whatever you do, please keep in mind that
>>>>> references from RFCs are supposed to be completely stable.
>>>>> That means that, if I, as author, reference
>>>>> draft-foo-bar-baz-03 at the time of RFC publication,
>>>>> wherever the link points should produce
>>>>> draft-foo-bar-baz-03 and not its most recent successor,
>>>>> whether that is
>>>>> draft-foo-bar-baz-15 or RFC 9999.
>>>> Yes, but the landing page for -03 could have pointers to
>>>> newer versions (I-D, RFC, Obsoleting RFC, …).
>>> I have no problem with that as long as the landing page
>>> unambiguously gets the reader to -03. The current datatracker
>>> page for a draft does not have that property -- one gets a
>>> multiversion page that shows the most recent one and then has
>>> to figure out how to navigate back to a particular version.
>> For me, the datatracker page that I get to from a datatracker
>> WG page has the metadata that I need to work, whereas the
>> tools page is sadly lacking in that regard. Yes, there is
>> less metadata but I need that missing metadata so leaving it
>> out is counter-productive.
>> Also, from https://datatracker.ietf.org/doc/<i-d name> I get
>> what is to me a clear display of the document history from
>> which I can navigate to (almost) any earlier version. I am
>> puzzled that there should be any difficulty in clicking on the
>> green or purple bar to select a different version (except when
>> the submissions window is closing and authors submit three
>> versions in under 24 hours and the bars shrink to zero).
>> I think that the datatracker took a giant leap forward at some
>> point from being unusable to being the best way into the work
>> of the IETF so my home page became Active WGs. I often want to
>> return there so that having the nav bar is most useful.
>> Tom Petch
>>>>> This is, of course a
>>>>> cousin of whether a new I-D or RFC should be referencing the
>>>>> same target RFC as the document it is replacing or should be
>>>>> referencing the most recent update/replacement for that
>>>>> earlier version. In both cases, heuristics will frequently
>>>>> be wrong. It might actually be useful for authors to be able
>>>>> to specify "the version we specified, really" versus "most
>>>>> recent version" in markup.
>>>> Which you already can do in the source for an I-D. RFC
>>>> references are frozen, though.
>>> I probably missed how to do that in I-Ds referencing I-Ds
>>> after I got frustrated many years ago with automated handling
>>> of them and just started typing them in.
>>>>> I'm even a little hesitant about your pointing to the HTML
>>>>> version as long as at least some of the html versions are
>>>>> synthesized from the text rather than being supplied by
>>>>> authors (who have presumably checked them) or generated from
>>>>> xml2rfc v3 (which is presumably infallible). The synthesis
>>>>> process doesn't make serious errors very often, but, in my
>>>>> experience, it does make them.
>>>> This could easily be fixed.
>>>> I did a PoC for that a while ago.
>>>> The data collection for the fixer does need some effort; this
>>>> could be crowd-sourced or done proactively (probably more
>>>> expensive than we care about this problem).
>>> Personally, I'd much rather see any spare energy in the short
>>> term concentrated on fixing things like indexes.
>>> rfc-interest mailing list
>>> rfc-interest at rfc-editor.org
More information about the rfc-interest