Subject: [rfc-i] should a bis document obsoleting a document, inherit its Updates: ?

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Feb 2019 14:11:31 -0500 (EST)

Hi,

Is this the correct procedure? Should draft-ietf-dnsop-algorithm-update
which is obsoleting 6944 adopt all the Updates: from 6944 ?

Paul

---------- Forwarded message ----------
Date: Mon, 18 Feb 2019 12:05:29
From: Mats Dufberg <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-algorithm-update-05.txt>
     (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to
     Proposed Standard

If this draft is approved, the new RFC will obsolete RFC 6944. RFC 6944, in turn, updates eight other RFCs. As I interpret it, the new RFC will inherit that role. I think that should be explicitly stated in the new RFC.

Yours,
Mats

---
Mats Dufberg
DNS Specialist, IIS
Mobile: +46 73 065 3899
https://www.iis.se/en/

-----Original Message-----
From: DNSOP <[email-masked]> on behalf of The IESG <[email-masked]>
Reply-To: "[email-masked]" <[email-masked]>
Date: Wednesday, 13 February 2019 at 20:30
To: IETF-Announce <[email-masked]>
Cc: Tim Wicinski <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [DNSOP] Last Call: <draft-ietf-dnsop-algorithm-update-05.txt> (Algorithm Implementation Requirements and Usage Guidance for DNSSEC) to Proposed Standard

     The IESG has received a request from the Domain Name System Operations WG
     (dnsop) to consider the following document: - 'Algorithm Implementation
     Requirements and Usage Guidance for DNSSEC'
       <draft-ietf-dnsop-algorithm-update-05.txt> as Proposed Standard

     The IESG plans to make a decision in the next few weeks, and solicits final
     comments on this action. Please send substantive comments to the
     [email-masked] mailing lists by 2019-02-27. Exceptionally, comments may be
     sent to [email-masked] instead. In either case, please retain the beginning of
     the Subject line to allow automated sorting.

     Abstract

        The DNSSEC protocol makes use of various cryptographic algorithms in
        order to provide authentication of DNS data and proof of non-
        existence.  To ensure interoperability between DNS resolvers and DNS
        authoritative servers, it is necessary to specify a set of algorithm
        implementation requirements and usage guidelines to ensure that there
        is at least one algorithm that all implementations support.  This
        document defines the current algorithm implementation requirements
        and usage guidance for DNSSEC.  This document obsoletes [RFC6944].

     The file can be obtained via
     https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/

     IESG discussion can be tracked via
     https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update/ballot/

     No IPR declarations have been submitted directly on this I-D.

     _______________________________________________
     DNSOP mailing list
     [email-masked]
     https://www.ietf.org/mailman/listinfo/dnsop

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Feb 2019 11:32:53 +1300

> which is obsoleting 6944 adopt all the Updates: from 6944 ?

afaik that would be a precedent. A reader of the older RFCs
should in theory be redirected to RFC6944 and then redirected
again to dnsop-algorithm-update.

Here's a recent case that is similar but different:

7550 Issues and Recommendations with Multiple Stateful DHCPv6 Options. O.
     Troan, B. Volz, M. Siodelski. May 2015. (Format: TXT=54206 bytes)
     (Obsoleted by RFC8415) (Updates RFC3315, RFC3633) (Status: PROPOSED
     STANDARD) (DOI: 10.17487/RFC7550)

8415 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). T. Mrugalski,
     M. Siodelski, B. Volz, A. Yourtchenko, M. Richardson, S. Jiang, T.
     Lemon, T. Winters. November 2018. (Format: TXT=370298 bytes)
     (Obsoletes RFC3315, RFC3633, RFC3736, RFC4242, RFC7083, RFC7283,
     RFC7550) (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC8415)

In this case they *obsoleted* the older documents, presumably for cause.

Here's a more relevant case:

7180 Transparent Interconnection of Lots of Links (TRILL):
     Clarifications, Corrections, and Updates. D. Eastlake 3rd, M. Zhang,
     A. Ghanwani, V. Manral, A. Banerjee. May 2014. (Format: TXT=56276
     bytes) (Obsoleted by RFC7780) (Updates RFC6325, RFC6327, RFC6439)
     (Status: PROPOSED STANDARD) (DOI: 10.17487/RFC7180)

7780 Transparent Interconnection of Lots of Links (TRILL):
     Clarifications, Corrections, and Updates. D. Eastlake 3rd, M. Zhang,
     R. Perlman, A. Banerjee, A. Ghanwani, S. Gupta. February 2016.
     (Format: TXT=125037 bytes) (Obsoletes RFC7180) (Updates RFC6325,
     RFC7177, RFC7179) (Updated by RFC8249) (Status: PROPOSED STANDARD)
     (DOI: 10.17487/RFC7780) 

See what they did there? They updated only *one *of the older RFCs,
but I don't know why.

Anyway - IMHO if the new document explicitly updates the old ones
*in a new way* they should be listed. But if all it does is rely on
the updates made previously, no.

If anyone's interested, I've attached a complete list of RFCs that
carry both "Updates" and "Obsoleted by" tags. The Python program that
made the list is available on request.

    Brian