[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-carroll-dynmobileip-cdma-04.txt
> Perhaps the way forward is to make a note of the "error(s)" in the
> Informational RFC?
Some background, so we're all on the same page. If this document were
submitted to the RFC editor today, it would be reviewed by the IESG
under the rules outlined in RFC 3932. In this case, the document would
fall under the following consideration (from Section 3):
5. The IESG thinks that this document extends an IETF protocol in a
way that requires IETF review and should therefore not be
published without IETF review and IESG approval.
As is being discussed, the document does extend radius.
All RFC Editor submissions (i.e., those not approved by the IETF) now
get published with a standard disclaimer (See Section 4 of RFC
3932). In this case, the standard note would have been:
2. For documents that specify a protocol or similar technology and
are independent of the IETF process:
This RFC is not a candidate for any level of Internet Standard.
The IETF disclaims any knowledge of the fitness of this RFC for
any purpose and in particular notes that the decision to publish
is not based on IETF review for such things as security,
congestion control, or inappropriate interaction with deployed
protocols. The RFC Editor has chosen to publish this document at
its discretion. Readers of this document should exercise caution
in evaluating its value for implementation and deployment. See
RFC 3932 for more information.
But, since this document does extend radius in ways that the IETF
apparently is not comfortable with, the above disclaimer may not be
enough. The IESG is quite willing to take the above disclaimer and
extend/modify it to describe what sort of IETF review it received and
what the IETF concerns are (w.r.t. to its extensions of our
protocols.) Thus, one possibility would be to add to the document an
IESG note that includes the above disclaimer plus adds to it based on
the concerns w.r.t. radius.
For example, So I think a disclaimer could also say something like:
This protocol makes use of and extends the IETF Radius protocol
(RFC XXX). It has been reviewed by the Radius community and the
following issues have been noted ....
and then list the violations and perhaps provide some explanation as
to why those violations are considered inappropriate or how serious
they are. Not a lot of text, but maybe one or two paragraphs total
would be best.
Given that the protocol is deployed, and most folks seem to think it's
better to document something (that is widely deployed) than not,
adding such a note as outlined above seems like a reasonable way out
(to me).
What do others think? Which particual radius extensions would need to
be called out for attention?
Thomas
--
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/>