Narrative Minutes interim-2019-iesg-24 2019-12-05 15:00
narrative-minutes-interim-2019-iesg-24-201912051500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2019-12-05 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
Alissa Cooper (Cisco) / IETF Chair, General Area
Roman Danyliw (CERT/SEI) / Security Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Wes Hardaker (USC/ISI) / IAB Liaison
Ted Hardie (Google) / IAB Chair
Benjamin Kaduk (Akamai Technologies) / Security Area
Suresh Krishnan (Kaloom) / Internet Area
Mirja Kuehlewind (Ericsson) / Transport Area
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Futurewei Technologies) / Routing Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area

REGRETS
---------------------------------
Ignas Bagdonas (Equinix) /  Operations and Management Area
Jay Daley / IETF Executive Director
Heather Flanagan / RFC Series Editor

OBSERVERS
---------------------------------
Ivaylo Petrov
Greg Wood

1.2 Bash the agenda

Amy: Does anyone have anything new to add to today's agenda?

Ben: Not exactly, but I believe in Singapore we'd added an action item for me
and a couple other folks to go through some IETF list archives, but I don't
remember seeing that on the agenda for this time.

Amy: We added a bunch of action items yesterday; we had to clean them up a
little bit. I believe there is an item for you.

Ben: Yes, it does show up now. Excellent.

1.3 Approval of the minutes of past telechats

Amy: Is there any objection to the minutes from the October 31 teleconference
being approved? Hearing none, so we'll get those posted. I also saw narrative
minutes from October 31 with one typo fixed; any objection to those? Hearing
none, so we'll get those posted 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: That's still in progress, thanks.

     o Eric Vyncke to write up draft text for the NomCom to help them
       understand the rules for the NomCom.

Eric: The text is written; I have a call tomorrow to finish it. Still a work in
progress.

     o Roman Danyliw to write up how measuring deployments could factor
       into WG chartering/rechartering.

Roman: That's done, we have that on the mailing list.

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

Alexey: Haven't done anything on my action items.

     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: I talked to Pete during the IETF on the anonymous flagging of offensive
emails. He then talked to Allison and Melinda and they were interested in
having such a functionality for them. They have started thinking on the toolset
that would be needed to achieve that functionality. I wait to hear back from
them. That's only part of the action item.

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

Alvaro: This is still in progress. Haven't done anything on any of my other
action items except one that's marked as done later on.

     o Alissa Cooper with Warren, Wes, Mirja, Alvaro, Martin, Eric, Ted,
       Robin (Zhenbin), Deborah, and Roman to work on organizing how IETF
       work is described and presented to external audiences.

Alissa: I think we can mark this as done. Greg is shepherding this now.

     o Eric Vyncke with Barry, Warren, Robin (Zhenbin), Deborah, and Alexey
       will work on defining Special Interest Groups.

Amy: This seems done, since we have new action items that came out of Singapore
relating to this.

Eric: Let's remove this one and keep the other ones.

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

Alexey: I don't think we've done anything on this.

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

