Narrative Minutes interim-2020-iesg-05 2020-02-20 15:00
narrative-minutes-interim-2020-iesg-05-202002201500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2020-02-20 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Deborah Brungard (AT&T) / Routing Area
Jenny Bui (AMS) / IETF Secretariat
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke / F5 Networks Inc / incoming Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Wes Hardaker (USC/ISI) / IAB Liaison
Ted Hardie (Google) / IAB Chair
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline / Loon LLC / incoming Internet Area
Suresh Krishnan (Kaloom) / Internet Area
Murray Kucherawy / Facebook / incoming Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / Transport Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Adam Roach (Mozilla) / Applications and Real-Time Area
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area
Robert Wilton / Cisco Systems / incoming Operations and Management Area

REGRETS
---------------------------------
Ignas Bagdonas (Equinix) /  Operations and Management Area
Jay Daley / IETF Executive Director
Alvaro Retana (Futurewei Technologies) / Routing Area
Warren Kumari (Google) / Operations and Management Area

GUEST
---------------------------------
Colin Perkins / IRTF Chair

OBSERVERS
---------------------------------
Ben Schwartz
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 February 6
teleconference being approved? Hearing no objection. Does anyone have an
objection to approving the narrative minutes from February 6? Hearing no
objection.

1.4 List of remaining action items from last telechat

     o Roman Danyliw to draft text to be posted on ietf.org about reporting
       protocol vulnerabilities via an email alias and possible procedures
       on how to assign triage resources.

Roman: I'd like to keep this. I'll figure out what additional help I need to
keep it going.

     o Alexey Melnikov to think about how to analyze how successful WGs and
       protocols are and why they failed or not.

Alexey: I'll only get to this one after I get off the IESG so I think dropping
it is probably the right thing here.

Amy: Does anyone else feel strongly about this and would like to pick up this
item?

Eric: Isn't it linked to Roman's matrix?

Alexey: I think it was more specific. It's from our first IESG retreat last
year, trying to look at ART area working groups and protocols.

     o Martin Vigoureux with Wes, and Alvaro to work on some
       mechanism to obtain wider or private feedback from people who are
       disenfranchised; anonymous flagging of offensive emails to inform
       leadership; more opportunities for private feedback.

Wes: I was just writing mail about that. I'll let it up to them if they want to
wait two weeks before deciding.

Martin: I'm inclined to keep it. It hasn't evolved much but there is some
relation with the ombudsteam so there is a dependency. I think it's important
so we should keep it.

     o Alvaro Retana with Warren, Alexey, Martin, Barry, and Roman
       to work on more transparency in the Datatracker about how long each
       phase of doc process takes / New datatracker flag to indicate who
       has the ball, area directors, authors, or chairs.

Martin: It would have been great for Alvaro to speak up but he's not here. My
personal opinion is that it would be a shame to drop it.

Barry: I'll agree with that.

Amy: Does anyone want to relieve Alvaro of the lead position there?

Barry: Why don't you say "Alvaro and Barry" as leaders.

     o Alexey Melnikov and Warren Kumari to add keyword tags to WG charters
       to identify specs that pertain to some general concept.

Alexey: I think it's a Keep. Warren and I should probably talk about this.

     o Alvaro Retana to work on a framework for analyzing new proposals.

Amy: We'll keep this in progress for Alvaro since he's not here.

     o Warren Kumari to work on acknowledging shepherds, directorate
       reviewers in a more standardized/formal way.

Amy: We'll keep this in progress for Warren since he's not here.

     o Alexey Melnikov to organize IoT overview discussion with interested
       ADs.

Alexey: Keep.

     o Alvaro Retana and Adam Roach to look at updating the I-D Checklist.

Adam: I don't think I'm going to be able to get to this before the March
meeting so I need to work with Alvaro to see if he wants to take it on or drop
it.

Amy: Adam, you let us know about your conversation with Alvaro and we'll keep
this in progress for now.

     o Eric Vyncke to write up draft text on Special Interest
       Groups and send to the IESG for comment.

Eric: In progress, keep it.

     o Ben Kaduk, Alvaro Retana, and Suresh Krishnan to skim the ietf@ietf
       list and collect a list of topics that seem to be the major concerns
       for the community from recent discussion threads.

Ben: I think collecting the list is done but we should give it to the rest of
the IESG and figure out what we want to do with the list and if there are
actions to be taken.

Suresh: It's in progress. We need to sit down and work on some action items to
follow up.

