IETF Plenary Meeting Venue Selection Process
draft-ietf-mtgvenue-iaoc-venue-selection-process-16

[Ballot comment]
Thank you for this document.

I am wondering what is the relationship between the section "2.1.  Core Values" and Section 3? I don't think all of core values are expressed as requirements. Is section 2 (and 2.1) Informative?

[Ballot comment]
Thanks for this. Most of my comments are already covered, but here's a few:

Substantive:

§3.2.3 and §3.3: The first section says that the cost of "open and unfiltered internet" in public spaces and guest rooms in "typically" included in the room price. But the latter simply says they are included.  Is that the intenti? It seems odd for the overflow hotels to be held to a higher standard than the meeting hotel.

Editorial and Nits:

§1, 2nd paragraph: " the IASA to apply their " - Plural disagreement. (It looks like a mix of the US English tendency to treat organizations as singular entities and the British English tendency to treat them as plural collectives ).

§7: The last sentence seems disconnected from the rest of the paragraph; I suggest a separate paragraph.

[Ballot comment]

(1) The term "participant" is used in several places, sometimes with different modifiers; for example: active, IETF and regular.  Some of the phrases seem to want to differentiate between them, but that distinction is not clear (for example): "in order to spread the difficulty and cost of travel among active participants, balancing travel time and expense across the regions in which IETF participants are based."  What is the difference between active and IETF participants?

Note that "attendee" is also used, in my interpretation, to also mean "participant".  Is that the intent, or is there a difference? 

Clarifying and being consistent would help.  I don't think that a terminology section is needed -- I just want to probe whether the terms were differentiated on purpose, and, if so, to understand what that differentiation may be.


(2) From §2.2 (Venue Selection Non-Objectives)

Maximal attendance:
    While the IETF strives to be as inclusive as possible both online
    and in person, maximal meeting attendance in and of itself is not
    a goal.  It would defeat a key goal of meeting if active
    contributors with differing points of view did not have the
    opportunity to resolve their disagreements, no matter how full the
    rooms.

Should maximal attendance by "active contributors" be listed as an objective?  Measuring what that means will not be easy...but that seems to be corollary: the text above sounds like it says "it doesn't matter how many people show up, as long as active contributors are there".

BTW, following up on my first point, what's the relationship between "contributor" and "participant"?  Is there a difference between an "active contributor" and an "active participant"?


(3) §3.2 (Important Criteria) says that "when a particular requirement in this section cannot be met...it may be appropriate for the IASA to assist those who, as a result, have been inconvenienced in some way."

What does the IASA providing assistance mean?  Looking at the criteria, would (for example) a high cost be considered an inconvenience?  Knowing that the intent is to spread the burden "over the course of multiple years", who determines that inconvenience?  How could the IASA assist?  Maybe there's some other purpose for that sentence for which I'm missing context.


(4) §3.2.5 (Food and Beverage)

  It is said that an army travels on its stomach.  So too does the
  IETF.  The following criteria relate to food and beverage.

Personal opinion: unfortunate quote and comparison.

  ...
  o  A range of attendee's health-related and religion-related dietary
      requirements can be satisfied with robust and flexible onsite
      service or through access to an adequate grocery.

  o  The Facility environs include grocery shopping that will
      accommodate a wide range of dietary requirements, within a
      reasonable walking distance, or conveniently accessible by a short
      taxi, bus, or subway ride, from the Facility and IETF Hotels.

These last two bullets sound almost the same: the difference seems to be in calling for "robust and flexible onsite service" in the first one.  Maybe they can be merged.


(5) I think that the reference to rfc3935 should be a Normative reference given that it defines why we meet (§2.1).


(6) Is the intent for this document and draft-ietf-mtgvenue-meeting-policy to be part of the same BCP?  I would think so, but I didn't see that mentioned an the writeups.

[Ballot comment]

(1) The term "participant" is used in several places, sometimes with different modifiers; for example: active, IETF and regular.  Some of the phrases seem to want to differentiate between them, but that distinction is not clear (for example): "in order to spread the difficulty and cost of travel among active participants, balancing travel time and expense across the regions in which IETF participants are based."  What is the difference between active and IETF participants?

