High-Level Guidance for the Meeting Policy of the IETF
draft-ietf-mtgvenue-meeting-policy-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-02-03
|
07 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-01-10
|
07 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-11-27
|
07 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-09-13
|
07 | (System) | RFC Editor state changed to EDIT from MISSREF |
2019-04-18
|
07 | (System) | RFC Editor state changed to MISSREF from EDIT |
2019-04-18
|
07 | (System) | RFC Editor state changed to EDIT from MISSREF |
2018-11-12
|
07 | (System) | RFC Editor state changed to MISSREF from AUTH48 |
2018-10-08
|
07 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-10-08
|
07 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-08-08
|
07 | (System) | IANA Action state changed to No IC from In Progress |
2018-08-08
|
07 | (System) | IANA Action state changed to In Progress |
2018-08-08
|
07 | (System) | RFC Editor state changed to EDIT |
2018-08-08
|
07 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-08-08
|
07 | (System) | Announcement was received by RFC Editor |
2018-08-08
|
07 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup |
2018-08-08
|
07 | Cindy Morgan | IESG has approved the document |
2018-08-08
|
07 | Cindy Morgan | Closed "Approve" ballot |
2018-08-08
|
07 | Cindy Morgan | Ballot approval text was generated |
2018-08-08
|
07 | Cindy Morgan | Ballot writeup was changed |
2018-07-02
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-07-02
|
07 | Suresh Krishnan | New version available: draft-ietf-mtgvenue-meeting-policy-07.txt |
2018-07-02
|
07 | (System) | New version approved |
2018-07-02
|
07 | (System) | Request for posting confirmation emailed to previous authors: Suresh Krishnan |
2018-07-02
|
07 | Suresh Krishnan | Uploaded new revision |
2018-06-12
|
06 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'No Response' |
2018-06-07
|
06 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2018-06-07
|
06 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-06-07
|
06 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2018-06-07
|
06 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-06-06
|
06 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2018-06-06
|
06 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-06-06
|
06 | Alvaro Retana | [Ballot comment] Documenting this policy is important and useful. Making the policy clear for future implementers is even more so. (1) §2 (The 1-1-1-* meeting … [Ballot comment] Documenting this policy is important and useful. Making the policy clear for future implementers is even more so. (1) §2 (The 1-1-1-* meeting policy) talks about "exploratory meeting proposals", but the process to be followed is not clear. Looking at the proposed text to Martin's comment [1]: The timing and frequency of future exploratory meetings will be based on IETF consensus as determined by the IETF chair. Once a meeting proposal is initiated, the IESG will make a decision in consultation with the Internet Administrative Support Activity (IASA) to ensure that the proposal can be realistically implemented. It is not clear to me what should happen if I, for example, would like the IETF to consider an exploratory meeting somewhere. The text talks about both IETF consensus and the IESG making a decision -- it seems to me that the IESG role "to ensure that the proposal can be realistically implemented" may be a nice first step before asking the community for feedback -- but I can see how the process could also be the other way around: if there is no consensus then don't even think about implementation. Please clarify. To all this, should I make my proposal for an exploratory meeting to the IESG, the IETF Chair, the IASA, the community (which list?)...? (2) §4 (Re-evaluation and changes to this policy) says that "this policy needs to be periodically evaluated and revised to ensure that the stated goals continue to be met". Which stated goals? The only goal (or objective/intent/criteria) explicitly mentioned as one is in this text from §1: "The IETF currently strives to have a 1-1-1-* meeting policy [IETFMEET] where the goal is to distribute the meetings equally between North America, Europe, and Asia. These are the locations most of the IETF participants have come from in the recent past." The text above is not clear because it says that the "goal is to distribute the meetings equally between North America, Europe, and Asia"...but [interpreting a little] I think the real intent might have been "to distribute the meetings equally between...the locations most of the IETF participants have come from". Is that the intent? If not, then re-evaluating with the objective to maintain the meetings in North America, Europe and Asia makes no sense. To be clear, if that distribution is the result of the periodic evaluation, then nothing should change -- I'm not raising a point about the regions mentioned, but about the clarity of what the goal is. (2a) Note also that the text in §4 goes on to say that "the criteria that are to be met need to be agreed upon by the community prior to initiating a revision of this document". I think that there are two (independent) things that can be revised: the policy (should it be 1-1-1 or 3-2-1 or ??), and the criteria used to determine the distribution. Based on the aspirational nature of the document, the policy should be able to be changed following the general guidelines ("distribute the meetings equally between...the locations most of the IETF participants have come from") without changing the criteria (which is what would most likely lead to an update of the document). Having statements about updating policy and criteria/document in the same paragraph, I think, confuses the evaluation needs going forward. Separating and clarifying them should help. (3) §3 (Implementation of the policy) As mentioned in [I-D.ietf-mtgvenue-iaoc-venue-selection-process], the IASA will also be responsible o to assist the community in the development of detailed meeting criteria that are feasible and implementable, and I couldn't find a place where I-D.ietf-mtgvenue-iaoc-venue-selection-process mentions that. (4) I think the I-D.ietf-mtgvenue-iaoc-venue-selection-process reference should be Normative. (5) Is the intent for this document and I-D.ietf-mtgvenue-iaoc-venue-selection-process to be part of the same BCP? I would think so, but I didn't see that mentioned an the writeups. [1] https://mailarchive.ietf.org/arch/msg/mtgvenue/t1TbS4qgrz7UF9dF6VGe2M-kAEw |
2018-06-06
|
06 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-06-06
|
06 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-06-06
|
06 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-06-06
|
06 | Benjamin Kaduk | [Ballot comment] Adam's point is valid. In addition to that and the other comments already made, I have an editorial suggestion for the Abstract: … [Ballot comment] Adam's point is valid. In addition to that and the other comments already made, I have an editorial suggestion for the Abstract: This document describes a meeting location policy for the IETF and the various stakeholders for realizing such a policy. I assume this is intended to be "describes ((a location policy) and (the various stakeholders))", in which case using "involved in" rather than "for" may be easier on the reader. |
2018-06-06
|
06 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2018-06-05
|
06 | Adam Roach | [Ballot comment] Thanks for the work everyone did on this document. Author -- please take note of https://tools.ietf.org/html/rfc7322#section-4.8.5 This should probably be a discuss, but … [Ballot comment] Thanks for the work everyone did on this document. Author -- please take note of https://tools.ietf.org/html/rfc7322#section-4.8.5 This should probably be a discuss, but I'm sure it'll be taken care of. I recognize that the contents will be pro-forma, but I worry about precedent. Copying text from draft-ietf-mtgvenue-iaoc-venue-selection-process is likely appropriate. |
2018-06-05
|
06 | Adam Roach | Ballot comment text updated for Adam Roach |
2018-06-05
|
06 | Adam Roach | [Ballot comment] Thanks for the work everyone did on this document. Authors -- please take note of https://tools.ietf.org/html/rfc7322#section-4.8.5 This should probably be a discuss, but … [Ballot comment] Thanks for the work everyone did on this document. Authors -- please take note of https://tools.ietf.org/html/rfc7322#section-4.8.5 This should probably be a discuss, but I'm sure it'll be taken care of. I recognize that the contents will be pro-forma, but I worry about precedent. Copying text from draft-ietf-mtgvenue-iaoc-venue-selection-process is likely appropriate. |
2018-06-05
|
06 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2018-06-05
|
06 | Suresh Krishnan | [Ballot comment] Document Author |
2018-06-05
|
06 | Suresh Krishnan | [Ballot Position Update] New position, Recuse, has been recorded for Suresh Krishnan |
2018-06-05
|
06 | Spencer Dawkins | [Ballot comment] (Sorry, this is a resend. The only change is that I should have clicked on Yes, instead of No Objection) Nice work. I … [Ballot comment] (Sorry, this is a resend. The only change is that I should have clicked on Yes, instead of No Objection) Nice work. I know BCP process text is hard. I share Martin's question, at least to the point where I'm guessing what that text means. 1-1-1-* is used in 1. Introduction The work of the IETF is primarily conducted on the working group mailing lists, while face-to-face WG meetings mainly provide a high bandwidth mechanism for working out unresolved issues. The IETF currently strives to have a 1-1-1-* meeting policy [IETFMEET] where the goal is to distribute the meetings equally between North America, Europe, and Asia. but defined in Section 2, following. I don't know whether it would be better to say "meeting policy" or "meeting rotation policy", but 1-1-1-* probably isn't universally understood without scanning down to Section 2. Are you just going to remove the prefix "BACKGROUND NOTE:"? This could be in its own section, I guess, maybe in an appendix? In While this meeting rotation caters to the current set of IETF participants, we need to recognize that due to the dynamic and evolving nature of participation, there may be significant changes to the regions that provide a major share of participants in the future. perhaps we should say "we recognize"? I'm hoping we've already done that :-) Is NOTE: There have not been a large number of such exploratory meetings under the current 1-1-1-* policy (with IETF95 in Buenos Aires and IETF47 in Adelaide being the exceptional instances). saying NOTE: There have not been a large number of meetings that would qualify as exploratory meetings under the current 1-1-1-* policy (with IETF95 in Buenos Aires and IETF47 in Adelaide being the exceptional instances). ? They weren't actually held under 1-1-1-*, which postdates IETF 27 and IETF 54 considerably … Might o There were some logistical issues (venue availability, cost etc.). be clearer as o There were some logistical issues (venue availability on previously committed dates, cost etc.). ? |
2018-06-05
|
06 | Spencer Dawkins | [Ballot Position Update] Position for Spencer Dawkins has been changed to Yes from No Objection |
2018-06-05
|
06 | Spencer Dawkins | [Ballot comment] Nice work. I know BCP process text is hard. I share Martin's question, at least to the point where I'm guessing what that … [Ballot comment] Nice work. I know BCP process text is hard. I share Martin's question, at least to the point where I'm guessing what that text means. 1-1-1-* is used in 1. Introduction The work of the IETF is primarily conducted on the working group mailing lists, while face-to-face WG meetings mainly provide a high bandwidth mechanism for working out unresolved issues. The IETF currently strives to have a 1-1-1-* meeting policy [IETFMEET] where the goal is to distribute the meetings equally between North America, Europe, and Asia. but defined in Section 2, following. I don't know whether it would be better to say "meeting policy" or "meeting rotation policy", but 1-1-1-* probably isn't universally understood without scanning down to Section 2. Are you just going to remove the prefix "BACKGROUND NOTE:"? This could be in its own section, I guess, maybe in an appendix? In While this meeting rotation caters to the current set of IETF participants, we need to recognize that due to the dynamic and evolving nature of participation, there may be significant changes to the regions that provide a major share of participants in the future. perhaps we should say "we recognize"? I'm hoping we've already done that :-) Is NOTE: There have not been a large number of such exploratory meetings under the current 1-1-1-* policy (with IETF95 in Buenos Aires and IETF47 in Adelaide being the exceptional instances). saying NOTE: There have not been a large number of meetings that would qualify as exploratory meetings under the current 1-1-1-* policy (with IETF95 in Buenos Aires and IETF47 in Adelaide being the exceptional instances). ? They weren't actually held under 1-1-1-*, which postdates IETF 27 and IETF 54 considerably … Might o There were some logistical issues (venue availability, cost etc.). be clearer as o There were some logistical issues (venue availability on previously committed dates, cost etc.). ? |
2018-06-05
|
06 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-06-05
|
06 | Martin Vigoureux | [Ballot comment] Hello, I am not sure to understand what that sentence means (might simply because I'm not a native English reader): The exploratory … [Ballot comment] Hello, I am not sure to understand what that sentence means (might simply because I'm not a native English reader): The exploratory meeting proposals will be initiated based on community consent. If the proposals are *initiated* based on community consent, what has the community effectively consented to? Thank you Martin |
2018-06-05
|
06 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2018-06-04
|
06 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2018-05-21
|
06 | Roni Even | Request for Telechat review by GENART Completed: Ready. Reviewer: Roni Even. Sent review to list. |
2018-05-18
|
06 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2018-05-17
|
06 | Alissa Cooper | Ballot has been issued |
2018-05-17
|
06 | Alissa Cooper | [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper |
2018-05-17
|
06 | Alissa Cooper | Created "Approve" ballot |
2018-05-17
|
06 | Alissa Cooper | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2018-05-17
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
2018-05-17
|
06 | Jean Mahoney | Request for Telechat review by GENART is assigned to Roni Even |
2018-05-14
|
06 | Suresh Krishnan | New version available: draft-ietf-mtgvenue-meeting-policy-06.txt |
2018-05-14
|
06 | (System) | New version approved |
2018-05-14
|
06 | (System) | Request for posting confirmation emailed to previous authors: Suresh Krishnan |
2018-05-14
|
06 | Suresh Krishnan | Uploaded new revision |
2018-05-14
|
05 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2018-05-14
|
05 | Suresh Krishnan | New version available: draft-ietf-mtgvenue-meeting-policy-05.txt |
2018-05-14
|
05 | (System) | New version approved |
2018-05-14
|
05 | (System) | Request for posting confirmation emailed to previous authors: Suresh Krishnan |
2018-05-14
|
05 | Suresh Krishnan | Uploaded new revision |
2018-05-04
|
04 | Alissa Cooper | Telechat date has been changed to 2018-06-07 from 2018-05-10 |
2018-04-26
|
04 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Chris Lonvick. |
2018-04-24
|
04 | Min Ye | Request for Telechat review by RTGDIR Completed: Has Issues. Reviewer: Julien Meuric. |
2018-04-19
|
04 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2018-04-17
|
04 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2018-04-17
|
04 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-mtgvenue-meeting-policy-04, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-mtgvenue-meeting-policy-04, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-04-15
|
04 | Roni Even | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Roni Even. Sent review to list. |
2018-04-12
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2018-04-12
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2018-04-10
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tina Tsou |
2018-04-10
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tina Tsou |
2018-04-09
|
04 | Jonathan Hardwick | Request for Telechat review by RTGDIR is assigned to Julien Meuric |
2018-04-09
|
04 | Jonathan Hardwick | Request for Telechat review by RTGDIR is assigned to Julien Meuric |
2018-04-06
|
04 | Alvaro Retana | Requested Telechat review by RTGDIR |
2018-04-05
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2018-04-05
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2018-04-05
|
04 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2018-04-05
|
04 | Cindy Morgan | The following Last Call announcement was sent out (ends 2018-04-19): From: The IESG To: IETF-Announce CC: Charles Eckel , draft-ietf-mtgvenue-meeting-policy@ietf.org, alissa@cooperw.in, eckelcu@cisco.com, … The following Last Call announcement was sent out (ends 2018-04-19): From: The IESG To: IETF-Announce CC: Charles Eckel , draft-ietf-mtgvenue-meeting-policy@ietf.org, alissa@cooperw.in, eckelcu@cisco.com, mtgvenue-chairs@ietf.org, mtgvenue@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (High level guidance for the meeting policy of the IETF) to Best Current Practice The IESG has received a request from the Meeting Venue WG (mtgvenue) to consider the following document: - 'High level guidance for the meeting policy of the IETF' as Best Current Practice 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 2018-04-19. 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. Abstract This document describes a proposed meeting location policy for the IETF and the various stakeholders for realizing such a policy. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-meeting-policy/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-meeting-policy/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-04-05
|
04 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2018-04-05
|
04 | Alissa Cooper | Ballot writeup was changed |
2018-04-05
|
04 | Alissa Cooper | Placed on agenda for telechat - 2018-05-10 |
2018-04-05
|
04 | Alissa Cooper | Last call was requested |
2018-04-05
|
04 | Alissa Cooper | Ballot approval text was generated |
2018-04-05
|
04 | Alissa Cooper | Ballot writeup was generated |
2018-04-05
|
04 | Alissa Cooper | IESG state changed to Last Call Requested from AD Evaluation |
2018-04-05
|
04 | Alissa Cooper | Last call announcement was generated |
2018-02-24
|
04 | Suresh Krishnan | New version available: draft-ietf-mtgvenue-meeting-policy-04.txt |
2018-02-24
|
04 | (System) | New version approved |
2018-02-24
|
04 | (System) | Request for posting confirmation emailed to previous authors: Suresh Krishnan |
2018-02-24
|
04 | Suresh Krishnan | Uploaded new revision |
2018-02-08
|
03 | Alissa Cooper | IESG state changed to AD Evaluation from Publication Requested |
2018-01-11
|
03 | Alissa Cooper | Shepherding AD changed to Alissa Cooper |
2018-01-11
|
03 | Charles Eckel | [Based on the 24 February 2012 template of the Document Shepherd Write-Up.] (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, … [Based on the 24 February 2012 template of the Document Shepherd Write-Up.] (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in title page header? BCP, as listed on the title page - This document defines an administrative policy for the IETF. It is intended to be the product of IETF consensus. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The IETF currently strives to have a 1-1-1-* meeting policy, the goal of which is where to distribute meeting locations equally between North America, Europe, and Asia. This meeting rotation is aimed at distributing the travel pain for IETF participants who physically attend meetings and the time zone pain for those who participate remotely. This policy has neither been defined precisely nor documented in an IETF consensus document. This document is meant to serve as a consensus-backed statement of this policy published as a BCP. Working Group Summary There was relatively little discussion on this draft. It progressed slowly but without much debate or heated discussion. There were only minor changes to the draft. These were based on working group discussion and consensus. The most noteworthy items hashed out in the working group were: 1) Consensus to leave the terms North America, Europe, and Asia vague and subject to interpretation 2) Consensus that maximizing in person attendance at meetings was not a goal of the policy 3) Consensus to use community consent as the bar for pursuing an exploratory meeting Document Quality The document went through a few rounds of light review, both before being adopted as a working group document as well as once adopted. All comments resulting from these reviews were addressed. Personnel Charles Eckel is the shepherd. Alissa Cooper is the responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The shepherd has read each version of the document, including the current one, and has read all commentary on the WG mailing list to ensure that all issues were addressed. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No other specialist reviews required. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No major concerns. The document lacks a Security Considerations section and an IANA Considerations section. The omission of these sections is appropriate for this document. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. This is a non-technical document, no IPR should be applicable. The draft author has confirmed having no IPR associated with this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None filed. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There appears to be WG-wide agreement on the document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No appeals anticipated. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are a couple nits to be addressed in the post-Last Call or post-IESG review version of the document: The copyright year in the IETF Trust and authors Copyright Line does not match the current year (i.e. 2017 vs. 2018) RFC 4071 is listed as a normative reference but there is not an explicit reference to it within the text of the document. An explicit reference should be added in section 2 where IASA is first mentioned, and the reference should be changed from normative to informative. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No required formal reviews outside of normal IETF process requirements. (13) Have all references within this document been identified as either normative or informative? Yes, with one normative reference to be recategorized as informational as noted in (11). (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. None noted. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). No IANA allocations. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No IANA allocations. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. None needed. |
2018-01-11
|
03 | Charles Eckel | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-01-11
|
03 | Charles Eckel | IESG state changed to Publication Requested |
2018-01-11
|
03 | Charles Eckel | IESG process started in state Publication Requested |
2018-01-11
|
03 | Charles Eckel | Changed document writeup |
2018-01-02
|
03 | Charles Eckel | Changed consensus to Yes from Unknown |
2018-01-02
|
03 | Charles Eckel | Intended Status changed to Best Current Practice from None |
2017-12-07
|
03 | Charles Eckel | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2017-12-07
|
03 | Charles Eckel | Notification list changed to Charles Eckel <eckelcu@cisco.com> |
2017-12-07
|
03 | Charles Eckel | Document shepherd changed to Charles Eckel |
2017-12-06
|
03 | Suresh Krishnan | New version available: draft-ietf-mtgvenue-meeting-policy-03.txt |
2017-12-06
|
03 | (System) | New version approved |
2017-12-06
|
03 | (System) | Request for posting confirmation emailed to previous authors: Suresh Krishnan |
2017-12-06
|
03 | Suresh Krishnan | Uploaded new revision |
2017-12-04
|
02 | Suresh Krishnan | New version available: draft-ietf-mtgvenue-meeting-policy-02.txt |
2017-12-04
|
02 | (System) | New version approved |
2017-12-04
|
02 | (System) | Request for posting confirmation emailed to previous authors: Suresh Krishnan |
2017-12-04
|
02 | Suresh Krishnan | Uploaded new revision |
2017-07-19
|
01 | Pete Resnick | Added to session: IETF-99: mtgvenue Wed-1520 |
2017-07-03
|
01 | Suresh Krishnan | New version available: draft-ietf-mtgvenue-meeting-policy-01.txt |
2017-07-03
|
01 | (System) | Forced post of submission |
2017-07-03
|
01 | (System) | Request for posting confirmation emailed to previous authors: Suresh Krishnan , mtgvenue-chairs@ietf.org |
2017-07-03
|
01 | Suresh Krishnan | Uploaded new revision |
2017-03-10
|
00 | Suresh Krishnan | New version available: draft-ietf-mtgvenue-meeting-policy-00.txt |
2017-03-10
|
00 | (System) | WG -00 approved |
2017-03-09
|
00 | Suresh Krishnan | Set submitter to "Suresh Krishnan ", replaces to (none) and sent approval email to group chairs: mtgvenue-chairs@ietf.org |
2017-03-09
|
00 | Suresh Krishnan | Uploaded new revision |