Narrative Minutes interim-2022-iesg-18 2022-08-25 14:00
narrative-minutes-interim-2022-iesg-18-202208251400-00

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

These are not an official record of the meeting.
Narrative Scribe: Amy Vezza, Secretariat

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Amanda Baber (ICANN) / IANA Liaison
Jenny Bui (AMS) / IETF Secretariat
Jay Daley / IETF Executive Director
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (Google) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Sandy Ginoza (AMS) / RFC Editor Liaison
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Robert Wilton (Cisco Systems) / Operations and Management Area
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area
Qin Wu (Huawei) / IAB Liaison

REGRETS
---------------------------------
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Francesca Palombini (Ericsson) / Applications and Real-Time Area

OBSERVERS
---------------------------------
Christian Hopps
Greg Wood
Ketan Talaulikar
Laurent Toutain
Ana Minaburo
Chris Box
Spencer Dawkins

1.2 Bash the agenda

Amy: Does anyone want to add anything new to today's agenda? Any other changes?

Lars: The Tao Revision approval as a MI. We

1.3 Approval of the minutes of past telechats

Amy: We have the August 11 teleconference under review. Does anyone have an
objection to these minutes being approved? I'm hearing no objection, so these
are approved. We also have the final narrative minutes from August 11 sent last
week; any objection to those being approved? I'm hearing no objection, so those
are approved as well.

1.4 List of remaining action items from last telechat

    * DESIGNATED EXPERTS NEEDED

      o Roman Danyliw to find designated experts for RFC 8809 (WebAuthn)
        [IANA #1229681].

Amy: Roman, any update?

Roman: Still in progress, thanks.

      o Paul Wouters to find designated experts for RFC 9258 (TLS KDF
        Identifiers) [Iana #1234294]

Amy: This is on as a MI later to approve folks, any names, Paul?

Paul: The same people on other TLS registries. I have confirmation of two of
the three. Rich and Nick. Waiting to hear from the third. Can we approve two
today, and add someone later?

Amy: Yes. We will send an official note to IANA.

    * OPEN ACTION ITEMS

      o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to
        the IESG on the impact of COVID-19 to the IETF in October 2022.

Amy: This is on hold until October

      o Lars Eggert to follow-up on the management of the IETF non-wg
        mailing lists.

Amy: Any update here?

Lars: I'm not sure there was action done.

Cindy: Yes, this was making sure the global whitelist was added to the non-wg
lists. So this was done for you and completed last week.

Lars: Great!

      o Lars Eggert to send email to Roman Danyliw about drafting text to
        working group chairs about side meetings.

Amy: Lars, Roman, is this complete? I think it was for before 114?

Roman: I don't know?

Lars: We made you the stuckee to send something about side meetings are not
official WG meetings. Yes, I sent email in July 18, so this is done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

  o draft-ietf-idr-bgp-ls-flex-algo-12  - IETF stream
    Flexible Algorithm Advertisement using BGP Link-State (Proposed
    Standard)
    Token: Alvaro Retana

Amy: There are no discusses. This looks like it approved.

Alvaro: It is ready to go.

Amy: Approved announcement to be sent.

  o draft-ietf-ipsecme-iptfs-17  - IETF stream
    IP-TFS: Aggregation and Fragmentation Mode for ESP and its Use for
    IP Traffic Flow Security (Proposed Standard)
    Token: Roman Danyliw

Amy: There are discusses.

Roman: I need to unpack all of that.  But  lot on congestion control and
transport issues. So advice I am looking for those who discussed, how do we
resolve this. I'm seeing some conversation. Will it be enough?

Paul: Christian [Hopps] is also here to help with questions.

Warren: I want this to be deployable in a way it doesn't hurt people when they
do it. I want people to be able to deploy it safely. Otherwise they will
deploy, discover an issue and turn it off. So minimizing the collateral damage.

Paul: The option is negotiated in a way where either end can drop confirming
it, so it transparent.

Warren: Let's say I deploy this and it is configured to always use 5gig per
second. But when my circuit fails, it may use all the bandwidth. When deploying
you need guidance for operators for implementors

Christian: I think as mentioned we offered to add the MUST language. So
non-congestion control mode must not be used outside of a fully admin
controlled network. So if you don't own the network you must not use this in
non-congestion control mode. The recommended mode is congestion control mode.

Warren: If I deploy this, please have something saying this will always need
this amount of bandwidth, so have that available.

Christian: We can say it needs a fixed amount of bandwidth if you don't use
congestion control.

Warren: It doesn't need to be super formal, just a note to bear it in mind.
Thanks, I can remove my discuss.

Zahed: I had similar feedback. I feel there is a lack of rational thought here.
Where are the guidelines to choose one over another. When someone claims they
can use the non-congestion control. What are the benefits to congestion control
mode?

Christian: It gives you more bandwidth on the tunnel. People who use this want
to use this for all of their traffic. They won't have any other traffic. If you
consider VPN traffic, you still have to own the network right?

Lars: I thought the mode also had a bandwidth cap, so I don't see how to get
more bandwidth that way.

Christian: You own the network and you don't want it competing with the
traffic. You don't want it slowed down with normal congestion control methods.

Lars: Yes, what I heard is that the CBR mode gives you more bandwidth in the
tunnel.

Christian: Yes, CBR mode. And if someone asks why they would want that, it is
to guarantee the traffic in the tunnel. They want this to be the highest
priority traffic. Used when it's the only traffic.

Zahed: Now it makes sense. I want this more information in the draft. When you
are explaining it here you are explaining a lot that is not in the document.

Christian: I can boil it down. We'll say that the reasons the operator may wish
to use this is the guarantee the bandwidth and prioritize it over all other
bandwidth.

Lars: I probably have the longest discuss. The discussion we had for the CBR
mode seems reasonable. I think we agreed offline that you guys would recommend
circuit breakers in your latest email you outlined how one might implement this
based In the information in the packet. I think that is great because that was
part of the missing step. That's what we have for pseudowires which is sort of
an equivalent technology. The other part is the CFRC part. It feels complex.
Almost all IETF congestion control is provider side, but this flips it to make
it receiver side tell the sender what to do.

Christian: I had to implement this to verify I had the right information. So
when I did that, when you do the PFRC for datagrams you have to sent back the
loss events. Or you calculate on the receiver side and send back the summary.

Lars: You just need a count.

Christian: No, you have to summarize the loss events so you have send each
range. You have to give it the history. If you read the modern document on how
to do this it says do either one. It does not prefer one over the other. We use
the one that was simpler.

Lars: This might eb something we don't hold the draft over for, I am not
convinced sticking the TCP traffic inside the tunnel is better than running TCP
which would be the calculation you already have. You avoid the header line
blocking, but you still have two congestion control inside the tunnel traffic
fighting.

Christian: We're no better or worse for that. The first point is important,
we're a datagram service.

Lars: If you could accept the performance degradation you wouldn't need to
specify as the entire mode. But you replace it with encapsulation which would
be simpler because the majority of the complexities in the TFRC.

Christian: It adds complexity to use TCP.

Roman: Should we document the design motivation discussion?

Lars: Yes.

Christian: I can put in the document that the TCP is a non-preferred fall back
mechanism which is why we continue to use a datagram service.

Paul: When using TCP regularly probe UDP to see if it is available and use that.

Martin: I'd like to go back to Lars' ECN point a bit. This problem of multiple
inner packets and one outer packet it turned out to be really complicated. Not
sure the new language for ECN copied value in number one, I'm not sure it is
right, so I will drop into that thread.

Christian: Did you read the version 17 text? The only difference you might have
two packets instead of one being carried, but we have put in that follow
correct behavior to mark them as they emerge from the tunnel.

Martin: We won't resolve it here, but I'll put it in the thread.

Lars: A lot of document talk about tunneling unique things. Might be some
specific things to do here.

Martin: The rules were complicated.

Christian: It's a union.

Martin: The dynamics are quite complicated.

Erik: Should this be experimental status?

Christian: I don't think anyone said this looks like experimental work.

Roman: The working group feels strongly in the robustness of the work.

ƒric: I think the ICMP on the outer, I would not trust that for this.

Christian: The outer packets are the outer packets. The two don't cross.

ƒric: It looks a bit experimental.

Christian: There is a big push for this.

ƒric: On the number, ask IANA you will get it.

Paul: It's about the next header protocol number. There was a discussion and
decided this is the best way.

Christian: You say it will go through. Will any other ADs object to a protocol
allocation now that ƒric said its okay, or is it a non-issue?

Erik: We just did one not too long ago for v6 network programming.

Warren: I've cleared my discuss, thanks Christian.

Christian: I will put the request in to IANA, than.

Roman: Thank you all for the discussion. Revised ID needed.

  o draft-ietf-ipsecme-yang-iptfs-09  - IETF stream
    A YANG Data Model for IP Traffic Flow Security (Proposed Standard)
    Token: Roman Danyliw

Amy: There are a couple of discusses. Do we need to discuss them?

Roman: No, we'll take them to the mailing list.

Amy: Will this require a revised ID?

Roman: Yes.

  o draft-ietf-lamps-documentsigning-eku-05  - IETF stream
    General Purpose Extended Key Usage (EKU) for Document Signing X.509
    Certificates (Proposed Standard)
    Token: Roman Danyliw

Amy: There are no discusses in the tracker. Approved?

Lars: I think there is stuff that needs a revised ID needed. Some working for
copy and paste error.

Roman: Right. Thanks for everyone's review here.

Amy: Approved announcement to be sent with a substate of revised ID needed.

  o draft-ietf-lpwan-schc-yang-data-model-16  - IETF stream
    Data Model for Static Context Header Compression (SCHC) (Proposed
    Standard)
    Token: ƒric Vyncke

Amy: Has discusses.

ƒric: I think the discusses are clear and easy to fix.

Laurent: I agree. No problem to adapt for new version to be ready next week.

ƒric: Revised ID needed.

  o draft-ietf-sidrops-rov-no-rr-06  - IETF stream
    RPKI-Based Policy Without Route Refresh (Proposed Standard)
    Token: Warren Kumari

Amy: There are a couple of discusses here.

Warren: Yes. I sent a message to Murray about this. What happened was the
document shepherd chose Internet Standard instead of Proposed Standard in the
writeup. It is clearly meant to be PS, and I didn't clarify the write up. The
RFC Editor should remove the bit about that. Andrew's seems reasonable to add
some text.

Andrew: I asked an author when I put this in, and they will come back to me in
a few days.

Warren: Hopefully we can finish this fast. Thank you!

Amy: Revised ID needed.

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-tsvwg-aqm-dualq-coupled-24  - IETF stream
    DualQ Coupled AQMs for Low Latency, Low Loss and Scalable
    Throughput (L4S) (Experimental)
    Token: Martin Duke

Amy: No discusses here. So approved.

Martin: Yes, let's put it in revised ID needed.

Amy: Approved announcement to be sent with a substate of revised ID needed for
the comments.

  o draft-ietf-tsvwg-l4s-arch-19  - IETF stream
    Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service:
    Architecture (Informational)
    Token: Martin Duke

Amy: Looks like there is a discuss.

Martin: It is not the intent this a controlled limited domain thing. I haven't
looked at 642 in a while.

Roman: I looked at the table and it looks like there is a flexible incremental
deployment. But you can't do that to data center deployments. You need data
center TCP, the was some evolution but that is not internet safe. If that isn't
accurate I am happy to clear, but that is what it looked like to me.

Zahed: This is the opposite of that. My read was not really what you were
saying, so I'm not sure I can be helpful.

Martin: This is not specifying data center TCP.

Zahed: This is putting to much information in the specification so it is
confusing.

Martin: The key point is that if an end point is going to make packets to take
advantage of this then it has to do some other stuff specifically instead of
the BFD have the correct feedback to the receiver. To be honest, I'm not sure
what "works downstream for control deployment trials" means.

Roman: That is what I was riffing off of. If the assessment is I am wrong, that
is what I am after. Always Internet safe regardless of sequencing I'll clear.

Martin: It's not a congestion control, it's a set of requirements.

Mirja: This is not fully safe, but nothing is. If you don't have ECN deployed
it is safe. May not be safe if you deploy scalable congestion control and you
have a ECN enabled switch. But it might just take bandwidth from other flows.
Strategy is deployable on any angle.

Martin: I think an experiment can be safe.

Roman: I will move this to a comment. And leave this to the experts.

Martin: Move it to approved revised ID needed?

Amy: Sure, once Roman moves his discuss to comments.

  o draft-ietf-tsvwg-ecn-l4s-id-28  - IETF stream
    Explicit Congestion Notification (ECN) Protocol for Very Low
    Queuing Delay (L4S) (Experimental)
    Token: Martin Duke

Amy: Has a discuss.

Martin: Roman's objection is clear for revision.

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-irtf-pearg-numeric-ids-generation-00
    IETF conflict review for draft-irtf-pearg-numeric-ids-generation
      draft-irtf-pearg-numeric-ids-generation-11
      On the Generation of Transient Numeric Identifiers (IRTF:
    Informational)
    Token: Erik Kline

Amy: There are no discusses, so unless there is an objection now. [NONE] The
note is okay, and this can go back to the IRSG.

  o conflict-review-irtf-pearg-numeric-ids-history-00
    IETF conflict review for draft-irtf-pearg-numeric-ids-history
      draft-irtf-pearg-numeric-ids-history-10
      Unfortunate History of Transient Numeric Identifiers (IRTF:
    Informational)
    Token: Erik Kline

Amy: There are no discusses, so unless there is an objection now. [NONE] The
note is okay, and this can go back to the IRSG.

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

  o NomCom Eligibility Update (elegy)
     Area GEN: (Lars Eggert)

Amy: No blocks, looks like this is approved. Are there edits needed?

Lars: No edits needed. Barry Leiba and Michael Richardson are the co-chairs.

Amy: We'll move the milestone down into the milestones and this will be good to
go, probably will be sent tomorrow.

  o Revise Universally Unique Identifier Definitions (uuidrev)
     Area ART: (Murray Kucherawy )

Amy: No blocks on this charter. Any edits needed?

Murray: No, this is ready, we have a mailing list and chairs.

ƒric: I note one of the chairs is also a chair for ELEGY.

Lars: ELEGY will be super quick, and likely done before this one really gets
started.

Amy: Approved. Will be sent tomorrow.

  o Media Over QUIC (moq)
     Area ART: (Murray Kucherawy)

Amy: This has a block, for discussion, is that right?

Zahed: Yes.

Murray: I will defer to Ted for the feedback provided.

Zahed: I saw his answer and it makes sense. I was thinking this would be a job
done by the proponents. I think we should remove it, or we have to explain what
the media type is.

Murray: If you agree I will tell him to make the edits. So just another
revision.

Zahed: I will reply to Ted, I have not seen the other discussion. It looks
good. So if he does the edits I will be fine.

Murray: We'll get a new revision very soon.

Zahed: I will do that after this meeting.

Amy: I have this as approved pending edits.

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

Warren: I had to drop the meeting early. But still loking at the IAB Workshops
and we should discuss participating in them.

Lars: Google folks gave a great talk at SIGCOMM. Maybe a plenary talk. Or INT
area, it was really nice content. The IAB is discussing this.

Mirja: We try to schedule more technical talks and there is one to discuss for
addressing in unlimited domains, and Robin and Russ are working on this, but
IESG folks might be interested.

6. Management issues

6.1 [IANA #1234294] Designated experts for RFC 9258 "Importing External
Pre-Shared Keys (PSKs) for TLS 1.3" (Paul Wouters)

Amy: We have Rich Salz and Nick Sullivan named as potential experts. [no
objection]

Paul: Do we have to formally hear from the one we have not yet responded?

Sabrina: He has been responsive in the past, but he may be out on vacation.

Alvaro: We always ask to make sure they are still up for it.

Paul: If we add two of the three now can we add one later?

Amy: Yes.

6.2 [IANA #1237502] Management Item: Request for Assignment (HTTP/2 Frame Type)
(IANA)

Amy: Request to register a frame type registration?

Martin: I am aware this is someone on my team. Is this an IESG approval
registry?

Sabrina: This requires either IETF Review or IESG approval.

Martin: There is a document. Do we read this?

Mirja: Was the http working group consulted?

Lars: If the WG says they are okay with the assignment, I would feel better
about assigning the code point.

John: If it is desired folks can use the code point without having an ID.

Lars: "IESG Approval" is the security valve here. I don't want this to be
causing issues here.

Warren: I don't know that is true. Having someone look at it and nod for it
seems good. The IESG could override these sorts of things.

Mirja: They need the frame but don't want the frame type?

Warren: We want them to not squat on a code point.

Martin: How big is that code space?

Warren: 256, and we've used 15 or so.

Martin: If no one wants this but Google, what is an issue? I think we should
either approve it or just ask the question of the WG if they object.

Mirja: Sounds like it should be expert review.

Erik: The frame types for HTTP2 and HTTP3 are different.

John: It takes three paragraphs to change the policy.

Martin: On what basis do we decide IESG approval?

John: Doesn't support "do what you want."

Lars: I don't think this raises to the bar of we need to do it.

Martin: What was the other criteria?

Warren: IETF review or IESG approval.

Martin: Should be to have an informational RFC for this. So can be an AD
sponsored document?

Warren: If the working group doesn't care?

Mirja: It should put it in a document.

Martin: This is a bad first experience for them. We can do the RFC.

Lars: I am happy to AD sponsor the document. Would basically allow people who
don't know about it have a say since it will go for Last Call.

Mirja: The RFC also says it needs a 4-week call for comments which we've never
done before.

Lars: Is it urgent?

Martin: I don't know. Trying to do the right thing in reserving the code point.

Warren: We can get a provisional one can't we?

Alvaro: That's 7120, and that requires a chair to request the early allocation.

Martin: Can't do this with an AD sponsored document?

Lars: We would do IESG approval.

Mirja: The policy needs to be changed to reflect that.

Martin: I can talk to them to find out what the deployment intent is.

Lars: Will the WG yell if the IESG reviews this? It is not clear based on the
email. Would be nice to have some sort of document to point to for what it is
used for.

Martin: This is why people write us off as a bureaucratic nightmare.

Rob: I think ask the WG to ask them about if they care or not.

ƒric: This would set precedence.

Lars: An action item for someone to talk to the chairs?

Murray: Yeah, I can try to figure it out.

Lars: Martin will you help?

Martin: We can talk to WG to see what they say for this one.

Lars: Just ask the question if they have objection to the IESG assigning the
point. And if they want to change the allocation policy.

Murray: Sabrina, can you forward this to me?

Sabrina: Yes.

Alvaro: The policy is described in an obsoleted document.

Martin: That seems not correct.

Warren: Maybe we need to discuss what the different registry requirements are
and if they need to be changed. Can expert review have IESG people seated as
the experts? Would that be weird?

Alvaro: To require it?

Warren: Sort of both? Can an IESG person be an expert?

John: You want them to be the IESG instead of someone else? Like a named person
who will stop being IESG person in the future?

Mirja: Why?

Lars: I have done it - been an expert as an AD.

Alvaro: It would be a problem to require an IESG member be the expert.

Lars: I've only seen IESG approval in conjunction with IETF review.

Martin: We talk to the chairs, and if they think the policy is wrong we can
approve it. And if they think it is right, we should AD sponsor it.

6.3 [IANA #1237984] renewing early allocations for
draft-ietf-idr-segment-routing-te-policy (IANA)

Amy: Alvaro do you want to speak to the renewal?

Alvaro: This is in my queue. We should definitely approve the renewal.

Andrew: There are definitely deployments of this. So please renew it.

Warren: We should generally rubber stamp these types of renewals.

Amy: No objections, so we will send the note to IANA.

6.4 [IANA #1237982] renewing early allocations for draft-ietf-lsr-flex-algo
(IANA)

Amy: John, do you want to speak to this?

John: This should be renewed. It will be in IETF Last Call very soon.

Amy: No objections, so we will send a note to IANA for this.

6.5 Executive Session: PR Action Discussion (Murray Kucherawy)

This topic was discussed in an executive session.

6.6 Tao Revision (Lars Eggert)

Lars: Do people have enough to approve this now? Or approve a week or so?

ƒric: I have not reviewed it.

Roman: I lost the thread here.

Lars: We will keep it on the agenda for next time.

Amy: We'll keep this on the agenda for the next formal call.

6.7 IESG Approval to Convene a Second Virtual Interim BOF for JWP (Roman
Danyliw)

Roman: We had a number of BoFs at 114. JWP is one of them. It talked about the
problem and there is a request to do a follow up BoF before 115. Does the IESG
support that. I will put a note out to the IAB for it.

ƒric: My issue with the virtual BoF is to get enough people attending.

Rob: If people want to have this, we should encourage them. Let's do it.

Roman: Okay. No loud objections on this, do you want me to follow up, or am I
good to go to them to get a meeting on the calendar in four or five weeks.
Okay. Thank you.

Amy: Follow up question, if they will charter before 115 or will they want
space on the agenda for the work? Can you add a BoF request for it so it gets
space and time on the agenda?

Roman: I will.

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

Amy: Any working group news or new proposals? No. Okay. Thanks everyone. The
IESG will go into executive session now.