Barry: Can we put it on next week's informal?

Ben: Sure.

     o Martin Vigoureux to put together a proposal on disambiguating side
       meetings from IETF meetings.

Amy: I did see email on this earlier today asking you to review text. I think
this item is done.

     o Magnus Westerlund to draft an IESG Statement regarding the IETF
       as the default change controller for IANA Registration requests.

Magnus: Keep this in progress.

     o Suresh Krishnan to draft a "best errata practices" document and
       post it on the IESG Wiki.

Suresh: That's in progress.

     o Roman Danyliw to find designated experts for RFC 7636 [IANA
       #1160634].

Roman: That is still in progress. The folks I thought would be good aren't
responding so I have to keep looking.

     o Suresh Krishnan to write a draft of an IoT Systems charter.

Suresh: This is in progress; Alissa forwarded me the notes and I'm collecting
context right now.

Amy: The last two are new.

     o Alexey Melnikov to find designated experts for RFC-ietf-cellar-ebml
       [IANA #1163482].

     o Suresh Krishnan to find designated experts for the IPv6 Low Power
       Personal Area Network Parameters registries [IANA #1163481].

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-dtn-tcpclv4-18  - IETF stream
   Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
   (Proposed Standard)
   Token: Magnus Westerlund

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

Magnus: I don't really think so. I think most is quite clear and the WG needs
some time to respond. Revised ID Needed.

 o draft-ietf-6tisch-enrollment-enhanced-beacon-13  - IETF stream
   IEEE 802.15.4 Information Element encapsulation of 6TiSCH Join and
   Enrollment Information (Proposed Standard)
   Token: Suresh Krishnan

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

Suresh: Some of them are already in discussion; I don't have any questions
about anything in there so we can keep this going over email and hopefully
they'll all get resolved.

Amy: Will it require a Revised ID?

Suresh: Absolutely.

 o draft-ietf-core-senml-more-units-05  - IETF stream
   Additional Units for SenML (Proposed Standard)
   Token: Alexey Melnikov

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

Alexey: Possibly. Alissa, there was a discussion with Carsten and I'm not
entirely sure where you stand with this. Should you update your Discuss based
on the discussion, or are you happy to clear, or what do you think?

Alissa: Neither. I wasn't really satisfied with his response, to be honest. His
response was basically that this draft is going to leave the signaling of
whether secondary units are present or not open-ended, because we don't want to
constrain how it's going to be signaled, but we're probably going to end up
doing it one way, but we don't know yet. Then I asked what's the rush for this
to be done before that is done, specifically, and he said because it was
already supposed to be done and there are other SDOs developing things. For
this is why we have to approve this today, before this is hashed out, it didn't
sound like a strong story to me. I don't know if there's more context but the
answers didn't seem to add up.

Alexey: Basically this other document, there's no time to get this to IETF last
call and get it approved before I step down. This is not a reason to rush this
one, but I'm just saying.

Alissa: I understand that but I thought the point of all of this SenML work was
that there are these failures of interoperability because people don't agree on
things like units. This seems like it's just setting it up to continue that
instead of fix it.

Alexey: I don't think we can fix it. There will be multiple version
negotiations or something like that.

Alissa: That's fine, but can we write down what they are?

Alexey: What do you mean?

Alissa: It just leaves it unspecified how someone will actually end up making
use of these secondary units, because this is an individual draft which is
defining the way that's going to happen. I don't see how we can approve this
one when that one isn't specified yet.

Alexey: I'm just trying to think of ways forward. If we make this version draft
a normative reference, would that make it any better? And then someone else
deals with the version draft and this will get stuck in the RFC Editor queue,
basically. Or would you rather wait until the other one is done altogether?

Alissa: I think that's better. Then this language that's in there now which is
that this will be open ended needs to get fixed. I think those two things
together.

Alexey: The language currently says you need to use a new version AND/OR use
"_". I think it's more likely to be AND use "_", but the WG is not entirely
sure. So that's the extent of it. I do agree that it might be significant.

Alissa: If you want to make that change, that would definitely make it more
clear. As long as that's what the WG is comfortable with as well.

Ben: I'd asked him to use more speculative language about that one versioning
document because I don't have a great feeling about the approach it takes. It's
not really clear to me that document should be the one way it's done; not to
pre-judge the efforts of the WG.

Alissa: Fair enough. I didn't spend a lot of time with that document; my point
is just that there shouldn't be an infinite number of ways of doing this.

Alexey: It's possible one outcome might be that people just use "_" with
version 10, which means you have to understand or you don't use it. So this is
complying with the other document. Whether the WG actually wants to revise the
rules in the original RFC, I don't know.

Alissa: The original RFC allows that exactly. It's just that this is opening
other ways. The original RFC already says you can use "_" in version 10. Right?

Alexey: Yes. It's not a new feature.

Ben: The per-field with "_" approach in some sense is better, because then you
explicitly know not just that secondary units are in effect but also which
units to expect. Whereas the versioning approach seems more likely to be more
open ended and you wouldn't necessarily know what to expect.

Alexey: So I don't know where this is going now. I'll need to talk to Carsten.
I think this is Revised ID Needed anyway.

Amy: Okay, we'll keep this in IESG Evaluation.

 o draft-ietf-mpls-summary-frr-rsvpte-08  - IETF stream
   RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels (Proposed
   Standard)
   Token: Deborah Brungard

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

Ben: Before we approve this, I just wanted to mention the very first comment in
my ballot is something that might have been a Discuss point if I understood
what was going on better. But I didn't make it a Discuss point because I wasn't
very sure. Deborah, I don't know if you had a chance to look at that or not;
whether the message ID object is supposed to just be over a single hop or not,
is the key question.

Deborah: I sent all these comments to the authors and haven't been able to get
answers from them yet. I'll definitely have them answer it, and [audio cut in
and out]. We'll do this as Point Raised so they can address it.

Ben: Thank you.

Deborah: And thank you everyone.

 o draft-ietf-6lo-backbone-router-16  - IETF stream
   IPv6 Backbone Router (Proposed Standard)
   Token: Suresh Krishnan

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

Suresh: No, this has to have a Revised ID. Pascal is on vacation so he's a
little slower in responding, but Ben and Roman's stuff will get addressed. I
don't see anything non-actionable there. Just put it in Revised ID and I'll
follow up.

 o draft-ietf-6lo-minimal-fragment-12  - IETF stream
   On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network
   (Proposed Standard)
   Token: Suresh Krishnan

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

Suresh: Same thing for this one and the next one as well. Ben, thanks, it's
very comprehensive. Most of them are pretty simple to fix, at least on the
comment side. The link layer security is something we need to think more about
but I think we can work through it over email.

Amy: So this will go into Revised ID Needed?

Suresh: Yes.

 o draft-ietf-6lo-fragment-recovery-13  - IETF stream
   6LoWPAN Selective Fragment Recovery (Proposed Standard)
   Token: Suresh Krishnan

Amy: This sounded like you thought it should be the same way?

Suresh: Exactly the same, yes.

Amy: So this will also stay in IESG Evaluation with Revised ID Needed.

Suresh: The only thing is to Warren, we'll standardize for octet or byte. It's
one of those things you don't really pay too much attention to. But we'll make
sure there's one in there.

 o draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07  - IETF stream
   RDMA Connection Manager Private Data For RPC-Over-RDMA Version 1
   (Proposed Standard)
   Token: Magnus Westerlund

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

Magnus: No, to my understanding there's text proposed and we just have to wait
for updates. Revised ID Needed and we'll have the authors get to the rest of
the comments.

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

 o draft-ietf-uta-tls-for-email-04  - IETF stream
   Deprecation of use of TLS 1.1 for Email Submission and Access
   (Proposed Standard)
   Token: Alexey Melnikov

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

Alexey: I don't think so. I think we need to see a response from editors on
this one. Ben, would you like to discuss your point?

Ben: I don't have a particular need to discuss it; the author responded to me
but there's not really a clear explanation that's likely to cause me to change
to No Objection.

Alexey: Okay. As long as you're happy with that, it's fine. This will need a
new revision.

2.1.2 Returning items

 o draft-ietf-jmap-websocket-05  - IETF stream
   A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket
   (Proposed Standard)
   Token: Alexey Melnikov

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

Alexey: Can I have this in Point Raised please, because there are some comments
that will be worth addressing.

2.2 Individual submissions
2.2.1 New items

 NONE

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

 NONE

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-spinosa-urn-lex-13  - IETF stream
   A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)
   (Informational)
   Token: Alexey Melnikov

Amy: I have Consensus Unknown for this; is it yes?

Alexey: Yes.

Amy: Okay, I'll change that. And we've got a lot of Discusses.

Alexey: Yeah. I think I would like to talk about this one a little bit. I think
both Barry and I made no secret that this is not a particularly beloved
document. I did ask the IESG two questions. One is whether this should be
published as an RFC in the current form, and judging from the number of
discusses, the answer is quite clearly no. There is still a question whether
the URN scheme should be approved and what is the best way of doing this.

Barry: I think the consensus bit is No, not Yes. This should not get the
consensus boilerplate. And I don't think that affects the result.

Alexey: Probably not. So I had a look again at the registration procedure for
this. It is expert review and experts said we should register this. However, if
the template is just extracted from the document, which is just section 2 and
doesn't talk about resolution, it still needs to be modified. What do people
think about possibly approving the URN registration as a separate template, as
a management item, and letting the authors fix this document?

Barry: I'll add some history. This has been in the works for years. Everyone
from Peter St Andre and Ted Hardie and John Klensin and Alexey and I have
reviewed this and tried to get the authors to make changes. They've made some
changes but they've really refused to change some of the basic problems with
this. They have this mechanism they want to use to manage this namespace and I
think it is important to have their plan written down somewhere that people can
refer to and understand, understand being a relative term here. We all think
there are some serious problems with their plan in that it's not really
workable in the long term. Several of us have agreed that it's better to get it
published and have it written down than not to. I think with the consensus bit
off, we really should go ahead and hold our noses for the most part. I see
nothing wrong with trying to hold out a couple of discusses and get them to
make some changes, but ultimately I think it's in the community's best interest
to go ahead and have it published and move on.

Ted: I obviously was involved with this some time ago and as you say lots of
other people have as well. I think one of the most basic problems here is that
it doesn't seem likely that once assigned, they'll follow the rules for URN
management of the namespace. That they will either have ambiguity or
reassignment in ways that break the guarantees URNs are supposed to provide.
Have we discussed with them just going for LEX as a URI scheme instead? And
going for a provisional registration of LEX instead of URN LEX? They can behave
toward it like DOIs do. DOIs are functionally URNs that chose not to use a URN:
preference because they wanted the flexibility in the future to possibly change
their minds. Given that these guys are almost certain to not do what URNs do in
the long run, is there a possibility we could talk them into using LEX:
instead, and point to DOIs as an example of people who did a URN using a URI
scheme. Then in the registry, anyone who looks at it knows where to find it and
who to talk to but also I'm not necessarily getting the guarantees a URN gives
you.

Barry: That is an interesting thought. I don't think we approached them with
that. Alexey, do you remember?

Alexey: No, I don't think we did.

Ted: I don't remember doing it but it might be worthwhile to check.

Barry: I think in the long run, because the audience for this is limited and
outside the IETF, I don't think that if they violate the permanence it will be
a problem. I do think it's worth proposing that to them and see if we can steer
them in that direction.

Alexey: Ted, can I ask you to write some text?

Ted: I'll do that. It may take me until Monday.

Barry: The short answer is that nobody should be clearing any Discusses now. I
do think it's a good idea to have one more set of pushbacks on them saying your
document has a lot of serious problems and we'd like to try to help you resolve
them.

Alexey: So I shouldn't attempt to register the scheme without approving the
document?

Barry: Let's hold off on that for now, especially with Ted's suggestion which I
think is worth pursuing.

Alexey: Okay. Well, this will most definitely be Revised ID Needed.

Amy: Do you want to keep that consensus as Yes, or Unknown?

Alexey: Let's do it as No, Barry's right.

Barry: It has to be No. No matter what we do we'll never have consensus on this.

Amy: Okay, so we'll change the consensus to No and this will go into Revised ID
Needed.

 o draft-kucherawy-rfc8478bis-03  - IETF stream
   Zstandard Compression and the application/zstd Media Type
   (Informational)
   Token: Barry Leiba

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

Barry: Make it Point Raised; we have to discuss some minor changes.

Michelle: I think we're still waiting to hear back from Ned.

Suresh: I had a question that seemed a bit silly to put in a position. There
are some dates on the references for the standard. What does it actually mean?
I saw 2017 and things like that. Does it mean anything, because there's no
versioning on the standard?

Murray: Let me look, I don't remember. Oh, on the normative reference. That
could be 2020. It's just when the website first appeared, so the registration
date of the website.

Suresh: I just thought a version number could have been more useful. But
nothing specific.

Murray: Okay. I'll review that with the coauthor.

Amy: So this is Approved, Announcement to be Sent, Point Raised, Writeup Needed.

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

 NONE

3.4.2 Returning items

 NONE

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

 NONE

4.1.2 Proposed for approval

 o Adaptive DNS Discovery (add)

Amy: I have no blocks so unless there's an objection this is approved as a WG.

Barry: There's nothing that needs to be tweaked; it's ready to go. Eric, do you
agree?

Eric: Absolutely.

Amy: So can we remove the "proposed working group" part?

Barry: Yes, sorry about that.

 o Web Packaging (wpack)

Amy: I had a block on version 9 and we're now on version 11. Does the block
still stand?

Alexey: I was a bit late responding to all the comments. I believe I responded
to all of them. I'm waiting for one response from Ekr; I've done one of his
suggested changes. Ben, what do you think?

Ben: I have not had a chance to catch up on the discussion. I'll attempt to do
so soon and hopefully be able to clear.

Alexey: If you can do it by Monday that's much appreciated. And if any comments
come in from Ekr maybe there will be some small tweaks.

Ben: Okay, I'll continue to pay attention.

Alexey: So the only other comment is that we have one chair, Sean Turner. We
have two candidates for chair. One is still in negotiation with Mirja, the
other person wants to try it out. Kazuho is active in quic and httpbis and it
would be nice to get him on board. He initially declined my request but Mirja
and I are trying to figure out if he's not interested in chairing, doesn't have
time, or if it's a language issue. Another possible co-chair is Dave Lawrence
who provisionally said yes.

Amy: So it sounds like we're waiting for a go-ahead from you, Alexey, when
you're ready.

Mirja: I also didn't put a ballot in because I was waiting for an update. I
still need to catch up. Do you still want me to?

Alexey: Yeah, do it.

Alissa: I didn't want to block on the same issue but the people who commented,
it would be nice if we heard back from them that they're okay with the way you
handled their comments. Otherwise what's the point of commenting.

Roman: +1 on that.

Suresh: I hadn't looked at it yet because there was no yes.

Alexey: People should also look at my replies, because I don't think I was
particularly harsh, but a lot of comments I didn't think had actions behind
them. I think we're getting to the point of people nitpicking and it's not
going to affect the end result of this work.

Mirja: If it's not super urgent for any reason can we put it on the agenda for
the informal so we have a deadline?

Alexey: Sounds good, yeah.

Amy: Okay, we'll still await instructions from Alexey.

 o Drone Remote ID Protocol (drip)

Amy: There are no blocks, so unless there's an objection this is approved.

Eric: Give me a few days, maybe until Monday, because Alissa's and Ben's
comments are minor but important, so let's wait one or two days and get
something perfect. I think I will approve the finalized on Monday.

Amy: Okay, we'll keep it in Approved, Point Raised and you can let us know when
it's ready to go.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 o QUIC (quic)

Amy: There are no blocks, so unless there's an objection this recharter is
approved.

5. IAB news we can use

Mirja: Yesterday they approved a new program, MODEL-T on defining a new trust
model. They're also about to finish the conflict of interest policy and they'll
be voting on it next week.

6. Management issues

6.2 [IANA #1161777] Management Item: Protocol Number for Transparent Inter
Process Communication (TIPC) (IANA)

Amy: Suresh has been talking to people for this.

Suresh: I've been going back and forth trying to collect more info about the
allocation. I think it's a fairly valid use case, I just want to hear from
other IESG members. In my mind I think there's a justification to do this. I'll
probably put it on ice for two weeks waiting for IESG members to comment and I
want to see if there are any external comments as well.

Eric: I agree, let's wait for two weeks.

Suresh: I just sent mail to the IESG before the telechat which contains lots of
info. We don't have much allocation out of this space. Take a look and send me
objections if you have any but I'm inclined to grant them this based on usage.

Amy: Suresh, do you want to put this back on the agenda for the informal in two
weeks on March 5?

Suresh: Yes, thank you.

6.3 [IANA #1163119] Management Item: CoAP Content-Format for
application/td+json (IANA)

Alexey: Basically this depends on a media type application which Murray is
responsible for. I think the media type will be approved but we will ask W3C to
do a small change to the registration. Assuming this is happening, we'd like to
do this registration.

Amy: Any objection to following that procedure? Hearing none.

Alexey: I replied today and I think Murray will send a message today, maybe.

Murray: This is the one with the two + in it? The general problem is they
propose a media type suffix that has a + in it, so now you have a type that's
something + something + something and we don't have any precedent for how to
interpret that. Does order matter, does order not matter, etc etc? Your
suggestion was to send it back to them saying we're probably not going to
accept this because the syntax is ambiguous. We need to decide what to do on
our side, to allow things like this or block them or specify how this is
supposed to be interpreted.

Alexey: Let me give more context. The issue is that the registration itself is
basically fine, but it also has a paragraph saying you can also construct new
media type names with this suffix of double pluses. The basic media type of
application/td+json can be registered as is if this paragraph is taken out. My
suggestion was to tell W3C to take this paragraph out, we'll register the media
type, and we'll have a separate conversation about whether suffixes with double
pluses should or shouldn't be allowed. Depending on the outcome of this
discussion they can update the registration or give up on the idea. This
discussion wouldn't affect registration of the CoAP code tools.

Michelle: Alexey, does that mean the secretariat could send us a message saying
it's approved pending the approval of the media type?

Alexey: That's what I was trying to say, yes.

Amy: I think that answered my question. We'll send a note to IANA that
indicates it's approved pending the approval of the media type by media type
reviewers.

6.4 [IANA #1163482] Designated experts for RFC-ietf-cellar-ebml (IANA)

Alexey has been assigned this item.

6.5 [IANA #1163481] Designated experts for IPv6 Low Power Personal Area Network
Parameters (IANA)

Suresh has been assigned this item.

Suresh: I'm on it. Trying to find someone who's available.

6.7 Reassignment of [some] System Ports to the IESG
(draft-kuehlewind-system-ports-05) (Alexey Melnikov)

Alexey: Did everybody have a chance to read my short message on this?

Adam: I did but I didn't track the objections people have as it pertains to RFC
6335.

Alexey: Basically I think the document as written may be unclear in some cases,
thinking that system ports assigned to people which are not covered by any
existing RFC will be forcibly reassigned to the IESG. I don't think this is the
intent. Ports fall into various categories, some are covered by existing RFCs,
some we suspect are not used, and others are assigned to people who happen to
get allocations under previous policy. This document is trying to ask IANA to
basically query all assignees of the ports and apply the category they are. In
some cases for documents covered by existing RFCs we can figure that out; in
other cases we may need more information.

Mirja: I owe you a reply, but just to clarify this. So this is what the outcome
of the discussion is. The first two cases are more obvious and easier to
handle, and the third and fourth case was a little bit of discussion if there's
any value in doing that. I also have to say the current document doesn't
explicitly point out those points. My expectation would be if IANA pings all
the current assignees and someone comes back to say this port is not used, it
should be deregistered, then we should act on it and figure out if we should do
it or not.

Barry: I have a general question on the third point. Other than for bookkeeping
stuff, is there ever a good reason to assign a TCP port and the same UDP port
number for different things?

Mirja: No. Maybe. I don't know. But that's not the intention here.

Barry: I know it's not the intention. All I was asking for is that releasing
the UDP ports that aren't actually used is just a bookkeeping thing of
acknowledging they're not used. It's not a precursor to an intent of
reassigning them to something else.

Alexey: RFC 6335 says that they will move to unassigned [audio cut out] and
they can only be reassigned once we run out, so this will be years in the
future. For now it's just bookkeeping.

Barry: All good. Thanks.

Mirja: The point here is that we used to assign both together. If you asked for
one you would automatically get the other. We're not doing that anymore.

Magnus: That was one of the changes that 6335 implemented, that you didn't
automatically get the port. Publication of that RFC stopped the practice.

Alexey: Right. But there were previously assigned ports which we suspect are
not used.

Magnus: At the same time I don't see huge value in that because anywhere there
are going to be a lot of UDP ports available...

Mirja: We've had a few cases where a protocol was first specified under either
UDP or TCP only, and then later on we got a second specification using the
other protocol. I can well see that this might happen now with QUIC, with some
protocols where we have a specification  over TCP and somebody comes up with a
specification over QUIC, and that would use the UDP port. We did this for HTTP
over QUIC; the port was never used and now it's assigned to QUIC. It just seems
so stupid that we had to reach out to an individual to ask if we can use a port
that was never used for a protocol that we maintain. It just seems wrong.

Alissa: I have a question about the order of operations here. We don't need an
RFC to ask IANA to contact these people, so why did we not do the contact first
for the existing set and then we would know exactly which ones we are claiming
to reassign, and then publish the document that says the process we're going to
use going forward.

Mirja: Maybe it was even you, but I know this discussion was two years ago.
Because it's such a big action and we figured people would complain about it,
we decided to get it into a document to make sure it had community review and
people knew about it, to be transparent.

Alexey: It's better than a management item because it's a complicated thing.

Mirja: And the other intention was to give clear instructions to IANA so they
can be sure it's not their fault.

Magnus: I think unfortunately because the TVSWG wasn't on the list to be
informed before IETF LC, I think we're in potential here even if it's from a
formality ground, we're going to get an appeal for it.

Mirja: We didn't violate the process. This is an individual document and all
you need to do is a last call.

Magnus: Yeah but it violates tradition.

Mirja: I didn't know it's tradition but it's not like the whole group is
charting it. It's also a very short document, it's a four week WG LC, and at
the end of the LC if everyone says we don't like this document then we don't
have to publish it. This is the right point of time to comment.

Alexey: One possible way of moving forward is to decide that we only care about
point 1 and point 2, which will make it much easier, then I can cancel Last
Call, Mirja can quickly update the document, and I can restart it.

Mirja: I'm happy to rewrite the document and make things clear, but the
document is not talking about point 3 and 4. The assumption simply was that
these things might come up if we contact the assignees.

Alexey: My attitude is we should try and see what happens with point 3 and 4.
We might hear nothing, or we might hear one or two objections.

Magnus: I think we already saw a little bit, there's a question about some of
the special ports, like what do we do if it's an informal informational RFC
that might be IETF documentation of proprietary protocols? I think there are a
few documents that might be in there.

Alexey: There would be cases where we're not sure because an RFC might have
predated streams, it might not be IETF stream and might not be clear if it's
under IESG control in the first place. I would really like before stepping down
from the IESG to have a management item so IANA can ask questions to assignees
and see what responses are. But it's still unclear what to do with this
document.

Mirja: We can discuss in the IESG again if the IESG thinks we should do
something without having a document. From a process point of view that's fine,
but it might look a little bit strange if we have this document, people
complain about it, and then we do it anyway. I'm not sure what people complain
about, if it's the process or the steps taken.

Martin D: I think we had a little bit of a perception problem because of this
tooling issue, where people who thought they should have gotten this
notification didn't get it.

Mirja: That wasn't a tooling issue, it was sent to the right list. It was the
assumption that it should be on another list.

Martin D: Fair enough.

Magnus: I know you want to get this done, Alexey, but hand it over is the best
way actually.

Alexey: Yes I would like to get it done. Realistically I probably wouldn't get
it done, but I would like IANA to ask questions so we can see what comes back
from different people. Michelle, is this something doable before Vancouver?

Michelle: Sending out mail to a handful of port assignees? Sure.

Mirja: It's more than a handful, but yes.

Martin D: And the purpose of this would be to verify contact information, not
to make any decision about how to reassign the ports?

Alexey: Yes, to verify contact information, and ask if they think their
protocol is still being used. If they say no, it's not being used, you can
release it, that's also something which is nice to know.

Mirja: This is the whole purpose of the document, instructing IANA to do that,
and then if they can't reach somebody, try to figure out if we get more updated
contact information, getting this information, and bringing it back to the IESG
to talk about what to do next. That was the whole purpose of this document,
nothing else.

Martin D: I think the point is there are some bits that are a little
controversial and some that are not. I don't think anyone objects to updating
contact information, whereas doing a bulk reassignment or bulk release of port
numbers, there seems to be some process objection to that.

Alexey: I don't think we want to do bulk reassignment or bulk release at this
point. Maybe the document is not very clear.

Mirja: It's not only about contact information, we would ask them if they want
to reassign it to the IESG. If they all say yes then we have a bulk
reassignment.

Magnus: Who is this going to, is it only the individual assignees of things we
think are IETF stream proposed standards style documents, or is it anyone in
the system ports range?

Mirja: This was intended for everyone in the system ports range except the
ports that are already assigned to the IESG.

Magnus: Asking for getting those assignments without qualifications is quite a
big overstep. It's not our ports. And asking for them, why would you need those
for non IETF protocols?

Mirja: Because these ports are important for the internet community and should
not be maintained by individuals. But it's also a question of how you ask for
it. You can just say, hi, you've got this port, we assigned it to you 20 years
ago. Are you still using it or do you want to reassign it? This is the way you
can ask.

Martin D: But the question would be who's the owner of the port rather than
de-assigning the actual previously assigned purpose?

Mirja: The owner of the port is the person who's listed in the registry.

Martin D: Yes, but there's an assignment to an individual and there's
assignment to a service, and those are two different things. Tracing ownership
is relatively simple but verifying that the port is safe to reassign...

Magnus: We're not doing that.

Mirja: Reassigning the port to a different service is not what we're doing,
definitely not. If we figure out the port is unused we might reserve it.

Martin D: Not reassign, but de-assigning the service is considerably more
fraught than just reassigning the owner of the port.

Magnus: And they'll be able to have a process for it. To a certain extent it
requires us to do quite a lot of work to deassign a port, including some public
last calls, etc.

Mirja: Even for those ports where the owner says, oh I never used this port, I
don't need it, you can have it, we can still decide if we want to de-assign it
and keep it in reserve, or if we just keep it as it is and assign it to the
IESG to maintain it later on.

Magnus: You can't do that without running it through the process.

Mirja: Yes, but I'm saying we can decide now if we want to run this process or
if we just reassign it to the IESG for now and then maybe de-assign it later if
it's needed. But then we don't have to reach out to that person again and ask
them if we can do it.

Alissa: It seems like we may want to take more of an incremental approach.
These are multiple different things, and some of them are way easier than
others. So why don't we do the two easier things first?

Alexey: How about I draft a message suggesting listing ports from category 1
and 2 and then we can review it, with specific messages to ask people. Message
number one is going to be, these are the ports covered by IETF RFCs assigned by
specific people, and we want to reassign them to the IESG because they're IETF
stream, and see if there are any objections. For other ports, asking do you
still use this, and check contact information, and we can see what we get for
these two categories.

Mirja: I'm just saying that's the purpose of the draft. Now we're just doing
the action without having a draft.

Martin D: I think the straightforward things that are clearly in scope for 6335
are to update the contact info and ask people voluntarily to give it up to
IESG. To that extent it seems like that should be relatively straightforward
and unobjectionable. The moment when we can't reach people or they have an
objection to giving it up to IESG, then there might be some wordsmithing issues
with the draft relative to the RFC and exactly what the procedure is and who
decides. I think the RFC indicates that IANA with the help of an IESG appointed
expert would make the decision, which is a little different from the IESG
making the decision.

Mirja: But it's within the procedures of RFC 6335 that you can do these actions
on IESG approval. If you tell something to the IESG and make a decision, that's
IESG approval.

Alissa: I think the four of you need to get together and figure out the way
forward and let the rest of the IESG know what to do. We need to move on.

Alexey: I'll propose some text and circulate it.

Magnus: TSVWG list also once we know what we're doing.

Alexey: Yes, but I was holding off replying to Joe until we know what we're
doing. I still don't have a full idea of what we're doing but I'll propose
something.

6.8 [IANA #1163554] Management Item: Acceptance of media type registration from
standards organization Audio Engineering Society, Inc. (AES) (IANA)

Amy: Is there any objection to approving this request?

Alissa: It looked fine to me.

Ben: I'm curious if we have any expectation they'll be making additional
allocations in the future, but that doesn't really affect what we do.

Michelle: We can report back if they start requesting more things.

Barry: I think we're not likely to expect it, but they clearly are the proper
organization for audio stuff like that so it seems pretty clear. They still go
through expert review in any case.

Murray: That was my question. Does this one go through the media type review
process as well, or are we approving this and adding to the list one action?

Michelle: The management item is just putting the standards organization not he
list. The request still goes to the experts.

Barry: The rules are in order to register in the standards tree, you have to be
approved by the IESG, but the individual requests still have to be approved by
the experts.

Murray: Okay, thank you.

Amy: I'm hearing no objection to approving this, so we'll send official note to
IANA.

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

Barry: Yesterday ICANN announced that ICANN 67 in Cancun will be remote-only
because of coronavirus. This came up during a meeting with Jay Daley who made
it clear the IETF is not planning to do anything like that at the moment.

Eric: Do you know how many people attend ICANN meetings?

Barry: On the order of 2500.

Amy: A reminder that for areas who are changing ADs, please send the
Secretariat your list of who is taking which WGs as soon as possible. Your
deadline is the Sunday of IETF 107.

6.1 Agenda Conflict Resolution for IETF 107 (Liz Flynn)

The IESG reviewed a draft agenda for IETF 107 and discussed conflicts.

6.6 Executive Session: IESG appointment to the IETF Trust (Suresh Krishnan)