Re: [auth48] [AD] Re: [Ext] AUTH48: RFC-to-be 9121 <draft-davies-int-historic-05> for your review

[Warren Kumari <[e-mail]>]

On Fri, Apr 14, 2023 at 4:25 PM, Warren Kumari <[e-mail]> wrote:

> On Wed, Apr 12, 2023 at 4:16 PM, Karen Moore <[e-mail]> wrote:
>
>> Hello Tim, Kim, and *Warren (AD),
>>
>> Thank you for your replies. We have updated our files accordingly.
>>
>> *Warren, please let us know if you agree with changing RFC 1528 to
>> “obsoletes” (instead of “updates”) in the header of the document. The
>> update may be viewed below or in this file: https://www.rfc-editor.org/
>> authors/rfc9121-auth48diff.html
>>
>
>
> Erm, https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic/
>  says:
>
> draft-davies-int-historic <https://datatracker.ietf.org/doc/draft-davies-int-historic/> [RFC ED: Replace with RFC number] marks RFC 1528 <https://datatracker.ietf.org/doc/rfc1528/> andRFC 1706 <https://datatracker.ietf.org/doc/rfc1706/> as historic.
>
> Section 3.1 of draft-davies-int-historic <https://datatracker.ietf.org/doc/draft-davies-int-historic/> makes RFC 1528 <https://datatracker.ietf.org/doc/rfc1528/> historic:
>
>    The specification for tpc.int [RFC1528 <https://datatracker.ietf.org/doc/rfc1528/>] should be deemed historic as
>    it no longer functions as described in the document.
>
> Section 2.4 of draft-davies-int-historic <https://datatracker.ietf.org/doc/draft-davies-int-historic/> makes RFC 1706 <https://datatracker.ietf.org/doc/rfc1706/> historic:
>
>    The nsap.int domain name was specified to experimentally map Open
>    Systems Interconnection (OSI) Network Service Access Points to domain
>    names [RFC1706 <https://datatracker.ietf.org/doc/rfc1706/>].
>
> I'm not sure how the RFC Editor usually handles this — does the
> "triggering" document (this one) usually "Updates" or "Obsoletes" a
> document which is being made historic? I don't think that there is a tag
> for "Historicizes" (largely because I just made up the word!).
>


I tried to find previous example / precedent where an RFC marks things as
Historic (as opposed to the more common case of a status-change-document
doing the work).

RFC8996 was the example I found, and it "formally deprecates Transport
Layer Security (TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346).
Accordingly, those documents have been moved to Historic status."

Interestingly enough, it doesn't actually list RFC 2246 or RFC4346 in the
header at all.

Another example is RFC 8423:
"This document moves seven Informational RFCs to Historic status: RFCs
5759, 6239, 6318, 6379, 6380, 6403, and 6460.  In addition, it moves three
obsolete Informational RFCs to Historic status: RFCs 4869, 5008, and 5430."
RFC 8423 doesn't list any Updates or Obsoletes…

So, it looks like the "tradition" is to not list the documents which are
being made historic in the header — this feels very odd to me. I would have
figured that having some mention in the header makes sense (Updates or
Obsoletes, or even some other to be defined header), but perhaps I'm
missing something?

So, I really don't know what the right thing to do here is — I'm fine with
your proposal below, but I'm also fine with other suggestions.

W



> W
>
>
>> Old:
>> Request for Comments: 9121
>> Updates: 1528, 1706
>>
>> New:
>> Request for Comments: 9121
>> Obsoletes: 1528
>> Updates: 1706
>>
>> Rationale
>> [TW]:
>> I went different ways on this, but I can see this:
>> - Obsoletes 1526
>> - Historic 1706 (not sure if we obsolete old RR types but if we can/do
>> please let me know!)
>>
>> [KD]:
>> In line with Tim Wicinski's comment, we believe the document can obsolete
>> RFC 1528. RFC 1706, on the other hand, has specifications for DNS resource
>> records (RRs) that are not discussed in the text of this document. It would
>> seem logical to obsolete those RRs but there has been no discussion as to
>> whether they are used in other applications and we'd be reluctant to do so
>> without further consultation. it would also expand the scope of the
>> document beyond merely removing names from .INT. At this risk of
>> overcomplicating things, maybe that exercise is for a separate document.
>>
>> FILES
>>
>> The updated XML file is here:
>> https://www.rfc-editor.org/authors/rfc9121.xml
>>
>> The updated output files are here:
>> https://www.rfc-editor.org/authors/rfc9121.txt
>> https://www.rfc-editor.org/authors/rfc9121.pdf
>> https://www.rfc-editor.org/authors/rfc9121.html
>>
>> This diff file shows all changes made during AUTH48: https://www.
>> rfc-editor.org/authors/rfc9121-auth48diff.html
>>
>> This diff file shows all changes made to date:
>> https://www.rfc-editor.org/authors/rfc9121-diff.html
>>
>> Note that it may be necessary for you to refresh your browser to view the
>> most recent version. Please review the document carefully to ensure
>> satisfaction as we do not make changes once it has been published as an
>> RFC.
>>
>> Please contact us with any further updates or with your approval of the
>> document in its current form. We will await approvals from each author and
>> the AD prior to moving forward in the publication process.
>>
>> For the AUTH48 status of this document, please see: https://www.
>> rfc-editor.org/auth48/rfc9121
>>
>> Thank you,
>>
>> RFC Editor/kc
>>
>> On Apr 12, 2023, at 10:51 AM, Kim Davies <[e-mail]> wrote:
>>
>> Dear RFC Editor, Dear all,
>>
>> Amanda and I have reviewed the comments, see in-line below.
>>
>> Quoting [e-mail] on Tuesday April 04, 2023:
>>
>> 1) <!-- [rfced] As this document is moving RFCs 1528 and 1706 to
>> Historic, should it obsolete those RFCs (rather than update them)?
>>
>> Original:
>> Updates: 1528, 1706 (if approved)
>> -->
>>
>> In line with Tim Wicinski's comment, we believe the document can obsolete
>> RFC 1528. RFC 1706, on the other hand, has specifications for DNS resource
>> records (RRs) that are not discussed in the text of this document. It would
>> seem logical to obsolete those RRs but there has been no discussion as to
>> whether they are used in other applications and we'd be reluctant to do so
>> without further consultation. it would also expand the scope of the
>> document beyond merely removing names from .INT. At this risk of
>> overcomplicating things, maybe that exercise is for a separate document.
>>
>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
>> the title) for use on https://urldefense.com/v3/__https://www.rfc-editor.
>> org/
>> search__;!!PtGJab4!5makTXO9JpvAMHkFLu_3Xttfn6MJdEA8HRf-jOu66mlyKe6W-U88GjePpciB86He1iyH4DWRdCcUZbZPEM1KB8sWqbFeecI$
>> [rfc-editor[.]org]. -->
>>
>> The only suggestion we had was to list the domains being deprecated by
>> the document (e.g. "nsap.int"), but it appears that keywords cannot
>> contain periods therefore they cannot be expressed.
>>
>> 3) <!--- [rfced] Please note that we have updated this sentence as shown
>> below. Please let us know if any updates are needed.
>>
>> Original:
>> Any implementation
>> that involves these domains should be considered deprecated.
>>
>> Current:
>> Any implementations
>> that involve these domains are now deprecated.
>> -->
>>
>> The new text is OK.
>>
>> 4) <!-- [rfced] Section 4 (IANA Considerations) indicates that IANA has
>> removed the "historical 'int' domains". In addition, we received the
>> following message from IANA:
>>
>> nsap.int and tpc.int have been removed from the int zone. The other five
>> domains listed in Section 2 had already been removed.
>>
>> When verifying the actions via <https://www.iana.org/cgi-bin/intreg/
>> intreg.pl>, we found the following are already registered:
>> 2.2. ip4.int
>> 2.3. ip6.int
>>
>> Please review and let us know if any updates are needed.
>> -->
>>
>> No updates are needed. We intend to post "tombstone" entries in the IANA
>> WHOIS database with pointers to this RFC once published. All domains have
>> been removed from the DNS and thus are functionally deleted even with these
>> WHOIS entries.
>>
>> 5) <!-- [rfced] To simplify this sentence, please consider whether this
>> update correctly conveys the intended meaning.
>>
>> Original:
>> There are a small number of existing "int" domains nominally for
>> "international databases" that are not defined by any standards
>> documentation, and are assigned to entities rather than for an identifier
>> purpose.
>>
>> Perhaps:
>> There are a small number of nominal "int" domains for
>> "international databases" that are not defined by any standards
>> documentation. They are assigned to entities rather than for identifier
>> purposes.
>> -->
>>
>> The revised text is OK.
>>
>> 6) <!-- [rfced] We are having trouble parsing this sentence. The "while"
>> indicates a counter statement is coming. However, it seems the disposition
>> of the domains is out of scope for this document because they do not
>> qualify as "int" domains under current criteria. Please review.
>>
>> Original:
>> While they would not qualify for a "int" domain under current criteria,
>> their disposition is beyond the scope of this memo.
>>
>> Perhaps:
>> Because they do not qualify as "int" domains under current criteria,
>> their dispositions are beyond the scope of this memo.
>> -->
>>
>> The revised text is not correct. What we were trying to convey (along
>> with the previous text above) is they are beyond the scope of the memo
>> because they are not for identifier purposes, _even though_ they do not
>> qualify. RFC 1591 talks of "international databases" which was outmoded by
>> the mandate described in RFC 3172, but this memo only tries to clear up
>> allocations made for such applications that touched the IETF. The remaining
>> allocations don't have a nexus with the IETF and therefore we'll tidy up in
>> other ways via other mechanisms.
>>
>> We'd be OK with Tim's suggestion of simplifying the text as follows:
>>
>> OLD:
>> While they would not qualify for a "int" domain under current criteria,
>> their disposition is beyond the scope of this memo.
>>
>> NEW:
>> Their dispositions are beyond the scope of this memo.
>>
>> 7) <!-- [rfced] Please review the "Inclusive Language" portion of the
>> online Style Guide <https://urldefense.com/v3/__https://www.rfc-editor.
>> org/styleguide/part2/
>> *inclusive_language__;Iw!!PtGJab4!5makTXO9JpvAMHkFLu_3Xttfn6MJdEA8HRf-jOu66mlyKe6W-U88GjePpciB86He1iyH4DWRdCcUZbZPEM1KB8sW6-kCmrE$
>> [rfc-editor[.]org]> and let us know if any changes are needed.
>>
>> Note that our script did not flag any words in particular, but this
>> should still be reviewed as a best practice.
>> -->
>>
>> We could not identify any changes to address this area of concern.
>>
>> kim
>>
>>