Skip to main content

Narrative Minutes interim-2021-iesg-05 2021-02-18 15:00

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

Narrative minutes for the 2021-02-18 IESG Teleconference

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

1. Administrivia
1.1 Roll call

Deborah Brungard (AT&T) / Routing Area
Jenny Bui (AMS) / IETF Secretariat
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Roman Danyliw (CERT/SEI) / Security Area
Lars Eggert (NetApp) / incoming IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Wes Hardaker (USC/ISI) / IAB Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline (Google) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / incoming Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / incoming Transport Area
John Scudder (Juniper) / incoming Routing Area
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

Jay Daley / IETF Executive Director
Martin Duke (F5 Networks Inc) / Transport Area
Martin Vigoureux (Nokia) / Routing Area

Yui Mi
Rene Struik
Greg Wood

1.2 Bash the agenda

Amy: Please note that one of the documents was removed last night and we'll
pick that up in management items. Does anyone have anything new to add to
today's agenda? Any other changes?

Alissa: I would like to talk about the pre-IETF meeting agenda briefly at the
end of the call.

Eric V: I may want to talk briefly about [an IETF 110] agenda change of moving
DNSSD to Friday.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the February 4
teleconference being approved? I'm hearing no objection to approving those. I
saw narrative minutes this week; any objection to approving the narrative
minutes for February 4 as well? Hearing no objection to those either. Also, I
got no response to the Bof coordination call minutes. Any objection to
approving those so we can get those posted? Hearing no objection.

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.

Alvaro: I think this is going well. It's out for review and we probably need to
wrap this up at some point and get it ready to be published. I'll follow up
with Murray.

Murray, later: We should have a final version of that by next week's telechat.

     o Alvaro Retana and Martin Vigoureux to draft text on guidance
       regarding the number of document authors on documents.

Alvaro: We're making slow progress on this. Martin is on a mountain somewhere
this week so we couldn't make much more progress. We're close to making a
decision on either letting it go or coming back with a specific proposal.

     o Roman Danyliw to draft text for a request to the Tools Team to move
       BoF requests from the BoF Wiki to the Datatracker.

Roman: We're done. I took all the feedback, I appreciate the polish, and it's
now with Robert. He's working on producing a rough order of magnitude estimate
for what it would take to do that and any other questions he may have for us.
We're basically waiting to hear that response and based on that level of effort
we can decide what to do next.

     o Alvaro Retana, Warren Kumari, and Barry Leiba to draft clarifying
       text on Errata Best Practices.

Warren: In progress.

Barry: We posted it to the IESG for review so we could say it's done. Do you
want to leave it just so we remember to follow through?

Alvaro: Sure. I sent an email yesterday with the new text, and hopefully we can
just make comments on email or the Google document. If needed, we'll set up a
management item next week to discuss it.

     o Martin Vigoureux and Alvaro Retana to work with Jay Daley on the
       process for using EthicsPoint incident management software as
       the mechanism of private feedback and anonymous reporting.

Alvaro: Martin has been taking the lead on this and we're working with Wes as
well. The next step was to talk to Jay, so this week nothing happened and
hopefully we can get back to that soon.

     o Erik Kline to find designated Experts for RFC 8915 [IANA #1179647].

Erik K: In progress.

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

Warren: That's making progress. We didn't meet last week because of scheduling,
but still making progress.

     o Erik Kline to find designated experts for RFC 8928 [IANA #1183445].

Erik K: Still in progress.

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

Ben: Still in progress; I'm waiting to hear back from somebody.

     o Ben Kaduk to find designated experts for RFC 8879 [IANA #1184206].

Ben: I didn't send email about this but the plan is to just approve the same
three experts for basically all the other TLS registries. I don't think it
really matters if we do that today or if I send mail and we schedule it [for

Amy: We can add a management item for today if you can send us the names, or
for next week. It's up to you.

Ben: Let's try to do it today then. I'll put the names into chat.

     o Robert Wilton, Alissa Cooper, Alvaro Retana, and Warren Kumari to
       report back to the IESG on the impact of COVID-19 to the IETF in
       January 2021.

Alissa: This is done. It would probably be good to set a time in six months or
something to look at it again.

Eric V: Did you intend to display this at the plenary?

Alissa: I think so. I did last time, but it was not as much data as we have
now. It would probably be good to include. What do you think?

Alvaro: We also need to think about that, the curves look about the same for
the last few years except the -00 drafts. There seems to be a difference there
of about 20%. If we're going to show this, the question is going to come up if
we have a plan, what we're going to do about it, why did it happen?

Warren: Well the answer is let's not get COVID and let's not have another
pandemic, because it messes with our output.

Alvaro: I really wonder if that's the case, because the normal published drafts
came at about the same pace.

Warren: I've had some discussion on this topic and it seems the difference is
often the -00s are driven by personal interactions with people. They'll get
together and say "this protocol does XYZ" and then "oh, we should fix that."
In-person interactions is what changes the frequency of -00s, since you're not
bouncing ideas off people and collaborating as much.

Alissa: The one thing we're talking about doing is having the Gather space live
on after the meeting. We were trying to figure out the authentication for that
and we don't have a great answer, but that's an option we have in the hopper to
try to facilitate more serendipitous interaction that sometimes leads to these

Mirja: This might also be an indication that we generally have less new work
but we have also not had a lot of Bof requests the last few meetings. On the
other hand maybe giving these new proposals a little bit of a pause and making
good progress on what we already have is a good thing.

Roman: I think not having Bof proposals is area-dependent. Sec has had a steady
stream of them.

Rob: Should we discuss this on an informal?

Alissa: We don't have an informal next week but we can talk about it as a
management item next week or at the pre-IETF meeting.

Eric V: Pre-IETF meeting sounds good.

Amy: When you say you want to bring it back in six months, when exactly? Or
would you rather table this until your pre-IETF meeting?

Alissa: My opinion isn't worth very much anymore, but if there's going to be
further discussion of it at 111, we should generate the updated data before 111.

Alvaro: I agree.

Eric V: I agree as well. We need to follow this closely.

Amy: Okay, we'll put that back on the action items list before 111.

     o Murray Kucherawy to find designated experts for RFC 8839 [IANA

Murray: Please leave this on for next week. I just posted to MMUSIC to ask.

     o Murray Kucherawy to find designated experts for RFC 8855 [IANA

Murray: I have someone for that. Do we do it here, or is it a management item
at the end? I can't remember.

Amy: Generally it's a management item. If you can give us the name of the
person in chat we can add it as a management item.

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

Eric V: Let's put that as in progress.

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

Amy: This is a new item for Warren.

Warren: I'm an author on this document, so I'm probably not the right person to
nominate a person. I expect there to be absolutely zero requests for the
registry, though. I believe that Barry was the responsible AD.

Barry: I can take it. Warren, will you be the expert?

Warren: Since there are likely to be zero requests ever, sure.

Barry: Amy, can we put a management item today to approve Warren?

Wes: Can I suggest we ask Duane too? He's by far the expert on it.

Warren: Aren't you an author on this too? I suggest Barry nominates Wes as the

Wes: Duane should do it.

Warren: I'll ask him.

Barry: We can deal with this later.

Amy: We'll change this to Barry's item and mark this as provisionally done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-core-echo-request-tag-12  - IETF stream
   CoAP: Echo, Request-Tag, and Token Processing (Proposed Standard)
   Token: Barry Leiba

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

Eric V: Just a quick question, why is it called "echo" and not "challenge" or
something else?

Barry: Couldn't really tell you. I don't have the history of the name. Please
put this in AD Followup, Amy.

 o draft-ietf-regext-rfc7482bis-02  - IETF stream
   Registration Data Access Protocol (RDAP) Query Format (Internet
   Token: Barry Leiba

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

Barry: This will be Revised ID needed. Just an alert to everybody, on next
week's telechat we have a status change document. There's a set of five
documents that are all part of this; two of them are on this week's telechat,
there's a status change document coming next week to push two others up to
Internet Standard without changes, and there's been some discussion with John
Klensin on the Last Call list, so this whole set might get held based on the
result of that discussion. But for next week's telechat, the Last Call on [the
status-change document] ends the day before the telechat, so there won't be a
ballot available until the day before the telechat. I might push that out and
let Francesca or Murray handle it, depending on how that goes.

Amy: I also have a list of downrefs here. I assume the downref registry doesn't
need to be updated with any of these?

Barry: It does not. The same is true for 7483bis.

 o draft-ietf-regext-rfc7483bis-04  - IETF stream
   JSON Responses for the Registration Data Access Protocol (RDAP)
   (Internet Standard)
   Token: Barry Leiba

Amy: I have no Discusses in the tracker, so unless there's an objection now, it
looks like this one is approved. Is this also approved pending revision?

Barry: Yes it is. Revised ID Needed please.

 o draft-ietf-pce-association-bidir-12  - IETF stream
   Path Computation Element Communication Protocol (PCEP) Extensions
   for Associated Bidirectional Label Switched Paths (LSPs) (Proposed
   Token: Deborah Brungard

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

Deborah: We'll do it as Revised ID Needed. I have some changes.

 o draft-ietf-detnet-tsn-vpn-over-mpls-06  - IETF stream
   DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS
   (Proposed Standard)
   Token: Deborah Brungard

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

Deborah: We'll do this as Revised ID Needed also.

 o draft-ietf-mpls-lsp-ping-registries-update-08  - IETF stream
   Updating the IANA MPLS LSP Ping Parameters (Proposed Standard)
   Token: Deborah Brungard

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

Deborah: I don't think so but I'll leave it up to the other ADs. The document
shepherd and authors are quite busy exchanging mails so I'll leave it up to
everyone else if they have anything.

Rob: From my point of view I think it's fine; we have our resolution path and
no further discussion is required.

Deborah: Okay, so this will be under IESG Evaluation and definitely a Revised

 o draft-ietf-regext-unhandled-namespaces-07  - IETF stream
   Extensible Provisioning Protocol (EPP) Unhandled Namespaces
   (Proposed Standard)
   Token: Barry Leiba

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

Barry: This will probably need a Revised ID. Go ahead and put it in AD
Followup, please.

Ben: There were a few examples that at least in my reading claimed to be
modified versions of examples from other documents, and there were more
modifications than just the ones there should have been. There were some other
examples that didn't claim to be modified versions of examples from other
documents, but were pretty close. Lots of ways to go with that.

Barry: I'm guessing we're going to need a Revised ID but we can put it in AD
Followup for now and I can always change it.

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-detnet-ip-over-tsn-06  - IETF stream
   DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking
   (TSN) (Informational)
   Token: Deborah Brungard

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

Deborah: We'll do this as Revised ID Needed also.

 o draft-ietf-detnet-mpls-over-tsn-06  - IETF stream
   DetNet Data Plane: MPLS over IEEE 802.1 Time-Sensitive Networking
   (TSN) (Informational)
   Token: Deborah Brungard

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

Deborah: Again, Revised ID Needed.

3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items


3.2.2 Returning items

 o draft-allan-5g-fmc-encapsulation-08  - IETF stream
   5G Wireless Wireline Convergence User Plane Encapsulation (5WE)
   Token: Erik Kline

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

Erik K: I meant to make one last pass to make sure all the comments from the
previous review had been addressed. I believe I had done so but I don't have a
record of having done so. So if I could get a chance to do one last scan?

Amy: Absolutely. It can go into Approved, Announcement to be Sent, AD Followup
and you can let us know when it's ready to go.

Erik K: Thank you.

3.3 Status changes
3.3.1 New items


3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items


3.4.2 Returning items


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


4.1.2 Proposed for approval

 o Real-Time Communication in WEB-browsers (rtcweb)

Amy: I have no blocking comments in the tracker, so unless there's an objection
now, it looks like this is ready for approval to be a new-old working group.
I'm hearing no objection.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval

 o Authentication and Authorization for Constrained Environments (ace)

Amy: I have no blocking comments in the tracker, so unless there's an objection
now, it looks like this is ready for approval. I'm hearing no objections so we
will send the recharter announcement for ACE.

5. IAB news we can use

Alvaro: Nothing new to report this week.

Wes: The slate for the ISOC board positions should be coming to the IESG
shortly, as an upcoming warning.

6. Management issues

6.1 IESG Conflict of Interest Policy (Barry Leiba)

Barry: Maybe I should share my screen. We got no comments on this since last
week's informal so I think we're done. I just want to go through and quickly
look at the items that are flagged. Warren's note about how we announce it so
it doesn't look like there's something wrong, I agree with that comment. We had
two bits where I said let's think about the sentence a little more. This one
here about where conflicts are strong, and we questioned whether "strong"
and/or "controversial" was the right spin there, but nobody suggested anything
else. Does anyone not want to leave it the way it is and if not do you have a
suggestion for an alternative? [silence] Okay, I'll resolve this then. The
other one was where we used to have "should" for the two "must"s in this
sentence and we changed them to "must." Does anyone want to discuss further
whether it should stay "must," or go back to "should," or something else?

Alvaro: I think I was the only one saying I didn't like it, and I'm okay with
the text you added.

Ben: I'm fine with "must" even if we don't really specify what the procedures
are supposed to be if you fail to do so.

Barry: This policy doesn't really say what happens if someone doesn't disclose,
but neither do the policies of the other bodies. Okay, I think we are done
here. The next step is to send this for legal review. Alissa, is that correct?

Alissa: Yes, we can send it to Brad and ask him to review it. Feel free to send

Barry: Thanks everybody.

6.2 [IANA #1189051] Designated experts for RFC 8976 (IANA)

Amy: This item has been assigned to Warren. This is the one Warren assigned to
Barry, I think.

Barry: Warren, you're willing to do it. You didn't get a response from Duane
yet, right?

Warren: I have not gotten a response from Duane. I think this registry is going
to be very low-traffic so I think just one for now and we can add Duane later.
We can also just appoint him, he's not going to say no.

Barry: We can approve both of you and only announce you until we get
confirmation from him. Does anyone object to that path? Okay, I think we're
done with that one.

Amy: Okay, so we will send the official note about Warren. You can let us know
if and when Duane also approves and we'll send a followup for that.

6.3 [IANA #1189045] renewing early allocations for
draft-ietf-idr-bgp-open-policy (IANA) 6.4 [IANA #1189046] renewing early
allocation for draft-ietf-idr-eag-distribution (IANA)

Alvaro: Both of these are for extensions of assignments and the documents are
in my publication queue. IDR requires implementations, so both of them actually
have implementations and I think we should definitely approve both of them.

Amy: Any objection to approving the extension of the early allocation for both
of these? Hearing no objection, so we'll send official note to IANA about that.

6.5 Possible Telechat Dates After IETF 110 (Secretariat)

Amy: We only really found one calendar that worked around the retreat week and
the other stuff. It gives you nine formal telechats between 110 and 111 which
is kind of a lot, but that's the way the calendar falls. The only question in
here is the BOF proposal deadline. If you go with a similar deadline than you
had for 110, the deadline would fall around May 28 and you'd have a
coordination call the week of Memorial Day, which would be June 1 Tuesday
through Friday. Then the approval deadline would be the 18th of June. Is there
any objection to approving this calendar? Hearing no objection, so we'll get
this in both the Datatracker and the subscribe-able calendar.

6.6 Discussion regarding draft-ietf-lwig-curve-representations (Erik Kline)

Amy: Erik, this is the document you removed from the telechat and wanted to

Erik K: Thanks everyone who had a chance to review the document and read
through a lot of e-ink. I want to try to find a way to progress the document in
service of the work. My understanding is there are basically three ways to
maybe go forward, but before I try to do a structured discussion I wanted to
give people a chance to say whatever they want to say.

Ben: I guess I should jump into a slightly related topic, which is that I
understand this draft was changed to be targeting a Proposed Standard solely to
meet the IANA registration policy for a couple of the allocations that require
a standards action for some of the code points that have a shorter encoding on
the wire. There was a question that came up at the COSE interim yesterday about
how strict that policy has to be and if the IESG could approve an exception and
allocate one of these code points from the standards action range without
actually requiring the associated documents to be a BCP or Standards track RFC.
I took a brief look at 8126 to refresh my memory and it didn't really look like
that was the case but I promised that I would ask people and if that is an
option, that might open up some other possibilities for how to handle the
document itself.

Erik K: You didn't get to a point where there was an obvious consensus?

Ben: I think it's a matter of interpretation of the RFCs and policies. That's
really a question for the IESG. There was a proposal made that if the standards
action registration policy really is strict then the COSE working group could
write a small RFC to change the policy and allow a case like this, but that
would, of course, incur some additional delay. I'm going to call out Barry and
Alissa as possibly having opinions about how strict the standards action policy
has to be. I don't want it to be just my interpretation that rules the day.

Alvaro: The way I read it is no, there's no leeway.

Barry: What do you mean, how strict the standards action....

Ben: Is there an implicit or IESG approval for any registry, basically.

Barry: The IESG can always approve something if it thinks it needs to, but we
avoid that as much as we can. Standards action means it needs to be a standards
track RFC, and if somebody wants to standardize something in a different
document they can always come to the IESG and give us a good reason. But I
don't think we should mention that in the document.

Alissa: Nobody is really objecting on the substance here, we just mishandled
the process a little bit. We should follow standards action for the IANA
registration bits, but I'm indifferent as to how that gets done.

John: I remember a case ten years ago or more where one of the ADs at that time
who shall remain nameless was really enthusiastic about wanting to do exactly
this process and bypass the RFC publication process. My understanding at that
time, not having been on the IESG, was that it ended up being more work than
publication of the RFC would have been, because they were inventing one-off
processes instead. Second point is that the concern about adding latency by
requiring them to publish a small RFC, isn't that what early allocation is for
so we can approve the code point with the understanding that you'll get your
RFC published in due time?

Barry: Right. If I were the responsible AD handling such a request, I'd really
want a good justification for why you don't want a Standards track RFC and I'd
Last Call the decision anyway to make sure the community didn't object.

Ben: Your last point about Last Calling the decision is related to why I was
thinking the standards action policy was pretty strict, in that standards
action includes IETF Last Call as part of it and if you wanted to just toss an
IESG approval in instead that's not necessarily acting with the community's
input and consensus.

Mirja: IESG approval should also have a call for community feedback before you
approve usually.

Magnus: I want to add one other aspect to this. Even that in the context of
LWIG is somewhat out of their charter. It's a question of how we deal with the
document in general because it is to some extent defining something new. I
understand it has one part which is this is how we can implement something to
make it work, but also a little bit of new specification for doing something
which otherwise wouldn't be done. That part I see as something outside of LWIG.
I don't know how to handle that part but we could fold that part out as a
separate issue.

Ben: So Magnus I think you're trying to get us back on track of the original
question Erik was asking. I agree there's a lot in this document that's
essentially just statements of the universal truth of mathematics, which should
basically be unobjectionable other than editorial questions of how it's
presented. That would be a perfectly reasonable thing for LWIG to produce. But
then we also have these bits about allocating code points, and this is how you
integrate it into other protocols, and that becomes significantly less clear to
me about whether LWIG is the right place to do it.

Warren: While maybe LWIG may or may not have been the right place for it to
have happened, from what I understand it's where it did happen. Is this
document good for the RFC series and is it good for the community to read? Does
this document move forward as is and in the future we need to be more careful
about where things actually happen?

Roman: I'm with Warren. We are where we are, so is this in scope, is this not
in scope, and do we start shopping for a new venue for a document that's close
to done? I don't know if it's worth the effort to me. It seems like if we think
this is worth publishing, let's think through if we're happy with the quality,
and administratively did we run the process to make sure we have confidence on
consensus, and the charter thing we probably should have been better but we are
where we are.

Magnus: Roman, I'm going to ask you a question. How [much] of your security
community has been aware of this work and been involved in it, and how much
would that impact the quality of what's written in this document?

Roman: You're exactly right, that's the key issue. I'll confess I figured we
were pulling this off the telechat so I did not complete a full review of the
document. Initially in my skimming I was concerned that we did a crypto thing
in a non-crypto WG, did we get enough eyes on it? But the thing that was
reassuring to me was that in a very early version of the draft it went to the
crypto panel and they did a full review. Frankly if we made this in a Sec WG,
if we hadn't gone to the crypto panel I would have had a problem with it. The
crypto panel cleared it after providing various feedback. The thing for me,
which is why I want to continue reviewing, is the crypto panel reviewed it in
-00. I'm not even done reviewing whether everything said in -00 got fixed in
subsequent versions, but it looks like there's a huge diff of text between -00
and -19, so the question for me is what else got introduced after the crypto
panel reviewed?

Ben: I think there were a few points from both Roman and Magnus I have some
thoughts about. Magnus, you'd asked about how aware and involved the Sec
community had been in the progression of this document. I think there had been
some level of awareness, Mohit forwarded some old emails from past years
earlier today where I was talking about it, and I'd talked to a couple of
people about it. There was some modest level of awareness this document existed
but to my understanding the participation from the IETF Sec community has been
minimal to nonexistent. I think if we were to go ahead and redo an IETF Last
Call for this document targeting Proposed Standard, especially given that we've
been talking about it recently as well, my expectation is that a repeated Last
Call would bring a lot more participation and feedback from the IETF Sec
community and would likely lead to changes as a result. Roman, you had asked if
we are happy with the state the document is in now and we should look at what
is the best path forward and not necessarily focus too much on what we could
have done differently in the past. That's an admirable sentiment that I
support, but unfortunately I am not particularly happy with the current state
of the document. Like you I did not complete doing my review because I assumed
it would be pulled off the telechat and I put it on the bottom of my priority
list. I have some comments and expect to have additional comments but I'm not
fully happy with the current state of the document so getting an additional
opportunity for some review and feedback would be worthwhile. I don't think it
should just be on the IESG to do this sort of review.

Erik K: Ben, the stuff that you have concerns about are outside of the IANA
registration stuff?

Ben: Some of it is. I was going to have a couple Discuss points like "you need
to do what the COSE expert said." There were also one or two of the points from
that review that may apply to the JOSE registrations as well that I still need
to follow up on. There's some other aspects where we seem to be haphazardly
tossing out some concepts and not going into full detail on them and it seems
like it might be hazardous to the community to mention that this thing exists
and name it but not fully talk about it. I'd want to either not mention it at
all or talk about it differently and go into a lot more detail, which hopefully
is not the preferred option because the document is already pretty long.

Erik K: Ok, I'm assuming there will be some opportunity for you to do that
review and provide some of that feedback in the future.

Ben: I hope it will be in the relatively immediate future, although I can't
guarantee that.

Erik K: It sounds to me like one way or another, people want there to be a
second IETF Last Call. What form that document is in by the time that happens,
I still am not quite sure. My understanding is that there are three possible
ways forward. One is to keep the document in LWIG and try to keep it complete.
This would involve various process exemptions, being Proposed Standard and
possibly not in charter for this work, or back to Informational but with an
exemption either from IESG or work done in COSE to change the registry but some
way where the document can stay where it is and stay approximately whole. A
second option would be for the document to stay where it is but split it in
two. Leave the informational math part in LWIG and leave the code point
registration for another venue. The third would be to try to re-home things,
although I sympathize with everyone who says we are where we are. It seemed
like there were homing discussions back when this was started, but if people
have other strong feelings or recommendations, this is the time to ask.

Ben: Not quite the question you asked, but related to the previous discussions,
I don't actually remember if the previous times I looked at it there were the
significant IANA registrations and other protocol integration features or not.
The current form has some features some people are unhappy with, like the IANA
registrations and the specification for how to integrate it with some of the
other IETF protocols. Magnus referred to that as to why it's only questionably
in charter for LWIG. I don't remember if those portions of the document were in
place in the previous times I looked at the document and had a discussion with
the WG chairs about what venue to do it in.

Magnus: To my understanding this was added in -04 and I think that's around the
time in March 2019 when I stepped in to the IESG. I think there was some
discussion on this particular topic at the time between Suresh, Ben, and
others. I wanted to add that I also think those neutral reviews did not include
those parts, it's something that's been added since the early crypto reviews.

Erik K: Should we request a second CFRG review? It sounded like that was one of
Roman's suggestions.

Ben: It sounded like Roman wanted to finish looking at the diff before deciding
whether to ask for another crypto panel review.

Roman: Precisely. I wanted to squint at it, because it is possible that
everything that changed is not crypto related and is just editorial. I wouldn't
want to impose upon the crypto panel because their resources are limited. But
if it turned out there are new crypto things that got introduced I would like
that confidence. But I need to take a look.

Erik K: So it sounds to me like Roman and possibly Ben want the chance to have
another look before we make any decision about which is the right home and what
form of this document is the right one to reconsider?

Ben: That was not the sense I had.

Roman: For me, again I'm not sure how widely believed it is, I think venue
shopping and the rest of it I don't personally see a need for it. It's in the
WG so let's figure out how we get review and consensus. Others may feel
differently but my feeling is that it's fine where it is and did we get all the
right reviewers. I wanted to see what changed between the last crypto panel
review and if we need to potentially bring them in again, and then I wanted to
finish my usual review.

Erik K: Okay, I look forward to your review, Roman. It sounds to me like the
much more drastic change option of rehoming the document is bottom in the sort
order of paths forward. So I don't know if people favor trying to keep the math
and the IANA registrations whole and together?

Ben: I have at least a modest preference for keeping them together. In the sake
of trying to propose constructive actions, I think it would be reasonable to
keep the draft together with both the math and the registrations and keep it in
LWIG but redo the Last Call for Proposed Standard and possibly ask for another
crypto panel review, depending on whether we think things have changed. That
would be my straw man proposal to see if people can live with it.

Roman: I support that. That's probably more articulately put together. I'm
trying to minimize work, so splitting means more work and potentially more WGs.
I'm not sure it's worth that effort; we have the text we have.

Erik K: Okay. So pending some input from Ben and Roman, a possible second
crypto panel request. I'm assuming we revert to informational and seek
something from COSE and/or IESG exemption during the Last Call? Essentially
during the second Last Call note that this is an exceptional process?

Ben: My attempted proposal for a strawman was to leave it a Proposed Standard.
But it's a strawman and we can change it.

Warren: That sounds fine to me. And also if we do that and for some reason we
downgrade it later, that's much easier than doing it as Informational and then
changing our mind and re-doing more Last Calls. The guiding principle should be
is the document good, and the rest of it is more process stuff.

Magnus: I don't really like this because of the precedent it creates that the
charter of a WG means very little. That's my main objection against not moving
it. if we had somewhere it fits it would be much better to move it there
because it would show we are doing the work where we said we were going to do
the work. It's about the community who can pick it up where their interests are.

Warren: I largely agree with you but I think the document went through a WG
which is not ideal. Redoing a bunch of work feels like it's unnecessarily
penalizing the document author for a mistake that was the WG chair and IESG's
mistake. Yes, it should not have happened where it did, but that's where it
happened. Making the author do a bunch fo work for a failure that was not
theirs and not something that they knew about feels like we're penalizing them
instead of the right set of people, which is us and the chairs.

Barry: Adding something to what Warren said, I do not perceive that this was in
LWIG as a workaround for any process stuff, as any kind of sneaky thing. It was
done in good faith. I think "do the right thing" is what we should be looking

Erik K: My understanding from Suresh was that there was discussion at the time
where it should go, and LWIG was where it landed.

Barry: right, but the result of that was a good faith attempt to put it where
they thought it belonged, not a workaround to keep the security people out of

Warren: Magnus, unless you think it has not been reviewed by the correct set of
people, while I agree with you that the charter is important, if we need to
bang some heads together it should be chairs or IESG and not make authors have
a harder life.

Magnus: I agree with what you're saying that the authors have minimal blame. An
experienced author would pick up this kind of scope creep, because it's creeped
from being within scope to out of scope quite quickly rom my perspective. Yes,
it was discussed and looking from those emails, it was the wrong decision made
by ADs mostly. I just am thinking how do we deal with saying that this is not
precedence and not open this up.  I think we can solve the review thing by
ensuring that this needs to be explicitly notified when it goes for next review
steps to those relevant WGs where it might have impact.

Erik K: For sure when there's a second IETF Last Call we can make sure to have
CFRG notified again and COSE and JOSE as well, and whomever else folks think
should have the Last Call explicitly forwarded to them.

Rob: Another quick question we've not discussed is, would it make sense to
recharter LWIG specifically to allow this document?

Warren: To me that sounds like a huge amount of process wonkery for process
wonkery's sake. I think we'd have to recharter the WG, say there's this
document which you've already done so we're going to recharter you so you can
do this document you've already done.

Eric V: This is what we just did for RTCWEB a few minutes ago, isn't it?

Erik K: RTCWEB was being revived. That's different.

Warren: I think that's different.

Barry: Very different. I actually think we are more likely to get somebody
appealing our decision if we try to recharter retroactively than if we just
say, a bad decision was made but it's the wrong thing right now to pull this
document and let's proceed with it.

Warren: If we were a much more strict standards body which had a lot more rules
and process, maybe recharter, but one of the strengths of the IETF is that we
aim to do the right thing even if that isn't strictly process following. That's
why we have the appeals procedure, etc.

John: Maybe this is also process wonkery, but it's much lighter weight process
wonkery. If LWIG is really the wrong WG and there isn't a right WG, what's the
downside to processing it as AD sponsored instead?

Warren: That's a fascinating idea.

Barry: What benefit does that give us? The WG has already processed the
document. There's no benefit now in saying it's AD sponsored. I think we're
better off just announcing to the community that this wound up not in the WG it
probably should have, but here it is.

Ben: The benefit would be that we stick to the charter and maintain the
strength of the charter as a contract between the IESG and the community.

Francesca: If I understand correctly there was no consensus on changing the
track of this document from Informational to Standards. I'm curious about how
the document can be changed from informational to standard track and suddenly
it's out of scope of the charter of the WG. Why not work on it as informational
and take the COSE registrations if these need to be done separately?

Murray: Is it in the charter as informational?

Francesca: Yes.

Erik K: From my discussion with suresh last night, he thinks so. LWIG is
chartered for informational work.

Francesca: It might need more CFRG reviews but if I understand correctly it's
in charter for informational.

Warren: I feel we've put the authors and WG in a funny situation, where you can
write informational documents but you can't actually do anything with them
because there's some other set of things you want to talk to that require
Standards track. So it feels in some ways like this weird Kafkaesque thing.

Magnus: No, if you're looking at the charter, the charter for LWIG is here's
how you do standards compliant implementations etc. One part of this document
is really that. What's outside of the charter is saying now we're actually
defining additional things and code points. That's where it steps outside of
the charter.

Warren: I agree with that. It's just an ongoing pet peeve of mine that we have
WGs which are only allowed to do certain types of documents and then they can't
accomplish their goal because it's the wrong type of document. I wasn't
specifically referring to this, it's a rathole.

Murray: The reason I asked that question earlier is that as I read the charter
I don't see anything that remotely talks about crypto or what it looks like
this document is doing, so that's why I was wondering if they're chartered to
do this type of work of any status. The document status is an orthogonal
question to should they be doing this work in the first place. But this is not
my area and I'm happy to yield to the ADs.

Warren: From my understanding, no, they're not really, but they did it and it
seems to be relatively good work. A mistake was made, and how do we recover
from this mistake in the least painful way to everyone concerned?

Murray: So here's a question for the Sec ADs, is SAAG chartered to do any type
of work at all, or is it just a dispatch type thing?

Roman: SAAG does no work.

Ben: SAAG is an advisory group, not a working group.

Roman: And SECDISPATCH is a dispatch, so they don't adopt.

Murray: I was just wondering if it could be a joint thing, like LWIG produced
this and then some WG in Sec says we think this is fine too, and now you've got
the coverage you need. I'm thinking out loud here.

Ben: There are some parts of it that would be a fairly natural fit in COSE. The
JOSE WG is closed and related to COSE so you could sort of squint and say
that's a tolerable place. The draft also has registrations for OIDs for use

Roman: That's maybe LAMPS.

Ben: People can do that in lots of places. DTN did one recently.

Murray: I'm slightly worried about setting a precedent where a WG exceeds its
charter and relies on the fact that we gave in this one time and ask us to do
it again. We don't want to redo work, so what cover can we find?

Ben: I want to say we actually did have a situation similar to this where a WG
exceeded its charter and we sort of allowed it but I don't remember it well
enough to look.

Warren: We could do public floggings of chairs and ADs, or we could just say
whoops, that was a mistake, let's try not to let it happen again.

Francesca: I think saying the WG exceeded its charter is not really correct.
I'm not even sure most of the WG was aware of this change from informational to
standard track. It just sort of happened. Without going into looking at who did

Murray: I think [the status change is] only half the question. It's how did we
get here, so far afield, without anybody noticing or stopping and saying wait a
minute, this is outside of our charter.

Erik K: Similar to what Warren was saying earlier, my assumption was that it's
130 pages of math and one page of, if you'd like to use this, here's a code
point. I did not consider the charter when I looked at that and thought it was
fine. It seemed sort of an ancillary outgrowth of all this work to just put the
value somewhere. Obviously I was mistaken and caused a bunch of headache for
many people as a result. Still trying to figure out what to do.

Murray: My point was not to continue to flog you.

Warren: Participants in WGs are largely folks who happen to show up on mailing
lists. We don't have a specific membership criteria. So it's more important to
ask have the right people look at the document, not assume that the right
people looked at the document while they were in the same room. People
participate in multiple WGs and have knowledge in various places. The fact that
it happened in a non-ideal place and let's not do that again, but the important
question is have the right people look at it. Maybe they haven't, but I don't
think they needed to be wearing specific hats while looking at it or not.

Rob: I quite liked Barry's suggestion of doing another Last Call on this and
say we're aware it's a bit outside of the process, but we want to make sure all
the right reviews are done. Otherwise moving it to another WG is a lot of work,
changing the charter is a lot of work. I sort of agree with Warren that we
should try to do the right thing and get this document published and because
it's using a number in the wrong space that has the wrong requirement seems
like a silly reason to make it harder to publish this document. I agree we
should get the right reviews done, but otherwise I think we should try to find
a pragmatic route through.

Ben: Just to clarify, I believe Magnus, you're not objecting specifically to
the proposed standard that was introduced because of the code point range,
you're saying that it fundamentally is a proposed standard based on the fact
that it's doing any allocations at all so changing the range would not help on
that front.

Magnus: It's at least specification work which is where I think the WG stepped
outside of its charter. That's my fundamental thing. I understand that maybe
the easiest way here is to note that something went wrong here and finding a
reasonable solution and being very up front about a process aberration in the
upcoming Last Call. If we're going to keep it as this, we shouldn't downgrade
it, we should keep it standards track and make sure it's the quality we need.
Otherwise I think it should be split to keep to LWIG's scope and move the rest
of it somewhere like COSE.

Erik K: So that would be splitting the document, pulling out the registrations?

Magnus: Not just the registrations; the things in the document that make
specifications for how you take the trick that LWIG describes into something
which is usable beyond existing algorithms.

Ben: So to clarify that it would be in scope for LWIG to do a document that
says there are these existing Ed25519 signatures, but you can implement those
signatures interoperably by using this trick so that your generic elliptic
curve library that works on short Weierstrass curves instead of twisted Edwards
curves can still be used and thereby save you space. But once it steps into the
realm of, you can also do ECDSA over the Weierstrass Curve25519, that's
specifying a protocol.

Magnus: Yes.

Erik K: Thank you for the interpretation, Ben.

Ben: Happy to help. Another thing Magnus said prompted me to ask another
question, which is directed at some of the people who are concerned about
setting a precedent for violating a charter. Is there any text we can put in an
IETF Last Call announcement to clarify that we are not only Last Calling the
document but we are also Last Calling an exception to the charter? Can we put
some language in there that would satisfy you, or do we need to do something

Barry: that was exactly what I was proposing.

Mirja: I'm not sure that creating a completely new kind of process is the
solution here.

Ben: I think John mentioned hat people tried that 10+ years ago and it was a
lot of work.

[long pause]

Roman: I don't know if I'm hearing any excitement around that notion, Ben.

Magnus: From my perspective what creates the least process aberrations is
splitting the document.

Ben: So do we think we could find document editors to work on splitting the

Erik K: You mean find some COSE folks? Assuming the author doesn't also want to
contribute that part?

Eric V: Don't forget we have an author on the call, he might want to state his
opinion. It's clear that the clean solution is better, even if it requires more

Rob: In terms of what IETF is producing, are we saying we want to split this
into two documents because it's easier for the community who are reading it, or
are we saying it's better to split this into two documents because our process
makes it hard to have this as one? It feels like the IETF process is going
wrong if the only reason to split this document is to jump through some hoops.

Warren: I fully agree with that. If it's better for the document and the
community to understand the document, I support that. To me it feels like a
fair bit of this is us trapping ourselves in the process. Our job is to serve
the community and do what's best for the document series and the understanding
of the documents in the community, not wind ourselves around process axles.

Mirja: But splitting off the registration part is nothing the reader could be
super interested in. People often don't even read the IANA section, it should
be registered and that's the point.

Magnus: It's a bit more than just the registration, but I fully understand. To
make it easy I think we should then take the route of Last Calling it again and
saying we're making the exception and seeing if anyone screams about it.
Probably not.

Ben: I think that would protect us from appeal concerns, but does that help
with the concerns about setting up for a precedent that the charter is

Warren: WGs have not frequently stepped outside their charter. I don't think
it's malicious, I don't think it's something people realize; folks start
writing a document, the scope grows a little bit, the scope grows a little bit,
the authors don't initially notice, the chairs don't initially notice, people
are focused on the technical aspects. So yes sometimes it happens. It think the
right thing we do is that we acknowledge the fact that this happened, we
apologize for it, and we try to make sure it doesn't happen again. I don't
think this really sets a precedent, especially if we say we know it was a
mistake and we are sorry. Rather than making things more process-y, we're
trying to do the right thing.

Murray: I think I agree with what Warren's saying. I'm trying to evaluate for
myself why I'm so paranoid about this, and I think it's just that I'm so used
to seeing as soon as someone carves out an exception, someone else will say why
can't I have that? Maybe it's just being paranoid.

Warren: I think the only way that we can prevent this happening is we have new
documents and new work being reviewed by a group which makes sure that
everything is within charter, and when substantive updates are made to docs
they have to be re-reviewed by a set of people who say yes, you are approved to
do this, it fits within your charter. I truly don't think we want to be that
sort of SDO.

Magnus: I think you're overstating it. I have put a topic on the pre-IETF
meeting on how do we avoid this. Maybe it's a time to better educate the WG
chairs and ourselves and ensure that our checklists, etc, includes to check
these things. I know the AD checklist for approval includes checking against
the charter, because I wrote it, but I guess not all of you are looking at it.
I think there are these kinds of steps we can take to reduce risk of these. If
the WG chairs are alert on this it shouldn't happen.

Warren: I think we've all experienced stuff where when we're writing a
document, as it evolves we see it's getting closer and closer to the edge of
the charter. You're so focused on writing the document, you don't want to take
it somewhere else; you're focused on content.

Erik K: We're coming up on 20 minutes left and I want to be cognizant of the
time. I know Roman and Ben want to do a deeper technical review. I heard it's
very clear that however the document happens, there will be a second IETF Last
Call and there are several groups who will need to be notified during the
course of that. The rest of the way out I'm not sure on. Maybe we try to solve
it on an email thread or I can send out a doodle poll, or we can bring it back
as a management item next week.

Mirja: Maybe you should discuss it with the authors and chairs. We've discussed
a few options and maybe they have a preference.

Warren: While they're on the call I think we should also just apologize to the
authors. Sorry this happened and I don't think this was their fault. Lots of
extra work for stuff that was opaque to them.

Erik K: Definitely. And that's a good idea, Mirja. I'll pick it up with the
author, the shepherd, and chairs, and I'll either bring it back as a management
item or on email after we've had a chance to discuss it more. Thank you
everyone for the time.

6.7 Pre-IETF 110 Agenda (Alissa Cooper)

Amy: Alissa had to leave early. Currently there is only one thing on the
agenda; please put anything you want to discuss on the website she gave the
link to and note whether you think it's a joint IAB/IESG discussion or IESG

6.8 IETF 110 Agenda (Eric V)

Eric V: There was a conflict between DNSSD and ADD and we couldn't figure out
anywhere to move it. It looks like now on the Friday first session there is one
open slot. Can WE move DNSSD and HOMENET to the first session on Friday?

Liz: They both conflict with CORE, which is in that slot -- is that okay?

Eric V: I checked with the chairs and this is an old conflict that's not really

Liz: I can go ahead and move both DNSSD and HOMENET to that slot.

Warren: While we're doing this, after we moved something we had IOTOPS and ASDF
that's bad too. Is there a way to fix that?

Liz: ASDF can move to the spot DNSSD and HOMENET just left; they don't have a
conflict with anything there. I can't remember if that will be an AD conflict

Francesca: That's fine.

6.9 [IANA #1184206] Designated experts for RFC 8879 (Ben)

Amy: Ben has identified three people. Any objection to approving Yoav, Rich,
and Nick as the experts? Hearing no objection, so we'll send official note to

6.10 [IANA #1187734] Designated experts for RFC 8855 (Murray)

Amy: Murray has identified Brian Rosen. Any objection to approving Brian as the
expert for this registry? Hearing no objection, so we'll send the official note
to IANA.

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