Subject: Re: draft-housley-two-maturity-levels

From: [email-masked] (Scott O. Bradner)
Date: Thu, 28 Jul 2011 08:19:04 -0400 (EDT)

this is better than the last version but

1/ I still see no reason to think that this change will cause any
significant change in the percent of Proposed Standards that move up the
(shorter) standards track since the proposal does nothing to change the
underlying reasons that people do not expend the effort needed to
advance documents

2/ one of the big issues with the PS->DS step is understanding what
documentation is needed to show that there are the interoperable
implementations and to list the unused features - it would help a lot to
provide some guidance (which I did not do in 2026 - as I have been
reminded a number of times :-) ) as to just what process is to be
followed

could be
	a spread sheet showing features & implementations
	an assertion by the person proposing the advancement that the
requirements have been met
or something in between

Scott

---

From: Robert Sparks <[email-masked]>
Date: Thu, 28 Jul 2011 09:19:45 -0400

Scott -

Didn't RFC 5657 address your point 2?

The current proposal no longer requires this report during advancement, but it does not disallow it.
I hope it's obvious that I believe these reports are valuable, but I am willing to accept the proposed
structure, with the hope and expectation that  communities that are serious about producing and 
refining protocols will be producing these reports anyhow.

RjS

On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote:

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

---

From: Eric Burger <[email-masked]>
Date: Thu, 28 Jul 2011 10:03:01 -0400

And the real question is, are we moving forward? I think that we are not moving as far as we originally wanted. However, I offer we are moving a baby step forward, and as such is worthwhile doing.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Jul 2011 10:06:56 -0400

On 7/28/11 10:03 AM, Eric Burger wrote:
> And the real question is, are we moving forward? I think that we are
> not moving as far as we originally wanted. However, I offer we are
> moving a baby step forward, and as such is worthwhile doing.

We are more closely aligning our documentation with our organizational
running code. All other things being equal, that's a good thing. That
doesn't imply that all of our organizatioal running code is bug-free. We
could have a broader conversation about the latter, but IMHO that's
outside the scope of this baby step forward.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Jul 2011 10:20:33 -0400

On Jul 28, 2011, at 10:06 AM, Peter Saint-Andre wrote:

> running code. All other things being equal, that's a good thing.

Hmm.  I've long believed that :

- trying to document existing practice
- trying to document desirable practice

are both worthwhile endeavors, as long as you don't try to do both at the same time.  When you try to do both at the same time, there is a conflict.

If someone wants to write a document that says we generally follow RFC 2026, except that:

- drafts hardly ever advance to Draft Standard and even more rarely to Full Standard, unless there is significant use of the protocol and there are bugs that need to be fixed (in which case the ability to advance can sometimes serve as an incentive of sorts)
- we have never been serious about periodic review of standards and we don't have enough time/energy to do that
- we've never really nailed down what Historic meant, and when it was appropriate to use it

etc.

that would be a fine thing.

And real changes to the process, say to bring in formal cross review earlier, to clarify the nature of community consensus and the need for it, etc. might also be a fine thing.  Unfortunately, such discussions are always contentious and difficult, because they affect the whole community, but they also attract a lot of interests from individuals with particularly unique axes to grind.  So we keep trying to fix the substantive problems with incremental changes.  I forget who it was who said yesterday that we can't really do that, but I certainly agree with him.

Meanwhile, it's not clear to me that simply changing from one document that we don't strictly follow, to another document that we won't follow much better, is helpful.  And I don't think IETF's problems with standards quality or process can be addressed merely by changes to the number of maturity levels.  That strikes me as a bit like rearranging deck chairs...it might make people feel better but is of little consequence.

In other words, I'm not convinced that this change will do much harm, but I'm also not convinced that it will help much.  And yet we keep flogging this idea...

Keith

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Jul 2011 10:31:57 -0400

On 7/28/11 10:20 AM, Keith Moore wrote:

> In other words, I'm not convinced that this change will do much harm,
> but I'm also not convinced that it will help much. 

I don't disagree.

> And yet we keep
> flogging this idea...

But we always flog the easy issues, rather than facing the tough ones.

It would be good to start talking about the tough issues, but IMHO there
is some value in settling on two maturity levels as well.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Jul 2011 11:07:38 +1200

Keith,

> If someone wants to write a document that says we generally follow RFC 2026, except that:

Been there, done that, it sank like a stone.

Let's just make this baby step and stop worrying about it.

   Brian

---

From: Pete Resnick <[email-masked]>
Date: Sat, 30 Jul 2011 11:55:45 -0500

> Let's just make this baby step and stop worrying about it.

Not to pick on Eric and Brian alone; I put this to everyone.

I *really* want an answer to the issue that Scott raises. Eric and Brian 
each refer to a "baby step". A baby step toward what exactly?

