Narrative Minutes interim-2020-iesg-10 2020-04-24 14:00
narrative-minutes-interim-2020-iesg-10-202004241400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2020-04-24 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 / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Wes Hardaker (USC/ISI) / IAB Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline / Loon LLC / Internet Area
Murray Kucherawy / Facebook / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Futurewei Technologies) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area (late arrival to call)
Magnus Westerlund (Ericsson) / Transport Area
Robert Wilton / Cisco Systems / Operations and Management Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director

OBSERVERS
---------------------------------
Brenda Lyons
T. Sridhar
Greg Wood

1.2 Bash the agenda

Amy: Does anyone have anything new to add to today's agenda? Any changes? None.

1.3 Approval of the minutes of past telechats

Does anyone have an objection to the minutes of the April 9 teleconference
being approved? Hearing none, so those are approved. Does anyone have an
objection to the narrative minutes of the April 9 teleconference being
approved? Hearing none, so those are approved as well.

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've actually made a lot of progress on this and I hope to talk about it
at the next informal.

     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: It's still in progress. We have a plan, we just need to implement it.

Martin V: We have a plan; we should reheat the discussion.

     o Alvaro Retana and Barry Leiba, with Warren Kumari, Alexey Melnikov,
       Martin Vigoureux, and Roman Danyliw 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.

Barry: This is in progress; we have active discussion amongst us.

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

Warren: This is fairly done, but I think it's still worth keeping in progress
because it needs continuing discussion and I'll be reminded.

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

Alvaro: I haven't done much on this but let's keep it in progress.

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

Warren: Let's keep this.

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

Eric V could not be on the call.

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

Magnus: I wonder if we need to rename this or comment on it because this moved
into a draft now. Should we have an action here to keep reminding us or just
keep working on the draft?

Barry: I think we can probably say that we strike this one because we're not
going to do it as an IESG statement, but instead there's a draft. Maybe just
get rid of this item.

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

Amy: We have this as a management item later in the agenda.

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

Murray: I have the pen on a first draft of this.

     o Eric Vyncke (with Suresh Krishnan) to write a draft of an IoT
       Systems charter.

Eric V could not be on the call.

     o Murray Kucherawy to send out a Last Call on marking TCP and UDP
       Ports 109 as "Reserved" in the "Service Name and Transport Protocol
       Port Number" Registry.

Murray: As a first step I contacted the IANA port reviewers and got a reply
from them saying that port 109, there was a recent software release that still
claims to support POP2, so this action was not recommended by them. I don't
know how urgently we need to pursue it or if that's enough for us to say this
shouldn't go ahead.

Magnus: There's no strong reason for removing the port registration for it.
It's fine to just convert the document saying it's historic.

Murray: Make a protocol action, you mean, on pop2 itself?

Magnus: Yeah.

Murray: Okay. Then we can change this to that and I'll take care of it.

Magnus: I think that was the intention to make the underlying protocol historic.

Mirja: What does make sense probably is to add a comment or a reference and say
that this is historic, but to actually mark it as reserved or remove it and
then have it as resolved, there has to be some kind of proof or at least some
idea that it's not used anymore.

Murray: Right, but there is evidence that's in use. So my understanding is we
can't touch the port registration, but we can mark the protocol as historic.
That seems to be the action here.

[crosstalk]

Ben: RFC937 already is historic.

Magnus: So basically then it's just an instruction to add a note in saying the
protocol is historic. Was the POP2 to historic, was that a document or was it
just an action?

Murray: This predates me on the IESG. I can try to find the history and figure
out where we go from here.

Magnus: Just wondering if you could add just a reference to the registry.

Murray: In the interest of time, I'll figure out what we can do from here.

Amy: So it sounds like this action item is being dropped in favor of another
action.

Murray: I'll email the IESG with a new action item and you can drop this one.

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

Erik K: Still in progress. I had a chat with the 6lo wg chairs and they agreed
they themselves could serve as experts but they wanted to find others. If we
can't find anyone else by June 1 I'll list them as experts.

     o Murray Kucherawy to find designated experts for RFC 7489.

Amy: This is on the agenda later today.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-idr-rfc5575bis-22  - IETF stream
   Dissemination of Flow Specification Rules (Proposed Standard)
   Token: Alvaro Retana

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

Alvaro: I think so, really quickly. But Eric V's not here. Rob, I think your
point is a good point. I just need to make sure there's nothing in the
implementations that would break based on changing that. I doubt it, but since
this is a bis we don't want to break anything that's already out there.

Rob: I'm not trying to change precedent here; if this the way it's always
written, and that's the right thing, that's fine. I just wanted to check that
that really is the right way of writing this.

Alvaro: I went to look at 5575, the original RFC, and it is not written this
way. It's actually not written at all. It's just some bits and we do whatever
we want with them. That's just why I want to check to make sure the
implementation is not going to break, because if this is what they assumed,
then I just don't want to change it. It's probably going to be okay.

Rob: Thank you.

Alvaro: This is most likely going to need a Revised ID. Actually, put it in AD
Followup since I have some homework to do first.

 o draft-ietf-ice-pac-05  - IETF stream
   Interactive Connectivity Establishment Patiently Awaiting
   Connectivity (ICE PAC) (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: It was version 4; the authors have been gloriously proactive at
responding and they have a new version that I think covers everything, so I
think we're good here.

Amy: Is this just going to be an AD Followup until that Discuss clears?

Murray: Thank you.

 o draft-ietf-netmod-factory-default-14  - IETF stream
   A YANG Data Model for Factory Default Settings (Proposed Standard)
   Token: Robert Wilton

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

Rob: Yes please; I would like to talk with Roman on this one as to whether he
still thinks there's an issue.

Roman: I briefly saw the responses early in the week but have not had a chance
to circle around. As I quickly looked at it, while I opened with saying this
was about the template, it actually wasn't about the template; it really was
about the language of tightening it up. If you give me some time I will look at
the responses and we can close this.

Rob: That's fine. One question in general, during the security review it was
raised about how this general template text is referencing documents that are
potentially out of date. Is that something I need to be concerned about, or do
we need to try and change that template text? Or is it fine as it is?

Roman: To be honest, I was intrigued by that comment, and it's on my list to
track those references down to see if we need to update the template. I'm not
sure.

Rob: So I can leave that with you?

Roman: Yes, consider that in our lap here in Security.

Rob: AD Followup for this one, please.

 o draft-ietf-core-stateless-06  - IETF stream
   Extended Tokens and Stateless Clients in the Constrained
   Application Protocol (CoAP) (Proposed Standard)
   Token: Barry Leiba

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

Barry: We don't. Klaus has been fairly responsive; he hasn't responded to the
Discusses yet but he's responded to other stuff. Let's put this in Revised ID
Needed, please.

 o draft-ietf-dnsop-extended-error-14  - IETF stream
   Extended DNS Errors (Proposed Standard)
   Token: Barry Leiba

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

Barry: I suppose if Warren wants to discuss any of it?

Warren: Quickly, I think we have agreement with Ben on new text that will
address his concern. Eric V's concern was just that we used the wrong template,
so I think both of these can be easily addressed. We should have a new version
out just after the call.

Martin: I actually had a couple of questions that I wasn't sure about. One is
that the error code point range has dropped to 65280 instead of 65536. Is that
just a typo?

Ben: I had the same question and it sounded like since the last full review was
of the 14, there were changes in the editor's copy.

Wes: We went through multiple rounds of number ranges depending on what we were
going to do. The one that ended up in the end, I suspect it's a typo from
removing one of the ranges and not updating the ending number. If we're not
going to the full 2 to the 16 bits then that should be fixed, yes. Thank you.

Martin: I already had a comment to that effect, so please handle that. Second
question, and I'm not the Security AD, but I know in other security protocols
you'll get very vague error codes purposefully to avoid analysis. Is that
something we should be concerned about with dnssec error codes or is that just
an orthogonal problem?

Warren: I think that's an orthogonal problem; it's not something that's likely
to be a useful signal to an attacker. Someone did have a question that this
helps with people getting a bogus answer and asking the next server. That is
one of the main motivations for this so we should also toss in a note saying
that it is a good feature.

Roman: I was going to slightly disagree with you. There's certainly signaling
that's going to occur there and it's worth calling out. Imagine you're an
attacker that's doing something with command and control, you're already on the
enterprise network, and you try to resolve your C2 domain and your helpful
enterprise DNS server says no, I already have you on the blacklist. Previously
that might not have been the case, vs a standard error. That's going to signal
something.

Wes: It's worth putting in a sentence, I think.

Roman: It's minor, but worth calling out.

Warren: Will do.

Amy: So I have this as Revised ID Needed to take care of all of that.

 o draft-ietf-sipcore-sip-token-authnz-13  - IETF stream
   Third-Party Token-based Authentication and Authorization for
   Session Initiation Protocol (SIP) (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: Not today; same batch of highly responsive reviewers and authors so I
expect this will all get resolved rather quickly and I don't have any questions
about the Discusses. It will be a Revised ID Needed.

2.1.2 Returning items

 o draft-ietf-pim-msdp-yang-18  - IETF stream
   A YANG Data Model for Multicast Source Discovery Protocol (MSDP)
   (Proposed Standard)
   Token: Alvaro Retana

Amy: All of the Discusses have cleared, so unless there's an objection it looks
like this one is approved.

Alvaro: There are a couple of things I need to tidy up; why don't we put this
in AD Followup/Point Raised.

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

 o draft-ietf-detnet-data-plane-framework-05  - IETF stream
   DetNet Data Plane Framework (Informational)
   Token: Deborah Brungard

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

Deborah: We'll do this as Point Raised. Thanks for all the edits, everyone.

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-dold-payto-00
   IETF conflict review for draft-dold-payto
     draft-dold-payto-12
     The 'payto' URI scheme for payments (ISE: Informational)
   Token: Barry Leiba

Amy: We have no Discusses, so unless there's an objection this conflict review
message can go back to the ISE.

Barry: This is all ready to go.

3.4.2 Returning items

 NONE

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

 o Automatic SIP trunking And Peering (asap)

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

Murray: No, this one needs to go back to the proponents in the WG. I was smart
enough to add the dispatch chairs to the mailings for this but not the people
who actually wrote the charter's text, so I'll make sure that dialogue begins
to happen.

Ben: I'm happy to clear now if you want me to; I just wanted to express that we
shouldn't blindly approve it because there were no blocking positions.

Murray: I don't mind either way. There are enough comments here that it needs
to go back to the wg at least once more. If you want to hold it and clear
later, that's fine with me.

Ben: That's the least-effort option, so I'm happy to do that.

Amy: So it sounds like we're just going to wait for instructions from you,
Murray, on when this can go for external review.

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Alvaro: I don't think there's any news this week.

6. Management issues

6.1 [IANA #1167290] Designated experts for RFC 7489 (Murray Kucherawy)

Amy: Any objection to approving Scott Kitterman as designated expert for this
registry? Hearing none, so we will send note to IANA.

6.2 Updating Ballot Pointers in Last Call Text (Secretariat)

Amy: We've received feedback from the community that one of the pointers in the
Last Call text goes to an error page, so we suggested some text. Is there any
objection to asking for that change in the template for Last Calls?

Alissa: I was wondering why we need to link to it at all. What's the point of
telling people where the ballot is going to be but it's not there?

Amy: That's a question for a former IESG, I don't have an answer there.

Warren: I think it's useful. I've had authors who don't know about the ballot
at all, so having folks know this is where the discussion is going to happen
seems useful. We've also had it for a really long time and nobody has run into
it as an issue before.

Wes: You can hit page reload a bunch of times.

Warren: For four days. [laughing] I think having people aware there is going to
be ballot text here is helpful so they know to check every now and then to
follow along at home. But it's not a hill I'm willing to die on.

Magnus: Considering in most cases, if you're on the relevant wg mail list, you
should see the comments being sent out when they happen, it's a rather small
group this might be relevant for. At the same time I think the formulation
that's suggested here is fine too.

Roman: To me it seems odd to send out a broken link, even if there's
explanatory text that says it's not live yet.

Magnus: There's no broken link in the suggestion.

Alissa: The point is that we're telling people there will be a ballot but it's
not there yet.

Warren: Even if it is a broken link I find it slightly faster than going to the
page and then the datatracker tab for ballot.

Alvaro: The tab is not active either, right? You can't click on the tab until
there's a ballot.

Warren: Yes, but if I find the email. Often the way I ballot is I search for
the document name and then I'll find an email. If I see the Last Call I'll
click on that, then I'll click on this link, and then I'll have to click on the
ballot tab, versus clicking straight to the ballot.

Alvaro: My point was that either way we're sending out broken links.

Warren: That's true.

Roman: My perception is that this fixes it really for us, it's for the
community.

Amy: We can do whatever you want; we can ask the tools team to remove the
notation in the template of any sort of ballot.

Eric V: I agree, removing the highlighted paragraph is going to be the most
sensible way.

Magnus: Let's do that, then.

Amy: So I'm hearing a proposal to just remove "The IESG discussion can be
tracked via [URL]" from the template completely and not say anything at all. We
will communicate that to the tools team and see if we can get that removed.

6.3 [IANA #1164643] Renewing early allocations for RFC 8111 (IANA)

Amy: The allocation expired and requires an IESG approved extension. Is there
any objection to granting an extension for the early allocation for this?

Alissa: What's the timeline for this? It looks like it was originally
registered a long time ago.

Michelle: Does anyone have an answer for that?

Deborah: I don't have a definite answer, but hopefully it will be done now when
these bis documents get approved. I see no reason not to.

Alissa: These are the documents that have been through IESG evaluation in the
last four or five months?

Deborah: This is the one that was considered experimental because all the
documents were experimental. Once those bis documents get through we'll be
cranking all these over to standards documents.

Alissa: But we did IESG evaluation on these.

Deborah: Yes. It's just this is the first time it's up for renewal.

Alissa: Got it.

Amy: I'm hearing no objection to renewing the early allocation, so we will send
an official note to IANA.

6.4 [IANA #1167929] Renewing early allocations for
draft-ietf-ospf-te-link-attr-reuse (IANA)

Amy: Is there any objection to granting an extension for this early allocation?

Alvaro: This one is in my queue, and I'm just waiting for a document update to
get it into Last Call. We should see it here before June.

Amy: Hearing no objection, so we'll send official note to IANA.

6.5 BOF Deadline for 108 (Alissa Cooper)

Alissa: We had taken the Important Dates down off the website because we were
not going to open registration at the time originally planned, which means we
also took down the BOF deadline and the I-D submission deadline and all the
ones we normally have. Obviously we still don't know what's happening with IETF
108 and we're not going to make a decision about whether in-person is viable
until May 15. Even after that we're going to be sending out a survey and
processing feedback about a format for a virtual meeting if people want to have
a replacement for 108. There's a lot of uncertainty still. We can reinstate the
BOF submission deadline to put it back where it was and proceed, not knowing
really how or when we might be scheduling BOFs. We could have the deadline
anyway and proceed like we normally would, or we could do something different.
We should sort it out since we got somebody asking and we should let people
know if they were planning a BOF for 108.

Barry: We should proceed with BOF planning as though the meeting were going to
be held that week.

Magnus: I also agree. I see no reason why not a deadline of June 12, even if we
have a more dispersed meeting that starts earlier and spread out more, we would
still be able to run the Bof preparation process sufficiently well.

Eric V: I'm with Magnus on this.

Roman: I also agree we need a date out there so we can catch those requests.

Alissa: Amy, could you get this added back to the Important Dates page? I'll
send out a reminder as usual four weeks in advance. Unless people think I need
to communicate this proactively. Doesn't sound like it, so we can wait until
May to remind people of the deadline. Do people want to talk about the draft
submission deadline or hold off until later? I don't think anyone really cares
about the draft deadline at this point so I think we could wait.

Barry: I agree with that.

Alvaro: We took it off, right?

Alissa: It's not up on the site right now.

Roman: I say we wait.

Barry: My view of the draft submission deadline is that we shouldn't have it
anyway, so definitely don't worry about it for this.

Alissa: Okay, sounds good. Thanks.

Amy: We'll add back the June 12 deadline for proposing BOFs and the BOF
coordination call will still be the week of June 15. I'll get the Doodle out
for that at the beginning of May as usual.

6.6 Designated experts for RFC 7636 [IANA #1160634] (Roman Danyliw)

Amy: Is there any objection to approving John Bradley and Mike Jones as the
designated experts for this registry? Hearing no objection, so we'll send
official note to IANA.

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

Barry: Is there a real point to have AD Followup and Point Raised being
separate substates? And we have to remember which major state uses which
substate, rather than just calling them both AD Followup because that's what it
is anyway.

Roman: I think they're the same thing.

Barry: Would anybody object if we asked the tools team to rename "Point Raised,
Writeup Needed" to "AD Followup" and be done with it?

Warren: I've never really understood what the differences are. I think the
"Revised ID Needed" is a helpful flag because it shows up differently in the
Datatracker, but other than that I've got no idea. I'm perfectly happy with
that.

Barry: Okay, so Amy, will you take care of that?

Amy: Sure; we can send a ticket to the Tools team to make that change.

Warren: One quick thing. Seeing as the Secretariat seems to know what the
difference is, is there a useful state difference between them that you think
we should be aware of? What does the Secretariat think should happen here?

Amy: Way back when, when something went into Approved, Announcement to be Sent,
there was no Revised ID Needed. It was just Approved, Announcement to be Sent
or Approved, Announcement to be Sent, Point Raised, Writeup Needed and that
covered a multitude of possible outcomes. Most usually, about a decade ago,
when there were a lot more RFC Editor notes added to the announcement, that's
kind of what it was; the AD is going to put in a note for the RFC Editor or a
note for IANA. That was the "writeup." Now, it seems more authors are wanting
to send something as complete as they can get it to the RFC Editor and they
don't want notes hanging around that go in announcements. From our perspective
it was useful while it was useful, but if you're not finding it useful we
should change the conversation as the culture has shifted.

Warren: Excellent. I just wanted to make sure there wasn't something important
we were all missing.

Cindy: One point on this; we can go ahead and put this request in for the tools
team but probably before we do that we'll go through and anything that
currently has a state of Point Raised, Writeup Needed we will change to AD
Followup, so you'll probably see some notifications about that.

Amy: Anything else before you go into executive session?

Martin D: Yes, very briefly. I've been working with the masque chairs to get
that work going and I think we're converging quickly on a charter. Probably
sometime next week you'll see a charter and wg chair nominations for masque as
a Transport area working group with me as AD.

6.7 Executive Session: Appeal to the IESG re WGLC of
draft-ietf-spring-srv6-network-programming