--On Tuesday, August 02, 2011 20:23 -0400 Joel M. Halpern
j...@joelhalpern.com wrote:
With mild apologies, I have retained John's text below
because, even though I come to a different conclusion, I
thought it important to retain for now. If folks choose to
follow up on this, significant
On 7/30/11 11:05 AM, Joel M. Halpern wrote:
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
With mild apologies, I have retained John's text below because, even
though I come to a different conclusion, I thought it important to
retain for now. If folks choose to follow up on this, significant
trimming is recommended.
John, as far as I can tell there are three problems which various
On 7/30/11 11:05 AM, Joel M. Halpern wrote:
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
On 31st July 2011, Brian Carpenter wrote, in part:
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
On Jul 31, 2011, at 11:55 AM, RJ Atkinson wrote:
On 31st July 2011, Brian Carpenter wrote, in part:
[snip]
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
it looks so - maybe it would be good to have a pointer in this doc
Scott
On Jul 28, 2011, at 9:19 AM, Robert Sparks wrote:
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
On 7/28/11 9:03 AM, Eric Burger wrote:
On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote:
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
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
Pete Resnick presn...@qualcomm.com wrote:
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)
Hi Pete,
On 2011-07-31 04:55, Pete Resnick wrote:
...
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
I have read version 08 and support this proposal.
- Chris
--On July 27, 2011 17:46:22 -0400 Jari Arkko jari.ar...@piuha.net wrote:
Here's the link:
http://tools.ietf.org/html/draft-housley-two-maturity-levels
___
Ietf mailing
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
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
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.
On Jul 28, 2011, at 9:19 AM, Robert Sparks wrote:
Scott -
Didn't RFC 5657 address your point
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
On Jul 28, 2011, at 10:06 AM, Peter Saint-Andre wrote:
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.
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.
Keith,
On 2011-07-29 02:20, Keith Moore wrote:
On Jul 28, 2011, at 10:06 AM, Peter Saint-Andre wrote:
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
On 2011-07-28 09:46, Jari Arkko wrote:
After extensive discussion on this list and in the IESG Russ has decided
to make a reduced proposal. I am now initiating a new Last Call to gauge
consensus on the new version.
Thankyou. I fully support this version.
Brian Carpenter
On Thu May 5 18:31:33 2011, Dave CROCKER wrote:
On 5/5/2011 10:22 AM, Dave Cridland wrote:
On balance, whilst I appreciate the aims of this document, I think
the proposals
are not suitable for adoption.
1) This document radically lowers the quality of Proposed
Standards.
What,
On 5/6/2011 1:31 AM, Dave Cridland wrote:
On Thu May 5 18:31:33 2011, Dave CROCKER wrote:
1) This document radically lowers the quality of Proposed Standards.
What, specifically, are the parts of the proposal that you believe will lower
the quality of a Proposed Standard?
The parts
On Fri, May 06, 2011 at 08:08:54AM -0700, Dave CROCKER wrote:
The parts unmentioned in the document, in effect.
^^^
You appear to be saying that the new document lowers quality by
continuing to use the same basic criteria and qualifiers for
Proposed that we've used for
Dave: the issue is that PS was previously not seen as a finished product,
now it has much more exalted status, but the criteria have not changed.
On May 6, 2011 11:09 AM, Dave CROCKER d...@dcrocker.net wrote:
On 5/6/2011 1:31 AM, Dave Cridland wrote:
On Thu May 5 18:31:33 2011, Dave CROCKER
I am strongly opposed to this 2 document maturity level proposal.
The real problem tha the IETF is regularly facing are constituencies that
will fight hard against specifications getting updated, improved or fixed,
once they have been published as RFC.
Dave Cridland wrote:
Dave CROCKER
On 5/6/2011 9:15 AM, Martin Rex wrote:
The real problem tha the IETF is regularly facing are constituencies that
will fight hard against specifications getting updated, improved or fixed,
once they have been published as RFC.
That seems particularly true about possible changes to RFC 2026.
On 5/6/2011 9:01 AM, Andrew Sullivan wrote:
I think he is saying that there is are _de facto_ criteria that are
neither called out in 2026 nor in this draft, and that those criteria
are the running code, so the documentation ought to be made to match.
Oh. But then that doesn't mean that
On Fri, May 06, 2011 at 09:27:16AM -0700, Dave CROCKER wrote:
On 5/6/2011 9:01 AM, Andrew Sullivan wrote:
I think he is saying that there is are _de facto_ criteria that are
neither called out in 2026 nor in this draft, and that those criteria
are the running code, so the documentation
--On Friday, May 06, 2011 18:15 +0200 Martin Rex m...@sap.com
wrote:
The real problem tha the IETF is regularly facing are
constituencies that will fight hard against specifications
getting updated, improved or fixed, once they have been
published as RFC.
Martin,
That is an interesting
On Fri May 6 17:50:07 2011, Andrew Sullivan wrote:
On Fri, May 06, 2011 at 09:27:16AM -0700, Dave CROCKER wrote:
On 5/6/2011 9:01 AM, Andrew Sullivan wrote:
I think he is saying that there is are _de facto_ criteria that
are
neither called out in 2026 nor in this draft, and that those
Martin,
I think you may actually be arguing for a 1 step process.
Eliot
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
I think he is saying that there is are _de facto_ criteria that are
neither called out in 2026 nor in this draft, and that those criteria
are the running code, so the documentation ought to be made to match.
This suggests that perhaps we should rename Proposed Standard to
Not a Standard But Might
This suggests that perhaps we should rename Proposed Standard to
Not a Standard But Might Be One Later, promote the PS published
under the overstrict rules to DS, and we're done.
I'm not sure whether I'm serious or not.
Whether you are or not.., the only way to do this is to stop calling
This suggests that perhaps we should rename Proposed Standard to
Not a Standard But Might Be One Later, promote the PS published
under the overstrict rules to DS, and we're done.
I'm not sure whether I'm serious or not.
Whether you are or not.., the only way to do this is to stop calling
them
On Fri May 6 22:12:35 2011, Barry Leiba wrote:
This suggests that perhaps we should rename Proposed Standard to
Not a Standard But Might Be One Later, promote the PS published
under the overstrict rules to DS, and we're done.
I'm not sure whether I'm serious or not.
Whether you are or
John said...
Well, you know, the Not a Standard But Might Be One Later really are
requesting comments.
Yes, well, we all know that RFC has lost any real sense of its
expansion long ago. It certainly has done so in the eyes of most of
the world, for whom RFC means Internet standard.
Dave
On 5/6/2011 2:29 PM, John R. Levine wrote:
Whether you are or not.., the only way to do this is to stop calling
them RFCs. Maybe we should have a PROP series for PS docs, and
only give them RFC numbers later, when they progress.
Well, you know, the Not a Standard But Might Be One Later
On Fri May 6 22:37:20 2011, Barry Leiba wrote:
John said...
Well, you know, the Not a Standard But Might Be One Later
really are
requesting comments.
Yes, well, we all know that RFC has lost any real sense of its
expansion long ago. It certainly has done so in the eyes of most of
the
Barry Leiba wrote:
John said...
Well, you know, the Not a Standard But Might Be One Later really are
requesting comments.
Yes, well, we all know that RFC has lost any real sense of its
expansion long ago. It certainly has done so in the eyes of most of
the world, for whom RFC means
07.05.2011 0:29, John R. Levine wrote:
This suggests that perhaps we should rename Proposed Standard to
Not a Standard But Might Be One Later, promote the PS published
under the overstrict rules to DS, and we're done.
I'm not sure whether I'm serious or not.
Whether you are or not.., the only
On 5/5/2011 10:22 AM, Dave Cridland wrote:
On balance, whilst I appreciate the aims of this document, I think the proposals
are not suitable for adoption.
1) This document radically lowers the quality of Proposed Standards.
What, specifically, are the parts of the proposal that you believe
19.04.2011 1:21, Russ Housley wrote:
Mykyta:
4. Downward References Permitted
This section says nothing about references to documents with no status
(pre-IETF RFCs). Maybe informative references to such RFCs should be
allowed. And what about normative ones? Whether the RFC 3967 procedure
Mykyta:
4. Downward References Permitted
This section says nothing about references to documents with no status
(pre-IETF RFCs). Maybe informative references to such RFCs should be
allowed. And what about normative ones? Whether the RFC 3967 procedure
will be used in such cases, or
On 4/19/11 9:57 AM, Russ Housley wrote:
Mykyta:
4. Downward References Permitted
This section says nothing about references to documents with no status
(pre-IETF RFCs). Maybe informative references to such RFCs should be
allowed. And what about normative ones? Whether the RFC 3967
06.04.2011 18:27, Russ Housley wrote:
This revision proposes a solution to the issue raised by Brian Carpenter about
documents lingering at Draft Standard. Some people thought it was a problem.
Others thought it did not matter. The proposed solution leaves the matter in
the hands of the
2011/4/7, Russ Housley hous...@vigilsec.com:
Mykyta:
If this approach is acceptable to the community, implementation reports will
no longer be needed at all.
In this case your document should obsolete RFC 5657 and mention this.
Mykyta
Russ
On Apr 7, 2011, at 10:09 AM, Mykyta Yevstifeyev
06.04.2011 18:27, Russ Housley wrote:
This revision proposes a solution to the issue raised by Brian Carpenter about
documents lingering at Draft Standard. Some people thought it was a problem.
Others thought it did not matter. The proposed solution leaves the matter in
the hands of the
Mykyta:
If this approach is acceptable to the community, implementation reports will no
longer be needed at all.
Russ
On Apr 7, 2011, at 10:09 AM, Mykyta Yevstifeyev wrote:
06.04.2011 18:27, Russ Housley wrote:
This revision proposes a solution to the issue raised by Brian Carpenter
The last *several* revisions have been perfectly fine.
The most recent edits are also fine.
We're micro-editing this document at this point, meaning that
perfect is impeding our ability to deploy more than good enough
to replace 3-tier system that most IETF folks agree is broken,
and has
On 06.04.2011 17:27, Russ Housley wrote:
This revision proposes a solution to the issue raised by Brian Carpenter about
documents lingering at Draft Standard. Some people thought it was a problem.
Others thought it did not matter. The proposed solution leaves the matter in
the hands of the
On 4/6/11 10:45 AM, Julian Reschke wrote:
On 06.04.2011 17:27, Russ Housley wrote:
This revision proposes a solution to the issue raised by Brian
Carpenter about documents lingering at Draft Standard. Some people
thought it was a problem. Others thought it did not matter. The
proposed
Julian:
A question...:
A specification shall remain at the Proposed Standard maturity level
for at least six (6) months before consideration for advancement to
the Internet Standard maturity level.
It would probably good to clarify when the six month period starts (IESG
approval?
Russ == Russ Housley hous...@vigilsec.com writes:
Russ The 6 months starts with RFC publication.
Please say that in the draft then.
I had a different take away from the last version of this discussion I
participated in.
I don't care much what the answer is, but it seems clear that it
Sam and Julian:
Russ == Russ Housley hous...@vigilsec.com writes:
Russ The 6 months starts with RFC publication.
Please say that in the draft then.
I had a different take away from the last version of this discussion I
participated in.
I don't care much what the answer is, but it
On 2011-04-07 03:27, Russ Housley wrote:
This revision proposes a solution to the issue raised by Brian Carpenter
about documents lingering at Draft Standard. Some people thought it was a
problem. Others thought it did not matter. The proposed solution leaves the
matter in the hands of
Russ, all,
Another proposal as for your document. So, it fails to mention what are
the procedures for reclassification of Standards Track RFCs to
Historic. Therefore, I propose the following text:
6. Procedures for Reclassification of Standards Track RFCs as
Historic Documents
Under
As far as I can tell, your proposal does not match the meaning we use
for Historic.
More importantly, there does not seem to be a problem that needs to be
addressed in this area.
Most importantly, if there is a problem, it should in my opinion be
addressed separately from the topic of this
24.03.2011 17:42, Joel M. Halpern wrote:
As far as I can tell, your proposal does not match the meaning we use
for Historic.
More importantly, there does not seem to be a problem that needs to be
addressed in this area.
Most importantly, if there is a problem, it should in my opinion be
On 3/24/2011 4:49 PM, Mykyta Yevstifeyev wrote:
Another proposal as for your document. So, it fails to mention what are
the procedures for reclassification of Standards Track RFCs to Historic.
Generally, the document tries to limit itself to discussion of what it changes.
There are no
On Mar 24, 2011, at 5:01 PM, Dave CROCKER wrote:
On 3/24/2011 4:49 PM, Mykyta Yevstifeyev wrote:
Another proposal as for your document. So, it fails to mention what are
the procedures for reclassification of Standards Track RFCs to Historic.
Generally, the document tries to limit
Agreed.
On Mar 24, 2011, at 12:13 PM, Bob Hinden wrote:
On Mar 24, 2011, at 5:01 PM, Dave CROCKER wrote:
On 3/24/2011 4:49 PM, Mykyta Yevstifeyev wrote:
Another proposal as for your document. So, it fails to mention what are
the procedures for reclassification of Standards Track RFCs
There seems to be a minor but important inconsistency which leaves us
still not clearly addressing the interoperability issues.
The commentary text on the second standards level includes, when
commenting on the removal of the requirement for interoperability
testing reports:
subsumed by
There have been conflicting suggestions about the best way forward. We have
constructed an updated proposal. It has been posted as
draft-housley-two-maturity-levels-04.
Russ
___
Ietf mailing list
Ietf@ietf.org
On 1/30/2011 8:06 AM, Andrew Sullivan wrote:
On Sun, Jan 30, 2011 at 07:49:44AM -0800, Dave CROCKER wrote:
The current proposal specifies a second maturity level that does not
permit changing the technical specification.
Yes, I know. I fail completely to see why anyone would ever do the
I believe this proposal to be dangerous and undesirable.
The fact is that the three stage process has never worked. As in not ever.
If you take a look at the current Internet standards over half of the total
are grandfathered from before the IETF was started.
You cannot return to a state that
On Sun, Jan 30, 2011 at 09:27:17AM -0500, Phillip Hallam-Baker wrote:
The raising of the bar for proposed standard has a very simple reason: it is
now almost impossible to change specifications once deployed.
That's an argument for _no_ maturity levels, then, not for two.
A
--
Andrew
On Jan 30, 2011, at 9:58 AM, Andrew Sullivan wrote:
On Sun, Jan 30, 2011 at 09:27:17AM -0500, Phillip Hallam-Baker wrote:
The raising of the bar for proposed standard has a very simple reason: it is
now almost impossible to change specifications once deployed.
That's an argument for _no_
On Sun, Jan 30, 2011 at 10:15:01AM -0500, Keith Moore wrote:
That's an argument for _no_ maturity levels, then, not for two.
Is there an implicit assumption here that more standards (presumably of
poorer quality) is a good thing?
Not on my part. I'm merely observing that, if the
On Jan 30, 2011, at 10:35 AM, Andrew Sullivan wrote:
On Sun, Jan 30, 2011 at 10:15:01AM -0500, Keith Moore wrote:
That's an argument for _no_ maturity levels, then, not for two.
Is there an implicit assumption here that more standards (presumably of
poorer quality) is a good thing?
On 1/30/2011 7:35 AM, Andrew Sullivan wrote:
Is there an implicit assumption here that more standards (presumably of
poorer quality) is a good thing?
Not on my part. I'm merely observing that, if the claim is that you can't
alter deployed protocols, then there's no reason to say that we
On Sun, Jan 30, 2011 at 07:49:44AM -0800, Dave CROCKER wrote:
Not on my part. I'm merely observing that, if the claim is that you can't
alter deployed protocols, then there's no reason to say that we need two
maturity levels, because in fact nothing will advance past the first stage
anyway.
On Sun, Jan 30, 2011 at 9:58 AM, Andrew Sullivan a...@shinkuro.com wrote:
On Sun, Jan 30, 2011 at 09:27:17AM -0500, Phillip Hallam-Baker wrote:
The raising of the bar for proposed standard has a very simple reason: it
is
now almost impossible to change specifications once deployed.
On 2011-01-27 16:29, Scott O. Bradner wrote:
1/ I still do not think this (modified) proposal will have any real
impact on the number of Proposed Standard documents that move
to a (in this proposal, the) higher level since I do not see
how this makes any significant changes to the
On 1/29/2011 12:10 PM, Brian E Carpenter wrote:
On 2011-01-27 16:29, Scott O. Bradner wrote:
4/ as part of #3 - the rules should also specifically deal with
the following pp from 2026
The requirement for at least two independent and interoperable
implementations applies to
On 2011-01-30 09:52, Dave CROCKER wrote:
On 1/29/2011 12:10 PM, Brian E Carpenter wrote:
On 2011-01-27 16:29, Scott O. Bradner wrote:
4/ as part of #3 - the rules should also specifically deal with
the following pp from 2026
The requirement for at least two independent and
I've previously expressed my opinion that proposals to muck with the
number of steps in teh IETF standards process will no do anything
useful (i.e., will not be effective) - JOhn and I have just posted
what, to us, would be a prerequisite for amy process mucking proposal
to succeed
Scott
-
Hi Scott and John,
I don't see this as inconsistent with the current 2-stage proposal,
if the latter's omission of a requirement for independent interoperable
implementations for stage 2 is corrected.
I don't, however, believe that the problems are separable.
The bar for PS has crept up, IMHO,
--On Sunday, January 30, 2011 1:01 PM +1300 Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
Hi Scott and John,
I don't see this as inconsistent with the current 2-stage
proposal, if the latter's omission of a requirement for
independent interoperable implementations for stage 2 is
Mark Atwood m...@pobox.com wrote:
This post would be much less confusing if you would name names, cite
examples, and point fingers.
No, it wouldn't.
We don't need a flame-war over which features of which protocols
would have to go away under a strict reading of RFC 2026 in order to
--On Thursday, January 27, 2011 09:41 +0200 Gonzalo Camarillo
gonzalo.camari...@ericsson.com wrote:
Hi,
yes, I also agree the first one is the most important point
and has not been addressed so far. If we want a system that
works (and is used), it needs to include incentives to move
from
On 1/26/2011 7:29 PM, Scott O. Bradner wrote:
2/ I think the proposal must specifically deal with the 2026 IPR licence
requirement in section 4.1.2
If patented or otherwise controlled technology
is required for implementation, the separate implementations must
also
On 01/27/2011 01:10, John C Klensin wrote:
--On Thursday, January 27, 2011 09:41 +0200 Gonzalo Camarillo
gonzalo.camari...@ericsson.com wrote:
Hi,
yes, I also agree the first one is the most important point
and has not been addressed so far. If we want a system that
works (and is used), it
At 19:29 26-01-11, Scott O. Bradner wrote:
1/ I still do not think this (modified) proposal will have any real
impact on the number of Proposed Standard documents that move
to a (in this proposal, the) higher level since I do not see
how this makes any significant changes to the
Scott O. Bradner wrote:
1/ I still do not think this (modified) proposal will have any real
impact on the number of Proposed Standard documents that move
to a (in this proposal, the) higher level since I do not see
how this makes any significant changes to the underlying reasons
This post would be much less confusing if you would name names, cite
examples, and point fingers.
The reason why so many documents are at proposed is that they're
often collections of bloat (limited-use features with an aggresive
requirements level) from various interest groups that is
not
+1 to the proposed rules for reclassifying DS to IS. I think they offer a
reasonable balance between expediency and quality.
Ned
On 1/24/2011 12:37 PM, Russ Housley wrote:
draft-housley-two-maturity-levels-03 was just posted. ...
Overall I find this spec to
1/ I still do not think this (modified) proposal will have any real
impact on the number of Proposed Standard documents that move
to a (in this proposal, the) higher level since I do not see
how this makes any significant changes to the underlying reasons
that documents have not
+1 on all points, especially the first one.
john
--On Wednesday, January 26, 2011 22:29 -0500 Scott O. Bradner
s...@harvard.edu wrote:
1/ I still do not think this (modified) proposal will have any
realimpact on the number of Proposed Standard documents
that moveto a (in this
Hi,
yes, I also agree the first one is the most important point and has not
been addressed so far. If we want a system that works (and is used), it
needs to include incentives to move from one level to the next one. I
have discussed this issue with quite a few people. Some people claim
that those
draft-housley-two-maturity-levels-03 was just posted. It reflects much of the
discussion on this thread over the last few months. In particular, it embraces
the changes put forward in the recent proposal by Dave Crocker, Eric Burger,
Peter Saint-Andre, and Spencer Dawkins. Please take a look
On 1/24/11 10:37 AM, Russ Housley wrote:
draft-housley-two-maturity-levels-03 was just posted. It reflects
much of the discussion on this thread over the last few months. In
particular, it embraces the changes put forward in the recent
proposal by Dave Crocker, Eric Burger, Peter
It seems to me that this proposal strikes a good balance in making an
effort to improve the situation regarding our document track.
Regarding the particular clause:
On 1/24/2011 1:30 PM, Peter Saint-Andre wrote:
...
2. I found this statement to be strange:
The intention of the two-tier
On 1/24/11 11:39 AM, Joel M. Halpern wrote:
It seems to me that this proposal strikes a good balance in making an
effort to improve the situation regarding our document track.
Regarding the particular clause:
On 1/24/2011 1:30 PM, Peter Saint-Andre wrote:
...
2. I found this statement to
On Mon, Jan 24, 2011 at 1:39 PM, Joel M. Halpern j...@joelhalpern.comwrote:
It seems to me that this proposal strikes a good balance in making an
effort to improve the situation regarding our document track.
Regarding the particular clause:
On 1/24/2011 1:30 PM, Peter Saint-Andre wrote:
Earlier, Joel Halpern wrote:
It seems to me that this proposal strikes a good balance in making an effort
to improve the situation regarding our document track.
Regarding the particular clause:
On 1/24/2011 1:30 PM, Peter Saint-Andre wrote:
...
2. I found this statement to be strange:
On 1/24/2011 12:37 PM, Russ Housley wrote:
draft-housley-two-maturity-levels-03 was just posted. ...
Overall I find this spec to be an improvement over the previous version.
Here are a few areas where improvements can be made.
This phrase in Section 1:
In addition,
IETF
25.01.2011 6:13, Tony Hansen wrote:
On 1/24/2011 12:37 PM, Russ Housley wrote:
draft-housley-two-maturity-levels-03 was just posted. ...
Overall I find this spec to be an improvement over the previous
version. Here are a few areas where improvements can be made.
[. . . . .]
One
At 13:39 29-10-10, Andrew Sullivan wrote:
Supppse we actually have the following problems:
1. People think that it's too hard to get to PS. (Never mind the
competing anecdotes. Let's just suppose this is true.)
2. People think that PS actually ought to mean Proposed and not
A few quick observations...
--On Friday, October 29, 2010 13:20 -0700 SM s...@resistor.net
wrote:
...
While my instinct is that RFC publication would be desirable,
if that didn't seem workable we could move the idea a bit
closer to the Snapshot idea by posting the document in the
I-D series
On Oct 29, 2010, at 10:39 PM, Andrew Sullivan wrote:
If all of those things are right and we're actually trying to solve
them all, then it seems to me that the answer is indeed to move to _n_
maturity levels of RFC, where _n_ 3 (I propose 1), but that we
introduce some new document series
1 - 100 of 244 matches
Mail list logo
