Skip to main content

Narrative Minutes interim-2021-iesg-14 2021-06-17 14:00

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



Narrative minutes for the 2021-06-17 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

Michelle Cotton (ICANN) / IANA Liaison

Martin Duke (F5 Networks Inc) / Transport Area

Lars Eggert (NetApp) / IETF Chair, General Area

Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe

Sandy Ginoza (AMS) / RFC Editor Liaison

Benjamin Kaduk (Akamai Technologies) / Security Area

Erik Kline (Google) / Internet Area

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

Warren Kumari (Google) / Operations and Management Area

Cindy Morgan (AMS) / IETF Secretariat

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

Alvaro Retana (Futurewei Technologies) / Routing Area

Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area

John Scudder (Juniper) / Routing Area

Amy Vezza (AMS) / IETF Secretariat

Martin Vigoureux (Nokia) / Routing Area

Eric Vyncke (Cisco) / Internet Area

Robert Wilton (Cisco Systems) / Operations and Management Area



Jay Daley / IETF Executive Director

Roman Danyliw (CERT/SEI) / Security Area

Mirja Kuehlewind (Ericsson) / IAB Chair



Tim Costello

Amy Creamer

Bob Hinden

Julian Reschke

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?

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the June 3 teleconference
being approved? Hearing no objection. I also saw final narrative minutes from
June 3; any objections to approving the narrative minutes? Hearing no
objection. The last set of minutes we have is the BOF Coordination Call
minutes; I received no comments on these. Any objection to approving those for
posting? Hearing no objection, so we will get all of those posted.

1.4 List of remaining action items from last telechat

     o Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy to look at

       updating the I-D Checklist.

Murray: I sent Robert a pull request that resolves all the open issues. When he
does that I think we can pull that ready to go, unless the IESG wants one more
shot at it. I’ll post to the list when he does that and if anybody wants to
reserve that right of review, great, otherwise we’re ready to go and we can
call this done. I don’t know if that means we should keep this one more cycle
or take it off the list.

Amy: We’ll keep an eye out for that email and let’s keep it in progress for now.

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

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


Warren: That’s still 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 are both in progress.

     o John Scudder and Martin Duke to review the document shepherd

       templates and propose changes to include updated questions and

       cross-area checks.

John: I think I’m still holding the token. Still in progress.

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

       section on use of YANG Models.

Rob: This is in progress.

     o Zahed Sarker and Michelle Cotton to draft text for prospective

       Designated Experts on the basics of the IANA request process and

       "how to be a designated expert."

Zahed: Michelle and I just confirmed that we agree on the text we have, so we
plan to send it out for the rest of the IESG to have a look and comment.

Michelle: Just a reminder that this is text you all can send to prospective
experts, so when we let you know you need to find experts you have something to
send them with a little bit about the process and what’s expected. Once they’re
confirmed as designated experts we have slightly different text we send them,
but this is to gauge their interest and try to reel them in to be experts.
Hopefully you find this helpful. We’ll wait for your comments. So this is done.

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

       assignments regarding topics identified through the poll taken at

       the IESG retreat.

Rob: I was hoping we could discuss this at an informal. I’ve started sending
emails and I think I can close this over email. We can take this off the list.

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

       best practices for directorate reviewers.

Eric V: This is in progress; we’ve already had one meeting and we have another
next week. It’s slowly moving.

Francesca: I just wanted to say for everyone’s information that I will be
adding some pages to the IESG wiki, so I know that’s moving anyway.

     o The IESG to report on the RFC 8989 experiment.

Lars: This is formally for us to report to the community but it’s actually
based on data the current and previous Nomcom chair need to gather. After some
discussion I think they are off crafting a survey to last year’s and this
year’s Nomcom pool to get the data we and they might need to write that report.
This is ongoing and I guess nothing really can happen until the Nomcom pool is
finalized. Let’s leave it on there and come back to it in a month.

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

Amy: This is on the agenda for later to approve experts so this is
provisionally done.

     o Murray Kucherawy to update BCP 97 to provide guidance about handling

       normative references to non-SDO documents.

