Copy Tao.md to Tao_Current.txt #5
Conversation
|
|
||
| Of course, it's true that many IETF participants don't go to the face-to-face meetings at all. Instead, they're active on the mailing list of various IETF Working Groups. Since the inner workings of Working Groups can be hard for newcomers to understand, this document provides the mundane bits of information that newcomers will need in order to become active participants. | ||
|
|
||
| The IETF is always in a state of change. Although the principles in this document are expected to remain largely the same over time, practical details may well have changed by the time you read it; for example, a web-based tool may have replaced an email address for requesting some sort of action. | ||
|
|
||
| Many types of IETF documentation are mentioned in the Tao, from BCPs to RFCs and STDs. BCPs make recommendations for Best Current Practices in the Internet; RFCs are the IETF's main technical documentation series, politely known as "Requests for Comments"; and STDs are RFCs identified as "standards". Actually, all three types of documents are RFCs; see Section 6 for more information. | ||
| Many types of IETF documentation are mentioned in the Tao, from BCPs to RFCs and STDs. The IETF publishes its main technical documentation as RFC, politely known as "Requests for Comments"; and STDs are RFCs identified as "standards". BCPs make recommendations for Best Current Practices in the Internet and are also RFCs; All three types of documents are in the RFC document stream; see Section 6 for more information. |
There was a problem hiding this comment.
You probably don't want to use "stream" here because "stream" has a technical meaning (IETF Stream,e tc.)
This whole "main technical documentation" thing is hard to process in both versions, and I'm not sure what it's trying to say. Does the IETF have some other technical documentation venue? I guess you could say "I-Ds". What do we think this is supposed to mean?
There was a problem hiding this comment.
Many types of IETF documentation are mentioned in the Tao, from BCPs to RFCs and STDs. The IETF publishes its technical documentation as RFCs, politely known as "Requests for Comments"; and STDs are RFCs identified as "standards". BCPs make recommendations for Best Current Practices in the Internet and are also RFCs; All three types of documents are in the RFC document series; see Section 6 for more information.
| | BCP | Best Current Practice | | ||
| | BOF | Birds of a Feather | | ||
| | FAQ | Frequently Asked Question(s) | | ||
| | FYI | For Your Information (RFC) | |
There was a problem hiding this comment.
This seems kind of confusing, as (XXX) is usually used to mean "this is an acronym for". Perhaps "a type of RFC".
| | IRTF | Internet Research Task Force | | ||
| | ISOC | Internet Society | | ||
| | RFC | Request for Comments | | ||
| | STD | Standard (RFC) | |
| | Term | Meaning | | ||
| |--------|-----------------------------------------------------| | ||
| | AD | Area Director | | ||
| | BCP | Best Current Practice | |
There was a problem hiding this comment.
Do you want to point out here that this is a kind of RFC.
| - Facilitating technology transfer from the Internet Research Task Force (IRTF) to the wider Internet community | ||
| - Providing a forum for the exchange of information within the Internet community between vendors, users, researchers, agency contractors, operators, and network managers | ||
|
|
||
| The IETF mission further states that the Internet isn't value-neutral, and neither is the IETF. We want the Internet to be useful for communities that share our commitment to openness and fairness. We embrace technical concepts such as decentralized control, edge-user empowerment and sharing of resources, because those concepts resonate with the core values of the IETF community. These concepts have little to do with the technology that's possible, and much to do with the technology that we choose to create. |
There was a problem hiding this comment.
What does "sharing of resources" mean here?
There was a problem hiding this comment.
That text comes straight from BCP95
|
|
||
| The Secretariat only schedules WG meetings a few weeks in advance, and the schedule often changes as little as a week before the first day. If you are only coming for one WG meeting, you may have a hard time booking your flight with such little notice, particularly if the Working Group's meeting changes schedule. Be sure to keep track of the current agenda so you can schedule flights and hotels. But, when it comes down to it, you probably shouldn't be coming for just one WG meeting. It's likely that your knowledge could be valuable in a few WGs, assuming that you've read the drafts and RFCs for those groups. | ||
| The Secretariat only schedules WG meetings a few weeks in advance, and the schedule often changes as little as a week before the first day. If you are only coming for one WG meeting, you may have a hard time booking your flight with such little notice, particularly if the Working Group's meeting changes schedule. Be sure to keep track of the current agenda so you can schedule flights and hotels. But, when it comes down to it, you probably shouldn't be coming for just one WG meeting. It's likely that your knowledge could be valuable in a few WGs, assuming that you've read the drafts and RFCs for those groups. Work in the IETf is often reciprocal, contribute positively to others work and your more likely to receive comments and feedback on your work. |
| 6. RFCs and Internet-Drafts | ||
|
|
||
| If you're a new IETF participant and are looking for a particular RFC or Internet-Draft, go to the RFC Editor's web pages, http://www.rfc-editor.org/rfc.html. That site also has links to other RFC collections, many with search capabilities. If you know the number of the RFC you're looking for, go to the RFC Editor's RFC pages, http://www.rfc-editor.org/rfc.html. For Internet-Drafts, a good resource is the IETF web site, https://datatracker.ietf.org/doc, where you can search by title and keyword. | ||
| This section discusses Internet-Drafts and RFCs in the IETF stream, that is, it describes how documents are produced and advanced within the IETF. For a brief note on other RFC streams, see Section 2.2.5. |
There was a problem hiding this comment.
At this point, I think we should probably be recommending the tools site or the datatracker for RFCs or I-Ds. They're much more usable.
There was a problem hiding this comment.
My understanding is that the features available on tools are being migrated to datatracker (but not vice-versa). I believe the intention is to turn tools off once datatracker implements equivalent functionality. If picking one, I would select datatracker.
There was a problem hiding this comment.
If you're a new IETF participant and are looking for a particular RFC or Internet-Draft, go to the IETF Datatracker [https://datatracker.ietf.org/]. That site has many search capabilities and can help you find the right document and information about its status, dependencies, potential updates and other information. Another entry point for searching and navigating RFCs is Mark Nottingham's EveryRFC [https://everyrfc.org/].
| - Repeat steps 1 through 3 a few times. | ||
| - Ask an Area Director to take the draft to the IESG (if it's an individual submission). If the draft is an official Working Group product, the WG chair asks the AD to take it to the IESG. | ||
| - If the Area Director accepts the submission, they will do their own initial review, and maybe ask for updates before they move it forwards. | ||
| - Get reviews from the wider IETF membership. In particular, some of the Areas in the IETF have formed review teams to look over drafts that are ready to go to the IESG. Two of the more active review teams are from the Security Directorate ("SecDir") and the General Area Review Team (Gen-Art), but there is also a Privacy Review Team and a Human Rights Review Team. Remember that all these reviews can help improve the quality of the eventual RFC. |
There was a problem hiding this comment.
I think rather than try to list all of these, we should just remove the list :)
There was a problem hiding this comment.
I agree -- it would be quite long once opsdir and rtgdir are included
|
|
||
| An I-D should have approximately the same format as an RFC. Contrary to many people's beliefs, an I-D does not need to look exactly like an RFC, but if you can use the same formatting procedures used by the RFC Editor when you create your I-Ds, it will simplify the RFC Editor's work when your draft is published as an RFC. [RFC2223], "Instructions to RFC Authors", describes the submission format. There is also a tool called "xml2rfc", available from http://xml.resource.org, that takes XML-formatted text and turns it into a valid Internet-Draft. | ||
| An I-D should have approximately the same format as an RFC. Contrary to many people's beliefs, an I-D does not need to look exactly like an RFC, but if you can use the same formatting procedures used by the RFC Editor when you create your I-Ds, it will simplify the RFC Editor's work when your draft is published as an RFC. [RFC2223], "Instructions to RFC Authors", describes the submission format. There is also a tool called "xml2rfc", available from [https://xml2rfc.tools.ietf.org], that takes XML-formatted text and turns it into a valid Internet-Draft. |
There was a problem hiding this comment.
Given how many people use markdown now, you might want to cite that.
There was a problem hiding this comment.
An I-D should have approximately the same format as an RFC. Contrary to many people's beliefs, an I-D does not need to look exactly like an RFC, but if you can use the same formatting procedures used by the RFC Editor when you create your I-Ds, it will simplify the RFC Editor's work when your draft is published as an RFC. [RFC2223], "Instructions to RFC Authors", describes the submission format. There is also a tool called "xml2rfc", available from [https://xml2rfc.tools.ietf.org], that takes XML-formatted text and turns it into a valid Internet-Draft, you can also use a tool called kramdown, available from [https://github.com/cabo/kramdown-rfc2629], that takes markdown-formatted text and turns it into a valid Internet-Draft.
|
|
||
| When you submit the first version of the draft, you also tell the draft administrator your proposed filename for the draft. If the draft is an official Working Group product, the name will start with "draft-ietf-" followed by the designation of the WG, followed by a descriptive word or two, followed by "00.txt". | ||
|
|
||
| For example, a draft in the S/MIME WG about creating keys might be named "draft-ietf-smime-keying-00.txt". If it's not the product of a Working Group, the name will start with "draft-" and the last name of one of the authors followed by a descriptive word or two, followed by "00.txt". For example, a draft that someone named Smith wrote might be named "draft-smith-keying-00.txt". If a draft is an individual submission but relates to a particular Working Group, authors sometimes follow their name with the name of the Working Group, such as "draft-smith-smime-keying-00.txt". If you follow the naming guidelines given at http://www.ietf.org/ietf/1id-guidelines.txt, chances are quite good that your suggested filename will be fine. | ||
| For example, a draft in the S/MIME WG about creating keys might be named "draft-ietf-smime-keying-00.txt". If it's not the product of a Working Group, the name will start with "draft-" and the last name of one of the authors followed by a descriptive word or two, followed by "00.txt". For example, a draft that someone named Smith wrote might be named "draft-smith-keying-00.txt". If a draft is an individual submission but relates to a particular Working Group, authors sometimes follow their name with the name of the Working Group, such as "draft-smith-smime-keying-00.txt". If you follow the naming guidelines given at [https://www.ietf.org/ietf/1id-guidelines.txt], chances are quite good that your suggested filename will be fine. |
There was a problem hiding this comment.
Note that I sometimes see draft-foo where foo is not a last name. E.g., draft-ymbk
There was a problem hiding this comment.
Not sure what to do with this.
There was a problem hiding this comment.
Maybe:
If it's not the product of a Working Group, the name will start with "draft-" but is not followed by "ietf-". Often the last name of one of the authors (or some other identifier) is followed by a descriptive word or two, followed by "00.txt".
| The ADs for a particular Area are expected to know more about the combined work of the WGs in that Area than anyone else. On the other hand, the entire IESG reviews each Internet-Draft that is proposed to become an RFC. Any AD may record a "DISCUSS" ballot position against a draft if he or she has serious concerns. If these concerns cannot be resolved by discussion, an override procedure is defined such that at least two IESG members must express concerns before a draft can be blocked from moving forward. These procedures help ensure that an AD's "pet project" doesn't make it onto the standards track if it will have a negative effect on the rest of the IETF protocols and that an AD's "pet peeve" cannot indefinitely block something. | ||
| Because the IESG is reviewing all Internet-Drafts before they become RFCs, Area Directors have quite a bit of influence. Some people therefore shy away from directly engaging with Area Directors, whereas they can be an important resource and help you find the person or the answer that your looking for. At the meeting they might be very busy. Planning ahead to schedule a meeting or to find time at the Newcomers Meet and Greet is a great way to get in touch. Email before or after a meeting is effective as well. | ||
|
|
||
| The ADs for a particular Area are expected to know more about the combined work of the WGs in that Area than anyone else. This is because the ADs actively follow the working groups for which they are responsible and assist working groups and chairs with charter and milestone reviews. The entire IESG reviews each Internet-Draft that is proposed to become an RFC and should be aware of general trends that can be gleaned from the collective work products of the IETF. As part of the document reviews, ADs place ballots that may contain comments on documents. The AD enters a position that may be YES, No OBJECTION, DISCUSS, ABSTAIN, or RECUSE as the result of their review. Any AD may record a "DISCUSS" ballot position against a draft if he or she has serious concerns and would like to discuss these concerns. If these concerns cannot be resolved by discussion, an override procedure is defined such that at least two IESG members must express concerns before a draft can be blocked from moving forward. These procedures help provide balance in reviews for publication and ensure that an AD's "pet project" doesn't make it onto the standards track if it will have a negative effect on the rest of the IETF protocols. The override procedure helps prevent an AD's "pet peeve" from indefinitely blocking something. |
There was a problem hiding this comment.
"NO OBJECTION" should probably be all-caps.
There was a problem hiding this comment.
If we're going to get down to the level of detail of mentioning all possible ballot positions, it's probably worth having a sentence or so that explains that it is quite common for documents to be approved with one or two "YES" ballots, and the majority of the remaining IESG balloting "NO OBJECTION." I've recently seen intimations from an IETF old-timer that a three-YES, eight-NO-OBJECTION ballot somehow indicated unusually weak approval; we don't want this misconception to be widespread among newcomers.
There was a problem hiding this comment.
Added: It is quite common for documents to be approved with one or two "YES" ballots, and the majority of the remaining IESG balloting "NO OBJECTION.".
| 2.2.5 RFC Editor | ||
|
|
||
| The RFC Editor edits, formats, and publishes Internet-Drafts as RFCs, working in conjunction with the IESG. An important secondary role is to provide one definitive repository for all RFCs (see http://www.rfc-editor.org). Once an RFC is published, it is never revised. If the specification it describes changes, the standard will be re-published in another RFC that "obsoletes" the first. | ||
| The RFC Editor edits, formats, and publishes Internet-Drafts as RFCs, working in conjunction with the IESG for IETF RFCs, the IRTF Chair for IRTF RFCs, the IAB for IAB RFCs, and the Independent Submissions Editor for Independent Submission RFC, and of course working with the authors.An important other role is to provide one definitive repository for all RFCs (see [https://www.rfc-editor.org]). Once an RFC is published, it is never revised. If the specification it describes changes, the standard will be re-published in another RFC that "obsoletes" the first. If a technical or editorial error is found in an RFC, an errata may be filed for review. If accepted, the errata will be linked to the RFC and may be held for the next document update. |
There was a problem hiding this comment.
s/Independent Submission RFC/independent stream RFCs/
There was a problem hiding this comment.
Should Independent Stream not be written with capitals here?
Added for now: Independent Stream RFCs
|
|
||
| You can register and pay on the web before the meeting, or in person at the meeting. To get a lower registration fee, you must pay by the early registration deadline (about one week before the meeting). The registration fee covers all of the week's meetings, the Sunday evening welcome reception (cash bar), daily continental breakfasts, and afternoon beverage and snack breaks. | ||
| You can register and pay on the web before the meeting, or in person at the meeting. To get a lower registration fee, you must pay by the early registration deadline (about one week before the meeting). The registration fee covers all of the week's meetings, the Sunday evening welcome reception, and afternoon beverage and snack breaks. |
There was a problem hiding this comment.
"about one week before the meeting" is changing for IETF 103
There was a problem hiding this comment.
Yes, this should be made consistent with the changes announced by the IAOC.
There was a problem hiding this comment.
Five weeks is not correct. There are three registration windows: early bird, standard, and late. Early bird closes 7 weeks before the meeting. Standard closes 2 weeks before the meeting. Late is any time after standard.
There was a problem hiding this comment.
Changed:
You can register and pay on the web before the meeting, or in person at the meeting. To get a lower registration fee, you must pay by the early-bird registration deadline (at least seven weeks before the meeting). The standard registration fee window closes 2 weeks before the meeting, if you register any time after that you will need to pay the fee for late registrants. The registration fee covers all of the week's meetings, the Sunday evening welcome reception, and afternoon beverage and snack breaks.
| - Repeat steps 1 through 3 a few times. | ||
| - Ask an Area Director to take the draft to the IESG (if it's an individual submission). If the draft is an official Working Group product, the WG chair asks the AD to take it to the IESG. | ||
| - If the Area Director accepts the submission, they will do their own initial review, and maybe ask for updates before they move it forwards. | ||
| - Get reviews from the wider IETF membership. In particular, some of the Areas in the IETF have formed review teams to look over drafts that are ready to go to the IESG. Two of the more active review teams are from the Security Directorate ("SecDir") and the General Area Review Team (Gen-Art), but there is also a Privacy Review Team and a Human Rights Review Team. Remember that all these reviews can help improve the quality of the eventual RFC. |
There was a problem hiding this comment.
I agree -- it would be quite long once opsdir and rtgdir are included
| The current version of this web page can always be found at http://www.ietf.org/tao.html; that page can also be retrieved protected by TLS. To contribute to this document or to discuss its content, please join the "tao-discuss" mailing list. A history of the major versions of the Tao can be found here. This particular version was created on 2012-11-02. | ||
| This is the upcoming revision of the Tao which can be found at [http://www.ietf.org/tao-possible-revision.html] | ||
|
|
||
| The current version of this web page can always be found at [https://www.ietf.org/tao.html]. To contribute to this document or to discuss its content, please join the "tao-discuss" mailing list. A history of the major versions of the Tao can be found here. This particular version was created on 2018-06-26. |
There was a problem hiding this comment.
This should probably include a pointer to https://www.ietf.org/mailman/listinfo/tao-discuss
|
|
||
| Of course, it's true that many IETF participants don't go to the face-to-face meetings at all. Instead, they're active on the mailing list of various IETF Working Groups. Since the inner workings of Working Groups can be hard for newcomers to understand, this document provides the mundane bits of information that newcomers will need in order to become active participants. | ||
|
|
||
| The IETF is always in a state of change. Although the principles in this document are expected to remain largely the same over time, practical details may well have changed by the time you read it; for example, a web-based tool may have replaced an email address for requesting some sort of action. | ||
|
|
||
| Many types of IETF documentation are mentioned in the Tao, from BCPs to RFCs and STDs. BCPs make recommendations for Best Current Practices in the Internet; RFCs are the IETF's main technical documentation series, politely known as "Requests for Comments"; and STDs are RFCs identified as "standards". Actually, all three types of documents are RFCs; see Section 6 for more information. | ||
| Many types of IETF documentation are mentioned in the Tao, from BCPs to RFCs and STDs. The IETF publishes its main technical documentation as RFC, politely known as "Requests for Comments"; and STDs are RFCs identified as "standards". BCPs make recommendations for Best Current Practices in the Internet and are also RFCs; All three types of documents are in the RFC document stream; see Section 6 for more information. |
There was a problem hiding this comment.
Nit: "The IETF publishes its main technical documentation as RFCs" (plural)
|
|
||
| Starting in spring 2005, the ISOC also became home base for the IETF's directly employed administrative staff. This is described in more detail in [BCP101], "Structure of the IETF Administrative Support Activity (IASA)". The staff initially includes only an Administrative Director (IAD) who works full-time overseeing IETF meeting planning, operational aspects of support services (the secretariat, IANA (the Internet Assigned Numbers Authority), and the RFC Editor, which are described later in this section), and the budget. He or she (currently it's a he) leads the IETF Administrative Support Activity (IASA), which takes care of tasks such as collecting meeting fees and paying invoices, and also supports the tools for the work of IETF working groups, the IESG, the IAB, and the IRTF (more about these later in this section). | ||
| Starting in spring 2005, the ISOC also became home base for the IETF's directly employed administrative staff. This is described in more detail in [BCP101], "Structure of the IETF Administrative Support Activity (IASA)". The staff initially includes only an Administrative Director (IAD) who works full-time overseeing IETF meeting planning, operational aspects of support services (the secretariat, IANA (the Internet Assigned Numbers Authority), and the RFC Editor, which are described later in this section), and the budget. He or she (currently it's a she) leads the IETF Administrative Support Activity (IASA), which takes care of tasks such as collecting meeting fees and paying invoices, and also supports the tools for the work of IETF working groups, the IESG, the IAB, and the IRTF (more about these later in this section). |
There was a problem hiding this comment.
It's also not clear that we want to have to update the Tao each time the gender of the IAD changes. Would recommend (along with EKR's point) to rephrase as The IAD leads the IETF Administrative...
| The ADs for a particular Area are expected to know more about the combined work of the WGs in that Area than anyone else. On the other hand, the entire IESG reviews each Internet-Draft that is proposed to become an RFC. Any AD may record a "DISCUSS" ballot position against a draft if he or she has serious concerns. If these concerns cannot be resolved by discussion, an override procedure is defined such that at least two IESG members must express concerns before a draft can be blocked from moving forward. These procedures help ensure that an AD's "pet project" doesn't make it onto the standards track if it will have a negative effect on the rest of the IETF protocols and that an AD's "pet peeve" cannot indefinitely block something. | ||
| Because the IESG is reviewing all Internet-Drafts before they become RFCs, Area Directors have quite a bit of influence. Some people therefore shy away from directly engaging with Area Directors, whereas they can be an important resource and help you find the person or the answer that your looking for. At the meeting they might be very busy. Planning ahead to schedule a meeting or to find time at the Newcomers Meet and Greet is a great way to get in touch. Email before or after a meeting is effective as well. | ||
|
|
||
| The ADs for a particular Area are expected to know more about the combined work of the WGs in that Area than anyone else. This is because the ADs actively follow the working groups for which they are responsible and assist working groups and chairs with charter and milestone reviews. The entire IESG reviews each Internet-Draft that is proposed to become an RFC and should be aware of general trends that can be gleaned from the collective work products of the IETF. As part of the document reviews, ADs place ballots that may contain comments on documents. The AD enters a position that may be YES, No OBJECTION, DISCUSS, ABSTAIN, or RECUSE as the result of their review. Any AD may record a "DISCUSS" ballot position against a draft if he or she has serious concerns and would like to discuss these concerns. If these concerns cannot be resolved by discussion, an override procedure is defined such that at least two IESG members must express concerns before a draft can be blocked from moving forward. These procedures help provide balance in reviews for publication and ensure that an AD's "pet project" doesn't make it onto the standards track if it will have a negative effect on the rest of the IETF protocols. The override procedure helps prevent an AD's "pet peeve" from indefinitely blocking something. |
There was a problem hiding this comment.
If we're going to get down to the level of detail of mentioning all possible ballot positions, it's probably worth having a sentence or so that explains that it is quite common for documents to be approved with one or two "YES" ballots, and the majority of the remaining IESG balloting "NO OBJECTION." I've recently seen intimations from an IETF old-timer that a three-YES, eight-NO-OBJECTION ballot somehow indicated unusually weak approval; we don't want this misconception to be widespread among newcomers.
| Newcomers are encouraged to attend the Newcomer's Orientation on Sunday afternoon, which is especially designed for first-time attendees. The orientation is organized and conducted by the IETF EDU team and is intended to provide useful introductory information. The session covers what all the dots on name tags mean, the structure of the IETF, and many other essential and enlightening topics for new IETFers. | ||
| Newcomers are encouraged to attend the Newcomer's Tutorial on Sunday afternoon, which is especially designed for first-time attendees. The tutorial is organized and conducted by the IETF EDU team and is intended to provide useful introductory information. The session covers what all the dots on name tags mean, the structure of the IETF, and many other essential and enlightening topics for new IETFers. If you are unable to attend this session, recorded ones from previous meetings are available ([https://www.ietf.org/about/participate/tutorials/]). | ||
|
|
||
| Later in the afternoon is the Quick Connections session where newcomers have the chance to get to know senior IETF participants, and ask questions. The Quick Connections session is followed by the Newcomer's Meet and Greet, which is only open to newcomers and WG chairs. This is a great place to try to find people knowledgeable in the areas in which you are interested. Feel free to approach any WG chair, not just those in your area, to either learn about their WG or to have them help find you someone in yours. |
There was a problem hiding this comment.
I think there's a tendency to read "newcomers" with "first-timers," but in this paragraph, we really mean people attending one of their first several (I think it's three?) meetings. This should probably be made clearer.
There was a problem hiding this comment.
The Quick Connections session is still quite open and people need to register beforehand, so am not sure whether we should put more boundaries here. We are still experimenting with it in EDU.
There was a problem hiding this comment.
Sorry, to be clear, I'm referring to the "Newcomer's Meet and Greet," not the Quick Connections.
There was a problem hiding this comment.
As Alissa said, the "Newcomer's Meet and Greet' is probably gonna undergo some changes since newcomers get quite lost and it is mostly a lot of experienced IETF-ers seeing each other in person for the first time in three months and enjoy some beer&wine while chatting with each other.
So I don't think the problem is that there are too many newcomers.
Having said that, making changes here, or even removing the Newcomers Meet and Greet would be a loss if we don't know what we'll replace it with.
There was a problem hiding this comment.
I think it would be useful to be a bit more pushy than "Feel free to approach chairs...".
Maybe:
This is a good opportunity to connect to the chairs of the working group your are interested in. If you can't find the right person easily or don't know which working group your interests are connected to, feel free to approach anybody without a newcomer ribbon to help you to get in touch with the right people.
| [RFC6722] Hoffman, P., “Publishing the "Tao of the IETF" as a Web Page”, RFC 6722, August 2012. | ||
| [RFC6722](https://tools.ietf.org/html/rfc6722) Hoffman, P., “Publishing the "Tao of the IETF" as a Web Page”, RFC 6722, August 2012. | ||
|
|
||
| [STD3](https://tools.ietf.org/html/rfc1123) Braden, R., “Requirements for Internet Hosts - Application and Support”, STD 3, RFC 1123, October 1989. |
There was a problem hiding this comment.
STD 3 is RFC 1122 and RFC 1123. It's probably best to link to https://tools.ietf.org/html/std3 instead of a specific RFC.
| 10. Informative References | ||
|
|
||
| [BCP9] Bradner, S., “The Internet Standards Process -- Revision 3”, BCP 9, RFC 2026, RFC 6410, October 1996. | ||
| [BCP9](https://tools.ietf.org/html/rfc6410) Bradner, S., “The Internet Standards Process -- Revision 3”, BCP 9, RFC 2026, RFC 6410, October 1996. |
There was a problem hiding this comment.
BCP 9 is comprised of six different RFCs. Probably best to use https://tools.ietf.org/html/bcp9 (or, if you really mean RFC 6410 in isolation, cite its RFC number rather than its BCP number).
|
|
||
| [BCP10] Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees”, BCP 10, RFC 3777, June 2004. | ||
| [BCP10](https://tools.ietf.org/html/rfc3777) Galvin, J., “IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees”, BCP 10, RFC 3777, June 2004. |
|
|
||
| [BCP14] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997. | ||
| [BCP14](https://tools.ietf.org/html/rfc2119) Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997. |
There was a problem hiding this comment.
This one is definitely two RFCs. Use https://tools.ietf.org/html/bcp14
|
|
||
| [BCP25] Bradner, S., “IETF Working Group Guidelines and Procedures”, BCP 25, RFC 2418, September 1998. | ||
| [BCP25](https://tools.ietf.org/html/rfc2418) Bradner, S., “IETF Working Group Guidelines and Procedures”, BCP 25, RFC 2418, September 1998. |
There was a problem hiding this comment.
This one is three RFCs.
I'm not going to check any further BCPs in this list, as I think it's obvious that saying "BCP XX" and linking to an RFC instead of a BCP is fraught with hazard. My recommendation is to change all links to BCP links, and to remove the RFC number from the citation itself (or, alternately, expand it to include all of the RFCs that comprise the cited BCP).
| 1. Introduction | ||
|
|
||
| Since its early years, attendance at Internet Engineering Task Force (IETF) face-to-face meetings has grown phenomenally. Many of the attendees are new to the IETF at each meeting, and many of those go on to become regular attendees. When the meetings were smaller, it was relatively easy for a newcomer to get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of documents or thought-provoking email messages. | ||
| Since its early years, attendance at Internet Engineering Task Force (IETF) face-to-face meetings has grown phenomenally and is now stabilizing. Many of the attendees are new to the IETF at each meeting, and many of those go on to become regular attendees. When the meetings were smaller, it was relatively easy for a newcomer to adjust. Today, however, a newcomer meets many more new people, some previously known only as the authors of documents or thought-provoking email messages. |
There was a problem hiding this comment.
I'm not sure it's true that attendance is "now stabilizing," and it also kind of mischaracterizes the current period compared to various other periods in the IETF's history. I think the more long-lasting change to make here would be to either cut this sentence altogether, or make it more timeless ("Thousands of people participate in the IETF.")
There was a problem hiding this comment.
Proposed text:
Since its early years, attendance at Internet Engineering Task Force (IETF) face-to-face meetings has grown phenomenally and is now averaging between 1100 and 1400 participants [https://datatracker.ietf.org/stats/meeting/overview/].
There was a problem hiding this comment.
I still think using specific numbers is unwarranted. The Tao doesn't get updated very often, so better to make this generic enough that it won't be out of date in a year if participation trends change.
There was a problem hiding this comment.
I hope it is okay that we keep it in here, since we agreed we're going to update the Tao more regularly anyhow.
| - Facilitating technology transfer from the Internet Research Task Force (IRTF) to the wider Internet community | ||
| - Providing a forum for the exchange of information within the Internet community between vendors, users, researchers, agency contractors, operators, and network managers | ||
|
|
||
| The IETF mission further states that the Internet isn't value-neutral, and neither is the IETF. We want the Internet to be useful for communities that share our commitment to openness and fairness. We embrace technical concepts such as decentralized control, edge-user empowerment and sharing of resources, because those concepts resonate with the core values of the IETF community. These concepts have little to do with the technology that's possible, and much to do with the technology that we choose to create. |
There was a problem hiding this comment.
I know that RFC3935 uses "we," but it seems less appropriate in this document. I think it would be preferable to either quote the mission directly (in quotes), or re-phrase so that you're not using "we."
| @@ -78,83 +89,96 @@ After the Internet Society (ISOC) was formed in January 1992, the IAB proposed t | |||
|
|
|||
| The IETF met in Amsterdam, The Netherlands, in July 1993. This was the first IETF meeting held in Europe, and the US/non-US attendee split was nearly 50/50. The IETF first met in Asia (in Adelaide, Australia) in 2000. | |||
|
|
|||
| 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. The number of non-US attendees continues to be high — about 50%, even at meetings held in the United States. | |||
| Currently, the IETF meets in North America, Europe, and Asia. We have also met in Latin America, but this is currently not part of the rotation schedule. The intention is to meet once a year in North America, Europe, and Asia, although due to scheduling and logistical issues this might vary. The number of non-US attendees continues to be high — about 60%, even at meetings held in the United States ([https://datatracker.ietf.org/stats/meeting/continent/]). | |||
|
|
|||
There was a problem hiding this comment.
For this whole paragraph I think it would be safer to just quote directly from the mtgvenue policy document. I'm not sure why Latin America would be mentioned rather than Oceania, etc.
| 2.2.1 ISOC (Internet Society) | ||
|
|
||
| The Internet Society is an international, non-profit, membership organization that fosters the expansion of the Internet. One of the ways that ISOC does this is through financial and legal support of the other "I" groups described here, particularly the IETF. ISOC provides insurance coverage for many of the people holding leadership positions in the IETF process and acts as a public relations channel for the times that one of the "I" groups wants to say something to the press. The ISOC is one of the major unsung heroes of the Internet. | ||
| The Internet Society is an international, non-profit, membership organization that fosters the expansion of the Internet. One of the ways that ISOC does this is through financial and legal support of the other "I" groups described here, particularly the IETF. ISOC provides insurance coverage for many of the people holding leadership positions in the IETF process and acts as a public relations channel for the times that one of the "I" groups wants to say something to the press. |
There was a problem hiding this comment.
This is going to be incorrect quite soon. ISOC will not be providing "legal support" for the IETF in any meaningful way, nor will it be providing insurance coverage. I think the part about public relations is already incorrect too.
There was a problem hiding this comment.
Is there anyone involved in the IASA work that could provide some sentences for this para and the IASA para? I am rly out of my depth there.
Or we could leave it for the next revision.
There was a problem hiding this comment.
Greg Wood is willing and able to suggest text for this - he assured me would work on it this week.
|
|
||
| Starting in spring 2005, the ISOC also became home base for the IETF's directly employed administrative staff. This is described in more detail in [BCP101], "Structure of the IETF Administrative Support Activity (IASA)". The staff initially includes only an Administrative Director (IAD) who works full-time overseeing IETF meeting planning, operational aspects of support services (the secretariat, IANA (the Internet Assigned Numbers Authority), and the RFC Editor, which are described later in this section), and the budget. He or she (currently it's a he) leads the IETF Administrative Support Activity (IASA), which takes care of tasks such as collecting meeting fees and paying invoices, and also supports the tools for the work of IETF working groups, the IESG, the IAB, and the IRTF (more about these later in this section). | ||
| Starting in spring 2005, the ISOC also became home base for the IETF's directly employed administrative staff. This is described in more detail in [BCP101], "Structure of the IETF Administrative Support Activity (IASA)". The staff initially includes only an Administrative Director (IAD) who works full-time overseeing IETF meeting planning, operational aspects of support services (the secretariat, IANA (the Internet Assigned Numbers Authority), and the RFC Editor, which are described later in this section), and the budget. He or she (currently it's a she) leads the IETF Administrative Support Activity (IASA), which takes care of tasks such as collecting meeting fees and paying invoices, and also supports the tools for the work of IETF working groups, the IESG, the IAB, and the IRTF (more about these later in this section). |
There was a problem hiding this comment.
All of this is going to be incorrect very soon. It should be updated to describe the IETF LLC.
| 3.8 Meals and Other Delights | ||
|
|
||
| Marshall Rose once remarked that the IETF was a place to go for "many fine lunches and dinners". Although it is true that some people eat very well at the IETF, they find the food on their own; lunches and dinners are not included in the registration fee. The Secretariat arranges for appetizers at the Sunday evening welcome reception (not meant to be a replacement for dinner), continental breakfast on Monday through Friday mornings (depending on the meeting venue), and (best of all) cookies, brownies, fruit, and other yummies during some of the afternoon breaks. These are very often paid for by the meeting host or a meeting sponsor. | ||
| Marshall Rose once remarked that the IETF was a place to go for "many fine lunches and dinners". Although it is true that some people eat very well at the IETF, they find the food on their own; lunches and dinners are not included in the registration fee. The Secretariat arranges for appetizers at the Sunday evening welcome reception (not meant to be a replacement for dinner), in some venues, continental breakfast on Monday through Friday mornings, and (best of all) cookies, brownies, fruit, and other yummies during some of the afternoon breaks. These are very often paid for by the meeting host or a meeting sponsor. |
There was a problem hiding this comment.
The extent of food and drink available at the welcome reception is dependent on our ability to find a sponsor for it, and is not guaranteed.
There was a problem hiding this comment.
Marshall Rose once remarked that the IETF was a place to go for "many fine lunches and dinners". Although it is true that some people eat very well at the IETF, they find the food on their own; lunches and dinners are not included in the registration fee. If sponsorship for it is secured, the Secretariat arranges for appetizers at the Sunday evening welcome reception (not meant to be a replacement for dinner), in some venues, continental breakfast on Monday through Friday mornings, and (best of all) cookies, brownies, fruit, and other yummies during some of the afternoon breaks. These are very often paid for by the meeting host or a meeting sponsor.
| 3.11 EDU to the Rescue | ||
|
|
||
| If certain aspects of the IETF still mystify you (even after you finish reading the Tao), you'll want to drop in on the on-site training offered by the Education (EDU) team. These informal classes are designed for newcomers and seasoned IETFers alike. In addition to the Newcomer Training, the EDU team offers workshops for document editors and Working Group chairs, plus an in-depth security tutorial that's indispensable for both novices and longtime IETF attendees. EDU sessions are generally held on Sunday afternoons. You'll find more about the EDU team at http://www.ietf.org/edu/. | ||
| If certain aspects of the IETF still mystify you (even after you finish reading the Tao), you'll want to drop in on the on-site training offered by the Education (EDU) team. These informal classes are designed for newcomers and seasoned IETFers alike. In addition to the Newcomer Training, the EDU team offers workshops for document editors and Working Group chairs, plus an in-depth security tutorial that's indispensable for both novices and longtime IETF attendees. EDU sessions are generally held on Sunday afternoons and are typically posted to watch later as well. |
There was a problem hiding this comment.
The security tutorial is not a regular thing I don't think.
There was a problem hiding this comment.
True, I made it more general alltogether:
If certain aspects of the IETF still mystify you (even after you finish reading the Tao), you'll want to drop in on the on-site training offered by the Education (EDU) team. These informal classes are designed for newcomers and seasoned IETFers alike. In addition to the Newcomer Training, the EDU team offers two in-depth tutorials that are indispensable for both novices and longtime IETF attendees. EDU sessions are generally held on Sunday afternoons and are posted to watch later as well.
| 4.1 Working Group Chairs | ||
|
|
||
| The role of the WG chairs is described in both [BCP11] and [BCP25]. | ||
|
|
||
| As volunteer cat-herders, a chair's first job is to determine the WG consensus goals and milestones, keeping the charter up to date. Next, often with the help of WG secretaries or document editors, the chair must manage WG discussion, both on the list and by scheduling meetings when appropriate. Sometimes discussions get stuck on contentious points and the chair may need to steer people toward productive interaction and then declare when rough consensus has been met and the discussion is over. Sometimes chairs also manage interactions with non-WG participants or the IESG, especially when a WG document approaches publication. Chairs have responsibility for the technical and non-technical quality of WG output. As you can imagine given the mix of secretarial, interpersonal, and technical demands, some Working Group chairs are much better at their jobs than others. | ||
|
|
||
| WG chairs are strongly advised to go to the WG leadership training that usually happens on the Sunday preceding the IETF meeting. There is also usually a WG chairs lunch mid-week during the meeting where chair-specific topics are presented and discussed. If you're interested in what they hear there, take a look at the slides at http://edu.ietf.org. | ||
| WG chairs are strongly advised to go to the WG leadership training that usually happens on the Sunday preceding the IETF meeting. There is also usually a WG chairs lunch mid-week during the meeting where chair-specific topics are presented and discussed. If you're interested in what they hear there, take a look at the slides at [https://trac.ietf.org/trac/edu]. |
There was a problem hiding this comment.
I don't think the WG leadership training still happens every Sunday.
There was a problem hiding this comment.
Accepted. Changed into:
WG chairs are advised to participate in the WG chairs lunch mid-week during the meeting where chair-specific topics are presented and discussed. Slides of the previous versions of this session can be found in the datatracker.
| @@ -553,14 +626,13 @@ In general, the IETF tries to have cordial relationships with other standards bo | |||
|
|
|||
| At the time of this writing, the IETF has some liaisons with large standards bodies, including the ITU-T (the Telecommunication Standardization Sector of the International Telecommunication Union), the W3C (World Wide Web Consortium), the IEEE (the Institute of Electrical and Electronics Engineers), and the Unicode Consortium. As stated in the IAB Charter [BCP39], "Liaisons are kept as informal as possible and must be of demonstrable value in improving the quality of IETF specifications". In practice, the IETF prefers liaisons to take place directly at Working Group level, with formal relationships and liaison documents in a backup role. | |||
|
|
|||
| Some of these liaison tasks fall to the IESG, whereas others fall to the IAB. Detail-oriented readers will learn much about the formal methods for dealing with other standards bodies in [BCP102], "IAB Processes for Management of IETF Liaison Relationships", and [BCP103], "Procedures for Handling Liaison Statements to and from the IETF". The best place to check to see whether the IETF has any formal liaison at all is the list of IETF liaisons, http://www.ietf.org/liaison. The list shows that there are many different liaisons to ISO/IEC JTC1 subcommittees. | |||
|
|
|||
| Some of these liaison tasks fall to the IESG, whereas others fall to the IAB. Detail-oriented readers will learn much about the formal methods for dealing with other standards bodies in [BCP102], "IAB Processes for Management of IETF Liaison Relationships", and [BCP103], "Procedures for Handling Liaison Statements to and from the IETF". The best place to check to see whether the IETF has any formal liaison at all is the list of IETF liaisons, [https://www.ietf.org/about/liaisons]. The list shows that there are many different liaisons to ISO/IEC JTC1 subcommittees. | |||
There was a problem hiding this comment.
Why is ISO/IEC JTC1 called out specifically?
There was a problem hiding this comment.
Removed this sentence: The list shows that there are many different liaisons to ISO/IEC JTC1 subcommittees.
|
|
||
| 8.2 Press Coverage of the IETF | ||
|
|
||
| Given that the IETF is one of the best-known bodies that is helping move the Internet forward, it's natural for the computer press (and even the trade press) to want to cover its actions. In recent years, a small number of magazines have assigned reporters and editors to cover the IETF in depth over a long period of time. These reporters have ample scars from articles that they got wrong, incorrect statements about the status of Internet-Drafts, quotes from people who are unrelated to the IETF work, and so on. | ||
|
|
||
| Major press errors fall into two categories: saying that the IETF is considering something when in fact there is just an Internet-Draft in a Working Group, and saying that the IETF approved something when all that happened was that an Informational RFC was published. In both cases, the press is not fully to blame for the problem, since they are usually alerted to the story by a company trying to get publicity for a protocol that they developed or at least support. Of course, a bit of research by the reporters would probably get them in contact with someone who could straighten them out, such as a WG chair or an Area Director. The default place that press should look for press contacts for the IETF is <http://www.ietf.org/media.html>. | ||
| Major press errors fall into two categories: saying that the IETF is considering something when in fact there is just an Internet-Draft in a Working Group, and saying that the IETF approved something when all that happened was that an Informational RFC was published. In both cases, the press is not fully to blame for the problem, since they are usually alerted to the story by a company trying to get publicity for a protocol that they developed or at least support. Of course, a bit of research by the reporters would probably get them in contact with someone who could straighten them out, such as a WG chair or an Area Director. The default place that press should look for press contacts for the IETF is [https://www.ietf.org/contact]. |
There was a problem hiding this comment.
This seems kind of needlessly demeaning towards reporters.
There was a problem hiding this comment.
Removed the following sentence: Of course, a bit of research by the reporters would probably get them in contact with someone who could straighten them out, such as a WG chair or an Area Director.
|
Changed and included. Thanks!
…On 08/22/2018 10:07 AM, mirjak wrote:
***@***.**** commented on this pull request.
------------------------------------------------------------------------
In Tao_Current.txt
<#5 (comment)>:
>
When you submit the first version of the draft, you also tell the draft administrator your proposed filename for the draft. If the draft is an official Working Group product, the name will start with "draft-ietf-" followed by the designation of the WG, followed by a descriptive word or two, followed by "00.txt".
-For example, a draft in the S/MIME WG about creating keys might be named "draft-ietf-smime-keying-00.txt". If it's not the product of a Working Group, the name will start with "draft-" and the last name of one of the authors followed by a descriptive word or two, followed by "00.txt". For example, a draft that someone named Smith wrote might be named "draft-smith-keying-00.txt". If a draft is an individual submission but relates to a particular Working Group, authors sometimes follow their name with the name of the Working Group, such as "draft-smith-smime-keying-00.txt". If you follow the naming guidelines given at http://www.ietf.org/ietf/1id-guidelines.txt, chances are quite good that your suggested filename will be fine.
+For example, a draft in the S/MIME WG about creating keys might be named "draft-ietf-smime-keying-00.txt". If it's not the product of a Working Group, the name will start with "draft-" and the last name of one of the authors followed by a descriptive word or two, followed by "00.txt". For example, a draft that someone named Smith wrote might be named "draft-smith-keying-00.txt". If a draft is an individual submission but relates to a particular Working Group, authors sometimes follow their name with the name of the Working Group, such as "draft-smith-smime-keying-00.txt". If you follow the naming guidelines given at [https://www.ietf.org/ietf/1id-guidelines.txt], chances are quite good that your suggested filename will be fine.
Maybe:
If it's not the product of a Working Group, the name will start with
"draft-" but is not followed by "ietf-". Often the last name of one of
the authors (or some other identifier) is followed by a descriptive word
or two, followed by "00.txt".
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEVodxKgFmUIq9fm5Sj34wDcw5F6hTXOks5uTRFHgaJpZM4VLXpS>.
--
Twitter : @nielstenoever
PGP fingerprint : 8D9F C567 BEE4 A431 56C4
678B 08B5 A0F2 636D 68E9
|
|
Thanks - accepted and changed.
…On 08/22/2018 10:16 AM, mirjak wrote:
***@***.**** commented on this pull request.
------------------------------------------------------------------------
In Tao_Current.txt
<#5 (comment)>:
> 3.3 Newcomer Training
-Newcomers are encouraged to attend the Newcomer's Orientation on Sunday afternoon, which is especially designed for first-time attendees. The orientation is organized and conducted by the IETF EDU team and is intended to provide useful introductory information. The session covers what all the dots on name tags mean, the structure of the IETF, and many other essential and enlightening topics for new IETFers.
+Newcomers are encouraged to attend the Newcomer's Tutorial on Sunday afternoon, which is especially designed for first-time attendees. The tutorial is organized and conducted by the IETF EDU team and is intended to provide useful introductory information. The session covers what all the dots on name tags mean, the structure of the IETF, and many other essential and enlightening topics for new IETFers. If you are unable to attend this session, recorded ones from previous meetings are available ([https://www.ietf.org/about/participate/tutorials/]).
+
+Later in the afternoon is the Quick Connections session where newcomers have the chance to get to know senior IETF participants, and ask questions. The Quick Connections session is followed by the Newcomer's Meet and Greet, which is only open to newcomers and WG chairs. This is a great place to try to find people knowledgeable in the areas in which you are interested. Feel free to approach any WG chair, not just those in your area, to either learn about their WG or to have them help find you someone in yours.
I think it would be useful to be a bit more pushy than "Feel free to
approach chairs...".
Maybe:
This is a good opportunity to connect to the chairs of the working group
your are interested in. If you can't find the right person easily or
don't know which working group your interests are connected to, feel
free to approach anybody without a newcomer ribbon to help you to get in
touch with the right people.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEVod_4pqPn_QI7UgRxKghKfHOaEez75ks5uTRNAgaJpZM4VLXpS>.
--
Twitter : @nielstenoever
PGP fingerprint : 8D9F C567 BEE4 A431 56C4
678B 08B5 A0F2 636D 68E9
|
|
Proposed fix with:
You can register and pay on the web before the meeting, or in person at
the meeting. To get a lower registration fee, you must pay by the
early-bird registration deadline (at least seven weeks before the
meeting). The standard registration fee window closes 2 weeks before the
meeting, if you register any time after that you will need to pay the
fee for late registrants. The registration fee covers all of the week's
meetings, the Sunday evening welcome reception, and afternoon beverage
and snack breaks.
…On 09/06/2018 03:31 PM, Alissa Cooper wrote:
***@***.**** commented on this pull request.
------------------------------------------------------------------------
In Tao_Current.txt
<#5 (comment)>:
>
-You can register and pay on the web before the meeting, or in person at the meeting. To get a lower registration fee, you must pay by the early registration deadline (about one week before the meeting). The registration fee covers all of the week's meetings, the Sunday evening welcome reception (cash bar), daily continental breakfasts, and afternoon beverage and snack breaks.
+You can register and pay on the web before the meeting, or in person at the meeting. To get a lower registration fee, you must pay by the early registration deadline (about one week before the meeting). The registration fee covers all of the week's meetings, the Sunday evening welcome reception, and afternoon beverage and snack breaks.
Five weeks is not correct. There are three registration windows: early
bird, standard, and late. Early bird closes 7 weeks before the meeting.
Standard closes 2 weeks before the meeting. Late is any time after standard.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEVod87MutgDnUuGHN1FzR2Jf-HP3wi9ks5uYSOkgaJpZM4VLXpS>.
--
Twitter : @nielstenoever
PGP fingerprint : 8D9F C567 BEE4 A431 56C4
678B 08B5 A0F2 636D 68E9
|
|
I would actually suggest that we do update the Tao regularly, else we
can also return to the RFC format for the Tao.
…On 09/06/2018 03:33 PM, Alissa Cooper wrote:
***@***.**** commented on this pull request.
------------------------------------------------------------------------
In Tao_Current.txt
<#5 (comment)>:
> 1. Introduction
-Since its early years, attendance at Internet Engineering Task Force (IETF) face-to-face meetings has grown phenomenally. Many of the attendees are new to the IETF at each meeting, and many of those go on to become regular attendees. When the meetings were smaller, it was relatively easy for a newcomer to get into the swing of things. Today, however, a newcomer meets many more new people, some previously known only as the authors of documents or thought-provoking email messages.
+Since its early years, attendance at Internet Engineering Task Force (IETF) face-to-face meetings has grown phenomenally and is now stabilizing. Many of the attendees are new to the IETF at each meeting, and many of those go on to become regular attendees. When the meetings were smaller, it was relatively easy for a newcomer to adjust. Today, however, a newcomer meets many more new people, some previously known only as the authors of documents or thought-provoking email messages.
I still think using specific numbers is unwarranted. The Tao doesn't get
updated very often, so better to make this generic enough that it won't
be out of date in a year if participation trends change.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEVod8Mse-V0fapsCknUxc4AOCOxHR_sks5uYSQTgaJpZM4VLXpS>.
--
Twitter : @nielstenoever
PGP fingerprint : 8D9F C567 BEE4 A431 56C4
678B 08B5 A0F2 636D 68E9
|
|
On Thu, Sep 6, 2018 at 6:52 AM, Niels ten Oever <notifications@github.com>
wrote:
Proposed fix with:
You can register and pay on the web before the meeting, or in person at
the meeting. To get a lower registration fee, you must pay by the
early-bird registration deadline (at least seven weeks before the
meeting). The standard registration fee window closes 2 weeks before the
meeting, if you register any time after that you will need to pay the
fee for late registrants. The registration fee covers all of the week's
meetings, the Sunday evening welcome reception, and afternoon beverage
and snack breaks.
I don't think we should name specific values. Then we have to revise this
whenever the policies change
… On 09/06/2018 03:31 PM, Alissa Cooper wrote:
> ***@***.**** commented on this pull request.
>
> ------------------------------------------------------------------------
>
> In Tao_Current.txt
> <#5 (comment)>:
>
>>
> -You can register and pay on the web before the meeting, or in person at
the meeting. To get a lower registration fee, you must pay by the early
registration deadline (about one week before the meeting). The registration
fee covers all of the week's meetings, the Sunday evening welcome reception
(cash bar), daily continental breakfasts, and afternoon beverage and snack
breaks.
> +You can register and pay on the web before the meeting, or in person at
the meeting. To get a lower registration fee, you must pay by the early
registration deadline (about one week before the meeting). The registration
fee covers all of the week's meetings, the Sunday evening welcome
reception, and afternoon beverage and snack breaks.
>
> Five weeks is not correct. There are three registration windows: early
> bird, standard, and late. Early bird closes 7 weeks before the meeting.
> Standard closes 2 weeks before the meeting. Late is any time after
standard.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#5 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/
AEVod87MutgDnUuGHN1FzR2Jf-HP3wi9ks5uYSOkgaJpZM4VLXpS>.
>
--
Twitter : @nielstenoever
PGP fingerprint : 8D9F C567 BEE4 A431 56C4
678B 08B5 A0F2 636D 68E9
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#5 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABD1oSpFDP3mCIycRkkgFnMgBfP_SdGEks5uYSiNgaJpZM4VLXpS>
.
|
|
OK, removed 'unfettered'.
…On 09/06/2018 03:36 PM, Alissa Cooper wrote:
***@***.**** commented on this pull request.
------------------------------------------------------------------------
In Tao_Current.txt
<#5 (comment)>:
> 3.7 Terminal Room
-One of the most important (depending on your point of view) things the host does is provide Internet access for the meeting attendees. In general, wireless connectivity is excellent in all the meeting rooms and most common areas, and the wired connectivity is provided in the terminal room. The people and companies that donate their equipment, services, and time are to be heartily congratulated and thanked.
+One of the most important (depending on your point of view) things the host does is provide unfettered Internet access for the meeting attendees. In general, wireless connectivity is excellent in all the meeting rooms and most common areas, and the wired connectivity is provided in the terminal room. The people and companies that donate their equipment, services, and time are to be heartily congratulated and thanked.
Probably best to drop "unfettered" or borrow the words from the mtgvenue
document.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#5 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEVod5pdmszNRrWKAwlNCt022pCFVbY7ks5uYSTrgaJpZM4VLXpS>.
--
Twitter : @nielstenoever
PGP fingerprint : 8D9F C567 BEE4 A431 56C4
678B 08B5 A0F2 636D 68E9
|
|
This can probably be closed? |
This PR was created to allow for easier review of the diff. DO NOT MERGE.