Subject: When to DISCUSS?

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Jul 2005 11:22:30 +0200

As most RFC authors know, when an IESG member identifies a problem in
a draft under IESG review, he or she casts a DISCUSS ballot, with
accompanying text, and the DISCUSS has to be cleared before the
document can advance.

draft-iesg-discuss-criteria-00.txt talks about this. Even within the
IESG, we still have one or two points to resolve, but we wanted to get
this out before the cutoff date. This isn't in any way intended to change
any of the principles of the standards process, but we'd welcome
community comment.

    Brian

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Internet Engineering Steering Group Working Group of the IETF.
> 
> 	Title		: DISCUSS Criteria in IESG Review
> 	Author(s)	: J. Peterson, et al.
> 	Filename	: draft-iesg-discuss-criteria-00.txt
> 	Pages		: 10
> 	Date		: 2005-7-7
> 	
>    This document describes the role of the 'DISCUSS' position in the
>    IESG review process.  It gives some guidance on when a DISCUSS should
>    and should not be issued.  It also discusses procedures for DISCUSS
>    resolution.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-iesg-discuss-criteria-00.txt

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

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 08 Jul 2005 16:05:04 +0200

>any of the principles of the standards process, but we'd welcome

I have a problem  It concerns the need of non IESG DISCUSS by concerned 
authoritative entities whose personal opposition may block the adhesion of 
the Internet community to the RFC. I will illustrate with the IANA aspects.

When a RFC calls for a IANA Registry management, the IANA under RFC 2860 
should comply with it. We however have a grey area which concerns the 
applications involving for example ISO 3166 (country codes), ISO 639 
(languages), ISO 11179 (Registires), etc. I name some which are in the 
current debate today. But it is likely that the convergence, the universal 
development of the Internet, etc. will lead to such situations where an 
IETF defined registry using external standards leads to correlations 
opposed by those who accepted the standard.

This problem is obviously a ransom of the Internet success, but it is a key 
problem for the Internet and IETF integration.

I have no specific solution here, but I say two things:

1. the joint committes and liaisons with other SDOs should have the 
possibility to rise a DISCUSS flag

2. the IANA should not be forced to accept the management of a Directory 
without the issue being agreed with all the concerned parties. The major 
evolution of the Internet we face is the distribution of the IANA functions 
(USA initiated a move I work on for four years). It is of the utmost 
importance that we avoid an "alt-root" situation here, all the more than 
the first partners will most probably include Governements and the next 
ones concerned cultures. It is therefore of the essence that the conference 
of the distributed National/Regional/Local/Corporate/Private Centers of 
References, whatever it may be built as, has the capacity to DISCUSS a 
Registry specified in an RFC and prevent its parameter polution by 
disagreeing Reference Centres Managers.

This is particularly true for the Registries where the ISO standards above 
are considered (ISO 3166 is the most widely used ISO table and is clearly 
identified in the Internet to ccTLDs for national communities and to GAC 
for Governments, ISO 639 series identifies languages, what means commonly 
cultures [English speaking people and young cultures use to attach more 
their culture to Nations, Religions, etc.]).

I know some will object that this is not the way the Internet is specified. 
Or that this is not the way it should work. Or this is L8/L9 concerns out 
of IETF/IESG scope. The same as some said and may be continue to say that 
for the root. This will not change that this is the way the root works 
today and this is the way the IANA starts being considered today.

Establishing rules taking reality into account, will only permit to smooth 
the transition from a mono-default to a multi-enacted parametered internet. 
The Internet partitionning (legacy, regalian, national, cultural, 
proximity, trade, kids, private, etc.) is a necessity: the USA just 
affirmed it for their own account; I identified and documented it here 
nearly two years ago. We have now to progressively acknowledge it and build 
the procedures and projects which will help making it a concerted 
compartmentalisation rather than to close our eyes on the wild 
balkanisation now engaged.

jfc

>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>directories.is draft is a work item of the Internet Engineering Steering 
>>Group Working Group of the IETF.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 12 Jul 2005 01:01:33 -0500

> any of the principles of the standards process, but we'd welcome

Dear Brian,

Thank you (and Jon, and Allison, and Margaret, and the rest of the et. 
al IESG) for producing this draft. At a high level, it is another 
welcome increase to IESG transparency (at least as good a reason to 
produce this draft as the two stated - new AD training and greater 
consistency between ADs).

I have a small number of suggestions I would like to make. I know the 
draft requested comments to [email-masked], but several others have 
commented here, and I am rarely reluctant to post to this list when I 
express a variety of opinions, so saying something nice in the same 
place seemed only fair!

- It is probably helpful to include a reference to a complete list of 
possible ballot positions in the Introduction (something like 
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_evaluation_desc, 
but you probably know the appropriate pointer - and I notice that this 
URL is titled "Explanation of DISCUSSes", but it is actually an 
explanation of all ballot otions).

- One point I took away from the recent chat about IANA registration 
on this list is that a substantial portion of the community thinks 
that when the IESG speaks, the IESG has spoken.

I understand that the term "discuss" is chosen intentionally (there is 
no "how long have you been smoking crack?" ballot option), and believe 
that the IESG actually expects the authors/editors/working group 
chairs/working group to "discuss" the draft with the AD/IESG, but I 
believe that a significant portion of the community hears "discuss", 
they think the IESG means "Discuss" (capitalized for emphasis), or 
maybe even "DISCUSS" (the IESG equivalent of a bullet through the 
forehead), and they start randomly changing text or otherwise folding 
up like cheap furniture, instead of expressing what the working group 
was trying to do in the DISCUSSed text.

I would suggest one paragraph that says something like "when we say 
"discuss", we mean this in the common English sense, even if we spell 
it in all caps, and we really do want a dialog, not random changes to 
a specification in the hopes of placating us and getting the DISCUSS 
removed".

