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 poin
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 d
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
>>>
I have read version 08 and support this proposal.
- Chris
--On July 27, 2011 17:46:22 -0400 Jari Arkko wrote:
Here's the link:
http://tools.ietf.org/html/draft-housley-two-maturity-levels
___
Ietf mailing list
Ietf@ietf.org
https
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 cha
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 inten
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 know:
> a) Why is it
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
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
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
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 thereb
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 the
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 Tuesday, August 02, 2011 20:23 -0400 "Joel M. Halpern"
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 trimming is recom
Russ,
Thanks for reviving this topic. As the YAM working group has been finding,
trying to elevate even the most well-established and widely-used protocols to
Full standard remains problematic.
As your Acknowledgments section cites, your proposal nicely adds to the
considerable repertoire
At 23:10 19-06-10, Dave CROCKER wrote:
Thanks for reviving this topic. As the YAM working group has been
finding, trying to elevate even the most well-established and
widely-used protocols to Full standard remains problematic.
It is problematic because there isn't any consensus on what an
In
On 20/Jun/10 11:53, SM wrote:
The reader will note that neither implementation nor operational
experience is required. In practice, the IESG does "require
implementation and/or operational experience prior to granting Proposed
Standard status". Implementors do not treat Proposed Standards as
imma
OK, we really do seem determined to relive the early 2000s...
It seems to me that abolishing the third level is possible, now, because
the handling of I-Ds has been enhanced. IMHO, it is an advantage to
require some experience before giving an I-D the rank of Proposed
Standard. Because I-Ds
Yaron:
> In general, I think this is a good idea. It might succeed in reviving
> the notion of formal interoperability reports. A few comments though:
>
> - Sec. 2 mentions that the criteria for Proposed Standard will not
> change. But the preceding section just described that our criteria (or
>
Dave:
The questions that you raise will be discussed for 30 minutes at the
front of the Wednesday plenary at IETF 78. The next step is to find out
what the community thinks about these choices. I fully expect there to
be changes to the draft after that discussion.
As you say, we really want to
Russ
I strongly support this approach.
In particular I think the downward ref relaxation is of great value as
chair of WG with with 30+ RFC's at PS and advancing them in order or
RFC's up the standards track vs. advancing the ones that are important
will hopefully be the happy consequence of a
Dave CROCKER wrote:
>
> Interoperability testing used to be an extremely substantial demonstration
> of industry interest and of meaningful learning. The resulting repair and
> streamlining of specifications was signficant. If that's still happening,
> I've been missing the reports about lessons
On 6/20/10 6:01 AM, Alessandro Vesely wrote:
> On 20/Jun/10 11:53, SM wrote:
>
>> This proposal removes Draft Standard and Internet Standard and replaces
>> it with Interoperable Standard. I won't quibble over the choice of the
>> name yet.
>
> If there are two levels and the first one is "Propose
On 6/20/2010 11:53 AM, SM wrote:
The reader will note that neither implementation nor operational
experience is required. In practice, the IESG does "require
implementation and/or operational experience prior to granting Proposed
Standard status".
Well, they do not /always/ require it.
Tha
On 2010-06-20 10:41, Dave CROCKER wrote:
On 6/20/2010 11:53 AM, SM wrote:
The reader will note that neither implementation nor operational
experience is required. In practice, the IESG does "require
implementation and/or operational experience prior to granting Proposed
Standard status".
We
Dave CROCKER wrote:
> On 6/20/2010 11:53 AM, SM wrote:
>
>> The reader will note that neither implementation nor operational
>> experience is required. In practice, the IESG does "require
>> implementation and/or operational experience prior to granting Proposed
>> Standard status".
That's ne
At 1:12 PM -0400 6/21/10, Scott Lawrence wrote:
>On 2010-06-20 10:41, Dave CROCKER wrote:
>>
>>
>>On 6/20/2010 11:53 AM, SM wrote:
>>>The reader will note that neither implementation nor operational
>>>experience is required. In practice, the IESG does "require
>>>implementation and/or operational
Russ,
I'd also like to think you for revisiting this topic.
I support the recommendation to eliminate the "Standard" maturity level, and
also agree with your recommendation on Maturity Level 2 (similar to Draft
Standard).
We need more thought on what to do with the other levels though
I think its a good idea to readdress this. Part of the issue with the current
system, is that there is both no great benefit to advancing a standard to the
next level for the advocates, and no real downside to not advancing it. In
many cases, having gone through the pain of getting to RFC stat
The only thing that I disagree with in the draft is the term "interoperable
standard". Looking at each change in a bit more detail:
- Two levels of standards rather than three:
I strongly support this. It is pretty clear that in most cases people don't
bother with the effort to move past Pr
At 05:01 20-06-10, Alessandro Vesely wrote:
pay to source routing decreases over time. There is no reason why a
new RFC aimed at reviewing a mature spec would need to reduce its
maturity level, if it accomplishes the current requirements for
third level. I hope this point will be made clearer
I don't think I agree with this.
On Jun 21, 2010, at 6:45 PM, Martin Rex wrote:
>
> I would prefer if the IETF retains the third level and puts an emphasis
> on cutting down on protocol feature bloat when going from draft to
> full standard.
You want to be very careful cutting down on feature bl
I like this proposal, but there should be a (relatively) easy process to
advance from Experimental to Proposed, especially if implementation experience
shows no need for bits-on-the-wire changes.
We should be able to say that for a particular experimental RFC there have been
this many independe
heckpoint.com]
Sent: Tuesday, June 22, 2010 1:00 AM
To: Bernard Aboba
Cc: ietf@ietf.org
Subject: Re: draft-housley-two-maturity-levels-00
I like this proposal, but there should be a (relatively) easy process to
advance from Experimental to Proposed, especially if implementation
experience sh
In reply to a number of different threads:
* This proposal, however flawed some might think it is is certainly a much
better description of current practice than the process document.
It is a fact that almost every 'IETF Standard' of any consequence was
developed before the first meeting of the I
On 6/21/2010 5:45 PM, Martin Rex wrote:
I would prefer if the IETF retains the third level and puts an emphasis
on cutting down on protocol feature bloat when going from draft to
full standard.
OK. All you need is to develop an IETF rough consensus in support of that
change.
d/
--
Dave
On 6/21/2010 5:57 PM, Peter Saint-Andre wrote:
Here's an idea:
1. The first level is simply "Request for Comments".
Once an RFC is published, we start to gather comments.
Peter,
How is that different from an Internet Draft?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
I disagree.
For changes such as DNSSEC there is no way to move as many parts of the
industry as need to be involved with an Internet draft. Microsoft is not
going to implement a draft in Windows Server, neither is Apple.
Operational experience in this case means at a minimum taking two conformant
On 6/21/10 1:12 PM, "Scott Lawrence" wrote:
> On 2010-06-20 10:41, Dave CROCKER wrote:
>>
>>
>> On 6/20/2010 11:53 AM, SM wrote:
>>> The reader will note that neither implementation nor operational
>>> experience is required. In practice, the IESG does "require
>>> implementation and/or operati
Another thing to consider here is the point at which code points are
assigned.
In a lot of cases we have had incompatibility resulting from experimental
code points being used and then changed when the final draft is agreed.
For some spaces code points are scarce and it is necessary to conserve.
Feature 'bloat' in PKIX is largely due to the fact that the features have
already been accepted in the ITU version of the spec that is being profiled.
But the other reason is that the original PKIX core did not cover the full
set of requirements and that these were added as additional protocols
in
All,
I support this change, as written in Russ's draft.
This is not a surprise, as I've proposed this kind
of change myself in the past (as have several other
folks).
I see various people quibbling about aspects of this
proposal, but I haven't seen any serious defence of
the obviously broken (i.e
Earlier, Mike StJohns wrote:
> One side note - MIBs.
>
> MIBs by their nature are actually collections of mini-standards
> - the objects. Once an object is defined and published in a
> non-transitional document (RFC), the OID associated with that
> object is pretty much stuck with that defin
RJ Atkinson wrote:
>
> Rather than quibble about the details of this, I'd
> urge folks to support the move to 2-track.
>
> If it becomes clear later, after experience with 2-track,
> that 2-track needs to be further refined later, then
> the community can always do that. In the meantime, it
>
I agree with these comments, and I'll tackle them in -01 of the draft.
Russ
On 6/20/2010 5:53 AM, SM wrote:
> In Section 6:
>
> 'The current rule prohibiting "down references" is a major cause
>of stagnation in the advancement of documents.'
>
> There isn't any current rule that prohibits
We often replace a Proposed Standard with an updated document that
remains at the Proposed Standard maturity level. There does not seem to
be confusion when this happens.
Russ
On 6/20/2010 8:01 AM, Alessandro Vesely wrote:
>> "In several situations, a Standard is obsoleted by a Proposed Standard
Dave & Scott:
>> On 6/20/2010 11:53 AM, SM wrote:
>>> The reader will note that neither implementation nor operational
>>> experience is required. In practice, the IESG does "require
>>> implementation and/or operational experience prior to granting Proposed
>>> Standard status".
>>
>>
>> Well, th
>I'm willing to be corrected: does anyone want to document a single
> case where this was required _by_the_IESG_ in the last two years?
I only know of one case where it was even discussed. The IESG felt that
it was necessary to tell the WG that such a requirement was needed in
their charter.
Bernard:
> In practice, we often see a document initial go to Proposed Standard,
> then go through a “bis” to enable clarifications and interop improvements.
>
> Often these changes are too substantial to enable advancement to Draft,
> but they nevertheless represent an important advancement in s
John,
That's news to me: I can't recall any recent discusses calling for
operational experience before publishing as Proposed Standard.
Some years ago, there was such a requirement for Routing Area, but
that was declared obsolete. (In actuality, there seems to still be a
somewhat informal requi
Yoav,
I like this proposal, but there should be a (relatively) easy process
to advance from Experimental to Proposed, especially if implementation
experience shows no need for bits-on-the-wire changes.
We should be able to say that for a particular experimental RFC there
have been this many i
Hi, Jari,
We should be able to say that for a particular experimental RFC there
have been this many independent implementation, and they interoperate OK,
and only so-and-so clarifications need to be added, and the document is
ready for "Proposed".
I think we already have that. There is reall
Spencer,
As I read http://www.rfc-editor.org/rfc/rfc5741.txt, Experimental RFCs
would be Category: Experimental on the first page, and I'd expect them
to be revised when they are reclassified, if only to make this say
Category: Standards Track. So that's at least a small barrier to
reclassifi
I'm with Ran and others who stated that best is the enemy of good in
this case. I think Russ' draft is a step in the right direction and will
reduce complexity and effort. An incremental improvement. We should
adopt it in Maastricht. And lets avoid too much fine-tuning or
fragmentation of the p
Dave:
This observation was based on many hallway discussions with many people
over many years. You are correct to observe that there are many factors
at play, and many of them were discussed at the mic in plenary. The
draft changes process in many different places. I've attempted to
balance man
Russ,
In reading the latest version of your proposal, I finally realized that a
motivating premise:
o Since many documents are published as Proposed Standard and never
advances to a higher maturity level, the initial publication
receives much more scrutiny that is call for by
I strongly disagree with this characterization. In my view, too many
things got bundled together, and the thing that was unacceptable too the
whole bundle down.
Russ
On 6/24/2010 2:52 PM, Phillip Hallam-Baker wrote:
> Last time the reforms were blocked without the IETF at large even
> knowing wh
Phillip:
Obviously, I was not General AD when this happened. However, I was
Security AD at the time, so I was involved in the discussions that
included the whole IESG.
I made my reply to your posting because I want people to realize that
there is another side to the story. We need to learn from
Scott Lawrence wrote:
The main drawback of this would be
> that a document would sometimes need to exist for longer as an I-D while
> implementations are developed, but balancing that is the fact that those
> implementations would then inform the first RFC version rather than some
> subsequ
I've mentioned this to Russ privately, but it's worth saying it out loud ...
Phillip:
Obviously, I was not General AD when this happened. However, I was
Security AD at the time, so I was involved in the discussions that
included the whole IESG.
I made my reply to your posting because I want
> The ISD proposal
> required the IESG spend a lot of time that the individuals simply did
> not have.
so the IESG insisted - that was not the opinion of the newtrk chair
(who thought that ISDs would likely reduce the load on ADs
> Further, this came at a very, very bad time
and that, apparently
It seems to me that we hit a vicious circle in which the lack of standards
progressing beyond proposed has meant that proposed standard has been
considered sufficiently advanced for adoption leading to more people
worrying about rough edges in proposed standards and demanding more complete
document
My point is that I am unable to have any characterization whatsoever since
nobody has ever told me the reason that the changes did not go ahead.
And since I have asked for reasons in a plenary and never got any statement
that was not phrased in the passive voice, I don't think it is unfair to
desc
Yes, I agree that the IETF has become a lot more open than the
self-perpetuating cabal that ran it during the mid 90s.
We no have de-facto term limits for ADs and it is no longer considered
acceptable for an AD to chair a working group (excepting process related
groups chaired by the IETF chair).
On 2010-06-26 02:49, Russ Housley wrote:
> Phillip:
>
> Obviously, I was not General AD when this happened. However, I was
> Security AD at the time, so I was involved in the discussions that
> included the whole IESG.
>
> I made my reply to your posting because I want people to realize that
> t
One approach that may help avoid that blockage is to use a Quaker poll.
[Yes, Yes, consensus, blah, blah]
At the moment the mode of discourse is that everyone proposes their
preferred solution. So the clear consensus that the three step process is
not being applied is lost because everyone is en
Scott Lawrence wrote:
> I think that a different numbering series needs to be created so that
> 'RFC' means what most people (incorrectly) think that it means now:
that
> something is a standard that has passed the IETF review and approval
> process.
I think this is far too late. Come what may,
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
>> propo
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
>
> "Russ" == Russ Housley 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
requires documenta
Sam and Julian:
>> "Russ" == Russ Housley 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 seem
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 o
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 IES
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
>>
2011/4/7, Russ Housley :
> 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 wrote:
>
>
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 IES
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,
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 procedur
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 s
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? Wheth
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
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, specifi
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 unmenti
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 use
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" wrote:
>
>
> On 5/6/2011 1:31 AM, Dave Cridland wrote:
>> On Thu May 5 18:31:33 2011, Dave CROCKER wrote:
1
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 wro
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 the
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 documenta
--On Friday, May 06, 2011 18:15 +0200 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.
Martin,
That is an interesting observatio
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 th
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
> 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 cal
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
th
101 - 200 of 257 matches
Mail list logo
