Re: Comments on draft-carroll-dynmobileip-cdma-04.txt

[Jari Arkko <jari.arkko@piuha.net>]

Hi Glen, Thomas, Avi,

Glen, you wrote:

> OK, but I haven't heard either Frank or Chris _ask_ for any help...
>  
I don't think they need to ask help in this case. This being treated
in the process in the manner that Thomas explained in his e-mail.
I don't think we should edit the document content itself, but
an IESG note is required to the document before it can proceed,
and I think the contents of that note should be formulated carefully.
I think we are discussing the contents of that note, not
fixing the protocol as such. The note is IESG's problem but my
understanding is that the ADs would welcome the help of the
RADIUS community in defining what issues should be highlighted.

Thomas, you wrote:

>   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).
I think this makes sense under the circumstances. Note,
however, the difference between "we have not reviewed it
and it does not directly concern us" and "we think there are
some problems and it affects our protocols". Lets hope that most
future individual submissions fall on the former category...

Avi, you wrote:

> This document extends RADIUS in the following way:
>
> The document returns an attribute in an Access-Reject message. According to
> RFC-2865 an Access-Reject packet MAY only include Reply-Message and
> Proxy-State.
>
> Subsequent RFCs allow for other attributes to be included in an
> Access-Reject packet but these are included to indicate the reason the
> authentication/authorization has failed.  Given the use in this document an
> Access-Challenge packet would have been more appropriate.
>  
Ok otherwise but lets be careful with the word "extends".
There are different types of extensions, lets be more
specific. How about

    This protocol defines how RADIUS (RFC 2865) is used in a
    specific situation and vendor-specific protocol extensions.
    It has been reviewed by the Radius community and the
    following issues have been noted: (1) The document suggests
    returning an attribute in an Access-Reject message. According to
    RFC 2865 an Access-Reject packet MAY only include Reply-Message
    and Proxy-State attributes.  Subsequent RFCs allow for other
    attributes to be included in an Access-Reject packet but these
    are included to indicate the reason the authentication/authorization
    has failed. Instead, the use of an Access-Challenge packet would have
    been appropriate according to RFC 2865. (2) ... maybe more issues ...
    As a result, the use of this specification in other circumstances than
    those described in the document or as a basis for new work is not
    recommended.

--Jari


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