Narrative Minutes interim-2024-iesg-22: Thu 14:00
narrative-minutes-interim-2024-iesg-22-202410241400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2024-10-24 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Jenny Bui (AMS) / IETF Secretariat
Deb Cooley (Department of Homeland Security, Cybersecurity and
 Infrastructure Security Agency) / Security Area
Roman Danyliw (CERT/SEI) / IETF Chair, General Area
Jay Daley / IETF Executive Director
Liz Flynn (AMS) / IETF Secretariat
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Routing Area
Mahesh Jethanandani (Arrcus) / Operations and Management Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Web and Internet Transport Area
Tommy Pauly (Apple) / IAB Chair
David Schinazi (Google) / IAB Liaison
John Scudder (Juniper) / Routing Area
Orie Steele (Transmute) / Applications and Real-Time Area
Sabrina Tanamal (ICANN) / IANA Liaison
Éric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area
Gunter Van de Velde (Nokia) / Routing Area

OBSERVERS
---------------------------------
Robert Sparks
Greg Wood

1.2 Bash the agenda

Liz: Does anyone want to add anything to today's agenda?

Roman: I want to do a little bit of 121 prep housekeeping things so could we
have a marker for that?

Liz: We can add that.

1.3 Approval of the minutes of past telechats

Liz: It's only been one week since the last formal telechat and we normally
have two weeks for minute approval, so we have nothing to approve here today.

1.4 List of remaining action items from last telechat

Roman: Could I have an action item that I think I took out of the last
informal, which I took an action to make a proposal for the IESG on adding a
box to the registration system to say willingness to be a working group chair
just like you do for serving on NomCom?

Liz: Sure. We can add that action item for you.

   OUTSTANDING TASKS

   * DESIGNATED EXPERTS NEEDED

     o Zahed Sarker to find designated experts for RFC 9653  (Zero
       Checksum for the Stream Control Transmission Protocol) [IANA #1378063].

Liz: He's not on the call today so we'll mark this in progress for him.

     o Warren Kumari to find designated experts for for RFC 9660 (The DNS
       Zone Version (ZONEVERSION) Option) [IANA #1385320].

Warren:  I have one person already who said that they're ok with that. I'd
asked three of them. Can we put an action item a little bit later in the call
to approve at least one of them? Is that doable now or not?

Liz: Sure. We can do that.

     o Murray Kucherawy to find designated experts for RFC 9559 (Matroska
       Media Container Format Specification) [IANA #1385324].

Murray: Ok.

   * OPEN ACTION ITEMS

     o Orie Steele, Francesca Palombini, Murray Kucherawy, Mahesh Jethanandani,
       Warren Kumari to write draft of IESG statement addressing issue of
       credit in documents & the importance of capturing and addressing all
       comments as a necessary part of the consensus process, mostly
       pointing at existing advice.

     o Murray Kucherawy and Éric Vyncke to create a draft IESG statement
       about using 2119 language.

Liz: I know we are talking about later today and same with the second one, the
statement about 2119 language, those are both on today's agenda, so we will
just mark these as in progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-rats-eat-media-type-11  - IETF stream
   Eat Media Types (Proposed Standard)
   Token: Deb Cooley

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

Deb: So I'm fine not discussing it. I think he's working it, which is fine as
you should. The author, that is.

Francesca: Just to go back to this one, so my discuss is going to be easily
cleared on this document, and the authors have already replied and they posted
the review on the media types mailing days so that's not a problem, but the
second part of my review that I put in a comment because I don't think it
should be blocking on this document is actually related to the other RATS
document that we reviewed, I think last time I chat or a while ago and I I feel
like this one defines a media type for something that is also present in that
one, the EUCC UJCS. What they call JCS, but it doesn't have a direct reference
to that document. I think that was Roman's document by the way, not that so I'm
still holding and discuss on that one and and Orie has been also having
conversation with the author there and I I would prefer that this was held
until that one was also approved just because it's defining many time or it's
registered media types that are defined there or like for structures defined
there.

Deb: I'm fine holding it and that's not a problem, but do you want things
referenced both directions, like from one to the other or from here to UCCS?

Francesca: Well, this is only for this UJCS that appears in the the other the
UCCS document in an appendix that says this appendix is informative and we're
not defining anything, we're just giving a name to this thing and we call it
UJCS. This document says, register media type for UJCS, which is a claim set as
the finding reference to OJWT. So it doesn't even reference that other
document, but there is, they use the same name, but it doesn't even reference
that document and that appendix which is informative.

Roman: I'm completely with you. It's a weird thing because the other document
says we're not doing anything related to kind of JSON, this is a completely
kind of CBOR kind of thing and here's this extra informative thing, and now we
have another standards track document which is treating this thing that is
informative. A throwaways not knock, not entirely fair, but like it's an
informative thing that just kind of got added, but now we're registering media
types in a PS like it's a first order thing, and that seems odd.

Deb: This seems like what happened with the EAT document, right? Where they
weren't registering something that we eventually forced them to register.

Orie: Which EAT document?

Deb: The first one. The one that they ended up running back through the process
without the manifest suit document as a normative reference but they ended up
with something that they weren't registering, but that they referred to.
Actually I think it was Francesca too, said no, you need to register this
thing. They did after much gnashing of teeth. So I think this looks similar to
that just from the discussion.

Orie: I don't have a discuss on this. I have no objection, right? I support
Francesca's point in particular the media type review pieces, I think the most
important for this RATS EAT media type document. Your question Deb about
references from RATS EAT media type to RATS UCCS, I'd be fine to have pointers
back to RATS UCCS to relate UCCS and UJCS as they are relevant to the media
type. But my discuss on the UCCS document is really just you're registering
this UCCFS plus CBOR media type, where in RATS do you use it and when should
you use this UCCS CBOR media type over the EAT media types and I saw Thomas had
filed a GitHub issue about that already. So I think they are planning to
address it.

Deb: On UCCS or on this draft?

Orie: In my last comment I said like maybe explain in both documents since
you're talking about the same terms in both documents.

Deb: But they're not defining the registry in the UCCS draft, right? It's an
informative blah blah.

Orie: But they're registering a CBOR media type in that document UCCS. They're
not registering a JSON media type, which was the original point that I raised
in my review, and I'm fine with them not registering media types that RATS
doesn't need to use. I just want to understand for the media types that these
RATS documents are using, where are these media types being used and when would
you use the EAT UCCS over the regular vanilla UCCS, if that makes sense.

Deb: Sort of. So regardless, I think we need to talk about this with the
authors, and that's fine. We have a meeting coming up, maybe we can talk about
it there. So I think the disposition of this is revised ID needed for sure,
right? And that I may write the RATS authors and say, hey, we need to talk
about this because it's all intermingled.

Francesca:  I will remove my discuss and I also check that this its media type,
each media type has a normative reference to the UCCS as it should, for other
reasons, so it will get anyway blocked by that other one that we're still
having a discussion with.

Deb: But we still have the issue with UCCS adding things informatively that
other people are then referencing normatively.

Francesca: Not referencing but using.

Deb: For something that's not actually been set up. That's the EAT situation
where EAT sort of mentions this thing, they don't register it and you pop up
and say, wait, what is this? And shouldn't you just register it? And they were
all, we don't want to do that, and we said we have to, and they eventually did
it. Something completely different probably, not anything related to this and
maybe not even media types for all I remember. And so this is the same sort of
deal where UCCS is popping up and saying, hey, there's this thing you might
want to use someday, but not registering it. Are you gonna use CBOR or not? We
can have that conversation too. But that's the UCCS conversation, not this
conversation, right?

Francesca: Right.

Orie: Yep.

Deb:  So Orie's gonna hold a discuss on UCCS until we straighten this out,
which will block this and that.

Roman: It would block this one in misref, not for approval.

Deb: It would be in misref. But we think this one the way that they've done it
is ok if UCCS it does what they're supposed to do ok, right? I don't know that
I want to have it held in misref because UCCS takes another way out then.

Roman: So the corner case yeah i'm exactly with you. I mean the corner case for
me is like what happens after all of deliberations that the UCCS document
removes the JSON kind of stuff. And so now we're gonna have this document
that's gonna make registrations and then there's no, I don't know what the
words are, there's no kind of artifact kind of describing this unprotected JWT
kind of claim set.

Deb: Yep, so I'm not gonna let it get to this ref. I'm gonna hold it until
after the meeting and we figure out what the hell they're gonna do. But I think
this is another case of getting, the EAT people and the RATS people and
whatever to like actually register the things they're supposed to be
registering in the documents that make sense to register them in. By the way
better than the OAUTH situation, so I'm happy about that.

Orie: Deb's gonna be a media type expert in the next couple of weeks. Probably
at this rate.

Deb:  I can't even tell you. It's not even funny. Anyway, so we're gonna hold
this as revised ID needed. Does that put it in my queue or their queue?

Eric: The authors, right?

Deb: Perfect. Let's do that cause it'll come back to me when they revise it,
right?

Eric: Indeed.

Deb: Thinking about my public queue, thank you very much.

Liz: This document is staying in ISEG evaluation with a substate of revised ID
needed.

 o draft-ietf-ippm-encrypted-pdmv2-09  - IETF stream
   IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2)
   Destination Option (Proposed Standard)
   Token: Warren Kumari

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

Warren: I think we might want to, I'm not quite sure what to do with the
document at this point. It clearly has a fairly substantial amount of work
still needed to help get it finished. So I don't know if the right thing for me
to do is hold the document and work with the authors to get it progressed or if
it would be better for it to go back to the working group.

Paul: Can you or Tommy share some of the history of how this document came to
be? Because I think that might be relevant to whatever has happened on the
document:

Warren: I took over the IPPM.

Tommy: There was the old PDM version, stuff which I think had been originally
done in IPPM like ages ago and they were like, hey, we need to revise this, we
need to have some encrypted versions of it and they brought it in a couple of
years ago. I think this is a case where the people within the group who are up
on the measurement side of things were supporting and reviewing those parts of
it, but they're not necessarily experts on some of the security aspects. Deb, I
haven't read your discuss yet. I think I mean they have gone through several
sectors.

Deb: It's very hand wavy, right? So they basically say, these are asymmetric
keys and that's what this means there's a private key and a public key or
secret key and a public key, and then there are symmetric keys and you need to
use these things, but there's really nothing in there that tells you how, and
you might want to use TLS, but, you know, maybe not. There's another section
that talks about AESGCM 128, that this is what we sort of recommend, but
nothing that says how you get from point A to point B and like you should have
an asymmetric key pair and you need to do a key exchange and a shared secret
and generate a key in HKDF and, sort of that kind of thing. So it's very loosey
goosey for a standard.

Tommy: In terms of how the keys are provisioned or derived. I mean, I think
that's not uncommon for this layer of like these are just kind of like markings
that are going between kind of measurement devices within kind of a controlled
network and so they're just saying like, I think the main point here is more to
define just like the the format for within this kind of marking measurement
system. How do we even incorporate the encryption at all? And I would almost
imagine it's just like the it should be more explicit about saying the the
actual negotiation of keys comes from somewhere else and that is not what this
document is trying to do.

Deb: So they could certainly say that and it would make it simpler, right? Or
my suggestion was you normatively reference the TLS handshake and say go use
that.

(crosstalk)

Deb: Out of scope, right. Say it's out of scope. So when you look at the packet
format though, the encrypted packet, the stuff that's encrypted inside that
packet is the same size as the unencrypted packet.

Paul: I'm assuming that just So I'm assuming that's just a bug in their thing,
right? They just copy pasted the encrypted unencrypted and because clearly the
encrypted one is kind of a variable, it's a variable length other thing, right?

Deb: If you're only encrypting these fields in the header, then it's gonna be
that size plus whatever metadata you need for AESGCM, right? Tag and whatever,
right? So all of that needs to be in there. You can't blithely say it's the
same size because it's not.

Tommy: The text could be the same size as the plain text, but then it needs the
other field.

Paul: Yeah but no the If you have a plain text and you encrypt it then for
definition it's not going to be the same size.

Deb: It could give you the same size, but they have not done that.

Warren: Yeah, you'd have to, I think you have to get it padded too.

Deb: No, there are disk encryption modes that do not expand the data.

Warren: Sorry yes, but with what they've defined or with ASGCM. Some of this
feels sort of like a, not actually or to me it feels not actually like a
standard, more like a architecture/framework for we would like to get PDM
encrypted, but I don't know if it has enough detail.

Deb: For a guidance document? I get that it's not everything that I discussed
it out of scope, obviously those things would go away.

Roman: My discuss wouldn't go away if they pulled all that out.

Paul: Mine neither.

Eric: Mine neither.

Roman: Because my fundamental argument is that if you want interoperability and
you're putting a new kind of header in and you said all of this is kind of out
of scope, there's no kind of MTI, there's no get there's no possibility for
interoperability implementations cause I'm gonna invent my own crypto that you
haven't specified and someone else is gonna invent their own and how are we
gonna talk on the wire?

Paul: But all of this also like I haven't even got to where the measurement
parts are and how you would change that. So if you change the packet size, your
whole measurements of what you're measuring goes out the window too, right? And
like and you're doing crypto operations to encrypt things, so that affects all
your measurements too, so like so how does an encrypted blob inside this thing
still measure the original thing that you were measuring, like you're not
anymore.

Warren: I think that part you can still do. This is how big the packet was. I'm
putting a header in, so the information in the PDM part refers to how big the
information was before I added the header.

Paul: But now you've got a server that has like a million of these connections
and it has to do crypto operations for all of these things to add this
information. So the entire state of that server has changed and now all the
measurements of all the clients are no longer the real product.

Warren: the act of measuring perturbs the system noticeably, but I think it's
with the assumption that only doing a very small number of these would be done.

Tommy: Like it would be incorrect to assume that this is being, A) being done
on all connections that are being handled by, I think this is probably very
sampled and very specific. And also going to the interoperability point I think
is very common that it's not a limited domain, but like it's kind of within a
particular operational domain where they are doing particular measurements and
our coordinating is not talking to random other servers that are expected to be.

Eric: The client and the server could be going through the complete globe
Internet.

Warren: I think part of the expected use case for this is, I run a server like
in an enterprise. I run a server and it does my HR or something and people
complain that it's a bit slow. So within my enterprise I allow IPPM connections
to happen. And so from my debugging workstation I include this option and I see
how long the round trip is and how all of that sort of input. So I expect this
is used for debugging and performance troubleshooting, not everybody's expected
to send these out.

Tommy: This is there's the the PDM options that have been around, I don't know,
it's like eight years or something that they've been doing. And they are using
it, so I think it maybe useful to have them also respond and talk about the use
cases and the deployment situations where they are using it.

Paul: So what are the applications that are actually being monitored by this?
Because aren't those applications in themselves already not using TLS and other
things to encrypt their data?

Tommy: I think I'd want the authors to comment on that. I don't want to speak
for them.

Deb: the other point too though is the point that John Scudder brought up,
which has to do with this thing that they call a global pointer, which isn't a
pointer, which is true, but also leaks between things if you're not careful.
You have to look at John's discuss. I didn't rewrite it. I just said I agreed
with it.

Warren: So I think I’ll get back to you. I'm not sure what I should do with
this. What I'm trying to figure out is normally I would just hold the document
and help the authors walk through work through it but I'm not entirely sure if
there are, if these changes are small enough that I can help them, I guess
maybe I hold it, help the authors walk through it and then send it back through
the working group for a consensus check. Does that make the most sense?

Tommy: I think that works, I mean it depends. I wanna get their responses in,
if some of the things like to devs are, these bits are out of scope and it's
about tightening up that the things that are in scope are clearly like we're
defining this bit of protocol foo and let's tighten that up and all the other
stuff about how it's negotiated is out of scope, but here are some references
to how it could look. That I I don't think changes the content enough that
given what I've seen from the working group input on this, that would not
really change what they're thinking, that I think the aspects that you're
pointing out here, which are great and definitely need to be tightened up, are
things that the working group participants aren't focused on anyway, so I think
punting it back to a working group wouldn't be as useful as kind of working
here to try to come up with the correct responses and have the right discussion
on the emails for the discusses.

Eric: Maybe you're right. But I think that the change will impact about 30% of
the documents. Even it doesn't change the way the working group needs.

Tommy: Right, but after I think it would be useful to have this exercise of
going back and forth on the discuss and handle this over email with the ADs and
the authors. And then once it is kind of clear what to do, then then we can
absolutely have the working group review it again. I don't think punting it
back to the working group now would help much because I think we need to get a
discussion.

Warren: so I think I will try and hold the document and try and keep discussion
going and thank you everyone for all of your comments and also for being
willing to potentially help the authors understand how to clear them. So I'll
hold it and then after we've got a bunch of changes, I guess it's, dear working
group there's a fairly large set of changes, please let me know if there's
still consensus to progress this. Does that sound right?

Paul: Sure. I still would like to ask one question. The documents sort of
states that someone has worked on the implementation or there's a thank you for
working on it. I was just wondering if there is an implementation or not?

Tommy: Yes, there is. I think there's a couple.

Eric: And if not mistaken, then even using EVPF for it. I can be wrong though.

Tommy: I believe that's correct.

Liz: This document is staying in IESG evaluation for now with I'm guessing your
advised ID needed.

Warren: Yes, it's going to be a revised ID needed.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 NONE

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-irtf-cfrg-aead-properties-00
   IETF conflict review for draft-irtf-cfrg-aead-properties
     draft-irtf-cfrg-aead-properties-09
     Properties of AEAD Algorithms (IRTF: Informational)
   Token: Deb Cooley

Liz: Deb prepared this response and is there any objection to sending this NO
problem message back to the IRTF? Okay, I'm not hearing any objection, so this
is ready to go. Deb, did you want to look it over over time or could we go
ahead and send it?

Deb: Send it. Ship it.

Roman: I want to thank Robert for the back end support.

Deb: Yes, because it was bad.

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

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Bidirectional Forwarding Detection (bfd)

Liz: We have a recharter under evaluation for review. So John said in the
comments, I think we can skip external review but push the wrong button. So is
there any objection to just making this change without external review.

Roman: Yeah, I'm fine with that. I would like some consideration on my comment
because I think we should cut out the things that aren't going to be done and
are already done.

John: I was gonna respond to that and say,  I will scrub those with the chairs.
My intention would be anything that just obviously can be removed will remove
anything where there's like any judgment call to be made. I'm just gonna leave
it.

Roman: That's perfect. I was looking for the mid thing and the other one that I
recognized is already being done.

John: The mid thing made my eyebrow go up too, but then I like looked at it
harder and I was like, I bet that that's complicated, but I'll talk to the
chairs and make sure that gets done.

Roman: Milestones too, would be the other thing.

John: Yeah, for sure. Is the conclusion that I do the scrub we just talked
about at the milestones and we can just ship it? Very good. Thank you.

Roman: I owe you a discuss.

Liz: This is approved for just making the change but pending some edits from
John, so John we will wait to hear from you that you're ready to move forward.

Eric: And by the way, about your clearing the as I'm the actual AD for the
unaffiliated one, just ping me when you do it. I'm not sure whether i'll get
the message.

Roman:  I apologize, Eric. I forgot that you took that document. Appreciate you
doing it.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

John: There was no meeting this week. Nothing new from me.

6. Management issues

6.1 [IANA #1375267] IESG approval for protocol number (homa) (IANA)

Liz: So 6.1 here was left on again from last week when Eric suggested waiting
one more week just to await a response and if there was no more information to
approve this today.

Eric: So I suggest we do both because I got a reply from the professor
Ousterhout from Stanford explaining what he is doing. It does not object to
making RFC out of the protocol, but it's too early. So which is kind of weird
to ask him for protocol number for something which is not stable. But as I said
last week he's using currently the experimental code point and to make Roman
smile its support IPV6 so all is good. So for me, my recommendation to the IESG
is that we approve it. And I will follow up with John Ousterhout regarding the
follow up and the potential RFC.

John: A question, is this something that should be approved like early
allocation type rules, i. E. It's provisionally assigned.

Eric: It's not provisionally assigned, it's definitely assigned. It's forever.
Because there is no draft, right? For it. So we can do an early allocation for
a non-existing draft.

John: It feels wrong to say if I bring you documentation, then I get a code
point that isn't as good as I as as what I get if I bring you nothing.

Warren: Can somebody remind me how big the protocol space is?

Eric: So it's a one byte and about 100 being used. So they are basically two
thirds still available. So, which is the reason why I say let's approve it. Now
John I got your point, right? So I'm on the edge with you on this one. So we
can say no and request for a draft, right? I don't think it will be a problem.

John: I haven't even looked at the the registration policy on this on this
thing, but, it sort of feels like we're doing an ad hoc process anyway, and why
can't the ad hoc process be we're assigning you a temporary number,
 but you have to renew it on an annual basis just like we do for the more
 standard provisional allocations.

Warren: Does somebody know if we've done this before?

Deb: My understanding is you can't do an early allocation if it's not an IETF
document.

Sabrina: That's correct.

John: So which is why I sort of revised my comment to say like if we're like
inventing ad hoc process anyway, can't our ad hoc process be you or assigned
this thing for one year?

Eric: It's not an ad hoc registry. For this specific registry, it's either
written. It's either standard action, which is not the case or IESG approval.

Warren: Yeah, but the IESG could agree we're only going to approve this for a
one year thing or the IESG could have could, you know, as part of their
agreement to approve, could say, give us a one page draft saying I would like a
thingy and then we have a draft to tie it too.

Paul: wWat happens if after one year or what does you're gonna measure uptake
or you're gonna measure whether or not the registration expires? And if it
expires, would it just go back to the pool for the next one? Because that's
normally we don't do that.

Warren: That's kind of true for any temporary assignment, right? It's a
provisionally assigned thing and then we said that we're not gonna renew it,
but God I hope nobody's actually using it.

Paul: But again like why we don't do this for protocol, right? Because the
space is so small and we really don't want to burn them.

Eric: We can burn it. If you look at the protocol history, we can burn it. We
can make it temporary.

John: My own answer to Paul's question would be, I think it would be your
question, Paul. Like how do what
 do we expect to happen in a year? And I mean based on what you said Eric, that
 after how was like sort of
seemed like he was collaborative and was open to doing a draft and so on. So
it's like we approve this, you get it for a year and in a year we expect to see
some progress towards having published documentation and then we'll renew on
that basis.

Eric: Extend it to two years.

John: Sure.

Roman: Sabrina, can you help us with precedent for any of these being suggested
here?

Sabrina: For IESG approval, I don't think we've ever had to mark something as
temporary in the registry. I may be wrong, so I may have to look into that but
I don't, this is not not something that we normally do.

Warren: Is it something that you would be comfortable doing? Is that easy for
you to do or is it great drama for you?

Sabrina: It might be a little bit difficult to track, but I don't think that
that's, you know, that should be an issue. I think we can, we can figure out a
way to track this one. I am just curious how do you expect us to, I guess mark
this in the registry? Do you, do you want us to kind of use the same temporary
marking that we're currently using for 7120 early allocation?

Warren: I would think so.

Eric: I would say so as well. And rather than the email, either you can put a
URL to the request somewhere on the web or the email address of John
ousterhout; he's requesting it.

Sabrina: Would it be ok to also link to the minutes of this telechat just so
that we know that it was agreed upon here that this is what we want to do?

Eric: I don't mind. The minutes are public.

Warren: We could do that or could we, is it worth having just we do a quick
separate management item to agree that, no that doesn't really work. I was just
trying to find something easier for IANA to link to or to refer to instead of
like, you know, 400 pages of minutes.

Roman: Sabrina, could I ask a practical question for what we're proposing? And
this has already been brought up. Aren't we burning the code point regardless?
So let's say we did a temporary approval kind of here and I don't know, the
IESG rotates out and they have a completely different kind of opinion on this
and they let it expire. Would we return it back to the pool or would we just
kind of mark it somehow as burnt?

Sabrina: Ee would check in with you on that and you'd have to let us know
whether you want to return it back to the unassigned pool or mark it as
deprecated. That's something that we would normally ask the chairs for 7120
early allocations.

Roman: Because I don't know any of any of this, so in cases where this has
happened before not in this particular kind of registry, is there a popular
answer? Do most people just burn the code point in most instances where this
occurs, does this not occur? You know, can you kind of walk me through it? Is
it kind of 50/50?

Sabrina: Very rarely, so for 7120 early allocations, we've had it marked just
as expired in the registry. I think there's been cases where it's been just
marked as deprecated, but very rarely does it ever return to the unassigned
pool? I can only speak about 7120 early allocation.

Paul:  I mean scanning the protocol page I actually don't see any individual
entries that say reserved or unassigned or anything. It's just like old craft
is still in there marked, like, I don't know Argus protocol 18. I don't know
what that is.

Warren: if it were not renewed, you know, or if it wasn't finally made
permanent, if it was marked as expired or something, when we have ended up
using 240 of these, people could then sort of try and decide which ones they
might investigate more and might cherry pick? So I suspect, this is making our
future lives 30 years down the road easier potentially, if it's marked as
expired or deprecated or wasn't use, but we don't think it's being used anymore
or was professional but isn't anymore or something like that. I mean I would
assume it doesn't get reassigned the next time somebody asks for something. 20
years from now, somebody when they desperately need one.

Roman: The background, Sabrina, is helpful and that thought process is helpful
to Warren. I'm good with the temporary thing, I think I'm also with the I
forgot kind of who said this about the ad hoc kind of nature. If we think we
are going to ever do again it would be really great if we had some collateral
describing this new thing we're just minuting here on the call.

Eric: But if you look, not all of them have an entry to an RFC or to our
standards. So they said been there multiple times.

Warren: Some of the older ones, even if it's not pointed in RFC, it means we
have no idea. The fact that something is listed as the registry and the
registry is temporary, the fact that it wasn't renewed kind of signals, I don't
know.

Roman: I mean I'll speak out of the mount. I mean it really comes down to like,
how much scarcity do we think we need and
 do we need to roll in a gate to manage the scarcity right now? The precedent
 would be just to hand out the permanent,
the permanent thing. To me that would be the easiest thing. But if we want to
do kind of something fancy, and the IESG kind of feels like that. I personally
wouldn't be kind of against it, I would just hope that we would write something
up to help us better manage this decision making next time.

EriK: I mean we don't get a lot of non IETF documents asking for these things,
right?

Eric: In my five years, this is the first time.

Warren: People figure out that they can get an assignment faster by not writing
a document, maybe we will get more.

Eric: But in this case, right, so I'm pretty sure that the gentleman in this
team, I guess there are students working on it or whatever, right? They simply
want to stabilize the protocol and make some tests. So I think this is good for
them to ask for a protocol number.

Roman: So we gotta decide here. So I'm gonna tip us to not doing kind of
something different in here whether there's objection. It looks like they have
published in a very reputable kind of place. They have open source kind of
implementations. Would there
 be an objective that we just gave them a permanent registration and, and
 thought about the future about how we would
want to handle these to prevent the situation you were talking, Warren.

Warren: That's fine with me. Let's assign Murray an action item to write up a
document or IESG statement on this

Erik: I have no objections here to approving.

Eric: And I understand the hesitation from John and Warren, right? I'm not 100
% for agreeing it,
 but I think that's the best way to do it.

Warren: It's Fine with me.

John: Go ahead.

Roman:  I think what we have here is that we're gonna approve this and it sound
I think the the idea of Ianabis is actually an excellent idea. I think we
should take this to the working group to to kind of figure out how to handle it
to the potential working group because we're not approved yet.

Eric: And I will follow up on a separate threat without IESG copy, but with
Eric and then I think I put in initially with John Ousterhout out, asking him
somehow to make a draft at least would be appreciated.

Liz: We will send the official note to IANA with that approval.

6.2 Approval of IESG Statement on Use of BCP 14 Key Words (Murray Kucherawy)

Murray: I apologize. I got nowhere near this, so what I'd like to do is, this
doesn't seek community inputs, so correct me if i'm wrong, we could approve
this when we all get together in Dublin, right?

Roman: Absolutely.

Murray: I'm gonna try to get a few of us together before the first meeting if
that's possible or at least we could do it during the week. I think I can do
this faster with facetime. I'm a little stimy because when at the retreat when
we said we were gonna do this is everybody was kind of that's a good idea, and
so I volunteered to do it because I thought we were on the same page, and now
the amount of feedback I'm getting back sort of at the last minute is a lot, I
think I need to look at
 this again so I want to get a few people in the room and like let's just hash
 it out fast so that we have something to show everybody.

Roman:  Free to loop me in on that Murray, so I provided I think a bunch of
proposed edits instead of comments. Hopefully that's more helpful. And I
personally narrowed down beyond the editorial to like, I think the two
substantive things we're saying about using those keywords and I think those
are the ones I want to talk about.

Murray: If you've commented on it, if I at the time I start working on this
again, if I see that you still have open comments I'm gonna try to corner you
with that cluster of people so that we have something we can finish up.

Roman: We can also add it to the agenda of the Sunday or Monday meeting.

Murray: I don't want to corner the entire room into what could turn into a long
conversation, but yes, we'll do it that way.

Liz: We'll put it on the agenda for 121.

6.3 IESG Statement Addressing Comments and Crediting Contributions (Orie,
Francesca, Murray, Mahesh, and Warren)

Roman: So I'll explain what I've done in the document and in the chat. I think
there was all sorts of different feedback on it and I was as guilty as anyone
else providing comments but not alternative texts, so at the end of the
document, I have a rewritten version of the statement that merges some of those
words and a bunch of the comments that were provided into a standalone
statement for discussion if that's helpful. I don't want to take this away from
Orie, Francesca, Murray, Mahesh, and Warren who have this action.

Orie: Thank you for doing that. I think it needed to kind of top down
restructuring. We've merged a bunch of comments iteratively. I think the next
step is to see if we can get consensus to take the rewritten text as the new
base and then figure out if there's anything left to add.

Eric: And I raised my hand on this the new text is very nice, Roman, but I
still wonder whether it should be one IESG statement or two because the two
parts addressing comments and crediting links are vastly different anyway.

Roman: I dropped it, I think 10 minutes before the meeting. Did you see my new
introductory paragraph desperately trying to kind of say why they're related
together saying the same thing?

Eric: Nope. I'll do it right now.

Liz: Should we also put this on the agenda for 121?

Roman: Yes.

Francesca: Yes, and maybe we can ask everyone to read Roman's version just as
the base and be prepared to send feedback before the meeting. We can do a first
pass in preparation for the meeting.

Roman: I'm not a G suite expert and so someone tell me that I am kind of wrong
here. It might be easier I don't want to be presumptive if the proposal I had
made to synthesize everyone else's text was accepted, so it was in the
document, I think it might be easier than to provide comments because I think
providing comments on suggested text is a little different than providing
comments on suggestions.

Francesca: We should definitely accept that.

Roman: It might be easier just to hammer on it.

Francesca:  I guess we can delete the first text before because he can anyway
we can anyway see it
 back in the history, so there's some version control. I'll do that.

 Deb: No, I would say make it as clean as you can cause it'll be easier to look
 at.

6.4 Confirm IANA email re: IESG-related early allocation process questions
(Paul Wouters)

Paul: That's my comment too. I'm not exactly sure what this is referring too.

Sabrina: I believe this was in reference to Amanda's email, Paul that she sent
a while back, but, so we're working on 7120 bits at the moment, and we just
actually uploaded a 00 version, but there is a line there that we wanted to
confirm with all of you if you want to keep it as is in the document or if you
want to change it. But it's regarding the, the temporarily expiration kind of
proof state, so where we would freeze the expiration date. And, in 7120
currently says that when its submitted for review to the IESG, and so our
interpretation of that is is when it entered the IESG evaluation state, but in
the past, I think a chair has suggested that this could be read as publication
requested. So we're not going to list the states in, I don't think that's what
you want us to do anyway. But we just wanted your input on if you think, we
should update that or if we should just leave it.

Paul: Right, I remember this discussion now. We did have a few emails about
this back and forth with IESG and I think actually John Scudder convinced me
that that really is where we should draw that line personally. But we haven't
talked about this with IESG, so I don't have any answer for IANA yet.

Sabrina: We can continue the discussion over email if that's better and or
check in with you also at 121 I think this was one of our updates.

Paul: I'll add it to the agenda, and confirm it again with the IESG at 121.

Liz: Ok. We'll discuss this further at 121 and no action for the moment.

6.5 [IANA #1385320] Designated experts for RFC 9660 (The DNS Zone Version
(ZONEVERSION) Option) (IANA)

Liz: Warren's new one and he's already got three names here; Hugo Salado,
Mauricio Vergara Ereche, Duane Dwayne Wessels as designed experts for this
registry and the objection to approving these three?

Paul: Just out of curiosity, I've never heard of the 1st two names actually.
Obviously Duane I know.

Warren: So they were the authors of the document and I know Hugo from ICANN
world.

Liz: I'm not hearing any objection, so I think we can call those three approved
and we
 will send that official note to IANA and to take that action item off your
 list, Warren.

6.6 [IANA #1385324] Designated experts for RFC 9559 (Matroska Media Container
Format Specification) (IANA)

Liz: This is the item just officially assigning this to Murray to find
designated experts for RFC 9559. So Murray, you've got that in your queue.

6.7 Markdown as a submission format (John Scudder)

John: This came out of me being grumpy that there appears to be some minority
but still a large group of authors that just like click through and submit text
because I don't know why that's what they've always done. Somebody else said
well that's probably includes probably partly because they can't submit
markdown directly and so they just generate the text and submit that which like
to me is saying why can't they just submit markdown? Which led to Robert
saying, if you want us to do that, you have to say you want us to do that. So I
want us to say that we want them to do that. And I see that Warren has his hand
up and I also see that Robert's on the call and if it's ok with everyone I
would like to invite him to speak if he wants to. And I see that Eric also has
his hand up.

Warren: So, Warren's main concern is, if they submit markdown and it's just a
pile of unreadable and usable stuff, is that helpful? I mean. One of the like
my reasons for being cool with all of this is I really like having some sort of
page numbers to be able to refer to and hopefully if it goes through a process,
we get that at least. But if people just submit markdown I'm concerned it's not
gonna render into anything that looks like an RFC unless there's a bunch of
like markdown lint.

John: so there's my answer on that one is I'm already starting to understand
why Robert smacked me upside the head and said this is more complicated than
you think it is because all that was happening in my mind was, I want to be
able to take the cramdown RFC that I sourced that I currently render into XML
and then submit the XML and have the site do the work for me in the middle. But
your point is no people will submit all kinds of crap and we have to make sure
that the rule is written which I agree with, but I think that whatever our
statement is, it should make it clear that this is like an aspirational goal.
We would like the to work towards this and we don't want to open the floodgates
to you submitting just any random garbage that doesn't render properly.

Robert: I'd ask a clarifying question from Warren. What is the distinction
between pilot junk that's not useful in
 Markdown and pile of Junk that's not useful in XML?

Eric: Or text.

Warren: I mean, I've noticed often when I write cram down, I managed to mess up
the references and similar things to that or like the author section. And yes,
I can mess it up with XML as well, but generally I've been writing it at
markdown, and then I used Martin Thompson's tooling which does it from cram
down to XML to something and so there's like a sanity check. Where one of those
parsers barf set me and says this is not a valid looking reference or your
author template bit is misformatted. So I think it's the fact that I had to
manually par pass it through some sort of parser, which does sanity checks. If
the submission tooling can do those sanity checks, then I don't care.

Robert: I had assumed that things would have to flow through something similar
to IDNITS.

Eric: And my question is that as far as I know, there are multiple dialects for
writing markdown for an ID, so this could be challenging for swallowing it and
digesting it by the tools team, but just my concern. But I don't object to your
proposal John.

John: Is it ok that we minute the, you know, statement either that's on the
screen right now or something like that? Basically, nothing more to say. It's
on the screen.

Roman: I'm very comfortable committing to that.

Liz: Robert, is that enough detail for you if we just say something like this
or do you need anything else?

Robert: This is fine. Thank you.

6.8 Registration changes (Liz)

Liz: So just a quick update for you all. For some time we've been moving toward
opening registration for multiple meetings at the same time. For a few reasons,
e.g., allowing people earlier access to letters of invitation so they can begin
their visa process sooner etc. And we're planning on opening registration for
122 this week, I think it might even be today. And there are a couple of
consequences to IESG related things that we just wanted to make sure you're
aware of. Firstly, we'll be changing the registration opening dates on the
important dates. I'm not sure how we'll handle this long term in terms of like
what dates will automatically assign for that, but for now, we'll probably just
be manually updating some of the registration related important dates for the
next couple of meetings. And then, the other thing is we may need to refine
some of the details of the bof request process. E.g., adding a line to the
template, be asking at which meeting are you hoping to have your bof because
there's is a closing date for bof requests but there's no opening date, but we
sort of feel like registration opening is a queue for people to like that it's
time for them to submit their bof request. And so with the earlier registration
dates, we anticipate people might be a little confused about when to submit
their bofs and what the timeline is. we were thinking maybe adding something to
the template, asking about what number, maybe some more explanatory text
somewhere at the top of that page or another page about sort of how the process
works, things like that. So I mean I'm not sure if people get confused, but we
just thought maybe they would, so we'll be thinking through a little bit how to
sort of make this a little clearer.

Eric: I just want to know why would someone propose a request to bof for one
meeting which is four months from now?

Liz: like if someone were to register today for 122, like and try and submit a
bof request, it's not actually clear from the request page like what the
timeline is the the deadline, like per meeting is listed on the important
dates, but it's not listed on the bof request page. So we were just thinking
some people might just get confused about how the process works,
 when are the cutoffs and how does that go? So we were just thinking like some
 way we can add some more clarification to the
bof request page about sort of how the deadlines work and that.

Roman: I mean one thing that immediately jumps to mind to your question, Eric,
is I've previously heard proponents say, I want to pitch the idea and I want to
be ready and geographically more people are interested in my thing are in this
kind of meeting kind of venue, and so they try to align because they think they
can get more proponents to come on site because of the location and they may
choose to delay as a result of that or accelerate potentially I've only heard
delay.

Eric: Fair enough.

Liz:  so we don't have any concrete changes right now, but just sort of a heads
up that we'll be keeping an eye on this and also seeing if people are getting
confused, and maybe using that as a cue to you know how we might need to
explain this a little better for people. So I think those are really the only
impacts to the IESG about opening registration earlier, but of course if you
notice anything else that's weird or you think is not right.

Eric: And out of curiosity, so will we be opening the registration four months
in advance for all meetings or six months?

Liz: I'm not sure if we have that time frame yet, so it might be a little too
early to say I don't know if we sort of can exactly set what that interval is
right now, but it kind of depends also on getting all the information for the
letters of invitation and all of that, so more to come on that.

6.9 IETF 121 Prep (Roman Danyliw)

Roman:  I pretty much just have a basket of things to mention. I don't think
they're long in a discussion items, just a few requests and a few heads up.

Deb: Do you want an executive session?

Roman: No executive session. First, I'm trying to prepare the agenda items for
the joint meeting, our meeting on Sunday and then Monday and kind of Wednesday
largely recognizing that Wednesday is gonna be largely focused on plenary prep
and things that we think are related to that. So I think the biggest kind of
scheduling is what do we want to put on Monday or potentially cancel the money
meeting and what we do with the IAB and with ourselves on Sunday. One thing I
wanted to mention that I'm going put on the agenda, Sandy knows this because we
just talked about this, but this maybe new to you, Sabrina. We had a bunch of
discussion I think over time when we ballot on how individuals have written up
IANA considerations and are they very clear and separating the difference
between being clear to everyone versus being clear to IANA who is lean
forwarded, and trying to understand the best they can and like how do we handle
that? The the RPC has been snagged by that. I know we ballot it a little bit,
so I, we don't often get all three parties kind of together. So that is one
item that when you see it on the agenda I wanted to explain the background on
that.

Roman: Then I wanted to warn everyone that I'm going to rerun all of the
different analyses around the document pipelines sometime, maybe mid next week
you can maybe kind of push me a little bit later. So now would be a great time
to clean up public things to get the numbers. I can of course kind of hand
change things as are required, but my intent, my working thinking is that I
don't know yet how much time I can allocate during the plenary session, whether
I can replay those slides, but I was thinking of replaying what I can't replay
that I would put some of them in the IETF chairs report given that I've gotten
indications that people actually kind of read that, so that might be a good,
good spot to put some of those stats just so, I mean no action other than doing
what you always do before. Realize I'm gonna probably do a run mid next week to
produce some charts.

Roman: Then the last one is largely just an FYI because we probably have talked
about this at at different points in time. I had an action item to take our
working thinking on, on those like recommendations letters or what have you
done in the IETF contribution letter to talk to Systers about that. So after
different kind of scheduling scheduling things have been discussed, what the
sisters have have kind of gravitated around is that there will be a session on
Thursday of the at lunchtime if someone's gonna correct me if I remember that
correctly. They want to have a scrum with a small group of IETF leaders and the
agenda is gonna roughly be me, Jay, Greg, Colin, and Tommy and Francesca and
you, Deb kind of as well. I am gonna prepare, actually I've already prepared,
I've sent you kind of links. All of the things that we have been talking about
women's experience in the report for the experience of women in the IETF and
some of the different actions and kind of lining up what we're doing, kind of
what we're talking about doing. I've consolidated that with also things that is
already happening in the LLC and kind of in one stop shop, and my plan is to
kind of facilitate a bit of a discussion on what we're kind of doing kind of
elicit feedback and kind of what not, and that's gonna be I think the good part
of the agenda as the Systers have explained it to me, and in addition, the
Systers before that are gonna explain some of the, some of the things that they
are working on and explaining their charter. So I wanted to make you kind of
aware that that's happening, but you are not looped into all of that. I would
appreciate feedback on the slides if kind of possible that I sent around
earlier this week. Alright, that's it for me, for IETF 121 prep. Is there
anything else anyone else wants to mention to the group about?

Murray: I had one thing about 121, but not about prep specifically. Ianabis
passed its internal review. I wrote the text up for the external review, but I
don't think it went out. It's currently scheduled for a telechat in November,
but it has an agenda slot, so, what's our way out of this? Do we cancel the
agenda slot or can we do this in a kind of a rolling approval if someone
suggested. That we start the external approval and then if as long as it clears
with no objections, then it's implicitly approved some that someone might look
at that and go call shenanigans, some people might be fine with it. I just need
a disposition here because it's kind of half approved right now and we need to,
we need to go one way or the other.

Roman: I would personally call significant shenanigans. If it's in external
review, we can't convene it as a working group, we can convene it as a bof and
as what are you, to me it would be what are you bof-ing, and if you aren't
really bof-ing but you're trying to do the start of the meeting like we
shouldn't do that.

Murray: I mean if it's a first meeting, then it would be like organizing
itself. What's the order in which we're gonna do stuff? And you can do that
informally, you just can't, there's no chair, nobody's adopting documents,
nobody's setting milestones or anything like that. Since it's got agenda time,
we could do something with it but it can't have any sort of official status
 and it looks a little weird. So I think the cleanest thing to do is just
 remove it from the agenda.

Roman: I strongly endorsed that because I think anything else begs a lot of
process.

Murray: So Liz, I guess that's where we're going.

Roman: In terms of time, you were unable to squeeze it into this telechat?

Murray: It needs two weeks of approval.

Cindy: To a point of clarification, so there's some sort of multiple points of
not greatness here. The default external review is for ten days. The minimum is
one week and when we had talked about this, we had said that like when this is
approved for external review, we need to explicitly call out that it's going to
be a one week external review and we didn't do that. So when the message went
out, the default ten day message or ten day external review went out, which put
the end of the external review date after today's telechat.

Murray: I didn't even see the external review go out.

Cindy: I believe it went Thursday or Friday.

Murray: Oh, here it is. We asked for feedback by the 28th, which is four days
from now, yeah. Okay, so we can't it's it can't approve properly before IETF
121.

Cindy: I will say that past IESGs have like we we've had that concept of
placeholder both and past IESGs have used those for working groups that may not
have finished chartering by the time the meeting rolls around, it sounds like
the current IESG is less comfortable with using that, but I would be shocked if
it hadn't actually been used before.

Murray:  The only thing I can say in favor of proceeding is that this is very
likely, I mean look at the number of yeses it got. It it's very likely to be
uncontroversial, and we haven't received any adverse feedback so far. Of course
something could come in. But I mean I'm not gonna I'm not gonna push the point.
It's not like this has to happen at 121.

Francesca: But I mean it does feel a bit like a waste of meeting to not have
them meet because of a process problem. Can we really not approve it at the
IESG meeting before? I know we've had this discussion before and we we have
refused to approve working groups before in that meeting, but I feel like that
maybe that was because we didn't have enough like notice in advance to do that
sort of approval and can we not just a formal meeting where we approve that?

Warren: I think technically we could, but the optics around it are followed the
letter of the law, but we didn't actually follow this for it.

Roman: I would be very unexcited by this, and I don't think we should do that.

Murray: No, i'll give you one other example of why we shouldn't do this. DKIM2
is pushing really hard for agenda time somewhere, and if I given if we if we
bend for ianabis, we've gotta bend for that, and I really don't want to give
them that sort of agenda time

Francesca: What I'm saying is the only thing that we are missing is the IESG
convening in in a formal meeting and approving it because we have done all the
steps, right? We've had the internal review, external review, and then we're
just missing a moment in time where we convene and we say, yeah, let's approve
and we formally minute that as well. so if we consider like the weekend meeting
as an informal, then of course you cannot do that during informal. But if we
consider it as formal, at least for the part. I'm just wondering maybe and and
this is.

Cindy: From an optics perspective, the Sunday meeting, like the the meetings
that you will have during the IETF week are not open to observers, which is one
of the things you guys have been doing for the formal tele chats, so doing that
at a meeting that does not allow observers, obviously I don't think that
there's anything untoward here, but if somebody wanted to make a stink, they
would.

Roman: I'm concerned kind of procedurally so we would convene a special session
to approve this what would be the threshold we would use to convene special
sessions for any of the other things that we did not get during the regular
IESG meetings.

Francesca: To be clear I wasn't suggesting that we convene a special meeting. I
was saying we are meeting anyway. Can we use that meeting and it's a little bit
different but Cindy has a point that we don't have observers.

Eric: When is ianabis scheduled? We could approve it during the plenary, there
are observers. I'm only joking.

Warren: It does actually it does feel like initially it kind of felt like a
joke, but it does feel like if we went to community and said hi community, we
understand you want to do this because of weird process reasons we couldn't, so
we'd like to do this now in a public thing and we would like to do it that way.
We've dotted the I's and crossed the T's. I think the community would be ok.
I'm not sure if it's on fire enough to do that, but I think if we really wanted
to be.

Murray: I appreciate the creativity but I think the precedent this would create
would be too dangerous for us.

Cindy: The minutes of the plenary are not the minutes of an IESG meeting.

Murray: There's this new effort with lots of large operators in the application
space. Dkim two is the successor to dkim. They really, really want some agenda
time somewhere. They try to get into all dispatch but it's full. And they are
just like we were just doing coming up with all kinds of creative ways that
they can get some kind of airtime. Can all dispatch have a second session where
they get some airtime? Can mailmaint get a 2nd session so they can get some
airtime there, even though mailmaint will determinately not take up this work
cause it's too big. They have a side meeting but like what's
 the point of traveling all the way to Dublin for a side meeting if that's all
 you're gonna get?
So is there anything they can do? I don't know what people's thoughts are about
adding time to all dispatch.
 I don't have a lot of other good options. I could give them the ianabis of
 this slot if we're gonna cancel it, but it's not a working group, it's not
 even a bof yet.

Warren: Could mailmaint or someone put a request in for a second session and
they use that second session during ianabis time.

Murray: Weird thing and tell me what you think of this dkim2 two will
absolutely not become a mailmaint work item because mailmaint is chartered for
just small things and Ddkim2 is a complete overhaul of dkim, like that's it, it
doesn't fit their charter. But if they need airtime somewhere, like this could
be like an AOB ART area type thing. I just think that looks a little weird.

Warren:  I mean DNS OPS is giving some time to something which is gonna be in
UTA, but UTA's not meeting and so DNS Op is like, you know, it's related to the
DNS, you can talk about it here. We're not adopting it but we wanted people to
be aware, so that feels like it could be done or a late approval of a bof.

Roman: No, please.

Francesca: Why don't you take the ianabis slot and make a late ART area meeting
if you don't have conflicts, and you and Orie are the chairs so you can put
whatever you want on the agenda.

Murray: The other alternative I thought was making in ART area meeting but it
would be an ART area meeting just for this, which also has bad optics, like
it's clear I'm favoring this group to get air time.

John: It's clear that your favoring this because you think that it's an
important topic and has community, forced behind it and like isn't that our job
actually is to identify valuable work and then favorite it?

Warren: Yes, but as long as it doesn't look like you're favoring your own stuff.

Paul: We could wing it a little bit and give them five or 10 min at saag since
clearly this is a security area.

Murray: Do you have 5 minutes at saag?

Warren: Is alldispatch full?

Murray: Yes. And like one of the solutions to this was, can we just create a
second alldispatch session and continue their agenda there? I don't know if the
chairs would be happy with that. Nobody's actually approached them about it
yet. I don't want to spring that on them and go, you've got one more session to
manage.

Paul: I don't think you can do that because they did send emails saying no more
proposals.

Roman: The other piece is, does this have a document to actually dispatch?

Murray: There's really only one outcome for something this big, but I mean, we
could go through the dispatch motions, but they do have a draft apparently, I
just haven't seen it yet. There is no charter though.

Roman: I just wasn't sure if there was a document or just an idea.

Murray: I understand what the idea is and they told me just yesterday that
there is finally a draft available, but a draft, like a draft, an internet
draft but a charter draft.

Roman: No, I meant an internet draft because one of requirements to enter the
gate or any dispatch is typically a document.

Murray: I think i'm going to go the route of trying to get mailmaint a second
slot or if they can fit themselves into mailmaint somehow now, I'll try to keep
it there, even though it's a little weird because mailmaint absolutely will not
pick this up. I don't want to create an ART area meeting that's that's clearly
just for this one thing that I think needs air time because then again a
precedent. Someone down the road is going to say: 'hey, you did this for them
so why aren't you doing it for me?'

Orie: Maybe if 5 minutes of saag is available or hotrfc?

Murray: Paul, i'll ask you about saag offline.

Deb: We don't have a problem with them taking 5 minutes of saag.

Murray: My only thing is 5 minutes enough? I think they might want 10 minutes.

Deb: That's fine. There was an email about this that came out, do you remember
where?

Murray: About dkim2?

Deb: Yeah. I saw it earlier.

Murray: There was some stuff about alldispatch.

Paul: I also talked to a few people on Slack about Stephen Farrell ended up
meeting with the dkim2 people.

Deb: Maybe you sent it to me, maybe that's where I saw it.

Murray: That's i'll figure it out from here.

Liz: We're taking ianabis off, but we're not putting an ART area or anything in
it's place.

Murray: No, not an ART area. I might ask for a second  mailmaint slot if a
chair is willing to run that. If not, i'll see if I can pack it into the tail
end of saag or mailmaint. Delete ianabis, and I may come back and ask if we
have open slots if we decide we want a much longer session.

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

Roman:  I would just remind everyone now's a good time to provide your NomCom
feedback.

Warren: That's a good time to provide your NomCom feedback, and I put the link
in the Slack so everybody can easily click on it. If people don't provide
feedback, you're going lose the right to complain if I get reappointed or
something. The NomCom really does need feedback, and the IESG you get  is the
one you help create.

Eric: It looks like it's pretty efficient this time. I got my interview slot
already booked ten days in advance during the IETF week and the convenient time
for me which is good.

Liz: Yes. Jenny's helping with the scheduling this time, so those of you who
are up, you should have already been in contact with her about scheduling your
slot. If you have not yet, then please check your email.

Roman: The last thing I just mentioned, if anyone hasn't noticed I put out the
meeting experiment stuff we talked about to IETF announced, so it's public.