Narrative Minutes interim-2019-iesg-16 2019-08-08 14:00
narrative-minutes-interim-2019-iesg-16-201908081400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2019-08-08 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Liz Flynn, Secretariat

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Ignas Bagdonas (Equinix) /  Operations and Management Area
Michelle Cotton (ICANN) / IANA Liaison
Alissa Cooper (Cisco) / IETF Chair, General Area
Roman Danyliw (CERT/SEI) / Security Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Wes Hardaker (USC/ISI) / IAB Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Suresh Krishnan (Kaloom) / Internet Area
Mirja Kuehlewind (Ericsson) / Transport Area
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Futurewei Technologies) / Routing Area
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area

REGRETS
---------------------------------
Deborah Brungard (AT&T) / Routing Area
Heather Flanagan / RFC Series Editor
Ted Hardie (Google) / IAB Chair
Adam Roach (Mozilla) / Applications and Real-Time Area
Amy Vezza (AMS) / IETF Secretariat
Portia Wenze-Danley (ISOC) / Interim LLC Executive Director
Magnus Westerlund (Ericsson) / Transport Area

OBSERVERS
---------------------------------
Jenny Bui
Greg Wood

1.2 Bash the agenda

Cindy: Does anyone want to add anything new to today's agenda? Any other
changes? Hearing none, we'll move on.

1.3 Approval of the minutes of past telechats

Cindy: Does anyone have an objection to the minutes of the July 11
teleconference being approved? Hearing none, we will get those posted. There
are narrative minutes that came out on Tuesday; does anyone have an objection
to the narrative minutes being posted? Hearing none, we'll get those posted too.

1.4 List of remaining action items from last telechat

     o Ignas Bagdonas to propose an additional question on YANG Model
       format validation for each of the styles of document write-ups.

Ignas: It's finally written up so I need to circulate this with a few YANG
Doctors. It's mostly done but please keep it in progress for now.

     o Roman Danyliw to talk to the tools team to reset the counters on
       substate change for documents in AD Evaluation.

Roman: A ticket was filed this morning in the track instance of the datatracker
so we can mark that closed.

     o Roman Danyliw to draft text to be posted on ietf.org about reporting
       protocol vulnerabilities via an email alias and possible procedures
       on how to assign triage resources.

Roman: That one is still in progress.

     o Suresh Krishnan to write a document on replacing the "updates" with
       new terminology (amends/amended by; extends/extended by; see also).

Suresh: Consider this complete. Mirja and I wrote something and we published
it. We had discussions with the other stream managers. This is done but I think
it's got a long way to go after. You can close it.

Mirja: The only other question for me is how we get more community feedback on
this but maybe that's a topic for an informal. Shall I put it on the informal
or will you?

Suresh: I'll put it on the informal. Thank you Mirja.

     o Martin Vigoureux to work with the IESG to create a list of possible
       IESG Tutorials and will prioritize them for scheduling on a series
       of Informal Telechats.

Martin: It's still in progress but the list is nearly finalized. I'll get back
to you all with the definitive list.

     o Eric Vyncke to write up draft text for the NomCom to help them
       understand the rules for the NomCom.

Eric: It's still a work in progress. I'm waiting for Victor to do something
with it. A work in progress.

     o Suresh Krishnan to write up a NomCom Chair BCP (work with past
       chairs).

Suresh: I had a long chat with Scott and previous NomCom chairs. We are putting
together something on GitHub right now. We don't know how it's going to get
published but the lead on this is going to be Scott. It's complete from my side
and I'll make sure this gets out sometime soon for Victor to do it. Victor
already has the information, so consider it done.

     o Roman Danyliw to shepherd the www.ietf.org analytics discussion
       with the community.

