Hi, On 2011-1-18, at 16:32, Phillip Hallam-Baker wrote: > That would work IF the reason this is happening is that people don't > understand that unassigned means reserved for future assignment. that *is* the reason, for at least those cases that I have been involved in. > But I rather suspect that the reason that this is happening is that people > know full well that there is a process and choose to ignore it because they > either can't be bothered to put up with the hassle or don't think that the > application will be accepted. Suspect all you want, but it doesn't match my experience. > SRV code points are an even bigger mess because there isn't even a proper > registry to enter them in. We're very close to fixing this: http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports > I think it is rather more likely that the root cause here goes back to the > fact that the old three track standard process has broken down and the > criteria for acceptance as a PROPOSED standard are now essentially those for > DRAFT. RFC2026 has almost nothing to do with IANA allocation procedures. (The only relation is that some registries require a Standards Action, but even then it is irrelevant which level of the standards track the RFC is on. And yes, it's somewhat more difficult to have a Standards Action occur than passing the bar for the other RFC5226 policies, but then again, few registries actually need a Standards Action.) Lars
<<attachment: smime.p7s>>
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf