Sam Hartman wrote:
"Stewart" == Stewart Bryant <stbryant(_at_)cisco(_dot_)com> writes:
Stewart> I am in favour of any practical method that allows us to
Stewart> progress towards the best tools for the job.
Stewart> My personal end-goal is simple: I want us to be able to
Stewart> use modern graphical techniques 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?
Yes
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)
Sam
In no particular order:
State diagrams - The issue here is density and line-crossing.
Packet Diagrams
Annotated network scenarios - I have particularly seen this problem
in BGP with ASBRs, packets, ASs and filters, but it applies to
any case where we wish to say this is the state in this node,
so this packet flows, so this is the resultant state this node.
The problem is particularly difficult when you get to four or
more nodes and need to show their topological context.
The problem here is the need for higher density line and
object density than you can achieve with ASCII art as well
as the need for small fonts to include the annotation.
Network snapshots, which require a set of network states to
be presented side by side by side. This is needed in showing
the dynamics of network state change such as the dynamics
of routing convergence.
Overlay networks of the sort that get built with tunnels - I have
seen problems in PWE3, RTGWG (with IP fast re-route), and L*VPN.
I would think that there are similar problems of expression in
the mobile area. This is an area that really benefits from both
lines and colours.
Non-trivial network scenarios where you want to show asymetric
costs commonly needed in routing.
Scenarios where you wish to illustrate reachibility of different
regions of a network.
Equations in general.
Network diagrams annotated with equations (such as routing costs
or timing).
Graphs, in general, but they become normative when you
wish to apply a performance mask.
Timing diagrams
G.802 diagrams (this is a formalized notation for layered
networks). These are sort of like equations in that the symbols
are well known. The diagrams can be quite complex.
It has also been pointed out that you can't write a draft showing
the dependency relationships between other drafts using the tools
group tools output. Not that such a draft would be normative.
I am planning to write a draft to illustrate the problem, which
I will submit in both ASCII and pdf using the current dual
submission procedure. This in itself will be an interesting
exercise to see if it still works.
- Stewart
Or are you looking at normative text that is easier to understand with
illustrative figures?
_______________________________________________
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