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

[Tim Wicinski <[e-mail]>]

Works for me

tim


On Fri, Apr 21, 2023 at 6:11 PM Karen Moore <[e-mail]> wrote:

> Hi Warren,
>
> Thank you for confirming. Our files reflect RFC 1528 as “Obsoletes” and
> RFC 1706 as “Updates”, and we have noted your approval of this change on
> the AUTH48 status page.
>
> We now await approvals from Kim and Tim before moving forward with
> publication.
>
> FILES (please refresh):
>
> 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
>
> For the AUTH48 status of this document, please see:
> https://www.rfc-editor.org/auth48/rfc9121
>
> Thank you,
>
> RFC Editor/kc
>
>
> > On Apr 21, 2023, at 2:15 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
> >
> > Old:
> > Request for Comments: 9121
> > Updates: 1528, 1706
> >
> > New:
> > Request for Comments: 9121
> > Obsoletes: 1528
> > Updates: 1706
> >
> >
> >
> > This works for me.
> >
> > Thank you!
> > W
>
>
> > On Apr 20, 2023, at 12:20 PM, Karen Moore <[e-mail]> wrote:
> >
> > 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
> >>
> >>
> >
>
>