Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

[Ned Freed <[e-mail]>]

> > 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.

Exactly so. Isn't it sort of the point of that whole "running code" thing to
prefer operational experience to finespun theorizing?

And in that vein, I have a few small data points to offer. I'm the author or
coauthor of quite a number of RFCs as well as various other documents, and up
until recently I have not only used whatever domain names I felt like in these
documents, I've also used actual valid email addresses. In particular, I've
used a lot of addresses in the innosoft.com domain, some valid, others invalid,
as well as the domain itself. I also served as postmaster for the domain for 15
years or so, which gives me a pretty good idea of the consequence of its usage.

Based on this experience, I've found that domain usage in documents basically
breaks down into three categories:

(1) Example objects, dialogs, and transactions
(2) Test objects and vectors.
(3) Sample configuration information

Despite having used innosoft.com extensively in example objects and dialogs,
including but not limited to widely implemented full standards like RFC 2920
and even more widely implemented draft standards like RFC 2049, I cannot recall
a single instance where this has caused a noticeable problem or generated a
complaint. This was true even before email became inundated with spam, and now
that spam is so prevalent it is difficult for me to imagine a scenario where
type (1) usage in a specification would actually matter.

Test objects and vectors have been more of an issue, but only slightly. The
example I have here is the set of MIME messages Nathaniel Borenstein assembled
back when MIME first came out. This corpus was never published in an RFC but
was widely disseminated in tarball form. Quite a number of these messages had
my address in a To: or Cc: field, with the result that I used to receive copies
of the messages from time to time from various random places performing
testing. All things being equal I would have preferred not to have gotten those
copies (although in some case it was amusing to see who was testing MIME
capabilities), but seeing as the spam I now get in a single day is probably an
order of magnitude greater than all the copies of these messages I ever
received put together, it is difficult to care very much.

Sample configurations are another matter entirely. We made the mistake of using
our domain in one or two such examples in product documentation, with the
result in one case that we were hit with quite a number of queries. This was
sufficiently annoying and we took note and never did that again.

My conclusion based on my own experience is that use of "proper" example
domains in sample configurations definitely rises to the level of a strong
SHOULD. Test objects and vectors warrant a weak SHOULD at most, in the email
subcase at least. But random sample email messages and dialogs have been a
nonissue and there warrant no special compliance.

Just a little data in support of evidence-based engineering.

				Ned

P.S. Based on the ongoing misunderstanding of the situation apparent in several
recent postings I feel compelled to reiterate that the appeal is almost
entirely about the nature of our process, not about the resolution of domain
usage in 2821bis. As for the process part of this, I've been trying very hard
to stay away, mostly because i find the fact that it was necessary for John to
file this appeal to be so utterly appalling that I don't entirely trust myself
to be able to engage in civil discourse about it.
_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf