The reason I chose RFC2821 is that there is really no basis on which the
earlier document is better.
RFC821 was accepted when the process was far less stringent. The working
group that produced 2821 was chartered to improve the documentation of SMTP
rather than redesign the protocol.
What people
The fact remains that RFC 821 has the STANDARD imprimatur and the better
specification that was intended to replace it does not.
It seems pretty basic to me that when you declare a document Obsolete it
should lose its STANDARD status. But under the current system that does not
happen.
This
Phillip Hallam-Baker wrote:
The fact remains that RFC 821 has the STANDARD imprimatur and the better
specification that was intended to replace it does not.
It seems pretty basic to me that when you declare a document Obsolete it
should lose its STANDARD status. But under the current
Phillip Hallam-Baker wrote:
The fact remains that RFC 821 has the STANDARD imprimatur and the better
specification that was intended to replace it does not.
It seems pretty basic to me that when you declare a document Obsolete it
should lose its STANDARD status. But under the current
On 6/28/10 12:35 PM, Martin Rex wrote:
To me it looks like Obsolete: has been used with quite different
meanings across RFCs, and some current uses might be inappropriate.
Although it's been more than two decades that I read rfc821 (and
none of the successors), I assume that all those RFC
On Jun 26, 2010, at 12:56 AM, Phillip Hallam-Baker wrote:
The fact remains that RFC 821 has the STANDARD imprimatur and the better
specification that was intended to replace it does not.
Yes, but most of the RFC repositories, including
http://tools.ietf.org/html/rfc821 show Obsoleted by:
Hi Yoav,
At 00:36 27-06-10, Yoav Nir wrote:
Yes, but most of the RFC repositories, including
http://tools.ietf.org/html/rfc821 show Obsoleted by: 2821 right
there at the top next to the word STANDARD. Anyone looking
Yes.
at this RFC now (as opposed to 10 years ago) would immediately know
It seems to me that this discussion is conflating two related but distinct
things: protocols and specifications.
The IETF is concerned with producing and refining *protocols*; however the
work products are specifications(RFCs).
A *protocol* such as SMTP is very mature and thus can be used by
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
subsequent
I can't remember offhand if DNS got to full standard or not, lets say for
the sake of argument that it did.
If we want to make a significant change to DNS, such as yank out some
features that were never used, we have a minimum of about six years before
the change can be made.
First we would have
On Thursday, June 24, 2010 22:01 Phillip Hallam-Baker wrote:
snip/
We currently have the idiotic position where RFC821 is a full standard and
RFC2821 which obsoletes it is not.
Why is this idiotic. RFC 821 needed to be obsoleted. It had some features that
needed to be removed, and some
Hi Ran, and thanks for your reply.
There are two separate issues that we need to distill. First, what to
do about draft-housley-two-maturity-levels-00, and second, how do take
input to improve the overall process?
I have not really come down on one side or the other on this draft
(yet
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
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
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
On 23 Jun 2010, at 08:45 , Eliot Lear wrote:
And now as to your specifics, you have placed a lot of weight on one
example, seemingly extrapolating from it, the Joint Interoperability
Test Command. I have no experience working with them, and defer to
yours. However, when you say,
Again,
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
Russ,
Thank you for bringing this topic full circle. Having considered this
topic for a long time, and having lead a cleanup around old standards in
newtrk, I share the following thoughts for your consideration.
In concurring in part with what Bernard and Mike wrote, the basic
question I ask,
On Tue, Jun 22, 2010 at 10:12:13AM +0200, Eliot Lear wrote:
Question #1: Is such a signal needed today? If we look at the 1694
Proposed Standards, are we seeing a lack of implementation due to lack
of stability? I would claim that there are quite a number of examples
to the contrary (but
@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 shows no need for bits-on-the-wire changes.
We should be able to say
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
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/
--
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
On 6/21/10 1:12 PM, Scott Lawrence xmlsc...@gmail.com 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
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
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
On 22nd June 2010, at 10:12:13 CET, Eliot Lear wrote:
This then leads to a question of motivations. What are the motivations
for the IESG, the IETF, and for individual implementers? Traditionally
for the IETF and IESG, the motivation was meant to be a signal to the
market that a standard
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
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
is
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 down
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, they do not /always/
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
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
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 Proposed
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.
That
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.
Dave CROCKER d...@dcrocker.net 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.
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 experience prior
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
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
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
an
Internet Standard is and the requirements to attain that level of maturity.
In Section 2 of draft-housley-two-maturity-levels-00:
The requirements for Proposed Standard are unchanged; they remain
exactly as specified in RFC 2026.
Quoting Section 4.1.1 of RFC 2026:
A Proposed Standard
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
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
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
processes) for
52 matches
Mail list logo
