Subject: [Mtgvenue] AD evaluation of draft-ietf-mtgvenue-iaoc-venue-selection-process-10

From: Alissa Cooper <[email-masked]>
Date: Fri, 5 Jan 2018 14:38:14 -0500

I have reviewed this document in preparation for IETF last call. The document is in good shape but I have a few substantive comments that need to be resolved before proceeding to LC. I’ve also listed below some nits to be resolved in the next version of the document.

Substantive comments:

== Section 3.2.1 ==

"The Venue is assessed as favorable for obtaining a host and
      sponsors.  That is, the Meeting is in a location and at a price
      that it is possible and probable to find a host and sponsors."

What does "at a price" mean here? I get the sense that this implies that we change the sponsorship values according to the cost of the meeting, which we do not do as far as I know. But I'm just not sure what is being referred to here.

== Section 4 ==

In the same way that Section 5 has a disclaimer about how the process steps may change over time without updates to the document, I think it would be useful to have a note at the beginning of this section to state that the roles may change over time without updates to this document. Because they probably will. :-)

== Section 4.3 ==

"ISOC also provides accounting services, such as invoicing and monthly
   financial statements."

This is not correct today. AMS provides accounting services.

== Section 4.5 ==

"The IETF Administrative Support Activity (IASA) performs the meeting
   selection process under the oversight of the IAOC.  This includes
   identifying, qualifying and reporting on potential meeting sites, as
   well as supporting meeting Venue contract negotiation.  The IETF
   Secretariat is part of the IASA under the management of the IAD."

The way the term "IASA" is used in this section is not consistent with how it is used in BCP 101. It seems that what this text means by "IASA" is really "the Secretariat." But in BCP 101 the implication is that the Secretariat is not part of IASA, but is a contractor to it. E.g., Section 1 of BCP 101 says:

"The IASA is responsible for ensuring that the IETF's administrative
   needs are met, and met well.  The IETF does not expect the IASA to
   undertake the bulk of this work directly; rather, the IETF expects
   the IASA to contract this work from others and to manage these
   contractual relationships to achieve efficiency, transparency, and
   cost effectiveness."

If what this section is trying to do is to reflect reality, I suggest s/IASA/IETF Secretariat/ 

== Section 4.7 ==

"It also tracks the meetings sponsorship program"

The committee does not do this, or at least didn't do it in 2017.

== Section 5.1 ==

(1)
"A list of target cities per region is provided to the Secretariat"

This process is typically more of a collaborative process or secretariat-led, I thought. That is, at least some of the ideas for target cities come from the secretariat rather than being provided to the secretariat.

(2)
Again in this section there seems to be a bit of confusion between "IASA" and "the Secretariat." Like I don't know what it would mean for the meetings committee to make a recommendation to IASA at this initial step in the process. At this point the meetings committee feedback usually goes to the secretariat, I thought.

Nits:

== Abstract ==

"This document details the IETF's Meeting
   Venue Selection Process from the perspective of its goals, criteria
   and thought processes."

The "its" is ambiguous in the above sentence. Would be good to clarify.

== Section 1 ==

s/Internet Administrative Support Activity (IASA)/IETF Administrative Support Activity (IASA)/

== Section 2.1 ==

The reference to [MeetingNet] seems like it could use a few words of context.

== Section 3.1 ==

s/It MUST be possible to provision Internet Access to the Meeting Venue/It MUST be possible to provision Internet Access to the Facility and IETF Hotels/

(this was a bug Eliot pointed out to me during IETF LC)

== Section 9 ==

Ray Pelletier's contact information and affiliation should be updated.

Thanks,
Alissa

---

From: Ole Jacobsen <[email-masked]>
Date: Fri, 05 Jan 2018 12:14:16 -0800 (PST)

Let me take a stab at one item since I remember the early discussions
about this:

== Section 3.2.1 ==

What does "at a price" mean here? I get the sense that this implies 
that we change the sponsorship values according to the cost of the 
meeting, which we do not do as far as I know. But I'm just not sure 
what is being referred to here.

OLE: "At a price" means that it falls within the "normal" expected
overall meeting cost (which does vary by region).

Suppose for the sake of argument that the expenses [1] of an average 
meeting is $500k and we are evaluating a venue that will cost instead 
$1,000,000 AND is in such a location that we are unlikely to find a 
local host [2], local sponsors or attract global sponsors, then we 
would probably pass on that particular location.

[1] Meeting room rental, Food and Beverage, A/V services, Internet 
provision...etc.

[2] A local host may or may not be needed depending on location.
Compare Berlin to Beijing for example.

Ole

Ole J. Jacobsen
Editor and Publisher
The Internet Protocol Journal
Office: +1 415-550-9433
Cell:   +1 415-370-4628
Docomo: +81 090 3337-9311
E-mail: [email-masked]
Skype: organdemo

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Jan 2018 15:41:21 -0500

Hi,

> This is not correct today. AMS provides accounting services.

Well, strictly, of course, AMS is under contract to ISOC to provide
these services for the purposes of the IETF.  At least, that's what I
understand the upshot of the IAOC resolution in the minutes of
2017-06-29 to be.  It's true however that ISOC does not provide these
services directly.  I'm not sure how to make this bit sufficiently
short and still accurate.

> The committee does not do this, or at least didn't do it in 2017.

Should it?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 5 Jan 2018 15:49:46 -0500

> On Jan 5, 2018, at 3:14 PM, Ole Jacobsen <[email-masked]> wrote:
> 
> 
> 

Ok. I think it would be clearer to just leave these two criteria separate, since I’m guessing we would want a favorable assessment for sponsor acquisition regardless of the projected meeting expense. The document already includes a criterion about cost in 3.2.2. So perhaps “and at a price” could just be deleted above.

Thanks,
Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 5 Jan 2018 15:59:44 -0500

> On Jan 5, 2018, at 3:41 PM, Andrew Sullivan <[email-masked]> wrote:
> 
> Hi,
> 
> services directly.  

But this item is grouped together with other tasks that ISOC does perform directly, which is confusing, I think. 

> I'm not sure how to make this bit sufficiently

Delete it? I don’t think this section aims to be complete in any event.

Overall, Section 4 gives me some pause because some of it is repeating material from BCP 101, and some of it seems to be enshrining mechanics internal to IASA that should (IMO) be more flexible to change than what would be required to update this document. I am willing to defer to the WG consensus to keep the section, however, which is why I didn’t mention this in my initial review.

>> The committee does not do this, or at least didn't do it in 2017.

No, IMO.

Alissa

> 
> Best regards,
> 
> A
> 
> -- 
> Andrew Sullivan
> [email-masked]
> 
> _______________________________________________
> Mtgvenue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mtgvenue

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 5 Jan 2018 16:16:32 -0500

> Delete it? I don’t think this section aims to be complete in any event.

I'm for that.

> Overall, Section 4 gives me some pause because some of it is repeating material from BCP 101, and some of it seems to be enshrining mechanics internal to IASA that should (IMO) be more flexible to…

I can't dig it out right now, but I seem to recall making an earlier
remark to the same effect.  I think the WG pushed back, but maybe we
need to revisit that.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Fri, 5 Jan 2018 23:11:19 +0100

Hi Alissa,

For everyone's information, Section 3.2.2 contains the following statement:
>    o  The cost of guest rooms, meeting space, meeting food and beverage
>       is affordable, within the norms of business travel.

Both of the criteria are treated as "important" under Section 3.2. 
Therefore, I agree with you that the text in Section 3.2.1 is
unnecessary, and propose to remove it.

Eliot
ps: I'll comment separately on other text

---

From: Eliot Lear <[email-masked]>
Date: Fri, 5 Jan 2018 23:16:40 +0100

Hi,

> remark to the same effect.  I think the WG pushed back, but maybe we

I need the chairs' guidance before continuing.  I don't specifically
recall a decision about that text as a whole, one way or another.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 5 Jan 2018 23:25:56 +0100

Hi Alissa,

Last message for the evening ;-)  Just addressing nits:

> The "its" is ambiguous in the above sentence. Would be good to clarify.

Propose s/its/the community's/

> s/Internet Administrative Support Activity (IASA)/IETF Administrative Support Activity (IASA)/

Propose to accept.
> The reference to [MeetingNet] seems like it could use a few words of context.

I propose two changes:

 1. Make the reference informative.
 2. Add the following text: "a list of requirements that has been used
    in the past can be found at..."

The issue is that Jim has told me that the doc is out of date, and is
not being maintained.  Having some notion of what they're looking for
might be helpful, but I wouldn't want to overstate that doc's value at
this time.

> Ray Pelletier's contact information and affiliation should be updated.
Good point.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 7 Jan 2018 10:06:05 +1300

On 06/01/2018 08:38, Alissa Cooper wrote:
...> == Section 4.5 ==
> If what this section is trying to do is to reflect reality, I suggest s/IASA/IETF Secretariat/ 

The secretariat is employed by IASA (yes, I know the contract is signed by ISOC).
IMHO it's important to be clear that the *responsibility* is IASA's even if
it's the secretariat that does the work. (The same goes for the previous point
about accounting.) So something like this works for me:

 The IETF Administrative Support Activity (IASA) performs the meeting
 selection process under the oversight of the IAOC. The IETF Secretariat
 is part of the IASA under the management of the IAD, and it supports
 the meeting selection process. This includes identifying, qualifying
 and reporting on potential meeting sites, as well as supporting meeting
 Venue contract negotiation.

   Brian

---

From: Corinne Cath <[email-masked]>
Date: Mon, 8 Jan 2018 12:25:29 +0000

Hi,

I am still a bit confused about the following:

== section 3.1 ==

The Facility and IETF Hotels MUST provide wheelchair access to
accommodate the number of people who are anticipated to require it.

== section 3.2.2 ==

The Facility is accessible or reasonable accommodations can be made to
allow access by people with disabilities.

How does it make sense that wheel chair access is mandatory, but
taking into account other disabilities is not mandatory (even if they
are considered significant)?

Best,

Corinne

On Sat, Jan 6, 2018 at 9:06 PM, Brian E Carpenter <
[email-masked]> wrote:

> > The way the term "IASA" is used in this section is not consistent with
> how it is used in BCP 101. It seems that what this text means by "IASA" is
> really "the Secretariat." But in BCP 101 the implication is that the
> Secretariat is not part of IASA, but is a contractor to it. E.g., Section 1
> of BCP 101 says:
> >

-- 
Corinne Cath
Ph.D. Candidate, Oxford Internet Institute & Alan Turing Institute

Web: www.oii.ox.ac.uk/people/corinne-cath
Email: [email-masked] & [email-masked]
Twitter: @C_Cath

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 8 Jan 2018 11:36:08 -0500

> On Jan 5, 2018, at 5:25 PM, Eliot Lear <[email-masked]> wrote:
>> 
>> == Section 2.1 ==
>> 
> Make the reference informative.
> Add the following text: "a list of requirements that has been used in the past can be found at..."
> The issue is that Jim has told me that the doc is out of date, and is not being maintained.  Having some notion of what they're looking for might be helpful, but I wouldn't want to overstate that doc's value at this time.
> 
Even more reason to provide some context.

Thanks,
Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 8 Jan 2018 11:40:50 -0500

> On Jan 6, 2018, at 4:06 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I still think this is inconsistent with BCP 101. Why not be explicit? E.g.,

is under contract to support the meeting selection process. This includes identifying, qualifying

Alissa

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 9 Jan 2018 07:32:46 +1300

> Venue contract negotiation.

Yes, that's fine.

    Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 09 Jan 2018 16:40:08 +0100

Hi Alissa,

I take the opportunity with your email to ask about this document:

https://datatracker.ietf.org/doc/draft-palet-ietf-meeting-network-requirements/

This document was originally published in 2006, together with the earlier version of what this WG has been doing (https://tools.ietf.org/html/draft-palet-ietf-meeting-venue-selection-criteria-04) but there was not a “convenient” WG.

As a consequence of not having a specific WG, they died, so we wasted our time (not just me, but all the contributors that invested time in reading and providing inputs), and we somehow duplicated the work in the mtgvenue WG, and we have now a document delayed 12 years (that is even not recognizing the previous work, which is sad).

I guess we agree this is not optimal, right?

The WG chairs believe there is not expertise here … but I got no further inputs. The NOC team agree that is relevant and should be done.

So how we advance this document? Should be taken in the General Area ?

Please, enlight me, so it doesn't die again …

By the way, why we don’t have a global policy to recognize previous work?

Regards,
Jordi

-----Mensaje original-----
De: Mtgvenue <[email-masked]> en nombre de Alissa Cooper <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 5 de enero de 2018, 20:38
Para: <[email-masked]>
Asunto: [Mtgvenue] AD evaluation of draft-ietf-mtgvenue-iaoc-venue-selection-process-10

    Substantive comments:
    
    == Section 3.2.1 ==

    
    == Section 4 ==

    == Section 4.3 ==

    
    == Section 4.5 ==

    

    == Section 4.7 ==

    
    == Section 5.1 ==
    
    (1)

    (2)

    Nits:
    
    == Abstract ==

    
    == Section 1 ==

    == Section 2.1 ==

    == Section 3.1 ==

    
    == Section 9 ==

    Thanks,
    Alissa

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 9 Jan 2018 17:52:04 +0000

-----Original Message-----
From: Mtgvenue <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Friday, January 5, 2018 at 2:16 PM
To: Andrew Sullivan <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Mtgvenue] AD evaluation of draft-ietf-mtgvenue-iaoc-venue-selection-process-10

    Hi,

    
    Eliot

I do not recall past discussions about anything more than making minor clarifications to this section. It has been in the draft since the beginning:
 
https://tools.ietf.org/html/draft-baker-mtgvenue-iaoc-venue-selection-process-00

Looking through meeting minutes and email archives, I see no discussions or debates about removing it.
 
My opinion is that it is best to keep this section in the document. It is possible that it will need to be updated to reflect changes that occur as a result of IASA 2.0, but that is okay.
The changes hashed out by Alissa and Brian later in this same thread seem helpful at addressing the specific issue raised with this section.

Cheers,
Charles

---

From: Eliot Lear <[email-masked]>
Date: Tue, 9 Jan 2018 18:53:48 +0100

Barring any objections I will proceed along the lines below to resolve
Alissa's comments.

---

From: Pete Resnick <[email-masked]>
Date: Tue, 9 Jan 2018 14:56:46 -0500

This has been discussed before. The way I have thought about the 
distinction is that things in 3.1 are things for which IASA (or the 
secretariat for most practical purposes) would have to come to the 
community and get consensus to do something different before they 
contract. Things in 3.2 they can use their expertise and best judgement 
and make the contract, but even so they must notify the community that 
they are doing so.

So in the case of accessibility, the inability to have wheelchair access 
at the Facility or Hotels is a showstopper; there is no reasonable 
accommodation that can be made for wheelchair users that involves not 
being able to access a location with their wheelchair. If IASA thinks 
that such a facility is still acceptable, they have to make their case 
to the IETF community first and get consensus. For other disabilities, 
IASA is supposed to use their expertise (or that of others they enlist) 
to make sure that the facility is accessible or that reasonable 
accommodations can be made, and might judge that, while a particular 
normal accommodation for a particular disability is not available, a 
facility is nonetheless acceptable. They still must notify the community 
in this case, and bad things might happen if the community finds that 
they have made a poor judgement, but they are not expected clear a given 
lack of accommodation with the community every time.

There appeared to be rough consensus that this was a reasonable 
operational model.

pr

On 8 Jan 2018, at 7:25, Corinne Cath wrote:

>>> If what this section is trying to do is to reflect reality, I 
>>> suggest
>> s/IASA/IETF Secretariat/
>>
>> The secretariat is employed by IASA (yes, I know the contract is 
>> signed by
>> ISOC).
>> it's the secretariat that does the work. (The same goes for the 
>> previous
>> point

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Corinne Cath <[email-masked]>
Date: Wed, 10 Jan 2018 06:53:32 +0000

Thank you for the clarification.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Jan 2018 09:10:15 +0100

Hi Alissa,

Following up on Charles' note, please now see the disposition of your
comments regarding Sections 4 and 5 (the other sections have been
previously addressed).  I've attempted to economize on changes.

How about:

>         This section
>         provides an informational overview of the current
>         meeting selection related roles of these and other parties that
>         participate in the process at the time of this writing. 

How about:

>           ISOC sees to the provisioning and oversight of accounting
>           services, such as invoicing and monthly financial
>           statements.

> If what this section is trying to do is to reflect reality, I suggest s/IASA/IETF Secretariat/ 

I took your text from downthread.

> The committee does not do this, or at least didn't do it in 2017.

Removed.

> Again in this section there seems to be a bit of confusion between "IASA" and "the Secretariat." Like I don't know what it would mean for the meetings committee to make a recommendation to IASA at…

To address both of these points I propose a modification to the chapeau
as follows:

>          Four years out,the IASA identifies cities that might be
> candidates
>           for meetings, making use of the Secretariat as they deem
>           appropriate.  For example:

And remember, point (1) you raised above is against an example.  This
document needn't tell the IASA how to develop that initial list, nor who
to take input from at that stage.

Alissa, if you are comfortable with these changes, I will post a new
version.

Regards,

Eliot

---

From: Pete Resnick <[email-masked]>
Date: Wed, 10 Jan 2018 22:18:04 -0500

A quick thank you to Charles for covering my shepherding duties while I 
was away for a family matter. All looks good to me.

pr

On 9 Jan 2018, at 12:52, Charles Eckel (eckelcu) wrote:

