Skip to main content

Narrative Minutes interim-2021-iesg-22 2021-10-07 14:00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2021-10-07 14:00
Title Narrative Minutes interim-2021-iesg-22 2021-10-07 14:00
State (None)
Other versions plain text
Last updated 2024-02-23

Narrative minutes for the 2021-10-07 IESG Teleconference

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

1. Administrivia
1.1 Roll call

Jenny Bui (AMS) / IETF Secretariat
Ben Campbell (Independent Consultant) / IAB 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 (Google) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Éricsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Éricsson) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

Michelle Cotton (ICANN) / IANA Liaison
Jay Daley / IETF Executive Director
Lars Eggert (NetApp) / IETF Chair, General Area

Amanda Baber
Chis Box
Adrian Farrel
Colin Perkins
Lee-Berkeley Shaw
Donald Trump
Greg Wood

1.2 Bash the agenda

Amy: I have one change to the agenda; we're going to take the
dnsop-dnssec-iana-con document first so that Martin Duke can be here for the
conversation. Anything new or any other changes?

1.3 Approval of the minutes of past telechats

Amy: Is there any objection to the minutes of the September 23 teleconference
being approved? I'm hearing no objection, so we'll get those posted. And there
were no changes to the narrative minutes of September 23; any objection to
approving those? Hearing no objection there either, so we will get those posted
as well.

