Stewart, You realize that the text "example" you gave is meaningless - without making some (potentially non-obvious) assumptions, right? --> -----Original Message----- --> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] --> On Behalf Of Stewart Bryant --> Sent: Monday, January 09, 2006 2:47 PM --> To: Sam Hartman --> Cc: Harald Tveit Alvestrand; ietf@xxxxxxxx --> 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@xxxxxxxx --> https://www1.ietf.org/mailman/listinfo/ietf --> _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf