Jinmei,
On Mon, 2005-05-23 at 14:23, JINMEI Tatuya / 神明達哉 wrote: > > > More than part of me is thinking this. It seems to me that there is a > > continuing confusion about how these bits interact with local decisions > > by the administrator of a specific machine or network. People are > > asking questions like "What happens if the M and/or O bits are clear but > > there is a DHCP server?" or "What happens if the M and/or O bits are > > clear but the client wants to use DHCP anyway" or "What happens if the M > > and/or O bits are set and the client doesn't want to run DHCP". None of > > these questions are in the realm of protocol design. Clearly, local > > administrators will do as they please with their machines. In this > > respect the M and O bits have never been anything but strong hints as to > > what the client should do. The client is always free to ignore the > > hints. Further network administrators are free to misconfigure their > > networks as they please. The current text describing these bits is > > clear almost to the point of being infantile. This isn't an indictment > > of the authors. Rather it is an indictment of attempts to enforce > > system configuration and management rules via protocol specifications. > > This is impossible. We should stop trying. > > First of all, as a part of the authors of the "infantile" document, > I'd like to emphasize once again that it's not our goal to *enforce* > system configuration issues through a protocol document. Perhaps the > current text is overacting, but the goal is to "clarify" (as the title > of the document shows) confusing points about the M/O flags. (You > seem to agree that there *is* confusion, but are saying that > clarifying those points is not IETF's work, correct?) > I made it clear that the current text is, I believe, a reaction on the authors' part to the persistent attempts to place operational restrictions on this protocol mechanism from within the specification. The clarity is good. I am for clarity. I apologize for any offense. However, I am against continuing to modify the document and the protocol in the hopes that the questions cited above will cease. They won't because they have nothing to do with the protocol. They have to do with operators wanting to tell users how to use their machines and users not wanting to do what operators want them to do and how that tension gets sorted out by what features and knobs are included or not included in the implementations the operators and users purchase. We aren't writing product specifications here. Trying to specify every implementation knob in the protocol specification is a mistake and removing useful features because all the possible knobs to control it aren't specified is also a mistake. tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
