John:
As others have pointed out, you are missing the _only_ thing
that I consider to be really important. In addition, we
disagree about some of the details as you have presented them.
You can consider this note an addendum to the appeal text if you
like.
The first issue is that, as several others have pointed out, the
key issue in the appeal isn't about the 2606 names, it is about
what I believe to be abuse of process and authority.
Regardless of what actually made it into documents, there was
very clear consensus in POISSON, in NEWTRK, and in the PESCI
effort, which is that the community is opposed to imposition of
new requirements on documents after Last Call and by the IESG
during IESG review. There was also clear consensus that the
community considers such actions, and the frustration and delays
they introduce, harmful to the Standards process and
inconsistent with a fair and open process.
I agree with this principle. In fact, I think that the IESG has
taken many steps over the last four or more years to reduce the
nearly-end-of-process surprises. Obviously, you do not think these
measures have been sufficient. One lesson from the many attempts to
make updates to RFC 2026 is that such policy documents needs to set
expectations without taking away flexibility and judgement.
While that community consensus has never appeared explicitly in
a BCP or other document with equivalent force, it is nonetheless
clear to many of us. One reason it has not appeared is that it
would be hard, or impossible, to write a specific and
appropriate rule where _technical_ issues are involved:
sometimes, one comes up late in the process and sometimes it is
legitimate and worth attention to the point of blocking a
document. Even in those cases, the community has seemed to
feel quite strongly that everything reasonable should be done to
avoid the issues showing up only because an AD raises them after
last call. For an essentially stylistic or documentary issue,
it appears to me that there is no excuse for continued late
actions and assertions of rules, even if those rules were
reasonable.
Your own discussions of this topic, both before and after the
appeal was filed, reinforce the view that this is not a
technical issue or, to paraphrase Brian's early comment, a
judgment call about the likelihood of confusion. There is no
issue of confusion here. Others have made the point that the
claim of harm is, at best, dubious.
The fact that the IESG has done something before, even regularly
before, does not make raising the issue after Last Call any less
"new", unless you actually believe that it is the responsibility
of every author, editor, or WG in the community to study
previous IESG decisions, deduce patterns from them, and then
infer the rules that are to be followed. I don't think that
position is tenable with regard to previous community
discussions about "late surprises". I also take the existence
of extensive guidelines and checklists as an indication that the
IESG doesn't believe it either, but perhaps you disagree.
As you said in your note, we disagree on the details. I have
forwarded the text to the list that shows that the issue was raised
during IETF Last Call. Meaning, it was not a late surprise.
I agree that the community should not have to watch IESG decisions to
infer trends. In this case, the ID Checklist already includes a
SHOULD statement. It could be more clear. More about that below.
In that context, there were at least two ways that this appeal
could have been avoided. I tried to be explicit about both:
(i) Had the blocking DISCUSS been removed and changed to
a comment, I would have reviewed the names in the
document with the mailing list and, unless they
objected, changed most or all of them. My objection is
primarily to the blocking DISCUSS itself, although I'll
review the issue with the specific names below.
Yes, you made this offer. You said that the DISCUSS needed to be
change to a COMMENT or you would appeal. Instead, I rewrote my
DISCUSS position to be clear that the domain names associated with
the tribute to Jon were not included in the DISCUSS position. The
Data Tracker clearly shows this part of the history.
(ii) Had you or the IESG said "yes, it is inappropriate
for us to insist on a blocking requirement for the 2606
names without documenting that fact, we will change,
e.g., the 'I-D Checklist' to clearly indicate that they
are required in the absence of an explicit IESG waiver",
then we would not be having this discussion at all. We
might well be having a discussion about whether that
change to the I-D Checklist rules was appropriate, but
that is exactly the discussion, IMO, that we should be
having. Instead, it appears from where I sit that the
IESG generally, and you in particular, have chosen to
impose the rule but avoid a community discussion of
whether that rule is appropriate by keeping the rule
--as a blocking issue, rather than a preference to be
interpreted by authors, editors, and WGs/ mailing
lists-- secret. And that is _exactly_ what years of
discussion about process have told the IESG to not do.
I believe this action was taken. First, Magnus Westerlund agreed to
write an IESG statement on this topic. This action item is clearly
documented in Section 1.3 of the minutes from the IESG Telechat on
May 22nd ( https://datatracker.ietf.org/iesg/telechat/391/ ). Second,
on June 9th, Bert Wijnen agreed to make updates to the ID Checklist
when he returned from vacation. Your appeal was submitted on Friday,
June 13th, after these actions had begun but before either was ready
for community review.
I believe that there is also clear community consensus,
expressed many times in WG and IETF List discussions, that they
IESG should follow the rules, whether those rules are explicit
in 2026 or its successors or are rules set by the IESG for
itself.
I had taken the very existence of the "DISCUSS criteria" and
"I-D Checklist" documents as evidence that the IESG understood
that community consensus and was trying to improve things by
getting the rules written down and open to community discussion
where needed, rather than playing 'gotcha' with WGs, document
authors, and the community. I applauded both. This appeal was
made necessary precisely because that conclusion appears to have
been incorrect unless the IESG is constrained to actually follow
the rules it writes done and to write down the rules it expects
to follow.
Several people have suggested to me, both before and after the
appeal was posted, that I not raise an appeal about the 2821bis
issue at all but simply appeal the process problem, thereby
avoiding the confusion that has appeared in many messages to the
list in recent days, including yours. Others have suggested
that this appeal should have gone directly to the ISOC BoT as a
demonstration that existing procedures, as the IESG chooses to
interpret them, are insufficient to ensure a fair an open
process. I do not believe that either of those approaches is
unambiguously permitted under RFC 2026. While I can certainly
read 2026 as permitting them, I can also see how applying either
one could result in rejection of the appeal on procedural
grounds while we all go into the rathole of a debate about what
2026 really says and means.
I agree that mixing the two issues in one appeal has made the two
issues more difficult to process by the IESG and more difficult to
discuss on this thread.
Instead, the appeal is based on a specific action (the DISCUSS
on 2821bis), claims that it violates the process and clear
community intent, and claims that the fact that this case has
arisen demonstrates that the current procedures are not
sufficient to protect a fair and open standards process. The
last of these isn't about 2821bis at all; it is about whether
the IESG is permitted to make up editorial and stylistic rules
after Last Call on a document, or to have long-standing rules
that it doesn't tell the community about, and then to use those
rules to block documents. I believe that it cannot do so if we
are to have a fair, open, and efficient standards process in the
IETF. You apparently disagree. I trust that this appeal will
help to resolve that issue.
I do not disagree. I think the two actions initiated before the
appeal was submitted clearly illustrate the opposite.
However, even on the specifics of the 2821bis issues, we
obviously disagree. More on that below.
--On Wednesday, 18 June, 2008 22:35 -0400 Russ Housley
<housley@xxxxxxxxxxxx> wrote:
>...
> You are missing a few things that I consider to be relevant
> and important.
>
> - We're talking about rfc2821bis (not RFC 2821 or RFC 821).
>
> - The examples in RFC 821 use different domains from the ones
> in RFC 2821.
Yes, and the decision to make those changes, and what to change
them too, were explicit decisions in the DRUMS WG. The examples
in 2821bis are not different from the examples in 2821, and that
actually is important here.
This is not true! Look a section 4.3.1.
RFC 2821 includes this example:
220 ISIF.USC.EDU Service ready
or
220 mail.foo.com SuperSMTP v 6.1.2 Service ready
or
220 [10.0.0.1] Clueless host service ready
draft-klensin-rfc2821bis-10 includes this revised example:
220 ISIF.USC.EDU Service ready
or
220 mail.example.com SuperSMTP v 6.1.2 Service ready
or
220 [10.0.0.1] Clueless host service ready
Frankly, I took this as an indication that the updating of the
examples had begun, but was done incompletely. In fact, it was this
section that was highlighted in the SecDir Review comments that were
raised in IETF Last Call.
> 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.
There are at least two issues here, both of which have been
discussed at length on the list. To summarize my view of them
(borrowing somewhat from the examples in another note):
I live in a community in which any change to a building may lead
to a requirement that I bring that system of the building up to
contemporary codes. My neighbor is free to continue to use his
fuse box, but any update to any part of his electrical system,
even replacing an outlet or light fixture or adding a circuit
for which the fuse box has space, may lead to a regulatory
demand that he upgrade his entire system back to the service
entrance and install contemporary equipment including GFIs and
arc protectors. As one might imagine, this sort of policy has
some bad effects (and it has been imposed much less often in
recent years than a few decades ago). But, even here, no one
thinks that I should be required to replace my electrical system
if I repair a toilet.
2821bis contains only those changes that the mailing list (and a
few years of comments before the revision effort formally
started) believed were needed to clarify the document. It
carefully does not contain changes made for purely stylistic
reasons. The argument that, because some changes were made,
changes should be required to "update" examples that were
completely unaffected by those substantive changes is very much
like the argument "you fixed a toilet, therefore you must update
all of the electrical systems to contemporary standards before
we give you permission to occupy the house". Even if the
principle had merit --which I suggest that it does not-- it is
undesirable to apply it because it is disproportionate,
unnecessary, imposes risks, and ultimately discourages people
from trying to advance documents along the standards track.
Each of those negative factors has been discussed in other notes
to this mailing list; I will not repeat them.
Interesting analogy. I could not have figured out this motive given
the diff between this document an RFC 2821. It is far from
minimal. In fact, two text samples above show the introduction of
additional blank lines. To me, that is a style change.
> 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.
As others have pointed out at some length, the statement in
IDNits apply a "SHOULD" to the use of fully qualified domain
names and only a (lower case) "preferably use" to "example
fqdns". So, once again, unless the IESG insists that the
community is either required to read its collective mind or that
we all read the history of IESG decisions and apply some sort of
exegesis to derive the rules, this is completely irrelevant.
As I said earlier, actions have begun to add clarity.
> This document uses "isif.usc.edu" and "postel@xxxxxxx" as
> examples. The authors want to leave these as a tribute to
> Jon. Fine. I think the implications of these are well
> understood.
Independent of what you were told, or thought you were told, by
the Proto shepherd, the decision made by DRUMS, and reaffirmed
by the mailing list considering 2821bis, was to preserve Jon's
examples to the extent possible, not to preserve (only) those
two examples. However, because it obviously cannot be repeated
enough times, that is not the issue here. The issue is the
imposition of a blocking "surprise" requirement by the IESG.
That does not match the message I got from the PROTO shepherd.
> 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.
Others have addressed this comment and ones like it but, to
repeat: I believe that the community has told the IESG many
times that late imposition of requirements on documents are
undesirable and that, if they cannot be avoided, they require
significant justification. This is a late requirement, no
matter how many times the IESG has applied it in the past, and
you have offered no evidence of harm. The strongest claim you
made in our correspondence was "rude". In addition, several
people have now offered concrete data that there is no evidence
of harm in the specific cases covered by 2821 or 2821bis. The
mere absence of complaints to the IETF about 2821 strengthens
their case. You suggest above that harm has occurred in other
places (other than the NTP example), but have not identified
those cases, especially sufficiently to overcome the presumption
of seven years of experience with 2821. As others have
suggested, there is a huge difference between examples of syntax
and operation and example configuration files (including the NTP
case).
I agree that this aspect of the issue has been covered very
completely on this thread already. Saying more will simply be
repeating things that have already been said more than once.
> 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.
Again, unless the IESG is willing to take the position that the
community is expected to review its previous decisions to deduce
the rules that will be applied, this is irrelevant. In
addition, and precisely relevant to the issue of whether a fair
and open process is operating here, there is evidence that at
least some of the domain name changes imposed by the IESG as
above were coerced in the sense that the requirement to get a
document out rather than engaging in an extended discussion with
the IESG overcame any desire to resist this type of demand.
Again, I believe the appropriate actions have already been
started. So some extent, we cannot avoid people sharing stories
about things that worked or didn't for them. This is human
nature. However, when we identify a defect in the documentation, we
do try to correct it.
Finally,
--On Thursday, 19 June, 2008 13:50 -0400 Russ Housley
<housley@xxxxxxxxxxxx> wrote:
>> 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?
If you review the archives of discussions about IETF process
matters, you will find that I've consistently been one of the
strongest advocates of giving the IESG considerable discretion
and latitude in technical matters. I do not believe it is
possible to anticipate or enumerate every case, and I believe
that attempting to do so just gets us into large problems.
However, stylistic issues --the form, organization, and content
of I-Ds and RFCs are a different matter. If the IESG cannot
identify the relevant rules and be explicit about them, then
either those rules are not important enough to enforce on a
blocking basis or they should have been written down long ago.
The fact that you can argue that 2606 names have been fairly
consistently for five or more years is an argument that they are
not a matter of technical judgment that requires discretion but
that they are like all of the materials that IDNits identifies
as "required".
We are in agreement. I have been working toward incremental
improvement since becoming IETF Chair.
Alternatively, you can claim that you are applying a technical
judgment in this case, a judgment that the IESG needs the
flexibility and discretion to discover and apply. But that is
inconsistent, IMO, with the claim of consistent reinforcement of
a rule... and I believe that the community has said that it
requires case-specific justification, for which "well, this
causes harm in some unrelated situation" or "it is rude" are,
IMO, insufficient.
I believe that you can't have it both ways, at least consistent
with a fair and open process, much less one that is focused on
efficiently moving documents through the IETF unless significant
problems are found.
We cannot get it all done in one day. It ought to be clear at this
point that actions were initiated even before your appeal was
submitted. You may or many not agree that these actions are
sufficient. In fact, in your position, I'd hold judgement until the
proposed text is available.
I find we agree on more than we disagree,
Russ
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf