Re: [Mtgvenue] issue #3: Too many mandatory

On Wed, Apr 5, 2017 at 2:02 PM, Dave Crocker <dhc@dcrocker.net> wrote:

>
>
>>
>> The draft as currently constructed covers those as venue selection steps,
>> at least as I read Section 5.  If each of those steps needs a new document,
>> we may be here a while.
>>
>
>
> "move or cancel" is language that only has meaning /after/ selection. It
> is therefore formally out of scope.
>
>
You should give Eliot a PR removing section 5.4 and 5.5,then; I don't
agree, but that would make this concrete.  As I said, I don't care whether
these are in this document or not, only that they are clear.

> And while I'm at it...
>
> The effort to move to a yet-more complicated ranking system -- adding
> Exception into the mix -- is mostly continuing to ignore the human factors
> points I keep raising:  Both in creating such a ranking list and in
> applying them, free-form human performance mostly sucks.
>
>
I think our disagreement is that I don't see these as a ranking system.
They indicate which branch of actions to follow.  For that, you want to
have as many indicators as branches you intend to support.  I think there
are four branches and that it is unhelpful to have indicators that might
match one or more of the underlying branches.

> On the creation side, people are inconsistent in their assessment, from
> one hour to the next, never mind one day to the next.  On the application
> side -- absent quite a lot of on-going training and quite a lot of diligent
> application -- people are quite horrible at decision-making that properly
> juggles such a range of nuanced requirements.
>
> So as folk comfortably move towards these changes, please do explain how
> they will be used in practice and what the basis is for believing that it
> will be practical for the Meetings Committee and for the staff.
>
>
If you have a requirement written to allow the branching, this works
better.  This sort of writing:

The Facility directly provides, or permits and
facilitates, the delivery of a high performance,
robust, unfiltered and unmodified IETF Network.

Is a lot harder to test than the "network has reachability to X of Y sites
and a throughput capacity of at least N mbps per attendee to the nearest
IXP."   I can see why you don't want to name X, Y, and N in an archival
document, but making them pointers to references maintained in a more
living document isn't beyond our capabilities.

Ted

> d/
>
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> _______________________________________________
> Mtgvenue mailing list
> Mtgvenue@ietf.org
> https://www.ietf.org/mailman/listinfo/mtgvenue
>