[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-agentopt-delegate-01.txt
Actually,
>1)in Section 5:
> The last sentence ".......by setting a shorter valid-lifetime in the
this
>option", should change "in the this option" to "in the corresponding
>option"?
It should also say LONGER, not shorter, lifetime.
A Relay Agent can't be told a shorter lifetime than the client as the
client is the one that needs to trigger the renewal. This was raised
before but we missed it in this last editing pass.
---
And, there is another issue that needs to be addressed. The RAAN option
should include *ALL* addresses or delegated prefixes for the client (on
that link); not just those that may be in the Reply to the client. This
is critical because otherwise a lost Release Reply (which never makes it
to the relay), may never communicate that released address/prefix even
if the client retransmits (since the server may now not have the
corresponding binding since it previously released it). It just seems
better for the Relay to be able to assume that any other addresses (or
prefixes) it may have had on that link, from that server, and for that
client are no longer in use.
---
Finally, some additional comments below (prefaced by BV>).
- Bernie
-----Original Message-----
From: Amy [mailto:zhaoyuping at huawei.com]
Sent: Thursday, August 10, 2006 10:52 PM
To: dhcwg at ietf.org
Subject: RE: [dhcwg] I-D
ACTION:draft-ietf-dhc-dhcpv6-agentopt-delegate-01.txt
Hi
I have some question:
In section 3, the second paragraph:
"The DHCP server MAY include this option in a Reply message sent to a
client that includes assigned addresses and/or prefixes. If the DHCP
server does include this option in a Reply message, it MUST include
it in the option area of the Relay-reply message sent to the relay
agent intended as the recipient of the option."
1) "The DHCP server MAY include this option in a Reply message ...." .
------ Why? To minimize the DHCP packet size(it's the reason I guess),
or
other reasons?
BV> This is the old issue of do we require all servers to support this
option or not. As it is a new option (not in the base specification), it
should not be a MUST. However, if a server claims it supports this
draft, it had better include this option in a Relay-Reply if it was
requested by the relay agent. (Note that a server may also be configured
to always send this, even if it wasn't requested by a relay agent).
BV> I think if you ship a DHCPv6 server and complain you adhere to this
draft (well, RFC when it becomes one), and you don't actually support it
because you say "hey, the RFC says MAY", I think you customers aren't
going to be very happy and not likely to purchase your products. If you
don't support this in a server, don't claim you support this draft.
2) "If the DHCP server does inclue this option in a Reply messge, it
MUST
include...". ---------- So, there is more than one RAAN options in a
Relay-reply message. Is the RAAN option included in a Reply message
useful?
Or it should be "does not" ?
BV> No. Look, a Reply is ENCAPSULATED in a Reply-Reply. But so are
Advertise messages. What this section is saying is that when the server
sends a Reply, and the Relay-Agent requested the RAAN option via the ORO
in the Relay-Agent's Relay-Forw, the server should include it in the
Relay-Reply. It is just a mouthful to say that every single time.
BV> There can be multiple RAAN options in a relayed Reply. The reason
for this is that if relay agent chaining is used, each relay agent may
request the RAAN option (probably not likely, but you need to support
that).
3) If DHCP client receives a reply message containing a RAAN option, how
does the DHCP client handle the RAAN option? ignore?
BV> The RAAN option should not be sent to a client. However, by the
normal rules if a client receives an option it doesn't "know" or "care
about", it SHOULD ignore it.
4) If DHCP server receives a relay-forw message requesting RAAN, when it
answers, should it insert the RAAN option into the reply message or the
relay-reply message?
BV> It should insert it in the corresponding Relay-Reply for any *Reply*
message it encapsulates in a Relay-Reply.
Two editing nits
1)in Section 5:
The last sentence ".......by setting a shorter valid-lifetime in the
this
option", should change "in the this option" to "in the corresponding
option"?
BV> See above, shorter should be LONGER too. I think dropping "this"
would be sufficient.
2)In Section 3:
The first sentence "The RAANn option carries information about.....",
should change "RAANn" to "RAAN"?
BV> Yup. Already in the list of edits. We noticed this just after it was
submitted ...
BV> Thanks for the comments.
> -----Original Message-----
> From: Internet-Drafts at ietf.org [mailto:Internet-Drafts at ietf.org]
> Sent: Friday, August 11, 2006 3:50 AM
> To: i-d-announce at ietf.org
> Cc: dhcwg at ietf.org
> Subject: [dhcwg] I-D
> ACTION:draft-ietf-dhc-dhcpv6-agentopt-delegate-01.txt
>
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> This draft is a work item of the Dynamic Host Configuration
> Working Group of the IETF.
>
> Title : DHCPv6 Relay Agent Assignment
> Notification (RAAN) Option
> Author(s) : R. Droms, et al.
> Filename : draft-ietf-dhc-dhcpv6-agentopt-delegate-01.txt
> Pages : 8
> Date : 2006-8-10
>
> The DHCP Relay Agent Assignment Notification (RAAN) option is
> sent from a DHCP server to a DHCP relay agent to inform the
> relay agent of
> IPv6 addresses that have been assigned or IPv6 prefixes that
> have been delegated to DHCP clients.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-agen
> topt-delegate-01.txt
>
> To remove yourself from the I-D Announcement list, send a
> message to i-d-announce-request at ietf.org with the word
> unsubscribe in the body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login
> with the username "anonymous" and a password of your e-mail
> address. After logging in, type "cd internet-drafts" and then
> "get draft-ietf-dhc-dhcpv6-agentopt-delegate-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv at ietf.org.
> In the body type:
> "FILE
> /internet-drafts/draft-ietf-dhc-dhcpv6-agentopt-delegate-01.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader. Different MIME-compliant
> mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg