Subject: RE: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

From: John C Klensin <[email-masked]>
Date: Sat, 14 Jun 2008 13:11:09 -0400

--On Saturday, 14 June, 2008 10:44 -0400 Eastlake III
Donald-LDE008 <[email-masked]> wrote:

> Standards track RFC 4343 was issued within the past five years
> (January 2006 to be precise). It contains some example domain
> names that do not follow the suggestions in RFC 2606 as well
> as some that do. As the author of both RFC 2606 and RFC 4343,
> I believe the domain names reserved in RFC 2606 were intended
> to be encouraged but not mandatory.

Donald,

Thanks.   The fact that those recommendations have not been
consistently been treated as mandatory doesn't really affect the
core of the appeal, but it further weakens any claim that this
behavior is ok based on a consistent (even if unpublicized)
pattern of prior IESG behavior and decision-making.

best,
   john

p.s. while I appreciate the comments I've received expressing
support for this appeal, I'm generally not going to respond to
them on-list lest the IESG interpret the comments as part of a
lobbying effort.   The procedures say that appeals go to the
IESG and the IESG decides (then they may go elsewhere).  I don't
believe that there is any prohibition on the IESG's asking for
community input if they want it, but they are certainly under no
obligation to do so or to consider such input as part of
considering the appeal.   This note is an exception only because
it identified a fact I didn't have available when I wrote the
appeal text.

_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Jun 2008 10:00:02 +1200

Regardless of John's P.S., I'd like to make some comments
that the IESG may wish to consider:

> pattern of prior IESG behavior and decision-making.

I think one can make a case that in some documents, use of non-RFC2606
names as examples is a purely stylistic matter, and that in others,
it would potentially cause technical confusion. I'm not asserting which
applies to 2821bis, but I do assert that there is scope here for
a judgement call and therefore the inconsistency is understandable.

In the evaluation record for what became RFC4343
(https://datatracker.ietf.org/idtracker/ballot/1612/) we find:

"Editorial issues:

 - the document uses a number of non-example.com/192.0.2.0
   addresses/names, but in this case this seems justifiable"

In other words this *was* a judgement call. [For the record:
I ballotted NO OBJECTION on RFC4343.] I regard the DISCUSS
that John is appealing against as a judgement call. It isn't clear
to me that it's a stylistic or editorial comment by construction.

To the underlying process issue, a DISCUSS based on a judgement call
is always a little tricky. However, if the document shepherd can show
that the call made in the draft was an explicit rough consensus, it
does seem like the sort of case where the DISCUSSing AD might choose
to switch to an ABSTAIN.

I strongly agree with John's suggestion that ADs should clearly distinguish
a comment where they really want discussion from something that they view
as a sticking point. One of the cleared DISCUSSes on 2821bis starts thus:
"This is a discuss discuss question....". Is that clear enough?

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Jun 2008 13:23:28 +1200

Dave,

On 2008-06-16 11:44, Dave Crocker wrote:
> Brian E Carpenter wrote:
> Actually, Brian, scope is exactly what this judgment call is out of.
> 
> The underlying question is whether rules matter in the IETF or whether
> the IETF is subject to whatever ADs feel like declaring at the moment.
> 
I doubt if anyone would disagree.

> If rules do matter, then the IESG needs to follow them.  In very
> concrete terms, the IESG needs to be constrained it its application of a
> Discuss to matters of serious import and to document the basis for an
> application of a Discuss.

Which, in fairness, the IESG has documented, in the DISCUSS criteria
document and generally in practice, over the last several years.
The question surely is whether the IESG failed to do so in this case.
> 
> The current case has an AD asserting a Discuss by claiming a rule that
> does not exist.  That's not judgment call, that's invention.

I haven't seen all the email in this case, so I don't know exactly
what has and hasn't been claimed as a rule. 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).
That may or may not be a valid conclusion. However, one of the two
DISCUSS comments points out that at least 3 of the domains used are
real ones. So the issue of confusion is a real one. What I am
saying is: these DISCUSSes are about a technical issue. They may or
may not be reasonable, but I object to the suggestion that they are
stylistic or editorial (which would automatically make them out of
scope under the IESG's own document).

> Even better is that application of this invented rule on a revision to
> an established standard represents an orientation towards change that is
> de-stabliling rather than helpful.

I don't think that changing foo.com to foo.example.com would
destabilise the email system too much.

    Brian

> 
> With that combination, you can't get much more out of scope.
> 
> d/

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 16 Jun 2008 09:27:27 -0500

Brian,

	As a matter of personal preference, I would very much 
prefer not to see process constructions that require repeated
use of the status in order to disambiguate the meaning of the
status.  In other words, having to clarify that a DISCUSS is 
(really) a discuss (and presumably not something else) is not
the way to clear things up - not even "clear enough."

	Either DISCUSS means what it implies (maybe we add some
separate status for BLOCK), or we change the state name to an
intentionally more ambiguous name (like HOLD, or PENDING).

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brian E Carpenter
> Sent: Sunday, June 15, 2008 6:00 PM
> To: John C Klensin
> Cc: [email-masked]; [email-masked]
> Subject: Re: Appeal against IESG blocking DISCUSS on 
> draft-klensin-rfc2821bis
>

---

From: Pete Resnick <[email-masked]>
Date: Mon, 16 Jun 2008 10:20:44 -0500

On 6/16/08 at 10:00 AM +1200, Brian E Carpenter wrote:

>I think one can make a case that in some documents, use of 
>non-RFC2606 names as examples is a purely stylistic matter, and that 
>in others, it would potentially cause technical confusion.

Please make that case if you would, because the example you give:

>In other words this *was* a judgement call.

...quite specifically said it was an "Editorial issue". Please 
explain the circumstance in which it would not be an editorial issue.

Of course, the ballot in this particular case 
<https://datatracker.ietf.org/idtracker/ballot/2471/> makes no claims 
about "technical confusion". I assume that when no "technical 
confusion" exists, you *would* consider such things "an editorial 
issue"? (A misplaced comma or the use of the passive *may* cause 
"technical confusion", but unless this is called out, the assumption 
is always that such things are "editorial issues".)

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Tony Hansen <[email-masked]>
Date: Mon, 16 Jun 2008 11:32:20 -0400

+1. Does "this is a discuss discuss question" mean that "I just want to 
discuss this, it's a nit, don't worry" or does it mean "we ABSOLUTELY 
MUST DISCUSS this and nothing's moving until we do!" Without other 
context, you don't know.

	Tony Hansen
	[email-masked]

Eric Gray wrote:
>> I strongly agree with John's suggestion that ADs should clearly
>> distinguish a comment where they really want discussion from
>> something that they view as a sticking point. One of the cleared
>> DISCUSSes on 2821bis starts thus: "This is a discuss discuss
>> question....". Is that clear enough?

---

From: Robert Elz <[email-masked]>
Date: Mon, 16 Jun 2008 15:51:15 +0700

Date:        Mon, 16 Jun 2008 13:23:28 +1200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | Which, in fairness, the IESG has documented, in the DISCUSS criteria
  | document and generally in practice, over the last several years.

The IESG is free to document their own procedures, that's a good thing.

They're not free to invent rules for the IETF, that's for the IETF as
a whole.   What gets a document approved is IETF rough consensus, that's
been the IETF rule for years.   If there's any real question whether this
revision has IETF consensus or not, then it should be blocked.   If there's
no question as to that, then it should be approved - after all, the IETF
would (under that assumption) have approved it, along with all of its
examples.   If the example domain names were really an issue to anyone,
that would have been raised during last call.   At that point, whether or
not rough consensus existed to continue with the doc as it was could have been
judged.

Even if we had a rule that all domain names in RFCs must be from the reserved
set (which we do not) the IETF has the power to change its rules.   That can
be done in general, or on a case by case basis.   Raising the issue during
last call, and having the IETF decide to ignore the problem for the doc in
question would be all that is required to set aside the rule for that doc.

But we have no such rule, there's never been a last call on anything that
says that all domain names in examples in RFCs must be from the set
documented in 2606, so the issue should not even arise.   If there ever were
such a last call, you can expect I'd be an vociferous opponent, as rules
like that make no sense at all.   There are perfectly good reasons for those
domains to exist, and very definitely places where they should be used,
but this is not one of those cases.

  | I don't think that changing foo.com to foo.example.com would
  | destabilise the email system too much.

Of course it wouldn't break e-mail, but it would make following the RFC
sequence, and working out what changed, and why, much more difficult.

Further, when dealing with something which necessarily deals (or should)
deal with many different domain names (like e-mail does), constraining
the examples to be from just a small set or (seemingly relayed) names would
do a disservice.   Sure, you and I know that the "example" in foo.example.com
is meant to be ignored, and isn't there for any particular purpose, but can
you expect that every reader of the doc will understand that.

Even if there was an "only those domain names" rule, and there was a good
reason for having that (neither of which is actually the case), there would
be a good case for ignoring it for this one doc.   If the "real" domain names
used in this doc are a problem to the owners of the domains, I have no real
doubt but they would be changed upon request, so that straw-man objection
can be ignored.

I have no idea which AD has the arrogance to put their own view of what
the IETF rules should be above the stated desires of the IETF as a whole
(as determined by the last call), but whoever that is really ought to
consider resignation as an honourable way out of the mess they're creating.

kre

---

From: "TSG" <[email-masked]>
Date: Mon, 16 Jun 2008 14:38:14 -0800

FYI - ALL of the commentary submitted to the IESG must be done so through a 
process which includes it in the archive of that IP initiative or the IETF 
will see itself in a world of hurt the first time it is litigated against 
and it cannot produce documentation showing all of that material happened in 
the open.

Todd Glassey

----- Original Message ----- 
From: "Brian E Carpenter" <[email-masked]>
To: <[email-masked]>
Cc: "John C Klensin" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Sunday, June 15, 2008 5:23 PM
Subject: Re: Appeal against IESG blocking DISCUSS on 
draft-klensin-rfc2821bis

---

From: "TSG" <[email-masked]>
Date: Mon, 16 Jun 2008 14:40:20 -0800

----- Original Message ----- 
From: "Robert Elz" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: "John C Klensin" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Monday, June 16, 2008 12:51 AM
Subject: Re: Appeal against IESG blocking DISCUSS on 
draft-klensin-rfc2821bis

> The IESG is free to document their own procedures, that's a good thing.

No they are NOT. The IESG's processes MUST also be transparent just like the 
IETF's or they risk creating liability for their sponsor's that NONE of 
those sponsor's will be too happy with.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jun 2008 09:42:18 +1200

Pete (and Dave Crocker),

On 2008-06-17 03:20, Pete Resnick wrote:
>> names as examples is a purely stylistic matter, and that in others, it
>> would potentially cause technical confusion.
> 
> ...quite specifically said it was an "Editorial issue". Please explain
> the circumstance in which it would not be an editorial issue.

Well, I've seen *many* cases of disagreement whether a particular
issue was editorial or substantative, so I wouldn't claim that there
is any absolute standard here. And I've been trying not to comment
on the specific issue of 2821bis, because I have not reviewed
it in detail and make no claim to expertise. Nor am I commenting
on whether the specific DISCUSS comments in this case are reasonable
or not and whether they are well-formulated or not.

If a real domain name, or a real IP address, or a real IP prefix,
is used as an example in code, pseudo-code, or in the description
of a configuration mechanism, there's a good chance that it will
end up in an actual implementation or in an actual configuration
file one day (far from the IETF). In my opinion that is a source
of technical confusion and possibly of unwanted traffic. So I think
there is a strong argument that RFC 2606 values SHOULD be used
whenever reasonably possible.

That's my opinion; I'm not asserting that it's an IETF consensus
or that it necessarily applies to 2821bis. But I do assert that
it's a technical argument and not an editorial one.

   Brian

> about "technical confusion". I assume that when no "technical confusion"
> exists, you *would* consider such things "an editorial issue"? (A
> misplaced comma or the use of the passive *may* cause "technical
> confusion", but unless this is called out, the assumption is always that
> such things are "editorial issues".)
> 
> pr

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 17 Jun 2008 00:57:55 +0200

Brian E Carpenter wrote:

> That's my opinion; I'm not asserting that it's an IETF
> consensus or that it necessarily applies to 2821bis.

+1

Some things I'd consider:

RFC 821 used foo.arpa and similar examples, and it won't
surprise me if the author knew precisely why this can
never have any undesirable side-effects.

As explained by John RFC 2821 switched to foo.com.  All
address harvesters looking for strings with an "@" have
found it years ago, nothing 2821bis will do can fix it.

Or the opposite effect, the RFCs listed in RFC 3092 might
have contributed to a better page rank of foo.com, maybe
the current owner has no problem with the overall effect.

Whatever 2821bis does, it cannot change the good or bad
caused by RFC 2821 and other RFCs.  Therefore the issue
is at first glance purely editorial.

*BUT* 2821bis will be one of the most important RFCs for
many years - assuming it goes "as is" to STD - and many
readers, who will take it as gospel.  They will see the
foo.com examples, and use similar constructs for their
own examples.  They won't know or read RFC 2606, and if
they get push back they can say "but 5821 also does it".

Of course I'd ignore red lights when there's no traffic,
and I just want to cross the street.  And I'd be upset
if some "authority" tells me that I shouldn't do this.
But is it really necessary to ignore red lights in the
presence of kids who have no clue what can go wrong ?

 Frank

---

From: Dave Crocker <[email-masked]>
Date: Mon, 16 Jun 2008 08:05:47 +0100

Brian E Carpenter wrote:
>     However, I'm arguing that

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.

> That may or may not be a valid conclusion. 

And that's one of the issues that is that the meat of the appeal, as I read 
it:  The serious basis for the Discuss has not been documented, nevermind 
defended.  So we can debate all sorts of hypotheses about whether their might 
or might not have been a legitimate basis for this Discuss, and we would 
thereby miss the underlying issue.

> However, one of the two
> real ones. So the issue of confusion is a real one. 

1. Where is the rule prohibiting the use of real domain names?

2. This particular spec began life 25+ years ago using those names, so we 
ought to have solid data showing that that particular document's use of those 
names is a problem.  Where is it?

3. Where is the empirical substantiation that use of a real domain name in an 
  RFC spec causes problems with the development of interoperable implementations?

4. If you want to focus on a judgement call, how about focusing on the 
judgement that keeping specification documents stable, as much as possible, 
across their life, is important?

> What I am

Like any good technical issue, I'm sure you can document the real-world 
demonstrations of this as a problem and for this document?

Mostly what you are doing, Brian, is demonstrating that one can claim that 
anything is a technical issue.

> destabilise the email system too much.

Perhaps you are missing the point.

I guess that's a judgement call, too.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Mon, 16 Jun 2008 00:44:41 +0100

The underlying question is whether rules matter in the IETF or whether the 
IETF is subject to whatever ADs feel like declaring at the moment.

If rules do matter, then the IESG needs to follow them.  In very concrete 
terms, the IESG needs to be constrained it its application of a Discuss to 
matters of serious import and to document the basis for an application of a 
Discuss.

The current case has an AD asserting a Discuss by claiming a rule that does 
not exist.  That's not judgment call, that's invention.

Even better is that application of this invented rule on a revision to an 
established standard represents an orientation towards change that is 
de-stabliling rather than helpful.

d/
-- 

   Dave Crocker

---

From: Brian Dickson <[email-masked]>
Date: Tue, 17 Jun 2008 02:36:46 -0400

> presence of kids who have no clue what can go wrong ?

The issue at hand (the DISCUSS and appeal) is at odds with the AD's view,
regarding updating names used in examples versus RFC2606.

In the interests of resolving the issue while respecting both the desire 
to preserve
the text between 2821 and 2821bis, and to acknowledge that the examples used
aren't 2606-compliant and preserved only to avoid making too many changes to
a document with a long history/ancestry, what about a minor compromise by
both parties?

Here's my suggestion:

List 2606 in the informative references, and footnote the examples used 
to indicate
that they are "grandfathered" non-2606 examples.

So, in text that previously read "not-example.com", it might read 
"not-example.com [*]",
with the references section having "[*] Note - non-RFC2606 examples 
used. Please read RFC2606."

Something along those lines, should hopefully be enough to keep both 
sides happy, and resolve the DISCUSS,
and hopefully both set a suitable precedent *and* make moot the appeal.

YMMV.

Brian Dickson

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 17 Jun 2008 11:30:05 +0200

> and hopefully both set a suitable precedent *and* make moot the appeal.

I think this sounds like a good compromise, and it does improve the
document quality IMHO.  John, would this be an acceptable addition to
the document?

Thanks,
Simon

---

From: [email-masked]
Date: Tue, 17 Jun 2008 12:26:30 +0000

Sounds like a lot of work to me. In the era of xml2rfc, that could be error-prone as well. For the particular issue, having a notice in the Conventions section might do (it may be there already...). However, it doesn't address the fundamental issue raised by the appeal. 

I don't think the IETF wants to go the path of U.N.-sponsored treaty organization SDO's [if you have no clue what I am referring to, just ask Tom Taylor or Rich Shockey who would love to earn beers for telling about their experiences].  The goal is not just to negotiate a "settlement", but to fix the problem. We are engineers, after alll. 

Moreover, I do not think the "problem" is an individual, where the fix is "fixing" the individual. I would encourage everyone to re-read John's original post. The fundamental problem of not knowing what is critical and what isn't needs to be made clear, and via the IETF's accepted processes.
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Simon Josefsson <[email-masked]>

Date: Tue, 17 Jun 2008 11:30:05 
To:Brian Dickson <[email-masked]>
Cc:Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

Thanks,
Simon

---

From: Fred Baker <[email-masked]>
Date: Tue, 17 Jun 2008 09:43:00 -0700

On Jun 16, 2008, at 11:36 PM, Brian Dickson wrote:

> List 2606 in the informative references, and footnote the examples  
> used to indicate that they are "grandfathered" non-2606 examples.

It seems that this gives 2606 more weight than it claims. What it  
claims is, quoting its abstract:

    To reduce the likelihood of conflict and confusion, a few top level
    domain names are reserved for use in private testing, as examples in
    documentation, and the like.  In addition, a few second level domain
    names reserved for use as examples are documented.

in other words, the names are reserved, but there is no statement (on  
either page of the RFC) that the naming is exclusive. One *may* use  
such names, but one is not *required* to.

Footnoting and saying that they have been "grandfathered" asserts  
that there is such an exclusionary rule and this is an exception to it.

To my way of thinking, if you want to put something into the  
document, you want something like:

     The names in this document are consistent with RFC 2820/2821 and  
RFC 820/821.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 17 Jun 2008 15:50:02 +0100

Not being a expert on this but having briefly read the documents in
question, I agree with Brian.  This is not editorial. I would also add that
to go against an IETF BCP on the grounds of "well we have done so already
historically" does not make an argument for continuing to do so; errors
should be corrected when found, not endorsed.  If we are to pick and choose
which RFC's/BCP's we will take notice of what is the point of
standardization? On the face of things, and with my little knowledge, I
would say that the person within the IESG who has invoked the DISCUSS is
quite correct.

Feel free to try to change my mind.

Best regards

Debbie Garside

> Sent: 16 June 2008 22:42
> To: Pete Resnick
> Cc: John C Klensin; [email-masked]; [email-masked]
> Well, I've seen *many* cases of disagreement whether a
> particular issue was editorial or substantative, so I
> wouldn't claim that there is any absolute standard here. And
> I've been trying not to comment on the specific issue of
> 2821bis, because I have not reviewed it in detail and make no
> claim to expertise. Nor am I commenting on whether the
> specific DISCUSS comments in this case are reasonable or not
> and whether they are well-formulated or not.
>
> If a real domain name, or a real IP address, or a real IP
> prefix, is used as an example in code, pseudo-code, or in the
> description of a configuration mechanism, there's a good
> chance that it will end up in an actual implementation or in
> an actual configuration file one day (far from the IETF). In
> my opinion that is a source of technical confusion and
> possibly of unwanted traffic. So I think there is a strong
> argument that RFC 2606 values SHOULD be used whenever
> reasonably possible.
>
> consensus or that it necessarily applies to 2821bis. But I do
> assert that it's a technical argument and not an editorial one.
>
>    Brian
>
> >
> > confusion", but unless this is called out, the assumption is always
> > that such things are "editorial issues".)
> >
> > pr

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 17 Jun 2008 14:44:33 -0400

I fully agree with Debbie here.

Human experience teaches us that examples will
be used, over time. Foo.com is a commercial site. If the IETF uses  
foo.com in email examples,
it is reasonable to assume that foo.com will get unwanted traffic  
because of that. I think that
the IETF should not put itself in the position of causing avoidable  
pain to others, even if the likelihood of serious harm is small. Since  
there is a remedy, and it could be adopted readily, I think that the
discuss was reasonable and do not support the appeal.

Regards
Marshall

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 17 Jun 2008 14:54:43 -0400

On Tue, 17 Jun 2008 14:44:33 -0400
Marshall Eubanks <[email-masked]> wrote:

> pain to others, even if the likelihood of serious harm is small.
> Since there is a remedy, and it could be adopted readily, I think
> that the discuss was reasonable and do not support the appeal.

Yes -- and there's certainly case law to support the IESG's
position; the IESG has been insisting on this for years.

Now -- there are times when the stated policy just doesn't work.  I
recall one IPsec document where the example had to show several
different networks.  John's appeal stated that the WG considered and
rejected using the 2606 names; perhaps this is another case.  (I
haven't read the draft in question.)  Hoping the reader will notice the
difference between example.com and example.net, or even
bad-dog.example.com and good-cat.example.net, is just asking for
trouble.

So -- in general, I think the IESG's position is a good one, and
well-supported by custom; however, there are exceptions.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Robert Elz <[email-masked]>
Date: Wed, 18 Jun 2008 01:49:42 +0700

Date:        Tue, 17 Jun 2008 15:50:02 +0100
    From:        "Debbie Garside" <[email-masked]>
    Message-ID:  <049b01c8d089$6c901ce0$0a00a8c0@CPQ86763045110>

  | I would also add that to go against an IETF BCP

Huh?   The BCP in question says (in a bit more eloquent form)
"Here are some domain names that are reserved from all normal use,
and so are suitable for use in places where something with the
syntax of a valid domain names is required, but no real domain
name should be used - use them where applicable".

It does not say "you must use these domain names" (for any purpose
at all).

Where's the "go against an IETF BCP" here?

kre

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Tue, 17 Jun 2008 15:08:25 -0400

The reason that RFC 2606 was made a BCP was that, at the time, it was
felt that a document with that level or approval was needed to reserve
domain names in the global Internet. Alternatively, it could have been
done with a standards track document, but that seemed inappropriate.

As has been stated, there is nothing in RFC 2606 constraining IETF
documents.

Donald
Author of RFC 2602

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Elz
Sent: Tuesday, June 17, 2008 2:50 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: Appeal against IESG blocking DISCUSS on
draft-klensin-rfc2821bis 

kre

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Jun 2008 15:31:35 -0400

--On Tuesday, 17 June, 2008 11:30 +0200 Simon Josefsson
<[email-masked]> wrote:

>> List 2606 in the informative references, and footnote the
>> examples used  to indicate
>> So, in text that previously read "not-example.com", it might
>> read  "not-example.com [*]",
>> with the references section having "[*] Note - non-RFC2606
>> examples  used. Please read RFC2606."
>> 
>> Something along those lines, should hopefully be enough to
>> keep both  sides happy, and resolve the DISCUSS,
> I think this sounds like a good compromise, and it does
> improve the document quality IMHO.  John, would this be an
> acceptable addition to the document?

Simon,

I've responded to Brian off-list and continue in my
determination to not engage in a debate about the appeal itself:
under the procedures as I read them and as they have been
applied in the past, the IESG will decide however it decides.
However, unless they make it one by composing a statement or
appeal response and issuing a Last Call on it (I believe they
have the right to do that, but certainly not any obligation, and
it would be unprecedented), the appeal itself is neither a
community popularity contest nor a consensus call.  Remember
that 2026 does not even require that appeals be made public when
they are submitted.

Without endorsing them (the authors speak for themselves and
have written clearly), you might want to re-read any of several
recent notes and the appeal text: the core issue that motivated
the appeal was not whether or not these examples were to be
changed.  

Changing the examples (or not) has _never_ been the core
question.  If it were, I would have included a discussion of
compromise positions and counter-suggestions that had already
been offered.  Even with such a discussion, the appeal text
would have been much shorter. The core issue has to do with how
the IESG manages document reviews, whether the community likes
late surprises that could easily be avoided, how rules are
formulated and applied in the IETF, how AD judgments relate to
consensus in the IETF Community or applicable subgroups, and so
on.

As to Brian's suggestion, please consider the following, derived
from RFC3501 and hypothesize that, at some point, an RFC 2606bis
might be created (and go through the consensus process to BCP)
that offers special reserved names for newsgroups or mailing
lists as well as domain names (many of the arguments offered for
using only reserved domain names, including "rude to the
owners", would probably apply to newsgroups and other sorts of
network entities as well) and that included a form of Brian's
suggestion as normative.

RFC3501 now includes:

>    Example:    C: A002 LSUB "#news." "comp.mail.*"
>                S: * LSUB () "." #news.comp.mail.mime
>                S: * LSUB () "." #news.comp.mail.misc
>                S: A002 OK LSUB completed

Now, suppose, per Brian's suggestion, that were changed to 

   Example:    C: A002 LSUB "#news." "comp.mail.*" *
               S: * LSUB () "." #news.comp.mail.mime
               S: * LSUB () "." #news.comp.mail.misc
               S: A002 OK LSUB completed
or

   Example:    C: A002 LSUB "#news." "comp.mail.*" [Foobar]
               S: * LSUB () "." #news.comp.mail.mime
               S: * LSUB () "." #news.comp.mail.misc
               S: A002 OK LSUB completed
or

   Example:    C: A002 LSUB "#news." "comp.mail.*"   [1]
               S: * LSUB () "." #news.comp.mail.mime
               S: * LSUB () "." #news.comp.mail.misc
               S: A002 OK LSUB completed

any of which would be consistent with what I interpret as the
spirit of Brian's suggestion, with the "*", "[Foobar]", or "[1]"
being anchors for a reference or footnote.

Now _that_, folks, is confusing, since a reasonable reader might
have trouble figuring out whether the footnote/reference anchor
was part of the IMAP syntax and example or not.   It would be so
confusing that I'd argue that it involved a substantive issue,
rather than an editorial/stylistic one as Brian Carpenter
suggests sometimes occurs.  I'd expect people to notice it
during Last Call and complain, and I'd think an AD would be
entirely justified in asking hard questions and forcing
discussions.

Whether the examples in 2821bis are like that case simply
because they fail to use 2606 names is something that you should
judge for yourselves.  But, because of possibilities that the
examples above illustrate, be careful what you wish for.

     john

---

From: Pete Resnick <[email-masked]>
Date: Tue, 17 Jun 2008 14:32:10 -0500

I first want to re-iterate what Eric posted earlier: Please read the 
appeal. The *very minor* issue of the appeal is whether or not to use 
2606 names. It is the use of the DISCUSS in this case that is at 
issue. That said:

On 6/17/08 at 2:54 PM -0400, Steven M. Bellovin wrote:

>On Tue, 17 Jun 2008 14:44:33 -0400 Marshall Eubanks 
><[email-masked]> wrote:
>
>>On 6/17/08 at 3:50 PM +0100, Debbie Garside wrote:
>>
>>>Not being a expert on this but having briefly read the documents 
>>>in question, I agree with Brian.  This is not editorial.
>>

Either Marshall or Debbie is going to have to explain this to me: 
Why, IN THIS DOCUMENT, is this not an "editorial issue". Nothing said 
so far that we can attribute to the IESG says anything like, "there's 
a technical issue here". Please, someone give any indication that IN 
THIS DOCUMENT, there is any hint of technical mistake that will be 
made because a domain name other than "example.com" or "example.org" 
is being used.

And for the record:

>>>I would also add that to go against an IETF BCP on the grounds of 
>>>"well we have done so already historically" does not make an 
>>>argument for continuing to do so; errors should be corrected when 
>>>found, not endorsed.

John did not "go against an IETF BCP". This is not an "error" to be 
"corrected". The BCP in question gives *an option* to use particular 
names, not a requirement. There are plenty of BCPs that make all 
kinds of suggestions, and some we take and some we don't. There is no 
"MUST" in 2606; it is up to the discretion of the user whether using 
2606 domain names suits a particular purpose. And in this case, the 
DRUMS working group made an explicit decision back in 2001 to choose 
something different in this document.

>>Human experience teaches us that examples will be used, over time. 
>>Foo.com is a commercial site. If the IETF uses  foo.com in email 
>>examples, it is reasonable to assume that foo.com will get unwanted 
>>traffic  because of that.

There has been no evidence, in 7 years of 2821 being available, that 
such has been the case. I don't see why you would say that it is 
"reasonable to assume" that. This is not a MIB or the like, where 
people will be copying this info into configuration files.

>position; the IESG has been insisting on this for years.

Let's assume you're both right. Let's assume that it's better (for 
some values of "better") to use 2606 domain names in 2821. Let's 
assume that it is easy (for some values of "easy") to put those names 
into 2821bis. Let's assume that "the IESG has been insisting on this 
for years." None of that matters:

The DRUMS working group (which produced 2821 *after* 2606 came out) 
made a conscious decision at the time not to use those names. (It is 
documented in the archive.) The original document passed the IESG at 
the time without those names (while 2606 was out), and one must 
assume that the IESG at that time made the conscious decision that 
the working group consensus on this point was sufficient to leave 
those names in 2821. To STOP the document now (and that is what the 
AD in question has said about the effect of the DISCUSS) with *no 
technical justification* of why an explicit working group decision 
should be reversed (there has been none given) is a clear process 
violation.

pr

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 17 Jun 2008 15:39:14 -0400

Dear Steve;

On Jun 17, 2008, at 2:54 PM, Steven M. Bellovin wrote:

> haven't read the draft in question.)

I have skimmed through it, and did not see any such problems in this  
case. Of course,
I could be wrong and would be gladly educated as to the error of my  
ways.

 From your description, it may be that 2606 needs a bis too.

Regards
Marshall

>  Hoping the reader will notice the

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Jun 2008 22:17:11 +0200

Pete,
> 2606 names. It is the use of the DISCUSS in this case that is at

I am uncomfortable ham-stringing the IESG (or having them do it to 
themselves) by requiring them to be excessively prescriptive about when 
they can and cannot use a DISCUSS.  It should be good enough for them to 
state their reasoning behind it, with the understanding that if someone 
doesn't like the reasoning they can appeal to the IAB.  If enough people 
disagree with the person or persons making the DISCUSS we have a recall 
function at our disposal.

I happen to tepidly agree with the DISCUSS on the grounds that Marshall 
Eubanks cited, but only tepidly because the likelihood of injury in this 
case is vanishingly small.  That having been said, the reason I agree is 
that we should strive to improve our documents over time.  SMTP should 
not be an exception but instead an example.(.com ;-).

Eliot

---

From: "TSG" <[email-masked]>
Date: Tue, 17 Jun 2008 13:29:05 -0800

Uh, Folks
DOMAIN NAMES cannot be reserved in that manner and this lawsuit from the US 
District Court says so.
http://www.domainnamenews.com/wp-content/uploads/2008/06/express-media-express-corp-nd-ca.pdf

That's not going to fly. DOMAIN NAMES are IP and need to be registered as 
TM's to protect them. If you want these domains to be protected and reserved 
then register them and pay the filing and maintenance fees on them.

Todd Glassey
----- Original Message ----- 
From: "Robert Elz" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 17, 2008 10:49 AM
Subject: Re: Appeal against IESG blocking DISCUSS on 
draft-klensin-rfc2821bis

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 17 Jun 2008 22:43:33 +0200

John C Klensin wrote:

> hypothesize that, at some point, an RFC 2606bis might be created
> (and go through the consensus process to BCP) that offers special
> reserved names for newsgroups or mailing lists as well as domain
> names

JFTR, with respect to newsgroups that is already specified in
http://tools.ietf.org/html/draft-ietf-usefor-usefor-12#section-3.1.4

| The following <newsgroup-name>s are reserved and MUST NOT be used as
| the name of a newsgroup:
|
| o  Groups whose first (or only) <component> is "example"

The (unnumbered) NetNews standard does not go into details for
which purpose the "example"-names are reserved, but I think it
is obvious.  The plan was to discuss such details in a separate
NetNews BCP later if needed.

> a reasonable reader might have trouble figuring out whether
> the footnote/reference anchor was part of the IMAP syntax
> and example or not.

+1  A consistent footnote style can be fine in Web pages, PDFs,
and similar document formats, but it is unsuited for the ASCII
text/plain xml2rfc output format(s).  

In the case of ABNF a single space could turn a clear concept into incomprehensible gibberish if the RFC line length limits
don't agree with adding this space. 

 Frank

---

From: LB <[email-masked]>
Date: Tue, 17 Jun 2008 23:09:41 +0200

Dear Colleagues,
I'm reading the proceedings of the IETF for the past few months. They
surprise me very much. I thought that the IETF was a serious
institution seriously publishing serious standards. I realized that
his organization is not made for that and I wonder how it can publish
something serious : I believe that the Dratf John is serious, but it
should not be a new document for us @large to read. It should be an
update of SMTP Page in the IETF Internet reference wiki.

I also read in detail the appeal of John Klensin. Most of the things
he asks seem obvious. And yet he's losing time to document them, and
many intelligent minds waste time on it, while the appeal relates
solely to the IESG. The real debate will be after the IESG response
and before a possible appeal to the IAB. Why not to wait for it. Or is
this some kind of pressure ?  If I understood correctly, this appeal
is not asking to IESG judge, but to document its defence.

Would not it be easier to create a WG-IETF, which would be mandated to
rebuild a IETF for today where a method, procedures, a logic of work
would be automated, with human decision points well documented? This
would allow the brains of engineers to worry about the Internet and
its users, rather than about internal disputes and the IESG? The
appeal would then simply concern the review of the three lines
defining the DISCUSS decision point in the IESG page.

My idea is it so  stupid?
--
LB

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 17 Jun 2008 19:59:49 -0400

Dear Dave;

On Jun 17, 2008, at 3:36 PM, Dave Crocker wrote:

> Marshall Eubanks wrote:
>> be used, over time.
> Seems like 25+ years is a pretty solid sample size of experience, to  
> test such a theory.*
>
> So you won't have any trouble providing data to support your  
> conclusion that, indeed, there is a problem?
>

I don't know - I do not own generic.com, foo.com, foo.org, bar.org or  
bar.com. Has anyone asked these companies (at least foo.com and  
bar.com are actual companies) or the domain holders for their opinion  
and experience in this matter ? For that matter, has anyone asked  
Jorge Contreras for his opinion as our counsel on the legal liability  
we might be incurring by using their names ?

I do know that if I did own one of those companies, I would request  
that this document be changed.

Regards
Marshall

> [Once again:  Not that that is the core issue being appealed.]
>
> d/
>
> * In theory, there isn't much difference between theory and  
> practice.  In practice...
>
>
> -- 
>
>  Dave Crocker

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 18 Jun 2008 09:05:41 +0200

> document quality IMHO.  John, would this be an acceptable addition to
I do not want a compromise on whether or not the IESG documents the 
rules it's enforcing.
BEFORE trying to enforce them "consistently", and using the 
"consistency" as an argument that what looks like a recommendation in a 
BCP is "really" a MUST.

               Harald

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 18 Jun 2008 13:19:13 +0200

John C Klensin <[email-masked]> writes:

> question.

I understand that, but I think the reason behind the DISCUSS can lead to
a better document.  I sympathize with your effort to make the IESG
decision process better documented, or at least consistent, and I'll
follow the result of this appeal with interest.

However, that is, as you seem to agree, not strongly related to the
document contents.

I think we can have two useful discussions at the same time: one about
the appeal/process issue and one about the document content.  My
thoughts here are more about the latter, as my time and energy to
participate in the discussion about the former is too restricted.

> examples above illustrate, be careful what you wish for.

That is a good and valid point.

There is one important part of what Brian Dickson suggested: that the
'[*]' (or similar markup) reference is added to "text".  Presumably it
would only be added to the first occurrence.  Adding the reference to
examples intended to illustrate the protocol is obviously a silly thing
to do.

With this elaboration regarding Brian's proposal, I would still be in
favor of making his change to the document, unrelated to the outcome of
the appeal.  The justification is that it results in a better and more
complete document.

/Simon

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 18 Jun 2008 16:00:53 +0200

[The main issue, in its discussion, and rightly so, is the "futile"
uses of DISCUSS - my favorite example being 2929bis « Domain Name
System (DNS) IANA Considerations », blocked for many months by
iana.org vs. ietf.org. But my message is about the "examples" RFC such
as 2606, 3330, 3849 or 4735.]

On Tue, Jun 17, 2008 at 09:42:18AM +1200,
 Brian E Carpenter <[email-masked]> wrote 
 a message of 62 lines which said:

> In my opinion that is a source of technical confusion and possibly
> of unwanted traffic.

Yes.

> So I think there is a strong argument that RFC 2606 values SHOULD be
> used whenever reasonably possible.

However, there are many cases where it is not reasonably
possible. Steve Bellovin gave good examples for RFC 2606. RFC 3330 has
similar problems. Only a /24 is reserved which means that, for BGP
tutorials, you need to announce /25s and /26s, with a long prefix in
common, which is pedagogically bad. RFC 3849 has a similar problem,
without even the excuse of address scarcity.

Many people who use IP addresses in documentations do not use RFC 3330
because it is too much to ask the readers to see at a glance the
difference between 192.0.2.1 and 192.0.2.129. They are too similar.

So, I agree with you, a RFC 2119 "SHOULD" is OK, and therefore should
not block the RFC, just trigger a discuss (lowercase, a real discuss,
not a blocking vote).
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Bob Hinden <[email-masked]>
Date: Wed, 18 Jun 2008 09:44:28 -0700

Hi,

Let me see if I understand this.

- This is the specification for SMTP.  It's was first used on the  
Arpanet.

- It is probably as widely deployed as IP and TCP.  Maybe more so.

- It works (e.g., the email discussing this thread was sent via SMTP).

- The IETF is now advancing it to Draft Standard.  I assume this means  
that we now have enough implementation experience.

- Now the IESG doesn't want to approve it for Draft Standard because  
it is using a different set of example domains instead of the official  
IETF ones.

Am I the only one who sees the insanity here?

Bob

---

From: "Debbie Garside" <[email-masked]>
Date: Tue, 17 Jun 2008 20:23:54 +0100

It is a matter of interpretation.  What does BCP stand for within IETF? ;-)

