[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RADIUS-Geopriv: Request for review

Hi,

On Sun, Feb 12, 2006 at 10:10:45PM +0100, Tschofenig, Hannes wrote:

> I have submitted an update for the RADIUS-Geopriv draft. Before it
> appears on the draft announcement list please find it at:
>
> http://www.tschofenig.com/drafts/draft-ietf-geopriv-radius-lo-05.txt
> http://www.tschofenig.com/drafts/draft-ietf-geopriv-radius-lo-05.html
> 
> I have incorporated the resolutions from the last IETF meeting
> (including follow-up discussions), review comments by Yoshi Ohba and a
> recent review by David Nelson.

I just reviewed the new draft briefly, and I'm glad to see that my
suggested approach towards challenges and capabilities was indeed useful
(although that's clearer from the new design than from the credits ;-))

I have two small suggestions for now, to make things a bit more
evolution-proof:

* Set the value of the Challenge-Capable attribute to 1, reserve all other
  values and and require the value to be non-zero in order for it to be
  interpreted as described. This allows the NAS to be more specific
  later, without loss of compatibility or a change in semantics that
  would require a new attribute.

* In Access-Challenges, I wonder whether Required-Information should be
  optional. The issues I see are as follows:

  - Challenge-Capable has potentially a wider applicability than just
    GEOPRIV. But in order to allow such later applications, and also to
    allow NASes to support challenges for purposeful withheld
    information as in GEOPRIV as well as the old PAP/CHAP-based OTP
    scheme, a mechanism is required to tell the NAS what it should do
    with a challenge following a request containing Challenge-Capable.

  - So, you can either have the NAS scan the challenge for anything that it
    can interpret as the reason for the challenge, and if it does not
    find anything, it should reissue the request as-is, including State,
    of course.

    This allows challenge reasons and required information sets to
    evolve without having to devise a new basic mechanism.

  - You can also require the server to be explicit in any challenge
    to a Challenge-Capable NAS, and create a Challenge-Cause attribute
    on the same architectural level as Challenge-Capable.

    Now, we can either promote Required-Information to that status, by
    *requiring* it in any challenge, and allow the IANA to assign other
    values, or reserve Required-Information for GEOPRIV alone, rename it
    Required-Location-Information and create a separate Challenge-Cause
    attribute.

  - But I think that one of the above two options is required for proper
    closure.

Kind regards,


Emile van Bergen.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

> > -----Ursprüngliche Nachricht-----
> > Von: owner-radiusext@ops.ietf.org 
> > [mailto:owner-radiusext@ops.ietf.org] Im Auftrag von Bernard Aboba
> > Gesendet: Donnerstag, 26. Januar 2006 05:52
> > An: radiusext@ops.ietf.org
> > Betreff: Request for review
> > 
> > A new version of the RADIUS location draft has been posted to 
> > the Internet 
> > Drafts archive:
> > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-
> > lo-05.txt
> > 
> > Please review this document and post comments to the GEOPRIV 
> > (and RADEXT) WG 
> > mailing lists.
> > 
> > In particular, please review conformance to the framework 
> > posted by Emile in 
> > this message to the list:
> > http://ops.ietf.org/lists/radiusext/2006/msg00028.html
> > 
> > FYI, the GEOPRIV WG issue tracker for this document is located at:
> > http://www.tschofenig.com:8080/radius-geopriv/

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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