Narrative Minutes interim-2022-iesg-04 2022-02-03 15:00
narrative-minutes-interim-2022-iesg-04-202202031500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2022-02-03 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) / incoming Routing Area
Jenny Bui (AMS) / IETF Secretariat
Ben Campbell (Independent Consultant) / IAB Liaison
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (Google) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
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
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
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) / incoming Security Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Sandy Ginoza (AMS) / RFC Editor Liaison

OBSERVERS
---------------------------------
Heb
Timothy Carlin
Brian Monkman
Al Morton
Kevin Nelson
Carsten Rossenhoevel
Lee-Berkeley Shaw
Greg Wood

1.2 Bash the agenda

Amy: Does anyone have anything to add to today's agenda or any other changes?

Murray: One quick thing, if it fits; I need to leave an hour and a half in.
Something came up on the IESG list we might want to chat about, the question I
asked about an IANA registry of SDOs that are allowed to register things and
adding links to their websites, and whether the IESG has to tell IANA to do
that or not. It sounded like the consensus was no but I thought we could spend
a couple of minutes on it if we have time.

Alvaro: I want to give a quick update on the MSR6 BOF. Thanks.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the January 20
teleconference being approved? I'm hearing no objection, so those are approved.
I saw narrative minutes were sent out early in the week; any objection to
approving those narrative minutes? Hearing no objection there either, so those
are approved.

