Re: [radext] Issues with draft-ietf-radext-radius-extensions-09

[Sam Hartman <[e-mail]>]

>>>>> "Barry" == Barry Leiba <[e-mail]> writes:
esn't make sense to me.  Section
    >>> 2.8 starts with this:
    >>> 
    >>> The term "invalid attribute" is new to this specification.  It
    >>> is defined to mean that the Length field of an Attribute is
    >>> valid (as per [RFC2865], Section 5, top of page 25).
    >>> 
    >>> These two appear to be contradictory: the first says that if the
    >>> length is invalid, it's an "invalid attribute", and the second
    >>> says that "invalid attribute" means that the length field is
    >>> valid (but there are other problems).  This comment also applies
    >>> to "TLV-Length" in Section 2.3.
    >> 
    >> The intent here is that the *contents* of the attribute are
    >> invalid.

    Barry> Yes, I get that.

    Barry> You are saying (in 2.8) that "invalid attribute" is a
    Barry> situation when the length is valid and the content is not.

    Barry> But you are also saying (in 2.1) that an EA is considered
    Barry> "invalid attribute" when its length is invalid.

If I may, I think this is a layering issue.

You have the base radius layer, which requires length be at least 2.
If your length isn't 2, you fall off the parse path in RFC 2865; it's a
low level problem.

If your length is at least 2 you get into an attribute-type-specific
abstraction.  One outcome of this abstraction is "invalid attribute," a
new concept introduced in this spec.  It means well-formed at the
2865-level but semantically garbage at an attribute-type-specific level
introduced in this spec.  And the attribute-type-specific layer for
extended types introduces the length must be 4 rule.

So, it's kind of like saying that a different chunk of code in the
abstraction will return an error depending on which length range things
fall in. 0-1: something like BaseRadius.WayTooShort; 2: if it's an
extended attribute extendedattribute.InvalidAttribute

The above is just an analogy to explain why I don't think it's
contradictory.  I'm not entirely convinced that distinction in
abstraction is useful.  I.E. the spec might be improved by addressing
your concern, and the wording might not be good enough for you to see a
reading that isn't contradictory, but I don't see any internal
consistency problem.

--Sam