Note that "attendee" is also used, in my interpretation, to also mean "participant".  Is that the intent, or is there a difference? 

Clarifying and being consistent would help.  I don't think that a terminology section is needed -- I just want to probe whether the terms were differentiated on purpose, and, if so, to understand what that differentiation may be.


(2) From §2.2 (Venue Selection Non-Objectives)

Maximal attendance:
    While the IETF strives to be as inclusive as possible both online
      and in person, maximal meeting attendance in and of itself is not
    a goal.  It would defeat a key goal of meeting if active
    contributors with differing points of view did not have the
    opportunity to resolve their disagreements, no matter how full the
    rooms.

Should maximal attendance by "active contributors" be listed as an objective?  Measuring what that means will not be easy...but that seems to be corollary: the text above sounds like it says "it doesn't matter how many people show up, as long as active contributors are there".

BTW, following up on my first point, what's the relationship between "contributor" and "participant"?  Is there a difference between an "active contributor" and an "active participant"?


(3) §3.2 (Important Criteria) says that "when a particular requirement in this section cannot be met...it may be appropriate for the IASA to assist those who, as a result, have been inconvenienced in some way."

What does the IASA providing assistance mean?  Looking at the criteria, would (for example) a high cost be considered an inconvenience?  Knowing that the intent is to spread the burden "over the course of multiple years", who determines that inconvenience?  How could the IASA assist?  Maybe there's some other purpose for that sentence for which I'm missing context.


(4) §3.2.5 (Food and Beverage)

  It is said that an army travels on its stomach.  So too does the
  IETF.  The following criteria relate to food and beverage.

Personal opinion: unfortunate quote and comparison.

  ...
  o  A range of attendee's health-related and religion-related dietary
      requirements can be satisfied with robust and flexible onsite
      service or through access to an adequate grocery.

  o  The Facility environs include grocery shopping that will
      accommodate a wide range of dietary requirements, within a
      reasonable walking distance, or conveniently accessible by a short
      taxi, bus, or subway ride, from the Facility and IETF Hotels.

These last two bullets sound almost the same: the difference seems to be in calling for "robust and flexible onsite service" in the first one.  Maybe they can be merged.


(5) I think that the reference to rfc3935 should be a Normative reference given that it defines why we meet (§2.1).


(6) Is the intent for this document and draft-ietf-mtgvenue-meeting-policy to be part of the same BCP?  I would think so, but I didn't see that mentioned an the writeups.

[Ballot comment]
(1) The term "participant" is used in several places, sometimes with different modifiers; for example: active, IETF and regular.  Some of the phrases seem to want to differentiate between them, but that distinction is not clear (for example): "in order to spread the difficulty and cost of travel among active participants, balancing travel time and expense across the regions in which IETF participants are based."  What is the difference between active and IETF participants?

Note that "attendee" is also used, in my interpretation, to also mean "participant".  Is that the intent, or is there a difference? 

Clarifying and being consistent would help.  I don't think that a terminology section is needed -- I just want to probe whether the terms were differentiated on purpose, and, if so, to understand what that differentiation may be.


(2) From §2.2 (Venue Selection Non-Objectives)

    Maximal attendance:
        While the IETF strives to be as inclusive as possible both online
          and in person, maximal meeting attendance in and of itself is not
        a goal.  It would defeat a key goal of meeting if active
        contributors with differing points of view did not have the
        opportunity to resolve their disagreements, no matter how full the
        rooms.

Should maximal attendance by "active contributors" be listed as an objective?  Measuring what that means will not be easy...but that seems to be corollary: the text above sounds like it says "it doesn't matter how many people show up, as long as active contributors are there".

BTW, following up on my first point, what's the relationship between "contributor" and "participant"?  Is there a difference between an "active contributor" and an "active participant"?


(3) §3.2 (Important Criteria) says that "when a particular requirement in this section cannot be met...it may be appropriate for the IASA to assist those who, as a result, have been inconvenienced in some way."

What does the IASA providing assistance mean?  Looking at the criteria, would (for example) a high cost be considered an inconvenience?  Knowing that the intent is to spread the burden "over the course of multiple years", who determines that inconvenience?  How could the IASA assist?  Maybe there's some other purpose for that sentence for which I'm missing context.


(4) §3.2.5 (Food and Beverage)

  It is said that an army travels on its stomach.  So too does the
  IETF.  The following criteria relate to food and beverage.

Personal opinion: unfortunate quote and comparison.

  ...
  o  A range of attendee's health-related and religion-related dietary
      requirements can be satisfied with robust and flexible onsite
      service or through access to an adequate grocery.

  o  The Facility environs include grocery shopping that will
      accommodate a wide range of dietary requirements, within a
      reasonable walking distance, or conveniently accessible by a short
      taxi, bus, or subway ride, from the Facility and IETF Hotels.

These last two bullets sound almost the same: the difference seems to be in calling for "robust and flexible onsite service" in the first one.  Maybe they can be merged.


(5) I think that the reference to rfc3935 should be a Normative reference given that it defines why we meet (§2.1).


(6) Is the intent for this document and draft-ietf-mtgvenue-meeting-policy to be part of the same BCP?  I would think so, but I didn't see that mentioned an the writeups.

[Ballot comment]
I agree with Adam about removing "around".

All my comments after the first are purely editorial.

Section 2.1

  Inclusiveness:
      We would like to facilitate the onsite or remote participation of
      anyone who wants to be involved.

Snarkily, "trolls included?"  That is to say, (productive) participation is
not truly unlimited, in that we have mechanisms to restrict abusive and
harmful behavior.  But I do not have any suggestions for better text -- it's
unclear that "productive participation" is a good change to make, for example.

On "Inclusiveness", does the point (2) about laws want to have the
"or failing that" clause present in point (1)?

Section 3.3

  o  It is desirable for Overflow Hotels provide reasonable, reliable,
      unfiltered Internet service for the public areas and guest rooms;
      this service is included in the cost of the room.

There seems to be a jarring mismatch of statement of
desire and statement of fact between the two clauses of this
sentence.

Section 4

  Therefore, the IASA SHALL publicly document and keep
  current both a list of roles and responsibilities relating to IETF
  meetings, as well as the selection processes they use in order to
  fulfill the requirements of the community.

Are the first two (roles and responsibilities)
qualitatively different from the process used, in terms of
visibility requirements?  It may make sense to just list all three
together, without an "as well as".

Section 7

  The requirements in this memo are intended to provide for some
  limited protections that attendees can apply.

This reads oddly to me -- we provide for limited
privacy protections that attendees can choose to apply but are not
universally applied without explicit action?  What are they?
The text would read more naturally to me as "to provide for some
limited protections that apply to attendees", though that does of
course have a different meaning.

[Ballot comment]
Thanks to everyone who worked on this document.

I agree with Spencer's concern that this document is tightly tied to the current
IASA structure, which is under revision at the moment. I think it would be an
improvement to describe, in more general terms, the entity responsible for
selecting venues, with a single note early in the document that the entity
currently in that role is the IASA.

I also have a handful of editorial nits that the authors may wish to address.

---------------------------------------------------------------------------

Please expand "IASA" in the Abstract, assuming it remains in the Abstract.

---------------------------------------------------------------------------

Abstract:

>  It directs the IASA to make available additional process
>  documents around that describe the current meeting selection process.

I'm having a really hard time parsing this sentence. It seems to make sense if
you remove "around".

---------------------------------------------------------------------------

§2.1:

>    criteria below, one mandatory and others important, to allow for
>    the case where local laws may require filtering in some
>    circumstances.[MeetingNet]

It's not clear what "[MeetingNet]" is doing here. Perhaps some explanatory text
about what the reader can expect to find at that reference would be useful.

In any case, consider putting a space before the opening bracket.

[Ballot comment]
I like where the exchange on Martin's comment has ended up.  Thanks for that.

Everything following my first comment is editorial (at most).

Given that we have an active effort to produce IASA 2.0, is

  As always, the community is
  encouraged to provide direct feedback to the Nominations Committee
  (NOMCOM), Internet Engineering Steering Group (IESG), and IAB
  regarding the discharge of the IASA's performance.

going to age well?

I think

  Focus:
      We meet to have focused technical discussions.  These are not
      limited to scheduled breakout sessions, although of course those
      are important.  They also happen over meals or drinks -- including
      a specific type of non-session that we call a "Bar BOF" [RFC6771]
      - or in side meetings.

should have the reference at the end of the sentence, as in

Focus:
      We meet to have focused technical discussions.  These are not
      limited to scheduled breakout sessions, although of course those
      are important.  They also happen over meals or drinks -- including
      a specific type of non-session that we call a "Bar BOF" or side
      meeting [RFC6771].

[RFC6771] uses both terms interchangeably.

Not asking for a text change on this, but I wonder when the last meeting was

  o  The Facility's support technologies and services -- network,
      audio-video, etc. -- are sufficient for the anticipated activities
      at the meeting, or the Facility is willing to add such
      infrastructure or these support technologies and services might be
      provided by a third party, all at no -- or at an acceptable --
      cost to the IETF.

where the Facility provided these things at no cost to the IETF ...

I wonder if "something of a preference for" is easy for ESL folk.

  o  We have something of a preference for an IETF meeting to be under
      "One Roof".  That is, qualified meeting space and guest rooms are
      available in the same facility.

I note that the following bullets are all "it is desirable".

This is a side question for the AD, but I note that we've started including long-lived URLs in RFCs, and I wonder if a URL could be selected to include in this text:

4.  Documentation Requirements

  The IETF Community works best when it is well informed.  This memo
  does not specify processes nor who has responsibility for fulfilling
  our requirements for meetings.  Nevertheless, both of these aspects
  are important.  Therefore, the IASA SHALL publicly document and keep
  current both a list of roles and responsibilities relating to IETF
  meetings, as well as the selection processes they use in order to
  fulfill the requirements of the community.

ISTM that people would click on it more often if they didn't have to search for it ...

[Ballot comment]
Hello,

please forgive me for raising the following point, especially because I haven't participated in nor followed the discussions on that draft, but I would much prefer if "ethnicity" was used instead of "race".

Martin

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-mtgvenue-iaoc-venue-selection-process-13, 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

The following Last Call announcement was sent out (ends 2018-04-19):

From: The IESG
To: IETF-Announce
CC: mtgvenue@ietf.org, presnick@qti.qualcomm.com, draft-ietf-mtgvenue-iaoc-venue-selection-process@ietf.org, alissa@cooperw.in, mtgvenue-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IETF Plenary Meeting Venue Selection Process) to Best Current Practice


The IESG has received a request from the Meeting Venue WG (mtgvenue) to
consider the following document: - 'IETF Plenary Meeting Venue Selection
Process'
  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


  The IASA has responsibility for arranging IETF plenary meeting Venue
  selection and operation.  This memo specifies IETF community
  requirements for meeting venues, including hotels and meeting room
  space.  It directs the IASA to make available additional process
  documents around that describe the current meeting selection process.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-iaoc-venue-selection-process/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-iaoc-venue-selection-process/ballot/


No IPR declarations have been submitted directly on this I-D.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-mtgvenue-iaoc-venue-selection-process-11, 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

The following Last Call announcement was sent out (ends 2018-01-31):

From: The IESG
To: IETF-Announce
CC: mtgvenue@ietf.org, presnick@qti.qualcomm.com, draft-ietf-mtgvenue-iaoc-venue-selection-process@ietf.org, alissa@cooperw.in, mtgvenue-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IETF Plenary Meeting Venue Selection Process) to Best Current Practice


The IESG has received a request from the Meeting Venue WG (mtgvenue) to
consider the following document: - 'IETF Plenary Meeting Venue Selection
Process'
  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-01-31. 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


  The IASA has responsibility for arranging IETF plenary meeting Venue
  selection and operation.  This document details the IETF's Meeting
  Venue Selection Process from the perspective of the community's
  goals, criteria and thought processes.  It points to additional
  process documents on the IAOC Web Site that go into further detail
  and are subject to change with experience.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-iaoc-venue-selection-process/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-iaoc-venue-selection-process/ballot/


No IPR declarations have been submitted directly on this I-D.

