Re: [EXTERNAL] Re: IAOC report to community at IETF 102

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Deen, Glenn (NBCUniversal) <Glenn.Deen@xxxxxxxxxx> wrote:
    > My [GD] attempts to answer are below

Thanks.

    > -glenn

    > On 7/18/18, 7:04 PM, "ietf on behalf of Michael Richardson" <ietf-bounces@xxxxxxxx on behalf of mcr+ietf@xxxxxxxxxxxx> wrote:

    
    > (greetings from a campsite in Northern Ontario...)
    
    > Andrew Sullivan <ajs@xxxxxxxxxxxxxxxxxx> wrote:
    >> in the IASA.  It appears that procedures were not always written down
    >> as completely as one might like, and the apparent gaps have had to be
    >> filled in from people's recollections.
    
    > Could we have a list of the things that were filled in?
    > Maybe the community will notice that the recollection was inaccurate?

    GD> At this point the new procedures are in place and it would be an
    GD> extraordinary effort to attempt  
    GD> go back create such a list.

So, i'm not asking for that.
I'm asking: what proceedures did you find were missing and had to be
documented?   It should be a short list of five or ten words, I'd think.
    
    >> is not available).  Accordingly, the IAOC closed the Tools Management
    >> Committee.  At the same meeting, the IAOC closed the Sponsorship
    
    > How will the tools work be supervised, and reported to the community?

    GD> The Tools work and reporting continues as it was except there is no
    GD> longer an IAOC subcommittee in the middle.  See the Tools team page:
    GD> https://www.ietf.org/about/groups/tools/

That page didn't help me at all, and would do nothing to help
someone who wasn't already familiar with the workings of things.

Previously, the tools team was effectively "managed" by the IAOC
subcommittee.   If the tools team identified that there was paid
work that needed to be done, then it made the IAOC aware of that.
If I had a problem with the tools team, the IAOC was the place to complain
to.   Is the path now via the IAD?

    >> https://iaoc.ietf.org/venue-selection.html.  An important part of that
    >> has been the replacement of the former Meetings Committee with a new
    >> Venue Review Committee.  The new committee is intended to be quite
    >> limited in its scope, because its primary task is to evaluate staff
    >> recommendations for conformance with the MTGVENUE criteria.  This is
    >> not an algorithm, of course, so some judgement will be required.  But
    >> the process is intended to be lightweight and transparent to the
    >> community.  We're continuing to refine procedures for this, and you
    >> should expect to see more announcements over time.
    
    > Will the reviews be public?  In particular, will reasons for rejecting sites
    > be public?  I don't think the previous evaluation was public, but maybe I
    > just never looked in the right place.
    
    > [GD] 
    > [GD] The new process that was just established based on MTGVENUE is
    > documented in:
    > https://iaoc.ietf.org/venue-selection-roles-and-processes.html .

Thank you.  The most useful part of that page:
      The venue-selection email address in not a discussion list that can be
      subscribed to. Email sent to the address is publicly viewable at the IETF
      Mail Archive.

that this list is archived and public was unknown to me.  The write-only,
but archived and viewable, nature of the list is strange, but whatever...
Maybe it's visible by IMAP too.. I didn't check.
Aaron Falk's recent comments about India were a very interesting read.

    GD> The list of rejected cites will be published, but it will not contain
    GD> detailed information about the venue.
    
    GD> However, for cities which are actually contracted to host a meeting,
    GD> information will be published as per section 4 Negotiation....

I think that the Venue Selection people are doing themselves a disservice by
not making the rational for rejecting public.
    a) gonna get the same suggestion over and over again.
    b) circumstances might change and someone might know about it.
    c) the city itself might realize they have a problem and do something
       about it.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@xxxxxxxxxxxx  http://www.sandelman.ca/        |   ruby on rails    [ 
	

    

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux