Did you consider that the IANA allocation policy for the two IANA values required by the document is "IETF Consensus"? The standards track status of the document doesn't matter then. What matters is if the registration meets "IETF Consensus", and the IESG decides this. I think the policies around what "IETF Consensus" means could be made more explicit, especially when it is applied to a document that itself do not require consensus to be published. I do think that the intention is clear, though, to be that registration should only be done if there is consensus in the IETF community that the IANA allocation should be done. /Simon RJ Atkinson <rja@xxxxxxxxxxxxxxxxxxx> writes: > Some important things that the FSF folks seem NOT to understand, > and frankly seem to aggressively NOT want to understand, are: > > - Many RFCs are *not* on the IETF standards track. > > - Any "Experimental RFC" is *not* on the IETF standards track. > So there is no "endorsement" by IETF in publishing such. > > - The IETF has published real standards-track documents that > required patented technology and were known to have > *difficult* license terms on the publication date (think > cryptographic algorithms and scan backwards in rfc-index.txt). > > - There is no history of IETF requiring technology to be freely > available (for either common definition of free). > > > I support the idea that virtually any document ought to be able > to be published as an Informational RFC or Experimental RFC. > Technology that is useful will be adopted if economically sensible, > whether in an RFC or not, whether made a formal standard or not. > By having an open specification, users can at least understand > the properties of the technology that is documented openly. > > Just to be crystal clear, I do support publishing draft-housley-* > as either Informational RFC or Experimental RFC. > > Yours, > > Ran > rja@xxxxxxxxxxxxxxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf