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

From: RJ Atkinson <[email-masked]>
Date: Tue, 26 Oct 2010 08:46:22 -0400

I support advancing this document to BCP and making
these process changes.    The changes will simplify
advancement of standards-track documents and be a
good step in the right direction.

Please do seek a sponsor for this draft.

Yours,

Ran Atkinson

---

From: [email-masked]
Date: Wed, 27 Oct 2010 08:53:57 -0700 (PDT)

> good step in the right direction.

Exactly. While I don't see how this document will fix several the high bar at
PS or the lack of advancement incentives, failure to fix those things doesn't
change the fact three level is one level too many. Simplifying things and
eliminating process clutter is helpful in and of itself.

I also believe that some of this process clutter acts as a sort of attractive
nuisance, allowing us to spend time turning the various knobs and pressing
the assorted buttons created by the clutter instead of having to address
issues directly.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 27 Oct 2010 09:35:37 -0700

On 10/27/2010 8:53 AM, [email-masked] wrote:
> three level is one level too many. Simplifying things and

By my reading of the proposal, this means that any spec with a couple of 
interoperable implementations can become a (full) Internet Standard.

This means that the assignment of that final status has nothing to do with 
real-world deployment and use, or even inclusion in products.

In other words, it has nothing to do with demonstrated utility.

Is that really what the IETF community wants?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: David Kessens <[email-masked]>
Date: Wed, 27 Oct 2010 10:10:38 -0700

Ned,

> the assorted buttons created by the clutter instead of having to address

Thanks for stating this so clearly. I also support the publication of
draft-housley-two-maturity-levels-02.txt as a BCP. From an operational
perspective, I believe it will be to the benefit of the IETF to bring the
written procedures more closely aligned with reality. In addition, the
simplification of the rules and procedures has its own benefits that should
not be understated.

David Kessens
---

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 27 Oct 2010 17:16:29 -0600

On 10/27/10 10:35 AM, Dave CROCKER wrote:
> This means that the assignment of that final status has nothing to do
> with real-world deployment and use, or even inclusion in products.
> 

I think there is a disconnect between the proposal as currently
structured and the core principle that the IETF community has always
professed: "rough consensus and running code".

As I understand it, running code means that the technology has been
deployed across the full breadth of the Internet, in services large and
small, by individuals and companies and service providers and
universities and government agencies and all the other kinds of entities
that are connected to the network. The technology doesn't need to be
universally deployed, but it does need to be widely deployed.

We can't achieve that kind of deployment in 6 months. We might achieve
that kind of deployment in 6 years.

We also can't measure that kind of deployment through rather informal
reports from the producers of two interoperable implementations. And if
we measure the wrong thing, we'll get the wrong results.

I don't think anyone in the IETF community wants to see the term
"Internet Standard" applied to a toy protocol merely because the
original designer just happened to convince one of his friends that it
would be cool to implement that protocol in a second hobby project.

"Internet Standard" is a weighty designation, and I think that to earn
it a technology community needs to show some weighty proof.

So I'm in favor of two maturity levels because it recognizes reality and
simplifies things in a reasonable way, but I think we need to reflect
more carefully and completely on how we determine if something is indeed
an Internet Standard.

And no, I don't yet have text to propose, although I'll get to work on
that...

Peter

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 27 Oct 2010 19:34:12 -0400

That depends on where the proposal is in the stack.

Cruft in the lower layers is decidedly bad. Cruft in the application layers
is inevitable and is best left to the market to sort out.

At this point with HTTP not recognized as an Internet Standard, I don't
think we need to worry too much about the bar having been set too low.

This is a process that is going to be run by humans, not machines. I don't
think we need to worry too much about them doing stupid things because that
is what the process appears to require.

On Wed, Oct 27, 2010 at 12:35 PM, Dave CROCKER <[email-masked]> wrote:

>
>
> On 10/27/2010 8:53 AM, [email-masked]<[email-masked]>wrote:
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

-- 
Website: http://hallambaker.com/

---

From: Eric Burger <[email-masked]>
Date: Wed, 27 Oct 2010 21:21:50 -0400

Look at RAI: I would be grateful if some proposals had running code that ran once.

---

From: [email-masked]
Date: Wed, 27 Oct 2010 17:45:25 -0700 (PDT)

> interoperable implementations can become a (full) Internet Standard.

That's effectively the case already. Check out the language in RFC 2026 section
4.1.3 -  it talks a bit about "significant" implementation and "successful"
operation, but imposes no concrete metrics the way the move to draft does.

What this translates to in practice is as long as there's a constituency asking
for advancement and the proposal has no obvious shortcomings, the move from
draft to full tends to be high on nuisance value and low on everything else.

> In other words, it has nothing to do with demonstrated utility.

Well, the implicit claim here is that our present process is making these sorts
of checks. In this regard, I think a comparison of the list of full standards
with the list of draft standards is in order to see if there's a marked
increase in utility associated with advancement, and to put it mildly, I don't
think the results of that comparison provide much support for your argument.

> Is that really what the IETF community wants?

I'm quite sure that in the abstract the IETF wants to only advance
specifications that are free from serious defect and which have demonstrable
utility. The question is whether or not the current draft->full process step is
providing suffficient benefit to be worth the cost. Unfortunately, I think the
answer to that is a pretty clear "no".

				Ned