[ 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
