Skip to main content

Narrative Minutes interim-2021-iesg-09 2021-04-22 14:00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2021-04-22 14:00
Title Narrative Minutes interim-2021-iesg-09 2021-04-22 14:00
State (None)
Other versions plain text
Last updated 2024-02-23

Narrative minutes for the 2021-04-22 IESG Teleconference

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

1. Administrivia
1.1 Roll call

Jenny Bui (AMS) / IETF Secretariat
Ben Campbell (Independent Consultant) / IAB Liaison
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (F5 Networks Inc) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline (Google) / Internet Area
Martin Vigoureux (Nokia) / Routing Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

Jay Daley / IETF Executive Director
Michelle Cotton (ICANN) / IANA Liaison

Doug Dodson
Enno Rey
Greg Wood

1.2 Bash the agenda

Amy: Does anyone have anything they'd like to add to today's agenda? Any other

1.3 Approval of the minutes of past telechats

Amy: Is there any objection to approving the minutes from April 8? Hearing no
objection. Does anyone have an objection to the narrative minutes from April 8
being approved? Hearing no objection there either. We will get those posted.

1.4 List of remaining action items from last telechat

     o Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy to look at
       updating the I-D Checklist.

Murray: Robert Sparks took a run at doing the whole thing from the beginning
because he had an idea about reorganizing the document around more modern
xml2rfc and so forth. I think I heard from him a day or two ago that it was
ready, so I need to take a look at it. The short answer is that it's in

     o Warren Kumari, Deborah Brungard, Stephen Farrell, and Jay Daley to
       investigate ways to recruit, recognize, and retain volunteers in the

Warren: Not going hugely well. I've been trying to get it rescheduled and have
been having a hard time, so no progress since last time.

     o Ben Kaduk to find designated experts for RFC 8935 [IANA #1184035].

Amy: This is on later as a management item so we'll call this provisionally

     o Eric Vyncke to draft text for the WG Chairs about requesting early
       review of documents by existing Directorates.

Eric V: This has been sent. You can mark this as done.

     o Alvaro Retana, Rob Wilton, and Martin Vigoureux to draft text on the
       framework for a long-term future plan for the IETF.

Alvaro: This is in progress. Some of this is in next week's retreat.

     o Alvaro Retana and Martin V to draft text to update the IESG Statement
       on Internet Draft Authorship to include "Contributors."
     o Alvaro Retana and Martin V to draft a note to wgchairs
       Asking them to always confirm author/contributor status.
     o Alvaro Retana and Martin V to draft text to include in the I-D
       Submission tool warning about too many authors.

Alvaro: We sent an email about the first item on Monday. Lars took a look and
made a bunch of comments. I haven't heard from anyone else. We'll leave this
text there for a few days and then do the publication of the new statement. The
next two we're going to handle in order, so once the first one is done we'll go
to the next. Those two are in progress.

     o Lars Eggert to update the text of the IESG Statement "Last Call
       Guidance to the Community."

Amy: This is done.

     o Lars Eggert to update BCP 45.

Lars: That was one of the two items that came out of the conclusion of the last
Call experiment. One of them we did, which was the previous action item to
update the statement. BCP 45 is the charter of the IETF discuss list. There's
an individual draft that I put together and discussed a little bit in
gendispatch. It's gotten the feedback it needed and I'm looking for someone to
AD Sponsor this. I suspect more feedback will come in during Last Call.

Rob: I was wondering whether it's worth having this discussion after the
retreat, depending on what comes out of the discussion on the IETF mailing list.

Lars: That makes sense. If we decide to make any changes to the list quickly,
this will be overtaken by events. So let's leave this here until the next
formal [telechat] and we'll see where we are.

     o Martin Duke to draft an email to the WG Chairs about session
       requests for IETF 111.

Amy: This is done, isn't it?

Martin D: I believe it went out.

Amy: That's what I thought. We'll mark this as done.

     o Erik Kline to find designated experts for RFC 8822 [IANA #1195655].

Amy: This is on [today's agenda] as a management item so we'll call this
provisionally done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-roll-aodv-rpl-10  - IETF stream
   Supporting Asymmetric Links in Low Power Networks: AODV-RPL
   (Proposed Standard)
   Token: Alvaro Retana

Amy: I have a number of Discusses for this document; do we need to discuss any
of those today?

Alvaro: For most of them, we need the authors to get involved in providing
answers and revisions. I did want to ask Rob about yours. Do we need to talk
about it more? Later in email?

Rob: I think we should probably have a conversation, maybe on an informal. My
basic question is, if the WG decides to publish a protocol without doing a YANG
model for it, and it looks like that model may not come anytime soon, if at
all, is that something that we care enough about? Would be we delaying
publication of documents until it looks like that's going to happen? I'm not
saying we should stop this document on that basis, which seems unreasonable,
but I do think there's a general question here as it's unclear to me if and
when a YANG model might come along for this protocol.

Alvaro: Sure. I guess we can talk about that at the next informal.

Rob: But I won't block the document on that basis.

Alvaro: Perfect, thanks.

Lars: Quickly, do you think all protocols should have YANG models, or
specifically routing ones?

Rob: No, not all protocols, I mean ones in the network area. I'm not even sure
we want to do that, but I think having a conversation about it would be useful.

Warren: I think that would be a new requirement so we should have a discussion
about it.

Lars: There's some time in the agenda for the retreat so we could provisionally
put it in the parking lot for next week.

Alvaro: Okay. So for this document, we're going to need a Revised ID.

 o draft-ietf-tls-dtls-connection-id-11  - IETF stream
   Connection Identifiers for DTLS 1.2 (Proposed Standard)
   Token: Benjamin Kaduk

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

Ben: Let's put it in Revised ID Needed; there are some good comments and
already some pull requests in Github so we should get those fixed.

Francesca: I didn't want to block this, but I do have a question about this 53
number that was highlighted before. I got some answers from the authors about
why this number is incompatible with this document, but the authors had some
preference about if this IANA number once it expires, if it gets used with
something that is DTLS compatible or only for TLS? I don't know how to make
sure that this number is not reallocated for something that works with DTLS.

Ben: My expectation is that IANA is basically going to not reuse numbers until
we're out of other numbers.

Francesca: Even if the allocation is expired?

Ben: I think so but I'm not entirely sure.

Sabrina: That's correct. We won't use the number until everything is exhausted,
but we would also notify you a couple of months before it expires to ask if you
want to renew it.

Ben: So I think in this case we would just not renew it and it would linger in
this state of previously allocated but currently expired.

Sabrina: The expiration date will remain in the registry if you decide to let
it expire.

Francesca: That answers my question. Thank you.

Amy: Okay, so this will go into Approved, Announcement to be Sent, Revised ID

 o draft-ietf-opsawg-tacacs-yang-10  - IETF stream
   A YANG Module for TACACS+ (Proposed Standard)
   Token: Robert Wilton

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

Rob: Yes please. I want to discuss both of them. My first question to Roman is,
in your Discuss are you asking both about the status of the document in terms
of being informational vs standards track, or just some of the text in the

Roman: I'm largely looking at the status. I'm trying to be practical here. My
worldview is that we did 8907 with all of the challenges that document has. We
did it primarily because we wanted a written reference to be able to use as a
springboard for next gen development and we caveated that this does not meet
the modern day bar but we're documenting the world as it's currently being
used. My finesse here is that no one's got a YANG module, no one's got any
running code, and we're about to say in a PS you have alternatives here but let
me give you new functionality for an insecure technique. That did not seem
right to me.

Warren: You're right. The existing TACACS+ protocol is awful and 8907 does just
document the existing stuff and also kind of implies it's awful. However, this
is one of the main, if not the main, way that people currently authenticate
operator log on to network devices, so having a management thing which says
seeing as you're doing this anyway, here's a way to manage what you're
currently doing even though it's stupid, does not seem completely unreasonable
to me. I'd rather that people have a way they can easily manage their
admittedly stupid TACACS+ protocol in a standardized way than that they don't,
so never get around to maintaining and managing and rolling the keys. I kind of
think this is the lesser of two evils.

Roman: Again, I agreed with the thinking on 8907 and I can get on board with
accepting reality and asking if it's a bridge too far to say 'we're already
using it so can you just help us do this insecure thing in a standardized
fashion?' But I don't think we should do that as a PS. 8907 is informational.
If we're talking about configuring an informational thing, that should also be
informational. And probably some more caveats as well, just like the ones that
are in 8907.

Rob: I sort of agree with Warren here. I think Proposed Standard is better for
YANG modules. Again, the same explanation Warren has given. I agree that 8907
is informational and that makes sense, but I don't think it necessarily follows
that this one should be informational. I think by and large this is just
finding a management API. As Warren says, if you're going to manage this
protocol, this is the way the IETF thinks it should be done.

Roman: We get into the bigger discussion then. PS has a bar, so I'm now
providing an administrative interface for the thing I know is bad and I lay out
in the document that there are alternatives to.

Rob: I think actually also on the point on YANG modules anyway, as a side
point, a discussion came up with the Routing ADs about what the standard is of
documents that define YANG models, in that case in terms of experimental. I
think having some discussion and guidance from the IESG makes sense. Does it
make sense to have a broader discussion there and then come back to this?

Roman: So what you're saying is do we have a consistent way of saying a
particular status for a YANG module?

Rob: Yes. In their context it was experimental. For me this is to find an API
and it comes back to saying this is the way to configure this protocol. It's
not like this is one possible YANG module you could use, we're saying this is
what you should use and what everyone should implement as accurately as
possible. If you make it informational, it feels to me like it waters that
down. Then if we come back along and try to build upon the YANG module and fix
the security things, I'd presume that fix, that augmentation, would probably be
Standards track and then that will be building on top of an informational YANG
model. That feels like potentially the worst of two evils.

Murray: I think I heard in there something I agree with, which is that this
goes to interoperability, which means Proposed Standard to me, and that kind of
ends the argument in my head.

Roman: So the piece I guess I didn't understand is, is the thinking that the
YANG module we're talking about here covers some future protocol we don't have
yet? Because I thought if there was a new TACACS++, there would be a new YANG
module. So this struck me as a self contained thing covering just the old
TACACS+ protocol. The language I read in there said this is the YANG module for
the thing we have now.

Warren: So there is in theory supposed to be a TACACS++. What it really was
going to be was wrapping TACACS+ in TLS and be done. Honestly though, the birth
of the original TACACS+ document was so drawn out and so painful, I think
nobody really has the stomach to take it on anymore. They spent months and
months and were beaten a number of times by various people and I think the
wrapping in TLS part people have kind of, not lost interest in, but it's more
trouble than they're willing to do.

Roman: That's a pretty scary situation, because that says we're going to
endorse the current way we have it, we all acknowledge it's really bad, and
we're not using this as a springboard for new work but accepting the scary
as-is which doesn't meet modern security.

Warren: That's true, however, going back to I believe that this is still the
standard way that most people authenticate for CLI logons onto devices. There
is no alternative. We can try to push again and say hey authors who wrote
TACACS+, the update should be easier, we can try for that. Regardless, seeing
as this is the thing that gets used, I think it's better to have a way for
people to be able to easily roll the keys and manage it than not.

Roman: The keys don't buy you anything. I don't get that.

Warren: They do some. In order to do anything interesting with it you need to
either know what the key is, and then you can decrypt everything, or you need
to know the structure of a bunch of things and then you can get back some
stuff. It's far from great. I believe almost everybody who actually uses the
protocol uses it in a limited domain / closed network. I don't really know what
the alternative is though, in the same way that we still kind of allow MD5 and
BGP open authentication stuff, which is also awful. We can choose between
acknowledging how the real world works and try to move people along, or not.
One thing worth mentioning is that part of the reason we haven't managed to
move it forward, is that last time people tried to document how the real world
existed, they got beaten so many times they ran away, potentially we propagate
that problem if -- [cut off]

Roman: Do you think we could write that up? That motivation, in terms of
operational considerations?

Warren: Possibly. I'm not sure that this is the document to do that, though.
This document says we have a protocol, this is how to manage it. This isn't my
document. Maybe having something to remind people that TACACS+ is probably a
bad idea, but if you're going to do it, here's how you manage it.

Lars: I was just going to ask whether this might be case where we want to put
an IESG note on the document to talk about this.

Eric V: But do we have the same caution when we're using a YANG model for OSPF
v2 or v3 without any authentication?

Alvaro: The YANG model covers the authentication. Whether people choose to
configure it or not.

Eric V: But in YANG if I'm not mistaken, you can make a leaf mandatory. Is it
mandatory, the YANG model? I don't think so, for OSPF.

John: It seems like there's a fine line here between a YANG model that can be
used to do something stupid, which is probably every YANG model in existence,
and a YANG model that can't be used to do anything that's not stupid, which is
this one.

Roman: I can get off the philosophical position of not evolving the thing that
isn't up to modern stuff because it's in the world and we need a way to manage
this thing that's widely deployed. I guess what I was saying is to remind folks
that this is here to help us manage this widely deployed thing which has these
known issues. It is what it is. I don't think we're inventing new language,
we're repeating the language we have in 8907. Having said that, there's clearly
a break that's happening here because this is the other part of the Discuss. We
actually are changing the guidance on the shared secret, because we're saying
MUST in the YANG module, and we're only saying SHOULD in the core TACACS+
document. We're saying different security things for the YANG than we are for
the base spec.

Rob: I don't know if you saw my reply, but the base spec also says that you
SHOULD use a minimum of sixteen, so I think the YANG model is consistent with
another sentence in the spec.

Roman: But a SHOULD is that I could potentially use four. It is literally
impossible, maybe I don't know YANG well enough, to do anything less than
sixteen, so the YANG model is MUST.

Warren: I might be stretching things a little far here, but I think what's
agreed is using something less than 16 in TACACS+ is probably a bad idea.
That's what the TACACS+ document says. How do you feel about saying the
management protocol doesn't let you do something stupid? If you want to do
something less than 16, you can't configure it using this management protocol.
That means if you're already using something lower, like eight, when you start
using this management protocol, seeing as you can no longer configure something
that short, you automatically are getting better security. I wonder if this is
getting hand wavy.

Roman: I'm hesitating because this is going to be a bizarre set of things
coming out of my mouth. I actually don't think we should do that. You open up
the Pandora's box. Either the YANG model is a one to one for TACACS+ as it's
currently documented, but if you're in the business of saying I know things are
bad, but let's selectively try to do that, why do we stop there? To me that
reopens the box. Either we're saying we know the thing is bad, but it's widely
used, let's just provide a standardized way to twiddle it, or we do it the
other way. My recommendation would just be don't make it 16..max, just make it
whatever TACACS+ is, which I think is zero..max.

John: Are there any other best practices? This is basically in the category of
enforcing a best practice. If there are other best practices that should be
enforced but aren't in the model, it seems like that's worth doing. But the
model is just a configuration API, right? It doesn't make sense to in that
model go and try to fix other things we know are bad about TACACS+, like how it
uses or doesn't use cryptography. It doesn't seem inconsistent to me, although
your argument is worth thinking about but at least for me, it's not compelling.

Rob: So Roman, if you look at my email reply, there are two sentences in the
document that are almost contradictory in the base spec. One saying you should
use more than 16, on saying you can use any number. I think if we had zero that
would be violating that other statement in the base spec. If you look at my
email reply, I've got the quoted text. That one we can probably resolve
offline. So to sum this up, looking at the chat, it sounds like having a
general discussion in the IESG about the standards of these YANG models related
to informational and experimental would be helpful. For this particular one, it
also sounds like having some text that's like a warning to explain the
background here, would that be sufficient to move this forward?

Roman: I could get on board with that. Let me check the language you have
around the second point.

Rob: Francesca, would that be sufficient for you as well? Or are you still

Francesca: I'm still a bit confused, this discussion would be not only for this
document. It's a good idea we should talk bout more YANG modules for
informational and experimental in general. I won't block this document but I
realize that I am not aware if this is common practice or not and I haven't
thought about the consequences of publishing this as informational instead of
proposed standard, so I think we should talk about that.

Rob: So I think we're done for today. I'll take an action to discuss it
hopefully next week during the retreat if there's time available, and then we
can decide in the general context and then this document in particular, if
necessary. So I guess AD Followup is the right state?

Amy: Sure, this will stay in IESG Evaluation and go into the substate of AD

 o draft-ietf-idr-ext-opt-param-12  - IETF stream
   Extended Optional Parameters Length for BGP OPEN Message (Proposed
   Token: Alvaro Retana

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

Alvaro: Can we put this in AD Followup? I just want to catch up on the updates

Amy: Okay, this is Approved, announcement to be sent, AD Followup and you can
let us know when you're ready.

 o draft-ietf-regext-secure-authinfo-transfer-06  - IETF stream
   Extensible Provisioning Protocol (EPP) Secure Authorization
   Information for Transfer (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: I don't think so. I need to go back and see how the WG wants to respond
to it. AD Followup, please.

 o draft-ietf-emu-eap-noob-04  - IETF stream
   Nimble out-of-band authentication for EAP (EAP-NOOB) (Proposed
   Token: Roman Danyliw

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

Roman: I don't think so. I appreciate the detailed feedback. I think we need
Revised ID here and the authors need to work through some of this.

2.1.2 Returning items

 o draft-ietf-stir-cert-delegation-04  - IETF stream
   STIR Certificate Delegation (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: This is ready to rock. I only put it on because there was a Discuss on
it that cleared, but then the IESG rotated and it didn't have enough ballots,
so I just let it ride one more time.

Amy: Okay, we'll send that announcement as usual and move on.

2.2 Individual submissions
2.2.1 New items


2.2.2 Returning items


2.3 Status changes
2.3.1 New items


2.3.2 Returning items


3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-opsec-v6-26  - IETF stream
   Operational Security Considerations for IPv6 Networks
   Token: Warren Kumari

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

Warren: I think Revised ID needed. There are a bunch of helpful comments that
would be useful if they were folded in.

Eric V: I was about to say the same. Many comments are sensible and we need to
work on it again.

Amy: So I'll put this in Approved, Announcement to be Sent, Revised ID needed.
You can let us know when that's ready to go.

Murray: Brief process question here. This got deferred to this telechat a
couple of weeks ago and the state is still IESG Evaluation - Defer. Is the
Defer not supposed to automatically clear on the second telechat?

Ben: If it did, you could just keep deferring and deferring.

Murray: Oh, so this blocks a second deferral. Okay, I get it, thanks.

Amy: It used to be that the Datatracker put in a block for the defer, so if it
went back to IESG Evaluation it still wouldn't allow another Defer, but it's
been several years and I don't know if that's still the case.

 o draft-ietf-dmarc-psd-12  - IETF stream
   Experimental DMARC Extension For Public Suffix Domains
   Token: Murray Kucherawy

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

Murray: No, I don't think so. Tim is the co author who has been responding and
he's been very responsive so he plans to respond to Ben very soon. Everything
else is comments and he's replied to most of those. We're fine here.

Amy: Sounds like this is going to get a Revised ID?

Murray: Yes, sorry.

 o draft-ietf-v6ops-ipv6-ehs-packet-drops-06  - IETF stream
   Operational Implications of IPv6 Packets with Extension Headers
   Token: Robert Wilton

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

Rob: I was just going to make a quick comment. Murray asked if I'd seen there
were six authors and if they were okay. I was going to quickly ask Warren since
he's an author, if he knows whether all the authors have contributed to this
document or if I should check with the chairs?

Warren: I believe they have all contributed to the document. This document has
also been around a really long time. If it was a newer document, the number of
authors might be a more reasonable question, but I think all of them have
contributed and contributed significantly.

Rob: Okay. That's enough for me. Murray, is that okay with you?

Murray: Yes, that's fine. I just wanted to ask the question.

Rob: Thanks for asking. And thanks for the reviews, I'll make sure the markups
get done.

Amy: So are we waiting on anything for this?

Rob: This will be a Revised ID, I'm sure.

3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items


3.2.2 Returning items


3.3 Status changes
3.3.1 New items


3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items


3.4.2 Returning items


3.4.3 For action

 o conflict-review-yao-regext-bundling-registration-00
   IETF conflict review for draft-yao-regext-bundling-registration
     Extensible Provisioning Protocol (EPP) Domain Name Mapping
   Extension for Strict Bundling Registration (ISE: Informational)
   Token: Lars Eggert

Amy: This was assigned to Murray this morning so we'll come back to this when
the review is done.

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

 o Effective Terminology in IETF Documents (term)

Amy: I have no blocks on this second external review, so unless there's an
objection now it looks like this second external review can go out for version

Lars: It can, thank you. The interesting discussion will happen when it comes

Amy: Okay, so this review has been approved, and we'll send an announcement.

4.1.2 Proposed for approval


4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Limited Additional Mechanisms for PKIX and SMIME (lamps)

Amy: It looks like this needs to go for external review, is that correct?

Roman: That's correct. I'd like to get it out for external review. What's
interesting about this one is that it's the start of getting support for post
quantum. Jody added to some of our protocols so if not for any other reason I
want to make sure we get a lot of eyes on it. There's some text some folks
suggested and I think that's worth doing before we get it out for external
review as well.

Amy: I'm hearing no objection to sending it for external review, so that's
approved. Did you want to do those edits before it goes?

Roman: Yes please.

Amy: Okay, so you can just let us know when it's ready for external review and
we'll send the note.

4.2.2 Proposed for approval


5. IAB news we can use

Amy: Martin V had to drop from the call but he sent an email update about the

6. Management issues

6.1 [IANA #1194832] Designated experts for RFC 9018 (Warren Kumari)

Amy: Any objection to approving Donald Eastlake as the second expert for this
registry?  Hearing no objection, so we'll send official note to IANA.

6.2 [IANA #1184035] Designated experts for RFC 8935 (Ben Kaduk)

Amy: Any objection to approving Mike Jones and John Bradley as the designated
experts for this registry? Hearing no objection, so we'll send official note to

6.3 [IANA #1195260] Renewing early allocations for draft-ietf-lsr-flex-algo

Amy: Any objection to approving this early allocation renewal?

John: I think we should approve it. The document has passed WG Last Call and is
waiting for me now. That's all. I'm pretty sure it already has implementations.

Amy: Okay, I'm hearing no objections to approving this renewal, so we'll send
official note to IANA.

6.4 [IANA #1195655] Designated experts for RFC 8822 (Erik Kline)

Amy: Any objection to approving Donald Eastlake as designated expert for this

Ben: I don't object to Donald, it's just that this particular registry is an
interesting scenario and the author of the document which creates the need for
the registry is not necessarily an informed expert for the registry as a whole,
but Donald has been around for a long time so I suspect he will be able to do
just fine.

Erik K: Given what we went through to create it in the first place, I don't
envision too many updates.

Amy: I'm hearing no objection to approving Donald, so we'll send official note
to IANA.

6.5 Finalize the Retreat Agenda (Lars Eggert)

The IESG edited and finalized the agenda for the following week's retreat.

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

Lars: I grabbed a bunch of Alissa's Discusses that got cleared when she stepped
down. I'm going to follow up and I'll either drop them or figure out what needs
to happen. That's why you saw email on those old Discusses today.

Francesca: I have a question. I have three documents that should advance
together. They'll soon go For IETF Last Call and I'd like them to get to the
telechat at the same time, but they will take almost all of the pages for a
telechat. How do I make sure they get to the same telechat?

Warren: The same way you do almost anything; you ask the Secretariat.

Amy: When you issue the ballot for each of the three of them, you can send us a
separate email just to let us know all three should be on the same telechat and
if we have to we'll put them out to a later telechat so they all get on the
same one.

Francesca: Thank you.