Skip to main content

Narrative Minutes interim-2020-iesg-22 2020-10-08 14:00

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

Narrative minutes for the 2020-10-08 IESG Teleconference

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

1. Administrivia
1.1 Roll call

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 ChairWarren 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 Eric Vyncke
(Cisco) / Internet Area Robert Wilton (Cisco Systems) / Operations and
Management Area

Jay Daley / IETF Executive Director
Martin Vigoureux (Nokia) / Routing Area
Magnus Westerlund (Ericsson) / Transport Area

Adrian Farrel
Tim McSweeney
Francesca Palombini
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 approving the minutes of the September 24
being approved? Hearing no objection. Does anyone have an objection to
approving the narrative minutes? Hearing no objection there. We'll get those

1.4 List of remaining action items from last telechat

     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.

Amy: This has been updated into another action item so this particular item is

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

Warren: Still in progress.

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

Eric V: Still in progress.

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

Murray: I have what I need to get Ben and Alvaro together to sync up. Moving
slowly but still moving.

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

Alvaro: 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

Alvaro: 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: We're in discussions. This won't be live for 109.

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

Alvaro: Also in progress.

     o Eric Vyncke to follow up on the suggestion at IETF 108 to share a
       list of grammar checking tools with the community.

Eric V: Still in progress.

     o Barry Leiba to discuss possible datatracker feature request
       regarding flagging who is responsible for the next step for a
       document; the document authors, the WG Chairs, the AD Discuss
       Holder, or the Responsible AD, with Robert Sparks. The feature
       request should include a "length of time in state" flag.

Barry: You can mark this done. We need to discuss it at the next informal. The
short answer is that I've had some discussion with Robert about it and he's
discouraging in his comments because of the difficulty of implementing in the
Datatracker. He suggests we might just use the Datatracker comments to keep
track of this rather than force it into the Datatracker fields. But we can
discuss it at the next informal; I'll put it on the agenda.

     o Robert Wilton and Warren Kumari to draft a charter for a proposed
       IOTOPS Working Group.

Rob: In progress.

     o Martin Vigoureux to find designated experts for RFC-ietf-babel-
       rfc6126bis [IANA #1178016]

Amy: This is on the agenda as a management item.

     o Roman Danyliw and Murray Kucherawy to find designated experts for
       RFC 8894 [IANA #1177950].

Roman: In progress.

     o Murray Kucherawy to find designated experts for RFC 8876 [IANA

Amy: This is a new item for Murray.

     o Robert Wilton, Alissa Cooper, Alvaro Retana, and Warren Kumari
       to gather more data regarding the impact of COVID-19 on the IETF.

Alissa: I got some mailing list information from Alexa. I haven't had time to
do anything with it yet.

     o Martin Vigoureux and Alvaro Retana to work with Jay Daley on the
       process for using EthicsPoint incident management software as
       the mechanism of private feedback and anonymous reporting.

Alvaro: This is in progress and we've already started talking to Jay.

     o Barry Leiba to draft a policy about when to create and announce
       mailing lists for new potential Working Groups in order to
       facilitate discussion of the Proposed WG charters.

Barry: This is in progress. I expect to get to it tomorrow.

     o Erik Kline to find designated Experts for RFC 8915.

Amy: This is a new item for Erik K.

Erik K: This is in progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-idr-rfc8203bis-07  - IETF stream
   Extended BGP Administrative Shutdown Communication (Proposed
   Token: Alvaro Retana

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

Alvaro: Sure. First I want to thank the ART area for letting me have this
document here today. Alissa, I know that Jacob has been emailing back and
forth. I don't know if you want to talk about that last question that you had.

Alissa: He didn't really answer the second question here in the ballot, but
that's okay. I think what he's proposed gets to the core of the issue anyway. I
was just trying to make sure that whatever information needs to be in the
document will be there, so somebody who goes and looks at this knows what
message they're going to send and how they're supposed to decide that. That's

Alvaro: What happens is the notification is an error message that says 'reset
the session.' There's nothing that happens after that. It doesn't necessarily
matter that much that you understand what I told you as long you know it's a
notification. The session is going to be reset anyway, so if I send you no text
or 128 bits or octets or 255, we're going to do the same thing and reset the

Warren: Different people have very different ways of putting info in their
ticketing system, etc. This text is fairly much always just used by humans so
the interesting thing is there is a message there saying it'll be back in two
hours, vs oops it disappeared. I don't know if trying to standardize the
message does make much sense. It's similar to people just sending out emails
saying 'I'll plan to do these seven things, see you in a bit.'

Alissa: I'm not suggesting anybody standardize the message, the question is
just literally, the guy there wants to send his message in Cyrillic and how
does he decide whether he should or not? That's all.

Alvaro: He is going to send it, it doesn't matter if the other guy understands
it or not.

Barry: It's just going to be a question of if the message appears in the log or
not. They're not going to be expecting a message that long, so they'll ignore

Alissa: I think the text he suggested now captures this much better than the
text we're looking at on the screen.

Alvaro: Okay. Great. We're going to need a Revised ID on this.

Alissa: I just want to ask how we could catch this better in the future on the
first try, if anybody has a thought.

Alvaro: I have no idea. We thought we were doing the right thing thinking about
internationalization. We just didn't think about that some messages when
translated would be a lot longer. Usually 'I'll be back in 2 hours' probably
fits, but if you want to say more, it just won't fit.

Barry: This isn't really a classic internationalization problem of how to
represent things or how to compare them. This is simply, nobody thought about
that the translation would wind up being more octets than the original. Given
that we haven't run into this a lot, I don't think it's worth a lot of cycles
to deal with. I don't think it will come up frequently. The only thing I can
think of is try doing a few translations before you publish the first version
and see what happens.

Warren: There was also a lot of effort when this was originally being done to
keep the message small. There was a huge amount of discussion that this should
not turn into Jabber over BGP. So I think this was a victim of people trying to

Alissa: That's interesting.

Ben: It seems perhaps it's a case where whether you're counting bytes or
unicode code points could be relevant. The idea was to limit the length to
avoid the jabber but also to avoid being able to put in long confusable things
that might cause problems with your parser. So they put a limit on, but the
limit is in bytes. If the limit had been in code points maybe that would have
been enough. But we do have the hard cap in the number of bytes in a single
byte field, so you still couldn't get all possible combinations of 128 code
points within those 255 bytes.

Alissa: Okay. I just wanted to check.

 o draft-ietf-dnsop-dns-zone-digest-12  - IETF stream
   Message Digest for DNS Zones (Proposed Standard)
   Token: Barry Leiba

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

Barry: There are two discusses and a bunch of useful comments. Mr. Recuse, is
there anything you would like to discuss here?

Warren: I believe the authors have addressed all of the comments and there are
commits/pull requests waiting for Roman and Ben to review. I think we can work
with them offline.

Roman: Did that happen this morning? I didn't see pull requests.

Ben: I did not remember seeing pull requests linked.

Warren: I'll have to take a look. I have not checked this morning. Maybe it's
actually just a set of commits and not pull requests. I don't think we need to
discuss it now.

Barry: I will suggest that we just post a Revised ID and let everybody review
the Revised ID. Please put this in Revised ID Needed.

 o draft-ietf-jmap-mdn-15  - IETF stream
   Handling Message Disposition Notification with JMAP (Proposed
   Token: Barry Leiba

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

Barry: We do not. I have not seen a response from the author yet so I'll bang
on the shepherd and/or author. Put it in AD Followup.

2.1.2 Returning items


2.2 Individual submissions
2.2.1 New items

 o draft-hardie-dispatch-rfc3405-update-03  - IETF stream
   Updated registration rules for URI.ARPA (Best Current Practice)
   Token: Barry Leiba

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

Barry: There are a couple of good suggestions for minor text updates so let's
put this in AD Followup as well.

Amy: This is going in Approved, Announcement to be Sent, AD Followup and Barry,
you can let us know when that's ready.

2.2.2 Returning items


2.3 Status changes
2.3.1 New items


2.3.2 Returning items


3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-cellar-ffv1-18  - IETF stream
   FFV1 Video Coding Format Version 0, 1, and 3 (Informational)
   Token: Murray Kucherawy

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

Murray: No. The authors seem to be responding. They hoped to have something
ready for this telechat and didn't quite make it. Definitely Revised ID Needed
for this one.

 o draft-ietf-dprive-rfc7626-bis-06  - IETF stream
   DNS Privacy Considerations (Informational)
   Token: Eric Vyncke

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

Eric V: If you don't mind. Alissa, about your first point, there was a
discussion on the IESG mailing list as well as the DNS privacy list. RFC 7626
is dated August 2015, five years ago. DoH is there which it wasn't five years
ago. I think this works but for sure there will be a bis document in five
years. It's informational, so for me it's normal that those documents go back
every five years or so. And the second point of your Discuss is a valid point
so it needs something there. I'm assuming everyone agrees on that. I've already
been in contact with Tim and he's willing to fix it quickly.

Alissa: On the first point, could the parts that are really very uncertain be
removed? There's a lot of this that could go either way and at the time of
writing we have no information. Why are we putting that in an RFC?

Eric V: It's a snapshot, right?

Barry: To be fair I think it is useful to call out stuff that's currently being
worked on, especially since we do expect to put out another update. I'd rather
see the document say here are some changes since the last version, there's more
stuff being worked on and this is what it is. We don't know where it's going
yet, but go look there in the interim.

Warren: I agree that it's worth publishing this as an RFC, because this
document is of interest to a much larger audience than just the people in the
DPRIVE wg or just the IETF. It provides some background and framework for
thinking about things. Even if it is going to be updated, having it available
for people to read, because a lot of people won't want to bother reading it
until it's an RFC. Even if it's incomplete it has value to the wider community
and not just the IETF and so worth publishing.  but maybe some more words of
'this is a snapshot of work in progress' would be helpful.

Alissa: I think really avoiding claims about the central point of this
document, which is the privacy properties of DNS, because on all of these
things it's not clear at the moment. You don't want to be telling people these
are the properties the various transports have when you don't actually know
that yet. Those sections listed there and this intro text probably needs
editing to make that a lot clearer.

Warren: That's a really good point.

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

3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items


3.2.2 Returning items


3.3 Status changes
3.3.1 New items


3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items


3.4.2 Returning items


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

 o JSON Path (jsonpath)

Amy: I have no blocking comments for this, so if there are no objections now
this can go for external review.

Murray: Do I have to click anything to make this happen or do you take it from

Amy: We'll take care of it, unless you have any edits to the charter.

Murray: No, nothing pending. Fire away.

4.1.2 Proposed for approval

 o A Semantic Definition Format for Data and Interactions of Things (asdf)

Amy: I have no blocking comments so unless there's an objection now it looks
like this charter is approved for this new WG.

Barry: We have a little bit of editing to do from Roman's comments. I'll let
you know when we're ready, Amy.

Roman: The proponents already responded and made even better polish on what I'd
suggested, so I think this is relatively easy.

Barry: Yes it is.

Amy: Okay, so you have chairs identified and all the pieces, so when you're
satisfied with the text of the charter let us know and we will send the new WG
action announcement.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Concise Binary Object Representation Maintenance and Extensions (cbor)

Amy: I understand these changes are small and might not need external review,
is that right?

Barry: That's what I believe, yes.

Amy: There are no blocking comments so unless there's an objection now it looks
like this is approved. Hearing no objections, so this is approved.

4.2.2 Proposed for approval


5. IAB news we can use

Alvaro: No news to report this week.

6. Management issues

6.1 [IANA #1178766] Designated experts for RFC 8876 (IANA)

Amy: This is a new item assigned to Murray.

6.2 [IANA #1178016] Designated experts for RFC-ietf-babel-rfc6126bis (Martin

Amy: Martin V has identified two experts. Any objections to approving Donald
Eastlake and Juliusz Chroboczek? Hearing no objections, so they are approved
and we'll get official note to IANA.

6.3 [IANA #1179647] Designated experts for RFC 8915 (IANA)

Amy: This is a new item for Erik K.

6.4 Possible Telechat Dates After IETF 109 (Secretariat)

Telechat dates have been drafted and the last back to back formal telechat will
be February 25th before IETF 110 starts the weekend of the 6th of March.

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

Amy: The BoF coordination call is tomorrow at this same time. Any other

Ben: I'll note we have several documents in flight for which Jim Schaad was the
only author. We plan to do the final publication that way, even though we'll
have someone else take over editing duties for the remaining steps in the

Michelle: We've identified all the registries Jim was an expert for. There was
only one registry for which Jim was the sole expert and Russ Housley said he
can handle that one. All others had multiple experts. In the next few weeks
we'll probably be submitting a management item to take care of that.

Alissa: We should probably schedule our pre-IETF leadership calls for the week
of November 9.

Amy: Last time you used your normal slot and extended it, so a three hour block
that Thursday. The joint IAB meeting followed the IAB meeting on the Wednesday
of that week.

Alissa: The IAB is meeting at a different time now. Maybe we can use that slot.
I'll send email.

Barry: I got a note from ISOC about the Jon Postel award ceremony. Do you know
why that's going to be before IETF rather than during the plenary?

Alissa: The announcement will be during the plenary but usually there's also a
reception and I think this is in place of that. Since the IETF meeting is in
the Asia time zone they decided to do the reception the week before and not
have it conflict.