Narrative Minutes interim-2022-iesg-25 2022-12-01 15:00
narrative-minutes-interim-2022-iesg-25-202212011500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2022-12-01 IESG Teleconference

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

1. Administrivia
1.1 Roll call

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

REGRETS
---------------------------------
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area

OBSERVERS
---------------------------------
Shwetha Bhandari
Frank Brockners
Marek Hajduczenia
Mike Jones
Greg Wood

1.2 Bash the agenda

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

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes from October 20 and October
27 being approved? I'm hearing no objection. I also saw final narrative minutes
for both; any objection to those being approved? I'm hearing no objection.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Paul Wouters to find designated experts for RFC 9200 (ACE-OAuth)
       [IANA #1239251].
    o Paul Wouters to find designated experts for RFC 9203 (The (OSCORE)
       Profile of the (ACE) Framework) [IANA #1239258].
     o Paul Wouters to find designated experts for RFC 9237 (An
       Authorization Information Format (AIF) for Authentication and
       Authorization for Constrained Environments (ACE))[IANA #1239259]].

Paul: I have 2 confirmations, one is Francesca and one is Goran, but then I
realized they're both at Ericsson so I started looking for a third just to have
a non-Ericsson person there. If I don't get an answer from that person I'm not
sure there is anyone else.

Roman: We should really try not to have them from the same company, and that
really tells us something about that registry.

Warren: I agree that it's better if we don't, but we do have a bunch where they
are from the same company. I don't know how important the registry is for that
and how likely people are to want code points and fight over them.

John: There's always an escalation path if someone thinks the DEs are
misbehaving, but it would be easier if they weren't.

Paul: Okay, well let's see what the third person says, and maybe I can ping
Francesca to suggest some names of people that might not be as active on the
mail list.

Francesca: I can suggest names if you want me to; we can take it offline.

     o Lars Eggert and Colin Perkins to find designated experts for RFC
       8609 (Content-Centric Networking (CCNx) Messages in TLV Format)
       [IANA #1239154].

Lars: Happy to report this is in progress. This should be moving forward; sorry
for being slow.

     o Roman Danyliw to find designated experts for RFC-ietf-lamps-cmp-
       updates-23 (Certificate Management Protocol (CMP) Updates) [IANA
       #1241372]

Roman:  In progress, thank you.

     o Francesca Palombini to find designated experts for RFC 9290 "Concise
       Problem Details for Constrained Application Protocol (CoAP)
       APIs" [IANA #1241511].

Francesca: Action caught, thank you.

     o Alvaro Retana to find designated experts for RFC 9303 "Locator/ID
       Separation Protocol Security (LISP-SEC)" [IANA #1241556].
     o Alvaro Retana to find designated experts for RFC 9305 "Locator/ID
       Separation Protocol (LISP) Generic Protocol Extension" [IANA
       #1241559].

Amy: Alvaro is not on the call today.

   * OPEN ACTION ITEMS

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

Amy: On hold until just before IETF 116.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-pim-igmp-mld-proxy-yang-08  - IETF stream
   A Yang Data Model for IGMP/MLD Proxy (Proposed Standard)
   Token: Alvaro Retana

Amy: I have a Discuss in the tracker and Alvaro is not here to discuss the
Discuss. He did say in his note that he wants all of his documents to go into
AD Followup and the authors are aware of that. Unless there's anything to
discuss here, we should do that.

Rob: That's fine, I'm sure this can be resolved with the authors.

Amy: Okay, we'll put this in AD Followup and Alvaro can pick it up when he's
back online.

 o draft-ietf-lamps-lightweight-cmp-profile-16  - IETF stream
   Lightweight Certificate Management Protocol (CMP) Profile (Proposed
   Standard)
   Token: Roman Danyliw

Amy: I have no Discusses for this document, but I also don't have enough
positions for this to pass.

Lars: I didn't ballot on anything this week, sorry. If you need something I
will review it next week and ballot. There's also an IANA not okay on it,
though.

Sabrina: We just need experts for this one; the action item is already assigned
to Roman.

Roman: I'm working on it. There were no new registries, so the registries it's
adding new entries to don't have any DEs?

Sabrina: That's correct.

Roman: Got it. So we can't proceed with finding DEs after the fact, we need
their names now?

Sabrina: Preferably, I think. If the document is approved we can't proceed with
the actions until we have experts.

Roman: Okay, thanks. It just needs more ballots and there is some good feedback
in here that can get sorted out.

Amy: Will this require a Revised ID or just AD Followup?

Roman: Can you just give me AD Followup? I think it's probably Revised ID but I
can make those changes. And I want to say thank you, this was a very large
document.

Murray: I didn't get through it; I can try to do so this weekend and get
another ballot.

Rob: Roman, can you look at the comment I made? I'd like your input on that as
well. You may have a better view as to whether there should be an updates tag
on a couple of documents or not.

Roman: Will do. Thank you.

 o draft-ietf-ippm-ioam-ipv6-options-09  - IETF stream
   In-situ OAM IPv6 Options (Proposed Standard)
   Token: Martin Duke

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

Martin: Not all of them. One micro point and one macro point. John, I know we
chatted about this but I was a little surprised by your Discuss. I saw it as
basically a fairly simple true standards spec, requesting the code points and
whatnot, and then a bunch of deployment considerations. I would think
deployment considerations are by nature pretty loosey goosey and not terribly
well structured. I guess I'm not clear what you think that section should look
like, or whether it should exist.

John: That's why it's a Discuss; I really want to hear from the authors. That's
the weird thing, that section is not a deployment considerations section,
because then it would present itself as such. It's neither fish nor fowl and I
guess I'd be more comfortable if it either moved in one direction or the other.
If I were implementing this thing I wouldn't quite be sure what to do with all
of this stuff.

Martin: That's fair enough. I took it as deployment considerations when I read
it but maybe I'm wrong. We'll see what the authors say. The larger comment, the
other theme in these Discusses is this leaking data limited domain thing. I
agree there's some not great language in there about potential leaks, but I'm
also a little leery of replaying the IOAM discussion again and again. The IOAM
RFC had a whole pile of Discusses about how to make sure data doesn't get out
of the domain and so on. I'm a little concerned that we'll go through this
every single time.

Warren: Normally if I see a limited domain type thing I say it's really bad,
what happens when it leaks? In this particular case, I abstained because to me
it feels like the document tried really hard to minimize the limited domain
type aspect of it. If the data does leak I don't think it's the end of the
world, as opposed to if it was something more like SPRING. I do have a concern
though which Andrew mentioned, which I only saw after I had finished my
balloting: what if this isn't actually a destination address and it's instead a
SID or something similar? That's the important bit. We shouldn't have the same
fight over and over, and I agree, and in this case the authors did as good a
job as could be expected with the domain part of it.

Andrew: From my side, my discuss is not about leakage. My Discuss is more about
undefined behavior that needs to be addressed.

Martin:  It's a great Discuss. I'm just speaking broadly, I saw a running theme
through these was the IOAM leakage thing. To me it's an encapsulated tunnel in
some ways.

Andrew: I think the problem comes, my take on the whole limited domain thing,
and this is not limited to IOAM but in general, is that the moment you define a
limited domain you have to clearly define how those borders are defined, and
how do you actively prevent leakage. As Warren said, I think they tried really
hard in this case to address that, and others had commented on it, but the
general thing you'll find from me with anything on limited domain is A) have
they adequately defined that border in such a way that it's clear to me as
someone implementing this, and B) have they given something more than you need
to stop exiting the domain with no specifics on how to do that? That is going
to cause me to scream every time, IOAM or not. That's my thing about the whole
limited domain.

Martin: I understand the general philosophical concern here. The authors still
need to engage with this, so I would just ask if you also have a Discuss in
this topic, to take a look at the IOAM document and maybe we should have a
reference to it if we don't have one already. A lot of this information can
happen in one place. This is probably the last one of these coming out of IPPM
and then it will become a thing other WGs will do, so whatever protocol is
going to have this encapsulation. It would be good to figure out what we want
out of these and provide a template. This is a good opportunity to do that. I
see Frank just joined. Frank, do you have anything you'd like to say about this?

Frank Brockners: I think we've been over rotating on the concept of limited
domains. We see IOAM deployed today in data centers, it's there in the linux
kernel, it's in BPP, so there are 2 open source implementations of the whole
thing. If you want to go and run it somewhere on the global internet, and you
have routers next to it where things leak, yeah it could be a problem. But it's
not a problem that's specific to IOAM, it's a generic problem with all limited
domains where stuff in the limited domain might happen that you don't want to
see appearing on the big-I Internet. I'm not really sure it's "fair" to hold
IOAM hostage. It's just delivering yet another use case for the behavior
instead of what I think is a general concern around limited domains. If we need
to go and solve the problem for limited domains, we should do that, but don't
ask IOAM to go and solve it for everybody.

Andrew: I think that's a fair comment and there is some work being done on
that. One other note while Frank is on the line, Frank, on my Discuss, you may
want to take a look at Suresh's document in 6man about how to handle stuff with
destination options. While that's still a draft, the solution to the second
part of my discuss may be a reference to that.

Erik K: I asked Suresh last night to consider adding some pre SRH hop by hop
destination option treatment text to his SIDS document.

Frank: We can absolutely do that, that's a fair comment. Some of this stuff has
been cooking for a lot longer than SRV-6. We can fold those in if so required.
Overall I think you know the history of that document, it's a merger of 2
documents, which you still see a document which was more of an informational
document to provide a set of considerations, not really guidance but
considerations, for what might need to be considered to deploy IOAM and the
other is asking for code points. So it's more of a specification and
informational combined.

Martin: Okay, I think this has been helpful. What I would hope people take away
from this is let's try to think systematically, since this is a template for
future instantiations of IOAM. Let's try to figure out a system to make this
less painful in the future. Does anyone else want to say anything about this
document?

Frank: A high level question; would it make sense to split this document again,
into one part that's purely about deployment considerations and one that's
purely about the code points? One informational and one standard?

John: If that's addressed to me, I think that potentially could work. We
shouldn't try to hash it out on the call right now because time is limited. Up
to section 4 it's super straightforward. Let's continue in email or a call
later.

Erik K: I had a different concern about IPv6 protocol violations but I
suggested a way forward in my followup.

Martin: There are several Discuss points on this ballot that are legitimate and
the authors need to deal with them; I just wanted to address a couple of
themes. Thank you.

Amy: Okay, so for this one we'll give this a Revised ID Needed and move on.

Martin: We're also going to need one more ballot on this, because of the
Abstain.

Lars: I'll take a look at it.

 o draft-ietf-ipsecme-ikev2-multiple-ke-10  - IETF stream
   Multiple Key Exchanges in IKEv2 (Proposed Standard)
   Token: Roman Danyliw

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

Roman: Thank you for everyone's review. I had a question. I was trying to go
through and see whether all the comments were addressed. Paul, the way you did
your ballot, are you saying everything is good to go? You re-pasted the Discuss
and I wasn't sure what you meant.

Paul: I tend to put my Discusses in after they're resolved in the comment
section otherwise they vanish from history. But yeah, it's all resolved.

Lars: It's not actually vanished, because the history of the document will have
the old Discusses.

Éric V: What I do is put in the mail archive URL of the first ballot in my next
one, which makes it easier.

Paul: Good advice, thanks.

Roman: I'd like to put this in AD Followup; there's a reference check I want to
run down.

 o draft-ietf-stir-messaging-06  - IETF stream
   Messaging Use Cases and Extensions for STIR (Proposed Standard)
   Token: Murray Kucherawy

Amy: I have a couple of Discusses; do we need to discuss any of those today?

Murray: I don't think so. I think I understood them. STIR is notoriously slow
at getting back with ballot feedback, so leave it to me.

Warren: I think similar to John on this, yes a lot of the document is
discussion around stuff, but it has a little bit of spec and I think that's all
that's needed. I don't understand the if it's not purely protocol we can't have
it as a standard thing. Maybe that's more of a discuss Discuss and we can take
it offline.

Murray: My intent is to ask if the WG or authors want to push back on what the
discuss holders are saying about that point. If they say they want it to be
this way, we'll go that direction.

Warren: One of my points of unease is not turning stuff into a lot of
additional work for authors and the IETF as a whole just for some sort of
process wangling stuff we think we need. The reason I mention this now is it
feels like this has happened a couple of times in this set of ballots. The EMP
for BGP thing was a lot of work to get a single code point. Having people take
docs and split them up to appease the process feels like allowing the process
to become the guiding thing, not the quality or utility of the document.

Rob: My comment wasn't really about trying to make extra work, it's that
there's a part of the document that's really waffly and not very precise.
There's a very small amount that's clear specification. All I was asking for
was to make those two bits of the document very clear, that this is the stuff
you'll have to implement and the rest is waffle. Don't mix those two things
together. That's all I was asking for, really.

Warren: Thank you; that's a lot clearer.

Murray: On the BGP document point, I agree that's a lot of process to do
something, but that's the process they have selected for their registry.
They've kind of forced that on themselves. You can't just do an IANA request on
that registry, it's standards action so this is the requirement.

Warren: That part of the soapbox rant was more of a meta point. That was
120-something emails, many hours of time, and I understand that's what's
required of that registry but maybe we should sometime try to discuss how to
get work to move through the IETF faster and provide guidance about standards
required registries.

Murray: That's an excellent point and Barry used to take that up as a cause,
don't make your IANA rules worse than they really need to be. I give that some
thought when I see new registries come through but I don't push back as hard as
he did. Maybe we should.

Warren: In this particular case I think that particular registry should
probably be standards required, because of what it is, but overall we keep
talking about how to make work faster but also spend a lot of time on process
stuff. Soapbox rant, moving on.

Amy: Okay, so this stays in IESG Evaluation and needs a Revised ID?

Murray: Let's do AD Followup, in case they decide to fight for this. I'll
change it if needed.

 o draft-ietf-lamps-rfc3709bis-08  - IETF stream
   Internet X.509 Public Key Infrastructure: Logotypes in X.509
   Certificates (Proposed Standard)
   Token: Roman Danyliw

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

Roman: Yeah, that would be super. Warren, I wanted to talk about your feedback.
I'm not sure how to resolve this. This is a little bit of a role reversion
where we have a bis document and I feel like you're asking if we should have
done the thing we already defined, which I know Security has a tendency to do.
I don't know how to answer your question other than to say we're revising the
thing we already decided we wanted to do with a little more guidance on the
graphic formats we wanted to support and a little more security considerations.

Warren: While writing it I did think this is already possible, maybe we
shouldn't be making it any easier. But I do understand that we've already
defined it. I have just changed my [ballot].

Paul: It's not making it easier; the increased security and privacy
considerations in theory make it harder to use.

Warren: Well, yeah, but I think people shouldn't be using it. Touching it again
and not saying this was a bad idea, make it historic. But whatever. I've just
moved from Discsus to No Objection because I don't really think my discuss
position is tenable. I still think it's awful. I believe people are going to
look at it and say I know this website should have a picture of a cat, this
looks vaguely like a cat, i'm not going to look at anything else and move on.
That means people are more likely to become victims to phishing attacks, etc.
but it's too late now.

Paul: For the record, I screamed too when I read this, and then I realized it
was a bis.

Warren: through the big repository of all certs for this specific oid, I could
not find a single one of these in the real world that actually worked. There
were some CA certs that had it, but the ones I tried were links to images that
didn't actually exist on the internet.

Roman: I appreciate that you cleared your Discuss, thank you. I'll note this is
another of five documents on this telechat that doesn't have enough ballots to
pass, so I'll ask for more reviews.

Lars: I'll put it on my list.

Amy: So it sounds like this is going to go into AD Followup so you can get a
few more reviews.

 o draft-ietf-stir-passport-rcd-23  - IETF stream
   PASSporT Extension for Rich Call Data (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: No, there's enough for me to take back to the WG and talk to them.
There wasn't anything that stuck out to me as needing discussion. Roman, did
you want to discuss?

Roman: No.

Murray: Okay. AD Followup please.

 o draft-ietf-lamps-5g-nftypes-08  - IETF stream
   X.509 Certificate Extension for 5G Network Function Types (Proposed
   Standard)
   Token: Roman Danyliw

Amy: I have no Discusses in the tracker, but it is still missing a position or
two.

Lars: I'll put it on my list.

Roman: If it's helpful, I'm happy to put these documents on the Dec 15 or the
Jan 5 telechat.

Martin: I have a comment about this. I think this is probably because of the
3GPP overlap thing. There's all this use your own NF types, please don't
collide, but there's no registry. Is that because we don't own it?

Roman: That's exactly it. I had a back and forth with the WG on exactly that,
because it didn't feel right. The right thing felt like creating a registry.
The answer I got back was not a satisfying one to the cleanliness of managing
this. Effectively, 3GPP doesn't have sufficient governance in place to think
about this right now so they need us to provide this mechanism and there will
be an evolution about how this ultimately gets managed. It's not as clean as we
would hope it would be.

Martin: Okay.

Warren: Cindy, would you mind refreshing? [Warren balloted No Objection and the
document now has enough positions to pass.] I had read it but hadn't balloted
anything.

Roman: Perfect, thank you. I still want to check whether all of the comments
were addressed; Approved, Announcement to be Sent, AD Followup please. Thank
you.

 o draft-ietf-stir-identity-header-errors-handling-07  - IETF stream
   Identity Header Errors Handling for STIR (Proposed Standard)
   Token: Murray Kucherawy

Amy: I have no Discusses in the tracker, so unless there's an objection now,
this is approved. It does have enough positions. Murray, is this ready to go
as-is?

Murray: Give me one more pass on it, please.

Amy: Okay, this will be Approved, Announcement to be Sent, AD Followup.

 o draft-ietf-idr-bfd-subcode-04  - IETF stream
   A BGP Cease Notification Subcode For Bidirectional Forwarding
   Detection (BFD) (Proposed Standard)
   Token: Alvaro Retana

Amy: I have no Discusses in the tracker, so unless there's an objection now,
this is approved. Alvaro is not with us but did say all his documents should go
into AD Followup so this will be Approved, Announcement to be Sent, AD Followup.

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-lsr-isis-flood-reflection-11  - IETF stream
   IS-IS Flood Reflection (Experimental)
   Token: John Scudder

Amy: I have the consensus as Unknown here, so we'll set that to Yes. There are
no Discusses in the tracker, so unless there's an objection now, it looks like
this is approved.

John: Thank you, and for all of my documents today I'd like this in AD
Followup, and the consensus bit set to Yes.

 o draft-ietf-raw-use-cases-08  - IETF stream
   RAW Use-Cases (Informational)
   Token: John Scudder

Amy: We're going to set this Consensus to Yes for you, and we do have a
Discuss. Do we need to discuss that today?

John: Not as far as I'm concerned; I saw that Carlos replied to Roman and
hopefully that discussion will continue apace. It looks like there are also
some comments that need followup. Unless anyone wants to talk about this thing?

Andrew: Roman, I supported your Discuss here but I was also in two minds when
you're talking about purely use cases whether or not the privacy concerns are
in the use case or in the implementation document, if that makes sense. The use
case doesn't really change whether or not you've got privacy concerns.

Roman: This is one that will take some discussion to resolve. In my opinion
you've stated the use cases which are fabulous, you're not engineering the
protocol which I understand. It seems to me though, we have this idea of
security considerations and privacy considerations; it seems like you should
describe those at the level of abstraction at which you're describing the rest
of the document; if you were to describe a protocol, I'd expect a lot of
protocol specific mechanics. Here you're using prose to describe how things
will be used, it should feel like you can add one or two sentences about those
considerations relative to the prose. This idea of amusement parks and
watchbands doing tracking of humans, we should explicitly acknowledge that this
is something that's going to have to be worked out.

Andrew: That kind of makes it more clear. While I support the discuss and fully
acknowledge there are privacy concerns, I was of two minds about how much
detail to put in when you're discussing a use case.

John: I don't see any of the authors on the call but I kind of want to take
Romans' short statement from right now and send it to the authors. It's very
clear. One other thing; Martin, I thought your abstain was really well taken
and also an awesome use of 'banal' in a ballot. I'm not sure we're actually
going to end up restructuring the document to this extent. You're right, it's
just a question of whether it's worth everybody's time.

Martin: It's harmless  as it is, even if I don't think it's a huge
contribution. I think there's probably a retreat topic in here about use case
and requirements documents, but I'm not going to hold that against these
particular authors.

Warren: I think I disagree on a lot of that stuff. I always think that use case
documents are really useful. This one maybe not quite as much as others, but
when someone has to deploy a protocol, having an architecture and a use case is
similar to understand what it's supposed to be accomplishing so they know when
it's working.

John: I thought Martin offered a rubric for how to produce a use case document
that is fit for purpose.

Warren: Somewhat. I guess more discussion needed at some other time. I found
this kind of useful.

Roman: to support what Martin was saying, I appreciate prose that tells me how
it could be used. What could have tightened this up was if this is used to
engineer a solution, you need much tighter performance envelopes to be able to
action it. Saying low latency is helpful, I don't know how you write a protocol
against it. If you say amusement park you have to follow it up with numbers
that are specific.

John: Anyway, this isn't going to be moving forward in the next week, so there
is further time to have these discussions.

Amy: You still want this in AD Followup?

John: Yes.

 o draft-ietf-ccamp-gmpls-otn-b100g-applicability-15  - IETF stream
   Applicability of GMPLS for Beyond 100G Optical Transport Network
   (Informational)
   Token: John Scudder

Amy: There are no Discusses in the tracker, so unless there's an objection now,
it looks like this is approved. We'll put this in Approved, Announcement to be
Sent, AD Followup.

 o draft-ietf-dnsop-rfc5933-bis-13  - IETF stream
   Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource
   Records for DNSSEC (Informational)
   Token: Warren Kumari

Amy: I'm changing this consensus from Unknown to Yes.

Warren: Thank you. I would like to discuss this, assuming that was going to be
your next question. This document does update an existing standards track
document, and I understand that it could be split into two different documents,
but this document talks about how one uses a crypto algorithm. It doesn't
define the crypto algorithm itself. It just says, if you're using this crypto
algorithm that was developed over here in DNSSEC, here's how you munge things
to make it work. To me, having it in the IETF stream seems correct and
reasonable. I'll also note that the authors have been working under the
assumption that was the right thing to do. They've put in a bunch of time and
effort on this. Getting to the end of the process and being told they've done
it all wrong and should do it this other way that feels arbitrary, doesn't feel
reasonable. This was a document that was going to move forward as a cluster, so
it's not just a small delay for this document, it impacts other documents that
have been waiting on it including the DNS terminology one. If this actually
defined GOST, I would much better understand Paul and Roman's position. Seeing
as it doesn't, this feels kind of arbitrary.

Roman: Yeah. But my retort to that is, when we specify behavior, then we
comment on the sec cons. To specify the code point, then we need to talk about
why we have confidence in what we have specified. What is the basis of the
security analysis that we are doing?

Paul: The thing is that during this document's life cycle, the registries got
updated. It had to be in this stream because of the registries, but the
registries have now been relaxed enough that it can go through the ISE.

Warren: Except for the fact that the document obsoletes 5933 and updates 8624,
which I don't think an ISE document should be doing.

Paul: But as Roman also pointed out to me, if this is your reasoning now,
you'll never get out of this reasoning when there's a new version of GOST in
the future. You'll have the exact same problem again.

Warren: To me it feels like a more reasonable thing to do would be for there to
be a statement saying this is how you use the algorithm in DNSSEC; we're not
saying the algorithm is good. If you're using whatever, and we make an explicit
statement that we don't think the whatever you're relying on is a good idea,
that feels more tractable than this which mainly says how to use something,
whether or not the something is reasonable.

Paul: Maybe I don't see the bigger issue you're worried about. We could
basically finish this document here on all the other items and leave out the
stream issue. Say it's ready to pass and hand it over to the ISE who hopefully
could just quickly let it go. This shouldn't be more than a two week delay,
right?

Warren: If the ISE agrees to that, perfectly fine with me. Saying dear ISE,
we're all happy with this but we don't want to dirty our hands by publishing
it. You take it and do it for us…

Paul: I can rephrase it somewhat more positively.

Roman: What was the point of relaxing the registry entries, as was done not
once but twice, if not to allow for exactly what we're saying, which is we're
going to have algorithms we can't review that can be specified elsewhere, and
it's okay to specify them but we're not going to do it. Otherwise, why relax it?

Warren: We relaxed it because this used to be standards track and it was taken
off standards track because people were uncomfortable with a standards track
saying here's GOST, you might want to use it with DNSSEC. We made it
informational instead specifically to address these concerns. We all thought
that would be sufficient because it doesn't define GOST.

Roman: I'm making a different distinction. I'm not talking about whether this
document is PS or informational, what I'm saying is that there were changes
made to the registry policies with two other RFCs. is that not why we did that,
to allow for exactly having an ISE document on these code points? Why did we do
6014 and 9157 if not for this exact situation?

Warren: Those were relaxed so they didn't need to be standards track, because
people wanted to more easily introduce algorithms. That was done a long time
ago, before this.

Paul: Not entirely. The WG really disliked having more algorithms. There's this
whole thing of nation-state crypto which they need to allow, and that's why the
relaxation was done. Not because DNSOP likes to see even more algorithms
published; they do not.

Warren: DNSOP even more than that does not want people to squat on code points.
That was some of the reason for relaxing originally, the earlier version.
Otherwise people were just going to squat on code points.

Paul: Warren, if your main concern is that it will take too much time, cna we
first ping the ISE and see if we can get it done quickly?

Roman: I'm not sure if folks saw in my ballot, I provided how to do that fast,
you have a document with four sections you pull out of the current document,
that's what you ask the ISE and then the residual text stays in the IETF
stream. That gives GOST an agile mechanism to update itself tomorrow and
structurally fix this problem of the IESG having to re-litigate this situation
about why this was one of the last places where we have national crypto in the
IETF stream when we have the flexibility to not do that.

Warren: Okay. I'll talk to the authors. It just feels like they've been jerked
around with this document, which I realize is not your problem. I can propose
it. Thank you for making the suggestion. I'll have another look.

Roman: I struggle to see that given the work in TLS, SSH and others where we
have a fairly well trodden path to the ISE for these. I'm confused why they
feel singled out, because this is consistent with other standard practices of
the last few years.

Warren: I guess thank you for your suggestion. I will chat with the authors.

Paul: I have one other item in my Discuss; they were discussing changing one of
the bits but they should make the whole thing obsolete.

Warren: I will re-read your Discuss and chat with you some more about it. Sorry
for being riled up about this.

Amy: Do you want AD Followup for this?

Warren: Yes please.

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-smyslov-ike2-gost-00
   IETF conflict review for draft-smyslov-ike2-gost
     draft-smyslov-ike2-gost-12
     Using GOST Cryptographic Algorithms in the Internet Key Exchange
   Protocol Version 2 (IKEv2) (ISE: None)
   Token: Roman Danyliw

Amy: I have no Discusses for this conflict review, so it looks like this is
approved.

Roman: Just to put a fine point on it, this is exactly what I was talking about
in the last document where flexible registry policies allow this national
crypto.

Warren: Some of it is because the original GOST thing was a standards track
document. But let's move on.

Amy: I'm hearing no objection to approving this conflict review message, so
we'll send this to the IRSG.

3.4.2 Returning items

 NONE

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

 o Javascript Object Signing and Encryption (jose)

Amy: This is the re-animation of a closed WG. I have no blocks for this charter
to external review, so unless there's an objection, this can go for external
review.

Roman: I appreciate everyone's review and John, about half an hour before the
telechat I merged your editorial comments. That's -01.

Amy: Do you need to add anything or is it ready to go right now?

Roman: It's ready to go.

Amy: Thank you; we'll get that sent.

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Warren: I don't believe there's news; there was no IAB call yesterday. Mirja
and Lars might have updates?

Mirja: The important news is there is a workshop going on next week. There will
be four sessions about energy impact and environmental impact. If you want to
join, contact Jari.

6. Management issues

6.1 Designated Experts (Rob Wilton)

Amy: Rob has identified three replacement designated experts for three
registries.. Are there any objections to these changes? I'm hearing no
objections, so we will send official notice to IANA about all of these three.

6.2 Designated expert for IANA-MAU-MIB (Rob Wilton)

Amy: This item is to approve Marek Hajduczenia as the primary expert for this
registry?

Rob: I'd like to thank Marek for doing this.

Amy: I'm hearing no objection, so we'll send notice to IANA. Thank you.

6.3 [IANA #1241511] Designated experts for RFC 9290 "Concise Problem Details
for Constrained Application Protocol (CoAP) APIs" (IANA)

Amy: Francesca has picked up this action item.

6.4 [IANA #1241556] Designated experts for RFC 9303 "Locator/ID Separation
Protocol Security (LISP-SEC)" (IANA) 6.5 [IANA #1241559] Designated experts for
RFC 9305 "Locator/ID Separation Protocol (LISP) Generic Protocol Extension"
(IANA)

Amy: These are both for Alvaro and we'll make sure he sees these when he
returns.

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

Éric V: Just a quick reminder, I sent an email about a poll box in Meetecho. If
you can comment and provide me feedback on my one-sentence proposal, that would
be cool. That's all.

Lars: Talking about this ICANN announcement of this RFC annotation thing;
Sabrina has reached out to someone on their CTO's staff. I haven't gotten email
from them yet but I suggest we might want to take some time next Thursday on
the informal to see if we want to chat with them and amend what they've offered
in a way that makes us less unhappy. I'll suggest that.

Jay: I was just going to respond to Eric, but I'll do it by email.

Francesca: I also wanted to mention that Murray and I are going to create a new
directorate for HTTP reviews. I don't think there should be any problem, but
just a heads up.

6.6 Executive Session:  IESG appointment to the IETF Trust (Lars Eggert)