Re: [apps-discuss] Missing IANA Considerations for TFTP

[Frank Ellermann <[e-mail]>]

On 22 August 2011 09:27, John C Klensin wrote:

> Historically, we rarely created IANA registries for protocol
> options unless we expected an ongoing series of added options.

Good.  Creating obscure IANA registries and expert review lists
before they are actually needed could be pointless, i.e., as
long as all interesting protocol parameters can be found in one
RFC.  And expert review lists not more working after years when
eventually somebody found something to register would be worse.

> As an example, the FTP registry created by RFC 5797 arguably
> should have been created when a formal extension mechanism was
> established in RFC 3659

Only four of five stars, because RFC 5797 does not mention the
registry URL.  But the RFC 3659 registry is a dubious example:
<URL:http://www.iana.org/assignments/os-specific-parameters>

> Because TFTP lacks even rudimentary, symbolic, security
> mechanisms, it is unsuited for use on the public Internet.

Maybe the TFTPS in the port registry was meant to improve it.
When a modern BIOS offers a "net boot" it *is* talking about
TFTP, or isn't it?  I'm not planning to implement or test it.

There is even a registered TFTP URI scheme in RFC 3617, and if
I understand RFC 3617 correctly it tried to *deprecate* TFTP
without actually doing it using pre STD 66 terminology.  But I
have an idea what happened, note to self, do not try to update
cram-md5 by scram-md5, or rather, don't try this in the IETF.

> If someone wanted to put in energy on TFTP today, I think
> that energy would be better spent in a good security analysis
> and set of recommendations as to how to use it safely.

"Security" is some IETF stuff that is deprecated before I begin
to grok what it was actually about, I try to avoid it unless it
is a nice test case for an MD5 test suite:  It can now emulate
RFC 2777, did you ever wish to check NomCom random selections
for the years before RFC 3797?  <gd&r>

-Frank