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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf