Subject: IAB report for IETF 104

From: Ted Hardie <[email-masked]>
Date: Sat, 23 Mar 2019 07:02:00 +0100

Dear Colleagues,

Here is the IAB report for the period between IETF 103 and IETF 104.  If
you have issues you want to discuss by email, feel free to send your
comments to [email-masked] (our public discussion list) or
[email-masked] (to reach just the IAB).  Questions at the open mic at IETF 104
are, of course, also welcome.

The IAB has a few chartered roles. It confirms the appointments to the
IESG, performs standards process oversight, and handles appeals. It also
performs architectural oversight (including appointing the IRTF Chair),
appoints the RFC series editor and oversight committee, manages the IETF's
relationship with IANA, and handles liaisons and appointments both to ISOC
and to other organizations.

Here's what the IAB has been doing since our last report; more detail on
many of the topics is available at https://www.iab.org.

There was an appeal during this period, received from Shyam Bandyopadhyay
requesting review of the transparency of the procedures of the Independent
submission stream of the RFC Series.
<https://www.iab.org/wp-content/IAB-uploads/2019/02/20190131-Independent-Submission-Process-Appeal.pdf>
The IAB response
<https://www.iab.org/wp-content/IAB-uploads/2019/03/independent-submissions-process-appeal-response.pdf>
was posted on February 19, 2019.

The changes in meeting practice since 103 have gone smoothly; there have
been a number of observers at IAB teleconferences
<https://www.iab.org/wiki/index.php/Agenda>.  A number of the attendees
were potential candidates for the IAB (then under consideration by the
NomCom), and we hope that in future other candidates for the IAB will avail
themselves of the same opportunity.

As part of its appointments role, the IAB has filled a number of positions
since our last report.   One of those was for the ISOC BoT; the new
candidate has been approved and confirmed. The details have been shared
with the chair of the ISOC elections committee, which will announce the
full slate of new Trustees when the other election processes have completed.

Another major role was for the position of IRTF Chair.  There were a number
of strong candidates, and the IAB process was necessarily long as a result.
 Dr. Colin Perkins
<https://www.gla.ac.uk/schools/computing/staff/colinperkins/> has been
appointed; he will take up the role at IETF 104.  The IAB is grateful to
Allison Mankin for her service as Chair.

In addition, the IAB appointed Warren Kumari to the ICANN Technical Liaison
Group.
<https://www.iab.org/2019/01/16/appointment-of-warren-kumari-to-the-icann-technical-liaison-group/>
DOCUMENTS

You can always find the documents the IAB has adopted and is working on at
https://datatracker.ietf.org/stream/iab
<https://datatracker.ietf.org/stream/iab>.

Two documents have been approved for publication since the last report,
though they have not yet been issued as RFCs.

Transport Protocol Path Signals
<https://datatracker.ietf.org/doc/draft-iab-path-signals/>
(draft-iab-path-signals)

The Wire Image of a Network Protocol
<https://datatracker.ietf.org/doc/draft-iab-wire-image/>
(draft-iab-wire-image)

Both are products of the IAB’s Stack Evolution Program, which has been
considering the behavior of on-path network elements which observe network
flows, especially when these are encrypted.
PROGRAMS

The IAB organizes its work, for the most part, into programs.  There are
basically two classes: management programs and architectural programs.  The
former are how we handle the oversight of various things, and the latter
are where we do architectural work.  The former are expected to last as
long as the IAB continues to have that oversight function; the latter last
until the IAB has come to a conclusion on the relevant group of topics or
has decided that the topic needs to be reframed.  Programs are listed at
https://www.iab.org/activities/programs/. As a general rule, each
architectural program has a public mailing list, as well as a
member-specific list.  For subscription instructions, see
https://www.iab.org/iab-mailing-lists/.

The Plenary Planning Program added Xiaodong Lee as a member during this
period and the Privacy and Security program added Roman Danyliw, who is an
incoming Security Area Director.
WORKSHOPS

In our last report, we noted that the IAB then had two workshops in
preparation.  Both were delayed as their topic focus and audiences shifted
during the course of workshop preparation.  Where the CIPE workshop was
originally broadly treating concentration and asymmetry, the current
proposal is to narrow that to examining the impact of concentrated,
centralized deployments which emerged in protocols designed for distributed
operation.  The timing of that workshop is currently targeted for June,
should other assumptions on logistics hold. The joint workshop with the W3C
will now likely shift from a broad ecosystem review to a meeting focused on
the potential impact of signed http exchanges
<https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/gPH_BcOBEtc>
.  While that may still take place as a workshop, the liaison aspects of
the work are also clearly important, as it touches on work at the W3C,
WHATWG, and the IETF.

Respectfully submitted,

Ted Hardie

for the IAB

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 Mar 2019 16:41:52 +0100

Ted Hardie <[email-masked]> wrote:
    > The Wire Image of a Network Protocol (draft-iab-wire-image)

    > considering the behavior of on-path network elements which observe
    > network flows, especially when these are encrypted.  

Thank you for this work.
It is very interesting description.

I would have liked to separate out the definition of the wire image a bit
From the value judgement that having a smaller wire-image is a good thing.

I read the document wondering if there was going to be a abstraction to
document what the wire-image of a protocol is.  I saw no such thing, and
probably such an effort might result in attempts to boil an ocean.

I then wondered as I read the document if some kind of "WIRE IMAGE
CONSIDERATIONS" section might be suggested.   I have put "PRIVACY
CONSIDERATIONS" headings in a few documents, and I know others have too.
I think that the wire-image description could fit into such a section.

The document could have wistfully wondered if we'd have a different
architecture had TCP made it's port numbers clearly invariant.
The document could perhaps beat people over the head a bit harder in this
area.

Thank you for this document.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Mirja Kuehlewind <[email-masked]>
Date: Sat, 23 Mar 2019 17:18:03 +0100

Hi Micheal,

One comment/question below:

> On 23. Mar 2019, at 16:41, Michael Richardson <[email-masked]> wrote:
> 
> 

I don’t think the doc says that the wire image needs necessarily to be small.

This is in the draft:

“… the protocol's wire image should
   therefore be designed to explicitly expose information to those
   network functions deemed important by the designers in an obvious
   way.  The wire image should expose as little other information as
   possible.”

Which just says that you need to design the wire image carefully to only expose things you really want to expose and not expose (or at least minimise) anything else (wherever possible). 

Where in the draft did you read that the wire image needs to be small. If that is in there or could be misinterpreted that way, we should fix that.

Mirja

---

From: Michael Richardson <[email-masked]>
Date: Sun, 24 Mar 2019 02:17:57 +0100

Mirja Kuehlewind <[email-masked]> wrote:
    >>> Both are products of the IAB’s Stack Evolution Program, which has
    >>> been considering the behavior of on-path network elements which
    >>> observe network flows, especially when these are encrypted.
    >>
    >> Thank you for this work.  It is very interesting description.
    >>
    >> I would have liked to separate out the definition of the wire image a
    >> bit From the value judgement that having a smaller wire-image is a
    >> good thing.

    > “… the protocol's wire image should therefore be designed to explicitly
    > expose information to those network functions deemed important by the
    > designers in an obvious way.  The wire image should expose as little
    > other information as possible.”

    > Which just says that you need to design the wire image carefully to
    > only expose things you really want to expose and not expose (or at
    > least minimise) anything else (wherever possible).

    > Where in the draft did you read that the wire image needs to be
    > small. If that is in there or could be misinterpreted that way, we
    > should fix that.

I think that the sentence:
   The wire image should expose as little other information as possible.

seems to suggest it to me, but I agree that in fact, it doesn't say that.

I read the first sentence say that what is exposed should be intentionally
exposed.

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

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 24 Mar 2019 10:38:31 +0100

> I think that the wire-image description could fit into such a section.

Michael,

I think it would be useful for documents to specify which information 
they expose; intentionally expose as well as what isn't intentional but 
they need to expose to function. (For example, I believe IPsec ESP needs 
to expose an SPI number to function.)

[And if it was me I'd put that information in the security 
considerations section, but let's not discuss the set of sections in the 
document and focus on the information in the document instead.]

But as the document mentions, the extent of the wire image is larger 
than a single protocol (with the example being the DNS lookup(s) before 
the main communication starts.) I wouldn't expect that system-level view 
to be captured in each RFC.

Regards,
   Erik