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

[Karen Moore <[e-mail]>]

Hi Warren,

From the RPC perspective, there is no requirement that a document be marked "Obsoleted by" when its status is changed to "Historic”.   We ask questions when the relationships are unclear, but the decision resides with the stream managers.  We agree it is nice to include updates/obsoletes where relevant - if someone looks up RFC 1528, they can easily see that it is historic and they are referred to the RFC that provides context.

Between obsoletes and updates, we suggest obsoletes if the entire document is now obsolete and updates if only a portion is outdated.  However, as noted this is ultimately a stream decision. 

Please review and confirm how the status for RFCs 1528 and 1706 should be listed.

Original:
    Request for Comments: 9121 
    Updates: 1528, 1706

Thank you.

RFC Editor/kc


> On Apr 18, 2023, at 7:38 AM, Warren Kumari <[e-mail]> wrote:
> 
> 
> 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 [RFC ED: Replace with RFC number] marks RFC 1528
>  and
> 
> RFC 1706
>  as historic.
> 
> Section 3.1 of 
> draft-davies-int-historic makes RFC 1528
>  historic:
> 
>    The specification for 
> tpc.int [RFC1528
> ] should be deemed historic as
>    it no longer functions as described in the document.
> 
> Section 2.4 of 
> draft-davies-int-historic makes RFC 1706
>  historic:
> 
>    The 
> nsap.int
>  domain name was specified to experimentally map Open
>    Systems Interconnection (OSI) Network Service Access Points to domain
>    names [
> 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
> 
>