Narrative Minutes interim-2024-iesg-05: Thu 15:00
narrative-minutes-interim-2024-iesg-05-202402291500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2024-02-29 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
Deb Cooley / Incoming Security Area
Roman Danyliw (CERT/SEI) / Security Area
Dhruv Dhody (Huawei) / IAB Liaison
Martin Duke (Google) / Transport Area
Lars Eggert (Mozilla) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat
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
Sabrina Tanamal (ICANN) / IANA Liaison
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

OBSERVERS
---------------------------------
Greg Wood

1.2 Bash the agenda

Liz: Does anyone have anything to add to today's agenda? Any other changes?
We'll take Andrew's documents first.

1.3 Approval of the minutes of past telechats

Liz: Does anyone have an objection to the minutes of the February 15, 2024
teleconference being approved? I'm hearing no objection, so those are approved
and we will place the minutes in the public archives.

Does anyone have an objection to the narrative minutes of the February 15, 2024
teleconference being approved? I'm hearing no objection, so those are approved
and we will place the minutes in the public archives.

Does anyone have an objection to the minutes of the IETF 119 BOF Coordination
Call being approved? I'm hearing no objection, so those are approved and we
will place the minutes in the public archives.

1.4 List of remaining action items from last telechat

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

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

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

  o Paul Wouters to find designated experts for for draft-ietf-emu-
rfc7170bis (TEAP Error TLV (value 5) Error Codes)[IANA #1359970].

Liz: These are all new action items being assigned to Murray and Paul.

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

Murray: In progress.

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

Murray: In progress.

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

Andrew: Maybe this should be removed? I can speak up at the mic during RSWG in
Brisbane and then someone can take it over.

Sandy: RSWG isn't meeting during Brisbane; they've been having interims.

Andrew: Okay. Then maybe we'll just leave it here and someone can take it over
when I leave.

  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-ssh-client-server-38 - IETF stream
    YANG Groupings for SSH Clients and SSH Servers (Proposed Standard)
    Token: Robert Wilton

Liz: We have a few Discusses on this document; do we want to discuss these now?

Rob: There's one I'd like to quickly comment on. I think the only one I want to
comment on is the security sections one. Actually no, it's not this document.
Nothing for me to discuss and I think the authors can respond to this.

Roman: My comment is congrats to Ken and thank you for the heroic effort at
trying to harmonize so many YANG documents. The substance of my feedback on
this one is very similar to the other two, which is I don't architecturally
understand how these YANG models are going to be used and I don't know the
right place to say the security considerations. It feels like a punt to say
this isn't a full YANG module, some other YANG module has to consider it, but
sometimes statements are made that seem inconsistent. I don't know the top
level place to make security level comments when the claim is it's someone
else's problem. I feel like we should say something.

Rob: I don't think that was the intention. I think the fact that YANG can use
groupings which can change over time is somewhat disingenuous to say I have
these security considerations now because you don't have a ton of binding to
other modules. In the comment where it says there are no security issues with
this module per se, but there are these other types which do have security
considerations, I thought it was helpful to be aware of. In some senses if you
deploy a load of different drafts you have to read the security considerations
of all those drafts and they all say mostly the same thing, i think that's less
useful. It's a meta conversation. By and large everything in a YANG model is
somewhat sensitive. It's all configuration and all operation data and all of
that has some level of sensitivity. What Henk has been saying and I agree with
him is you want to pull out the things that are particularly sensitive to the
point where you want to change the access policy on the router so you don't
allow them to be read by default. That's the thing Kent has been trying to draw
out more and I'd like to see the sec cons in YANG models move more in that
direction.

Roman: I agree with the sentiment you're saying but that's inconsistent with
every YANG module I think I've balloted on in the last five years. That's not
the approach we've taken in other places.

Rob: There's a document in netmod at the moment, YANG author guidelines, and
that would be the place to update that. I don't think it improves the security
posture. So I can ask them to put more text in if that's what you think is
required. Or I'll wait for the authors to respond.

Roman: I think we can find some middle ground here, where we can not repeat
everything but there's some text. It's confusing for me to say there are no
security considerations and then the next paragraph says oh yeah, watch out for
these things. That's incongruent to me.

Rob: I think what he means is not in this YANG module, but its dependencies
mean when you compile it, there is. Okay, so this is obviously staying in IESG
Eval. Revised I-D Needed.

Liz: To save us a step later, there is a downref. Do you want to add RFC 5647
to the downref registry?

Rob: I have no idea. I think that would be something for the security ADs to
comment on.

Roman: Let's keep going and not do this live.

Liz: Rob, why don't you let us know after you've had a chance to look.

  o draft-ietf-netconf-tcp-client-server-22 - IETF stream
    YANG Groupings for TCP Clients and TCP Servers (Proposed Standard)
    Token: Robert Wilton

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

Rob: I'm not sure, unless Éric wants to discuss it. I think the authors have
gotten back to you but I'm not sure what the current state is.

Éric V: It's about data proxy. I think Ken is making confusion between the word
proxy, where you use a method called get-http-something, and the one which is
connect, which are two different methods on http. There's one that's only a
proxy on http so it belongs to the http thing in netconf, but the connect
method is a real TCP proxy. I think it should be there.

Rob: Okay. I want to get these published and done because they've been in the
WG a long time. Is this something that could be added later? How important is
it to do it now?

Éric V: It's mainly for consistency. It's not blocking everyone. If you really
want me to remove my Discuss I can. MASQUE is indeed over UDP so we can assume
it's something different.

Zahed: I'd say the connect method you're talking about is also an HTTP matter.
We've overloaded that one. I see your point but I think this is about TCP
configuration. [crosstalk]

Martin:  HTTP connect is an HTTP method, but HTTP is just a protocol to deliver
to TCP, just like Socks is.

Zahed: If you look at the YANG model, I only see you're getting a proxy address
and it doesn't matter how you connect to that one. I didn't raise that to
Discuss level because I thought this is about just getting proxy information
somewhere in the client. How you connect is irrespective of the model, that's
my take. I don't think this is defining any method at all.

Éric V: Rob, if you want me to push it through, that's fine. It's just kind of
an incomplete YANG model, that's all. There are some proxies using the connect
method that won't be able to be configured by this model.

Rob: I pragmatically think if this could be added in later, and depending on
how widely it's used, it's still okay to publish this and add that as an
updated version of the model. Otherwise it's just moving goalposts.

Zahed: Rob, I think Mirja has a suggestion that we can scope it to Socks and
then say other proxies could be added in extension.

Rob: That sounds fine.

Éric V: Putting somewhere that other proxies can be added later, but saying it
in the document, would be good.

Liz: Okay, so this document is staying in IESG Evaluation and will require a
Revised I-D, I'm guessing?

Rob: Yes, thanks.

  o draft-ietf-netconf-tls-client-server-39 - IETF stream
    YANG Groupings for TLS Clients and TLS Servers (Proposed Standard)
    Token: Robert Wilton

Liz: We have a few Discusses on this document; do we want to discuss these now?

Rob: I think we already discussed Roman's, the one about security
considerations. The only one I want to discuss is Paul's one at a time - I
believe what's meant there is he put in an example covering TLS 1.1, 1.2, or
1.3, and thus you generate the example using either or. I think you could just
produce that twice. I don't think there's any other intention in my reading.
You could add a sentence to make that clear, or change it to use examples.

Paul: That's fine.

Rob: So either of those?

Paul: The example for TLS 1.1 seems to be an error.

Rob: That one's fine. I had asked ages ago if it should include TLS 1.1. It was
more the use one at a time bit that could be more clear. I'll ask them to add
more text. Otherwise I'll just say thank you for all the reviews.

Liz: This document will stay in IESG Evaluation, Revised I-D Needed?

Rob: Yes please.

Liz: Also, this document has seven downrefs. I'm guessing you haven't had a
chance to look at those and know all seven numbers by heart, but we will be
asking you if you want any or all of these added to the downref registry.

Rob: Okay, thanks. I may send them around to the IESG.

  o draft-ietf-suit-manifest-25 - IETF stream
    A Concise Binary Object Representation (CBOR)-based Serialization
    Format for the Software Updates for Internet of Things (SUIT)
    Manifest (Proposed Standard)
    Token: Roman Danyliw

Liz: We have a few Discusses on this document; do we want to discuss these now?

Roman: I do not. I think these are all manageable by the WG and authors. Thank
you for the review, everyone. Revised I-D Needed.

Liz: Okay. This document has three downrefs, so we're also going to be asking
you if you want these added to the downref registry.

Cindy: Just a note, this document doesn't have enough positions to clear once
those Discusses are cleared, so it does need more positions.

Éric V: I'm not sure I will have time before IETF to do it, sorry.

  o draft-ietf-ccamp-l1csm-YANG-25 - IETF stream
    A YANG Data Model for L1 Connectivity Service Model (L1CSM)
    (Proposed Standard)
    Token: Roman Danyliw

Liz: There are no Discusses in the tracker, so unless there's an objection now,
it looks like this one is approved. Okay, this is approved. Roman, is this
ready to go or do you want to give it a look?

Roman: Thanks very much for the review. I haven't had a chance to review the
detailed comments so let's put it in AD Followup, please.

  o draft-ietf-mpls-lspping-norao-07 - IETF stream
    Deprecating the Use of Router Alert in LSP Ping (Proposed Standard)
    Token: Andrew Alston

Liz: We have a Discuss here; do we need to discuss that today?

Andrew: Éric, I'm curious how you see us resolving this Discuss. I see your
point.

Éric V: I think it's very simple. This draft is using past tense, saying this
document has been made historic. But we don't yet have the document making it
historic. The only way to ensure the sequence is to first approve the document
yet to be done, making RFC blah blah historic, and then we can approve this
document. I think the only way to do it is block it until we have this change
of status.

Paul: The document itself doesn't cause the action. This document should only
say this document is historic, not that this document makes it historic.

Éric V: They changed the text on my request, so at least that part is solved.
The same thing for the missing reference, which was my bad.

Andrew: So you're basically proposing we create a simple document that makes
the other one historic, and then pass that, and then we'll be able to remove
the Discuss for this one?

Éric V: Correct. If there's another solution, I'm all ears.

Paul: You don't need a document to make it historic, right? It's just an IESG
action.

Éric V: I think we need a document.

John: It's all spelled out in that IESG statement. It has almost a flow chart.

Éric V: So it's simple. They're already providing some justification in this
document.

Andrew: Let me talk to the authors on this. You said that process has to be AD
initiated.

Éric V: I think the IESG statement says that.

Andrew: I'm just trying to figure out if I can tell the authors to go write
that document or does whoever is taking over for me have to write it.

John: I think you could ask them to ghost write it for you, but it's you that
has to put it up.

Warren: The status change document should be really short. If it were me I'd
suggest this document gets approved and held, the status change document gets
written up and points at this new document, and we leave a note to the RFC
Editor please don't publish this until the status change happens. Once there's
an assigned RFC number, you can do them both at the same time.

Andrew:  That works for me.

Éric V: Me as well, as long as the RFC Editor is okay with that procedure.

Warren: The RFC Editor has done this in the past. You basically just attach a
note saying to please let us know when it has an RFC number assigned, then you
update the status change document saying that RFC blahblahblah makes this
historic, and then we do them at the same time. I don't think the RFC Editor
will mind at all; they're used to holding stuff.

Andrew: I can write that document and put it up but it's never going to get
through Last Call in time and then it won't be an AD bringing it to the
telechat.

Warren: You write it and assign it to me as AD and then I can bring it.

Liz: So for this document, are we just leaving it where it is for now?

Éric V: I think we need a Revised I-D to add this note, at least.

Andrew: So Revised I-D Needed.

  o draft-ietf-ippm-ioam-YANG-12 - IETF stream
    A YANG Data Model for In-Situ OAM (Proposed Standard)
    Token: Martin Duke

Liz: This document doesn't have any Discusses, but it does need one more
position.

Martin: Rob has assured me that I will get that in a matter of hours. I believe
the existing comments have been addressed so it will just remain here and Rob
will have substantive comments, so I expect it will end up in Revised I-D
Needed.

2.1.2 Returning items

NONE

2.2 Individual submissions
2.2.1 New items

NONE

2.2.2 Returning items

NONE

2.3 Status changes
2.3.1 New items

NONE

2.3.2 Returning items

NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

  o draft-ietf-detnet-mpls-over-ip-preof-11 - IETF stream
    Deterministic Networking (DetNet): DetNet PREOF via MPLS over
    UDP/IP (Informational)
    Token: Roman Danyliw

Liz: We don't have any Discusses and we do have enough positions, so unless
there's an objection now, it looks like this document is approved. This is
approved; Roman, is this ready to go now?

Roman: I'm in the same position as the last one; I haven't had an opportunity
to cruise through the comments so please put it in AD Followup.

  o draft-ietf-bess-bgp-sdwan-usage-20 - IETF stream
    BGP Usage for SD-WAN Overlay Networks (Informational)
    Token: Andrew Alston

Liz: The consensus here is set to Unknown, so we can go ahead and change that
to Yes for you. We have a few Discusses; do we need to discuss these now?

Andrew: I don't know what to do with this document anymore. I took the
document, I sent it all the way back to the WG, I even un-adopted it in the WG.
I sent them 87 grammatical corrections and they still screwed it up. I hate to
say it but I agree with John's Discuss, particularly parts 1 and 2.

Lars: It sounds like you might need new editors, or new chairs, or both.

Andrew: So I could return it and appoint another editor.

Lars: The concern is that it doesn't get fixed. Then you need to put people
holding the pen who can understand what needs to be fixed.

Paul: I thought the issue was much larger. Is this document publishable at all?

John: I think Lars is right. The authors are not iterating as efficiently as
most authors do to fix the technical defects. That's something we can
eventually get past. I agree that overall is this something we should even be
publishing? Having raised the Discuss I feel a little bit like the dog that
caught the car. I'm not entirely sure what to do with it. This is just not
publishable.

Andrew: there is a status of do not publish but i have no idea how a document
ends up there.

John: Robert clarified that that's not an IETF stream status. But we can still,
one possible outcome of this whole process is to say don't publish it and
return it to the WG. It's generally not a very nice thing to do but at a
minimum I'd like to see some engagement from the WG chairs to say we've seen
this and looked at the charter and here's what we think. I haven't seen
anything like that.

Warren: I think there is utility in having use case documents and architecture
documents, so something like this would be useful and could be published. But
it's not quite this document. If you want to kill it, I think the right status
change is to make it dead. But it also seems like if you don't feel like the
chairs and authors are doing what you want, maybe this is your successor's
problem. i don't know if you removing the chairs on the way out the door is --

Andrew: I don't think I could remove the chairs but I could certainly ask them
to appoint an editor, I'm not convinced that would fix this document. So
Gunter, I'm gonna make those your problem.

Gunter: Great, thank you.

John: In terms of this not being chartered, it's not chartered. Sometimes it
can be fine to publish use cases, I'd just like to see some acknowledgement of
that. I could imagine the conversation saying, we should have updated our
charter a long time ago, let's get on that. I recall past similar
conversations. I think the first step needs to be some kind of actual dialogue
with the chairs/wg.

Andrew: I have had a number of conversations with them.

Warren: A bunch of authors put a bunch of time into it and now just want an RFC
number. I think people are just tired and grumpy.

Andrew: So what do we do with this now?

John: I can't clear my discuss until the authors fix or at least acceptably
respond to the technical defect, the second set of points in the discuss.

Paul: I think we will get someone visiting the sec office hours for this. My
guess is that they will use 119 to talk about what to do.

Andrew: In that case we'll leave this in IESG evaluation.

Rob: What if we suggest they take this to ISE?

John: They could attempt that.

Roman: We should think about our published Discuss criteria. If we think this
document is not in charter, that's a very clear path. If we determine the
document is in charter but still don't want to publish it we should wrap that
into published Discuss criteria. I don't want us to invent an augmented path
for something that's not chartered and still have a path forward. The option is
abstain.

John: I'm willing to take a stand that it's not in charter. I don't actually in
my heart feel like it's not in charter is … I think it could be in a reasonable
charter. They could recharter and place it in charter. I think that's a path
forward for that aspect of it.

Zahed: I agree with you John, this does not fall within the charter. We're
sticking to that? It's a process violation and we should send it back? One way
forward would be to recharter.

Andrew: Then I just have one question, Gunter, do you want to send this back or
do you want me to do it before I leave? I'm happy either way.

John: I don't think you need to send it back, you could just leave it in IESG
review.

Gunter: So then we'll leave it where it is and during 119 then discuss with
chairs and authors telling them it's out of charter? That's the plan?

John: That sounds good.

Andrew: I have no problem being the bad guy. So we'll leave it where it is, but
if you do decide you want me to send it back, let me know.

Liz: Should we put this in Revised I-D Needed, or AD Followup?

Andrew: AD Followup, I think.

Gunter: If we keep it in AD Followup, is it fair to the authors to wait until
119 for any followup?

Andrew: I sent this back the first time and it took them three or four months
to do what was fairly simple in fixing boilerplate, so in three weeks I'm not
overly concerned.

John: The ball is currently in their court anyway.

Roman: Irrespective of John's position, Paul and I have Discusses on technical
merit that need to be discussed anyway, so it would still be blocked. I would
love operator feedback or someone who knows more about routing than me, about
the claim that BGP over tLS is a widely deployed thing.

Warren: I have seen it kind of done, but that's when people build a TLS tunnel.

Andrew: BGP over TLS itself, there was a draft that if I remember went nowhere.

John: Of course it can be done. But it's not standardized. That's sort of
emblematic of a lot of the defects of this document. You can do this thing, it
doesn't tell us how.

Andrew: So this document is going to stay where it is.

  o draft-ietf-tvr-use-cases-07 - IETF stream
    TVR (Time-Variant Routing) Use Cases (Informational)
    Token: Andrew Alston

Liz: This one has no Discusses, so unless there's an objection now, this one is
approved.

Andrew: This is Revised I-D Needed, I just want to clear a couple of those
comments. Other than that, it's good to go.

Liz: Great, then this document is Approved, Announcement to be Sent, Revised
I-D Needed and you can let us know when it's ready to move forward.

  o draft-ietf-lamps-pkcs12-pbmac1-08 - IETF stream
    Use of Password Based Message Authentication Code 1 (PBMAC1) in
    PKCS #12 Syntax (Informational)
    Token: Roman Danyliw

Liz: We have no Discusses, so unless there's an objection now, this document is
approved.

Roman: Thanks again for everyone's review. I just wanted to respond to Éric.
The answer why this is not PS is this is building on a collection of
informational documents. Can I just have AD Followup here as well to read the
comments?

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 Detecting Unwanted Location Trackers (dult)

Liz: There aren't any Discusses, so unless there's an objection it looks like
this charter is approved. Okay, I think we have approved this.

Roman: Thank you for everyone's review. John, I merged your edits into -07 so
that's in production. The text is ready to go; I have two chairs; we're off to
a good launch at 119.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

o Multiplexed Application Substrate over QUIC Encryption (masque)

Liz: Is this ready for external review?

Martin: Yes, I believe it is.

Zahed: I don't see any changes with the milestones. Should we just copy these
when it goes for external review?

Martin: I had a conversation with the chairs about milestones awhile back. I'm
trying to remember what the outcome was. Were there no milestones before for
the previous charter?

Zahed: I was thinking it was too old. Maybe we just add one milestone? I'm
pushing a bit.

Martin: I don't think there were milestones for the previous one. I'm trying to
remember. I think the chairs are pushing back about having milestones. Do we
have a policy on this?

Roman: Yes. There's an RFC I can't quote that says to charter a WG you need a
charter, chairs, and milestones.

Cindy: The current charter has two milestones.

Warren: Has that been changed by an IESG statement? I seem to remember you
could.

Mirja: I think we changed it so that you don't need a deadline or a timeline
for them but you do need milestones.

Martin: Why can I not see them?

Cindy: There's a charter document page and a group About page and you need to
look on the About page.

Martin: Okay. I'll just add these right now.

Cindy: I have one more question. Do you want this to be a seven day external
review so it can be approved on next week's telechat?

Martin: No, I don't think so. Given the outside interest, I think it's
appropriate to have the additional time. I don't think it will really affect
what happens in Brisbane.

Cindy: Okay.

Liz: Thank you for that, Martin and Cindy.

4.2.2 Proposed for approval

NONE

5. IAB news we can use

Roman: It appeared no one was able to join yesterday, one of our tech talks
that talked a lot about UN related things that deal with Internet governance.
It was a really great talk and the slides will be made available. I'll share
those around. I want to publicly thank the IAB here for getting Deb as a new
SEC AD.

6. Management issues

6.1 [IANA #1358158] renewing early allocation for
draft-ietf-anima-constrained-voucher (IANA)

Liz: Rob, this is one of your documents; do you want to let us know how you
feel about renewing this early allocation?

Rob: Yes. I need to look at this one. I have no issues with it. Was this the
one I replied to in email?

Sabrina: We did get your email approval, so we submitted the management item
after that.

Rob: Okay, fine. So I'm happy for this to be renewed; anyone else object?

Liz: Okay, I'm not hearing any objections so we'll consider this renewed and
we'll send an official note to IANA.

6.2 [IANA #1359278] Designated experts for RFC 9530 (Digest Fields) (IANA)

Liz: This is a new one being assigned to Murray.

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

Liz: This is a new one being assigned to Paul.

6.4 I[ANA #1359744] Designated experts for [RFC 9535 (JSONPath: Query
Expressions for JSON)] (IANA)

Liz: This is a new one being assigned to Murray.

6.5 Telechat dates between IETF 119 and IETF 120 (Secretariat)

Liz: We have some dates here between 119 and 120. Because of how the weeks are
laying out we really only have one option. June 20 could be an informal but I
guessed since the following two weeks are the retreat and a holiday in the US,
you might want another formal one there. Any comments or questions? Okay, we'll
just go ahead and book these. Thanks.

6.6 [IANA #1359970] Designated experts for draft-ietf-emu-rfc7170bis (TEAP
Error TLV (value 5) Error Codes) (IANA)

Liz: Paul has identified  Margaret Cullen and Nancy Cam-Winget as the
designated experts for this registry. Any objections to naming them? Okay, I'm
hearing no objection, so we'll send that official note to IANA.

6.7. Downref in draft-ietf-cellar-flac-14

Murray: One quick thing I wanted to get minuted. A document coming out of
cellar (draft-ietf-cellar-flac-14) was asked to change a reference.  RFC 2083
was changed from an informative reference to a normative reference, which
creates a normative downref. Do we want to send this back through for another
Last Call. The consensus among me and Roman was that this document was
published in 1997 so it's sufficiently stable it would be a waste of time doing
a Last Call just for that and we should just add it to the downref registry.
Does anyone have a problem with handling it that way? … Okay, I'm not hearing
any objection, so we'll just do that. Thanks.

7. Any Other Business

Lars: The agenda for the IESG and joint IAB meetings at 119 are looking a
little light. Please add topics to the wiki.