Subject: [Geopriv] RADIUS-Geopriv: Request for review

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sun, 12 Feb 2006 22:10:45 +0100

Hi all, 

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.priv.at/drafts/draft-ietf-geopriv-radius-lo-05.txt
http://www.tschofenig.priv.at/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.

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Bernard Aboba
> Gesendet: Donnerstag, 26. Januar 2006 05:52
> An: [email-masked]
> 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.priv.at:8080/radius-geopriv/
> 
> 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Emile van Bergen <[email-masked]>
Date: Tue, 21 Feb 2006 10:08:38 +0100

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:
>
> 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           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 21 Feb 2006 18:10:04 -0500

> http://www.tschofenig.priv.at/drafts/draft-ietf-geopriv-radius-lo-05.html

  The Operator-Name attribute does not follow existing RADIUS data
types.  Packing multiple pieces of data into one attribute should be
discouraged.

  The Location-Information attribute is even more complicated.  And
the format of the attribute changes depending on field values.  This
is a recipe for disaster.  At the minimum, the Location-Info field
should be removed from Location-Information, and replaced with two new
attributes: Location-Civic-Information and
Location-Geospatial-Information.

  And defining the resolution & latitude data as non-byte aligned is
another recipe for disaster.  It would cost almost nothing to align
the fields, and would significantly increase inter-operability and
decrease deployment problems.

  If the unaligned data is taken from another standard, then the
fields should be left undefined here.  Rather than explicitely
describing them, the attribute contents should instead be a normitive
reference to another data structure.  And I don't see any normitive
reference to a document describing these fields, so it looks like the
geospatial attribute format was created specifically for this I-D.

  In that case, it is even more of a requirement that the format be
fixed before this document moves forward.

  For the Requested-Info attribute, it would be best to describe it as
a bit array, rather than saying things like "a numerical value of this
attribute is 8".  If it's a bit array, then the fields have offsets
with the array, but have no numerical value.

  Alan DeKok.