On Wed, 12 Jul 2006, Eric Rosen wrote:
The focus on document relationships rather than on simplifying
the standards track is what (well, is one of the things) that
sent newtrk off into the weeds.
I completely agree.
Frankly, I don't care if someone on a desert island cannot
figure out from
Fred Baker wrote:
I would like to believe that a well documented interoperability test
constitutes DS qualification; the current DS qualification sets the
bar somewhat higher than that, and I note that few documents actually
achieve that, even though we can daily see implementations
Joel,
there is one useful aspect of our DS contortions. When we do the
work, we actually figure out which features turn out not to be used,
and get them out of the spec.
OSPF had ToS routing in its PS specification. It turned out that
there was only one implementation.
So when the protocol
On Thu, 13 Jul 2006, Eliot Lear wrote:
By RFC, not by STD (obviously):
Status 1999200020012002200320042005
-
PS 102 119 71 105 103 131 169
DRAFT 6 6 2 4 7
Pekka Savola wrote:
Some of this would in fact usually be documenting the product bugs
that were caused by ambiguous or incorrect specification. You're
right that once you've figured out a way to fix a spec problem in YOUR
implementation, there may be marginal interest in fixing it in the
Has this been exercised in the past, say, 5 years?
At least for widely-implemented protocols, such as SIP, there is no
reasonable way to say there is only one implementation that does X,
as there is no plausible way to catalog all such implementations.
Most of the implementors don't show
A variety of people at the plenary last night said declare victory.
But I know that different people took that statement to mean different
things. To me, declare victory means recognizing the reality of the
single level standard as it appears to be and moving on. This doesn't
mean to stop working
Tony,
If no one is willing to do the testing necessary to find and generate an
errata list, the spec should automatically become Historic. (Pick a time
span, say 2 years.) So the burden then is laid on updating the errata
list in order for the spec to remain a standard. (There would be an
On Jul 13, 2006, at 3:25 PM, Eliot Lear wrote:
We are in this position because we are not today documenting
existing practice, having not properly understood the lack of
desire to do what you class as minor amount of work.
The SRD approach generates Name.Serial references to sets of
At 21:25 13/07/2006, Eliot Lear wrote:
And I think we're at the point where I'm violating my own rule. There
is no concrete proposal here that I can argue in favor of or oppose, so
I think I'd better shut up and wait for one.
Dear Eliot,
IMHO the ambiguity is in the IETF mission. This is why
Hi,
I believe the rule was applied to the Entity MIB and the RMONMIB work,
IIRC.
dbh
-Original Message-
From: Henning Schulzrinne [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 13, 2006 9:02 AM
To: Joel M. Halpern
Cc: ietf@ietf.org
Subject: Re: Comments on draft-carpenter-newtrk
I thought it would be helpful to send these onlist, rather than blather at a
mike at the Wednesday night plenary, so I'm at least getting people to the
bar sooner.
If you have comments on my comments, please grab me anytime before the
plenary - I'd like to better understand what I'm seeing...
On Wed, 12 Jul 2006, Spencer Dawkins wrote:
2. Focus on document relationships
Today, users of IETF standards have no way to unambiguously identify
the complete current set of specifications for a given standard. In
particular, there is no effective structured document identification
Eric Rosen [EMAIL PROTECTED] wrote:
The focus on document relationships rather than on simplifying the standards
track is what... sent newtrk off into the weeds.
Wandering in the weeds isn't always wrong.
(We did make serious attempts to simplify the standards track, BTW.)
`
Frankly,
As Ted said during tonight's plenary, the draft and the plenary
discussion seem to be proposing either making (presumably
significant) changes in the standards process, or doing nothing, when
there may be other possibilities. Ted mentioned that there were
other things that could be done to
On Jul 12, 2006, at 7:18 PM, Randall Gellens wrote:
I'd also like to note that our specifications are not atomic;
advancing from PS to DS means showing at least two interworking
implementations of every feature and option.
Yes. The questions, at least in my mind, are:
(1) what does it
On Sun, 2006-06-11 at 09:04 -0400, Keith Moore wrote:
The general circumstances under which IETF has trouble designing new
protocols are either or both of these: 1. When there are substantial
conflicts between major industry players about strategic direction in
that area. 2. When the
On Sat, 2006-06-10 at 09:17 +0200, Brian E Carpenter wrote:
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-newtrk-questions-00.txt
,---
|The three possible ways forward are:
|
| 1. Agree that, apart from day to day efforts to improve efficiency
18 matches
Mail list logo
