Re: Accessibility of Documents (veering off-topic)

[Spencer Dawkins]

Dear Dave and Lucy,


watch how you use the word "lynch" please. As the oldest of six
I'm a bit *sensitive* to mob comments. ;-)


Lucy, I suspect that they merely were making a spelling error, since I'm 
sure they were referring to folk who are truly essential, and therefore 
qualify as linch pins...


d/

ps.  As one who constantly wishes people would find a different dismissive 
label than "crock" I do, however, share your sensitivity.


My sincerest ("chuckle, snort!") apologies :-)

It is difficult to come up with useful terms that clearly describe a 
barely-controlled riot ... I thought the reference to July14 in the name of 
the draft that became RFC 3933 was very witty, but so few people caught the 
reference to Bastille Day that I finally decided it was only half-witty.


I guess, based on the IETF's previous experience, I should be using "Kobe" 
as a verb?


Thanks,

Spencer 




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Accessibility of Documents (veering off-topic)

[Dave Crocker]

watch how you use the word "lynch" please. As the oldest of six
I'm a bit *sensitive* to mob comments. ;-)




Lucy, I suspect that they merely were making a spelling error, since I'm sure 
they were referring to folk who are truly essential, and therefore qualify as 
linch pins...


d/

ps.  As one who constantly wishes people would find a different dismissive label 
than "crock" I do, however, share your sensitivity.



--

Dave Crocker
Brandenburg InternetWorking


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Alternative formats for IDs

[Brian Rosen]

I'd mostly agree if this was a one off, but it's not; it requires continuous
effort to maintain.  My experience that manual is usually cheapest if it
only has to be done once, and automation is cheapest if it has to be
continuously maintained.  YMMV.

Most of the harvesting of sections of things that are now text that could be
harvested apply to RFCs and not IDs, but things like ABNF checking and even
MIB checking could be part of ID nits.  Hyperlinks apply to both.

There are many ways to put meta-data in files, but I'd rather not invent a
new one.  xml is just fine, thank you.  And we have a nice tool that puts
out text and html, and with a small amount of effort, PDF from xml.  Our
reluctance to use it is mostly:
The RFC editor has some problems which have not, to my knowledge,
beenenumerated.

There are currently other ways to produce ASCII output that people
are
reluctant to give up on.

I suspect we can fix the former.  The question is whether the usefulness of
the harvesting and alternative outputs outweighs the latter, assuming we
accept ASCII output as required and normative.

Brian


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul
Hoffman
Sent: Tuesday, January 10, 2006 11:15 AM
To: ietf@ietf.org
Subject: RE: Alternative formats for IDs

At 9:45 AM -0500 1/10/06, Brian Rosen wrote:
>Do you have any idea how painful it is to build any kind of product that
has
>good management simply because there is no library of MIBs, with references
>to documents?  There isn't even a LIST of IETF MIBs.  You can't figure out
>if a document has a MIB unless you actually look at the text (although many
>have a big hint in the title of the document).  So yes, I believe better
MIB
>tools would lead to better products, although it would be hard to prove it.

Why does this need to be done in the RFCs or Internet Drafts 
themselves? Why, for example, can't a human with a bit of training 
extract all the MIBs from the current RFCs and put them into a 
repository that is machine-accessible? Doing so would probably take 
less time than writing the tool to make human-readable RFCs also 
machine-readable.

As for Internet Drafts (if we really want people implementing from 
Internet Drafts), it is trivial to create a convention that says "if 
you want the MIB in your draft to be machine-readable, copy the MIB 
to a public web server and, in the draft, put on a line by itself: 
THE-MIB-IS-AT ". No changes are needed to any input or output 
tools, yet the problem of finding MIBs is solved.

>I would like to enable automated testing of ABNF.  I'd like to be able to
>cross check the ABNF from one document against its normative references to
>see what changes or conflicts.  I'd like to be able to generate a complete
>list of SIP error messages a UA may be expected to encounter.  I'd like to
>see a lot more hyperlinking of things.  All of these are much easier with
>meta-data.

Sure. If any of those features came free or very cheap, that would be 
great. None of them do, particularly when you factor in the 
design-by-entire-IETF-mailing-list work factor. Instead, a bit of 
human interaction is much less expensive.

--Paul Hoffman, Director
--VPN Consortium

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Alternative formats for IDs

[Frank Ellermann]

Paul Hoffman wrote:

> If any of those features came free or very cheap, that
> would be great.

JFTR:  The last xml2rfc version under test (pre3) supported
to validate ABNF on the fly for  if the
source asks for "strict" processing.

 Bye, Frank



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Accessibility of Documents (veering off-topic)

[Lucy E. Lynch]

On Tue, 10 Jan 2006, John C Klensin wrote:

>
>
> --On Tuesday, 10 January, 2006 16:58 -0600 Spencer Dawkins
> <[EMAIL PROTECTED]> wrote:
>
> >...
> > I'm also thinking that if an RFC is bad enough, having
> > pictures of authors/editors might make it easier to recognize
> > the guilty parties and organize a lynch mob, and that might do
> > more to improve our quality than anything since Kobe...
>
> As an occasional fan of lynch mobs in the service of rough
> consensus, I believe your objective would be better accomplished
> by a photo gallery of recent RFC authors and editors, WG chairs,
> and IESG and IAB members rather than making RFCs longer and more
> bulky.
>
> You might suggest this to the IAOC; I am fairly certain they
> would give it the appropriate priority :-)

Gents,

watch how you use the word "lynch" please. As the oldest of six
I'm a bit *sensitive* to mob comments. ;-)

Lucy E. Lynch   Academic User Services
Computing CenterUniversity of Oregon
llynch  @darkwing.uoregon.edu   (541) 346-1774



> john
>
>
>
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Accessibility of Documents (veering off-topic)

[John C Klensin]

--On Tuesday, 10 January, 2006 16:58 -0600 Spencer Dawkins
<[EMAIL PROTECTED]> wrote:

>...
> I'm also thinking that if an RFC is bad enough, having
> pictures of authors/editors might make it easier to recognize
> the guilty parties and organize a lynch mob, and that might do
> more to improve our quality than anything since Kobe...

As an occasional fan of lynch mobs in the service of rough
consensus, I believe your objective would be better accomplished
by a photo gallery of recent RFC authors and editors, WG chairs,
and IESG and IAB members rather than making RFCs longer and more
bulky.  

You might suggest this to the IAOC; I am fairly certain they
would give it the appropriate priority :-)

john




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Normative figures

[Frank Ellermann]

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 output...   Joke off, this "code" should work as
it is forever for everybody who wants it to work.  Bye, Frank



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Working Group chartering

[Burger, Eric]

Title: RE: Working Group chartering






I was responding to the assertion that stuff got to the IETF because the individuals are, for the most part, paid by companies, and thus if someone was proposing a work item, it obviously was motivated by a corporate need.  My statements was an obvious COUNTER-example.  Sorry I didn't make the smiley larger.

 -Original Message-
From:   Harald Tveit Alvestrand [mailto:[EMAIL PROTECTED]]
Sent:   Tue Jan 10 18:23:55 2006
To: James M. Polk; Burger, Eric
Cc: ietf@ietf.org
Subject:    RE: Working Group chartering



--On tirsdag, januar 10, 2006 12:26:22 -0600 "James M. Polk"
<[EMAIL PROTECTED]> wrote:

> At 12:55 PM 1/10/2006 -0500, Burger, Eric wrote:
>> Also, I am a big proponent of microeconomics, which would have rational
>> actors only put forth and push stuff clearly needed for products.
>> HOWEVER, in the "highest" IETF fashion, I've regularly seen multiple
>> folks from the same company arguing against each other in the working
>> groups.
>
> Now, which company does this sound like?
>
>> I would have much more appreciated their working out their
>> differences at home and bring in their 'corporate' position :)
>
> I do hope you're not even remotely serious with this suggestion...

Seconding James.. a requirement to have unanimous intra-company signoff on
anything presented to the IETF would be the single quickest way to reduce
the contributions to the IETF from the companies I've been involved in

"we are all individuals", in addition to its other properties, is a way to
let me say things (like this message) in public WITHOUT having to check
with my "representative" or my "coordinating committee" before sending it.
If my company says "why did you say ", I can always say "it
was my personal contribution, you don't have to take the blame for it".
Has worked for me so far





___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Working Group chartering

[Harald Tveit Alvestrand]

--On tirsdag, januar 10, 2006 12:26:22 -0600 "James M. Polk" 
<[EMAIL PROTECTED]> wrote:



At 12:55 PM 1/10/2006 -0500, Burger, Eric wrote:

Also, I am a big proponent of microeconomics, which would have rational
actors only put forth and push stuff clearly needed for products.
HOWEVER, in the "highest" IETF fashion, I've regularly seen multiple
folks from the same company arguing against each other in the working
groups.


Now, which company does this sound like?


I would have much more appreciated their working out their
differences at home and bring in their 'corporate' position :)


I do hope you're not even remotely serious with this suggestion...


Seconding James.. a requirement to have unanimous intra-company signoff on 
anything presented to the IETF would be the single quickest way to reduce 
the contributions to the IETF from the companies I've been involved in


"we are all individuals", in addition to its other properties, is a way to 
let me say things (like this message) in public WITHOUT having to check 
with my "representative" or my "coordinating committee" before sending it.
If my company says "why did you say ", I can always say "it 
was my personal contribution, you don't have to take the blame for it".

Has worked for me so far



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Accessibility of Documents (veering off-topic)

[Spencer Dawkins]

Hi, Sam,

Thank you for taking the time to explain this stuff to us. It is very 
helpful.


Just on your last point:


pictures: I guess someone might want to include a photo or other
picture in an IETF spec.  I'd kind of like to know why.  Be sure to
explain what the point of the photo is in the text.


In RFC 2397, "The "data" URL scheme", the following URL appears:

  

If you cut-and-paste this text into an HTML document and view it with a 
browser that supports RFC 2397 (last I looked, Netscape and Mozilla did and 
IE did not, but that's been a while), you see either a black-and-white GIF 
of Larry Masinter that's about the size of your thumbnail, or "Larry" as the 
ALT text.


That's not quite "putting a picture in an RFC", but it's close :-)

I'm also thinking that if an RFC is bad enough, having pictures of 
authors/editors might make it easier to recognize the guilty parties and 
organize a lynch mob, and that might do more to improve our quality than 
anything since Kobe...


Have a great day,

Spencer 




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Normative figures

[Sam Hartman]

> "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 A is 6, and the cost to
Stewart> router C is 10. Router C connects to router D. The cost
Stewart> to router B is 9 and the cost to router D is 8. The cost
Stewart> from router D to router A is 16 and the cost to router A
Stewart> is 99.


I think we fundamentally disagree here that the text is not needed.
There's a bit of fuzz in that I think the normative text needs to
describe the properties of the graph necessary to make your point and
to make it obvious that such a graph exists; it may not need to
describe all the labels of all edges.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Accessibility of Documents

[Sam Hartman]

Hi.  I'd hoped to avoid this, but a number of people both on and
off-list have asked me to discuss the issue of accessibility of documents.
for those who may not know, I'm blind.


