Re: [Iasa20] draft-haberman-iasa20dt-recs-00.txt

[Stephen Farrell <[e-mail]>]

Just one addition for now:

WRT default-open: I'd suggest starting from a
position where there's a default-open policy
with a published list of exceptions that can
be changed (shortened or added to) via some
TBD iasa/2 process - for today, I'd suggest that
the IAOC publish changes to that list via the
[e-mail] list and have to take feedback
from the community - the future analog of that
shouldn't be hard to figure. in future.

The inclusion of something like the above in
the draft would mean happiness++ for me:-)

Cheers,
S

On 11/07/17 23:29, Jari Arkko wrote:
> 
>> For me, the main things that need improving with IASA
>> nearly all relate to transparency and I think that got
>> maybe one mention in the draft. (Didn't check back,
>> sorry if I've gotten that wrong.) I would have hoped
>> that a default-open statement would have been included
>> and to see if that'd differ based on the different
>> organisational options.
> 
> The transparency topic has been high on our
> mind, but we’ve struggled to figure out what
> exactly to say about that. The default-open
> statement is certainly one way forward,
> thanks for reminding us of that.
> 
> But, what specifically will that include? I suspect
> that the devil is in the details. Personnel discussions…
> contract awards… sums until an award for a project
> is made… negotiation strategies… discussion of
> legal issues such as court cases where IETF is
> included… there are a fair number of these, even
> outside the most discussed topic of hotel contracts.
> 
> Would a specification (e.g., RFC) of what’s open and what’s
> not open be the ultimate outcome of that approach, or
> would you see that as an alternative to the
> default-open statement?
> 
>> So I'd be interested in the analysis covering which
>> of the options might be most transparent. I worry
>> there's a big risk that transparency++ might get
>> lost if we undertake the two more radical changes
>> to the organisation.
> 
> Impacts on transparency are clearly a necessary
> piece of the analysis. That needs to be added. Thanks.
> 
>>
>>>
>>> So, do you have thoughts on what aspects we
>>> are missing and which should be documented?
>>> Or are you unhappy with the level of detail or
>>> analysis of the current options?
>>
>> Not sure it's that useful to note but there are
>> things with which folks seem generally very happy
>> (e.g. AMS staff today) and I don't think the draft
>> covers not-breaking-those. So what other things
>> do we not want to break? Lack of membership is
>> one I'd like to keep, there may be more. So maybe
>> consider documenting things we like too?
> 
> Good points. Would certainly want to include
> a positive statement about things that are currently
> working well.
> 
>>>
>>>> - I didn't find section 6 clear or convincing but
>>>> it's also hard to see how one might document
>>>> such an analysis at this point. Maybe when I
>>>> read it more closely or we see a presentation in
>>>> Prague, it'll be clearer, but as of now, the DT's
>>>> analysis isn't that clear to me. It could be that
>>>> I change my opinion about IASA++ if/when I do
>>>> understand the DT's analysis better, but I'd be
>>>> surprised if that were the case.
>>>
>>> At this point, we’d love to hear your thoughts
>>> on aspects that should be taken into account.
>>> Lets worry about what the right conclusion is
>>> later.
>>
>> Fair enough. But TBH, I think I still need to see
>> the presentation in Prague to get what's being
>> said in the analysis. I'll try give it another
>> read in the meantime if I can and respond further
>> but not sure I'll have a chance.
> 
> In honesty, the analysis section is very early
> text.
> 
> Let me turn your statement around a bit. We still
> need to hear what you care about in Prague in
> order to produce a more complete analysis section :-)
> 
> Jari
> 
> 
> 
> 
> _______________________________________________
> iasa20 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iasa20
>