Narrative Minutes interim-2024-iesg-03 2024-02-01 15:00
narrative-minutes-interim-2024-iesg-03-202402011500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2024-02-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
Amanda Baber (ICANN) / IANA Liaison
Jenny Bui (AMS) / IETF Secretariat
Roman Danyliw (CERT/SEI) / Security Area
Dhruv Dhody (Huawei) / IAB Liaison
Martin Duke (Google) / Transport Area
Lars Eggert (Mozilla) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Routing Area
Mahesh Jethanandani (Arrcus) / Incoming Operations and Management Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Meta) / 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
Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area
John Scudder (Juniper) / Routing Area
Orie Steele (Transmute) / Incoming Applications and Real-Time Area
Gunter Van de Velde (Nokia) / Incoming Routing Area
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Sabrina Tanamal (ICANN) / IANA Liaison

OBSERVERS
---------------------------------
Deb Cooley
Suresh Krishnan
Eliot Lear
Greg Wood

1.2 Bash the agenda

Liz: Does anyone have anything to add to today's agenda? Any other changes?

1.3 Approval of the minutes of past telechats

Liz: Does anyone have an objection to the minutes of the January 18 IESG
Teleconference being approved? I'm hearing no objection, so those are approved
and we'll post them in the public archive.

Does anyone have an objection to the narrative minutes of the January 18 IESG
Teleconference being approved? I'm hearing no objection, so those are approved
and we'll post them in the public archive.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Roman Danyliw to find designated experts for RFC 9447, ACME
       Authority Token Challenge Types" [IANA #1281679].

Liz: We have a management item at the end of the call to approve an expert for
this registry, so we'll mark this as provisionally done.

     o Robert Wilton to find designated experts for RFC 9487 (Export of
       Segment Routing over IPv6 Information in IP Flow Information Export
       (IPFIX))[IANA #1287238].

Liz: We have a management item at the end of the call to approve an expert for
this registry, so we'll mark this as provisionally done.

   * OPEN ACTION ITEMS

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

Murray: Barry won't have time to get to this solo, so we're going to create a
Github project to collaborate on this with IANA and it will be in progress very
soon.

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

Andrew: In progress.

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

Lars: In progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-netconf-crypto-types-29  - IETF stream
   YANG Data Types and Groupings for Cryptography (Proposed Standard)
   Token: Robert Wilton

Liz: We have some Discusses in the tracker; do we need to discuss those today?

Rob: I don't think so, unless someone else wants to. I think Kent is responding
to issues. Roman or Paul, do you want to discuss?

Roman: No, my only comment is I think the hidden thing is a thread through a
number of the documents.

Rob: I was talking to Paul offline about that, trying to manage keys in TPMs
versus YANG semantics where there's an expectation all the configuration is
complete. I think that's a bit as to why these hidden keys have turned up, you
still need to be able to complete the configuration but you don't want to put
the private keys in. I think that's a running theme that's trying to get around
some of the YANG or NETCONF restrictions.

Roman: Yeah, there's an architectural thing. I think it comes up in someone's
Discuss on one of the other documents, where there's a semantics being
described here. I've thought of these YANG documents as describing this XML
blob, this data model for stuff. There's a whole bunch of additional semantics
in the keystore document about how you manage things, now there's multiple
APIs, these expectations with TPMs, and I thought we were only talking about a
data model but now we're talking about handling it.  That was a little
confusing.

Rob: I think it's a limitation of trying to get flexibility in there. In some
cases you want to be able to configure these keys and you might encrypt them.
You want to have that flexibility and you want to define the data model
correctly that says if you have one of these keys you need to have both of
these bits, you can't have half a key. At the same time, when you're then
reporting on that and exposing it, you don't want to expose this data. So it's
a bit icky. There are discussions happening about whether we should change the
YANG architecture to address this but there are different views on that. I'm
not sure there is long term consensus on where to go. Where I ended up is the
data model should accurately reflect the way things are and what's expected to
be there. Protocol issues, we'll have to see how we handle those in future and
further discussions are required. I think it's important to get these documents
done.

Paul: The way I read them was the considerations are purely for how to do
things in the management configuration. The security for managing the
configuration itself and not so much for generic uses that are enabled by these
configurations. That's how I interpreted these advisory things like if you
encrypt your configuration file, don't do it with a weak key.

Rob: The bit it's falling afoul of is this idea that YANG validates
configuration and it's complete, so all the references are complete. If you're
referencing how to use a particular keystore then it has to exist, and if you
reference a key in that keystore you have to know it exists. Traditionally YANG
says that reference has to appear in that configuration and that's the bit it's
falling over on. Does that help, or have I just confused things?

Roman: I have less concerns about this one because I think it's possible to
explain the hidden. I think it's the other one I'm more worried about.

Rob: I'll leave Kent to drive this since he has the background, and if more
conversation is needed, I'm happy to drive those.

Liz: Rob, will this require a Revised I-D?

Rob: Almost certainly, yes.

Liz: To save ourselves a step later, there's a downref here to RFC 7093. Once
this is approved, do you want us to go ahead and add that to the downref
registry?

Rob: I don't think so, we can just have it the once.

Francesca: This was Last Called, so the IESG doesn't need to approve it - the
question is just whether to add it to the registry, which I think is no.

Rob: Oh. Yes, that's right.

Liz: Thank you.

 o draft-ietf-netconf-keystore-30  - IETF stream
   A YANG Data Model for a Keystore (Proposed Standard)
   Token: Robert Wilton

Liz: We have some Discusses in the tracker; do we need to discuss those today?

Rob: Roman, Paul?

Roman: This is where we got into the architectural questions, where there were
discussions in Section 3 about other APIs and it wasn't clear to me what that
API was and what it had to do with YANG. It just gave me pause that we're
providing normative requirements on the existence of these APIs and they seem
underspecified. I think I pointed out in what ways you might want to do that.

Rob: My assumption is that this is about upgrading those trust stores and key
stores out of bound. So effectively you're not using YANG, but some other
process on the device.

Roman: One thing I didn't understand with the YANG document was it seemed like
we were talking about a repository of keys, but the way I read the text was
that a management interface fronted some store, but then language about what
store it needed to be in, which suggested there were multiple stores. Then I
was wondering if this is the YANG interface for a TPE API, but no because it
seemed there was another API. A little architectural clarity would have helped
me.

Rob: Okay. We'll see if Kent can address those.

Roman: My bigger question, not on this one, is I've never seen a YANG document
that talked about backup and restore procedures. Is that a thing we should be
putting in mandatory operational considerations or do you feel like this one is
really special?

Éric V: I raised the same concern, because it's going beyond a data model and
talking about operation. They will change the title to include operation.

Rob: To answer your question, Roman, I think this one is special. The vast
majority of yang models are just defining configuration. Here it's because you
are storing particular keys, they're more sensitive. Or the other one that
comes up in this document is trying to transfer configuration between devices
and how you do that in a secure way.

Roman: Part of it is, I'm not the expert, but I've heard about it in SUIT,
RATS, and TEEP. If we're really talking about forklifting keys across TEEs, I
don't know whether we've used enough language here, but we do say we support
that.

Paul: If you look at it from a point of view of a configuration file you need
to migrate to another unit, that's really what it's talking about. The
encryption keys become a complication. Maybe it should just only say to take
care if you do this and leave out the details about restore and backup. Another
document could specify that if they wanted to. Just saying, remember, if
something in your configuration is encrypted, it's not a usable configuration
when you migrate it until you have the keys that belong to it.

Rob: Maybe. I think the key is you're going to use the TPM keys to sign some
things, but that's not enough and having a separate step allows you to make
your configuration more portable. I think the approach you're suggesting is
quite useful that it could go into a separate document.

Roman: My concern is it started invoking APIs that have particular functions,
and then it seemed to intimate that those APIs need to exist in certain places.
I never understood what those APIs are, who's providing them, and where they
needed to be. I don't know whether a layer on top of the TEE, a layer on top of
some open SSL library, or some network based API.

Rob: My expectation there is that that's out of scope and this document
shouldn't specify what the API is, just that if it's done out of band, here's
what you need to account for. Maybe that can be clearer.

Liz: I'm guessing this might be a Revised I-D as well?

Rob: Yes, thanks.

 o draft-ietf-netconf-trust-anchors-23  - IETF stream
   A YANG Data Model for a Truststore (Proposed Standard)
   Token: Robert Wilton

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

Rob: It sounds like the feedback here is similar. Is there anything different,
Roman, on this one?

Roman: Same thing. Nothing new here.

Rob: Okay. Then I think we're done for this one and it can also be Revised I-D
Needed. Thank you everyone for the reviews.

 o draft-ietf-suit-mud-07  - IETF stream
   Strong Assertions of IoT Network Access Requirements (Proposed
   Standard)
   Token: Roman Danyliw

Liz: We have some Discusses in the tracker; do we need to discuss those today?

Roman: I just wanted to briefly go over everything. Thank you everyone for all
the reviews. Éric, correct me if I'm wrong, we talked about things in email.
We'll get the edits on the update for you. Rob, I'd like the authors to respond
to you on that consideration. For me, we can put it in the operational
considerations and that seems editorial, but you have a tangible concern here
so we can work on that. Is that a good understanding?

Rob: Sort of. I had some offline discussion with Eliot who's not an author on
this document but he's playing in the space. It sounds like from Eliot's
comments that he thinks the concerns are sort of valid but doesn't think they
should be addressed here. Which is fine with me. This is future work mostly and
maybe a little bit more text here. I think an operational section would be
helpful just in terms of directing people. I think it's minor changes.

Roman: Okay. Éric, we traded some email, did you want to talk more about
anything?

Éric V: As long as there is an update coming, I'm all set.

Roman: So that brings us to the procedural observation, Francesca. I don't know
how that didn't get generated in the Last Call text, so thank you for adding
that.

Francesca: No worries. It was added after the Last Call, that's why it wasn't
there. It was probably a response to a Last Call comment. We should just
approve it and then I can remove the Discuss.

Roman: Thank you for pointing it out. What do we do, just agree here?

Liz: Any objections to approving this downref for RFC 9334? Okay, we'll call
that good to go. The second part of that question is do we want to add that to
the downref registry?

Roman: I don't want to add it to the downref registry. I'd like to see it used
a little more.

Liz: Okay, so that downref is approved but not added to the registry. I'm
guessing we're going Revised I-D Needed here?

Roman: We sure are, thank you.

 o draft-ietf-lsr-ospfv3-extended-lsa-yang-28  - IETF stream
   YANG Model for OSPFv3 Extended LSAs (Proposed Standard)
   Token: John Scudder

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

John:  Roman, I saw that Acee had replied and I haven't had a lot of time to
review but it looked like you could summarize his reply as yes, once somebody
gets the ability to write to the OSPF config there's no end of mischief they
can get into, and are we really going to require every YANG model that touches
the routing protocols to enumerate every possible thing you can do to a routing
protocol, or is it enough to have that in the base?

Roman: There were two things I read in the feedback. One is something on the
order of, no one would do it this way because you'd need to do these other
things. That may be true but I thought the definition of a security
consideration for a yang module would be if someone in fact were to do it. To
your point of enumerating this each and every time, I'm sympathetic to that but
part of why I chose to Discuss it instead of leaving it alone is that there is
a declarative statement that says if you mess with this it results in denial of
service. But it doesn't just do that, it could possibly be these other things.
It's an inconsistency to say you don't need to repeat that but you call out one
attack, that's weird because it's not suggesting the others. I was surprised
that in the references to the underlying specs, no one said those things. That
seemed odd to me that in none of the chain of anything in OSPF that someone
bothered to point out you could mess with these. I'm happy to find some common
ground here but it seems like if you say denial of service you should say a few
more words.

John: That's fair. It sounds like we can probably finish that off in email with
Acee. Thanks. This should go in AD Followup.

 o draft-ietf-drip-auth-46  - IETF stream
   DRIP Entity Tag Authentication Formats & Protocols for Broadcast
   Remote ID (Proposed Standard)
   Token: Éric Vyncke

Liz: This document was deferred by Paul, so it will return on the next telechat.

Éric V: Of course, there is no problem, Paul, just to be clear. I prefer a deep
and qualified review.

Paul: I really just ran out of time, apologies.

Éric V: It's no problem.

 o draft-ietf-lamps-x509-policy-graph-04  - IETF stream
   Updates to X.509 Policy Validation (Proposed Standard)
   Token: Roman Danyliw

Liz: This is the only document today that doesn't have any Discusses, so unless
there's an objection now, we can approve this. I'm hearing no objections, so
one document is approved.

Éric V: Do you have an explanation for why it went so fast? One year between
the -00 and the acceptance. I think that's a record, I've never seen it so fast.

Paul: I believe this was the vulnerability announced at the last IETF?

Roman: This went to SECDISPATCH initially because there were some
vulnerabilities in some libraries and the question was where to go. It ended up
in LAMPS and we moved it fast because there were vulnerabilities. I think
there's even CV references in the document.

Éric V: Thanks for the explanation.

Liz: This one is approved. Roman, is this ready to go?

Roman: I have not had a chance to look at all the comments so I just want to
make sure there's nothing else there. Can we put it in AD Followup? Thanks for
the reviews, everyone.

2.1.2 Returning items

 o draft-ietf-netconf-https-notif-14  - IETF stream
   An HTTPS-based Transport for YANG Notifications (Proposed Standard)
   Token: Robert Wilton

Liz: We have a Discuss for this document; do we want to discuss this now?

Rob: I don't think so. I think John and Mahesh have agreed what the changes
should be. I think we're good to go once there's a new version posted.

Liz: Great, so we'll put this in Revised I-D Needed because there's a revision
coming.

Rob: Yes. Thanks all for the reviews.

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-6man-sids-05  - IETF stream
   Segment Identifiers in SRv6 (Informational)
   Token: Erik Kline

Liz: We have some Discusses here; do we need to discuss these today?

Erik K: I think we probably should. I'd like to level set that this is a 6MAN
document, it's not a full security review for SRv6, it's not a SPRING document,
it's not an SRv6 ops document about how to operationalize SRv6 security. I
realize SRv6 brings up a lot of feelings for people but this is just a 6man
document in response to some SPRING work. I'd like to maintain some context
there. I did see there were some comments that came in overnight and I haven't
read them all.

Jim: Mine is the quickest. I had a couple of exchanges with Suresh and he
satisfied mine, so my Discuss will come off once the document is updated. That
leaves John and Andrew.

Erik K: I've seen some ongoing discussions with Suresh and it looks like he has
changes queued up.

John: Similar in my case. We're close enough I don't think i'll have to keep
holding the Discuss after he pushes the next version.

Andrew: From my side I have a number of issues. Firstly, in my view this
document tries to say it's an IPv6 address but it's not an IPv6 address. It
comes across like quantum network where you have multiple states depending on
which way you view it and that creates a problem. Secondly, if you say that a
SID is not an IPv6 address, that creates a direct conflict with 8402. If you
claim that it is an IPv6 address, yes it does. In my discussions with Suresh, I
said to him I'd be far happier if this document explained that a SID is not an
IPv6 address. But it does say that, except 8402 explicitly states that a SID is
an IPv6 address. Then we get to the opposite position where we say if this is
an IPv6 address that automatically brings 8200 into scope and this document
explicitly says that these SIDs don't conform. Either way you create a
situation where you now have a lack of clarity. There's a solution. We can bis
8402 that states a SID is an IPv6 address. At that point, this document would
be fine. But until you do that you have direct conflicts in both directions.

Erik K: This document clarifies that a SID is an IPv6 address. There hasn't
been any statement to the contrary. What it's saying is that it's not a 4291
address. Which is an IPv6 address that has to be assigned to an interface. It
is an IPv6 address and that has always been the case. This document does not
change that, it just says this is one of the types of IPv6 addresses that does
not necessarily have to be assigned to an interface per the architecture of
4291.

Jim: I have to be honest, I'm a little bit annoyed about the whole thing. This
has been beaten to death for God knows how long on all of the mailing lists. If
you look on the wire, you can't tell whether it's an IPv6 address or not. If I
can figure a route with some code that allows me to do a funky thing with an
IPv4 address, if I look on the wire it's an IPv4 address. It's just semantics
going around and around and around and we've been over this. I don't know how
many emails we've had in 6MAN and SPRING on this very subject. I just don't see
what we're trying to achieve here. The document seemed pretty clear to me and
the wording in 8402 is pretty clear that it's an IPv6 address, just not
assigned to an interface.

Warren: From the abstract, the document says "Due to this underlying use of
IPv6, Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 addresses and
behave like them while exhibiting slightly different behaviors in some
situations." "can resemble IPv6 addresses" clearly is not "is an IPv6 address."
The assertion that these are IPv6 addresses is….

Erik K: That should probably say "resemble 4291 addresses."

Warren: There are a bunch of other places throughout the document where it does
similar things. In my Abstain comment I said this dances around whether or not
it's an address a whole bunch. I abstained because I think much of the document
is fairly awful, but at least it's trying to make the problem slightly better
by lumping all of this together in one potentially more easily filtered group.
I don't think it's clear as to whether it's an address or not.

John: To add to Warren's point, I was on team 'this is good enough' in terms of
IP addresses but after hearing Erik say clearly they are IP addresses, and
looking at the plain English of the document, I think we really do have a
problem here. I'm moving in the direction of supporting Andrew's.

Éric V: What would you do, John, about the DNS 64 addresses? they are not real
IPv6 addresses assigned to an interface either.

John: That's not what this document is about.

[crosstalk]

Warren: … nat 64 addresses say these are synthesized things which are mapped to
v4 addresses. I think SRv6 just said there's this field and ew decided to shove
something that looks like an IPv6 address in it and people can forward on it.
That would be a lot better than trying to play both sides of the coin.

Andrew: I have to agree and I also have to say that in the case of nat 64,
different situation, different story. If I saw the same thing and I went
through it, I can't remember if I was around when that was done, but if I saw
the same thing I'd possibly say the same thing. I look at these documents as a
document that has come before the iesg and my evaluation is that this document
is handwaving around the addresses. I do not believe it is clear these things
are or aren't v6 addresses. If they aren't, then there's possibly a problem
with 8200. If they are, there's  a problem with 8402. We've got to fix one or
the other.

Paul: It would be nice to have stronger language to say it's a band-aid and not
a proper fix. It could say this is a band-aid, please put it on, but look at
avoiding this problem altogether. That's why after reading Warren's abstain I
sort of agreed with him, but put the band-aid on because we're bleeding.

Erik K: I think the ether type stuff or other recommendations might be out of
scope for a 6MAN document. Let me ask Suresh if he wants to jump in here.

Suresh: Thanks Erik. I understand the concern. This document does not state
that it's an IPv6 address. I think the irregular part is there might be an
issue with 8402, but it's not fixable in this document. Let me go back and go
through our reasoning. Like Erik said, it doesn't follow 4291. So that's really
where the issue is. We talked about nat 64 as well. The nodes that don't do nat
64, they treat them as IPv6 addresses. They don't know these things are
synthesized. For anybody outside the domain, they are no different than any
other IPv6 address. So that is the inherent duality of this thing. There's
people who follow the SRv6 pack who do different things with it but the people
who don't understand it are just going through the island of people who don't
understand this. That's nothing different from an IPv6 address. Imagine
somebody had a v4 packet in it, and the nat64 doesn't, the people on the v6 nat
don't care, right? If there's wording where I can make that clearer, I thought
I'd covered that by saying there are transit nodes. The nodes that don't do
SRv6, treat them like IPv6 addresses. I think it covers both the cases, but if
we can strengthen the text, that's okay. For nodes that don't do IPv6, these
are not distinguishable from IPv6 addresses. They are IPv6 addresses. So that's
the part Erik brought up. Outside the domain it's a plain IPv6 address.

Jim: in the abstract, perhaps just removing the text that says resembles an
IPv6 address is all that this needs.

Andrew: No, because it goes further than that. For one thing it states that
these addresses are not assigned to hosts. That conflicts directly with 8402.

Jim: That's a different issue. Let's deal with one issue at a time. It seems to
me that in the abstract you could change that wording to remove 'resembles
IPv6' and that gets rid of the ambiguity.

Suresh: Sure, that's fine. And if you want stronger text, Andrew, to say that
this should not be assigned on an interface, I think we can add that too. It
says it's not assigned but we can say it cannot be assigned too.

Erik K: No, that would conflict with SPRING.

Andrew: 8402 explicitly states that hosts may be part of the SR delay. This
document explicitly says the exact opposite.

Erik K: No, it shouldn't. It just says the're not 4291 IPv6 addressing
architecture style addresses. They may not be assigned; it doesn't mean they
can't be. They're not required to be. We already have this other quantum
concept.

Warren: "While looking at the transit nodes, it becomes apparent that these
addresses are used purely for forwarding and not for packet delivery to end
hosts."

Suresh: Correct.

Andrew: Furthermore, it also says "It is clear that this format for SRv6 SIDs
is not compliant with the requirements set forth in RFC4291 for IPv6 addresses
but it is also clear that SRv6 SIDs are not intended for assignment onto
interfaces on end hosts." That directly conflicts with 8402.

Erik K: There are SIDs that can be assigned to interfaces. Adjacency SIDs.

Jim: Yes.

[crosstalk]

Warren: I think the bit I quoted is incorrect, because you can use these
addresses for packet delivery to end hosts. We just said end hosts can
participate and often do. Many cloud providers, as an example, do segment
routing type stuff to the host. The host is the thing that understands the
complex path it wants to send the packet around.

Erik K: Not SR aware end hosts.

Warren: I think having a prefix is really useful. I just don't really know if
the rest of the text around this as justification improves the situation. I
think it adds confusion.

Andrew: That's my problem. I'm not disputing that a prefix would be useful, I'm
saying this document as it stands in my view creates a lot more confusion
because you can end up with this weird quantum state address thing.

Warren: I do also want to say I think Suresh did an incredibly good job of
trying to thread the needle.

Andrew:  Don't get me wrong. Suresh, I appreciate the document. It is what it
is.

Warren: Suresh is in a difficult position and huge props to him for managing to
get it this close. It's huge to try to clarify specs which to me seem to be in
conflict.

Suresh: To be frank, we need to work with the previous deviations, like nat64
and all that. We can't just say all those things that have gone through the
IETF process are wrong. That's part of threading the needle. We've done things
like this before, and this is why this duality exists. And we've done this.
Warren, you know about this thing that says routing not being [slash 64?]. This
needed to be said, because that was not clear to a lot of people outside the
inside baseball paradigm. Everything here is strictly true. I understand the
discomfort that it doesn't give a clear answer, but this is as close as I think
we can get, saying that it doesn't follow 4291. If there's something that needs
to be done with 8402, I think we should do it. Maybe we can come up with an
update for that. But not on this document. I think it's bad precedent to say in
this document that something in another area's document is wrong. We won't say
someone doing a 256 calculation on the address inst allowed because they're not
following the address architecture.

Warren: If it didn't have the bit in the abstract saying they look like IPv6
addresses but aren't, and if it took out the bit saying they can't be used for
packet delivery to end hosts, that would go a long way towards making me less
twitchy. Because they look like a duck and quack like a duck, we're pretending
they're ducks. I'm only abstaining; I'm intentionally not blocking it.

Erik K: Are there some edits that would change you from Abstain to another
position?

Warren: [laughing] Delete sections 1 through 4 and just allocate a global
prefix for SIDs and then I'd ballot yes? Obviously that's not reasonable.

Andrew: As I said, if 8402 said these things weren't v6 addresses, I'd have
almost no problem. While there's that conflict, I am going to need to give this
long and serious consideration as to what could potentially change my mind. At
the moment, I don't know the answer to that. I do see conflicts here and I do
not believe the argument that because we've done strange things in the past is
ever sufficient justification to do more. I'll never buy into that argument.

Warren: What if the document explicitly noted that 8402…

Andrew: [crosstalk] If the document said 8402 is wrong, I'd be good with it.

Warren: The right way to fix that is new consensus.

Erik K: There might be a way to punch up the nat64 dual analogy where if you
know what it is, you know what it is, and if you don't it's a v6 address you
forward, to basically say that' show SRv6 sids operate. This is not a past
action justifying a future action, there's past precedent justifying slightly
more recent past precedent, not future action. This has already happened.

Warren: Although 8402 strongly implies or states that these are an address, in
many environments it's more that they act like an address. Something like how
they are treated in the real world.

Andrew: If you say these things are v6 addresses out there on the Internet, you
imply they are safe v6 addresses. They're not, because the moment they get
somewhere that doesn't see them as v6 addresses, they suddenly become something
else. Suresh, that's snot a problem with your document, it's a problem with
SRv6, that an address is suddenly a funky quantum thing. This document seems to
confuse the issue rather than resolve it. If there was a way to assign a prefix
without creating further confusion, that would be wonderful.

Suresh: I like Warren's suggestion. I can work on some text to talk about what
8402 says and what it means in an operational network. If you're willing to go
in that direction, I think I can work on some text.

Andrew: We can certainly take that offline and work on it.

Lars: This sounds like an excellent topic to use the informal for. We haven't
used them lately. If you want to invite Suresh or anyone else, invite them, and
let's hopefully make some progress.

Erik K: Thanks everyone for reviewing and commenting, and to Suresh for being
here.

Warren: Seriously, thank you very much Suresh for trying. It's hugely important
that we get this sorted out. And thanks Erik for trying to carry it.

Andrew: Thank you to both of you.

Erik K: Pretty clearly Revised I-D Needed, I think.

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-hrpc-guidelines-00
   IETF conflict review for draft-irtf-hrpc-guidelines
     draft-irtf-hrpc-guidelines-20
     Guidelines for Human Rights Protocol and Architecture
   Considerations (IRTF: Informational)
   Token: Paul Wouters

Liz: We have a Discuss here; do we want to discuss this now?

Paul: Briefly, yes. I'm not sure what Roman's concern is when they list some
examples of work they have done.

Roman: My observation is that there's a reference there to a repository that
makes recommendations on IETF stream protocols. That minimally seems that it's
not entirely clean. I'm not saying there's an issue, but we're already
providing commentary here on in-flight protocols. What I didn't do was actually
take a look at whether the recommendations conflict with what the documents
currently say. If we're in that situation, that seems a little problematic.

Paul: The link is to a live document, because it's in Gitlab. I don't think you
can say how it will be five minutes from now. It's more a principle matter.

Roman: Yes. We're now in editorial vs conflict review. I think the answer is
just remove that link which changes nothing. But my concern is the situation
we're setting up is we're publishing through a reference that seems to be
argued as the basis of the document, recommendations on in-flight IETF
protocols and some of them are published. I think that is a conflict. What am I
missing here?

Paul: I see it more as a historic link giving some background of things they've
done in the past to help protocols.

Roman: And I would agree with that, except the text in those references says
the recommendation is to do the following. So if there was just an observation
that we ran an HRPC evaluation on protocols, here's the mismatch we found, that
would be perfect. But the text goes further and says as a result of this
review, here are the recommended changes. That's where I think the line is
crossed.

Paul: I think that's fair. I'll look into more details in the reference and
I'll talk to the authors and we can return this item on the next telechat.

Liz: Sure. There's no AD Followup state for conflict reviews so we'll just
leave this in IESG Evaluation where it is while you work on it.

 o conflict-review-farinacci-lisp-lispers-net-nat-00
   IETF conflict review for draft-farinacci-lisp-lispers-net-nat
     draft-farinacci-lisp-lispers-net-nat-07
     lispers.net LISP NAT-Traversal Implementation Report (ISE:
   Informational)
   Token: Éric Vyncke

Liz: We have a Discuss here; do we want to discuss this now?

Éric V: Yes, thank you everyone for reviewing it. Martin and Paul, this was my
first concern when I saw this. We just approved the rechartering of the LISP WG
containing a NAT work item. So it's documenting an experiment. This is kind of
the way ISE is sometimes used. I have no hard feelings anyway, but I think I
saw Eliot on the call earlier, so if you would like to add something you may.

Eliot: Good afternoon. I don't really want to add too much here other than to
say I took thai draft on in part because the topic this covers was sort of dead
in the LISP WG. they have since rechartered, but this was well underway before
that. Even in the rechartering, if you look at the draft that's referenced, it
hasn't been updated for three years. I'm not in a hurry, I don't think Dino is
in a tremendous hurry, but what I don't want to do is be unfair to him in that
just because something is chartered in a WG doesn't mean anything actually
happens. I don't want to drag him out too long. That's my main thought, there's
always an opportunity to defer, and I shouldn't say much more.

Lars: We've had cases like this in the past. Basically we can tell the RFC
Editor to not publish this on the independent stream until the IETF work item
is out. That means Dino will have to wait. That's exactly why we have these
conflict reviews, it's end-run protection. It would have been different if LISP
hadn't rechartered to work on this; now we have actual IETF work chartered in
the space so I don't think anything should be published in the independent
stream while this is still pending.

Martin: [garbled] While I agree this is an unfortunate situation that's a
little unfair to him, we can't publish anything until after the consensus
document.

Éric V: That makes sense. How do we proceed? I've never heard of this before.

Lars: This happened ten years ago where we would have rejected stuff from WGs
go to the ISE, and because WGs are slow, they were able to potentially get
their RFC from the rejected proposal first. That was the whole reason why this
conflict review was instantiated in the first place. Before, the ISE could just
publish whenever. This is not quite the same case, because it's not like
someone maliciously wants to do this, they just have done this and the IETF
changed its mind. The optics are similar. My preference would be to do the same
thing we've done before and basically hold this for update. And ideally add
text to the ISE stream document that says 'here's the IETF document in this
space.' We can do that with an IESG note as well.

Éric V: So basically we remove the conflict and send it back to ISE?

Lars: I guess I need to have a chat with the RPC. This has not been done in a
while. I think we basically told the RFC Editor don't publish this as an RFC
until this other draft from the IETF is also with you, and basically treat them
as a cluster. I don't know if they have any running code for how this works
anymore.

Eliot: If I may, 5744 covers that. I think what you're talking about is your
third option: "The IESG has concluded that publication could potentially
disrupt IETF work in WG X and recommends not publishing the document at this
time." You Can send it back to me like that. All I ask in return as we go
through this process is if nobody updates that draft for a good long while, 
I'm going to send it back to you for another review and I expect a better
answer at that point.

Lars: It would need to get off the charter. Just because a WG is slow is not a
reason to let something go. But we can have that discussion once it's in that
state and I'm off the IESG.

Eliot: Thank you everyone.

Martin: Is this NAT thing really going to happen, Jim? Do you have a sense of
that?

Jim: It looks like it's going to happen. A lot of the recharter in LISP was to
cover things they've pretty much already done and get them in scope. I'd need
to go look at the NAT one specifically.

Lars: That was one of the items I asked them to cut. Remember there was a long
shopping list and for every single thing I asked if they were really going to
do it, and they said yes. So now they need to deliver.

Jim: I'm keeping my eye on it.

Éric V: Okay, so I will change the conflict text then and can we approve it at
the next telechat?

Liz: If you want we can just leave it in IESG Evaluation for now and give
Martin and Paul a chance to clear their Discusses, and then we can bring it
back for next time.

 o conflict-review-cuiling-dnsop-sm2-alg-00
   IETF conflict review for draft-cuiling-dnsop-sm2-alg
     draft-cuiling-dnsop-sm2-alg-15
     SM2 Digital Signature Algorithm for DNSSEC (ISE: Informational)
   Token: Roman Danyliw

Liz: There are no Discusses here, so unless there's an objection, this conflict
review is ready to go back to the ISE. I'm hearing no objection, so this is
approved and ready to go.

Roman: I think we're good to go here. We polished it already.

Liz: Then we can call this approved and we'll send it.

3.4.2 Returning items

 NONE

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

 NONE

4.1.2 Proposed for approval

 o Network Management Operations (nmop)

Liz: There are no blocking comments, so unless there's an objection now, this
is approved.

Rob: Thanks everyone. I've merged in the latest comments already. We just need
to change the email address from what it is now to NMOP. What's the order of
operations there?

Cindy: We need to create a new NMOP list. Do we just announce the new list and
have people sign up themselves, or do we move everyone from the existing list?

Rob: Ideally we'd just move everyone over, if that's allowed.

Cindy: We have done that recently, so we can. We will create the new mailing
list, move folks over, close the old list and retain the archive, and then
announce the new WG.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Roman: In the spirit of bringing outside people in to brief the IAB, in
February there will be some expertise on UN activities that may have an impact
on IETF work. That's going to be February 28 and I don't have information on
the speakers but I think that might be interesting. That's it.

6. Management issues

6.1 [IANA #1281679] Designated experts for RFC 9447, ACME Authority Token
Challenge Types" (Roman Danyliw)

Liz: Roman has identified Mary Barnes as an expert. Does anyone have an
objection to naming Mary as the expert? I'm hearing no objection, so we'll send
the official note to IANA.

6.2 [IANA #1352987] Acceptance of media type registration from standards
organization MIDI Manufacturers Association (IANA)

Liz: We've received this request from the MIDI Manufacturers Association; has
anyone had a chance to look at this for more information?

Murray: I did. I don't have any objection.

Francesca: It's not really an objection, but I insist often in drafts that the
request is sent to the media types mailing list, and this wasn't. I know it's
not mandatory, so I'm okay with approving it, but should we make it so that
it's more visible?

Lars: If we want to make this a thing, maybe we can ask IANA to forward it when
they get a request.

Amanda: We are currently copying the list on the expert review requests.

Lars: So this should have gone to the list?

Amanda: We don't send it to the experts until we get acceptance of the
organization. So if this is approved, we'll send it to the experts and the list.

Francesca: How much more work is it to ask IANA to send this to the list before
it gets to the IESG? I don't want to add work for you guys.

Murray: I want to make sure we're doing that for the right reasons. The
decision about adding them to the list is an IESG decision. The decision about
whether this is a sane media type request is an expert decision. I'm having a
hard time figuring out what the right order is.

Lars: This is the request for a decision on whether we want to, in the future,
accept registrations from them without having to go to the IESG. Amanda, it
would be good if you could highlight that in the action items you put on the
agenda in the future so that we're not constantly getting this confused. We're
supposed to vet the organization, whether they're a legit standards body. In my
book, this one seems to be.

Murray: This comes up from time to time as what's the point of the IESG looking
at these? The point is that we want to decide if there's going to be a lot of
activity from this potential SDO, should the IAB create a liaison, should we
pay more attention to the source of these registrations, is there something
here we should pay attention to. It's like a one time chance to think about it.
Should that come ahead of the registration? That's the part I'm wondering
about. And we don't want the experts to worry about that.

Lars: If I recall correctly the RFC doesn't allow us to just approve the
request if it's from another SDO. This is one that Barry was going to fix. At
the moment, we cannot just say yes to the request if it comes from another SDO,
we need to also approve them, which is a little bit backwards if we don't
expect another request from them. We're going to disentangle that at some point
but it hasn't happened yet.

Murray: something for me and Orie to look into, I guess. I think this one is
fine to approve. We can figure out the process later.

Francesca: Sounds good.

Orie: On the topic of order, is there some conversation on the list we're
expecting to have been valuable prior to making this decision? Are we lacking
information from some conversation on the list that would cause us to ask the
list first?

Lars: Not really. Typically the way this goes is we google them. Do they
actually publish specifications, is this just a technical marketing thing or is
it an actual SDO with something we'd consider a spec we could reference?
Whether the request is sane is another piece of information that goes into the
decision. If they don't look like a real proper SDO and the request doesn't
really make sense, that's two strikes.

Orie: For our side then, we're just basically vetting the entity and approving
them without objection. It seems like we can just keep doing that until we want
to do something else.

Murray: There is this intended component from the people who sent this up that
they want to have a stopgap opportunity to create a liaison or something else.
Once we approve them, we're not going to hear about them anymore. Of course,
they left us no criteria about what the definition for a bona fide SDO is. We
just have the current context and what we've approved in the past. We have used
this to pick off someone who claims SDO status that's just a guy with a website.

Orie: Is it really true that we never hear about them at all, or do we hear
about them on the list relative to what new registrations they want?

Murray: By we I mean the IESG is never presented with the question to create a
liaison with them. They can register stuff all they want.

Orie: And we'd still become aware if there was evidence there was a problem,
right?

Murray: If you happen to be watching the media types list, yes. The IESG is not
going to be told about anything once this gets approved.

Orie: Understood.

Liz: So for this one, I don't think anyone was actually objecting to processing
this media request and adding this organization to the standards tree, so we'll
go ahead and send that official note to IANA.

6.3 [IANA #1353885] Acceptance of media type registration from standards
organization Trust Over IP Foundation Technology Stack Working Group -2 (TSWG)
(IANA)

Liz: Has anyone had a chance to look at this one?

Murray: I did not see this one prior to the call so I don't have an opinion yet.

Lars: I looked at this and I've come across this foundation before. I have some
mild question marks. Specifically, I tried to read the request they're making
and I can't figure out what this is. The words don't make any sense to me. I
don't know if it's because I'm not in the space. Can someone review this?

Orie: I'm familiar with this. I hadn't seen this specific request prior to the
meeting so I'd want to review it, but I have a lot of background on what I
think this is.

Liz: So do we want to hold this one until the next telechat and give folks more
time to review?

Roman: I think that's a safe thing to do.

Liz: Great, so we will leave this right here and you'll have two more weeks to
look it over.

6.4 [IANA #1287238] Designated experts for RFC 9487 (Export of Segment Routing
over IPv6 Information in IP Flow Information Export (IPFIX)) (Rob Wilton)

Liz: Rob has identified two individuals and a list as experts for this
registry. Is there any objection to approving them?

Francesca: Why is this a list and not individuals?

Rob: This list has the experts for the other IPFIX registries, so I'm doing
what's been done before.

Francesca: It feels a little strange that we're putting a list where we might
not know the individuals or the individuals on it might change.

Lars: Can we name the experts without the list?

Rob: Then this one would be the odd one out for the IPFIX registries; the
others are all listed the same way. In general I think pushing this stuff onto
a list from individuals is a good idea.

Amanda: This is a private list, so it consists only of the IE doctors. They
were all designated by the IESG. I don't recall why we're not listing them
individually here, but we can certainly change that.

Francesca: That would be fine by me, so I can see the names. I don't have
anything against approving them as experts, it's just strange to approve a list.

Lars: For the other ones, I'd list them by name as well. They can use the list
to discuss amongst themselves, that's fine, but the experts should be actually
named in what the IESG manages.

Amanda: Okay, we'll update that.

Liz: Okay, so it sounds like there's no actual objection, we just want to list
out these individuals.

Rob: Will Amanda also take an action to change the other IPFIX ones?

Amanda: Yes, we can do that.

Rob: Okay, as long as they're consistent I'm fine.

Liz: I think we have what we need.

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

Liz: Two reminders from me. First, if you haven't yet filled in the Doodle for
retreat dates, please do so. Second, the final BOF approval deadline is
tomorrow and we'll be discussing the BOF final approvals next week during the
informal telechat time slot, so we'll definitely have an informal next week.

Andrew: The discussion on the document we had today, I've also put that on the
agenda for next week. Do you think it's better I push that to the next
informal, or will we have the time next week?

Liz: It's up to you, I don't know how much more discussion time the BOFs need
or if that will go quickly. But the week after next will be the agenda conflict
resolution, so we probably will not have extra discussion time then.

Andrew: I think I'm going to leave it scheduled for next week then.

Warren: No objection from me. I've had a lot of long discussions with the DNSOP
chairs and the DELEG proponents and I think things are looking good for them
for a WG-forming BOF in the ops area to work on the deleg proposal. If anyone
would like to chat to me about that, please do reach out to me.