> I suppose this draft could be published as documentation of existing > practice / fielded deployment, as an Informational RFC using the fielded VSA > assignments. Indeed, according to the Design Guidelines document, that is the *preferred* approach, since it maximizes interoperability with existing implementations. Of course, this raises the question whether the existing attributes are allocated in the IEEE 802 space (e.g. SDO-specific attributes), or in the Vendor-Space. However, in terms of the review process described in the Design Guidelines document, it does not matter. > Using Extended Attributes was my first choice but it is unfortunatelyGiven that this protocol has supposedly already been implemented by 2 vendors, why is the presence or absence of any feature within the Extended Attributes document relevant? Presumably a description of an existing implementation would be self-contained, not requiring a normative reference to any work-in-progress, assuming that the protocol is already implemented. > (it _is_ interesting that RFCs can be updated & made obsolete & What I don't understand is what "working group consensus" has to do with publishing documentation of an existing implementation. Presumably the only criteria governing would be whether the document actually describes what has been implemented. > These spurious claims can't avoid the fact that you haven't succeededThe "claims" in question here seem to have nothing whatever to do with the document under discussion in this thread: draft-zorn-radius-pkm1. So before we get drawn into a discussion of the validity of them, I'd first like to understand why they are even relevant. If the goal here is to publish documentation of an existing implementation of RADIUS attributes for IEEE 802.16a, then a request should be sent to the AAA-Doctors list for a review. Such a document need not become a RADEXT WG work item to be eligible for publication. Certainly that has not been the case for other such documents, most recently RFC 4679. |