Narrative Minutes interim-2021-iesg-04 2021-02-04 15:00
narrative-minutes-interim-2021-iesg-04-202102041500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2021-02-04 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
Jenny Bui (AMS) / IETF Secretariat
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
Lars Eggert (NetApp) / incoming IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline (Google) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area
Martin Vigoureux (Nokia) / Routing 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
Francesca Palombini (Ericsson) / incoming Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / incoming Transport Area
John Scudder (Juniper) / incoming Routing Area
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Wes Hardaker (USC/ISI) / IAB Liaison

OBSERVERS
---------------------------------
Colin Perkins
Rene Struik
Greg Wood

1.2 Bash the agenda

Amy: Does anyone want to add anything new to today's agenda? Are there any
other changes? We will be taking the agenda conflict resolution at the end of
the call.

Warren: Myself and a couple of other people may need to run off before the end
because of [another meeting].

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the January 21
teleconference being approved? I'm hearing no objection. We also have final
narrative minutes from January 21; are there any objection to those being
approved? Hearing no objection there either.

1.4 List of remaining action items from last telechat

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

Alvaro: This is still very close. I don't think that has changed.

Amy: We'll keep this in progress for Murray.

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

Alvaro: We haven't done much here but I did take up an action to set up a call,
so next time we can report something.

     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 dug up the previous conversation I had with the tools team and there
are some decision points they need from us to better scope how to move forward
with this. If you could respond to the questions in your email that will help
me come up with what that draft text will look like.

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

Barry: This is making progress. We've got something that needs a little more
editing before passing on to the group as a whole. One thing we discussed was
asking the RPC folks to handle simple editorial errata that's obvious and pass
on to us any errata that's not obvious, so they handle typos and obvious
grammar errors, things like that. I ran this by Sandy and she thinks that's
fine. Before we move any further with that I want to ask the IESG if anyone
thinks that's a bad idea.  I didn't think so. In progress.

     o Martin Vigoureux and Alvaro Retana to work with Jay Daley on the
       process for using EthicsPoint incident management software as
       the mechanism of private feedback and anonymous reporting.

Martin V: We are nearly done. Still in progress but we're close to closing this.

     o Erik Kline to find designated Experts for RFC  8915 [IANA #1179647].

Erik K: Still in progress. I have one person and I need to find a second.

Amy: You can approve them separately. If you have one person who's willing to
take it on you can continue to look and approve one person, if you wanted to do
it that way.

Erik K: Okay. Maybe I'll check with them and add an item for the next telechat.
Thanks.

     o Warren Kumari, Deborah Brungard, Stephen Farrell, and Jay Daley to
       investigate ways to recruit, recognize, and retain volunteers in the
       IETF.

Warren: This is making good progress. We had a long meeting with the person
from RIPE who used to do community building to discuss. We will continue to
report as time goes by.

     o Erik Kline to find designated experts for RFC 8928 [IANA #1183445].

Erik K: Still in progress.

     o Ben Kaduk to find designated experts for RFC 8935 [IANA #1184035].
     o Ben Kaduk to find designated experts for RFC 8879 [IANA #1184206].

Ben: These are both in progress. I'm waiting to hear back.

     o Rob Wilton to find designated experts for RFC 8819 [IANA #1186621]

Rob: The authors all agree to be designated experts for this.

Amy: Did you want to put on a management item to approve them as the experts
for IANA?

Rob: Yes please.

     o Robert Wilton, Alissa Cooper, Alvaro Retana, and Warren Kumari to
       report back to the IESG on the impact of COVID-19 to the IETF in
       January 2021.

Alissa: Last time we talked about this a few people wanted further years back
for comparison. We're still gathering that data; we need a little bit more data
to produce the new charts. So this is in progress.

     o Murray Kucherawy to find designated experts for RFC 8839 [IANA
       #1187517].

In progress.

     o Barry Leiba to find designated experts for RFC 8798 [IANA #1187946]

Barry: Complete.

     o Murray Kucherawy to find designated experts for RFC 8855 [IANA
       #1187734].

In progress.

     o Barry Leiba to find designated experts for RFC 8847 [IANA #1187672].

Barry: Complete.

EricV: Can you add an action item for me to write draft text to propose to WG
chairs to contact directorates? It's from the discussion at the informal last
week.

Amy: This is for the ipv6?

Eric V: It's applicable to all directorates; people are afraid to contact them.

Amy: Thank you, Eric.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-dime-group-signaling-13  - IETF stream
   Diameter Group Signaling (Proposed Standard)
   Token: Robert Wilton

Amy: I have no Discusses in the tracker, so unless there's an objection now it
looks like this is approved.

Rob: I think we'll need a Revised ID here. I'd like to thank everyone for their
reviews; apologies that this document was a bit rough in places. This is an old
document that's been carried through, so I think it was just the change of
hands. Apologies for that, it makes it slightly harder to review.

Amy: Thanks; this will go into Approved, Announcement to be Sent, Revised ID
Needed.

 o draft-ietf-extra-imap4rev2-27  - IETF stream
   Internet Message Access Protocol (IMAP) - Version 4rev2 (Proposed
   Standard)
   Token: Murray Kucherawy

Amy: I have no Discusses in the tracker, so unless there's an objection now it
looks like this is approved.

Murray: Can you please put it in AD Followup? There's been a lot of feedback on
the ballot positions and I just want to make sure they've all been addressed
before it goes.

Barry: Make it Revised ID; it's definitely going to need one.

Amy: Thanks; this will go into Approved, Announcement to be Sent, Revised ID
Needed. I do see that we have quite a number of downrefs; are all of those
appropriate to put in the downref registry?

Murray: I seem to remember going through that list once and the answer being
yes.

Amy: Great. Once you approve that for publication we'll add that list of RFCs
that are Informational and Experimental to the downref registry.

Barry: You had asked what should go in the downref registry. Change that to
only RFCs 2180 and 4549 should go in the downref registry and the others should
not. What I wanted to remind all of the ADs is just because something was Last
Called as a downref doesn't mean it should go in the downref registry. We
should really look at whether the documents are likely to be referenced
repeatedly and whether they are downrefs that should be recorded as expected.
In this case, the majority of these, there are seven others which are either
not going to be referenced again or if they are, we should call them out.

Murray: I overlooked it because I thought the reason we do downref stuff is
just so we officially record that a standards track document made a normative
reference to something at a lower status, and that was sort of the end of it.

Barry: That's what happens when we call it out during Last Call. The purpose of
the registry is to make it so that the ones we expect to see come up again are
already approved and don't have to be called out.  If you go look at the RFC
that created that registry, it specifically says that it should be more of an
exceptional situation. You need to think about what things should go in the
downref registry.

Murray: So the downref registry doesn't refer to the RFC that creates it. I'm
probably going to ask the Secretariat to add that, because it would be a great
reference to have locally.

2.1.2 Returning items

 o draft-ietf-oauth-jwt-introspection-response-10  - IETF stream
   JWT Response for OAuth Token Introspection (Proposed Standard)
   Token: Roman Danyliw

Amy: I have couple of Discusses in the tracker; do we need to discuss those
today?

Roman: We don't. It's going to require a Revised ID, please. Thanks for the
second look, everyone who did it twice.

Rob: Is it worth discussing the question about privacy? Or do you think there's
no further discussion there?

Roman: I responded back maybe 15 minutes ago before this call with some text
that softens those legal requirements, and I wanted the authors to respond back
whether that softening works, and then we can see if it works for you.

Rob: My key question I was hoping to get feedback from the IESG on was whether
it's ok to use RFC 2119 language to put constraints on legal requirements, or
whether that should be out of scope.

Roman: My thought on it would be what that particular text is suggesting is
that there are policy considerations for handling that particular data, given
how sensitive some of that information might be for a privacy context, so I
personally don't see an issue saying you should think about your policies
relative to your jurisdiction, legally so, but I would probably use a little
softer language than that current text has relative to that.

Rob: But you'd still think it's okay to use RFC 2119 language for those
constraints? I was just after people's opinions here, rather than trying to
express that I think it's wrong. I just wanted to check that's not overstepping.

Roman: I'm interested to hear other perspectives too.

Alissa: It's definitely something we've done in other documents.

Ben: Rob, you're not unique in feeling a little uncomfortable about it, but we
have precedent in both ways. We just don't have a single position on it.

Rob: If there's precedent, and we've done it before, that's fine with me. Thank
you.

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

 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

 o conflict-review-oran-icnrg-qosarch-00
   IETF conflict review for draft-oran-icnrg-qosarch
     draft-oran-icnrg-qosarch-06
     Considerations in the development of a QoS Architecture for
   CCNx-like ICN protocols (IRTF: Informational)
   Token: Magnus Westerlund

Amy: I have no Discuss positions for this conflict review, so unless there's an
objection this is approved.

Ben: Not an objection, I just found it a little bit amusing that they had a
statement in there about how you could use up to 64 bits of the IP address as a
way to classify traffic.

Warren: I must admit I didn't actually read this document. That seems
entertaining.

Erik K: I regret to say I also missed that.

Ben: Do you want to click the defer button and have a chance to look at it?

Erik K: It is prefaced with "this is the author's opinion" in multiple places.

Magnus: Exactly, it's very much a position piece. It's really just a discussion
paper so I don't see a conflict.

Barry: I balloted no conflict because I think there's no conflict. I found it
odd that it wasn't going through the independent stream, but I don't object to
it coming from the IRTF stream.

Amy: Okay, it sounds like there's no objection to sending this no conflict
message back to the IRSG.

 o conflict-review-irtf-panrg-what-not-to-do-00
   IETF conflict review for draft-irtf-panrg-what-not-to-do
     draft-irtf-panrg-what-not-to-do-16
     Path Aware Networking: Obstacles to Deployment (A Bestiary of
   Roads Not Taken) (IRTF: Informational)
   Token: Martin Duke

Amy: I have no Discuss positions for this conflict review, so unless there's an
objection this is approved. I'm hearing no objection, so we will send the
no-problem message.

3.4.2 Returning items

 NONE

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

 o Real-Time Communication in WEB-browsers (rtcweb)

Amy: I have no blocking comments for the reanimation of RTCWEB, so it looks
like this external review is approved and we will send that message.

Magnus: Are you updating it before it goes out, Murray?

Murray: Beyond what I said in that email yesterday? I already did that.

Magnus: Okay, that's fine. Thank you.

4.1.2 Proposed for approval

 o WebRTC Ingest Signaling over HTTPS (wish)

Amy: There are no blocking comments for this charter so unless there's an
objection, this charter is approved to become a new WG. Hearing no objection. I
have all of the pieces we need, so this is ready to go and we will send the
announcement.

 o IOT Operations (iotops)

Amy: I have a Block in the tracker for this. Do we need to discuss this?

Warren: Yes please. I think we've had a useful discussion on the mailing list
and the idea that after a year or so there's a report to the IESG explaining
how it's gone so far, what the progress is; I think that's generally met with
approval. Martin, would that address your concern?

Martin D: Yes, I'm just looking for any sort of checkpoint. That's fine.

Warren: Okay. Maybe we can craft some text together that will address your
concern, or maybe just say after a year the WG will report back and we can
determine how it's going. Something like that.

Martin D: Thank you.

Warren: I believe I've addressed everyone else's comments in the new version.
Thank you very much everyone.

Rob: I just want to add that I think my intent is to keep track of how it goes
over the next year, and whether it needs prompting. But we do have at least one
very experienced chair in there so we are hoping they'll be able to keep it on
the rails and stop it going off in the weeds.

Warren: I think with all charters one of the big things is the people who are
concerned about stuff going off the rails all meet every week on telechats, and
a lot of this can be done if Martin pokes me to ask what are people doing
there, and I can poke the chairs and say "don't overreach," so this can be
fixed by people trying to do the right thing.

Martin D: To be clear, it's not just a matter of it going off the rails, but
also just is anything happening or is this a research group where people are
presenting their experiences?

Warren: That wasn't necessarily directed at you; more general. It feels to me
that over time our chartering text has become more lawyer-y, which is sometimes
useful and sometimes not.

Erik K: Can I ask a question about IOTOPS and the IOT Directorate?

Warren: I think the answer is, we don't know. The official plan isn't folded
in, but over time IOTOPS might need up doing more of the stuff the directorate
used to do.

Erik K: The question was, what should we do with reviews directed toward the
IOT Directorate? Do you want that to be a function of the IOTOPS?

Warren: I believe they should continue where they are.

Erik K: Do you want the responsible AD for IOTOPS to take over the IOT
directorate?

Warren: Do you want to continue running the IOT Directorate?

Erik K: It's currently in Eric V's hands.

Eric V: I don't mind either way, Warren. I think it should fall logically that
the IOT Directorate members become active participants in IOTOPS. If that's not
the case, something is going wrong.

Warren: Yes. I truly don't care; I think it's purely administrative. I'm happy
to be the responsible AD, or you can. It makes zero difference to me. Let's
pick this up offline.

Amy: Okay, so it sounds like we are just waiting for instructions from you,
Warren, when everything is to your satisfaction.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Global Routing Operations (grow)

Amy: This has a Block.

Warren: Yes it does. This is almost all entirely my fault. GROW was formed in
like 2003 and many months ago I realized their charter was really old and told
the chairs they had to update it. They didn't want to change much so the
charter text ended up being that it just needed to make a few changes so it's
updated and the AD is happy. This means that the text that was generated was
not necessarily perfect, specifically on Magnus's question of stewardship and
maintenance. GROW mainly thinks of itself as more operational stuff, but
somehow it ended up with the BMG protocol. This is supposed to mean that they
will look after the protocol and make sure it's going along nicely and if there
are updates they can happen here. "Stewardship" was probably not the right
word; we can work on getting a better word.

Magnus: That was all I was after. You could just say "may publish future
updates for this protocol" or something. Any of these more common words would
work fine for me. It's just that it's not a usual term is what I was reacting
to.

Warren: Okay, that's fine. It's supposed to be "the care and feeding of." There
are also some other comments, Martin has a thing on one-way communication from
GROW to other WGs. That's definitely not supposed to be the intent and we
should fix that. And one last comment, Ben was asking about "effects of the
interactions between interior and exterior routing protocols, the effect of
address allocation policies, or practices on the global routing system." What
that was trying to aim at is different address allocation policies could
potentially make the global routing table explode with too many routes. That's
what that's supposed to talk about, but it's not clear from the text so we will
make the text clearer.

Ben: I was looking at that and it looked like it was trying to be a list and it
didn't line up very well.

Warren: There's been a lot of process wonkery for no real reason. Sorry for the
weird text and we will make it better.

Amy: Will this require an external review, do you think?

Warren: I don't know. I'm of there minds. One, I don't think it does, but if
the text has been changed enough I think we either don't recharter GROW, or we
take the original text and change a few words. This new text isn't actually
better than the old one. Situation unclear, I will report back later.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Alvaro: There's nothing to report this week.

6. Management issues

6.1 [IANA #1187946] Designated experts for RFC 8798 (IANA)

Barry: I'd like to get approval for designating Ari Keranen for this.

Amy: Is there any objection to approving Ari? Hearing no objection, so we will
send official note to IANA.

6.3 [IANA #1187672] Designated experts for RFC 8847 (IANA)

Barry: I've confirmed with Simon Pietro Romano and I'm checking with Roni Even
because he's retired. I may be pulling him off of all the registries if he
doesn't still want to be on it. I'd like to get him approved by the IESG but
not announced yet in case he still wants to be on it. So Simon Pietro Romano
and Roni Even.

Amy: Is there any objection to approving those two, knowing we will embargo
Roni's name until he confirms? Hearing no objection, so that's all set.

6.4 [IANA #1187734] Designated experts for RFC 8855 (IANA)

Murray: I put the call out to RTCWEB and haven't heard anything yet, but I
expect to have this resolved by the next time this comes around.

6.5 IANA #1186621] Designated experts for RFC 8819 (Rob Wilton)

Amy: You'd like to approve the authors of the document, is that correct?

Rob: Chris Hopps, Lou Berger, and Dan Bogdanovic, and they've all agreed.

Amy: Is there any objection to approving those three as designated experts?
Hearing no objection, so they are approved and we will send note to IANA.

6.2 IETF 110 Agenda Conflict Resolution (Liz)

The agenda and conflict resolution was discussed.

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