Narrative Minutes interim-2022-iesg-12 2022-06-02 14:00
narrative-minutes-interim-2022-iesg-12-202206021400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2022-06-02 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jenny Bui (AMS) / IETF Secretariat
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (Google) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
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
Francesca Palombini (Ericsson) / 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
Éric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area
Qin Wu (Huawei) / IAB Liaison

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Robert Wilton (Cisco Systems) / Operations and Management Area

OBSERVERS
---------------------------------
Mike Jones
Anthony Somerset
Ketan Talaulikar
Greg Wood
Kristina Yasuda

1.2 Bash the agenda

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

Roman: I wanted to ask a question to make sure I correctly understood our
discussions from the informal. Does the IESG want to talk any more about the
SCITT BoF? If the answer is no, I'd like to get an announcement out after this
meeting. I will pause to ask whether we need an agenda item.

Martin: Isn't the BOF coordination call like an hour after this?

Roman: No, this is for the virtual interim.

Warren: I think we all decided, thanks for asking, but it's' entirely up to you.

Amy: It's going to come up twice, I believe. The virtual interim and they also
want presence at IETF 114, which we can talk about later today at the BOF
coordination call. This is for the virtual interim that I believe they want for
June 16.

Roman: Correct, exactly 2 weeks from today.

Martin: First of all, what Warren said, but inevitably these things seem tied
together, 114 and the virtual interim.

Roman: Would you feel better if we waited three hours?

Martin: I don't see what the harm is. If the IAB is going to hate it, that
would be their chance to hate it.

Roman: I haven't gotten anything back from the IAB. I'm happy to wait until the
coordination call; I just need to get it out today so I can be legal on the 2
week notice.

Warren: I kind of agree; we can wait a couple of hours until we are with the
IAB. Assuming there's no massive no, that sounds like a great plan.

Roman: Thanks so much.

1.3 Approval of the minutes of past telechats

Amy: We have two sets of minutes to approve. The first set is May 5 and the
second set is May 12. Any objection to approving the official minutes of May 5?
Hearing no objection. Any objection to approving the official minutes of the
May 12 telechat? Hearing no objection, so those are both approved. We also have
narrative minutes from both; any objection to approving the narrative minutes
of May 5? Hearing no objection. Any objection to approving the narrative
minutes of May 12? 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].

Roman: Still in progress.

     o Security ADs to find designated experts for RFC 9116 (A File Format
       to Aid in Security Vulnerability Disclosure) [IANA #1230049].

Paul: I've identified experts and both are willing. The RFC authors are willing
to be the experts.

Amy: You put it in as a management item, which is exactly what you should do,
and then later in the call the IESG will approve the folks you found, and then
the Secretariat will send an official note to IANA letting them know that these
are the experts for this registry. We'll mark this provisionally done for now.

     o Éric Vyncke to find designated experts for RFC 9250, "DNS over
       Dedicated QUIC Connections" [IANA #1230687].

Éric V: I just learned about this today so I'll be working on this and it will
hopefully be done next time.

   * 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 July 2022.

Amy: This is on hold.

     o Murray Kucherawy to look into updating the guidance in BCP 13 on
       when to add organizations to the "Standards-related organizations
       that have registered Media Types in the Standards Tree" list.

Murray: I think I finished this by putting something in our wiki a couple weeks
ago and didn't hear any feedback that it was bad, wrong, or confusing, so I
think this is done.

     o Lars Eggert to facilitate an update of the document shepherd writeup
       form.

Lars: I'm in the process of that. I did a PR based on what I saw on the
wgchairs mailing list and there is some discussion. People generally seem to
like it. Hopefully this will conclude over the next couple of days or so and
then I will make the datatracker and the chairs wiki have the new text.

     o Lars Eggert to ask the Tools Team to push the global whitelist out
       to WG mailing lists again.

Lars: I did ask. I don't know if it got done; do we have Robert on the call?

Amy: No, I don't see Robert.

Lars: There was a discussion that Robert started with Jay and there are a whole
bunch of lists wondering whether the global whitelist should be applied to all
of them. Jay and I told him that it should be pushed to all lists that don't
otherwise have rules about who can post. I'm not sure if it happened yet
though; Robert is on vacation next week and I'm not sure if it will get done
before he leaves or not.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-idr-bgp-ls-app-specific-attr-12  - IETF stream
   Application-Specific Attributes Advertisement with BGP Link-State
   (Proposed Standard)
   Token: Alvaro Retana

Amy: I have a Discuss in the tracker; do we need to discuss that today?

Alvaro: No, I don't think so. Ketan has been exchanging emails with John so I
think we're making progress there. We're going to need a revised ID.

Andrew: I put some stuff in there as a comment and was debating around making
it a Discuss. Alvaro, if you can take a look at that as well.

Alvaro: I already replied to that.

Andrew: Oh okay, I haven't seen it yet.

Alvaro: We'll take care of that in the next revision.

 o draft-ietf-lisp-6834bis-12  - IETF stream
   Locator/ID Separation Protocol (LISP) Map-Versioning (Proposed
   Standard)
   Token: Alvaro Retana

Amy: I have a number of Discusses in the tracker; do we need to discuss any of
these today?

Alvaro: No, I don't think so. I just wanted to point out to Paul and Roman that
I think your Discusses are both related, and related to the SECDIR review
Donald did. We settled with Donald on the text, which of course doesn't mean
you need to agree as well, but if you can take a look at the thread that would
be good. Luigi has been in touch with John and there's progress there. Besides
that I don't think we need to discuss.

Roman: I appreciate Luigi's fast response and he's working on new text. I think
we can work it out.

Alvaro: We're also going to need a revised ID for this one.

 o draft-ietf-lamps-cmp-algorithms-15  - IETF stream
   Certificate Management Protocol (CMP) Algorithms (Proposed Standard)
   Token: Roman Danyliw

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

Roman: We're going to need to do a process check that Francesca pointed out.
There was a downref not called out in the last call. My fault for not checking
the text there. I want to run the 8067 process through the IESG to confirm we
can use the PKCS 2.1 reference which is informational.

Francesca: I support that and i think we should add 8018 to the downref list.
That has already been last called for another document so we don't want to have
to do this again.

Roman: Right. We're going to use PKCS 5 version 2.1 again.

Lars: Let's do it.

Francesca: I was just wondering, usually those are picked up by the tool; why
wasn't this?

Lars: The short answer is that idnits was broken and the tool I use is a
re-implementation of what idnits should be doing.

Roman: I thought that, but I went back to idnits, and it does call it out. I
was surprised I missed it. I also thought it would auto-gen in the text.

Lars: It might be that idnits is not stable and maybe it gives different
results at different times. I don't know.

Roman: Just a heads up to everyone to double check idnits and their downrefs. I
didn't hear any objections; can we put this in AD followup so i can make sure
those changes are there in the -15?

Amy: Absolutely. Approved, announcement to be sent, AD followup.

 o draft-ietf-tls-subcerts-14  - IETF stream
   Delegated Credentials for (D)TLS (Proposed Standard)
   Token: Paul Wouters

Amy: I have no Discusses in the tracker, so unless there's an objection now it
looks like this one is approved. I'm hearing no objections. Are there any notes
needed?

Paul: No, this is ready to go.

Amy: Okay, this is approved, announcement to be sent.

Francesca: I had some comments and I haven't seen answers. Not from me but from
Christian Amsüss for his ART-ART review. I don't know if we want to wait for
the author's reply to that before it's approved. Or did I miss an answer?

Paul: I would have to double check, I'm not sure. I can take it on me to check
that that's okay before it goes.

Francesca: Thank you. It was mostly general comments but there was one on the
IANA considerations that I would like to get confirmation all is good.

Amy: So we'll put this in Approved, Announcement to be sent, AD Followup so
Paul can follow up. You can just let us know when that's ready, Paul.

 o draft-ietf-opsawg-l2nm-19  - IETF stream
   A YANG Network Data Model for Layer 2 VPNs (Proposed Standard)
   Token: Robert Wilton

Amy: Rob could not be with us today. There are no Discusses in the tracker. Is
there any objection to approving?

Zahed: I think this needs a revised ID. There has been some discussion between
me and the authors and as far as I see in the slack chat with Rob, this should
be in AD Followup. I've cleared my Discuss but I'm still waiting for some
updates to be done.

Martin: A new version just dropped today.

Zahed: I haven't checked that yet. Rob wants it in AD Followup.

Amy: Okay, so this will be Approved, Announcement to be sent, AD Followup so
Rob can make sure the changes that were agreed upon were done.

 o draft-ietf-lamps-cmp-updates-20  - IETF stream
   Certificate Management Protocol (CMP) Updates (Proposed Standard)
   Token: Roman Danyliw

Amy: I have a few Discusses in the tracker and quite a number of abstentions.
It sounds like this document needs a little bit of discussion.

Roman: Thanks everyone for taking a peek at this document. I think we have 3
classes of feedback; certainly some comments that need to be adjudicated and I
don't want to talk about that. There are some Discusses that are technical
things we should talk about. The bigger thing is to talk about the abstains and
the editorial process that was pursued with this document. I've roughly laid
out how we got here. To repeat, there is a history in PKIX to do old/new, they
started with what they thought was going to be a limited set of things, then
the list was almost 70 pages worth of edits, and now there's a technical debt
question; now that we're on the other side of all that work, do we take all
that work and spin a new document, or do we spin a new document when this gets
packaged again to upgrade its status to IS? It seemed like from the abstains,
folks found this challenging to read and felt like we should just do a bis.
Does that roughly summarize the abstain positions?

Éric V: Yeah.

Roman: To me, where we are with this exchange is this document does not have a
quorum now and if the WG wants this document, they should do a bis or nothing,
procedurally. Is that right?

Amy: There are five abstains, so yes. You're not going to get your two-thirds.

Martin: Are any of these abstains Discuss abstains? [laughter]

Warren: I'm glad other people are carrying the Discusses and abstains because I
didn't really know what I wanted to ballot on this. The more I thought about
it, I figured that the WG has done largely what people have been telling them
they should do. We often say not to release a draft with a single small update,
so if you do a bis, people are going to poke at all the random crap you didn't
write. I agree this document is severely sub-optimal, but I think the authors
and WG were trying to do what we told them to do. I think they got some shitty
advice, but we gave it to them, so [they] should continue with this and let's
make sure it doesn't happen again.

John: I'd like to dissociate myself from that 'we'. I try not to give that
advice to people. I give some related advice, which is I don't think this is
the right way to do it but I won't blame you if you do it this way because of
these practical reasons. There's a certain undertone that this is a process
hack at your own risk.

Warren: It is very vague when one should choose the old/new old/new vs a
completely new document. Clearly this strayed from old/new old/new into oh my
goodness, you should have done a new document.

Paul: Let me clarify that, because we had 2 documents on the list that used
this. One of them used inline old and new which I found fairly readable. This
document used old, go look at the old RFC, and new, look at the new text here.
I'm switching between the two documents and now my brain just cannot parse
things anymore and I don't know anymore if I'm reading the old or the new. The
method is really what caused me most of the problems for this document. We can
argue about the amount but the fact that I have to have 2 windows open with old
and new is too difficult for such a large amount.

Lars: That's basically what I was going to say. There's a gray area about when
you do this kind of updates style fix document or a bis. Clearly this is way
past the bar; even the WG or authors must have found this difficult to review.
I'm not convinced someone could really say this is the best way forward. Maybe
historically they thought they were doing a small fix and it got out of
control, that makes sense.  I want to propose a way forward. I feel somewhat
bad yanking this document back to the WG specifically, because it was pointed
out that implementations might be waiting on an RFC before they ship. Could we
do something where we pass this onwards and give the WG a work item to do a bis
immediately?

Roman: What you would say is approve this, but almost approve this
conditionally with the WG having a chartered milestone with a date for when the
bis would be published?

Lars: Yes. Obviously the milestone isn't binding but that's the closest we can
do to force someone to do something.

Éric V: How long will it take for the authors to apply all the patches to the
original document? Four hours maximum. It goes again to IETF Last Call and then
we're done. That's basically a one month delay maximum.

John: Is it an original document or original documents plural? I thought it was
several.

Roman: I am not optimistic that this is just a said script and let's respin it.

Warren: What if we were to do largely what Kars said, but also attach an IESG
note saying that clearly this is suboptimal, we believe it's useful to be
published, the authors are planning on having a new one sometime soon, please
never do this again, but this seems least bad.

Murray: I would totally support that.

Zahed: I balloted no objection with a comment that this needs to motivate what
you are doing and what's the plan. That's basically kind of like what Lars is
proposing. I have two points, one in favor; yeah, you guys have been doing good
and things are waiting on it, so you might need an RFC number to get things
shipped. I think that's a very valid reason to allow this thing. But also what
Paul said, this kind of reviewing is really really bad because it hurt my head
when I was doing it. If there is no technical problem that we have marked that
actually blocks us from publishing it, we don't have much to say about it. This
is formatting so let's pass it through with some notes and make sure the WG
works on the bis immediately.

Éric V: But it's different, because I have not reviewed the document. I gave
up. I want to review it. It's unreadable and I want to review it.

Zahed: As I said, my head was hurting, but I don't think I'm qualified to
question the contents. I did my basic reviews and I was done with it.

Roman: To those parties like Éric that would in principle would support what
Lars said, which is commit the WG to doing the followup bis, create a
milestone, but you feel like you didn't have an opportunity to look at the
document because you immediately went abstain, do you want me to bring this
back as a returning item? Would that be helpful? Do you want me to just leave
it as is and you can look at it at your leisure?

Éric V: In the best case, to be honest, I will go into no position. How can you
read this?

Paul: I have the same problem. I would also not be able to say no objection
because I didn't manage to read everything.

John: From my point of view, I don't have to read and understand everything
from every area, but I hope that at least the security ADs are both able to
ballot no objection on a security document. If they can't, that worries me.

Zahed: That's a valid point, John.

Paul: If we return the document I can reserve some time and do it reluctantly,
assuming it's going to be the last time we do this. But that will take some
time.

Éric V: If you do a cut and paste, Paul, can you share it? I'm joking, sorry.

Murray: Someone made a point earlier; how do we stop this from happening again?
Mirja just said in the chat she doesn't think this will be the last time.
Should we do an IESG statement separate from this document saying don't do
this? If you have an old/new maybe set a guideline of, pick a number, any
number smaller than this one. Otherwise this will happen again. I'm amazed that
this got to us with nobody in the review path saying wait, why are we doing it
this way instead of a bis document? Or if that feedback was given to them, I
missed it. I think how we prevent this from happening in the future was the
question and we should deal with that, even if we do decide to hold our noses
and let this go by.

Martin: I think it's a question of relative page count. This is a 70 page
document and the core document is like 90. Just having a fixed number of
old/new is not … if it's a 165 page document I'm happy with five old/news. But
if it's a 10 page document, just do a bis. Unless it's like, a typo. It's a
little more complicated and will be hard to do a hard and fast rule. But I
guess we could wordsmith that later.

Murray: The problem is that if we don't give a hard and fast rule, we leave it
objective, then lots of stuff is going to squeak through that hole we leave.
It's a tough problem.

John: This is in danger of turning into the topic from the retreat about how we
change the way we incentivize people to do bises instead of patches.

Roman: I agree. While this seems odd for me to say since I'm the person who
often tries to come up with a quantitative metric, here, maybe that's not what
we need. Maybe what we need is an IESG note that in a sense puts the community
on notice that says we've encountered these things before, they are incredibly
hard for us and give us a lot of pause about whether the documents got adequate
review. We would urge WGs to think very very hard about bringing documents that
look like this forward. That gives us top cover when we see another instance of
this to say we already told you that's complicated. That gives us a more
principled ground to send something back to the WG because we've already warned
the community this is a problem.

John: I want to follow up a little bit on my previous comment. I agree with
that but if we put that out there by itself, there's a whiff of the beatings
will continue until morale improves. Which is to say, we should look at the
fact that we're getting these documents as a vote of no confidence in our
ability to process bis documents. I would feel even better about saying just
don't give us more patch documents if we had a little bit of additional history
processing bis documents smoothly and easily. Maybe I'm being too harsh on us.

Warren: I think that sounds reasonable. Clearly this was annoying work for
people to do. They had a reason. Instead of just saying please don't do this,
we might want to word it as here are a number of things we've noticed that are
making things harder or easier. As well as please don't send us 4,000 pages of
diff. I'm sure there are other things we could also mention that would help
with making your document go easier through the process. Wording it more like
that might sound less like they're doing it wrong and more like here's how you
can make documents better and easier to read, including for us. I don't know
what else to put, though.

John: I'm ok with the statement as described if that's how we do it.

Francesca: I'm in favor of having the statement. I just wanted to mention what
I wrote in chat just for the record. Usually authors don't want to do bis
documents because then the whole community feels entitled to go over the
original docs, even the parts that weren't changed, and that can delay a
document as well. They're kind of stuck. Possibly also why this started with
the patch in this document in particular. I do think it would be good to have a
statement but that doesn't mean it's going to be easy for authors and WGs to
decide which way to go. There are pros and cons in both.

Warren: Clearly it's not do this and everything magically works out for you,
but for some things it is just better just to have an old/new. What I think
would help with the problem of bis and re-litigating everything is provide a
place for authors to note in the bis document which bits have actually changed
so that for this document, I could just go through and look for them.

Francesca: There are still people who think that a bis should not be published
without fixing, if there were old issues.

Martin: In the slack, Murray has offered to draft something, which I think
would make a future discussion on this statement more productive. And I would
encourage us to return back to the question at hand, which is whether we are
comfortable with this document moving forward. What I heard was let's just give
Paul two weeks to do the painful thing. Is that good enough? Are we really
going to have more people commit to do this kind of detailed reading or are we
just going to say no, this cannot have the quality of reviews it needs, and
kick it back?

Murray: To be clear, what I'm volunteering to do is write a separate IESG
statement, not write a note to put at the top of this document.

Martin: Yes, that's correct.

Murray: Okay.

Roman: Martin, your question is exactly the right one, because now we're in
balloting finesse. Not to say that edits aren't needed, but we have five in no
objection plus me as a yes is six. Even if Paul did his work, and I'd say you
should take a month, I'd think the June 30 telechat to bring it back, that's
still not enough positions to carry. I'd need commitment if we wanted to go
down this path from some of the other abstaining parties, not that you're not
going to come back with a Discuss, but that you're willing to re-look at the
document.

John: I'm willing to re-look at the document.

Éric V: Like I said, I will not read this document as such. I'm sorry. I will
go with whatever you want, abstain or no position, but that doesn't change a
lot.

Lars: You need four. That includes Francesca. Are you willing to ballot on it
or are you abstaining by doing no record, Francesca?

Francesca: I haven't had time. I'm willing to take a look, but I can't say what
the result will be.

Martin: Why does it need four? My thing is pretty minor and can be cleared up.
Paul is going to do it. I see 8 non abstains. If it gets 2 abstains to actually
read the thing, then we're good, right?

Roman: Right. We'd need Lars and Francesca to look at it.

Martin: John agreed, so just one of them.

Lars: If the Discusses clear, and they don't go to abstain.

Francesca: If you could put it on a telechat, it's easier so it counts toward
the page count.

Roman: You're absolutely right, Francesca. Here's the thing. I think informally
what I heard is that folks are willing to look at it again. I'm not going to
make anyone commit to changing their position live without reviewing the
document. The question I would have for everyone is do you want the June 30
telechat or do you want six weeks to take the last one before IETF 114, given
that there's always a bit of push on that last one?

Paul: I'd pick the earlier of the two.

Roman: Okay. Unless anyone objects, I'll bring this back on June 30.

Lars: I'm on vacation June 30, but I will then need to remember to ballot on
this early. I'm happy that we're finding a way forward for this document but
maybe we should consider doing an IESG statement. There is a pretty clear case
when it's just a few lines that it's basically a glorified errata. Then there
are clearly cases like this where it doesn't. We need to have some guidance for
the chairs about what to do here.

Martin: Murray has already agreed to draft something.

Lars: Okay, great.

Martin: Can I very briefly discuss my actual technical point? For the reasons
that we have been discussing it was very hard for me to figure out exactly what
protections are on what for what message. Roman, is it true that all the
messages, including error messages, in CMP are authenticated in some way even
if they don't use TLS?

Roman: Correct.

Martin: Okay. In that case there's no problem and I will clear my Discuss.

Roman: Double check the specifics. I think you got a very specific answer on
points in the document; make sure you're happy with those.

Martin: He said version upgrade doesn't matter because we don't fix the
problems in v2 and v3, but if the point of v3 is to put in crypto agility,
there will be some differential at some point. I don't know if that point is
correct but regardless if it's authenticated there's no downgrade potential.
Thank you.

Roman: The other thing for rescheduling is I will get with the WG to get a
milestone into the datatracker.

Zahed:  We discussed this document should say something about why this is like
that and what is their plan. Right?

Roman: Got it. We can add. I'll work with the authors to create some text to
the effect that this is staging for the bis to the upgrade for IS. and i'll
also get the shepherd writeup cleaned up as well because it didn't have those
implementation pointers I was sharing.

Francesca: Should this be an IESG note or text in the document?

Roman: My preference would be to inline it in the text rather than do an IESG
note. Part of that is my experience with the ISE; it prejudices the text a
little bit if you have this extra thing. If it's the intent of the WG to
already produce a bis, why not document that as the plan of the WG.

Francesca: Okay.

Roman: I very much appreciate everyones' time and feedback and also future
flexibility. Thank you.

Amy: It sounds like this will stayin IESG Evaluation, Revised ID needed, and
we'll put it on the agenda for June 30. I also have a new action item for
Murray to draft text on bis vs diff documents.

 o draft-ietf-oauth-jwk-thumbprint-uri-03  - IETF stream
   JWK Thumbprint URI (Proposed Standard)
   Token: Roman Danyliw

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

Roman: I appreciate everyone's feedback here. We do have the authors online if
there are any questions. I've seen the changes in -03 but can i just have this
in AD followup so i can double check that everything is clear?

Amy: Sure, you can let us know when that's ready.

 o draft-ietf-alto-cost-mode-03  - IETF stream
   A Cost Mode Registry for the Application-Layer Traffic Optimization
   (ALTO) Protocol (Proposed Standard)
   Token: Martin Duke

Amy: I have a Discuss in the tracker; do we need to discuss that today?

Martin: Mohamed dropped a new version this morning. Paul, you can be forgiven
for not having read it yet but i think it addresses your issues. When you get a
moment, please take a look. For now let's call this AD followup and I
anticipate we'll be able to go to Approved, Announcement to be sent shortly.

Amy: Okay, this will stay in IESG Eval and go into AD Followup and you can let
us know when it's ready.

 o draft-ietf-lamps-8410-ku-clarifications-01  - IETF stream
   Clarifications for Ed25519, Ed448, X25519, and X448 Algorithm
   Identifiers (Proposed Standard)
   Token: Roman Danyliw

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

Roman: Thank you for the feedback, everyone. As with the previous document
there are some good things in the comments I just need to follow up on. Can you
put it in AD Followup and i'll check all those.

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

 NONE

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-faltstrom-base45-10  - IETF stream
   The Base45 Data Encoding (Informational)
   Token: Erik Kline

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

Erik K: There will be a revised ID needed. Patrick had some questions about
what to do with the sec-dir review. I was waiting to see what Paul might have
put in his ballot but I didn't see a ballot from Paul.

Paul: I forgot about this document. I'll have a look at it today.

Erik K: I think some of the comments in the secdir review are not really things
the document can address, like why the space character was included and why 45
characters. The issue of a covert channel at the end of a message string is
something we might need to add some text about. If you have a chance to give it
some thought that would be appreciated. This will be revised ID needed unless
Paul wants to Discuss it.

Amy: So this goes into Approved, Announcement to be sent, Revised ID needed,and
you can take it from there.

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 NONE

3.4.2 Returning items

 NONE

3.4.3 For action

 o conflict-review-irtf-nmrg-ibn-intent-classification-00
   IETF conflict review for draft-irtf-nmrg-ibn-intent-classification
     draft-irtf-nmrg-ibn-intent-classification-08
     Intent Classification (IRTF: Informational)
   Token: Lars Eggert

 o conflict-review-irtf-nmrg-ibn-concepts-definitions-00
   IETF conflict review for draft-irtf-nmrg-ibn-concepts-definitions
     draft-irtf-nmrg-ibn-concepts-definitions-09
     Intent-Based Networking - Concepts and Definitions (IRTF:
   Informational)
   Token: Lars Eggert

Amy: Lars, do you have any idea of who might be appropriate to review these?
Rob said in slack that if nobody else grabbed them he would be happy to do
these reviews.

Lars: That's fine, Rob can take them.

Zahed: I have some interest in [the first] one.

Lars: These two seem pretty related so I think it makes sense if the same
person does them both. One is classification and the other one is concepts and
definitions.

Zahed: I can take both but my output will be delayed. Or you can give them both
to Rob.

Lars: Did he volunteer for both?

Amy: He did.

Lars: Okay, then if Rob volunteered for both, let's give them to him. You can
do the next one, Zahed.

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

 o Source Address Validation in Intra-domain and Inter-domain Networks (savnet)

Amy: I have no blocking comments so if there are no objections it looks like
this is approved. This is approved for external review so we will send a wg
review announcement and put it back on the agenda for the next telechat.

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 Remote ATtestation ProcedureS (rats)

Amy: There are no blocks in the tracker, so unless there's an objection now
this recharter is approved.

Roman: I appreciate everyone's review of this.

Martin: Between this and oauth and these new bofs there seem to be 8 WGs in the
space of this thing attests to this other thing over there. Maybe in Philly we
can have a beer and you can explain it to me. They all seem to have a lot of
overlap. But I trust you to do the right thing.

Erik K: I said the same thing to him in slack last night.

Roman: In fairness, that's a good question. This is a question I get from
others outside the IETF, to contextualize most of the work that's happening in
identity or authentication on some reference architecture, or you guys are
working on stuff for particular verticals, are you actually working on
different technical problems? I think both your questions are on point. If you
don't ask me to do that in the next week or two I can come up with something
notional, because I think we'll have something more usable to explain the
portfolio.

Amy: I'm hearing no objection to this rechartering for RATS, so we'll send that
announcement as normal.

5. IAB news we can use

Warren: None I can think of. I don't think there was anything newsworthy for
the IESG. There will be more discussion on the BOF call which happens in a
couple of hours.

Mirja: Can I add a minor point? We are creating a new IAB support group for
liaison coordination between IEEE and the IETF. The main reason why we're
officially creating this group is to maintain minutes and things in the
datatracker. We already have the existing liaison manager for IEEE, Russ
Housley, and before every IETF meeting he coordinates a call. It's a good
opportunity to create awareness for this on the IESG again and if you have WGs
who are related to this work you should probably be part of this effort.

Erik K: Will the IEEE call appear on the calendar?

Cindy: It appears on the IESG private calendar and will continue to do so; if
we schedule it in the datatracker it will also appear on the main IETF meetings
calendar.

Warren: I don't know if it's actually helpful for all of those calls to have
everyone show up.

Mirja: This is not really an open group but it's not specifically closed.
Everyone involved in this work should join. If it's a problem that these show
up on the calendar we can try to fix that.

6. Management issues

6.1 [IANA #1230687] Designated experts for RFC 9250, "DNS over Dedicated QUIC
Connections" (IANA)

Amy: This is just to assign this item to Eric, which we discussed at the top of
the call.

6.2 [IANA #1230049] RFC 9116 (A File Format to Aid in Security Vulnerability
Disclosure) (Paul Wouters)

Amy: Paul has identified Yakov Shafranovich and Edwin Foudil as designated
experts for this registry. Is there any objection to naming these two folks?

Paul: To clarify, these two are the main authors on the RFC itself so they're
the ones who spend the most time on this.

Martin: I was just going to ask that. Cool.

Amy: I'm hearing no objection to approving these two experts, so we will send
an official note to IANA.

6.3 Review Request for Possible Revision of the Tao of the IETF (Lars Eggert)

Lars: You probably saw that the Tao editors have prepared a new revision and
want us to look at it. Under this process in RFC 6722 it's the IESG that needs
to approve revisions to the Tao. We've had a bunch of discussions about whether
this should go out for community review or not. It raises the bigger issue of
whether this process in 6722 envisioned how frequently we would update the Tao,
much more frequently than we did when it was an RFC. I don't think we've
updated the Tao in years. So there are 2 questions. One is what we should do
for this revision of the Tao, and the broader question is what we should do
with future revisions of the Tao.

Warren: I think the Tao should be an RFC. I think we could copy and paste the
text into a webpage to make it pretty for people to look at as well but what
the IETF generates is RFCs, those are our work products, and having the message
that this is the sort of thing we use for our important stuff is useful. If
updating an RFC every year or so to change some text like what color the dots
are is too onerous, then we've got much bigger problems than this. From talking
to Paul who'd originally had the this should be a webpage discussion, the
original plan was a webpage that would be updated every month or two. It ended
up being every couple of years. I think it's an important enough and
foundational enough document, or set of text, that it should go through the
normal process. Whenever somebody comes to me about writing a document I say
the very best thing you should do, and the most important resource, is this
thing called the Tao. It's over here. I think it should be open to community
review and should follow our normal process and that's my soapbox rant.

Lars: Before we go to Francesca, I also wanted to point out that Jay and I have
been discussing this. There is a bunch of similar material we're maintaining
now like authors.ietf.org and chairs.ietf.org and so on. For none of them, we
have a lightweight community review system. We've been thinking about what we
do here. One suggestion would be to have, for lack of a better term, a content
team or something; people that can help Greg, who is our main comms person,
review things that will go on the public website in some form but don't
necessarily need to involve the IESG or formal RFC editing. So that would be a
solution for this one as well if we wanted to do it. I personally am fine with
having this go back to an RFC.

Francesca: I don't have a strong opinion about whether this should be an RFC. I
feel like I am also lacking a history and maybe someone can summarize how
previous IESGs have gotten there so we don't go back and forth and continue to
re-discuss the same thing. I have a very strong opinion that this should be
open for community feedback as Warren said. This is not a small update and my
mistake for [not reviewing], I always start with reviewing the docs first and
then checking the rest of the agenda and I ran out of time to review the Tao.
But the endpoint is that I haven't had time to review the whole thing and I
would not be comfortable with today approving it silently as I don't know how
many people in the IESG have had the chance to read it through. It's not like
with the other documents where we have an actual record of who has read it and
who hasn't, and who is okay with letting it pass and what the documents are. I
would be against approving it today and I think giving 2 weeks for community
review can't hurt. Sure, it's not a requirement, but I still think we want
community feedback and this is a big update. For what you were saying, Lars,
I'm a bit hesitant to have a team of people like you said. I think we need to
be careful not to exclude part of the community and when we relegate certain
discussions to certain lists and we make them more invisible to the rest of the
community, if there is not even a mail saying by the way this is happening
there, and we just assume people know this is happening there, people will get
surprised and we don't want to alienate the community. That's my opinion.

Alvaro: All I want to say is that 6722 is a consensus RFC. so the community
decided that. If we want to change what the community decided, we need to
change that RFC. None of us was in the IESG when that RFC was approved, and it
doesn't seem from reading it that consensus was relatively strong. It was rough
that there's no requirement from anyone except the IESG to approve changes. So
we can't just change stuff because we want to, we have to follow the process
whether we like it or not.

John: I think Francesca said two different things. One is we maybe should take
some more time to review those things; I also have not done so. The other thing
which is completely separable is should there be a community consultation. I
wanted to point out that it's not like the community lacks the ability to
discuss this on their own, they don't need our permission. The only thing we
have done is send an email to ietf@ietf. If one of you wants to send an email
to ietf@ietf and say we're planning to approve these changes, if you have
comments send them to the IESG, I think that's neither in nor out of the
process.

Warren: From looking at the RFC 6722, what it says is that the Tao was a IETF
consensus document that the IESG had final say about what's contained in it,
and the IESG has final say about what shows up in the Tao when it's on a
webpage. There's nothing in there that says that changes anything about whether
the IESG should be asking the community to review and provide feedback. I think
it's perfectly reasonable and we should say dear community, these are the
proposed changes and these are what we want to accept as a web page, but I
think also 6722 was written up as an informational document, we've run it for a
while, it's been ten years, and it doesn't really seem as though moving this to
a webpage has accomplished the change it often and early [thing], so we're just
going to decide that it was a bad idea and go back to having it an RFC. So
basically update 6722 to undo it and make it be an RFC again. And we will also
copy the content into a more readable form on the web. I'm happy to write that.

Lars: My suggestion would be that we send a message to Last Call saying there
is a sizeable change to the Tao being discussed, and point people to the
tao-discuss list and github to give their feedback and comments and then rely
on Niels and the others to incorporate it or not. The second one is I think I'm
going to ask for a brief agenda item for secdispatch and propose that we undo
6722 and go back to an RFC or do something else that works better than what we
currently have.

Martin: I'm fine with sending email to the community, that's common courtesy.
But this is a low stakes document and creating a huge amount of procedure
around a low stakes document seems backwards. This is not a standard, it
doesn't have a force of anything, no one ever cites the Tao when they're
talking about something we screwed up in IESG review. It's just a welcome
document that explains how stuff works if people are new. If somebody has the
energy to update this with current practice, we should make the bar extremely
low for them. Obviously there should be oversight so people don't just
vandalize the page and whatnot but let's have an informal let everyone know
what's going on, and if people have suggested edits we should have a github up
and people can propose a PR, and someone in power just to approve it. It
doesn't have to be the IESG; I would be happy with an officer to do that,
whether it's Niels or somebody else. And it's easy to fix if there's a mistake.
It's all super simple. It doesn't have to be this webpage, if people find this
hard to find, but for an RFC we have to go through this whole thing. What's the
value in that?

Warren: I disagree with you on the importance of the document. But we tried to
make it super easy to update, and stick it on a new webpage, and that hasn't
accomplished this. What it's done is it still hasn't been updated. There are a
lot of other places where we already have intro material. Chunks of this can be
copied and put in newcomers' discussions, how to participate in the IETF, etc.
If you want to put new and interesting info, that goes in the random web page
text, but this is its own standalone thing which is useful to demonstrate how
we work. It has some more reviews, I think it's more foundational. If people
want to make helpful comments, or helpful suggestions, we have a bunch of
resources where people can put those which are not this.

Martin: I'm not married to this particular webpage; I think having the github
there as it is in the intro is good. What's the problem we're trying to solve
here? If the problem is that people are not actually updating this frequently,
forcing people to go through the RFC process is not going to solve that
problem. If there's some other problem I'm happy to address that.

Zahed: I'm with you, Martin. I think the thing is adding this in the RFC
process doesn't solve how frequently we want to update. It puts a lot of burden
on this procedure. The other thing is that we have this tao-discuss mailing
list. Who are the participants of the mailing list? The community, I guess.
This is not an explicit member list we picked up. I don't understand why we
need to bring this to more announcements. Tao-discuss is there, whoever cares
about the Tao is supposed to be there. If you do all this discuss mailing lists
and put it somewhere else to get community feedback, then the system is broken.
I don't understand what you guys are discussing here.

Francesca: I also agree with what Martin has said. You convinced me that moving
it back to RFC is not going to help things. It's probably going to make it even
harder process wise. I do like that there is some flexibility in the process
and the IESG has a say on how much community feedback we think a certain update
will need. If the update is quite small I'm perfectly fine with just approving
it. In this particular case, with an update this big, I would not feel
comfortable to just go ahead and approve it. For the tao-discuss, I can check
but I think we do need to send an email to ietf@ietf or some wider list because
I don't think the people who are subscribed to tao-discuss are a wide enough
representation of the community. I think it's our responsibility to make sure
people are aware this is happening.

Zahed: I fully agree with you, we need to inform people. In that case we also
have tao-discuss, the IESG making a decision, and let the community know we
have done this. This is uppsoedt o be a small process thing and if someone
thinks it's really bad we can come back and fix it.

Andrew: For me, particularly when you're dealing with the Tao, which is such a
fundamental document to the IETF, I think it would be good to consult as widely
as possible. This is a really major document and I think giving it to ietf@,
etc for comment is enhancing the bottom up process. I definitely would agree
with Francesca on that.

Warren: Following on from what Andrew said, the Tao is really important. I
believe it's a foundational document and has a lot of history, adn a lot of
people refer to it. For other stuff, we have things like
ietf.org/about/participate/get-started and a whole bunch of resources from
that. I think the Tao is important, should get strong community review, or
other sorts of stuff which doesn't need community review isn't as foundational,
does not have the history behind it. That we can just stick on the website. If
you want to have a thing saying when you show up at the IETF don't wear
sandals, stuff that in the webpage but the Tao should get community review,
should be discussed with the community, and sets our view and ethos.

Francesca: I agree with everything you're saying, which is why I agreed with
you in the IESG mailing list that we should bring this up and discuss it. At
the same time, if you do want this to be published as an RFC, the process is to
actually write a document and get it through the process to revert 6722 as Erik
was saying.

Warren: Yes.

Francesca: That can be one thing, but for the time being, I think we can still
get community review and still make sure.

Warren: I fully agree with you. We should get community feedback on this.
Reverting 6722 would be a really long thing. There will be much navel gazing.

Francesca: Even that needs community consensus.

Warren: What I heard was a number of people on this call saying no, they think
it should not be an RFC, that it should remain a webpage, and that's what I was
responding to.

Francesca: I believe there are different types of updates. This is a big one
and needs community review. There might be a small one later on that the IESG
will consider that it does not need. I hope the IESG will be able to make this
decision about how much community review is needed for certain updates and
making sure the community is involved.

Warren: Then what makes the Tao special? Why not just say we're obsoleting the
Tao, we'll put random stuff on the webpage, and if there's something we think
is important we'll ask the community? The Tao is its own thing. It's different
from random musings people put on webpages. I don't understand how we can have
this is the Tao, this is our not quite foundational but sets a lot of our views
and ethos, but we've decided that we can change random bits without the
community. That's what the website is for; the Tao is its own thing.

Lars: Action items; I will send a notification or have the Secretariat send a
notification to last-call and point them at the revision URL and ask for
feedback on the tao-discuss list. I just sent an email to gendispatch to ask
for agenda time to discuss 6722. Funnily enough, what the current editors of
the Tao are doing is not what 6722 says they should be doing. It needs to be
changed anyway no matter what we do. I would much rather publish RFCs. There is
a slight issue here in the sense that Greg is always looking for material to
stick on the web page and do something else with and he likes stuff that has
community review or consensus because then nobody can point to him and ask
where this text on ietf.org came from and it's misrepresenting something. So he
prefers to take stuff from others. One problem with the Tao is that it's long
and also the name is completely cryptic to newcomers, nobody understands what a
Tao is without googling it. Because it's heavily edited by the community we are
probably, from Greg's perspective, there is a lot of insider stuff in here.
Although we try to make it friendly to newcomers it's actually not really
anymore. I think there is a discussion to be had which is unrelated to the Tao
of how much does the community allow the staff to craft material about the IETF
without running everything by the community all the time? That's separate from
the Tao. For the revision I'm going to send a last call announcement, we're
going to talk in gendispatch, and then we'll see what comes out of that. Greg,
if I spoke for you and I spoke incorrectly, please correct me.

Greg: That's all right, thank you Lars. You're absolutely right, community
review is great because I don't want to get out of line with what the community
thinks in the IETF. But it is true that the Tao and those kinds of materials
are intended for an audience that isn't currently in the community. It's often
helpful to try to gather input from people who won't be on ietf@ietf, for
example, for these kinds of materials and we do try to do that.

Lars: Amy, question to you. Can I send directly to last-call? I think I can.

Amy: I think you can as IETF Chair. If you have trouble let us know and we can
try and troubleshoot.

Lars: Okay then I'll just send that. Thanks.

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

Amy: It looks like this is about to expire. John, do you have an idea of where
the document is and if you'd like these early allocations to renew?

John: That one is in my queue and the answer is yes.

Amy: Okay, is there any objection to renewing the early allocation for this
document? Hearing no objection, so we will send an official note to IANA.

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

Murray: You may have seen the note that Ned Freed passed away recently. He's
been our longtime media types reviewer and he was also designated expert on a
lot of registries and you may see a flurry of replacement action items. If
anybody hears of someone that is willing to step forward and fill his shoes, or
succeed him, we're looking for that because that's important stuff that is
painful when it lags. I don't know what the process is for scheduling a moment
of silence during a plenary in the future but we should not forget that when
the time comes.

Lars: I talked to Alexey and he suggested I reach out to Pete Resnick to say a
few words at the plenary. If someone else has other suggestions I'm happy to
hear them, or I'm also happy to hand this off to somebody to coordinate. If
not, the stuckee is me.

Murray: Two other names I would suggest are John Klensin, because they worked
together on a lot of email things, and Nathaniel Bornstein who posted something
very thoughtful to Facebook and I think Dave Crocker as well. They all might
have stuff they want to contribute because they worked with Ned a lot over the
years.

Lars: Okay, I will see if I can dig up the email addresses and I'll ask them if
one or some of them would say something brief at the plenary in Philadelphia.

Amy: Anything else?

Lars: I'm looking through my action items. There's this long standing
discussion on what we should be doing with antitrust in the IETF, and there's
recently been a discussion between us and ISOC and the lawyers are disagreeing
slightly, so this is going to keep us busy for a while longer. The BCP 45 bis
should be out soon, which means we can close the last call experiment. That was
promised as part of that. You saw that the RFC Editor has started to execute
the transparency stuff, so there's a public auth 48 list now and that's all
looking fine. Otherwise you saw that Jay has put out the Covid requirements for
Philadelphia and I haven't seen any reactions to that yet either. Earlier one
participant was somewhat concerned we would enforce masks when they have a
doctor's order they can do without. Jay clarified that we do require it and if
that prevents you from participating we believe our remote participation
facilities are good enough. If you're not on ietf@ietf you might want to look
at the archive because there's a discussion on going related to management of
non-WG mailing lists. I think this was a topic we had discussed in the past but
I don't know if we had an actionable outcome. Brian Carpenter's message on that
thread was basically spot on, pointing people to the Note Well and that it
applies to non-WG mail lists as well. There's some discussion about not being
clear who the moderators are for a list and who to appeal to, so we might want
to consider doing an IESG statement on the moderation and management of non WG
mail lists. If somebody is interested in that, Amy can you give me an action
item to follow up and see if someone want to write one? It would be brief and
basically just say the note well applies, the mail list admins are also
supposed to act as moderators, and the appeals chain is to the IESG. Basically
those three things. I think that's all.

Francesca: I wanted to mention that we got the auth 48 archive and I wanted to
thank everybody involved and especially Sandy for setting this up. It only has
one email in the archive so far, just an introduction email, but I'm really
glad that we got this so it's there.