[rfc-i] obsoletes/updates

Brian E Carpenter brian.e.carpenter at gmail.com
Thu Jun 18 15:39:35 PDT 2015


On 19/06/2015 10:15, Andrew G. Malis wrote:
> John,
> 
> Is the replaced-by mechanism in the datatracker insufficient for what you
> want?

Two issues there:

1. It doesn't help a reader who isn't aware that the datatracker does this.

2. It is very incompletely implemented in the tracker. IMHO "replaces" should
be a field in the I-D submission tool, so that submitter can flag this status
seamlessly.

   Brian

> 
> Cheers,
> Andy
> 
> On Thu, Jun 18, 2015 at 12:53 PM, John C Klensin <john-ietf at jck.com> wrote:
> 
>>
>>
>> --On Thursday, June 18, 2015 08:30:53 +0200 Julian Reschke
>> <julian.reschke at gmx.de> wrote:
>>
>>> On 2015-06-17 22:51, Paul Hoffman wrote:
>>> ...
>>>> The most significant change in
>>>> this version is to give examples of the "updates" and
>>>> "obsoletes" attributes of <rfc>. In the same attributes,
>>>> removed the ability to say that an Internet-Draft updates or
>>>> obsoletes another Internet-Draft, based on RFC 2026. ...
>>>
>>> I think that's a regression.
>>>
>>> There are cases where a *draft* wants to say that it
>>> updates/obsoletes  another one, and there's no reason to
>>> forbid it. The situation for RFCs  is of course different.
>>
>> I'm usually quiet on this list (and rarely read it these days),
>> but I have to agree with both Julian and Paul (even though they
>> seem to be disagreeing with each other).
>>
>> An I-D really serves two purposes, as a working document for
>> development and discussion and, at least for a subset of I-Ds,
>> as a proto-RFC.    For the latter, including the tracking
>> information ("Obsoletes", "Updates") that would be associated
>> with the document if published as an RFC is very important for
>> both information and checking.   However, for the first
>> function, tracking for I-D relationships may, in some
>> circumstances, be equally important.  I hope we never get
>> pedantic and petty enough to want to see that
>> draft-foo-bar-baz-03 obsoleted draft-foo-bar-baz-02.  However,
>> as documents are consolidated and move in and out of WGs, having
>> a standard way to note, in an I-D (not just the tracker), that
>> draft-ietf-bar-baz-00 has replaced draft-foo-bar-baz-05 seems to
>> me to be very helpful, independent of how it is marked up and
>> presented.
>>
>>> As a matter of fact, this very draft shouldn't say "obsoletes:
>>> 2629" but  "obsoletes: draft-iab-xml2rfcv2".
>>
>> It is very unusual to have a document and its successor under
>> active development at the same time, but my vague memory is that
>> it has even happened with standards track protocol specs.
>> Certainly "obsoletes: draft-iab-xml2rfcv2" (or "obsoletes:
>> 2629bis" or even "obsoletes: 2629, draft-iab-xml2rfcv2") convey
>> a lot more information to those trying to understand what is
>> going on and how things should be reviewed than "obsoletes:
>> 2629". The latter, if draft-iab-xml2rfcv2 is published, will
>> simply be false.
>>
>> As a general principle for I-Ds, I believe we should be striving
>> for maximum communication and information content, even if
>> getting there requires temporarily doing things that the RFC
>> Editor would not allow in permanent/archival RFCs.
>>
>> best,
>>     john
>>
>> (back to intermittent lurking)
>>
>>
>>
>>
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest at rfc-editor.org
>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>>
> 
> 
> 
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> 


More information about the rfc-interest mailing list