[radext] #30: Section 1.4

["radext issue tracker" <trac@tools.ietf.org>]

#30: Section 1.4
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@â            |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  minor                      |   Milestone:  milestone1
Component:  design                     |     Version:  1.0       
 Severity:  Submitted WG Document      |    Keywords:            
---------------------------------------+------------------------------------
 Material relating to reviews is included in various places within the
 document.  My recommendation is to delete Section 3.3.4 and to
 combine material relating to reviews into Section 1.4:

 1.4 Reviews

    For specifications utilizing attributes within the standards
    space, conformance with the design guidelines in this document
    is expected unless a good case can be made for an exception.
    Reviewers SHOULD use the design guidelines as a review
    checklist.

    While not required, IETF review may also be beneficial for
 specifications
    utilizing the Vendor-Specific space. Experience has shown that
 attributes
    not originally designed for general usage can subsequently garner
    wide-spread deployment.  An example is the vendor-specific attributes
    defined in [RFC2548], which have been widely implemented within
    IEEE 802.11 Access Points.

    In order to assist in the development of specifications
    conforming to these guidelines, authors can request review by
    sending email to the AAA Doctors [DOCTORS] or equivalent mailing list.
    The IETF Operations & Management Area Directors will then arrange for
    the review to be completed and posted to the AAA Doctors mailing list
    [DOCTORS], RADEXT WG mailing list, or other IETF mailing list.
    Since reviews are handled by volunteers, responses are provided on a
    best-effort basis, with no service level guarantees.  Authors are
    encouraged to seek review as early as possible, so as to
    avoid potential delays.

    In order to provide reviewers with access to the specification, vendors
    and SDOs are encouraged to make them publicly available.
    Where the RADIUS specification is embedded within a larger document
    which cannot be made public, the RADIUS attribute and value
    definitions can be made available on a public web site or can be
    published as an Informational RFC, as with [RFC4679].

    The review process requires neither allocation of attributes within
    the IETF standard attribute space nor publication of an IETF RFC.
    Requiring SDOs or vendors to rehost VSAs into the IETF standards
    attribute space solely for the purpose of obtaining review would put
    pressure on the standards space, and may be harmful to
    interoperability, since would create two ways to provision the same
    service.  Rehosting may also require changes to the RADIUS data model
    which will affect implementations that do not intend to support the
    SDO or vendor specifications.

    Similarly, vendors are encouraged to make their specifications
    publicly available, for maximum interoperability.  However, it is not
    necessary for a vendor to request publication of a VSA specification
    as an Informational RFC by the IETF.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/30>
radext <http://tools.ietf.org/radext/>


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