Narrative Minutes interim-2021-iesg-13 2021-06-03 14:00
narrative-minutes-interim-2021-iesg-13-202106031400-00

INTERNET ENGINEERING STEERING GROUP (IESG)

Narrative minutes for the 2021-06-03 IESG Teleconference

These are not an official record of the meeting.

Narrative Scribe: Liz Flynn, Secretariat

1. Administrivia

1.1 Roll call

ATTENDEES

---------------------------------

Jenny Bui (AMS) / IETF Secretariat

Ben Campbell (Independent Consultant) / IAB Liaison

Michelle Cotton (ICANN) / IANA 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

Murray Kucherawy (Facebook) / Applications and Real-Time Area

Warren Kumari (Google) / Operations and Management Area

Cindy Morgan (AMS) / IETF Secretariat

Francesca Palombini (Ericsson) / Applications and Real-Time Area

Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area

John Scudder (Juniper) / Routing Area

Amy Vezza (AMS) / IETF Secretariat

Eric Vyncke (Cisco) / Internet Area

Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS

---------------------------------

Jay Daley / IETF Executive Director

Mirja Kuehlewind (Ericsson) / IAB Chair

Alvaro Retana (Futurewei Technologies) / Routing Area

Martin Vigoureux (Nokia) / Routing Area

OBSERVERS

---------------------------------

Zafar Ali

Karen O'Donoghue

Greg Wood

1.2 Bash the agenda

Amy: Does anyone have anything new to add to today’s agenda? Any other changes?

1.3 Approval of the minutes of past telechats

Amy: Is there any objection to approving the minutes of the May 20
teleconference? Hearing no objection. I also saw updated narrative minutes from
May 20; any objection to those being approved? Hearing no objection there
either.

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: I haven’t touched it since last time. I’ll try to get this wrapped up;
I don't think I need to wait for the next telechat, I can just last-call it to
the IESG when it’s ready. I hope to do that very soon.

     o Warren Kumari, Deborah Brungard, Stephen Farrell, and Jay Daley to

       investigate ways to recruit, recognize, and retain volunteers in the

       IETF.

Warren: I’m not sure if that’s still in progress; I will email people and try
to find out what we’re doing with it.

     o Alvaro Retana and Martin Vigoureux to draft a note to wgchairs

       asking them to always confirm author/contributor status.

     o Alvaro Retana and Martin Vigoureux to draft text to include in the

       I-D submission tool warning about too many authors.

Amy: Neither Alvaro or Martin V are here so we will keep these in progress for
them.

     o John Scudder and Martin Duke to review the document shepherd

       templates and propose changes to include updated questions and

       cross-area checks.

John: We can call this in progress.

     o Rob Wilton to draft text to expand the document shepherd write-up

       section on use of YANG Models.

Rob: In progress.

     o Zahed Sarker and Michelle Cotton to draft text for prospective

       Designated Experts on the basics of the IANA request process and

       "how to be a designated expert."

Zahed: Michelle and I have exchanged some emails. She will produce some text
and start the process and hopefully it will be something within a week.

     o Michelle Cotton to add conflict of interest text to the introductory

       email sent to new Designated Experts.

Michelle: That is done. We added a paragraph of text to make sure the experts
know that if they do have any type of conflict of interest we have the option
to go to the ADs to assist with review. The text was added and we’re using it
from now on.

     o Rob Wilton to follow up with the IESG on small group project

       assignments regarding topics identified through the poll taken at

       the IESG retreat.

Rob: This is sort of done, but please keep it open. I didn't have a chance to
follow this up at the last informal.

     o Martin Duke to draft a proposal for 360 degree reviews of the IESG

       Members.

Amy: This is on [the agenda] as a management item to discuss the text that has
been produced so we’ll mark it provisionally done based on the discussion we’ll
have later.

     o Eric Vyncke and Francesca Palombini to draft text for guidelines/

       best practices for directorate reviewers.

Eric V: We’ve only had our first meeting on this and still have a couple of
action items to move forward. Work in progress.

     o The IESG to report on the RFC 8989 experiment.

