RE: Guidelines suggested text for checklist:

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Please bear with me here, I'm attempting to track the state of the existing
and proposed text, as it is evolving in this discussion.

Given all the discussion, proposals and counter proposals, I suggest that a
straw-man draft be made available for additional review, prior to formally
submitting -01.

My comments, in-line, below, are flagged with "DBN:".

From the last paragraph of Section 3.1 (-00 draft):

   In particular, it is RECOMMENDED that RADIUS Attribute specifications
   allocate attributes from the vendor space, rather than requesting an
   allocation from the RADIUS standard attribute space, for attributes
   matching any of the following criteria:
      * attributes relying on data types not defined within RADIUS 
      * attributes intended primarily for use within an SDO
      * attributes intended primarily for use within a group of SDOs.

As proposed during discussion in this thread:

Suggested text:

   In particular, RADIUS Attribute specifications SHOULD allocate
   attributes from the vendor space, rather than requesting an
   allocation from the RADIUS standard attribute space, for attributes
   matching any of the following criteria:

      * attributes defined by vendors and not suitable for general use,
        as per [RFC2865] Section 5.26.

DBN: Clearly, yes.

      * attributes relying on data types not defined within RADIUS

DBN: To the extent that someone really needs to do this, given the existence
of the RADIUS Extended Attribute work, yes.

      * attributes intended primarily for use within an SDO
      * attributes intended primarily for use within a group of SDOs.

DBN: I think what we are saying here is that work not brought to the IETF
should not request IANA assignments.  We are implicitly reserving the
IANA-controlled standard RADIUS attribute ID space for use for work
published via the IETF, or by the Independent RFC-Editor Submission route.
If that is the case, perhaps we should say so in so many words.

   SDOs are encouraged to submit their RADIUS specifications to the IETF
   for publication as an informational RFC.

DBN:  If the SDOs have an open publication policy, whereby all interested
parties can obtain a copy of the relevant portions of these standards
documents, containing the description of RADIUS attributes, this would seem
redundant.  For example the IEEE, while restricting access to draft
standards and newly published standards, will typically make the MIB modules
from their works freely available in text format.

   Vendors defining Vendor-
   Specific dictionaries for their own use SHOULD make their
   specification publicly available, but there is no need to publish
   their specification as an RFC.

DBN:  Sure.

   All other specifications, including new authentication and/or
   security methods SHOULD be allocated via the standard RADIUS space,
   via "IETF Consensus" as noted in [RFC3575] Section 2.1.

From the proposed Section 3.1.3 (intended for the -01 draft):

3.1.3.  Publication of specifications

   SDOs are encouraged to seek review of VSA specifications by the IETF.
   Once reviewed, the specifications may be published as Informational
   RFCs.  This process should be followed instead of requesting IANA
   allocations from within the standard RADIUS attribute space.  Vendors
   wishing to make their specifications publicly available may also
   request publication of their VSA specifications as Informational RFCs
   by the IETF, instead of requesting IANA allocations for proprietary
   attributes

   All other specifications, including new authentication and/or
   security methods SHOULD be allocated via the standard RADIUS space,
   via "IETF Consensus" as noted in [RFC3575] Section 2.1.

DBN: Is this duplicate text, or is the text I've annotated above proposed to
be replaced by this text?

From the proposed Appendix A (intended for the -01 draft):

A.6. Allocation of attributes

   RADIUS attribute specifications SHOULD allocate attributes from the
   vendor space, rather than requesting an allocation from the RADIUS
   standard attribute space, for attributes matching any of the
   following criteria:

      * attributes relying on data types not defined within RADIUS
      * attributes intended primarily for use within an SDO
      * attributes intended primarily for use within a group of SDOs.

   Even if attributes are allocated from the vendor space, it is often
   useful for SDOs to publish the specification as an informational RFC,
   as with [RFC4679].

   Note that the first bullet point above relaxes many of the previous
   guidelines on data types, but only within a narrowly defined scope.

DBN:  What exactly do we mean here?  Why are we relaxing previously defined
guidelines and in what scope?

   Extensions to RADIUS that may not be appropriate for widespread use
   may be acceptable within a limited context.

DBN:  This sounds like the start of a slippery slope, especially for a BCP
document.  :-)

DBN:  I'm not sure that I can find the most recent text proposed for
Sections 3.1.1, 3.1.2 and 3.1.3.

DBN:  I think it would be useful, however, to insert somewhere among those
sections a bit of text that describes the "level of care" that is expected
for RADIUS attributes, encoded as VSAs, but intended for standardization in
non-IETF SDOs, for use by multiple vendors within an industry segment, or
within the global Internet community.  I would suggest that the design,
review and interoperability guidelines for any such VSAs (what I have called
SSAs) be the same as for full standard RADIUS attributes under IANA
allocation and IETF review.  The review mechanism would differ, but the
criteria should not.

DBN:  Without attempting to specify a particular section, let me suggest
some additional clarifying text:

	"In recognizing the utility of Vendor Specific Attributes (VSAs)
	for defining RADIUS extensions standardized in various SDOs, 
	for use by multiple vendors within an industry segment or within
	the global Internet community, it is important to make a 
	distinction in terms of the expected level of design guideline
	adherence and attention to interoperability considerations.
	The design and specification of VSAs for multi-vendor usages,
	by non-IETF SDOs, should be undertaken with the same level of 
	care as Standard RADIUS attributes.  Specifically, the provisions
	of this document that apply to Standard RADIUS attributes SHOULD
	apply to any such VSAs."

	"In this regard, the term Vendor Specific Attribute is perhaps
	unfortunate.  When used by an SDO, such an attribute is not 
	specific to any singe vendor.  It might be useful to think in 
	terms of two categories of VSAs, one for vendor proprietary 
	features and one for non-IETF standardization.  The latter 
	might be though of as an SDO-Specific Attribute (SSA), which
	just happens to use the same encoding format as the Vendor 
	Specific Attribute."


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>