1.4 List of remaining action items from last telechat


     o Roman Danyliw to find designated experts for RFC 8739 and RFC 9115
       (Automated Certificate Management Environment (ACME)) [IANA

Amy: This is to alert you that you have this designated expert request.

Roman: Perfect, action caught.

     o Francesca Palombini to find designated experts for RFC-ietf-httpbis-
       semantics-19 (HTTP Semantics) [IANA #1210675].

Francesca: I have one expert and I'm trying to see if I can get two. What's
best? Should we add the item to today's agenda to approve the one I have right
now, or is it best to have both at the same time?

Amy: That's really up to you. I can't remember if IANA has an outstanding
request for this.

Francesca: I think it's just from the document being in the RFC Editors' hands.

Amy: If there's no urgent request for it, I think you can wait until you have
both in hand and let us know so we can put it on an agenda.

Francesca: Okay. I have an unrelated question for IANA but maybe we should take
that at the end.


     o John Scudder, Martin Duke, and Robert Wilton to review the document
       shepherd templates and propose changes to include updated questions,
       cross-area checks, and an expanded section on the use of YANG

Rob: Still in progress; we're a bit closer to actually progressing.

     o Alvaro Retana and Martin Vigoureux to draft a note to wgchairs
       asking them to always confirm author/contributor status.
     o Alvaro Retana and Martin Vigoureux to draft text to include in the
       I-D submission tool warning about too many authors.

Amy: These two hinge on the first one, so we'll mark these in progress.

     o Murray Kucherawy to update BCP 97 to provide guidance about handling
       normative references to non-SDO documents.

Murray: There is a draft posted for everyone to review; I emailed the IESG
about it, so feedback is welcome. And I am looking for a sponsor for this one.

Amy: It sounds like you've done the document; is this a completed item or do
you want to keep tracking it?

Murray: Either way is fine with me. We can either track this until publication
is requested or we can call this done and just run the process.

Amy: Any volunteers to AD Sponsor the document?

Roman: It seems done to me; let's run the process. I'll have some feedback for

Erik K: If Roman doesn't take it, I will.

Murray: So let's say Erik can [sponsor it] and Roman has feedback.

     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 2021.

Amy: This will happen next time; I have to get updated numbers for you.

     o The IESG to review the feedback on whether to continue the RFC 8989
       experiment 2022-2023 cycle by October 7, 2021.

Amy: Lars put this on the agenda but he's not here, so I'm not sure if you'll
want to push it to the next meeting.

     o Warren Kumari to rewrite the IESG blog post on "Handling IESG ballot
       positions" as an IESG statement.

Warren: In progress.

     o Éric Vyncke to work with the Tools Team to update the references to
       the BSD License in the Trust Legal Provisions in the various IETF

Éric V: I've looked a little bit around in the Datatracker and there's nowhere
we see this license except for the RFC Editor. Sandy opened a case with the
tools team and I have no feedback yet. Let's keep this item open.

     o Greg Wood to update the references to the BSD License in the Trust
       Legal Provisions on the IETF website.

Amy: I'm not sure if this is completely finished yet so we'll keep this in
progress until Greg is back.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-dnsop-dnssec-iana-cons-04  - IETF stream
   Revised IANA Considerations for DNSSEC (Proposed Standard)
   Token: Warren Kumari

Martin: I think my Discuss says it all. I don't know that this is a problem
with this document but 3658 is obsolete, but the IANA registration information
is not in any of the bis-es that obsoleted it. I was looking at one of the IANA
RFCs and I guess this is a problem. I did want to discuss this but I'm happy to
take any one of three answers. One is that this isn't a real problem, don't
worry about it. Number two, yes this is a problem and we'll address it in some
other draft, or three, we should fix the problem in this draft since it's here
and dealing with this general subject.

Warren: Would you accept a combination of all? I think this isn't really a
problem. When 4034 and 4035 obsoleted 3658, I think the obsoleting was a signal
that we really mean it, but that doesn't make all of the text that was in 3658
completely incorrect or not worth reading, nor did it really seem to replace
all of it. The designated experts for the registry had asked IANA to please
keep this reference around. So I think we should probably try and in the future
do a better job of making sure that when a document obsoletes an existing
document, that the registry is updated to either remove the old one or note
both. I think in this particular case it's not really an issue. I also think
the main thing that 3658 is still being used for in the reference is SHA-1,
which is going to be going away relatively soon. Not an ideal situation, but I
think it's not worth all of the fuss and bother that would be required to write
a new document to fix that. I also don't think this particular document is the
place to fix it so we'd have to make a really short document to tell IANA to
update the reference.

Martin D: I guess whoever is on from IANA, is that fine? Is this a serious
policy concern?

Sabrina: That's okay with us. If it needs to be updated you can just let us
know, and if not we'll just leave it as-is.

Martin D: Okay, I'll lift my Discuss and just say that we recognize the issue
and might address it in another document. Thanks.

Amy: Okay, so if Martin is going to lift his Discuss we have no other Discusses
and it looks like it's approved.

Warren: I believe so. The authors have agreed to address all the open comments
but I can't remember if they've published the new version with the nits and
things addressed. So I guess let's do Revised ID Needed.

Amy: Okay, so this will go into Approved, Announcement to be Sent. You can pick
either Revised ID Needed or AD Followup.

Warren: AD Followup is good enough, thanks.

 o draft-ietf-netmod-yang-instance-file-format-20  - IETF stream
   YANG Instance Data File Format (Proposed Standard)
   Token: Robert Wilton

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

Rob: Thanks everyone for their reviews, especially since I put it on the
telechat slightly late. I know the authors have been good at updating the docs
but I need to check that everything has been fed in. Can we put this in AD
Followup please?

Amy: Absolutely; we'll put this in Approved, Announcement to be Sent, AD
Followup and you can let us know when it's ready to go.

 o draft-ietf-netconf-notification-capabilities-18  - IETF stream
   YANG Modules describing Capabilities for Systems and Datastore
   Update Notifications (Proposed Standard)
   Token: Robert Wilton

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

Rob: I don't know if Roman needs to. I think his point is valid and the authors
have already sent a suggestion on how to fix this with some relatively minor
changes to the security section, so I think it's just waiting on Roman to check
if that text is okay.

Roman: Indeed. I have a half-written response to the authors. What they
clarified is in spirit exactly right; what I'd intended was to have A and C
match, but the combination of A and C conflict with B, not that you couldn't
mix and match A and C. They did propose some text and I think it needs to be
clarified a little more, but I just need to put my fingers to the keyboard to
propose some text. I think this one's really clear.

Rob: Thank you, that sounds good.

Amy: So is that still waiting for a Revised ID?

Rob: Yes.

Amy: Okay, so it will stay in IESG Evaluation with a substate of Revised ID

 o draft-ietf-regext-epp-registry-maintenance-17  - IETF stream
   Registry Maintenance Notifications for the Extensible Provisioning
   Protocol (EPP) (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: No. The authors already have a response prepared, I just asked them not
to post it in the middle of IESG evaluation. We can move this to Revised ID
Needed and that will be their trigger to post it and allow Francesca to clear
her Discuss. I think we're all set.

Amy: Great; this will go into Revised ID Needed.

 o draft-ietf-cbor-network-addresses-10  - IETF stream
   CBOR tags for IPv4 and IPv6 addresses and prefixes (Proposed
   Token: Francesca Palombini

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

Francesca: The authors have not had a chance to respond to John yet. John, you
tell me if you want to expand on anything?

John: No, I don't really expect it to be a big deal. I just wanted to make sure
it didn't get missed, that's all.

Francesca: Great, thank you. So we'll need a Revised ID.

Amy: Okay, this will stay in IESG Evaluation with Revised ID Needed.

2.1.2 Returning items

 o draft-ietf-emu-eap-tls13-20  - IETF stream
   Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3) (Proposed Standard)
   Token: Roman Danyliw

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

Roman: I'd like to discuss it. Ben, in terms of history, I think Éric said
roughly the same thing, which is how do I apply the patch with the updates? And
with apologies to the authors, it was my suggestion to use the magic word
"amends." The intent was that you have the text in the old document and there
was a lot of heartburn about how to modify that text. The thinking was there is
new text here, you read the old text and new text and the union of that is the
updated version of the document. There was WG consensus not to try to nitpick
sentence by sentence, to come up with a unified set of text. So my proposal was
that this "amends."

Ben: Okay. I don't object to "amending" per se, just grammatically if we say
"amended with something" it feels like it should have an interpretation and I
can't find it. If we were saying by amending it according to the guidance in
the following text, or something like that, that would not be problematic to
me. We can tweak a few words and I can write something up, not in the middle of
the call.

Roman: Okay, so I just want to capture that. If it was more instead of this
amends this section, it would say it amends with the text below, that's better?
Or do you want to polish it offline?

Ben: I think we should polish it offline.

Roman: That's fine. Can you help me understand the contrast, you said in the
third paragraph, about the replaces vs amends?

Ben: Replacing is a pretty well-defined thing, and if you're amending
something, at a grammatical level you need the subject, what are you amending,
and what the actual action is. Just saying I have some text, unless the
contents of the text describe what to do, is not really something that amends
the other text. It's providing extra context or information.

Roman: Thanks for clearing that up. We'll work on what else to add offline. We
can put this in Revised ID Needed. Thanks everyone for giving this a second

2.2 Individual submissions
2.2.1 New items

 o draft-danyliw-replace-ftp-pointers-04  - IETF stream
   Updating References to the IETF FTP Service (Proposed Standard)
   Token: Éric Vyncke

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

Éric V: It's approved for sure, but I wonder whether Roman can address the
couple of comments that came in lately.

Roman: Sure; I wanted to wait until you asked me to do that. I didn't want to
abuse my AD privilege since I'm also on the call wearing the other hat. The
first thing I wanted to say is, boy, I guess I didn't really appreciate the
finesse that's required when you want precise spacing when you start with
markdown and generate xml. Thank you to everyone that found all of those
things. I don't think I caught all of them yet, but I'll get them. The
editorial ones are easy and I appreciate those. Martin, yes, we'll use the RFC
[url] instead of /in-notes, that makes perfect sense. The one I wanted to talk
about is the thing Ben pointed out, which was if we make changes to the urls in
the MIBs, do we need to change the last-revised dates for MIBs? I hadn't
thought of it. How do people feel about that? It seems right. Are there
objections to doing that?

Warren: I believe you should because I think a lot of tooling uses
last-modified to determine when it should download a new copy of the MIB. So if
you make any changes, last-modified should be updated too.

Ben: Do we also have to produce the updated MIB file somehow? I have literally
no idea how that works.

Roman: I need help here, I've never made a MIB document before.

Warren: I don't know, it all has gotten complex.

Rob: I'll have to ask.

Warren: If we do have to update it, do we have to publish a bis document?
There's all sorts of messiness here.

Ben: I was a little reluctant to actually propose updating the MIB. I was
trying to suggest we could finesse the wording a little bit so that the link in
the RFC is incorrect, this is what the correct version is, but we aren't
changing the published MIB.

Warren: That doesn't sound unreasonable, largely because who the hell is using
this MIB anymore?

Roman: So Ben has a proposal on the table that instead of updating the
document, we make a commentary on the document. Does anyone object to that?

Ben: I think we have to update the document in some sense, in terms of the RFC

Roman: Sure. I meant update the MIB.

Ben: Exactly.

Warren: In the updated document, can you say this document updates RFC blah
blah, by changing the last-modified date from X to Y?

Roman: Does that mean you're really changing the MIB and we're back in the same

Warren: It does mean you're updating the MIB, but that doesn't require a change
of the document. It seems very ugly, but we often update information in a

Roman: How about I do the following; instead of discussing this in the
abstract, i will craft the sentence we could use for those MIBs, we'll get some
feedback on it, and if I could get some help running the traps for folks that
know how to publish MIB documents, how hard really is it? Maybe it's easier
than we think it is.

Éric: Do we still have a MIB directorate or reviews group? It's worth asking

Rob: Jurgen will know the answer to this as well.

Éric V: Rob, may i suggest that you ask them? You know better how to write this
question compared to Roman and myself.

Rob: That's fine. There's a bit of me thinking pragmatically that I don't think
republishing MIBs for this seems like the right answer. Trying to get to an
answer where we highlight the difference in the MIB without having to republish
it seems like the right answer. It just seems that republishing MIBs seems like
a waste of time and effort and won't help anyone.

Warren: This gets back to one of our core problems. We often seem to combine
code and narrative in one place and call it an RFC and then it's immutable.
Maybe stuff like this should be that the MIB was always stored in IANA where it
could be updated without having to publish new versions of documents.

Roman: So it sounds like I'll propose some squirrely text and send it around,
and we'll do a check with the MIB doctors to get a check on the level of
difficulty here, and then we'll decide how to update the document.

Rob: That makes sense to me.

Éric V: Let's say Approved, Revised ID Needed.

2.2.2 Returning items


2.3 Status changes
2.3.1 New items


2.3.2 Returning items


3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-lamps-rfc7299-update-01  - IETF stream
   Update to the Object Identifier Registry for the PKIX Working Group
   Token: Roman Danyliw

Amy: I have no Discusses in the tracker, so unless there's an objection it
looks like this one is approved. I'm hearing no objection to approving the
document. I have no notes in the tracker; are there any needed, or is this
ready to go as-is?

Roman: I'll confess I did not check all of the comments. I think Russ is still
promising an editorial fix here and there; I know he staged it but I don't know
whether he pushed it. Can we say AD Followup and I'll figure out what has to
happen after I look?

Amy: Sure; we'll put this in AD Followup and you can let us know.

3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items


3.2.2 Returning items


3.3 Status changes
3.3.1 New items


3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items


3.4.2 Returning items


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

 o System for Cross-domain Identity Management (scim)

Amy: I have no blocks for sending this to external review; unless there's an
objection now, it looks like external review is approved for SCIM. I'm hearing
no objection, so it looks like external review is approved and we'll send that
review announcement and it will come back for approval at the next telechat.

Roman: Since we have everyone on the call, if I could ask a question or two
based on the feedback that I'm trying to merge in. Ben, I clearly don't get the
standards maturation process. Can you say a little bit more about how the
approach to do those revisions is not compatible with the stated goal? Do we
not want to make a bis document and then advance the bis document?

Ben: The typical thing to do would be to have the bis document and have it go
as Internet Standard, but there are also these bullet points about profiling
relationships with other protocols, and updating the external ID usage, and
updating account state to capture some other stuff. It's not really clear what
the scope of those updates would be; if they're developing new functionality or
new features that would need to go to Proposed Standard first.

Roman: I believe the way I would frame it is that it's the more specific
version of the vaguer text at the beginning, which is that there are errata and
then there is a different implementation experience, and there's a desire to
jam that into the bis document.

Ben: It may be a matter of we just have to wait and see what it looks like. I
apologize that my comments are not very well formed; I'd been hoping to read a
little bit more and update them this morning but it didn't happen.

Roman: Not at all; I appreciate the review. I'll take a closer look at it and
crosswalk with you to see whether we need to make any more edits. Thanks.

Amy: Did you want to hold external review until that happens?

Roman: No, I'd like this to go out and we'll use the extra time with external
review to polish as needed.

Amy: Okay, so we'll send that external review message for SCIM tomorrow as we
normally would.

4.1.2 Proposed for approval


4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval


5. IAB news we can use

Martin V: No news, just one point. The IAB had an interesting talk from Olaf
Kolkmann yesterday on the internet standardization policy landscape. That was
really interesting, I don't know if slides can be shared, but if they can you
should ask the IAB. Beyond that, no specific point.

Éric V: Did Olaf give suggestions to improve?

Mirja: The point he made was that we see governments have more and more
interest in the standardization space and that's something to have an eye on.
The request he made to the IAB was to have a little more connection between IAB
and ISOC to make sure we are well aligned and we know how to handle that. We
have a few IAB members who will have some side meetings with some ISOC people
to come up with some guidelines, and will bring them back to the IAB at some

Ben C: To add a little to that, there was a question about how ISOC can talk
about the IETF and how much the IAB and IESG need to be involved in approving
those sorts of messages, recognizing that they need to be able to react quickly
and speak about things quickly, so anything that requires them to come back and
get various groups to agree on a message probably won't be reactive to whatever
problem they're trying to deal with. So part of that small group is to discuss
how to deal with that.

6. Management issues

6.1 Continuing the RFC 8989 experiment (Lars Eggert)

Amy: Lars added this but could not be here today. Is there anything to discuss
or should we put this on the agenda for next time?

Rob: I'd suggest putting it on next time.

Mirja: Is there actually discussion needed, or did we already discuss it by
email? Is this just to minute our decision?

Éric V: Do we know Lars's point of view? I'm more positive to continue on this

Mirja: This is the recommendation we gave when we sent this out for community
review so I believe he stands behind this recommendation.

Amy: Is there any action to take to continue the experiment or has that action
already been taken? I'm not clear.

Mirja: I'm not sure if there's any action for the Secretariat. Maybe Lars wants
to announce the final outcome at some point. I guess we can just minute for now
that there are no concerns and see if anything else is needed when Lars comes

6.3 [IANA #1210257] Designated experts for RFC 8739 and RFC 9115 (Automated
Certificate Management Environment (ACME)) (IANA)

Amy: This is to alert Roman that he has this action item.

6.4 BCP14 terms in non-IETF streams (Lars Eggert)

Amy: Lars also added this but he didn't really give us any information on what
this was about. Can anyone speak to this, or should we continue this for next

Mirja: I think this came out of the discussion with the independent stream
author about the question of if BCP 14 keywords can be used in other drafts and
if we need to clarify that in each stream. I think this should probably wait
until Lars is back.

Ben: I agree, we should wait to discuss this one. It's hard to stop other
people from using those terms, so it's pretty clear that's roughly the desired
outcome, but we should discuss how to get there and if we need to publish

Amy: Okay, we'll keep this on as a management item for discussion next time.

6.5 Update to Last Call Template (Lars Eggert)

Amy: This also seems fairly straightforward. Lars wants to add a line to the
Datatracker template for Last Calls that will automatically be added to the
announcements that says something like "A listing of open IETF Last Calls is
available at [URL]." This seems like a good idea to me, but is there any
discussion needed? Any controversy?

Roman: I like it. We should do it.

Éric V: Yes, let's do it.

Amy: Okay. It sounds like this suggestion is approved. Éric, as the tools team
liaison do you want to take that to the tools team?

Éric V: That's fine, I will take it.

6.6 [IANA #1210675] Designated experts for RFC-ietf-httpbis-semantics-19 (HTTP
Semantics) (IANA)

Amy: Francesca knows she has this designated expert request as we discussed at
the top of the call.

6.7 Telechat Dates Between IETF 112 and IETF 113 (Secretariat)

A schedule of informal/formal telechat dates for between IETF 112 and 113 was
discussed. There was essentially only one option for the date rotation, and it
was approved and the dates will be added to the calendar.

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

Éric V: Just a quick update on HOMENET; they still intend to close in the
coming weeks or months. Barbara Stark is about to retire and has selected Kiran
Makhijani as a third co chair, so Barbara can leave whenever she wants and the
rest can finalize the remaining document.

6.2 IETF 112 Conflict Resolution (will be taken last) (Liz Flynn)

The pre-preliminary agenda for IETF 112 was discussed and deconflicted. The
preliminary agenda will be published on 8 October.