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

[Warren Kumari <[e-mail]>]

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!).

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
>
>