> yes - I have to divorce the hostname-label linkage after the create > to retain predictability (i.e., so that set-addrprop/delete-addr etc > don't go and operate on the wrong address).
Yes, I understand that. It is also my contention that this will create confusion because you have something that is somewhat like a hostname, and will likely be named using hostnames, but is not a hostname. This has been my point through the entire discussion. It seems like you want it both ways here. That is, you want to give the administrator the "convenience" of being able to use a hostname as a label, but then acknowledge that it falls apart in many real-world scenarios and want to discourage the practice and have them come up with a new set of names for their IP addresses. Have I misunderstood your position on this? I have suggested an alternative of using an "improved" version of the existing logical interface naming scheme which does not have the V4/V6 namespace split and which would also accommodate address bundles in the same manner that address labels accommodate them (at least, to the degree which I understand how address labels accommodate them). Specifically, each address object for a particular IP interface (whether it's a single address, a point-to-point address, or an IPv6 address bundle) would have an associated numeric identifier. During create-addr, the administrator can either choose this identifier or have the system assign one for them. The address object is then identified by the interface/id tuple until it is eventually removed -- i.e., net0/0 or net0/86 or whatever. What are your reservations regarding such as system? Is it that you feel it does not provide enough semantic meaning? (My contention is that it is better to be vague than to be misleading, as the label can end up.) Is it that it is too much like logical interfaces? (If so, I'll note that the only material difference I see between the label and id proposals is the way in which the namespace is expressed and managed; both schemes have "address objects".) I am not married to my proposal -- maybe someone has a better idea, and I'm certainly open to suggestions. However, I continue to have significant concerns about the real-world usability of the label model. That said, if I'm the only one that feels strongly about this, then I'll concede -- I don't want to stand in the way of progress. -- meem
