[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Inconsistencies between RFCs and implementations
Bernard Aboba wrote:
> [BA] Since the guidelines document is just a BCP, it shouldn't be
> updating existing standards. So when you say the "remainder of the
> guidelines document" this makes me wonder what part of the guidelines
> document lies outside the appropriate role of a BCP.
Creating a RADIUS data model could arguably be outside of the role of
a BCP. However, pointing out that one exists would likely be within the
role of a BCP.
> [BA] During prior WG discussion, there was a general aversion to a large
> scale remake of the RADIUS data model (e.g. attempts to converge the model
> with Diameter). However, the addition of some modest enhancements might
> be within the scope of the Extended Attributes document.
I would suggest codifying the data model, rather than remaking it.
The data model has already largely been codified in the implementations.
If these are wrong, then we could say that no RADIUS implementations
exist. If they are right, then documenting what the implementations
have done would remake nothing.
> [BA] My preference would be for minor updates, with the goal of
> addressing the outstanding issues. Where the specifications are
> genuinely ambiguous about the types being defined, the document can
> state that, but can leave resolution to the future.
> Assuming we restrict additional work to that scope, what remaining
> changes do we need to make?
We need to change integer64 -> ifid, or something similar. We need to
achieve WG consensus that the current document reflects current
practice, and that the current practice is acceptable.
I suggest also adding a sentence or two describing the implicit versus
explicit nature of the RADIUS data model, and the failure of RFC 3162
et. al. to follow the "data type definition" framework shown in RFC 2865.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.