Stewart,
You realize that the text "example" you gave is meaningless -
without making some (potentially non-obvious) assumptions, right?
--> -----Original Message-----
--> From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org]
--> On Behalf Of Stewart Bryant
--> Sent: Monday, January 09, 2006 2:47 PM
--> To: Sam Hartman
--> Cc: Harald Tveit Alvestrand; ietf(_at_)ietf(_dot_)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 am not saying that clear text is not needed to accompany
--> a diagram.
--> However a diagram allows a lot less text to be written producing a
--> shorter clearer draft with less clutter.
-->
--> 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.
A --(2)--> B
|
+---(4)--> D
--> Router B connects to router C. The cost to router A is 6, and
--> the cost to router C is 10.
+ A <--(6)--+
| | |
| +--(2)--> B --(10)--> C
|
+--(4)--> D
(Assumes "cost" is from router B in both cases)
--> Router C connects to router D. The cost to router B is 9
--> and the cost to router D is 8.
+ A <--(6)--+
| | |
| +--(2)--> B <--(9)---+
| | |
| +--(10)--> C
| |
+--(4)--> D <----(8)---+
(Assumes "cost" is from router C in both cases)
--> The cost from router D to router A is 16 and ...
+------+
| |
| +-> A <--(6)--+
| | | |
| | +--(2)--> B <--(9)---+
| | | |
| +--(16)----+ +--(10)--> C
| | |
+------(4)--> D <----(8)----+
-->
--> ... the cost to router A is 99.
?
(Assuming you meant the cost from D to C - not A)
+------+
| |
| +-> A <--(6)--+
| | | |
| | +--(2)--> B <--(9)---+
| | | |
| +--(16)----+ +--(10)--> C <-+
| | | |
+------(4)--> D <----(8)----+ |
| |
+-----(99)--------+
(Figure foo?)
-->
--> In fact you would probably need a table to make sure that
--> you did not make a mistake. In either case it is hard for
--> most people to figure out the what the topology is much
--> less imagine packet actions.
Actually, you need a figure to make sure that you did not
make a mistake, and a second set of eyes to compare what
you said to what you apparently meant.
-->
--> Now compare this to:
-->
--> "The network and costs are as shown in figure foo."
-->
Is the above actually figure foo?
The reality is that it would be better to break it this way:
"In the network in figure foo, the link costs are as follows:
A -> B = 2
B -> A = 6 +-> A <----> B <-+
A -> D = 4 | |
D -> A = 16 +-> D <----> C <-+
B -> C = 10
C -> B = 9 Figure foo
C -> D = 8
D -> C = 99 "
--> Simple text and the visualisation is already done for you
--> so you can focus on the problem.
-->
The reality is that putting things entirely in pictures means
that less validation of the intent of the picture is possible.
Keeping pictures as simple as possible is, therefore, a goal
since it is far easier to make mistakes in complex figures and
far more difficult to determine that a mistake has been made.
Using a mixture of text and figure(s), tables or - possibly -
equations makes it both more understandable and easier to be
certain of conveying the idea(s).
For example, in the above, I could verify that I understand
your intent by asking:
"From this it is apparent that the link cost (D->C) is 99,
but the actual minimum cost of getting from D to C given by
the formula:
(D->A) + (A->B) + (B->C) = 16 + 2 + 10 = 28
Is that correct?"
If we choose to use a simple combination of representations,
rather than strictly expecting a figure to explain it all,
the figure is likely to be far simpler. For example, using
an approach similar to the above, you could probably describe
a much more complex network than 13, or 20 or maybe even 30
nodes using ASCII art. The purpose of the picture is to be
a simplified referent.
-->
--> Now I realise the above could be done in ascii art, but we
--> have problems that need 13 or more nodes to set up.
-->
--> > 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 belief.
--> >
--> >
--> >
--> >As such, I don't believe these diagrams should be normative.
--> >
--> >
--> >I actually thin that many of the tunnel overlay network documents
--> >(PWE3, L2VPN, L3VPN) could benefit significantly from more focus on
--> >the text of the descriptions of situations being described.
--> >
--> >
--> It is probably a question of how we work and the tools that we
--> find most effective.
-->
--> >If you believe that normative documents are required, I'd
--> like you to
--> >explain why the diagrams cannot be described in the text,
--> why doing so
--> >would decrease the quality of the specification, or why
--> doing so would
--> >not be a useful investment in our time.
--> >
--> >
--> >
--> >
--> One reason is that it takes a lot of text to describe what
--> can be drawn
--> with a few lines and symbols. Many people will get lost in
--> the text and
--> in any case would have to transcribe the text into a diagram for
--> themselves before they could understand what is happening.
-->
--> - Stewart
-->
-->
-->
-->
-->
--> _______________________________________________
--> Ietf mailing list
--> Ietf(_at_)ietf(_dot_)org
--> https://www1.ietf.org/mailman/listinfo/ietf
-->
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf