Skip to main content

Narrative Minutes interim-2020-iesg-16 2020-07-09 14:00
narrative-minutes-interim-2020-iesg-16-202007091400-00

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

narrative-minutes-interim-2020-iesg-16-202007091400-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2020-07-09 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
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
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area
Robert Wilton / Cisco Systems / Operations and Management Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Wes Hardaker (USC/ISI) / IAB Liaison
Alvaro Retana (Futurewei Technologies) / Routing Area

OBSERVERS
---------------------------------
Luigi Iannone
Brenda Lyons
Greg Wood

1.2 Bash the agenda

Amy: Does anyone have anything to add to the agenda? Any other changes?

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the June 25 telechat being
approved? Hearing no objections. Does anyone have an objection to the narrative
minutes of the June 25 telechat being approved? Hearing no objection. Both are
approved.

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 dropped a status update on the list a couple hours ago to summarize. I
haven't gotten any other feedback so I'm considering everyone here comfortable
with that text; please speak up. I've been working with Greg and Jay to link
what's said there to the upcoming policy the LLC will have on the same topic.
We'll wait for that to finish so we can put it all out together. If anyone has
specific ideas on where and how to drop it on the website, I put some ideas on
the mail list about where we could create pointers. If you have ideas let me
know.

     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.

Martin V: Still in progress. There's been a discussion with Jay on the tool
which is being used by the LLC. We have also involved the ombudsteam and we
haven't had feedback from them. But it's in progress.

     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: Remains in progress.

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

Warren: In progress.

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

Eric V: In progress.

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

Murray: I have the token. I'll move it along next week.

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

Eric V: In progress.

     o Alvaro Retana and Martin Vigoureux to draft text on guidance
       regarding the number of document authors on documents.

Martin V: In progress.

     o Alvaro Retana, Rob Wilton, Alissa Cooper, and Martin Vigoureux to
       draft text on the framework for a long-term future plan for the
       IETF.

Rob: In progress.

     o Roman Danyliw to draft text for a request to the Tools Team to move
       BoF requests from the BoF Wiki to the Datatracker.

Roman: In progress.

     o Barry Leiba to draft a proposal regarding moving the deadline for
       BoF Proposals for IETF 109 earlier (more than two weeks before the
       BoF Coordination Call).

Barry: This is complete. I posted the proposal, there's been a little bit of
discussion, and it's on the agenda for one of the meetings prior to 108.

     o Alvaro Retana, Warren Kumari, and Barry Leiba to draft clarifying
       text on Errata Best Practices.

Barry: In progress.

     o Magnus Westerlund to find designated experts for the RDMA-CM Private
       Data Identifiers registry (RFC8797) [IANA #1173341]

Amy: This is just to let you know you have this action item, Magnus.

     o Ben Kaduk to find designated experts for RFC 8784 [IANA #1173591]

Amy: This is a new item for Ben.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-pim-igmp-mld-snooping-yang-17  - IETF stream
   A Yang Data Model for IGMP and MLD Snooping (Proposed Standard)
   Token: Alvaro Retana

Amy: Alvaro is not here and I have a couple of Discusses; do the Discuss
holders feel these require a Revised ID, or are you just going to follow up
with Alvaro or the document authors?

Rob: I'll follow up with Alvaro.

Ben: I think following up with Alvaro should be good enough.

Amy: It sounds like AD Followup is the correct substate?

Rob: Yes I think so.

 o draft-ietf-nfsv4-rpc-tls-08  - IETF stream
   Towards Remote Procedure Call Encryption By Default (Proposed
   Standard)
   Token: Magnus Westerlund

Amy: I have a number of Discusses in the tracker. Do we need to discuss those
today?

Magnus: I don't think so.

Ben: I guess I did have one point we might talk about. In the case we're
using RPC over DTLS you can shut down the DTLS association and you may want
to start sending unprotected RPCs again, even if just to do STARTTLS again.
When there's an ephemeral port you can have a cool-down time to let any
packets that are still buffered in the network to get by and get discarded
properly. But it seems like there's some ambiguity between whether the
incoming packet should be processed as a DTLS packet or as an unprotected
RPC. I believe in some of the NFS situations you're using a fixed port for
both the source and the destination, so you wouldn't necessarily be able to
get away with a cool down period.

Magnus: I think we need to let the WG figure that out. It's a valid point but I
think it has too much to do with the deployment.

Ben: Fair enough. I don't think DTLS deployments are common for NFS. That might
be why people are...

Magnus: I'm uncertain that they've tested this or come to implement the TLS
side. They're probably less experienced with DTLS side.

Ben: Okay. I'll wait and see what we hear back from the authors then.

Magnus: They have an interim meeting today so we'll discuss it soon. So Revised
ID Needed for this.

 o draft-ietf-pce-stateful-pce-lsp-scheduling-19  - IETF stream
   PCEP Extensions for LSP scheduling with stateful PCE (Proposed
   Standard)
   Token: Deborah Brungard

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

Deborah: I don't think so, unless someone wants to discuss something. I think
it's best for the authors to respond on the inconsistencies and the comments,
like the one from Alvaro.

Amy: Okay. And this should be AD Followup or Revised ID Needed?

Deborah: Revised ID Needed, definitely.

 o draft-ietf-i2rs-yang-l2-network-topology-14  - IETF stream
   A YANG Data Model for Layer 2 Network Topologies (Proposed Standard)
   Token: Martin Vigoureux

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

Martin V: Yes. I'd like to better understand Magnus's Discuss. Magnus, I'm not
sure how to read your Discuss or understand it. Are you suggesting that there
should be a formal review from IEEE on that specific model?

Magnus: If you were on the IETF-IEEE coordination list you would have seen that
exchange. It was a request from Glenn because he was like, oh, you've done
this? We need to review it! So we should discuss if we give them the time, it
might even just be one week, to see if they have feedback.

Martin V: That's the question I have; what do you mean by feedback? In the
sense that having your Discuss gives me the impression that IEEE could hold a
Discuss on that document.

Magnus: No, no. I have a Discuss so that we discuss if we should do something.
My intention was to release this Discuss now by having an agreement on what the
step is to deal with the IEEE and their request now.

Warren: If the IEEE came back and pointed out a serious issue, I'm assuming it
would be perfectly reasonable for Magnus to hold a discuss saying 'I've learned
this does not work for reason.' I think that seems reasonable.

Martin V: I'm not saying it's unreasonable, I'm just trying to understand the
process here. I wasn't aware that formal reviews by IEEE was part of our IESG
process.

Magnus: No it's not, but.

Martin V: Since you wrote it's a process Discuss.....

Magnus: Yeah, I wrote it's a process Discuss because it's for us in IESG to
discuss what we should do here, not anything else. It's to say the WG shouldn't
be up in arms. Sorry if I wasn't clear enough.

Martin V: It's fine; I was just looking for clarification and I believe I have
received it, so thank you. I have read Glenn's reply but I think there was some
misunderstanding also on the scope of the model. We can pull this apart and I
have seen the specific questions asked by Sue on that list, which were taking
their roots in Ben's review. For me, the next step is effectively to wait for
IEEE feedback on that document and even if you had no Discuss I wouldn't
approve it before we get that feedback.

Magnus: Good. Do you communicate with Glenn and say we appreciate feedback they
have and will not make decision until next week? I think that's best. And I
will remove my Discuss now.

Martin V: Yeah I can do that.

Rob: I think IEEE may have some concerns with our use of the terminology VLAN
and QinQ and how those line up with the IEEE standards. So I would expect
comments back on that.

Martin V: I think that should be easy to address.

Rob: Maybe!

Martin V: Okay. Thanks Magnus and Rob. I guess it will require a Revised ID. I
will send that email to the list.

 o draft-ietf-tcpm-rto-consider-16  - IETF stream
   Requirements for Time-Based Loss Detection (Best Current Practice)
   Token: Martin Duke

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

Martin D: I think we do. Ben, I know you're having a discussion with Mark about
this. Obviously this is drawn with experience from TCP. Your point is accurate
and yet I'm not 100% sure how we should proceed.

Ben: I'm not 100% sure either. I guess it was not super clear, but my first
point had some predicates that it doesn't make sense if those predicates
don't hold. So if the whole point of this document is to give guidance to
future protocol designs, for protocols that are doing loss detection via a
timer, after the absence of an ACK.  If those all hold, there's maybe
something we should do here, especially if we know there's only this SHOULD
level requirement for the whole document's procedures and you can do an
exception if you have some justification.

Martin D: I think we should certainly add something in the security
considerations about this. I would have to go back and look at the text again;
if there's something that describes the acknowledgment mechanism or the
requirements for the acknowledgements, if we just put a SHOULD in there about
making it hard to guess, do you think that's sufficient?

Ben: That might be sufficient. I'd also have to go back and check. I don't
think we currently have an acknowledgment mechanism in the text so there might
not be a good place to add something. I guess the place I'm uncertain about is
if having a SHOULD be un-spoofable, that is also affected by the overall SHOULD
for SHOULD comply with the practices here. I don't know if that sends quite the
message that we want. It might. I'll have to think about it a bit more.

Martin D: It's an odd document in a lot of ways. I don't know if Mark would
agree, but as I see it, when people do things on top of UDP, setting aside
QUIC, people who are doing their own loss detection because they're running
over UDP, that's the ideal target audience for this document. I think clearly
this is a Revised ID Needed and we will add some text here.

Ben: I'm not planning to die on this hill.

Martin D: Okay. I'll add another email to the thread once I check the
acknowledgment text.

Magnus: A comment; I think it probably shouldn't be too specific about how you
achieve that secure reliability, etc. I think that's the safest, considering
where this might end up.

Ben: We don't need to be very prescriptive about how these things are done.

Martin D: I don't want to end up defining security properties of the transport
in general. I think it sounds like we can reach something mutually agreeable.

2.1.2 Returning items

 o draft-ietf-lisp-gpe-17  - IETF stream
   LISP Generic Protocol Extension (Proposed Standard)
   Token: Deborah Brungard

Amy: I have no active Discusses for this document so unless there's an
objection now it looks like this one is approved.

Deborah: Thanks, everyone, for reviewing. This definitely needs a Revised ID
because there were quite a few comments.

 o draft-ietf-lisp-rfc6830bis-32  - IETF stream
   The Locator/ID Separation Protocol (LISP) (Proposed Standard)
   Token: Deborah Brungard

Amy: I have a number of Discusses in the tracker. Do we need to discuss those
today?

Deborah: I don't think so. I think we should wait for the authors, unless
somebody has something.

Michelle: We marked it as IANA OK but we did ask the authors to clarify some
language in the IANA Considerations section with what they're requesting to do,
but since there are so many other Discusses hopefully they can clear that up
with the Revised ID.

Deborah: I'll make sure they get at it.

Amy: Okay, so that is going to stay in IESG Evaluation, Revised ID Needed.

 o draft-ietf-lisp-rfc6833bis-27  - IETF stream
   Locator/ID Separation Protocol (LISP) Control-Plane (Proposed
   Standard)
   Token: Deborah Brungard

Amy: I have a number of Discusses in the tracker. Do we need to discuss those
today?

Deborah: Again, I don't think so, we'll let the authors respond. I think they
should be pretty straightforward to address. That's also Revised ID Needed.

 o draft-ietf-dprive-bcp-op-12  - IETF stream
   Recommendations for DNS Privacy Service Operators (Best Current
   Practice)
   Token: Eric Vyncke

Amy: I have no active Discusses for this document so unless there's an
objection now it looks like this one is approved.

Eric V: Revised ID Needed, please.

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-dots-use-cases-25  - IETF stream
   Use cases for DDoS Open Threat Signaling (Informational)
   Token: Benjamin Kaduk

Amy: I have no active Discusses for this document so unless there's an
objection now it looks like this one is approved.

Ben: We just got a few nits so I think we can leave this as Announcement to be
Sent and we can roll those fixes in when we send xml to the RFC Editor.

Amy: Great, it will go into Approved, Announcement to be Sent.

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

 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 Grant Negotiation and Authorization Protocol (gnap)

Amy: I have no blocking comments for this chartering effort, so unless there's
an objection this charter is approved. Hearing no objection, so we will send
the WG Action announcement for gnap.

Roman: Thank you, everyone, for all the feedback.

 o Privacy Pass (privacypass)

Amy: I have no blocking comments for this chartering effort, so unless there's
an objection this charter is approved.

Ben: There are no comments of any sort, so it looks like we did well.

Warren: I just realized I haven't actually been clicking the button for WGs. I
just added my No Objection.

Amy: It looks like this is ready to go so we will get that announcement sent
tomorrow.

 o Stay Home Meet Only Online (shmoo)

Amy: I have no blocking comments, so unless there's an objection this charter
is approved.

Ben: Not objecting, but I wonder if we think SM should get a response to his
latest emails.

Alissa: I thought the people on the IAB responded to him?

Mirja: Only on one specific point.

Alissa: That was his question, right?

Mirja: There were a couple more things.

Alissa: I'll try to find them.

Amy: Did you want that to happen before this is chartered?

Alissa: No.

Amy: Okay, so this charter effort is approved and we will get that sent,
probably tomorrow.

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

Amy: Alvaro is not here, can someone fill in if there is IAB news to impart?

Mirja: I wasn't at the last call. I don't think there's anything to report,
unless Alissa has something she wants to mention.

Alissa: No, I do not.

6. Management issues

6.1 [IANA #1173341] Designated experts for the RDMA-CM Private Data Identifiers
registry (RFC8797) (IANA)

Amy: We've assigned this action item to Magnus.

6.2 [IANA #1173349] Secondary TZ Coordinator (IANA)

Amy: This is to officially designate a second coordinator. Any objection?

Barry: The ART ADs certainly support this.

Amy: Great. I'm hearing no objection. The second expert is named as Tim Parenti
and we will send an official note to IANA.

6.3 [IANA #1173346] Management Item: Acceptance of media type registration from
standards organization Sequence Ontology (IANA)

Barry: I've checked them out and it seems reasonable.

Amy: Any objection to adding Sequence Ontology to the list?

Ben: Do we expect to get more media types from them in the future?

Barry: Exactly the question I asked. If not, I figured we would just approve
this one. They're not expecting to submit a lot but they said they might submit
one more. So we thought it's benign to put them on the list, let's add them.

Ben: I didn't do very much investigation.

Barry: The intent of that designation is for subject matter SDOs in different
industries. That they are. I'm happy to go back and say we'll approve them one
at a time but the only thing this allows them to do is submit a media type
request that gets expert reviewed without having to come to the IESG.

Ben: I'm happy to defer to your more in-depth investigation.

Amy: It sounds like adding them to the list is approved and we'll send official
note to IANA.

6.4 [IANA #1173591] Designated experts for RFC 8784 (IANA)

Amy: This is just to alert Ben that he has designated experts to find for this.

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

Amy: Just a couple of reminders; we have another formal telechat next week
which means you won't be getting the preliminary package until tomorrow. On
Monday we start our normal adding of an extra week to Last Calls, so any Last
Call we see starting from Monday will have that next week added as we usually
do around a meeting.