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: Colloquial language
On 5/31/12 7:46 AM, Noel Chiappa wrote: 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... So the way we introduce some people to the IETF is to expect that they will look up fifty unfamiliar words and phrases? Having taught English as a second language, I can attest that some of the idioms and colloquialisms included in this document would have caused puzzlement in my students. It's bad enough that many IETFers speak in a highly colloquial fashion at our meetings. I think it would be a shame if we do not avoid such confusion in our written (and supposedly user-friendly) introduction to the IETF. Showing up at your first IETF meeting is quite enough of taking the plunge [1] for most people. Why make it even more difficult? Peter [1] http://idioms.thefreedictionary.com/take+the+plunge
Re: Colloquial language
From: Peter Saint-Andre stpe...@stpeter.im It's bad enough that many IETFers speak in a highly colloquial fashion at our meetings. ... Showing up at your first IETF meeting is quite enough of taking the plunge [1] for most people. If it's meeting attendees one is worried about, I'd have thought that having common colloquialisms in the document would be a feature, not a bug - people would meet them while facing a computer upon which they could look them up at their leisure, not in a live (and likely fast-moving) conversation. Having said that, I think both sides have decent points, and personally don't have any strong preference. Noel
Re: Colloquial language
I fully agree. One could (perhaps) argue that this document would be a suitable place to INTRODUCE non-native speakers to such language, but then the document really needs to do that rather than have the reader infer meaning based on context. 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 Thu, 31 May 2012, Peter Saint-Andre wrote: On 5/31/12 7:46 AM, Noel Chiappa wrote: 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... So the way we introduce some people to the IETF is to expect that they will look up fifty unfamiliar words and phrases? Having taught English as a second language, I can attest that some of the idioms and colloquialisms included in this document would have caused puzzlement in my students. It's bad enough that many IETFers speak in a highly colloquial fashion at our meetings. I think it would be a shame if we do not avoid such confusion in our written (and supposedly user-friendly) introduction to the IETF. Showing up at your first IETF meeting is quite enough of taking the plunge [1] for most people. Why make it even more difficult? Peter [1] http://idioms.thefreedictionary.com/take+the+plunge
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/
Gen-ART LC/Telechat review of draft-ietf-trill-rbridge-extension-04
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-trill-rbridge-extension-04 Reviewer: Ben Campbell Review Date: 2012-05-31 IETF LC End Date: 2012-06-07 IESG Telechat date: 2012-06-07 Note: Since this draft is on the agenda of the IESG Telechat on the same day that the IETF last call expires, this review is intended for both purposes. Summary: This draft is almost ready for publication as a proposed standard, but I have some clarification questions and comments that should be considered prior to publication. Major issues: None Minor issues: -- section 2, general: Do the authors assume that all TRILL extensions will follow this spec? Since RFC6325 already specifies an extension mechanism, what stops an extension from ignoring this spec and doing something different? Does it hurt if they do? -- section 2, 3rd paragraph from end: Non-critical extensions can be safely ignored. Is that intended to be normative? (Seems like it should be, since behavior for critical extensions is normative). -- section 2.1, 1st paragraph, last sentence: Redundant with normative language in previous section. -- section 2.3, first paragraph: Is the first sentence intended as normative? -- section 6, last paragraph: No security implications of this are mentioned. Is it really a security consideration? Also, is this more likely to be set incorrectly than all the other things that some implementation might screw up, so that it warrants special treatment? Nits/editorial comments: -- section 1: Please expand TRILL on first mention in the body of the document (i.e. not just in the Abstract.) -- section 2: Please expand RBridge and IS-IS on first mention. -- section 2, bullet list, 2nd bullet: ... which would only necessarily affect the RBridge(s) where a TRILL frame is decapsulated Does that mean it always affects the decapsulating RBridge but might effect transit RBridges as well? -- section 2, first paragraph after bullet list: critical hop-by-hop extension I assume this means an extension with the critical flag set? If so, it would be more precise to say that. -- sectio 2.1, 1st paragraph: I'm a little confused by a citation for future documents. Do you mean the cited document as an example of something that might do this (in which case a for example would help), or do you mean to say that document will do this? -- section 2.2, 1st paragraph: Please expand PDU on first mention. -- section 2.3, first paragraph: s/modifictions/modifications -- section 5: Since section 3 is entirely composed of the referenced table, and seems to exist mostly if not entirely for the purpose of this reference, why not just move the table to the IANA considerations section.
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
Making the Tao a web page
On May 31, 2012, at 8:19 AM, John C Klensin wrote: (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. Works for me, other than it should not be a wiki. It should have one editor who takes proposed changes from the community the same way we do it now. Not all suggestions from this community, even from individuals in the leadership, are ones that should appear in such a document. Simpler than the above: make it a web page (as Brian points out, we already have a good URL), have one editor, have one leadership person who approves non-trivial changes (I think IETF Chair fits here well), have a last modified date on it, and update it as needed. If there is consensus in the community to do this, I'm happy to take on the HTMLizing and skip the RFCizing for this round. --Paul Hoffman
Re: Making the Tao a web page
On 01/06/2012 00:04, Paul Hoffman wrote: Works for me, other than it should not be a wiki. It should have one editor who takes proposed changes from the community the same way we do it now. Not all suggestions from this community, even from individuals in the leadership, are ones that should appear in such a document. In practice, if this is to be a living document then it should be open for inspection and poking rather than preserved in formaldehyde and put in a display case, only to be opened occasionally when the curator decides the glass needs some dusting. That way leads to sclerosis. Please put it on a wiki and put all changes through a lightweight review system. If someone makes a change which doesn't work, then it can be reverted quickly and easily. This approach is much more in line with the ietf approach of informality / asking for forgiveness rather than permission / rough consensus + running code / etc. Nick
Re: Making the Tao a web page
On May 31, 2012, at 4:30 PM, Nick Hilliard wrote: On 01/06/2012 00:04, Paul Hoffman wrote: Works for me, other than it should not be a wiki. It should have one editor who takes proposed changes from the community the same way we do it now. Not all suggestions from this community, even from individuals in the leadership, are ones that should appear in such a document. In practice, if this is to be a living document then it should be open for inspection and poking rather than preserved in formaldehyde and put in a display case, only to be opened occasionally when the curator decides the glass needs some dusting. That way leads to sclerosis. Thank you for that most colorful analogy. :-) What I proposed is exactly what we are doing now, except that the changes would appear on the web page instead of an Internet-Draft and, five years later, an RFC. Are you saying that the current system (which you have not commented on until now) is sclerotic (a word that I have wanted to use since I learned it in high school)? Please put it on a wiki and put all changes through a lightweight review system. If someone makes a change which doesn't work, then it can be reverted quickly and easily. This approach is much more in line with the ietf approach of informality / asking for forgiveness rather than permission / rough consensus + running code / etc. In the IETF approach, only the authors of an Internet-Draft can change the contents of that draft. I hope you are not proposing a change to that as well. --Paul Hoffman
Re: Making the Tao a web page
On May 31, 2012, at 4:04 PM, Paul Hoffman wrote: Simpler than the above: make it a web page (as Brian points out, we already have a good URL), have one editor, have one leadership person who approves non-trivial changes (I think IETF Chair fits here well), have a last modified date on it, and update it as needed. If there is consensus in the community to do this, I'm happy to take on the HTMLizing and skip the RFCizing for this round. wfm
Re: Making the Tao a web page
On 5/31/12 5:59 PM, Fred Baker wrote: On May 31, 2012, at 4:04 PM, Paul Hoffman wrote: Simpler than the above: make it a web page (as Brian points out, we already have a good URL), have one editor, have one leadership person who approves non-trivial changes (I think IETF Chair fits here well), have a last modified date on it, and update it as needed. If there is consensus in the community to do this, I'm happy to take on the HTMLizing and skip the RFCizing for this round. wfm Me, too. And I'd volunteer to help maintain it. :) Peter -- Peter Saint-Andre https://stpeter.im/
Re: Making the Tao a web page
Awesome idea, I will be more than happy to be part of it. On Thu, May 31, 2012 at 8:04 PM, Peter Saint-Andre stpe...@stpeter.imwrote: On 5/31/12 5:59 PM, Fred Baker wrote: On May 31, 2012, at 4:04 PM, Paul Hoffman wrote: Simpler than the above: make it a web page (as Brian points out, we already have a good URL), have one editor, have one leadership person who approves non-trivial changes (I think IETF Chair fits here well), have a last modified date on it, and update it as needed. If there is consensus in the community to do this, I'm happy to take on the HTMLizing and skip the RFCizing for this round. wfm Me, too. And I'd volunteer to help maintain it. :) Peter -- Peter Saint-Andre https://stpeter.im/ -- Fadi.Mohsen
Re: Making the Tao a web page
--On Thursday, May 31, 2012 16:04 -0700 Paul Hoffman paul.hoff...@vpnc.org wrote: On May 31, 2012, at 8:19 AM, John C Klensin wrote: (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. Works for me, other than it should not be a wiki. It should have one editor who takes proposed changes from the community the same way we do it now. Not all suggestions from this community, even from individuals in the leadership, are ones that should appear in such a document. Paul, that is precisely what I meant by modified Wiki and the editorial committee comment. Note that I was not only proposing appointing you (in recognition both of doing a good job and of the status quo) but giving you discretion over whether you wanted a committee. If that wasn't clear, I apologize. If it is clear now (whether it was before or not), kumbayah. Simpler than the above: make it a web page (as Brian points out, we already have a good URL), have one editor, have one leadership person who approves non-trivial changes (I think IETF Chair fits here well), have a last modified date on it, and update it as needed. If there is consensus in the community to do this, I'm happy to take on the HTMLizing and skip the RFCizing for this round. Wfm. And also, I think, completely consistent with what I was trying to suggest. Make that IETF Chair or designee and you are back to my editorial committee, modulo my desire to make you the final authority unless extraordinary measures are taken rather than adding to the required task list of the IETF Chair or even the IESG more generally. best, john
Re: Making the Tao a web page
Hi Paul, At 16:04 31-05-2012, Paul Hoffman wrote: needed. If there is consensus in the community to do this, I'm happy to take on the HTMLizing and skip the RFCizing for this round. I'll volunteer to help. Regards, -sm P.S. To see what the Web 3.0 folks are up to, see http://trac.tools.ietf.org/wg/httpbis/trac/wiki
RE: Making the Tao a web page
Wish come true... -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM Sent: Friday, June 01, 2012 8:46 AM To: Paul Hoffman Cc: IETF discussion list Subject: Re: Making the Tao a web page Hi Paul, At 16:04 31-05-2012, Paul Hoffman wrote: needed. If there is consensus in the community to do this, I'm happy to take on the HTMLizing and skip the RFCizing for this round. I'll volunteer to help. Regards, -sm P.S. To see what the Web 3.0 folks are up to, see http://trac.tools.ietf.org/wg/httpbis/trac/wiki This e-mail message (including attachments, if any) is intended for the use of the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete this E-mail message immediately.
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: Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
On Thu, 31 May 2012, The IESG wrote: The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'Updated Specification of the IPv4 ID Field' draft-ietf-intarea-ipv4-id-update-05.txt as Proposed Standard 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-14. 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. I commented on the previous version of this draft during WG last call (as a WG non-member) and supported its publication then. I have looked over the changes in the present version and continue to support its publication. I believe that it addresses an operational deficiency in current IPv4 specifications and largely codifies existing pactice. My one reservation is that I do not think it is strictly necessary to ban re-use of the IPv4 ID value in retransmitted non-atomic IPv4 datagrams. On the other hand, the evidence available to me suggests that existing implementations overwhelmingly comply with this ban anyway, so it does not seem to do any harm. Regards, C. M. Heard
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.
Weekly posting summary for ietf@ietf.org
Total of 76 messages in the last 7 days. script run at: Fri Jun 1 00:53:02 EDT 2012 Messages | Bytes| Who +--++--+ 11.84% |9 | 10.55% |60521 | brian.e.carpen...@gmail.com 6.58% |5 | 4.99% |28656 | bortzme...@nic.fr 5.26% |4 | 5.11% |29344 | hartmans-i...@mit.edu 5.26% |4 | 4.92% |28206 | john-i...@jck.com 3.95% |3 | 2.93% |16803 | stpe...@stpeter.im 1.32% |1 | 5.43% |31182 | bcla...@cisco.com 1.32% |1 | 5.13% |29420 | ron.even@gmail.com 2.63% |2 | 3.35% |19220 | s...@resistor.net 2.63% |2 | 2.54% |14594 | o...@cisco.com 2.63% |2 | 2.39% |13720 | y...@checkpoint.com 2.63% |2 | 2.29% |13169 | paul.hoff...@vpnc.org 2.63% |2 | 2.01% |11525 | d...@dcrocker.net 2.63% |2 | 1.94% |11147 | simon.perrea...@viagenie.ca 2.63% |2 | 1.81% |10366 | jo...@iecc.com 2.63% |2 | 1.66% | 9540 | j...@mercury.lcs.mit.edu 1.32% |1 | 2.40% |13754 | turn...@ieca.com 1.32% |1 | 2.21% |12707 | l...@cisco.com 1.32% |1 | 2.09% |12016 | g...@gtwassociates.com 1.32% |1 | 2.08% |11949 | ietf...@comcast.net 1.32% |1 | 1.91% |10932 | flu...@iii.ca 1.32% |1 | 1.59% | 9123 | mehmet.er...@nsn.com 1.32% |1 | 1.46% | 8382 | kl...@cisco.com 1.32% |1 | 1.46% | 8360 | nar...@us.ibm.com 1.32% |1 | 1.40% | 8049 | stephen.farr...@cs.tcd.ie 1.32% |1 | 1.36% | 7801 | fadi20052...@gmail.com 1.32% |1 | 1.36% | 7797 | basavaraj.pa...@nokia.com 1.32% |1 | 1.35% | 7738 | b...@nostrum.com 1.32% |1 | 1.31% | 7531 | m...@cloudmark.com 1.32% |1 | 1.31% | 7489 | droma...@avaya.com 1.32% |1 | 1.21% | 6922 | melinda.sh...@gmail.com 1.32% |1 | 1.17% | 6697 | me...@globetel.com.ph 1.32% |1 | 1.15% | 6583 | scott.b...@gmail.com 1.32% |1 | 1.10% | 6334 | dcroc...@bbiw.net 1.32% |1 | 1.10% | 6288 | f...@cisco.com 1.32% |1 | 1.09% | 6240 | hous...@vigilsec.com 1.32% |1 | 1.07% | 6112 | i...@ietf.org 1.32% |1 | 1.06% | 6094 | rbar...@bbn.com 1.32% |1 | 1.06% | 6066 | n...@inex.ie 1.32% |1 | 1.06% | 6064 | tb...@textuality.com 1.32% |1 | 1.04% | 5976 | fa...@isi.edu 1.32% |1 | 1.02% | 5826 | he...@pobox.com 1.32% |1 | 1.00% | 5767 | joe...@bogus.com 1.32% |1 | 0.97% | 5567 | pe...@akayla.com 1.32% |1 | 0.96% | 5490 | m...@sap.com 1.32% |1 | 0.95% | 5468 | b...@niven-jenkins.co.uk 1.32% |1 | 0.93% | 5338 | d...@dcrocker.net 1.32% |1 | 0.89% | 5080 | thierry.mor...@connotech.com 1.32% |1 | 0.85% | 4883 | malcolm.be...@zte.com.cn +--++--+ 100.00% | 76 |100.00% | 573836 | Total
Last Call: draft-ietf-xrblock-rtcp-xr-meas-identity-06.txt (Measurement Identity and information Reporting using SDES item and XR Block) to Proposed Standard
The IESG has received a request from the Metric Blocks for use with RTCP's Extended Report Framework WG (xrblock) to consider the following document: - 'Measurement Identity and information Reporting using SDES item and XR Block' draft-ietf-xrblock-rtcp-xr-meas-identity-06.txt as Proposed Standard 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-14. 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 defines an RTP Control Protocol (RTCP) Source Description (SDES) item and an RTCP Extended Report (XR) Block carrying parameters that identify and describe a measurement period, to which one or more other RTCP XR Report Blocks may refer. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-meas-identity/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-meas-identity/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-intarea-ipv4-id-update-05.txt (Updated Specification of the IPv4 ID Field) to Proposed Standard
The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'Updated Specification of the IPv4 ID Field' draft-ietf-intarea-ipv4-id-update-05.txt as Proposed Standard 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-14. 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 The IPv4 Identification (ID) field enables fragmentation and reassembly, and as currently specified is required to be unique within the maximum lifetime for all datagrams with a given source/destination/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFC791, RFC1122, and RFC2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update/ballot/ No IPR declarations have been submitted directly on this I-D.
WG Review: System for Cross-domain Identity Management (SCIM)
A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by June 7, 2012. System for Cross-domain Identity Management (SCIM) -- Status: Proposed Working Group Last updated: 2012-05-29 Chair(s): TBD Applications Area Director(s): Pete Resnick presn...@qualcomm.com Barry Leiba barryle...@computer.org Mailing Lists: General Discussion: s...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/scim Archive:http://www.ietf.org/mail-archive/web/scim/ Description of Working Group: The System for Cross-domain Identity Management (SCIM) working group will standardize methods for creating, reading, searching, modifying, and deleting user identities and identity-related objects across administrative domains, with the goal of simplifying common tasks related to user identity management in services and applications. Standardize does not necessarily mean that the working group will develop new technologies. For example, the existing specifications for SCIM 1.0 provide RESTful interfaces on top of HTTP rather than defining a new application protocol. Today, distributed identity management across administrative domains is complicated by a lack of protocol and schema standardization between consumers and producers of identities. This has led to a number of approaches, including error-prone manual administration and bulk file uploads, as well as proprietary protocols and mediation devices that must be adapted to each service for each organization. While there is existing work in the field, it has not been widely adopted for a variety of reasons, including a lack of common artifacts such as schema, toolsets, and libraries. The SCIM working group will develop the core schema and RESTful interfaces to address these problems. Initially, the group will focus on - a schema definition - a set of operations for creation, modification, and deletion of users - schema discovery - read and search - bulk operations - mapping between the inetOrgPerson LDAP object class (RFC 2798) and the SCIM schema It will follow that by considering extensions for client targeting of specific SCIM endpoints and SAML binding. The approach will be extensible. The group will use, as starting points, the following drafts in the following ways: draft-scim-use-cases-00 as the initial use cases for SCIM draft-scim-core-schema-00 as the schema specification draft-scim-api-00 as the protocol specification These drafts are based on existing specifications, which together are commonly known as SCIM 1.0. Because there is existing work with existing implementations, some consideration should be given to backward compatibility, though getting it right takes priority. This group will consider the operational experience gathered from the existing work, as well as experiences with work done by other bodies, including the OASIS Provisioning TC. The use cases document will be a living document, guiding the working group during its development of the standards. The group may take snapshots of that document for Informational publication, to serve as documentation of the motivation for the work in progress and to similarly guide planning and implementation. The group will produce Proposed Standards for a schema, a REST-based protocol, and a SAML binding, as well as an Informational document defining an LDAP mapping. In doing so, the group will make the terminology consistent, identify any functional gaps that would be useful for future work, address internationalization, and provide guidelines and mechanisms for extensibility. In addition, the working group will ensure that the SCIM protocol embodies good security practices. Given both the sensitivity of the information being conveyed in SCIM messages and the regulatory requirements regarding the privacy of personally identifiable information, the working group will pay particular attention to issues around authorization, authenticity, and privacy. The group considers the following out of scope for this group: Defining new authentication schemes Defining new policy/authorization schemes Milestones 06/2012Initial adoption of SCIM use cases, as a living document 06/2012Initial adoption of SCIM core schema 08/2012Initial adoption of SCIM restful interface draft 12/2012Snapshot version of SCIM use cases to IESG as Informational (possibly) 12/2012Proposal for client targeting of SCIM endpoints 01/2013Initial adoption of SCIM LDAP inetOrgPerson mapping draft 02/2013SCIM core schema to IESG as Proposed Standard 05/2013SCIM restful interface to IESG as Proposed Standard 06/2013SCIM LDAP inetOrgPerson
IETF 84 - Social Event
Only 58 days until the Vancouver IETF! Online registration for the IETF meeting is at: http://www.ietf.org/meetings/84/ Follow the IETF on twitter @ietf IETF 84 - Social Event Where: Telus World of Science Date: Tuesday, July 31, 2012 Time: 19:00 - 23:00 hours Cost: $25 USD per person. Availability: Open to all!! Host: Google Telus World of Science - Science World has recently completed a $35-million renovation at its False Creek facility, adding 30,000 square feet of space, a green roof, and many energy‐efficient initiatives with lots of hands-on exhibits. Science World is home to five permanent galleries: the Eureka! Gallery, the Sara Stern Search Gallery, the Kidspace Gallery, the Our World Gallery, and Illusions. It also boasts a feature gallery for special exhibitions. Both the 11,000 square-foot Eureka! Gallery and the facility’s new green roof provide incredible views of False Creek and the city skyline. Experiment with water, light, sound, air and motion among the colourful and lively exhibits in Eureka! Hands-on fun encourages visitors to ask what would happen if...? Home to the popular water table with launchable balls, Eureka! is a place where you can also launch a parachute, spin on a rotating platform, and capture your shadow. Eureka! is also home to the Engineering Lab by the James Dyson Foundation. Experience Da Vinci - the genius, the most comprehensive exhibition ever compiled on the works of Leonardo da Vinci. This 10,000-square-foot exhibition features a vast array of full-scale machine inventions crafted from da Vinci's personal notebooks; amazing anatomical sketches; reproductions of his most famous Renaissance art examined in extraordinary detail, including the Mona Lisa and the Virgin of the Rocks; and three-dimensional interactive presentations of the Last Supper and the Vitruvian Man. In addition guests will enjoy a showing at the famous OMNIMAX® Theatre. It boasts a five-story high dome screen with an IMAX projection and surround sound. Getting there: World of Science is easily accessible via rail system SkyTrain from Burrad St (at Hyatt) - take SkyTrain EXPO Line to King George, exit at Main Street/Science World SkyTrain Station. Approximately a 4 minute ride. Food and Beverage: Lots of local cuisine available to suit various dietary choices. Buffet dinner and beverage service. NOTE: You must be registered for IETF 84 to purchase a Social Ticket. If you have already registered for the IETF, please use this link to purchase a social ticket: https://www.ietf.org/registration/ietf84/eventticket.py Only 58 days until the Vancouver IETF! Online registration for the IETF meeting is at: http://www.ietf.org/meetings/84/ Follow the IETF on twitter @ietf
Results of IETF-conflict review for draft-irtf-rrg-ilnp-dns-05.txt
The IESG has completed a review of draft-irtf-rrg-ilnp-dns consistent with RFC5742. This review is applied to all non-IETF streams. The IESG has no problem with the publication of 'DNS Resource Records for ILNP' draft-irtf-rrg-ilnp-dns-05.txt as an Experimental RFC. The IESG would also like the IRSG to review the comments in the datatracker (http://datatracker.ietf.org/doc/draft-irtf-rrg-ilnp-dns/) related to this document and determine whether or not they merit incorporation into the document. Comments may exist in both the ballot and the history log. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-irtf-rrg-ilnp-dns/ The process for such documents is described at http://www.rfc-editor.org/indsubs.html Thank you, The IESG Secretary Technical Summary This document defines several new optional data Resource Records. This note specifies the syntax and other items required for independent implementations of these DNS resource records. The reader is assumed to be familiar with the basics of DNS, including familiarity with [RFC1034] [RFC1035]. The concept of using DNS to support mobile nodes or mobile networks has been proposed earlier, more than once, independently, by several other researchers; for example, please see [SB00] [SBK01] and [PHG02]. Working Group Summary This document is a product of the IRTF Routing RG. Document Quality Ralph Droms reviewed the document according to RFC 5742 and recommends responding that the IESG has no problem with the publication of 'DNS Resource Records for ILNP' draft-irtf-rrg-ilnp-dns-02.txt as an Experimental RFC, along with the RFC Editor Note below. Note that IANA will request Expert Review and review on the dnsext mailing list for allocation of the requested Data RRTYPE values. Personnel Tony Li tony...@tony.li is the document shepherd. Ralph Droms rdroms.i...@gmail.com is managing the IESG review. RFC Editor Note The IESG has concluded that this work is related to IETF work done in WGs HIP and LISP, but this relationship does not prevent publishing.
Protocol Action: 'GSS-API Naming Extensions' to Proposed Standard (draft-ietf-kitten-gssapi-naming-exts-15.txt)
The IESG has approved the following document: - 'GSS-API Naming Extensions' (draft-ietf-kitten-gssapi-naming-exts-15.txt) as Proposed Standard This document is the product of the Common Authentication Technology Next Generation Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-kitten-gssapi-naming-exts/ Technical Summary The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. Working Group Summary Nothing worth noting regarding WG process. Document Quality This protocol has been implemented in the MIT 1.8 release. At least one other vendor has plans on implementing this in the future as well. Personnel The document shepherd is Shawn Emery The responsible AD is Stephen Farrell
