Re: Normative figures
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
Re: Normative figures
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: 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
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
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: Normative figures
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
... 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. code.../code Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
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
sorry, couldn't help it 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. code.../code Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Normative figures
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: Binary Choices?
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: Working Group chartering
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
informal survey
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
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 http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 url. 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
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 http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Normative figures
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: Normative figures
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: 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
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
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: Working Group chartering
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 x; 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: Trying to invent a way of determining consensus
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
Accessibility of Documents
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: Normative 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 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
Re: Accessibility of Documents (veering off-topic)
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: IMG SRC=data:image/gif;base64,R0lGODdhMAAwAPAAAP///ywAMAAw AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH hhx4dbgYKAAA7 ALT=Larry 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: 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 stupid thing, 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: Normative figures
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... g 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: Accessibility of Documents (veering off-topic)
--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: Accessibility of Documents (veering off-topic)
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: Alternative formats for IDs
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 artwork type=abnf if the source asks for strict processing. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Alternative formats for IDs
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 url. 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: Accessibility of Documents (veering off-topic)
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
Last Call: 'Media Type Registration for SMPTE Material Exchange Format (MXF)' to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Media Type Registration for SMPTE Material Exchange Format (MXF) ' draft-edwards-mime-mxf-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-02-07. The file can be obtained via http://www.ietf.org/internet-drafts/draft-edwards-mime-mxf-01.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Detecting MPLS Data Plane Failures' to Proposed Standard
The IESG has approved the following document: - 'Detecting MPLS Data Plane Failures ' draft-ietf-mpls-lsp-ping-13.txt as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alex Zinin and Bill Fenner. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-13.txt Technical Summary This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS echo request and echo reply for the purposes of fault detection and isolation; and mechanisms for reliably sending the echo reply. Working Group Summary The WG had consensus on progressing this document. Protocol Quality The document has been reviewed by Ross Callon, and Russ White for Routing area directorate, and by Alex Zinin for the IESG. RFC Editor Note: Section 1.1 Conventions [Add new paragraph at end] Since this document refers to the MPLS TTL far more frequently than the IP TTL, the authors have chosen the convention of using the unqualified TTL to mean MPLS TTL and using IP TTL for the TTL value in the IP header. In section: 6. Security OLD: Although this document makes special use of 127/8 address, these are used only in conjunction with the UDP port 3503. Further these packets are only processed by routers. All other hosts MUST treat all with a destination address in the range 127/8 in accordance to RFC1122. Any packet received by a router with a destination address in the range 127/8 without a destination UDP port of 3503 MUST be treated in accordance to RFC1812. NEW: Although this document makes special use of 127/8 address, these are used only in conjunction with the UDP port 3503. Further these packets are only processed by routers. All other hosts MUST treat all packets with a destination address in the range 127/8 in accordance to RFC1122. Any packet received by a router with a destination address in the range 127/8 without a destination UDP port of 3503 MUST be treated in accordance to RFC1812. In particular, the default behavior is to treat packets destined to a 127/8 address as martians. Section 2.1., para. 9: OLD: The 127/8 range for IPv4 and that same range embedded in an IPv6 addresses for IPv6 was chosen for a number of reasons. NEW: The 127/8 range for IPv4 and that same range embedded in as IPv4-mapped IPv6 addresses for IPv6 was chosen for a number of reasons. Section 3.3., para. 26: OLD: Key Type Multipath Information --- - 0no multipath Empty (Multipath Length = 0) 2IP addressIP addresses 4IP address range low/high address pairs 8Bit-masked IPv4 IP address prefix and bit mask address set 9Bit-masked label set Label prefix and bit mask NEW: Key Type Multipath Information --- - 0no multipath Empty (Multipath Length = 0) 2IP addressIP addresses 4IP address range low/high address pairs 8Bit-masked IP IP address prefix and bit mask address set 9Bit-masked label set Label prefix and bit mask Section 3.3.1., para. 1: OLD: The multipath information encodes labels or addresses which will exercise this path. The multipath information depends on the multi- path type. The contents of the field are shown in the table above. IP addresses are drawn from the range 127/8. Labels are treated as numbers, i.e. they are right justified in the field. For Type 4, ranges indicated by Address pairs MUST NOT overlap and MUST be in ascending sequence. NEW: The multipath information encodes labels or addresses which will exercise this path. The multipath information depends on the multi- path type. The contents of the field are shown in the table above. IPv4 addresses are drawn from the range 127/8; IPv6 addresses are drawn from the range 0:0:0:0:0::127/104. Labels are treated as numbers, i.e. they are right justified in the field. For Type 4, ranges indicated by Address pairs MUST NOT overlap and MUST be in ascending sequence. Section 3.3.1., para. 2: OLD: Type 8 allows a denser encoding of IP address. The IPv4 prefix is formatted as a base IPv4 address with the non-prefix low order bits set to zero. The maximum prefix length is 27. Following the prefix is a mask of length 2^(32-prefix length) bits. Each bit set to one represents a valid address. The address is the base
