Toerless, I've seen no evidence that nsap.int is used by anyone anywhere for anything. If there was any use for it, I'm sure it would have been migrated to nsap.arpa a long time ago. Regards Brian On 07-Apr-22 21:38, Toerless Eckert wrote:
[ Disclaimer: Cc some more mailing list in the hope that it would help to reach more technical and administrative contributors to the specific aspects asked for IETF than those who can afford to track an IETF wide list such as last-call.] 0. Confused I am really confused about the email, because the subject refers to making domain infrastructures historic, whereas the text asks for making RFCs historic. I am commenting on the ask to make RFCs historic. 1. RFC1706 from Informational to Historic (DNS NSAP Resource Records) Back in the 80th/90th when i was working on CLNP (and IAB until after Kobe too ? ;-)), i already found it quite difficult back then to figure out how much CLNP was actually used, and seemingly most use was in closed industrial environments, although those deployments sometimes even just used TP4 over Ethernet, but (AFAIR) still with NSAPs. My ability to vet if or how much CLNP or in a broader sense NSAP are in active use in any closed networks has not become better. Even less so any possible use of RFC1706. So, what to do in the absence of knowledge but often reconfirmed fear of unknown usage... ? 1.a) Given how CLNP/X.233 is to the best of my understanding an active/enforced standard at ISO/OSI and ITU-T, it would certainly be useful to consider bringing the suggested change to the attention of those SDO through our liaison mechanism. Any positive feedback from their side would be extremely helpful. Short of getting real insight into how relevant/irrelevant NSAP really are today in badly visible environment, i think we do not win anything by changing status from informational to historic. Instead, we are assuming that we know something. Which i think we don't. In which case we should just keep it as is. 1.b) Personally i am saying that i wish for RFC1706 not be moved to historic, because to me historic not only means not--used, but also technically-obsolete, and given how NSAP are variable length, IPv6 is not, and many proposals in the IETF have argued for variable length addressing at the network layer to better solve problems, my opinion is that we should move something like this only to historic when we have something equal or better. E.g.: after we have updated IPv6 to also support variable length addresses. 2.) RFC1528 from Experimental to Historic I am not aware of a better, interoperable standard solution for remote printing (or should i say Internet FAX ?). Instead it feels to me as if every printer vendor has started its own proprietary remote-printing cloud-service. I hope i am wrong (pointers please), but if not, then i fear this decade old experiment is still the best we have ? See 1.b) about arguing to changing status for something where there is no new evidence of there being something better and/or the mechanism being technically flawed (as opposed to just not being enough in the interest of vendors attempting to create monopolistic silos...) Cheers Toerless On Wed, Mar 30, 2022 at 02:18:07PM -0700, The IESG wrote:----- Please note: This is a second IETF LC. This isn't really a document (or at least a document that does anything). The "IESG Statement on Designating RFCs as Historic" (https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/ ) says that: "The current process, then, of moving an RFC to Historic status is to follow one of these, depending upon the level of documentation and discussion of the documentation required: 1: [...] 2: "An individual or a working group posts an Internet Draft containing an explanation of the reason for the status change. The I-D is discussed and iterated as usual for I-Ds. At some point, it is sent to an appropriate AD to request publication. The AD creates a status-change document, with an explanation that points to the I-D. The I-D and the status-change are then last-called together, after which the IESG evaluates and ballots on both." [...] 3: "As #2 above, except that the I-D might also contain other information. In this case, after IESG approval the I-D is sent to the RFC Editor. When the RFC is published, the status-change document is changed to point to the RFC instead of the I-D." [...] This last call is *just* for the status change document (https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic), which is just a supporting document for https://datatracker.ietf.org/doc/draft-davies-int-historic/ (which does the actual work and explains stuff). Basically, this is process-wonkey - please read https://datatracker.ietf.org/doc/draft-davies-int-historic/ instead, it's much more useful an interesting... ---- The IESG has received a request from an individual participant to make the following status changes: - RFC1706 from Informational to Historic (DNS NSAP Resource Records) - RFC1528 from Experimental to Historic (Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures) The supporting document for this request can be found here: https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic/ 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 last-call@xxxxxxxx mailing lists by 2022-04-27. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The affected documents can be obtained via https://datatracker.ietf.org/doc/rfc1706/ https://datatracker.ietf.org/doc/rfc1528/ IESG discussion of this request can be tracked via https://datatracker.ietf.org/doc/status-change-int-tlds-to-historic/ballot/ _______________________________________________ IETF-Announce mailing list IETF-Announce@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf-announce
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
