On Thu, 2009-07-16 at 13:34 -0700, Peter Memishian wrote: > In any case, I'm not > trying to strongarm you into agreeing with my proposal, but rather make my > concerns regarding the existing proposal as clear as possible. I would be > interested in hearing some other takes on this -- e.g., Seb, what's your > view?
My concern with some of the earlier proposals was it wasn't clear what the object handle was from the administrator's perspective. For dynamic addressing such as DHCP or IPv6 stateless address autoconfiguration, there was a label. For static non-point-to-point interfaces, there could be a hostname, but that had issues because hostnames can resolve do different addresses over time, and thus the handle and/or what it would refer had the potential to change unexpectedly. Then, point-to-point interfaces came along and neither could be used, and here we are. My initial feedback to Sowmini was that using a label that isn't a hostname as a handle for all address subcommands is self-consistent between address types and over time. The format of the label is less interesting to me, but using <interface-name>/<index> seems like a fine labeling scheme to me. Using <interface-name>:<index> would be a wink to the existing design, has that been considered? ;-) In addition to that, ifconfig's "addif" option is widely used, and its main benefit is to allow for the creation of addresses without having to manage the "logical interface" namespace. Having a requirement that there be some way for the UI (or better yet, the API) to manage the namespace on behalf of the consumer would seem wise. Another idea would be to have a label namespace that is flexible (not strictly constrained to an interface name and index), while automatically generated labels could use a convention using an interface name and index. -Seb
