Re: objection to proposed change to consensus
On Jan 5, 2006, at 18:35, Sandy Wills wrote: People who agree will mumble yeah under their breath and otherwise ignore the post. People who disagree will reply on the list. After two weeks, someone will compare the size of the subscriber list to the number of negative replies, and we'll all start gathering rocks together. Then there are people who will mumble, that's so stupid/bad/foolish/ misguided, and virtually all of the many responses are negative, it'll never pass, and otherwise ignore the post. I doubt I'm the only one who sometimes finds himself in that camp. Then there are those who will mumble, I don't care about this, and otherwise ignore the post. Like I do for the majority of the IETF- wide last-call announcements on things like, say, IP over MPEG-2, or Calendar Access Protocol. Personally, I object to the suggestion that my vote should be counted one way or another if I am silent. At most, it should be counted as no strong opinion. Or should I now start responding to all the Last Calls with I don't care about this, so please don't count me as supporting it? For an IETF-wide last call, I do think it's reasonable to assume that the proposing working group -- the rough consensus of the group, not necessarily every participant -- is indicating approval of the document by bringing it forward. But that's a *small* bias in favor, not a large one. Ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
Ken Raeburn wrote: Personally, I object to the suggestion that my vote should be counted one way or another if I am silent. At most, it should be counted as no strong opinion. Or should I now start responding to all the Last Calls with I don't care about this, so please don't count me as supporting it? We wouldn't count you as supporting it. We would count you as not objecting. That's all. Maybe there's another way to put it. How about: I think we have reached substantial agreement on the following statement: ASCII text was good enough for my Grandfather, and it's going to be good enough for my grandchildren. Please reply to this CfC if you object. Do we need to put into the CfC that we are assuming agreement, and that people who don't care don't have to respond? I thought it obvious and understood by all (maybe that's my mistake, right there) that a CfC is a request to respond if you object. This is not a change; this seems to be the way the IETF works. Many group gatherings work the same way; to me its an intuitive way of getting any/all objections brought up, or establishing that there aren't any, after a period of free discussion. It's the same as at a wedding, when the preacher asks if anyone objects, speak now, or forever hold your peace. A CfC is assuming an agreement (or don't-care), and only those who do NOT agree need to respond. Any other response is undesired. It's just noise that makes it harder to hear the useful objection responses. When you got married, did you want every person in the audience to stand up and say I'm okay with this marriage!? No, you wanted the entire room silent, so that you could hear any objection. -- Unable to locate coffee. Operator halted. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ancients-moderns dispute (was: PDF, Postscript, and normative versions (was: Re: Baby Steps (was RE: Alternative formats for IDs)))
We need to get out this ancients vs moderns dispute. Ancients saying they have no experience of actual need by moderns, and moderns saying this is because the ancient culture does not permit it. Is there an objection to quote non-ascii documents hyperlinks? I suppose not. Why not to just to proceed step by step and experiment? Let create an optional non-ascii art RFC-Editor repositories, for images quoted in RFCs. This will not permit non-ASCII art to be normative but will permit non-ASCII art to be _better_ descriptive in a first time. Experience will show if there are many such images. If there is a real need for normative non-ASCII art, it will provide experience to create a non-ASCII art IANA registry making sure they will survive, at an adeqate place. jfc At 21:00 05/01/2006, John C Klensin wrote: No, I'm not saying that. But the distinction I was trying to make is pretty subtle. The ASCII is the ASCII. Normative doesn't mean much for an I-D (see below for RFCs). The rule about PDF or Postscript versions is that they are supposed to be equivalent to the ASCII (and vice versa). But equivalent gets a little subjective... We know perfectly well that there are a few cases in which, no matter what one does with ASCII art, it is not sufficient to make whatever point is being made and supplemental text --more description, in words, of what would be in the pictures-- will not help much either. Now, part of the point that the people who have said if you can't do it in ASCII art, you generally shouldn't be doing it -- use the ASCII art and write a better description are making is that the cases in which we really need fancy pictures are very few and that, except for those cases, we are better off without them or at least being able to treat them as strictly supplementary. Before I go on, I continue to be fascinated by the observation that, each time the we really need pictures and fancy formatting and need them frequently argument comes up, the vast majority of those who make it most strongly are people whose contributions to the IETF -- in designer, editor, or other leadership roles-- have been fairly minimal. Now, of course, some of them might argue that our current rules prevent them from contributing and that, if only we would let them submit documents written with the DeathRay word processor in Klingon script, not only would their productivity rise, but everyone else's would too --once we bought copies of DeathRay, learned Klingon, and persuaded UTC to get the characters into Unicode. However, that aside, assume that you are describing the new Mona Lisa protocol, and that it is really impossible to adequately describe the protocol without a high-resolution scale picture of the Mona Lisa overlaid with your coordinate system. The ASCII form of your document could (and must under our current rules) describe the coordinate system, include all of the measurements, and describe what you are doing with them. That text is normative (and the important thing is the text, not whether it is in ASCII or not) and has to be. But it is going to be _very_ hard for anyone to understand your protocol without seeing the picture unless they have a good mental image of it. Under those conditions, our precedents are that you can probably convince the WG/WGchairs/ADs, and eventually the RFC Editor, that a PDF document containing a picture of the Mona Lisa and an ASCII document with _- / \ _ | o o | | | | | __ | _ | | \_/ _ | | | | as a substitute for that picture, with the marginal lines roughly identifying your grid marks and coordinate system, is equivalent or as close to it as one can get. I would expect that to be a hard sell. I, personally, would _want_ it to be a hard sell. If it is really necessary, folks will figure out how to get the picture (maybe only the picture, which will probably not change from one version of the I-D to the next) to those who can't handle the PDF (or Postscript). But we have done it before, all of the needed rules and procedures are in place, and nothing new is needed other than your understanding that you are going to have to get consensus that the artwork is vital before making that great a departure between the ASCII and the PDF versions. Similarly, when PDF has been posted in order to exhibit non-ASCII characters, it has proven helpful to have Unicode character offsets (i.e., U+ representations) in both the ASCII and PDF forms to ensure complete precision even though the character-glyphs themselves appear only in the PDF form. So, consider the first baby step to have been taken: nothing prevents you from posting an I-D in both ASCII and PDF today, and the relevant sub-community will sort out, on a case by case basis, whether the ASCII is good enough. ...and if it's not the pdf version of the text
Re: objection to proposed change to consensus
So... here's the problem. Personally, I object to the suggestion that my vote should be counted one way or another if I am silent. At most, it should be counted as no strong opinion. Or should I now start responding to all the Last Calls with I don't care about this, so please don't count me as supporting it? Our technology support for do we have consensus stinks. We ask for feedback to a mailing list, knowing that me, too postings are (and should be) discouraged in most shared e-mail environments. What we get is exactly what you described - postings from a non-random subset of participants, and then we try to figure out what the sampling error is, and in which direction, based on not a lot more information. There is a safety mechanism, because when we REALLY miscount we can be appealed, but we don't use it often, and it's really an expensive mechanism to use. Sometimes chairs even remember to say, we also need to hear from people who AGREE, but not always. The mailing list archives would be even worse if everyone DID respond to all the Last Calls, so we need to be careful about what we ask for... It shouldn't be a vote (we don't vote - I know you know this, because you put vote in quotes), but if we had some way to let people say you know, I just don't care, that would help, too. Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
--On fredag, januar 06, 2006 09:02:21 -0500 Sandy Wills [EMAIL PROTECTED] wrote: This is not a change; this seems to be the way the IETF works. Many group gatherings work the same way; to me its an intuitive way of getting any/all objections brought up, or establishing that there aren't any, after a period of free discussion. It's the same as at a wedding, when the preacher asks if anyone objects, speak now, or forever hold your peace. A CfC is assuming an agreement (or don't-care), and only those who do NOT agree need to respond. Any other response is undesired. In this case, we've already had the loud shouts of no, so we're into the much more tricky case of either convincing the consensus-deciders that the naysayers are loud, argumentative loonies, or convincing the ones who asked for the consensus call that despite their strongly held convictions, there are good reasons why we shouldn't just do what they want. The CfC (if the original draft could be seen as one) has failed - or rather - succeded most brilliantly in proving that there is no present proposal that enjoys a strong consensus. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ABNF Re: Troubles with UTF-8
On 1/5/06, Tom.Petch [EMAIL PROTECTED] wrote: You say that a Unicode code point can be represented by %xABCD but that is not spelt out in ABNF [RFC4234]. ABNF uses non-negative integers to represent characters - note that it explicitly doesn't specify a range (2nd sentence of section 2.3). RFC 4234 specifies the encoding of those integers into ASCII, and says that other encodings may be specified. There's an implicit (obvious) encoding of ABNF characters into Unicode, and as Misha pointed out the IRI spec uses it - technically maybe it needs to be spelled out somewhere. And when it refers to 'one printable character' as '%x20-7E' I get the impressions that coded character sets like Unicode, with more than 256 code points, do not fall within its remit. That's an example, which is probably missing the word US-ASCII between printable and character. Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
Hello; On Jan 6, 2006, at 9:28 AM, Harald Tveit Alvestrand wrote: --On fredag, januar 06, 2006 09:02:21 -0500 Sandy Wills [EMAIL PROTECTED] wrote: This is not a change; this seems to be the way the IETF works. Many group gatherings work the same way; to me its an intuitive way of getting any/all objections brought up, or establishing that there aren't any, after a period of free discussion. It's the same as at a wedding, when the preacher asks if anyone objects, speak now, or forever hold your peace. A CfC is assuming an agreement (or don't-care), and only those who do NOT agree need to respond. Any other response is undesired. In this case, we've already had the loud shouts of no, so we're into the much more tricky case of either convincing the consensus- deciders that the naysayers are loud, argumentative loonies, or convincing the ones who asked for the consensus call that despite their strongly held convictions, there are good reasons why we shouldn't just do what they want. To me, this is the trouble with such proposals. If there is a last call, and _nobody_ objects, then I think it is fair to say that the majority either was in favor, or at least acquiesced. At least, if people complain later, you can say, you should have spoken up when appropriate. (I suppose, for symmetry, that the same could be said against a proposal if there are only objections, and absolutely no support, but this must be rare indeed.) But, as soon as there are _any_ objections, then people could remain silent saying to themselves I agree or I don't care or I agree with the objections, which have been much better stated than I could do. You just don't know. So, I regard it as improper to assume support either way from the silent majority if there is any dissension at all. That doesn't mean that you can't have consensus in the face of objections, but it does mean that you can't just wave them away by pointing to all the people who remain silent. Regards Marshall The CfC (if the original draft could be seen as one) has failed - or rather - succeded most brilliantly in proving that there is no present proposal that enjoys a strong consensus. Harald ___ 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
Experiments as a Gateway to Process Change
Ash, == Ash, Gerald R (Jerry) [EMAIL PROTECTED] writes: Ash, Happy New Year to all! Many thanks to Yaakov for his Ash, excellent handling of the list discussion. I'm not very Ash, surprised with the way it has gone. Déjà vu all over Ash, again :-) Ash, The challenge is to focus the discussion to try to reach Ash, consensus on moving forward with a process change, i.e., we Ash, need to take baby steps to make progress. Ash, I'd suggest we try to reach consensus first on the Ash, following: Alternative format(s) for IDs, in addition to Ash, ASCII text, should be allowed. I'd like to propose something I hope is simpler to act on. I'd like to get in the habit of asking people who propose process changes that are hard to get consensus on to conduct RFC 3933 experiments. So in this particular case please restructure your draft as in experiment. Find some working groups or authors who would benefit. Find some rfc editor staff and an AD who would be willing to help you out. Propose a time limit and let's see if the world comes to an end if we publish a few documents that are not in ASCII. I suspect we'll all survive. I think there are a lot of good reasons why we should do this. The first is that as part of evaluating plausibility of experiments we can make sure that the experiment could take place. It seems reasonable to require that those wanting to change the process spend the effort to make their changes possible. Hey. I've got these people over in the PWE3 working group who would really like to have better diagrams in their specifications. The AD says he would be able to review the diagrams and thinks it might be more clear. The rfc editor says they have time and would be willing to try publishing a few specs with diagrams if the community thinks it is reasonable, is a lot more compelling as a starting point than I want the process to change. I'm going to write text to change the process and you should all approve it. If in trying to put together the experiment you find that no one actually would take advantage of your process change or you find that people along the way don't have time to do additional work required by your proposed change, then perhaps that's not where we should be spending our process change energy. Second, a lot of objections (more so for other process changes than for this one) fall into the category of That will never work, or that will drown us all in additional paperwork. The nice thing about experiments is that they can be constructed so that participation is optional and so that you have flow control at all stages. Well, it will either work or not. If it doesn't we will delay a few documents or efforts that agreed to participate in the experiment, is a more compelling response than It will work fine! I'm willing to risk the entire IETF process on it! Even if you are absolutely sure it will work fine, what harm is there in starting out slow? Also, opt-in experiments are an excellent response to questions about whether something is useful. If you start out with enough people who think it is to justify the IESG review cycle and publication of an experimental RFC, then you have a strong response to those who question utility: We think it is useful; let us waste our own time. We will either be right or wrong. Another good thing about experiments is that they often do get people to become familiar with something and that tends to defuse a lot of negative feelings steming from anxiety about change. I certainly know I've had strong negative reactions to things in the past and have reluctantly agreed to try something. Typically I find it is not nearly as bad as I had feared. Sometimes I find that I was completely right but that I have significant evidence to point to now helping others understand the problem. I don't think I'm atypical in this regard. Finally, I'm hoping that we can build a culture of constructive progress around experiments. I think we have consensus that the IETF needs to change and evolve. Perhaps we can come to consensus that experiments are a way we can make forward progress. We may not all like the experiments but perhaps e can decide that a culture in which we've all agreed to constructively work towards conducting plausible experiments is the best compromise we can come up with. I'm hoping that we can get to a point where it is culturally unacceptable to object to plausible experiments without explaining what the proponents of the experiment would need to do in order to get around the objection. I'm also hoping that we can get to a culture where the response to a long flame war like this quickly becomes Well, write it up, convince the people whose work would be influenced to give it a try and let's go for it. There will still need to be a lot of compromise; when people have concerns we will need to try and find ways of collecting the data we need to evaluate the change. We probably
Re: Baby Steps (was RE: Alternative formats for IDs)
Gray, Eric wrote: Stewart, You bring up a good point. I have been assuming that - since IDs can be submitted in multiple formats - that the additional formats would also become part of the RFC library on publication. I just took a quick peek at the RFCs and there does not appear to be a single example of a version that is not in text format. I don't know if that is because they are not stored in the same place, or they are not carried forward as part of the publishing process. You must have looked in the wrong place. Where there are PS or PDF versions, they can be found via the search page at http://www.rfc-editor.org/cgi-bin/rfcsearch.pl It's less clear that all mirror sites carry them. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
Ash, Gerald R (Jerry) wrote: Unless the IESG has changed the rules while I was not looking, it has been permitted to post I-Ds in PDF in addition to ASCII for some years. BUT the pdf is not allowed to be normative. Right. The ASCII version is the only normative format. Furthermore, all diagrams, no matter how complex in the PDF version, must be converted to ASCII stick figures in the normative ASCII version. There are no tools I'm aware of to aid that conversion, and in many cases much is lost in the conversion. Changing that rule alone would be sufficient to allow modern graphics to be called up in normative texts. It would, and the same would apply to mathematical formulae. As a matter of fact, the relatively unmodern RFC 1119 that John mentioned does use some graphics and mathematics that would be annoying to code in ASCII. We can certainly ask the question whether that is a big enough benefit to be worth the cost. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
Spencer == Spencer Dawkins [EMAIL PROTECTED] writes: Spencer So... here's the problem. Personally, I object to the suggestion that my vote should be counted one way or another if I am silent. At most, it should be counted as no strong opinion. Or should I now start responding to all the Last Calls with I don't care about this, so please don't count me as supporting it? Spencer Our technology support for do we have consensus Spencer stinks. We ask for feedback to a mailing list, knowing Spencer that me, too postings are (and should be) discouraged Spencer in most shared e-mail environments. What we get is Spencer exactly what you described - postings from a non-random Spencer subset of participants, and then we try to figure out Spencer what the sampling error is, and in which direction, based Spencer on not a lot more information. There is a safety Spencer mechanism, because when we REALLY miscount we can be Spencer appealed, but we don't use it often, and it's really an Spencer expensive mechanism to use. I'm not sure I consider this very broken. If I'm reading a last call and I have opinions that differ from the way the discussion is going, I'm certainly going to speak up. It seems to work fairly well in practice at determining rough consensus when there is a rough consensus to be determined. It gives questionable results in cases where the results are questionable; I'm not sure this a bug. Spencer some way to let people say you know, I just don't care, Spencer that would help, too. And what do we do with those people anyway? How would it help me to know there are 30 people who don't care? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: participation sans meeting attendance (was RE: Alternative formats for IDs)
Melinda Shore wrote: On 1/2/06 11:32 PM, Jeffrey Hutzelman [EMAIL PROTECTED] wrote: I think we're doing better on this front than we have in many years. The technical support for remote participation really has become terrific. Some sessions are run with great sensitivity to remote participation, others are not - it depends on the chairs. However, on the other hand it does seem as if groups have become more likely to make final decisions during meetings and not on mailing lists. I'd like to point out that this would be an appealable process failure, i.e. there should always be (at the minimum) an email call for consensus about decisions embedded in the minutes, and important decisions should certainly have their own email consensus call. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ABNF Re: Troubles with UTF-8
- Original Message - From: Misha Wolf [EMAIL PROTECTED] To: Tom.Petch [EMAIL PROTECTED] Cc: ietf ietf@ietf.org Sent: Thursday, January 05, 2006 10:53 PM Subject: RE: ABNF Re: Troubles with UTF-8 See: 2.2. ABNF for IRI References and IRIs in: http://www.ietf.org/rfc/rfc3987.txt=20 Misha Misha Yes, spot on, thanks for that; I had read the IRI RFC and forgotten it. There is a (Standards Track) precedent for specifying UCS in ABNF. Tom Petch -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom.Petch Sent: 05 January 2006 20:15 To: James Seng Cc: ietf Subject: ABNF Re: Troubles with UTF-8 You say that a Unicode code point can be represented by %xABCD but that is not spelt out in ABNF [RFC4234]. And when it refers to 'one printable character' as '%x20-7E' I get the impressions that coded character sets like Unicode, with more than 256 code points, do not fall within its remit. I have yet to see any use of this in an I-D or RFC. I did post a question about this to this list on 24th December and the lack of response reinforces my view that this is uncharted territory. Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ancients-moderns dispute (was: PDF, Postscript, and normative versions (was: Re: Baby Steps (was RE: Alternative formats for IDs)))
* * Why not to just to proceed step by step and experiment? Let create an * optional non-ascii art RFC-Editor repositories, for images quoted in * RFCs. This will not permit non-ASCII art to be normative but will * permit non-ASCII art to be _better_ descriptive in a first time. * Experience will show if there are many such images. If there is a * real need for normative non-ASCII art, it will provide experience to * create a non-ASCII art IANA registry making sure they will survive, * at an adeqate place. * * jfc This has been in place for many years, in the form of PS and/or PDF versions of RFCs. What am I missing? Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Trying to invent a way of determining consensus
Are you guys taking turns, saying the same thing over and over again? For the record, I'm not taking sides in any of the current questions about ASCII/Word/AmiPro/etc, or DKIM, or the other discussions filling my inbox. I'm trying to come up with a way for the participants in those discussions to determine if they are done yet. I am proposing a formal construct, called a Call for Concensus, or appreviated as CfC (because I'm lazy and can't spell that third word the same way two times in a row anyway), for a specific purpose: to determine if we have reached an agreement during a discussion. It is _not_ used _IN_ a discussion, it is used when the discussers are tired of the endless circles that these discussions turn in, _AFTER_ all the different options have been mentioned. In order for such a test to work, it MUST be posted as a statement, which can be agreed with, or not. Simple enough. In order to cut down on the noise level, you word the statement such that it includes the supposed-agreement. People who agree don't need to reply. People who don't care, either from lack of expertise or apathy, don't need to reply. ONLY PEOPLE WHO OBJECT to that statement should reply to the CfC. If you have a rough idea of how many people received the CfC post, and you can easily see how many people objected, then you can easily see if your statement does, in fact, state a concensus agreement. I don't see how this can be too complicated for people who create software. The CfC is not part of the discussion. It is a test to see if the discussion has had a result. Is this a bad idea? I don't think so, but I keep getting replies, from differing posters, with differing words, that all evaluate to But someone will disagree, and then you can't tell Yes, you can. There are only four meaningful groups of people here, the matrix of care/don't care and agree/don't agree: Anyone who disagrees with the CfC statement, but didn't reply, is too apathetic to participate. Don't count them, because they themselves don't think that their opinion is worth your time. Anyone who agrees, and did reply, has trouble understanding instructions like Only reply to this CfC if you disagree. Given that, should these people be making decisions for the group?. Who's left? The two groups that we care about: Anyone who disagrees, and replies, will have their voices heard, because their opinion is the one asked for by the CfC. If their objections (or volume) are significant, then the discussion will turn to ways to make progress while satisfying their concerns. 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. Marshall Eubanks wrote: If there is a last call, and _nobody_ objects, then I think it is fair to say that the majority either was in favor, or at least acquiesced. At least, if people complain later, you can say, you should have spoken up when appropriate. (I suppose, for symmetry, that the same could be said against a proposal if there are only objections, and absolutely no support, but this must be rare indeed.) But, as soon as there are _any_ objections, then people could remain silent saying to themselves I agree or I don't care or I agree with the objections, which have been much better stated than I could do. You just don't know. So, I regard it as improper to assume support either way from the silent majority if there is any dissension at all. That doesn't mean that you can't have consensus in the face of objections, but it does mean that you can't just wave them away by pointing to all the people who remain silent. Regards Marshall -- Unable to locate coffee. Operator halted. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Baby Steps (was RE: Alternative formats for IDs)
* * I just took a quick peek at the RFCs and there does not appear * to be a single example of a version that is not in text format. I * don't know if that is because they are not stored in the same place, * or they are not carried forward as part of the publishing process. * You must not be looking at the official RFC repository maintained by the RFC Editor. For Unix fans, looking at the ~in-notes directory: 31% ls -al rfc*.ps|wc 55 4403127 32% ls -al rfc*.pdf|wc 54 4323124 That is, there are 55 Postscript RFCs and 54 PDF RFCs (they don't exactly match because some early Postscript files could not be converted to PDF). Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
-- -- I think we have reached substantial agreement on the following -- statement: ASCII text was good enough for my Grandfather, and it's -- going to be good enough for my grandchildren. Please reply to this -- CfC if you object. -- I object. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
On Fri, 6 Jan 2006, Gray, Eric wrote: -- I think we have reached substantial agreement on the following -- statement: ASCII text was good enough for my Grandfather, and it's -- going to be good enough for my grandchildren. Please reply to this -- CfC if you object. IMO an objection should be required to also have an explanation. I object. Why? to which parts? the grandfather/grandchildren? -- ~Randy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
Spencer, -- -- It shouldn't be a vote (we don't vote - I know you know this, because you -- put vote in quotes), but if we had some way to let people say you know, -- I just don't care, that would help, too. -- I agree, and it could also be very useful should we ever start to realize that it is important to gauge who is paying attention as well as who is subscribed. -- Spencer -- -- -- -- ___ -- 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
Digression was-Re: objection to proposed change to consensus
At 9:02 AM -0500 1/6/06, Sandy Wills wrote: When you got married, did you want every person in the audience to stand up and say I'm okay with this marriage!? No, you wanted the entire room silent, so that you could hear any objection. Hi, This is a digression. Hit delete now unless you're willing to digress. Speaking as a liturgical die-hard, let me just note that the affirmative *is* asked in many forms of the marriage ceremony. In the Episcopal church, for example, the question takes this form: (Celebrant) Will all of you witnessing these promises do all in your power to uphold these two persons in their marriage? (People) We will. (see http://vidicon.dandello.net/bocp/bocp4.htm for the full text) This requires that those who are present at the wedding take the affirmative step of saying they will support the marriage, which is considerably more than I'm okay with this. For many who see marriage in sacramental terms, this single statement is why the sacrament is a public one, rather than a private one. The key sacramental act here is the commitment of the two people to throw their lot in together and be a family; it does not need onlookers (or even a celebrant, as the individuals can exchange vows without one). But the public act is a request for the support of the community for the marriage and is the public participation in the sacrament. I think there is far too much treating of IETF documents like holy writ now, so I not only would not draw a parallel here, I actively discourage any one else from doing so. This, in other words, is pure digression. Don't say I didn't warn you. Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
Randy, Nosey, aren't we? :-) If you must know, let's see: one grandfather worked in a machine shop during WWII, retired in the late 50s; the other was in the Army for WWI and a farmer, sawyer, moon-shiner and road worker the rest of his life (being a farmer isn't a living, it's a hobby). I doubt ASCII figured much into either of their lives. ASCII isn't good enough for me, but PDF is useful where the problem is really bad. Between them (counting PS as a variation of PDF - especially since I have to convert PS to PDF to read it) they are what there is. I don't even pretend to know what will be good for my own grandchildren because - so far - I don't even know that I will ever have any. My point in making a terse response was that all that was asked for was objections. Sometimes, reasons are neither asked for nor needed. I suspect that - now that you know the reasons - you might agree that this was one of those times... -- Eric -- -Original Message- -- From: Randy.Dunlap [mailto:[EMAIL PROTECTED] -- Sent: Friday, January 06, 2006 1:21 PM -- To: Gray, Eric -- Cc: 'Sandy Wills'; Ken Raeburn; IETF General Discussion Mailing List -- Subject: RE: objection to proposed change to consensus -- -- On Fri, 6 Jan 2006, Gray, Eric wrote: -- -- -- I think we have reached substantial agreement on -- the following -- -- statement: ASCII text was good enough for my -- Grandfather, and it's -- -- going to be good enough for my grandchildren. Please -- reply to this -- -- CfC if you object. -- -- IMO an objection should be required to also have an explanation. -- -- I object. -- -- Why? to which parts? the grandfather/grandchildren? -- -- -- -- ~Randy -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
* * -- * -- I think we have reached substantial agreement on the following * -- statement: ASCII text was good enough for my Grandfather, and it's * -- going to be good enough for my grandchildren. Please reply to this * -- CfC if you object. * -- * Are we all in favor of Motherhood and Apple Pie? Well, mostly. No one (well, the IETF is a big tent, so that's probably too strong... almost no one) questions the desirability of a better format for publishing RFCs than pure ASCII text. This has been the subject of repeated discussions over the last 20 years. Will the same discussion be taking place 20 years from now? I, for one, certainly hope not. However, simply wishing we had a better solution is not enough. We need to have such a reasonable solution in hand before we agree to adopt it. We believe we want vendor neutrality, ubiquity, convenience, searchability, editability, etc.. The obvious, simple suggestions have all failed on one criterion or another, and ASCII has continued to be the best (if flawed) compromise. For many years, PS and PDF files have been allowed as secondary formats for RFCs. (You can find them by searching rfc-index.txt for the strings 'PS=' and 'PDF=', respectively). This provision does not handle things like state diagrams, which are presumably normative. In practice, creating the PS/PDF forms has been a major pain, because the documentswere created by the authors using a wide variety of different editors and tools. On the other hand, it does appear that the availability of ASCII support as a common denominator is decreasing over time. As has been observed, some software vendors seem to go out of their way to make simple ASCII hard to use. So there is increasing pressure to find a (truly) better solution. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
Randy.Dunlap wrote: On Fri, 6 Jan 2006, Gray, Eric wrote: -- "I think we have reached substantial agreement on the following -- statement: ASCII text was good enough for my Grandfather, and it's -- going to be good enough for my grandchildren. Please reply to this -- CfC if you object." IMO an objection should be required to also have an explanation. I object. Why? to which parts? the grandfather/grandchildren? OK, I object on the basis that ASCII diagrams are inadequate for our purposes. - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
On Fri, 6 Jan 2006, Gray, Eric wrote: Randy, Nosey, aren't we? :-) Nah, I was interested in technical objections, not family history. [snippage] ASCII isn't good enough for me, but PDF is useful where the problem is really bad. Between them (counting PS as a variation of PDF - especially since I have to convert PS to PDF to read it) they are what there is. My point in making a terse response was that all that was asked for was objections. Sometimes, reasons are neither asked for nor needed. and sometimes they are... I suspect that - now that you know the reasons - you might agree that this was one of those times... Yes. -- Eric -- -Original Message- -- From: Randy.Dunlap [mailto:[EMAIL PROTECTED] -- Sent: Friday, January 06, 2006 1:21 PM -- To: Gray, Eric -- Cc: 'Sandy Wills'; Ken Raeburn; IETF General Discussion Mailing List -- Subject: RE: objection to proposed change to consensus -- -- On Fri, 6 Jan 2006, Gray, Eric wrote: -- -- -- I think we have reached substantial agreement on -- the following -- -- statement: ASCII text was good enough for my -- Grandfather, and it's -- -- going to be good enough for my grandchildren. Please -- reply to this -- -- CfC if you object. -- -- IMO an objection should be required to also have an explanation. -- -- I object. -- -- Why? to which parts? the grandfather/grandchildren? -- ~Randy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
Sam, It is useful sometimes to differentiate those who have no stake in a particular issue from those who are not paying attention. Sometimes (maybe most of the time) it is not a very important distinction, and the IETF treats it this way all of the time. Maybe that's the right way to go. Maybe not. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Sam Hartman -- Sent: Friday, January 06, 2006 10:51 AM -- To: Spencer Dawkins -- Cc: IETF General Discussion Mailing List -- Subject: Re: objection to proposed change to consensus -- -- Spencer == Spencer Dawkins [EMAIL PROTECTED] writes: -- -- Spencer So... here's the problem. -- Personally, I object to the suggestion that my -- vote should be -- counted one way or another if I am silent. At most, -- it should -- be counted as no strong opinion. Or should I now start -- responding to all the Last Calls with I don't care -- about this, -- so please don't count me as supporting it? -- -- Spencer Our technology support for do we have consensus -- Spencer stinks. We ask for feedback to a mailing list, knowing -- Spencer that me, too postings are (and should be) discouraged -- Spencer in most shared e-mail environments. What we get is -- Spencer exactly what you described - postings from a non-random -- Spencer subset of participants, and then we try to figure out -- Spencer what the sampling error is, and in which -- direction, based -- Spencer on not a lot more information. There is a safety -- Spencer mechanism, because when we REALLY miscount we can be -- Spencer appealed, but we don't use it often, and it's really an -- Spencer expensive mechanism to use. -- -- I'm not sure I consider this very broken. If I'm reading a -- last call -- and I have opinions that differ from the way the discussion -- is going, -- I'm certainly going to speak up. It seems to work fairly well in -- practice at determining rough consensus when there is a rough -- consensus to be determined. It gives questionable results in cases -- where the results are questionable; I'm not sure this a bug. -- -- Spencer some way to let people say you know, I just -- don't care, -- Spencer that would help, too. -- -- And what do we do with those people anyway? How would it help me to -- know there are 30 people who don't care? -- -- -- ___ -- 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
This On the other hand, it does appear that the availability of ASCII support as a common denominator is decreasing over time. As has been observed, some software vendors seem to go out of their way to make simple ASCII hard to use. So there is increasing pressure to find a (truly) better solution. This is the nut of the output representation problem for me. Most people who object to changing the output format talk about ASCII as if it always was the standard, and always will be the standard. If we were having this discussion 30 or 35 years ago, we would be discussing whether ASCII would take over EBCDIC or not. 35 years ago, it would not be clear that ASCII would survive. There was a holy war about that. ASCII did in fact take over from EBCDIC, but it wasn't always clear that it would. As Bob points out, we are, in fact, coming to the end of the line for ASCII. It's not in trouble this year, except that it's pretty damn tough to print it satisfactorily on the machines most of us have to work with. I suspect it will get increasingly difficult to create and edit in the not too distant future. That would make it a possible minimum common denominator archive format, but not a useful reading format. It's probably true that we can push this problem off another year, but maybe not, and definitely not for very much longer. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ancients-moderns dispute (was: PDF, Postscript, and normative versions (was: Re: Baby Steps (was RE: Alternative formats for IDs)))
At 18:49 06/01/2006, Bob Braden wrote: * * Why not to just to proceed step by step and experiment? Let create an * optional non-ascii art RFC-Editor repositories, for images quoted in * RFCs. This will not permit non-ASCII art to be normative but will * permit non-ASCII art to be _better_ descriptive in a first time. * Experience will show if there are many such images. If there is a * real need for normative non-ASCII art, it will provide experience to * create a non-ASCII art IANA registry making sure they will survive, * at an adeqate place. * * jfc This has been in place for many years, in the form of PS and/or PDF versions of RFCs. What am I missing? I am not suggesting a repository of the RFC PDF version. But a repository of the _art_ attached to an ASCII version. So we first see if there is a real need through the usage made. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: objection to proposed change to consensus
Bob, State Diagrams is a bad example. State machines can, and should always be, described definitively in text. State machine diagrams must be derived from textual description. Consequently, if we want to create a document with a pictorial representation, that document could contain normative references to a document containing a textual description and not the other way around. Being able to put both in the same document and have that document be authoritative would be a plus, provided we could be sure that everyone could read that document. Perhaps a better example might be complex functional block diagrams. Or mathematical expressions as someone else pointed out earlier. If your point is that there are things that are painfully hard to represent in text, obviously that is true - although we have had several people argue that this is a good thing, most of the time. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Bob Braden -- Sent: Friday, January 06, 2006 1:57 PM -- To: [EMAIL PROTECTED] -- Cc: ietf@ietf.org -- Subject: RE: objection to proposed change to consensus -- -- -- * -- * -- -- * -- I think we have reached substantial agreement -- on the following -- * -- statement: ASCII text was good enough for my -- Grandfather, and it's -- * -- going to be good enough for my grandchildren. -- Please reply to this -- * -- CfC if you object. -- * -- -- * -- -- Are we all in favor of Motherhood and Apple Pie? Well, mostly. -- -- No one (well, the IETF is a big tent, so that's probably -- too strong... -- almost no one) questions the desirability of a better format for -- publishing RFCs than pure ASCII text. This has been the subject of -- repeated discussions over the last 20 years. Will the same -- discussion -- be taking place 20 years from now? I, for one, certainly hope not. -- -- However, simply wishing we had a better solution is not enough. We -- need to have such a reasonable solution in hand before we agree to -- adopt it. We believe we want vendor neutrality, ubiquity, -- convenience, -- searchability, editability, etc.. The obvious, simple -- suggestions have -- all failed on one criterion or another, and ASCII has -- continued to be -- the best (if flawed) compromise. -- -- For many years, PS and PDF files have been allowed as -- secondary formats -- for RFCs. (You can find them by searching rfc-index.txt for the -- strings 'PS=' and 'PDF=', respectively). This provision does not -- handle things like state diagrams, which are presumably -- normative. In -- practice, creating the PS/PDF forms has been a major pain, -- because the -- documentswere created by the authors using a wide variety of -- different editors and tools. -- -- On the other hand, it does appear that the availability of ASCII -- support as a common denominator is decreasing over time. -- As has been -- observed, some software vendors seem to go out of their way to make -- simple ASCII hard to use. So there is increasing pressure to find -- a (truly) better solution. -- -- Bob Braden -- -- ___ -- 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
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. (rest of post snipped) Here I must become two-faced. Personally, I agree with you. Often, there are many shades of grey between the white and black binary choices. Often, being able to communicate those shades of grey will be essential to creating a usable compromise. Unfortunately, there seems to be a religious dogma among the long-time IETF participants that they never take votes. All they do is judge rough or smooth concensus, and that reduces our options to simple binary choices. Thus, my attempt to create a binary method for asserting and testing a claim of concensus. I truly believe that we will have to go to some kind of multiple- choice voting system to reach decisions in these multi-valued cases. We have already seen a couple of examples on this list, where someone set up an opinion poll on the web, and later reported the results. Of course, in order for us to actually use them, they would have to be hosted by the IETF, or the winners of any poll would spend the rest of their lives fighting off charges of cheating. -- Unable to locate coffee. Operator halted. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
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. I think that everyone here is aware of that, which is why we keep coming back to it, and will continue to until the agents of change win. I've only been following the IETF for a couple of years now, but this discussion seems to come closer to adopting a change every time I see it. -- Unable to locate coffee. Operator halted. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: objection to proposed change to consensus
For an organisation that, apparently, ought to be stymied and ineffectual because of its reliance on ASCII, the IETF appears to have had a remarkably productive run these past 20 years. Dare I suggest a certain organisational maturity is evidenced by the IETF's unwillingness to swing with every change in the winds of popular editing and presentation formats over these 20 years. gja ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'RTP Payload Format for MIDI' to Proposed Standard
The IESG has received a request from the Audio/Video Transport WG to consider the following documents: - 'RTP Payload Format for MIDI ' draft-ietf-avt-rtp-midi-format-14.txt as a Proposed Standard - 'An Implementation Guide for RTP MIDI ' draft-ietf-avt-rtp-midi-guidelines-14.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-01-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi-format-14.txt http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-midi-guidelines-14.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4254 on The Secure Shell (SSH) Connection Protocol
A new Request for Comments is now available in online RFC libraries. RFC 4254 Title: The Secure Shell (SSH) Connection Protocol Author(s): T. Ylonen, C. Lonvick, Ed. Status: Standards Track Date: January 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 24 Characters: 50338 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-secsh-connect-25.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4254.txt Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. This document is a product of the Secure Shell 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/rfc4254.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4250 on The Secure Shell (SSH) Protocol Assigned Numbers
A new Request for Comments is now available in online RFC libraries. RFC 4250 Title: The Secure Shell (SSH) Protocol Assigned Numbers Author(s): S. Lehtinen, C. Lonvick, Ed. Status: Standards Track Date: January 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 20 Characters: 44010 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-secsh-assignednumbers-12.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4250.txt This document defines the instructions to the IANA and the initial state of the IANA assigned numbers for the Secure Shell (SSH) protocol. It is intended only for the initialization of the IANA registries referenced in the set of SSH documents. This document is a product of the Secure Shell 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/rfc4250.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4253 on The Secure Shell (SSH) Transport Layer Protocol
A new Request for Comments is now available in online RFC libraries. RFC 4253 Title: The Secure Shell (SSH) Transport Layer Protocol Author(s): T. Ylonen, C. Lonvick, Ed. Status: Standards Track Date: January 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 32 Characters: 68263 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-secsh-transport-24.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4253.txt The Secure Shell (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol, which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. This document is a product of the Secure Shell 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/rfc4253.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4252 on The Secure Shell (SSH) Authentication Protocol
A new Request for Comments is now available in online RFC libraries. RFC 4252 Title: The Secure Shell (SSH) Authentication Protocol Author(s): T. Ylonen, C. Lonvick, Ed. Status: Standards Track Date: January 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 17 Characters: 34268 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-secsh-userauth-27.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4252.txt The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. This document is a product of the Secure Shell 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/rfc4252.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4251 on The Secure Shell (SSH) Protocol Architecture
A new Request for Comments is now available in online RFC libraries. RFC 4251 Title: The Secure Shell (SSH) Protocol Architecture Author(s): T. Ylonen, C. Lonvick, Ed. Status: Standards Track Date: January 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 30 Characters: 71750 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-secsh-architecture-22.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4251.txt The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. This document is a product of the Secure Shell 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/rfc4251.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4256 on Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
A new Request for Comments is now available in online RFC libraries. RFC 4256 Title: Generic Message Exchange Authentication for the Secure Shell Protocol (SSH) Author(s): F. Cusack, M. Forssen Status: Standards Track Date: January 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 12 Characters: 24728 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-secsh-auth-kbdinteract-07.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4256.txt The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard (or equivalent alphanumeric input device). The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). This document is a product of the Secure Shell 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/rfc4256.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'LDAP: Authentication Methods and Security Mechanisms' to Proposed Standard
The IESG has received a request from the LDAP (v3) Revision WG to consider the following document: - 'LDAP: Authentication Methods and Security Mechanisms ' draft-ietf-ldapbis-authmeth-18.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-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-authmeth-18.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