Murray: Not started. I’ll probably have a draft for everyone to start looking
at next cycle.

     o Murray Kucherawy to find designated experts for RFC 9036

       [IANA #1199105]

Amy: This is brand new for Murray.

     o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to

       the IESG on the impact of COVID-19 to the IETF in June 2021.

Rob: We haven’t done anything on this. I was just thinking about what we need
to do here; previously we’ve given a report in the plenary, and is this the
best place we should aim it to? We’re talking about the statistics of drafts
published, right?

Alvaro: I believe so. I think what we need to do is catch up with...I'm not
sure who exactly gave Alissa all the stats she shared before.

Amy: That was us. I have updated that same document Alissa was working on.
That’s been updated for January through May of 2021.

Alvaro: Great, then we have made progress! So we need to go look at the
document and say something next time.

     o Lars Eggert to update BCP 45.

Lars: This was basically one of the promises the previous IESG made for when
the Last Call experiments closed. BCP 45 is the charter of the IETF discussion
list. A couple of weeks ago there was a discussion about what to do with that
list in general but it’s been kind of quiet on gendispatch about this so I
think I’m going to try again to push this minimal update to BCP 45 that
basically says, here are these other lists where some topics that originally
were in scope should go. This is still in progress.

2. Protocol actions

2.1 WG submissions

2.1.1 New items

 o draft-ietf-idr-bgp-optimal-route-reflection-25  - IETF stream

   BGP Optimal Route Reflection (BGP-ORR) (Proposed Standard)

   Token: Alvaro Retana

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

Alvaro: I think this is ready to go but can we please put it in AD Followup so
I can catch up with a couple of things?

Ay: Of course. Approved, Announcement to be sent, AD Followup.

 o draft-ietf-httpbis-messaging-16  - IETF stream

   HTTP/1.1 (Proposed Standard)

   Token: Francesca Palombini

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

Francesca: Thank you all for the comments first of all. I see we have Julian
here, one of the authors. Ben, do you want to discuss [now] or do you prefer to
take this offline? I’ve seen there are some exchanges on the mail list but I
haven’t followed in detail.

Ben: I saw that there was some exchange between Mark and Martin and I didn't
quite understand all of the points that were being made. I don’t think I'm in
the best position to be discussing this particular question, in terms of what's
the right change to make in response. From my perspective it’s fine to let this
continue to evolve on the email thread.

Francesca: The WG also has an interim later today, in six hours. I’m not sure
if there is agenda time for discussing this but I would expect that this would
be one of the agenda items. If you’re available to join you’re very welcome to
do so.

Martin D: My discussion with Mark was about semantics; are we talking about the
same thing here? Ben dropped my name so I was a little confused.

Ben: The other Martin, Martin Thomson.

Martin D: Oh, sorry.

Francesca: So I think anyway this is going to need a Revised ID. It can stay in
IESG Evaluation for now and we’ll continue on the list.

 o draft-ietf-httpbis-semantics-16  - IETF stream

   HTTP Semantics (Proposed Standard)

   Token: Francesca Palombini

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

Ben: No, this one I think we have a pretty clear resolution to. I think Mark
put out the request for objections, but there’s a default resolution for this

Francesca: Julian, you can also speak.

Julian: Thanks for all the feedback we got in the last seven days. I don’t
think we’ve ever had so much feedback before. We have copied everything to our
Github repo for commenting so if people want to see how we are progressing with
the comments they can look over there. The Discusses are currently processed by
Mark mainly but they are not trivially resolvable, so this will take a few
days. Regarding what you said earlier about our interim, I don’t think we
currently have this on the agenda but maybe they will get onto the agenda
because now we have Discusses which we didn’t have a few days ago. I’ll talk to
Mark about that.

Francesca: I think that would be useful. I put this document on this telechat
specifically so if Discusses came up we would have the interim to discuss them.
So I guess this will also require a Revised ID and can stay in IESG Evaluation
while we clear this up.

Martin D: While Julian is here, I made a few comments on this but I eventually
gave up because there were so many instances, but there seems to be a real
aversion to using normative language throughout this draft. There are a lot of
oughts and cans and I just was curious if there was a philosophy behind that or
if it’s just that the active wordsmithing has missed some of these cases.

Julian: Funny that you mention it, because I talked about that very type of
feedback with Mark a few days ago. The main reason is that we are revising
something that has been deployed widely and we are very reluctant to make
changes and normative requirements which are not really backed by security
aspects. So we are changing normative requirements when they are objectively
incorrect, but of course there is always some wiggle room and also we avoid
normative language when it really doesn’t affect the interoperability. Some of
the feedback was why don’t you use BCP 14 keywords in your requirements to
people registering new code points, and the answer to that is we don't do it
because we don’t use BCP 14 keywords for registration procedures, we just use
prose for that. So if you look at the specs we are revising you will see the
exact same type of mixture between BCP 14 language and just prose. When we did
this project of revising the specs we didn't plan to change that.

Martin D: That sounds reasonable. I think maybe two of my comments are along
this line; feel free to ignore them now that you’ve explained.

Julian: Just to be sure, we will look at every piece of feedback and discuss
with editors, but that’s the main reason things are the way they are. It’s not
sloppiness, it’s intentional.

Francesca: Thank you. So revised ID for this one as well.

Amy: Great; this will stay in IESG Evaluation with Revised ID Needed.

 o draft-ietf-httpbis-cache-16  - IETF stream

   HTTP Caching (Proposed Standard)

   Token: Francesca Palombini

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

Francesca: I believe this will also require a Revised ID.

Julian: Just to be clear here, these are three documents who are essentially
siblings, so we will revise them all. Approving an earlier version would not be
useful for us.

Francesca: This will be waiting for the others too, so this will also require a
Revised ID.

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

 o draft-ietf-payload-rtp-jpegxs-16  - IETF stream

   RTP Payload Format for ISO/IEC 21122 (JPEG XS) (Proposed Standard)

   Token: Murray Kucherawy

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

Murray: I’m chatting with Zahed on Slack and he’s got the same concern that was
raised by some other people, which is that the ISO document to which this
refers normatively is not actually visible for review. It’s up to him whether
he wants to place a Discuss and hold it until we get a copy. I encouraged him
to do it, because this is not the first time this has come up recently that
there’s something behind a paywall and we get asked a bunch of questions about
it. So at minimum it will be AD Followup but it’s up to him.

Zahed: I basically raised the question of when this was done in the WG, was it
made available to the WG? Even if we are talking about packetization, the
document is written in a way that defines some terminology which asks me to
read the specification, and I cannot read the specification. So I don't really
know if what they are defining is true or false or what. Ben and I talked about
it and there was some unintended error in the VP9 payload which might have been
crashing the whole thing. Either you don’t define the terminology you want me
to read, you write it in a different way, or you make it available. I don't
know what we should do. My other colleagues are fine with reviewing it so I
didn't put a Discuss but I can put a Discuss or defer on it and try to see if
the specification could be made available to us.

Murray: I’m fine with however you’re comfortable handling it. I would note that
two other ADs chose not to block it but also pointed out that this is a thing,
and if three of us are saying the same thing, this is maybe someplace we should
push back a bit. I’m fine with however you want to handle this; defer, discuss,
or doing neither and leaving it to me to follow up is fine.

Zahed: If you want to follow up that’s fine.

Murray: If I take the token to follow up, the ballot will close. That's why I'm
wondering if you should do something instead.

Zahed: Okay. In that case, I would like to defer. Can I do it now?

Murray: Defer will force it onto a telechat later and i don’t know if that’s
necessary. Maybe Discuss is the better thing to do.

Zahed: Okay; I’ll put a Discuss on it.

Murray: So because of the Discuss, AD Followup is probably the right

Amy: Great. So it will stay in IESG Evaluation and go to AD Followup because of
the new Discuss.


Ben: Can I jump in? I failed to mention during the HTTP document discussion,
but I was a little surprised that we didn't have a conversation about
progressing these at Proposed Standard vs at full Internet Standard. I saw in
the shepherd writeup for [draft-ietf-httpbis-cache], Martin Thomson had implied
that it should be going for Internet Standard, but the datatracker lists all
three as going for Proposed Standard. I wasn’t sure if that was something the
IESG should talk about or if there’s a story there.

Murray: I suggest that because the messaging is inconsistent we ask them and
make it a management item next time.

Warren: We do this so seldom I’ve forgotten the process. Does it require
anything like an IETF Last Call if it goes PS to full?

Ben: I think we would specifically want to have a last call that indicates it’s
going for IS.

Alvaro: I think so too.

Warren: To me it sounds like this is one of the few times when it’s clear
something probably should be an actual standard.

John: I presume others would also want to give it a quick eyeball again looking
at the different requirements for full Standard.

Francesca: Julian, do you have the background there? I admit I’m missing the
background so I couldn’t answer you, Ben. [pause] Maybe he has left. I will
talk with the chairs and authors and come back with that. Thanks for raising 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


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

 o Oblivious HTTP (ohttp)

Amy: I have a number of blocks on the charter.

Francesca: This is a WG that is supposed to be in the Security area, with an
ART AD, so I will be the responsible AD. This is a collaboration with Ben and
Roman. We have a number of Discusses and I've seen a lot of mail coming in. I
wanted to mostly talk about the fact that this should really go for a BOF. In
general, I want to hear what you all have to say about that and if you do all
think this should go for a BOF I’m willing to reconsider. I wanted to explain
why it hasn't gone to a BOF in the first place. This has been discussed on
various mailing lists and it has been presented in SECDISPATCH, so it has been
presented to the community and discussed. We made a judgement call with Ben and
Roman and we thought the discussion was supportive enough of the work and the
scope was clear enough that WG was okay. If the comments now are saying the
opposite I'm willing to reconsider but I wanted to just bring this forward and
also I don’t want to delay things too much when it’s not necessary. I’m not
saying it’s the case this time, it might be the case that we need to delay to
clarify the scope, but i wanted to say that if we don’t accept to create WGs
from items that are dispatched from SECDISPATCH, DISPATCH, other dispatch WGs,
then we should all agree with that. My personal understanding was that it’s
totally reasonable for an item to be dispatched to a WG via dispatch without
needing a BOF, and now I'm getting this feeling of resistance.

Lars: It’s possible to go to the dispatch route, and we often do, but sometimes
the consensus in the dispatch groups isn't the consensus of the IESG or the
broader IETF and I think this might be a case like that.

Francesca: I’m talking about the general case rather than this case. This might
be a case when a BOF is a better route. It was confusing because we got some
comments coming in before it was sent for external review, so this is only an
internal review, but discussion has started.

Ben: I think this protocol proposal is not changing http, it’s just something
on top of http the same as all the other things we do on top of http. Just
because you’re not changing the core technology, that doesn’t mean we should
clearly do it in the IETF. Obviously the things we want to do in the IETF need
to be good ideas in their own right if we’re going to claim IETF consensus for
them. But I'm a little confused about the opposition because in this particular
protocol scenario you really need cooperation among all the three parties in
order for it to be workable, the client has to trust the proxy and the origin
server has to trust the proxy as well. You can’t use this protocol with
unrelated parties that don’t have a prior relationship. In that sense, this is
documenting something that all consenting parties opt into and it’s not clear
that we need to be super reluctant to take on that sort of work because we
don't expect there to be harmful impacts on bystanders.

Eric V: As I was the first one to raise a block on this, I think my position is
not so much about the work itself, even if I have some questions there.
Basically it’s coming mostly out of the blue if you didnt attend SECDISPATCH,
and maybe it was discussed in HTTPBIS. But also it’s quite fuzzy. There is no
explanation, no context. I’m pretty sure other people will have comments as
well. I really believe on this one it’s too vague and should be analyzed by
more people. A BOF is really the way to go. About the delay, I don't buy the
argument, one point being we can still progress on the document itself.
Everyone can do it and we can adopt it later. So that’s one point. And I've
never seen that we need to rush a document because of delay. We would love to
get a short delay, but as a reason to bypass this? I don’t buy it.

Francesca: It’s not about delaying the document. I don’t think there’s an
absolute hurry to publish this document. It's more about delaying the work
getting started. It’s more that this had started being discussed in January and
it’s now June, and it has taken a while to get the document to SECDISPATCH and
then it has taken a while for us ADs to figure out how we want to deal with
this after we heard the community. I don’t necessarily disagree with you that a
BOF might be a good thing, especially if we get more comments about the scope
of the charter. If the charter is not as clear as I thought it was, then maybe
a BOF to discuss the charter and its scope would be better than an endless
external review. I’m not disagreeing with you but I just wanted to point out
what I think delay means.

Lars: There’s another option, since this is an internal review. We could do a
slightly unusual external review and send it out and ask the community if they
believe a BOF in this space is warranted. Then we could make the decision when
that comes back. We don’t have to do it now, we can ask, if you feel that’s
helpful. If the answer is yes there’s no delay; the answer is no we don't need
a BOF, we all understand and this should go forward. I'm guessing if that would
be the community feedback the IESG would probably charter it.

Francesca: What worries me is that today we are supposed to approve the BOFs.
it’s more of a process thing. If we do send out this call….

Lars: We can block a slot for it, either for a WG or a BOF, and we can return
the slot at some future time. That doesn’t necessarily need to be a concern.

Francesca: Are you saying we would unblock this, send it out an email --

Lars: It’s up to the block holders. At the moment it can’t go out for external
review because there are blocks on it. One proposal would be to ask the people
holding the block if a way forward into external review would be to make part
of the external review on the question of whether a BOF is needed or not. If
the answer is no, we continue to discuss more. If that would lift the blocks we
could do it and then in two weeks see what the broader community has said, and
then either it goes to BOF or it goes to WG or we give back the slot because
it’s so conflicted we don’t know what to do.

Rob: The people that I’ve asked about this in the ops area were not’ aware this
was happening; they've all suggested that having a BOF is a better way forward.
There was someone else I asked in the security area and she also said she
thought in the SECDISPATCH meeting she thought it was a bit premature to go
straight to a WG and she suggested a BOF as well. The people I've spoken to
seem to be saying a BOF is a good idea. From my perspective, my concern is to
do with how DOH landed on the ops community. I don't think they're necessarily
that happy about it and this seems to be a further step towards that in terms
of increasing privacy in that area, and from an optics point of view I’d like
to have that discussion earlier on and make sure the community has had a chance
to say, rather than have that later in the process. That’s where I was coming
from, that it’s safer for everyone if we have a wider discussion first.

Warren: I didn't ballot, but I largely agree with what Rob said. I think a
number of people have never seen or heard of this before and will be very
surprised if there’s suddenly a working group.

Francesca: I understand that, but isn't that part of the external review, to
gather the community feedback? This is going against what I was saying before,
that we’re not allowed to charter a WG from dispatch, because dispatches are
not attended by everyone. As dispatch chairs we ask the authors to please try
to make this available for the whole community and the authors have done that
and forwarded it to WG mail lists they think will be interested. I understand
the concern for this document, and I'm willing to go for a BOF if you think
that’s the best way to solve this, but I think this might come up again.

Martin D: Francesca, could you say some words about why this didn’t go into
HTTPBIS? We wouldn't be having this discussion if we’d just put it in as a WG
document. That’s why I'm stumbling over the BOF requirement.

Francesca: I'll have to go into the details of the SECDISPATCH minutes and also
to the thread in HTTPBIS.

Martin D: We don't have to do it in real time. I’m of two minds about this. I
think having a BOF is actually five weeks of delay. If we do it this way --

Francesca: If we can get the BOF for the next IETF there is no delay, in my
opinion. The BOF will be about the charter, rather than the meeting being about
the draft itself, but--

Martin D: But on the other hand, if this had just been adopted by HTTPBIS I
wouldn't have blinked at all and we would have had none of the outreach people
are complaining about. I would be fine with either outcome, I don’t think it's
a huge deal which one we do. I do think there are some problems with the
wordsmithing in the charter, but I am confident from the email exchanges and
Martin Thomson’s draft that they actually know what they mean and all these
questions actually have answers, the charter just needs to be rewritten to
reflect those answers and tighten up the scope. But I don't think there’s
confusion on what they’re actually trying to do among the proponents, it just
needs to be written up better, in my personal opinion.

Zahed: I think I got the whole process thing a bit wrapped up in my head. I saw
this one as a BOF proposal in the wiki and then I saw there was a ballot for
external review and I got confused. In the slack I asked what’s going on, and
that was the reason. I thought this was a BOF.

Francesca: Let me clarify. This was not for external review, it was just
internal review, and the mail got forwarded. Apparently that’s the way it is,
the mail gets forwarded, and the community is already aware that this is for
internal review. The reason there is a placeholder in the BOF wiki is because I
was told to do that by the secretariat to schedule it into the 111 meeting. I
did write that there is a charter.

Zahed: Having said that, my comments were not really about BOF or not. It was
more that I didn't really follow. I read the charter and my judgment call is
that I'm not really sure what’s going on. The charter went very low on the
context of it. What’s going on? I know the technology, I work with http things,
so I can read a lot between the lines, but the charter should not let me read
between the lines. It should be pretty clear. Especially if it’s coming from a
dispatch, i think it should be much more on the background, much more giving
examples, much more on the context to the reviewer saying this makes sense.
Obviously I think the other comments we are getting is basically because it
touches on different layers, not only on the http layer, and I think that makes
some of us maybe a bit concerned. But my block was not about BOF or no BOF, it
was about clarification in the charter text.

Francesca: Okay. So what I'm getting is that the charter is not clear. I have
seen that the proponents have been trying to answer emails. If that still
doesn’t help I'm not against going for a BOF and i would like to have the BOF
at IETF 111. Martin, I agree with you.

Martin D: I want to be clear here, I think their answer is completely
satisfactory. The email replies have cleared up  all the problems. The issue is
that it needs to be in the charter. The answers are out there, they're just not
written down where they need to be.

Francesca: So if I manage to work with them to update the charter, you would
feel that would be satisfactory for you? I think others have said no. Eric
would prefer a BOF.

Eric V: I’m sorry but I think it’s quite a touchy topic, having possibly
multiple impacts, and we are five weeks from the BOF. I don't see the
opposition to run the BOF. We can still work on the charter, of course, that’s
no problem. They can still work on the document. If the BOF and the charter are
okay we can approve it in a matter of weeks. If we want to say wait until
November, this I understand is not too good. But we can work on it.

Francesca: Rob, you also had a discuss.

Rob: My thoughts are the same as Eric. I think holding the BOF is safer for us
and it doesn’t look like we’re pushing this through. I think we can have a BOF
at 111 and work on the charter at the same time, and I have no issues if they
have a side meeting at 111 as well to discuss the document. I just think having
the opportunity for people to comment is the best thing. I don't mind removing
the block to ask people if they want to hold a BOF but I think that would slow
things down. I think we should just do the BOF.

Francesca: Ben, what do you think? I’m the responsible AD but this is in the
security area.

Ben: I personally don’t think we should need to have a BOF. I think the
intended scope of the work, even if it's not very clearly defined in the
charter text, the intended scope is such that it should be able to go ahead. On
the related topic, I think we should be able to progress to chartering directly
from a dispatch outcome without having to go through a BOF. I think you touched
on how it’s not always going to be reliably that case and there may be some
situations when having a BOF is the right thing to do even if dispatch
recommended to go straight to a WG. But the flip side is that I don't have an
argument that can override the concerns people are raising. We do have blocks
from other IESG members that are presenting reasonable arguments a BOF is the
right thing to do here and I don't have any reasoning that would contradict
that in a clear and strong way. So from that sense it seems like we’re going to
be doing the BOF because we have AD objections and we don’t have reasoning to
claim that the objections are not valid.

Francesca: I understand you are agreeing with going ahead with the BOF and
hopefully we can approve the BOF today together with the other BOFs.

Ben: Right.

Francesca: And again, I'm fine with this and I think the proponents are mostly
fine with it. I’m not going to speak for them, they might not, but I’m just
concerned in general if items coming out of dispatch, this could apply to any
item coming out of dispatch. Dispatch is usually attended by people in a
certain area.

Rob: On that point, i definitely think it should be okay for dispatch groups to
be able to create WGs, but I feel that that’s the case when the charter of the
WG is clearly tied to that area. In this case it feels like it potentially
spans, or impacts, more areas. That’s the reason why I feel that a BOF is
helpful. In the general case I have no issues with that.

Francesca: Thanks, that’s helpful for me.

Zahed: I completely agree. I don't think you need to worry about it. Whenever
it’s cross-area i do believe people need to have a wider view. That’s what
external review is for. This is a special case, this is not an example.

Francesca: I'm okay with this also because if ADs have concerns, this will come
up in external review of the charter and that might delay creating the WG even
further, while a BOF might actually solve the problem. So I'm happy with this. 
Thank you.

Amy: Okay, so it sounds like the OHTTP charter is sort of on hold. We’re not
approving it for external review so we’re going to wait until we get
instructions on that.

Francesca: And we should add OHTTP to the list of proposed BOFs for IETF 111.
Thank you for the discussion, everybody.

4.1.2 Proposed for approval


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: Not much. IAB got an interesting talk yesterday from Wes on root
servers, but beyond that not so much news from IAB.

6. Management issues

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

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

Amy: This early allocation is about to expire.

Michelle: Just to remind everybody, we had this on the prior telechat but it
was requested to wait and bring it back because Martin wasn’t with us. I think
there might have been questions about if this was actually going to move ahead.

Martin V: The first draft is about to enter IETF Last Call.

Michelle: That’s good news.

Amy: Are there objections to renewing the early allocation for this document?

Lars: I think we pushed this and another BESS document because Martin wasn’t
here. One of them we saw was coming very soon and the other one looked like it
was further away. I think that’s why we decided to move them both. This must be
the one that’s closer to us.

Martin V: This one is closest to us. The ipvpn-interworking is about to enter
WG Last Call.

Lars: Okay. Thank you. We were just wondering when you weren’t there. It sounds
like we can just approve them and hope we’ll get them soon.

Martin V: In BESS, the WG tends to do early allocations pretty early, so we
have to renew them at least once, often twice. Hopefully the documents reach us
in time.

Amy: I’m hearing no objection to renewing the early allocation to both of these
BESS documents, so it looks like both of those can go on to IANA as approved.

6.3 [IANA #1198995] Acceptance of media type registration from standards
organization ISO/TC 184/SC 4 - Industrial Data (IANA)

Amy: This was also placed back on the agenda from last time and I think this is
only here to minute that this specific ISO instance is approved. Is that

Michelle: Yes. I did want to mention that we got a response back from Barry,
who was involved in the first ISO approval we did. It was his opinion that ISO
as a whole should be added. I just wanted to throw that out there. I know we
had quite a bit of discussion last time that it should just be the
subcommittees. I just wanted to let you know what his opinion was there and see
if it changes anybody’s minds about ISO as a whole vs. only adding

Murray: I don’t think I know enough about the structure and politics of ISO to
be able to say either way which is the best path.

Warren: I think we decided last time that we don't get very many of these so
it’s not particularly onerous for us to approve one at a time. If there was a
huge spike and we were getting a lot of them we could always reconsider.

Michelle: That sounds reasonable, that if there’s an uptick in requests from
ISO then we can revisit. This is just to officially put it in the minutes and
you can send us a message and this will be done.

6.4 IETF 111 BoFs decisions (Secretariat)

Amy: We have four proposed BOFs that have been provisionally approved and this
is now your opportunity to approve them for scheduling.

Eric V: I was about to say, about MADINAS, we got a couple of comments two
weeks ago that I shared with the proponents and the potential chairs. They
modified the draft charter, so they moved something there.

Martin V: Should I go on APN? You heard the very brief summary and you saw my
message a few weeks ago following the APN interim, so I won’t go back on that,
but I think in general it was useful. For the last few days we’ve worked with
the proponents and the BOF chairs. I don't know if I'd given you the name of
the BOF chairs, Adrian, Bob, and Daniel. We’ve worked with the proponents and
the BOF chairs to draft a quick first version of the charter. Please don’t take
that as a definitive version of course, but it was really for having something
in the wiki for you to see. It’s been uploaded in the wiki since yesterday and
you can take a look at that. I believe the consensus in our previous call was
to approve that BOF and i still believe we should because i think it's time to
have that discussion. I do have some outstanding questions as AD, whether that
best fits in RTG or in INT, because I know Eric V is particularly fond of that
technology and wants to be their shepherding AD. That’s a real question, where
does it fit best in INT or RTG? If the WG gets formed, where will the
technology be developed? For example if they are a data plane extension
impacting ipv6, should that be done in 6MAN or that WG? Same for MPLS and and
for NVO3. The same question applies to the protocol extensions, PCE, BGP and so
on. These are questions I will expect during the BOF to get feedback from the
community. So unless anyone strongly disapproves I believe we are good to go.

Amy: I know renaming it had been discussed, is it staying APN?

Martin V: I’m still working on finding a good name. I originally thought there
would be some opposition from the proponents to rename it but they are not
completely opposed. I’m working on finding a good name, particularly removing
the application because that’s the one causing concerns.

Amy: Do you have an ETA on a new name? Because to put it into the scheduling
tool we need a name and acronym attached.

Martin V: What’s your deadline?

Amy: Tomorrow.

Martin V: I’ll do my best.

Amy: I’m not hearing any objection to approving APN, so it looks like it’s
approved pending a name and acronym change. Please let us know as soon as
possible. Moving back to MADINAS, I also didn't hear any objection to that so
it looks like MADINAS is also approved to go forward as a BOF. Regarding
DANISH, I hope Roman left some instruction with someone; Ben maybe?

Ben: I’m pretty sure we want this to go forward as well. I have some text from
him. We should go ahead with this and consider it approved.

Amy: Okay; unless there’s an objection, it looks like this one is approved.
You’ve got some conflicts as TBD but we do have BOF chairs identified, so that
will help. That brings us to OHTTP. From the discussion of the proposed WG it
sounds like the BOF is definitely a yes, so unless there's an objection it
sounds like OHTTP is approved.

Lars: Is there anything you need to do in the datatracker to make it flip over
to being a BOF?

Amy: I think we just move it from PWG to BOF. I think that will do the right

Lars: That’s something the secretariat needs to do, right?

Amy: You may have the permissions too, but we’ll take care of it.

Francesca: Process wise, because I put all the information in the wiki, is
there anything you’re missing?

Amy: BOF chairs need to be named.

Francesca: Okay. I will try to. Ben, I hope you can help me with that.

Amy: That’s for all of them; if they’re not in the BOF wiki, we do need chairs

Francesca: This also has a deadline of tomorrow?

Amy: No, you have more time for the chairs. Getting it in the datatracker for a
scheduling request, you already did that piece. So this is ready for scheduling
and Liz has the information. BOF chairs can come later; we generally want those
the week before the meeting at the latest. We’ll start hassling you for those
in about three weeks.

Amy: Okay, I think we know what’s going on with the BOFs and we have four of

Eric V: When I saw the BOF wiki, I saw a last BOF request from SCIM at the
complete bottom which is mostly empty.

Amy: Oh, this is new.

Eric V: I don’t know when this came in.

Amy: Did anyone add this System for Cross-Domain Identity Management as an
Other Session, not in an area?

Lars: What does the history say? Pamela Dingle at added this,

Ben: SCIM is a somewhat well known thing in the web identity security space.

Erik K: The responsible AD would be from Security then, Ben?

Ben: Probably.

Amy: They’re a proponent and they put themselves in as a BOF chair. This sort
of sidestepped the process for talking about a BOF.

Cindy: Also, SCIM was originally an ART area WG that concluded in 2016.

Warren: Is that the same SCIM?

Ben: Yes, the proposal is referencing the existing RFCs.

Lars: This was done six days ago, did they make the timeline?

Warren: Its acronym is SINS, it kind of seems like we have to approve that

Francesca: The approval deadline is tomorrow but wasn’t the request deadline
the 11th?

Lars: It was the 11th, yes. It was submitted on the 11th at 5 pm UTC. So they
did make it, they just didn't tell anybody about it. Which is a great example
of why we shouldn’t have the BOF call with the IAB before the final deadline.

Warren: However, while what they did was wildly suboptimal, they didn’t
actually do anything wrong.

Lars: They should have told the AD at least.

Warren: Definitely they should have. But if it’s trying to do more stuff with
something that was an existing WG, it’s possibly not completely crazy, having
no idea what they really meant.

Lars: My suggestion would be for the SEC ADs to reach out to the proponents
immediately and try to figure out what this is by tomorrow.

Warren: Is it definitely SEC? Because someone was saying the original SCIM was
in ART.

Amy: They’ve also put in chair conflicts: none, technology overlap: none, key
participant conflict: none.

Ben: They have some links in the BOF wiki, including a github page which claims
they’re having biweekly meetings and they're using the IETF SCIM mailing list.

Lars: Which I guess nobody is still on?

Martin D: Should we have an emergency BOF coordination call tomorrow, when
someone has read this and understands where they’re at?

Lars: There have actually been quite a few mails on the SCIM mailing list.

Francesca: This is non-WG forming.

Warren: If it’s non-WG forming, it’s continuation of existing work, and there
have been emails about it, I'd likely say ‘why not.’

Lars: I’d still like to have ADs to reach out because i don’t recognize any of
the names that are participating in this discussion.

Warren: I was meaning, if the SEC or ART or whoever ADs think it’s reasonable,
I’ll bow to their better judgment.

Lars: That seems like a good approach.

Francesca: Does this have enough input even? I see just a bunch of links but I
don't really understand the motivation behind having this meeting.

Lars: I think that needs to be found out.

Rob: Maybe we should remove the “Other Sessions” part of the wiki and force
people to put it somewhere else?

Warren: Maybe we shouldn’t have an “Other Sessions” area. Eventually this will
all go in the Datatracker.

Ben: One potential question here is what do they gain from being an officially
scheduled BOF vs an unofficial side meeting-like thing? I guess the theory
would be to get more visibility, but I don't have a great sense for who would
show up to a BOF.

Lars: All of these require someone to talk to the proponents.

Erik K: People who were involved in SCIM the first time around, presumably?

Ben: We don’t really have enough information to make a decision right now, so
we need to find a stuckee to reach out to the proponents and find out what the
story is.

Lars: Leif Johansson was one of the original SCIM chairs, Alexey was the AD,
and I don't recognize the other name Morteza. We could figure out if Leif and
Alexey at least

Ben: Morteza is a known quantity but I think not really active in the IETF
anymore. I’d considered making them a designated expert but I got some feedback
that they’d retired, basically.

Eric V: Other than the fact that we are falling out of the sky with this
proposal, it looks sensible to have a BOF on this. The format is not correct,
and the way they did it is suboptimal, but I see no problem.

Martin D: This is obviously a shortcoming of both our process and our tooling,
that there’s no second meeting or notification. The proponents seem to have
done the minimum, but met our requirements to be considered. Maybe we can just
pencil this in the schedule and punt the decision, waive our own deadline so we
have some actual time to discuss this? I think the driver is Liz and we can
decide later than we normally would.

Lars: Cindy has a point though that we need a new acronym. The datatracker
doesn’t like to reuse acronyms.

Warren: It’s SINS; SCIM Industry Next Steps. That’s a new acronym. I don’t
think they’re trying to reuse the existing one.

Ben: We don’t even have much indication about how timely it is, if this would
be a big deal to do this at 112 vs 111.

Amy: Usually when you have all of these types of questions for something,
usually BOFs don't get approved, they get shunted to a side meeting. I don’t
know that we’re going to answer all the questions you want before…

Rob: My concern is, if they’ve met the deadline, we still need to go through
the process to evaluate it. Otherwise they've in theory met the deadline but we
reject them because it wasn’t the deadline we wanted them to meet.

John: Considering that they have no chair conflict, no technology overlap, and
no key participant conflict, what’s really the difference between a non-WG
forming BOF and a side meeting?

Warren: How many people see it.

Amy: It’s on the official agenda.

John: Isn’t there a cap on the number of non-WG forming BOFs you can have on a
topic? Or is that for WG-forming?

Rob: I thought it was five for Covid times.

Francesca: It gets time on the official agenda but it has conflicts with
nothing so we don’t even know…

John: If they don’t have any conflicts with anything, that means they think
they can be scheduled any time at all, and it doesn't seem like telling them to
have a side meeting instead of a BOF would be that onerous.

Alvaro: I agree with what Rob said before, unless we really go through the
process of examining what they want to do, we should approve, because they met
the deadline. Now we can have a bunch of people submitting the last day and
we’d have to approve everything.

Warren: The other option is we could do a better job of checking the wiki page
at the deadline date. This was our failure. I’ll admit it didn’t occur to me to

Lars: I did look on the wiki page but I didn't see it because it was all the
way at the bottom.

Francesca: There’s also no responsible AD suggested.

Warren: We’ve approved ones before that are at least this messy.

Lars: My suggestion to make progress on this is that the ADs of the areas it
might fall into reach out to them now and see if there’s any more material to
be had. We can tell them look, you added it on the last day and you didn’t tell
anybody; we’re trying our best but it might not get approved simply because we
don’t have enough time to evaluate. If we get something within the next 24
hours we can talk again tomorrow.

Martin D: In lieu of the informal next week can we have a coordination call
with the IAB?

Liz: We’re doing conflict resolution at the informal next week, because the
preliminary agenda is published next Friday. It really should be decided before
next Thursday.

Alvaro: Unless we get something in the next 24 hours, we can’t approve
anything, because we can’t go through the process.

Eric V: To gain some time, whoever is contacting the proponents can put the IAB
and IESG in CC so we can see the replies.

Lars: Do we have a volunteer to write email on this? Ideally someone from the
US who still has a bit of time in their day left? [long pause] I can send an
email to them tomorrow saying we didn’t see it in time and unfortunately it
won’t be approved. Unless i see an email on the IESG list indicating that
somebody contacted them before i get back to work tomorrow.

Amy: So SINS I guess is in a gray area and we will continue on with our next
management item.

6.5 [IANA #1198928] Designated experts for RFC9031 (Erik Kline)

Amy: Erik has identified two possible experts for this registry. Any objection
to approving these two, Malisa Vucinic and Michael Richardson, as designated
experts? Hearing no objection, so we will send official note to IANA.

6.6 [IANA #1199105] Designated experts for RFC 9036 (IANA)

Amy: Murray was assigned to this action item at the top of the call.

Murray: I’ve already got a candidate, but we can do it next time.

6.7 Finalization on blog on "Unofficial side meetings at IETF meetings" (Lars

Lars: I don’t think we can finalize it yet because there are comments in the
Google Doc that I don't think Jay has seen yet. We’ll try to finalize this by
email. I think this stuff is relatively minor but I want to give Jay a chance
to take a look, since it’s his text.

6.8 [IANA #1199760] Renewing early allocation for
draft-ietf-idr-bgp-ls-sbfd-extensions (IANA)

6.9 [IANA #1199761] Renewing early allocation for
draft-ietf-idr-bgp-ls-app-specific-attr (IANA)

6.10 [IANA #1199764] Renewing early allocations for
draft-ietf-idr-bgpls-srv6-ext (IANA)

Alvaro: [These three] are all in the same boat. They’re all BGP extensions and
all three are in my publication queue. All three have implementations; IDR
requires implementations for everything. We should renew all of them.

Amy: Any objection to approving the renewal of early allocations to all three
of these? I’m hearing no objections, so we’ll send official note to IANA.

6.11 [IANA #1199765] Renewing early allocations for
draft-ietf-lsr-dynamic-flooding (IANA)

John: There’s implementation of this and they are planning to Last Call it
soon, so it should be renewed.

Amy: Any objection to approving the renewal of early allocations to this
document? I’m hearing no objections, so we’ll send official note to IANA.

6.12 [IANA #1199786] Renewing early allocations for
draft-ietf-idr-bgp-ls-flex-algo (IANA)

Alvaro: This is almost the same as the others. This one already passed WG Last
Call; it was actually already sent out for publication but I returned it
because the corresponding ospf document is not out of the WG yet. So we’re
waiting for that, but there are implementations of this already and we should
renew this one too.

Amy: Any objection to approving this? I’m hearing no objections, so we’ll send
official note to IANA.

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

Martin D: I’ve agreed to be the stuckee on this SINS thing because it’s the
right thing to do to not leave these people hanging, but I don't know anything.
I’m soliciting what this email should say exactly. Do we want to discuss this
verbally or on slack?

Lars: Even for a non WG forming BOF, we’d want to have a little more
information about what the new work would be. There’s a small presentation of
new work for feedback from the larger group, but some indication of what it
actually is that they might want to do if a WG is formed, and what it might
take to get there. The other option is AD sponsored but it might not even need
a WG.

Francesca: There might be other options, like dispatching. My question would be
what Eric wrote, which is why is this different from a side meeting?

Martin D: Let’s just say they’re incredibly responsive and we iterate very
quickly. What is the timeline here on how quickly things need to happen? Let's
say this sounds super interesting and we want to discuss it with the IAB. In
fact, I'm going to add the IAB to the thread. Do we need to have all the
information by Tuesday? Wednesday? We can pencil it in to the schedule. Liz,
when is it that we release the provisional schedule to the community?

Liz: That’s on Friday the 25th.

Martin D: So we have to absolutely decide by next Friday.

Eric V: We should put the pressure on the proponents to say please reply by
Friday midnight UTC.

Lars: Their charter has actions to talk to an AD, and make acquaintances in the
area, and all this stuff they haven’t done but put into the wiki. I don’t know
if they ran out of steam or what. It seems like they know what they should be
doing but they haven’t done it.

Martin D: Is this in the wiki or in the github?

Lars: There’s a link from the BOF page to an interim version of the charter
which is not on github. ‘Collaborative HackMD version’. That one has other
stuff in it.

Francesca: Could you also make it clear, Martin, that if we don’t have enough
information we might need to reject the BOF for now and possibly ask them to
request it for next time?

Martin D: I’d really appreciate if the people who actually know something about
REST and security participate in the thread. I’ll get it started but I'm going
to be out of my depth pretty quickly. I’ll start a separate thread without the
proponents with the IAB to try to identify a time for this meeting if we need
it. Does that sound acceptable to everybody? I think we need to have two BOF
coordination meetings per cycle, but that’s a separate issue.

Eric V: It’s assumed those won’t be used anymore when we use the BOF feature in
the Datatracker, right?

Amy: I believe the BOF feature of the datatracker will automatically send email
to folks when things are added, so we won't have this surprise when that’s

Francesca: One more thing. I wanted to get your opinion. I have this SEDATE WG
that is now in external review and I've got some comments, more than I
expected, so the charter is getting worked on with the proponents and the
people who have comments. My question is more of a process question. I've put
in a placeholder for IETF 111 because I think this should get chartered by
then, but what happens if it doesn’t, or if it doesn’t clear all the steps?

Amy: They can still meet. You have now two formal telechats, you’ve got July 1
and 15. It’s in external review now so the next step is approval, and if it
doesn't hit approval on the 1st it can still come back between the 1st and the
15th and be approved. They can still meet during 111 and if the proposed
charter is approved they just meet as any other WG. If it’s not approved maybe
they can use that time to fix the charter to get approved, but you have two
formal telechats before 111.

Francesca: I was just wondering what if it doesn’t. Thanks.