Still in progress.

     o Adam Roach to work on a virtual social room for remote attendees
       (promoting #hallway)

Adam: That is still in progress. The one Alexey and I are both on later is
still in progress too.

     o Alissa Cooper and Roman Danyliw to create list of questions where we
       need answers about IETF participation to make better operational
       decisions.

Roman: That's still in progress. I need to follow up from our conversation at
the face to face and frame up how feedback could be collected from all those on
the call. Thanks.

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

Warren: Still in progress.

     o Barry Leiba and Warren Kumari to write a more concrete proposal to
       create intermediate step between DISCUSS and COMMENT - "Important
       Points."

Barry: This is done.

     o Barry Leiba to write a proposal to have drafts expire after 3 months
       rather than 6 months.

Barry: This is also done. The result of both of those is that they've gone
away. We didn't get any particular interest in either proposal and Martin has a
draft out eliminating draft expiration entirely. These are both now dead.

     o Alvaro Retana to work on early shepherding.

This is done.

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

Alexey: This is not done.

Eric: We may want to have an informal call on this IoT thing. There are many
pieces flying in the air about IoT and it's maybe good to synchronize among us.

Suresh: Eric, do you want me to write up an item for the next informal?

Eric: That would be superb, thank you.

     o Ignas Bagdonas to write a draft of an IoT Systems charter.

Ignas is not here today.

     o Alexey Melnikov to find designated experts for RFC 8620 [IANA
       #1155192].

Alexey: Not done.

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

Still in progress.

     o Roman Danilyw to find designated experts for RFC-ietf-lamps-cms-mix-
       with-psk [IANA #1156116].

Amy: This is now assigned to Roman.

     o Roman Danilyw to find designated experts for RFC 8471 [IANA
       #1156118].

Amy: This is now assigned to Roman.

     o Barry Leiba to find designated experts for RFC 8543 [IANA #1156117].

Barry: This is done.

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

Eric: This is not yet started.

     o Warren Kumari to write up draft text on Affiliate Groups
       and send to the IESG for comment.

Warren: Also not done.

     o All IESG to submit their metrics data priorities to Roman (deadline TBD)

     o Roman Danyliw to collect feedback from the IESG on the metrics
       data priorities for the IESG to discuss at a future meeting.

Roman: I didn't realize these had been broken out. One of my action items high
up about enumerating metrics should be closed, now, and both of these are in
progress.

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

Ben: Let's mark that as in progress.

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

Martin: I haven't done anything yet.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-pim-drlb-13  - IETF stream
   PIM Designated Router Load Balancing (Proposed Standard)
   Token: Alvaro Retana

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

Alvaro: No, I don't think so. The lead author is still on vacation so I think
we need to wait for him. We'll need a Revised ID.

 o draft-ietf-ospf-ospfv2-hbit-11  - IETF stream
   Host Router Support for OSPFv2 (Proposed Standard)
   Token: Alvaro Retana

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

Alvaro: We are going to need a Revised ID for this one as well.

Amy: Great. This will go into Approved, Announcement to be Sent, Revised ID
Needed.

 o draft-ietf-mpls-ri-rsvp-frr-07  - IETF stream
   Refresh-interval Independent FRR Facility Protection (Proposed
   Standard)
   Token: Deborah Brungard

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

Deborah: I'm not sure. Does anyone want to discuss? The authors have been busy
communicating. Alvaro?

Alvaro: No, Chandra has been talking about this with me.  I think we're okay.

Deborah: Benjamin, did you want to discuss at all?

Ben: I think we can do this over email. I don't remember if I got a response
yet or not.

Deborah: Okay, so we'll keep this in IESG Evaluation and a revised ID will be
needed.

 o draft-ietf-nvo3-geneve-14  - IETF stream
   Geneve: Generic Network Virtualization Encapsulation (Proposed Standard)
   Token: Martin Vigoureux

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

Martin: Eight! I'm really open to discussing and I'd like to discuss some of
them. I don't want to hijack the whole call but I'd like some clarifications.
Alissa, I think you're received a reply from the authors and it looks to me
that it goes in the right direction to resolve your Discuss. Some
clarifications are effectively needed so I'll let the discussion continue.

Alissa: When they publish the next version I think I can clear.

Martin: I'm not asking to clear anything before that. Mirja, I think yours is
easy to clarify and I think in the answer to Alissa the authors have already
said this will be addressed. Barry, I'm not opposed to having the framework as
a normative reference; is that critical?

Barry: That's the only thing. Mine is very trivial to fix but I cannot imagine
that someone could understand this document without referring to that; so it
think it does need to be normative.

Martin: Okay. Eric, of course yours will be addressed.

Eric: Yes and no, by the way. To be honest I was quite disappointed by the
reply from one author. It was sent today.

Martin: I think what they replied is that it was identified in the shepherd
report and they were already planning to do the update.

Eric: But if it's not defined in the shepherd, why did they not fix it? The
other point, the reply from the same author, from all of my comments, was deny
deny deny. Which is okay, with comments.

Martin: Let me check that; I only looked at the replies to the discuss. I
didn't perceive that it could be offending.

Eric: The language was respectful but denying all of my comments was kind of
weird.

Martin: Okay, let me check that. I didn't go into the detail. I only looked at
the Discuss part, which was changing the reference to 8200, which I think the
authors agreed to.

Eric: Thank you.

Martin: Adam, I'm taking your comment as a Discuss and I will make sure it is
properly addressed.

Adam: Thank you.

Suresh: My stuff is probably easy to address. Otherwise I'd like some kind of
explanatory text in there, like how the non-default ports work. I couldn't
figure it out.

Martin: They have two I would like to discuss a bit. One which is Roman, I
wasn't sure what you were expecting. I read it, I understand the first part,
I'm not sure what is your concern. Could you elaborate a bit?

Roman: Would it be helpful if I just went down point by point in the Discuss?

Martin: Yeah. The first one is the one I don't really understand what you're
looking for.

Roman: I'm just looking for it to deconflict the text, because in my read the
section 4 text says one thing and everything in the security considerations
says another thing. So section 4 is that this is constrained, [the security
considerations] reads like it's not. I'm just looking to get clarification: is
it constrained or not? And if it's constrained then the words in the security
considerations needs to change. But if the security considerations text is
correct, which is that it's the open internet, then I think the text in section
4 needs to change. I don't know how to reconcile those two.

Martin: I think the original intent is to have that in controlled data center
environments, but I think the authors have also envisaged a case where you
could go outside and get out of the controlled environment. So maybe there is a
clarification needed. I think the security considerations they have tried to do
a good work in that space and envision the possibilities that could happen even
if the primary deployment scenario is within a single data center. Maybe they
can re work to make it clearer, but I don't think we want to remove the
considerations for controlled environments.

Roman: I completely agree. I agree with all the advice they're putting in the
security considerations, so like you said we don't want to remove it. I think
if what it takes is that the security considerations are being very defensive
about making sure all cases are covered, maybe a sentence that says 'like we
said in the applicability section, we envision this is a constrained
environment, but just in case we want to tell you how to do the right thing.'

Martin: That kind of sentence would satisfy you?

Roman: Absolutely. Under no circumstance should we remove that good guidance
they have about untrusted links. That's good stuff.

Martin: For points 2, 3, and 4 I think I understand what you want so I'll work
with the authors. The first point was a bit obscure to me thanks for the
clarification. Ben, should we have a quick discussion on transit devices?

Ben: Yes, let us.

Martin: The answer is pretty direct. Transit devices do not exist in nvo3
architecture. They do not exist, they haven't been specified. That document
introduces that concept of transit device. So it introduces it in a way which
doesn't conflict with the architecture in the sense that they are optional. I
would also like to clarify that even if the architecture did not mention
transit devices, they exist because they are part of the underlay that routes
your traffic between your two end points. The transit devices exist but were
never explicitly mentioned in the architecture because they don't participate
in the overlay. That document talks about this in a way that they are optional.
Their participation in the overlay is optional. I understand there is a
conflict somehow with end to end security, but not so much. There has been a
lot of discussion within the WG and with Daniel who made extremely good
contributions to the group and the document. If you have internal security you
don't have transit devices that participate in the overlay.

Ben: Okay. That makes sense to me.

Martin: If you want them to participate in the overlay somehow you can't have
security. If you have security, then they don't participate in the overlay
because they can't do anything with the Geneve header.

Ben: I think that is the discussion that I was looking to have, so you can
consider this point resolved and I'll try to make some text suggestions to the
authors to clarify the bits that left me confused.

Martin: Okay. Then I think you have other important points; maybe I won't go
through them. I want to go through the UDP checksum part that you point out in
section 4.3.1. Indeed there is text that says requirement 1 applies, as if all
the other requirements don't apply. That whole section was suggested by David
Black. He suggested to have text on that and to use as example what was done in
MPLS over UDP, in RFC 7510. If you check the RFC you will see that exact same
paragraph you picked, saying requirement 1 applies.

Ben: Okay.

Martin: The way I understand it is that requirement 1 applies as-is. It's the
rephrased requirement of 6936, section 5 requirement 3, then the next one
corresponds to another one. They have rewritten the requirements of 6936 to
make it specific to Geneve. Basically it stays the same but they are using
Geneve wording in that requirement. Then they end up saying all the others
reply natively, we don't need to rewrite them. In a way, there is nothing
specific in Geneve for these requirements.

Ben: I think it's clear enough. I see what you're saying. I pulled up 7510 and
6936 and was following along. The parallel structure you described makes sense
to me.

Martin: The intent is to clarify. Whether you are happy or not is a different
issue but I wanted to give you additional context to better understand that
paragraph.

Ben: That is very helpful additional context to have.

Martin: I'll skip the rest; we can have a discussion over email. I think those
were the more important points.

Ben: You've covered the points I wanted to have a discussion about. Thanks.

Martin: Magnus, I didn't have the time to investigate your discuss, so I'm not
in a position to talk about it right now. We'll get back to you via email.

Magnus: That's fine.

Martin: I hope I've talked about everyone's.

Adam: Just to be clear, Magnus's point and mine are kind of related. They'll
probably be addressed by the WG at the same time.

Suresh: My part is regarding transit devices, so take a look and let me know if
there's something you want addressed. I think if you're ever talking about
transit devices you need to figure out how the configurable port works.

Martin: Your point was a really good one and I don't have an answer. Thank you
all. So it will require a Revised ID.

Amy: This will go into Revised ID Needed, thank you.

 o draft-ietf-cose-hash-sig-08  - IETF stream
   Use of the HSS/LMS Hash-based Signature Algorithm with CBOR Object
   Signing and Encryption (COSE) (Proposed Standard)
   Token: Roman Danyliw

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

Roman: There's an IANA review we're going to need on that document because in
response to Ben there was some new registry stuff added. So pending any other
comments to be made here, please flag this as Point Raised and we're going to
need to resolve that.

Ben: In a similar vein, I think most of my comments were addressed but I didn't
get a chance to respond to Russ. There was one point which might still need to
be flagged, which was that we define how to convey the public key but we don't
define how to convey the private key. I think that's the right thing to do but
there's a question: do we want to explicitly say we are not defining how to
convey the private key because that's a bad idea? Or do we just want to leave
it without saying anything the way we currently do?

Roman: No problem. I'll hold the document pending clarification of the issue
you just identified and the followup IANA review.

Ben: Great. Thanks.

Amy: So this will go into Approved Announcement to be sent, Point Raised, and
Roman you can let us know when those issues are solved.

 o draft-ietf-ippm-metric-registry-22  - IETF stream
   Registry for Performance
       Metrics (Best Current Practice)
   Token: Mirja Kuehlewind

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

Mirja: No, it's fine.

Alissa: There was something that Al said in response to the Gen-ART review last
night that I feel like there's still a lack of clarity. We're talking about
replacing the places where it talks about an RFC with something more generic.
He responded and said in some of the places it's about IESG review, so it will
still say RFC. Which I still don't understand. It's either specification
required or something else, but if it's specification required there's no
subset that sometimes requires IESG review.

Michelle: We're currently working with Al on a couple of other improvements to
the language in the document. I can add this to our list to make clear, where
it says specification required. I think all of them are specification required,
so I'll check what else is mentioned. I can work with him to get that cleared
up and make sure Mirja signs off on it.

Mirja: Sorry for the chaos here, because we just changed the policy here. The
intention here is to have specification required. I think what Al meant is that
there's one paragraph that's related to Alvaro's discuss, which is about what
happens if you have an RFC that might not be ready for assignment yet. So in
that case it's specific to RFCs. But it should not say IESG approval or
anything, it should say specification required.

Alissa: Roni had gone back and made the whole list of other places in the
document where he felt RFC needed to be replaced, and Al wrote back and said
we're not going to replace all of those, and I was confused.

Mirja: I saw that Roni sent the list and didn't look at all the places. I think
in most cases we need to replace it and there's definitely one place where we
can't replace it because it's talking about RFCs, and there might be another
one or two places where that might be the case because it's something specific
to RFCs. But it's not meant to have IETF Review or anything like that. I'll
double check that.

Alissa: Sounds good.

Mirja: So did I already say we need a Revised ID?

Amy: Yes, it'll stay in IESG Evaluation with Revised ID Needed.

 o draft-ietf-ippm-initial-registry-14  - IETF stream
   Initial Performance Metrics Registry
       Entries (Proposed Standard)
   Token: Mirja Kuehlewind

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

Mirja: I believe discussion is ongoing in email and we probably need a Revised
ID.

Ben: I will just throw in that I did not finish doing this one; I'll try to
finish it up after the call but I assume people are okay if I submit some new
comments without pushing the Defer button?

Mirja: That's fine for me; please do so.

Eric: The authors are quite reactive about Magnus's discuss; I got exactly the
same one. It's been promised that in the next ID all those things will be
fixed. I think Magnus's discuss will disappear.

Mirja: Al is very active at the moment so there might be a Revised ID soon but
we also should wait for Michelle.

 o draft-ietf-dnsop-serve-stale-09  - IETF stream
   Serving Stale Data to Improve DNS Resiliency (Proposed Standard)
   Token: Barry Leiba

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

Barry: We'll leave this in Point Raised so we can deal with the comments.

Warren: Asking as an author, to me it sounded like everybody was okay with us
leaving the implementation section in? Just wanted to make sure that does seem
to be what everyone thinks. Does anyone object to it?

Barry: I've always thought it would be a good idea to leave it in.

Ben: We may want to revisit the specific wording again to make sure it makes
sense in that context, but I think in principle having it stay is good.

Warren: Okay. I generally think it's good for all documents. thanks.

Mirja: I think the implementation section of this document is not a typical
implementation section; usually the purpose is only to list current
implementations and in this case it's referring to only one specific
implementation that's important for the content of this document so it's a
little bit different. We can still have another look at the RFC.

 o draft-ietf-mpls-ldp-yang-07  - IETF stream
   YANG Data Model for MPLS LDP (Proposed Standard)
   Token: Deborah Brungard

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

Deborah: I'd prefer not unless someone wants to. I'm not a YANG expert and I
totally agree the authors should respond on how they dealt with the YANG doctor
reviews. It was my understanding that they did do some updates based on the
YANG doctor's review so I'm not sure why these issues are still present. I've
been pinging them and nobody answers; hopefully they get back from their
Thanksgiving holidays and start responding. If it's okay with everybody let's
leave it IESG Evaluation and revised draft definitely needed.

Ben: I did want to talk about one or two points real quick. First, the author
count; do we want to go ahead with the six authors or do we think that's going
to change?

Deborah: I usually tell my shepherd to put a note in the writeup on why there
are six. I don't allow it except in rare cases. There have not been not many
people interested in doing YANG for LDP, but they felt it was really needed.
It's been sitting around and there's been a lot of input on it, going through a
lot of different author groups. I left it there because it not only indicates
the interest by multiple groups of people but they really did input on it. So I
left it.

Ben: Mostly I just wanted to check that it was intentional, so I wrote that my
Discuss point was pro forma to make sure we talked about it a little bit.

Barry: It's going to require some shepherding during auth-48.

Deborah: I'm very strict with it and I push back, especially if there's a huge
amount of authors from the same company. But this group really reflects a
diverse industry interest and they really all did work on it, so I left it.
We've got to make sure they are all responsive.

Eric: There were also many comments about the v4 and v6 imbalance in this
modeling.

Deborah: We've got to get that sorted out.

Eric: Thank you.

Ben: Thanks; that was all I felt a desire to talk about today.

Amy: Great, so that will stay in IESG Evaluation with Revised ID Needed.

 o draft-ietf-netmod-yang-data-ext-04  - IETF stream
   YANG Data Structure Extensions (Proposed Standard)
   Token: Ignas Bagdonas

Amy: Ignas has not joined us today but I have no active Discusses so it looks
like this one is approved unless there's an objection now. Hearing no
objection, so this will go into Approved, Announcement to be Sent, Point Raised
so he can make final checks.

2.1.2 Returning items

 NONE

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-stir-oob-06  - IETF stream
   STIR Out-of-Band Architecture and Use Cases (Informational)
   Token: Adam Roach

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

Adam: This came in late last night and I want to give the authors an
opportunity to respond. Alissa, did you see the response that I sent to your
abstain?

Alissa: No.

Adam: The notion is that there's a really high chance an external body like
ATIS is going to take this document and put a concrete implementation around
it, and they would need something much more cite-able than an internet-draft to
be able to do so. That's the reason the WG wants to get it out as an RFC in
this particular case.

Alissa: Okay. That would have been useful information to have in the shepherd
writeup, and I also asked the authors and didn't get that as a response. So
that's why I abstained.

Adam: Thanks.

Ben: Just to be clear, my Discuss point is intended to be a very low barrier;
if you want to tell me we don't need such a thing, I'm pretty willing to accept
that.

Adam: It reads like that, and I'd expect the authors to interpret it
accordingly. I want to hear from them first.

Ben: Thanks.

Amy: So this will stay in IESG Evaluation, AD Followup.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-schaad-cbor-content-02  - IETF stream
   Cryptographic Message System (CMS) Content Types for Concise Binary
   Object Representation (CBOR) (Informational)
   Token: Alexey Melnikov

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

Eric: Why does it say cbor in the name but it was not submitted on the mailing
list of cbor?

Alexey: I think it was mentioned, according to Jim.

Eric: I looked at the mailing list and wasn't able to find it.

Alexey: Maybe it was mentioned at the face to face meeting. I can chase.

Eric: Just to know. I don't mind either way.

Alexey: This document is waiting for IANA so I'd like to hold it in Point
Raised.

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-chz-simple-cu-separation-bng-protocol-00
   IETF conflict review for draft-chz-simple-cu-separation-bng-protocol
     draft-chz-simple-cu-separation-bng-protocol-06
     The China Mobile, Huawei, and ZTE BNG Simple Control and User
   Plane Separation Protocol (S-CUSP) (ISE: Informational)
   Token: Martin Vigoureux

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

Martin: There was no comment from my side because that document strictly
represents an existing implementation, so there was no real point in trying to
provide a technical comments to that. However, in discussing with the ISE we
have added some text to clarify the relationship between this document and the
ongoing activity in BBF on the specification of the requirements by solution.
It's in the latest version, so if you have read the draft you've read that text.

Amy: Thanks Martin. We'll send that to the ISE.

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 JSON Mail Access Protocol (jmap)

Amy: I have no blocks on sending this for external review.

Alexey: I think that's fine. I've edited the milestones so it's now
synchronized with the WG.

Amy: So it sounds like it needs to go for external review, so we'll send the WG
review recharter announcement.

4.2.2 Proposed for approval

 o EAP Method Update (emu)

Amy: I have no blocking comments for this recharter, so unless there's an
objection now it looks like this WG is rechartered. Hearing no objections, so
this is approved and we'll send the announcement.

 o Limited Additional Mechanisms for PKIX and SMIME (lamps)

Amy: I have a block on this recharter. Do we need to discuss this today?

Roman: I wanted to ask, Magnus. Russ and I sent some mail you may not have had
a chance to read yet. They provide examples of those small clarifications.

Magnus: I didn't check the actual reference. It's very much a spectrum with
clarifications. Writing something that describes what's always been intended,
and everyone agrees it's always been intended, over to the border of somewhere
where you don't change the scope of the document but you update how things are
done. That's from my perspective what the potential for a clarification is.
It's very easy to slip over to that where you say we need to change this
because otherwise it doesn't work. That's why I was bringing this up.

Roman: That makes sense; this has been a tension in the WG, how to balance when
a document like those that were sent comes and is it worth having to recharter
for each and every one? The belief was that the language suggested there was
tight enough but flexible enough to catch things like that. Help me understand;
are there more precise words that would help bound the clarifications for you?

Magnus: That's difficult because it's quite hard to define these things in a
good way. That's the problem. At the same time I assume the AD here is going to
be doing gatekeeping so I just wanted to have this discussion. You didn't
really answer me; how far do you consider this is primarily to make text
clearer without changing anything about how things are done?

Roman: The intent is to provide clarity on the existing documents, and if it
really looks like there's something to bolt on, recognizing that that is not a
precise term, that's clearly a recharter activity. This is really about small
nits that have come up from implementation, that would benefit from clarity on
the docs that are in WGs that don't exist. I don't know whether those slippery
words help you any more.

Magnus: I guess unless others think this is problematic I will clear my block.

Roman: Do others want to speak up here? I'm not hearing anyone. I don't want to
steamroll you, Magnus. If you have more precise language you'd be interested
in, please suggest it.

Magnus: No, I think the problem is that we don't really have the terminology
that defines this well. I think this is not something this WG should be
suffering from.

Roman: So do you want to think it over more or do you want to move forward? Up
to you.

Magnus: [audio cutting out] I'm fine with it. I'm cleared. You can approve it.

Roman: Thank you.

Amy: So we now have no blocks, so it looks like this is approved.

5. IAB news we can use

Mirja: No news so far.

6. Management issues

6.1 [IANA #1156116] Designated experts for RFC-ietf-lamps-cms-mix-with-psk
(IANA)

Amy: This is an action item for Roman.

6.2 [IANA #1156118] Designated experts for RFC 8471 (IANA)

Amy: This is an action item for Roman.

6.3 [IANA #1156117] Designated experts for RFC 8543 (IANA)

Barry: the expert I want to designate is James Gould. Any objections to that?
He's an active participant in the EPP stuff.

Amy: Great. We'll mark that done and send official note to IANA.

6.4 [IANA #1156270] Designated experts for RFC 7193 (IANA)

Amy: I think we need to assign this as an action item because this was a
Stephen Farrell document so we don't have a stuckee. Should Alexey be the
stuckee to find experts here?

Alexey: I don't mind. I just emailed the Security ADs about this. I think
between the three of us we can figure it out.

Amy: So we'll assign an action item for you, Alexey, to work with Security area
to find an expert here.

6.5 [IANA #1154263] approving CoAP Content-Formats 282 and 283 for permanent
registration (IANA)

Amy: Michelle, it sounds like IANA talked this over with Alexey and we just
need approval. Is that right?

Michelle: Yes, that's right.

Amy: So does anyone object to making these two registrations permanent?

Ben: This is good; we should do it.

Amy: I think that is approved. We will send that official note to IANA.

6.6 Quality Directorate Reviews (Ben Kaduk)

Ben: Sorry for the title, that was a little pun to the quality of directorate
reviews thread we had on the IETF discussion list. It happened for a few
documents this time that I was going through and looking at directorate reviews
and last call comments, and it seemed like there had been some sort of review,
whether it had been a directorate or generic last call comments, that happened
to the document and I couldn't find any response or change that corresponded to
those and yet the document still ended up on the telechat. I wanted to try and
get on the same page about what it means for the IETF last call to have
completed and what we expect our role as ADs to be in terms of making sure the
comments have been seen by the authors and WG and addressed in some fashion
before we decide the last call is really completed and it's time to create the
ballot.

Barry: Thanks for bringing this up, because I always make sure that when a last
call on one of my documents finishes, I don't put it in IESG Evaluation until
they've addressed all the last call comments and if necessary posted a new
draft. But I see a lot of AD comments in IESG Evaluation saying, please address
the blah review, or indicating the documents have not done that. I think we
should make it our habit to do it the way I've been doing it, not putting it in
IESG Evaluation until all the comments have been dealt with.

Warren: I largely agree, but there are sometimes comments which are sort of
non-actionable. I'm not going to say not worth responding to, but ...

Barry: Sure. I didn't mean to be absolute in what I said.

Ben: I would also follow up that I can certainly understand there's going to be
differences of opinion from time to time about whether something's going to be
a useful comment, or worth responding to even. I can certainly recognize it's
going to happen sometimes that I see documents coming forward in this scenario.
But since it happened several times for this telechat I felt I wanted to call
it out and synchronize where we stand.

Alissa: The thing that happened with this telechat, probably because of the
IETF meeting, was that there was no response at all. Not that there was a
response that said I'm not addressing your comments. There was just nothing in
response to reviews. It's not that all comments have to be addressed, but there
could be some response that I think is useful. I will also say from the process
perspective from Gen-ART, they do last call reviews and telechat reviews which
is meant to allow the reviewer to follow up and see if their previous comments
were addressed. So I think the Gen-ART reviewers will be very happy with this
kind of change, because otherwise they're asked to do a second review when they
haven't heard anything back the first time and that's unfortunate.

Mirja: I agree it's a good thing to try to address all the comments. I also
agree this shouldn't be a hard requirement because there are always cases where
it's different. I also want to say I think it's important to provide some kind
of feedback to every review. They put effort into reviewing the documents so we
should at least provide them an answer.

Deborah: I agree we should try to ensure this but I don't think we should make
it contingent that we can't ballot. Often these reviews come late, maybe on the
reviewer's side they don't respond. I strongly encourage authors to respond,
and I think as ADs we can pick it up and put it on our ballot as a comment to
say please address this, and if it's critical we can make it a Discuss. I don't
think we should be holding up telechat scheduling based on responses to
directorate reviews.

Mirja: For example if there's something that needs more discussion, I think
it's valuable to be able to have discussion before you have IESG evaluation. If
you have something that's easy to address, it would be fine if you as
responsible AD reply and say you'll make sure it gets addressed. That's fine.

Deborah: I also tell my authors to get revisions on documents based on
directorate reviews, before we start reviewing for the telechat. I say one week
before the telechat, get that document updated. But with Thanksgiving last week
I think it was difficult this time. I wouldn't want to see that we make it a
requirement that all reviews are addressed before we can place a document on
the telechat.

Ben: I think we can try to do the right thing and be reasonable about it.
Thanks everybody for having the discussion and for the most part we're all on
the same page, so that's promising.

6.7 Approve experts for performance metrics registry (Mirja Kuehlewind)

Amy: Mirja has identified two experts for this registry, Al Morton and Marcelo
Bagnulo Braun. Any objections? Hearing none, so it looks like they are
approved. We will send the official note to IANA.

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

No other business.