Skip to main content

Narrative Minutes interim-2021-iesg-16 2021-07-15 14:00

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

Narrative minutes for the 2021-07-15 IESG Teleconference

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

1. Administrivia
1.1 Roll call

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

Michelle Cotton (ICANN) / IANA Liaison
Jay Daley / IETF Executive Director
Francesca Palombini (Ericsson) / Applications and Real-Time Area

Lee-Berkeley Shaw
Greg Wood

1.2 Bash the agenda

Amy: Does anyone want to add anything new to today's agenda? Any other changes?

Lars: The only thing I would add is to discuss the email policy.

Murray: I don't know if we should make a management item this time or next time
to approve the I-D checklist.

Lars: Has it gotten enough review by authors, chairs, or if we publish it will
we get a lot of emails that it's wrong?

Murray: It hasn't circulated outside the IESG apart from Robert and IANA. If we
put it out for general review it's undoubtedly going to draw a ton of feedback.

Lars: Maybe we do need a management item to figure out what to do.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the July 1 teleconference
being approved? Hearing no objections. Does anyone have an objection to the
narrative minutes from July 1 being approved? Hearing no objections; we will
get those posted.

1.4 List of remaining action items from last telechat

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

Amy: As we just discussed, we'll add a management item to discuss next steps
for this.

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

Warren: In progress.

     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.

Alvaro: [These two] are both in progress. What we think we want to do is tie
these with the next one which is about updating the shepherd writeup template
so we can put something in there and then ask the WG chairs to make sure that's
filled out all the time.

     o John Scudder and Martin Duke to review the document shepherd
       templates and propose changes to include updated questions and
       cross-area checks.

John: This is still in progress.

     o Rob Wilton to draft text to expand the document shepherd write-up
       section on use of YANG Models.

Rob: I've not done anything on this yet but I wonder whether it would be better
to fold this into the previous item since it's related. John, Martin, any issue
with merging these together?

John: No issue.

Martin: No problem.

Amy: Okay, we'll merge these two about updating the document shepherd templates
and then we have two more that depend on that. Alvaro, you're going to have
them add a bit of text?

Alvaro: That's right. I'll review that.

     o Eric Vyncke and Francesca Palombini to draft text for guidelines/
       best practices for directorate reviewers.

Amy: I know we had a discussion about this last week; is this done?

Eric V: There is more to do and we had a very interesting call with Jean
Mahoney. It needs to be written down on the wiki page.

     o The IESG to report on the RFC 8989 experiment after the 2021 NomCom
       is seated (likely July 2021).

Lars: Gabriel sent a message proposing a timeline and I said it's okay. The
timeline said July 19 which is next Monday, is when the NomCom is officially
seated. That's when we should start officially consulting with the NomCom
chairs. He proposed September 1 to publish this report and I said it seemed
reasonable, specifically because the report will likely find that diversity was
not materially increased because only two additional people qualified to path
two -- other than path one, only two additional people qualified which doesn't
add much diversity. That will be the result and therefore we're not going to
dive into defining diversity. If anyone doesn't think we can get this done by
September, now would be the time to say. I guess this is in progress.

Roman: With the cutover to the new NomCom happening next Monday, [there is an
attempt to] try and get the whole group together for the first time and that
date has not yet been decided.

Lars: Do you think that's what counts as formally seated, when they have their
actual first meeting?

Roman: I don't know, but there's an attempt to get all the parties that have
been named to get together so it seems informally like that will be the seating
of the NomCom.

