Subject: Proposed Standard requirements

From: Dave Cridland <[email-masked]>
Date: Thu, 6 Mar 2014 17:11:07 +0000

Detaching from a thread about moving a particular specification from
Experimental to PS - this means I'm (quite deliberately) taking Barry and
Cyrus Daboo's quotes out of their proper context here, please bear this in
mind.

But I happened to be talking about this recently, and this has reminded me.

On 6 March 2014 16:51, Barry Leiba <[email-masked]> wrote:

> > My point here is that until we have interoperable implementations on both
> > client and server and have caught and fixed any issues in the spec, we
> > shouldn't advance the status.
>
> Why not?  Interoperable implementations aren't required for Proposed
> Standard.  Internet Standard, sure, but not PS.  The requirement for
> PS is that we think we got it right.
>
>
So this made sense when Proposed Standard actually meant Proposed, rather
than Standard.

But now that Proposed Standard actually means Draft, because (to paraphrase
Scott Bradner), we've left-shifted our standards process, why aren't we
requiring implementation experience for PS?

We've tightened up review a far bit, and raised the bar for spec quality in
general, but since PS is now DS by any other name, it's had the effect of
side-stepping the "two independent interoperable implementation"
requirement.

> I would like to see more implementation experience -- it's be great to
> see.  That's why I asked whether there is any.  But to me, the gating
> factor is more about whether there's *interest* in implementing it.
>
>
Wouldn't it be great to require? Running code and all that, after all...

Dave.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Mar 2014 06:29:21 +1300

On 07/03/2014 06:11, Dave Cridland wrote:
...

> But now that Proposed Standard actually means Draft, 

It was Draft that we abolished, and we did *not* change the
criteria for Proposed. In fact I understood that the idea
was to counteract the "left-shift".

So no, we are not supposed to require experience for PS.
RFC 6410 is quite clear about this: "The stated requirements
for Proposed Standard are not changed; they remain exactly
as specified in RFC 2026."

  Brian

---

From: [email-masked]
Date: Thu, 06 Mar 2014 10:07:30 -0800 (PST)

> requiring implementation experience for PS?

That's one, IMO extreme, way to look at it. The other extreme is that we've
noted that the difference between draft and full was essentially meaningless
and gotten rid of it, leaving PS completely unchanged.

Both extreme views fail to capture the nuances of the shift. Indeed, since this
is an ongoing process and we have relatively little experience with our current
two level approach, any current view is going to be based on scant data.

But I think it's safe to say that PS now means more, but neverthess falls short
of what draft used to mean.

> side-stepping the "two independent interoperable implementation"

Sorry, I reject the implication this question is based on. PS is not the same
as draft used to be. Which leaves open the question of how much more
should now be required for PS.

I am comfortable with making implementation experience a SHOULD for PS. But
nothing more than that. In particular, interoperability testing of multiple
implementations is far too high a barrier for PS.

And there are going to be exception, where for various reasons implementation
prior to approval is impractical.

> Wouldn't it be great to require? Running code and all that, after all...

First, running code is not the same as multiple interoperable implementations,
which is what draft used to mean.

Second, as many others have noted, the existence of running code doesn't mean
as much as it used to. Our collective ability to make pigs fly should never be
underestimated. In fact I'll channel my inner Pete and say that simple
assertions that "I implemented this" are of no real use to me, nor, I suspect,
to anyone else.

What I really want to is is statements of the form, "I implemented foo, here's
what was eesy, here's what was hard, here's what made no sense." That
sort of thing helps me immensely when deciding whether or not something
is worth doing.

				Ned

---

From: S Moonesamy <[email-masked]>
Date: Thu, 06 Mar 2014 10:27:07 -0800

Hi Dave,
At 09:11 06-03-2014, Dave Cridland wrote:
>So this made sense when Proposed Standard actually meant Proposed, 
>rather than Standard.

Quoting Olaf, Sean and Scott:

   "A Proposed Standard specification is stable, has resolved known
    design choices, has received significant community review, and
    appears to enjoy enough community interest to be considered valuable.

    Usually, neither implementation nor operational experience is
    required for the designation of a specification as a Proposed
    Standard.  However, such experience is highly desirable and will
    usually represent a strong argument in favor of a Proposed Standard
    designation."

>But now that Proposed Standard actually means Draft, because (to 
>paraphrase Scott Bradner), we've left-shifted our standards process, 
>why aren't we requiring implementation experience for PS?

There is an IETF Area which requires implementation 
experience.  There can be cases where implementation experience may 
be needed as you cannot go back if you break stuff.

>We've tightened up review a far bit, and raised the bar for spec 
>quality in general, but since PS is now DS by any other name, it's 
>had the effect of side-stepping the "two independent interoperable 
>implementation" requirement.
>

"Two independent implementations" is not running code.  Running code 
is what is deployed out there.  There is likely a thread in the YAM 
archives about "widely deployed".  Lab tests do not unearth problems 
which can be encountered in the wild.

In terms of compliance, do you test the implementations against RFC 
821 or RFC 5321?  Please note that I have looked into what is being 
required out there.

There is the gating factor.  There is a BCP about documenting 
implementation experience which is now in an unknown state (the 
reader would have to do a thorough read of BCP 9 to find out 
why).  There is a thread of (IRTF) CFRG relevant to "Proposed 
Standards ( 
http://www.ietf.org/mail-archive/web/cfrg/current/msg04327.html 
).  This is where a person might wonder what the gating factor is in practice.

I am biased when I participate in a discussion about a Proposed 
Standard, i.e. I know the background; I know the finer points raised 
in the discussions but which are not in the Proposed Standard.  I 
take these finer points into consideration as I implement the 
specification (before the specification becomes a RFC).  I find it 
difficult to assess the readability of an intended Proposed 
Standard.  It matters as the specification will have to be readable 
by someone out there who will be implementing it.

Regards,
S. Moonesamy