1.4 List of remaining action items from last telechat

    * DESIGNATED EXPERTS NEEDED

     o Francesca Palombini to find designated experts for RFC-ietf-httpbis-
       priority (Extensible Prioritization Scheme for HTTP) [IANA
       #1223879].

Amy: This is a new item for Francesca.

Francesca: I think we already have a management item to assign those experts.

   * OPEN ACTION ITEMS

     o John Scudder, Martin Duke, and Robert Wilton to review the document
       shepherd templates and propose changes to include updated questions,
       cross-area checks, and an expanded section on the use of YANG
       models.

Amy: We talked about this last week; is this done?

John: I looked at the document and it looks like we have more comments to
integrate.

Lars: Those might have been mine, I'm sorry.

John: Thank you for reviewing and commenting. Surely we can be done before the
next time.

Rob: Just a quick question on your comments, Lars, I've not looked at them yet.
Are they minor things we can resolve and be done, or do you need to see it
again afterwards?

Lars: It's a mix. Some of them I suggest consolidating various numbered items
that seem related. A lot of others are just little wording things.

Alvaro: What's going to happen now? Are we going to post the new one? Because
there's the detail of getting rid of the essay one.

Martin D: We're going to ask the secretariat to put this wherever it belongs on
the internet. I think it would also be wise to send out some sort of IESG note
or email to the chairs or something that says we did this. That's it.

Alvaro: I was just wondering, I don't know how many people use the essay.

John: I think there's going to be a lingering problem that these things are
sitting out there in ASCII form and there's probably people with a copy cached
on their local disk. We'll continue to get the old form for some period of time
and individual ADs can decide if they mind or not. I don't mind as long as
somebody writes up a report at all. If anybody objects to the essay going away,
I think they already would have spoken up. So I'm assuming that's not
controversial.

Warren: I think you see them so seldom, if anyone sends one I think it's fine
to just say thanks, next time please use this other form instead.

Ben: Not providing an essay template doesn't mean we won't accept shepherd
writeups using something roughly essay-like.

Amy: Okay, so we'll keep that in progress and hopefully next time be able to
resolve it.

     o Alvaro Retana and Martin Vigoureux to draft a note to wgchairs
       asking them to always confirm author/contributor status.
     o Alvaro Retana and Martin Vigoureux to draft text to include in the
       I-D submission tool warning about too many authors.

These two both depend on the former.

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

This is on hold until March.

     o Murray Kucherawy to look into updating the guidance in BCP 13 on
       when to add organizations to the "Standards-related organizations
       that have registered Media Types in the Standards Tree" list.

Murray: Leave this in progress, please. I'll get to it before the next telechat.

     o Francesca Palombini to draft text to the community on archiving
       conversations between RPC and authors.

Francesca: I have done that and sent it to the IESG mailing list earlier today.
I'm looking forward to comments and I hope we can agree on some text by the
next telechat and then after that set this up. Maybe it's too optimistic in two
weeks but please do check it and comment, everyone. I think we can mark this as
done; I don't know if we want to add something else for the next telechat.

Amy: We can add a management item to discuss it.

Lars: I want to approve. I think we should be able to get this ready. Can you
make it so that everyone with the link can edit or leave comments in the google
doc?

Francesca: You should be able to make comments but I didn't want people to just
make edits so I know what's been changed.

Lars: I don't have anything available other than a button to request edit
access.

Francesca: Oh. It should be open. Let me check. Can anybody else access it? Let
me post the mail I sent to the IESG.

Lars: I can see it, but I can't make comments. Look at it in a private tab and
you'll see what I see.

Francesca: Now you should be able to comment. I'd put Viewer instead. I see
Lars has started commenting already, thank you. Let's have a management item on
the next telechat and I'll look for comments and replies to the mail thread.
Thank you.

Amy: Thank you. We'll mark this action item as done and add it as a management
item for next time.

     o Éric Vyncke to create a tools team ticket to add more
       guidance for BoF Requests in the datatracker.

Éric V: The ticket was opened a week or two ago and this morning it was
accepted by Robert. I will follow up but we can remove this action item.

     o The IESG to report back to the community on the early plenary
       experiment.

Martin D: I drafted something and then forgot about it. I sent it out to
everyone, didn't I?

Lars: Yes you did and it looked okay. If you want to publish this in its
current form with the diagrams I think we need to ask Greg to put it in a blog
post or something and then we can send an announcement.

Martin D: Okay. I'll look at the comments; I don't think anyone had any burning
comments. I'll then send it to Greg and to Lars. This is mostly done and I just
need to do the final fix up which should happen shortly.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-dots-telemetry-22  - IETF stream
   Distributed Denial-of-Service Open Threat Signaling (DOTS)
   Telemetry (Proposed Standard)
   Token: Benjamin Kaduk

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

Francesca: Let's take a second, I think. I expect to be removing this Discuss
after this discussion, so this is a 'let's talk' Discuss. I just wanted to
explain, because Ben, I'm not sure if you've been following the conversation or
if I explained myself properly in the mail because one of the other authors
seemed a bit confused. What I had put the Discuss on is that the examples, the
body of the co-op message, is in CBOR format, so it's dots+cbor. The example
used JSON. So in the beginning I was a bit confused and thought it was not
consistent, and you're saying this content format is CBOR but you're doing JSON
instead. There was one sentence in a section that said all the examples will be
in JSON. So that sentence in the far away section, I had forgotten by the time
I'd seen the examples. Now the authors have added more text in that section and
also just before the first example so I think that's fine. But I still wanted
to bring up that that's not my preferred solution because I would have
preferred to see the examples in actual CBOR diagnostic notation. That is
equally readable and if I'm not reading the whole document or I'm not looking
at that particular text and I just go and look at the examples to understand
how they're done, because JSON could look like CBOR with everything being
strings, so that's not optimal.

Ben: Right. I've definitely run into cases where there's a disclaimer at the
top and somebody who goes in and just looks at individual examples will do the
wrong thing because they missed the disclaimer.

Francesca: The other author was saying that he has implemented everything in
JSON anyway and with the table that's the translation between JSON and CBOR,
that's super easy and he doesn't have to worry about it. I see his point, but
also that's one way of implementing and others may want to implement directly
in CBOR.

Ben: That's a good point. I think we should put this in the AD followup
substate if we can, because I do want to take a closer look.

Francesca:  I will leave it to you. With the text they added this is non
blocking, it would just be my personal preference to do it the other way. The
other point I had was point number 8, where they're describing what happens
when a client contacts this resource at a server and it says it MUST respond
with a 404 not found and a response code. This is the case where the 404 is the
expected behavior, because the resource is not present in the case they're
describing.  I would have just removed this requirement, this MUST, and say the
server responds with a 404.

Ben: This gets into the overall BCP about don't have your application have
specific semantics for specific error codes.

Francesca: The author's response was that this was already done in 9132, and I
missed it, otherwise I would have complained about the same thing. Again, I
will remove the Discuss because there is precedent for it, but I'm also not
happy about this and I'll leave it up to you to make the right choice.

Ben: All right. Thanks for taking the time to clarify, it's good to hear that.
I will take a look.

Amy: So I have that Francesca is going to clear her Discuss and this will go
into Approved, Announcement to be Sent, AD Followup.

 o draft-ietf-pim-igmp-mld-extension-06  - IETF stream
   Internet Group Management Protocol version 3 (IGMPv3) and Multicast
   Listener Discovery version 2 (MLDv2) Message Extension (Proposed
   Standard)
   Token: Alvaro Retana

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

Alvaro: We're going to need a Revised ID, please.

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

 o draft-ietf-pce-binding-label-sid-12  - IETF stream
   Carrying Binding Label/Segment Identifier in PCE-based Networks.
   (Proposed Standard)
   Token: John Scudder

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

John: Only if Ben or Martin want to. The authors are not responding; I think
the principal author is probably on holiday for Chinese New Year but the wg
chair is engaged and it seemed like there was a reasonable conversation going
on. If either of you have anything you want to talk about right now, fine,
otherwise I think we can just let those conversations play out.

Ben: I'm happy to let it play out.

Martin V: Me too. I'm good with the proposed modifications so I'll confirm that
with him and I'll clear.

Warren: So once Ben and Martin clear their Discusses the document can move
forward and be published.

John: Right, it can move forward, although it will definitely need a Revised ID.

 o draft-ietf-quic-datagram-08  - IETF stream
   An Unreliable Datagram Extension to QUIC (Proposed Standard)
   Token: Zaheduzzaman Sarker

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

Warren: I don't really have an objection. Tommy and I had a bit of a discussion
about this. I do still think people are likely to read the document and assume
that when it says use QUIC for carrying datagrams, they will assume this means
carrying UDP datagrams, because that's a very common assumption that datagram
equals UDP. But as I could not come up with any good text to suggest, I think
we're just leaving it as-is. I don't know if anyone else ran into the same
thing, seeing the word datagram and thinking obviously that means a UDP packet.

Erik K: Isn't MASQUE going to use this for IP datagrams?

Warren: Yes, but this particular thing, QUIC datagram, this is just some raw
payload. So every time I saw a datagram I had to say, oh hang on, they
specifically mean we're carrying unreliable payload, not that this actually
means a UDP packet.

John: I was surprised to see that comment. I see your point. It's not in my own
mental translation table but I can see how it would be in some peoples'. If the
authors don't mind they could just stick a definition in there that says
definition of datagram and pull something out of your favorite reference.

Warren: I think that would be really helpful. I realize that datagram does not
mean a UDP packet, but every time I saw it I had to remember that it doesn't
mean what I think it does, and when I was trying to work out the length
formatting I thought how can you have a zero byte UDP packet? I don't have any
terms to suggest, but okay.

Mirja: Warren, your association isn't that wrong, because the main use case for
this is use applications that currently use plain UDP and put it over QUIC
datagrams, but of course removing the UDP header because you don't need that
anymore.

Warren: Yeah, exactly. But because my mental model is datagram equals UDP I
keep tripping over it. I can chat with Tommy a bit, it should just require one
sentence.

Mirja: I agree with Tommy, I don't think that association is something that
everybody's having and adding something would be more confusing than helpful to
other people. I'm just saying this association is not that wrong, there's just
no UDP header which is the only difference.

Warren: That's the only bit I thought would be helpful, just a reminder that
this doesn't mean there's a  UDP header. But if it's going to be confusing,
that's okay and we can leave it as is.

Zahed: I think we were already talking with David and saw the response there.
So chat with them and if you can come up with something that clarifies that
one, that makes sense. I mostly just wanted to listen here to what others say,
because I have that association and I don't have that association. I have that
association a little bit but not that a datagram equals UDP. If there is a
solution in editing, you can talk it out with Tommy. This needs a few changes
anyway. I see the authors have responded with a new ID that covers a couple of
things but I still see a standing pull request in their repository so this will
need a Revised ID anyway.

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

 o draft-ietf-sidrops-6486bis-09  - IETF stream
   Manifests for the Resource Public Key Infrastructure (RPKI)
   (Proposed Standard)
   Token: Warren Kumari

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

Warren: I don't think so. Ben, feel free to correct me, but I think you're
currently having ongoing discussions with the authors; correct?

Ben: Yes, Job replied to me that he held the pen and they were going to try to
work out what they wanted to do. I don't think we need an urgent response on
this and we should take our time to think it through.

Warren: Okay, so once you and Job come to an agreement and you clear, this can
move ahead.

Ben: I think so.

Amy: Is that going to require a revised ID, or just AD Followup?

Warren: Probably Revised ID.

Amy: I also have a downref on this document, is that something to add to the
registry once it's approved? It's RFC 8488, which is an informational document.

Warren: Yes, add it to the registry.

Amy: Good, we'll make a note so that can happen.

Lars: Hang on a second; I don't think the document actually cites 8488. It has
a reference but in the text it's not been cited. I think you can just remove
that.

Amy: The document doesn't have a downref?

Lars: It has a downref in the reference section, but in the text it isn't
cited. It's a dangling reference.

Warren: Oh, that might have gotten removed. We will double check that and if
it's not there it doesn't get added to downref, and if it is then it does.

Amy: Okay. When you tell us that this is now approved, can you make a note of
that for us?

Warren: Yes.

 o draft-ietf-httpbis-h3-websockets-02  - IETF stream
   Bootstrapping WebSockets with HTTP/3 (Proposed Standard)
   Token: Francesca Palombini

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

Francesca: I believe it needs to go into Revised ID Needed because I see at
least some editorials that have already been merged.

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

2.1.2 Returning items

 o draft-ietf-i2nsf-capability-data-model-25  - IETF stream
   I2NSF Capability YANG Data Model (Proposed Standard)
   Token: Roman Danyliw

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

Roman: I would just like to ask, I believe I understand the substance of what
Ben put in his Discuss and thank you for that. Could I ask a few questions
about Zahed's, if you could scroll down a little bit? Just so I'm clear, and
the authors are going to largely handle this but I'll work with them on it.
You're pointing out that there are all sorts of representations for other
protocols but did you forget the obvious big one, QUIC? Is that what you meant
with point 1?

Zahed: I don't know when this was written, maybe at that time there was no
QUIC, but now that we have it I don't really see the point of missing QUIC out,
when you have traffic to manage them. That's basically the things you liked to
do with the security function. The other point was the name of it. I'm mostly
complaining about the 'volte.' If you make it so much about a cellular
technology or the particular generation, what happens to your 5G voice? Will
this be extending that one? If we're publishing this one now, why not do it
now? What's the point? Or can we make this whole filtering and identity non
generation specific? Those are my main questions. On the third point I'm mostly
saying is it good enough to just say  HTTPS? I'll definitely see HTTPS for
HTTP2 and HTTP3 and they don't have the same in the transport layer. So
basically if you have very generic capabilities, which doesn't differentiate if
it is HTTP2 or HTTP3, you might get into some problem where you allow HTTPS
traffic but you block UDP. I was not sure how you handle those things by
reading this specification. Those are the three points I had. The first two are
basically why is this specification not updated with the current trend.

Roman: That makes perfect sense. I just wanted to clarify that. I understood
the top line. I will let the authors answer. I think the simple answer on
number 1 is that this has been a work in progress for a really long time and a
lot of this has to do with tickling as-is capabilities, not to-be capabilities.
And there's not a lot of existing capability to do a lot of the fancy security
stuff in QUIC so this standard isn't tickling it. On number 2, you hit it
exactly right on the extension. There was an extension document that fleshed
out a lot of the voice monitoring capabilities that for a lot of historical
reasons I won't go into here didn't make it. There was a little bit of moving
content to save it to put it in here but not a lot of fleshing it out. This is
the case for a lot of things like the denial of service mitigation as well
where things were in other documents, in the end we couldn't finish it, so
there were at least stubs here for extensions. The third piece, I think that
requires a bit more of a nuanced answer and that's not necessarily all history,
so I'll let the authors do it. Thanks. This is definitely Revised ID Needed.

Zahed: For one and two I think the simplest answer is to say we thought about
it, we have some ideas for extensions, but we won't do it now.

Martin D: I was actually pleased that there was no QUIC filtering in this
document, because I might have Discussed it had QUIC been in it. I think we're
going to grease just about everything and you'd have a pretty narrow eye of the
needle to do something useful there that wouldn't step on some deployment plans
that are fairly solid.

Zahed: We'll still be perhaps ID-ing QUIC. There will be some watermark there
that says this is QUIC traffic, maybe. I don't know, my point is more that I'm
now here, I have RFC 9000, why are you not talking about it? A reasonable
answer would fix it.

Martin D: If there's a paragraph that says we considered using QUIC and didn't,
I'm comfortable with that. But if there is going to be actual filtering, then I
think we may have mutually incompatible demands. Thanks.

Zahed: That's fine, what you're saying. I just wanted to make it for the record
that we thought about it.

Roman: I'm glad we discussed it. We'll work with the authors to get something
that scratches both of these conversations, thank you.

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

Roman: And thanks for the review, this was a long document and a round trip for
some of you.

2.2 Individual submissions
2.2.1 New items

 o draft-faltstrom-unicode12-06  - IETF stream
   IDNA2008 and Unicode 12.0.0 (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: AD Followup please, I just want to ping him about some of the comments
that were added, but there's nothing blocking it.

Amy: Okay. It looks like this also has some downrefs, do those go into the
registry? I have three; 5894, 5895, and 6912.

Murray: Yes, I think for all three that's appropriate.

Amy: Great, we will get those into the downref registry once the approval
announcement has been sent.

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-rats-tpm-based-network-device-attest-11  - IETF stream
   TPM-based Network Device Remote Integrity Verification
   (Informational)
   Token: Roman Danyliw

Amy: I have a Consensus Unknown here, I'll move that to Yes for you. And I have
a Discuss for this document; do we need to discuss it today?

Roman: We do not; we actually talked about it already. We just have to figure
out what to do with that reference. Thanks for catching that, Ben. This is
definitely Revised ID Needed based on the other feedback as well.

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

 o draft-ietf-bmwg-ngfw-performance-13  - IETF stream
   Benchmarking Methodology for Network Security Device Performance
   (Informational)
   Token: Warren Kumari

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

Warren: Yes please, I think that would be helpful. I believe we also have some
of the authors on the call and thanks to the authors for joining. I'll invite
them to speak if they would like. I think many of the Discusses seem relatively
easy to address, and the main thing is just discussion between the authors and
the ADs to try and figure out how the document can be improved. I'm assuming
the authors know that Discusses, as we say in our recent IESG statement, are an
opportunity to actually have a discussion with the ADs and that they don't all
need to be addressed before the telechat. The document can still be
provisionally approved and once the Discusses have been dealt with, the ADs
clear their Discusses and it can move forward. But we do have the authors on
the call and I'm not sure if they'd like to comment or raise any questions for
discussion.

Carsten: Thank you Warren. I don't want to take too much time. We're fine to
discuss everything. I did get a little worried assuming that we should respond
to everything in advance but I think there was a misunderstanding with our
document shepherd. So anyway, we'll work to resolve these. At least in one case
we need support from other working groups so I'll ask for more guidance there.

Warren: Awesome, thank you. If things can be addressed before the telechat that
makes it easier, but if they're not, which happens really often, the document
is sort of approved by everyone else and the blocking positions are held by the
relevant ADs until the issues are dealt with and then it moves along. So,
again, thank you very much for joining and apologies that there was some drama
and misunderstandings. Do any of the ADs have any specific things they want to
discuss now, or is this better dealt with via email?

Murray: Email is fine for mine.

Éric V: And mine is already mostly solved; we agreed on some text. I'll clear
as soon as we have an updated version.

Warren: Excellent, thank you very much.

Amy: Okay, so it sounds like this is going to stay in IESG Evaluation and go to
Revised ID Needed until those Discusses clear.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-smyslov-esp-gost-00
   IETF conflict review for draft-smyslov-esp-gost
     draft-smyslov-esp-gost-12
     Using GOST ciphers in ESP and IKEv2 (ISE: Informational)
   Token: Roman Danyliw

Amy: I have no Discusses for this conflict review, so unless there's an
objection, it looks like this is ready to go back to the ISE. I'm hearing no
objection to sending this back to the ISE, so we'll do so on Monday unless you
need to add anything. [long silence] I'm going to take that as a yes.

 o conflict-review-irtf-cfrg-spake2-00
   IETF conflict review for draft-irtf-cfrg-spake2
     draft-irtf-cfrg-spake2-25
     SPAKE2, a PAKE (IRTF: Informational)
   Token: Roman Danyliw

Amy: I have no Discusses for this conflict review, so unless there's an
objection it looks like this conflict review can go back to the IRSG. Hearing
no objection, so we'll send this on Monday.

3.4.2 Returning items

 o conflict-review-crocker-email-deliveredto-00
   IETF conflict review for draft-crocker-email-deliveredto
     draft-crocker-email-deliveredto-09
     Delivered-To Email Header Field (ISE: Experimental)
   Token: Murray Kucherawy

Amy: I have a Discuss here; do we need to discuss that?

Murray: I think this will be brief. Alvaro and I have already chatted and given
our positions and I'm looking to go with whatever the consensus of the IESG is.
The summary is that although the ART area deals with email generally, and there
are WGs currently chartered to work on email, none of them are chartered to
work on this. So is the appropriate review to pick one of those WGs and say
it's related to that WG but it doesn't prevent publication, should I edit the
thing to say it's related to work done generally by the ART area but doesn't
currently conflict with anything, or is the right thing to say that there is no
conflict at all? I'll go with whatever the consensus here is. Either way
there's no conflict, but what's the right thing to say exactly?

John: Off the top of my head, related is not the same thing as perfectly within
the scope of.

Murray: That's always how it's been used so that's what I went with. Like I
said, it's not a major concern; it will guide how I do this in the future.
Thanks John; what do others think? Or is three opinions enough?

Lars: 5742 doesn't really let us rephrase the text of the options, so we need
to refer to a WG if we want to do option 2. We can't say the ART area.

Murray: It says there are these five types of answers, it doesn't say there are
these five answers.

Erik K: I agree with Murray, having just reread that for the ICN review.

Mirja: My memory also tells me that we did something like multiple WGs in a
certain area as well.

Ben: We've definitely put a list of WGs in. I'm kind of inclined to agree with
Lars that it should be WGs and not an area. But I also pretty much agree with
John that this is related to stuff we do, we do have groups that work on email
and think about email header fields. So I feel like we can put some kind of
group or groups in there and use number 2.

Murray: Okay. The reason I did that is because emailcore a) isn't chartered to
do that specific thing and b) was asked to take this up and they explicitly
said go away. So you could say that it's related, but you could also say that
door was slammed so there's no relationship. I just want to get this right
because it could create precedent for how others interpret these things down
the road.

John: Correct me if I'm wrong, but isn't the independent stream exactly used
for the kind of case you talked about, where a piece of work is taken to a WG,
the WG says we don't want it, and then it goes to the ISE? So that doesn't seem
like it's disqualifying.

Ben: It's related enough that they were willing to talk about it and explicitly
reject it; I think that qualifies.

Zahed: To me it seems like that's a good reason to actually call the WG out in
this option; it's related to that but we don't care, so publish it.

Murray: Okay, I'll change it to that, and I guess we can send this on its way
as soon as I've done that. Thanks.

Amy: So once you've changed that text and Alvaro has cleared his Discuss, we'll
send that no problem message.

3.4.3 For action

 o conflict-review-irtf-icnrg-nrsarch-considerations-00
   IETF conflict review for draft-irtf-icnrg-nrsarch-considerations
     draft-irtf-icnrg-nrsarch-considerations-07
     Architectural Considerations of ICN using Name Resolution Service
   (IRTF: Informational)
   Token: Lars Eggert

Amy: This was assigned just before the telechat began and was taken off the
agenda.

Lars: Can I get positive confirmation that Erik is okay to take this on? I
eagerly assigned it to him after he put a proposal for a response into Slack.

Erik K: That was why I read the thing last night and why I sent it. I was
waiting to see if anyone else would take it up. Since nobody had said anything
before I went to bed, I sent that out in case. But I didn't want to assume in
case someone wanted to have a read of it themselves. I don't mind.

Lars: Thank you.

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

 o Privacy Preserving Measurement (ppm)

Amy: I have no blocking comments so unless there's an objection now it looks
like this is approved for external review. I know there was a question about
the acronym.

Roman: If I could use this time to save a little bit of email and ask some
questions to the comments, because they're all good. Alvaro first, I believe I
did respond to the idea of having the pointer to the prior work on PPM as the
starting point, and given that we put this in a bunch of charters, it largely
just gives everyone a little comfort that this is the concrete thing we're
talking about. Are you okay with that?

Alvaro: No, but it's not a blocking comment, it's okay. It doesn't matter. I
just said I'm not comfortable.

Roman: That makes sense. And apologies to everyone about the milestones given
that I throw that down a lot. Ben, yes I will clean up the references to CFRG.
To the acronym, Lars, I hope we're past that. We ended up with the PRIV BOF and
that name was resoundingly rejected. The hope was to go back to the previous
name, because there wasn't a feeling there was confusion, that confusion
appeared to exist only in the IESG/IAB sphere. I would say let's wait for the
public comment on the list to see whether that's a problem.

Warren: Any word you come up with, you're going to find some collison or
unhappiness with. For the technical deep dive we had to WGTLGO which was We Got
The Last Good One, specifically because there were no acronyms left that did
not cause some unhappiness.

Roman: And then Éric, yeah, we'll clean up the language around the
architecture, because there are some assumptions there, just to make that more
accessible. Rob, let me know about the email I sent. The BOF feedback was
pretty clear about how to talk about abuse cases. They wanted to see how the
badness would occur in a very particular way. That's why the language looks
like that in the charter but we can add a little bit more if you want to talk
about deployment too. But otherwise thank you for the feedback, everyone.

Amy: We had a question, since you added this at an odd time. It needs a one
week internal review; the 1 week will end next Monday or Tuesday and that's
when we would normally send the external review. Is that an okay timeline for
you or did you want us to send the external review tomorrow as we normally
would and run those concurrently?

Roman: I don't think I can make the necessary charter polishes before Monday
anyway, because I would want to ask the list as well, so I think it works for
both you and me to run the official process and just give me some editorial
time to get it out on Monday. I just want to make sure that assuming there
isn't a groundswell of negative feedback from the community that we can
probably get it back on the next telechat. If not, we'll push.

Amy: We should be able to get it on the next telechat in fine time if the
external review message goes out Monday or Tuesday.

Roman: Perfect then. I very much appreciate the support.

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Calendaring Extensions (calext)

Amy: I have no blocking comments for this review, so unless there's an
objection it looks like this is ready for external review.

Francesca: There is one question from Ben but I would like to take that at the
same time as the external review as it's non-blocking. I think we can get the
chairs and community to pitch in as well. There were some comments about the
markdown being a bit messed up on the bullet list and I noticed that too but I
don't really know how to fix it and I think it will appear correctly on the WG
page afterward.

Éric V: To fix it you simply need to put an empty line between the bullets.

Francesca: Okay. Maybe I will try to do it for the next update; I didn't want
to do a new revision just for that. It's strange because some bullets are
working and some others are not.

Ben: I think the hidden behavior is if there's a trailing space at the end of
the line of the bullet.

Francesca: So there shouldn't be [a space]?

Ben: I don't remember.

Francesca: I'll investigate.

Ben: There's traffic on the wgchairs list; I think Carsten posted some analysis
of the different markdown variants.

Francesca: Okay, thank you for that information and I'll also try it on the
sandbox. So I think we can send it for external review.

Amy: Great, so we will send this announcement tomorrow.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Mirja: Martin indicated in Slack he was leaving early.

John: He mentioned one small thing.

Mirja: I'll add. First of all we discussed yesterday how the IAB wants to
organize the IETF [leadership] meetings. The IAB was willing and interested in
having the usual Sunday meeting, adjusted to a time zone that is possible for
those who are remote as well. We will probably not have any additional
breakfast meetings, but that's for the IESG and IAB to discuss separately. So
that's for meetings. The point Martin mentioned was that we got a request from
the RFC future model program to publish a new RFC editor model. This will go
out very soon for community review. We'll send it to all kinds of lists,
including last-call, and this will go together with three documents that Lars
is shepherding which also update the IAB charter and some other IETF stream
documents. There was a request from the program if explicit IESG approval and
potentially the LLC as well was needed. I'm not sure if that's needed but what
we want to do is definitely get broad community feedback and make everybody
aware. If you want to approve officially we can also add this as a management
item at some point. We're right at the point where we start the community call
for four weeks and then we'll approve this.

Lars: I think we should formally approve this on a call and I wonder if we
should even run it through the normal ballot process.

Mirja: I'm not sure from the tooling how easy that would be.

Lars: Fair point, yeah. But we should get it reviewed widely by the
directorates anyway. If possible I would like to get directorate reviews as
well like we do for the review teams. I don't think enough community people
have taken a look at this and that's one way to force that.

Mirja: Let me check something. Can I request directorate reviews for the
document? I can request reviews, so which directorates should I request?

Lars: All of them?

Mirja: Some of them don't review all the documents, right? Like I know the
transport area only reviews documents that are related to transport. But I can
still request them and then they can just not review it if they don't want to
do it.

Lars: I would request them all.

Mirja: Cindy, can you do that when you send out the call for community feedback?

Cindy: The call for comment is generally four weeks. I've never actually
requested a directorate review before so I don't know.

Mirja: If you look at the document with your account I believe there's a button
saying request reviews. If you don't see the button, I can do it. Just let me
know so we can coordinate on that.

Cindy: I'll look at that after this call.

Mirja: And then basically what I also heard is that we should add this as a
management item on the IESG call in four weeks?

Lars: That would be good.

Mirja: Lars, because you're an LLC member as well, do you want to feed this
somehow to the LLC?

Lars: When the last call is out I will forward it to the LLC and have them give
it a read. I know Jay has read it and I think Jason and Sean have looked at it
already too.

Mirja: Okay, so you will care about that. Thank you very much. One more last
thing, next week in the IAB slot Cindy will present a slide set that we have
put together mainly for new IAB members about how we organize ourselves and
these kinds of things. This could also be interesting for anybody who would be
willing to serve as a liaison in the next year, so if you're interested in
that, maybe mark your calendar and join next week.

Cindy: I just want to caveat that we're only going to do that if both of our
new people are available and I'm still waiting to hear back from Qin. I think
he may still be on holiday next week in which case we'll do it when he's back.
In either case we'll let you all know.

Mirja: Great, thank you Cindy. That's it.

Amy: Thank you everyone. We'll make sure the RFC editor future development
program document gets added as a management item for March 3.

Lars: There are also three other documents that go through the IETF stream that
update various BCPs and two of them are very short. One of them updates RFC
2028 which is basically a brief description of all the organizations and
standards process which is a bikeshed dream. We will run all of these through
the IETF Last Call process and that one specifically will get a lot of comments
and disagree with a few words that were used to describe a certain body's role
and that might be a little bit tricky. I might need all your help to get this
through because we can't do this without updating that. But all four of them
will basically be in last call at the same time.

Mirja: We should add them to the same telechat if possible.

Lars: Two of them are basically ready to last call now and one of them needs a
revision. I hope we can do it quickly.

Mirja: To get this done in four weeks we'd basically need to start today.

Amy: We are primed for that. Lars, to let you know, the telechat on March 3
already has 210 pages on it so I don't know how long those documents are but
you might be coming up on the page count.

Lars: They're very short. Two of them are one pagers and the other is maybe 3
or 4 pages.

Amy: Okay, great.

6. Management issues

6.1 [IANA #1222953] Management Item: Acceptance of media type registration from
standards organization AutomationML e.V. (IANA)

Amy: We need someone to take a look at this but IANA did say that Alexey
Melnikov gave an initial review and said they probably qualify as an SDO.

Murray: These usually seem to land on me so I'll take this one. It shouldn't
take long if Alexey has already looked at it.

Lars: This seems to be an association of various German industries. Based on
their website they do look like something like an SDO.

Amy: Murray, thank you for taking a look. Do you just want to keep this on as a
management item for next time?

Murray: Sure; I'll have an answer for next time. One quick thing; if I decide
between now and the telechat can I email you and it drops off or does it have
to come back to the IESG?

Amy: That's a good question. I think you can just email us and we can send an
official note to IANA. You might just want to pass it by the IESG.

Murray: Okay. I don't want to create a future action item we don't need.

Éric V: On the other hand, if it's on the agenda, it's basically that all of us
have looked at it.

Francesca: Question, do these not require to go to the media type mailing list?
Murray, you might know better.

Murray: No, I don't think so. The process is written in a funny way.
Technically once we approve anything from this SDO, they're added to the list
of people that are allowed to put stuff on the standards tree. Now what happens
is they ask us if this is one they should add and I think that's probably more
appropriate given some of the ones we've rejected lately.

Francesca: Okay. Because I've been really strict with drafts or documents
asking for registrations and putting Discusses if they haven't posted to the
media types mailing list.

Murray: These are SDOs that are attempting to register directly to the
standards tree without a document. So the process is a little different for
those. If a document comes through the IESG they've made a registration, we
have approved it, and they want to make sure it's okay to add them to the SDO
list. So someone registered this. So Amy, I'll email the list and Éric might be
right that since it's on the agenda we should deal with it next time. I'll put
it out there so we can just slam dunk it when it arrives.

Amy: Okay, we'll make sure this gets added as a management item next time.

6.2 [IANA #1223879] Designated experts for RFC-ietf-httpbis-priority
(Extensible Prioritization Scheme for HTTP) (IANA)

Amy: We have a couple of people here who have volunteered to be the designated
experts. Is there any objection to naming Lucas Pardue and Kazuho Oku as
experts for this registry? Hearing no objection, so it looks like they are
approved and we will send official note to IANA.

6.4 MSR6 BOF Update (Alvaro Retana)

Alvaro: I wanted to get some feedback on what I would like to do with this BOF.
We approved it last week as WG-forming with the requirement that they needed to
update their proposal and the agenda to make it reflect what we wanted it to,
and that I also find chairs. Turns out this week is the spring festival in
China and almost all the proponents are in China, so no one has replied. There
has been one reply when I announced who the shepherds and AD are going to be
and there will be a call tomorrow morning with them my time which will be
Friday night in China. So with the festival and Friday night I doubt there will
be a lot of progress made tomorrow night. The deadline for tomorrow was for
updated proposals and there's another deadline next week for final approval.
What we agreed last week is that if they didn't make any substantial progress
we could still approve the BOF as non-WG-forming. I would prefer that we don't
make it non-WG-forming so what I really want to do is give them this extra week
to get back from their celebrations and we'll get enough work done by next
Friday before we have to do the official approval and get them approved. I
still haven't found chairs; I've gotten four or five rejections at this point
so I'm still looking. That's the other piece there. Anyone object to that? What
do others think?

Erik K: No objection from me. It seems like we probably should review every
year things that might conflict with the new year celebrations, since this is
not the first time this kind of thing has come up. Not for my last term on the
IESG but for other contexts.

Alvaro: Thanks, Erik. That was it, thank you.

6.5 Instruction to IANA about Media Types SDO Listing (Murray Kucherawy)

Murray: Briefly, there is a table under the media types registry of SDOs
allowed to make standards track entries without producing standards track
documents. That listing is just the name of a company and the date it was
added. Someone suggested it might be a good idea to have links from those names
to their respective websites whenever those websites are available. IANA asked
me if they were allowed to make that change without IESG instruction and then
some debate happened back and forth about whether the IESG had to make that
request. The BCP governing mime type registrations says they have to keep track
of it but they don't stipulate the format it has to use. So the format that's
there, they've kind of made up on their own. On that basis they could continue
to make it up on their own and just add it. But i don't imagine it would be
controversial for us to give them a formal instruction if they would feel
better having it from us.i wanted to raise it here quickly if anyone else has
thoughts on it.

Éric V: Go ahead. It's up to IANA when you read the text.

Murray: So if no one else has any contrary feedback I'll tell them to go ahead
and they don't need us. Thanks.

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

Lars: I sent out a Doodle poll about a week for an in-person retreat. Since the
IESG meets on more of the days than any other group, if an AD wants to host us
that would be great. Otherwise I'll ask the IAB and LLC if anyone has a
location. Basically we'd need two rooms at a minimum, one which can seat 30
people or so and the other can be a little smaller. If there are even smaller
breakout rooms that would be nice but I don't think we necessarily need them. A
few people doodled already and there's one week in May that looks so far like
everyone can make it so I'm crossing my fingers that won't change. We'll try to
have people attend in person if that's possible and if it's not we'll have
people dial in remotely, so doodle based on your in person or remote
availability.

Mirja: We do have the budget to also just have some meeting rooms in a hotel,
which we've done before. We should also consider what places are good places to
travel to in the next couple of months. I know we've been offered some space in
Beijing or Shanghai but I'm not sure if this is the right time to travel there.

Lars: If you want to suggest a city and have the secretariat plan something,
that's fine too. We can take that to email or Slack.

6.3 Executive Session (Francesca Palombini)