This would naturally fit at the beginning of Section 4 ("Discuss 
Resolution"), but I would like to see all of "Section 4" appear as 
context before the rest of the discussion about how DISCUSS can and 
cannot happen.

- I thought that historically the IESG had the most irritated AD hold 
the DISCUSS for a draft, instead of having five separate DISCUSSes 
that might be resolved in conflicting ways. If this is still current 
practice, you might mention this, and explain why.

- I agree with the list of DISCUSS Criteria, but 
http://www.ietf.org/rfc/rfc3967.txt is probably worth mentioning in 
the bullet on downrefs.

- I agree with the list of DISCUSS Non-Criteria ("thank you!"), but 
would like to see the "cross-area" bullet phrased so that it states 
what SHOULD have happened - something like,

   o  There is recent work or additional information that might be 
added
      to the document.  Although the cross-area perspective of the 
IESG
      invites connections and comparison between disparate work in the
      IETF, cross-area review should have happened before IESG review,
      and if this has not happened, it is evidence of a process 
failure.

- I'm not sure I "get" 3.3 ("saying no to a document"), for these 
reasons:

(1) If the irritated AD votes "abstain", the document doesn't say what 
the resolution path is - is the idea that some other AD who didn't 
write the comments reads them and votes "DISCUSS - Marvin's comments 
are right, or you need to explain why they are not right"? Or is an 
ABSTAIN with very irritated comments somehow a special state?

(2) The ABSTAIN path (assuming that (1) is explained fully) seems 
entirely sufficient, without adding the "However" path, where the 
irritated AD writes the comments and still votes DISCUSS. How strongly 
does the IESG feel about this? To me, it is edging toward "IESG as 
protector of the universe", but it assumes that the AD can't convince 
anyone else to vote DISCUSS (or whatever the path through (1) is). The 
DISCUSS path seems like the weakest part of this very good 00 draft. 
But maybe I just don't understand the path through (1) well enough to 
understand the difference between the ABSTAIN option and the DISCUSS 
option.

(3) The description of the ABSTAIN path says "writes up the comments", 
and the description of the DISCUSS path says "explain his or her 
position as clearly as possible in the tracker". Is this really 
different, or just the kind of thing that happens the week before the 
00 cutoff? (I know it happens in MY 00 drafts!) I still wish there was 
some reference to the comments on this evil, evil draft actually 
appearing in the mailing list that is theoretically the archive for 
discussions about the specifications produced by the working group, 
but let's let that lie for now.

- The first paragraph in Section 4 is more specific than "the people 
who need to discuss the draft, discuss the draft", but not a lot more 
specific. I understand that many possible combinations of AD/ADs/IESG 
and editor(s)/working group chair(s)/working groups may end up as 
parties to the discussion, but I would like to see text that finally 
assigns responsibility for negotiating DISCUSS resolution to SOMEbody 
(not sure I care who). If there was a sentence that says "DISCUSSes 
are supposed to be serious and relatively rare, so DISCUSS resolutions 
should be posted to the appropriate mailing lists before the document 
appears on the next IESG telechat agenda", that would be lovely. Other 
sentences with other nouns might be lovely as well.

Again, thank you for spending the time to hammer out the first version 
of this draft.

Spencer

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Jul 2005 18:08:22 -0400

>>>>> "Spencer" == Spencer Dawkins <[email-masked]> writes:

    Spencer> - It is probably helpful to include a reference to a
    Spencer> - One point I took away from the recent chat about IANA
    Spencer> registration on this list is that a substantial portion
    Spencer> of the community thinks that when the IESG speaks, the
    Spencer> IESG has spoken.

    Spencer> I understand that the term "discuss" is chosen
    Spencer> intentionally (there is no "how long have you been
    Spencer> smoking crack?" ballot option), and believe that the IESG
    Spencer> actually expects the authors/editors/working group
    Spencer> chairs/working group to "discuss" the draft with the
    Spencer> AD/IESG, but I believe that a significant portion of the
    Spencer> community hears "discuss", they think the IESG means
    Spencer> "Discuss" (capitalized for emphasis), or maybe even
    Spencer> "DISCUSS" (the IESG equivalent of a bullet through the
    Spencer> forehead), and they start randomly changing text or
    Spencer> otherwise folding up like cheap furniture, instead of
    Spencer> expressing what the working group was trying to do in the
    Spencer> DISCUSSed text.

YES!  It's very frustrating to me when I ask a blocking question and
get a note saying that "the new draft addresses your discuss."  I have
to figure out what changed and then try to imply an answer to my
question.  I'd much rather have a dialogue.

    Spencer> I would suggest one paragraph that says something like
    Spencer> "when we say "discuss", we mean this in the common
    Spencer> English sense, even if we spell it in all caps, and we
    Spencer> really do want a dialog, not random changes to a
    Spencer> specification in the hopes of placating us and getting
    Spencer> the DISCUSS removed".

Yes.

    Spencer> This would naturally fit at the beginning of Section 4
    Spencer> failure.

    Spencer> - I'm not sure I "get" 3.3 ("saying no to a document"),
    Spencer> for these reasons:

Section 3.3 is mostly my fault so I'll try and defend it.

The fact is that there is some possibility an AD will want to try and
convince the IESG that a document is so bad it should not be
published.  If we don't clearly document suggestions on how to do
this, a lot of bad things will happen.  First, in the middle of trying
to deal with a specific document we'll be debating what procedures to
use.  People will be more upset about the process issues than the
actual technical issues.  Things will take a lot of time and they will
not be efficient.  Instead, what I'd like to do is have suggestions
written down ahead of time on how to behave so that we can quickly
determine how the IESG as a whole feels about the document.  If more
than 4 ADs don't want to see the document  go forward, then clearly we
need to spend some significant time on it.  (passing a document
requires 9 ADs on the current IESG).  If only 1 person feels the
document should be stopped and the other ADs have already carefully
considered    the issue, well, we run on rough consensus.  

    Spencer> (1) If the irritated AD votes "abstain", the document
    Spencer> doesn't say what the resolution path is - is the idea
    Spencer> that some other AD who didn't write the comments reads
    Spencer> them and votes "DISCUSS - Marvin's comments are right, or
    Spencer> you need to explain why they are not right"? Or is an
    Spencer> ABSTAIN with very irritated comments somehow a special
    Spencer> state?

Generally it's a special state: you are mostly admitting that you are
part of the rough rather than the consensus and you expect the
document to go forward despite your objections.  The only case this is
not true is when too many people vote abstain.

    Spencer> (2) The ABSTAIN path (assuming that (1) is explained
    Spencer> fully) seems entirely sufficient, without adding the
    Spencer> "However" path, where the irritated AD writes the
    Spencer> comments and still votes DISCUSS. How strongly does the
    Spencer> IESG feel about this? To me, it is edging toward "IESG as
    Spencer> protector of the universe", but it assumes that the AD
    Spencer> can't convince anyone else to vote DISCUSS (or whatever
    Spencer> the path through (1) is). The DISCUSS path seems like the
    Spencer> weakest part of this very good 00 draft. But maybe I just
    Spencer> don't understand the path through (1) well enough to
    Spencer> understand the difference between the ABSTAIN option and
    Spencer> the DISCUSS option.

So, I at least feel really strongly about the discuss path.  The
problem with the abstain path is that part of forming consensus is
taking the time to understand the people you disagree with.

I want the opportunity to stop the document for a week or so--possibly
a bit longer--to try and explain to others why it is broken.
Practically speaking the way to do that on our ballots is a discuss.
I should only use this discuss to get an opportunity to explain my
position and to work with people to make up their minds.  I should do
something else with my discuss as soon as any of the following are
true: the discussion is not making progress, everyone understands me
and has made up their mind, or too much time has passed.  I don't
think specific time limits should apply, but I think the chair of the
IESG should be very sensitive to claims from the document authors and
the proponents of the document on the IESG that the discussion has
dragged on too long.

If I had started with an abstain, I would not have been given this
opportunity.  People would probably read my abstain comments, but in
general abstain comments do not even get discussion in the telechat.

Once the discussion is done, I can do one of two things.  In most
cases I'll want to change my vote to an abstain.  The outcome is
probably reasonably clear and I'll either have convinced enough people
or not.

However another thing I could do is insist on an override vote.  The
reason I would do that is that an override vote has different voting
criteria than a normal vote.  It takes 5 ADs to say no to a document
on a normal vote and 3 on an override vote.  I don't think it would be
wrong to use the override mechanism provided that  you did it quickly
and did not use it as a delaying tactic.

    Spencer> (3) The description of the ABSTAIN path says "writes up
    Spencer> the comments", and the description of the DISCUSS path
    Spencer> says "explain his or her position as clearly as possible
    Spencer> in the tracker". Is this really different, or just the
    Spencer> kind of thing that happens the week before the 00 cutoff?

Text written by different authors.

    Spencer> (I know it happens in MY 00 drafts!) I still wish there
    Spencer> was some reference to the comments on this evil, evil
    Spencer> draft actually appearing in the mailing list that is
    Spencer> theoretically the archive for discussions about the
    Spencer> specifications produced by the working group, but let's
    Spencer> let that lie for now.

I'm not sure this draft is the right place for that discussion but I
completely agree with you.

    Spencer> - The first paragraph in Section 4 is more specific than
    Spencer> "the people who need to discuss the draft, discuss the
    Spencer> draft", but not a lot more specific. I understand that
    Spencer> many possible combinations of AD/ADs/IESG and
    Spencer> editor(s)/working group chair(s)/working groups may end
    Spencer> up as parties to the discussion, but I would like to see
    Spencer> text that finally assigns responsibility for negotiating
    Spencer> DISCUSS resolution to SOMEbody (not sure I care who). If
    Spencer> there was a sentence that says "DISCUSSes are supposed to
    Spencer> be serious and relatively rare, so DISCUSS resolutions
    Spencer> should be posted to the appropriate mailing lists before
    Spencer> the document appears on the next IESG telechat agenda",
    Spencer> that would be lovely. Other sentences with other nouns
    Spencer> might be lovely as well.

The proto shepherd (or document shepherd for non-proto documents) is
responsible for making sure progress happens on resolving discussions.
I'd assume that you would complain to the document shepherd and/or
IESG chair if the process is failing.