>> Ted, as an IESG member, are you really sticking to a that the meaning of a BCP? > > Working groups are where IETF consensus comes from. The IETF mailing > list review is there to see if the IETF disagrees with the working > group consensus. I'm trying to explain to you, the only (late) > dissenter in the IETF last call, why I think the IETF should have > consensus to publish the DHC working group's advice about how to > implement DHCP options as a BCP. I'm doing this because I think that > it is the right thing. If you think it's the wrong thing, at least > do me the courtesy of walking me through your reasoning. > > Can you make a clear argument for why some RAI working group, and not > the DHC working group, should be the one to offer advice on how to do > DHCP options? Would you, for example, want sipping to be where > advice on how to do new DNS RRtypes comes from? Really, now, this is over the top. First, BCPs have IETF consensus, and are applicable across the IETF. When you said that "RAI working groups are free to go against these recommendations," you were completely wrong, and the IESG should and would slap them down if they did. Second, anyone who participates in the IETF can bring up issues, as IETF consensus is built. The output of working groups doesn't have any magical force field protecting it from challenges from others. The working group consensus means a lot, of course, but reasonable and reasoned arguments still have to be addressed. Third, your second paragraph above is really out of line. So let's back away a bit and look at the picture we're painting. No one has tried to say that some other working group should be telling people how to use DHCP. What several of us have said, and what Cullen is saying, is that various protocols (including some in the RAI area) are using DHCP to get their configuration information. Nothing theoretical: they ARE. And that use has already been approved with IETF consensus. So IF the DHC working group means to say that such use by those protocols in that way is ill advised, it needs to be explicitly clear about that, and the issue needs to be discussed and have IETF consensus. Otherwise, the document's recommendations need to be clarified to say that this is legitimately done to configure application-layer protocols, and different recommendations may apply to those. Ideally, it would give those recommendations as well. So, one or the other: - say "don't do that; it's bad, and here's why," *and get IETF consensus on that*, or - say "different recommendations apply in those situations, and here are those recommendations," *and get IETF consensus on that*. Barry