But seriously, Best Common Practise, IMHO, means, follow this unless you
have a damn good reason not to and if you have that damn good reason then
ask for the BCP to be updated. Just my interpretation.

Best regards

Debbie

> From: [email-masked] [mailto:[email-masked]]
> Sent: 17 June 2008 19:50
> "Here are some domain names that are reserved from all normal
> use, and so are suitable for use in places where something
> with the syntax of a valid domain names is required, but no
> real domain name should be used - use them where applicable".
>
> It does not say "you must use these domain names" (for any
> purpose at all).
>

---

From: "Debbie Garside" <[email-masked]>
Date: Wed, 18 Jun 2008 12:02:44 +0100

Dave wrote:

> Even on Wednesdays.

Or for purple documents... ;-)

I see your point.  I do think, assuming it is not already documented and
further assuming this is the whole point of the appeal, that the IESG could
create a general policy wrt BCP's.  Shouldn't be too onerous.  That way
everyone knows in advance that they should follow a BCP unless they can show
reasonable cause not to (in which case the BCP in question probably needs
updating).  The IETF uses terms such as MAY, MUST and SHOULD extensively
during the creation of an RFC and invariably a MAY or SHOULD is used in
order not to constrain future development (wise decisions in most cases) -
but doesn't mean that they SHOULD NOT be followed where it is reasonably
possible :-)

Best regards

Debbie

> From: Dave Cridland [mailto:[email-masked]]
> Sent: 18 June 2008 11:39
> Cc: 'John C Klensin'; [email-masked]; [email-masked]; 'Brian E
> Carpenter'; 'Pete Resnick'
> Subject: RE: Appeal against IESG blocking DISCUSS on
> draft-klensin-rfc2821bis
>
> On Tue Jun 17 15:50:02 2008, Debbie Garside wrote:
> > question, I agree with Brian.  This is not editorial.
>
> Well, people have commented that changing the examples will
> hardly break the Internet mail system, so it seems reasonable
> to assert that the counter-argument is also true. In other
> words, NOT changing the examples will also not break Internet
> mail. However, I couldn't really care what the examples say,
> as long as they're good, clear examples, and I think they are.
>
> >  I would also add that
> > to go against an IETF BCP
>
> Ah, wait - the document in question is not a missive from the
> mount stating "Thou SHALT use example.net everywhere", it
> says "The IETF said, 'Let there be reserved domain names for
> examples'; and there were."
>
> (I'm translating the documents into language more suitable
> for the religious tracts some people appear to think they are
> - at this rate, I'm fully expecting future editions to
> include marginalia comencing "Once, a student asked the Postel ...")
>
> But the facts are that nobody is "going against" the BCP. The
> examples in the document don't take advantage of the
> facilities provided by the BCP, but that's different.
>
> >  on the grounds of "well we have done so already historically" does
> > not make an argument for continuing to do so;
>
> Perhaps your implication that, irrespective of the past
> behaviour, we should create such a rule is sensible...
>
> >  errors
> > should be corrected when found, not endorsed.
>
> ... but until we do, it is not an error, and - crucially - we
> should not expect nor allow the IESG to decide on a whim what
> is and is not an error.
>
> >   If we are to pick and choose
> > standardization?
> Well, indeed, bravo, and well spoken - that's what John's
> appeal is about - what's the point of having procedures and
> policies at all if the IESG can say "I must reject your
> document; it is purple. No purple documents on Wednesdays,
> for lo, I have spoken."
>
> You may think I'm making light of this - and I am, because I
> think it's a remarkably silly stance from the IESG - but if
> you can explain the difference between rejecting all purple
> documents on Wednesdays and rejecting documents that do not
> use RFC 2606, I'll be most grateful.
>
> > On the face of things, and with my little knowledge, I
> would say that
> > the person within the IESG who has invoked the DISCUSS is quite
> > correct.
> >
> >
> And I reckon they're talking bananas.
>
> It doesn't matter, incidentally, whether you consider the use
> of example.com to be a good idea or not. I do, although I
> note that the XSF's tradition of using a fictional ".lit" TLD
> with example domains taken from Shakespeare's plays is
> actually considerably more readable, but anyway, I'd be
> perfectly happy if the IESG made a statement that as of now,
> documents which use domains other than those present in RFC
> 2606 will not be acceptable.
>
> But I note that there is no such statement from the IESG, so
> I'm personally not clear about whether there even is such a
> policy, or upon which days of the week it applies - for all I
> know, given the lack of statements made by the IESG on RFC
> 2606 names, these may be mandated only for purple documents
> submitted on Wednesdays. And those aren't allowed, as
> previously discussed. (And yeah, I know, but consider this -
> if I say that the IESG say that purple documents are not
> allowed on Wednesdays, that gives that equal weight with the
> alledged RFC 2606 rule - the IESG has not made any statement,
> we've only heard about this informally via third parties).
>
> What matters here is whether the IESG is allowed to introduce
> and enforce a rule with the same action. I do not believe
> they should be allowed to.
>
> Even on Wednesdays.
>
> Dave.
> --
> Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
>   - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
>   - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>
>
>
>

---

From: Robert Elz <[email-masked]>
Date: Thu, 19 Jun 2008 00:59:59 +0700

Date:        Wed, 18 Jun 2008 12:02:44 +0100
    From:        "Debbie Garside" <[email-masked]>
    Message-ID:  <059901c8d132$d65df170$0a00a8c0@CPQ86763045110>

  | I see your point.

I doubt that you do.

  | I do think, assuming it is not already documented and
  | further assuming this is the whole point of the appeal, that the IESG could
  | create a general policy wrt BCP's.

No, you totally fail to understand.   The IESG's job is not to create
policies.   It is to implement the policies created by the IETF as
a whole.   That's kind of the point here, the IESG (or at least one
member of it) seems to want to create a new policy, or is somehow assuming
such a policy has already been created (by someone, it isn't clear who or
how.)   That's what I believe John's appeal is really about - the IESG
should not (not now, not ever) be attempting this kind of thing.

  | Shouldn't be too onerous.  That way
  | everyone knows in advance that they should follow a BCP unless they can show
  | reasonable cause not to

Not true in general.   You also clearly don't know what a BCP is all about.

If you're inferring things from the name, I'd suggest you go back to the
poised/poised95/poisson (whenever it was that these things were created)
mailing list archives, and observe all the discussions about the name, and
what people might incorrectly read into it.   We ended up with BCP as a name
largely because no-one was able to suggest anything better.

What those documents are however, is anything for which the IETF desires to
express that there is community consensus behind what is written (whatever
that is), but for which the standards process does not work (in that the
latter requires interoperable implementations, several of them, and some
things - like reserving a domain name - simply do not allow multiple
interoperable implementations.)

In this case, 2606 is a BCP merely to show (as its author stated a few days
ago) that there was community consensus to remove from allocation to "normal"
people/organisations a few particular domain names - that is, to convince
IANA to make that reservation.

That's it.

Having achieved that objective, I guess 2606 could now be made historic.

There neither is, was, or ever should be, any implication that anyone
necessarily should ever use those names for anything.   Of course,
in many situations using them makes sense.  In some it is a very very
intelligent thing to do (for example if you're distributing a sample
configuration file and you need to show the configuration to attach to
a particular (end user supplied) server, using server.example.com as the
domain name in the sample configuration would be a very wise choice.)
In other cases using those domain names is of no benefit at all, and worse,
may actually create confusion.

Which is the case here isn't really the point - that's already been decided
by both the working group, the previous standard (2881 to which this doc is
a fairly minor revision, if I understand it all correctly) and the IETF
last call processes for both 2881 and 2821bis.   The issue is why the IESG
is ignoring the demonstrated will of the IETF.

kre

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 18 Jun 2008 20:09:14 +0200

Stephane Bortzmeyer wrote:

> my message is about the "examples" RFC such as 2606,
> 3330, 3849 or 4735.

I don't see a plausible way to reference RFC 4735 
in 2606bis.  The "examples" zoo should get its own 
section in Brian's next IETF marauders map - adding
TLH example in the Usefor RFC for NetNews.

> RFC 3330 has similar problems.

There's a 3330bis draft, if you want more example
IPs we could in theory reserve parts of the former 
"class E" for this purpose.  In practice I think
we're better off with "unreserving" these IPs excl.
255.255.255.255 covered by RFC 1122 (STD 3).  See
<http://tools.ietf.org/html/draft-iana-33330bis> +
<http://tools.ietf.org/html/draft-fuller-240space>
+ the RFC 3330 errata for the state of the art.

> I agree with you, a RFC 2119 "SHOULD" is OK

+1  MUST makes no sense, an RFC 2119 RECOMMENDED
matches what "we" (TINW) want.  But I think that 
boils down to a "judgement call" for all involved
parties (editors, authors, community, Chairs, ADs),
it won't fix the bug(s) in the DISCUSS-"protocol".

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 18 Jun 2008 20:35:54 +0200

Robert Elz wrote:

> The issue is why the IESG is ignoring the demonstrated
> will of the IETF.

Figuring out what the "demonstrated will of the IETF" is
is the job of the IESG, and in the case of an individual
submission such as 2821bis it can be rather tricky.  

Somebody *deciding* that using foo.com in 2821bis is "the
demonstrated will of the IETF" needs to be a Chair or the
IESG, and I'd consider to appeal the decision.  

 Frank

---

From: Robert Elz <[email-masked]>
Date: Thu, 19 Jun 2008 01:55:55 +0700

Date:        Wed, 18 Jun 2008 20:35:54 +0200
    From:        "Frank Ellermann" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Figuring out what the "demonstrated will of the IETF" is
  | is the job of the IESG,

Agreed, that is part of their role.

  | and in the case of an individual
  | submission such as 2821bis it can be rather tricky.

It can be tricky in any case, I don't really think individual
submissions are that different - in either case, there's a last
call, and the results need to be evaluated.

If, in this case, the reason for the IESG's objection were something
along the lines of "there seems to be a disputed about whether the
domain names used in examples are the correct ones to use, so we
don't see consensus to publish it", that would be fine (it may or
not be debatable, but procedurally fine), and the IETF as a whole would
need to make a decision (using the IESG as arbiter).

But that is not what happened here.
 
  | Somebody *deciding* that using foo.com in 2821bis is "the
  | demonstrated will of the IETF"

That was already done for 2821, wasn't it?   It is published already
(years ago).    This is just a minor update.  Only a fool would go
making unnecessary changes to a document meant as a minor update of
an existing doc.

Further, there already was a list call on 2821 bis, wasn't there (I'm
pretty sure I remember seeing it).    I don't recall seeing any objections
lodged to the examples.

kre

---

From: Dave Cridland <[email-masked]>
Date: Wed, 18 Jun 2008 12:28:10 +0100

On Wed Jun 18 12:02:44 2008, Debbie Garside wrote:
> create a general policy wrt BCP's.

Well, that is indeed a possibility, but RFC 2606 - the BCP involved  
in this specific case - does not state anywhere that people MUST use  
the domains it reserves in examples.

Therefore, to cover this particular case, such a blanket policy would  
have to be stated such that even vague recommendations in BCPs MUST  
be followed religiously, even if the document's author not only  
doesn't think that was the purpose of the document, but clearly  
states that wasn't the reason it's a BCP anyway.

Maybe the policy could also state a Doctrine Of IESG Infallibility,  
and just bypass the entire issue.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 18 Jun 2008 13:34:02 +0100

On Wed Jun 18 12:28:10 2008, Dave Cridland wrote:
> Therefore, to cover this particular case, such a blanket policy  
> would  have to be stated such that even vague recommendations in  
> BCPs

I received a private comment which appeared to suggest I'm being  
unclear here. So let me clarify:

The BCP, RFC 2606, as a whole is not a vague recommendation, and I  
certainly didn't say that - the BCP states that the domains are  
reserved, and, by its status as a BCP, it therefore reserves them.  
(Donald Eastlake said elsewhere in the thread that the reason it's a  
BCP at all was because the reservation of the domains needed the kind  
of solid consensus that BCP status provides).

What is very much a vague recommendation is whether these domains  
should be used.

The document says:

	Depending on the nature of
   the test or example, it might be best for it to be referencing a  
TLD
   permanently reserved for such purposes.

Yes, folks, that's "might be best" - hardly the eleventh commandment,  
here.

And:

      ".example" is recommended for use in documentation or as  
examples.

Note that both these, the latter of which is by far the strongest  
recommendation in the document, refer to the rarely used ".example"  
TLD.

On the subject of the more traditionally used second-level domains,  
it says only this:

   The Internet Assigned Numbers Authority (IANA) also currently has  
the
   following second level domain names reserved which can be used as
   examples.

So to summarize, if the IESG were saying that this phrasing forms a  
policy that all technical specifications MUST only use the domains  
from RFC 2606 - not that it is, but if it were, it would seem odd  
that the outcome would be that the IESG would recommend the second  
level domains in Section 3, rather than the TLD which seems to have  
been more strongly recommended in the consensus backed document that  
the IESG would be citing.

But that's not the point here, really - there is no such documented  
policy, and the policy we don't have is quite clearly not specified  
in the BCP that doesn't define it. At best, the BCP which does not  
define the policy we don't have suggests a different policy we don't  
have either would be a better policy to have, yet this alternate  
policy is not, as far as I can tell, what the community would  
generally want - so it's actually quite lucky that neither policy the  
BCP doesn't define actually exists.

I hope that's clearer now.

Dave.

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 18 Jun 2008 23:01:44 +0200

Robert Elz wrote:
 
 [general procedural considerations:] 
> submissions are that different - in either case, there's a 
> last call, and the results need to be evaluated.

A WG is an additional layer to sort out conflicts, with Chairs
deciding what the WG "consensus" is, with a WGLC, and editors
expected to mirror the "consensus" in WG drafts.  Most issues
are solved before the short two weeks IETF Last Call.

An individual draft has authors, not editors, it reflects what
the authors think.  Backed by a sponsoring AD when it goes to
a long four weeks IETF Last Call.  There was no opportunity to
appeal controversial WG Chair decisions for non-WG drafts, it
is an informal procedure until somebody triggers the "PubReq".

>From my POV that is a rather important procedural difference -
"if" there are controversial points.  But there are always nits
where some folks (including the authors) are not exactly happy
with the outcome.   

 [for the specific 2821bis case:] 
> "there seems to be a disputed about whether the domain names
> used in examples are the correct ones to use, so we don't 
> see consensus to publish it", that would be fine (it may or
> not be debatable, but procedurally fine), and the IETF as a
> whole would need to make a decision (using the IESG as 
> arbiter).

The topic was debated at different times in the making of 5821,
back in 2005, and again in 2007.  I expected that this might
hit a wall when 2821bis reaches the IESG, it's a known point
in the idnits "specification".  Admittedly this text is no BCP,
but what can we expect, we have a semi-obsolete RFC 2026, an
expired semi-official 2231bis, an old IETF marauders map still
talking about the old Tao, etc.  Most IETF procedures are in
constant flux and different states of decay.  

 [decision about foo.com] 
> That was already done for 2821, wasn't it?

Seven years ago for 2821, time moves on.  There wouldn't be a
2821bis if 2821 was perfect (it wasn't, the errata are rather
incomplete, nobody bothered to update them after the work on
2821bis started, and besides the errata procedure didn't work
as it should in 2005..2006).

It is no secret that RFC 2821 kind of missed some points wrt
spam by the diameter of the universe.

> This is just a minor update.

This will be one of the top ten RFCs in any decent list I care
about.  I never supported "minor update" theories for 2821bis.

And the post-2nd Last Call 2821bis debate consisted of about
as much messages as fifty ordinary IETF Last Calls together.
None of them about "example addresses", in relation to other
SMTP questions this is just too irrelevant.

 Frank

---

From: Ralph Droms <[email-masked]>
Date: Wed, 18 Jun 2008 17:27:46 -0400

No, you're not the only one seeing insanity.

- Ralph

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 18 Jun 2008 16:48:30 -0500

By now, I'm hoping that the IESG has enough public and private feedback on 
this topic to do the right thing (whatever that is, and yes, I also have an 
opinion about what the IESG should be doing, which I'm not including here).

Do we need to say more? If not, perhaps we could wait for the IESG to 
respond, and then do the right thing from our end, if needed.

If we do need to say more, by all means, keep typing...

Thanks,

Spencer

---

From: Dave Cridland <[email-masked]>
Date: Wed, 18 Jun 2008 11:39:01 +0100

> question, I agree with Brian.  This is not editorial.

Well, people have commented that changing the examples will hardly  
break the Internet mail system, so it seems reasonable to assert that  
the counter-argument is also true. In other words, NOT changing the  
examples will also not break Internet mail. However, I couldn't  
really care what the examples say, as long as they're good, clear  
examples, and I think they are.

> to go against an IETF BCP

Ah, wait - the document in question is not a missive from the mount  
stating "Thou SHALT use example.net everywhere", it says "The IETF  
said, 'Let there be reserved domain names for examples'; and there  
were."

(I'm translating the documents into language more suitable for the  
religious tracts some people appear to think they are - at this rate,  
I'm fully expecting future editions to include marginalia comencing  
"Once, a student asked the Postel ...")

But the facts are that nobody is "going against" the BCP. The  
examples in the document don't take advantage of the facilities  
provided by the BCP, but that's different.

>  on the grounds of "well we have done so already
> historically" does not make an argument for continuing to do so;

Perhaps your implication that, irrespective of the past behaviour, we  
should create such a rule is sensible...

> should be corrected when found, not endorsed.

... but until we do, it is not an error, and - crucially - we should  
not expect nor allow the IESG to decide on a whim what is and is not  
an error.

> which RFC's/BCP's we will take notice of what is the point of

Well, indeed, bravo, and well spoken - that's what John's appeal is  
about - what's the point of having procedures and policies at all if  
the IESG can say "I must reject your document; it is purple. No  
purple documents on Wednesdays, for lo, I have spoken."

You may think I'm making light of this - and I am, because I think  
it's a remarkably silly stance from the IESG - but if you can explain  
the difference between rejecting all purple documents on Wednesdays  
and rejecting documents that do not use RFC 2606, I'll be most  
grateful.

It doesn't matter, incidentally, whether you consider the use of  
example.com to be a good idea or not. I do, although I note that the  
XSF's tradition of using a fictional ".lit" TLD with example domains  
taken from Shakespeare's plays is actually considerably more  
readable, but anyway, I'd be perfectly happy if the IESG made a  
statement that as of now, documents which use domains other than  
those present in RFC 2606 will not be acceptable.

But I note that there is no such statement from the IESG, so I'm  
personally not clear about whether there even is such a policy, or  
upon which days of the week it applies - for all I know, given the  
lack of statements made by the IESG on RFC 2606 names, these may be  
mandated only for purple documents submitted on Wednesdays. And those  
aren't allowed, as previously discussed. (And yeah, I know, but  
consider this - if I say that the IESG say that purple documents are  
not allowed on Wednesdays, that gives that equal weight with the  
alledged RFC 2606 rule - the IESG has not made any statement, we've  
only heard about this informally via third parties).

What matters here is whether the IESG is allowed to introduce and  
enforce a rule with the same action. I do not believe they should be  
allowed to.

Even on Wednesdays.

Dave.

---

From: Ned Freed <[email-masked]>
Date: Wed, 18 Jun 2008 14:11:06 -0700 (PDT)

> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Jun 2008 22:35:59 -0400

Bob:

Insanity?  I think not.  Maybe you made the comment to get me post to 
this thread.  If so, it worked.

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.

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.

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.

This document uses "isif.usc.edu" and "[email-masked]" as 
examples.  The authors want to leave these as a  tribute to 
Jon.  Fine.  I think the implications of these are well understood.

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.

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.

So, Bob, the situation is not as simple as your message might indicate.

Russ

---

From: "Debbie Garside" <[email-masked]>
Date: Wed, 18 Jun 2008 21:53:18 +0100

Maybe I and a few others thought a BCP was worth something.  Apparently not.
Unlike the authors of these documents I am not privy to the reasoning behind
them  I am just privy to the document itself.  Neither are countless other
people who observe IETF BCP's. Perhaps I should not bother recommending BCP
47 (full of MAY's and SHOULD's) anymore or indeed contributing to the IETF
LTRU process.  It obviously is not worth the digital paper it is printed on.

A sad day for IETF in my book.

My last word.

Best regards

Debbie

> Behalf Of Dave Cridland
> Sent: 18 June 2008 12:28
> Cc: 'John C Klensin'; 'Pete Resnick'; [email-masked]; [email-masked]
> > I see your point.  I do think, assuming it is not already
> documented
> > and further assuming this is the whole point of the appeal,
> that the
> > IESG could create a general policy wrt BCP's.
>
> Well, that is indeed a possibility, but RFC 2606 - the BCP
> involved in this specific case - does not state anywhere that
> people MUST use the domains it reserves in examples.
>
> Therefore, to cover this particular case, such a blanket
> policy would have to be stated such that even vague
> recommendations in BCPs MUST be followed religiously, even if
> the document's author not only doesn't think that was the
> purpose of the document, but clearly states that wasn't the
> reason it's a BCP anyway.
>
> Maybe the policy could also state a Doctrine Of IESG
> Infallibility, and just bypass the entire issue.
>
> Dave.
> --

---

From: Russ Housley <[email-masked]>
Date: Thu, 19 Jun 2008 13:50:45 -0400

Dave:

I'm not sure I did a wise thing by joining the discussion, but in for 
a penny, in for a pound ...

>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 "[email-masked]" 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:
>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.

>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

---

From: John C Klensin <[email-masked]>
Date: Thu, 19 Jun 2008 14:23:47 -0400

--On Wednesday, 18 June, 2008 21:53 +0100 Debbie Garside
<[email-masked]> wrote:

> Maybe I and a few others thought a BCP was worth something.
> Apparently not. Unlike the authors of these documents I am not
> privy to the reasoning behind them  I am just privy to the
> document itself.  Neither are countless other people who
> observe IETF BCP's. Perhaps I should not bother recommending
> BCP 47 (full of MAY's and SHOULD's) anymore or indeed
> contributing to the IETF LTRU process.  It obviously is not
> worth the digital paper it is printed on.

Debbie,

Please take the time to read the relevant documents, starting
with the full text of the appeal and then the text of "the BCP"
before making comments like this.   RFC 2606/BCP32 very clearly
makes the names available for use where authors find them
useful.  It does not require them, specify that they SHOULD be
used, or call for a community consensus process to determine the
cases in which they might or might not be used.  The author of
that document has commented on this list that nothing else,
especially an implicit requirement, was intended.  And no one
else has been able to cite text in RFC2606/BCP32 that imposes a
requirement.   But you apparently did not read those notes
either (in addition to not reading the document to which you
claim to be "privy").

The only published requirement for the use of these names is in
the "ID Checklist" (IDNits).  That document is not a BCP.  It is
not even an IETF consensus documents.  It is an IESG statement
about what the IESG intends to look at.  And it says "SHOULD
preferably".    Traditionally in the IETF, "SHOULD preferably"
is a WG (or author and editor) decision as to whether there are
grounds for doing something other than what the SHOULD
recommends.  For the IESG to block a document on that basis
turns a SHOULD into a "MUST unless we choose to grant an
exception".  And, in any event, IDNits is not a BCP of any
flavor - there is no evidence of community consensus for
applying IDNits this way.

> A sad day for IETF in my book.

They are always sad days for the IETF when people comment
passionately on documents they haven't read and clearly don't
understand and when they fail to read and consider other
comments in a discussion thread before posting remarks of their
own that could have been informed by those comments.

    john

---

From: Ted Hardie <[email-masked]>
Date: Thu, 19 Jun 2008 11:33:54 -0700

>confidence in their judgement?

Russ,
	This is casting the problem in ways that continue to miss
the point.  Of course we expect individual Area Directors to exercise
judgement, and we expect the IESG as a body to do the same.

	But we also expect them to exercise due care in listening
to the folks actually doing the work, and not over-rule them when they
clearly have considered the issues.  In this case, John's appeal makes
clear that the folks writing the document considered the issue
and made a decision to value continuity.  A DISCUSS position
to reconfirm that in light of an Area Director's concerns would
be valid (and probably welcome); once confirmed though, it
should get dropped.  Otherwise, it over-rules a community decision
with the individual technical judgement of the Area Director. 

 	There are very few cases where that is okay.  It applies when
there is a documented, larger community consensus that the WG or
submission group decision ignores (a working group decision that
congestion control wasn't important would get pushback on this
front, for example).  It applies when the Area Director can demonstrate
harm to the Internet as a result of the decision; the "can demonstrate"
there, though, is to the *community* not just to himself or the IESG.
It applies when the Area Director can demonstrate that the proposal
simply *does not work* to the satisfaction of the larger community, no
matter what the proposers believe.

	Most DISCUSS don't need to meet any of those tests because
the WGs or proposers agree that the issues need to be addressed, so
there is no over-ride present.  That's good, because over-riding the
considered technical judgement of the folks doing the work doesn't
just generate appeals, it drives folks away.  The extent to which
the current IESG is sliding back into substituting its technical
judgement for the WGs' is a worrying trend that I've already pointed
out.  This appeal may seem to be on a small point in a single
document, but the issue is quite fundamental.  The IETF can drive
itself into irrelevance very quickly by appearing to be driven by
ex cathedra pronouncements; even the Pope has done that only
once since his infallibility was declared doctrine.  Doing so constantly
over things where the AD's opinion is not backed by community
consensus is currently getting you an appeal.  The next step could
well be reformation.

	I hope the IESG considers John's appeal in this light
and responds promptly to the issues he has raised.

				Ted Hardie

---

From: Pete Resnick <[email-masked]>
Date: Thu, 19 Jun 2008 14:22:19 -0500

On 6/19/08 at 7:54 PM +0100, Debbie Garside wrote:

>I am more for going with standards rather than finding ways around 
>them with MAYs and SHOULDs.  If there is a recommendation within a 
>standard IMHO it should be followed.
>[...]
>I don't see what the problem is with following BCP's

Please identify ANYWHERE in this BCP (RFC 2606) that says that 
anybody MUST, SHOULD, ought to, might want to think about, or 
otherwise really really needs to, use these domain names.

Anywhere. Please quote text.

Your repeated statements that you think there is something in that 
BCP that "should be followed" indicate that you have not read the BCP.

The BCP registers names so that they can be used if one wants to. It 
does not say that they must be used in RFCs. It does not even 
recommend their use. It only registers the names.

Perhaps the ISO is different and they don't actually say what they 
mean when they write a document. That has not been my experience 
reading ISO documents, but perhaps it's because I work in the IETF.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 19 Jun 2008 21:53:31 +0200

Debbie Garside wrote:

> I and a few others thought a BCP was worth something.  Apparently not.

Please don't panic, nobody said that RFC 2606 or 4646 are "worthless".

This discussion is mainly about some bugs in the DISCUSS "protocol",
and the somewhat unclear status of the IDNITS "specification".  That's
about BCP 9 (RFC 2026), not about BCP 32 (RFC 2606), let alone BCP 47.

> BCP 47 (full of MAY's and SHOULD's)

Arguably tons of BCP 14 (RFC 2119) key words might obscure the really
important points, but that's another topic - it is difficult enough to
keep 2026 vs. 2606 apart in this discussion.  BTW, working on 2606bis
I stumbled over <http://rfc-editor.org/errata_search.php?rfc=3406>.

> A sad day for IETF in my book.

Well, I thought Dave's jokes were funny, but that's a matter of taste.

The serious question is to what degree the IESG or individual ADs can
de jure or de facto force authors to jump through hoops.

 Frank

---

From: Eliot Lear <[email-masked]>
Date: Thu, 19 Jun 2008 22:32:59 +0200

> matter what the proposers believe.

Isn't the IESG is meant to serve two roles?  The first is to be the 
arbiter of community consensus.  The second is to be a judge on the 
quality of the work before them, as to whether it is ready to move 
forward.  The threat of the IESG saying, "jeez what a {dumb|complex|...} 
approach" separates us from other standards organizations (or at least 
it did).  The most famous example of all of this is still the 
ETHERNET-MIB WG where they were upset that Jon Postel reset a counter 
size in the final copy of the MIB to match the IEEE specification, and 
those folks were rip roaring upset that he did so.  I don't want the 
IESG to author the docs like Jon did but I do want them to stand in the 
way of dumb ideas.

In this case they should be there to apply our *evolving* standards.  To 
hogtie those folk to me just begs for others to attempt to make use of 
those knots to get their dumb standards.

Shouldn't the response to John's appeal demonstrate the balance between 
their two roles?

Eliot

---

From: Ted Hardie <[email-masked]>
Date: Thu, 19 Jun 2008 14:57:47 -0700

At 1:32 PM -0700 6/19/08, Eliot Lear wrote:
>forward.

The IESG is not meant to over-ride the community consensus for
specific technical choices without reason.  It needs to show *why*
it is over-riding a specific technical choice in a way that references
existing consensus, technical correctness, or the health of the
Internet.  Saying "I don't like the way you have done it, do it
my way" is not their job, and the existing "discuss criteria" document
tries to make that clear.

This is not about an overall judgement that a doc is not ready;
this is about over-riding the informed technical judgement of
the people who are doing the work.

>  The threat of the IESG saying, "jeez what a {dumb|complex|...}

I look forward to seeing what it demonstrates.
					Ted

---

From: Robert Elz <[email-masked]>
Date: Fri, 20 Jun 2008 05:13:15 +0700

Date:        Thu, 19 Jun 2008 22:32:59 +0200
    From:        Eliot Lear <[email-masked]>
    Message-ID:  <[email-masked]>

  | Isn't the IESG is meant to serve two roles?

Yes, but not the two you enumerated.   The first, and far and away
most important, is to cause the work to get done - to coordinate the
working groups, help keep out (unwanted) duplicated effort, and somehow
try to cajole people into actually getting things done (etc.)

The second ...

  | The first is to be the arbiter of community consensus.

is that one - which really ought to be done by something different, as
asking #1 to do the work, then #2 to judge if the work is done correctly
really is a conflict of interest.   But that's not germane to any
current discussion.

  | The second is to be a judge on the 
  | quality of the work before them, as to whether it is ready to move 
  | forward.

In the sense of whether the WG has reached consensus, yes, but that's
all a part of #1.

In the sense you mean it, no, that's the job of the whole community.

Of course, the IESG members are a part of the community, and are just
as entitled to an opinion as anyone else.   Their opinions also carry
the same weight as anyone else's (or anyone else with similar reputation
and experience anyway - there's no expectation that necessarily everyone's
ability is equal).

  | I don't want the IESG to author the docs like Jon did but I do
  | want them to stand in the way of dumb ideas.

I don't, I want the community as a whole to do that.   It is just fine for
an IESG member (or anyone else) to point out that they think a proposal is
deficient in some way, but then the community get to judge whether it
should go forward anyway (whether the objection matters).

The IESG do get to judge the community's opinion (figure out what we're all
saying), but when doing that, they need to do so absent any personal
biases one way or the other.

It always appeals to have someone else we can blame when dumb things happen,
"anyone but me", but that's unreasonable.   If poor ideas become codified,
its our fault, not the IESGs, nor is it their responsibility to prevent it.

kre

---

From: SM <[email-masked]>
Date: Thu, 19 Jun 2008 23:39:44 -0700

>confidence in their judgement?

A process gets constrained if we have to go by written rules 
only.  However, without such rules one has to resort to second 
guessing to determine what the rules might be.  Written rules are a 
way to set the expectations and bring in openness and fairness into 
the process.  The decision-making process is hampered if the rules 
are too rigid.  That's why guiding principles are defined.

By selecting leaders, we are demonstrating confidence in them.  As in 
any process, disputes may arise.  Sometimes, a person might not agree 
with a particular decision.  The person may ask the leaders to review 
their decision.

Appeals are there for a purpose.  It provides a recourse if the 
person is not satisfied with a judgement.  Some may view it as a 
process failure.  Others may read it as a motion of no confidence in 
the judgement of the leaders.  It is better to hear both sides of the 
argument instead of jumping to hasty conclusions.  Whether it is in a 
Working Group discussion, on a Last Call or anywhere throughout the 
process, there are bound to be differences of opinion.  Sometimes 
this entails challenging current dogma or some higher 
authority.  This is after all a battleground of ideas which are 
judged on their technical merits.

Regards,
-sm

---

From: "Debbie Garside" <[email-masked]>
Date: Thu, 19 Jun 2008 19:54:19 +0100

John

I have read the documents (all of them).  I know you have been around a long
time and have a good deal of experience but I have been within IETF
processes for some 5 years now (or maybe more - seems like an eternity) and
am fairly familiar with it.

I still come out on the side of the IESG.

Sorry but we have to agree to differ on this.  Nothing personal but probably
due to my ISO experience, I am more for going with standards rather than
finding ways around them with MAYs and SHOULDs.  If there is a
recommendation within a standard IMHO it should be followed.  This is just
my humble opinion - you are welcome to yours.

I don't see what the problem is with following BCP's or with the IESG
putting a simple DISCUSS (albeit temporarily blocking) on your document
because you have not followed one - whether or not you seem to think it
fits.  And, yes, I know that is not what your appeal is about but it does
play a fairly large part nevertheless.  You have taken umbridge at a last
minute decision made by the IESG for an aspect that you think is irrelevant
to the document as a whole - editorial in otherwords.

You state that the IESG has provided a statement as to what they intend to
look at and yet you are now arguing the semantics of that statement.

I think as the IESG Chair has just stated, you should trust in your top
level management.   I would add, you should tell them when they have been
inconsistent in order that they may learn from the experience and revise
their statements as necessary.

Wrt the author's intention for publishing BCP32, it is irrelevant unless
documented within the BCP itself.  We cannot go back to the author for each
BCP or RFC and ask what was the intended use.  The document, as with any
standard, has to stand alone.

Best regards

Debbie

> From: John C Klensin [mailto:[email-masked]]
> Sent: 19 June 2008 19:24
> To: [email-masked]; 'Dave Cridland'
> Cc: 'Pete Resnick'; [email-masked]; [email-masked]
> > Apparently not. Unlike the authors of these documents I am
> not privy
> > to the reasoning behind them  I am just privy to the
> document itself.
> > Neither are countless other people who observe IETF BCP's.
> Perhaps I
> > should not bother recommending BCP 47 (full of MAY's and SHOULD's)
> > anymore or indeed contributing to the IETF LTRU process.
> It obviously
> > is not worth the digital paper it is printed on.
>
> Debbie,
>
> useful.  It does not require them, specify that they SHOULD
> be used, or call for a community consensus process to
> determine the cases in which they might or might not be used.
>  The author of that document has commented on this list that
> nothing else, especially an implicit requirement, was
> intended.  And no one else has been able to cite text in
> RFC2606/BCP32 that imposes a
> The only published requirement for the use of these names is
> in the "ID Checklist" (IDNits).  That document is not a BCP.
> It is not even an IETF consensus documents.  It is an IESG
> statement about what the IESG intends to look at.  And it says "SHOULD
> is a WG (or author and editor) decision as to whether there
> are grounds for doing something other than what the SHOULD
> comments in a discussion thread before posting remarks of
> their own that could have been informed by those comments.
>
>     john
>
>
>
>
>

---

From: "Debbie Garside" <[email-masked]>
Date: Fri, 20 Jun 2008 00:26:43 +0100

Hi Pete

You should read my original message (17th June) where I talk about BCP's in
general.  I am not aware of quoting MAY's and SHOULD's wrt RFC2606 but
rather in general terms - if I have, I apologise for the error.  I have been
speaking very generally about BCP's and what I consider to be good practice.

It has been (and still is) my opinion that a BCP should be followed unless
good cause and reasoning is shown to the contrary.  Please do not
misinterpret the word "follow" but rather read my view (below) on BCP's
(which is, after all, only my view).

Should we decide for each RFC when, where and if we will follow BCP's?

Perhaps you and John are right... perhaps I don't understand what is going
on.  I just follow (and write) standards and for me a BCP is a standard that
should be followed where possible whether the wording is: IT MIGHT BE BEST,
MUST, SHOULD, MAY, or ONLY ON WEDNESDAYS! (I have a great sense of humour
Frank but not on Thursdays or when using my pink mouse ;-)).

Extract of BCP37

2. TLDs for Testing, & Documentation Examples

   There is a need for top level domain (TLD) names that can be used for
   creating names which, without fear of conflicts with current or
   future actual TLD names in the global DNS, can be used for private
   testing of existing DNS related code, examples in documentation, DNS
   related experimentation, invalid DNS names, or other similar uses.

It is my understanding that the DISCUSS was put in place because John's RFC
does not follow this BCP for Documentation Examples.  Maybe I am wrong but
this is my understanding.  The fact that this is a BCP means (for me) that
it does not need a MUST or SHOULD.  It *IS* Best Current Practice for
examples in IETF documentation by title alone.  Just my humble opinion.

Extract of BCP 9

5.  BEST CURRENT PRACTICE (BCP) RFCs

   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.  A
   BCP document is subject to the same basic set of procedures as
   standards track documents and thus is a vehicle by which the IETF
   community can define and ratify the community's best current thinking
   on a statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function.

