Brian E Carpenter wrote: > However, I'm arguing that > there is scope on this particular point for concluding that there is > a *technical* issue (a source of confusion, i.e. a lack of clarity). If would be fascinating to see someone attempt to defend such a claim seriously and with pragmatic substance, rather than detached theory. That is, to try to prove the claim with facts. > That may or may not be a valid conclusion. And that's one of the issues that is that the meat of the appeal, as I read it: The serious basis for the Discuss has not been documented, nevermind defended. So we can debate all sorts of hypotheses about whether their might or might not have been a legitimate basis for this Discuss, and we would thereby miss the underlying issue. > However, one of the two > DISCUSS comments points out that at least 3 of the domains used are > real ones. So the issue of confusion is a real one. 1. Where is the rule prohibiting the use of real domain names? 2. This particular spec began life 25+ years ago using those names, so we ought to have solid data showing that that particular document's use of those names is a problem. Where is it? 3. Where is the empirical substantiation that use of a real domain name in an RFC spec causes problems with the development of interoperable implementations? 4. If you want to focus on a judgement call, how about focusing on the judgement that keeping specification documents stable, as much as possible, across their life, is important? > What I am > saying is: these DISCUSSes are about a technical issue. They may or > may not be reasonable, but I object to the suggestion that they are > stylistic or editorial (which would automatically make them out of > scope under the IESG's own document). Like any good technical issue, I'm sure you can document the real-world demonstrations of this as a problem and for this document? Mostly what you are doing, Brian, is demonstrating that one can claim that anything is a technical issue. >> Even better is that application of this invented rule on a revision to >> an established standard represents an orientation towards change that is >> de-stabliling rather than helpful. > > I don't think that changing foo.com to foo.example.com would > destabilise the email system too much. Perhaps you are missing the point. I guess that's a judgement call, too. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf