>>>>> On Wed, 13 Apr 2005 10:09:12 -0400,
>>>>> Brian Haberman <[EMAIL PROTECTED]> said:
> Title : Considerations on M and O Flags of IPv6 Router
> Advertisement
> Author(s) : S. Park, et al.
> Filename : draft-ietf-ipv6-ra-mo-flags-01.txt
> Pages : 13
> Date : 2005-3-30
> as a Proposed Standard. Substantive comments should be directed
> to the mailing list. Editorial comments can be sent to the document
> editor. This Last Call will end on April 27, 2005.
Although I'm listed in this document as a co-author, this time I'm
commenting as an ordinary reader (I could not find time to make
comments on this version at the intra-author review period. It was
just my bad).
I don't think this document is ready for publication (or being
submitted to the IESG) yet.
COMMENT 1: (the biggest concern)
I believe we should address the first comment on a prior version of
this document from Pekka:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03808.html
That is, with the current specification (of the mo-flags document or
of ND/autoconf/DHCPv6), we'll see troubles like this:
Consider the following settings:
a) the M flag is on in RAs
b) all available DHCPv6 servers support the RFC3736 subset
c) host's M-Policy is set to 2 (invoke DHCPv6 when M-Flag changes
from False to True)
then the host will try the "Host Configuration Behaviour"
(Solicit/Advertise/Request/Reply exchanges), but the server does not
respond to the Solicits. According to the DHCPv6 specification, the
host will send Solicits eternally, and won't even get other
configuration information such as recursive DNS server addresses.
I can think of several possible resolutions:
1. just say that it's host/network administrator's responsibility to
provide consistent parameters/configurations. In this sense, the
combination of a) and b) above is just a configuration error.
This would be the most lightweight resolution for the authors:-),
but I personally think it's irresponsible.
2. allow a host to fall-back to Information Configuration Behaviour in
such a case. This is not 100% compliant with the DHCPv6
specification, though.
3. make small updates on the DHCPv6 specifications (RFC3315 and
RFC3736) to help mitigate or avoid the problematic scenario.
I showed some concrete ideas of 2 and 3 before:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03862.html
But at that time we did not have detailed discussions much.
Ideally, I think resolution 3 is the way to go and should be included
in this document (we'll then need to DHCPv6 updates at the dhc wg, of
course). But if it's too tough, resolution 2 can be a workaround with
careful wording.
COMMENT 2:
I believe we should also make consensus on the open issue described in
Section 11 (default policy values) before publication.
COMMENT 3: (miscellaneous minor issues, mostly editorial)
- In the last sentence of Section 12
s/is different form/is different from/
- SEND is now published as an RFC (RFC3971)
- if we need an update version of this document (I believe we do),
we'll need to use the new IPR boilerplate (e.g., with version 1.29
of xml2rfc)
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
