I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors. Document editors and WG chairs should treat these comments just
like
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 1/29/11 9:34 PM, Joe Touch wrote:
On 1/29/2011 8:54 PM, Cullen Jennings wrote:
On Jan 27, 2011, at 17:10 , Joe Touch wrote:
...
AFAICT, the experts team reports to IANA. We make recommendations to
them. They are the ones who have the conversation with the applicant.
They can take our
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.
Paul (et al.),
See below.
Note that IANA can't just make its own decisions either and ignore IETF
process *AND* expert review.
I wasn't trying to imply that, but it appears to have been inferred from
my claim that neither document binds IANA to the advice of a reviewer.
IANA is bound by
Mykyta Yevstifeyev wrote:
I'd like to see some kind of guideline that the RFC should not be considered
obsolete solely because of security or performance concerns in some
particular, specific context. For example, the fact that vanilla FTP is not
sufficiently secure for use in some
Cullen,
On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote:
AFAICT, the experts team reports to IANA. We make recommendations to
them. They are the ones who have the conversation with the applicant.
They can take our advice or not - that's their decision.
I think you are pretty
David has said this well. Thank you.
Please let me know if there are any other questions.
--Michelle
On 1/30/11 10:52 AM, David Conrad d...@virtualized.org wrote:
Cullen,
On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote:
AFAICT, the experts team reports to IANA. We make
Doug, all,
30.01.2011 20:51, Doug Ewell wrote:
Mykyta Yevstifeyev wrote:
I'd like to see some kind of guideline that the RFC should not be
considered obsolete solely because of security or performance concerns
in some particular, specific context. For example, the fact that
vanilla FTP is
15 matches
Mail list logo
