Meeting Venue (mtgvenue) Working Group Minutes

=============================================================

IETF 99, Prague

1520 - 1650 Wednesday, July 19, 2017. Room: Karlin I/II

Chairs: Charles Eckel eckelcu@cisco.com, Pete Resnick presnick@qti.qualcomm.com

Notes thanks to Avri Doria. Thanks also to Barry Leiba for being Jabber scribe.

1520 Meeting Start

mtgvenue status update (Chairs, 10)

IETF Plenary Meeting Venue Selection                                  (Eliot, 50)

draft-ietf-mtgvenue-iaoc-venue-selection-process-07

https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-iaoc-venue-selection-process/

Issue List: https://github.com/elear/mtgvenue/issues

issue 6 closed

issue 15 was a misunderstanding closed with no change

issue 18 hold that one for WGLC

Issue 22 no change

Issue 23 no change (i.e. not to add text for issue)

No one spoke

Issue to be closed in GitHub

2 open issues:

issue 20: IAOC references should be IASA. Text prepared for replacement. no objections on list.

took all Brian's recommended changes

except: reference to mtg Committees as IASA subcommittee inaccurate, change not made

no one had concerns

new issue: travel barriers issue

(including visa requirements because of SF issue)

Is text accurate.

Because of double negative, text matches what happened, nonetheless text needs changing

Text confuses people

Question of attaching a numeric value.

Point:  meeting was moved because of insecurity, not because people could not travel.

Question of overwhelming majority does this take in uncertainty?

Bob Hinden: Moved to reduce risk of a successful meeting. no one knows what the policy will be at the time, yet it seemed possible.  no one knew, and the cost of moving early factored in.

could the current words have justified the change?

Driven by action in the real world.

Leslie Daigle: The work for evaluating at a point in time. this set of criteria does not speak to the question of when it is a good idea to change.

wording ok for meeting selections but not for venue changes.

Eliot: 2 problems with existing 

- double negatives confuse people

- impede should be impeded or discouraged

Re Late changes:

this text appears fine

Text is blurry enough to allow the decision that was made and may allow other changes as well

how does one measure overwhelming and significant?

Currently late changes discussed when a meeting must be moved, not one when it may be.

Questions: does the ability to bring computer count as an additional item.   Seen as being included in travel barrier, inability to travel. 

construe travel barriers broadly

Perhaps add some consideration on travel barriers

All criteria feed into ability to hold successful meeting

Look at adding another criterion

Define travel barriers - things that persuade people to not want to come

Travel barriers can change over time.

will open up GitHub issue or two.

Eliot will update, the chairs will do a WGLC

Ask Laura AMS to do sanity scrub of document with/after WGLC

hoping to progress to publication requests in next 4-6 weeks

High level guidance for the meeting policy of the IETF          (Suresh, 10)

draft-ietf-mtgvenue-meeting-policy-01

https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-meeting-policy/

Converging

some small items

believes document is ready for WGLC

no objections to last call

current rev is the one going

IETF Meeting Network and Other Technical Requirements (Jordi, 10)

draft-palet-ietf-meeting-network-requirements-01

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

Believe existing guidelines (at https://iaoc.ietf.org/ietf-network-requirements.html) were based on -00 version of this draft

Not specific, but close enough for technical review

Request to become WG item

Is this doc useful at survey time or later?

Bottom line - this is important for us to have written

Q: how frequently do requirements change

A: base requirements stable but evolve - substantive change every 3 years. What may change more often are technical specific details, such as types of wiring, how it is setup, etc.

Useful to go through IETF process on baseline.

Should be easy to access - more than just as one RFC

Can this be used as RFP, making it a RFC may be too heavy weight

It should not nail down specific tech - it changes

should not be included in contract as that needs tailoring.

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

no other business.

1650    End