[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [OPS-DIR] Operations Directorate Review ofdraft-ietf-radext-design-18
Hi Alan,
Please prepare a revised ID and submit it as soon as the pre-IETF
submission blackout is over which is the Monday of the IETF meeting. I
plan to put this document on the agenda of the first IESG telechat after
Beijing.
Thanks and Regards,
Dan
> -----Original Message-----
> From: ops-dir-bounces@ietf.org
> [mailto:ops-dir-bounces@ietf.org] On Behalf Of Alan T DeKok
> Sent: Wednesday, October 27, 2010 2:54 PM
> To: lionel.morand@orange-ftgroup.com
> Cc: ops-dir@ietf.org; 'radext mailing list'; gdweber@gmail.com
> Subject: Re: [OPS-DIR] Operations Directorate Review
> ofdraft-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.
> _______________________________________________
> OPS-DIR mailing list
> OPS-DIR@ietf.org
> https://www.ietf.org/mailman/listinfo/ops-dir
>
--
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/>