I try and avoid such discussions.  It is fairly clear to me that my
standards of accessibility are different than other blind peoples'.
The one time I was involved in accessibility consulting,the I was told
by the blind users that there is no way a blind person could use the
system we had designed.  So, I can speak for myself, but I will not
claim that  anyone else will agree with me.


I do find IETF specs significantly easier to read than most other
SDOs.  Much of this is the fact that RFCs are available as text.  I'd
find HTML almost as convenient.  

I think HTML would be much more accessible than PDF.  Some PDFs are
reasonably OK.  However some PDFs tend to have images instead of text
and that roughly requires printing out, scanning and then OCRing the
get information out.  (In theory you could just OCR the PDF; I have
not had as good of luck with that as I should, but a new solution I've
been working with for OCR might do much better that way.)


Some PDFs are just hard to extract text from even if they don't use
images.  I think it is a font encoding issue.  PDFs using the computer
modern fonts are notoriously bad in this regard.

I also find that IETF specs are more readable because they do tend to
focus less on figures and actually spend the time to explain what is
going on rather than depending on a picture.  

I'd like to focus on several types of possible figures and discuss
ways they could be handled.

network packet diagrams: I can get enough content out of these in
ASCII text so that I know what is in the packet and roughly what
order.  I find determining how long fields are to be challenging
without help from someone else.  I believe the accessibility of our
documents would be significantly reduced if we replaced these with
images without having an alternate representation of the information.

equations: ASCII equations are generally as easy to follow for me as
for others--which is to say sometimes not so great.  I agree that
visually appealing equations could be useful.  LaTex is easier to read
than mathml; I'm not sure how to provide both the image and the latex
in the same document.  Perhaps alt tags could be used.


Graphs: A lot of diagrams attempt to show relations between entities,
state transitions or other things that fall into the category of
mathematical graphs (sets of nodes and edges).  I can generally get
the names of nodes out of ASCII descriptions but no more.  Here's a
case where I really think the diagram should not be normative and that
you need good text to go along with the diagram.  It should be
possible to find the names of the nodes, the edges and the labels on
the edges by reading the text.  In general if you are doing a good job
of explaining your protocol you'll want this in your text anyway.  The
one case where this might not be true is state transition diagrams: if
you don't manage to explain why your state machine works the way it
does, then you might not have any reason to describe the states in the
text.  My opinion as an IESG member and document reviewer is that it's
worth it to explain the reasoning behind your states.  That gives you
an excuse to have your text be complete and makes your document much
easier to review.

function graphs: Another class of diagram would be a graph of some
function.  I'm likely to get nothing out of the diagram in ASCII.
Here, if I really cared, I actually could do something with an image;
there are ways to print the image in such a way that I could at least
look at the shape of the function.  It is useful to describe the
variables and the domain and range of the function.  It is useful if
the text describes the basic conclusion of the graph.  "As you can
see, the performance of this protocol is exponential in the number of
participants in the session.  We recommend against large sessions."

pictures: I guess someone might want to include a photo or other
picture in an IETF spec.  I'd kind of like to know why.  Be sure to
explain what the point of the photo is in the text.

--Sam

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Working Group chartering

[James M. Polk]

At 12:55 PM 1/10/2006 -0500, Burger, Eric wrote:

Also, I am a big proponent of microeconomics, which would have rational
actors only put forth and push stuff clearly needed for products.
HOWEVER, in the "highest" IETF fashion, I've regularly seen multiple
folks from the same company arguing against each other in the working
groups.


Now, which company does this sound like?


I would have much more appreciated their working out their
differences at home and bring in their 'corporate' position :)


I do hope you're not even remotely serious with this suggestion...



Likewise, often I see folks bring something that "needs to be solved" to
the IETF.  This can generate lots of interest, especially if the person
with the problem is a customer.  However, that still doesn't mean the
solution space is in the realm of the IETF.

-Original Message-
From: Gray, Eric [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 10, 2006 12:03 PM
To: Burger, Eric
Cc: ietf@ietf.org
Subject: RE: Working Group chartering

Eric,

--- [SNIP ---
--> IMHO, *way* too many I*E*TF work groups get chartered based on
--> an idea. We then spend tons of resources on figuring out if the
--> idea will work. We produce lots of half-baked documents with
--> little basis in working code.  Then folks try implementing
--> what's been spec'ed, find it doesn't work, but then find a ton
--> of resistance to change, because the specs are three years old
--> and "we don't want to break draft-mumble-05 implementations."
-->
--> If something is an idea, let's make it politically acceptable
--> for the "work" to be done in the I*R*TF first.
-->
--- [SNIP] ---

I think this is a gross mischaraterization of current practice in
the IETF generally - however many exceptions we might find.

Usually - at least among those of us that work for a living - we
would not bring something to the IETF unless we were already in
the process of implementing it and we have been encouraged by our
employers (or - indirectly - by our customers) to bring it to the
IETF.

When people bring ideas to the IETF that "seem like a good thing"
but aren't practical or implementable at the current time, they
are usually encouraged to take those ideas to the IRTF.

--
Eric

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Trying to invent a way of determining "consensus"

[Sam Hartman]

I strongly disagree with David's characterization of the IETF, his
characterization of how things should work, his claim that the problem
he has identified should be fixed and the proposed solution.

Consider this a vote of "wrong direction."  If it becomes apparent
that David is attracting significant interest in his proposal then I
will respond in more detail.  Until then I'll try and work on
directions of improving the IETF that I like better.  

the only reason I'm writing this message is that I don't want silence
to be taken as agreement in this instance.  Clearly if a number of
people come forward and agree with David then I must either provide
more constructive suggestions or accept that my objection will have
little weight.


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Working Group chartering

[Melinda Shore]

On 1/10/06 12:55 PM, "Burger, Eric" <[EMAIL PROTECTED]> wrote:
> Normally, I would agree, but in one area in particular where I'm active,
> RAI, I've seen it all.  There has been a ton of work that was
> "interesting" and "nice to have."

I'm going to hazard a guess here and suggest that that area has
more interaction with/more interdependencies with other standards
bodies, where it's more typical to be very, very top-down.  In a
number of cases those bodies have said "We need an internet
protocol that does ; the IETF is the organization that standardizes
internet protocols so we'll send the work there."  To the extent that
the other option is to have other bodies standardizing internet
protocols I expect that's actually somewhat desirable.  If the
alternative were that the work went on hold until something had something
that was technically acceptable and reasonably mature, what would
happen outside the IETF?  Would those other bodies go along (even though
that's not how they work, themselves) or would they start producing
more internet protocols?

On the upside, one considerable benefit to the way the IETF does
its work, I think, is that it's usually pretty difficult to do
the kind of horse trading ("I'll agree to your unnecessary feature
if you'll agree to my unnecessary feature") that sometimes takes
place elsewhere.

Melinda

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Working Group chartering

[Burger, Eric]

Normally, I would agree, but in one area in particular where I'm active,
RAI, I've seen it all.  There has been a ton of work that was
"interesting" and "nice to have."

Also, I am a big proponent of microeconomics, which would have rational
actors only put forth and push stuff clearly needed for products.
HOWEVER, in the "highest" IETF fashion, I've regularly seen multiple
folks from the same company arguing against each other in the working
groups.  I would have much more appreciated their working out their
differences at home and bring in their 'corporate' position :)

Likewise, often I see folks bring something that "needs to be solved" to
the IETF.  This can generate lots of interest, especially if the person
with the problem is a customer.  However, that still doesn't mean the
solution space is in the realm of the IETF.

-Original Message-
From: Gray, Eric [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 10, 2006 12:03 PM
To: Burger, Eric
Cc: ietf@ietf.org
Subject: RE: Working Group chartering

Eric,

--- [SNIP ---
--> IMHO, *way* too many I*E*TF work groups get chartered based on
--> an idea. We then spend tons of resources on figuring out if the
--> idea will work. We produce lots of half-baked documents with 
--> little basis in working code.  Then folks try implementing 
--> what's been spec'ed, find it doesn't work, but then find a ton 
--> of resistance to change, because the specs are three years old 
--> and "we don't want to break draft-mumble-05 implementations."
--> 
--> If something is an idea, let's make it politically acceptable 
--> for the "work" to be done in the I*R*TF first.
--> 
--- [SNIP] ---

I think this is a gross mischaraterization of current practice in
the IETF generally - however many exceptions we might find.

Usually - at least among those of us that work for a living - we
would not bring something to the IETF unless we were already in
the process of implementing it and we have been encouraged by our
employers (or - indirectly - by our customers) to bring it to the
IETF.

When people bring ideas to the IETF that "seem like a good thing"
but aren't practical or implementable at the current time, they
are usually encouraged to take those ideas to the IRTF.

--
Eric

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: objection to proposed change to "consensus"

[Sam Hartman]

> "Stewart" == Stewart Bryant <[EMAIL PROTECTED]> writes:

>> I think these are valuable inputs as well.  There are people
>> involved; whether these people are happy, whether they will
>> continue to work, are important factors.  Of course there are
>> religious arguments on the other side: "I want my architectural
>> diagrams; they work well in the ITU and I want them here," is
>> on the same level as "I won't use MS software."
>> 
>> 

Stewart> Sam

Stewart> I disagree that the use of diagrams is a religious
Stewart> issue. Diagrams are a very simple way to 

I think the discussion has reached an all time low.  We're arguing
about whether something is a religious issue or not.

I think I'll add one more reason to why I think it is important to
consider religious issues: that way,you don't have to argue about
whether something is religious.

--Sam


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Working Group chartering

[Gray, Eric]

Eric,

--- [SNIP ---
--> IMHO, *way* too many I*E*TF work groups get chartered based on
--> an idea. We then spend tons of resources on figuring out if the
--> idea will work. We produce lots of half-baked documents with 
--> little basis in working code.  Then folks try implementing 
--> what's been spec'ed, find it doesn't work, but then find a ton 
--> of resistance to change, because the specs are three years old 
--> and "we don't want to break draft-mumble-05 implementations."
--> 
--> If something is an idea, let's make it politically acceptable 
--> for the "work" to be done in the I*R*TF first.
--> 
--- [SNIP] ---

I think this is a gross mischaraterization of current practice in
the IETF generally - however many exceptions we might find.

Usually - at least among those of us that work for a living - we
would not bring something to the IETF unless we were already in
the process of implementing it and we have been encouraged by our
employers (or - indirectly - by our customers) to bring it to the
IETF.

When people bring ideas to the IETF that "seem like a good thing"
but aren't practical or implementable at the current time, they
are usually encouraged to take those ideas to the IRTF.

--
Eric

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Normative figures

[Gray, Eric]

Stewart,

You address this to me - though I do not make these rules.

However, I will do my best to answer your question.  In the
case you pose below, "almost incomprehensible" is the key phrase.
Had you not qualified "incomprehensible", the answer would be no,
at least IMO.

Moreover, I believe there is evidence to this effect, as
pointed out previously, in the fact that at least one RFC is 
essentially only available in PS and PDF format.

However, as long as a text version is comprehensible, it
should be the normative version - simply because, however hard
it might be to overcome the difficulty in comprehending it for
the average reader, it is not sufficient to justify making it
absolutely impossible to comprehend for any specific minority
of readers (at least among those "minorities" that are likely
to be required to understand it).  Minorities in this context
inclide anyone who does not have the ability to use the needed
document display tools - either because they do not have them
or because they are otherwise prevented from using them.

However, as must be apparent from other discussion in 
various related threads, this is only a minority 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
--> >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 standards track document is it technically acceptable 
--> to provide:
--> 
--> A .pdf that is complete (but is non-normative under current rules)
--> 
--> plus
--> 
--> An ASCII text in which the background material refers to 
--> figures in the
--> .pdf  but which contains the essential normative statements.
--> 
--> i.e. Is a standards track RFC approvable when it is correct in the 
--> technical
--> sense, even if it is almost incomprehensible without the 
--> text, figures and
--> equations from its non-normative twin.
--> 
--> - Stewart
--> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Normative figures

[Gray, Eric]

Stewart,

Yes, you are correct.  But, if you had correctly understood
the comment you quote below, you would realize that we're clearly
in agreement already - at least on that aspect of the discussion.

:-)

My point is that we make inclusion of elaborate figures more
difficult because elaborate figures don't necessarily make for a
better understanding - any more than complicated equations do.  If
people generally agree that complicated diagrams, tables, figures
or equations is necessary to understanding a specification - then
it is quite possible to do so.

The fact that this makes it (at least slightly) harder to
write a specification if it must include complex art, does not 
impact on the difficulty in reading the resulting specification.
However, as pointed out several times, making it trivially easy
to include complex art MAY make reading specifications that do
not require it much harder.

Since the vast majority of documents produced by the IETF
do not appear to require complex art, our process is optimized
for the normal case - just as it should be...

--
Eric

--> -Original Message-
--> From: Stewart Bryant [mailto:[EMAIL 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 specs so that they will be correctly implemented.
--> Anything that makes a specification easier to correctly understand
--> surely makes it more likely that it will be correctly implemented?
--> 
--> The cost of incorrect implementation is so high that we can
--> can afford to pay a relatively high cost in the effort and
--> technology needed to read and write the specification.
--> 
--> - Stewart
--> 
--> 
--> 
--> 
--> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Alternative formats for IDs

[Randy.Dunlap]

On Tue, 10 Jan 2006, Brian E Carpenter wrote:

> ...
> > What we are seeing is increasing use of fully automated tools that don't
> > have humans identifying which octets are MIB and which are code.  You can't
> > do that with plain ASCII.
>
> You can do that with meta-data encoded in plain ASCII. In fact, that
> would work better for automated extraction than anything visual such as
> using multiple fonts.
>
> ...

Does the RFC editor accept HTML in plain ASCII RFCs?

-- 
~Randy

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Working Group chartering

[Dave Crocker]

IMHO, *way* too many I*E*TF work groups get chartered based on an idea.

...

Standardize stuff that already works -- what a concept.


...

I don't care how the technology gets developed.
IRTF, vendors, universities, whatever.  



The current model in the IETF appears to be:  Your running code does suggest
that this is worth pursuing.  So, now let's start all over, with no real concern
for preserving that work and develop a fresh wish-list of features.

My suggestion is that we stop doing that, instead using the core of workers who
are committed to delivering that running code, to define the requirements.  The
community then gets to review potential problems with that work.
Pseudo-problems, such as "it should do more things" and "I can't give you any
specifics, but there might be problems" are out of bounds.

d/
--

Dave Crocker
Brandenburg InternetWorking


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Alternative formats for IDs

[Paul Hoffman]

At 9:45 AM -0500 1/10/06, Brian Rosen wrote:

Do you have any idea how painful it is to build any kind of product that has
good management simply because there is no library of MIBs, with references
to documents?  There isn't even a LIST of IETF MIBs.  You can't figure out
if a document has a MIB unless you actually look at the text (although many
have a big hint in the title of the document).  So yes, I believe better MIB
tools would lead to better products, although it would be hard to prove it.


Why does this need to be done in the RFCs or Internet Drafts 
themselves? Why, for example, can't a human with a bit of training 
extract all the MIBs from the current RFCs and put them into a 
repository that is machine-accessible? Doing so would probably take 
less time than writing the tool to make human-readable RFCs also 
machine-readable.


As for Internet Drafts (if we really want people implementing from 
Internet Drafts), it is trivial to create a convention that says "if 
you want the MIB in your draft to be machine-readable, copy the MIB 
to a public web server and, in the draft, put on a line by itself: 
THE-MIB-IS-AT ". No changes are needed to any input or output 
tools, yet the problem of finding MIBs is solved.



I would like to enable automated testing of ABNF.  I'd like to be able to
cross check the ABNF from one document against its normative references to
see what changes or conflicts.  I'd like to be able to generate a complete
list of SIP error messages a UA may be expected to encounter.  I'd like to
see a lot more hyperlinking of things.  All of these are much easier with
meta-data.


Sure. If any of those features came free or very cheap, that would be 
great. None of them do, particularly when you factor in the 
design-by-entire-IETF-mailing-list work factor. Instead, a bit of 
human interaction is much less expensive.


--Paul Hoffman, Director
--VPN Consortium

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Working Group chartering

[Dave Crocker]

IMHO, *way* too many I*E*TF work groups get chartered based on an idea.

...

Standardize stuff that already works -- what a concept.


...

I don't care how the technology gets developed.
IRTF, vendors, universities, whatever.  



The current model in the IETF appears to be:  Your running code does suggest 
that this is worth pursuing.  So, now let's start all over, with no real concern 
for preserving that work and develop a fresh wish-list of features.


My suggestion is that we stop doing that, instead using the core of workers who 
are committed to delivering that running code, to define the requirements.  The 
community then gets to review potential problems with that work. 
Pseudo-problems, such as "it should do more things" and "I can't give you any 
specifics, but there might be problems" are out of bounds.


d/
--

Dave Crocker
Brandenburg InternetWorking


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

informal survey

[Carl Malamud]

Hi -

I'm conducting an informal, non-scientific survey with the aim of trying
to understand within an order of magnitude how much it costs folks to
contribute to open source software.

If any of you have 30 seconds and feel like answering 3 questions, please
mail your responses back to me.  Please do NOT send your responses to
the entire list.

Questions:

1. What country do you live in?

2. Did you contribute time to any open source development efforts in
   2005? (*)

3. If the answer to 2 is yes, how much would you estimate your
   out-of-pocket costs were in 2005? (**)

 * Where "contribute" and "open source" are defined any way you 
   feel is appropriate.  
** Out-of-pocket costs are direct personal expenditures not
   reiumbursed by your employer.  Your time is worth nothing
   for purposes of this calculation.  Examples of costs might 
   be web hosting, computers, or directly related travel.

Thanks!

Carl

P.S. Privacy policy: I will not put your name on a mailing list
or in any other way release your name or email address.  Any 
results released will be aggregated over the entire survey
population.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Working Group chartering

[Andy Bierman]

Burger, Eric wrote:


IMHO, *way* too many I*E*TF work groups get chartered based on an idea.
We then spend tons of resources on figuring out if the idea will work.
We produce lots of half-baked documents with little basis in working
code.  Then folks try implementing what's been spec'ed, find it doesn't
work, but then find a ton of resistance to change, because the specs are
three years old and "we don't want to break draft-mumble-05
implementations."
 



I completely agree with you.
I wonder if we are in the minority opinion?
Standardize stuff that already works -- what a concept.

When we see a proposal without any "running code"
to back it up, we should be asking:
"If this is so good, then why aren't you using it yourself?"


If something is an idea, let's make it politically acceptable for the
"work" to be done in the I*R*TF first.

 



I don't care how the technology gets developed.
IRTF, vendors, universities, whatever.  Show us
running code that's reasonably close to what you
want to standardize.  Let's get feedback from people who
have used the technology, too.



Yes, I agree that the process should be fuzzy - the AD should be able to
figure out if something is likely to work in the real world.  However,
building a work group out of an idea, rather than somewhat working code
or a demonstration framework, should be the exception, rather than the
rule. 
 



Agreed, but I'm no fan of more process rules.
Area Directors who want to produce successful standards
will know how to make this decision.  ADs have to be tough
enough to say "Come back when you've done more work."


Andy


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Dave Crocker
Sent: Tuesday, January 03, 2006 1:13 PM
To: Jeffrey Hutzelman
Cc: ietf@ietf.org
Subject: Working Group chartering

[snip]

And here is where we have the major disconnect.

Working groups start from a wide variety of places.  Some start with an
idea.  Some with a detailed proposal.  Some with a detailed
specification and some with existing and deployed technology.  When a
working group starts, it must make the strategic decision about how much
prior work to preserve, versus how much new work to encourage or
require.
[snip]

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


 




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Binary Choices?

[Gray, Eric]

Ted,

I think we disagree on fine points and agree on the bigger
points.

As Melinda Shore aptly put it ('objection to proposed change 
to "consensus"' on Saturday, 1/7/2006, at 10:15 AM Eastern Time):

'Consensus process leads to decisions being made through synthesis 
 and restatement, and by the time that the question is asked "Do we 
 have consensus?" we should pretty much have consensus already.' 

While the point at which a question can be asked that is likely to
engender consensus is not always going to be quite this binary, it
is often the case that people will not try to 'call' for consensus
until there are no more than three choices - and usually it will be
when there are no more than two.

--
Eric

--> -Original Message-
--> From: Theodore Ts'o [mailto:[EMAIL PROTECTED] 
--> Sent: Monday, January 09, 2006 10:43 PM
--> To: Gray, Eric
--> Cc: 'Sam Hartman'; Sandy Wills; IETF General Discussion Mailing List
--> Subject: Re: Binary Choices?
--> 
--> On Mon, Jan 09, 2006 at 12:57:56PM -0500, Gray, Eric wrote:
--> > 
--> > Usually, before you can actually seek consensus, you must have an
--> > essentially "binary" choice.  It is hard enough to reach consensus
--> > on simple choices without turning up the process noise by having a
--> > plethora of possible choices.
--> > 
--> 
--> I disagree here.  The process of seeking consensus means you have to
--> sort *through* the plethora of possible choices, and see which ones
--> meets the needs and requirements of the stakeholder.  If you have a
--> binary choice, all you can really do is force a vote.  So 
--> hopefully by
--> the time that you come up to your last two choices, they hopefully
--> aren't "binary" in the sense of 0 and 1 being diametric opposites.
--> Hopefully the two or three final choices are pretty closely 
--> except for
--> a few minor details (and then we end up spending huge amount of time
--> arguing over those tiny details :-)
--> 
--> - Ted
--> 

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Normative figures

[Stephane Bortzmeyer]

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. The cost to router A is 6,
> and the cost to router C is 10. Router C connects to router D. The
> cost to router B is 9 and the cost to router D is 8. The cost from
> router D to router A is 16 and the cost to router A is 99.

Here is the Graphviz code, to compare (I also attached the
automatically produced PNG but Graphviz can make PDF or SVG as well):

// See http://www1.ietf.org/mail-archive/web/ietf/current/msg39858.html

digraph bryantnetwork {
  
  label = "Stewart Bryant's network";
 
 // Routers
 node [shape=box, fontsize=15];

 // Links
 edge [len=2.0];
A -> B [label="2"];
A -> D [label="4"];
B -> A [label="6"];
B -> C [label="10"];
C -> B [label="9"];
C -> D [label="8"];
D -> A [label="16"];
D -> C [label="99"];

}


bryant.png
Description: PNG image
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Alternative formats for IDs

[Brian Rosen]

You mean, like xml?


-Original Message-
From: Brian E Carpenter [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 10, 2006 8:53 AM
To: [EMAIL PROTECTED]
Cc: ietf@ietf.org
Subject: Re: Alternative formats for IDs

...
> What we are seeing is increasing use of fully automated tools that don't
> have humans identifying which octets are MIB and which are code.  You
can't
> do that with plain ASCII.

You can do that with meta-data encoded in plain ASCII. In fact, that
would work better for automated extraction than anything visual such as
using multiple fonts.

...

 Brian




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Alternative formats for IDs

[Brian Rosen]

Ted

You are arguing that we have been producing documents for a long time with
only primitive tools and we don't need to make any new tools.  You are
losing that argument.   We are increasing the number, and usefulness of
tools, and most of us appreciate these tools and want more of them.  The
range of useful tools we can produce is related to how much meta-data we put
in the source files.  The more meta-data we put in, the more usefulness we
can get out of the data.  There is very little downside to adding meta-data
as long as it's easy to put in.  For most of these things, we have to do
special formatting, so we are already marking the octets in some way.  

Do you have any idea how painful it is to build any kind of product that has
good management simply because there is no library of MIBs, with references
to documents?  There isn't even a LIST of IETF MIBs.  You can't figure out
if a document has a MIB unless you actually look at the text (although many
have a big hint in the title of the document).  So yes, I believe better MIB
tools would lead to better products, although it would be hard to prove it.

I would like to enable automated testing of ABNF.  I'd like to be able to
cross check the ABNF from one document against its normative references to
see what changes or conflicts.  I'd like to be able to generate a complete
list of SIP error messages a UA may be expected to encounter.  I'd like to
see a lot more hyperlinking of things.  All of these are much easier with
meta-data.

Brian


-Original Message-
From: Theodore Ts'o [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 10, 2006 8:58 AM
To: Brian Rosen
Cc: [EMAIL PROTECTED]; 'John C Klensin'; 'Marshall Eubanks'; ietf@ietf.org
Subject: Re: Alternative formats for IDs

On Tue, Jan 10, 2006 at 08:09:10AM -0500, Brian Rosen wrote:
> It's trivial for a human, but not for a computer.
> Many things trivial for humans are not trivial for computers.
> 
> The kind of harvesting you are talking about is trivial for a human from
any
> format as long as your editor can paste while losing formatting.
> 
> What we are seeing is increasing use of fully automated tools that don't
> have humans identifying which octets are MIB and which are code.  You
can't
> do that with plain ASCII.

True.  So what?  Do you think that it is possible, or even a good
idea, that tools be able to rip out a MIB without reading the rest of
the text?  If so, why the heck do we spend so much time working on a
the human-readable sections, like Security Considerations?

And how much time does it really save to have an automated tool pull
out the MIB, instead of having a human do it?  And what percentage of
the effort does that represent out of the effort to create a product,
anyway?  0.0001%   0.1%?   

I can usually do it in under a minute with some emacs macros, but I'm
willing to admit that I may be a bit better at it than others.  Other
people could probably do it in a few minutes using sed and awk, or
even (gasp) perl.

- Ted



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Alternative formats for IDs

[Brian E Carpenter]

...

What we are seeing is increasing use of fully automated tools that don't
have humans identifying which octets are MIB and which are code.  You can't
do that with plain ASCII.


You can do that with meta-data encoded in plain ASCII. In fact, that
would work better for automated extraction than anything visual such as
using multiple fonts.

...

Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Normative figures

[Brian E Carpenter]

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 complex than
these examples.  The only significant exception I can think of is the
NTP spec.


RFC 3247 is quite tricky too.



People who REALLY use equations generally prefer LaTeX.



Yes, and if the equations are informative that's fine; they can publish
where they want to. But we have a genuine issue when equations
are both normative and complicated.

Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Alternative formats for IDs

[Theodore Ts'o]

On Tue, Jan 10, 2006 at 08:09:10AM -0500, Brian Rosen wrote:
> It's trivial for a human, but not for a computer.
> Many things trivial for humans are not trivial for computers.
> 
> The kind of harvesting you are talking about is trivial for a human from any
> format as long as your editor can paste while losing formatting.
> 
> What we are seeing is increasing use of fully automated tools that don't
> have humans identifying which octets are MIB and which are code.  You can't
> do that with plain ASCII.

True.  So what?  Do you think that it is possible, or even a good
idea, that tools be able to rip out a MIB without reading the rest of
the text?  If so, why the heck do we spend so much time working on a
the human-readable sections, like Security Considerations?

And how much time does it really save to have an automated tool pull
out the MIB, instead of having a human do it?  And what percentage of
the effort does that represent out of the effort to create a product,
anyway?  0.0001%   0.1%?   

I can usually do it in under a minute with some emacs macros, but I'm
willing to admit that I may be a bit better at it than others.  Other
people could probably do it in a few minutes using sed and awk, or
even (gasp) perl.

- Ted

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Alternative formats for IDs

[David B Harrington]

Hi,

> What we are seeing is increasing use of fully automated tools 
> that don't
> have humans identifying which octets are MIB and which are 
> code.  You can't
> do that with plain ASCII.

MIB modules may be a bad example for you to use. All MIB modules start
with a BEGIN character string and end with an END character string.
Plain ASCII works perfectly well for this purpose. Binary formatted
documents, such as MS-Word and PDF, require much more work from the
tools  to find those BEGIN and END statements.

David Harrington
[EMAIL PROTECTED]

> -Original Message-
> From: Brian Rosen [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, January 10, 2006 8:09 AM
> To: 'Theodore Ts'o'
> Cc: [EMAIL PROTECTED]; 'John C Klensin'; 'Marshall 
> Eubanks'; ietf@ietf.org
> Subject: RE: Alternative formats for IDs
> 
> It's trivial for a human, but not for a computer.
> Many things trivial for humans are not trivial for computers.
> 
> The kind of harvesting you are talking about is trivial for a 
> human from any
> format as long as your editor can paste while losing formatting.
> 
> What we are seeing is increasing use of fully automated tools 
> that don't
> have humans identifying which octets are MIB and which are 
> code.  You can't
> do that with plain ASCII.
> 
> Your statement that the IETF is getting populated with people 
> who don't code
> is true.  It's a fact, and we need to adapt.  Most (but not 
> all) of the
> people who design protocols these days don't code; they have 
> people who work
> with them who do.  Part of that is unavoidable.  The part I 
> regret, which
> could be avoided, is the loss of "running code" that we used 
> to care about.
> Another thread.
> 
> Brian
> 
> -Original Message-
> From: Theodore Ts'o [mailto:[EMAIL PROTECTED] 
> Sent: Monday, January 09, 2006 11:37 PM
> To: Brian Rosen
> Cc: [EMAIL PROTECTED]; 'John C Klensin'; 'Marshall 
> Eubanks'; ietf@ietf.org
> Subject: Re: Alternative formats for IDs
> 
> On Sat, Jan 07, 2006 at 03:18:08PM -0500, Brian Rosen wrote:
> > Any format can be used for any purpose, but it might be 
> time to fully
> stand
> > up to requirements to harvest data, and to recognize (as I 
> did on another
> > side thread), that reading is getting harder and harder for 
> ASCII.  It may
> > be a decent archive format still, but I'm not sure it's 
> going to stay that
> > way.
> 
> Huh?  "Harvesting data" from ASCII, in terms of pulling out MIB's to
> be fed into MIB compiler, or reference C code for algorithms like
MD5
> (RFC 1321) is *trivial* under ASCII.  Last I checked, C compilers
and
> MIB compilers still use ASCII text as input, and not Word documents
or
> XML documents.  Maybe part of what is going on is that IETF is
getting
> populated with people who aren't close to coding as much as before?
> You can get perfectly decent text editors for all operating systems,
> even Windows.
> 
> And even Word can import text (i.e., plain ASCII) documents Just
Fine.
> 
>   - Ted
> 
> 
> 



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Alternative formats for IDs

[Brian Rosen]

It's trivial for a human, but not for a computer.
Many things trivial for humans are not trivial for computers.

The kind of harvesting you are talking about is trivial for a human from any
format as long as your editor can paste while losing formatting.

What we are seeing is increasing use of fully automated tools that don't
have humans identifying which octets are MIB and which are code.  You can't
do that with plain ASCII.

Your statement that the IETF is getting populated with people who don't code
is true.  It's a fact, and we need to adapt.  Most (but not all) of the
people who design protocols these days don't code; they have people who work
with them who do.  Part of that is unavoidable.  The part I regret, which
could be avoided, is the loss of "running code" that we used to care about.
Another thread.

Brian

-Original Message-
From: Theodore Ts'o [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 09, 2006 11:37 PM
To: Brian Rosen
Cc: [EMAIL PROTECTED]; 'John C Klensin'; 'Marshall Eubanks'; ietf@ietf.org
Subject: Re: Alternative formats for IDs

On Sat, Jan 07, 2006 at 03:18:08PM -0500, Brian Rosen wrote:
> Any format can be used for any purpose, but it might be time to fully
stand
> up to requirements to harvest data, and to recognize (as I did on another
> side thread), that reading is getting harder and harder for ASCII.  It may
> be a decent archive format still, but I'm not sure it's going to stay that
> way.

Huh?  "Harvesting data" from ASCII, in terms of pulling out MIB's to
be fed into MIB compiler, or reference C code for algorithms like MD5
(RFC 1321) is *trivial* under ASCII.  Last I checked, C compilers and
MIB compilers still use ASCII text as input, and not Word documents or
XML documents.  Maybe part of what is going on is that IETF is getting
populated with people who aren't close to coding as much as before?
You can get perfectly decent text editors for all operating systems,
even Windows.

And even Word can import text (i.e., plain ASCII) documents Just Fine.

- Ted



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Normative figures

[Stephane Bortzmeyer]

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 either with
unstructured ASCII art. To do so, you would need a formal graph
language (like Graphviz I mentioned before and even Graphviz is too
low-level, too drawing-oriented to do so).

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: Normative figures

[Stephane Bortzmeyer]

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 therefore does not need to be normative, like, say, a state
diagram), graph people produced several languages which are
non-ambiguous, expressed as ASCII and produce nice output. Some even
are free (as in free speech and as in free beer). (Unfortunately, none
is "standard" in any way, AFAIK.)

The one I recommend is Graphviz
(http://www.research.att.com/sw/tools/graphviz/). An example of
Graphviz code for a real network:

http://www.seekingfire.com/projects/metanetwork/maps/meta.dot

(See http://www.seekingfire.com/projects/metanetwork/info.html for the
context)

See also:

"Managing IP Networks with Free Software"
http://www.nanog.org/mtg-0210/ppt/stephen.pdf has a chapter about
Graphviz

"A Systematic Approach to BGP Configuration Checking"
http://www.nanog.org/mtg-0310/pdf/feamster.pdf uses cflow to produce
Graphviz ".dot" files.

(ACL compilers like Netspoc http://netspoc.berlios.de/ also have an
ASCII language to represent networks.)

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf