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@xxxxxxx" 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf