Hi.
The recent discussion about DISCUSS and DS/IS documents has
inspired me to go back and think about the two maturity levels
draft again. Sadly, it hasn't changed my mind but has, in some
respects, reinforced and strengthened my earlier view that this
is not a good idea and is not harmless.
--On Thursday, September 01, 2011 08:10 -0700 Dave CROCKER
d...@dcrocker.net wrote:
...
Folks should remember that this is a system that has been
functioning quite well for some decades and I am not aware of
any recent emergencies that justify starting over or making
major changes.
The
I pretty much agree, although one form of discuss might be
reasonable: This document needs to be recycled at Proposed
Standard because of the following *observed* interoperability
problem:
In other words, once we have got this BCP out (soon, please),
the IESG should update the DISCUSS
On Aug 14, 2011, at 5:49 AM, jari.ar...@piuha.net wrote:
I pretty much agree, although one form of discuss might be
reasonable: This document needs to be recycled at Proposed
Standard because of the following *observed* interoperability
problem:
In other words, once we have got this
Keith,
However, as with most things I don't think there are hard and fast
rules.
I agree that such things need to be described, but I don't think this
description should be gated on, or wait for, advancement in grade. The
errata mechanism can be used to report some kinds of
On Aug 14, 2011, at 9:24 AM, jari.ar...@piuha.net wrote:
What I tried to say above is that I dislike hard rules such as:
- We should never require a -ds document to say additional things
- We should always apply the most recent IETF approved rules (such as BCP
109 on key management) to all
jari.ar...@piuha.net wrote:
Keith,
However, as with most things I don't think there are hard and fast
rules.
I agree that such things need to be described, but I don't think this
description should be gated on, or wait for, advancement in grade. The
errata mechanism can be used to report
I really have to wonder if the entire yes/no-obj/discuss voting model
is appropriate for document advancement. For initial approval at
proposed, sure, having the ability to discuss the document makes
all sorts of sense. But for subsequent steps that virtue is a lot
obvious, to me at least.
To add one observation to SM's comment and other observations
that the scarcity of implementation reports implies that they
are somehow difficult...
--On Friday, August 05, 2011 02:45 -0700 SM s...@resistor.net
wrote:
I presume that the IESG will only use the following criteria
for
On 2011-08-14 06:29, ned+i...@mauve.mrochek.com wrote:
...
I really have to wonder if the entire yes/no-obj/discuss voting model is
appropriate for document advancement. For initial approval at proposed, sure,
having the ability to discuss the document makes all sorts of sense. But
for
ned+i...@mauve.mrochek.com ned+i...@mauve.mrochek.com wrote:
I really have to wonder if the entire yes/no-obj/discuss voting model
is appropriate for document advancement. For initial approval at
proposed, sure, having the ability to discuss the document makes
all sorts of sense. But for
On 2011-08-14 06:29, ned+i...@mauve.mrochek.com wrote:
...
I really have to wonder if the entire yes/no-obj/discuss voting model is
appropriate for document advancement. For initial approval at proposed,
sure,
having the ability to discuss the document makes all sorts of sense. But
On Aug 13, 2011, at 4:43 PM, John Leslie wrote:
ned+i...@mauve.mrochek.com ned+i...@mauve.mrochek.com wrote:
I really have to wonder if the entire yes/no-obj/discuss voting model
is appropriate for document advancement. For initial approval at
proposed, sure, having the ability to discuss
+1
d/
--
Dave Crocker
bbiw.net
via mobile
-Original Message-
I pretty much agree, although one form of discuss might be
reasonable: This document needs to be recycled at Proposed
Standard because of the following *observed* interoperability
problem:
In other words,
On Wed, Jul 27, 2011 at 07:02:07PM -0700, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Reducing the Standards Track to Two Maturity Levels'
draft-housley-two-maturity-levels-08.txt as a BCP
I have reviewed this version
To add one observation to SM's comment and other observations
that the scarcity of implementation reports implies that they
are somehow difficult...
--On Friday, August 05, 2011 02:45 -0700 SM s...@resistor.net
wrote:
I presume that the IESG will only use the following criteria
for
Hi Medel,
At 17:57 07-08-2011, GT RAMIREZ, Medel G. wrote:
1)Is there such thing as a good enough Criteria to handle this
concern?
Glen Zorn asked a question during the last plenary and there was a
discussion [1] about criteria on this mailing list.
To be fair, I'll quote a message from
Hi Hector,
At 18:22 07-08-2011, Hector Santos wrote:
Of course, when implementation reports are written, one has to
watchful for the summarized analytical results that either attempt
to add weight to an desired goal or mask the undesired goal and natural result.
An implementation report is
SM wrote:
This is not an exercise we should have to go through. Engineers must
have complete faith in implementation reports.
Faith-based engineering and reality are mutually exclusive. :-)
Touche!
--
Hector Santos, CTO
http://www.santronics.com
--On Saturday, August 06, 2011 07:15 -0700 Bob Hinden
bob.hin...@gmail.com wrote:
If a document no longer has anyone watching it, there's a
reasonable concern that it no longer has much constituency.
In that case, it's better to treat it as immature rather
than mature.
In order to have
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-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
SM
SM wrote:
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
Dave,
On Fri, Jul 29, 2011 at 9:53 AM, Dave CROCKER d...@dcrocker.net wrote:
On 7/29/2011 11:13 AM, Russ Housley wrote:
(2) At any time after two years from the approval of this document as a
BCP, the IESG may choose to reclassify any Draft Standard document as
Proposed Standard.
I think
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
Hector,
On 2011-08-04 14:35, Hector Santos wrote:
Brian E Carpenter asked:
Can you be more specific? Are you talking about
a) drafts that appear in the WG with very mature text, so complete
the WG progress very quickly?
b) drafts that are direct submissions to the IESG, and go through
Brian E Carpenter wrote:
Are you saying that the existing review process
for direct submission or Independent Submission RFCs fails to detect
work that overlaps with WGs?
At least in one experience, I would not say it was a failure per se
but more realistically, for many possible reasons, it
SM:
From Section 2.1:
no existing published requirements are relaxed.
Are these published requirements BCPs?
Yes.
From Section 2.2:
'This maturity level is a merger of Draft Standard and Standard as
specified in RFC 2026 [1]. The chosen name avoids confusion between
Draft
I appreciate this exchange here. I have a better idea of the draft and
your intention I have a few comments.
What I have noticed of late are fast track RFCs are coming out of no
where, very fast and sometimes are indirectly related to a WG but not
a WG chartered work item, and it may have an
Hector,
On 2011-08-04 09:19, Hector Santos wrote:
I appreciate this exchange here. I have a better idea of the draft and
your intention I have a few comments.
What I have noticed of late are fast track RFCs are coming out of no
where, very fast and sometimes are indirectly related to a WG
Brian E Carpenter asked:
Can you be more specific? Are you talking about
a) drafts that appear in the WG with very mature text, so complete
the WG progress very quickly?
b) drafts that are direct submissions to the IESG, and go through
IETF Last Call and IESG review without coming near the
Hi,
I generally support this proposal, but have some questions on Section 2.3,
Transition to a Standards Track with Two Maturity Levels. I am both an
author of several Draft Standards and have chaired working groups that have
produced them.
Any protocol or service that is currently at
Bob:
I generally support this proposal, but have some questions on Section 2.3,
Transition to a Standards Track with Two Maturity Levels. I am both an
author of several Draft Standards and have chaired working groups that have
produced them.
Any protocol or service that is currently
On 7/29/2011 11:13 AM, Russ Housley wrote:
(2) At any time after two years from the approval of this document as a
BCP, the IESG may choose to reclassify any Draft Standard document as
Proposed Standard.
I think this is unfair to the people who have done considerable work to get
a document
At 07:02 PM 7/27/2011, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Reducing the Standards Track to Two Maturity Levels'
draft-housley-two-maturity-levels-08.txt as a BCP
The IESG plans to make a decision in the next few
On 7/28/11 1:05 AM, Mykyta Yevstifeyev wrote:
Hello,
The new version is obviously shorter, but it omits some points. With
eliminating of DS level, RFC 5657 makes no sense more.
Wrong. The *title* needs to be adjusted, but mutatis mutandis the
general advice is useful.
It should be
28.07.2011 16:52, Peter Saint-Andre wrote:
On 7/28/11 1:05 AM, Mykyta Yevstifeyev wrote:
Hello,
The new version is obviously shorter, but it omits some points. With
eliminating of DS level, RFC 5657 makes no sense more.
Wrong. The *title* needs to be adjusted, but mutatis mutandis the
Hello,
The new version is obviously shorter, but it omits some points. With
eliminating of DS level, RFC 5657 makes no sense more. It should be
obsoleted and moved to Historic by your document, if IESG decides to
eliminate the requirement for interoperability documentation, which I am
The IESG has received a request from an individual submitter to consider
the following document:
- 'Reducing the Standards Track to Two Maturity Levels'
draft-housley-two-maturity-levels-08.txt as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final comments on
38 matches
Mail list logo