Are folks happy with the following approach? I've not seen any
objections (or any agreements either), but I'm not sure if I can start
editing based on the proposal, considering the fact that this is quite
a big set of changes.
Explicit support or objections are highly appreciated. If the list is
still silent, I'll start revising the document anyway.
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
>>>>> On Thu, 13 May 2004 20:00:14 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
>> Although his suggestion was apparently supported by several key
>> players in this group, I'm afraid details on actual changes for
>> rfc2462bis may still vary. So I'll soon throw concrete idea of the
>> changes based on my own interpretation of his suggestion in a separate
>> message.
> And here are the proposed changes. The basic idea is:
> 1. clarify (change) the meaning of the M/O flags; they are just hints
> of availability of the corresponding services, not triggers for
> invoking the protocols under a certain level of requirement
> 2. remove "requirements" regarding these flags according to the above
> change
> 3. (optionally) make a separate document (standard or BCP) on how to
> interact the protocols with these flags
> (In the followings, I'm assuming we have agreed that
> - we should clearly specify the corresponding protocols for the M/O
> flags
> - the protocol for the M flag is DHCPv6 (RFC3315)
> - the protocol for the O flag is the "stateless" subset of DHCPv6
> (RFC3736)
> but these details are not the essential part of the proposal.)
> The followings are some concrete examples of how I'd revise the
> document based on the idea.
> For 1, I'd revise the following sentence of RFC2462 Section 4 (page
> 9):
> A "managed address configuration" flag indicates whether hosts
> should use stateful autoconfiguration to obtain addresses.
> to:
> A "managed address configuration" flag indicates whether DHCPv6 is
> available for hosts to obtain addresses.
> For 2,
> - remove the notion of the ManagedFlag and OtherConfigFlag
> (conceptual) variables defined in Section 5.2, since these flags
> will become meaningless if we do not mandate invoking particular
> protocols by the RA M/O flags.
> - remove "requirement" sentences like the following one
> If the value of ManagedFlag changes from FALSE to TRUE,
> and the host is not already running the stateful address
> autoconfiguration protocol, the host should invoke the stateful
> address autoconfiguration protocol, requesting both address
> information and other information.
> (Section 5.5.3 of RFC2462)
> - remove Section 5.5.2 of RFC2462 (that mandates performing the
> "stateful" protocol when no RAs)
> Hopefully, these are not so different from what others imagined by
> Christian's suggestion. But I'm not that optimistic, and expect
> objections. Please make comments on the idea shown above,
> particularly if you have an objection.
> Thanks,
> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center, Toshiba Corp.
> [EMAIL PROTECTED]
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [EMAIL PROTECTED]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