The IESG is surely following BCP 9 (and thus not making up their own rules)
and my interpretation of this section on BCP's is that a BCP is the best way
forward (and thus should be "followed") for the use of whatever it documents
- whether it be example domains within RFCs and BCPs or language tags (which
is more my field).  Maybe I am wrong on this too.  I hope not as I have
spent several years following and contributing to one.

If I was writing an RFC I would follow any damn BCP that the IESG/IETF cares
to put in front of me and I really do not see the problem with that unless
it gets in the way of technical development within the IETF - in which case
I would be highlighting said BCP for an update and informing IESG and ADs
etc. as to why it cannot be followed.  This is not the case here IMHO.  This
BCP does not infringe upon any technical development and thus there is no
right to appeal (I may have this bit wrong but I am sure I read it somewhere
- doubtless someone will correct me if I have).  However, IMHO the case for
a DISCUSS is considered technical because the document does not follow "the
best way to perform" this operation according to a BCP which according to
BCP 9 - which documents the Internet Standards process - is as ratified by
the IETF community and not just the WG and the Author in question.

This is my final final word as I think you have all heard enough on my views
and whilst I am very open to other people's opinions, I have not heard
anything here to change my mind. As my opinion seems to differ from yours
and John's substantially, I obviously have not read the documents properly,
have completely misinterpreted them and completely failed to understand them
for which I, of course, apologise :-)

Best regards

Debbie Garside

> From: Pete Resnick [mailto:[email-masked]]
> Sent: 19 June 2008 20:22
> Cc: 'John C Klensin'; 'Dave Cridland'; [email-masked]; [email-masked]
> <x-flowed>On 6/19/08 at 7:54 PM +0100, Debbie Garside wrote:
>
> >I am more for going with standards rather than finding ways
> around them
> >with MAYs and SHOULDs.  If there is a recommendation within
> a standard
> >IMHO it should be followed.
> >[...]
> Please identify ANYWHERE in this BCP (RFC 2606) that says
> that anybody MUST, SHOULD, ought to, might want to think
> about, or otherwise really really needs to, use these domain names.
>
> Your repeated statements that you think there is something in
> that BCP that "should be followed" indicate that you have not
> read the BCP.
>
> The BCP registers names so that they can be used if one wants
> to. It does not say that they must be used in RFCs. It does
> not even recommend their use. It only registers the names.
>
> Perhaps the ISO is different and they don't actually say what
> they mean when they write a document. That has not been my
> experience reading ISO documents, but perhaps it's because I
> work in the IETF.
>
> pr
> --

---

From: Russ Housley <[email-masked]>
Date: Fri, 20 Jun 2008 13:14:33 -0400

Ted:

First, looking at a diff of RFC 2821 and draft-klensin-rfc2821bis, I 
do not find the argument about continuity very questionable.  This 
document does include some clarification and lessons learned, and it 
includes much more too.

RFC 2821 Outline for Sections 1 and 2:

    1.     Introduction
    2.     The SMTP Model
    2.1    Basic Structure
    2.2    The Extension Model
    2.2.1  Background
    2.2.2  Definition and Registration of Extensions
    2.3    Terminology
    2.3.1  Mail Objects
    2.3.2  Senders and Receivers
    2.3.3  Mail Agents and Message Stores
    2.3.4  Host
    2.3.5  Domain
    2.3.6  Buffer and State Table
    2.3.7  Lines
    2.3.8  Originator, Delivery, Relay, and Gateway Systems
    2.3.9  Message Content and Mail Data
    2.3.10 Mailbox and Address
    2.3.11 Reply
    2.4    General Syntax Principles and Transaction Model

draft-klensin-rfc2821bis-10 Outline for Sections 1 and 2:

    1      Introduction
    1.1    Context and Notes for this Draft
    1.2    Mailing List
    1.3    Transport of electronic mail
    1.4    History and context for this document
    2      The SMTP Model
    2.1    Basic Structure
    2.2    The Extension Model
    2.2.1  Background
    2.2.2  Definition and Registration of Extensions
    2.2.3  Special Issues with Extensions
    2.3    Terminology
    2.3.1  Mail Objects
    2.3.2  Senders and Receivers
    2.3.3  Mail Agents and Message Stores
    2.3.4  Host
    2.3.5  Domain Names
    2.3.6  Buffer and State Table
    2.3.7  Commands and Replies
    2.3.8  Lines
    2.3.9  Message Content and Mail Data
    2.3.10 Originator, Delivery, Relay, and Gateway Systems
    2.3.11 Mailbox and Address
    2.4.   General Syntax Principles and Transaction Model

Note: Sections 1.1 and 1.2 are to be deleted prior to publication of 
the document as an RFC.

I am not saying that any of the changes are inappropriate, but that 
it is hard to claim that the changes are minimal.

Second, from my perspective, the dialogue about this document did not 
happen as you suggest.

The issue was first raised in the SecDir Review during IETF Last 
Call.  The text from that SecDir Review was included in my note on 
this thread in response to Dave Crocker.  When I highlighted this 
paragraph, the document PROTO shepherd pointed out that the 
"isif.usc.edu" and "[email-masked]" 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.

At least three ADs believe that the examples should be changed, and 
they have comments in the Data Tracker that clearly indicate this 
position.  Others feel that the examples out to be changed, but do 
not consider it important enough to delay the document.

We are no having a debate to determine the community consensus on 
this topic.  In addition to the people that are speaking publicly on 
this thread, I am receiving a fair number of private messages.  Some 
are supportive of the appeal position and others are not.  Judging 
community consensus in such a situation is somewhat difficult.  I 
have suggested to the IESG a way to determine the community consensus 
in this case, and I am waiting to hear if other ADs think it is a 
good idea or not.

Russ

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 20 Jun 2008 12:06:41 -0700

Hi -

> To: "'John C Klensin'" <[email-masked]>; "'Dave Cridland'" <[email-masked]>
> Cc: "'Pete Resnick'" <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Thursday, June 19, 2008 11:54 AM
> Subject: RE: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
...
> my humble opinion - you are welcome to yours.
...
> standard, has to stand alone.
...

Both these arguments get back to the question of the applicability of
a standard or BCP.  Although we are sometimes rather clear on the
scope of applicability for a particular specification, more often things
are more or less deliberately left open ended.  Whether it makes
sense to use SNMPv3 as a file transfer protocol (as in RFC 2592)
is left to the user's judgement.  The existence of a potentially applicable
BCP or standard doesn't imply that it MUST be used - the WG needs to
investigate it, and then make the engineering decision whether
that specification is the right tool for the job at hand.

Randy

---

From: Dave Cridland <[email-masked]>
Date: Mon, 23 Jun 2008 11:19:54 +0100

On Fri Jun 20 18:14:33 2008, Russ Housley wrote:
> First, looking at a diff of RFC 2821 and draft-klensin-rfc2821bis,  
> I do not find the argument about continuity very questionable.   
> This document does include some clarification and lessons learned,  
> and it includes much more too.

Your first sentence contains a freudian slip, I think.

But so people can sing along at home:

http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-klensin-rfc2821bis-10.txt&url1=http://tools.ietf.org/rfc/rfc2821.txt

> it is hard to claim that the changes are minimal.

I think it's a demonstrably easy claim to make:

Important to note is that the only new domain introduced by the  
document is an example.com one (a change in section 4.3.1 of both  
documents).

This also represents one of four cases where the examples or  
explanatory text surrounding them were changed at all. The others  
were:

Section 4.1.1.3, the word "appendix" was capitalized to "Appendix" in  
one paragraph, and another paragraph was (very) slightly reworded.  
(Removal of "Of course", and captilization of "MAY"). I'm not sure  
this counts at all, but it's offered as a straw for the IESG to  
clutch at.

Appendix D.3, the example was reworked to change from a source route  
relay to an MX lookup - this is a comparitively major change, but  
note from the diff that essentially it's adding some explanatory  
text, and then changing the MAIL FROM lines - nothing else in the  
examples is changed.

Finally, Appendix D.4 corrects an error - it's a single word change  
from SEND to MAIL.

I don't think it would be at all fair to claim that the changes to  
the examples - which is the significant item here - are anything but  
minimal, and it's quite obvious to me as to why this is the case.

Examples, and particularly changing them, is a tough thing to get  
right in application protocols. By my own experience, I tend to find  
that my own example mismatch the text in early stages (and that often  
leaks through to late stages); changing examples can often lead to  
mismatches between discussion and example, for example if xyz.com and  
foo.com were inconsistently changed to example.com and example.net;  
and finally I see broken examples in the documents I review.

This is of special concern because whilst we publically chastise  
implementors for only reading the examples, the fact remains that  
most of us certainly rely on the examples for getting the jist of a  
protocol, and turn to the rest of the text afterward, having formed  
our preconceptions nice and early on.

Moving back from the general to the specific, then, it's important to  
note that the examples are therefore substantially unchanged from  
those which DRUMS WG carefully weighed and understood the full  
implications thereof.

I'd note, as an aside, that whilst it could be argued that  
ID-Checklist has a SHOULD which covers the later part of the sentence  
and therefore SHOULDs the RFC 2606 names, the ID-Checklist does not  
itself specify that SHOULD is to be interpreted using RFC 2119, and  
therefore arguably doesn't even say SHOULD, as such.

It'd be fairly petty to argue this as a significant point, but I hope  
that even if this and the (rather more serious) odd phrasing in the  
ID-Checklist is overlooked, the resultant argument - that rfc2821bis  
ignores a SHOULD - is essentially baseless, as the examples in  
question were substantially the result of heavy consideration from a  
working group, and have been previously accepted by the IESG.

> Second, from my perspective, the dialogue about this document did  
> not happen as you suggest.

And that's a fine explanation of why the situation has arisen, but it  
doesn't (or shouldn't) affect the outcome of the appeal - I'd have  
thought that one of the great benefits of an appeal is that more  
information is made available to the IESG so as to enable them to  
correct a bad decision or confirm a good one. It's unfortunate that  
appeals are sometimes perceived as a way to slap wrists.

Appeals are, surely, meant as a mechanism for the community to say:

Are you really sure you want to go down this route, because it looks  
to me like there's stuff you've missed, and/or you've not thought  
this through, and I'd like you to carefully reconsider.

In another message, you state: "Don't we select leaders because we  
have some confidence in their judgement?" - we do, of course, select  
them because we think they'll be right the majority of the time, and  
willing to accept when they're wrong, too.

Dave.

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Jun 2008 11:35:02 -0400

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
><[email-masked]> wrote:
>
> >...
>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.

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

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

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

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

>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
><[email-masked]> 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

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Jun 2008 14:19:26 -0400

Dave:

>Again, I hope we do not find ourselves in a he said/no he didn't 
>exchange.  I'll
>merely suggest that had the Discuss been immediately taken to the 
>public mailing
>list, it seems pretty likely that salient details would quickly have been put
>forward.

This is an individual submission, not a WG document.  So, there is no 
charter that lists the appropriate mail list for such a 
discussion.  That said, John did take the issue to a mail list.  I 
know this because someone forward his posting to me.  John did not CC 
me on the posting, which I interpret as not seeking dialogue at that point.

Russ

---

From: John C Klensin <[email-masked]>
Date: Mon, 23 Jun 2008 15:59:41 -0400

--On Monday, 23 June, 2008 14:19 -0400 Russ Housley
<[email-masked]> wrote:

> Dave:
> 
>>>> 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?
>>> raised.  It was not raised by John, the document PROTO
>>> shepherd, or  the IESG member sponsoring the document.
>> 
>> Again, I hope we do not find ourselves in a he said/no he
>> didn't  exchange.  I'll
>> merely suggest that had the Discuss been immediately taken to
>> the  public mailing
>> list, it seems pretty likely that salient details would
>> quickly have been put forward.
> 
> This is an individual submission, not a WG document.  So,
> there is no charter that lists the appropriate mail list for
> such a discussion.  That said, John did take the issue to a
> mail list.  I know this because someone forward his posting to
> me.  John did not CC me on the posting, which I interpret as
> not seeking dialogue at that point.

Russ, that note was sent to the mailing list after I received
your "change the document or appeal" note.   I believed that
note from you closed the door on any further dialogue with you
(or the IESG).  The note to the SMTP list was simply to collect
opinions on which of the two choices you gave me to adopt.

If you intended the "change the document or appeal" note to be
interpreted in any other way, I apologize for not copying you on
the question to the list, but I really could not figure out any
other way to read it (and cannot to this day).

best,
   john

---

From: Pete Resnick <[email-masked]>
Date: Mon, 23 Jun 2008 15:39:24 -0500

On 6/18/08 at 10:35 PM -0400, Russ Housley wrote:

