RE: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt

"MORAND Lionel RD-CORE-ISS" <lionel.morand@orange-ftgroup.com> Tue, 28 November 2006 17:21 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp6eU-0001RT-Bn; Tue, 28 Nov 2006 12:21:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp6eT-0001RD-6w for pana@ietf.org; Tue, 28 Nov 2006 12:21:49 -0500
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp6eR-0005bs-PT for pana@ietf.org; Tue, 28 Nov 2006 12:21:49 -0500
Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 18:21:38 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt
Date: Tue, 28 Nov 2006 18:21:28 +0100
Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026041811C0@FTRDMEL2.rd.francetelecom.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt
Thread-Index: Acb83r0Ama5KdVBDQNydXoS88DyKywWJ8muA
From: MORAND Lionel RD-CORE-ISS <lionel.morand@orange-ftgroup.com>
To: Jari Arkko <jari.arkko@piuha.net>, Alper Yegin <alper.yegin@yegin.org>
X-OriginalArrivalTime: 28 Nov 2006 17:21:38.0439 (UTC) FILETIME=[A99D7970:01C71311]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c
Cc: pana@ietf.org
X-BeenThere: pana@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Protocol for carrying Authentication for Network Access <pana.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pana@ietf.org>
List-Help: <mailto:pana-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pana>, <mailto:pana-request@ietf.org?subject=subscribe>
Errors-To: pana-bounces@ietf.org

Hi Jari, Alper

According to the presentation made during the last IETF meeting, here are the proposed changes to include in the next version of the PANA-DHCP document.
Please consider the proposed modifications to make sure that all the remaining issues are covered.
I will submit a new version of the draft (v05) based on your feedack.

BR,

Lionel

****************************************************************** 

#1- in the introduction (section 1), at the end of the 3rd paragraph, revise the text to remove "many"

From:
 
   "This document specifies DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options
   that allow PANA client (PaC) to discover PANA Authentication Agents
   (PAA).  This is one of the many methods for locating PAAs."

To:

   "This document specifies DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options
   that allow PANA client (PaC) to discover PANA Authentication Agents
   (PAA).  This is one of the methods for locating PAAs."

#2- in the introduction (section 1), extend the existing section with the following text:

   "The DHCP options defined in this document are used only as a PAA
   discovery mechanism. These DHCP options MUST NOT be used to perform 
   any negotiation on the use of PANA between the PaC and a PAA."

#3- At the end of the section 4 (DHCPv4 option), revise the text to clarify the use of the DHCP options:

From:

   "A DHCPv4 client requests the PAA DHCPv4 Option in a Parameter Request
   List as described in [RFC2131] and [RFC2132].

   The DHCPv4 client MUST try the records in the order listed in the PAA
   DHCPv4 option."

To:

   "A PaC (DHCPv4 client) SHOULD request the PAA DHCPv4 Option in a
   Parameter Request List as described in [RFC2131] and [RFC2132].

   If configured with a (list of) PAA address(es), a DHCPv4 server SHOULD
   send a client with the PAA DHCPv4 option, even if this option is not
   explicitly requested by the client.

   A PaC (DHCPv4 client) receiving the PAA DHCPv4 option SHOULD use the
   (list of) IP address(es) to locate PAA.

   The PaC (DHCPv4 client) MUST try the records in the order listed in 
   the PAA DHCPv4 option received from the DHCPv4 server."

#4- At the end of the section 5 (DHCPv6 option), revise the text to clarify the client/server behavior:

From:

   "A DHCPv6 client requests the PAA DHCPv6 option in an Options Request
   Option (ORO) as described in the DHCPv6 specification [RFC3315].

   The DHCPv6 client MUST try the records in the order listed in the PAA
   DHCPv6 option."

To:

   "A PaC (DHCPv6 client) SHOULD request the PAA DHCPv6 option in an
   Options Request Option (ORO) as described in the DHCPv6 specification
   [RFC3315].

   If configured with a (list of) PAA address(es), a DHCPv6 server SHOULD
   send a client with the PAA DHCPv6 option, even if this option is not
   explicitly requested by the client.

   A PaC (DHCPv6 client) receiving the PAA DHCPv6 option SHOULD use the
   (list of) IP address(es) to locate PAA.

   The PaC (DHCPv6 client) MUST try the records in the order listed in the
   PAA DHCPv6 option."




> -----Message d'origine-----
> De : Jari Arkko [mailto:jari.arkko@piuha.net] 
> Envoyé : mardi 31 octobre 2006 12:22
> À : Alper Yegin; MORAND Lionel RD-CORE-ISS
> Cc : pana@ietf.org
> Objet : Re: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt
> 
> I am fine with the approach that the option is merely for PAA 
> address discovery, not affecting whether PANA is on or not. 
> But I would like that to be explicitly stated in the 
> document. It would also be useful to have a warning that 
> there are issues if you attempt to do otherwise.
> 
> Changes needed to state are likely fairly small.
> If you submit the draft it probably appears when the IETF 
> starts and I can move the draft along after that.
> > "A PaC SHOULD request the PAA DHCPv4 Option in a Parameter Request 
> > List as described in [RFC2131] and [RFC2132].
> > If configured with a (list of) PAA address(es), a DHCPv4 
> server SHOULD 
> > send a client with the PAA DHCPv4 option, even if this 
> option is not 
> > explicitly requested by the client."
> This is a start. It defines what the nodes do, but I would 
> also like to see
> 
> 1) What the PaC does when it receives the option
> 2) Explanation that the option is not used for turning PANA 
> on/off, along with the warning
> 
> --Jari
> 
> 

_______________________________________________
Pana mailing list
Pana@ietf.org
https://www1.ietf.org/mailman/listinfo/pana