Re: I-D Action:draft-housley-two-maturity-levels-04.txt
On Wed, Mar 16, 2011 at 1:11 AM, Phillip Hallam-Baker hal...@gmail.com wrote: On Tue, Mar 15, 2011 at 3:33 AM, James M. Polk jmp...@cisco.com wrote: Brian playing devil's advocate here... Say someone submits a request for an existing DS to the IESG and it takes 6 months (or 3 months) to get through the process, but only 2 months remain before the 2 year window is up (since this RFC was published). Does that grandfather the DS into the process - meaning that document is no longer subject to this 'within 2 year notice' rule? I'm just saying that this appears to beg all DS editors to get their DS notifications into the IESG sooner rather than later, which is fine, but that also creates a heck of a workload on the IESG that they currently do not have, does it not? Something is going to be impacted. Make it a 2 year deadline for receiving requests. Problem solved. Yes, good idea. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
On Wed, Mar 16, 2011 at 12:03 AM, Mykyta Yevstifeyev evniki...@gmail.com wrote: Hello, 2011/3/14, Brian E Carpenter brian.e.carpen...@gmail.com: There are numerous improvements in this version and I hope we can get consensus soon. Just a couple of remarks on 5. Transition to a Standards Track with Two Maturity Levels 1) Probably there should be a statement that all existing Internet Standard documents are still classified as Internet Standard. That may seem blindingly obvious, but if we don't write it down, somebody will ask. 2) More substantively, Any protocol or service that is currently at the Draft Standard maturity level may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied. This reclassification is accomplished by submitting a request to the IESG along with a description of the implementation and operational experience. I'm a bit concerned that this doesn't scale, and we will be left with a long tail of DS documents that end up in limbo. One way to avoid this is to encourage bulk reclassifications (rather like we did a bulk declassification in RFC 4450). Another way is to define a sunset date, e.g. Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. I'm personally not sure whether such operations will be acceptable. If there is a Draft Standard, it means that it is more mature that Proposed Standrad. Therefore downgrading DSs to PSs does not seem a good idea personally for me. It is better to say that DSs should remain in this maturity level until properly advanced to FS, obsoleted or moved to Historic status. All our experience shows that unless we have a firm sunset date, the job will never be finished and in fifty years there will still be DS documents. If nobody cares - the document will be downgraded. What's the problem with that? It will still be on the standards track. (Automatic downgrading to Historic would be a different matter.) Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-04.txt
On Wed, Mar 16, 2011 at 6:13 AM, Dave CROCKER d...@dcrocker.net wrote: On 3/14/2011 2:05 PM, Brian E Carpenter wrote: 2) More substantively, Any protocol or service that is currently at the Draft Standard maturity level may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied. This reclassification is accomplished by submitting a request to the IESG along with a description of the implementation and operational experience. I'm a bit concerned that this doesn't scale, and we will be left with a long tail of DS documents that end up in limbo. One way to avoid this is to encourage bulk reclassifications (rather like we did a bulk declassification in RFC 4450). Another way is to define a sunset date, e.g. Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. Brian, Certainly a reasonable concern. However... 1. While the accounting ugliness of leaving these untouched is obvious, I am less clear about the practical trouble they cause. We should gain some public agreement that this is seriousness enough to worry about, and why. 2. Automatic reclassification strikes me as dangerous and likely to have serious unintended consequences. I believe we do not have a history of having done anything like this, in spite of our rules, except for aging out I-Ds. 3. Your's specific proposal assumes ready availability of workers for documents that are used. In fact, the folks who use specs are often far removed from the IETF and neither aware of IETF activities nor available to contribute to them. This is an example of a downside likely to downgrade docs inappropriately, IMO. Alas, I don't have a constructive, alternative suggestion. There's a fairly obvious alternative, which is to shrug about the widespread deployment rule and promote all existing DS automatically to Internet Standard. That wouldn't shock me - and it would be a lot less work for everybody. We could still require widespread deployment for future documents. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
ION approved
An IETF Operational Note has been approved and posted: http://www.ietf.org/IESG/content/ions/ion-ad-sponsoring.html This note discusses the process related to individual submissions, publication of RFCs by finding a sponsoring Area Director to take it through IETF and Internet Engineering Steering Group (IESG) review. This note covers both the the processing in the IESG as well as guidance on when such sponsoring is appropriate. For the general ION page, see http://www.ietf.org/IESG/content/ions.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
This last call technically expires today. Since there were objections to only holding a two week last call, it won't be on the IESG agenda before March 8, and comments on the substance are still most welcome. I will be asking the IESG to consider whether it should be published as an ION rather than as an RFC. Brian (as General AD) On 2007-02-07 16:20, The IESG wrote: The IESG has received a request from the Internet Engineering Steering Group (iesg) to consider the following document: - 'Guidance on Area Director Sponsoring of Documents ' draft-iesg-sponsoring-guidelines-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-02-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-iesg-sponsoring-guidelines-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15381rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
ion-agenda-and-minutes open for public comment
An ION (IETF Operational Note, see RFC 4693) is open for public comment on the ietf@ietf.org list. Comments should be sent by 2007-02-12. Note that some early reviewers have suggested that this document is not really needed, since IETF minutes are already of a good enough standard. Opinions on this point are welcome. Please see http://www.ietf.org/IESG/content/ions/drafts/ion-agenda-and-minutes.html ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ion-procdocs open for public comment
An ION (IETF Operational Note, see RFC 4693) is open for public comment on the ietf@ietf.org list. Comments should be sent by 2007-02-12. Please see http://www.ietf.org/IESG/content/ions/drafts/ion-procdocs.html ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ion-procdocs open for public comment
An ION (IETF Operational Note, see RFC 4693) is open for public comment on the ietf@ietf.org list. Comments should be sent by 2007-02-12. Please see http://www.ietf.org/IESG/content/ions/drafts/ion-procdocs.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
ion-agenda-and-minutes open for public comment
An ION (IETF Operational Note, see RFC 4693) is open for public comment on the ietf@ietf.org list. Comments should be sent by 2007-02-12. Note that some early reviewers have suggested that this document is not really needed, since IETF minutes are already of a good enough standard. Opinions on this point are welcome. Please see http://www.ietf.org/IESG/content/ions/drafts/ion-agenda-and-minutes.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: Routing Addressing -- activities (BOF)
As part of the routing and addressing activities, a BOF is planned during IETF 68, as a plenary activity (day and time to be announced later). This will be tracked in the BOF wiki at http://www1.tools.ietf.org/bof/trac/wiki Details so far: * ROAP o ROuting and Addressing Problem BOF o Joint with Internet Area; will be a plenary session o Status: preliminary discussions o Background: RAWS report o Responsible ADs: Ross Callon, Mark Townsley Ross and Mark will be collecting proposals for the goals and content of the BOF. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Looking for another IESG scribe
The IESG's informal narrative minutes can be found at http://www.ietf.org/IESG/iesg-narrative.html These minutes rely on volunteer scribes, who join the IESG teleconferences to take notes. We would like to appoint a third scribe, to reduce the load on Spencer Dawkins and Marshall Eubanks. If you think you have the necessary skills, and a few hours per month available, please write to me at [EMAIL PROTECTED] by January 12th. Brian Carpenter, for the IESG ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
ion-ion-store open for public comment
An ION (IETF Operational Note, see RFC 4693) is open for public comment on the ietf@ietf.org list. Comments should be sent by 2006-12-31. Please see http://www.ietf.org/IESG/content/ions/drafts/ion-ion-store.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
ion-ion-format open for public comment
An ION (IETF Operational Note, see RFC 4693) is open for public comment on the ietf@ietf.org list. Comments should be sent by 2006-12-31. Please see http://www.ietf.org/IESG/content/ions/drafts/ion-ion-format.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Updated charter and strengthened leadership for EDU team
The charter of the EDU team has been updated; please see http://edu.ietf.org/ I'm glad to welcome Margaret Wasserman as co-leader of the team with Avri Doria. Brian Carpenter General Area Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
IETF Journal 2.2 published
See http://www.isoc.org/tools/blogs/ietfjournal/?cat=9 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
The BOF wiki
http://www1.tools.ietf.org/bof/trac/wiki This is a best-efforts attempt to track BOF requests (not approved BOFs, which will be in the official agenda). If you're aware of a BOF request that isn't listed, please contact the relevant Area Director for status. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Reminder - BOF proposal deadline is Monday September 18
September 18, Monday - Cutoff date for requests to schedule Working Group meetings and for preliminary BOF proposals to ADs at 17:00 ET (21:00 UTC/GMT). To request a Working Group session, use the IETF Meeting Session Request Tool September 25, Monday - Cutoff date for requests to schedule BOFs at 17:00 ET (21:00 UTC/GMT). All deadlines are listed at http://www.ietf.org/meetings/67-cutoff_dates.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
How to receive IESG agendas by email
Hi, There is a new mailing list that anyone can join in order to receive advance notice of the upcoming IESG agenda. One week before each official IESG teleconference, the draft agenda will be sent to this list, once as an ASCII message and once as an HTML message containing relevant links. This isn't new information, since the agenda is always posted (and updated) at http://www.ietf.org/IESG/agenda.html. However, various people have expressed a desire to receive an email version, so here it is. Please feel free to join the list via this URL: https://www1.ietf.org/mailman/listinfo/iesg-agenda-dist It's not a discussion list, so only the Secretariat can post. Brian Carpenter ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
IESG response and questions to the normative reference experiment (draft-klensin-norm-ref-01.txt)
[Discussion invited on [EMAIL PROTECTED] The IESG received a request under RFC 3933 to run draft-klensin-norm-ref-01.txt as an experiment in loosening the IETF's requirements for normative references in RFCs. The experiment is composed of two parts. The first part allows approved Internet Drafts to reference RFCs at a lower level of maturity, provided that a note explaining the reference is added. One way of looking at this is that it relaxes the requirements for normative downreferences in RFC 3967. The IESG believes that there is sufficient support for this part of the experiment that simply writing a BCP is a better approach than running an experiment. The second part of the experiment proposes that RFCs be allowed to contain normative down references to approved Internet Drafts that have not yet been published as RFCs. According to RFC 3933, the IESG must make a determination of whether an experiment is plausibly useful before it is approved. The IESG can institute whatever procedures it wishes to make this determination and to avoid denial of service attacks from large numbers of spurious or unimportant proposals. In particular, they might institute a procedure requiring a number of endorsements, or endorsements of a particular type, before the IESG considers the proposal. The IESG is, however, expected to understand that procedures or review processes that act as a mechanism for significant delays do not fall within the intent of this specification. The IESG is new to RFC 3933 experiments and like the rest of the community is still trying to figure out how to evaluate these experiments. In this instance, the IESG issued a last call and the discussion focused around the question of whether it would be a good idea if the IETF tried this experiment. The consensus was by no means clear-cut. The IESG believes it is likely that after more definition, we could eventually get to an experiment for which there is community consensus. However the question of plausibly useful includes aspects that were not adequately considered during the last call. In particular, while discussing how to move forward, the IESG realized it had never actually considered who would use the second part of the experiment. When queried, no area director indicated a specific desire to use the experiment to reference an approved Internet Draft from an RFC. The IESG believes the second part of this experiment is unlikely to be useful unless there are IESG members that find it sufficiently compelling to invest time in trying to use the experiment. In the future, it may be desirable to ask for specific intentions of IESG members for experiments that would only be successful with the active participation of some IESG members. The question is: are there IESG members who have a specific need for the proposed experiment and are going to use this proposal in real life? This should not be used to block efforts for change with very strong community support. However it is appropriate to use such endorsements to focus our efforts especially when consensus is mixed or when there are a lot of efforts on the table. The IESG realizes that it needs to be responsive to the community. The IESG also trusts that we all realize that change where there is active, eager support will be more successful than change with inadequate support. So, in conclusion, the IESG seeks comments on whether there is community interest in turning the first part of this experiment into a BCP. The IESG also seeks comments from interested document editors and working group chairs pointing to instances where the second part of the experiment would be useful. In particular, please let the IESG know about upcoming work where being able to reference approved Internet Drafts from RFCs would be useful; please explain how it would be useful. Unless the IESG finds significant cases where the second part of this experiment will be useful, the IESG plans to decline to run that part of the experiment. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IESG response and questions to the normative reference experiment (draft-klensin-norm-ref-01.txt)
[Discussion invited on [EMAIL PROTECTED] The IESG received a request under RFC 3933 to run draft-klensin-norm-ref-01.txt as an experiment in loosening the IETF's requirements for normative references in RFCs. The experiment is composed of two parts. The first part allows approved Internet Drafts to reference RFCs at a lower level of maturity, provided that a note explaining the reference is added. One way of looking at this is that it relaxes the requirements for normative downreferences in RFC 3967. The IESG believes that there is sufficient support for this part of the experiment that simply writing a BCP is a better approach than running an experiment. The second part of the experiment proposes that RFCs be allowed to contain normative down references to approved Internet Drafts that have not yet been published as RFCs. According to RFC 3933, the IESG must make a determination of whether an experiment is plausibly useful before it is approved. The IESG can institute whatever procedures it wishes to make this determination and to avoid denial of service attacks from large numbers of spurious or unimportant proposals. In particular, they might institute a procedure requiring a number of endorsements, or endorsements of a particular type, before the IESG considers the proposal. The IESG is, however, expected to understand that procedures or review processes that act as a mechanism for significant delays do not fall within the intent of this specification. The IESG is new to RFC 3933 experiments and like the rest of the community is still trying to figure out how to evaluate these experiments. In this instance, the IESG issued a last call and the discussion focused around the question of whether it would be a good idea if the IETF tried this experiment. The consensus was by no means clear-cut. The IESG believes it is likely that after more definition, we could eventually get to an experiment for which there is community consensus. However the question of plausibly useful includes aspects that were not adequately considered during the last call. In particular, while discussing how to move forward, the IESG realized it had never actually considered who would use the second part of the experiment. When queried, no area director indicated a specific desire to use the experiment to reference an approved Internet Draft from an RFC. The IESG believes the second part of this experiment is unlikely to be useful unless there are IESG members that find it sufficiently compelling to invest time in trying to use the experiment. In the future, it may be desirable to ask for specific intentions of IESG members for experiments that would only be successful with the active participation of some IESG members. The question is: are there IESG members who have a specific need for the proposed experiment and are going to use this proposal in real life? This should not be used to block efforts for change with very strong community support. However it is appropriate to use such endorsements to focus our efforts especially when consensus is mixed or when there are a lot of efforts on the table. The IESG realizes that it needs to be responsive to the community. The IESG also trusts that we all realize that change where there is active, eager support will be more successful than change with inadequate support. So, in conclusion, the IESG seeks comments on whether there is community interest in turning the first part of this experiment into a BCP. The IESG also seeks comments from interested document editors and working group chairs pointing to instances where the second part of the experiment would be useful. In particular, please let the IESG know about upcoming work where being able to reference approved Internet Drafts from RFCs would be useful; please explain how it would be useful. Unless the IESG finds significant cases where the second part of this experiment will be useful, the IESG plans to decline to run that part of the experiment. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
First RFC 4633 procedure for six month suspensions
This procedure is an RFC 4633 procedure for mailing list suspensions under the RFC 4633 experiment. This procedure applies to all IETF mailing lists that are covered by RFC 4633. The IESG approved this procedure on 2006-08-31. When area directors are involved in a situation where an IETF mailing list is undergoing disruption, they first work with interested parties to try and find a constructive solution to the underlying problem that leads to the disruption. This often involves talking to the disruptive parties to make sure their concerns are understood as well as to inform them of expected rules of conduct. When such constructive solutions fail to work and when a 30-day suspension has been tried and failed, the IESG may approve a posting-rights suspension of up to six months for a named set of individuals from the affected mailing lists. The IESG may delegate the authority to re-suspend some or all of the named individuals to the mailing list manager or area director should these delegates determine that disruption has resumed after the suspension expires. In no event shall a suspension last for more than six months nor shall any suspension last beyond the end of the RFC 4633 experiment. Whenever a suspension or re-suspension is made under this procedure, a notice must be sent to the affected mailing lists announcing who has been suspended. Any IESG member may ask to have a delegate's decision to re-suspend an individual reviewed by the whole IESG. This review should be much less formal than an appeal; it should be treated as the same sort of review that the IESG would perform if it had received a request to re-suspend an individual in a case where this authority was not re-delegated. The suspension remains in force during such a review. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Reminder: Earlier dates for BOF proposals
Here is a reminder of the BOF scheduling deadlines for San Diego. There might be some confusion since I just noticed a link to an obsolete version on the IETF site. --- If you are expecting to propose a BOF in San Diego, please note the new scheduling deadlines: August 7, Monday - WG and BOF scheduling begins September 18, Monday - Cutoff date for requests to schedule WG and for preliminary BOF proposals to ADs September 25, Monday - Cutoff date for requests to schedule BOF In other words you MUST send a preliminary proposal to the relevant AD by September 18; but earlier would be better. The final scheduling request must be sent by September 25. This change is designed to ensure that all BOF proposals can be discussed between the IESG and IAB before a final decision is taken. The general BOF procedures are at http://www.ietf.org/ietf/1bof-procedures.txt and there is excellent general advice at http://tools.ietf.org/html/draft-narten-successful-bof Brian Carpenter ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Volume 2 Issue 1 of the IETF Journal
Volume 2 Issue 1 of the IETF Journal is now available via: http://ietfjournal.isoc.org/ (sent on behalf of the Editor, Mirjam Kuehne) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Notes from IESG Retreat held in May
The notes from the recent IESG Retreat, held May 5/6, 2006, can be found at the following URL: http://www.ietf.org/u/ietfchair/Spring06retreatNotes.txt Brian Carpenter IESG Chair ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Call for additional IESG narrative scribe volunteers
The IESG narrative minutes are posted, whenever available, at http://www.ietf.org/IESG/iesg-narrative.html. Currently, two scribes (Spencer Dawkins and Marshall Eubanks) share the work. The IESG would like to recruit a third scribe to spread the load. Volunteers should write to iesg@ietf.org by May 17. We'll keep names confidential, unless of course people choose to volunteer in public. The general guidelines are: - at least one scribe attends the regular IESG telechats (11:30 - 14:00 US ET on alternate Thursdays). - the scribe(s) record narrative minutes of the discussions, and do not take part in the discussions except to ask for clarifications. - the narrative minutes will be published after review by the IESG. The intent is to do this two to four weeks after the meeting in question. - confidential items (principally personnel discussions) will not be reported in detail. The scribe will not take part in any sessions that liaisons are excluded from (e.g. nominating discussions and appeal discussions). Brian Carpenter for the IESG ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Submission of BOF requests recommended by May 22
The formal cutoff date for BOF requests for IETF 66 is June 5. However, the IESG *strongly* urges that all BOF requests, with supporting material, should be sent to the relevant Area Director at least two weeks before that date, i.e. by May 22, in order to allow time for full consideration by the IESG and IAB. Please see draft-narten-successful-bof-01.txt for suggestions on how to plan a successful BOF, and also http://www.ietf.org/ietf/1bof-procedures.txt. Brian Carpenter, for the IESG ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Summary of IESG Efficiency retreat
This can now be found at: http://www.ietf.org/u/ietfchair/Jan06retreat.txt In particular, the IESG settled on some new target times for document processing by the IESG and by authors. Brian Carpenter ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Volume 1 Issue 2 of the IETF Journal
Volume 1 Issue 2 of the IETF Journal is now available at: http://ietfjournal.isoc.org/ (sent on behalf of the Editor, Peter Godwin) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Final Update - IETF Trust Consensus Call
(posted for Lucy Lynch, IAOC Chair) All - The amended language for Section 9.5 (Licensing) of the IETF Trust was posted to the IETF lists on December 1st and the IETF Trust FAQ has been updated to reflect the new text (see below). We have also added additional details on the handling of historical data. As we develop procedures for the transfer of assets into the IETF Trust and an inventory of items held by the IETF Trust we will publish them to the IAOC web site (see: http://koi.uoregon.edu/~iaoc/) Several people asked for additional time to review our final language, and with that in mind, I would like to extend this Call one last time to December 8th, 2005. Please send comments to: ietf@ietf.org or iaoc.ietf.org - Thanks Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 FAQ Updates: - 18. How will the license provisions in Section 9.5 affect the contents of Standards related documents like RFCs and Internet Drafts. The IETF IPR rules in force when such documents were published still apply and Section 9.5 has been updated to reflect community concerns about the effect of licensing terms. The new text reads: 9.5 Licenses. The Trust (acting through the Trustees) shall have the right to grant licenses for the use of the Trust Assets on such terms, subject to Section 7.1, as the Trustees deem appropriate; provided, however, that the Trust shall not grant any license that would be deemed a transfer of ownership or abandonment of any Trust Assets under applicable law. Specifically, any license granted by the Trust for the use of the Trust Assets consisting of IPR other than rights in IETF standards-related documents (such as RFCs, Internet Drafts and the like) that have been acquired by the Trust through non-exclusive licenses granted by their contributors pursuant to the IETF community-approved procedures currently set forth in RFC 3978, and any community-approved updates and revisions thereto, shall include provisions stating that (a) the licensee agrees to grant and assign to the Trust all right, title, and interest it may have or claim in any derivative works of licensee that are based on or incorporate the IPR, and (b) the licensee's use of the IPR and any goodwill associated therewith shall inure to the benefit of the Trust. 19. Which of the assets listed in Schedule A will be transferred when the IETF Trust is established? Will the Trustees publish an accounting of these assets? All of the Marks, Domain Names, and Current Data listed in Schedule A will be transferred at closing. In addition, Historical Data that is currently available from available from the servers currently operated by or for the IETF Secretariat (i.e. data available on spinning disk) will also be transferred at closing. The Trustees will inventory all assets and provide a full accounting to the IETF community. Historical data which is currently in-accessible will be subject to the conditions outlined in sub-sections b-g. When and if additional data becomes available, those assets will transfer to the IETF Trust and will be added to the inventory. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
IETF budget detail
(posted on behalf of Ray Pelletier) A brief overview of the IETF FY06 budget will be presented at the Wednesday Plenary. Those interested in more detail, rationale, history and assumptions may find them at the following IAOC link: http://koi.uoregon.edu/~iaoc/ Ray Pelletier IETF Administrative Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Reminder: Tickets for IETF-64 Social are still on sale
(posted on behalf of Ed Juskevicius) FYI, tickets for the IETF Social on Tuesday evening, November 8th, are still available for purchase on-line at: https://www.meetinghq.com/group/101004751?wslid=nortel_ietf2005social A short FAQ related to this Social is contained in: http://www1.ietf.org/mail-archive/web/ietf/current/msg38485.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
First set of IESG narrative minutes
The first set of IESG narrative minutes are now available. The link is just below the link for the official minutes, on http://www.ietf.org/iesg.html These minutes are intended to give more detail about discussions during IESG teleconferences but they do not replace the official minutes as the record of decisions. They are informal and not a complete record of the discussions. It's taken us a bit longer than we hoped to start this experiment, but we hope the community will find it useful. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
FYI: Announcing the IETF Journal - a new ISOC publication
(As announced to the ISOC membership) Announcing the IETF Journal - a new ISOC publication ISOC is pleased to announce the IETF Journal, a new Internet Society publication produced in cooperation with the Internet Engineering Task Force. Our aim is to provide an easily understandable overview of what's happening in the world of Internet standards with a particular focus on the activities of the IETF Working Groups (WG). Each issue of the IETF Journal will highlight some of the hot issues being discussed in IETF meetings and in the IETF mailing lists. Our first issue takes a look back at the recent 63rd meeting of the IETF in Paris and is available here:http://ietfjournal.isoc.org/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Creation of the Real-time Applications and Infrastructure (RAI) Area
Creation of the Real-time Applications and Infrastructure (RAI) Area The IESG is grateful for the useful comments received on the proposal to create an RAI Area (see http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01566.html for the original proposal). After integrating those comments and carefully considering the arguments both in favour and against, the IESG has decided to create the new area starting in March 2006 and has duly informed the NomCom Chair. The revised area description is attached below. One concern expressed was about the impact of increasing the number of Area Directors on the IESG's efficiency. The IESG takes this concern seriously and we intend soon to discuss operational and organisational changes to deal with it. Brian Carpenter for the IESG --- Real-time Applications and Infrastructure Area: The Real-Time Applications and Infrastructure Area develops protocols and architectures for delay-sensitive interpersonal communications Work in this area serves an industry whose applications and services include voice and video over IP, instant messaging and presence. These applications and services are real-time in the sense set out first in RFC 1889. The RAI Area is seeded with existing working groups from the Transport and Applications Areas: AVT, ECRIT, ENUM, GEOPRIV, IEPREP, IPTEL, MEGACO, MMUSIC, SIGTRAN, SIMPLE, SIP, SIPPING, SPEECHSC, and XCON. A good rule of thumb for the incorporation of new work into RAI, as opposed to Transport or Applications, is that the work in question is needed to support real-time interpersonal communication. The infrastructure applications needed to support such communications are explicitly in scope, as are discussions of operational concerns specific to this area. For example, work might relate to presence services, to session signaling protocols and emergency call routing solutions, or to work on the layer five issues for Internet telephony. Like all areas of the IETF, the RAI Area draws on the work of numerous other areas, and as such there can be no neat mathematical boundaries delineating RAI's work from the rest of the IETF. The new area will allow an existing community within the IETF to solidify its vision and to benefit from increased institutional support. --- ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Update on the IPR Trust
(sent for Lucy Lynch, IAOC Chair, for those who didn't see it on the IETF discussion list) All - As I outlined in my presentation at IETF 63*, the IAOC is pursuing the notion of a dedicated IPR Trust. We have been through several revisions of the Trust document and have developed a formula that we believe will work for all parties. Below you'll find a summary of the current framework for such a trust. The IAOC believes that the formation of such a Trust is in the best interests of the IETF as a whole and we hope to close on a final document in the near future. Please send comments or questions to: [EMAIL PROTECTED] *(http://koi.uoregon.edu/~iaoc/116.html) IETF IPR Trust Summary: __ The IETF Trust will be created by ISOC, CNRI and the IETF. Its purposes include acquiring, holding, maintaining and licensing certain existing and future intellectual property used in connection with the Internet standards process. The Beneficiary of the Trust shall be the IETF as a whole. ISOC and CNRI, as settlors, will transfer to the Trust all of their right, title and interest, if any, in and to their respective IPR relevant to the IETF [specified below]. The Trustees will encourage others who may hold rights and interests in intellectual property, domain names or other property relevant to the IETF to similarly transfer all of their respective rights, title and interest therein to the Trust. The Trustees will be the members of the IAOC. The Trust shall be for an indefinite term (limited to the maximum period permitted by law). Prior to July 1, 2010, the Trust Agreement may be amended only by unanimous written consent of ISOC and CNRI and two-thirds of the Trustees. After July 1, 2010, the Trustees, acting by at least a two-thirds majority vote, may elect to amend or terminate the Trust. The Trust (acting through the Trustees) shall have the right to grant licenses for the use of the Trust Assets on such terms, as the Trustees deem appropriate; provided, however, that the Trust shall not grant any license that would be deemed a transfer of ownership or abandonment of any Trust Assets under applicable law. Initial contributed IPR shall be (as far as the parties' rights extend): - Trademarks - Domain names - Current databases, mailing lists, web pages, working group and IESG materials - Current I-Ds and RFCs - Rights in extracted historical data (records of past meetings, past I-Ds and RFCs and their processing history) __ Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Monthly Report for the IAOC for August, 2005
(Sent on behalf of Lucy Lynch, IAOC Chair) Monthly Report for the IAOC for August, 2005. The IETF Administrative Oversight Committee (IAOC) was formed to provide appropriate direction to the IAD [IETF Administrative Director], to review the IAD's regular reports, and to oversee IASA functions to ensure that the administrative needs of the IETF community are being properly met. The IAOC is charged by BCP 101 with providing regular reports to the IETF community; this monthly report is intended to serve as part of this reporting requirement. The current membership is (in alphabetical order): Brian Carpenter, IETF Chair, ex officio. Steve Crocker, appointed by the ISOC Board of Trustees for two years. Leslie Daigle, IAB Chair, ex officio. Ed Juskevicius, 1 Year NomCom Selection. Kurtis Lindqvist, appointed by the IESG for one year. Lucy Lynch, appointed by the IAB for two years. Lynn St Amour, ISOC President/CEO, ex officio. Jonne Soininen, 2 Year NomCom Selection. In addition, Marshall Eubanks serves as the Secretary and scribe. The IAOC conducts regular (presently weekly) teleconferences, for which minutes are currently available at http://koi.uoregon.edu/~iaoc/. The work conducted by the IAOC during the month of August centered on the following areas : IETF meetings, establishment of a Trust for IETF Intellectual Property Rights (IPR), establishment of a contract for Secretariat Services, and various housekeeping details. IETF-63 in Paris, France : The IAOC had Office Hours during the Paris IETF from 3:45 to 4:45 (local time), Tuesday-Wednesday-Thursday, and presented during the Wednesday plenary. The slides from the presentation are available at http://koi.uoregon.edu/~iaoc/docs/ietf-63-iaoc.pdf . Preparations for upcoming IETF Meetings : Registration for IETF-64 was opened on August 31st. The IAOC and Neustar intend to use this meeting as a template to better understand financial flows and expenses associated with an IETF meeting. Possible locations for meetings after IETF-64 were discussed at length in August, and the IAD, along with IETF volunteers and personnel from Foretec and NeuStar, made a site visit to evaluate possible locations for IETF-65 during the week of August 22nd. The IAD and the IETF Chair worked together to develop a survey questionnaire aimed at IETF 63 meeting attendees to evaluate the meeting itself and suggest changes to future meetings. The survey was released publicly on August 17th, and responses closed on August 26th; a total of 373 responses were received. Survey results are available at http://geneva.isoc.org/surveys/results/IETF63/ . IETF Trust : The IAOC met with Robert Kahn of CNRI and Patrice Lyons, CNRI Counsel, on August 3rd to discuss the the proposed IETF Trust for IPR. Based on comments from this and other meetings, and their internal review, the IOAC prepared a new draft Trust agreement during August. After discussion, the IAOC concluded that this draft would benefit from additional legal review and asked the IETF Counsel to forward it and the associated License documents for review by other counsel at Wilmer Cutler Pickering Hale and Dorr. In addition, during the August 3rd meeting it was agreed that some of the text in BCP 101 is based on assumptions that the IASA has moved beyond. The final version of BCP 101, i.e., RFC 4071, assumed that the vehicle for certain IETF-related Intellectual Property Rights (IPR) would be the Internet Society (ISOC). Since the publication of RFC 4071, the IAOC has been working define and create the IETF Trust to hold such IPR. Since this Trust is not described in BCP 101, the IAOC decided that a new BCP, to include the IETF Trust in the definition of the IASA structure, would be of value, and Brian Carpenter prepared a draft, draft-carpenter-bcp101-update-00.txt, with the IAOC's assistance, to address this. This draft was submitted on August 17th. Contract for Secretariat Services : At present, there is no outstanding contract for the services provided by the IETF Secretariat. The IAOC is empowered by the BCP 101 to execute such a contract and is pursuing this matter vigorously. The IETF Secretariat is hosted by Foretec Seminars Inc., a subsidiary of the Corporation for National Research Initiatives (CNRI). Foretec is currently in the process of being sold to NeuStar, Inc. Assuming that this sale is completed, the IAOC intends to contract with NeuStar, if mutually acceptable terms can be reached, to provide these services for a term not to exceed 2 years, with subsequent terms being contracted under a formal Request for Proposals. On August 1st, in Paris, the IAOC met with Mark Foster, Jeff Neuman and Alan Khalili from Neustar to discuss issues related to the shift of Secretariat services, include the draft Statement of Work, IPR License, and the IEFT Trust. The IAOC agreed that the IAD and the IETF Counsel, Jorge Contreras, should prepare a draft IPR License
IETF Process Evolution: PESCI team members
I've picked the following PESCI team members from the various volunteers and nominees: Harald Alvestrand Scott Brim Elwyn Davies Adrian Farrel Michael Richardson Thanks to everybody who was willing to serve at short notice. As a reminder, PESCI's immediate tasks are: - review recent discussions on IETF process changes - identify a concise set of goals and principles for process change - publish these for comment and seek IETF debate and rough consensus and the cutoff date for our first draft is October 17. As noted previously, the open mailing list is [EMAIL PROTECTED] (see https://www1.ietf.org/mailman/listinfo/pesci-discuss) You can write privately to the team at [EMAIL PROTECTED] If you've lost track of the background to PESCI, see http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01567.html ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Results of IETF 63 on-line survey
The results are at http://geneva.isoc.org/surveys/results/IETF63/ One question proved to be ambiguous, so we are not sure how to interpret its result: Would you prefer longer meetings or shorter meetings? was intended to refer to the total length of the IETF meeting, currently Monday 9:00 a.m. through Friday 11:30 a.m. Brian Carpenter, IETF Chair Ray Pelletier, IETF Administrative Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
IETF 63 On-line Survey: Deadline Friday
Note that Javascript is needed for all questions to be visible. Note that the question Would you prefer longer meetings or shorter meetings? refers to the total length of the IETF meeting, currently Monday 9:00 a.m. through Friday 11:30 a.m. To assist the planning of future meetings, we ask you kindly to spend a minute or two responding to the on-line survey at http://geneva.isoc.org/surveys/index.php?sid=4 Even if you did not attend IETF 63 in Paris, we would value your responses. All responses will be treated anonymously, and a summary will be available on-line. Please respond by August 26 at the latest. Thanks Brian Carpenter, IETF Chair Ray Pelletier, IETF Administrative Director ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Monthly Report for the IAOC for June, 2005
Monthly Report for the IAOC for June, 2005. (posted for Lucy Lynch, IAOC Chair) The IETF Administrative Oversight Committee (IAOC) was formed to provide appropriate direction to the IAD [IETF Administrative Director], to review the IAD's regular reports, and to oversee IASA functions to ensure that the administrative needs of the IETF community are being properly met. The IAOC is charged by BCP 101 with providing regular reports to the IETF community; this monthly report is intended to serve as part of this reporting requirement. The current membership is (in alphabetical order): Brian Carpenter, IETF Chair, ex officio. Steve Crocker, appointed by the ISOC Board of Trustees for two years. Leslie Daigle, IAB Chair, ex officio. Ed Juskevicius, 1 Year NomCom Selection. Kurtis Lindqvist, appointed by the IESG for one year. Lucy Lynch, appointed by the IAB for two years. Lynn St Amour, ISOC President/CEO, ex officio. Jonne Soininen, 2 Year NomCom Selection. In addition, Marshall Eubanks serves as the Secretary and scribe. The IAOC conducts regular (presently weekly) teleconferences, for which minutes are currently available at http://koi.uoregon.edu/~iaoc/. This month included a Face to Face meeting of the entire IAOC, except for the IETF Chair, on June 8th in Reston, Virginia. The work conducted by the IAOC during the month of June centered on the following areas : welcoming and beginning to work with the new IAD, establishment of a Trust for IETF Intellectual Property Rights (IPR), establishment of a contract for Secretariat Services, and various housekeeping details. In addition, in June the NomCom announced its selections for two new members for the IAOC, which fills the IAOC as set out in BCP 101. The New IAD : In June, the IAOC began work with the new IAD, Ray Pelletier (whose hiring was effective May 31st). With the assent of the IAOC, the IAD has now assumed responsibility for routine interactions with NeuStar, and has had meetings with the IAOC, the IETF Chair, the RFC Editor and others to gain a better understanding of his new responsibilities. IPR Trust : On June 2nd, the IAOC Chair sent the IAOC's suggested revisions to the proposed Trust document to CNRI. While a formal response has not yet been received from CNRI, this topic was discussed during phone conversations with Robert Kahn of CNRI by the IETF and IAOC Chairs (June 3rd) and by the IAD (June 28th). Contract for Secretariat Services : At present, there is no outstanding contract for the services provided by the IETF Secretariat. The IAOC is empowered by the BCP 101 to execute such a contract and is pursuing this matter vigorously. The IETF Secretariat is hosted by Foretec Seminars Inc., a subsidiary of the Corporation for National Research Initiatives (CNRI). Foretec is currently in the process of being sold to NeuStar, Inc. Assuming that this sale is completed, the IAOC intends to contract with NeuStar, if mutually acceptable terms can be reached, to provide these services for a term not to exceed 2 years, with subsequent terms being contracted under a formal Request for Proposals. On June 1st, the IAOC received a revised Services Agreement from NeuStar. This was discussed at length with Mark Foster (CTO, NeuStar) and Jeff Neuman (Counsel to NeuStar) as part of the face to Face meeting on June 8th. After discussion, a new revision of this proposed Service Agreement was sent to NeuStar on June 23rd by the IAD. The IAD has initiated regular weekly phone calls with NeuStar personnel to facilitate the progress of the proposed draft contract. New Members : The IAOC welcomed two new members during June, Jonne Soininen and Ed Juskevicius, after selection by the IETF NomCom and confirmation by the IESG. These new members complete the IAOC membership authorized by BCP 101. The IAOC intends to revisit its decision procedures and the selection of the IAOC Chair once the new members have had the time to become familiar with the existing structure. Housekeeping : The IAOC and the IETF Secretariat have placed a link to the IAOC web page as part of the Related Web Pages line of the IETF main web page. The IAOC plans to have Office Hours during the Paris IETF and has requested a room for this from the IETF Secretariat. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Proposed update of Tools Team charter
The Tools Team was set up by Harald Alvestrand and has made good progress (e.g. draft-ietf-tools-draft-submission-09, which has been approved as an Informational RFC). Now it's time to update the team's charter. Please see the proposed new charter: http://tools.ietf.org/charters/charter-2005-06-17.html The current charter is at http://tools.ietf.org/charter-page Main changes: References to IASA and IAD added in accordance with BCP 101's assignment of responsibilities. Clarifies that the Tools Team works at most on unsupported prototypes and that IASA is responsible for production tools. Milestones updated. If you have comments on the new charter, please write to [EMAIL PROTECTED] (or to ietf@ietf.org if you really have a point for the whole IETF). Brian Carpenter General AD ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
ISOC Board of Trustees position
The Internet Society has announced the result of its annual election process for its Board of Trustees. The full announcement is at http://www.isoc.org/members/vote/2005election/ For the position selected under RFC 3677 (BCP 77) IETF ISOC Board of Trustee Appointment Procedures, the announcement states: As part of ISOC's election process, one member of the Board is named by the IETF, through selection by the Internet Architecture Board (IAB) and confirmation by the IESG. We are pleased to be able to announce that Fred Baker will be returning for a new three year term on the Internet Society Board of Trustees. Thanks are due both to Fred and to the unselected candidates for their willingness to serve. Also see http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg01001.html (posted by Brian Carpenter during Leslie Daigle's absence on vacation) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Notes from IESG Retreat
The notes from the IESG Retreat held last month can be found at http://www.ietf.org/u/ietfchair/nyon-notes.txt Brian Carpenter ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Monthly Report for the IAOC for April, 2005
(Posted on behalf of Lucy Lynch, IAOC Chair) Monthly Report for the IAOC for April, 2005. As part of the IETF Administrative Support Activity (IASA) described by BCP 101 (RFC4071), the IETF Administrative Oversight Committee (IAOC) was formed to provide appropriate direction to the IAD [IETF Administrative Director], to review the IAD's regular reports, and to oversee IASA functions to ensure that the administrative needs of the IETF community are being properly met. The IAOC is charged by BCP 101 with providing regular reports to the IETF community; this monthly report is intended to serve as part of this reporting requirement. Following the processes outlined in draft-iab-iaoc-selection-01.txt, the IAB, IESG and ISOC selected members for the IAOC in March and early April, 2005. BCP 101 states that The IAOC will become active as soon as a majority (three or more) of the appointed members have been selected. Leslie Daigle and Brian Carpenter, in an email to the IETF Announcement list on April 4, 2005, announced the instantiation of the IAOC : With these appointments and ISOC's concurrent announcement of their selection, the initial IAOC is now live, and the IASA structure is instantiated. The initial IAOC, which also includes the IETF Chair, the IAB Chair, and the ISOC President as ex officio members, will be seated at the first regular business meeting, scheduled for Thursday, April 7. The current membership is (in alphabetical order): Brian Carpenter, IETF Chair, ex officio. Steve Crocker, appointed by the ISOC Board of Trustees for two years. Leslie Daigle, IAB Chair, ex officio. Kurtis Lindqvist, appointed by the IESG for one year. Lucy Lynch, appointed by the IAB for two years. Lynn St Amour, ISOC President/CEO, ex officio. Two additional members are to be provided by the NomCom; this selection process is now underway. The IAOC conducts regular (presently weekly) teleconferences, for which minutes are currently available at http://www.alvestrand.no/ietf/adminrest/transteam/notes/. The first such teleconference, on April 7, 2005, led to the election of Lucy Lynch as the IAOC Chair and the appointment of Marshall Eubanks as the IAOC Secretary. According to BCP 101 The IAOC decides the details about its decision-making rules, including its rules for quorum, conflict of interest, and breaking of ties. and in its first meetings the IAOC decided that all members (including ex officio members) would have one vote and that the IAOC would operate on consensus to the extent possible. The work conducted by the IAOC during the month of April centered on the following areas : IAD hiring, establishment of a contract for Secretariat Services, establishment of a Trust for IETF Intellectual Property Rights (IPR), and resolving logistical and housekeeping details associated with the start of a new oversight body. IAD Hiring : The IAOC is charged with selection of the IAD, who will conduct and oversee most of the day-to-day operational tasks of the IASA. The IASA Transition Team issued a call for applications for this position and conducted the initial interviews of the applicants. The IAOC has continued evaluating these applicants and expects to make a selection in May. Contract for Secretariat Services : At present, there is no outstanding contract for the services provided by the IETF Secretariat. The IAOC is empowered by the BCP 101 to execute such a contract and is pursuing this matter vigorously. The IETF Secretariat is hosted by Foretec Seminars Inc., a subsidiary of the Corporation for National Research Initiatives (CNRI). Foretec is currently in the process of being sold to NeuStar, Inc. Assuming that this sale is completed, the IAOC intends to contract with NeuStar, if mutually acceptable terms can be reached, to provide these services for a term not to exceed 2 years, with subsequent terms being contracted under a formal Request for Proposals. NeuStar has informed the IAOC that it is working on a draft contract and will circulate it to the IAOC for comments soon. NeuStar and the IAOC intend to use the upcoming IETF-63 in Paris as a case study to better understand the revenues, expenses, and service requirements of IETF meetings. IPR Trust : The IAOC received from CNRI a proposed Trust Agreement for the handling of Intellectual Property belonging to the IETF and is discussing it with CNRI. Housekeeping : Directors Insurance for IAOC members is now in place, there is an email to reach the IAOC ([EMAIL PROTECTED]), and it was decided to maintain public IAOC information on the IASA Transition Team Wiki for the present, and to make changes there to reflect the advent of the IAOC. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
