--On Tuesday, December 02, 2008 03:53:58 PM -0500 John C Klensin
<john-ietf(_at_)jck(_dot_)com> wrote:
--On Tuesday, 02 December, 2008 15:23 -0500 Ralph Droms
<rdroms(_at_)cisco(_dot_)com> wrote:
Sam - I think most of the issues in your review of
draft-raj-dhc-tftp-addr-option-04 can be resolved by reviewing
the purposes of RFC 3942 and publishing Informational RFCs
describing DHCP option codes. Fundamentally, the reason to
publish RFCs under the process described in RFC 3942 is to
document existing uses of option codes in the range of option
codes reclaimed for assignment to new DHCP options. The
concern is to avoid conflicts between new options and those
grandfathered ("hijacked") option codes. As such, these RFCs
(usually Informational) simply document the already
...
Responding to some of your specific points:
At the very least, I suggest mandating the use of DHCP Auth
and removing the suggestion to use option 66 to enhance
security. And, in the absence of a more data about how
widely used this option is, I suggest not publishing this
document at all.
The consensus of the dhc WG, to which I concur, is to publish
the document as Informational. The text in the Security
Considerations section about option 66 might be removed.
...
To reiterate, it's not so much a question of whether a new
code point is needed; rather, according to the procedures
described in RFC 3942, this document gives a description of an
existing use of option code 150. That option code is in use
...
Ralph,
It seems to me that there is a middle ground here. One can
stick with Informational publication as the WG intends, but
still modify the Security Considerations section, not only to
remove the reference to option 66 (if there is consensus that is
appropriate) but to add some explanation about why the use of
this option without authentication might be problematic.
Put differently, your objection to Sam's suggestion seems to
hinge on "just describe the existing practice, don't try to
change it in this document". Given RFC 3492, that is entirely
reasonable. But, if there are relatively obvious difficulties
with that practice, it seems to me that documenting them would
be helpful (indeed that not doing so borders on irresponsible).
I'm inclined to agree with John here.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf