Hi SM,
Pardon me;
1)Is there such thing as a "good enough" Criteria to handle this
concern?
2)Or as usual it passes "rough consensus" process?
Regards,
Medel
++++++++++++++++++++++++++++++++++++++++
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
SM
Sent: Friday, August 05, 2011 5:45 PM
To: Russ Housley
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: Last Call:
<draft-housley-two-maturity-levels-08.txt>(Reducing the Standards Track
to Two Maturity Levels) to BCP
Hi Russ,
At 12:28 PM 8/3/2011, Russ Housley wrote:
I am well aware of the implementation reports. The premise here is
that the protocol specification is "good enough" there are at least
two interoperable implementations and the protocol is deployed
widely. The implementation report would become optional.
One of the advantages of an implementation report is that it provides
a statement about interoperability between two or more known
implementations. If there is any dispute about that claim, it can be
resolved in a non-controversial way. Determining whether a protocol
is widely deployed is not always a clear-cut decision.
People are not doing many implementation reports. As you say above,
there are only about 75 of them. How many protocols are documented
in RFCs? That is a very low percentage in my view.
Yes, it's a very low percentage. I don't have the figure for the
number of protocols documented. Given the low barrier for such
reports, I would have expected to see more reports. After all, if
the RFC has been published, the protocol has been widely deployed, it
should simply have been a matter of filing the short report.
From draft-housley-two-maturity-levels-08:
"this document measures interoperability through widespread
deployment
of multiple implementations from different code bases, thus
condensing
the two separate metrics into one."
This change is expected to solve the problem. I am not convinced
that the metrics is the problem.
So, I see the cost quite differently. Most protocols are published
as Proposed Standards, and they are never advanced. I'm seeking a
process where implementation and deployment experience actually
improves the protocol specifications. Today, that rarely happens,
and when it does, the
Agreed.
I didn't find any incentive to inject implementation and deployment
experience into the process.
This is an argument for the status quo. We have decades of
experience with that not working. That is essentially an argument
for a single maturity level; that is how the process is really working
today.
I am not arguing for a single maturity level (the status quo). I do
not agree with the conclusion that the decades of stagnation is due
to the three maturity level.
This document is not about IESG review time, except for the
elimination of the requirement for annual reviews which are not done
anyway. If that is what you get from the document, then I have done
a very poor job in writing it. That is not the point at all.
I don't think that you did a poor job. A three maturity level
requires three IESG Evaluations. A two maturity level requires two
IESG Evaluations. If more documents moved from Proposed Standard to
the next level, it would obviously take more IESG review time.
I presume that the IESG will only use the following criteria for
advancement:
- two independent interoperating implementations with widespread
deployment and successful operational experience
- no errata against the specification
- no unused features in the specification
And there won't be any DISCUSSes along the lines of:
"I don't think the implementation reports are adequate for me to meet
the
requirements of 2026. It does not clearly identify what software
was used or
show support of each of the individual options and features."
"Examples througout the document make use of non-example domains."
"The implementation report is woefully inadequate to document there
are
interoperable implementations of all the features from two different
code bases."
"My Discuss was not addressed at all - I believe that the WG ignored
the
spirit of the implementation report requirement - my Discuss said
that
we should know that there are multiple implementations that have
handled the significant changes in the recycling of this Draft
Standard.
The group apparently refused to update its implementation report"
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
This e-mail message (including attachments, if any) is intended for the use of
the individual or the entity to whom it is addressed and may contain
information that is privileged, proprietary, confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that any
dissemination, distribution or copying of this communication is strictly
prohibited. If you have received this communication in error, please notify the
sender and delete this E-mail message immediately.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf