Skip to main content

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