Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
--On Friday, June 08, 2012 12:49 -0700 Paul Hoffman paul.hoff...@vpnc.org wrote: I am supporting not putting anything about appeals to the ISOC Board in the Tao. They do not apply to novices. Paul, that suggests something else which the Tao does sort of say but maybe not clearly enough in context. A novice really shouldn't attempt to exercise any of our processes, especially the more advanced/complex ones like appeals, without either a lot of observation or seeking out advice and guidance. It is too easy to get tangled up in things or have an almost-reasonable request or suggestion rejected because it is badly presented. Fortunately the community is ultimately pretty friendly to newcomers/novices. While that friendliness may not express itself proactively, I've encountered very few people who would not try to help get a novice pointed in the right direction if asked for advice. IMO, the more clearly and broadly that can be said the better. john
RE: [Fwd: Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
To be fair, nearly half the attendees come from that continent. Even when the meetings are held in Taipei or Paris. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Randy Bush Sent: 10 June 2012 03:33 To: Glen Zorn Cc: IETF Disgust Subject: Re: [Fwd: Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC] A quick check of the Upcoming IETF Meetings calendar (http://www.ietf.org/meeting/upcoming.html) shows that the next meeting in Asia is scheduled for November 2015, while the last was November 2011. How does a 4 year gap map to approximately once a year? this winter we are meeting in georgia (not the one in the caucasus) and florida. what more diversity do you want? canada? randy
Re: [Fwd: Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
The intended rotation cycle is still 1-1-1 for NA-EU-AP regions, but it's all dependent on finding suitable and available venues and willing hosts and sponsors. Changing the text of the document would imply a change in policy or normal state of things which there hasn't been. Hmm. So a dream world is the normal state of things...I guess really should read this thing, if only to discover what other fantasies have been made real through the magic of rough consensus. Gee, while we're at it, perhaps we should remind novices that the best way to make progress is to send snarky comments rather than revised text. Old: Currently, the IETF meets in North America, Europe, and Asia, approximately once a year in each region. New: Currently, the IETF meets in North America, Europe, and Asia. The intention is to meet once a year in each region, although due to scheduling issues there are often more meetings in North America and fewer in Asia. R's, John
Re: [Fwd: Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On Sun, 10 Jun 2012, John Levine wrote: Old: Currently, the IETF meets in North America, Europe, and Asia, approximately once a year in each region. New: Currently, the IETF meets in North America, Europe, and Asia. The intention is to meet once a year in each region, although due to scheduling issues there are often more meetings in North America and fewer in Asia. R's, John Friendly amendment: Currently, the IETF meets in North America, Europe, and Asia. The intention is to meet once a year in each region, although due to scheduling issues there are often more meetings in North America and fewer in Asia and Europe. eofa There are many reasons for the current situation, but this is probably not the forum/context to discuss this. Let me just draw everyones attention to the message sent out today by the IETF Chair regarding hosting of the upcoming Berlin meeting. Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo
Re: [Fwd: Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
Currently, the IETF meets in North America, Europe, and Asia. The intention is to meet once a year in each region, although due to scheduling issues there are often more meetings in North America and fewer in Asia. s/intention/intent/
[Fwd: Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
Looks like this didn't get through the first time. From: Glen Zorn glenz...@gmail.com To: ietf@ietf.org Cc: glenz...@cmail.com Subject: Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC Date: Sat, 09 Jun 2012 08:03:14 +0700 On Thu, 2012-06-07 at 16:09 -0700, Paul Hoffman wrote: ... • The Tao mentions that we meet once a year in each region. I don't think that's true for Asia at this point. The text might call out that we meet where there are participants, or words that the IAOC might provide. It doesn't say that. It says approximately once a year in each region. That is still true. A quick check of the Upcoming IETF Meetings calendar (http://www.ietf.org/meeting/upcoming.html) shows that the next meeting in Asia is scheduled for November 2015, while the last was November 2011. How does a 4 year gap map to approximately once a year? ...
Re: [Fwd: Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
A quick check of the Upcoming IETF Meetings calendar (http://www.ietf.org/meeting/upcoming.html) shows that the next meeting in Asia is scheduled for November 2015, while the last was November 2011. How does a 4 year gap map to approximately once a year? this winter we are meeting in georgia (not the one in the caucasus) and florida. what more diversity do you want? canada? randy
Re: [Fwd: Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
The intended rotation cycle is still 1-1-1 for NA-EU-AP regions, but it's all dependent on finding suitable and available venues and willing hosts and sponsors. Changing the text of the document would imply a change in policy or normal state of things which there hasn't been. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo On Sun, 10 Jun 2012, Glen Zorn wrote: A quick check of the Upcoming IETF Meetings calendar (http://www.ietf.org/meeting/upcoming.html) shows that the next meeting in Asia is scheduled for November 2015, while the last was November 2011. How does a 4 year gap map to approximately once a year?
Re: [Fwd: Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On Sat, 2012-06-09 at 18:09 -0700, Ole Jacobsen wrote: The intended rotation cycle is still 1-1-1 for NA-EU-AP regions, but it's all dependent on finding suitable and available venues and willing hosts and sponsors. Changing the text of the document would imply a change in policy or normal state of things which there hasn't been. Hmm. So a dream world is the normal state of things...I guess really should read this thing, if only to discover what other fantasies have been made real through the magic of rough consensus. However, since this is a guide for the novice, I might remind folks that there is chance that, lacking real experience, the novices in question might actually believe what's in it -- a dangerous prospect it seems. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo On Sun, 10 Jun 2012, Glen Zorn wrote: A quick check of the Upcoming IETF Meetings calendar (http://www.ietf.org/meeting/upcoming.html) shows that the next meeting in Asia is scheduled for November 2015, while the last was November 2011. How does a 4 year gap map to approximately once a year?
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
Sigh. These multiple threads are, IMO, a wonderful exposition of how the IETF can waste a tremendous amount of collective time and energy fine-tuning a document and/or procedures by a very large committee. If nothing else, the process often leads to victory by exhaustion as people just give up, leaving the discussion who have the energy (or, as a colleague would put it, too much time on their hands. I plead somewhat guilty for getting sucked back in, but I want to make a few suggestions: (1) Can we figure out a way to converge on whether we are editing an RFC-to-be by committee or planning something web-ish (not distinguishing between web page and wiki for the moment? If the former, then there are several irrelevant threads. If the latter, then there are a lot of useful comments that should be handled in a different way. (2) At one time, one of the key differences between the IETF and other bodies in more or less the same business was that we allowed ourselves considerable flexibility to match how we did things to the situation and our needs while those other bodies had to spend huge amounts of energy getting agreement on the exact way that something should be done before attempting to do it. If we are going down the web-ish path and haven't lost that sense of flexibility entirely, I would like to recommend that we perform a let's try this, see how it works, and then work out specific procedures for the future experimental engineering process rather than trying to get the details right by committee. In particular, I suggest that, for the initial round of turning the current I-D into something web-ish and establishing a model for handling suggestions and changes, we: Ii) We appoint an Editor (or Editor-in-chief). (ii) Based on precedent, history, a much-better-than-decent job, authorship of the I-D, and an orderly transition from one publication model to the other, we should appoint Paul by acclamation. By that I mean that someone, ideally Russ, gets on the list and says is there really any objection to appointing Paul... if not, done. That skips, for the present, wasting more time figuring out who makes the appointment, whose approval is needed, whether we need a whole process (e.g., of volunteers, lists and comments) similar to how we handle IAOC and ISOC BoT appointments, and a whole series of other ways in which we could waste a lot of time and then get the same result. (iii) Let's give the Editor six or nine months of discretion and experimental time about formats (let's at least start with a controlled list of people who can make changes until we have a document in place and a bit of experience -- I see no substantive difference between a controlled-authorship Wiki and a controlled-authorship web page other than the tools used although we could spend lots of time debating the non-substantive differences), editorial board composition, how to solicit and receive input, etc. We encourage the editor to consult with the IESG to the extent to which the IESG (or some IESG-chosen subcommittee) is inclined to be involved. (iv) At the end of that period, we see if we can find an efficient way to examine the experience, draw ideas together, and figure out what we really want to do for the long term and what procedures are needed to do it. I think I just said BOF in Atlanta or Orlando rather than mail storm on the IETF list, but, if we need to do a mail storm, let's at least have some experience and a web-based document on which to focus, rather than trying to have editorial, procedural, organizational, and format suggestions all mixed up with each other. If we all really have this many spare cycles, perhaps many of them would be better spent getting the document (page, wiki,...) right rather than tuning procedures. Perhaps some of them might even be better invested in protocol specification. And, on that note, I'm going to go try to spend a little time on a neglected WG. best, john
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
On Jun 7, 2012, at 10:20 PM, Paul Hoffman wrote: On Jun 7, 2012, at 6:13 PM, Bradner, Scott wrote: On Jun 7, 2012, at 7:09 PM, Paul Hoffman wrote: On May 30, 2012, at 11:22 PM, Eliot Lear wrote: • It's probably worth adding a word or two about the fact that the ISOC Board is the final appellate avenue in the standardization process. In this way it may also make sense to move Section 3.2.1 further back behind the IAB. I have heard that as well, but cannot find it in RFC 2026 or any of the RFCs that update 2026 (3667 3668 3932 3978 3979 5378 5657 5742 6410). It should only be in the Tao if we can point to where the rule comes from. see RFC 2026 section 6.5.3 6.5.3 Questions of Applicable Procedure Further recourse is available only in cases in which the procedures themselves (i.e., the procedures described in this document) are claimed to be inadequate or insufficient to the protection of the rights of all parties in a fair and open Internet Standards Process. Claims on this basis may be made to the Internet Society Board of Trustees. The President of the Internet Society shall acknowledge such an appeal within two weeks, and shall at the time of acknowledgment advise the petitioner of the expected duration of the Trustees' review of the appeal. The Trustees shall review the situation in a manner of its own choosing and report to the IETF on the outcome of its review. The Trustees' decision upon completion of their review shall be final with respect to all aspects of the dispute. note that the appeal to the ISOC BopT is only if the claim is that the rules are broken not the application of the rules Exactly right. What Eliot said, and others have said, is that the ISOC board is the final appellate avenue in the standardization process. That's quite different than the rules are broken. just to be clear - saying final appellate avenue in the standardization process. could be read as meaning that a appeal of a technical decision could be made to the ISOC Board and that is not the case - this is why I used different language not sure which you were supporting Scott there has never been such an appeal Happily noted. --Paul Hoffman
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
On Jun 8, 2012, at 12:46 PM, Bradner, Scott wrote: just to be clear - saying final appellate avenue in the standardization process. could be read as meaning that a appeal of a technical decision could be made to the ISOC Board and that is not the case - this is why I used different language not sure which you were supporting I am supporting not putting anything about appeals to the ISOC Board in the Tao. They do not apply to novices. --Paul Hoffman
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
All, Based on this explanation from Scott I withdraw my suggestion. Text can stay as it is. Eliot On 6/8/12 9:46 PM, Bradner, Scott wrote: On Jun 7, 2012, at 10:20 PM, Paul Hoffman wrote: On Jun 7, 2012, at 6:13 PM, Bradner, Scott wrote: On Jun 7, 2012, at 7:09 PM, Paul Hoffman wrote: On May 30, 2012, at 11:22 PM, Eliot Lear wrote: • It's probably worth adding a word or two about the fact that the ISOC Board is the final appellate avenue in the standardization process. In this way it may also make sense to move Section 3.2.1 further back behind the IAB. I have heard that as well, but cannot find it in RFC 2026 or any of the RFCs that update 2026 (3667 3668 3932 3978 3979 5378 5657 5742 6410). It should only be in the Tao if we can point to where the rule comes from. see RFC 2026 section 6.5.3 6.5.3 Questions of Applicable Procedure Further recourse is available only in cases in which the procedures themselves (i.e., the procedures described in this document) are claimed to be inadequate or insufficient to the protection of the rights of all parties in a fair and open Internet Standards Process. Claims on this basis may be made to the Internet Society Board of Trustees. The President of the Internet Society shall acknowledge such an appeal within two weeks, and shall at the time of acknowledgment advise the petitioner of the expected duration of the Trustees' review of the appeal. The Trustees shall review the situation in a manner of its own choosing and report to the IETF on the outcome of its review. The Trustees' decision upon completion of their review shall be final with respect to all aspects of the dispute. note that the appeal to the ISOC BopT is only if the claim is that the rules are broken not the application of the rules Exactly right. What Eliot said, and others have said, is that the ISOC board is the final appellate avenue in the standardization process. That's quite different than the rules are broken. just to be clear - saying final appellate avenue in the standardization process. could be read as meaning that a appeal of a technical decision could be made to the ISOC Board and that is not the case - this is why I used different language not sure which you were supporting Scott there has never been such an appeal Happily noted. --Paul Hoffman
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
wfm On Jun 8, 2012, at 3:49 PM, Paul Hoffman wrote: On Jun 8, 2012, at 12:46 PM, Bradner, Scott wrote: just to be clear - saying final appellate avenue in the standardization process. could be read as meaning that a appeal of a technical decision could be made to the ISOC Board and that is not the case - this is why I used different language not sure which you were supporting I am supporting not putting anything about appeals to the ISOC Board in the Tao. They do not apply to novices. --Paul Hoffman
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
On Thu, 2012-06-07 at 16:09 -0700, Paul Hoffman wrote: ... • The Tao mentions that we meet once a year in each region. I don't think that's true for Asia at this point. The text might call out that we meet where there are participants, or words that the IAOC might provide. It doesn't say that. It says approximately once a year in each region. That is still true. A quick check of the Upcoming IETF Meetings calendar (http://www.ietf.org/meeting/upcoming.html) shows that the next meeting in Asia is scheduled for November 2015, while the last was November 2011. How does a 4 year gap map to approximately once a year? ...
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
On May 30, 2012, at 11:22 PM, Eliot Lear wrote: • I've been told by some that the Mission of the IETF is in some way out of date. I don't know whether this is true, but if it is, the reference should be removed. As others pointed out, it is a BCP, it is the only BCP we have that covers the mission, so it should probably stay. • It's probably worth adding a word or two about the fact that the ISOC Board is the final appellate avenue in the standardization process. In this way it may also make sense to move Section 3.2.1 further back behind the IAB. I have heard that as well, but cannot find it in RFC 2026 or any of the RFCs that update 2026 (3667 3668 3932 3978 3979 5378 5657 5742 6410). It should only be in the Tao if we can point to where the rule comes from. • I don't know about anyone else, but my experience has changed with regard to there being a fair amount of time for socializing. I would say there is a modest amount of time for socializing. I have met with many first-timers at IETF meetings, and they have a fair amount of time for socializing. The more meetings you go to, the less time you have to socialize. I have added for many participants to the sentence. • The Tao mentions that we meet once a year in each region. I don't think that's true for Asia at this point. The text might call out that we meet where there are participants, or words that the IAOC might provide. It doesn't say that. It says approximately once a year in each region. That is still true. • The last paragraph in Section 4 is outdated. Everyone uses wireless these days– everywhere at nearly every meeting. Good catch. • 4.12 really should be a top level section (moved further back). This was a conscious decision made for the last Tao: put it in the middle to give the reader a sense of what the can do. • Section 5 (Working Groups) really should be moved forward (after Section 3 but before what is now Section 4). The Tao is still normally read by people coming to their first meeting, not by someone participating for the first time on a WG mailing list. • Move acknowledgments to the back. As it stands that text forms a disconnect between the Intro and later sections. Done. --Paul Hoffman
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
On Jun 7, 2012, at 7:09 PM, Paul Hoffman wrote: On May 30, 2012, at 11:22 PM, Eliot Lear wrote: • It's probably worth adding a word or two about the fact that the ISOC Board is the final appellate avenue in the standardization process. In this way it may also make sense to move Section 3.2.1 further back behind the IAB. I have heard that as well, but cannot find it in RFC 2026 or any of the RFCs that update 2026 (3667 3668 3932 3978 3979 5378 5657 5742 6410). It should only be in the Tao if we can point to where the rule comes from. see RFC 2026 section 6.5.3 6.5.3 Questions of Applicable Procedure Further recourse is available only in cases in which the procedures themselves (i.e., the procedures described in this document) are claimed to be inadequate or insufficient to the protection of the rights of all parties in a fair and open Internet Standards Process. Claims on this basis may be made to the Internet Society Board of Trustees. The President of the Internet Society shall acknowledge such an appeal within two weeks, and shall at the time of acknowledgment advise the petitioner of the expected duration of the Trustees' review of the appeal. The Trustees shall review the situation in a manner of its own choosing and report to the IETF on the outcome of its review. The Trustees' decision upon completion of their review shall be final with respect to all aspects of the dispute. note that the appeal to the ISOC BopT is only if the claim is that the rules are broken not the application of the rules there has never been such an appeal Scott
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
On Jun 7, 2012, at 6:13 PM, Bradner, Scott wrote: On Jun 7, 2012, at 7:09 PM, Paul Hoffman wrote: On May 30, 2012, at 11:22 PM, Eliot Lear wrote: • It's probably worth adding a word or two about the fact that the ISOC Board is the final appellate avenue in the standardization process. In this way it may also make sense to move Section 3.2.1 further back behind the IAB. I have heard that as well, but cannot find it in RFC 2026 or any of the RFCs that update 2026 (3667 3668 3932 3978 3979 5378 5657 5742 6410). It should only be in the Tao if we can point to where the rule comes from. see RFC 2026 section 6.5.3 6.5.3 Questions of Applicable Procedure Further recourse is available only in cases in which the procedures themselves (i.e., the procedures described in this document) are claimed to be inadequate or insufficient to the protection of the rights of all parties in a fair and open Internet Standards Process. Claims on this basis may be made to the Internet Society Board of Trustees. The President of the Internet Society shall acknowledge such an appeal within two weeks, and shall at the time of acknowledgment advise the petitioner of the expected duration of the Trustees' review of the appeal. The Trustees shall review the situation in a manner of its own choosing and report to the IETF on the outcome of its review. The Trustees' decision upon completion of their review shall be final with respect to all aspects of the dispute. note that the appeal to the ISOC BopT is only if the claim is that the rules are broken not the application of the rules Exactly right. What Eliot said, and others have said, is that the ISOC board is the final appellate avenue in the standardization process. That's quite different than the rules are broken. there has never been such an appeal Happily noted. --Paul Hoffman
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 5/31/12 02:05 , Klaas Wierenga wrote: On 5/31/12 10:58 AM, Stephen Farrell wrote: I'm with Brian and Yoav on this. I don't see a need to change here. And I do think we might lose something if we become too PC. If a bunch of non-native speakers did say yes, I found that made the document less useful then I'd be more convinced that all these changes were worth it. As a non-native speaker I agree. I think colloquial is fine. The one thing causes me some trouble is all the references that Americans make to sports that nobody in the civilized world cares about ;-) (left field, Hail Mary passes If the Congregatio a Sancta Cruce hadn't come to North America from Le Mans France and specifically to South Bend Indiana there would be no Hail Mary.
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On May 31, 2012:6:36 PM, at 6:36 PM, Ben Niven-Jenkins wrote: On 31 May 2012, at 09:16, Ole Jacobsen wrote: Sounds like a difficult thing to do with any kind of predictable or measurable outcome, although it might be fun to ask the Brits if they understand everything the Americans are saying and vice versa :-) I don't really have any issues understanding American English but I'm regularly gobsmacked by how many North Americans struggle to understand some things that I say :-) I can personally attest to that. *) --Tom
Re: IANA [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On May 31, 2012, at 9:38 PM, Fred Baker wrote: The IAB decides who acts as the IETF's IANA. RFC 2860 again. http://ntia.doc.gov/page/iana-functions-purchase-order You're correct that NTIA wants to pay someone to do the protocol parameter job. Err, pay isn't the right word here: it's a zero dollar contract (although this doesn't preclude the contract assignee from charging to recover costs (as long as NTIA agrees)). The IAB can decide to not use that office. Yep. Of course, what happens after that is left to the reader as an exercise. Fortunately, I believe (hope?) everybody wants the same thing wrt administrative oversight of the IANA so that exercise won't need to be handed in to the teacher. Regards, -drc
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
Hi, I agree with much of what Peter Saint-Andre wrote. In addition I suggest the following changes: * I've been told by some that the Mission of the IETF is in some way out of date. I don't know whether this is true, but if it is, the reference should be removed. * It's probably worth adding a word or two about the fact that the ISOC Board is the final appellate avenue in the standardization process. In this way it may also make sense to move Section 3.2.1 further back behind the IAB. * I don't know about anyone else, but my experience has changed with regard to there being a fair amount of time for socializing. I would say there is a modest amount of time for socializing. * The Tao mentions that we meet once a year in each region. I don't think that's true for Asia at this point. The text might call out that we meet where there are participants, or words that the IAOC might provide. * The last paragraph in Section 4 is outdated. Everyone uses wireless these days– everywhere at nearly every meeting. * 4.12 really should be a top level section (moved further back). * Section 5 (Working Groups) really should be moved forward (after Section 3 but before what is now Section 4). * Move acknowledgments to the back. As it stands that text forms a disconnect between the Intro and later sections. Finally I have been told that the Tao is meant to be a living document, e.g., a wiki. Is that now not to be the case? Eliot On 5/31/12 12:56 AM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force' draft-hoffman-tao4677bis-15.txt as Informational RFC The Tao of the IETF has grown a bit stale. For example, many of the tasks that were requested by email are now done with online tools, completely avoiding manual intervention by the Secretariat. This is an effort to refresh the document. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-06-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview. The file can be obtained via http://datatracker.ietf.org/doc/draft-hoffman-tao4677bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-hoffman-tao4677bis/ballot/ No IPR declarations have been submitted directly on this I-D.
Mission statement [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 2012-05-31 07:22, Eliot Lear wrote: ... * I've been told by some that the Mission of the IETF is in some way out of date. I don't know whether this is true, That sound like somebody's personal opinion, but it is still a BCP and therefore still represents IETF consensus. but if it is, the reference should be removed. I don't think so. Brian
Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 2012-05-31 02:49, Peter Saint-Andre wrote: Overall I continue to think that this is a helpful document, as were its predecessors. That said, I would assume that many potential readers of this document are not native English speakers. Thus I suggest that the more colloquial words and phrases might best be changed to more standard English. Have we any evidence that this is a problem for the community? The informal style is one of the virtues of the Tao. I'd be sorry to lose it. Maybe we can ask some of the people concerned, such as recent presenters of the Newcomers tutorial in languages other than English. Brian
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 5/31/2012 8:36 AM, Brian E Carpenter wrote: Have we any evidence that this is a problem for the community? The informal style is one of the virtues of the Tao. I'd be sorry to lose it. Let's separate use of colloquial language from overall writing style. It is possible to write in an informal style without using colloquialisms. I could, for example, insert some side comment here that would be informal and lack colloquialisms. By some measures, the preceding sentence is an example of exactly that... Colloquialisms are well known to impede understanding by non-native English speakers. So, do you have any evidence that this is /not/ a problem for that part of our community? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
ICANN relationship [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
3.2.4. IANA (Internet Assigned Numbers Authority) The core registrar for the IETF's activities is the IANA (see http://www.iana.org). Many Internet protocols require that someone keep track of protocol items that were added after the protocol came out. Typical examples of the kinds of registries needed are for TCP port numbers and MIME types. The IAB has designated the IANA organization to perform these tasks, and the IANA's activities are financially supported by ICANN, the Internet Corporation for Assigned Names and Numbers. The IAB selected ICANN, and the IANA activities are provided for free as specified in [RFC2860]. The phrase The IAB selected ICANN is, as the saying goes, economical with the truth. The fact is that we had no choice at the time. Suggestion for the last sentence: The IAB and the IETF established a Memorandum of Understanding with ICANN [RFC2860], under which the IANA services are provided for free to the IETF. Nit: Editor is a separate job. Today, these jobs are preformed by s/preformed/performed/ Regards Brian Carpenter
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 2012-05-31 07:59, Dave Crocker wrote: On 5/31/2012 8:36 AM, Brian E Carpenter wrote: Have we any evidence that this is a problem for the community? The informal style is one of the virtues of the Tao. I'd be sorry to lose it. Let's separate use of colloquial language from overall writing style. It is possible to write in an informal style without using colloquialisms. I could, for example, insert some side comment here that would be informal and lack colloquialisms. By some measures, the preceding sentence is an example of exactly that... Colloquialisms are well known to impede understanding by non-native English speakers. So, do you have any evidence that this is /not/ a problem for that part of our community? I actually have no evidence either way; that's why I suggested asking some of them ;-) Brian
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 5/31/2012 9:24 AM, Brian E Carpenter wrote: I actually have no evidence either way; that's why I suggested asking some of them;-) 1. Reliance on self-reporting for such things is methodologically problematic. It presumes a degree of self-awareness that is often missing. For example a native speaker of a language that uses noun doubling -- saying the noun twice -- to indicate plurals was quite insistent with me that that wasn't the rule. 2. To claim a lack of evidence presumes some previous effort to acquire it. However a quick search discloses: http://journals.cambridge.org/action/displayAbstract;jsessionid=054711CCAB4AFB348F7E70C9079E7305.journals?fromPage=onlineaid=2546012 http://dc.library.okstate.edu/cdm/singleitem/collection/theses/id/1031/rec/9 http://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=3ved=0CF0QFjACurl=http%3A%2F%2Fscholarcommons.usf.edu%2Fcgi%2Fviewcontent.cgi%3Farticle%3D1255%26context%3Detdei=iyDHT4eBB874sgaa-rGQDwusg=AFQjCNFnYm2MzlDnknB6AzfB0Oi4tUVyVg among others. The mere existence of these ought to make clear that there is a significant issue in the use of colloquialisms with non-native listeners. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On Thu, 31 May 2012, Brian E Carpenter wrote: On 2012-05-31 02:49, Peter Saint-Andre wrote: That said, I would assume that many potential readers of this document are not native English speakers. Thus I suggest that the more colloquial words and phrases might best be changed to more standard English. Have we any evidence that this is a problem for the community? The informal style is one of the virtues of the Tao. I'd be sorry to lose it. Informal style does not equal heavy use of (localized) colloquialisms. My copy editor always reminds me that I have an international readership and thus should avoid such phrases as the ones listed by Peter. Maybe we can ask some of the people concerned, such as recent presenters of the Newcomers tutorial in languages other than English. Sounds like a difficult thing to do with any kind of predictable or measurable outcome, although it might be fun to ask the Brits if they understand everything the Americans are saying and vice versa :-) Having evindence that someone did not understand a particular phrase gets into the weeds of cultural differences which go way beyond a group of engineers who don't understand the meaning of approximately. I suggest we NOT conduct that particular line of questioning, really. Brian Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
Hi Peter I tend to disagree. I am not a native English speaker, although I will admit to watching way too much American TV in my teens. I believe most of these should be recognizable to anyone who has learned enough English to participate meaningfully in IETF mailing lists and discussions. What you haven't seen before, you can usually either deduce (cosmic significance would obviously mean a lot of significance), or else easily searchable on the net or in idiom books, although I did get some incorrect results searching google for warm fuzzy feeling. Yes, we should keep both messages and documents straight-forward, and avoid cultural references and memes (like home base or I do have a Dalek but I do not yet have a Tardis, or any reference to taking arrows to the knee), but I don't think it's necessary to go back and prune all idioms out of a document. Yoav On May 31, 2012, at 4:49 AM, Peter Saint-Andre wrote: Overall I continue to think that this is a helpful document, as were its predecessors. That said, I would assume that many potential readers of this document are not native English speakers. Thus I suggest that the more colloquial words and phrases might best be changed to more standard English. Naturally one can quibble about particulars, but here are some examples as I see them: get into the swing of things give them a warm, fuzzy feeling happenings unsung heroes home base pet project pet peeve leaps and bounds get technical discussions of cosmic significance gatherings of the tribes kicks in breath of fresh air big-name take the pluge I realize that such words and phrases lend a friendly tone to the document, but IMHO that friendliness will be lost on non-native speakers.
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
On 5/31/2012 8:22 AM, Eliot Lear wrote: The Tao mentions that we meet once a year in each region. I don't think that's true for Asia at this point. The text might call out that we meet where there are participants, or words that the IAOC might provide. The relatively recent change in policy is to average one meeting in each region every year. The current departure from that policy is due to logistics and cost issues, not a change in policy. Hence, possible language could be: The IETF policy is to meeting in each region once a year, as possible. Or the like. d/ ps. this note is a personal offering, not an IAOC one. -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
At 15:56 30-05-2012, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force' draft-hoffman-tao4677bis-15.txt as Informational RFC In the Introduction Section: This will give them a warm, fuzzy feeling and enable them to make the meeting and the Working Group discussions more productive for everyone. Reading 51 pages may give people who are a bit stale a warm, fuzzy feeling. I don't think that is what newcomers seek. Reading this draft does not make the meeting or Working Group discussions more productive except for people who have been around before November, 2008. Section 3.2.1 mentions ISOC (Internet Society). Didn't ISOC rebrand itself to Internet Society? The ISOC is one of the major unsung heroes of the Internet. This sounds like a line from the marketing department. According to www.ietf.org, the Internet Engineering Task Force (IETF) is an organized activity of the Internet Society (ISOC). This draft places ISOC at the top of the hierarchy. Does that mean that ISOC runs the IETF? In Section 3.2.2: It administers the process according to the rules and procedures that have been ratified by the ISOC Board of Trustees. Isn't the process (and rules) documented through BCPs? Are the BCPs ratified by the ISOC Board of Trustees? Because of this, one of the main reasons that the IESG might block something that was produced in a WG is that the result did not really gain consensus in the IETF as a whole, that is, among all of the Working Groups in all Areas. The above does not seem correct to me. All working groups do not participate through this mailing list. This list is more of a venue for the IETF as a whole, i.e. its participants and not its Working Groups, to provide substantive comments about a draft during a Last Call. These substantive comments tends to include +1 as it is viewed as a way for some participants to make their vote heard. The origins of the +1 can be traced back to another community, which is unrelated to the IETF, where contributors actually vote. In Section 3.2.3: Approves the appointment of the IANA Isn't IANA more of a U.S. Government decision? In Section 3.2.5: Once an RFC is published, it is never revised. That can be debatable [1]. In Section 3.2.7: Few IETF participants come into contact with the IETF Trust, which is a good sign that they are quietly doing their job. This sounds more like marketing. In Section 3.3: 'People who would like to get technical may also join the IETF general discussion list' People who would like to get a vague idea of IETF politics may also join the IETF general discussion lists. Some of the topics discussed on that mailing list are: - What is a MUST - Future Handling of the Blue Sheets - IETF aging - Proposed IESG Statements (not even mentioned in the draft) - Is IPv6 bad news - Why is DNS broken - A proxy war between the IETF and the ITU - Shared IPv4 address space I wouldn't describe the above-mentioned topics as being of cosmic significance. In Section 4: primary goal is to reinvigorate the WGs to get their tasks done After watching two people taking shots at low flying ducks, my guess is that such action does have an invigorating effect. Those ducks must have read the current version of the Tao to learn the inner workings. There were a couple of unfortunate accidents [1]. although IASA kicks in additional funds for things such as the audio broadcast of some Working Group sessions. This is an unnecessary detail. How important is it to know that some body within the IETF called IASA is paying for that? There is no exposition hall Isn't there a plan to have an exposition during meetings? In Section 4.5: These are used for long-term archival purpose to show how many people came to a particular meeting and, in rare cases, exactly who showed up. What's the consensus on Blue Sheets these days? In Section 5.2: Any decision made at a face-to-face meeting must also gain consensus on the WG mailing list. Are decisions taken during meetings or only on the mailing list? There are numerous examples of important decisions made in WG meetings that are later overturned on the mailing list, often because someone who couldn't attend the meeting pointed out a serious flaw in the logic used to come to the decision. The above does not seem correct. In Section 7.3: '[RFC2223], Instructions to RFC Authors, describes the submission format.' Isn't RFC 2223 considered as Historic? I doubt that the RFC editor uses that RFC. In Section 7.4: To become an Internet Standard, an RFC must have multiple interoperable implementations and the unused features in the Proposed Standard must be removed; there are additional requirements listed in [BCP9]. Is
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
I'm with Brian and Yoav on this. I don't see a need to change here. And I do think we might lose something if we become too PC. If a bunch of non-native speakers did say yes, I found that made the document less useful then I'd be more convinced that all these changes were worth it. On 05/31/2012 08:47 AM, Dave Crocker wrote: On 5/31/2012 9:24 AM, Brian E Carpenter wrote: I actually have no evidence either way; that's why I suggested asking some of them;-) 1. Reliance on self-reporting for such things is methodologically problematic. It presumes a degree of self-awareness that is often missing. For example a native speaker of a language that uses noun doubling -- saying the noun twice -- to indicate plurals was quite insistent with me that that wasn't the rule. 2. To claim a lack of evidence presumes some previous effort to acquire it. However a quick search discloses: http://journals.cambridge.org/action/displayAbstract;jsessionid=054711CCAB4AFB348F7E70C9079E7305.journals?fromPage=onlineaid=2546012 Paywalled. Abstract says comprehen-sibility of the non-native's interlanguage so is a worse sinner IMO:-) http://dc.library.okstate.edu/cdm/singleitem/collection/theses/id/1031/rec/9 Drives NoScript bonkers and needs some kind of FF plug in. http://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=3ved=0CF0QFjACurl=http%3A%2F%2Fscholarcommons.usf.edu%2Fcgi%2Fviewcontent.cgi%3Farticle%3D1255%26context%3Detdei=iyDHT4eBB874sgaa-rGQDwusg=AFQjCNFnYm2MzlDnknB6AzfB0Oi4tUVyVg 289 pages, so only read abstract. That's about adolescents. My experience at IETF meetings is that more native English speakers seem to behave like adolescents, but maybe that's just me:-) It does make the point that there's a (presumably positive) correlation between understanding of idiom and academic achievement, I guess the argument could also be made that the Tao should be about as difficult to read as a typical IETF mailing list. S. among others. The mere existence of these ought to make clear that there is a significant issue in the use of colloquialisms with non-native listeners. d/
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 5/31/12 10:58 AM, Stephen Farrell wrote: I'm with Brian and Yoav on this. I don't see a need to change here. And I do think we might lose something if we become too PC. If a bunch of non-native speakers did say yes, I found that made the document less useful then I'd be more convinced that all these changes were worth it. As a non-native speaker I agree. I think colloquial is fine. The one thing causes me some trouble is all the references that Americans make to sports that nobody in the civilized world cares about ;-) (left field, Hail Mary passes etc.) But I think the Tao pretty much avoids those (perhaps Home base is the exception). Klaas On 05/31/2012 08:47 AM, Dave Crocker wrote: On 5/31/2012 9:24 AM, Brian E Carpenter wrote: I actually have no evidence either way; that's why I suggested asking some of them;-) 1. Reliance on self-reporting for such things is methodologically problematic. It presumes a degree of self-awareness that is often missing. For example a native speaker of a language that uses noun doubling -- saying the noun twice -- to indicate plurals was quite insistent with me that that wasn't the rule. 2. To claim a lack of evidence presumes some previous effort to acquire it. However a quick search discloses: http://journals.cambridge.org/action/displayAbstract;jsessionid=054711CCAB4AFB348F7E70C9079E7305.journals?fromPage=onlineaid=2546012 Paywalled. Abstract says comprehen-sibility of the non-native's interlanguage so is a worse sinner IMO:-) http://dc.library.okstate.edu/cdm/singleitem/collection/theses/id/1031/rec/9 Drives NoScript bonkers and needs some kind of FF plug in. http://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=3ved=0CF0QFjACurl=http%3A%2F%2Fscholarcommons.usf.edu%2Fcgi%2Fviewcontent.cgi%3Farticle%3D1255%26context%3Detdei=iyDHT4eBB874sgaa-rGQDwusg=AFQjCNFnYm2MzlDnknB6AzfB0Oi4tUVyVg 289 pages, so only read abstract. That's about adolescents. My experience at IETF meetings is that more native English speakers seem to behave like adolescents, but maybe that's just me:-) It does make the point that there's a (presumably positive) correlation between understanding of idiom and academic achievement, I guess the argument could also be made that the Tao should be about as difficult to read as a typical IETF mailing list. S. among others. The mere existence of these ought to make clear that there is a significant issue in the use of colloquialisms with non-native listeners. d/
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 2012-05-31 04:58, Stephen Farrell wrote: I'm with Brian and Yoav on this. I don't see a need to change here. And I do think we might lose something if we become too PC. If a bunch of non-native speakers did say yes, I found that made the document less useful then I'd be more convinced that all these changes were worth it. Another non-native English speaker here. Didn't have any problem understanding the Tao. Its level of language made me more interested in the IETF. Although my level of English is better than other non-native speakers'. Non-native != bad at English. I think colloquialisms may often be as hard to understand as excellent but seldom-used vocabulary. Should we also dumb down our level of language? Such as this: http://simple.wikipedia.org/wiki/Simple_English_Wikipedia I don't think so. Thanks, Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
From: Simon Perreault simon.perrea...@viagenie.ca I think colloquialisms may often be as hard to understand as excellent but seldom-used vocabulary. Indeed - and now that we have this really cool Internet thingy (it's odd to think that young people have no memory of what the world was like before a large fraction of its information was instantly at one's fingertips - and in 80 years or so, _nobody_ will remember that age personally), one can very easily look up either a recondite word, or an obscure colloquialism, in moments... Noel
Re: Mission statement [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
--On Thursday, May 31, 2012 07:31 +0100 Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 2012-05-31 07:22, Eliot Lear wrote: ... * I've been told by some that the Mission of the IETF is in some way out of date. I don't know whether this is true, That sound like somebody's personal opinion, but it is still a BCP and therefore still represents IETF consensus. Brian, Regardless of how I feel about this particular case, I don't understand how to put your comment in context. In particular, would you * Assert that the IETF is so diligent about its process BCPs that any that have become out of date, overtaken by events, or otherwise irrelevant have been immediately and formally declared obsolete or historic? I have better ways to spend my time at the moment, but I imagine that many members of the community could come up with lists of counterexamples rather quickly (perhaps starting from how long it took us to get automatic review out of RFC 2026). * When a document is revised (updated or obsoleted) omitting a reference that appeared in the earlier version requires a special consensus call rather than treating consensus on the new document, once achieved, as atomic? Granted, the relatively new provisions requiring identification and explanation of what was obsoleted or updated are a step toward making sure that those participating in the consensus process are aware of what happened but (i) those provisions have, no far, not been extended to require a discussion of every changed reference and (ii) are not themselves in a BCP or other document that has been documented as achieving community consensus on the details. Independent of that BCP problem, would you advocate making each new document list all of the references to BCP or Standards Track documents that were not carried forward and identifying the reasons? john
Re: Mission statement [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On Thu, May 31, 2012 at 2:31 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 2012-05-31 07:22, Eliot Lear wrote: ... * I've been told by some that the Mission of the IETF is in some way out of date. I don't know whether this is true, That sound like somebody's personal opinion, but it is still a BCP and therefore still represents IETF consensus. but if it is, the reference should be removed. I don't think so. I just want to support the sense of this message. The mission statement is one of the few things that anchors and orients the work of the IETF -- and personally I like it. If people think it's out of date, let them say explicitly why (they can still do so anonymously) so we can have a real discussion. I don't want to have doubt cast on the mission statement, and have our leadership feel a need to reconsider it, because someone somewhere might have said something general about not liking it. And in any case as long as we have a mission statement the Tao should refer to it. Scott
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
--On Wednesday, May 30, 2012 15:56 -0700 The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'The Tao of IETF: A Novice's Guide to the Internet Engineering TaskForce' draft-hoffman-tao4677bis-15.txt as Informational RFC The Tao of the IETF has grown a bit stale. For example, many of the tasks that were requested by email are now done with online tools, completely avoiding manual intervention by the Secretariat. This is an effort to refresh the document. I'd like to move this discussion up a level from discussions about the present state of the text. The community has concluded several times that certain types of documents are better handled as web pages (wiki or otherwise), by published statements, or even as permanent I-Ds, rather than as archival RFCs. Examples include the Internet Official Protocol Standards sequence, the Requests for Comments Summary, the Instructions to RFC Authors, procedures of the IAOC and other bodies, and a series of IESG statements. I've argued that we use RFCs for anything of normative significance, even when the only marginal value the RFC provides is a good time-stamped snapshot (and sometimes lost those arguments). But this is an Informational document merely provides advice, general guidance about procedures, and pointers to the real specifications. I suggest that, if anything is stale, it is RFC 4677, not the rolling I-D updates that Paul has been maintaining from time to time. I haven't pointed a newcomer to the IETF to the RFC, rather than the current I-D, for years. I assume that others have done similarly. Assuming Paul isn't planning to get this published as an RFC and then immediately retire from the IETF and that we don't have a delusion that this document will not need to be maintained and updated as things change, I propose the following: (1) Establish the Tao as a modified Wiki, complete with live HTML links to relevant documents and other relevant discussions.. Provide some mechanism for comments to the editor or even discussion that works better than the RFC Errata process. Turn maintenance of that page over to a volunteer or two (ideally someone young enough to learn a lot from the process) or the Secretariat. Before someone says cost, please calculate the costs to the community of an extended Last Call in which people debate details of wording. (2) Appoint Paul as chair of an editorial committee with zero or more additional members to be appointed at his discretion subject to advice and consent of the IESG. That committee gets to consider whether to make changes. If they get it wrong, they are subject to the community's normal forms of abuse and, in principle, appeals. That could add a bit of work for the IESG but I suggest only a bit and less than running a Last Call. (3) Replace/ obsolete RFC 4677 by a document modeled on RFC 5000. I.e., it should explain why we are maintaining the Tao as one or more web pages and should provide a durable pointer to how the web page can be found. just my opinion, john
Re: Mission statement [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
John, On 2012-05-31 15:53, John C Klensin wrote: --On Thursday, May 31, 2012 07:31 +0100 Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 2012-05-31 07:22, Eliot Lear wrote: ... * I've been told by some that the Mission of the IETF is in some way out of date. I don't know whether this is true, That sound like somebody's personal opinion, but it is still a BCP and therefore still represents IETF consensus. Brian, Regardless of how I feel about this particular case, I don't understand how to put your comment in context. In particular, would you * Assert that the IETF is so diligent about its process BCPs that any that have become out of date, overtaken by events, or otherwise irrelevant have been immediately and formally declared obsolete or historic? I have better ways to spend my time at the moment, but I imagine that many members of the community could come up with lists of counterexamples rather quickly (perhaps starting from how long it took us to get automatic review out of RFC 2026). True, but adding to what Scott Brim said, where is the evidence that the mission statement is OBE? The comment I was responding to seemed quite gratuitous. * When a document is revised (updated or obsoleted) omitting a reference that appeared in the earlier version requires a special consensus call rather than treating consensus on the new document, once achieved, as atomic? Granted, the relatively new provisions requiring identification and explanation of what was obsoleted or updated are a step toward making sure that those participating in the consensus process are aware of what happened but (i) those provisions have, no far, not been extended to require a discussion of every changed reference and (ii) are not themselves in a BCP or other document that has been documented as achieving community consensus on the details. Independent of that BCP problem, would you advocate making each new document list all of the references to BCP or Standards Track documents that were not carried forward and identifying the reasons? Certainly not, although there might be cases where it was useful. (Since carrier pigeons have gone extinct, the mapping to Avian Carriers has been removed from this specification.) Brian
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
John, On 2012-05-31 16:19, John C Klensin wrote: ... Assuming Paul isn't planning to get this published as an RFC and then immediately retire from the IETF and that we don't have a delusion that this document will not need to be maintained and updated as things change, I propose the following: (1) Establish the Tao as a modified Wiki, complete with live HTML links to relevant documents and other relevant discussions.. Provide some mechanism for comments to the editor or even discussion that works better than the RFC Errata process. Turn maintenance of that page over to a volunteer or two (ideally someone young enough to learn a lot from the process) or the Secretariat. Before someone says cost, please calculate the costs to the community of an extended Last Call in which people debate details of wording. +- some trivia such as avoiding the fuzziness of a wiki, isn't that what http://www.ietf.org/tao.html already achieves? I tend to agree with your suggestions below. Brian (2) Appoint Paul as chair of an editorial committee with zero or more additional members to be appointed at his discretion subject to advice and consent of the IESG. That committee gets to consider whether to make changes. If they get it wrong, they are subject to the community's normal forms of abuse and, in principle, appeals. That could add a bit of work for the IESG but I suggest only a bit and less than running a Last Call. (3) Replace/ obsolete RFC 4677 by a document modeled on RFC 5000. I.e., it should explain why we are maintaining the Tao as one or more web pages and should provide a durable pointer to how the web page can be found. just my opinion, john
IANA [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 2012-05-31 09:24, SM wrote: ... In Section 3.2.3: Approves the appointment of the IANA Isn't IANA more of a U.S. Government decision? The IAB decides who acts as the IETF's IANA. RFC 2860 again. Brian
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 5/31/12 1:05 AM, Klaas Wierenga wrote: As a non-native speaker I agree. I think colloquial is fine. The one thing causes me some trouble is all the references that Americans make to sports that nobody in the civilized world cares about ;-) (left field, Hail Mary passes etc.) But I think the Tao pretty much avoids those (perhaps Home base is the exception). A previous employer's HR team put together training material for those of us who were helping with university recruiting and it was one extended American football metaphor. Since nearly all the engineers who were volunteering were Indian or Chinese it turned out to be more confusing than effective (and not necessarily understandable by North American nerds, either). I tend to use a lot of idiomatic language when I write but I do understand the issues around use of regional idioms, and I note that so far of the non-native speakers who've commented, all are either European or Israeli. I'm wondering if regional idioms are as clear to people from east, southeast, and south Asian countries. Also, for whatever it's worth, the English idioms under discussion all seem to be American. Melinda
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
Stephen Farrell wrote: I'm with Brian and Yoav on this. I don't see a need to change here. And I do think we might lose something if we become too PC. If a bunch of non-native speakers did say yes, I found that made the document less useful then I'd be more convinced that all these changes were worth it. +1 I do not believe that *over*simplyfying the language is beneficial for a clearly non-technical document. Using a language that is similar to discussion on mailing lists should be perfectly OK, as long as the colloquial expressions can still be googled easily, for those not familiar with them. I have to google Dilberts and xkcd every once in a while, an those sometimes contain very local expressions that are really difficult to find -- and still I'm OK with this. -Martin
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On May 31, 2012, at 10:39 PM, Martin Rex wrote: Stephen Farrell wrote: I'm with Brian and Yoav on this. I don't see a need to change here. And I do think we might lose something if we become too PC. If a bunch of non-native speakers did say yes, I found that made the document less useful then I'd be more convinced that all these changes were worth it. +1 I do not believe that *over*simplyfying the language is beneficial for a clearly non-technical document. Using a language that is similar to discussion on mailing lists should be perfectly OK, as long as the colloquial expressions can still be googled easily, for those not familiar with them. I have to google Dilberts and xkcd every once in a while, an those sometimes contain very local expressions that are really difficult to find -- and still I'm OK with this. -Martin I had to look up some things when I ready The Adventures of ACTION ITEM for the first time[1], but the TAO draft is nowhere near that level. Besides, it's essential vocabulary for anyone seeking a career in project management. Yoav [1] http://professionalsuperhero.com/
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 31 May 2012, at 09:16, Ole Jacobsen wrote: Sounds like a difficult thing to do with any kind of predictable or measurable outcome, although it might be fun to ask the Brits if they understand everything the Americans are saying and vice versa :-) I don't really have any issues understanding American English but I'm regularly gobsmacked by how many North Americans struggle to understand some things that I say :-) Ben
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On 5/31/12 15:36 , Ben Niven-Jenkins wrote: On 31 May 2012, at 09:16, Ole Jacobsen wrote: Sounds like a difficult thing to do with any kind of predictable or measurable outcome, although it might be fun to ask the Brits if they understand everything the Americans are saying and vice versa :-) I don't really have any issues understanding American English but I'm regularly gobsmacked by how many North Americans struggle to understand some things that I say :-) Do we spell Standardization with and s or a z? Ben
Re: Colloquial language [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
Do we spell Standardization with and s or a z? Yez. R's, John
Re: IANA [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
Brian E Carpenter wrote: On 2012-05-31 09:24, SM wrote: ... In Section 3.2.3: Approves the appointment of the IANA Isn't IANA more of a U.S. Government decision? The IAB decides who acts as the IETF's IANA. RFC 2860 again. Brian See e.g. http://ntia.doc.gov/page/iana-functions-purchase-order -- - Thierry Moreau
Re: IANA [Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC]
On May 31, 2012, at 7:53 PM, Thierry Moreau wrote: Brian E Carpenter wrote: On 2012-05-31 09:24, SM wrote: ... In Section 3.2.3: Approves the appointment of the IANA Isn't IANA more of a U.S. Government decision? The IAB decides who acts as the IETF's IANA. RFC 2860 again. Brian See e.g. http://ntia.doc.gov/page/iana-functions-purchase-order You're correct that NTIA wants to pay someone to do the protocol parameter job. The IAB can decide to not use that office.
Re: Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
Overall I continue to think that this is a helpful document, as were its predecessors. That said, I would assume that many potential readers of this document are not native English speakers. Thus I suggest that the more colloquial words and phrases might best be changed to more standard English. Naturally one can quibble about particulars, but here are some examples as I see them: get into the swing of things give them a warm, fuzzy feeling happenings unsung heroes home base pet project pet peeve leaps and bounds get technical discussions of cosmic significance gatherings of the tribes kicks in breath of fresh air big-name take the pluge I realize that such words and phrases lend a friendly tone to the document, but IMHO that friendliness will be lost on non-native speakers. Peter -- Peter Saint-Andre https://stpeter.im/
Last Call: draft-hoffman-tao4677bis-15.txt (The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force' draft-hoffman-tao4677bis-15.txt as Informational RFC The Tao of the IETF has grown a bit stale. For example, many of the tasks that were requested by email are now done with online tools, completely avoiding manual intervention by the Secretariat. This is an effort to refresh the document. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2012-06-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the inner workings of IETF meetings and Working Groups, discusses organizations related to the IETF, and introduces the standards process. It is not a formal IETF process document but instead an informational overview. The file can be obtained via http://datatracker.ietf.org/doc/draft-hoffman-tao4677bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-hoffman-tao4677bis/ballot/ No IPR declarations have been submitted directly on this I-D.
