RE: Guidelines suggested text for checklist:

["David B. Nelson" <d.b.nelson@comcast.net>]

Bernard Aboba writes...

> IANA assignments are governed by RFC 3575, not anything in this
> document (which is only a BCP).
>
> The issue is whether an SDO (or vendor) requesting IETF review 
> should be required to re-host their attributes into the IETF 
> standards space.  The answer should be "no" -- IETF review is 
> orthogonal to IANA allocation policy.

The term "re-host" assumes that there is an already initial hosting in VSA
space.  While that may often be the case, especially if the work is
standardizing something already deployed by one or more vendors, it may not
be the case if it is new work.  My issue is whether other SDOs are to be
advised to "stay away" from the IETF process and seeking RFC 3575
allocations, when no previous VSA allocation exists.  Nothing in RFC 3575
says that today.  SDOs are presumably free to seek IETF Consensus for IANA
assignments.

> In terms of public availability, the main issue is that the IETF 
> cannot review a document that is not made available to it.  So the
> train of logic here is:
> 
> * The SDO wants their document reviewed by the IETF.
> * To get IETF review, the SDO needs to make the document available 
> to the reviewers.
> * One way to make the document available for wide review is to make it
> openly available, either on the SDO site, or by publishing it as an I-D
> (and eventually, RFC).

There's more to this issue that IETF review.  There's the issue of open
availability for implementers.  Some "country club SDOs" (no, I don't mean
the IEEE) only allow members to get standards, or don't have any program for
free access.  That may be a reason to want to re-publish work as an RFC,
just to make the full collection of RADIUS attributes freely available.




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