Narrative Minutes interim-2024-iesg-06: Thu 15:00
narrative-minutes-interim-2024-iesg-06-202403071500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2024-03-07 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Jenny Bui, Secretariat

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jenny Bui (AMS) / IETF Secretariat
Deb Cooley / Incoming Security Area
Roman Danyliw (CERT/SEI) / Security Area
Dhruv Dhody (Huawei) / IAB Liaison
Martin Duke (Google) / Transport Area
Lars Eggert (Mozilla) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat
Jim Guichard (Futurewei Technologies) / Routing Area
Mahesh Jethanandani (Arrcus) / Incoming Operations and Management Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Erik Kline (Aalyria Technologies) / Internet Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Jean Mahoney (AMS) / RFC Editor
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN)/ IANA Liaison
Orie Steele (Transmute) / Incoming Applications and Real-Time Area
Gunter Van de Velde (Nokia) / Incoming Routing Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Sandy Ginoza (AMS) / RFC Editor Liaison
Warren Kumari (Google) / Operations and Management Area
Éric Vyncke (Cisco) / Internet Area

OBSERVERS
---------------------------------
Greg Wood
Jeffrey Zhang

1.2 Bash the agenda
Liz: Does anyone want to add anything new to today's agenda? Besides the
Dispatch thing. Anything you want to change?

1.3 Approval of the minutes of past telechat

Liz: This is our second formal telechat in a row. The minutes from the February
29th telechat needs some more time for review before they can be approved so
those will be on the agenda for approval at the first formal telechat after 119.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Murray Kucherawy to find designated experts for RFC 9422 (SMTP Server
       Limits) [IANA #1358457].

     o Murray Kucherawy to find designated experts for RFC 9530 (Digest
       Fields) [IANA #1359278].

     o Murray Kucherawy to find designated experts for RFC 9535 (JSONPath:
       Query Expressions for JSON)[IANA #1359744].

Murray: All three of mine are in progress.

     o Paul Wouters to find designated experts for RFC 9421 (HTTP Message
       Signatures)[IANA #1359281].

Paul: I have two people, but I forgot the names. I'll suggest it next time.

   * OPEN ACTION ITEMS

     o Warren Kumari and Murray Kucherawy to follow up on a bis document for
       RFC 8126 regarding designated experts.

Murray: I don't know if we want to keep this on now that we're not blocked by
Barry anymore this just becomes regular document development. Should we keep an
action item on it? I'm fine if we want to, but it seems kind of a waste.

Liz: It's up to you guys, would it be helpful to keep reminding you about this
everytime?

Murray: Does anyone want to keep it?

Roman: No, it's been on 23 telechats. I think we got to re-scope the action.

Murray: I think we call this done because we have a path forward where before
we weren't sure, now that we're not waiting on Barry and we are proceeding.

Liz: Ok, we'll remove this from the list for you.

     o Andrew Alston to email the RSWG regarding document authorship/
       editorship with regards to the number of authors listed.

Liz: We talked last time about someone else taking this over, do we want to do
that now or wait until 119?

Andrew: I was going to take this up with RSWG in person, but they're not
meeting. So who wants to take this over? Volunteers? I nominate John.

John: Thanks? If nobody else is willing to pick this up, I will pick it up but
I reserve the right to close it in the very next meeting.

Paul: What was the exact question you had for them? To talk about more than 5
authors?

Andrew: Basically, the current text in the document, I can't remember all of
it. I'd have to check my notes. In the event there are 5 authors, the IESG has
to go ahead and appoint an editor. It doesn't give any scope for us to tell the
chairs to appoint an editor except for that the whole thing needs to be
clarified. When I raised this with one of the chairs, he said to me 'That's
insane'. The current wording of the document is a little bit nuts because it
puts everything on the IESG, it doesn't actually allow us to say  there are
more than 5 authors, etc. We've always have repeated that In the document is
kind of optional because it's informational, but at the moment the text is a
bit weird.

Paul: That seems like a quick email to the RSWG list would be fine?

Andrew: Yeah, except I remember Mirja you had some comments to me about this as
well, I think we talked about it briefly online.

Mirja: I only said that I think the right process here is to just as an
individual contributor, to propose a draft to RSWG and see what the group says.
I don't think that has to be something the IESG drives for.

Paul: I was wondering why this was an IESG item.

Andrew: I'd have to go back to my notes. We had quite a bit of discussion about
this at the time.

John: There we go. I agree with my esteemed colleagues and following it right
back to you, Andrew and taking it off the IESG.

Andrew: I'm quite happy to take it off the agenda.

John: If you want to talk about it offline, I'm happy to look it over.

Andrew: Let's do that. Let's take it off the agenda then.

Liz: Ok, we'll remove this one as well.

     o Lars Eggert and Warren Kumari to 1) draft a revision of RFC 4858,
       2) draft a revised IESG Statement on Document Shepherds (original
       statement October 2010), and 3) update the WG Chairs wiki to point
       to the new IESG Statement.

Liz: Neither Lars or Warren are here, so we'll keep this in progress for them.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-bess-evpn-irb-mcast-11  - IETF stream
   EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding (Proposed
   Standard)
   Token: Andrew Alston

Liz: We have no discusses so unless there's an objection now; it looks like
this one is approved.

Andrew: This is going to need a revised ID, there's a bunch of comments to
follow up on. Other than that, thank you everyone for taking the time to review
it. It was quite a heavy document. I figured I'd give you all something to
remember me by in the final telechat. Thanks for the detailed reviews. We'll
put this in revised ID, and I'll get it done before 119.

Liz: This one will go into approved announcement to be sent, revised ID needed
and Andrew, you can let us know when it's ready.

 o draft-ietf-opsawg-mud-iot-dns-considerations-12  - IETF stream
   Operational Considerations for use of DNS in IoT devices (Best
   Current Practice)
   Token: Robert Wilton

Liz: We have a couple of discusses, Rob, do you want to discuss that now?

Rob: I don't think so. Paul discussed to me during the week, it sounds like he
thinks there's some significant changes required in this document. I'm not sure
it'd be easy to resolve it here now before I step down. I think we just need to
wait for the authors to respond to these comments then it's up to Mahesh to
take it forward unless Paul or Roman wants to say anything here.

Paul: Let me bring up a problem because The core problem of Mud has always
been, the whole point of Mud that you’re constrained to a device to what
communication it is allowed to have with the outside world for additional
security. The problem is of course, you allow it to do random DNS lookups. It
can basically communicate to the world either through DNS answered or trading
data by sending queries and so it's a really core concept of that data handled
properly or otherwise, it just defeats the entire purpose of Mud.

In this case, there's a real mix up on how these parts talk together. If the
Mud controller is not the CPE that is also the DNS result then all hell breaks
loose. There's no protocol defined to how these separate parts have to
communicate with each other to keep information in sync. I think this might be
unpublishable as is because of those fundamental problems. I tried to phrase it
as nicely as I could, but not sure if it's salvageable.

Rob: My reading of that is that you think it would be better to send it back to
the working group and say this needs more thinking and bring it back when it's
been addressed. You think that's a better approach here?

Paul: Normally, yes but I know that at least one of authors will be at 119 so
many some hallway talk beforehand will be more useful before taking action.
There's a problem here that needs resolving.

Roman: Another to approach this is an applicability statement because the way I
read the text, and this was in my support of what Paul wrote, I'm not sure
we're talking about a Mud only ecosystem or whether we're talking about all IoT
or whether we're scoping it for Mud in the home kind of network. I think those
are all different proportions of it, and the recommendations or even the
observations are not clearly chucked kind of against it which I think is
creating a lot of confusion because depending on which version of that you can
interpret this document to be about, the feedback makes complete sense or it
doesn't make sense.

Zahed: I read this one thoroughly and like multiple times just to understand.
At first, I thought it might need to rewrite and we can help with that and
publish it, but then when I read Paul's discuss I thought this is much more
fundamental issues that needs to be fixed before a rewrite of this document is
not going to help. I think the proposal you have, Rob, is the right thing to
do, but I don't know what others think. First, is sending it back to really
work on the fundamental problems and all that stuff.

Rob: It feels to me is the next steps is to have a chat with Paul at IETF even
with the authors, that would be a good next step. If the outcome of that is
actually some misunderstanding that needs to be fixed then that's fine which
seems unlikely based on this conversation. But otherwise, it sounds sending
this back to the working group and clear guidance as to what they need to
clarify and also constrained use case. So that's my conclusion.

Paul: I think that's the way forward, and i'll keep you up to speed at 119.

Rob: Thanks everyone for review.

Liz: This one will stay in IESG evaluation, and it sounds like it will need a
revised ID?

Rob: I have AD follow-up might be better.

Liz: Ok, We'll put it in AD follow-up. Rob, just so you know, this document has
3 downrefs so we'll also need to know if those 3 need to be added to the
downref registry.  1794, 9019 8094, so by the time this gets ready for
approval, we'll need to know about the downref registry.

 o draft-ietf-gnap-core-protocol-18  - IETF stream
   Grant Negotiation and Authorization Protocol (Proposed Standard)
   Token: Roman Danyliw

Liz: We have a couple of discusses, do we want to discuss it now?

Roman: I don't, I appreciate the reviews. Unless Paul or Francesca.

Paul: First of all, apologies for not completing the review yet I put in a
discuss that's partially a placeholder because there's a bunch of normative
references, sorry, normative languages is where I'm really confused about.
There's a lot of ‘mays’ that seem to just be like ‘cans.’ Like a client can do
this, instead of the main normative reference makes no sense. One of the other
things, which i'm not sure we would technically call that discuss worthy is
that there's a lot references of the document to other sections in the document
itself, but there's are visible as blue hyperlinks that appear to go to an
external document. Normally, when we have references inside a document they
tend to be between square brackets and usually a section number only. Here, it
seems like the authors have done both. Both are linked to foobar in another
section is a link followed by in between brackets or braces, the section number
with the same link added it to. I find that blue link kind of bleeds through
the entire document quite badly. I was wondering if that was talked about or
not or whether we could just tell them to place square brackets around anything
that's a link inside the document or whether to just not do the double
references anymore and only just put the section number there. Like, make the
text of the name of thing they're referencing, not a hyperlink.

Roman: I read the document in text format so I didn't even know what you were
talking about until you said it and I pulled it up in the HTML. You can
certainly go to the authors and talk to them about why they chose that style
and approach, I don't know. Like I said, I read it in text format so I didn't
even see that. As to the discussions on the mays, that actually came up in the
Last Call sector review so if you have concerns about specifics of a family of
those mays you should bring it up because that would be helpful. We've had a
little bit of that discussion already about why some of the normative language
needs to look the way it looks. Russ and Justin did a long volley on some of
this.

Paul: There's a few other shoots where I think it should be must, like if we're
talking about authentication, a client should do this or a surfer should allow
the client access that seems really scary in an authorization protocol.

Roman: I appreciate the general concern. I think the specifics matter here
because a number of others may or may not have been discussed. I don't know
which ones are concerning to you so if you could enumerate those we can work
through it.

Paul: I'll complete the rest of them today and update the discuss.

Roman: Francesca, do you want to talk to about the media registration type that
you know about then all of us combined?

Francesca: It's Orie who caught that, if he wants to say anything more.

Orie: The document replies on Json Web Tokens or the Json Web Tokens VCPs,
there's this recommendation to use explicit typing. Explicit typing takes a
media type and so although you don't see the application prefix next to the TYP
example, it's there. These media types are to assumed to exist but they’re not
registered in this document and I don't think they're in either of the existing
registries. In addition, +JWXD is a structured syntax topic so you would expect
to see the registration required for that structure syntax suffix and the
registrations for the media types that use them.

Roman: Thanks for the details, the working group and authors are going to have
to work with you on that.

Orie: I'm happy to help, I can point them to examples.

Roman: I think given everything we talked about, it's a revised ID needed.
Thank you for the deep review on this very elaborate document.

Liz: This will stay in IESG evaluation with a substate of revised ID needed.

 o draft-ietf-lamps-cms-kemri-08  - IETF stream
   Using Key Encapsulation Mechanism (KEM) Algorithms in the
   Cryptographic Message Syntax (CMS) (Proposed Standard)
   Token: Roman Danyliw

Liz: We have no discusses unless there's an objections, it looks like this one
is approved.

Ok, not hearing any objections. Roman, is this ready to go?

Roman: I've not had the opportunity to look at all the comments yet given the
document load this week. So I could just have it in AD followup so I can just
take a look at everything that's coming.

Liz: This will be approved announcement to be sent, AD follow-up.

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-lamps-e2e-mail-guidance-15  - IETF stream
   Guidance on End-to-End E-mail Security (Informational)
   Token: Roman Danyliw

Liz: We have a couple of discusses, do we want to discuss this now?

Roman: I'd like to talk about what Rob and Murray discussed here, so the
central premise here is why is this published as informational versus a BCP.
I'm paraphrasing a little bit about the working group deliberations, but kind
of a simple answer is, there was a feeling that BCP means you have full
confidence and all of the recommendations that you are given to the level of
being a BCP. This a new area, there's a lot of different kind of
recommendations there. This is notionally a little bit of a profile so that's
why it's published information. So this is about the ability, you can confirm
to the following set of recommendations as to explicitly calling it an
applicability statement. The way the authors editorially chose to handle that
is to use the language they put in the directory section about what it means to
be a conforming MUN.

Murray: That sounds an awful like how we define applicability statements in
2026, that's why I made that suggestion. I don't intend to hold this document
up, I just wanted to ask the question, and they might consider going the
applicability statement which requires this to a standards track. I'm not going
to say this needs a Last Call for my purposes, but we might want to be diligent
about doing that if you agree, but mostly, I just wanted to ask the question.
Thanks for the background.

Roman: From what I remember what the conversation being, there's not a interest
in doing this as a PS. I mean, there's confidence in the recommendations based
on informational. I will say that if we do this to PS, to the PS bar, I would
have poked a lot harder about some of the of the design guidance they're
suggesting, and wanting the basis for those recommendations. But since it's
informational, I had a little bit of a lower bar. Then you mentioned in your
comments about the UI design and all that.

Murray: Then i'm just left feeling weird about BCP14 language in an
informational document. I can sort of turn a blind eye this time, I guess.

Roman: I think there might be a bigger conversation because this comes up not
infrequently where we ask the question 'why are we using those keywords in
informational documents?' This is probably a retreat topic.

Murray: Those words are meant to talk about conformance and how do you conform
to that has no normative force? Yes, we can save this for a retreat. I don't
need to be in the way for here, if we're going to talk about it again later.

Roman: We'll put a marker, because I think we'll definitely see this when folks
write informational architecture document as well as the most common one I can
think of.

Murray: I'll clear.

Mirja: I never link those two right? Because you also use normative language in
experimental specifications because you think this is not ready for a standards
track. This was kind of similar for me, information doesn't have the same kind
of level of agreement or impact but this is an independent question for me from
using normative language because normally languages are only there to make
whatever's written in the document more clear about what the requirements are.

Roman: I believe that is the convention folks have used here and folks have
used when they put normative language and informational architectures as well.
Like, we mean this in this particular way.

Gunter: It doesn't hurt, I don't think it breaks anything if you do that. It
just makes it more clear.

Mirja: Even if you don't use the upper letter words, right? It doesn't change
the meaning, the upper letter words are just a way to make things more clear.

Murray: I think it's more than that.

Mirja: That's what the BCP says, even if you decide to not use, follow this
kind of framing. It's still kind of the same thing. This is just a way to make
it more clear.

John: I just rejected an errata on the flipside of that. The authors didn't use
the uppercase words so the spec is no good, and I was like 'no, that's not
right.' The lowercase must, but any fool can see it means must..

Mirja: We cannot mix it, right? If you use uppercase MUST then you must use it
consistently for the document, but if you decide not to use it at all then it's
kind of the same thing.

Murray: You don't need to use those words to be normative. It's been pointed to
me so many times that you can just say something complying with this protocol
does the following without using MUST and SHOULD and you're still specifying.
The needs for conformance is still laid out in the document. I'm looking at
2026, and we actually make a distinction between a technical specification
applicability statement requirements levels and informational is a completely
different thing. I understand what you're saying Roman but this is why it's
weird for me to have an informational that actually specifies something that
has compliance requirements. Retreat topic, I get it. Let's keep going.

Rob: Roman, back to the original point on this. I had a different view of this
in terms of BCP versus informational. My general feel that people outside of
the IETF don't necessarily care about a difference that much between the
different tracks within IETF. But in the name, BCP, best current practice, sort
of gives to me better guidance outside that we want you to be implemented this
and doing this. I think that was more my drive as to why I was saying, I prefer
BCP. I think it's just more helpful to the community outside the IETF and if
there's bits in the document where we don't have 100% confidence on that then
maybe those bits could be labeled in the document saying, 'actually, i'm not
sure about this.' I think that would be a better outcome here, but i'm not
holding a discuss and also, i'm off the IESG very soon.

John: I'm not going to pick up a discuss on this point either, but i'm not
especially comfortable with the idea that informational is just the lowest run
on the standards track which is kind of what I heard 'you know, I would've
reviewed it harder if it was a standards track document.' So no, let's not
reinvent the 3 level standards, correct? But just stick the lowest level on
informational, I don't think it's a good idea.

Zahed: So why do we have this kind of different informational, experimental,
and standards track then? What is the purpose of an informational document?

John: Retreat topic.

Zahed: Yeah, definitely, retreat topic but I understand like the philosophy
that we should not have three different categories for standards track, but
informational is for information sharing, right?  That's the general meaning of
it. Functional sharing should not have a compliance requirement where a
standard track should have it.

Must have a complex requirement, the standards track have a must do it. If you
say, 'i'm confined to this standard, you must do that and informational is just
to implement something, to deploy something or to use something. Informational
document is giving background, giving other information to make that happen.
That's basically my criteria, when I look into an informational document, I
definitely see it breaking the internet but I don't really see there's a hard
limit, and maybe we're a bit loose looking at it. You definitely have it lower
than a standards track, or at least to me.

Roman: To further confuse the issue, I know that there's a couple of SEC
working groups that will publish informational only if there's not running code
that backs it and they feel like to do a PS in their work, despite that's not
what RFC says. That's only done with a PS when you have running code,
otherwise, they'll publish it as informational.

Lars: As many of you know, this is an evergreen topic whether 119 language
belongs in informational or non standards documents or IRTF documents for that
matter and what exactly it means. If you want to discuss it in Brisbane or in
the retreat then that's fine, there's ample of background material from decades
past that we can look at. My suggestion would be retreat.

Roman: I'm editing the Wiki with Murray's name next to the topic, thank you. As
it pertains to this document, thank you for all kinds of reviews. If we can
just mark it as revised ID needed.

Liz: This one will stay in IESG evaluation with a substate of revised ID needed.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-tenoever-tao-retirement-04  - IETF stream
   Retiring the Tao of the IETF (Informational)
   Token: Lars Eggert

Liz: There are no discusses so unless there's an objection now, it looks like
this one is approved.

Hearing no objections, it looks like it's good to go. Lars, is this ready to go
or do you want to do anything else to it?

Lars: I think this is ready to go.

Liz: Then we'll go ahead and send this document action announcement.

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

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

 NONE

4.1.2 Proposed for approval

 o Workload Identity in Multi System Environments (wimse)

Liz: This has enough positions to pass so unless we have an objection now; it
looks like this charter. Do we approve this charter?

Ok, I think we can call that approved. Murray, is this ready to go? Do you want
to do anything else?

Murray: I just need to verify what's in there. Are they the intended chairs and
not the previous BoF chairs, and yeah this is ready. If we're fine then ship it
the way it is and I can edit the chairs later. I don't have a preference, but
that's the only thing I can think of that I need to do still.

Liz: Do you want to just get that done today?

Murray: I'll message you over Slack when I know it's right.

Liz: Ok, so why don't you go ahead and take care of that and you can just left
us know when that's done and we can just send it out.

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

Roman: I think the primary thing to convey is the IAB is ready to support us
with all the BoF activities that we're planning at 119 meeting. Mirja, Dhruv,
Lars, anything?

Mirja: I don't think so.

Lars: I wasn't on the call, so no.

6. Management issues

6.1 Early registration of COSE Header Parameters c5b, c5c, c5t and c5u (Paul
Wouters)

Paul: They were actually done by IANA already. I just got a message from
Sabrina before the meeting.

Liz: Sabrina, do you want an official note that this is approved or is this
already taken care of?

Sabrina: This is actually done already so we're good on our end.

6.3 Designated experts for RFC 9421 (HTTP Message Signatures)[IANA #1359281]
(Paul Wouters)

Liz: Paul and Francesca have name Justin Richer and Manu Sporny. Does anyone
have any objections to naming these two as the designated experts for this RFC?

Ok, hearing no objections so we'll call this approved. We'll send that official
note to IANA and we'll mark that action item as done for you,  Paul.

6.2 ALLDISPATCH Agenda (Martin Duke)

Martin: I checked in with the ALLDISPATCH chairs a couple of days ago and it
seems like they got things under control. They're probably looking at about 12
topics, 15 minutes each. They're pushing back on some things, but I did want us
to take a very quick look at this. If there's anything an AD particularly wants
to gran, they can kind of jump on the alldispatch list and claim it, and that
would make it shorter which is good.

To give people a chance to read what these things area and get a good overview.
If anyone sees something they want to discuss, please just say so. I emailed
this to IESG only, so if there's anything that you want, if you actually want
to click on any of these links, you can.

Paul: The TLS verifiable credentials, is there a reason this isn't just going
to TLS? Why does it need dispatching?

Martin: I don't know.

Mirja: Can I quickly ask why we're discussing this rather than the chairs as
this was done in previous dispatch meetings as well. Did the chairs ask for any
kind of input from the IESG?

Martin: They did not, but I did want all to pay attention to this stuff that's
going on the agenda. If we wanted to grab it or we could pull it.

Anyway, Paul, if you have questions about the TLS thing, I would suggest
getting on the alldispatch list and start a discussion about it. The other one
that we talked on Slack about a little bit, is the dots one, I don't know where
we ended up with that but I have to drop actually and i'll see you all in
Brisbane.

Rob: So the DOTs Yang model is on here, and I think the question is here it
turned up in NMOP being presented, but I think they turned around and said 'no
it's not in scope.' I had a question as to whether SAG would be the place for
this because of security? The other, I think happy-eyeballs-3, since v1 and v2
were done with V6OPS, is there not a place to just take that to V6OPS for the
v3 version? I haven't read any of the comments on it.

Paul: I don't think the happy-eyeballs in this case is only limited to v4 and
v6, right? It includes many more things.

Rob: Is that the reason why? Ok, fine.

Lars: To me this looks reasonable, for TLS, i'll trust the chairs to make the
call. We should check if they are agenda shopping or venue shopping and whether
these people are also asking for slots in other working groups in which case
should not happen. There was the whole point of all the specialists to
centralize this thing. So we should ask the alldispatch chairs to do is send
this proposed agenda around and tell the other chairs, if anybody is asking
about any of these, you're on alldispatch.

Mirja: I have another question which is more about the process so far. Did we
get more requests that we have time or did it just match, like in general did
people react positively to it? What's the impression, Martin?

Lars: Martin dropped, and I don't think we know. This would also be a question
to the chairs. We should probably try to schedule a postmortem of some sorts
with the chairs.

When are our breakfasts? Do we have a Tuesday breakfast?

Mirja: Wednesday.

Lars: Wednesday, so maybe we can slot that into the Wednesday IESG breakfast
while it's still fresh in the chairs mind to see how it went. I think probably
a half hour is fine. Could somebody in the Secretariat invite the alldispatch
chairs to that?

Liz: Sure. I thought there was something else we wanted to talk about, but
since we're not having the Monday morning meeting. Sunday and Wednesday are the
IESG only meetings.

Lars: Mirja, Roman, and me are getting together after this call to bucket these
candidates topics into slots.

Liz: Ok, why don't you guys do that first and then maybe we'll invite people.

Lars: It has to be on Wednesday though because alldispatch has to have happened
before we can do that. I don't think we can do that on Friday because we're
always running out of time on Friday. For that one, I think we can just stick
in for Wednesday or we can shrink it.

Mirja: I can imagine that the IAB would be interested to also provide feedback
about this, but we can pick it up on Friday again.

Lars: Sure, but this is an IESG experiment.

Mirja: Right, but the IAB is in the loop of onboarding new work or whatever. So
I believe people would have opinions.

Lars: How is the IAB in the loop of onboarding new work?

Mirja: Because we provide feedback to the IESG about new work.

Lars: Of the charters.

Mirja: I guess IAB people would have input for you as well, if you want to hear
it, it's your decision but i'm pretty sure they do.

Lars: I mean, I think we're going to hear it whether we want to or not, but the
thing is the IESG and the alldispatch chairs really need to decide if we want
to run another one of things or not. I think the larger we make the group, the
less we're going to come to a conclusion.

Mirja: I guess the conclusion lies with the IESG only, and not with the chairs.

Lars: Correct, but we want the input from the chairs.

Mira: I also agree that probably there is not enough time on Friday, and it
probably doesn't make sense to have a huge group, but we can pick it up Friday
again with the IAB.

Lars: Sure, but as I said, we're always running out of time on Friday. If it
goes terribly, or if things went terribly then by all means, tell us about it
on Friday. I think the meeting with the chairs should be on Wednesday.

Mirja: Yes.

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

Rob: The attempted announcement that Greg was going to send out, was the
conclusion just to leave off the IESG sensitive to the LLC, is that the
conclusion?

Roman: I don't understand the question, can you say it again?

Rob: In terms of Greg's announcement, as to who's been appointed to various
bodies and things like that. There's one for the IETF LLC, and the question as
to which IESG representative so currently, you were listed there, Roman. And I
said to him, I will discuss this and then we'll know who leads or gets pushed
off. I think that's one thing we need to close in and let Greg know because the
report goes out next week some time.

Roman: This is about who is the IESG appointee on the LLC board.

Mirja: Doesn't the IESG usually decide that on Sunday?

John: Usually it does.

Mirja: I think Greg just needs to take it off the list for now, if he wants to
publish before Sunday.

Greg: The idea is announce this next week since most of the items have been
decided as a lead into the meeting so people going into the meeting kind of
know what's going on. I'm happy to remove the IESG appointment to the LLC board
of directors bit, and not that it'll be decided during IETF 119, if that's ok.

Lars: That's fine, and the effect of that change is actually at the board
meeting in March which is the week after IETF anyways so you do another if you
wanted to. News item, sayings transition that has happened. I think technically
we actually want to wait until after Wednesday when the new IESG has been
seated because they need to make the decision. We can do it on Sunday, and they
can already vote, but I think it's the new IESG that decides on that case. I
strongly urge you to pick Roman and nothing else makes sense.

Greg: Ok, i'll update the text and share it around with you. Thank you Rob for
flagging it.

Lars: I put the side meeting wiki into the Slack since we have a little bit of
time, maybe we can take a quick look and see what we have so far and whether
there's anything that's sort of raises eyebrows like a working group using 10
slots or something. I haven't scrolled down, but the stuff on Monday seems fine?

Mirja: This is not a new observation, but I feel we have a lot of side meeting
that are just kind of continuous side meetings that they put in every time.

Lars: What is this IVY working group? There's a bunch in OPS. Is this working
group business? There's one on Monday and Tuesday.

Mirja: It says liaisons to BBF, Broadband Forum, and I already flagged this
with our liaison manager so we don't know much about it yet.

Lars: If this is a working group session then it should be a working group
session.

Mirja: This is a coordination with BBF, but again, our liaison manager should
be interested.

Dhruv: On the IAB mailing list, this was being discussed. The request came from
BBF folks and they wanted some BBF folks to be on the call as well so there
will people joining in from the BBF side, there of course, would be members
from the working group. I did not understand why they have to rush to it but
there's some internal reason for that, and I think the BBF folks are in the
loop as well.

Mirja: Our liaison manager, David Sinicrope wasn't in the loop, but he's aware
now.

Dhruv: But we can make sure that's done from the IAB side as well.

Roman: Is there any insight to the Thursday HTTP, TBD slot?

Mirja: I have no insight, but I remember Mark was also having this kind of
meeting the last 2 times, and I think he was always kind of design team like,
discussing very specific issues that didn't have enough time in the working
group. This is a good practice is another thing, but that's what happened the
last 2 meetings.

Roman: Isn't that we are not allowed to do?

Mirja: If it's not really an extended working group meeting but more design
team or author thing. I don't know, but you should talk to Mark, I guess.

Lars:  These are all open meetings, right? So, otherwise they wouldn't be on
the side meeting wiki. So they can just go somewhere. So I'm a little bit
concerned about all the ones that are sort of working group related. We talked
about the IVY, but they also have the Monday one, which may or may not be about
a call. Then there's the CCAMP on Wednesday, it's all the same person who's
asking for this, Italo Busi. There's another CCAMP one on Thursday. Those of
you should double check that these are actually legit side meeting topics and
not sort of creeping.

Dhruv: I think we should push back. I can see on some of them being just
authors getting together and just discussing things. That's what it looks like.

Lars: They don't need a meeting room for that.

Mirja: They don't need a meeting room, and we should make them aware that these
are open meeting, and not close meetings.

And did you see APN is back on the agenda here?

Lars: Yeah, but that's not a working group.

Mirja: I'm just saying.

Lars: They're talking about deployment so that'll be interesting.

Mirja: There's a new draft that specifies an extension for the application tp
prove this information, which was like a lot of discussion where people were
saying this is not reasonable, but I don't know.

Rob: In terms of, Lars, your comment about whether working group work is
leaking into these side meetings . I will check for the IVY ones, and I get the
feeling it's yes, possibly. So I think IVY's only got a single slot and then
maybe the agenda time meeting is just focused on slides and drafts and things,
and actually they need to be having a second slot of having more time for some
of these topics. It does feel that some of the working groups are pushing work
that lots of participants might be interested in, into side meetings. I think
it's a valid concern.