Ralph,
Are you saying that the vendor community interprets registration delay
as damage, and routes around it?
Spencer
John - as a concrete example of the problem you describe, the dhc WG
perceived that there was a looming problem with exhaustion of the
DHCP
option code space. So, we wrote up a procedure (RFC 2939) requiring
documentation of new options in an RFC, implying technical review by
the
dhc WG. Now, we find a significant number of option codes in the
private code space (128-254), which have been unofficially
appropriated
for use in shipping products.
To clean up the mess, the dhc WG has enlarged the available option
code
space and is working through a process of identifying and
registering
the unofficially appropriated option codes (RFC 3942). I'll ask the
dhc
WG to review RFC 2939 in light of the expanded option code space and
our
experience with unofficial appropriation.
- Ralph
On Mon, 2005-06-27 at 06:32 -0400, John C Klensin wrote:
[...]
But, for the first, I'm getting more and more anxious about
rejecting a registration request. That is largely because, if
the applicant still feels that the idea is a good one, we've got
lots of unfortunate experience that he or she will just ignore
the registration requirement, squat on a code, and proceed as if
the allocation had been made. Worse, that applicant may not come
back and ask the next time, depriving the community of a
heads-up and the applicant of potentially-valuable IETF review.
[...]
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf