Subject: IAB agendas now public

From: IAB Chair <[email-masked]>
Date: Tue, 4 Sep 2018 08:58:55 -0700

At the IETF 102 plenary session there was a request to the IAB to make 
its agendas public in advance of its meetings, so that interested 
members of the community could contact the IAB regarding items on the 
agenda.  The IAB agreed, and the draft agendas will be available at:

https://www.iab.org/wiki/index.php/Agenda

beginning with this week's meeting.  Since agendas change fairly 
frequently, the page will show the date at which the agenda was last 
updated so that updates may be tracked.

regards,

Ted Hardie
for the IAB

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 Sep 2018 07:29:15 -0700

> agenda.  The IAB agreed, and the draft agendas will be available at:

my memory is that the critical request that the iab follow the iesg's
lead and make the meeting o-p-e-n.  and i fully and strongly support
that request.

randy

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 5 Sep 2018 10:31:45 -0400

+1

All of these meetings should be.

—Tom

> On Sep 5, 2018, at 10:29 AM, Randy Bush <[email-masked]> wrote:
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 5 Sep 2018 07:50:56 -0700

As you'll note from following the link provided, that is on today's
agenda.  Thanks for your input into the agenda item.

regards,

Ted Hardie

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 Sep 2018 07:57:17 -0700

> agenda.  Thanks for your input into the agenda item.

no extra charge

>>> lead and make the meeting o-p-e-n.  and i fully and strongly support

ydnar

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 5 Sep 2018 12:30:31 -0400

As with almost any institution that is 30 years old, the IETF considers
itself to be a newcomer when it is actually approaching its mid-life
crisis.

One of the biggest malfunctions in the IETF is that since the Kobe meeting,
it has not been allowed to do architecture or only allowed to do it in ways
that have the least influence possible. And we need a group that is
thinking about architecture and can make recommendations that have broad
consensus across the IETF.

To do that, IAB meetings have to be open and include all the stakeholders
for a particular issue. Because what is important is not what the decision
is but who is going to follow it.

Right now, I see a lot of interesting work going on in service discovery.
People are starting to realize that the principal benefit of DNSSEC is not
that it eliminates the need to trust the local DNS resolver, it is that it
eliminates the need to use the local DNS resolver at all.

No-resolver DNS is a powerful idea. So is the idea of not using DNS as the
client-resolver protocol and using a protocol designed to enable service
discovery that is as fast and as expressive as possible.

But getting movement there right now is really hard because the problem is
split between a number of different IETF areas. There is the applications
area which consumes the discovery service and there is the DNS area that
maintains the authoritative service and then we have a series of WGs that
each demand that they 'own' one piece of the problem and absolutely refuse
to listen to any requirements other than the exact set of requirements that
justify the exact solution that they came up with in the first place.

Another problem with the lack of architectural direction I see is that we
don't have a group that is able to say 'that is a great point solution,
other people want to do similar, now propose a general framework'. For
example, the MX record was proposed very early in the history of DNS and
was clearly essential for service scalability. Yet it took us a decade to
generalize as SRV and another decade to establish SRV+TXT records as the
principle service discovery mechanism. Meanwhile we have had DANE throw in
a service description attribute record but only for one transport protocol
and only for one trust model and even though it has seen precisely zero
adoption in the WebPKI world, it is apparently the only security policy
approach we are permitted to consider.

The TRANS/CT notary infrastructure is great as a mechanism for notarizing
PKIX certs. But do we really want to build on that point solution for every
other application that needs a notary? Maybe we do, maybe we don't but at
least there should be people asking whether that is the right approach or
if we should treat that as the MX record proof of concept, the special case
for the WebPKI and do something else for the general case.

I would like to see at least some part of the organization do a post mortem
on past efforts to ask whether they went wrong because what they were
trying to do is impossible, because they were doing it in the wrong way or
because there was a necessary pre-condition that was not met. My position
on security policy for the past 15 years has been that it is one of the two
most important security problems we need to solve, that devising a language
for specifying security problem is not difficult.

The biggest deployment obstacle I see is that the security policy records
are useless unless they are accurate and they will never be accurate unless
there is an automated infrastructure for service management. The biggest
technical challenge is what the client is to do when it detects a security
policy violation. And that is really difficult to even get people to
discuss because what people imagine to be a 'common sense approach' tends
to be impossible to reduce to code because it requires a different response
to use cases that the client cannot distinguish based on the information
available to it when it makes the decision.

On Wed, Sep 5, 2018 at 10:50 AM, Ted Hardie <[email-masked]> wrote:

> On Wed, Sep 5, 2018 at 7:31 AM, Thomas Nadeau <tnadeau@lucidvision..com
> <[email-masked]>> wrote:
>
>> +1
>>

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 5 Sep 2018 13:00:26 -0400

> On Sep 5, 2018, at 12:30 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> Meanwhile we have had DANE throw in a service description attribute record but only for one transport protocol and only for one trust model and even though it has seen precisely zero adoption in the WebPKI world, it is apparently the only security policy approach we are permitted to consider.

By WebPKI world, I assume you mean web browsers using HTTPS?

DANE *has* seen adoption in SMTP (~314,000 domains presently),
with implementations in multiple MTAs: Postfix, Exim,
MailChannels, Halon, PowerMTA (beta), Cisco ESA (beta), ...

For the Web, the main obstacle is last-mile DNSSEC issues, which
may get easier as DNS over TLS and DNS over HTTP offerings from
Cloudflare and the like eliminate bypass the CPE DNS breakage.
The remaining obstacle is purportedly latency, which may be
addressed with tls-dnssec-chain, if we manage to get adequate
downgrade-protection into the spec.  Finally, DNSSEC adoption
is still light, at ~9.5 million domains, highly concentrated in
Northern Europe, the USA and Brazil.  The actual payload of DANE
TLSA record has not been a real barrier to adoption.  The
PKIX-TA(0) certificate usage is a reasonable candidate for
hardening HTTPS against rogue CAs.

True, DANE is not "service discovery".  If a new service
discovery protocol that subsumed DANE became popular,
and vended both service location and security policy,
that'd be fine.  It is an interesting problem to work on.

-- 
	Viktor.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Sep 2018 07:40:30 +1200

> agenda.  Thanks for your input into the agenda item.

fwiw I think this is a two-edged sword. It's not a new discussion, of course.
In fact it goes back to 1994 to my personal recollection. And there was
a time when the IAB held open face-to-face meetings at IETF sites, before the
IETF Plenary was invented. When the IAB is discussing architecture, there's
every reason to open the discussion (which is why there are IAB workshops
and [email-masked]).

But there are quite a lot of issues the IAB has to handle that are not
part of its architecture remit and that do have a political angle. Replay
the great ICANN/IANA saga a couple of years ago, for example. I fear that
either the IAB would have been very inhibited in its discussions, or
they would mainly have been held in executive sessions.

So yes to opening up the discussions, but not all of them.

As for publishing the agenda, yes, we should have done that all along.
Mea culpa.

Regards
    Brian

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 Sep 2018 14:00:43 -0700

> part of its architecture remit and that do have a political
> angle. Replay the great ICANN/IANA saga a couple of years ago, for
> example. I fear that either the IAB would have been very inhibited in
> its discussions, or they would mainly have been held in executive
> sessions.

i beg to differ.  heck, forget the begging :)

when it is a personnel or analogous issue, sure

but when it affects our community, it should be open.  and 'politics'
affects our community.  the icann/iana saga should have been open.
the ietf prides itself on being open.  well, we should walk the walk.

btw, politics is what happens when more than one person is involved.

randy

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 5 Sep 2018 17:13:28 -0400

I totally agree with Randy.  The one distinction is between observing these
discussions and being allowed to partake in them. I can understand that you
folks might want to limit discussion at IAB meetings to the IAB membership,
and then have designated open comment/discussion later where anyone can comment.
That is fair, but there should be few exceptions where the IAB discussions/debates 
should be behind closed doors such as for HR/legal matters.

—Tom

> On Sep 5, 2018, at 5:00 PM, Randy Bush <[email-masked]> wrote:
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 05 Sep 2018 14:17:26 -0700

for example, the elephant in the room.

https://www.iab.org/documents/minutes/minutes-2018/iab-minutes-2018-05-30/

9. Executive Session: RFC++ BoF proposal
The RFC++ BOF Proposal was discussed in an executive session.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 5 Sep 2018 21:04:11 -0700

On my time on the board, there were very few "pens down" moments, but
there were a few:

  * Appointments/NOMCOM confirmations
  * Organizational disputes involving intelligence that would not have
    been shared in an open forum.

The IAB was very effective addressing both of these with some limited
use of executive session.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 6 Sep 2018 16:49:35 +1200

> btw, politics is what happens when more than one person is involved.

Yes. And I didn't mean that all politics should be in executive
session. It's just that if the IAB needs to discuss how it should
respond to external politically charged events, the discussion would
happen in one of three ways:

1. In an open session, in which case the IAB would be showing its
weaknesses to the other parties.

2. In an executive session.

3. If #2 is not an option, in a secret meeting.

I like #3 less than #2. So if there's to be a new dispensation,
I think the IAB needs to be able to hold executive sessions about
external (non-I*TF) matters as well as the usual HR/legal matters.
In general, I don't see why internal I*TF matters would need
secrecy.

    Brian

---

From: Christian Huitema <[email-masked]>
Date: Wed, 5 Sep 2018 22:27:04 -0700

> In general, I don't see why internal I*TF matters would need

The IAB does a lot of discussions with external partners. Sometimes that
involves bargaining, and bargaining often involves a part of bluff. One
of the concerns is that if the IAB entirely discusses its bargaining
positions in open meetings, then the other party will effectively see
through the bluff, and the IAB/IETF negotiation position will be much
weakened.

-- Christian Huitema

---

From: George Michaelson <[email-masked]>
Date: Thu, 6 Sep 2018 15:40:27 +1000

Realpolitk exists, denying it is futile. But this also has
consequences. If we accept that "bluff" and "negotiate" exist in IAB
process here, we need to be mindful of echoes into things we prefer
not to expose to the real world. Like.. standards. We don't want
bluff, and "negotiate" in protocol decisions. Otherwise, why are we
claiming some model of distinction against eg the votes in the ITU?

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Sep 2018 05:30:33 -0700

> through the bluff, and the IAB/IETF negotiation position will be much

so holding a secret meeting within a closed meeting to discuss a bof on
the rfc series is
  o perfectly fine
  o a lapse of judgement (of course i have none of those :)
  o a lapse of process
  o your ad goes here?

randy

---

From: Bob Hinden <[email-masked]>
Date: Thu, 6 Sep 2018 08:38:30 -0700

Randy,

> On Sep 6, 2018, at 5:30 AM, Randy Bush <[email-masked]> wrote:
> 

If the IAB decided it needed to discuss an IETF BOF proposal in executive session something is seriously wrong.   This was not a personal matter, nor negotiating with another group, nor discussing individuals being considered for an open position.

This is very broken.

Bob

---

From: Ted Hardie <[email-masked]>
Date: Thu, 6 Sep 2018 08:40:16 -0700

Randy,

If you refer to the minutes of the previous meetings you'll see:

10. Feedback from the Independent Stream Editorial Board

The IAB discussed feedback from the Independent Stream Editorial Board on
proposed changes to the Independent Stream. The IAB will discuss this
further next week when Heather Flanagan is available to join the IAB meeting

on 5/9, followed by:

5. Independent Stream

The IAB discussed the future of the Independent Stream and how to frame
that discussion with the community.

Martin Thomson noted that the conversation was not about closing the
Independent Stream, but about trying to find ways to remove some of the
confusion about what counts as a standard and what documents are actually
produced by the IETF.

Jari Arkko added he does not want to see publication of documents made more
difficult or add obstacles to publishing research.

After the discussion, Martin Thomson, Ted Hardie, Melinda Shore, and
Suzanne Woolf agreed to write up a BOF proposal for IETF 102 to discuss an
experiment with the community for publishing IAB, IRTF, and IS documents
with an identifier other than “RFC.” A new mailing list will be created to
go with the BOF proposal.

on 5/11.

There were also a number of previous discussions, including at the joint
IESG and IAB retreat.

The 5/30 meeting had this in executive session because I wanted it to have
the balance of time in the meeting; the item before it needed to be an
executive session (personnel issue):

8. Executive Session: RZERC Appointment

The IAB’s appointment to the RZERC was discussed in an executive session.
9. Executive Session: RFC++ BoF proposal

As a result, it ended up in executive session, since calling people back
into the meeting once you have gone into executive session is impractical.
  I recognized that at the time and was okay with it, because of some of
the discussion was who to request act as chair.  That is, again, a
personnel issue.

I understand that you may disagree with the decision to hold any part of a
meeting in executive session, and if it that was a lapse in judgement, it
was mine.

regards,

Ted