Narrative Minutes interim-2020-iesg-17 2020-07-16 14:00
narrative-minutes-interim-2020-iesg-17-202007161400-00

DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2020-07-16 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
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
Murray Kucherawy / Facebook / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
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
Robert Wilton / Cisco Systems / Operations and Management Area

REGRETS
---------------------------------
Alissa Cooper (Cisco) / IETF Chair, General Area
Jay Daley / IETF Executive Director
Erik Kline / Loon LLC / Internet Area
Warren Kumari (Google) / Operations and Management Area
Magnus Westerlund (Ericsson) / Transport Area

OBSERVERS
---------------------------------
Greg Wood

1.2 Bash the agenda

Roman: Can I have a little time at the end to button up the protocol
vulnerability reporting guidelines, please?

Rob: Barry, did you suggest we discuss the document limit on a second week
today?

Barry: Sure, let's put that on.

Martin V: Can I have two minutes at the end to ask a question relating to the
draft-knodel-terminology document about offensive words?

1.3 Approval of the minutes of past telechats

Amy: Generally we give these two weeks between formal telechats, which we
haven't had. I think we should defer both the official and narrative minutes
until after IETF 108. Any objection to that? [none] So when we come back in
August we'll have the July 9 and July 16 minutes to approve.

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: Let's keep this in progress and we'll take it off if it's resolved at
the end of the call.

     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: 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: Continuing progress.

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

Amy: Warren could not be with us today so we'll keep this in progress for him.

     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've been talking to Michelle about getting their feedback. I still
have to look at Alvaro's pull request. Still in progress.

     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.

Alvaro: In progress, and so are the other two that have my name on them.

     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.

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: I wanted to ask a clarifying question. I was trying to write that up but
I lost the bubble in terms of how we wanted to scope that. Currently folks put
things on the bof wiki, but then I forgot what exactly was the support we
wanted in datatracker and how rich was that front end supposed to be? Did we
decide that or were we asking for a proposal?

Amy: From my recollection I believe it was to treat proposed Bofs sort of like
the little sibling of the proposed WG, so once you have a chair named they
could do stuff in the datatracker for the Bof. But I don't think it was really
well defined yet. I think you were looking for what's possible.

Barry: I remember Roman was going to talk to the tools team about what would be
reasonable to do. I think we thought there would be a form that people would
fill out to fill in the appropriate fields and then see what the tools team
thought would be a reasonable way for people to manipulate it.

Roman: Okay. I didn't exactly remember it that way but it's clear to me now and
I can progress. Put it in progress, please. Thanks.

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

In progress.

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

Magnus could not be with us so we'll mark this in progress.

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

Ben: Also in progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-bess-evpn-inter-subnet-forwarding-09  - IETF stream
   Integrated Routing and Bridging in EVPN (Proposed Standard)
   Token: Martin Vigoureux

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

Martin V: No, but I would like to say a few words. First of all, apologies
because I didn't have the time to go through your Discusses so that's partly
why I'm not able to discuss them today. Out of my head I think they are
technical objections and process objections. The technical objections, I'm
really happy you caught them and the fact is I have had some challenges myself
to have my own technical objections be resolved because the authors took eight
months to reply to my AD review. I believe those months took me way off the
document and that's partly why it's in that state. The end result is that you
caught them and I thank you for that but I'm sorry it gave you more work than
expected. Now I am not sure how long the authors will take to reply. On the
process objections, I believe those mainly concern the normative references on
documents which are not advanced enough. I checked with the chairs and both IRB
multicast and GENEVE are up for WGLC soon, like in August. I think we are on
the safe side here. Ben, you're suggesting to still do everything in the right
order. Did I read you correctly?

Ben: I don't think we need to be strictly holding up on clicking the Approve
button for this document until the other documents are also ready to be
approved. I think we've done similar things in the past where we will know that
the dependencies are believed to be done and we can move ahead with the
document such as this one which depends on them.

Martin V: In any case I think resolving the technical objections will take
time, so it will possibly give time for the other documents to reach me. I
think that should allow us when possible to approve in confidence. I have some
other documents in bess that have the same type of issues, so I will be working
with the chairs to redefine their WGLC plan so that this doesn't happen again.
Knowing that I don't have the Discusses out of my head, if one of you wants to
try to raise a specific point I'm happy to try to answer it.

Ben: One specific point I don't know enough to answer and I'm hoping someone on
the call might know. With the risk of having a MAC address collision between
the customer system and the well known range value we're trying to use, what is
the actual risk of a collision? Would the customer somehow be using a MAC
address from a reserved range even though it's a reserved range? I did not
expect you to answer this, maybe someone from Internet area.

Martin V: I don't think I have an answer for that. I think it can happen, but
it's not supposed to happen. [audio cut out]

Ben: I don't think we need to have a mitigation for it strictly, I just think
we need to be clear about documenting what the actual risk is. In some sense my
Discuss point could be read to say that there's an internal inconsistency about
is there a risk vs. is there not a risk? I don't know there's a specific
mitigation we'd be able to use for this case. I guess we should continue the
discussion via email and see if anyone else chimes in.

Martin V: Okay, thank you Ben and everyone else for your time and review.

Amy: I'm hearing that this discussion is ongoing so it will require a Revised
ID?

Martin V: Yes.

 o draft-ietf-lsr-isis-invalid-tlv-02  - IETF stream
   Invalid TLV Handling in IS-IS (Proposed Standard)
   Token: Alvaro Retana

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

Alvaro: We're going to need a Revised ID for this one.

 o draft-ietf-ippm-stamp-option-tlv-07  - IETF stream
   Simple Two-way Active Measurement Protocol Optional Extensions
   (Proposed Standard)
   Token: Martin Duke

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

Martin D: No, I think this is clearly a Revised ID Needed. There was a lot of
revision in Last Call. These are really good points.

2.1.2 Returning items

 o draft-ietf-hip-native-nat-traversal-31  - IETF stream
   Native NAT Traversal Mode for the Host Identity Protocol (Proposed
   Standard)
   Token: Eric Vyncke

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

Eric V: No, I would have loved to see Magnus's review because the point he
raised has been fixed. And Martin, on your two points the first one is a good
one and easy to fix. I would love to get the wisdom of the crowd here. This is
a standard track document and it refers to the nat-traversal by using ICE,
which is 5770, which is experimental. And indeed Martin, it's really used as a
normative. It really refers to some procedures there. I was hoping naively to
get it done right but can we do this for experimental? I know we can do it from
standards to informal, but standards to experimental I have no clue.

Alvaro: We've done that before with some other references.

Ben: In terms of the process and the level of maturity, we don't really
differentiate between informational and experimental.

Eric V: On the other hand there are not too many implementations of this, maybe
one by Ericsson, so keeping it experimental could be another way. I will check
with the authors. Anyway, Revised ID Needed, clearly.

Martin D: Was the outcome that we're going to ask the authors to go to
experimental?

Eric V: Right. That's easier.

Martin D: Okay, thanks.

 o draft-ietf-lpwan-coap-static-context-hc-15  - IETF stream
   LPWAN Static Context Header Compression (SCHC) for CoAP (Proposed
   Standard)
   Token: Eric Vyncke

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

Eric V: I don't think we need to discuss. Ben has a couple of points that are
all technical and very well detailed and easy to fix. The authors are quite
responsive so I expect to get this fixed in the next days or weeks. So no point
to discuss except if you think so, Ben.

Ben: No, I don't think we need to discuss it. Just to note further that my last
point about CoAP being end to end or not is something I'm only 95% confident
about. I think someone else had already raised similar issues so probably
that's okay.

Eric V: Okay, point taken. So Revised ID Needed.

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

 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

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Network File System Version 4 (nfsv4)

Amy: I have no blocking comments for this rechartering effort, so unless
there's an objection now  this will go for external review. Hearing no
objection, so we will send this announcement and put it back on the agenda for
August 13.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Alvaro: I had mentioned before this program that the IAB is talking about
called Evolvability, Deployability, and Maintainability. There was some
discussion on the architecture discuss list and I keep bringing it up because I
think there's a close relationship with what we do with the WGs and right now
some of the text talks about making accommodations to WGs. If I understood the
discussion yesterday correctly the next AI is to clarify some actions and goals
to make sure it fits an IAB program, which I think it does. We just need to
coordinate a little bit on some of the things that may come out. So keep an eye
on that. If anyone is interested in participating there, it will be an open
list at some point and I'll keep informing you guys as it goes forward.

Mirja: We also put this on the agenda for our joint meeting so there will be
time for discussion there. We're looking for people from the IESG who want to
actively participate in the program too.

6. Management issues

6.1 [IANA #1172452 ] Application for a Port Number and/or Service Name
"3gpp-w1ap" (IANA)

Amy: This is a request for a port number and Magnus has confirmed that this is
ready to be sent for review.

Michelle: That's correct.

Ben: To refresh my memory, is this the one that we had some liaison statements
about? Because we had tried to get them to use ephemeral ports in the future
but their timelines didn't line up quite right so they wanted just one last
assigned port number?

Michelle: We have been working with the liaisons on this. In my notes it says
that Lionel Morand sent a liaison statement to the port experts mailing list on
July 1. So I think the experts wanted to see them conserve on ports but for
some reason they also needed this one as well. Ultimately Magnus said that he
thought it should go to the IESG for final approval. 'The IESG would like to
receive a liaison statement with a commitment from 3GPP to find an alternate
solution to network internal interfaces for the future before approving this
request' and then Lionel sent a liaison statement, so that satisfied the
request. This is just the final step that Magnus wanted to put this request
through.

Ben: Okay, thanks. I think that matches my understanding of which port this
was. It sounds like we should approve this because we think, fingers crossed,
it will be the last one.

Amy: So the question is, does anyone object to granting this request?

Michelle: Magnus did say he was going to work on a response to the liaison
statement, so he's going to wrap up that end as well.

Mirja: Lionel is not the liaison anymore so we should probably update the
contact information to something more generic here. No, sorry, I'm mixing this
up. He's the new one. But I'm still wondering if we should change it to
something more generic, because they change over time.

Michelle: We can talk about that. We have information in our internal records
of which liaisons we need to contact for which group, so if there's something
to update we're happy to do that. I'll follow up on that separately.

Mirja: Perfect, thanks.

Amy: I didn't hear an objection to approving this request, so this is approved
and we will send official note to IANA.

6.2 [IANA #1174385] Acceptance of media type registration from standards
organization ECMA (IANA)

Barry: ECMA is the organization that does ECMA script and this is related to
JSON. They are definitely a standards organization and we should definitely put
them on the list. I think many of you know about them.

Amy: Any objection to adding them to the list? Hearing none, so this is
approved and we will get notification sent to IANA.

6.3 Reporting Protocol Vulnerabilities (Roman Danyliw)

Roman: I want to thank everyone for the feedback provided. I received no
additional input from IESG but got helpful comments from Jay, Greg, and the
tools team, specifically Russ and some outside folks. Jay helped us thread the
text with the upcoming policy statement coming from the LLC. Greg threaded it
stylistically with some of the other content that's already on the website and
Russ also pointed out some process things. These are all nits so I believe the
text is gold and the pointer to that is in your mailboxes. The two open
questions are, what is the format by which we want to publish it? And two,
after we publish it, what are the places on the website we want to make sure we
hook this so it's prominent enough but not in your face?

To the first, we have two options. We can choose to make this an IESG
Statement, or just make it content on the website. Does anyone have any strong
feelings about which way to take it? Would anyone object to just making it
content on the website as it's not actually providing any new change in
process, it's just an explanatory document?

Eric V: Not at all, I was about to suggest exactly what you said. It's better
if you do it only on the web.

Roman: I think it's more dynamic that way so that would be my preference. The
other piece, does anyone have any strong ideas or object to all the places I
referenced in the email? Realizing we can always change it later.

Mirja: I found all proposals not super great because none of them is easy to
find. But I also don't see a better one.

Roman: The alternative is to make it really prominent on the splash page and it
doesn't seem like this is big enough to do that. Greg had a late breaking
suggestion to also make sure that we put it into the errata area as well.

Mirja: That's a good idea. I think the best fit was maybe on the Contact site.

Roman: You don't want it in the other places?

Mirja: I don't mind also having it in the other places.

Roman: Okay. I'll talk to Greg and we can always incrementally put it in more
places.

Ben: The idea is we shouldn't put it in .well-known/security.txt until that's
actually registered?

Roman: Correct. So we'll close the action item for this and just for everyone's
awareness, Jay is going to drop something for community comment because he is
publishing an LLC policy that we're referencing, but his spin is independent of
what we're doing. Thanks for all the feedback.

6.4 Page Limit for Back-to-Back Telechats (Barry Leiba)

Barry: A few of us were chatting about this at the beginning of the call before
most people were on. It has to do with my deferring the anima-acp draft because
I didn't have time to review it. A couple people mentioned that one of the
issues is we had two weeks in a row of formal telechats with a large number of
pages on each. Maybe we should reduce the page limit for the second week in
cases that happens. Does anybody think that's a bad idea? Does anybody have a
specific suggestion for how much to reduce the page limit for the second back
to back?

Murray: What's the page count for a typical telechat?

Amy: 400 pages.

Barry: We could cut it in half and say 200, or someone suggested 250.

Murray: Those both sound plausible to me.

Eric V: I would not go higher than 200, to be honest. Sometimes we have to
schedule our week with the rest of our job. I'd go to 200 or lower.

Barry: Other thoughts?  Should we do 200 then? Or Eric, do you want to go to
150?

Eric V: I'm fine with 200. But I would object politely to 250. And again,
you're perfectly right to defer on this one.

Roman: I can compromise with you at 175 if this closes the deal.

Barry: Okay. Shall we say 175 then? Anyone think we should do something
different?

Amy: What I'm hearing is that you'd prefer to limit the page count to 175 for
only the second telechat of two back-to-back ones.

Murray: Can we do an average across both?

Barry: None of this is cast in stone anyway. If we tell Amy a document really
needs to get on, she'll do it.

Rob: My aim here was to avoid people reviewing docs that get deferred later. So
just having a lower limit means this way everyone will be focused on the
documents to review.

Barry: We're less likely to have deferred documents, but as long as we can hit
defer it's always going to happen that someone's going to defer the document
you just finished reading, and oh well. But the purpose is to make it less
likely that we will need to defer.

Amy: Great, we will put that in our procedures.

6.5 draft-knodel-terminology (Martin Vigoureux)

Martin V: In IETF we have the draft-knodel-terminology. Across the industry,
organizations are taking steps to effectively remove offensive language from
different places (code, documentation, and so on). As it happens, Nokia is
taking steps in that direction. My question is: Nokia has implemented (along
with others) RFC 6870 which is about pseudowires, which uses the master/slave
wording. We are effectively thinking of modifying our documentation but more
importantly, our CLI, to remove those terms. The question we have is what are
the possible implications on 6870? If we want to follow the trend in IETF,
should people feel an errata? Can we consider this change as simply editorial
or should it be a draft which updates the RFC knowing that there are some CLI
implications? For example Juniper and Cisco have exactly the same CLI with
master/slave wordings.

Barry: I think this is not something errata is appropriate for. It would
certainly be reasonable to bis the documents that use those terms to update
them. That's just on a document by document basis and whether a WG or AD wants
to deal with that.

Martin V: Thank you for your opinion, Barry. Can you tell me why you think an
errata is not appropriate?

Barry: Errata is intended for something that would have been considered an
error when the document was published but we missed it. This is something that
our views on it have changed since the document was published, and that's not
what errata are for.

Eric V: For this one you're proposing to put an update there. That's fine for
one document but I fear we'll have an avalanche of people wanting to do a bis.
Same for all the YANG models and everything with master/slave in it. Do we
really want this avalanche of new RFCs?

Barry: My preference would be that these issues get fixed as documents are
opened for other reasons, rather than going back and opening them just to fix
this. But there may be people who feel differently, who feel so strongly that
this terminology needs to be eradicated that they're willing to do that work.
I'm not going to tell them no.

Martin V: I can talk to what's happening in Nokia. People feel it is important
to take a step in that direction. The small issue with 6870 is that by making
that change, we could somehow be considered as not being compliant anymore with
6870. I don't believe so, but people do believe so, that compliancy includes
using the same terminology. That's why the willingness to change something
within Nokia has raised a question of changing the standard.

Alvaro: I'd imagine in this case that assuming we have that other terminology
draft to point to, if the community agreed on alternative language, it would be
relatively easy to point to that as the justification. By that reference we can
still be compliant. The RFCs don't exactly talk about specific CLIs, so the CLI
saying something is better that it matches to what the RFC says but it's not
necessary for compliance.

Martin V: That's exactly the point I've made internally but I got the argument
back that master/slave describe functions and if you call these functions
differently in your code you could get in a challenging situation with regards
to compliancy.

Eric V: We could issue an IESG statement or RFC that every time you see X
replace with Y and we go.

Martin V: I think we are getting into the wider debate. I think I got an answer
to my question which was that errata is not the right place for that. I can
live with that. Indeed, it opens the discussion but I'm not sure it's the right
time to have it now: Should we as IESG take that topic as an action item and
provide guidance to the community on how to do it, or expect each RFC to be
updated? Or as Alvaro said having a master document serving as the pointer? If
the situation continues to develop, we might have to do something. I'm not
asking for the solution now but I know it's going to be a topic.

Alvaro: I thought this topic came up on the list a few weeks ago.

Martin V: Yes but I don't remember any conclusion.

Alvaro: I thought the conclusion was we're going to let them go to gendispatch
and see what happens there, and not take this up as an IESG action now. Is that
how everyone else remembers it?

[chorus of yeses]

Deborah: I also think it shouldn't be an errata; it would have huge operational
impact. I think let's look at the documents in gendispatch.

Martin V: That implies that IETF-wide we agree on a replacement for the
offensive terms. Which is going to be extremely challenging because depending
on the context the replacement might be different.

Rob: In terms of the actual change of terms, my understanding is that in Cisco
we're looking to update documentation. I'm not sure we were currently planning
to change keywords at this stage. So we're doing what we can without impacting
customers. The other point you raise, whether we should wait for draft-knodel
to progress, I do wonder whether the IESG shouldn't do some statement or
something sooner, making some comment on it rather than being silent. That's my
one concern, that IETF seem to be slow responding compared to other
organizations.

Martin V: I agree with that last statement.

Roman: Am I hearing right, there's a proposal for three things? The notion just
mentioned that the IESG needs to say something about that in the IETF context,
two, there is progress in gendispatch that describes a document that suggests
the changes to be done, and then I'd propose there's a third discussion which
is to have a conversation about how said guidance codified in that document
could be applied. Like the difference between BCP, informational, whether we
open up documents, etc.

Alvaro: Going back to an IESG statement, what can we say? The only thing we can
say is that there is offensive language. Unless we have agreement on the
terminology or the effect, the other two parts, it doesn't seem like there's
much we can say.

Roman: There's certainly power in acknowledging that there is, and some
statement saying what is the IETF doing about that? Highlighting those two
steps minimally would have some power as well. Saying that we have a thing in
gendispatch that might describe what we do and also need to have a conversation
as a community how we action that.

Rob: Exactly.

Roman: To let people know where to potentially participate.

Deborah: We have IESG statements but also some kind of brief. Alissa could also
put it in her summary of the meeting that this is being worked on in
gendispatch.

Martin V: That's good. Thank you, Roman.

Roman: Since we're restricted to telechats before the meeting, let's put this
on email. Maybe put a marker on the agenda for the pre-meeting call.

Mirja: I think someone should take the action to write up some text to get it
started.

Roman: I can't do that in the next week but I can later.

Martin V: Let's continue talking over email and come to some conclusions about
immediate next steps.

Roman: Minimally I can write up the three things I just said and send them in
email so we have a place to start.

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