Skip to main content

Narrative Minutes interim-2018-iesg-09 2018-05-10 14:00

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


Narrative Minutes of the May 10, 2018 IESG Teleconference

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

1. Administrivia
1.1 Roll call

Ignas Bagdonas (Equinix) /  Operations and Management Area
Deborah Brungard (AT&T) / Routing Area
Ben Campbell (Oracle) / Applications and Real-Time Area
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Spencer Dawkins (Wonder Hamster Internetworking) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Ted Hardie (Google) / IAB Chair
Benjamin Kaduk (Akamai Technologies) / Security Area
Suresh Krishnan (Kaloom) / Internet Area
Warren Kumari (Google) / Operations and Management Area
Terry Manderson (ICANN) / Internet Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alexa Morris (AMS) / IETF Secretariat
Eric Rescorla (Mozilla) / Security Area
Alvaro Retana (Huawei) / Routing Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Jeff Tantsura (Nuage Networks) / IAB Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area

Heather Flanagan / RFC Series Editor
Mirja Kuehlewind (ETH Zurich) / Transport Area
Portia Wenze-Danley (ISOC) / Interim IAD

John Bradley
Mike Jones
Andrei Popov


1.2 Bash the agenda
1.3 Approval of the minutes of past telechats

     o April 19, 2018: Any objections? Hearing none, these will be posted on
     the public archive. o April 5, 2018 Revised Narrative Minutes: No
     objection, those are approved and will be posted. o Narrative Minutes for
     April 19, 2018: There were no changes. With no objections, those are
       approved also.

1.4 List of remaining action items from last telechat


     o Benjamin Kaduk to find a designated expert for RFC 5793 [IANA

Amy: This is a management item later in the agenda so we will call this
provisionally done.

     o Alexey Melnikov to find a designated expert for RFC-irtf-cfrg-xmss-
       hash-based-signatures [IANA #1053888].

Amy: This is also on later in the agenda as a management item so we will pick
that up then.

     o Benjamin Kaduk to ask the designated experts for the AEAD Parameters
       registry to update the registry noting that draft-nir-cfrg-
       rfc7539bis will obsolete RFC 7539.

Benjamin: Alissa and I have tried to get in touch with the expert but it
doesn’t look like the expert has taken any action yet. We continue to attempt
to contact them.

     o Ignas Bagdonas to find a designated expert for RFC 8350 [IANA

Ignas: Two authors have agreed to serve as experts. I have responded to that
email so what is the formal process to get those names through?

Amy: You add it as a management item for general approval from the IESG and it
will come up as a management item. If you send those names in as a ticket now
we can probably get it up on the agenda before the end of the call, and approve
them or not as the IESG will.

Ignas: Okay, will do.

     o Alexey Melnikov to find a designated expert for RFC 8323 [IANA

Alexey: I became aware of this today so this is in process.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-tokbind-https-14  - IETF stream
   Token Binding over HTTP (Proposed Standard)
   Token: Eric Rescorla

Amy: I have an open position here for Martin, did you want to state a position
on anything that might be open?

Martin: I don’t have any objection on my side, sorry.

Amy: I currently have a couple of Discusses in the tracker for this, do we need
to discuss those today?

EKR: To be honest, I found the text Ben is citing impenetrable as well. I think
we may have some of the authors on this call, maybe they can speak up and
explain what this means. John, are you here? No? Okay. Ben, I assume if this is
clarified you’d be happy—it’s that you don’t understand it, not because there’s
something majorly substantively wrong?

Ben: I’d be surprised if they came up with an answer to clarify and I wasn’t
okay with it. It’s not that big a piece of the overall draft.

EKR: I’ll take the action item to get that done. Alissa raised this point about
eTLD+1. I was expecting to look at this quickly and find the answer and I was
unable to do so. I was hoping to get some guidance from my friends in the ART
area about whether this is a well-done proposal.

Alexey: Are you asking about the scope of cookies or the public suffix list,
which we used to have a WG that concluded with proposals and people couldn’t
agree on anything.

EKR: As I understand it, Alissa’s complaint was that the document claims that
you can’t find anything lighter than eTLD+1, but cites 6265, which is not in
fact anything like that. Then it needs some kind of normative reference to what
eTLD+1 is.

Alissa: Exactly. I was surprised when I went back to 6265 because I would have
thought it does what this document says it does, but that didn’t seem to be the
case. It’s a clarification point; This document doesn’t have to be constrained
by whatever 6265 does, for any particular reason as far as I can tell, but
right now it’s just wrong.

Alexey: Do they want to ask the HTTPBIS WG?

EKR: I can do that. There are 2 problems: one is that we need a normative
reference here somewhere, either a reference to a policy which you could
supply, or a reference which gives us normative content. So if there were some
document that provided we could reference that, if not we’re proposing a new
thing here and we need to work with PSL.

Alexey: PSL is a big elephant in the room. We tried to do something in IETF and

EKR: I don’t have a problem with normative referencing PSL, but others might
because it’s not a stable reference.

John Bradley: This is a problem for pretty much everyone. The facts on the
ground are that the browser vendors through the WG wanted to but coming up with
a normative reference someplace is hard. If someone can help us with that it
would be great. Essentially the rule is no wider than the scoping of cookies,
but finding a normative reference to have cookies, good luck.

EKR: I’ll take the action item to email the HTTPBIS WG about this. Can we all
agree now that this may be a little crusty when we get to it and we’ll just
have to accept the resolution?

Alissa: Sounds good.

EKR: I just want to make sure we get this document published. I don’t want to
boil the ocean on this.

John: There is a difference between user agents as in browsers, which tend to
be passive things and aren’t actively involved in the upper level protocols
that are using the token binding; vs a native app on a phone which may have its
own privacy concerns or want to scope things narrower or broader if it knows
there’s a security concern. If you have a correlatable token that you’re using
between two points, jumping through hoops to not use the same token binding ID
may be unreasonable for some implementations. We’re trying to leave a little
flexibility for native apps that have a better notion of what their own privacy
and security profiles are, as opposed to say you must do it this way, which is
a more reasonable thing for browsers which tend to be generic and not have a
knowledge of the upper level parameters. There’s something in there that we’re
not clear on. We can work through and try to sort that out for people. That’s
the basic idea.

Ben: So what you said there is great; I didn’t get that from the text. I think
it just needs some clarification about what you mean by the differences there.
Another thing I noticed is the text described it from the perspective of the
server; if the server is going to work with native applications it needs
something. I assume what you mean is to allow this kind of flexibility.

John: The server doesn’t know anything about it, it’s how the client itself is
constructed when the client isn’t another server.

Ben: That’s another place where I didn’t get what you just said from Section 6.
I’m perfectly happy with what you just said. So if that can be clarified then I
would clear the Discuss.

John: I’ll work with the authors to get that turned around, because that’s what
it was intended to be. We really do have two classes of things, one which is a
user agent which may be relaying HTTP connection through, or if we can ever get
the WG to get that sorted, have javascript which is doing things that involve
running over token-bound connections but not necessarily reaching down into the
stack. So that’s on the server side with javascript vs something that’s native
app on Windows which has token binding to native applications … they have some
control over where the keys are created and stored.

EKR: Are we ready to move on from this document? I think we have two action
items. I’ll send HTTPBIS mail pronto.

Amy: I’m hearing that this is going to require a revised ID.

EKR: Oh yes. I’d prefer Ben and Alexey keep their discusses so that’s a
placeholder in the system for what needs to be fixed.

John: A lot of the other comments have already been addressed. The authors put
out another draft last night, which I don’t expect anyone has read. Hopefully
it addresses a lot of the other comments.

EKR: Thanks to the authors for being so productive.

Amy: That will go into Revised ID Needed and we’ll move on to our next document.

 o draft-ietf-tokbind-negotiation-13  - IETF stream
   Transport Layer Security (TLS) Extension for Token Binding Protocol
   Negotiation (Proposed Standard)
   Token: Eric Rescorla

Amy: I have no open positions, but I do have a Discuss. Do we need to discuss
that today?

EKR: This has the exact negotiation mechanism TLS had prior to 1.3. I don’t
think TLS did a very good job of giving semantics to major and minor. It’s
almost a naming convention. I’m going to be pretty resistant to the idea of
actually changing the negotiation mechanism. If people would be happier
treating this as a 16 bit integer I wouldn’t have any problem with that. But I
don’t want us to revisit the question of whether we’re going to do highest
version negotiation at this point.

Alexey: That’s okay with me. Are there likely to be future versions of this?

John: Yes. Obviously the authors and other people in the industry anticipate
this will become a major  feature, as the browsers and the large sites start
depending on it. From this perspective it’s seen as a way protocols can meet
AFL3 in sp800-63, so these will never mention private sector interests. It’s
going to evolve over time, now the question is: as we go forward, if we want to
change the negotiation method we would just define a new mechanism and
extension number. Likely both things will happen over time. I expect this to be
around for a while.

EKR: Alexey, do you think some change is needed here?

Alexey: I’m not convinced the version number is needed because the rest of its
sensibility is already good enough. This was discussed in the WG, so I’ll just

John: When we were developing this, having a version number allowed us to do
interop testing.

Alexey: Early drafts.

John: Going forward for testing and other things it will be useful, rather than
having to go and ask for a new code point to have a different extension. We
want to be frugal on the extension points. If there is a big change likely it
would be through a new code point. The version number allows us to have better
control over testing and some potential conflicts going forward. Some people
think version numbers and version negotiation leads to bad things, but there
are also benefits. I’m sympathetic to that position. Practically, getting it
out in the world, version numbers help.

Alexey: I’m not objecting to versioning, I just think the documentis
underspecified in how it’s going to be used. I’ll clear.

John: So essentially there were the 2 points, one was around the negotiation
mechanism and one was around the meaning of the version number. If we clear the
version number, are we okay with the TLS 1.2 type negotiation?

EKR:  I was hearing Alexey say you can do both.

Alexey: Yeah, I’ll just clear. If you want to stop calling them major and minor
that would be an improvement, but. ..

John: I think there’s a general feeling in the WG that having 2 digits for the
version number is somehow more humanly comprehensible. On the other hand people
might believe there’s more significance to it. We could keep the common format
and add some text around ‘don’t believe that there’s any difference between
incrementing a major number and a minor number,’ something like that?

Amy: For this document I have that Alexey is going to clear but that hasn’t
happened yet, right?

Alexey: Give me two minutes.

EKR: John, do you believe the authors have covered all the other points?

John: I think so.

EKR: Since I haven’t had a chance to read that document, why don’t you mark it
Revised ID Needed, and I’ll read that relatively soon.

John: If we only need one revision past this, we’ll be so lucky.

EKR: John, if you could do me a favor and let me know when you think it’s ready
for approval? Per the previous document, I emailed the HTTPBIS WG and Alissa
two minutes ago. Hopefully we can resolve that quickly.

Amy: Once Alexey clears, this will go into Approved, Announcement to be Sent,
Revised ID Needed.

 o draft-ietf-tokbind-protocol-18  - IETF stream
   The Token Binding Protocol Version 1.0 (Proposed Standard)
   Token: Eric Rescorla

Amy: I have no Discusses in the tracker for this doc, so unless anyone has an
objection it looks like it’s approved.

John: There was a new draft put out last night that should have addressed
everything. We need to go through and make sure we’ve actually captured all of
it. In the questions there was lingering confusion about why we’re not
addressing. .. no that’s another one, so we’ll leave that. For protocol we’re

EKR: For the same reason, let’s mark it revised ID needed. Once we have the
Discusses cleared I’m going to go over all three.

Amy: That will go into Approved, Announcement to be Sent, Revised ID Needed.

 o draft-ietf-bess-evpn-prefix-advertisement-10  - IETF stream
   IP Prefix Advertisement in EVPN (Proposed Standard)
   Token: Alvaro Retana

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

Alvaro: No I don’t think so, the authors seem to be waking up to the fact that
they need to respond so I’ll give them a chance to do that. We’ll definitely
need a Revised ID Needed.

Amy: This will stay in IESG Evaluation and Revised ID Needed. Moving on.

 o draft-ietf-homenet-babel-profile-06  - IETF stream
   Homenet profile of the Babel routing protocol (Proposed Standard)
   Token: Terry Manderson

Amy: I have no active Discusses. Unless there’s an objection, it looks like
this is approved.

Terry: It will definitely be Revised ID Needed please.
Amy: Okay, this will go into Approved, Announcement to be Sent, Revised ID
Needed. Terry, let us know when it’s ready.

 o draft-ietf-hip-native-nat-traversal-28  - IETF stream
   Native NAT Traversal Mode for the Host Identity Protocol (Proposed
   Token: Terry Manderson

Amy: I have a couple of open positions. Ignas, did you want to state a position?

Ignas: Let this be a No record, I did not do a detailed analysis.

Amy: Okay, no record for Ignas. Warren?

Warren: No record, I didn’t look at it.

Amy: And Alexey said no position. I have a couple of discusses, do we need to

Terry: No, there’s no point in discussing the discusses yet, I’ve not seen any
meaningful responses from the authors to address EKR’s or Mirja’s discuss. I’m
going to have to make this Revised ID Needed.

Amy: This will stay in IESG Evaluation and go into Revised ID Needed.

 o draft-ietf-secevent-token-13  - IETF stream
   Security Event Token (SET) (Proposed Standard)
   Token: Benjamin Kaduk

Amy: I have no open positions and no discusses, so if there are no objections
it looks like this is approved. Are there any notes needed?

Benjamin: I don’t think so, the authors have been good about pushing updated
IDs as comments come in. I think this one can go into Approved, Announcement to
be Sent.

 o draft-ietf-uta-mta-sts-17  - IETF stream
   SMTP MTA Strict Transport Security (MTA-STS) (Proposed Standard)
   Token: Alexey Melnikov

Amy: I have several Discusses in the tracker, do we need to discuss those today?

Alexey: Yes I think so. For EKR’s, that discussion is ongoing and should be
settled by email. Adam, yours is relatively trivial but I’m waiting for a
response from the authors. Do you agree?

Adam: I suspect what is intended here is that TLS RBT [Correction: TLS RPT]
needs to change, and this document probably reflects consensus, but  however it
plays out they just need to say the same thing.

Alexey: Yes, the other one is not approved yet, so I think that’s fine. Warren,
would you like to talk about your discuss?

Warren: Yes please, I would love to. This document reserves _mta-sts.domain
name —— which makes me a little twitchy that it does it by just burying it in
the text. However that’s what we’ve been doing up until now. That’s the
standard way of reserving one of these TXTs. Dave Crocker is working on
creating a registry to record these. So what I think would be a reasonable way
forward is to carry on with this document as it is and suggest that Dave please
add this to the document he is working on. That seems reasonable. What is more
concerning is that the document also reserves the label mta-sts.whatever the
domain is with no underscore. This is something I don’t think has been done
before. There’s nothing that says you can’t do it, it just feels weird and
sketchy. I also think it sets a dangerous precedent, but seeing as there’s
nothing that says you can’t do it, I can’t really fault the authors that much.
We also currently do that kind of - for example, even though it’s not
documented anywhere, everybody assumes the web server for is It’s not written down in a standards document. What might be a
reasonable thing, but it would require a change to the document, is that the
underscore text label would specify the name, or label, that then you use to
look up the policy. You could specify a label of “foo” and then preset foo and
that tells you where to find the policy. It feels odd to at this point suggest
that they’ve done things wrong. I don’t really know how this should proceed. I
don’t know if the WG would be open to just adding this; it seems like a simple

Alexey: I have no idea. I suggest you ask the question. Maybe there are good
reasons not to do it, or maybe everyone says it’s fine and let’s do it.

Warren: I will also apologize to them for not catching this earlier.

Ted: I went back and looked at this and the closest I could find to a
reservation like this was really early notes on conventions. There was a group
of FAQ like descriptions of what the dimensions were where network services
were commonly - postmaster was reserved as a mailbox but the convention for
where you got to send mail was SMTP. None of those were reservations and
there’s a note in them that basically says if this doesn’t work, you need to
find out another way of finding out what the correct one is because there’s no
necessity that it be this one. Benjamin’s point in the jabber that some people
are going to be too cool for the convention is definitely true. There’s no
enforcement mechanism here that says you must use this one. The only thing that
will happen is that if someone doesn’t reserve this name according to the way
the document is currently written, they can’t use this standard at all. I think
it would be fine for them to say, here’s how you specify a label in the record,
but you could also say conventionally this is mta-sts, and absent such a label
expression, that’s where you should go.  If you did that, it goes back it not
being a convention. Too, anyone who’s already done it this way, it will work,
but we’re not trying to tell the entire DNS community thou shalt reserve this.
We’re simply saying, anybody who’s already using this, this is what it means,
and if you want to do something different, here’s the protocol mechanism for
making that work. I think there’s a way of going forward that takes security
into account but also doesn’t break anything that’s already out there.

Warren: I really like that. There is a concern that if someone’s not expecting
this and has a machine called mta-sts, they will suddenly be getting a lot of
queries for things they don’t know what to do with, but oh well - if you have a
machine on the Internet, you’re going to be getting queries you don’t know what
to do with. I like that.

Alexey: Ted, if you could write something in jabber, that would be amazing and
then I can cut and paste.

Ted: Will do.

Adam: One thing I’d be careful with: we want to look at the security properties
of doing this, vis a vis somebody standing up a server that is publishing false
policies and somehow getting banned from the DNS.

Warren I guess that’s true; if I can register that name in a domain I can break
mail by having a bad error or something.

Adam: The scenarios I’m concerned about are you have a domain with subdomains
under it that are under different control. Similar to what Alexey mentioned,
having something more like would cause the same
issues. I think someone needs to sit down and think about the security aspect
of having this become unpinned from a known name. It just warrants a little bit
of time.

Warren: It looks as though there are likely to be solutions. I don’t know if I
should leave my Discuss.

Alexey: Leave your discuss, send an email, and we’ll see how the discussion
progresses. If we can conclude on this particular topic in a week or so that
would be great.  The only other issue on this document is I’ve sent email to
IESG saying that registration doesn’t quite fall under current tools, so I’d
like to approve an exception for this document. I hope people are okay with

Alissa: Did you talk to Mark about that part, that we would approve the

Alexey: I did tell them that I would ask for an exception.

Alissa: Okay, that’s fine.

Alexey: This document will definitely need a new revision.

Amy: Great. We will keep that in IESG Review with a substate of Revised ID

2.1.2 Returning items


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-teas-sr-rsvp-coexistence-rec-03  - IETF stream
   Recommendations for RSVP-TE and Segment Routing LSP co-existence
   Token: Deborah Brungard

Amy: I have no active Discusses in the tracker, so if there are no objections,
it looks like this one is approved.

Deborah: We’ll do this Point Raised.

Amy: Certainly. This will go into Point Raised, Writeup Needed, and Deborah you
can let us know when that’s ready.

 o draft-ietf-hip-rfc4423-bis-19  - IETF stream
   Host Identity Protocol Architecture (Informational)
   Token: Terry Manderson

Amy: I have no Discusses in the tracker for this document, so unless anyone has
an objection it looks like it’s approved. Any notes needed?

Terry: Actually I think this needs to be a Revised ID Needed. I didn’t see
comments being addressed from the authors. If you could put it as Point Raised
that would be great.

Amy: I can do either Point Raised or Revised ID Needed. I’ll put it in Revised
ID Needed.

Terry: Thank you. No notes are going to be needed either.

3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items

 o draft-hoffman-dns-in-json-15  - IETF stream
   Representing DNS Messages in JSON (Experimental)
   Token: Alexey Melnikov

Amy: I have no Discusses in the tracker for this document, so unless anyone has
an objection it looks like it’s approved.

Alexey: Can I have this in AD Followup? There are some comments which I think
also reply to the comments in the revised document but I would like to catch
the rest.

Warren: There had been some discussion about should this be informational or
experimental? I don’t know if the IESG needs to decide ahead if it’s okay for
that to change? From what I remember the authors said do whatever you want on
that front.

Alexey: Shepherding AD says I don’t really mind either way.

Warren: Does anybody object wildly if it’s changed to Informational, ad that
way the AD can decide?

Spencer: The amount of review we ask for is the same so I would not have
concerns about changing.

Alexey: Let’s change it to informational then. Neither would require another
last call.

Amy: Okay, so this is going to change the intended status from experimental to
informational. It’s Approved, Announcement to be sent, Point raised. Are they
going to do a revision of the document so the header says informational?

Alexey: I don’t know. Let’s do Point Raised, AD Followup.

Amy: You’ll figure all that out? Okay.

3.2.2 Returning items


3.3 Status changes
3.3.1 New items


3.3.2 Returning items


3.3.3 For action

 o status-change-kerberos-3des-rc4-to-historic-00  - IETF stream
   Deprecating 3DES and RC4 in Kerberos (Status Change) (None)
   Token: Eric Rescorla

Amy: There was a document that went along with this that we probably should
have had on this agenda as well, but we missed it.

EKR: That document was on a previous telechat and had discusses that were about
this. I think what needs to happen is that Mirja needs to clear her Discuss and
then we proceed. We’re now pretty far into the weeds as far as process.

Amy: I think you’re right, the document now has its status change and both the
status change and the document will go together. If the document has a discuss
on it, that needs to clear before this can go as well. It’s not something we do
very often.

EKR: Maybe I should just ping Mirja and ask her to clear her discuss.

Amy: I think you’re right. Then when her Discuss is cleared, that document can
go as well as the status change can be sent at the same time. You can just let
us know when that’s done and we can get them sent together.

3.4 IRTF and Independent Submission stream documents
3.4.1 New items


3.4.2 Returning items


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

 o Messaging Layer Security (mls)

Amy: I currently have no blocking comments for this chartering effort, so if
there are no objections this can be sent for external review. Hearing no
objection, we will send that and put it on the agenda for the next telechat.

4.1.2 Proposed for approval


4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Benchmarking Methodology (bmwg)

Amy: I do currently have a blocking comment. Warren, do we need to discuss that?

Warren: Yes please. There are two requests in it; one is the milestone for one
of them. The document which is currently referred to in the milestone is overly
broad, and sounds as if it’s doing more than it’s intended to. The authors have
promised they will fix it, largely by removing Section 2. I fully agree that
they’re not the WG to do that. I don’t know how Deborah wants to handle that,
if she wants to trust the authors and WG chair and myself to make sure that the
document is more narrowed, or if she’d rather that we removed the milestone or

Deborah: What I found lacking was any description of taking on this type of
work in the description. They have a huge several paragraphs that they’re going
to do DNS now. If you look at the existing older type work, none of this fits
any of that. I think if they even think they want to be looking at adopting
those documents they need a couple sentences to say what they’re planning to do
with it.

Warren: I think what it’s supposed to be is only scoped for benchmarking and
measurement. The document was adopted when it was way more broad. It’s supposed
to be simply explaining how you — Let’s see whether you, myself, Elle, and
Sarah have a chat? I believe this will be narrowed down purely to cover
benchmarking stuff,  which I think is covered in their text.

Deborah: We can talk among ourselves. Even if they could just add a couple
sentences. If they really feel this fits in that’s fine. Still, they need to
add a sentence to say, because everybody from the other groups will pick up on
these acronyms, they need a sentence to say they’ll coordinate with those other
groups when needed.

Warren: Chairs also suggested they add something saying they will continue to
work with people like the operating community, etc, and coordinate with other
IETF WGs as well, as they are already doing. We will chat more offline and I
think that’s the only blocking position.

Amy: Are we just going to wait for instructions from you about when this might
be ready for external review?

Warren: I wasn’t quite sure how the process on that works. It’s not a document
so we do meet much less often. If it were a document I’d guess it stays like
this until the equivalent of a discuss is cleared, then I guess I send email
saying I think it’s happy to go.

Amy: You could do that. If you think it requires an external review we can do

Warren: I don’t think it needs external review. Deborah, do you think it needs
external review?

Deborah: If the appropriate wording is added I don’t think it needs external

Warren: Excellent. We will chat, and once we’ve decided I will send mail to the

4.2.2 Proposed for approval


5. IAB news we can use

Deborah: No news. I can give an update. They’re still discussing to scope their
work items. The other item is what they will do for the technical plenary for
the next meeting. As soon as I have some news I’ll let you know.

6. Management issues

6.1 Designated Experts for WOTS+ Signatures, XMSS Signatures, XMSS^MT
Signatures [IANA #1053888] (Alexey Melnikov)

Amy: Alexey has taken this and recommended that two of the editors from the
draft-irtf-cfrg-xmss-hash-based-signatures be approved as experts. Any
objection to naming Andreas Huelsing and Stefan-Lukas Gazdag as the experts?
Hearing none, we will call those approved and send an official note to IANA.

6.2 [IANA #1108549] Designated expert for RFC 8350  (Sabrina Tanamal/IANA)

Amy: Sri Gundavelli and Li Xue have offered to be experts. Any objection to
them? With no objections, they are approved as experts.

6.3 [IANA #1108551] Management Item: Acceptance of media type registration from
standards organization ETSI (Amanda Baber/IANA)

Amy: We are looking for a blank permission approval.

Alexey: Amanda asked me whether we should just register them but I said it
requires full IESG approval. I think this can go in parallel. The main point of
IESG approval for this is a sanity check to make sure we recognize them as an
established organization and we have some confidence they usually know what
they’re doing.

Ben: I was a little surprised by this because they’ve brought the Tetra audio
codec to the PAYLOAD wg. These appear to be related to that, but I guess they
don’t make sense for PAYLOAD. So maybe it makes sense like this.

Alexey: Would you like to follow up with them?

Ben: I don’t see it as a problem. These are all related and it’s clear this is
all part of a bigger system. PAYLOAD is probably the only place where we have a
WG for what they’re doing.

Adam: This sort of thing could be done as a draft through DISPATCH, as it’s
just a registration of a MIME type. But I think having it registered directly
by ETSI makes more sense.

Ben: How accessible are their documents these days? I don’t know if that
changes anything.

Alexey: Typically expert reviewers will see the documents for the formats.
They’re not accessible for everybody to see.

Ben: I guess that’s better than nothing. I didn’t mean any of that as an
objection, just for your information.

Amy: I’m not hearing any objection to approving this?

Alexey: Yes I think we are approving ETSI and a designated expert will review
registration separately.

Amy: Okay, with that approval we will send the official note to IANA.

6.4 [IANA #1108770] Designated expert for RFC 8323 (Sabrina Tanamal/IANA)

Amy: We will mark this as in progress, since Alexey is now aware of it.

6.5 Designated Experts for RFCs 5792 and 5793 [IANA #1050763] (Benjamin Kaduk)

Amy: Benjamin would like to approve Steve Hanna, Jessica Fitzgerald-McKay, and
Charles Schmidt as experts. Any objection? Hearing none, they are approved.

6.6 Current IESG procedure for allowing Secretariat to manage telechat queues
(Alexey Melnikov)

Alexey: I think the last message in the thread suggested that we should email
the Secretariat when we issue ballots, since this does not happen
automatically. I just want to agree that’s the process. I already issued three
or four ballots and I want to know what to do with them.

Amy: Speaking for the Secretariat we would greatly appreciate if we got word
when you issue a ballot and something is ready to be put on a future telechat
agenda. Until the tooling catches up; we’ve asked for tooling changes for that.
We need to know when you all think something is ready.

Alissa: Don’t the ballot issued emails go to the IESG list?

Alexey: I think you’re correct.

Alissa: Why isn’t that sufficient?

Cindy: The sheer volume of traffic makes it hard to track what we need to
follow up. It’s much much easier if it comes to us as a ticket. If we try to
track that on the IESG list we will almost certainly miss things.

EKR: Can you filter? Most mail systems have a way to filter.

Warren: It does feel like something that takes a copy of this and forwards it
to the ticket system, I’m guessing Glen, writes a - -

Adam: I imagine the change to the Datatracker is less than one line, and
pushing out a new Datatracker release is easy. Instead of asking Glen to do
something we should ask Henrik.

Warren: Sounds like an answer to me, if Henrik has time.

Alissa: We were worried about getting the GDPR compliance stuff done but it
sounds like Henrik will have that finished up this week. I assume Henrik could
do this next week since it takes like ten minutes. Do you disagree, Alexey,
Ben, EKR?

Alexey: This can be done with tools, that’s fine.

Ben: So does that mean the change in procedure doesn’t start until Henrik does

Spencer: Seems much easier, if we start the procedure when that tool becomes
available. Doing it the other way doubles the number of emails we send to the

Alexa: So just to be clear, are we asking them to just add the notification to
send mail to IESG Secretary, or the further automation of actually doing the
initial loading of documents onto the agenda that Amy and Cindy will manage,
which was the other solution we proposed?

Ekr: I thought they’d send mail to the ticketing system.

Alissa: I think the email is the short term solution. The alternative was that
we send those emails manually. We can figure out prioritizing the larger piece
of work later. Alexey, since this was yours, do you want to email tools about

Alexey: Okay.

6.7 Proposed note re agenda experiment at IETF 103 (Alissa Cooper)

Alissa: I sent a revised version of this yesterday and wanted to see if there
are any objections to it going out. Looks like no objections - I will send it
sometime today.

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

No new business.