>The I-D Checklist (IDnits, http://www.ietf.org/ID-Checklist.html), 
>Section 6, says:
>

Ahem. RFC 2119 is also pretty clear about two other things:

    In many standards track documents several words are used to signify
    the requirements in the specification.  These words are often
    capitalized.  This document defines these words as they should be
    interpreted in IETF documents.

I-D Nits ain't no "standards track document", and it barely qualifies 
as an "IETF document". It's certainly not an IETF consensus document.

But also:

6. Guidance in the use of these Imperatives

    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.

Indeed, the real potential for causing harm or failure to 
interoperate in the case of 2821bis would be to change all of the 
examples to "example.org", inadvertently screw it up in some 
interesting way, and cause people to implement incorrectly. In the 
case of a document where almost all of the examples have been left 
alone, and those examples have been in use for 7 years without 
problems, the burden of proof is on you to demonstrate harm if you 
want to put a DISCUSS on the document. If you want to put a COMMENT 
on the document, it is incumbent on the document editors to review 
the decision of 7 years ago and have them explain why that path was 
chosen. But unless there is *demonstrable* harm at this point in the 
life cycle of the document, it's an editorial issue that does not 
warrant a DISCUSS.

(To wit: Wouldn't it have been amusing if John had changed all of the 
examples to fit 2606 names and some AD came along and said, "DISCUSS: 
This document is heading for Draft Standard after 7 years of 
deployment. Even though I can't see an overt problem in the examples 
now used, changing them from perfectly good examples that have 
interoperated for 7 years without problem has the potential for harm. 
Please change them back to their original forms." I'd be far less in 
favor of an appeal against *that* DISCUSS.)

pr

---

From: Russ Housley <[email-masked]>
Date: Mon, 23 Jun 2008 16:11:32 -0400

>other way to read it (and cannot to this day).

That was in response you your note that said I needed to change my 
position from DISCUSS to COMMENT or you would appeal.  I was simply 
confirming the position that we had reached.  That position is now 
clear to all.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 24 Jun 2008 18:24:20 -0400

I'm sorry for the way that this discussion has gone. I joined the 
discussion in order to let the whole community see both sides of the 
disagreement.  However, in an attempt to provide clarity and correct 
inaccurate statements, the discussion turned into tit for tat.  The 
back-and-forth banter did not help any of the people that wanted to 
understand the issues or context for the disagreement.  For my part 
in that situation, I apologize.  I'll try very hard to not repeat my 
mistakes in the future.

As Chair of the IESG, I am going to do my best to find ways to reduce 
the number of late surprises.  This is in line with the goal that I 
set when I took on this position: incremental improvement to the IETF 
standards process.

The I-D Tracker and the way that IESG ballot positions are used is at 
the center of the issues raised by this appeal.  The I-D Tracker was 
built with two goals in mind.  First, it was intended to increase 
transparency.  Second, it was intended to help ADs manage the 
document review and approval process.  The first goal seems to have 
been achieved to a greater degree than I ever realized.  As a result, 
IESG members now find themselves being asked to explain processes 
that were previously invisible to the community.  As such, I think it 
is time to consider whether the IESG ballot structure needs 
revision.  The ballot was designed for ADs and the Secretariat; it 
tells whether a document is ready for approval.  Today, it appears 
that we also need a ballot that tells the document authors, WG 
chairs, and PROTO shepherds what actions are needed to move a document forward.

At this point I cannot give any explicit actions that will be taken, 
I sincerely hope that the handling of this appeal will provide 
insights for the next steps.  I think it is time to let the IESG 
process the appeal.

All the best,
   Russ

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Jun 2008 10:47:28 +0100

>
> At least three ADs believe that the examples should be changed
>

I agree with them.

Use of any identifier outside the example space may cause real harm to
the owner, where that harm may range from serious harm (technical
and/or financial)  to mild embarrassment.

If anyone wants to use an identifier outside the example space, then to
protect both the owner  of the identifier and the IETF, the author really
needs to provide the IETF with evidence of  written authorization to use
it for this purpose.

In the case of this draft, have the owners of the identifiers
been contacted by the author, and do they agree to this use?

Stewart

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Jun 2008 12:01:03 +0200

> been contacted by the author, and do they agree to this use?

You are aware that the same examples have been in a published RFC for 
over seven years?

BR, Julian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 25 Jun 2008 07:49:43 -0500

> You are aware that the same examples have been in a published RFC for over 
> seven years?

Because this point keeps getting overlooked, it's worth saying "... a 
published STANDARDS-TRACK RFC ...".

But, whatever. My suggestion is to stop posting in this thread and let the 
IESG do what they need to do, now that they have an appeal in hand. We're 
just distracting them and inflaming the community at this point.

They are actively discussing the topic, not just the appeal. From the most 
recent IESG telechat minutes:
6.2 IESG Statement on BCP 32 (Russ Housley)

    The management issue was discussed.

    Action Item: Magnus Westerlund to draft an IESG Statement on BCP 32.

(taken from https://datatracker.ietf.org/iesg/telechat/391/)

Jari has split off a new thread on "Measuring IETF and IESG trends" - 
obviously, that's not the kind of "posting in this thread" I'm hoping to 
discourage.

Thanks,

Spencer

---

From: John Levine <[email-masked]>
Date: 25 Jun 2008 14:40:39 -0000

>been contacted by the author, and do they agree to this use?

Perhaps you might want to compare the draft with RFC 2821, which was
published over seven years ago, and then reconsider the question.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

PS: Anyone know offhand the RFC for IP-over-Ouija-board?
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Tue, 24 Jun 2008 08:09:03 -0700

Russ Housley wrote:
> 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.

First, there is a difference between a reviewer's making an observation, versus
an Area Director's imposing it as a requirement.  The latter is the issue in the
appeal.

Second, even the reviewer said they didn't care about it.  So it is not merely a
possibility of having missed the reviwer's comment; it is that the reviewer
explicity removed any need for concern about their observation.

> infer trends.  In this case, the ID Checklist already includes a SHOULD 
> statement.  It could be more clear.  More about that below.

I'll ask again:  When did ID-Nits become an authoritative source, rather than a
summary of other sources?

And if it does indeed represent the sole venue for imposing some requirements,
by what approval process did these individual items get reviewed and approved?

This should be particularly explained with respect to the specific rule that you
are using as the basis for blocking the document.

And lastly, what has emerged from this exchange is a rather explicit
clarification that the IETF really has a two-state requirements model.

The first set of requirements is based on community consensus and the second on
IESG consensus, with the latter overriding whatever might be set by the first,
in terms of form, style or content.

This is, after all, the real implication of a framework which leaves the IESG
free to impose whatever judgment it wishes either in requirements documents it
issues without community approval, or Discuss vetoes it sustains.

To the extent that this summary of the IETF authority model is incorrect, how?

To the extent that it is correct, is this really what the community wants?

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Jun 2008 13:08:51 -0700

Russ Housley wrote:
> charter that lists the appropriate mail list for such a discussion.  
> That said, John did take the issue to a mail list.  I know this because 
> someone forward his posting to me.  John did not CC me on the posting, 
> which I interpret as not seeking dialogue at that point.

Hmmm...

Only because it got shot down so quickly and soundly, I'll indulge in some sour 
grapes:  Once upon a time, I suggested that all I-D's be required to specify a 
discussion venue.

What we have here, now, is an example of why that should be a requirement: An 
I-D is for the purpose of discussion. We need to facilitate it's happening.

For rfc2821bis, there was, in fact, an established discussion venue, and it 
long-standing and quite well known to the email community, namely 
[email-masked].

It could only have helped for that venue to have been known to others, 
particularly if folks wanted to pursue a "community" discussion about a concern 
with the draft.

And especially since rfc2821bis development was, in fact, pursued with exactly 
the same rough consensus process a formally-chartered chartered working group.

But your last sentence probably highlights a basic structural disconnect -- for 
want of a better term -- that we ought to think about fixing:  when an 
individual submission is actually the result of a group process, the group ought 
to be identified and direct dialogue with the group ought to take place, not 
depending upon mediation by an author or proto-shepherd.

d/

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Jun 2008 09:30:21 -0700

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Jun 2008 09:09:19 -0700

(re-posted, since the original apparently went out with an unsubscribed From: /d)

Russ,

> a penny, in for a pound ...

What I am seeing is a thread that had some bits of silliness, early on, but has
moved into serious, thoughtful efforts to put forward serious, albeit differing,
points of view.  Under those conditions and in terms of immediate and long-term
IETF health, I am quite sure it is wise for the principals of the current
situation to participate in a public exchange of this type:  After all, the IETF
is supposed to be about collaboration among equals.

Collaboration does not have to begin with agreement, but it does have to begin.
Having one or another party sit quietly off to the side hurts mutual
understanding and, therefore, mutual comfort in the outcome.

(I'll note that I found the latest postings by Ted Hardie and Robert Elz to be
compatible with my own views and particularly well written. I found them worth
re-reading.)

> The first hint of this issue surfaces during Last Call. 
...
...

As soon as discussion needs to review the timeline of the disagreement, we
probably have a prima facie basis for suspecting a problem with the process, not
just the people.  The reason is that such a review tends to turn into a debate
about what happened when, rather than about the substance of the Discuss.

I suspect there are ways to improve the mechanics of the process leading up to
and following a Discuss.  I'm not sure what those are, but the current mechanics
tend to favor informal, private exchanges which in turn favors limited, mediated
information and limited review.  These are not good for ensuring community
buy-in or, for that matter, the quality of the outcome.

I think that informal, private exchanges have an important role to play, because
their personal dynamics is far less charged than a public exchange.  But I
suspect the current mechanics could greatly benefit from being more public.

A simple suggestion that might help is that an Area Director who issues a
Discuss could be required to post their reasons to the working group mailing
list and be obligated to engage in a... discussion... about it, starting with a
careful explanation of their justification for blocking approval.

> text.  Vacation schedules will keep this from happening in the next few days.

At base, it is clear that the current appeal is not about John's willingness to
make changes.

It is about the application of a Discuss to force this kind of change and the
claim that formal authority for it is lacking.

> the IESG member sponsoring the document.

Again, I hope we do not find ourselves in a he said/no he didn't exchange.  I'll
merely suggest that had the Discuss been immediately taken to the public mailing
list, it seems pretty likely that salient details would quickly have been put
forward.

Again: having these authority-related exchanges be private makes them extremely
fragile and subject to problematic outcome.  Limited perspectives.  Partial
information.  Likelihood of entrenched positions. All of that disappears --
well, ok, maybe not, but at least it's reduced -- when the working group is
brought into the mix directly -- not mediated by a chair or author.

> confidence in their judgement?

If we are to have detailed rules, yet allow deviations from them, then what is
the point of the rules?

My own guess is that the real question is not about confidence in judgment but
about the types of judgment that should be called for.

I believe that a collaborative process which empowers a single person to block
progress is broken in a very fundamental way.

The premise of an open, collaborative process like the IETF has is that no
individual's view/opinion is definitive. The most knowledgeable, most skilled
and best-intentioned person has a bad day.  Poor judgment even within their area
of expertise, nevermind outside it.

In an IETF environment, choice is directed by the ability to garner group
support. This has direct long-term benefit: A choice dictated by a minority will
not have broad-based support.  One which really does represent rough consensus
has already overcome the major barrier to adoption:  a critical mass of the
community agrees with it.

We have a long-standing exception to this, when we ask IESG members to exercise
veto authority.  It sets one person's expertise against that of the folks who do
the work.  Worse, it is exercised at the end of their considerable effort.  In
the context of an IETF, this is strikingly dissonant.

Contrast this with the view that the considerable judgment of IESG members is
not for saying yes or no, but for raising flags.  It takes quite a lot of
skilled judgment to see when there is an embedded, subtle problem with a
specification.  And it takes quite a lot of skilled judgment to be able to
communicate this problem to the community, so that the community itself can form
rough consensus about the problem -- and the solution.

My view has been that was the intent behind choosing the word "Discuss" rather
than "No" or "Veto".

I happened to be on the IESG at the time.  While it was clear even then that
some specifications weren't salvageable, it was also clear that the job of
management in an IETF community was to facilitate development of community
understanding and decision, rather than to exercise raw authority.  (But then,
we were just coming off of the IAB Kobe debacle and were rather sensitive to the
exercise of authority.)

Let me suggest something radical:

      Let's have fewer rules, not more of them.  With fewer rules, there is a
greater burden to explore and negotiate legitimate concerns carefully and
explicitly.

      But if we are going to have detailed rules, let's follow them.

d/

-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Thu, 26 Jun 2008 11:17:47 -0700

Hi Dave,
At 13:08 23-06-2008, Dave Crocker wrote:
>For rfc2821bis, there was, in fact, an established discussion venue, 
>and it long-standing and quite well known to the email community, 
>namely [email-masked].
>
>It could only have helped for that venue to have been known to 
>others, particularly if folks wanted to pursue a "community" 
>discussion about a concern with the draft.

Section 1.2 of the draft specifies where the document was being 
discussed.  I assume that people commenting on the draft would have read that.

Regards,
-sm