----- Original Message ----- From: "Robert Elz" <kre@xxxxxxxxxxxxx> To: "Brian E Carpenter" <brian.e.carpenter@xxxxxxxxx> Cc: "John C Klensin" <john-ietf@xxxxxxx>; <ietf@xxxxxxxx>; <dcrocker@xxxxxxxx>; <iesg@xxxxxxxx> Sent: Monday, June 16, 2008 12:51 AM Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis > Date: Mon, 16 Jun 2008 13:23:28 +1200 > From: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> > Message-ID: <4855C090.6040203@xxxxxxxxx> > > > | Which, in fairness, the IESG has documented, in the DISCUSS criteria > | document and generally in practice, over the last several years. > > The IESG is free to document their own procedures, that's a good thing. No they are NOT. The IESG's processes MUST also be transparent just like the IETF's or they risk creating liability for their sponsor's that NONE of those sponsor's will be too happy with. > > They're not free to invent rules for the IETF, that's for the IETF as > a whole. What gets a document approved is IETF rough consensus, that's > been the IETF rule for years. If there's any real question whether this > revision has IETF consensus or not, then it should be blocked. If > there's > no question as to that, then it should be approved - after all, the IETF > would (under that assumption) have approved it, along with all of its > examples. If the example domain names were really an issue to anyone, > that would have been raised during last call. At that point, whether or > not rough consensus existed to continue with the doc as it was could have > been > judged. > > Even if we had a rule that all domain names in RFCs must be from the > reserved > set (which we do not) the IETF has the power to change its rules. That > can > be done in general, or on a case by case basis. Raising the issue during > last call, and having the IETF decide to ignore the problem for the doc in > question would be all that is required to set aside the rule for that doc. > > But we have no such rule, there's never been a last call on anything that > says that all domain names in examples in RFCs must be from the set > documented in 2606, so the issue should not even arise. If there ever > were > such a last call, you can expect I'd be an vociferous opponent, as rules > like that make no sense at all. There are perfectly good reasons for > those > domains to exist, and very definitely places where they should be used, > but this is not one of those cases. > > | I don't think that changing foo.com to foo.example.com would > | destabilise the email system too much. > > Of course it wouldn't break e-mail, but it would make following the RFC > sequence, and working out what changed, and why, much more difficult. > > Further, when dealing with something which necessarily deals (or should) > deal with many different domain names (like e-mail does), constraining > the examples to be from just a small set or (seemingly relayed) names > would > do a disservice. Sure, you and I know that the "example" in > foo.example.com > is meant to be ignored, and isn't there for any particular purpose, but > can > you expect that every reader of the doc will understand that. > > Even if there was an "only those domain names" rule, and there was a good > reason for having that (neither of which is actually the case), there > would > be a good case for ignoring it for this one doc. If the "real" domain > names > used in this doc are a problem to the owners of the domains, I have no > real > doubt but they would be changed upon request, so that straw-man objection > can be ignored. > > I have no idea which AD has the arrogance to put their own view of what > the IETF rules should be above the stated desires of the IETF as a whole > (as determined by the last call), but whoever that is really ought to > consider resignation as an honourable way out of the mess they're > creating. > > kre > > > _______________________________________________ > IETF mailing list > IETF@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf