Subject: Re: [Iotops] Last Call: Moving TPC.INT and NSAP.INT infrastructure domains to historic

From: Toerless Eckert <[email-masked]>
Date: Thu, 7 Apr 2022 11:38:04 +0200

[ 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
> [email-masked] mailing lists by 2022-04-27. Exceptionally, comments may
> be sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Michael Sweet <[email-masked]>
Date: Thu, 7 Apr 2022 10:11:45 -0400

Toerless,

> On Apr 7, 2022, at 5:38 AM, Toerless Eckert <[email-masked]> wrote:
> ...

I don't know if this was meant as serious?  But FWIW the IETF published the Internet Printing Protocol (STD 92) more than 2 decades ago, and it is used by nearly every network printer ("billions of printers") and most "cloud" printing services (including Microsoft's Azure-based Universal Print Service).  Any printer with "AirPrint", "IPP Everywhere", "Mopria", or "Wi-Fi Direct" on the box supports IPP.

The Printer Working Group (who is the current steward of IPP and the variable SNMP printing MIBs) has also defined numerous IPP extensions, including standards for cloud printing and Internet fax using a streamable subset of PDF.

So, assuming somebody doesn't just email you a file you can print it quite easily using a single, standard protocol.

[But of course telephone-based fax still hasn't died - boggles the mind...]

________________________
Michael Sweet

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Apr 2022 09:32:28 +1200

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

---

From: tom petch <[email-masked]>
Date: Fri, 8 Apr 2022 09:02:18 +0000

From: Int-area <[email-masked]> on behalf of Michael Sweet <msweet=[email-masked]>
Sent: 07 April 2022 15:11
Re: [Int-area] [Iotops] Last Call: Moving TPC.INT and NSAP.INT infrastructure domains to historic

Michael

I am well familiar with the work of IPP in the IETF.  You mention MIBs which I know of.  Is there anything similar in YANG?

Tom Petch

Toerless,

________________________
Michael Sweet

---

From: Michael Sweet <[email-masked]>
Date: Fri, 8 Apr 2022 09:23:15 -0400

Tom,

> On Apr 8, 2022, at 5:02 AM, tom petch <[email-masked]> wrote:
> 

Not that I am aware of, but doing a YANG model for IPP to allow configuration via NETCONF is certainly feasible - the IPP model and semantics are well insulated from the transport and implementation/encoding details.

In fact, the Printer Working Group spent quite a few years developing an XML schema for the IPP model and semantics (RFC 8011) and various printing MIBs, what is known collectively as the PWG Semantic Model.  However, its usage has been limited to bridging mechanisms with other vendor/standard printing models since IPP is generally able to work everywhere...

________________________
Michael Sweet