RE: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Pana] AD review of draft-ietf-dhc-paa-option-04.txt
Hi Lionel,
Thank you for the updates.
> #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."
Would replacing the second sentence with the one below improve clarity?
Presence of these DHCP options does not indicate PANA must be used
in
the network.
Others look good.
Alper
>
> #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 at piuha.net]
> > Envoyé : mardi 31 octobre 2006 12:22
> > À : Alper Yegin; MORAND Lionel RD-CORE-ISS
> > Cc : pana at 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 at ietf.org
https://www1.ietf.org/mailman/listinfo/pana
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.