If the answer is simply, "to align documentation with current 
procedure", that's fine, but then I want to know: a) Why is it useful 
and positive to line up documentation with current procedure? That is, 
what are we gaining by publishing this? and b) This document is 
identical to neither 2026 *nor* current procedure, so how is it 
accomplishing the goal of aligning with current procedure anyway?

If the answer is, "Yes, this document will cause a change in the percent 
of Proposed Standards that move up", then I want to know "How?", because 
like Scott, I haven't heard the answer stated in this dicussion.

If you think I've missed an obvious alternative reason to go ahead with 
this document, I'm open to hear it, but it sounds like the only two 
alternatives expressed so far are, "Document current practice" and 
"Improve number of documents moving along standards track", and I 
haven't heard how this document does either of those things.

I consider this an open, unaddressed, issue.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 30 Jul 2011 13:05:18 -0400

It seems to me that this does two things, both small but useful.
1) It makes a minor change in the advancement procedures so that they 
are more reasonable.  They may still not be sufficiently reasonable to 
be used, but it improves them, and thereby improves the odds.
2) It is coupled to an intent to actually behave according to what the 
document says.  Such an intent is obviously not feasible without some 
change.  It is useful to have our behavior and our documented 
description of how we work match because the mismatch causes confusion, 
at least for new participants, and sometimes even for experienced 
participants.

It might be the case that it will improve the advancement percentage. 
It might not.  I can not imagine that it will make that even worse.

So, it seems to me that this matches the description that Eric, Brian, 
and others have used of a baby step that is not harmful and may be helpful.

Yours,
Joel

---

From: John Leslie <[email-masked]>
Date: Sat, 30 Jul 2011 15:31:38 -0400

Pete Resnick <[email-masked]> wrote:
> procedure", that's fine, but then I want to know:
> a) Why is it useful and positive to line up documentation with current
>    procedure? That is, what are we gaining by publishing this? and
> b) This document is identical to neither 2026 *nor* current procedure,
>    so how is it accomplishing the goal of aligning with current
>    procedure anyway?

   Although, to tell truth, I don't care very much whether this I-D
becomes an RFC, I am _very_ glad that Pete is raising these questions.

   We have been wandering in the weeds for years now over "how many
steps should there be?" IMHO, the last serious WG effort (newtrk)
reached something very like consensus that that was the wrong question.

   I _seriously_ hope the IESG will either decide to enact this I-D or
stop beating this horse.

   I suggest that we accept the principle that "consensus" process
means it will be hard to change something in the future; and admit
that "adjust to current practice" isn't a sufficient shibboleth to
gain consensus for a change from a previous consensus.

   It _is_ appropriate for anyone sufficiently bothered by failure to
follow current documented rules to appeal actions which don't follow
the "rules". That _will_ make you unpopular with the folks that must
process the appeal, but it is less harmful than asking the entire IETF
to wander in the weeds in seek of consensus to change the "rules".

   If I may make a suggestion, actual practice could be documented on
ietf.org web pages (with some explanation of how it differs from the
RFC "rules" and why) -- without all this wandering in the weeds. It
is _really_ unlikely that would invoke the full appeal process more
than once, and it would save a lot of bandwidth on this list.

   BTW, while I do intend to be silent if the IESG adopts this I-D
for publication, that does _not_ mean I will be silent when the next
"adjust to current practice" I-D comes up.

--
John Leslie <[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 31 Jul 2011 08:40:30 +1200

Hi Pete,

On 2011-07-31 04:55, Pete Resnick wrote:
...
> what are we gaining by publishing this? 

I believe that the present situation is confusing both to IETF newcomers
(who may falsely believe that the IETF actually follows the 3 stage process)
and, worse, confusing to users of IETF standards (who may falsely believe
that a document isn't useful until it's advanced). We, and those users,
gain by reducing the confusion. (Note: I did not write "eliminating the
confusion".)

> and b) This document is

It defines a practice which is *very* close to present practice,
apart from a minor name change. I think that's the best we can do,
but that's why it's a baby step, not a no-op.

> like Scott, I haven't heard the answer stated in this dicussion.

It might cause a change, simply because the effort of making the single
move PS->IS will get you to the end state, whereas previously you had
to make two efforts, PS->DS->STD. But only time will tell if this changes
our collective behaviour.

   Brian

---

From: Scott O Bradner <[email-masked]>
Date: Thu, 28 Jul 2011 14:39:24 -0400

it looks so - maybe it would be good to have a pointer in this doc

Scott

>> requirements have been met

Scott Bradner

Harvard University Information Technology
Security | Policy, Risk & Compliance
+1 617 495 3864
29 Oxford St., Room 407
Cambridge, MA 02138
www.harvard.edu/huit