Skip to main content

Narrative Minutes interim-2020-iesg-18 2020-08-13 14:00
narrative-minutes-interim-2020-iesg-18-202008131400-00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2020-08-13 14:00
Title Narrative Minutes interim-2020-iesg-18 2020-08-13 14:00
State (None)
Other versions plain text
Last updated 2024-02-23

narrative-minutes-interim-2020-iesg-18-202008131400-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2020-08-13 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Deborah Brungard (AT&T) / Routing Area
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke / F5 Networks Inc / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline / Loon LLC / Internet Area
Murray Kucherawy / Facebook / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Futurewei Technologies) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area
Robert Wilton / Cisco Systems / Operations and Management Area

REGRETS
---------------------------------
Jenny Bui (AMS) / IETF Secretariat
Jay Daley / IETF Executive Director
Wes Hardaker (USC/ISI) / IAB Liaison
Magnus Westerlund (Ericsson) / Transport Area

OBSERVERS
---------------------------------
John Bradley
Chris Box
Toerless Eckert
Timothy McSweeney
David Millman
Nat Sakimura

1.2 Bash the agenda

Amy: Does anyone have anything new to add to today's agenda?

Alissa: I'd like to have an executive session about these terminology threads.

1.3 Approval of the minutes of past telechats

Amy: Is there any objection to approving the minutes of July 9? Hearing no
objection there, so those are approved. Is there any objection to approving the
minutes of July 16? Hearing no objection to that either. We also have narrative
minutes for July 9 and July 16. Any objection to approving the narrative
minutes for July 9? Hearing no objection. Any objection to approving the
narrative minutes for July 16? Hearing no objection there either.

1.4 List of remaining action items from last telechat

     o Martin Vigoureux with Wes, and Alvaro to work on some
       mechanism to obtain wider or private feedback from people who are
       disenfranchised; anonymous flagging of offensive emails to inform
       leadership; more opportunities for private feedback.

Martin V: This is still ongoing. We pinged Pete on the ombudsteam again because
we didn't hear back from them.

     o Alvaro Retana and Barry Leiba, with Warren Kumari, Alexey Melnikov,
       Martin Vigoureux, and Roman Danyliw to work on more transparency in
       the Datatracker about how long each phase of doc process takes / New
       datatracker flag to indicate who has the ball: area directors,
       authors, or chairs.

Barry: That's still in progress. I'm going to have something on next week's
informal where we can talk about it.

Murray: Should we take off Alexey's name?

Barry: We left his name on because we thought he might have input, even though
he doesn't have the action item anymore.

Murray: Okay. Just curious.

     o Warren Kumari to work on acknowledging shepherds, directorate
       reviewers in a more standardized/formal way.

Warren: Still in progress.

     o Eric Vyncke to write up draft text on Special Interest
       Groups and send to the IESG for comment.

Eric V: Still in progress.

     o Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy to look at
       updating the I-D Checklist.

Murray: Please leave this in progress. Michelle, did you get the links I sent
about this?

Michelle: Yes, thank you very much. I'll look through those and add our
feedback.

     o Eric Vyncke (with Suresh Krishnan) to write a draft of an IoT
       Systems charter.

Eric V: I still need to talk to Suresh, so work in progress.

     o Alvaro Retana and Martin Vigoureux to draft text on guidance
       regarding the number of document authors on documents.

Alvaro: I'm going to say that's still in progress. The next one is in the same
boat.

     o Alvaro Retana, Rob Wilton, Alissa Cooper, and Martin Vigoureux to
       draft text on the framework for a long-term future plan for the
       IETF.

In progress.

     o Roman Danyliw to draft text for a request to the Tools Team to move
       BoF requests from the BoF Wiki to the Datatracker.

Roman: I talked to the tools team a little bit and anything is doable, because
it's a relatively easy mod to the datatracker. They have a couple of questions
about how we would envision the workflow. Right now when you have the wiki,
anyone with a Datatracker credential can create a marker for a BOF. If we move
it into the datatracker, would that be a similar expectation, that anyone in
the community can spin up something that's the equivalent of an earlier phase
of what we now call a BOF or a working group? We may want to think about that.
Additionally there were some questions about timing. I'll write that up.

Alissa: My initial reaction is we definitely don't want this creating new
objects in the Datatracker. This should be a web form that people can put a
bunch of information that spits out a table or something. Right?

Roman: I'd certainly lean that way as well personally but the way I remember us
talking about earlier was that we wanted something with a bit more formalism so
a BOF request would look very similar to an already approved BOF or an
in-flight but not approved WG, and what we were doing was creating an earlier
state for that and us being able to manage it in that workflow. But that
creates all sorts of access control things.

Mirja: It shouldn't create an object immediately because that means people can
jump on acronyms that we want to use later for WGs and block them, basically.
That's also something we don't want. We need a state before that.

Roman: Why don't I take this to the informal so we can keep moving? There are
still a lot of questions here. Let's mark it as in progress and move on for now.

     o Alvaro Retana, Warren Kumari, and Barry Leiba to draft clarifying
       text on Errata Best Practices.

Alvaro: We're also in progress.

Murray: Are errata supposed to be normative references in a document that
incorporates them?

Alvaro: I don't know. I've always thought maybe not, I've always thought
informative references.

Murray: I just saw that a document this week had that and I was curious.

Warren: I guess it sort of falls into the normal thing of 'is it required that
somebody reads this in order to understand it?' If the errata is something
that's really important someone knows about, that's one thing, or if it's just
more information or clarification. If you were on a desert island would you be
able to implement the protocol without it?

Murray: I guess that's maybe something this could cover. Since I had a question
about it I thought I'd mention it. Thanks.

     o Magnus Westerlund to find designated experts for the RDMA-CM Private
       Data Identifiers registry (RFC8797) [IANA #1173341].

Amy: Magnus could not be with us today so we will keep this in progress for him.

     o Ben Kaduk to find designated experts for RFC 8784 [IANA #1173591].

Ben: That has a management item that supersedes it.

     o Murray Kucherawy to find designated experts for content SDP
       Parameters, QoS Mechanism Tokens [IANA #1175036].

Amy: IANA added this not too long ago, so this is to alert you that you have
this action item.

Murray: Great. I should have something by the next formal telechat.

     o [All IESG] to follow up on the suggestion at IETF 108 to share a
       list of grammar checking tools with the community.

Alissa: I really wanted to find a stuckee for this so that it's someone's
responsibility to collate this list.

Eric V: Sounds easy and doable; put my name.

Alissa: Thank you.

     o Eric Vyncke to find designated experts for RFC 8801 [IANA #1175284].

Amy: This is provisionally done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-core-resource-directory-25  - IETF stream
   CoRE Resource Directory (Proposed Standard)
   Token: Barry Leiba

Amy: I have a number of Discusses; do we need to discuss any of those today?

Barry: We haven't heard from the authors yet, so we just need to let them
respond. Keep it in AD Followup.

Eric V: If you don't mind, Erik and I have a small comment. When we're
requesting a change or getting a new code point about ipv6 it would be nice to
involve 6man at some point in time. You can just send an email with the draft.

Barry: So that's basically to everybody. So how do we make that happen?

Eric V: Simply sending an email to the 6man list.

Barry: So all the WG chairs have to know to do that?

Eric V: There's a reason why I say it here, to the IESG level, so if you see
something. It's not mandatory, more like a courtesy and double checking.

Ben: This is a good match for some of the hot topics lists that some areas had
been making, like ART had one that Adam was driving and SEC has one. We've
tried to pass those out to our directorate review teams as a tool for them but
also to the broader IESG and also possibly all the WG chairs to get visibility
into these hot topics at an earlier stage of review.

Erik K: Is this list of items available somewhere?

Ben: It should be on a wiki page. I'll see if I can dig up the link.

Barry: It would be nice to pull out the items from those various lists that are
more global and have a concise list for ADs to reference. We'll do our best but
it's going to be difficult to remember all the different pieces.

Roman: I think this came up in 2019 and the way we did this was each area came
up with the list of hot topics that commonly come up in their area and we were
going to try to push it to our directorates and also broadcast it more broadly
in the community, for example if you don't want to get ensnared in common
security issues, check this list.
[https://trac.ietf.org/trac/iesg/wiki/ExpertTopics]

Barry: So for this document it's AD Followup.

 o draft-ietf-lamps-rfc7030est-clarify-10  - IETF stream
   Clarification of Enrollment over Secure Transport (EST): transfer
   encodings and ASN.1 (Proposed Standard)
   Token: Roman Danyliw

Amy: There are no Discusses in the tracker, so unless there's an objection it
looks like this one is approved. Hearing no objection to approving this
document. I have an IESG note in the tracker; is this one you want to go with
the announcement?

Roman: Can you mark this AD Followup? There are some things we need to clean up
based on the comments. Thanks for all the feedback with 2616 and changing the
errata, that was a helpful reminder.

Amy: This will go into Approved, Announcement to be sent, AD Followup and you
can let us know when it's ready to go.

 o draft-ietf-ippm-route-09  - IETF stream
   Advanced Unidirectional Route Assessment (AURA) (Proposed Standard)
   Token: Martin Duke

Amy: I have a Discuss for this document; do we need to discuss it today?

Martin D: No, it looks like the author is on it. This is Revised ID Needed.

 o draft-ietf-dhc-v6only-07  - IETF stream
   IPv6-Only-Preferred Option for DHCPv4 (Proposed Standard)
   Token: Eric Vyncke

Amy: There are no Discusses in the tracker, so unless there's an objection it
looks like this one is approved. Hearing no objection to approving this
document.

Eric V: We just need to wait for the approval of the in a couple of comments.

Amy: So it sounds like this will go into AD Followup.

Murray: I think they're waiting on an answer from me for some stuff; I'll get
to that today.

 o draft-ietf-mmusic-msrp-usage-data-channel-23  - IETF stream
   MSRP over Data Channels (Proposed Standard)
   Token: Murray Kucherawy

Amy: There are no Discusses in the tracker, so unless there's an objection it
looks like this one is approved. Hearing no objection to approving this
document.

Murray: Ship it.

Amy: There are no notes needed, is that correct?

Murray: Yes.

Amy: Great; we will get this announcement sent on Monday.

2.1.2 Returning items

 o draft-ietf-oauth-jwsreq-26  - IETF stream
   The OAuth 2.0 Authorization Framework: JWT Secured Authorization
   Request (JAR) (Proposed Standard)
   Token: Roman Danyliw

Amy: There are no Discusses in the tracker, so unless there's an objection it
looks like this one is approved and ready to go.

Michelle: Not quite yet. It looks like since the last time this was Last Called
three years ago they've added a bunch of IANA actions that weren't there
before. We have some expert reviews out and we're hoping to get those back so
we can continue.

Roman: We'll hold the document for all that. There are also some good edits to
make based on this subsequent review. I want to reiterate to everyone, thank
you for your iterative feedback to get this ready to finally publish. It's been
a long way.

Amy: So this is Approved, Announcement to be Sent, AD Followup until we're
ready to go.

Murray: I noticed the directorate reviews for this one date back to the first
time it came up to the IESG and there have been 15 revisions since then. Do we
have any common practice or guidance around circling this back around to at
least some of the directorates before we ballot on it again?

Roman: We might want to have a general practice. The reason I felt comfortable
with this is that there was one particular issue that Ben was working with the
team on iterating, so that was the primary change that went into this document.
It just took a long time to get us there.

Murray: I could have asked the question on the list, I probably shouldn't have
interrupted us here. It just came up because that happened and there was
another document on this telechat where the shepherd writeup was terribly stale
and someone else brought that up. I'm just wondering if for things that are
returning we should revisit some of these things. I'll take it to the list.

Ben: The current practice is just at the discretion of the shepherding AD. I
don't think we have a more formal policy or anything.

 o draft-ietf-anima-autonomic-control-plane-28  - IETF stream
   An Autonomic Control Plane (ACP) (Proposed Standard)
   Token: Eric Vyncke

Amy: I have a number of Discusses here. Eric, do we need to discuss those?

Eric V: It would be cool for me and I noticed Toerless the anima wg chair is
also on the call. It would be nice to have a short discussion. Roman, [name
unclear] suggested some text around your Discuss point. Is the proposed text ok
for you? If you've had time to read it.

Roman: I did not see Brian's response. He proposed a more general approach
about some of the references to put in and I believe I responded to him that
those are good. I had one or two more things to put in that text. I think that
would resolve that last Discuss I'm holding.

Eric V: Okay. That would be good. Ben, if you don't mind, you have a good point
about this downgrade attack. I'm unsure about potential action by the authors.
Should we add the text in security considerations? Your comments are quite
sensible and your explanation text is quite clear, so it would be nice if the
authors agree we can just copy paste your text into the considerations.

Ben: That would likely be reasonable. The main point I had as a Discuss level
there was just to make sure my understanding and summary was accurate. I don't
think there's a discuss level we need to make a change to the document if my
understanding is actually correct there. It would be reasonable to take
something like that text and put it in the security considerations but I was
not trying to hold a Discuss and say that we have to add it to the security
considerations.

Eric V: I get your point about the certificate check based on the prefix, which
I think makes sense and the authors will be happy to change it. Barry, I agree
the text sometimes could be clearer and is ambiguous at some points and we can
fix. Your point about having only two code points and creating an IANA registry
and handwaving about extensibility later is another good point. We'll try a
change with the authors and see.

Barry: On the point about the namespace, the idea was to have the discussion.
It may be that the result of the discussion is that it's fine the way it is. I
don't mean to insist on a change, I mean to have the discussion.

Eric V: Perfect. And the Discuss from the other Erik, [unintelligible] they are
previously isolated so shame on me on this one. That's all for my discussion,
unless somebody else wants to say anything.

Amy: It sounds like this will need a revision?

Eric V: Yes, Revised ID is obviously required.

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

 NONE

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-allan-5g-fmc-encapsulation-05  - IETF stream
   5G Wireless Wireline Convergence User Plane Encapsulation (5WE)
   (Informational)
   Token: Erik Kline

Amy: I have a few Discusses here; do we need to discuss those today?

Erik K: We could, or we could try to take it on the list. I have not fully
digested everyone's Discuss feedback; thank you for all the reviews. I'm not
sure what the best way forward is. There was a mention of seeking an EBF
liaison statement, there were some IPR concerns raised. Splitting the document
into two documents, an independent submission and a separate standards track
for the IANA registry. I'm not sure what the best way forward is. If there's
time, we can discuss it; if not, we can follow up on the list.

Alissa: From my perspective I think an additional Last Call that explicitly
states the IPR question the way you normally would in a working group would be
sufficient. I don't think you need a liaison statement. There's been a bunch of
people chiming in since the ballots started flowing in so I think that's a good
demonstration of support for the document.

Alvaro: From my point of view I'd like to hear from you whether you think
there's IETF consensus or not and why. That's really the question I'm asking
there. I may not agree in the end, or we may both agree, but let's start there.
We don't have to do it here, we can do it on email, but if you think there's
consensus we can move forward somehow.

Erik K: I heard no arguments against it. The literal handful of folks who still
care about PPPoE and this sort of thing are in support of it. I'm going to
guess in terms of measurement scales the activity is maybe too low. I don't
know what you can say when... [trails off]

Alvaro: Sometimes when you look at WGs there's also very low activity. When I
first looked at this I didn't see anything except directorate reviews. After
balloting other people came out saying they support it, which is a good thing.
I think this was probably not the type of document that 8789 or whatever it is
had in mind. It was probably something more contentious than this. It's
probably too bad this is the first test. This is not the type of document
anyone wants to die for. From my POV I'm prepared. I'm just asking the
question; if you think there's consensus we can move forward. I'll think about
it and clear my Discuss, I might abstain in the end, but we should be able to
move forward. I just want to say one other thing, not for you but in general.
Now that we're starting to get these types of documents [like] 8789 from
gendispatch, changing IETF process, maybe we need to be a little more vigilant
to that. They probably don't get as much discussion or exposure as many of the
other work does. There was a lot more discussion on the list about 8789 about
this draft but the number of people participating in the discussion is
relatively small compared to the whole IETF and it affects the whole IETF. So
just a soapbox rant here.

Warren: I think this is one of our standard problems in the IETF, is that our
definition of consensus by design is very vague. Sometimes it does kind of come
down to 'nobody is actively objecting to the document and we think there's
value.' Which is different to our normal discussion and view of consensus. When
we were doing 8789 I was fairly uncomfortable with it. In some cases this falls
into the HBU type thing where there is some value, 99.9999% of the IETF doesn't
care, but one or two people think it's worth having.

Barry: 8789 was different. I don't think that's really the issue here. 8789 was
addressing that it was possible in the past to AD sponsor a document that was
informational and never do a Last Call on it. That's all 8789 is addressing,
that we need to record IETF consensus by having a Last Call on any document
that comes through the IETF stream. That's not an issue for this. The general
issue is how do we decide that a document with two reviews has IETF consensus?
That's a little more of challenge. This came up some years ago when I tried to
hold a discuss on a document because as far as I could tell only two people
besides the authors reviewed it, and in the end we let the document through. We
need to have a conversation as an IESG at some point about how to make that
judgment and what to bring back to the community for their opinion, because I
think the community really needs to decide the answer to this question in
general.

Warren: You're right about what 8789 says. I was using it as a shorthand for
the whole consensus question, which used to take an almost infinite amount of
time, like can you do an informational document that has No marked in the
datatracker.

Ben: I think that is the key point, that the process for assessing consensus is
fairly vaguely defined and largely subjective. At some point it's a judgment
call based on the WG chair or responsible AD as to what the consensus is and
whether there is consensus. One thing that's useful to have in mind at least
for me as we think about that is if somebody who was knowledgeable in the IETF
were to take a look would there be anything surprising in there? We can have
already established consensus on general ideas and topics through previous
documents and precedent and if everything in this document in question is
consistent with that and it's an incremental addition or boring changes,
there's more of a presumption that there's consensus. If there's completely new
stuff then it's harder to say. That's just something to keep in mind but I tend
to agree with Barry that we need to be keeping with what the community wants.
We can't keep winging it forever.

Deborah: While we all may feel confident in this group of authors and people
speaking up on the list, it's really a misrepresentation for a couple of people
to come to IETF, do a document, and claim it's needed by another SDO. [muffled]
this is an extension request by the BBF. A year or two ago we had that BCAUSE
BOF and they were so against it because the document was from a group of
authors and they said it was not with BBF and we had to liaison with BBF. It's
why we did the whole change control process document on liaison-ing. It was
exactly that to avoid that we have groups of authors coming and claiming to
have the hats on of another SDO and it just meets the needs of the other SDO.
They stand on different sides of the fence. When this group of authors was
against the BCAUSE work, they wanted to liaison. Now they're on the other side
of the fence and they're saying we don't need to liaison, we represent BBF. You
can't have it both ways. And the BBF meets in two weeks so I don't see any
difficulty why they can't get a liaison to tell us what meets their needs.

Barry: As I said in my response to Donald, or I didn't say this part, the
general thing about liaison relationships is that we prefer cross-participation
to liaison statements. I'd like not to change that, I don't want us to be
starting to insist on liaison statements for all communication between SDOs.

Deborah: He totally misrepresented that, Barry. That's actually in these
documents, it's in the 7775 and it's in our document on change control. It's in
the documents. You need to have a group of authors, according to IETF process,
on a document. That document, by the time it reaches maturity, needs to be
liaisoned back to the group. You can't just have those people that are on the
author team say it meets the needs. We have run into so many problems with this
in the past. While this looks very simple and we trust these people that are
the lead people, it's just the process how we have said to deal with other
SDOs. If they want to keep that sentence there about the Broadband Forum,
making it look like it meets the Broadband Forum's outcome, we've got to
liaison.

Alissa: I think that's a fair argument. I was really concerned about hanging
this up for a lot longer but if the impression is that they can send us a
liaison statement in two weeks that solidifies it, and we might have to re-Last
Call the document anyway, I think we can have all of the needs met.

Erik K: We can certainly do that.

Deborah: We can say let's have a liaison to BBF see what's in this document, we
understand it's a work in progress, does it meet the needs, or we can just
expect David Sinicrope to go to BBF, which he does, to say they need to
liaison. I have no idea where this document is in all this stuff but Donald
indicated it's one of the documents being referred to.

Warren: I may have lost the thread somewhere. Looking in the document, I don't
see anything saying that this is specifically requested by BBF. What it says is
that it acknowledges some comprehensive discussions in BBF.

Alissa: He said it on the list.

Warren: Thank you. That's where I lost the thread.

Deborah: If this was just by a couple of individuals and had nothing to do with
BBF, then probably it should just go independent stream because we'll probably
have other vendors coming and requesting a code point. We could even have BBF
or 3GPP come in with a request for a code point.

Warren: I'm not disagreeing. I just wanted to make sure I understood what the
actual status was. Having a liaison seems useful. I do think that it would
often be nice if we had a slightly easier, less formal way of doing liaison
type stuff without doing a liaison statement. I realize it's not hugely onerous
but something like we kind of have with the IEEE Yangsters, which is not a
great example either, but something similar where we can say we want to get a
temperature of the room, does this sound vaguely right?

Erik K: Do we need to issue a liaison statement to request a liaison statement,
or can we just ask the authors to bring it up with the BBF and have them send
us one?

Deborah: We can do it either way. I'd just contact Sinicrope and ask what he
wants to do.

Warren: And also what exactly it is we want the statement to say. Largely, do
you think this is something that's useful to you?

Deborah: And does it overlap with work ongoing? We have no idea. Maybe like
with the BCAUSE bof, they have other stuff going on.

Mirja: I'm all into double checking to make sure, because that's what we have
liaisons for, but us requiring the other SDO to send a liaison in order to
process an action is something we usually don't do. If we want to do this step
we should carefully think about it.

Erik: Can you repeat that last statement?

Mirja: It's usually not us, the IETF, who is requiring other SDOs to send a
liaison statement in order for us to do actions. That's a process other SDOs do
often, but we don't usually do it. If we want to do it we should consider it
carefully. What we should do for sure is we shouldn't publish a document where
we don't think it's the right thing to do. We have to use our own procedures to
figure out that the document is valuable to publish in the RFC series and we
need to make sure that it has the quality and review that it needs to be
published here, and we should also coordinate with the other SDO to figure out
that there are no conflicts, but that coordination is why we have a liaison
relationship and it doesn't need to be formally via a liaison statement.

Erik K: I heard if they're meeting in two weeks, it might be possible, I'll
talk to the authors to see if they'll send us a liaison statement if that's
what they want. I heard Alissa say maybe a second Last Call with an explicit
IPR call-out, so that's another four weeks.

Alissa: I think two weeks is okay. You have some flexibility if time is of the
essence; I don't know if it is.

Erik K: I don't know if that's choosable in the Datatracker?

Alissa: Just tell the secretariat what you want and they can do it for you.

Erik K: Okay. And then there was a question of whether or not it should be
expert review or specification required. The IANA registry for these PPPoE
version numbers.

Warren: Would you mind reminding me how big the code space is and how used it
is?

Erik K: It has so few values, a single value, that there was never even a
registry for it.

Eric V: Four bits.

Warren: In that case it seems like spec required might be--

Barry: The difference between expert review and specification required is not
relevant to that aspect. Either way an expert reviews it. The question is just
whether it's important to have a specification explaining how the extension
works.

Alissa: It just seemed like the kind of thing that would be super useful, in
the way that this document itself is, they didn't just go off and do it without
writing a spec.

Erik K: It seems fair to ask them to point to a TR number. Any other things?
I'll take the rest offline, then. Thank you.

Amy: It sounds like this is going to require a Revised ID?

Erik K: At minimum.

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 o status-change-comcast-congestion-management-rfc6057-to-historic-01  - IETF
 stream
   Change the status of Comcast Congestion Management (RFC 6057) to
   historic (None)
   Token: Martin Duke

Amy: There are no Discusses, so unless there's an objection now this status
change is approved.

Martin D: Ship it.

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-cooley-cnsa-dtls-tls-profile-00
   IETF conflict review for draft-cooley-cnsa-dtls-tls-profile
     draft-cooley-cnsa-dtls-tls-profile-04
     Commercial National Security Algorithm (CNSA) Suite Profile for
   TLS and DTLS 1.2 and 1.3 (ISE: Informational)
   Token: Benjamin Kaduk

Amy: There are no Discusses in the tracker, so unless there's an objection now
this conflict review can go back to the ISE with the writeup currently in the
tracker. Hearing no objection, so we will send that out.

 o conflict-review-moriarty-caris2-00
   IETF conflict review for draft-moriarty-caris2
     draft-moriarty-caris2-03
     Coordinating Attack Response at Internet Scale 2 (CARIS2)
   Workshop Report (ISE: Informational)
   Token: Roman Danyliw

Amy: There are no Discusses in the tracker, so unless there's an objection now
this conflict review can go back to the ISE with the writeup currently in the
tracker. I'm hearing no objection so this will be sent.

 o conflict-review-irtf-cfrg-randomness-improvements-00
   IETF conflict review for draft-irtf-cfrg-randomness-improvements
     draft-irtf-cfrg-randomness-improvements-13
     Randomness Improvements for Security Protocols (IRTF:
   Informational)
   Token: Roman Danyliw

Amy: There are no Discusses in the tracker, so unless there's an objection now
this conflict review can go back to the IRSG with the writeup currently in the
tracker. Hearing no objection so we'll get that sent.

3.4.2 Returning items

 NONE

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

 o Network File System Version 4 (nfsv4)

Amy: I have no blocking comments for this recharter, so unless there's an
objection now this is approved and we will send out the WG action recharter
announcement. Hearing no objection; since Magnus is not here we'll check with
him to make sure he's okay before the message goes out. That will happen
shortly, whenever he is back from vacation.

5. IAB news we can use

Alvaro: The only thing I want to mention is that yesterday the IAB approved the
EDM program. Tommy had been on the call a few weeks ago to talk about that. Now
they're figuring out the logistical details, so keep an eye out for that.

6. Management issues

6.1 IKEv2 Parameters DE updates (Ben Kaduk)

Amy: We want to add an expert to complete the set for him?

Ben: Right now there are a bunch of registries on that page and almost all of
them have a single expert. The idea is to have two experts for every registry
on that page, so it's adding one expert to one registry and one expert to all
of the others.

Amy: Any objection to adding the expert for all of these registries? Hearing no
objection, so that is approved and we will send official note to IANA.

6.2 IESG Positions - Desired Expertise descriptions (Martin Vigoureux)

Martin V: That was really a trigger to all of you to make sure you take the
time to review the descriptions. Some of you have already done so, so that's
good. For the specific AD positions, there are 2 elements that might require
the attention of everyone. One is the generic description, although I don't
think there's any real need to change. One more specifically pointed toward
you, Alissa, on the IETF chair position since it hasn't been updated since you
took the job.

Alissa: I updated it.

Martin V: Okay, that's great. Thank you very much. I know Warren did the OPS
side, and on RTG we did a couple of updates. So everyone, please take a look at
yours and update it.

Eric V: Eric and Erik have completed theirs as well.

Martin V: Perfect. One question I had was on the generic description. We assume
that ADs meet physically and develop a working relationship. Should we change
anything with regard to the generic description considering the possible
continuation of our virtual meetings, or not?

Barry: How would that affect the Nomcom's decisions?

Martin V: I don't think it is subject to affect the Nomcom decision, however it
is subject to affect the way we work together.

Barry: It could affect whether someone was willing to take the position or not.

Martin V: I'm not promoting one way or another.

Warren: Doesn't this change because some subset of people haven't been willing
to run because they don't think they can travel to meetings because of funding
or whatever? Or have I lost track again?

Martin V: It wasn't really related to funding or anything, it was more related
to building relationship amongst the ADs.

Warren: I've heard of at least one candidate who is unable to run for a
position because they will never be able to travel to meetings, partly for
health and partly for money.

Eric V: I agree Warren, when I was Nomcom liaison and had access to all the
feedback, at least one potential AD declined the nomination because of travel
issues. We need to keep this sentence there; who knows when we will meet again.
It needs to be there.

Alvaro: What is the sentence we're talking about? The one about potential
travel?

Martin V: That's for Eric to answer.

Eric V: The sentence about physically meeting.

Martin V: There are two references to travel; one which says that because of
the time and travel commitments, we imply travel commitments.

Alissa: I think we should keep that, but I think your point is fair, Martin,
that people need to be comfortable joining a leadership group that might not
meet in person. I think it's fine to add a little bit of text about that.

Martin V: That was really my point, in the domain of virtual teams. That's
substantially different from occasionally physical meeting.

Barry: The question is still open: are we open to having an AD who participates
only remotely and does not come to meetings? Do we want to say that's a
possibility?

Warren: I'd thought it was always a possibility, just that it was heavily
frowned upon/discouraged. If for example we could only find an ART person who
refuses to leave their country, that would still be okay, but it's worth
considering.

Barry: The only thing I recall in history is someone whose health was such that
there were several meetings in a row they couldn't come to and we worked it out
fine. We could use that as a precedent to say, don't rule out somebody just
because they can't come to meetings.

Warren: I think that should be right. The Nomcom is a bright set of folk who
are humans and consider things. If our choice is between having someone who is
truly awful who can show up, or having someone who is awesome but can never
possibly show up, it's worth letting the Nomcom make a decision.

Alvaro: Is there anything in the current description that would preclude that,
or is it just that we all assume, including the Nomcom, that we have to travel
everywhere?

Barry: I think it's the latter. If we want the Nomcom to consider people who
can't travel, we should say that explicitly if that's what we want.

Warren: There is also something to be said for people who have already
participated in the IESG and who are unable to travel. Someone who is
relatively known in the community, has already served on the IESG, and couldn't
travel, that would probably be more okay than if someone we've never interacted
with were to be appointed.

Roman: That's really subjective.

Warren: Yes. But this is basically a job description, then we interview someone
for a job and we hire them or not. All of that is wildly subjective.

Alissa: But our part of that is just the description. We should leave the rest
to the people whose responsibility it is. We just have to tell people what this
job entails, and under normal circumstances it entails travel to meetings
because that's where you get all the work done.

Warren: Okay; that's all fair.

Martin V: I'm not sure, Alissa, if I understood. Should we try to add a few
words about physical vs virtual or we should leave that out of the description
and consider that part of the decision process of the Nomcom?

Alissa: I think your point is a good one, which is to point out the possibility
that this person will be joining a team that for the foreseeable future only
meets online, and they need to be comfortable with that. This is kind of
obvious, to anybody living on Earth, but otherwise I think the text about
travel doesn't need to change.

Martin V: Okay. I'll try to draft a couple of sentences along those lines and
submit them to you all. I still have a week or so. The Nomcom plans on sending
the call for nominations on August 25, so we have a little time. I need to
explain the IESG in detail to the Nomcom. The descriptions are fine enough but
they need to be absolutely finalized by the 24th. That's it for me. Thank you
very much for your feedback.

6.3 [IANA #1175036] Designated experts for content SDP Parameters, QoS
Mechanism Tokens (IANA)

Amy: This is a reminder that this action item has been assigned to Murray.

6.4 [IANA #1173341] Designated experts for the RDMA-CM Private Data Identifiers
registry (RFC8797) (Magnus Westerlund)

Amy: Magnus has identified a designated expert for this registry. Is there any
objection to approving Chuck Lever? Hearing no objection so we'll get official
note sent to IANA.

6.5 Designated Expert listing for URI.ARPA (Alissa Cooper)

Alissa: Basically, this comes from the discussion around RFC 3172 and it was
pointed out that the document presumes the IESG is the designated expert but
the registry page doesn't actually list that. The question was whether we could
just ask IANA to update the registry page to make that clear.

Barry: I'm confused because we have a designated expert, right? And the IESG is
always the backup, the IESG can approve any registration.

Alissa: I don't think we have a designated expert for this.

Barry: I thought Ted Hardie was.

Michelle: Just to clarify, which specific registry would this be adding an
expert for?

Alissa: This was Ted's suggestion and I've lost the thread.

Michelle: Graham is the expert for the URI schemes registry.

Alissa: But not for ARPA.

Michelle: On the protocols listing page, we don't have a registry per se for
URI.ARPA because it's a second level zone. So that's why I was trying to figure
out where we would be adding this.

Alissa: Could you put it on the ARPA zone management page?

Michelle: Potentially.

Alissa: It's just another place to document what's already in the document, but
that was the suggestion.

Barry: The IESG approves registrations in URI.ARPA?

Alissa: Yeah, exactly.

Ben: It seems like it would look weird to only say something about URI.ARPA on
the ARPA zone management page, at least the way it's currently structured.

Alissa: If people are generally supportive maybe we can work on crafting
exactly the precise text and bring that back.

Barry: I think that's better. Let's look at this in more detail and figure out
exactly what we want to do. Maybe it should be part of the 3405 update rather
than doing it as a management item.

Michelle: I'll go back and find out what possibilities we have for where we can
add information to the ARPA page.

Barry: Whatever it is, we should do it right rather than throwing out a
management item and being too quick about it.

Alissa: Sounds like a plan. Thank you.

Amy: So it sounds like this is going to come back?

Alissa: Yeah. I'll bring it back when it's ready. Or it might go into the
document and not come back.

6.6 [IANA #1175284] Designated experts for RFC 8801 (IANA)

Amy: Two experts have been named for this registry. Any objection to approving
Tommy Pauly and David Schinazi? Hearing no objection, so we will send official
note to IANA.

6.7 [IANA #1175507] Management Item: Acceptance of media type registration from
standards organization OPC Foundation (IANA)

Barry: I looked into the organization, it looks legitimate, and Alexey as media
type expert recommended we accept them. I think we should.

Amy: Any objection?

Alissa: Seems like a legitimate standards organization.

Amy: Okay, this is approved and we'll send note to IANA.

6.8 IETF Datatracker and number of positions required to pass a Standards Track
Document (Secretariat)

Amy: We thought that when we went from 15 to 14 IESG members that the algorithm
in the datatracker would round down to 9 instead of up to 10. The datatracker
actually does round up to 10. So for standards track documents we would need
ten yes or no objection positions to pass. If you don't want to change that we
don't have to, but if you want to change that we can. What would you prefer?

Barry: Rounding up is the customary thing that happens. If the US Senate with
100 members needs a 2/3 majority that becomes 67, not 66. That seems like the
right answer. If we want to make it nine we can make it nine, but I think ten
is not an issue.

Alissa: Does anybody know what it was when there were previously 14 members on
the IESG?

Amy: I think it was nine but that was a really long time ago and the
Datatracker was very different.

Warren: How often do we run into issues where this is actually important? It
doesn't seem like that often so I think we should keep it at ten.

Barry: It's not often that it's a long term problem but you see it happening
when ADs turn over and we need more reviews. It happens quite often but it's
not generally a problem. It would only be a problem if we had four or five
abstentions and that happens very rarely.

Warren: I think ten.

Roman: I say ten.

Warren: Does anybody strongly object to ten?

Amy: Great, so no change to the datatracker needed and we'll keep 10 as the
target number for minimum yes and no objection. Thank you all for talking it
out with us.

6.9 IESG Retreat (Alissa Cooper)

Alissa: I asked this on the list and didn't get any response so I just wanted
to double check. Last time we did Tuesday and Thursday, three hour slot with a
break in the middle, from 1400-1700 UTC. I was wondering if people wanted to
follow that format or do something else.

Roman: That looks great. Let's do that.

Mirja: Do we have topics for six hours?

Alissa: I'm sure we could talk about how to form consensus for six hours. 
[laughter]  We can do some social time too. What we did last time was block off
all the time and if we don't use it all, you can have time back. Let's put it
in the calendar and create the page to collect topics and see what we get.

Amy: We will block out that time for the retreat.

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

8. Executive Session