RE: FW: ISSUE: Inappropriate usage of RFC 2119 key words

["Glen Zorn" <glenzorn@comcast.net>]

> Glen Zorn wrote:
> > Alan DeKok [mailto:aland@deployingradius.com] writes:
> ..
> >>   I welcome suggestions for how implementations can *meaningfully*
> >> interoperate when they have different interpretations for an
> attribute.
> >
> > What, if anything, do you imagine that has to do with my comment?
> 
>   It's a complex logic chain, explained in my previous message.
> 
>   The suggestion that specifications SHOULD re-use existing data types
> means that implementations can re-use those data types for new
> specifications.  Since the data types are already inter-operable,
> adding
> new attributes of the same data type means a high likelihood of
> inter-operability.
> 
>   Or... we give up on the idea of data types (as has been insinuated
> here), 

Nothing is being insinuated: AFAICT, the only justification for most of the
prescriptions in the draft is that to so otherwise requires code changes in
some implementations.  My rather clear question was "What harm does a
correctly implemented code change have do to interoperability?"  I think
that the answer is obvious (none), which may explain your need to avoid
answering it at all costs ;-).

> and new specs do whatever they want.  Since the old
> implementations don't know about those new data types, they won't
> implement them, and the systems won't be inter-operable.

Without changes to code (or in a more reasonable system, to a (auxiliary)
dictionary).

> 
>   And to repeat: Yes, they will be able to exchange RADIUS packets.
> No,
> they will not be able to agree on the format, meaning, interpretations,
> and processing requirements for attributes.
> 
>   e.g. An implementation that doesn't support Message-Authenticator
> cannot be meaningfully said to be interoperable with another one that
> requires Message-Authenticator for EAP sessions.

Excellent example!  Section 3.1 of RFC 3579 says "the Message-Authenticator
attribute MUST be used to protect all Access-Request, Access-Challenge,
Access-Accept, and Access-Reject packets containing an EAP-Message
attribute".  So you seem to be saying that the fact that an implementation
that is compliant with RFC 3579 won't interoperate with one that isn't
compliant is, amazingly, a bug rather than a feature!

> 
>   RADIUS has had attribute interoperability problems for over a decade.

If so, isn't the answer to require more detailed and specific attribute
definitions rather than attempting to homogenize everything (often
inappropriately, as I pointed out with the "integer64" concoction)?

...


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