[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 the
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 purpose of this document is to guide the IASA in their selection
  of regions, cities, facilities, and hotels when arranging IETF
  plenary meeting venue selection.  The IASA applies this guidance at
  different points in the process in an attempt to faithfully meet the
  requirements of the IETF community. We specify a set of general
  criteria for venue selection and several requirements for
  transparency and community consultation.

Working Group Summary

  Two things of note: 1) There was a good deal of disagreement about
  the general format of the document and its purpose at the time the
  current chairs were appointed. In particular, it was difficult to
  figure out what different people meant by "mandatory" and
  "important". In the end, rough consensus seemed to be that
  "mandatory" items were those that could not be disregarded by IASA
  without coming back to the community and get a new consensus on the
  failure to meet the criteria, while "important" items were those that
  IASA could exercise it's judgment, and simply report to the community
  if any were not met. In the end, only three items were considered
  "mandatory". 2) Several people made direct and significant textual
  contributions to the document. They are now noted in the
  "Contributors" section, as per current procedure. However, this is
  obviously not ideal, since those people are not included in the
  citation index or on the cover page of the document. On the other
  hand, having all of those people on the front page is unwieldy, and
  having them all responsible to reply to the AUTH48 is undesirable.
  This is something that the IESG should work out.

Document Quality

  The secretariat (and in particular, the meeting arranger) did a
  solicited review of the document, and all comments were addressed in
  the document. The secretariat also did a review of how previous
  meetings would or would not have conformed to the criteria in the
  document, and the WG found the results to be satisfactory.

Personnel

  Pete Resnick  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 thoroughly 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. In particular, see Document Quality above.

(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.

See Document Quality above. 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. A couple of nits to be addressed in the post-Last Call
or post-IESG review version of the document:

  In 2.1: The "Why we meet" and "Where we meet" should end with ":",
  not "?". To be even more consistent with the rest of the list,
  perhaps change them to "Purpose" and "Location".

  In 3.1: In the third bullet, s/Meeting Venue/Facility and IETF Hotels

  In 3.2: s/preferable than another/preferable to another

  In 3.2.4: The 5th bullet (disabilities) should mirror the 3rd bullet
  in 3.2.2.

(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.

Since this is a non-technical document, no IPR should be applicable.
If the AD truly wants the question asked of anyone beyond the editor,
the shepherd will dutifully comply.

(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, notwithstanding
the rough consensus noted in  "Working Group Summary" above.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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.

Nits tool only made two comments (see 14 below); no real nits found by
the tool or the shepherd.

(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?

Check.

(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?

There is a normative reference to the IAOC's "Network Requirements"
web page. The shepherd believes that is appropriate.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

None.

(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, but the IESG might want to consider whether this is
included in BCP 101.

(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.

Request for posting confirmation emailed to previous authors: Ole Jacobsen , Laura Nugent , Eliot Lear , Ray Pelletier , mtgvenue-chairs@ietf.org, Jim Martin , Lou Berger , Dave Crocker , Fred Baker

Request for posting confirmation emailed to previous authors: Ole Jacobsen , Laura Nugent , Eliot Lear , Ray Pelletier , mtgvenue-chairs@ietf.org, Jim Martin , Lou Berger , Dave Crocker , Fred Baker

Request for posting confirmation emailed to previous authors: Ole Jacobsen , Laura Nugent , Eliot Lear , Ray Pelletier , mtgvenue-chairs@ietf.org, Jim Martin , Lou Berger , Dave Crocker , Fred Baker

Request for posting confirmation emailed to previous authors: Ole Jacobsen , Laura Nugent , Ray Pelletier , mtgvenue-chairs@ietf.org, Jim Martin , Lou Berger , Dave Crocker , Fred Baker

Request for posting confirmation emailed to previous authors: "Jim Martin" , "Lou Berger" , "Fred Baker" , mtgvenue-chairs@ietf.org, "Laura Nugent" , "Ole Jacobsen" , "Dave Crocker" , "Ray Pelletier"

Request for posting confirmation emailed to previous authors: "Jim Martin" , "Lou Berger" , "Fred Baker" , mtgvenue-chairs@ietf.org, "Laura Nugent" , "Ole Jacobsen" , "Dave Crocker" , "Ray Pelletier"

Request for posting confirmation emailed to previous authors: "Jim Martin" , "Lou Berger" , mtgvenue-chairs@ietf.org, "Laura Nugent" , "Fred Baker" , "Ole Jacobsen" , "Dave Crocker" , "Ray Pelletier"