Date: Wed, 18 Jun 2008 12:02:44 +0100 From: "Debbie Garside" <debbie@xxxxxxxxxxxxxxxxxx> Message-ID: <059901c8d132$d65df170$0a00a8c0@CPQ86763045110> | I see your point. I doubt that you do. | I do think, assuming it is not already documented and | further assuming this is the whole point of the appeal, that the IESG could | create a general policy wrt BCP's. No, you totally fail to understand. The IESG's job is not to create policies. It is to implement the policies created by the IETF as a whole. That's kind of the point here, the IESG (or at least one member of it) seems to want to create a new policy, or is somehow assuming such a policy has already been created (by someone, it isn't clear who or how.) That's what I believe John's appeal is really about - the IESG should not (not now, not ever) be attempting this kind of thing. | Shouldn't be too onerous. That way | everyone knows in advance that they should follow a BCP unless they can show | reasonable cause not to Not true in general. You also clearly don't know what a BCP is all about. If you're inferring things from the name, I'd suggest you go back to the poised/poised95/poisson (whenever it was that these things were created) mailing list archives, and observe all the discussions about the name, and what people might incorrectly read into it. We ended up with BCP as a name largely because no-one was able to suggest anything better. What those documents are however, is anything for which the IETF desires to express that there is community consensus behind what is written (whatever that is), but for which the standards process does not work (in that the latter requires interoperable implementations, several of them, and some things - like reserving a domain name - simply do not allow multiple interoperable implementations.) In this case, 2606 is a BCP merely to show (as its author stated a few days ago) that there was community consensus to remove from allocation to "normal" people/organisations a few particular domain names - that is, to convince IANA to make that reservation. That's it. Having achieved that objective, I guess 2606 could now be made historic. There neither is, was, or ever should be, any implication that anyone necessarily should ever use those names for anything. Of course, in many situations using them makes sense. In some it is a very very intelligent thing to do (for example if you're distributing a sample configuration file and you need to show the configuration to attach to a particular (end user supplied) server, using server.example.com as the domain name in the sample configuration would be a very wise choice.) In other cases using those domain names is of no benefit at all, and worse, may actually create confusion. Which is the case here isn't really the point - that's already been decided by both the working group, the previous standard (2881 to which this doc is a fairly minor revision, if I understand it all correctly) and the IETF last call processes for both 2881 and 2821bis. The issue is why the IESG is ignoring the demonstrated will of the IETF. kre _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf