Bob Braden wrote:
* The draft has expired so I need to point to an external version. This draft
* which is looking at the properties of a routing network under conditions of
* failure would have been much clearer if it could have used mathematical
* notation rather than ASCIIised equations
Stewart Bryant writes...
If linearised formulas were a good idea mathematicians would use them
:)
Translation to ASCII representation should surely be the final step in
implementation not something imposed during the understanding and
description phase.
If symbolic formulas were useful in
How about a new mailing list or some such?!
Eliot
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
On Wed, Jan 11, 2006 at 01:02:55AM +0100,
Frank Ellermann [EMAIL PROTECTED] wrote
a message of 11 lines which said:
this code should work as it is forever for everybody who wants it
to work.
Yes, the good point about Graphviz is that it is readable even if you
do not know / have the
tell us anything
about the current rules.
...
-- -Original Message-
-- From: Stewart Bryant [mailto:[EMAIL PROTECTED]
-- Sent: Tuesday, January 10, 2006 12:01 AM
-- To: Gray, Eric
-- Cc: ietf@ietf.org
-- Subject: Re: Normative figures
--
--
-- Yes. And, if we're talking about wanting
* The draft has expired so I need to point to an external version. This draft
* which is looking at the properties of a routing network under conditions of
* failure would have been much clearer if it could have used mathematical
* notation rather than ASCIIised equations
*
*
* Scott,
*
* How about Sections 4.2.3.3 and 4.2.3.4 of RFC 1122 (1889), for examples
* of readable equations in ASCII? I my experience, normative protocol
* technical specifications rarely need equations much more complex than
* these examples. The only significant exception
On Mon, Jan 09, 2006 at 07:46:42PM +,
Stewart Bryant [EMAIL PROTECTED] wrote
a message of 73 lines which said:
For example you could say the following in text : [long and
complicated example deleted]
For such examples (do note that your example is an illustration of a
point and
On Mon, Jan 09, 2006 at 05:35:51PM -0500,
Gray, Eric [EMAIL PROTECTED] wrote
a message of 211 lines which said:
The reality is that putting things entirely in pictures means that
less validation of the intent of the picture is possible.
Automatic validation (by a program) is not possible
Bob Braden wrote:
*
* Normative figures perhaps. Normative equations definitely.
Scott,
How about Sections 4.2.3.3 and 4.2.3.4 of RFC 1122 (1889), for examples
of readable equations in ASCII? I my experience, normative protocol
technical specifications rarely need equations much more
On Mon, Jan 09, 2006 at 07:46:42PM +,
Stewart Bryant [EMAIL PROTECTED] wrote
a message of 73 lines which said:
For example you could say the following in text : router A connects
to router B and D, the cost from A to B is 2, and the cost from A to
D is 4. Router B connects to router C.
PROTECTED]
-- Sent: Monday, January 09, 2006 11:40 PM
-- To: Gray, Eric
-- Cc: ietf@ietf.org
-- Subject: Re: Normative figures
--
--
-- We write specifications so that they are easier to read, validate
-- and understand, not so that they are easier to write.
--
--
--
--
-- Eric
--
-- We write
consideration.
--
Eric
-- -Original Message-
-- From: Stewart Bryant [mailto:[EMAIL PROTECTED]
-- Sent: Tuesday, January 10, 2006 12:01 AM
-- To: Gray, Eric
-- Cc: ietf@ietf.org
-- Subject: Re: Normative figures
--
--
-- Yes. And, if we're talking about wanting to make the figures
Stewart == Stewart Bryant [EMAIL PROTECTED] writes:
Stewart For example you could say the following in text : router
Stewart A connects to router B and D, the cost from A to B is 2,
Stewart and the cost from A to D is 4. Router B connects to
Stewart router C. The cost to router
Stephane Bortzmeyer wrote:
Here is the Graphviz code, to compare (I also attached the
automatically produced PNG but Graphviz can make PDF or SVG
as well)
Nice, I've always loved graph theory. Now let it colour the
shortest path fromn B to D, and then ask it for some decent
ASCII art
in normative text to help
Stewart me to describe problems and their solutions. There are
Stewart many other nice-to-have's, but at the end of the day it
Stewart is the diagrams that are the key missing feature in our
Stewart document process.
Are you looking for normative figures
On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote:
Are you looking for normative figures? If so, can you point to an
example where you think they are necessary? (I'd like to avoid a
discussion of packet diagrams for the moment if that's OK)
Normative figures perhaps. Normative equations
Scott == Scott W Brim sbrim@cisco.com writes:
Scott On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote:
Are you looking for normative figures? If so, can you point to
an example where you think they are necessary? (I'd like to
avoid a discussion of packet diagrams
In message [EMAIL PROTECTED], Scott W Brim writes:
On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote:
Are you looking for normative figures? If so, can you point to an
example where you think they are necessary? (I'd like to avoid a
discussion of packet diagrams for the moment if that's OK
*
* Normative figures perhaps. Normative equations definitely.
Scott,
How about Sections 4.2.3.3 and 4.2.3.4 of RFC 1122 (1889), for examples
of readable equations in ASCII? I my experience, normative protocol
technical specifications rarely need equations much more complex than
Hi. With the exception of packet diagrams, I think all the examples
you bring up benefit significantly from clear textual description. I
believe I'd think that even if I could see the diagrams and I believe
I have enough experience with visualization (although not sight) to be
confident in that
Bob Braden wrote:
*
* Normative figures perhaps. Normative equations definitely.
Scott,
How about Sections 4.2.3.3 and 4.2.3.4 of RFC 1122 (1889), for examples
of readable equations in ASCII? I my experience, normative protocol
technical specifications rarely need equations much more
Sam Hartman wrote:
Hi. With the exception of packet diagrams, I think all the examples
you bring up benefit significantly from clear textual description.
Sam
I am not saying that clear text is not needed to accompany a diagram.
However a diagram allows a lot less text to be written
: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
-- On Behalf Of Stewart Bryant
-- Sent: Monday, January 09, 2006 2:22 PM
-- To: Bob Braden
-- Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
-- ietf@ietf.org; sbrim@cisco.com
-- Subject: Re: Normative figures
--
-- Bob Braden wrote
In message [EMAIL PROTECTED], Scott W Brim writes:
On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote:
Are you looking for normative figures? If so, can you point to an
example where you think they are necessary? (I'd like to avoid a
discussion of packet diagrams for the moment
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| On Behalf Of Stewart Bryant
| Sent: Tuesday, January 10, 2006 6:47 AM
| To: Sam Hartman
| Cc: Harald Tveit Alvestrand; ietf@ietf.org
| Subject: Re: Normative figures
|
| Sam Hartman wrote:
|
| Hi
PM, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Scott W Brim writes:
On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote:
Are you looking for normative figures? If so, can you point to an
example where you think they are necessary? (I'd like to avoid a
discussion of packet diagrams
:47 PM
-- To: Sam Hartman
-- Cc: Harald Tveit Alvestrand; ietf@ietf.org
-- Subject: Re: Normative figures
--
-- Sam Hartman wrote:
--
-- Hi. With the exception of packet diagrams, I think all
-- the examples
-- you bring up benefit significantly from clear textual description.
--
-- Sam
--
-- I
Dassa wrote:
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| On Behalf Of Stewart Bryant
| Sent: Tuesday, January 10, 2006 6:47 AM
| To: Sam Hartman
| Cc: Harald Tveit Alvestrand; ietf@ietf.org
| Subject: Re: Normative figures
|
| Sam Hartman wrote:
|
| Hi
(potentially non-obvious) assumptions, right?
-- -Original Message-
-- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
-- On Behalf Of Stewart Bryant
-- Sent: Monday, January 09, 2006 2:47 PM
-- To: Sam Hartman
-- Cc: Harald Tveit Alvestrand; ietf@ietf.org
-- Subject: Re: Normative figures
Stewart,
See below...
--
Eric
-- -Original Message-
-- From: Stewart Bryant [mailto:[EMAIL PROTECTED]
-- Sent: Monday, January 09, 2006 6:50 PM
-- To: Gray, Eric
-- Cc: ietf@ietf.org
-- Subject: Re: Normative figures
--
-- Eric
--
-- You are missing the point.
--
Out
We write specifications so that they are easier to read, validate
and understand, not so that they are easier to write.
Eric
We write specs so that they will be correctly implemented.
Anything that makes a specification easier to correctly understand
surely makes it more likely that it
Yes. And, if we're talking about wanting to make the figures
normative, I assume we are talking about a specification. In
that case, it is far more important that the description MUST
be precise, than it is that it MAY be convenient.
Please can we clarify the existing rules:
For a
Stewart Bryant wrote:
We write specifications so that they are easier to read, validate and
understand, not so that they are easier to write.
Eric
We write specs so that they will be correctly implemented.
Anything that makes a specification easier to correctly understand
surely makes it
34 matches
Mail list logo