Roman: I want to thank everyone for the great feedback I got on the updated
proposal while we were at 105. I still haven't finished putting that all into
text so please mark it in progress.

     o Alexey Melnikov to find designated experts for RFC-ietf-core-object-
       security [IANA #1141664].

Alexey: This one is in progress.

     o Alvaro Retana to finalize the proposal for relabeling the IETF
       Meeting Agenda Conflicts, and discuss the proposal with the WG
       Chairs.

Alvaro: This is done. I got confirmation from Robert Sparks yesterday that he
made he change and just needs to commit it. The commit should be done before
August 19 when the window opens for requests.

     o Alexey Melnikov to find designated experts for RFC 8554 [IANA
       #1142796].

     o Alexey Melnikov to find designated experts for RFC 8610 [IANA
       #1145107].

Alexey: Both in progress.

     o Ignas Bagdonas to find designated experts for RFC 7317 [IANA
       #1146017].

Ignas: There is one; I don't have the second one not yet. Still in progress.

     o Adam Roach to collate the list of specific "hot topic" items from
       each Area that will be provided to document authors and post it on
       the wiki.

Cindy: Adam is not with us today [so we will leave this in progress].

     o Alvaro Retana to find designated experts for RFC 5575 [IANA
       #1147895]

Cindy: I think there's a management item today officially noting this.

Alvaro: I did send a couple minutes ago the two people I want to designate
there. We can talk about it later.

     o Warren Kumari to find designated experts for RFC 8552 [IANA
       #1148605]

Warren: I just did this about half an hour ago.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-idr-bgp-extended-messages-35  - IETF stream
   Extended Message support for BGP (Proposed Standard)
   Token: Alvaro Retana

Cindy: We have a couple of open positions today. Ben, did you want to state a
position?

Ben: No, I ran out of time this week. I'll finish dnssd-push during the call
but everything else I don't have a position on, I won't.

Cindy: Okay. It looks like the other open positions are for people who aren't
here. There are no active Discusses, so unless there's an objection now it
looks like this is approved.

Alvaro: We'll need a revised ID on this please.

Cindy: Okay, we'll put this in Approved, Announcement to be Sent, Revised ID
Needed, and you can let us know when it's ready to go.

 o draft-ietf-curdle-ssh-ed25519-ed448-09  - IETF stream
   Ed25519 and Ed448 public key algorithms for the Secure Shell (SSH)
   protocol (Proposed Standard)
   Token: Benjamin Kaduk

Cindy: There are no open Discusses so unless there's an objection now it looks
like this one is approved. Is this good to go as is, or does it need any
revisions or notes?

Ben: I believe we had some comments it would be good to address so let's put it
in Revised ID needed.

 o draft-ietf-lamps-cms-shakes-16  - IETF stream
   Use of the SHAKE One-way Hash Functions in the Cryptographic
   Message Syntax (CMS) (Proposed Standard)
   Token: Roman Danyliw

Cindy: Ignas, did you want to state a position?

Ignas: No, I ran out of time this week.

Cindy: There are no active Discusses, so unless there's an objection this one
is approved. There's currently an IESG note about whether to do a second last
call about a downref for RFC 8017. Does that still need to be there?

Roman: This was a procedural note, the same one pointed out earlier. We need to
make a judgment call whether we're comfortable with that downref. I mistakenly
did not put that in the last call. However, the downref it references is
actually an update to something that is in the downref registry, and when I
made this mistake in the peer document, draft-ietf-lamps, we agreed that was
okay. I'm hopeful that's still ok with the group now but I need to ask.

Barry: So this is the second time this particular downref was missed?

Roman: Correct. I pushed the documents both at the same time and did not catch
that.

Barry: I don't have any problem with it but if we keep missing the same
document I do have a problem with it. We're supposed to make sure the community
is informed.

Roman: Absolutely. This one is on me; I wasn't screening them correctly.

Barry: It happens all the time. I have no problem this time.

Warren: No problem either.

Alissa: And Cindy notes that it's in the downref registry from a different
downref now.

Cindy: It sounds like then this one is approved and we can remove this IESG
note. Is this good to go as is or does it need another check?

Roman: It needs a Revised ID.

Barry: Actually I have a comment then. Roman, if you're waiting for a revised
ID anyway, would there be any harm in putting out a 2 week last call
specifically on the downref?

Roman: There would be no harm. The revised ID is that there are some typos in
the editorial guidance and so it's a very minor turn that's going to be done
this morning.

Barry: Okay, never mind then.

Mirja: You can even put the edits in an RFC editor note and move on right away.

Roman: The typo is in the editor notes.

Cindy: Okay, so it sounds like this is going to stay in Approved, Announcement
to be Sent, Revised ID Needed, and you can let us know when it's ready to go.

 o draft-ietf-babel-dtls-07  - IETF stream
   Babel Routing Protocol over Datagram Transport Layer Security
   (Proposed Standard)
   Token: Martin Vigoureux

Cindy: There's an open position for Warren. Would you like to state a position?

Warren: No, I ran out of time.

Cindy: There are a few Discusses. Would anyone like to discuss them today?

Martin: Not necessarily from my side, but I'm perfectly open to discussing them
if my fellow ADs want. Julius has been quite responsive on the whole set of
babel drafts. Let me know, Roman?

Roman: I'm not understanding. I'll iterate with the authors to get these banged
out.

Martin: I was only saying if you wanted to discuss it now, I'm fine, but since
Julius is quite active, I think you can keep discussing with him.

Roman: Completely agree.

Martin: I think we can move on and keep it in IESG evaluation. It will
definitely require a Revised ID.

 o draft-ietf-intarea-frag-fragile-15  - IETF stream
   IP Fragmentation Considered Fragile (Best Current Practice)
   Token: Suresh Krishnan

Cindy: There's a Discuss for this document. Would you like to discuss that
today?

Suresh: The discussion is happening on the mailing list. I agree with Alissa's
point; we'll continue on the mailing list. There seems to be some resistance in
the WG so we'll figure out some wording that will work. Warren also has some
pseudo-Discuss points on there. I think this will happen on the mailing list,
but I do understand Alissa's and Warren's points. I'll go through the other
comments to make sure they're addressed as well.

Alissa: I really just wanted to ask if this is possible. I'm not hung up on it.
So just let me know if you think the discussion is not resolving at some point
and I can clear it. I just wanted to ask the question. If the specific point
has already been discussed in the WG that's fine.

Suresh: It has been but I think it's possible to have slightly more nuanced
text without breaking the whole thing. I'll think about it a little bit and see
if I can come up with some text that addresses your point without opening up a
rathole. I'll let you know.

Cindy: Is this going to be a revised ID needed or an AD Followup?

Suresh: Revised ID needed please, thank you.

 o draft-ietf-manet-dlep-latency-extension-04  - IETF stream
   DLEP Latency Range Extension (Proposed Standard)
   Token: Alvaro Retana

Cindy: There are no active Discusses so unless there's an objection this is
approved.

Alvaro: We're going to need a revised ID on this one to address the comments. 
Thanks.

 o draft-ietf-babel-hmac-08  - IETF stream
   HMAC authentication for the Babel routing protocol (Proposed
   Standard)
   Token: Martin Vigoureux

Cindy: There are a number of discusses on this document; would you like to
discuss them today?

Martin: No; same as the previous babel draft, I'm happy to discuss but the
authors are quite responsive and I didn't notice any Discuss which couldn't be
resolved, so it's progressing. We can keep it in IESG evaluation and Revised ID
needed.

Ben: The only thing I would ask is if people think I'm being unreasonable about
the HMAC terminology because we're not actually using HMAC with a keyed
Blake2s. That's going to be changes all throughout the document; they talk
about HMAC everywhere.

Martin: Is it very important to you?

Ben: It's moderately important for me. I don't like to be putting things that
are factually incorrect into a document.

Martin: I think the authors are pretty open to making changes. Let's see where
they go with that point and if we face resistance, then I might jump in. Ok?

Ben: Sounds good. Thanks.

Mirja: I have a question on this document, which was a comment from my side but
I'd like to figure out opinions. I understood this was coming out of the IRTF
and was experimental and so on. I wonder if it would make sense to have this
HMAC mechanism in the main document and not have it as a separate document.
Keeping it separate makes it easier to read but also gives less incentive to
look at it and implement it.

Ben: I think Alissa has a discuss on the main protocol that's roughly the same
question.

Alissa: I don't have an opinion about the document structure. My question was
more about, are there any baseline security requirements for this protocol?

Mirja: Usually I don't care about the document structure but in this case
merging it into one document would give a stronger message that this isn't only
an optional extension but something that actually belongs to the protocol.

Martin: I understand your point, Mirja. My preference would be to keep them
separate; I think the WG has made the effort to work on the security solutions
for babel. It's not only HMAC, it's HMAC or DTLS, so we would have to choose
which one and we can't reasonably impose both. So I'm not sure it adds anything
to integrate one or the other solution in the document. It doesn't make it more
mandatory than having it in a separate document which updates the base spec.

Mirja: The difference is in one case you'd say this is a protocol which has
security features you can optionally choose to not use, if you have an
environment where it makes sense, where currently it's the other way around:
this is a protocol which doesn't have any security and you can optionally
choose to add some security. I wanted to figure out if other people have
thoughts here and that's it.

Eric: On a similar document about routing for ipv6 there were complaints
because HMAC was in the main document, to the other point.

Mirja: I'm not sure I remember the other document.

Suresh: It's not in here yet.

Mirja: So there were complaints in the WG?

Suresh: I think no matter what you do, someone's going to complain. That's my
point.

Mirja: I'm sure there are people who prefer one or the other but we here as the
IESG can make a statement if we want to.

Suresh: Just to clarify what Eric said, the document does have HMAC. The one
that's coming in. So it is included in the document, to Mirja's point.

Eric: The opposite end, people complained too.

Suresh: People can complain about either thing.

Mirja: I'm sure people will complain if we ask them to merge the documents,
because they might not have implemented this part. But that's the point, right,
we want to give a push on people who didn't implement it to think about it.

Barry: As I see it, the document does not have any 'should' about implementing
one of these. It says if both of them are applicable, you should use HMAC. But
it doesn't say you should use one of them. It's allowing a completely optional
choice of whether to implement the security or not. Is that really the way we
want it?

Roman: I have a Discuss on that language.

Mirja: I'd prefer saying this is part of the base protocol and you may not use
it if you have a scenario where you're sure you don't need it. That would be
what I was looking for.

Martin: Roman, did you get an answer to that Discuss point?

Roman: Negative, but in fairness, I dropped those all in very late last night.

Martin: Okay. I suggest we wait on the authors to respond to that specific
discuss point, which is valid, and could make a difference in what Mirja is
talking about, and see where it goes.

Mirja: Okay, thank you.

Alissa: On a more general point, it makes this experience, which we sort of
knew was coming because we looked at babel before when it was experimental, is
that it was set up to have this issue. If we allow things are that experimental
and they don't have security mechanisms built in, and we say 'that's okay,
because it's experimental!' And then inevitably people put them onto the
standards track, at which point you have this tension that we already designed
this thing and deployed it experimentally and now we'd have to change it in a
fairly significant way, and that makes people grumpy. Just something to think
about for the future, how to compare the standards for what is experimental vs.
what is on standards track, when you know the eventual goal is to move
something from experimental to standards track.

Mirja: But this was an independent submission, right? We could not have imposed
anything on the experimental one.

Alissa: The base protocol was? I thought only the...

Suresh: The whole thing was.

Alissa: My bad, sorry. I'm misremembering.

Mirja: We could have put more push onto the charter to make sure this was part
of the base protocol. Not sure if that would have made a big difference.

Alissa: Agreed.

Martin: I think we can move on.

Cindy: This will stay in IESG Evaluation and Revised ID Needed.

 o draft-ietf-ospf-xaf-te-06  - IETF stream
   OSPF Routing with Cross-Address Family Traffic Engineering Tunnels
   (Proposed Standard)
   Token: Martin Vigoureux

Cindy: There's an open Discuss; would you like to discuss that today?

Martin: No, I think it's fairly easy to resolve and I don't think the authors
will oppose. Alvaro can speak as author, and maybe already has replied.

Alvaro: Yes, I have. We're okay.

Cindy: Is this going to require a Revised ID?

Martin: Yes please.

 o draft-ietf-babel-rfc6126bis-12  - IETF stream
   The Babel Routing Protocol (Proposed Standard)
   Token: Martin Vigoureux

Cindy: We have a number of Discusses; would you like to discuss these today?

Martin: Again, happy to discuss, but the authors are really responsive. It's up
to the others to decide.

Suresh: One thing; I saw Julius's response and only put in a position this
morning so I'm not too picky on this. I think the backwards compatibility story
needs to be put in the draft. Julius said this has been discussed in the wg and
I have a feeling that the HMAC thing is because of the background compatibility
plan they have. The new protocol, you don't want to push new TLVs thats why I
have a feeling it won't fly well, but it's important to name this somewhere in
the draft so people have an understanding of how this is supposed to be another
version to babel. I understand why they didn't pick a different version now at
least, because I think you get backwards compatible and I think it has to be in
a draft rather than email.

Martin: I agree with you and I think it is a fair point. I will work with
Julius on this.

Suresh: Perfect, thanks.

Martin: This will require a Revised ID.

Martin: I have a small point to make on those other drafts. Maybe I will ask
the ADs who are not on the call, because I think some of them are missing a
position that's needed to progress even if all the discusses are cleared. So if
some of you haven't expressed a position, you have the time to do so I think.

Mirja: If there's a major revision maybe put it back as a returning item anyway.

Martin: Do you expect a major revision on the protocol?

Mirja: No, not on the protocol. But there might be quite some text changes
required in the end.

Martin: Okay, I'll check that.

 o draft-ietf-dnssd-push-23  - IETF stream
   DNS Push Notifications (Proposed Standard)
   Token: Eric Vyncke

Cindy: There are no active Discusses so unless there's an objection this is
approved.

Eric: Approved, but we got two reviews which are just comments after the last
revision, so Revised ID needed is most probably required. Just received a
request from the author. There's another draft in the independent submission
queue they want to put in the same cluster. How do I do this?

Alissa: This document would have to normatively reference that document.

Eric: The thing is that they want to document, as an informational draft, their
[?]

Warren: I think you can just ask the RFC editor to do that. You can send a note
to please make them sequential RFC numbers.

Eric: So an email, basically. Thank you.

 o draft-ietf-mpls-rfc8287-len-clarification-02  - IETF stream
   RFC8287 Sub-TLV Length Clarification (Proposed Standard)
   Token: Deborah Brungard

Cindy: The token here is for Deborah and she's not here. There are a couple of
Discusses; do we think these are going to require a Revised ID?

Alvaro: I'm pretty sure yes.

Cindy: Okay, we'll keep this in IESG Evaluation, Revised ID Needed.

 o draft-ietf-mmusic-sdp-uks-06  - IETF stream
   Unknown Key Share Attacks on uses of TLS with the Session
   Description Protocol (SDP) (Proposed Standard)
   Token: Adam Roach

Cindy: There are a couple of discusses for this document. Adam sent a message
saying his documents would go into Revised ID Needed. Any discuss holders want
to discuss anything now?

Roman: Negative.

Cindy: Okay, this will stay in IESG Evaluation and we'll move on.

 o draft-ietf-mmusic-ice-sip-sdp-37  - IETF stream
   Session Description Protocol (SDP) Offer/Answer procedures for
   Interactive Connectivity Establishment (ICE) (Proposed Standard)
   Token: Adam Roach

Cindy: Again, Adam is not here. There are a number of discusses and Adam did
say this would require a Revised ID. Any discuss holders want to discuss
anything now? I'll take that as a no and this will be in IESG Evaluation.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-6tisch-architecture-24  - IETF stream
   An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4
   (Informational)
   Token: Suresh Krishnan

Cindy: There are a couple of Discusses here; does anyone want to discuss them
today?

Suresh: Not really. Ben's Discuss hasn't gotten a response and it needs a
followup. I think we can follow up over email. For sure Revised ID Needed. One
thing I heard is this point about the shepherd writeup not being updated; I
just wanted to poll the IESG. If we change this after the document left the wg,
should we edit the update to say we changed it somewhere? There's no specific
thing to say what happens after the document leaves the wg process. Can I just
add some freeform text as the AD?

Mirja: I'd usually ping the shepherd and ask the shepherd to update it.

Ben: I think there have been a couple times when I edited the shepherd writeup
to change the responsible AD and fix a couple things.

Suresh: Okay, I'll just put an AD note in that we changed it from standards
track to informational.

 o draft-ietf-i2nsf-applicability-16  - IETF stream
   Applicability of Interfaces to Network Security Functions to
   Network-Based Security Services (Informational)
   Token: Roman Danyliw

Cindy: There is an open Discuss. Would you like to discuss it today?

Roman: I don't need to talk about the discuss. I've not had a lot of time to
cross-read some of the documents but I sensed from the group with all these
abstains, the unhappiness with the framing and how this is different than the
other existing drafts and how this isn't really an applicability statement. So
instead of trying to talk it out here, let me go back to the wg, pull some of
the history, and that will determine the course of action. You can jus mark it
AD Followup.

Mirja: Just to be sure, because you haven't seen many of these yet, usually
when we abstain we really mean we don't want to block publication, so you can
make a call there and publish. For me the more important part is to give the
message to the wg that the IESG doesn't think this is an extremely valuable
document to spend our time on.

Roman: Thanks Mirja, that makes sense. I'm still getting a sense of when to
have that conversation with the group. That's helpful.

 o draft-ietf-babel-applicability-09  - IETF stream
   Applicability of the Babel routing protocol (Informational)
   Token: Martin Vigoureux

Cindy: There are no open discusses on this document, so unless there's an
objection this is approved. Martin, just checking; does this need notes or is
it ready to go as-is?

Martin: I just want to check the comments a second time. Can you put it in AD
Followup and I'll get back to you?

Cindy: We can do Point Raised, Writeup Needed and you can let us know when it's
ready.

Ben: I had some specific comments I put in late last night so people probably
haven't seen it.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 NONE

3.4.2 Returning items

 o conflict-review-sheffer-tls-pinning-ticket-02
   IETF conflict review for draft-sheffer-tls-pinning-ticket
     draft-sheffer-tls-pinning-ticket-12
     TLS Server Identity Pinning with Tickets (ISE: Experimental)
   Token: Benjamin Kaduk

Cindy: There are no Discusses on this conflict review so unless there's an
objection this can go back to the ISE. Hearing none, we'll get this response
sent.

4. Working Group actions
4.1 WG creation
4.1.1 Proposed for IETF review

 NONE

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Mirja: The IAB has now officially closed the privsec and stackevo programs.
They will soon publish a statement on avoiding unintended harms of encryption
policies.

6. Management issues

6.1 [IANA #1147782] Designated experts for RFC 5613 (IANA)

Cindy: It looks like this was originally an OSPF document?

Alvaro: I guess that would be me. I'll take this on and find someone.

6.2 [IANA #1147895] Designated experts for RFC 5575 (IANA)

Alvaro: I sent a message a few minutes before the call to approve Sue Hares and
Robert Raszuk. If nobody objects I'd like to get them confirmed.

Cindy: Hearing no objection, so we'll send note to IANA.

6.3 Wiki for 2nd retreat agenda topics (Alissa Cooper)

Alissa: The question would be having a retreat October 8 and 9. There are a
number of issues that got put on the wiki. For my topics, other than the last
one, I think they're items that could go onto a face to face agenda but could
also be informal telechat or email discussions. Hopefully people had a chance
to review the wiki and the floor is open for thoughts about if it's worth it to
people.

Mirja: Looking at the topics, I think many of them are really touching the
Steering topic. How do we want to guide the community? Maybe it would make more
sense that instead of the traditional retreat that we do topics we didn't have
time for on calls, but if we set this up more to take time for this.

Alvaro: I agree with that. Many of the topics are in line with what I wanted to
do also, which is look at overall direction. Maybe pieces of that bigger thing.
I think it would be worth having the retreat.

Martin: These topics really want to get more than 15 minutes on an informal. So
yes for the retreat.

Roman: I don't think we need a joint with the IAB.

Warren: I agree. I don't think a joint with IAB would be harmful but it's
probably not necessary. I got the impression the IAB was not interested in
meeting. Did we ever figure out where it was going to be?

Alissa: We had talked about Europe. Depending on how people felt about going
forward I was going to propose possibly London, because we have two people
based in London or nearby and it's easy for other people to get to. We can
bikeshed on the location forever if we want to.

Alvaro: I have no problem with London but there's potentially a Quic meeting
that same week. It was proposed to me in the same place as the LACNIC meeting
in Panama City. For me it doesn't matter because I wasn't going to go anyway
but it might matter to some people.

Alissa: Mirja do you know the Quic schedule?

Mirja: I'm looking it up. Originally they were planning to do it in North
America.

Warren: Having been there before I would think it's not good for us to go to
Panama City because it's not easy to get in and out of.

Ben: Back on the question of, do we need the second retreat? Alissa had
mentioned many of these topics could be done over informals or email and I
wanted to toss out a counterproposal that over the next several informals we'll
try to focus on one of these topics. if that would be effective enough.

Warren: I think theres a very large difference in the type of discourse we have
on informal telechats vs in person. I also think we might be giving the wrong
impression if we decide we don't need to meet. I realize that shouldn't be our
primary concern but it's fairly clear there are some issues that need solving.
If we don't meet it might appear, even though it isn't, that we're avoiding
discussing them.

Wes: The IAB's position, as liaison to you, we only wanted to meet if it seemed
there were topics worthwhile discussing. Waiting for a complete list of topics
was more necessary before making that decision.

Suresh: If I recall correctly one reason we wanted to have the second retreat
is that we spent so much of the first one with the IAB and we wanted to discuss
bigger topics.

Alissa: There were multiple motivations mentioned. It started as team-building,
would it be good for us to have more time when we're not exhausted at an IETF
meeting, and reaffirm our working relationships. Some people were hoping for
interaction with IAB, and some thought the bigger picture would be useful. The
scheduling here is a major challenge; if we try to do all together, even in the
dates of the original Doodle we were going to be missing Suresh and Alvaro for
some of the days. And if we include the IAB, and now the Quic interim is
overlapping, we're not going to get everybody. That's another question; should
we do this even though we know we're going to be down some people, or does that
argue for not doing it?

Suresh: I'll see if I can make it. It depends on what day of the week.

Martin: In my opinion the bigger questions on the wiki might require yet
another retreat. I think they are important questions to try to answer and we
should define a work plan for addressing them in the next few months, whether
we do a retreat or not. A retreat itself will not be sufficient in my opinion.

Warren: One thing we always say about IETF meetings is part of it is the work
product and part of it is the hallway conversations. The team-building
terminology makes me twitch but I do think it's important. As much as I do not
want to get on another plane again, I think it probably is something worth
considering. How much would this cost?

Alissa: It cost hardly anything last time because we only paid for dinner. We
have budget to do something similar again. I will try to figure out what's
happening with the Quic interim. If they don't have a plan yet, I say we go
forward with a plan to secure a venue in London for Oct 8 and 9. Does 2 days
seem reasonable to people?

Alvaro: If Oct 9 and 10 works for everyone that would be better.

Mirja: Do you still want to try to colocate with IAB?

Alissa: I say we set dates, find a venue, and then invite the IAB if they want
to come. Whoever shows up, shows up.

Mirja: Should we quickly do another doodle and see if dates have changed a lot
for people?

Warren: Can we possibly add the location thing? A lot of people have issues
getting in and out of London.

Mirja: Brexit is planned for end of October, right? I can also check Stockholm.

Alvaro: I can't fly on the 7th but I can fly on the 8th.

Suresh: I'm highly tentative. I do have a conflicting thing that week. I'll try
to change it.

Ignas: 9th would be painful but doable. 10-11 fine.

6.4 [IANA #1148605] Designated experts for RFC 8552 (IANA)

Warren: The plan is to have n+1 redundancy. I have Paul Wouters now and also
will want to add Peter Koch later.

Barry: Why don't we officially approve Peter now, and if it doesn't work out,
then you can deal with it.

Warren: Anyone object to both Paul Wouters and Peter Koch?

Cindy: I'm hearing no objection to approving both, but if you're still waiting
to hear back from Peter, I'm assuming we should not send notice to IANA until
you give us the go-ahead.

Warren: Can you send a note approving Paul now, and when I hear back from Peter
we can let them know about him too?

Cindy: Okay. Thank you.

6.5 Response regarding meeting cadence (Alissa Cooper)

Alissa: I was trying to find someone who wanted to take an action to respond to
Eliot's draft. One of the things in it is about the meeting cadence and its
effect on remote participants. This could be a very simple response but I was
wondering if someone wanted to take this one on. The LLC is going to put
environmental impact policy as a discussion item for 2020.

Mirja: The only thing that came to mind is that we had a discussion about doing
a full interim virtual meeting but discussion stopped. Maybe we should think
about it again.

Ben: Someone had also proposed to do a large scale joint virtual interim for 5
or 10 wgs in a single area and have multiple parallel tracks during that, as a
smaller scale dry run for a full on virtual plenary.

Alissa: The manycouches thing sort of fizzled out due to lack of interest.

Mirja: In the sense of trying to improve our remote participation capabilities
and being prepared for an emergency case if we have to cancel a meeting last
minute or whatever, we could do some experiments.

Alvaro: Maybe being prepared for an emergency is a good thing. I didn't read
Eliot's draft but I saw discussion about it. If he's worried about fairness and
accessibility from remote people there are a few things, like incentivizing wgs
to meet between meetings, so everyone is remote. Without having to cancel a
whole meeting, which won't happen for another 3, 4, 5 years because of
contracting. I don't know what else we tell Eliot about it.

Eric: I'm not sure Eliot was expecting an answer from the IESG.

Alissa: I thought there was a direct request.

Ben: To the LLC board, yes.

Alissa: But most of this is not within the purview of the LLC. I guess that's a
fine answer too, that we await the piece of it thats reliant on the
environmental impact analysis.

Barry: I don't really think he's expecting a response from the IESG now, he's
asking the IESG, LLC, etc to talk about it and come up with a broader response
later.

Alissa: Okay; we can wait for the LLC bits to emerge.

Mirja: Whatever it is, it will be a gradual change.

6.6 Moving IETF LC discussions to a separate mailing list (Alexey Melnikov)

Alexey: There was a show of hands for this in Montreal and I was surprised how
many hands were up. Is this something we should just do, or get community
consensus first and then a next step?

Barry: I think this was a just do. I don't think we need further consensus from
the community.

Alexey: I'd be happy with that. But we do already have a mailing list for
announcements, so maybe we make it not just read-only so people can participate
there.

Alissa: That's something different. The announcement list is pretty important;
the Secretariat posts to that list, and it's quite useful to have that one
separate.

Alexey:  That's fine. I don't care really.

Barry: I think we make a mailing list called last-call@ietf.org and when we
send out LC announcements, we ask people to post there instead of ietf@. Right?

Alissa: One question is do we define some sort of boundary? Sometimes the LC
thread meanders until it gets to things that have nothing to do with the
document being discussed. There's no moderation of the point at which something
doesn't belong on the LC list anymore. Or is there moderation?

Alexey: I assume the sergeant at arms would still read it and redirect people
elsewhere.

Barry: We would have to ask them to do that.

Alexey: Or maybe find people just for this one.

Barry: We could also ask document shepherds to gently steer people back to the
IIETF list if they veer and see how that works.

Alissa: Either of those last two would be better, because the sergeant at arms
role is defined in an RFC. My other question is if we automatically sign up
people to it?

Alexey: No.

Warren: I also think no but it seems like a hard position to justify. The
entire point of the LC is that we want the whole IETF to see it.

Barry: But the entire IETF does not read the IETF list because it's too noisy.
If we publicize that there's this list that will be limited to last call
discussion, we'll get more people to subscribe to it. But I think we should
tell people to subscribe to it themselves.

Warren: Automatically signing up feels horrendously icky, but yes people have
unsubscribed from ietf@ because it's filled with drama. The problem is, if we
end up moving stuff to this new list and we don't get more people signing up,
we've done the community a large disservice.

Ben: Can we send the last call to ietf@ and the new list? And set the reply-to
to the LC list?

Warren: That's an idea. The problem is we're going to have peoples' posts
rejected because they're not a member.

Barry: This has to be behind the global whitelist.

Alissa: The way they work now is they get sent to ietf-announce and reply-to is
set to ietf@. Everybody who is subscribed to ietf-announce, which I presume is
more than ietf@, already sees the announcement. I'd suggest just changing the
reply-to. If we add ietf@ as a recipient, which it isn't now, it's only a
reply-to, then we haven't accomplished anything.

Ben: I propose we nominate Barry to come up with a concrete proposal.

Barry: Sure, I'm happy to do that.

Alexey: Thank you for that; that was more positive than I anticipated.

Cindy: We've got that action item down for Barry. That's the end of our
management items for today.

7. Any Other Business (WG News, New Proposals, etc.)

Barry: I have WG news. I mentioned merging avtcore, payload, and xrblock. I
announced to the wgs and nobody screamed, so I'm going to start working to
recharter avtcore. I wanted advice from you on what to do with this. Should I
just merge the payload and xrblock charter stuff into the avtcore charter and
put it on for rechartering?

Alissa: Sounds good.

Barry: Okay. I don't think it's going to be controversial with the IESG either
but I want to make sure the charter doesn't turn into a Frankenstein.

Warren: The mops BoF happened at the last meeting and I think it makes sense
for there to be a mops wg. Eric and I should talk about chartering such a
thing. I just wanted to make sure people are aware that mops does look like a
reasonable thing.

Alissa: I was going to ask about an update on the reorganizing of DNS work and
figuring out the disposition of some of those items.

Barry: I dropped it but I'll pick it up. I want to send a note to the IESG and
IAB about having a conference call. Maybe I'll put it on an informal telechat.
I'll set up something very soon.

Ben: There was also this thing from Pete about STD 1. Does anyone have more
information about what the status of that is?

Warren: I had a hard time parsing that. I don't understand it but it does seem
that something should happen.

Ben: There's some skew between the tools page and the RFC editor page, but it
should be to make sure that when someone tries to access STD 1 by that title,
they get some notice that it's somewhere else. I don't know if the best way to
do that is to add another RFC into STD 1 and have that be the only content, but
we already sort of obsoleted it.

Barry: I think what he was asking for as specifically a tombstone, that when
you look for STD 1 that this isn't the place to go for this information
anymore, that is.

Alissa: He was asking for something on rfc-editor.org. I don't think this is
our problem.

Sandy: As an FYI, we're talking to Heather about how we can handle this on our
side. I'd guess that information might get transported into the datatracker,
but we can talk to Henrik about that.

Ben: That answers the question I wanted to raise, so thank you.