Mark, On 2005/08/09, at 5:40, Mark K. Thompson wrote:
> > On 8 Aug 2005, at 21:16, Fred Baker wrote: > > >> personally, I an see a *lot* of reasons to leave such decisions in the hand >> of the administration. The most compelling is: "try taking it out of the >> administration's hands. Just try. I dare ya." >> >> DHCP/DHCPv6 seems like a reasonable choice of dynamic host configuration >> protocol. >> > > Naturally I concur, however two technical challenges leap out at me > concerning the nature of the policy table as specified by RFC3484. > > First, the lack of field definition for labels has seen different OSes use > different datatypes for the label, from string through stringified-integer to > integer. Any cross-platform policy specification protocol would need to cater > for this inconsistency. Perhaps this is something that a RFC3484-bis could > address when making that spec compliant with the requirements of RFC3879 > Section 4? let me comment one thing. By our protocol, we intend to distribute an address selection policy, of course, but the values in this option aren't absolute but relative. When an option includes the following, for example: Prefix Precedence Label 2001:db8::/48 100 10 3ffe:db8::/48 20 10 2002:1:2::/48 10 5 The Label values just indicate that the first line and the second line has the same label and the third line doesn't have the same label as any other lines. This is the case with Precedence value. This option indicates the order of precedence. So, if a host has its policy table configured manually and has the label value 10, the distributed policy's label value should be changed to another un-used value or string. About Precedence, the values in distributed option can be changed as far as the order isn't changed. So, this just seems to me an issue of implementation on DHCPv6 option receiver. It may be better to clarify these implementation considerations in our draft or in another draft. > > Also, RFC3484 permits the specification of zone index in the policy (c.f > section 2.1). Section 6 of RFC4007 explicitly states that zone indices are > strictly local to the node, making any centralisation of RFC3484 policy > "challenging". [aside: OK, so administrators could harvest index data for > links on which scoped-policy is required and then maintained in the DHCPv6 > server as specific for that node, but there's no protocol for that harvesting > and I've not surveyed sufficient implementations to determine whether indexes > persist and are consistent between reboots] Actually, we aren't sure that this field is necessary. We also have never heard a case harvesting it. As you mention it, this value is local in a node, so there may be no use to distribute it in a centralized manner. -- Arifumi Matsumoto <[EMAIL PROTECTED]> -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
