Re: Trying to invent a way of determining consensus
... Anyone who agrees with the CfC statement, and doesn't say anything, is fine, because the CfC doesn't need or want their support. The CfC will stand or fall based upon the size of the disagree and replied group. That's pretty much how I've seen IETF consensus work over the years. As Harald said, a straw poll can be very handy in getting an idea how things are stacking up in the discussion, but the ultimate test is whether the residual dissent at the end of the conversation is important enough to matter. And that is the judgement that the IETF process leaves to the deciders (WG Chairs or IESG in most cases) following a Last Call message. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Binary Choices?
Sandy == Sandy Wills [EMAIL PROTECTED] writes: Sandy Gray, Eric wrote: It is useful sometimes to differentiate those who have no stake in a particular issue from those who are not paying attention. Sandy (rest of post snipped) Sandy Here I must become two-faced. Sandy Personally, I agree with you. Often, there are many Sandy shades of grey between the white and black binary choices. Sandy Often, being able to communicate those shades of grey will Sandy be essential to creating a usable compromise. Agreed. Sandy Unfortunately, there seems to be a religious dogma Sandy among the long-time IETF participants that they never take Sandy votes. All they do is judge rough or smooth concensus, and Sandy that reduces our options to simple binary choices. I'm very confused here; as far as I can tell judging consensus works much better with things in the middle than any sort of votes. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
Sandy == Sandy Wills [EMAIL PROTECTED] writes: Sandy Brian Rosen wrote (about the format issue): It's probably true that we can push this problem off another year, but maybe not, and definitely not for very much longer. Sandy I think that everyone here is aware of that, which is why Sandy we keep coming back to it, and will continue to until the Sandy agents of change win. I've only been following the IETF Sandy for a couple of years now, but this discussion seems to Sandy come closer to adopting a change every time I see it. And that's what we call building consensus. It how we conduct our business and while for things like this it is conservative, it does move. I do think that if the proponents pull together an experiment, we may find that within two years, we have a proposal that can get consensus. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Normative figures
Stewart == Stewart Bryant [EMAIL PROTECTED] writes: Stewart I am in favour of any practical method that allows us to Stewart progress towards the best tools for the job. Stewart My personal end-goal is simple: I want us to be able to Stewart use modern graphical techniques in normative text to help Stewart me to describe problems and their solutions. There are Stewart many other nice-to-have's, but at the end of the day it Stewart is the diagrams that are the key missing feature in our Stewart document process. Are you looking for normative figures? If so, can you point to an example where you think they are necessary? (I'd like to avoid a discussion of packet diagrams for the moment if that's OK) Or are you looking at normative text that is easier to understand with illustrative figures? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Normative figures
On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote: Are you looking for normative figures? If so, can you point to an example where you think they are necessary? (I'd like to avoid a discussion of packet diagrams for the moment if that's OK) Normative figures perhaps. Normative equations definitely. Is there any input format for *just* equations (or figures), standing by themselves, which we can agree is open, standardized, stable and deterministic in output? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Normative figures
Scott == Scott W Brim sbrim@cisco.com writes: Scott On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote: Are you looking for normative figures? If so, can you point to an example where you think they are necessary? (I'd like to avoid a discussion of packet diagrams for the moment if that's OK) Scott Normative figures perhaps. Normative equations definitely. Scott Is there any input format for *just* equations (or Scott figures), standing by themselves, which we can agree is Scott open, standardized, stable and deterministic in output? Mmm. I have some significant accessibility concerns with that if you expect me to review the documents. I think that's a small (although probably impossible at the current point) matter of technology. If you go so far as normative figures I have a lot more questions about why and what you are trying to accomplish. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
Sandy == Sandy Wills [EMAIL PROTECTED] writes: Sandy Gray, Eric wrote: Sandy, In fact, contrary to what we observe in nature, change is not the default outcome in most human organizations. That is because - as a careful analysis of this discussion over the years will disclose - there are as many ways to go with a change as there are people prepared to make changes. Sandy I think that there is also a very strong element of Sandy emotional attachment to any system or solution, from those Sandy people who had a hand in creating it (Certainly, I'm just Sandy as guilty of this as the next guy!). Any job is harder if Sandy you have to change your tools every time you get used to Sandy them. I think that's a valuable thing to consider in consensus building. This makes me retool how I do things; it works well today, is actually a valid input to a discussion. Sandy It's also true that some people will object to Sandy anything in front of them, simply because it was done by Sandy someone else. I'm having a hard time arguing that this is a good thing. Sandy We also have the religious responses, both Sandy pro and con, where someone either approves (or disapproves) Sandy of it simply because of the source. We've all seen It's Sandy gotta be good, Jon Postel wrote it, as well as I'll cut Sandy my wrists before I use MS software 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. Note that related to religious arguments may be more practical issues as well. Sandy It appears that, if we want to judge solution-quality Sandy by mob volume, we need to find some way to separate the Sandy emotional responses from the reasoned responses. I disagree that discarding the emotional responses is appropriate. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Accessibility issues affecting IETF document format choices
Mmm. I have some significant accessibility concerns with that if you expect me to review the documents. I think that's a small (although probably impossible at the current point) matter of technology. Sam, Thank you for raising this basic point. Since the IETF seeks the widest possible availability for its documents, it might help discussion about format choices to understand how your ability to review documents is affected. For starters, what sorts of things about the *current* IETF document format make your reviewing easier or more difficult? (Given the discussion that triggered this note, specific comments on figures and formulas would be helpful. I will add my own curiosity about the extent to which punctuation choices aid or hinder review.) d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Accessibility issues affecting IETF document format choices
Dave == Dave Crocker [EMAIL PROTECTED] writes: Mmm. I have some significant accessibility concerns with that if you expect me to review the documents. I think that's a small (although probably impossible at the current point) matter of technology. Dave Sam, Dave Thank you for raising this basic point. Since the IETF Dave seeks the widest possible availability for its documents, it Dave might help discussion about format choices to understand how Dave your ability to review documents is affected. Hi. I was actually not trying to raise the general issue of how accessible the IETF should make its documents. I was simply trying to raise the practical issue that while I'm on the IESG, I will hold a discuss if I cannot understand some aspect of a document well enough to review it. It's not trying to make a political statement, just that I've been asked to do a job by the nomcom and I will try and do that job. Naturally should I hold such a discuss I'd work with the authors to try and figure out enough detail to quickly understand their document. I think the general issue is important but should be examined in the broader context of the document format issue. However I'd like to wait and see if we're going to actually do anything about the broader issue before spending cycles on this question. I proposed a specific set of steps that the proponents could take to conduct an experiment; so far no one has disagreed with that proposal. So let's see if it looks like people are going to try that approach. If so, I agree this would be an important thing to at least start thinking about. It may well not matter for the experiment, but it may matter long-term. If anyone wants to chat about document accessibility in person I'd be happy to do so. I just would rather not get into a long email discussion right now. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Normative figures
In message [EMAIL PROTECTED], Scott W Brim writes: On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote: Are you looking for normative figures? If so, can you point to an example where you think they are necessary? (I'd like to avoid a discussion of packet diagrams for the moment if that's OK) Normative figures perhaps. Normative equations definitely. Is there any input format for *just* equations (or figures), standing by themselves, which we can agree is open, standardized, stable and deterministic in output? LaTeX is the standard in the math and theory world. It's free, and runs on just about everything. If I recall correctly what Kernighan once said, eqn was designed so that its input language was more or less what one mathematician would say to another over the phone, which (I assume) would help with accessibility. There are open source versions of eqn; I think that they run on more or less anything, too. In the pure HTML world, there's MathML, though it's *really* ugly to read. I have no idea how much it's supported by today's browsers. (Kernighan started working on an eqn to HTML translator some years ago, but back then no browser really worked properly for it.) Note that I'm *not* saying we should adopt any of these for RFCs; I'm simply saying that there are some well-known systems that satisfy at least your four criteria. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Binary Choices?
Sam/Sandy, See below... -- Eric --- [SNIP] --- -- Sandy Unfortunately, there seems to be a religious dogma -- Sandy among the long-time IETF participants that they never take -- Sandy votes. All they do is judge rough or smooth concensus, and -- Sandy that reduces our options to simple binary choices. -- -- I'm very confused here; as far as I can tell judging consensus works -- much better with things in the middle than any sort of votes. Ultimately, you're both right. 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. However, the process of seeking consensus does tend to solicit the reasons and feelings involved in making choices and this can lead to solution searches in the gray-areas between proposals. -- -- --Sam -- -- -- ___ -- 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: objection to proposed change to consensus
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. Sam I disagree that the use of diagrams is a religious issue. Diagrams are a very simple way to put specification and context together in a compact notation such that it is easy to move from key point to key point in a non-linear way. They provide visual hyperlinking. Here is a good way to judge the value of a diagram: Look at a diagram presented in an IETF WG session and ask the questions : does this diagram make the draft easier to understand? If the answer is yes, then the diagram should probably be in the draft. The problem is that it is frequently impossible to translate the clarity of the graphics used in the presentation to the technology of ASCII art. - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Normative figures
* * 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. People who REALLY use equations generally prefer LaTeX. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Normative figures
Hi. With the exception of packet diagrams, I think all the examples you bring up benefit significantly from clear textual description. I believe I'd think that even if I could see the diagrams and I believe I have enough experience with visualization (although not sight) to be confident in that belief. As such, I don't believe these diagrams should be normative. I actually thin that many of the tunnel overlay network documents (PWE3, L2VPN, L3VPN) could benefit significantly from more focus on the text of the descriptions of situations being described. If you believe that normative documents are required, I'd like you to explain why the diagrams cannot be described in the text, why doing so would decrease the quality of the specification, or why doing so would not be a useful investment in our time. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
--On Monday, 09 January, 2006 18:17 + Stewart Bryant [EMAIL PROTECTED] wrote: 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. I disagree that the use of diagrams is a religious issue. Diagrams are a very simple way to put specification and context together in a compact notation such that it is easy to move from key point to key point in a non-linear way. They provide visual hyperlinking. Stewart, While I agree that diagrams are not simply a religious issue, I think that there are many cases in which the use of diagrams, especially complex ones, leaves people with the impression that they have understood something when, in fact, they do not. Ed Tufte's work, among many others, has provided repeated graphical, and often humorous, illustrations of that point. Part of that issue overlaps the resistance to WG sessions that are dominated by PowerPoint presentations every time that discussion breaks out, although some of that discussion is driven by what are clearly religious issues. This brings us back to one on the early comments in these threads -- that the need to describe a complex concept in text or in ASCII art imposes a discipline that is actually quite useful. I agree with you that there are some things that cannot be thus described with a sensible amount of effort, but it has seemed to me that it would be helpful, from a document quality standpoint, to examine each case and to try to strive for the minimum diagram complexity that is actually necessary. I get even more concerned when it is suggested that not only are diagrams are needed, but that color documents may be needed. While things are easier than they were a decade or two ago, the need to transmit and render color images imposes costs in both printing facilities and transmission sizes of documents that I, at least, would prefer to avoid unless necessity can be demonstrated. Sam can, and I hope will, speak for himself, but my experience working with programmers with visual difficulties some years ago suggests that while monochrome line art --whether conveniently expressible in ASCII or not-- can often be made comprehensible with sufficient effort, either continuous-tone materials or line-art drawings that depend on color are fairly close to impossible. Here is a good way to judge the value of a diagram: Look at a diagram presented in an IETF WG session and ask the questions : does this diagram make the draft easier to understand? If the answer is yes, then the diagram should probably be in the draft. I think that criterion leads down a slippery slope toward documents that are collections of PowerPoint images. The understanding of a document in a WG session can be improved by an oral presentation with selected bullet points on slides, too, but that doesn't automatically make the case that either that the bullet points ought to be precisely the section headings of the document or that the slides should be included with the text. The problem is that it is frequently impossible to translate the clarity of the graphics used in the presentation to the technology of ASCII art. Assuming we agree on that, can we figure out some criteria or guidelines for keeping graphics to the minimum complexity needed to express ideas, for being sure that graphics are accompanied by good explanations whenever possible, and generally for preventing people from going hog-wild with complex colored illustrations? It seems to me that, if possible, we also need to find ways to be sure that any normative graphics that appear in I-Ds can be edited with tools that are easily accessible on all relevant platforms. Most of the above of course are probably best taken as input to, or evaluation criteria for, precisely the sort of experiment that Sam suggests. john ___ 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. People who REALLY use equations generally prefer LaTeX. Bob Braden The draft has expired so I need to point to an external version. This draft which is looking at the properties of a routing network under conditions of failure would have been much clearer if it could have used mathematical notation rather than ASCIIised equations http://www.faqs.org/ftp/pub/internet-drafts/draft-atlas-ip-local-protect-uturn-02.txt Of course the diagrams could have also been clearer, as is seen by comparing them to the ones that Alia used in her presentatons on the subject. - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
On 01/09/2006 14:02 PM, John C Klensin allegedly wrote: While I agree that diagrams are not simply a religious issue, I think that there are many cases in which the use of diagrams, especially complex ones, leaves people with the impression that they have understood something when, in fact, they do not. the need to describe a complex concept in text or in ASCII art imposes a discipline that is actually quite useful. Yup, although we've seen plenty of cases where people understand text differently as well. I think I'm beginning to like TeX again. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Normative figures
Sam Hartman wrote: Hi. With the exception of packet diagrams, I think all the examples you bring up benefit significantly from clear textual description. Sam I am not saying that clear text is not needed to accompany a diagram. However a diagram allows a lot less text to be written producing a shorter clearer draft with less clutter. For example you could say the following in text : router A connects to router B and D, the cost from A to B is 2, and the cost from A to D is 4. 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. In fact you would probably need a table to make sure that you did not make a mistake. In either case it is hard for most people to figure out the what the topology is much less imagine packet actions. Now compare this to: The network and costs are as shown in figure foo. Simple text and the visualisation is already done for you so you can focus on the problem. Now I realise the above could be done in ascii art, but we have problems that need 13 or more nodes to set up. I believe I'd think that even if I could see the diagrams and I believe I have enough experience with visualization (although not sight) to be confident in that belief. As such, I don't believe these diagrams should be normative. I actually thin that many of the tunnel overlay network documents (PWE3, L2VPN, L3VPN) could benefit significantly from more focus on the text of the descriptions of situations being described. It is probably a question of how we work and the tools that we find most effective. If you believe that normative documents are required, I'd like you to explain why the diagrams cannot be described in the text, why doing so would decrease the quality of the specification, or why doing so would not be a useful investment in our time. One reason is that it takes a lot of text to describe what can be drawn with a few lines and symbols. Many people will get lost in the text and in any case would have to transcribe the text into a diagram for themselves before they could understand what is happening. - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Normative figures
Stewart, There's a joke that goes something like this: there are three kinds of people in this world - those that are good at Math and those that are not. Funny thing is that there are at least three ways in which people approach mathematical expressions: 1) Some see a nice, clean, symbolic expression and mentally reject it out of hand (for these people, a summation symbol terminates a line of readable text); 2) Some see a symbolic expression, look at it briefly and become (as one person said earlier about figures) convinced they understand it while actually they do not (this can be established by a simple search for published material in which non-sensical mathematical expressions were included without comment in peer reviews); 3) Some people see any symbolic expression and play with it until either they understand it or they know what is wrong with it. In the first two cases - in which, I think we can agree, most people would fall - it is much better to have made the effort to put the expression in plain English - however much prettier it would have been in symbolic representation. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Stewart Bryant -- Sent: Monday, January 09, 2006 2:22 PM -- To: Bob Braden -- Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; -- ietf@ietf.org; sbrim@cisco.com -- Subject: 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. -- -- People who REALLY use equations generally prefer LaTeX. -- -- Bob Braden -- -- -- -- -- The draft has expired so I need to point to an external -- version. This draft -- which is looking at the properties of a routing network -- under conditions of -- failure would have been much clearer if it could have used -- mathematical -- notation rather than ASCIIised equations -- -- http://www.faqs.org/ftp/pub/internet-drafts/draft-atlas-ip-l -- ocal-protect-uturn-02.txt -- -- Of course the diagrams could have also been clearer, as is seen by -- comparing them to the ones that Alia used in her presentatons on the -- subject. -- -- - Stewart -- -- -- ___ -- 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: Normative figures
In message [EMAIL PROTECTED], Scott W Brim writes: On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote: Are you looking for normative figures? If so, can you point to an example where you think they are necessary? (I'd like to avoid a discussion of packet diagrams for the moment if that's OK) Normative figures perhaps. Normative equations definitely. Is there any input format for *just* equations (or figures), standing by themselves, which we can agree is open, standardized, stable and deterministic in output? LaTeX is the standard in the math and theory world. It's free, and runs on just about everything. LaTeX or some other TeX variant. AMS-TeX is one such but there are a bunch of others. (Always fun when you get TeX source that uses a macro package you don't have available.) If I recall correctly what Kernighan once said, eqn was designed so that its input language was more or less what one mathematician would say to another over the phone, which (I assume) would help with accessibility. There are open source versions of eqn; I think that they run on more or less anything, too. Personally, I'm unconvinced that design goal was met. In the pure HTML world, there's MathML, though it's *really* ugly to read. I have no idea how much it's supported by today's browsers. (Kernighan started working on an eqn to HTML translator some years ago, but back then no browser really worked properly for it.) It is probably worth noting that another very popular format in the math world for equations is essentially ASCII art. This is what you tend to get as output from the various symbolic manipulation packages like Reduce, Macsyma, Maple, and last time I looked, Mathematica. Stuff like: 23 2 23 3 ww x (w k + w ) x(3 w k + w ) x (D7)/T/ -- + --- - -- - + . . . 434 3 kk 6 k 6 k is actually pretty readable. And any of these packages can be used to generate this sort of thing; no need to piddle around in an editor. (The example above is a Taylor series expansion from Maxima.) These packages often have TeX and eqn output modes as well. Another interesting development in this space is the new programming language Fortress being developed by Guy Steele, which sticks with simple character strings but uses the full UTF-8 repetoire to advantage. I personally find it hard to get used to after so many years of looking at ASCII art equations, especially when lots of matrix and vectoor stuff is involved, but this might be an interesting avenue to pursue if we ever started allowing UTF-8. See: http://research.sun.com/projects/plrg/ for additional information. Note that I'm *not* saying we should adopt any of these for RFCs; I'm simply saying that there are some well-known systems that satisfy at least your four criteria. Indeed. I will also point out that as with anything having to do with which notation is better or best, getting agreement even in the relatively narrow confines of the math community is next to impossible. You know how it is: The arguments are nasty because the stakes are so low. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Normative figures
| -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Stewart Bryant | Sent: Tuesday, January 10, 2006 6:47 AM | To: Sam Hartman | Cc: Harald Tveit Alvestrand; ietf@ietf.org | Subject: Re: Normative figures | | Sam Hartman wrote: | | Hi. With the exception of packet diagrams, I think all the | examples | you bring up benefit significantly from clear textual description. | | Sam | | I am not saying that clear text is not needed to accompany a diagram. | However a diagram allows a lot less text to be written | producing a shorter clearer draft with less clutter. SNIP Perhaps this is getting to the crux of the issues. I see the IETF documents as breaking down the problems into smaller chunks that can be dealt with one at a time and which add up to a big picture description of the whole Internet. I see each individual document as being simple within itself, limiting the context to the smallest level an issue may be dealt with. By adding more complexity to the documents I feel it is allowing more complex issues to be described in the documents but the documents then become larger, more difficult to comprehend and will be more difficult to process. Using the example you gave for routing costs, I see the description of routing cost basics or specifics as one document and the description of how they may be dealt with as another. By forcing the documents to be in a simple format, there are limitations on the complexity that may be explained in a single document, but I consider this a good thing. It forces everyone to break the problems and issues down to their lowest levels and forces simple explanations that make it easier for everyone to understand. If more complex documents with full diagramatic process flows are required, these could be books written linking a number of IETF documents together to describe a more general practical picture of their implementation. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF Meeting Survey
All: To assist the planning of future meetings, we ask you kindly to spend a minute or two responding to the on-line survey at https://www.surveymonkey.com/s.asp?u=465231656574 Even if you did not attend IETF 64 in Vancouver, we would value your responses. All responses will be treated anonymously, and a summary will be available on-line. Please respond by January 20, 2006 at the latest. Thanks, Ray Pelletier IETF Administrative Director. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Normative figures
Note that LaTeX is an input format - it will output to many output formats - even to ASCII. (And, of course, it sits on top of and drives TeX itself.) As a physicist, I have used LaTeX a lot. It has a steep learning curve - much more than with, say, html. When I did a set of conference proceedings in LaTEX - Proc. USNO Workshop on Relativistic Models for use in Space Geodesy, 1991. most of the papers went fine, a few just would not display correctly and took a lot of tweaking just to get them to look halfway right. These last took a lot of time. TeX / LaTeX is like that. So, most journals today use style sheets, such as the AMS-TEX ones, and templates, to enforce their look and feel. I suspect they have issues from time to time even with that. Oh, and if an email line begins with From and get turns into From, LaTex will turn that into upside down ?From, which you can see in the strangest places, once you know to look for it. There are a few WSIWYG editors for Tex/LaTex, but most people I know use a text editor. I certainly would not regard moving everything to LaTeX as a trivial change. Regards Marshall Eubanks On Jan 9, 2006, at 12:59 PM, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Scott W Brim writes: On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote: Are you looking for normative figures? If so, can you point to an example where you think they are necessary? (I'd like to avoid a discussion of packet diagrams for the moment if that's OK) Normative figures perhaps. Normative equations definitely. Is there any input format for *just* equations (or figures), standing by themselves, which we can agree is open, standardized, stable and deterministic in output? LaTeX is the standard in the math and theory world. It's free, and runs on just about everything. If I recall correctly what Kernighan once said, eqn was designed so that its input language was more or less what one mathematician would say to another over the phone, which (I assume) would help with accessibility. There are open source versions of eqn; I think that they run on more or less anything, too. In the pure HTML world, there's MathML, though it's *really* ugly to read. I have no idea how much it's supported by today's browsers. (Kernighan started working on an eqn to HTML translator some years ago, but back then no browser really worked properly for it.) Note that I'm *not* saying we should adopt any of these for RFCs; I'm simply saying that there are some well-known systems that satisfy at least your four criteria. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ 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: Normative figures
Stewart, You realize that the text example you gave is meaningless - without making some (potentially non-obvious) assumptions, right? -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Stewart Bryant -- Sent: Monday, January 09, 2006 2:47 PM -- To: Sam Hartman -- Cc: Harald Tveit Alvestrand; ietf@ietf.org -- Subject: Re: Normative figures -- -- Sam Hartman wrote: -- -- Hi. With the exception of packet diagrams, I think all -- the examples -- you bring up benefit significantly from clear textual description. -- -- Sam -- -- I am not saying that clear text is not needed to accompany -- a diagram. -- However a diagram allows a lot less text to be written producing a -- shorter clearer draft with less clutter. -- -- For example you could say the following in text : router A connects to -- router B and D, the cost from A to B is 2, and the cost from A to D is 4. A --(2)-- B | +---(4)-- D -- Router B connects to router C. The cost to router A is 6, and -- the cost to router C is 10. + A --(6)--+ | | | | +--(2)-- B --(10)-- C | +--(4)-- D (Assumes cost is from router B in both cases) -- Router C connects to router D. The cost to router B is 9 -- and the cost to router D is 8. + A --(6)--+ | | | | +--(2)-- B --(9)---+ | | | | +--(10)-- C | | +--(4)-- D (8)---+ (Assumes cost is from router C in both cases) -- The cost from router D to router A is 16 and ... +--+ | | | +- A --(6)--+ | | | | | | +--(2)-- B --(9)---+ | | | | | +--(16)+ +--(10)-- C | | | +--(4)-- D (8)+ -- -- ... the cost to router A is 99. ? (Assuming you meant the cost from D to C - not A) +--+ | | | +- A --(6)--+ | | | | | | +--(2)-- B --(9)---+ | | | | | +--(16)+ +--(10)-- C -+ | | | | +--(4)-- D (8)+ | | | +-(99)+ (Figure foo?) -- -- In fact you would probably need a table to make sure that -- you did not make a mistake. In either case it is hard for -- most people to figure out the what the topology is much -- less imagine packet actions. Actually, you need a figure to make sure that you did not make a mistake, and a second set of eyes to compare what you said to what you apparently meant. -- -- Now compare this to: -- -- The network and costs are as shown in figure foo. -- Is the above actually figure foo? The reality is that it would be better to break it this way: In the network in figure foo, the link costs are as follows: A - B = 2 B - A = 6 +- A B -+ A - D = 4 || D - A = 16 +- D C -+ B - C = 10 C - B = 9 Figure foo C - D = 8 D - C = 99 -- Simple text and the visualisation is already done for you -- so you can focus on the problem. -- The reality is that putting things entirely in pictures means that less validation of the intent of the picture is possible. Keeping pictures as simple as possible is, therefore, a goal since it is far easier to make mistakes in complex figures and far more difficult to determine that a mistake has been made. Using a mixture of text and figure(s), tables or - possibly - equations makes it both more understandable and easier to be certain of conveying the idea(s). For example, in the above, I could verify that I understand your intent by asking: From this it is apparent that the link cost (D-C) is 99, but the actual minimum cost of getting from D to C given by the formula: (D-A) + (A-B) + (B-C) = 16 + 2 + 10 = 28 Is that correct? If we choose to use a simple combination of representations, rather than strictly expecting a figure to explain it all, the figure is likely to be far simpler. For example, using an approach similar to the above, you could probably describe a much more complex network than 13, or 20 or maybe even 30 nodes using ASCII art. The purpose of the picture is to be a simplified referent. -- -- Now I realise the above could be done in ascii art, but we -- have problems that need 13 or more nodes to set up. -- -- I believe I'd think that even if I could see the diagrams -- and I believe I have enough experience with visualization -- (although not sight) to be confident in that belief. -- -- -- -- As such, I don't believe these diagrams should be normative. -- -- -- I actually thin that many of the tunnel overlay network documents -- (PWE3, L2VPN, L3VPN) could benefit significantly from more focus on -- the text of the descriptions of situations being described. -- --
Re: Normative figures
Dassa wrote: | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Stewart Bryant | Sent: Tuesday, January 10, 2006 6:47 AM | To: Sam Hartman | Cc: Harald Tveit Alvestrand; ietf@ietf.org | Subject: Re: Normative figures | | Sam Hartman wrote: | | Hi. With the exception of packet diagrams, I think all the | examples | you bring up benefit significantly from clear textual description. | | Sam | | I am not saying that clear text is not needed to accompany a diagram. | However a diagram allows a lot less text to be written | producing a shorter clearer draft with less clutter. SNIP Perhaps this is getting to the crux of the issues. I see the IETF documents as breaking down the problems into smaller chunks that can be dealt with one at a time and which add up to a big picture description of the whole Internet. I see each individual document as being simple within itself, limiting the context to the smallest level an issue may be dealt with. By adding more complexity to the documents I feel it is allowing more complex issues to be described in the documents but the documents then become larger, more difficult to comprehend and will be more difficult to process. Using the example you gave for routing costs, I see the description of routing cost basics or specifics as one document and the description of how they may be dealt with as another. By forcing the documents to be in a simple format, there are limitations on the complexity that may be explained in a single document, but I consider this a good thing. It forces everyone to break the problems and issues down to their lowest levels and forces simple explanations that make it easier for everyone to understand. That does not work if you need the costs to set up a scenario that you are about to describe the solution to. If more complex documents with full diagramatic process flows are required, these could be books written linking a number of IETF documents together to describe a more general practical picture of their implementation. It may not be possible to do that. It depends on what we are describing. - Stewart Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Normative figures
Eric You are missing the point. I was picking an example out of thin air, but it is the type of construct that we use all the time in fast-reroute. The example was four routers connected together in a square with some randomly chosen asymetric costs. Such a network is trivial, but FRR need to cope with arbitary network fragments with arbitary costs, so there are lots of fragments that we have created for study the properties of. One of the ways to operate on the fragment is to draw it and then to figure out the packet flows, consequences of failure etc etc. Now the question is why should the examples in our drafts be forced by our ability to describe them, rather than being the example that most clearly illustrates the problem and its solution? - Stewart Gray, Eric wrote: Stewart, You realize that the text example you gave is meaningless - without making some (potentially non-obvious) assumptions, right? -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Stewart Bryant -- Sent: Monday, January 09, 2006 2:47 PM -- To: Sam Hartman -- Cc: Harald Tveit Alvestrand; ietf@ietf.org -- Subject: Re: Normative figures -- -- Sam Hartman wrote: -- -- Hi. With the exception of packet diagrams, I think all -- the examples -- you bring up benefit significantly from clear textual description. -- -- Sam -- -- I am not saying that clear text is not needed to accompany -- a diagram. -- However a diagram allows a lot less text to be written producing a -- shorter clearer draft with less clutter. -- -- For example you could say the following in text : router A connects to -- router B and D, the cost from A to B is 2, and the cost from A to D is 4. A --(2)-- B | +---(4)-- D -- Router B connects to router C. The cost to router A is 6, and -- the cost to router C is 10. + A --(6)--+ | | | | +--(2)-- B --(10)-- C | +--(4)-- D (Assumes cost is from router B in both cases) -- Router C connects to router D. The cost to router B is 9 -- and the cost to router D is 8. + A --(6)--+ | | | | +--(2)-- B --(9)---+ | | | | +--(10)-- C | | +--(4)-- D (8)---+ (Assumes cost is from router C in both cases) -- The cost from router D to router A is 16 and ... +--+ | | | +- A --(6)--+ | | | | | | +--(2)-- B --(9)---+ | | | | | +--(16)+ +--(10)-- C | | | +--(4)-- D (8)+ -- -- ... the cost to router A is 99. ? (Assuming you meant the cost from D to C - not A) +--+ | | | +- A --(6)--+ | | | | | | +--(2)-- B --(9)---+ | | | | | +--(16)+ +--(10)-- C -+ | | | | +--(4)-- D (8)+ | | | +-(99)+ (Figure foo?) -- -- In fact you would probably need a table to make sure that -- you did not make a mistake. In either case it is hard for -- most people to figure out the what the topology is much -- less imagine packet actions. Actually, you need a figure to make sure that you did not make a mistake, and a second set of eyes to compare what you said to what you apparently meant. -- -- Now compare this to: -- -- The network and costs are as shown in figure foo. -- Is the above actually figure foo? The reality is that it would be better to break it this way: In the network in figure foo, the link costs are as follows: A - B = 2 B - A = 6 +- A B -+ A - D = 4 || D - A = 16 +- D C -+ B - C = 10 C - B = 9 Figure foo C - D = 8 D - C = 99 -- Simple text and the visualisation is already done for you -- so you can focus on the problem. -- The reality is that putting things entirely in pictures means that less validation of the intent of the picture is possible. Keeping pictures as simple as possible is, therefore, a goal since it is far easier to make mistakes in complex figures and far more difficult to determine that a mistake has been made. Using a mixture of text and figure(s), tables or - possibly - equations makes it both more understandable and easier to be certain of conveying the idea(s). For example, in the above, I could verify that I understand your intent by asking: From this it is apparent that the link cost (D-C) is 99, but the actual minimum cost of getting from D to C given by the formula: (D-A) + (A-B) + (B-C) = 16 + 2 + 10 = 28 Is that correct? If we choose to use a simple combination of representations, rather than strictly expecting a figure to explain it all, the figure is likely to be far simpler. For example, using an approach similar to the above, you could probably describe
RE: Normative figures
Stewart, See below... -- Eric -- -Original Message- -- From: Stewart Bryant [mailto:[EMAIL PROTECTED] -- Sent: Monday, January 09, 2006 6:50 PM -- To: Gray, Eric -- Cc: ietf@ietf.org -- Subject: Re: Normative figures -- -- Eric -- -- You are missing the point. -- Out of politeness, let's consider the possibility that I am not missing the point. -- -- I was picking an example out of thin air, but it is the -- type of construct that we use all the time in fast-reroute. -- I follow that discussion in each WG in which it has come up. -- -- The example was four routers connected together in a -- square with some randomly chosen asymetric costs. Such a -- network is trivial, but FRR need to cope with arbitary -- network fragments with arbitary costs, so there are lots -- of fragments that we have created for study the properties -- of. -- 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. As I indicated in my response, it is possible to represent a lot of different topologies in simplistic figures with textual descriptions and - potentially other means of helping readers to understand _and_ verify the specification. -- -- One of the ways to operate on the fragment is to draw it and -- then to figure out the packet flows, consequences of failure etc -- etc. -- -- Now the question is why should the examples in our drafts be forced -- by our ability to describe them, rather than being the example that -- most clearly illustrates the problem and its solution? -- There are two issues built into this question: 1) Are the available tools preventing completion of the task, or do they merely constrain the ways in which it can be done? 2) Is the purpose of the task to describe, or to illustrate, the specified solution? I believe these two questions - taken separately - have been beaten utterly to death. In the first issue, it is clear that a number of people feel that the current tools merely constrain the specification process. To many of those people, this is a good thing. In addition, nobody has yet been able to demonstrate an example of a case where the tools - as they are (and including the potential for PDF use) are preventing the completion of any specification task. In the second issue, it SHOULD be clear that the task is to give as precise a description as possible. Most everyone agrees that figures, tables and equations MAY help. Most everyone agrees that they MAY occasionally be necessary for correct understanding of a specification. And most people agree that text MUST be precise and complete for specification wherever it is possible to do so. Figures help to understand. In many cases, they are not required. The fact that an accurate description in text may not be easy to produce is not nearly as important as the fact that a description in text is easier to test for correctness. We write specifications so that they are easier to read, validate and understand, not so that they are easier to write. -- -- - Stewart -- -- -- Gray, Eric wrote: -- -- Stewart, -- --You realize that the text example you gave is meaningless - -- without making some (potentially non-obvious) assumptions, right? -- -- -- -Original Message- -- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- -- On Behalf Of Stewart Bryant -- -- Sent: Monday, January 09, 2006 2:47 PM -- -- To: Sam Hartman -- -- Cc: Harald Tveit Alvestrand; ietf@ietf.org -- -- Subject: Re: Normative figures -- -- -- -- Sam Hartman wrote: -- -- -- -- Hi. With the exception of packet diagrams, I think all -- -- the examples -- -- you bring up benefit significantly from clear textual -- description. -- -- -- -- Sam -- -- -- -- I am not saying that clear text is not needed to accompany -- -- a diagram. -- -- However a diagram allows a lot less text to be written -- producing a -- -- shorter clearer draft with less clutter. -- -- -- -- For example you could say the following in text : -- router A connects to -- -- router B and D, the cost from A to B is 2, and the -- cost from A to D is -- 4. -- --A --(2)-- B -- | -- +---(4)-- D -- -- -- Router B connects to router C. The cost to router A is 6, and -- -- the cost to router C is 10. -- -- + A --(6)--+ -- | | | -- | +--(2)-- B --(10)-- C -- | -- +--(4)-- D -- -- (Assumes cost is from router B in both cases) -- -- -- Router C connects to router D. The cost to router B is 9 -- -- and the cost to router D is 8. -- -- + A --(6)--+ -- | | | -- | +--(2)-- B --(9)---+ -- | | | -- | +--(10)-- C -- | | -- +--(4)-- D (8)---+ -- -- (Assumes cost is from router C in both cases) -- -- -- The cost from
Re: objection to proposed change to consensus
I disagree that the use of diagrams is a religious issue. Diagrams are a very simple way to put specification and context together in a compact notation such that it is easy to move from key point to key point in a non-linear way. They provide visual hyperlinking. Stewart, While I agree that diagrams are not simply a religious issue, I think that there are many cases in which the use of diagrams, especially complex ones, leaves people with the impression that they have understood something when, in fact, they do not. Ed Tufte's work, among many others, has provided repeated graphical, and often humorous, illustrations of that point. That's an interesting way of looking at it that I hadn't considered before. Tufte's work is for the most part focused on elaboration of the best techniques for presenting things visually - lessons that few us seem to heed. But it also provides a catalog of how and sometimes even why things go wrong, as well as providing ample evidence of how surprisingly hard it is to get this stuff right. Part of that issue overlaps the resistance to WG sessions that are dominated by PowerPoint presentations every time that discussion breaks out, although some of that discussion is driven by what are clearly religious issues. I guess, although I find Tufte's monograph on PowerPoint to be pretty levelheaded but a savage indictment nevertheless. This brings us back to one on the early comments in these threads -- that the need to describe a complex concept in text or in ASCII art imposes a discipline that is actually quite useful. I agree with you that there are some things that cannot be thus described with a sensible amount of effort, but it has seemed to me that it would be helpful, from a document quality standpoint, to examine each case and to try to strive for the minimum diagram complexity that is actually necessary. Not to sound trite, but whether or not a diagram works to advantage is highly dependent on the visual aspects of the thing being diagrammed. And sometimes finding those aspects (or not finding them, as the case may be) requires some effort. For example, one time I drew out a state diagram for SMTP (which is surprisingly complex, BTW) with the intention of asking you to include it in 821bis (now 2821). I don't recall if I ever showed it to you or not, but it's a case where a diagram hurts rather than helps. But you have to draw it and fiddle with it in order to see it. The TCP state diagram, OTOH, is one where a diagram really helps. At least part of this is due to the fact that there are symmetries in the state flow that most easily observed in a diagram - they'd be hard to see in text. Another example is the teletex state machine (T.101 or something like that - I'm not going to bother to search for it) is so complex that the state diagram fills at least two pages and still leaves out some details. It seems likely that no amount of graphical or prose ingenuity would be sufficient to tame this particular beast. The authors of the specification that includes appear to have tried (and IMO failed). In any case, while I think better diagrams would be helpful, I am concerned that if we make them cheap and easy we will actually lower the quality of our specifications, not raise it. I get even more concerned when it is suggested that not only are diagrams are needed, but that color documents may be needed. While things are easier than they were a decade or two ago, the need to transmit and render color images imposes costs in both printing facilities and transmission sizes of documents that I, at least, would prefer to avoid unless necessity can be demonstrated. Sam can, and I hope will, speak for himself, but my experience working with programmers with visual difficulties some years ago suggests that while monochrome line art --whether conveniently expressible in ASCII or not-- can often be made comprehensible with sufficient effort, either continuous-tone materials or line-art drawings that depend on color are fairly close to impossible. It is incredibly easy to misuse color coding - in fact we have a good example in our own current processes. These days the RFC Editor makes available differences listings showing the changes been the draft and the final RFC. These listings show deleted stuff in struck out red letters and added stuff in dark green. This scheme may sound fine, but it isn't: Try finding an added commas or single letter change inside of a big block of black text. That one bit of green simply vanishes unless you look really, really close. And sometimes a comma can change the meaning of something quite dramatically. (I addressed this problem personally by regenerating the differences using my own tools that make more appropriate color choices.) I have to say I still find it amazing given the prevalence of red-green color blindness how much material on the web and how many applications blunder badly in their use
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
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
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
Stewart Bryant wrote: 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? I'm a little confused. What is it about Eric's formulation of the statement that you take exception to in your followup question? They sound the same to me. (Or is it that you believe easier to write necessarily leads to will be more likely to be correctly implemented, and therefore easier to write should not be excluded as a desirable goal of our specification writing process?) cheers, gja ___ 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. 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. 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. -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
Protocol Action: 'Rivest-Shamir-Adleman (RSA) key exchange for the Secure Shell (SSH) Transport Layer Protocol' to Proposed Standard
The IESG has approved the following document: - 'Rivest-Shamir-Adleman (RSA) key exchange for the Secure Shell (SSH) Transport Layer Protocol ' draft-harris-ssh-rsa-kex-06.txt as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-harris-ssh-rsa-kex-06.txt Technical Summary This memo describes a key-exchange method for the Secure Shell (SSH) protocol based on Rivest-Shamir-Adleman (RSA) public-key encryption. It uses much less client CPU time than the Diffie-Hellman algorithm specified as part of the core protocol, and hence is particularly suitable for slow client systems. Working Group Summary This document is not a product of the secsh working group but it has been reviewed by participants of that working group. Protocol Quality This document has been reviewed by Sam Hartman for the IESG. There are at least two implementations of this specification underway. Note to RFC Editor Remove the trademark notice section prior to publication. Unlike the core ssh documents it is not needed in this case. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)' to Proposed Standard
The IESG has approved the following document: - 'Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP) ' draft-ietf-sip-identity-06.txt as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-identity-06.txt Technical Summary The existing security mechanisms in the Session Initiation Protocol are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document specifies a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. It specifies the mechanisms and procedures for using these and how they can be used with the existing SIP privacy capabilities. It is desirable for SIP user agents to be able to send requests to destinations with which they have no previous association - just as in the telephone network today, one can receive a call from someone with whom one has no previous association, and still have a reasonable assurance that their displayed Caller-ID is accurate. A cryptographic approach, like the one described in this document, can probably provide a much stronger and less-spoofable assurance of identity than the telephone network provides today. Working Group Summary This specification required a number of tries and much analysis. There was strong consensus on the solution by the time it reached the version in this draft. Protocol Quality Eric Rescorla provided early architectural review of the work. The careful reading by the GEN-ART reviewer, Lakshminath Dondeti was valuable. Allison Mankin is the Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Optimistic Duplicate Address Detection for IPv6' to Proposed Standard
The IESG has approved the following document: - 'Optimistic Duplicate Address Detection for IPv6 ' draft-ietf-ipv6-optimistic-dad-07.txt as a Proposed Standard This document is the product of the IP Version 6 Working Group Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-optimistic-dad-07.txt - Technical Summary Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC2461) and Stateless Address Autoconfiguration (RFC2462) process. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case and to remain interoperable with unmodified hosts and routers. - Working Group Summary The IPv6 working group has done extensive review of this document and this document reflects the consensus of the group. - Protocol Quality This document has been reviewed by members of the ipv6@ietf.org mailing list and by the working group chairs. This document was reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Low Latency Handoffs in Mobile IPv4' to Experimental RFC
The IESG has approved the following document: - 'Low Latency Handoffs in Mobile IPv4 ' draft-ietf-mobileip-lowlatency-handoffs-v4-11.txt as an Experimental RFC This document is the product of the Mobility for IPv4 Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-handoffs-v4-11.txt Technical Summary Mobile IPv4 describes how a Mobile Node can perform IP-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two methods to achieve low-latency Mobile IP handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support for real-time services on a Mobile IPv4 network by minimising the period of time when a Mobile Node is unable to send or receive IP packets due to the delay in the Mobile IP Registration process. Working Group Summary This document is a work item of the MIP4 WG. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Mobile IPv4 Dynamic Home Agent Assignment' to Proposed Standard
The IESG has approved the following document: - 'Mobile IPv4 Dynamic Home Agent Assignment ' draft-ietf-mip4-dynamic-assignment-07.txt as a Proposed Standard This document is the product of the Mobility for IPv4 Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-assignment-07.txt Technical Summary Mobile IPv4 uses the Home Agent (HA) to anchor sessions of a roaming Mobile Node (MN). This draft proposes a messaging mechanism for dynamic home agent assignment and HA redirection. The goal is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA selection. Working Group Summary This document is a work item of the MIP4 WG. There were several changes made to this document based on AD and IETF LC comments from Thomas Narten and others. Protocol Quality This document has been reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Fibre-Channel Name Server MIB' to Proposed Standard
The IESG has approved the following document: - 'Fibre-Channel Name Server MIB ' draft-ietf-imss-fc-nsm-mib-05.txt as a Proposed Standard This document is the product of the Internet and Management Support for Storage Working Group. The IESG contact persons are Bert Wijnen and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-nsm-mib-05.txt Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to the Name Server function of a Fibre Channel network. The Fibre Channel Name Server provides a means for Fibre Channel ports to register and discover Fibre Channel names and attributes. Working Group Summary This document was reviewed in the IMSS WG and in Technical Committee T11 (the official Fibre Channel standards body). T11 voted to recommend a prior version of this document to the IETF. Protocol Quality The protocol has been reviewed by Keith McCloghrie for the imss WG. Keith is one in the group of authors. Orly Nicklass did independent MIB Doctor review and Bert Wijnen reviewed this document for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Fibre Channel Fabric Address Manager MIB' to Proposed Standard
The IESG has approved the following document: - 'Fibre Channel Fabric Address Manager MIB ' draft-ietf-imss-fc-fam-mib-03.txt as a Proposed Standard This document is the product of the Internet and Management Support for Storage Working Group. The IESG contact persons are Bert Wijnen and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-fam-mib-03.txt Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for information related to a Fibre Channel network's Fabric Address Manager. Fabric Address Manager refers to the functionality of acquiring DomainID(s) as specified in [FC-SW-3], and managing Fibre Channel Identifiers as specified in [FC-FS]. Working Group Summary This document was reviewed in the IMSS WG and in Technical Committee T11 (the official Fibre Channel standards body). T11 voted to recommend a prior version of this document to the IETF. Protocol Quality The protocol has been reviewed for the imss WG by Keith McCloghrie (who is one in the group of authors). Orly Nicklass did independent MIB doctor review and Bert Wijnen reviewed the document for the IESG. Note to RFC Editor - Section 7 is redundant with the back matter. So it is best deleted. - Fix typo (missing e), sect 12 page 40 OLD: t11FamRcFabricNotifyEnabl -- ability to enable/disable a notification. NEW: t11FamRcFabricNotifyEnable -- ability to enable/disable a notification. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'The AES-CMAC Algorithm' to Informational RFC
The IESG has approved the following document: - 'The AES-CMAC Algorithm ' draft-songlee-aes-cmac-03.txt as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-songlee-aes-cmac-03.txt Technical Summary AES-CMAC uses the AES cipher block to provide a 128-bit message authentication code (MAC). The document provides clear guidelines on the use of AES-CMAC, test vectors, and test code. Working Group Summary This is an individual submission. Protocol Quality The AES-CMAC is one of choices for the message authentication code (MAC) and key derivation function (KDF) supported in IEEE 802.16e. We believe that AES-CMAC has been immplemented by INTEL, Runcom and SAMSUNG for their IEEE 802.16e-compliant products. We believe that other vendors develop or have developed AES-CMAC for their IEEE 802.16e-compliant products. This document was reviewed by Russ Housley for the IESG. Note to RFC Editor Please delete the reference to [RFC1750] in the informative references. This document is not referenced in the text: [RFC1750] Eastlake 3rd, D., Crocker, S., and J. Schiller, Randomness Recommendations for Security, RFC 1750, December 1994. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'L2VPN Extensions for L2TP' to Proposed Standard
The IESG has received a request from the Layer Two Tunneling Protocol Extensions WG to consider the following document: - 'L2VPN Extensions for L2TP ' draft-ietf-l2tpext-l2vpn-06.txt as a Proposed Standard 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-01-23. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2vpn-06.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4285 on Authentication Protocol for Mobile IPv6
A new Request for Comments is now available in online RFC libraries. RFC 4285 Title: Authentication Protocol for Mobile IPv6 Author(s): A. Patel, K. Leung, M. Khalil, H. Akhtar, K. Chowdhury Status: Informational Date: January 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 19 Characters: 40874 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-mip6-auth-protocol-07.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4285.txt IPsec is specified as the means of securing signaling messages between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6). MIPv6 signaling messages that are secured include the Binding Updates and Acknowledgement messages used for managing the bindings between a Mobile Node and its Home Agent. This document proposes an alternate method for securing MIPv6 signaling messages between Mobile Nodes and Home Agents. The alternate method defined here consists of a MIPv6-specific mobility message authentication option that can be added to MIPv6 signaling messages. This document is a product of the Mobility for IPv6 Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4285.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4233 on Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer
A new Request for Comments is now available in online RFC libraries. RFC 4233 Title: Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer Author(s): K. Morneault, S. Rengasami, M. Kalla, G. Sidebottom Status: Standards Track Date: January 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 73 Characters: 157857 Obsoletes: 3057 I-D Tag:draft-ietf-sigtran-rfc3057bis-02.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4233.txt This document defines a protocol for backhauling of Integrated Services Digital Network (ISDN) Q.921 User messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol would be used between a Signaling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives ISDN signaling over a standard ISDN interface. This document obsoletes RFC 3057. This document is a product of the Signaling Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4233.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
