Narrative Minutes interim-2025-iesg-21: Thu 14:00
narrative-minutes-interim-2025-iesg-21-202510231400-01

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2025-10-23 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Morgan Condie, Secretariat

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Mike Bishop (Akamai) / Web and Internet Transport Area
Matthew Bocci (Nokia) / IAB Liaison
Mohamed Boucadair (Orange) / Operations and Management Area
Morgan Condie (AMS) / IETF Secretariat
Deb Cooley (Independent) / Security Area
Roman Danyliw (CERT/SEI) / IETF Chair, General Area
Gorry Fairhurst (Univ. of Aberdeen) / Web and Internet Transport Area
Liz Flynn (AMS) / IETF Secretariat
Jim Guichard (Futurewei Technologies) / Routing Area
Mahesh Jethanandani (Arrcus) / Operations and Management Area
Erik Kline (Aalyria Technologies) / Internet Area
Jean Mahoney (AMS) / RFC Editor Liaison
Cindy Morgan (AMS) / IETF Secretariat
Andy Newton (ICANN) / Applications and Real-Time Area
Tommy Pauly (Apple) / IAB Chair
Sabrina Tanamal (ICANN) / IANA Liaison
Gunter Van de Velde (Nokia) / Routing Area
Éric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Orie Steele (mesur.io) / Applications and Real-Time Area
Ketan Talaulikar (Cisco) / Routing Area

GUEST
---------------------------------
Eliot Lear / Independent Submissions Editor (ISE)

OBSERVERS
---------------------------------
Donald Eastlake
Sandy Ginoza
Karen O'Donoghue
Nicola Rustignoli
Greg Wood

1.2 Bash the agenda

Roman: I just wanted to do a quick agenda bash, there is an executive session
at the end, just as a reminder, and then we have our Independent Submissions
Editor here, Eliot. I was going to move him in before we even start documents
but after the action items to talk about an upcoming conflict review. Are there
other bashes? Okay, not hearing any, let's get started.

1.3 Approval of the minutes of past telechats

Liz: Does anyone have an objection to the approval of the minutes from the
October 09 telechat? I’m hearing no objection, so those are approved. Does
anyone have an objection to the approval of the narrative minutes from the
October 09 telechat? I’m hearing no objection, so those are approved as well.

1.4 List of remaining action items from last telechat

OUTSTANDING TASKS

         Last updated: October 9, 2025

    * DESIGNATED EXPERTS NEEDED

      o Paul Wouters to find designated experts for RFC 9770 (Notification
        of Revoked Access Tokens in the Authentication and Authorization
        for Constrained Environments (ACE) Framework) [IANA #1421561].

Paul: In Progress.

    * OPEN ACTION ITEMS

      o Roman Danyliw to take a look at Datatracker documentation of
        document states and update as needed.

Roman: Is in progress. As discussed late last week, I wanted to make sure there
was nothing contradictory and I’m still doing that review.

      o Mahesh Jethanandani and Ketan Talaulikar to work with Dhruv Dhody
        and Suresh Krishnan to look into potential retreat locations in
        Asia.

Liz: I know this is on the list to discuss at the joint session at the meeting.
Anything we need to know about it before then.

Mahesh: No, let’s just discuss it then.

      o Roman Danyliw and Mahesh Jethanandani to draft update to "Guidance
        on Area Director Sponsoring of Documents" statement.

Roman: In Progress.

      o Roman Danyliw to check with the Trust about whether the IESG
        Statement on Copyright is overtaken by RFC8721 Section 4.3.

Roman: Talked with the trust and the guidance still applies and we need the
statement. The action is no action and leave as is. We can mark as done.

      o Med Boucadair and Mahesh Jethanandani to review "IESG Statement on
        Proposed Status for IETF Documents Reserving Resources for Example
        Purposes" and propose what needs to be updated.

Med: There was only one minor edit and sent to the secretariat for approval.
Otherwise, I think it’s good to go. Liz, Cindy, you should have a pointer to
that statement.

Cindy: We can get that posted today.

      o Andy Newton and Roman Danyliw to work on re-chartering dispatch to
        cover multiple areas.

Andy: In Progress.

      o Ketan Talaulikar, Mahesh Jethanandani, and Roman Danyliw to work on
        an announcement regarding Datatracker state change for WG adoption.

Roman: Tightly linked to the first action, announcement is pending that purview.

Éric: Sounds like the WG lunch wants to talk about this topic as well.

Med: I confirmed they received an invitation from Robert but I won’t be
available to attend. I forward the invitation to Éric and he seems available. I
think that the presentation of the discussion will be just commenting that we
will make an announcement.

Deb: Are there two separate things? That’s a tool change, right? Robert’s
talking about a tool change.

Med: They’re actually linked but two actions. This one is about communication
about that change.

Éric: People want to talk about it is my understanding, they were not too happy.

Deb: Because it wasn’t announced.

Éric: Correct, and this announcement is basically announced afterward. If I
understand the complete context.

      o Deb Cooley to work with Greg Wood on guidance for WG Chairs about
        how to use the Note Well.

Deb: We finished this. If you want me to tell you where we landed, basically
Jay said the IESG approved it. I don’t think it’s controversial and happy to
add to the agenda if needed.

Roman: We did look at it and approved it based on your recommendations.

Cindy: I believe this was all closed at the end of the informal last week. Your
action with Greg was a little outside of that.

Deb: I’m happy to call it done and drop a link in the chat. Basically the do’s
and don’t’s are the same and there is now text for what the working group chair
might say during the meeting. I would close the action.

6.8 ISE discussion of SCION
Eliot:

Slide 1: ISE/SCION

Eliot: This seems like a great time to talk about ISE procedures since I’m
about to drop three large documents on you probably in the next few weeks. This
is about SCION which is an alternative IP and control plane system that folks
at ETH Zurich developed and it’s actually used in the Swiss banking system.
Here we have something that is running code, that is a path based network
approach, where the source picks the path. It’s a little different from an
independent submission in that we normally see that it's very big. Most of the
time I reject things that are very big, but this is interesting for a number of
reasons.

Slide 2: We Are Here - Independent - RPC - RFCs

Eliot: We are here in the dependent stream, that's one of the alternative ways
to get an RFC. It’s subject to a RFC 4846 and therefore you guys get 5742 as
part of that to review. I want to take a moment to thank those that have been
doing those 5742 reviews, Jim I remember and Gorry as well.

Slide 3: Three drafts

Draft-ietf-dekater-scion-dataplane : Date plane comms (It’s not v4 or v6)
Draft-dekater-scion-controlplace : Control Plane (how to learn of what paths
are available) Uses an additional level of hierarchy over BGP system
Draft-dekater-scion-pki : Securing of the control plane

Eliot: These documents interact with each other and are somewhat involved
reading because obviously the data plane needs the and the control plane in
order to know where to send the packet. The data plane draft is implemented on
top of a VPN or something like that and underneath you will find IP hiding
somewhere but this is the mechanism that they have deployed. Why would the
independent submissions that are considered these 3 drafts you might ask?

Slide 4: Where does SCION fit within RFC 4846

Informational discussions of technologies, options, or experience with protocols
April 1st RFCs and other humor
Informational publication of vendor-specific protocols
Discussion of Internet-related technologies that are not part of the IETF agenda
Introduction of important new ideas as a bridge publication venue between
academia and IETF engineering Critiques and discussions of alternatives to IETF
Standards-Track protocols and processes Documents considered by IETF Working
Groups but not standardized Meeting notes and reports Tributes

Eliot: Reasons we have to publish anything, this one hits about 3 of the
different areas. First is Informational publication of vendor-specific
protocols. There is a company that is pushing this now that spun off of ETH
Zurich. The second is Discussion of Internet-related technologies that are not
part of the IETF agenda. These aren’t but could in the future be. Brian
Trammell and I have been collaborating and Éric has been part of the
conversation at different times in that we are hoping that the SCION work will
be an input into PANRG and actually some of the SCION authors. They don’t want
the independent submission to be the end of the story. They would like it to be
the beginning of consideration for a path-aware networking that the IETF could
actually take up. Does that mean that the IETF has to? Of course not. Does it
mean the IETF would take their stuff up untouched? Of course not. This is just
an input into IRTF work which is then an input into IETF work. Then
introduction of important new ideas as a bridge publication venue between
academia and IETF engineering. This is the first really good example in a while
that is pathware networking. There have been other technologies from long long
ago that did source based routing from end to end. This is a new model. It
provides a complete security model or mostly complete security model.  Does
that mean that it’s perfect? Absolutely not. I’m sure people will find flaws
but I think this is a really good discussion input which is why I think we are
going to see documents come out. Now as a reminder, 4846 says that I should
take not only IESG’s input but also input from competent reviewers and I base
my decision on the preponderance based on those reviews.

Slide 5: The IESG’s Formal Role: RFC 5742 Reviews: Advise the ISE
Common Choices -
No conflict between this document and IETF work; or
Work is related to IETF work done in WG <X>, but this relationship does not
prevent publishing; or Publication could potentially disrupt the IETF work done
in WG <X> and recommends not publishing the document at this time; or Document
violates IETF procedures for <Y> and should therefore not be published without
IETF review and IESG approval; or Document extends an IETF protocol in a way
that requires IETF review and should therefore not be published without IETF
review and IESG approval.

Eliot: I believe in an iterative process, and this has happened before with the
IESG where there was a document that involved a new name service and Warren and
I worked really well together to iterate through that process to figure out the
best way forward to produce that draft.

Slide 6: How the ISE processes results of a RFC 5742 review
If there is a conflict there are 5 choices for ISE:
1. Consider advice and publish
2. Consider advice and ask authors to make some changes
3. Negotiate an IESG note
4. Delay publication for a time
5. Consider advice and decide not to publish, I wouldn’t ever expect to get to
this point. I really work hard to avoid this.

Eliot: With SCION there are big differences between it and other versions like
new IP. The biggest difference is A. There is a full specification, B. There is
deployment and C. Maybe there is something we can learn from the deployment
experience. It’s not meant to be standardized in the IETF, it’s meant as more
input into PANRG. These documents will probably be coming through in the next
few weeks. I’ll probably wait until after the IETF since Brian Trammell is
going to do another round of reviews for the authors and we will get you
something that is as close to review ready as possible. Questions?

Gorry: The obvious place where this overlaps with PANRG, is it correct that
it’s not our job to figure out this overlap it is yours?

Eliot: Correct. In fact, Brian is a co-chair of PANRG.

Eliot: I usually ask that review try to be complete in about 30 days after
submission but obviously with these wildly large documents, that’s going to
need to be a little longer and that’s going to be somewhere around the
beginning of next year assuming that they get to you in a reasonable period of
time. Maybe even a little later would be okay.

Roman: Hopefully this was helpful for the conflict review we will be doing. The
first thing we will need to do is assign an AD but let’s worry about that when
the documents come in.

Erik: Will we assign 1 AD or 3 AD’s?

Roman: That’s a great question. Do you feel like we need to decide that now?

Erik: I guess we can decide that when the documents get to us. Will we assign a
page count to that?

Roman: We can actually do that too. I don’t know the size of these documents
but yes, it would make sense if they are as large as they say they are.

Deb: I looked them up and they are about 65-75 pages each. I can see splitting
it. I could see PKI going one way and path routing and data plane/control plane
stuff going another way.

Roman: Step 1 is assigning an AD, once we see the size and shape we talk
through how we want to stage their processing? Objections? Okay, let’s do it.

Eliot: There will be other series like this, CNSA will be coming along next
year so you should expect a group of documents at some point in February.

Deb: Are you going to put them all through together?

Eliot: I wouldn’t have to but they are all being processed together by the
authors so I’m not going to hold them for any particular reason.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

  o draft-ietf-suit-report-16  - IETF stream
    Secure Reporting of SUIT Update Status (Proposed Standard)
    Token: Deb Cooley

Liz: We have a couple of discusses. Do we want to discuss this now?

Deb: I don’t, I think the discusses are pretty clear and I don’t believe the
authors are on the call.

Jim: And Ketan is not here either Deb.

Deb: It will be fine, they will noodle this through.

Liz: This will stay in IESG Evaluation would you like in AD Followup or Revised
I-D?

Deb: Revised I-D Needed.

Liz: This is IESG Evaluation::Revised I-D Needed. There are two downrefs in
this document, 9019 and 9334.

Deb: I’m not saying yes, but thank you for the notice.

  o draft-ietf-core-oscore-groupcomm-27  - IETF stream
    Group Object Security for Constrained RESTful Environments (Group
    OSCORE) (Proposed Standard)
    Token: Mike Bishop

Liz: There are no Discusses, so unless there is an objection now, this is
approved. I'm hearing no objections, so this is approved.

Mike: Thank you! Please put in Revised I-D needed since it has a companion doc
that has a few discusses.

Liz: Approved - announcement to be sent::Revised I-D Needed.

  o draft-ietf-bess-mvpn-evpn-sr-p2mp-15  - IETF stream
    Multicast and Ethernet VPN with Segment Routing P2MP and Ingress
    Replication (Proposed Standard)
    Token: Gunter Van de Velde

Liz: We have a few discusses. Do we want to discuss this now?

Gunter: There is a new version ready but waiting to get uploaded. I believe the
discusses are pretty clear and will be addressed in the next few days.

Éric: About the field in my discuss, there is a field called MPLS label which
does not contain any MPLS label but contains an SRv6 and I was suggesting
updating the previous RFC to change the field name. Basically the authors said
no, which is okay, but I think a field called MPLS label doesn’t contain MPLS
label, which is quite misleading for the future generation. Asking for your
point of view.

Gunter: Honestly, I haven’t looked into it yet. I need to further look into it
before giving an answer.

Erik: I have a discussion going back and forth on the mailing list about what
kind of prefix to use for non routable stuff. I believe there were some
responses.

Gunter: I realize this draft is complex. Thank you for digging through it.

Liz: This is staying in IESG Evaluation, would you like it AD Followup or
Revised ID needed?

Gunter: Revised ID Needed. They already have a new version ready and are
waiting for it to be submitted and pick up the remaining comment from Éric.

Liz: This is IESG Evaluation::Revised I-D Needed.

  o draft-ietf-idr-link-bandwidth-19  - IETF stream
    BGP Link Bandwidth Extended Community (Proposed Standard)
    Token: Ketan Talaulikar

Liz: We have a few discusses. Do we want to discuss this now even though Ketan
isn’t on the call today? Okay, I guess not, will leave in IESG Evaluation::AD
Followup so Ketan can do what he likes with it when back.

  o draft-ietf-ntp-over-ptp-06  - IETF stream
    NTP Over PTP (Proposed Standard)
    Token: Erik Kline

Liz: We have a discuss. Do we want to discuss?

Erik: Thank you for the reviews. There is a thread about what to say for DEs.
Not too hard to write some text.

Roman: I don’t have an opinion on what it should be, but that something should
be something.

Erik: It’s a little interesting how the IEEE OUI based registry works, it’s a
whole new registry just to show this is an NTP message. I can’t imagine anyone
will ever extend it, but yes, we should say something. We will get some amended
text in there.

Roman: Karen, I saw you joined, do you have commentary?

Karen: I agree with what Erik is saying, I think we need to finesse the text a
little bit. It is an odd relationship.

Liz: This one is staying in IESG Evaluation. Would you like in Revised I-D
needed or AD Followup?

Erik: Revised ID Needed.

Liz: This is IESG Evaluation::Revised I-D Needed.

  o draft-ietf-cose-hash-envelope-09  - IETF stream
    COSE Hash Envelope (Proposed Standard)
    Token: Paul Wouters

Liz: There are no Discusses, so unless there is an objection now, this is
approved.

Paul: Please put in AD Followup.

Liz: Approved - announcement to be sent::AD Followup. Just let us know when
this is ready Paul.

  o draft-ietf-tls-tls13-pkcs1-06  - IETF stream
    Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 (Proposed Standard)
    Token: Paul Wouters

Liz: We have a discuss. Do we want to discuss this now?

Paul: Honestly, I don’t know why this discuss is still on the document. The
entire introduction explains why there are operational considerations that
require this document to reintroduce something that the working group hoped to
have killed off in the past. I think it’s very obvious and I don’t understand
why Med is holding this discuss. At least the TLS chair is pretty unhappy and
the authors of this document are really new to the IETF so they suggested maybe
agreeing with the change for recommended deprecated which I think is definitely
the wrong step, so told them not to make that change. Med, what can we do to
resolve this?

Med: I spent some time going through this document and I would say this
specification actually does not mean deprecated, it means discouraged. The
major one is updating the base TLS specification. There are various excerpts in
RFC 8446, for example if you go to page 39, page 40 or page 66 it’s my
interpretation that it’s affirmative that this cannot be used for the TLS
handshakes. With this specification we are relaxing this constraint which is
clearly updating that specification for me. I would also say the clarification
between the not recommended and discouraged clarification.

Paul: Too many issues at once for me. Changing or allowing a new algorithm
isn’t changing the core specifications. I don’t think that’s an update. It’s
really an extension. You’re adding another algorithm that’s allowed. I don't
think that's an update to the core TLS1.3 specification. I disagree with your
evaluation that this should be an update on the TLS1.3 RFC.

Med: If you see the part introducing the algorithms, for example this value is
referred to the signature and is not defined for use in handshake messages. You
can find the same statement also under the legacy algorithms in which the same
are not defined in science handshake messages and so on. If you tell me that’s
my interpretation and it’s not correct, that’s fine. The purpose is just to
make sure that we are not breaking something that is already there in the
specification. Also under the legacy algorithm, it indicated algorithms which
are being deprecated. So if we say this isn’t recommended, I had a concern with
that one in RFC 8446 and also bis, that algorithm was evaluated and the text is
clear that this is something which is deprecated and is not encouraged. So for
example if we put in the registry, this is not recommended and people just say
that yeah this is not something because there is no evaluation from the IETF
that is a little contradicting with what is recommended or at least recorded in
the base TLS specification itself. If they can crosscheck, I just want to make
sure we have the same understanding of the text. If you check it and you think
it’s right, I can remove my discuss.

Mike: I addressed both of these in my ballot comments. Med, the definition for
N has 3 possible reasons for using it. One of them is that it hasn’t been
through a consensus process, the other two apply to this document. I think N is
probably the right choice here. I believe you are right that it does modify
8446. Paul, normally I would agree with you that this would be just an
extension using a regular extension point. But 8446 says that you’re allowed to
list things with this algorithm for backward compatibility, but they must not
be used if you’re in TLS 1.3. This is changing that restriction from must not
be used to you can use them in this particular situation.

Paul: Is the text still in the bis document?

Mike: I believe it is. If the solution is to ask the RFC editor to take it out
before they publish it, that’s fine too.

Deb: Is it specifically for certificate signature, not regular signature right?

Mike: That I would have to confirm.

Deb: So this is only the certificate signature extension?

Mike: Right. Currently it says that in processing the certificate verify
message, you must not consider these algorithms, even if they’re present. This
document says that the server can process them but the client can’t.

Deb: My only point was to say that this is specifically for client
verifications for certificate signature only, not for regular certificate
algorithm extensions, not for server certificate extensions, not any of that.
There’s not even one for servers, but just for the client certificate. I will
go so far as to say that I expected this requirement originally in 8446 was
ignored routinely because you can’t get certificates without it.

Mike: How do we move forward from here? Do we want to take a look at what 8446
says and then decide if it’s an update?

Paul: Yes, I’ll look at that.

Mike:  Med are you satisfied or willing to be overruled?

Med: I don’t remember if in the registry we have some kind of notes where we
can point specifically to the applicable application scope, is that something
we have currently in the registry or the notes column. The other point is that
we are losing the encouragement to transition to the new ones. That’s actually
why I had that I would say balance between N and discouraged. We are providing
this because we have a trade off and we know we want you to use TLS 1.3, we
know that there are downsides of it but we also like to convey that you have
something more robust which is currently in the base itself. So if we have a
comment of a specific column in that review which we can specifically include
some kind of these comments, I would be okay.

Deb: There is a very natural cut off for this, and that’s the advent of the
quantum based computer. Once the quantum based computer is around, this
algorithm will be deprecated along with the rest of RSA and the elliptic curve
algorithm. This will go away by itself by the natural course of events.

Paul: I can see about adding a note. I’ll double check to see what the history
has been for using the note column in that registry.

Liz: This is staying in IESG Evaluation, would you like me to put to Revised
I-D Needed?

Paul: Yes, you can put to Revised I-D needed.

Liz: This is IESG Evaluation::Revised I-D Needed.
2.1.2 Returning items

  o draft-ietf-asap-sip-auto-peer-35  - IETF stream
    Automatic Peering for SIP Trunks (Proposed Standard)
    Token: Andy Newton

Liz: We have a few discusses. Do we want to discuss this now?

Andy: I believe that Mike’s comments can all be addressed. Med, I believe the
authors have attempted to address your concerns.

Med: I think they are making excellent progress. There’s only one pending
comment about avoiding creating a new source of information for the SIP option
tags. I provided them with an example of how to solve that and waited for them
to see if they could do that. If they implement it, I think that we are done
with my discuss.

Andy: I don’t quite understand the read-only.

Mahesh: It’s the fact that the entire model is read-only, which means that all
those parameters they described in the YANG module have to be populated by the
system itself, system being in this case SIP device. I was trying to understand
how this gets populated. Meaning if you don’t allow anything to be written and
an instance created, how does the model get populated?

Andy: Okay, so it’s not that the data model can not be read-only, it’s just
that we need to understand how that information gets there. Correct?

Mahesh: Correct. What I understand is that the enterprise reached out to the
service provider to build the config, but then how does the enterprise then
populate it on the SIP devices?

Andy: I don’t have an answer for that. What I do believe is that this got
changed to read-only after the last IESG evaluation on this document. We need
to figure out the answer to your question which is basically how that data gets
there if it’s read only.

Med: One more comment, I think for the interface between the network and the
service provider having it as read-only is the right choice because you are
just exposing the capabilities and you are not giving the right to the other to
modify the capabilities. From that standpoint, I think they are right in the
way they are designed but the way this will be managed is something which can
be internal , but they don’t have that experience document and I think that
this can be straightforward in the explanation. For the interface itself, they
are having it right at least from my point of view.

Mahesh: Thank you for that explanation. That explains if this is a model that
is meant for the service provider to have the instance data. They just need to
make it clear, is this for a device? Is this for the enterprise or is this for
the service provider? Who is the model for? And it’s for the service provider,
it’s read only. I’ll clear my discuss.

Andy: I think that would be good for them to clarify. You said you’re holding
this for an IANA issue? Which one is that the downref?

Mahesh: IANA has put a hold on it. I’ll check if that is still the case.

Med: I think that they have cleared it, but please check on your side as well
Mahesh.

Mahesh: I think there was a point in the document that they didn’t have any
consideration for the module.

Andy: I believe they addressed that when Med pointed it out. The downref to the
IANA crypt-yang model, I think we are going to need some guidance on whether we
should be doing that or not. I can’t see any implementations of this, so if we
need to point them to something that is better, I think we can do that. I just
don’t have enough context and don’t know whether that downref is appropriate or
not. I think we can put to Revised I-D needed.

Liz: This is staying in IESG Evaluation::Revised I-D Needed.

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-opsawg-pcaplinktype-13  - IETF stream
    Link-Layer Types for PCAP-related Capture File Formats
    (Informational)
    Token: Mahesh Jethanandani

Liz: We have a few discusses. Do we want to discuss this now?

Mahesh: Ketan is not here and I know most of the discusses are around the
registry information. The authors have updated the registry information to now
make it first come first served without expert review, which I think was one of
the points of contention. I don’t know if that is the only thing holding this
up at this point. Roman, I don't know if you got a chance to see the responses
from the authors on your point.

Roman: I have not had a chance to look, but I’m checking in real time.

Maheash: I believe this one should stay in IESG Evaluation, Revised ID Needed.

Roman: Before we go, I observe that we’re now in a first-come first-served
situation, yet we still have a bunch of guidance for registration. What is in a
first-come first-served situation? I thought it was literally first-come
first-served, but there’s all sorts of text now that looks like that takes some
kind of judgment about whether to accept things. Is that usual?

Mahesh: No, you’re right. If I read 8126, I think it’s pretty much the source
information on what is the reference and pretty much accepted. No, generally
you don’t have too much guidance in that case.

Roman: IANA can you jump in in real time here on this text?

Sabrina: I think I’d have to agree with that as well. Outside of checking that
it’s a valid request and making sure that they provided all the information for
the required fields, that’s pretty much the extent of what we would check. Also
something we're trying to include in the registry is also a change controller
field for all first-come first-served and expert review registries. This is
just to make it more clear in terms of who is authorized to make changes in the
future.

Roman: So we probably need another column then for change control?

Sabrina: If it’s not included in the document, we would do it. If it’s not
something included in the document, it’s something that we’re doing across all
registries, all first come first serve and expert review.

Roman: The judgment piece that worries me is the test says when the content of
a link type can contain a v4v6 header, then the context because the beginning
of the link type and the need to clearly specified, that seems like a judgement
call that someone has to go find the specification and make an assessment of
whether that’s clear of not. That seems well beyond what first come first serve
would be.

Sabrina: Yes, we won’t be able to do that.

Mahesh: One clarification question for myself is the change controller, is that
for each entry in the registry?

Sabrina: Yes

Mahesh: Does each of those entries have to have a change controller?

Sabriana: Yes, and if it’s an IETF document, then we would just list it as
IETF. We would like to have an entry for each of them.

Mahesh: The reason I ask is because this document has had a lot of history on
it. It has made a very last minute attempt to try to document what has been in
existence, I don’t know for years. There would be a bit of a struggle to try to
identify all the sources of why some of those reservations were made. I think I
have the answers to my questions.

Liz: This is IESG Evaluation::Revised I-D Needed.

  o draft-ietf-bier-oam-requirements-19  - IETF stream
    Operations, Administration and Maintenance (OAM) Requirements for
    Bit Index Explicit Replication (BIER) Layer (Informational)
    Token: Gunter Van de Velde

Liz: We have a few discusses. Do we want to discuss this now?

Gunter: I think the discusses are quite clear, some of them relate to the BCP
14 language. Then there is also a comment about normative language and Med had
a whole bunch of comments on some of the more state of the art announcement.
Greg tends to be quite responsive in this area and usually quick to respond.
Revised ID Needed for sure.

Liz: This is IESG Evaluation::Revised I-D Needed.

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

  NONE

3.4.2 Returning items

  NONE

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

  NONE

4.1.2 Proposed for approval

  o Web Bot Auth (webbotauth)

Liz: I see no blocking comments so if there are no objections now, this is
approved.

Mike: There was one comment Paul had made and Mahesh seconded about the charter
specifying the directionality of fetching additional information and what we
had done and discussed offline is making a one word change allowing the working
group to decide which way that goes instead of requiring the deliverable. After
I make that one word change, then I think we’re good to go.

Liz: This charter is approved and we will wait for Mike to tell us it's ready
to be announced.

  o Open Cloud Mesh (ocm)

Liz: I see no blocking comments so if there are no objections now, this is
approved.

Andy: I do need to modify this based on the nit Erik Kline made. Éric Vynke
made a comment about the milestone. I thought we had discussed at the last
telechat but maybe it wasn't clear. Your objection is we only have one
milestone in there?

Éric: Basically the vagueness of one familiar specification which is not clear.
It’s not about this milestone at all.

Andy: The intent is, if they get into the input there’s an input document,
right? Here’s what people are currently doing but the IETF needs to look at
that and it’s not going to rubber stamp it right? The IETF could change it
completely. This is language to say, if they get into it and they need to
create more than one doc, that’s what’s going to happen but it’s all one
deliverable.

Éric: Seems vague to me but that’s all.

Andy: I believe it’s purposefully a little vague. Please hold until I make one
change.

Liz: This is approved and we will wait for Andy to let us know it’s ready to go
to send the announcement.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

  NONE

4.2.2 Proposed for approval

  o IPv6 Operations (v6ops)

Liz: I see no blocking comments so if there are no objections now, this is
approved.

Med: I’ve implemented the nits from Erik Kline, Éric Vynke, and Gunter. From
Mike, I would say the introduction centers it because for me, unless you have a
specific modification that you want to see, I just prefer to keep the current
wording.

Mike: I’m thinking of it more as a long term direction than a "go fix your
text," and it might even belong in a different working group.

Liz: This is approved, Med is this ready to be announced?

Med: It’s ready to go.

Liz: This one is approved and ready to announce. We will get those
announcements sent out today.

5. IAB news we can use

Deb: A few great discussions on Open Fiber Data Standard by Stephen Song
(ISOC). There’s discussion about where this lands from a standards point of
view and it’s somewhere between IETF, Open GIS, and ITU-T. The other one was
about Human Rights in Standards by Simone Onofri. He’s talking about what the
W3C is doing. There was discussion on the IAB Open meeting. Dirk mentioned that
SPACERG is having their first meeting this go around and some other interesting
side meetings, ARMOR and PAIN. They are both research group related.

Tommy: IP Geolocation workshop coming up in December. We received a good amount
of contributions to that. We’ll be letting people know soon and the official
list of papers and invitees.

Matthew: The age verification workshop jointly with W3C and had a pretty good
turnout.

Deb: It sounds like they plan to have a summary of that at the IAB Open.

Tommy: There’ll be a presentation of that and I think the official workshop
report draft should be by the end of the calendar year.

6. Management issues

6.1 [IANA #1433997] renewing early allocation for draft-ietf-pce-sr-bidir-path

Liz: Any objections for approving this early allocation approval?

Liz: I’m hearing no objection, so this is approved and we will send the
official approval to IANA.

6.2 Note Well

Liz: This is to formally minute the decision that the IESG approved the new
Note Well text.

6.3 DCONN session request (Orie/Liz)

Liz: We do have an open slot, but Orie has an AD conflict. Orie wants consensus
that this is okay and not precedent setting and if someone can cover it for him?

Gunter: I saw the LSVR session was cancelled so maybe that slot could work?

Roman: I have no objections to adding to the agenda.

Andy: I thought Orie said this was a miscommunication and that DCONN didn’t
want to meet.

Éric: It was a reply to my message asking if they were planning to meet.

Liz: The message I got was that they weren’t going to meet so we didn’t save a
space for them.

Mike: We should accommodate just like any other late request. If we have space,
great, and if not.

Liz: We'll look at the new LSVR open slot and the Friday slot. If Orie needs AD
coverage you may be hearing from one of us.

6.4 [IANA #1433996] renewing early allocations for
draft-ietf-ippm-ioam-data-integrity - (Mohamed Boucadair)

Med: It makes sense to extend.

Liz: Any objections to approving?

Liz: This is approved and we will get the official note sent to IANA.

6.5 DRIP Videos (Éric Vyncke)

Éric: I’m hoping to have the last 15 minutes from the video/transcript of the
DRIP interim meeting on October 15th after the top of the hour was removed.
This is where I’m talking in french with the WG chairs for 15mins about random
topics after the meeting ends.

Roman: I have no issue with this since the meeting had ended. Any objections?

Éric: Meetecho wanted IESG approval. I will follow up with them.

6.6 YANG versioning and Semver, and its possible impact (Mahesh Jethanandani)

Mahesh: This is meant to be more of a heads up, since there are trial documents
making their way through pretty soon. One of them is in the working group's
last call, the others will be there soon.

Slide 1: YANG Versioning and Semver - How these changes impact the folks in the
IETF

Slide 2: Trio of documents
draft-ietf-netmod-yang-module-versioning
draft-ietf-netmod-yang-module-semver
Draft-ietf-netmod-yang-module-filename

Mahesh: All three of these documents in some form are affecting the way the
YANG modules are going to be versioned going forward.

Slide 3: Current versioning scheme
Strictly Backwards Compatible (BC)
Follows a YYYY-MM-DD format
E.g., ietf-blah@2018-10-12.yang

Slide 4: draft-ietf-netmod-yang-module-versioning

revision 2020-08-09 {
  rev:non-backwards-compatible;
}

revision 2020-06-07 {
}

revision 2020-02-10 {
  rev:non-backwards-compatible;
}

Slide 5: draft-ietf-netmod-yang-module-semver
revision 2017-08-30 {
      description "Backport 'wibble' leaf";
      ysv:version 1.2.2_non_compatible;
    }

    revision 2017-07-30 {
      description "Rename 'baz' to 'bar'";
      ysv:version 1.2.1_non_compatible;
      rev:non-backwards-compatible;
    }

Slide 6: draft-ietf-netmod-yang-module-filename
acme-router-module@2024-05-15.yang

OR

 acme‑router‑module#2.0.3.yang.

Slide 7: Impact on current process
Toolset needs to be updated
Datatracker will check for these new versioning statements
pyang
Yanglint
IANA
IANA modules
IETF modules

Slide 8: Community education
Working with Greg Wood
WG Chairs Lunch
Blog post
SYN-ACK newsletter
Others??

Mahesh: Any questions?

Andy: How does Errata deal with this? Does it change the patch number? There
are major, minor, and patch. The last number digit is patch. If someone files
an Errata, does that mean that the YANG model has to be updated with a patch
number?

Mahesh: If its editorial it would be a patch and it would be marked as
backwards compatible, especially if editorial. If it’s technical and it’s
changing the model, then I have to ask the authors to give us an example of
what it would do.

Andy: Can they register a YANG model prior to an RFC? Anything with a major of
0 won’t be allowed then?

Mahesh: Correct. 1.0.0 is the minimum version.

Andy: In the REGEX working group there is some work about semantic versioning
which isn’t nearly as clear as what you’re describing. I appreciate YANG taking
on the challenge.

6.7 Executive Session: Appeals

The topic was discussed in an executive session with IESG,
IAB Chair, and Secretariat present. Paul Wouters recused himself from
the discussion and left the call.

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

Gunter: Would like to combine lunch for RTGDIR and OPSDIR since they are both
on November 4th and there is a lot of overlap.

Jim: I’m okay with combining.

Mahesh: Let’s just be creative with the agenda.

Liz: How many people?

Gunter: 41 people. I can send an email to Paige.

Liz: I can update her as well.