[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute"
Alan DeKok <> supposedly scribbled:
> "Avi Lior" <email@example.com> wrote:
>> The closest RADIUs type would be string. Neither 3162 nor this
>> document defines the type as string. In essence both documents (and
>> thank god they are consistant) are defining a new type, which is a
>> compound type, that contains a length field counting bits, Octet
>> based variable length array containing bits.
Syntactically, I think that they are both strings. Semantics are a different ballgame, of course, but 2865 isn't really consistent on this either. In fact, RADIUS is (laudably or lamentably, depending on your POV) pretty loose WRT to data typing.
> Yes, though this document simply re-uses the existing standards
> track type defined in 3162.
Good argument, except that 3162 nowhere uses the word "type" except as the name of an attribute field. Since RFC 3162 doesn't define any types, it seems hard to substantiate your claim of an existing type, let alone a standard one.
>> I don't think EXTATTR folks are thinking about encoding attributes
>> the way this document and 3162 is proposing -- so that is out of the
Maybe they should be? Seems kind of useful...
>> So perhaps the Guidelines document should be changed to allow for
>> this encoding. That would be my choice.
That's OK, too.
> I have no objections to the guidelines permitting the definition of
> new attributes that re-use existing formats, however awkward. The
> practice should be discouraged, but not forbidden.
> Therefore, I have no objections to this format, or this document.
> Alan DeKok.
Hope this helps,
Why is it that most of the world's problems can't be solved by simply
listening to John Coltrane? -- Henry Gabriel
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.