Lars: I don't think the community will care very much that we started on the
exact date as long as we produce the report in a timely manner.

     o Murray Kucherawy to update BCP 97 to provide guidance about handling
       normative references to non-SDO documents.
     o Murray Kucherawy to find designated experts for RFC 9036
       [IANA #1199105]

Murray: These will both probably be resolved during IETF 111.

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

Warren: I had thought we were waiting to see the number of additional

Amy: I'll get that early next week and add it to the document.

Rob: Is the IESG-only meeting the best one for this or should we discuss
jointly with the IAB?

Amy: Seeing as both of your agendas are pretty much empty at this point, you've
got agenda time.

Rob: I wanted to see if people were interested. Is anyone opposed to sharing
this with the IAB?

Lars: I think it's a good idea. The current IAB seems to have the desire to be
informed of many things, for instance we're thinking of having the tools people
talk to the IAB about what they're doing.

Amy: Okay, so this will happen at the Friday meeting.

     o Lars Eggert to update BCP 45.

Lars: Before my vacation I did post an update to the individual draft and
people seemed to be fine with it. I got some minor feedback from Mark
Nottingham that wants the website to be better to point newcomers at these
lists, which is fine but doesn't really go in the BCP. I think this is probably
done for somebody to AD Sponsor and then we can do a Last Call. Somebody
volunteered to AD Sponsor this but I forgot who. Maybe Roman? If not, I need

Rob: I think it might have been me.

Lars: If you want to take it on, that would be appreciated.

Rob: Sure. Can you point me to the draft offline?

Lars: Sure, I'll send an email. So this one is in progress.

     o Lars Eggert, John Scudder, Ben Kaduk, Mirja Kuehlewind, Murray
       Kucherawy and Warren Kumari to work on short-term improvements to
       "IETF Culture, Toxicity, Inclusion."

Lars: In progress. Since I've been on vacation we haven't scheduled a meeting

     o Eric Vyncke, Lars Eggert, and Rob Wilton to work on improvements to
       authoring and reviewing tools.

Eric V: I didn't post the draft before the deadline so it's in progress but
there hasn't been any more progress.

     o Francesca Palombini to find designated experts for RFC 9039 [IANA

Amy: Francesca cannot be with us today but she will pick this up when she

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-curdle-ssh-kex-sha2-19  - IETF stream
   Key Exchange (KEX) Method Updates and Recommendations for Secure
   Shell (SSH) (Proposed Standard)
   Token: Benjamin Kaduk

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

Ben: Yeah, we should talk about that briefly. The main point here is that the
author was proposing to add some stuff to the IANA registry. It sounds like
adding a new column. The data for this new column will come from table 12,
which is in section 4 of the document. IANA had asked if we should be adding
one new column or two new columns, because this table in the document has both
the previous recommendation status and the current guidance. I thought this
would be a straightforward thing that we could just add one column with the
current recommendations and there's no reason to put in the registry what the
previous recommendation was, but the authors seem to think that having the IESG
talk about this would be useful so I said we could talk about it. I think it
should be pretty straightforward to get an answer to the question and get that
into the document as more clear IANA considerations. I'm going to propose we
just add the one column with the current implementation guidance and ask for
any objections to that.

Lars: It seems fine. I don't understand why you'd want to keep the historic
stuff there.

Roman: It will be confusing when people don't know the history.

Lars: Are you saying we should keep it and add two?

Roman: No, I think we should do what Ben said. I endorse his proposal.

Ben: Okay, I'll get back to the authors with that and we can get an update
posted that gives clear guidance to IANA. This will be Revised ID Needed.

 o draft-ietf-netmod-nmda-diff-10  - IETF stream
   Comparison of NMDA datastores (Proposed Standard)
   Token: Robert Wilton

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

Robert: I've had a look at the comments and I think that's correct. Thank you
for the reviews and comments. I think some of these will require a Revised ID.

Amy: Okay, this will go into Approved, Announcement to be Sent, Revised ID
Needed and you can let us know when it's ready.

 o draft-ietf-core-yang-cbor-16  - IETF stream
   CBOR Encoding of Data Modeled with YANG (Proposed Standard)
   Token: Francesca Palombini

Amy: I have a couple of Discusses in the tracker. Do we need to discuss those
today, even if Francesca's not here?

Ben: It may be worth talking about my second point, which is the relationship
between this document and draft-ietf-core-sid. We have at least a couple people
who think they should be normative references on each other, because currently
this one only references SID informationally.

Rob: I agree with Ben here, that the way these documents are structured
together, they need to be normative references. I can't see there being an
alternative SID format with how these are defined.

Roman: I tend to agree. For me it's less about envisioning whether you could do
it a different way, it's would we want to do it a different way. I don't think

Rob: Without Francesca here, I'm not sure. We may need to have a discussion
with her.

Ben: It's possible. It seems like we've petered out for a discussion here,
though, so we should move on.

Amy: We'll keep this in IESG Evaluation, and it sounds like we should do an AD
Followup here.

Ben: I expect some of the other ones will require a Revised ID, but leaving it
in AD Followup is fine too.

 o draft-ietf-core-sid-16  - IETF stream
   YANG Schema Item iDentifier (YANG SID) (Proposed Standard)
   Token: Francesca Palombini

Amy: I have several Discusses for this; do we need to discuss any of these

Rob: I think most of them fit into the same category as the previous one. The
two documents are closely tied together and some of the issues I've raised on
one of them apply to the other as well. I think we need to wait for Francesca
or the authors.

Amy: Similar state, AD Followup, or Revised ID, do you think?

Rob: I think AD Followup is probably good. Some of these might be a bit more
than a Revised ID.

 o draft-ietf-sfc-nsh-integrity-06  - IETF stream
   Integrity Protection for the Network Service Header (NSH) and
   Encryption of Sensitive Context Headers (Proposed Standard)
   Token: Martin Vigoureux

Amy: I have several Discusses for this; do we need to discuss any of these

Martin V: No, I don't think so, for two reasons: one, Mohammed seems to be on
top of pretty much everything, and the other reason is that it largely goes
beyond my field of expertise. Rather than saying crazy things, I should skip.
There was one item I could discuss, which is Murray's, but you've promised to
go through the thread and come back to the authors.

Murray: Yes, that's happening as we speak.

Martin V: Okay. So I'm happy to discuss but I'm not sure it will help anyone.

Murray: No. I'll be clearing probably within the hour.

Martin V: On the security aspects, I'm not sure I can be of any help here. The
only point, Ben, is that the authors pointed out to me that 18 months ago they
went to SAAG's mailing list to discuss that specific first point you raised,
and sadly there was no followup. They're a bit disappointed that it came up
only now.

Ben: Thank you for pointing that out. I should go take a look at what happened

Martin V: They are willing to address it, of course.

Ben: Yes. It's unfortunate that it only came so late.

Martin V: That's what they told me, but that's life. Okay, this draft will
definitely need a revision so we can put it in that state.

Amy: Great; this will be IESG Evaluation, Revised ID Needed.

 o draft-ietf-shmoo-cancel-meeting-05  - IETF stream
   Considerations for Cancellation of IETF Meetings (Best Current
   Token: Lars Eggert

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

Lars: This will also require a Revised ID, there were a bunch of editorial
improvements and I think Martin said he was going to roll a new version.

Martin D: All the comments except Murray's are already in the editor's copy, so
I'll do Murray's today and then...can I publish a new version right now or are
we in the blackout?

Amy: We are in the blackout, but you can get Lars to approve it for you.

Lars: Do we enforce the blackout even for stuff that's with the IESG? I thought
we didn't.

Murray: It's usually about WG documents.

Martin D: If the tooling won't stop me, I'll do it.

Amy: The tooling isn't smart enough to know that the IESG state is something it
needs to pay attention to. You can approve it, though.

Warren: This is something where it feels like we might want to be kind of
careful. We often approve [documents] that are in this state for WGs, but where
it's us does feel like ...

Amy: It is a WG document, it's just written by someone on the IESG.

Warren: That's true. I take back my concern.

Lars: Let's wait until the Monday of the IETF week. So, Revised ID Needed.

2.1.2 Returning items

 o draft-ietf-bess-evpn-inter-subnet-forwarding-14  - IETF stream
   Integrated Routing and Bridging in EVPN (Proposed Standard)
   Token: Martin Vigoureux

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

Warren: I have a quick question. Roman's comments are "I support the discuss,
etc." I often find myself doing similar comments but it feels weird that the
only way we capture that is by sticking it as a piece of text in the middle of
a ballot. Supporting a Discuss does have actual meaning. Should there maybe be
some better way of doing it? Like another ballot state other than Discuss or No

Lars: This got started when I was AD the first time. Back then we'd file a
Discuss that said "I support this Discuss," but then the author or sponsoring
AD had to chase a bunch of other ADs to clear. At the time we decided the first
person who raised it or the person who expressed it best, we're going to let
them hold the Discuss and the rest [are] just basically comments. But I agree
it's not ideal from a tooling perspective.

Roman: I think some of the process nuance, why it gets a little difficult, is
I've seen folks say "I only support point 2 of this Discuss" and there's no
easy way to have a pointer to that, vs what I did here which is basically
giving a thumbs up to everything that got said.

Warren: I just feel weird when I say "no objection, other than the fact that
I'm supporting someone's Discuss point" and if we ever end up again in the
single Discuss override procedure, supporting a Discuss is actually a strong

John: That seems like an exceptional enough case that we can go through to read
the comments.

Warren: Okay.

Martin V: I didn't check, did they publish a new version based on your comments?

John: No, I'm waiting. We did come to closure about what they're going to do,
so I cleared on that basis. It's going to need a new ID.

Martin V: Okay. Anyway, they can't post right now, but I'll wait for that
before doing anything.

Amy: Okay, so this is Approved, Announcement to be Sent, Revised ID Needed.

2.2 Individual submissions
2.2.1 New items


2.2.2 Returning items


2.3 Status changes
2.3.1 New items


2.3.2 Returning items


3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-opsec-ipv6-eh-filtering-08  - IETF stream
   Recommendations on the Filtering of IPv6 Packets Containing IPv6
   Extension Headers at Transit Routers (Informational)
   Token: Warren Kumari

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

Warren: I guess yes, please. Mainly just to note that this document has been
around for a long time, since 2014, and it went through IETF Last Call in 2018,
and then it got weird and stuck. So I think that explains at least some of the
reasons why it's become messy and out of date. The authors are a little
frustrated and twitchy, so yes these are all valid points and we'll get to
them, but if the authors seem abrupt or frustrated, that's some of the
background reason. That's all.

Roman: Understood, thanks Warren. I'm going to have to probably put this in
email but I think one of the things that could help clear up perhaps some of
the discuss positions I have is more clearly framing that history, that I know
you have explained and I've seen in the followup dialogue. For example, to me,
what is a transit router is apparently not as clear as it is to some other
parties, and some implicit assumptions for where a transit router is, whether
it shares administrative domains, if we tighten that up I think that would help
with a lot of the things I have.

Warren: Awesome, thank you very much. The authors should be fairly responsive.

Amy: Great, that will stay in IESG Evaluation, Revised ID Needed.

Eric V: Just a side thing. I've abstained on this because I'm the document
shepherd. Roman, I see your second paragraph about HIP, which is one of my WGs.
Why would a transit operator like to forbid its customers from using it?

Roman: I think part of this comes down to what is the definition of a transit
thing? The point I'm making is that it's an inconsistency. We decide at some
point that the operator, or whoever is operating the transit router, that RSVP
and multicast routing is bad, and you need to make a judgment call whether you
want that on your network. My observation is, ok, so if you're willing to make
a protocol specific judgment call, why wouldn't you do that for everything?
It's HIP and a couple of others, where if you're at that level of deciding
what's okay, that opens the box for everything. I think that's different. What
I'm hearing the tone of this is to say all the things that are deprecated
already through our documentation, filter that, but leave everything else.

Warren: I think part of this is that things like HIP are fairly similar to
IPSEC. If you're an ISP and traffic comes through and it's IPSEC, you can't
really make a useful decision based upon it so it's probably a bad idea to drop
it. I think HIP falls into that same category that you don't know what is
likely to be in the payload but whoever has set up the connection probably
wants that traffic. But yes, I understand what you're saying.

Roman: That makes sense. What I'm hearing in both of your comments is this
implicit assumption that I guess I don't track, which is that a transit router
means an internet service provider that has no knowledge of their customers.
What I read in the definition was that a transit router is moving packets that
aren't destined for it. To me that's very different.

Warren: Yes. okay, thank you. The clarification of where they think this should
go. Some of this is that the authors still have scars from the previous one so
the wording got twitchy. I should point out that the previous time this came up
in 2018, there was huge drama and people being beaten with bit sticks. Anyway,
thank you.

Amy: Okay, thank you. Let's move on.

3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items


3.2.2 Returning items


3.3 Status changes
3.3.1 New items


3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items


3.4.2 Returning items


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


4.1.2 Proposed for approval

 o Media Type Maintenance (mediaman)

Amy: I have no blocking comments. Is there any objection to approving this new

Murray: Two quick points: one, I haven't found chairs yet. That's also
something that probably won't happen before IETF 111. If you look at my yes
ballot, there's one edit in case anyone's interested in checking it out, that
was proposed and appears to have consensus. Then I think we're going to have a
quick conversation about the name of it.

Ben: Your proposed change in your yes ballot seems fine. I did put in my ballot
another potential change, that's not quite the right word. We currently say
something like the product of the WG will be based on this specific individual
draft, and that seems perhaps a bit restrictive.

Murray: I can tweak that accordingly. The strictness of it was not intentional.

Ben: I figured. I was also too chicken to send that comment to the actual WG
list in my initial comments.

Murray: As far as the name, the issue was raised that it ends in "man." Quick
recap for anyone who hasn't read the thread: I just picked mediaman based on
the way 6man, which is IPv6 Maintenance, this is just a maintenance WG. I
couldn't find any good examples. All the other uses of "maintenance" in past
WGs have been part of acronyms, so we don't have an out to justify it there. I
think the strongest argument for not changing it is that Amy said it would be a
nightmare for them to change it now. I think I saw Lars say that this is just
something we should pay attention to in the future and let this one go.

Lars: I agree. Amy's point trumps everything.

Amy: Okay, so it sounds like mediaman is approved as mediaman, pending chairs.

Murray: Amy, should I make those edits now, or when the chairs are selected?
How do I make a final edit to the charter before it ships?

Amy: You can make that edit at any time before the chairs are named. Once the
chairs are named, you'll let us know it's ready.

Murray: Okay, thank you.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval


5. IAB news we can use

Martin V: The IAB has published a statement on inclusive language; you might
have seen that on the mailing list. Also, on the liaison coordination role, Wes
and Tommy are having discussions with all the liaison managers to reevaluate
the global situation. It's still a work in progress but they might come with
suggestions on things to do in that space.

6. Management issues

6.1 [IANA #1200145] Management Item: Acceptance of media type registration from
standards organization Gedcom (IANA)

Amy: We discussed this briefly last time but decided the right people weren't
there to discuss it with, so we brought it back.

Ben: I think I forgot a little bit about the actual process needs here. If I
remember correctly there are a couple of different aspects relating to whether
this can be sent to the media type reviewers with the blessing to go as a type
in the standards tree, and then it's a separate question for whether or not
this organization is listed as organizations that can register types in the
standards tree without coming back to the IESG?

Murray: Without a standards action.

Ben: I'm not sure how much that helps. I did open up the document and it does
look like a standard, but the group itself didn't necessarily seem like a
standards body that we expect to be doing a lot of these things. I was
wondering if there's a way to get this a media type from the standards tree as
opposed to the vendor tree, but not list them as a standards body that can do
this again.

Murray: I'm reading from 6838, "The standards tree is intended for types of
general interest to the internet community. Registrations in the standards tree
must  be either 1. in the case of registrations associated with IETF
specifications, approved directly by the IESG, or 2. registered by a recognized
standards-related organization using the "Specification Required" IANA
registration policy." So if they publish this specification and we take this
action, they can make registrations directly in the standards tree without
coming through us first.

Ben: So I guess the action here is that we really do have to approve them as a
standards development body.

Murray: For these purposes, yes.

Lars: Is there any information on them? I'm looking at the website and I don't
see a lot.

Ben: They do genealogy tracking, and that's their main thing.

Lars: The copyright of the latest edition is owned by a person called Tamura
Jones, and they're free for download, but copyrighted. It's not clear whether
this is actually an organization or a person.

Ben: It's a little hard for me to claim that we should recognize this as a
standards development organization.

Murray: Who brought this action? They asked IANA to get us to approve this and
that's the backing for it? Does anyone remember who added this?

Amy: This came from IANA. Sabrina is still here, maybe she can talk about it a
little bit?

Sabrina: Yes, that's correct. Michelle Cotton submitted this management item
for the last telechat and I'm just reviewing her notes here as well. It looks
like based on the last telechat we wanted to wait for Murray to be on the call
because I think Ben, you also brought us some security issues. Michelle just
forwarded some additional information late last night. I'm not sure if you've
had a chance to review that. We're waiting for approval and upon approval we'll
ask the expert to review it as well.

Murray: There's a wikipedia page about Gedcom but it's about the file format,
not the standards body that claims to maintain it. I can take up reviewing this
with Michelle and come back with a recommendation. I would have done that last
week but I didn't know this happened on a week I was away.

Amy: Unless there's an objection, I think getting more information is probably
a good thing. We'll keep this in our list of management items and hopefully
everyone can connect for the next call.

6.2 [IANA #1201198] Designated experts for RFC 9039 (IANA)

Amy: This is just to assign this action item to Francesca.

6.3 [IANA #1203392] renewing early allocations for
draft-ietf-idr-segment-routing-te-policy (IANA)

Alvaro: This draft is already in WG Last Call and there are already
implementations so we should definitely renew this for at least one more year.

Amy: Any objection to renewing the early allocation for this document?

Lars: How far are they from publishing?

Alvaro: WG Last Call.

Lars: Oh, okay, that's promising. I'm good then.

Amy: I'm not hearing any objection so it looks like this renewal is approved.

6.4 Forum for publishing draft-ietf-lwig-curve-representations (Ben Kaduk)

Ben: Lars has a Discuss ballot on the document and it would be good to discuss
that today. Even if I don't have my comments ready I think we should still try
to figure out how this document can get published without violating somebody's
charter. We don't need to serialize the different tasks here. So this is mostly
just a placeholder in terms of me being the owner here. Lars, did you have
further thoughts?

Lars: I think I put it all in my Discuss. In case you guys haven't seen it, I
looked at the LWIG charter. This document was moved from Standards Track to
Informational and that's great but from my reading of the charter, LWIG isn't
chartered to work on this at all. The charter talks about network layer and
transport layer protocols that they're supposed to work on, and then it
actually has a list of 8 or 10 different protocols they're supposed to work on.
A, this is not a protocol, and B, it's nowhere near those protocols listed. I
think it's really simply not something for LWIG to work on and I think the
chairs dropped the ball here when they took the document on and it should have
gone somewhere else. I do understand this is actually reasonable work, I'm not
an expert here but it seems fine to me, so we should publish this. I don't want
to just say okay, we'll do it through LWIG, because it will set a precedent
that we just let WGs go beyond their charter. CFRG might be an option but it
would require another pass through the community, which isn't super great. One
thing I dreamt up is whether someone at this point could AD sponsor it and we
basically take it forward as Ben's document or whoever else wants to take it.

Erik K: My understanding is that when this came up under Suresh there was a
discussion of where to house this work. I forget with whom Suresh consulted.

Ben: I believe I was on that thread.

Erik K: Under the spirit of lightweight implementation guidance, this was a way
of trying to have one implementation that can do many different things.

Lars: I get that, but it's not just the title of the WG that counts, there's
this whole piece of text below it that says something a little more
constrained. If they had only updated the charter we wouldn't have this
discussion now. That would be the other way forward, but then you have to do
the pass through the community for the charter update.

Warren: To me it still feels like we're punishing the author or authors, and
somewhat current AD, based upon some decisions that were agreed to by a
previous set of IESG/AD people who said they could do it there. It feels like
we have become a slave to a piece of process where we generally try and follow
'just do the right thing.' I don't understand why we can't say we're doing
this, it doesn't set a precedent but it's the right thing to do, so we're doing
it. Maybe I'm missing something.

Erik K: I think that's what Lars is trying to do; find a way to publish it
without setting a precedent.

Lars: We might be able to put something into the document announcement, when
the email goes out. If we customize that and basically say 'this document is
published. Although it's out of scope of the LWIG WG, based on the reading of
the current IESG, we are publishing it under special approval because everyone
agrees it's reasonable work.'

Warren: I don't think anybody other than the IESG cares about this. As long as
there aren't WGs saying 'you're working on stuff I should be working on…'

Roman: To pull on that thread a little, Warren, I think there is some overlap
with other existing work in the IETF. There's all sorts of talk about COSE
stuff, and there's PKIX and CMS updates being done as well.

Warren: Have people in any of those WGs said this work conflicts with mine, or
we should have been involved in this, or you're breaking my protocol?

Roman: Yes, I think Ben has identified where there is some threading that needs
to happen with an existing COSE document.

Erik K: The document grew in scope over time. It was felt that why define all
this new curve stuff without defining the code points and the little
registrations which are necessary to actually make it useful? That has caused
lots of COSE/JOSE interactions that I have had to leave to Ben.

Roman: I'm not going to make a clear policy statement because I don't think
it's entirely clear, but traditionally what we do is we have some entity define
a crypto document, which says this is the crypto transform, here's the
algorithm. Then we have associated WGs that then want to use that in their
protocols, they pick it up and find the right identifiers to take that
algorithm in their protocols and add those code points. This document tries to
be very helpful to make that end to end solution but the thing that's missing
is that none of that binding to be used in a particular protocol is clear
that's in LWIG, at all.

Erik K: My understanding of what Lars wrote was that even if we were to remove
all the IANA considerations, because that was one of the options we had last
time when Magnus raised his Discuss, was to try again with removing all the
IANA considerations. It sounds like Lars thinks it's still not in scope for

Lars: I read the charter that way. It's related to the overall topic of LWIG
buf if you read the actual charter text, it's not part of the technical area
that's chartered as approved for work. That's where they should have added a
bullet item or a paragraph. I wonder, the more I think about this, whether the
right way forward here is to add a paragraph to the document announcement.
Usually we say 'this is a product of the LWIG working group' but we can say
'although the IESG determined the work item was outside of charter, it had
progressed to the point over a number of years that it's better to publish.' I
don't want to make up the words right now, but let's customize the document
announcement so that there's a record of what happened and why we still
published it through LWIG, and let's publish it through LWIG. That might be a
way forward.

Erik K: Like the IESG note that we add on conflict reviews?

Lars: No, I don't want to put anything in the document. There's an email that
goes out that says we have a new RFC available and there's some boilerplate. I
think the chairs prepare it and then the AD copies it into the datatracker as
part of the announcement email. If we customize that announcement text to
explain what happened and why we're still publishing it through LWIG, that
would be fine.

Martin D: Lars, does making a statement about it amplify the precedent? If
we're just quiet about it, is that maybe better than calling attention to the
fact that there's a loophole?

Warren: Maybe, except that I don't think anyone's likely to read it and notice
it. If they do, all they're going to see is that this document isn't strictly
within the charter but we published it anyway. I understand where you're coming
from but I don't think most people are going to notice it.

Lars: I don't think they're going to notice it, but on the off chance that
somebody asks how the heck did LWIG publish this, we can point to a record of

Warren: I agree with Lars on this actually. That seems perfectly reasonable.

Erik K: If we do that, is that sufficient? I can propose some announcement text
before pasting it in the datatracker. The datatracker allows me to save
multiple revisions of the announcement text before it goes out.

Lars: I would be fine with that.

Ben: On the face of it, it seems like that would be enough. Unfortunately, one
of the comments I got privately on the document suggests that the document may
not have gotten enough review by technical experts that understand its contents
in its current form. That maybe throws a little bit of a wrench in it; does it
actually have consensus to be published? I don't have an answer for that.

Warren: I view that as a proper problem we need to deal with. That doesn't feel
like process issues, that feels like more of a real thing.

Zahed: I agree with that.

Warren: I don't know how we get whoever raised that concern to do a once over.

Erik K: I've reached out to request another crypto panel review of the latest
revision, but that's not the same thing as what Ben is talking about.

Lars: Ben, the people or person who raised that, can we make them review it?
There was ample chance to review these documents. Maybe someone didn't catch it
because it was in a WG they didn't expect it to be in, but we have IETF Last
Call. There was some time at least.

Ben: I definitely forwarded the last call notice to SAAG to try and raise

Lars: Given that it's not on the agenda anymore, does that give them time to do
this and take this forward in your ballot?

Ben: I did get a little more detail. The technical issues are things I should
be able to dig into and put into my ballot if they're actually valid concerns,
so I think I have a path forward for that.

Roman: We should also wait for a time estimate from the review panel and use
that to help us set the date.

Ben: It would be good to have a time estimate from the review panel. To back up
to my previous bit, the potential technical concerns sound like things that
were raised in earlier discussions and the discussion may not have reached an
actual conclusion there, which would be also unfortunate. I think those would
have been discussions that took place not on the LWIG list so the chairs and
ADs didn't necessarily see them to know they should be tracking them, so it's a
little bit of a mess.

Sabrina: I'm not sure if this would help but I'd like to point out that as far
as the IANA Considerations section goes, we had to ask the COSE and JOSE
experts again yesterday to review the latest version. One of the COSE experts
said as far as he is aware, his review has not been addressed and he's
referring to the detailed review he provided back in February.

Ben: Right. I believe that is correct and I have a separate thread with the
author where he is proposing some changes that I believe will address at least
some parts of the expert's review. There are a lot of threads going on in
parallel for this document.

Lars: I think it's fine to explain to the author, and I can do it if you think
that would be helpful, that because this document was in a WG where the usual
suspects didn't necessarily see it and track it during its development, that he
needs to be okay with a little more time being spent on these reviews now, some
of which would probably have happened over the years otherwise. Then hopefully
by August 12 we know where we are. My Discuss, which is on something else, that
could be addressed with this writeup text but i'm going to leave it in there
for now.

Erik K: When I was backchanneling with Ben and Roman yesterday, the actual
issues and actual technical Discuss points are all things that obviously need
to get addressed, it was the meta point Magnus had raised before about where to
do the work that I wanted to resolve. All of the technical things definitely
need to get addressed but I just wanted a management item to go through to
address the other stuff.

Martin D: Is there a time difference between sending it straight to CFRG last
call, which would cross the Ts procedurally, but does that actually create more

Lars: The IRSG would then need to review it and then we'd need to do a 5742

Ben: And the CFRG chairs are only sometimes prompt about getting the RG Last
Call going.

Martin D: Is there something in SEC area that's a good fit for this?

Ben: There's not really a perfect fit; there are a couple options that might
fit, COSE or LAMPS.

Roman: In the ideal world, which we're not in and I'm not arguing we should
have, we would take the definition of the crypto transform, have the IRTF give
us an informational on that, and we'd have COSE and LAMPS publish the
identifiers for it.

Erik K: That's still on the table technically, isn't it? All options are still
on the table.

Martin D: The bureaucratically correct thing to do is to pass it through some
other more properly chartered WG, but I'm very conscious of jerking around the
authors. If we're talking about doing a crypto review anyway...none of this is
work I'll be doing, so I don't want to volunteer anyone for anything, but I'm
just throwing it out there as maybe a path out of this to solve some issues
that are creating a lot more pain.

Erik K: The WG adopted this back in October of 2018 so it's been going on for a
while. It's easy to see that one could be frustrated by certain things. The
lack of a clear path forward is more frustrating  than just the time it takes.
Being told to do something and then being told to do something different.
Whatever the right thing to do is, I'd just like to figure out what that is.

Martin D: I guess the judgment to make is whether a formal WGLC would actually
improve the document? Is that the proper venue to get enough review?

Ben: The WGLC is not exactly a required step of the process. Chairs have to
assert there is WG consensus and it's hard for there to be WG consensus if you
don't have some core body of people who have read the thing and understand it.
I can't speak to whether that's the case for LWIG, but it's certainly not
currently the case for any of the other WGs we're talking about. It would be
weird to have a WG rubber stamp it in a WG that hasn't looked at it before.
You'd need to actually have some feedback occurring by people saying 'I read
this and it makes sense.' We don't really have much leverage to get people to
do that.

Martin D: Lars mentioned AD Sponsoring. Ultimately what we need to do is have
an AD supervise a process where there's some cross-area review. That's what's
going on. It does kind of sound like an AD sponsoring process, doesn't it?

Ben: It does. Unfortunately I've been taking way too long on the documents I'm
currently AD sponsoring to be enthusiastic about picking up another one so I
don't want to volunteer in this case.

Roman: It's a bandwidth thing. We should give the author the courtesy of a
defined path and a defined timeline.

Erik K: This is in one of my WGs so I could try to AD sponsor it. I don't know
if it actually lessens the time that would be required of Ben for some of the
other rpoints, but maybe it would.

Roman: I will set aside the other [pieces] and focus on [the question] are we
confident that the technical contents of this document are there, and leave it
at that. If we proceed down the path of getting the crypto panel review to look
at that, I think the combination of the questions that are going to be run
through the COSE WG will probably fix most of the IANA issues. Between that and
the organic review that Ben and I will do on it, I think we can have confidence
that it technically says good things. As to whether people care about it, and
whether we followed the process, that's a different class of engineer.

Zahed: On that note, I think we just decided to just put something on the
announcement text and publish it through LWIG as an exception. Let's just do
that. When it comes to the content the questions raised will be addressed.
Whether it's through LWIG or not, I thought we decided it so I don't know why
we're convoluting this question again. Let's just say Lars's idea was good and
then focus on the content of the document. I don't think there's anything else
we can do.

Martin D: I believe we've come to a consensus on the substantive action, which
is Ben and Roman are going to informally supervise an additional review process
to make sure the crypto content is good. One thing is to ship it as an LWIG
document with this [announcement text]. A second thing is to have it be AD
sponsored, whether that's Erik or a SEC AD is orthogonal. That's the only thing
we're still discussing. If Lars is fine with the [announcement text], does that

Lars: The [announcement text] works for me for addressing the out of charter
issue. Getting it adequate review is orthogonal.

Zahed: My question now is do we believe it needs more review? [Several yeses].
Okay, let's do that then.

Erik K: That's fine with me, then. Once it gets to a technically correct state,
as long as we know what to do with the document from there, that's fine.

6.5 Email address policy (Lars Eggert)

Lars: I sent an email yesterday with a very short proposed IESG statement that
basically has the exact same text we had in the thing that went out for
community review. In case you didn't read the community feedback, it was
shockingly broad consensus with the exceptions of John Levine and Bob Hinden,
who felt it was going to be problematic to have some name and also
potentially some name, with which I agree, but it's so unlikely
to happen in practice that I don't lose sleep over it. I talked to John offline
and he's okay and I haven't heard anything from Bob. So I would suggest we put
what I put in email out as an IESG statement. If there are any suggested
changes can you send them soon or at least tell me you want more time to review
it? The LLC board has a meeting in a few hours and we basically want to publish
the same text as the LLC board as a policy or whatever they call it because it
also concerns what they're going to do. So there will be two web pages with the
same body of text. Does that sound reasonable? [silence] Okay great, that's all
I have.

6.6. I-D Checklist Updates (Murray Kucherawy)

Murray: It sounded like from the earlier discussion that we want to circulate
this in the community. We could post the github link and say this looks like
it's what we're going to do and allow pull requests, to ease our editing
burden. Or we can just post a final looking version somewhere and ask for
complaints. That process could take weeks or months but I agree with Lars's
comments that we seem to be in a swing towards everybody wanting to give
feedback on things. It's just a matter of what process we follow from here.
Then once that feedback is in we take one more management item to say yes, it's
published, and then we're done. Does that sound insane?

Lars: I would prefer doing it that way, and we specifically tell them to send
feedback as Github PRs because that makes it easy. We could also ask for
substantial comments, although I don't know if that makes people come up with
substantial comments.

Ben: If you're asking for substantial comments you'll get them. This sounds
like a good plan to me. I'd suggest starting off with the github link in the
email but also maybe as a footnote including the raw text.

Murray: The raw text is going to be markdown-y, but yeah, we could do something
like that.

Alvaro: Who are we thinking of sending this to? The IETF list? We may get more
useful comments from the wgchairs list, for example.

Murray: I guess wgchairs would be a good place to start. I don't know that
we're going to get a lot of feedback from a community other than that anyway.

Alvaro: Yeah, I just mean that not everyone is going to be on the IETF list to
start with .

Lars: This concerns all I-D authors, we could even do this on ietf- and
irtf-announce, in addition to wgchairs.

Murray: If we're going to put it out for feedback let's just put it out, so no
one can say we did a closed audience for reviews. So I'm hearing we should put
it out for wide review, we should do it through github. I'll try to take it off
the rjsparks repository, there's no reason he needs to get bombed with all of
this. Is there an IESG or IETF one?

Lars: There's an IETF one; we can put it there if you like. It probably should
live there. I asked the IESG if they wanted one in the past and you said no.
But we can easily make one.

Murray: The IETF one is fine and I can make sure I can manage issues as they
come in.

Lars: If you make me an admin on this one,  or Robert does, I can transfer it
over and add you guys with whatever roles you need.

Murray: Okay, I'll start a thread with you and Robert to get that done. Then we
can make the announcement and hopefully have just a two week comment period; I
don't want this to go on forever.

Lars: Maybe one week past IETF 111?

Murray: I can do that.

Amy: For sending to the ietf-announce list, Lars can do that or you can get us
the text and we can send it for you.

6.7 draft-ietf-netmod-geo-location (Rob Wilton)

Rob: This one was on the telechat a month or six weeks ago and Roman had a
Discuss on it about one of the references, which is a normative reference to
the IAU, the International Astronomical Union. There's not really a good proper
reference to it, there's just a URL. I had a discussion with Roman offline and
we want a way of acknowledging that this is not an ideal normative reference
but it's okay and we should publish it. So really the question is, does anyone
have any objections to us waving that through in the IESG? Does anyone want us
to put this back through Last Call to highlight that? I propose that the IESG
just says this is the best we can achieve here and it's the right thing so we
should move on. Any objections or comments?

Ben: That seems like basically the right thing to do. We might be able to
finesse it somewhat by saying the IAU is the association that assigns these
things and referencing the organization but not the list of planet names.

Roman: The issue is that there is no list of planet names, and the current text
already is doing what you're suggesting. It just references the URL of the

Ben: Oh, I guess I'm misremembering. I'm not saying I found a list, we just
know that the IAU are the people who do this but we don't know how to find the

Roman: I want to clear [my Discuss], but we had a big discussion that that's
not the right reference, and we didn't resolve how to clear. That's what Rob's
asking for.

Erik K: Did anyone reach out to IAU folks?

Rob: We could try that, but we haven't. I know there's membership to the IAU
but I'm not sure if that then opens up information or databases for these
things. The question is, is that really worth doing here? Would that
fundamentally change anything?

Roman: In my opinion, no. That is the organization that hands out names,
whether we can get to it or not. I'm personally also a little dubious that
we're going to need anything but Earth, anyway.

Rob: I'd rather not do that just in the sense that it seems like extra work for
work's sake, but I can do it if there's a strong consensus to do that. But
otherwise I'd prefer we just try to wave this through if people are okay with
it. Ben, would that be sufficient for you?

Ben: I believe so.

Rob: Erik, would you be okay with that?

Erik K: I had no objection, I was fine.

Rob: I can't remember who commented.

Roman: In that case, I'm hitting No Objection.

Rob: Thanks Roman, and thanks all for the discussion.

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

Lars: It's time for this IETF 111 chair report or blog post and it typically
has a highlight of technical work. I can't think of anything that has happened
between 110 and 111 that isn't just management stuff, which is all I do. If
anything has something technical that would be of broader community interest,
we could highlight it there and it would make Greg happy to have something
interesting in there rather than the regular reporting.

 Martin D: Does RFC publication count, because we shipped QUIC.

Lars: We used that already.

Amy: That was the highlight for 110.

Lars: This is not super urgent, but if somebody comes up with something send me
an email and I can stick it in. We don't have to have that section in the
report but maybe something happened that wasn't purely management stuff.

Martin D: There's the HTTP series, which is just a cleanup, but it's also kind
of important.

Lars: Is it out yet though?

Ben: No, there are still a few Discusses. I think they committed a pull request
that should address at least one one of them.

Martin D: Oh, never mind. I thought we'd approved it.

Lars: Roman suggested in slack the adoption of STIR; does anyone remember if
that was used already?

Roman: There was an article in the New York Times saying robocalls are bad, and
they didn't cite us specifically, but that our underlying technology,
specifically STIR, is being used as a mitigation.

Ben: I thought we'd talked about that in some form, maybe a blog post, before.

Amy: I don't think it's been mentioned specifically in the IETF Chair and IESG
Report but it does sound familiar. The report doesn't need to have a highlight
for a technical topic, it's just nice to have. But it doesn't need it,

John: I don't think lack of huge broad community interest things is necessarily
a cause for concern; half the time those are things where there's some kind of
drama going on. Sometimes quiet is good.

Lars: We could highlight a BoF, but it also seems not good to highlight one BoF
over all the other BoFs.

Eric V: MADINAS has a fairly broad scope for a BoF, if you want to go that way.

Romab Couldn't you roll that up into a security/privacy thing, this is what
we're talking about now? That gets you MADINAS and OHTTP.

Lars: That seems more like a blog post. We're really only talking about a
paragraph here. But we could do a short one and Greg can turn it into something
longer potentially.