Re: Guidelines suggested text for checklist:

[Alan DeKok <aland@nitros9.org>]

David B. Nelson wrote:
> 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.

  I'll put it online, and post a URL separately.

>       * 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.

  Yes.  Suggested text:

   Vendors and SDOs are reminded that the standard RADIUS attribute ID
   space, and the enumerated value space for enumerated attributes, are
   reserved for allocation through work published via the IETF, as noted
   in [RFC3575] Section 2.1.  Some vendors and SDOs have historically
   performed self-allocation by assigning vendor-specific meaning to
   "unused" values from the standard RADIUS attribute ID or enumerated
   value space.  This practice MUST NOT be followed.  The IETF process
   discussed above MUST be used instead for allocations from the
   standard spaces.

> 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.

  Good point.

...
>    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?

  I've re-arranged it so that vendors and SDO's have their own sections,
as the guidelines were diverging slightly for them.  As such, some text
is duplicated, with minor edits.  This should be clearer once I post a
proposed draft.

>    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?

  I'll post the draft, which will make this clear.

>    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.  :-)

  It's a recognition that site-specific nonsense has a limited scope.

> 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.

  I'll post the draft.

> 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.

  I agree.

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

  OK.  I'll word smith it and integrate it in.

  While I like the term SSA, I'm not sure introducing another acronym
here would help.

  I'll do another pass over the document for consistency and flow of
thought, then post a URL to this list.

  Alan DeKok.


--
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/>