Dave:
I'm not sure I did a wise thing by joining the discussion, but in for
a penny, in for a pound ...
- The examples in RFC 821 use different domains from the ones in RFC 2821.
Where are the reports of problems with with that aspect of RFC 2821?
Changes from Proposed to Draft are expected to be for fixing minor,
actual problems with the specification, and they are quite clearly
*not* for revisting old issues or playing around with new preferences.
The first hint of this issue surfaces during Last Call. It was one
small paragraph in the SecDir Review, but a casual observation might
have missed it due to the volume of discussion around A and AAAA DNS
records. The SecDir Review said:
- "isif.usc.edu" is used as an example in section 4.3.1. Some of the
examples in the appendices also use non-example hostnames.
Personally, I don't care, the meaning is obvious and inoffensive,
but since some of the examples have been rewritten in terms of
example.com etc, this may have been an oversight.
When I highlighted this paragraph, the document PROTO shepherd
pointed out that the "isif.usc.edu" and "postel(_at_)isi(_dot_)edu" were left
in
the document as a tribute to Jon. No one has objected to this. This
lead to a discussion of the domain names in the rest of the document.
If the document were being advanced to Draft Standard with no
changes at all, then I think it would be unreasonable to anyone ask
for a change to address this issue. However, other changes were
deemed necessary. Given that situation, it seems appropriate to
consider current guidance. This guidance is referenced in the
appeal. The I-D Checklist (IDnits,
http://www.ietf.org/ID-Checklist.html), Section 6, says:
Addresses used in examples SHOULD preferably use
fully qualified domain names instead of literal IP
addresses, and preferably use example fqdn's such as
foo.example.com instead of real-world fqdn's.
1. When did the nits list gain authoritative control as a source
directive for normative detail of IETF specification content? I was
under the impression that it was strictly a compendium of
requirements from elsewhere.
2. You parsed the sentence incorrectly. The SHOULD applies only to
the first clause. The second clause notably repeats the
"preferably" but without the SHOULD. This type of parallel
constructive is used quite explicitly to set a different context
between clauses. Hence the second clause is not normative. (The
term "SHOULD preferably" also suggests some problematic -- or at
least odd -- writing, given the semantics of the SHOULD.")
Upon detailed study, I see that the paragraph could be more
clear. I've asked the author if he is willing to propose revised
text. Vacation schedules will keep this from happening in the next few days.
RFC 2119 has a pretty clear definition of "SHOULD". It says:
This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
Absent any explanation from you, you appear to be treating SHOULD
the same as MUST.
I think I provided my thinking in the previous message.
As John noted, there was extensive Drums wg consideration of this
topic. This means that your requirement for changing the examples
seeks to override the explicit considerations of an IETF working group.
If you feel that group was rogue, please explain. If you do not,
what is the basis for your view that its considerations were
sufficiently faulty to warrant being overridden?
Prior to the appeal, this aspect of John's rationale was not
raised. It was not raised by John, the document PROTO shepherd, or
the IESG member sponsoring the document.
And most importantly, why is not of this explanation already
documented in the tracker?
Since this issue has been use in DISCUSS ballot positions for more
than 5 years, it seems to me like there is adequate context to not
document every step in the though process.
This document also uses "foo.com", "foo.org", "bar.org",
"foo-u.edu", and "generic.com" in examples. I have not heard
anyone offer "valid reasons" for using them instead of the ones in
BCP 37. I have heard people say that they are not causing
harm. That is not the same. We have seen examples that use real
IP addresses and domain names cause harm. The excessive traffic
sent to one NTP server comes to mind.
First is the use of "valid", which implies there are arguments
deemed invalid. Which arguments are you dismissing and why? Since
the ietf list discussion has seen serious arguments put forward by
serious and experienced contributors, my question is not merely pro forma.
Second is the logic error that some examples of harm elsewhere are a
sufficient basis for requiring the current change, independent of
the *absence* of problems with this heavily-used specification. The
direct absence of problems constitutes positive data in favor of
retaining the current text in rfc2821bis.
Why should your indirect negative data override the direct positive data?
You misunderstand my point. RFC 2119 uses "valid" in the definition
of "SHOULD." That is the reason for quote marks in my text.
Prior to the discussion of the appeal on this thread, lack of harm in
this context was not raised. It was not raised by John or the
document PROTO shepherd. This might be a reason to ignore the
"SHOULD." That is a discussion could have happened, but it didn't.
The IESG has been using DISCUSS positions since before 2003 to
remove real domain names. I'm sure that some have slipped
through. A couple have been pointed out in this thread.
Yet, for all of the IETF's formal documentation of technical and
stylistic requirements, we do not seem to have any community
consensus document -- and not even an IESG document -- that
justifies asserting this as a requirement.
That seems to be the crux of the appeal. Does every possible thing
upon which an AD can raise a DISCUSS position need to align with a
written rule? Don't we select leaders because we have some
confidence in their judgement?
Russ
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf