RE: Operations Directorate Review of draft-ietf-radext-design-18

[<lionel.morand@orange-ftgroup.com>]

Hi Alan,

Thanks for your prompt answer. And thank you for taking account my comment.
I have no problem with the proposed answer.

About re-organizing the doc, I understand your concerns.

Regards,

Lionel  

> -----Message d'origine-----
> De : Alan T DeKok [mailto:aland@freeradius.org] 
> Envoyé : mercredi 27 octobre 2010 14:54
> À : MORAND Lionel RD-CORE-ISS
> Cc : ops-dir@ietf.org; gdweber@gmail.com; 'radext mailing list'
> Objet : Re: Operations Directorate Review of 
> draft-ietf-radext-design-18
> 
> lionel.morand@orange-ftgroup.com wrote:
> > I reviewed the document draft-ietf-radext-design-18 and here is my 
> > feedback.
> ...
> > I found this draft OK. Authors and reviewers have tried to provide 
> > clear statements and recommendations regarding the RADIUS attribute 
> > design. I can only regret that the recommendations are 
> spread all over 
> > the document and it is quite difficult to find them if you are not 
> > reading the whole doucment.
> 
>   Appendix A outlines the recommendations in detail, and in a 
> short form.  We can add text at the start which points to the 
> appendix as a simple set of the recommendations.
> 
> >    This document provides guidelines for the design of RADIUS 
> > attributes
> > 
> > [LM] RADIUS acronym can be expended at this stage, instead 
> of doing it 
> > later. [LM]
> 
>   OK.
> 
> > [LM] s/will used/will be used [LM]
> 
>   Fixes.
> 
> > standard space
> >      RADIUS attributes which are allocated by IANA and 
> which follow the
> >      format defined in RFC 2865 [RFC2865] Section 5.
> > 
> > [LM] Comment: instead of speaking of attributes, we should 
> speak about 
> > codes allocated from the standard/vendor space. [LM]
> 
>   OK.
> 
> 
> >    The advice in this document applies to attributes used to encode
> > 
> > [LM] s/applies to attributes/applies to RADIUS attributes [LM]
> 
>   That should be implicit, but OK.
> 
> > [LM] s/standards space/standard space [LM]
> 
>   Fixed here, and elsewhere.
> 
> >    Note that the RADEXT WG is currently (as of 2010) involved in
> >    developing updates to RADIUS.  Those updates will 
> provide their own
> >    usage guidelines that may "override" some of the 
> guidelines discussed
> >    here.
> > 
> > [LM] comment: this part is a little bit tricky. It is said at the 
> > beginning that this document should be used as guidelines, 
> especially 
> > for standard code allocation, while it is said right after that the 
> > existing work could "override" some of the statements 
> encapuslated in 
> > this BCP. Is "override" the right wording here? I mean, do 
> you foresee 
> > any possible 'conflict' or it is just to say that some guidelines 
> > introduced by new documents miht not be covered by this BCP? Some 
> > clarification text may be useful [LM]
> 
>   OK.  I think "modify" is a better work than "over-ride".  
> Adding an example like "such as adding new data types" should 
> be a good clarification.
> 
> >    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.
> > 
> > [LM] why just a "SHOULD" here, when speaking about standard 
> space? The 
> > use of this checlinst can be made required in the IETF 
> process, except 
> > if it is out of scope of BCP. Mandate the use of this 
> checklist does 
> > not mean that we mandate to follow scrupulously all the guidelines. 
> > [LM]
> 
>   The document is a BCP, and can't require modifications to 
> the IETF process.
> 
> >    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.
> > 
> > [LM] I failded to see the link between this BCP and an IETF 
> review of 
> > vendor specific attributes. What would be the added value 
> of an IETF 
> > review if vendors/SDOs are following the guidelines of this BCP?
> 
>   If the SDOs are doing something which has wider use, the 
> review might suggest to do the work within the IETF, rather 
> than within the SDO.
> 
> >    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.
> > 
> > [LM] the main part of this text details the process for an 
> IETF review.
> > As expressed above, the link of this process and the present BCP is 
> > not obvious. It even seems quite contradictory. [LM]
> 
>   It suggest reviews are good, but not mandatory.
> 
> > 2.  Guidelines
> > 
> >    The Remote Authentication Dial In User Service (RADIUS) 
> defined in
> > 
> > [LM] see comment in Introduction reagrding RADIUS acronym expansion 
> > [LM]
> 
>   OK.
> 
> > [LM] RADIUS design decision we/RADIUS design decision, we [LM]
> 
>   OK.
> 
> > [LM] s/defined in Section 2.1,/defined in Section 2.1 of this 
> > document, [LM]
> 
>   OK.
> 
> >    [RFC2865] RADIUS VSA.  All other data formats are 
> "complex types".
> > 
> > [LM] in section 3.2.3, complex data type is characherized as 
> > attributes with multiple sub-fields into the
> >    "Value" field. Should we reflect this point at this stage, when 
> > defining the two kinds of data types? [LM]
> 
>   No.  The text in 3.2.3 gives an *example* of a complex 
> type.  It shouldn't be construed as defining what a complex type is.
> 
> > [LM] s/this situation..  Code-point/this situation.  Code-point [LM]
> 
>   OK.
> 
> >       * Attributes that are of broad interest to the 
> Internet Community.
> >         Multi-vendor interoperability is expected.
> > 
> > [LM] I think that if it is foro Internet Community, 
> interoperability 
> > is required and not "expected" [LM]
> 
>   Sure... but we can't require that in a BCO.
> 
> > [LM] we should not speak about "self-allocation" but use of code 
> > values reserved for standard attributes. [LM]
> 
>   OK.
> 
> >       * Enumerated data types, represented as a 32-bit 
> unsigned integer
> >         with a list of name to value mappings.  (e.g. Service-Type)
> > 
> > [LM] why a specific example here? [LM]
> 
>   Because it makes it clearer...?
> 
> > [LM] s/their own Attributes/their own attributes [LM]
> 
>   OK.
> 
> > [LM] s/allocation (or self-allocating) from/allocation from [LM]
> 
>   OK.
> 
> >    It is therefore NOT RECOMMENDED that specifications 
> intended solely
> >    for use by a vendor or SDO use be translated into the 
> standard space.
> > 
> > [LM] It would be maybe useful to summarize the set of 
> recommendations 
> > in a dedicated sub-section at the end of this chapter. It could be 
> > done through a table listing the recommendations and a reference to 
> > the section in which the recommendation is explained. This 
> table could 
> > help reviewer, along with the checking list provided in Annex. [LM]
> 
>   That's already done in Appendix A.  I don't think we need 
> to repeat it here.
> 
> > 3.  Rationale
> > 
> >    This section outlines the rationale behind the above 
> recommendations.
> > 
> > [skip]
> > 
> > [LM] I would suggest to split the whole section on multiple 
> > sub-sections dedicated to a single point concluded by a 
> recommendation 
> > [LM]
> 
>   I disagree.  The first sentence clearly says 
> "recommendations are given above".  Repeating them here is awkward.
> 
>   The WG went through 3-4 complete re-organizations of the document.
> The form it's in now was judged to the the simplest of the 
> alternatives, including the one you're proposing here.
> 
> > [LM] and this has lead/and this has led [LM]
> 
>   OK.
> 
> >    Subsequent RADIUS specifications defined attributes by using type
> >    names not defined in [RFC2865], without defining the new 
> names as was
> >    done in [RFC2865].  They did not consistently indicate 
> the format 
> > of
> > 
> > [LM] either "names as it was done" or "names as done" [LM]
> 
>   "names as done" seems clearer.
> 
> >    In other cases, the data in the complex type are 
> described textually.
> >    This is possible because the data types are not sent within the
> >    attributes, but are a matter for endpoint interpretation.  An
> >    implementation can define additional data types, and use 
> these data
> >    types today by matching them to the attribute's textual 
> description.
> > 
> > [LM] an example could help to understand the paragraph above [LM]
> 
>   OK.  I'll work on something.
> 
> > 3.3.1.  Interoperability Considerations
> > 
> >    Vendors and SDOs are reminded that the standard RADIUS attribute
> >    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 in the past
> >    performed self-allocation by assigning vendor-specific meaning to
> >    "unused" values from the standard RADIUS attribute ID or 
> enumerated
> >    value space.  This self-allocation results in interoperability
> >    issues, and is counter-productive.  Similarly, the 
> Vendor-Specific
> >    enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT
> >    RECOMMENDED.
> > 
> > [LM] here it is exactly why I'm relunctant to speak about 
> > self-allocation. Values from the standard space are not formally 
> > allocated but used by vendors/SDOs. Self-allocation would mean that 
> > you can decide on your own to allocate standard values to 
> non-standard 
> > attributes and that theses values would be considered by IETF as 
> > already allocated, that is not the case here. If it was the case, 
> > there will be no interoperability issue, only a problem of 
> standard value exhaustion.
> > As I said, what it is not recommended is to use values from the 
> > standard space without official IETF allocation. [LM]
> 
>   OK.  I'll re-word it to remove the "self-allocation" text.
> 
> >    If it is not possible to follow the IETF process, 
> vendors and SDOs
> >    SHOULD self-allocate an attribute, which MUST be in 
> vendor space, as
> >    discussed in Sections 3.3.2 and 3.3.3, below.
> > 
> > [LM] just a note: vendors and SDOs do not share the same 
> vendor space 
> > and vendors are not encouraged to pick values in the SDO 
> vendor space.
> > [LM]
> 
>   Hmm... OK.    It could say "MUST be in their own vendor space".
> 
> > [LM] s/requesting a PEC/requesting a PEN [LM]
> 
>   OK.
> 
> > [LM] s/As a result. pre-existing/As a result, pre-existing [LM]
> 
>   OK.
> 
> >    in Appendix B MAY be used.
> > 
> > [skip]
> > 
> > A.2.2. More Complex Data Types
> > 
> >    Does the attribute:
> > 
> >    * define a complex data type not described in Appendix B,
> > 
> > [LM] s/Appendix B,/Appendix B? [LM]
> > 
> 
>   I disagree.  The text is part of a run-on sentence which 
> continues to the next bullet point.
> 
>   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/>