Re: [arch-d] draft-iab-m-ten-workshop

[Wes Hardaker <[e-mail]>]

Eliot Lear <[e-mail]> writes:

> Hi everyone,

Hi Eliot and Arnaud,

I'm responding to the larger point you both had concerned with together
about the nature of the wording and the purpose of the IAB workshop
report.  Thank you both for your extensive comments about the content.

> To begin with, it's nice when a report can seamlessly join various
> workshop components, but this report goes so far as to appear to be
> itself a position paper.  There are a great many unsupported and
> otherwise unattributed assertions made.  Under Chatham House rules one
> might expect such assertions along the lines of, “[one person/several
> people] suggested that...”

I think the general of how best to describe what happens in an IAB
workshop and what the report entails is an interesting one, and I'm
surprised it hasn't been brought up before (well, at least to my
knowledge so it may very much have been in past discussions).  IAB
workshop reports (IMHO) are designed not to assert the veracity of the
statements within, but rather to capture the discussion and the
statements that participants made either in presentations or in ensuing
discussions.  So, to some extent the entire report should be read as
"[one person/several people] suggested that"...  To that end, we [the
IAB] did discuss the best way to represent this and have published a -02
version with a number of changes, including a new section in the
introduction to make this more clear which I'll quote below:

    1.1.  About this workshop report content        
            
       This document is a report on the proceedings of the workshop.  The   
       views and positions documented in this report are those of the       
       expressed during the workshop by participants and do not necessarily 
       reflect IAB views and positions.     
            
       Furthermore, the content of the report comes from presentations given        
       by workshop participants and notes taken during the discussions,     
       without interpretation or validation.  Thus, the content of this     
       report follows the flow and dialog of the workshop but does not      
       attempt to capture a consensus.

The full diff between -01 and -02 can be found here:

  https://author-tools.ietf.org/iddiff?url2=draft-iab-m-ten-workshop-02

Most of the rest of your comments were about specific statements that
you disagreed with, but were made during the course of the workshop by
at least "[one person/several people]".

Note that the full recordings are on the IETF youtube channel as well:

https://www.youtube.com/watch?v=Kizk_QrIc3s
https://www.youtube.com/watch?v=aV1pzuCduLo
https://www.youtube.com/watch?v=p4NlZJlactE

A number of your comments were requesting references:

> Great!  Reference, please?

We did not include references to work, but rather included references to
the individual position papers which themselves often contained
references.  And the youtube presentations also have discussions from
the presenters and comments that will give rise to additional information.

>     Within the IETF, the Manufacturer Usage Description Specification (MUDD) {?RFC8520} specification is one
>     subset of contracts. Note that contracts are likely to only succeed in a constrained, expected environment
>     maintained by operational staff, and may not work in an open internet environment where end users are
>     driving all network connections.
> 
> The initial demonstration implementation of MUD (one D) was
> implemented using a plugin to DNSCAP that itself issued commands to
> iptables.

FYI, fixed the typo in MUD.  Thanks for catching that.

> There are two real questions hiding here:
> 
>  1. Are firewall vendors and telcos have an interest in protecting the user with such contractors?  The user
>     certainly has that interest.
>  2. Can a contract be properly described and maintained in a secure way?
> 
> There has been some academic work on answering the latter
> question.[1,2]  Going further, though, some aspects of MUD (and
> Michael could say a good bit about this, and probably did at the
> workshop), require visibility.   So for instance, rather than making
> use of DNSCAP, a more explicit API between the resolver and the rest
> of network management is something that has been discussed in various
> corners (if memory serves, dnsop just recently).  This very much
> depends on whether the endpoint uses a resolver with that sort of
> binding.  Future work, I suppose.

I've argued recently that half (if not more) of an IAB workshop is to
start the discussion and direction, and rarely should the workshop
actually solve a problem.  The point is to get people in the room so a
conversation starts, even if there isn't agreement at the end.  To that
end, there should *always* (IMHO) be future work after an IAB workshop.
For if there isn't and the problem was actually solved during the
workshop, it probably should have been a working group instead of a
workshop :-)

-- 
Wes Hardaker
USC/ISI