Amy: I’ve seen some discussion of this on the email list; is there more to do
here? [Silence] Well we’ll keep this in progress for you and hopefully it will
come to a conclusion.

     o Warren Kumari to find designated experts for RFC 8995 [IANA

       #1198192]

Warren: I took this document over from Ignas and I don’t really know anybody
who might be a good designated expert. Perhaps I can hand this to Rob? Or does
anybody have any good suggestions? I can just use the authors, I guess; Brian
Carpenter was one of them.

Eric V: You may want to add Ignas?

Warren: He wasn’t an author. Oh, it’s MIchael Richardson.

Amy: I think IANA suggested Michael Richardson but you have to confirm with him
if he’s willing to serve.

Ben: I think Toerless also spent a lot of time going back and forth with me on
that document so if you need more than one you might consider him as well.

Warren: Okay, you can keep me on the hook and I’ll talk to both of them.

     o Zahed Sarker to find designated experts for RFC-ietf-dtn-bpsec [IANA

       #1198662]

Zahed: I’ve just gotten confirmation from the candidates that they are willing
to serve so I’ll add it to the next telechat.

Amy: If you have names and they’ve agreed, when we get to management issue 6.4
we can go ahead and approve them. You can put the names of the experts in chat
so we can pick them up from there.

     o Erik Kline to find designated experts for RFC 9031 [IANA #1198928].

Amy: This is a new action item for Erik K.

2. Protocol actions

2.1 WG submissions

2.1.1 New items

 o draft-ietf-6man-spring-srv6-oam-11  - IETF stream

   Operations, Administration, and Maintenance (OAM) in Segment

   Routing Networks with IPv6 Data plane (SRv6) (Proposed Standard)

   Token: Erik Kline

Amy: I have a number of Discusses in the tracker; do we need to discuss any of
those today?

Erik K: I think we should, if that's okay. Zafar has been replying to many
peoples’ points. I did not see a reply to John’s request to split the document
so I was wondering if we should discuss splitting the document or not. I don’t
know what people want to do, whether or not adding two months to split the
document and go through Last Calls and come back…

John: I’m certainly prepared to be in the rough on that, but I thought it
should be discussed. I don’t know if anybody else had the same impression that
this was really two documents that are uncomfortably stuck together in one.

Rob: I put some comments in a No Objection ballot this morning. I do have some
sympathy with you in terms of being two separate things, but at the same time I
thought having the OAM stuff together seemed nice. I wondered whether another
alternative is just to try and make it clearer in the document what text is
normative, defining new stuff, and what text is illustrative, giving examples
of how existing functionality works.

John: I think that would be helpful. Especially since eit looked to me like
it’s rough enough that it needs to, I don't know if it needs to literally be
sent back to the WG or not, but it needs another pretty thorough editing pass.
It seems like they could do one or the other of those pieces of work at the
same time.

Erik K: There are certainly a bunch of comments about the general quality of
the text, and insofar as we know fine to some. If it goes back to 6man, I don't
know that it will get the same review as spring. We could CC spring to make
sure they’re looking at it. I’m not sure what happened for this Last Call, if
anyone notified spring or not. I should have looked that up.

John: I would be good with either outcome I suggested or the thing Rob
suggested. Like I said, I’m also prepared to be in the rough, I just wanted to
make sure we talked about it.

Roman: I’ll say your observation makes total sense, John. I think this is a
question of what’s the effort to split it to get that outcome, and is the juice
worth that squeeze?

John: I guess the next thing would be to see what the authors say.

Erik K: I don’t see that he’s responded to you on this particular point, or
responded to your Discuss at all. I don’t know if you received anything unicast
or not.

John: I have not.

Erik K: I can send an email to the author and we can discuss what they’d like
to do.

Rob: I think the author is on the call.

Zafar Ali: Yes, I’m on the call. Hi. I tend to agree with what Rob mentioned
that it’s better to have one place where people can see the OAM mechanism. This
draft has been structured like this since the beginning. It’s what spring and
6man are trying to work, it was presented and worked with both working groups
copied every time. It’s already been reviewed. I think it would take a lot of
effort to go back to the WG and I personally do not feel that effort would be
worth the pain. We can restructure the document, so that it is easier to read,
so I’m all for that. Some restructuring can do the job and we are fully
committed to doing that. Would that work for you, John?

John: Yeah, as I’ve mentioned, that would be a fine resolution.

Zafar: Thank you very much.

Eric V: And by the way Roman, if you don’t mind, about your suggested text for
privacy. Every router has got a way to do spanning, right? A service provider
by law has to have a lawful intercept as well. So why is it that this is
different? It’s not APN, right?

Warren: With this it feels like you can target stuff to be monitored or not.
There’s a difference between taking all the traffic that goes through the box
and setting this particular flag for certain types of traffic, like Facebook.

Eric V: When people are doing a lawful intercept, they do it for a specific
subject, right? They do it for addresses. So I guess they do something based on
ACL. I don't see a big difference, but I don't mind.

Warren: It also feels like because this is eventually going to end up coming
out of hosts, you could end up with this being set per application as well.

Eric V: This is into the SRH, right?

Warren: You know people are going to extend SRH into data centers.

Eric V: But then you can do it as well for specific code points, or whatever.
We can restart the APN discussion ehre.

Warren: This is really similar to APN; you could do it in other marking bits or
tunnel certain sets of things through. This is another way. We had all the
discussion about spin bit and that was wildly difficult because they're kind of
similar.

Eric V: But it’s not limited enough because if you don’t use this you won’t get
interception, right? That was my point.

Roman: That’s why I framed the text that this seems like a dual use technology.
There’s a ton of very helpful applicability to run your network, to do security
operations, and the rest, but it could potentially be flipped around to be used
for surveillance without consent of users above and beyond even lawful
intercept. I just wanted to make sure that was called out and I think I
proposed some text to that effect.

Zafar: Roman, I responded to you in the last thirty minutes. We’ll take part of
the text you have. There’s some clarification also sent to you that the copy of
the packet is also sent to a local OAM process at the box, and then the local
OAM process then manages it just like IPFIX does. So I hope this clarification
will help but we’re totally committed to addressing your comment.

Roman: Perfect. I think that’s a quite helpful clarification. The way i framed
the text in the comment it still does apply, because even if you have the local
OAM process, and maybe I’m misunderstanding, there’s some notion of then
centralizing it after you’ve done the local processing, and I believe my
comment was largely targeted saying whatever are the security properties of the
thing you’re using to send it to the centralization, they may be very good,
they may provide almost nothing, and you may or may not be able to watch
depending on the properties of that channel.

Zafar: That sounds good. I think Roman, we will take your suggested text as
well. Thank you.

Roman: Perfect, thanks.

Erik K: And I guess we’ll continue to respond to all the points raised so far
in future edits. If after all of that John still wants to split the document we
can discuss it again at that time.

John: I think we have a verbal agreement to follow a different route, but let’s
see what the final product is of course.

Erik K: Hopefully addressing all the comments and making clarifications as
requested will be okay, but we’ll reevaluate when we get there. Any other
important things to discuss? I think this is all addressable.

Amy: It sounds like this will stay in IESG Evaluation and go into Revised ID
Needed.

 o draft-ietf-dots-rfc8782-bis-07  - IETF stream

   Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal

   Channel Specification (Proposed Standard)

   Token: Benjamin Kaduk

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

Ben: The authors put out a new rev this morning, so in theory it addresses all
the comments but i did not get a chance to take a look yet. Let’s leave this in
AD Followup and I'll drop you a note once I have looked at it.

Amy: Approved, Announcement to be sent, AD Followup. There is a downref, to add
RFC 7918 to the downref registry; do we need to do that?

Ben: I think it would be okay to do that. Does anybody else have a thought
about that?

Amy: Sounds like not. We will add that downref to the downref registry on
approval of the document.

 o draft-ietf-ntp-port-randomization-06  - IETF stream

   Port Randomization in the Network Time Protocol Version 4 (Proposed

   Standard)

   Token: Erik Kline

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

Erik K: The author is still producing new versions to address the comments, I
think.

Amy: So it sounds like it’s approved but it needs to wait until that’s all
finished. Do you want it to be Revised ID or AD Followup?

Erik K: Revised ID.

Amy: Okay, Approved, Announcement to be Sent, Revised ID Needed. Thank you.

 o draft-ietf-payload-vp9-13  - IETF stream

   RTP Payload Format for VP9 Video (Proposed Standard)

   Token: Murray Kucherawy

Amy: I have a number of Discusses here, do we need to discuss any of those?

Murray: I think Lars wanted to talk about his. The other ones I don’t need to
cover here, I have to wait for the authors to get back.

Amy: Lars has not yet joined us.

Murray: I guess we can take a couple minutes. The question Lars raised is that
there’s a downref to a document that [has] a Google API URL. I've never seen a
downref to an external document that’s just some other document before;
normally they’re RFCs at lower status. Something that’s external and doesn’t
necessarily have such a status, this is the first time I’ve ever run into a
case where there’s a downref of this nature. Do we basically handle things that
aren’t from other standards bodies as if they were informational and deal with
them that way? Is that what I should have gotten from this?

Roman: To clarify, didn’t we have this exact same situation with that NETMOD
document about geolocation as well? I was wondering what we do there, too.

Murray: It’s more that I was caught by surprise that there even is a practice
around this, and it’s something I should learn. I'll go back and look at the
NETMOD thing.

Roman: The only reason I ask is that I’m holding a Discuss that looks very
similar to Lars’s on the other document, and it would be great if we
consistently thought it through.

Murray: I agree. If necessary, the things that talk about downrefs in general,
RFC 3967 and an update to that, are very good at describing different maturity
levels of SDOs but how do you treat something that's just somebody’s document,
a PDF out there?

Warren: I’m a little confused about why we would view things like this as a
downref. We have the view that if you have a standards track document and it
refers to an informational document, that’s a downref and we note that in the
IETF Last Call. I don’t really understand what the purpose of doing something
like a Last Call on this is to say there’s an external thing that’s referenced.
What do we think the community is going to learn or take away from that? If
this is something that people need to review and understand to implement the
document, it should be normative. I don't see how it has a rating or stance or
something. If it’s something you need to understand in order to do it, it’s
normative, if not, it’s informational, but there’s no upref/downref because it
doesn’t have a status.

Murray: Right. That’s part of the question. The reason we do it this way for
RFCs is because an informational document is not as mature, theoretically, as a
standards track document, and for something that doesn’t have that status, we
don’t want to make the conclusion that it has any particular maturity status.
This should have been called out to someone that we don’t know how mature this
thing that is a normative reference to this standards track document is, so the
community should be clear that they accept that external thing as having the
equivalent of standards track status.

Warren: What I don’t understand is what do we expect “Mary” to do when she sees
a Last Call come across a list of things that says there’s a downref in the
standards track document? Do we think Mary will now read the document and she
wouldn’t have otherwise? Other than dotting the i and crossing the t, what
behavior do we think we’re going to realistically invoke from people?

Murray: I don’t think it speaks to the quality of the document we’re reviewing,
I think it speaks to the maturity level of something upon which it depends. You
can have a standards track document with a normative ref to the outside and it
might be legitimately a normative reference, but if that external document is
in terrible shape then what does that say about the document we’re processing?

Warren: Do we then end up in a situation where the IETF says this IEEE document
we think is kind of [bad] so we’re not willing to do it as normative? We think
your outside SDO document is useless so it can only be as good as informative?
That feels like dangerous territory we’re walking into there.

Murray: I think that’s why the whole downref thing was created in the first
place; that had happened a couple of times and there needed to be a process to
manage it. That’s what we’re working our way through.

Warren: it marks sense kind of for standards track referring to informational
kind of only sort of, but I also don't entirely get that because the way the
IETF works now, most documents don’t get real outside review during IETF Last
Call and I don't think this is a useful signal to anyone. I think it just adds
to clutter and is going to make it less likely that people will review
documents in depth.

Martin D: Any downref is implicitly taking a document that has not reached
consensus as a standard and essentially elevating it to that level, at least in
part. It is a bit bureaucratic and I don't know if people are going to read
this 100something page document, but it does give people the opportunity to
recognize that we are taking this thing that hasn't reached IETF consensus and
making it part of a standard.

Murray: I’m not really concerned about the other two Discusses, it’s just this
one that seems like a procedural point. The easy way out of this is to re-Last
Call that downref and deal with it. By that point the other two Discusses will
have been resolved anyway. I think that’s fine, but I also think we should
probably consider cracking open whatever 3967-bis-bis would be to talk about
external documents that don't come from any SDO just to provide some guidance
around this. I read 3967 and the other one this morning and that wasn’t very
clear.

Ben: I think what 3967 and update actually say is not necessarily consistent
with what we’ve been doing in practice in recent years.

Murray: Which is interesting, because the second document was only published
four years ago.

Ben: If I recall correctly, which i might not, that was intended to give us a
bit more of an escape valve and say you don’t have to run the Last Call again
if you messed up here.

Murray: That’s true, that’s what the second one says. I don't want to take up
too much more time. Do we want to do the Last Call here? I confess I haven't
gone deeply into the referenced document. We can do that or we can decide this
is fine and we’ll proceed.

Ben: My recollection is that Lars had followed up for this particular case and
noticed the document has been around unchanged for several years and this is
clearly the right reference for VP9 itself. So i think he was just leaving the
Discuss point on to formally have the IESG approve it today and not necessarily
to have the broader conversation. I think the broader conversation is still
good, and as you say we may want to revisit the 3967.

Roman: In my opinion this is the reference, there’s no other reference to point
to. We’re not going to gain anything from going back to the community. And I
would say ditto on the NETMOD document i keep referencing too, I think we just
decide that we’re okay with it per the process.

Murray: Okay. Does anyone object to me doing this: I’ll add these two comments
to my Yes ballot, just so that there's a reference this happened, and go back
to Lars and when he clears we can deal with the other Discusses as usual.
That’s how we can record the IESG approval of this.

Zahed: Lars is joining later, right? Can we come back to this one? I’d like to
hear what he thinks. It’s not that clear whether he’s complaining about it.

Murray: If we want to defer to later in the telechat, that’s fine. I’ll do what
I said if he manages not to join.

Zahed: I think what you said makes a lot of sense to do, but i was just
thinking if Lars is coming back we can just check that with him.

Murray: Is that okay with you Amy if we come back to this?

Amy: Yes, we’re expecting Lars within the next twenty minutes. It sounds like
this is going to require a Revised ID anyway, so let’s put a pin in this and
move on temporarily.

[Later, after Lars has joined the call]

Amy: Do we want to come back to this document?

Murray: We’ve already resolved everything in chat. But we should do it on the
record. So I filled Lars in on what we’d been talking about and the two
actions; one was just to have the IESG formally approve this because it wasn’t
in the Last Call, and I think that’s where the IESG landed anyway. The second
part is that we don't’ have any good guidance about how to handle non-SDO
external references like this one, so I'll take up a document to amend our
current downref policies to at least provide some informational guidance about
how to deal with those, because we don’t have any.

Lars: I think it’s overdue. We’re hitting this again and again with these
references to other stuff that we want to make normative but we can’t because
of the rules.

Murray: I’ll put the summary of how we’re handling this specific case in my Yes
ballot.

Lars: I’ll clear my Discuss.

Murray: There are two other Discusses so this isn’t going anywhere immediately
anyway. I guess we can add an action item, and I’ll give Amy wording for the
action item to start tracking it.

 o draft-ietf-core-senml-versions-03  - IETF stream

   SenML Features and Versions (Proposed Standard)

   Token: Francesca Palombini

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

Francesca: Thank you all for the comments. This will require a revised ID.

Martin D: I didn’t get a reply on my comment. It wasn’t a big one, just
something to the effect that you’re burning the zero in two code points as
reserved and it’s a very constrained code space. Certainly not Discuss-able but
i just kind of wondered why they made that decision with how few code points
there are.

Francesca: I’ll make sure Carsten replies to all the comments before he pushes
the new version. Thank you.

Amy: Okay, this is Approved, Revised ID Needed.

 o draft-ietf-dnsop-iana-class-type-yang-03  - IETF stream

   YANG Types for DNS Classes and Resource Record Types (Proposed

   Standard)

   Token: Warren Kumari

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

Warren: Yes please. I’ve read through Rob’s Discuss and also the author’s
response and I'm not entirely sure I understand what’s going on. Hopefully Rob
and I and the author can talk after and figure out how the whole obsolete
deprecated mapping should work with Yang.

Rob: Warren, I think that makes sense. The problem here is there’s not a great
relationship. Whichever way you go is not perfect; I wonder if mapping
deprecated to deprecated is closer, or safer, than mapping deprecated to
obsolete. Specifically my concern is with the way Yang is evolving it’s likely
stuff that’s marked as obsolete gets to the point where you can’t use it. That
feels quite strong, so that’s my concern. Happy to discuss it with you offline
and with the author.

Warren: Excellent, thank you. Francesca?

Francesca: Yes. I'd also like to get Michelle’s comment about this because it's
IANA related. To recap, the document basically defines a procedure for IANA to
update this sheet. I was wondering if it wouldn’t make more sense that the
designated experts for the registries are tasked to do that, or at least they
are consulted. IANA would check with them before that is updated.

Michelle: We’re always happy to check with the experts.

Francesca: This is more than the usual registration, adding an element, etc. I
would like to give less work to IANA.

Michelle: It’s a little bit more intense if I recall correctly, this is
updating the Yang module in using a script.

Warren: One concern is there are some cases where we’ve often had almost
disagreements, I guess, between the IESG and the designated experts. I don’t
think any of them were like DNS, but we’ve had some controversy about things
like the ports registry. Also I don't know how quickly we always get responses
from designated experts. Is the plan that any time there’s a change to a
registry one pokes the DEs?

Francesca: I checked the registry policies and most, if not all of these, are
the experts will need to be checked anyway.

Michelle: That's what I was just looking at, double checking to see what the
registration procedures are. If it’s specification required or expert review,
we’re going to go to them anyway. The only ones with first come first serve are
the only registry where we wouldn't necessarily check in with them.

Warren: So for specification required you’re currently checking with the
designated experts anyway?

Michelle: That's correct.

Warren: Okay, in that case I don’t care.

Zahed: I looked into the IANA registration and my thinking was that in this
document it’s saying hey IANA, this registry to that RFC, and that RFC has a
procedure on how do you update IANA registration. I thought that is fine,
that’s not an implicit procedure. I will not just take this document and add it.

Francesca: But the difference is that, right now as it's defined, IANA would
ask the expert does this registration make sense, the expert would say yes, and
then IANA would have the task of updating the Yang module with whatever
parameters were added to the registry. I’m saying, why not give that task to
the experts, or at least for the experts to check that the update is consistent
with whatever is added to the registry?

Rob: I don’t know if you’ve been monitoring the chat but there are a couple of
other IANA-maintained registries that auto-generate Yang modules, and IANA
looks after those. It’s the iana-if-types.yang, and the BGP AFI/SAFI ones. I
don’t think this is necessarily pushing this outside IANA’s bounds of what they
already do today. You could check with those experts but you could also check
with the Yang Doctors. I don’t know whether it’s required though, because
ideally these should look exactly the same between the two with instructions.
Maybe it’s only worth checking if there’s any ambiguity between the two.

Francesca: But if this is already done, if there are other examples it makes
more sense to have it this way.

Michelle: If the registration procedures have us ask an expert, we do that.
Regardless of what the registration procedures are, if we have questions or
we’re questioning a registration coming to us, we would ask either in the case
of the Yang modules we’d ask the Doctors, or we’d end up coming to any of you
as the AD to further consult. I think we’re okay on this, and as Rob pointed
out we do maintain a bunch of other modules that we update and i think we’re
okay on it.

Francesca: Okay, thank you for the discussion. So I will clear my Discuss.

Warren: Thanks for the discussion, I think this was useful.

Amy: So it sounds like this is going to require a Revised ID, is that right?

Warren: Yes.

Amy: Okay, so this will stay in IESG Evaluation, Revised ID Needed.

2.1.2 Returning items

 o draft-ietf-ippm-capacity-metric-method-11  - IETF stream

   Metrics and Methods for One-way IP Capacity (Proposed Standard)

   Token: Martin Duke

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

Martin D: The authors did release a new draft this morning which I haven't had
a chance to scrub for comments but it sounds like things have gone pretty well.
Thanks to the authors for that. I think Eric V had a comment that landed after
that draft so I’ll just follow up and make sure that they’ve answered your
question and see if any changes need to be made. We can call this Approved,
Announcement to be Sent, AD Followup.

Amy: I also have a couple of downrefs, do these need to be added to the
registry? It’s RFC 8468 and RFC 7497.

Martin D: There were two? I thought there was just the one.

Amy: They’re both Informational.

Martin D: We waived one of them last time, right? I think 7497, if I’m not
mistaken. It’s on our last agenda.

Amy: I think we’ve got notes on this so we’ll look that up. If they’re unclear
we’ll get back to you.

Martin D: The issue was it came up to the IESG, Magnnus had a Discuss, to
address the Discuss we added a normative reference to an informational draft,
and so that’s why it slipped through the cracks. The second one is news to me
and I’m not really sure what happened there.

Amy: We know one doesn’t need to be added to the downref registry. We’ll look
at the notes and if we have any questions we’ll get back to you.

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

 NONE

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD

3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes

3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents

3.4.1 New items

 o conflict-review-camwinget-tls-ts13-macciphersuites-00

   IETF conflict review for draft-camwinget-tls-ts13-macciphersuites

     draft-camwinget-tls-ts13-macciphersuites-11

     TLS 1.3 Authentication and Integrity only Cipher Suites (ISE:

   Informational)

   Token: Benjamin Kaduk

Amy: I have no Discusses in the tracker for this conflict review, so unless
there’s an objection now, this is approved to go back to the ISE. I’m hearing
no objections, so it looks like this is good to go.

 o conflict-review-dukhovni-tls-dnssec-chain-00

   IETF conflict review for draft-dukhovni-tls-dnssec-chain

     draft-dukhovni-tls-dnssec-chain-06

     TLS DNSSEC Chain Extension (ISE: Experimental)

   Token: Benjamin Kaduk

AMY: I have no Discusses in the tracker for this conflict review, so unless
there’s an objection now, this is approved to go back to the ISE.

Eric V: Ben, can we say it’s related to work done in TLS and DPRIVE, even if
it’s marginal to DPRIVE?

Ben: Yeah, that would be fine with me.

Eric V: Simply to be complete.

Warren: I didn’t want to comment in the email but I do kind of remember this
being discussed a bunch in DPRIVE. I don’t know if it was officially presented
but it was discussed and reviewed.

Ben: I’m editing the text right now.

Warren: Quick question; does changing that review text invalidate all of the
ballots?

Amy: No. It’s just the text that will go in the announcement.

Warren: Okay, good.

Amy: So with the text that’s just been updated to include DPRIVE, I’m hearing
no objection to approving this, so it will go back to the ISE.

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

 NONE

4.2 WG rechartering

4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Amy: We don’t have Martin or Mirja here, so Lars, any news we can use?

Lars: A lot of the call was spent discussing the planned workshop on
measurement of access networks, specifically with the goal of quantifying the
goodness of user experience. This is driven by Stuart Cheshire and some other
folks and I think this workshop is going forward. There’s some discussion of
when it will be, and I think it will be sometime in September and there should
be a call for papers out soon. This is the usual IAB style thing. There’s a
little bit of a push to get this done soon because Stuart has mentioned the
workshop in his Apple developer keynote, which will go live Friday. By Friday
there will also be an IAB webpage on this. There were two other topics we
punted; Karen gave an update on EMODIR that was helpful. It’s still mostly in
transition and there’s not a whole lot more to say about that. It’s been one of
my ongoing action items to understand better what the Edu Team / EMODIR are
doing and who’s responsible for what. There’s a whole lot of un-clarity and I’m
hoping when Joey Salazar takes over it will bring some additional clarity.

6. Management issues

6.1 AD 360 review (Martin Duke)

Warren: A couple of weeks ago I sent email to all of my chairs asking for
feedback, not using this text, but just that I’d love to know what I’m doing
well and what I’m not. I got very few responses and the ones I did get were all
that I’m doing an awesome job, we love you, which I’m sure is not true. I don’t
know if that means anything for what sort of feedback and review we’re going to
get from a 360 type thing. I hope that doesn’t bode poorly for the quality of
feedback we’re going to get.

Roman: Isn’t the feedback in a 360 review typically anonymized in an aggregate?

Warren: My point is, it’s a fairly small population that we're doing the
reviews across. Especially in some areas which are smaller than others. Keeping
the review properly anonymous is going to be tricky. I think we should do it, I
just hope we get good quality feedback. The only sort of actionable feedback I
got is that one of my WGs would like me to be more involved and show up to
chair meetings, so there was some.

Marin D: To summarize the feedback [on the proposed document], there was a lot
of wordsmithing which is fine, and some new questions. The subject for
discussion is really how broadly we want to distribute this. The original draft
had authors and shepherds of Internet-Drafts that have gone into review. So if
you had a draft that went in front of IESG review you’d get surveys for all the
ADs because they’d all in theory reviewed the document. Lars suggested that we
shrink that down to shepherds, and then limit it to the actual AD reviewed
documents rather than getting all these ballots. You see what’s right now in
the document, and I don't know if we want to have a conversation about how
broadly to distribute this. Warren makes some good points about shrinking the
population down and anonymity. There's a tradeoff between survey fatigue and
getting a lot of data.

Lars: For this trial I’d rather keep this small, rather than spamming half the
community with multiple survey links.

Zahed: I think we should keep it small. I have another point; I tend to do
surveys when I know the results. I do a survey and then I expect to be notified
about the results. But I don’t see anything about sharing the survey results
with the respondents. I’m feeling a bit like maybe there are more people like
me who won’t be very interested in doing the survey if they don’t see the
results back. I understand anonymity is a problem.

Martin D: Not so much anonymity, but the idea that these are confidential
results that are not considered Nomcom inputs, etc. Would it scratch your itch,
Zahed, if we published the cumulative IESG results?

Zahed: Any sort. My point is that any kind of information that did leave the
survey or a gist of the results would be helpful.

Ben: Sometimes you can see cases where the histograms from the numerical
answers are public but the freeform text is not. I don’t know if that would
make sense in this case.

Zahed: Those kind of things we could do.

Warren: My concern is if we start displaying some of the histograms or stuff,
we end up causing people to optimize toward making things look better. I now
have an incentive that the people who provide feedback are my chairs, so every
time a document comes out of my WG I should just say yay chairs, you’re
awesome, let me move this forward, whereas what’s probably more useful is for
me to do deep review and push back on things, which makes me less popular with
my chairs, which makes my scores go down. I’m worried we potentially create
false incentives for people.

Zahed: That you can do without sharing. The idea is that my review is only
private to me, like Martin cannot see mine?

Warren: If we share this with the community or with the WG Chairs or something,
they look and see “Everybody likes Ben more than they like Warren, because
Warren does stricter reviews and is grumpier.” Now I have an incentive to be
nicer to chairs and just progress their documents without reviewing them.

Zahed: I get it. But my point was that as the IESG, if we summarize all these
questions as the IESG how we are doing, not really per AD or no granularity.
We’ll have to summarize this on a very high level, how this IESG is doing. That
could be shared without pushing to Ben vs Zahed.

Lars: The only thing I can see us sharing here is something that’s rolled up to
the entire IESG as a body. That might work, but it’s only really useful if
we’re doing it again so we can see what the trajectory is. That we can
certainly do. The idea initially was that the feedback goes to the individual
ADs. We had an open question, and I can’t remember if we settled it, about
whether the IESG Chair should see all the information and be able to have a
global view. I don’t really care.

Martin D: We didn't really settle on having a person who is knowledgeable about
the IESG seeing all the feedback, but there will be an IESG summary so that you
can compare yourself to the average. So everyone is doing great on AD reviews
except me, for example. There’s some normalization there and we can include
that as some of the feedback and discuss it as an IESG collectively if we have
a problem with something. The idea you’re referring to, Lars, is that someone
would see the individual feedback for each person and identify trends like the
survey population is biased toward European ADs, or something like that you can
only see with all the data. I don’t necessarily see that we agreed to do that
at all. Whoever it is that collates the data is going to have an IESG summary
and then the individual reports get given to the individual ADs.

Roman: I love the idea of doing the 360 reviews, I would just encourage us to
be a little bit less ambitious. We’re talking a lot about pipeline management,
transparency--all those things could happen down the road but right now we have
nothing. I feel like it would be a great improvement just if the ADs got some
feedback. Where that goes later, what are the trends, of course we want to do
that, but let’s just successfully try a run at it once and then we can figure
out how to do this repeatedly and share and compare.

Zahed: Roman, I share your feelings. I also have this thought that you’ve been
here for quite a long time but not me. The data points people have with you
compared to me is almost nothing. They haven’t seen me for a year. This doesn’t
make much sense for me to run it.

Lars: It might not give you a very strong indication, so then you ignore it and
wait until next time around.

Zahed: If we start to do this kind of feedback then I hope we’re planning to do
it more and more.

Lars: I think the idea would be to do this yearly at least. Maybe what we'll
learn is that for first time or incoming ADs the feedback isn’t very useful in
their first year, and then we can decide if we might not want to do it. But I
lean towards just including everybody. I think you’re going to get some
feedback that will be mildly useful.

Zahed: When I read this as ‘year’ I thought it was when my first year was
finished.

Lars: We don’t need to decide now whether we want to make something public to
the community in some form. We can analyze the data and see if there’s anything
of interest to the broader community and do it after the fact.

Warren: Something i think would also be really useful, and this is maybe scope
creep. The people who most know how we’re doing is not really our chairs, it’s
also each other. I’d love it if IESG people could provide me some feedback on
what I’m doing well, what I'm doing badly, etc.

Martin D: That’s in here. I’m going to highlight here the current distribution
list, of who gets a ballot. We’ve talked about this and there’s a little
difference of opinion, but can we agree on it?

Lars: I still think this is too many people. If you just do the math for
shepherds of drafts, that means that every draft that went to ballot in the
last twelve months will get a ballot for the AD.

Martin D: The responsible AD.

Lars: Either my math is wrong or there’s going to be hundreds of these.

Warren: Your math is wrong, because most of them are done by chairs.

Lars: But it still means that all the chairs get basically one for each AD,
because each AD usually ballots.

Martin D: We’re not doing IESG review as a threshold. It’s shepherds who get
the survey for the responsible AD.

Lars: Okay. So the second and the third bullet are basically almost the same.

Martin D: Given that shepherds are usually WG chairs, basically all your chairs
are going to get a ballot for you and for no one else, and then the I* people
and the secretariat will get a mountain of surveys.

Warren: What if we just send it to WG chairs and see what they say? If all of
them say ‘this was useless because you didn't’ ask question X’ we can then
update it and send it to a wider group?

Lars: That’s a good suggestion. Asking the WG chairs, would this survey allow
you to give the feedback you want to give the ADs? Or if not, what would you
change? That would be useful before doing it.

Warren: Or even after we look at the results we realize we’re missing something.

Lars: We can have the questions as what Martin is writing now, and next time we
can iterate. Maybe also ask if a question is useless or they didn’t know how to
answer it.

Martin D: The second, third, and fourth bullets are essentially going to
collapse on the WG Chairs. We can simplify this by just making it chairs, which
maybe eliminates a bit of staff work. Do we think shepherds who are not chairs
are a significant population we’d like to catch?

Francesca: I’d like to keep those. There are not that many and I think it’s
good we can involve shepherds who are not chairs.

Martin D: Okay, so if you are a chair of a single WG or a shepherd that
operates in a single WG you will get one survey for one AD, and the
secretariat, IESG, LLC, IAB will get fourteen surveys. Sounds like everyone can
live with that? Okay. The other item is in the cover letter, there’s this
anonymity promise and will not be shared by Nomcom promise. I do think we
should clarify how this is being used, because it will probably affect how
things are answered. Unfortunately I do think we need to nail down what we’re
going to make public. I could live with an IESG-wide aggregate of the results,
if people really want to do that, but I don’t feel strongly about it. I think
we should write it down in the intro letter if that’s what’s going to happen.

Lars: We could say that we’re considering publishing an IESG-level aggregate of
the results. Then I would tweak it and say the detailed results will not be
shared with the Nomcom, because that [aggregate] would be shared with nomcom
implicitly because they’re in the community.

Zahed: This would work for me.

Roman: I didn’t follow, what does it mean to share with the Nomcom?

Martin D: What we wanted to make clear is that Martin Duke’s survey results are
not going to the Nomcom as input to their process.

Warren: Why not?

Martin D: Because this is a pilot, we’re not really sure what’s going to come
out of this. Also the intent is to get honest, constructive feedback, and if
negative feedback can get this guy fired, it may not create that dynamic.

Warren: To me it always seems like Nomcom has a really hard time getting
feedback about people. If all of my WG chairs think I’m a complete waste of
time and space, I think that would be useful for Nomcom to know.

Eric V: But then your chairs would tell the Nomcom, no? If you’re really bad
they will tell.

Warren: It feels much more like they’re stabbing me in the back if they go to
the Nomcom, whereas if they just fill out the survey….

Lars: If the Nomcom wanted this kind of information they can ask for it. I
would be concerned with giving them all the data, I could see some Nomcoms
going “okay who’s the best AD?” according to these metrics. If there’s data
that’s a bit more scientific looking than what they have, which is just text,
they may weigh it more heavily than they should.

Roman: Depending on how we want to handle it, that suggests a destruction or
retention process around this. The ADs get it, the scores get computed for the
aggregate, and then it disappears. Or is this now going into the HR file?

Martin D: I’ve discussed this with Jay a little bit and I think we'd have the
normal sensitive information procedures we have for this kind of thing. I
haven’t yet nailed down with him who would do the work, whether it would be an
outside contractor, which would have some advantages, or someone from the
secretariat. But it’s not like the secretariat can’t handle sensitive data and
not spill the beans.

Roman: Where I’ve seen this done, using the external vendor is actually viewed
more favorably, not because of the retention but because if you want to get
honest feedback you need to be anonymous, and there was a belief if you use the
external vendor you’ll be more anonymous.

Martin D: Exactly. Jay and I need to work this out; we’ve had a little
conversation about it but not enough. If the IESG has really strong feedback
for one or the other I can communicate that.

Roman: I say third party.

Warren: I don’t really care on that, but I am still wondering about the Nomcom
thing. If I get this feedback and decide to stand again, am I allowed to share
my own feedback with the nomcom?

Martin D: I don't know how we could stop you.

Warren: You could say it's confidential, don’t share it. I just wondered.

Martin D: I do want to say that in the long run I’m not dead set against this
going to the Nomcom, I’m just a little reluctant to do it in this pilot.

Warren: Fair enough.

Lars: One thing we could do is we can have an action item after the Nomcom has
made their selections, to ask if this type of data would have been helpful. We
could anonymize it somehow and have a discussion whether we should share it in
some form in the future. But my overarching principle is we should start this
small.

Martin D: I think I have what I need. Does anyone still need to look at this
document? Then I will assume this is in decent enough shape that I can take
this to Jay. Thanks everyone.

6.2 [IANA #1197181] Renewing early allocations for
draft-ietf-tls-dtls-connection-id (IANA)

Ben: This document is in Approved, Announcement to be Sent, AD Followup, and I
just need to look at the latest I-D that was uploaded. I mostly expect this
document to be with the RFC Editor before the expiration time, but we should
approve the extension just in case.

Amy: Any objection to approving this extension of the early allocation? Hearing
none, so we will send official note to IANA.

6.3 [IANA #1198192] Designated expert for RFC8995 (IANA)

Amy: This was assigned at the top of the call and we know Warren is going to
check with Michael Richardson and Toerless.

Warren: Toerless says yes. Can we approve him for now and add Michael later,
assuming he says yes?

Amy: Yes. Is there any objection to approving Toerless as the designated expert
for this?

Warren: And is there any objection to approving Michael Richardson when he
replies later in the day to say yes?

Amy: Okay, looks like Toerless is approved and Michael is approved pending his
acceptance. Warren, let us know when he replies and we’ll get official note
sent to IANA for both of them.

[A few minutes later: Warren: Michael Richardson said yes.]

6.4 [IANA #1198662] Designated experts for RFC-ietf-dtn-bpsec (IANA)

Amy: Zahed has proposed Ken McKeever and Edward Birrane. Any objection to
approving them as the designated experts? Okay, we’ll send official note to
IANA.

6.5 Changes in AUTH48 to draft-ietf-calext-jscalendar (Francesca Palombini)

Francesca: Ben, I don't know if you saw the last emails. I sent one just before
the telechat. Michael Douglass sent an email five minutes ago so you probably
haven't seen that one.

Ben: I saw it, but haven’t read all of the details.

Francesca: Let me summarize for everyone if someone hasn’t seen this on the
mailing list. I have this draft that was in AUTH48. When I did the last check
before approving for the RFC Editor I realized there were changes that were not
purely editorial. I talked to the chairs and authors and these changes had been
discussed in the WG, but I preferred to run a second IETF Last Call just to be
safe for the process, even though the changes are not major and they all make
sense. I ran the IETF Last CAll and there were no comments. Now the choice is
either to reopen the ballot for everyone to reread the document and ballot
again, or if we could, my preference, I would get an informal no objection from
the IESG. As I said in email, Murray was kind enough to provide a reference
where this was done before, where the document diff was checked, there was no
objection, and it was sent back to the RFC Editor.

Lars: I think when we sent it back to IETF Last Call we do need to run it
through the IESG again as well.

Francesca: There was a previous occasion where Barry had a document and he
didn’t run it through IESG and reopen the ballot. He just got an informal okay.
I can post the link.

Lars: That would be helpful; I had no idea that was an option.

Eric V: Francesca, was the first ballot done by this IESG or a previous one? If
it was done by this IESG we can simply ballot the same, right?

Francesca: The thing I would like to avoid is two more weeks of waiting time.

Lars: So the IESG did vote on it, but informally, and not a ballot. Right? That
I think is okay. But just doing the IETF Last Call and not having the IESG okay
it wouldn't work.

Francesca: Of course. When I started the mail thread this was my way to ask for
the IESG to okay it. After reaction from Ben I also put it on this telechat to
make sure it’s not missed.

Lars: I must have misunderstood what you wanted to do then. What you have in
the email is fine.

Francesca: It was in September of last year so everyone except those of us who
are new this year has already read it.

Eric V: So it’s the previous IESG, basically.

Francesca: Yes. This was Barry’s document. So Ben had some comments about the
diff, which I’ve answered. I think at this point we can continue discussion
offline if you prefer and everybody else, you can also take a look at the diff.
 Everything is in the link in the IESG Agenda for today.

Ben: I think I’m okay to keep talking about it offline, we don't need to spend
a lot of time today. The main thing that might have further discussion is about
the ID vs UUID. Fernando has a draft I’m trying to AD sponsor about the
numerical IDs and security considerations. I just think we should make sure
we’ve actually thought through if the server does use a sequential number, does
that leak any information that’s not already available?

Francesca: I did have a question about that from your comment. You said
sequentially assigned integers, and I didn't find anything about the IDs being
sequentially assigned.

Ben: There’s no text about it, but in some of the examples, they were showing
that if the first one is 1, and the second is 2, that sets a precedent for what
you might expect. Given my minimal knowledge of what existing implementations
do…

Francesca: IDs are actually strings, they’re not integers. But it doesn't
matter. I thought the sentence that was removed "Nevertheless, a universally
unique identifier (UUID) is typically a good choice." was not as strong as a
RECOMMENDED recommendation, and the requirements they had still stand, so I
thought this was not a major change.

Ben: I’m looking at some of the examples. In section 6.6 they have an event
with end time zone, and they list two locations in the event and the new
version of the example has the string 1 and string 2 has IDs for the location.

Francesca: Okay, so if that instead of being 1, 2 was 1, 9, or something like
that, would that be better?

Ben: It might. I think we probably shouldn't talk about this right now. I think
we should look at it more closely.

Francesca: That sounds good. Let’s take it offline and I’ll ask my fellow ADs
to please shout in the next two or three days. I’d like to know fairly quickly
if I need to reopen the ballot, which I would rather not do but I’ll do it if I
need to. If I can solve this with Ben by Tuesday next week and I don’t hear
anything else I will move this back to the RFC Editor. Thank you.

6.6 [IANA #1197180] Renewing early allocations for
draft-ietf-bess-evpn-optimized-ir (IANA)

Amy: Martin V is the AD for the document, but he could not join us today. Can
someone speak to this?

Michelle: I’m pretty sure that Martin indicated that this was approved, or that
he was okay with it. Let me double check.

Eric V: I was about to wonder on this. The first allocation is five years ago
and there’s still no specification for it, that’s a little bit weird. Is it
still active?

Michelle: Martin did approve this and the chairs also indicated it should be
approved. I don't know the details of the progression of the document, that
would be a question for Martin. As far as they told us that we should approve
it, it just must be taking a really long time to get through the process.

Eric V: If the chair and Martin are agreed, that's no problem.

Lars: I’d actually suggest we bring this back on in two weeks when Martin can
be here because he’s at the APN interim. I agree with Eric, it’s been five
years and it’s been in WG Last Call since November so I guess there is some
activity.

Michelle: Timing wise, it wouldn't be a problem to bring it back in two weeks.

Ben: Is it in WG Last Call or submitted to the AD?

Lars: It says it’s in WG Last Call, issue raised by WG substrate.

Roman: That does not appear consistent with the history, the history says it’s
in AD Review.

Michelle: It does say AD Evaluation. This particular one looks like it’s moving
along.

Lars: Okay, that’s even better.

Eric V: We can wait until the next telechat just to get confirmation, right?

Lars: If it’s with Martin, I’m okay.

Michelle: This one does look like it’s progressing. So are we going to hold
this for Martin or since we see that it’s moving along and he did approve it in
our ticket, do we approve it? What does everybody feel most comfortable doing?

Ben: I think I’m okay approving it.

Eric V: Slight preference to postpone for two weeks, but I’m okay approving it
as well just to be clear and clean.

Lars: If I look at the Datatracker it’s been in AD Followup for 699 days,
though. Ithink the Datatracker is wrong. It says it was in Revised ID Needed
and AD Followup, and that’s from last July. I don't understand why the thing
says 699 days.

Ben: It’s been in AD Evaluation for 699 days.

Lars: It’s almost been a year in AD Followup so I would bring it back and ask
Martin.

Michelle: Okay, Amy, can you add this to the next call?

Amy: Absolutely; we’ll keep this item on for next time when Martin is hopefully
able to join us.

6.7 [IANA #1198928] Designated experts for RFC9031 (IANA)

Amy: This was assigned to Erik K at the top of the call.

6.8 [IANA #1197184] Renewing early allocations for
draft-ietf-bess-evpn-ipvpn-interworking (IANA)

Amy: This is also Martin V’s document; Michelle, can you speak to this one?

Michelle: This was initially registered in 2019, so it’s a lot newer. The
initial extension was already done so this is now coming to the IESG. Since we
have time on this one, it expires in July, we can move this to the next
telechat also if you’d like.

Lars: That’s good.

Michelle: Amy, let’s move this one to the next telechat as well and we’ll wait
for Martin.

6.9 [IANA #1198995] Management Item: Acceptance of media type registration from
standards organization ISO (IANA)

Michelle: Previously we had registered as an organization that could register
standards org media types a very specific ISO group. This is to consider ISO as
a whole, because we just received a request from a different group within ISO.
This is to see if we can approve ISO as a whole organization that can register
media types.

Ben: I guess I'm surprised it was just a subgroup of ISO before and not the
whole thing. Do you have the particular subgroups handy, the one that’s already
listed and the new one?

Michelle: The current ISO listed is ISO/IEC JTC 1. The new request that came
in, it’s actually multiple requests, ISO/TC 184/SC 4. Does that help?

Ben: It does. The first one is Information Technology, so that’s a fairly broad
scope group in my understanding.

Michelle: Are there any objections to making it so that ISO more broadly is
listed?

[crosstalk]

Warren: ISO feels big and stable enough that I don’t think it’s likely to be
abused if we add all of ISO.

Michelle: The requests will still go through expert review.

Ben: Right.

Roman: But if we haven't’ gotten requests from large parts of ISO, and this is
the first time in a while it’s occurred, why have the default allow?

Warren: Some of it comes down to playing nicely with other SDOs. for every
single thing you want to do we’ll triple check it and make sure that you’re
playing like big boys and girls sounds different than we're both SDOs and we
expect you to be sane.

Lars: We don’t have full liaison status with ISO.  ISO is a big thing with many
different groups and a default accept seems maybe too broad. Can we maybe just
not add that second group? Maybe we should ask the experts for the registry if
they would default accept that other group, or if they think this is a bit odd.
I would go and tell the experts, look, we got this request not from the usual
group in ISO, A is the request ok and B do you think it’s a good idea for us to
default accept from that group in the future?

Michelle: From the specific group, or the whole group?

Lars: Not the whole of ISO, the specific group who sent that new request now.

Michelle: We can do that.

Lars: If the experts say we can’t approve this, that’s probably a signal we
don’t want to have that group in ISO be default accept in the future.

Michelle: I’m looking to see if we have any other communications in that
particular ticket that would help. Question; if we go back to the experts and
we ask them if they’d suggest adding this particular subgroup to the list,
would I have to come back to the IESG?

Lars: Probably you’d have to come back to the IESG. But I suggest we do
whatever the expert says, but it’s still the IESG that needs to make the
decision formally.

Michelle: I will follow up to the IESG mail list after I go through these
tickets. I see some conversation with Ned and Alexey about approving this
particular subgroup. So let me follow up to the IESG list and maybe we can sort
this out over email.

Ben: That sounds like a good start. As Lars says we may formally need to bring
it back to the IESG, we’ll see.

Michelle: The only thing that's not good about that is the request sits for
another two weeks.

Lars: We can do it over email, we don’t have to wait for a telechat.

Michelle: Amy, I think that means we need to bring this to the next telechat
just to minute a decision.

Amy: Yes, and if you need official notification from us, just keep us in the
loop on that email at the end of the discussion.

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

Francesca: I was just reminded about the oblivious-http that was dispatched by
secdispatch and I accepted to pick it up as responsible AD. I haven't started
the chartering process but I plan to do so quickly. I’m considering also adding
it to the Bofs. I want your opinion if that’s too premature. This has been in
discussion for a while and there’s some community support.

Lars: Do you want to ask for a placeholder for 111?

Francesca: I’m considering doing that, yes. I’m sending an email now to the
proponents to see if they want to have a spot there or if they’re okay with an
interim.

Lars: Is the plan to charter this without a Bof?

Francesca: No, chartered without a Bof. It’s had enough discussion and been
dispatched.

Lars: So you basically want a placeholder meeting for 111. If the thing exists
in the datatracker you can make a request for it.

Francesca: It might be that for the next IESG telechat you’ll see this new
placeholder and I don't want you to be surprised.

Lars: I have a quick status update on the email addresses under ietf.org
discussion. I thought the LLC board was okay with the proposed statement we
wanted to send to the community but then Jay rewrote it so we’re still spinning
there. I’m hoping to have that resolved soon, at the very latest I guess it
would resolve next week when the board has their monthly call, but I'm hoping
we can do it beforehand. You’ve also seen the fundraiser is starting next week.
The reason she asked for the term development is apparently that's' the term
that’s used in fundraising circles for development of the fund, or the
endowment. I agree there’s an unfortunate terminology overlap. Maybe we want to
ask her not to assign development@ietf.org now and we can decide on a different
role based email later.

Eric V: You can ask her to suggest another name. Maybe there are others.
Development is too much of an overlap.

Lars: Apparently that’s the term that is used in fundraising. I’ll propose we
give her that personal email address but maybe we will wait on the role based
one. That’s all I had.