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

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