> Subject: Re: [Mtgvenue] AD evaluation of 
> draft-ietf-mtgvenue-iaoc-venue-selection-process-10
>
>     Hi,
>
>
>     >> Overall, Section 4 gives me some pause because some of it is 
> repeating material from BCP 101, and some of it seems to be enshrining 
> mechanics internal to IASA that should (IMO) be more flexible to 
> change than what would be required to update this document. I am 
> willing to defer to the WG consensus to keep the section, however, 
> which is why I didn’t mention this in my initial review.
>     >>
> I do not recall past discussions about anything more than making minor 
> clarifications to this section. It has been in the draft since the 
> beginning:
>
> Looking through meeting minutes and email archives, I see no 
> discussions or debates about removing it.
>
> My opinion is that it is best to keep this section in the document. It 
> is possible that it will need to be updated to reflect changes that 
> occur as a result of IASA 2.0, but that is okay.
> The changes hashed out by Alissa and Brian later in this same thread 
> seem helpful at addressing the specific issue raised with this 
> section.
>
> Cheers,
> Charles

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 11 Jan 2018 10:06:30 -0500

Hi Eliot,

> On Jan 10, 2018, at 3:10 AM, Eliot Lear <[email-masked]> wrote:
> 
> Hi Alissa,
> 

I would prefer that this be more explicit about not needing document updates, as in Section 5.

Otherwise the rest of the changes look good to me.

Thanks,
Alissa

---

From: Eliot Lear <[email-masked]>
Date: Thu, 11 Jan 2018 19:58:02 +0100

Hi again,

Ok, how about this:

> This section describes the roles involved in meeting venue selection. It is anticipated that those roles will evolve.  The IASA is responsible for keeping the community informed in this regard, and MAY do so without updating this memo. 

Again, aiming for succinctness.

I do think it would be good for the leadership to contemplate what these
words mean, and HOW they will keep the community informed.

Eliot

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 11 Jan 2018 14:16:11 -0500

> On Jan 11, 2018, at 1:58 PM, Eliot Lear <[email-masked]> wrote:
> 
> Hi again,
> 
> 

WFM

Thanks,
Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 12 Jan 2018 09:16:09 -0500

Hi Jordi,

Thanks for raising these questions.

Regarding the detailed meeting network requirements, this strikes me as the sort of documentation that should be maintained by the NOC and updated when they have the time and impetus to do so, rather than having it memorialized in an RFC. The high-level requirements from the community seem to me to be adequately captured in Sec 2.1 and 3.1 of draft-ietf-mtgvenue-iaoc-venue-selection-process but I don’t think the detailed implementation of those requirements needs to be subject to community consensus.

Regarding a policy for recognizing previous work, indeed we do not have one, although we have guidance about normative referencing and about authorship. Since the barrier to produce an internet draft is very low it seems to me that we’ve struck the right balance here, but of course if the community wants a more strict policy there is nothing standing in the way of someone proposing one.

Alissa

> On Jan 9, 2018, at 10:40 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> Hi Alissa,
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 15 Jan 2018 12:38:44 +0100

Hi Alissa,

I guess one of the issues, that I already mention before in this list, is that very few (if any) of the WG participants has participant in an “on-site venue survey”.

I’m not really sure if sec 2.1 and 3.1 are enough. I’ve a feeling that if we restrict the criteria to those points (regarding technical aspects), many venues will fail to meet the technical requirements.

In fact, in 2.1 there is an informative reference to MeetingNet. If MeetingNet is not an RFC, is not mandatory … so somehow a contradiction.

Furthermore a few months ago, while reading MeetingNet, I discovered that it is based in my old document: https://www.ietf.org/archive/id/draft-palet-ietf-meeting-network-requirements-00, even with many sentences “copy&paste”, etc.

As you can also read in my “ack” section, this was done with the inputs of the NOC, and in fact, I recall it was the NOC asking for this document, and we had a couple of face-to-face meetings in 2006, to work on the document, and then discussion in the list.

If I recall correctly, it was out of a conversation with Jim Martin (NOC) and Laura Nugent in April 2017, that told me “yes” you should revive that document and update it, it is key for the survey and to inform the venues/hosts in advance of our “on-site survey”.

Further to this, in IETF 99 (unfortunately not reflected in the minutes, but I just heard the audio and is there), Jim Martin agreed that the web site is outdated and the RFC is needed.

My document tries to capture what are the basic needs and keeps open data that will evolve over the time, for example, such as bandwidth needs or WiFi technologies, etc., and Jim Martin said that in the mike (base line document).

At the end, in IETF everything is done with RFCs, otherwise, why we have draft-ietf-mtgvenue-iaoc-venue-selection-process?

There is not difference on that in between both documents, and if you heard the audio recording, I think it is clear that there is a support on the WG on the document, but there is not a clear view of how to move on, even if it was confirmed that this is within the scope of the WG charter …

Regarding the policy, someone reminded me about this document (and this I think, belongs to the general IETF mail exploder, not the mtgvenue WG, so feel free to move it there …):

https://tools.ietf.org/html/draft-carpenter-whats-an-author

I think we must “resurrect” it and while I agree with the document, I disagree with a “minor” comment on it:

“This draft has been written to aid discussion and is not intended to
   be published as an RFC”

I think it must become an RFC … At the end, everything in IETF is made by RFCs (not just protocols but also policies)

Regards,
Jordi

-----Mensaje original-----
De: Mtgvenue <[email-masked]> en nombre de Alissa Cooper <[email-masked]>
Fecha: viernes, 12 de enero de 2018, 15:16
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: <[email-masked]>
Asunto: Re: [Mtgvenue] AD evaluation of draft-ietf-mtgvenue-iaoc-venue-selection-process-10

    Hi Jordi,

    
    
    Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 19 Jan 2018 11:30:43 -0500

Hi Jordi,

To be clear, it’s up to the WG to decide what to work on (within the bounds of the charter), and it’s up to the IETF community to decide what documents have consensus. My personal view is that the detailed technical requirements of the meeting network are better articulated by the NOC with community review, and are likely to change more frequently than the RFC update cycle would allow. (Note that we’re coming up on the two-year mark since the work on draft-ietf-mtgvenue-iaoc-venue-selection-process began). But my personal view isn’t terribly relevant here. If there is consensus in the WG, as judged by the chairs, to adopt an additional work item, I will happily occupy my spot in the rough.

A couple of comments below.

> On Jan 15, 2018, at 6:38 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> Hi Alissa,
> 

Documents do not need to be RFCs to be normatively referenced. We normatively reference documents from other SDOs all the time that are not RFCs.

> At the end, in IETF everything is done with RFCs, otherwise, why we have draft-ietf-mtgvenue-iaoc-venue-selection-process?

This is not true for administrative matters. The detailed list of criteria used by the meeting planning staff to vet venues is not in an RFC. There are numerous IAOC policies that are not written in RFCs (see https://iaoc.ietf.org/policy-procedures.html <https://iaoc.ietf.org/policy-procedures.html>). The whole point of having IASA is so that the IETF consensus process need not be run for every administrative detail that needs to be decided.

Cheers,
Alissa

---

From: Pete Resnick <[email-masked]>
Date: Wed, 24 Jan 2018 12:26:12 -0600

On 19 Jan 2018, at 10:30, Alissa Cooper wrote:

> To be clear, it’s up to the WG to decide what to work on (within the 
> bounds of the charter), and it’s up to the IETF community to decide 
> what documents have consensus. My personal view is that the detailed 
> technical requirements of the meeting network are better articulated 
> by the NOC with community review, and are likely to change more 
> frequently than the RFC update cycle would allow. (Note that we’re 
> coming up on the two-year mark since the work 
> on draft-ietf-mtgvenue-iaoc-venue-selection-process began). But my 
> personal view isn’t terribly relevant here. If there is consensus in 
> the WG, as judged by the chairs, to adopt an additional work item, I 
> will happily occupy my spot in the rough.

This looks to be in part a bit of a "chair-fail". From the minutes of 
our last f2f:

- not in charter. new charter?
	- if this becomes a requirement then it goes too far

- Should the group ask a for a charter change?

- 'Does this need the efforts of a whole working group; or the NOC

	- Show of hands in people interested - very few

- AD not a recharter - just an edit of a milestone

- Chair: will post summary of discussion to list, ask who wants to work 
on it and whether they are willing to work with Jordi to do it.

My read of the discussion was that there was little interest in the room 
for the WG to take this up as a work item, but that if a group of people 
(presumably including Jordi) wanted to work this into a document and 
propose it as a WG document, that would be OK. Where I failed was that 
last point: To post to the list and see if anyone else was willing to 
work with Jordi on this document. I think I presumed that the posting of 
the minutes would be sufficient, but it really isn't.

So, Jordi, is this a formal enough request to ask for interest in 
working on the document, or should I post a separate message?

pr