Skip to main content

Narrative Minutes interim-2020-iesg-08 2020-03-19 14:00

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

Narrative minutes for the 2020-03-19 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 / incoming Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Wes Hardaker (USC/ISI) / IAB Liaison
Ted Hardie (Google) / IAB Chair
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline / Loon LLC / incoming Internet Area
Suresh Krishnan (Kaloom) / Internet Area
Murray Kucherawy / Facebook / incoming Applications and Real-Time 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
Alice Russo (AMS) / RFC Editor Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area
Robert Wilton / Cisco Systems / incoming Operations and Management Area

Ignas Bagdonas (Equinix) /  Operations and Management Area
Jay Daley / IETF Executive Director

Karen O'Donoghue
Greg Wood

1.2 Bash the agenda

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

Mirja: Do we need an official item for discussion of remaining Discusses from
outgoing ADs?

Amy: I figured once we finished the agenda it could be open for that kind of

Suresh: Are we going to have a meeting next week too?

Amy: You already have meetings scheduled for Monday, Tuesday, and Thursday in
this same time.

1.3 Approval of the minutes of past telechats

Amy: We have two sets of minutes, March 5 and March 12. Is there any objection
to approving the minutes of March 5? Hearing no objection there. I believe
there are narrative minutes as well from March 5. Any objection to approving
those? Hearing no objection. March 12, you've only had these for a week. Maybe
you should keep those and we'll come back to those in April.

1.4 List of remaining action items from last telechat

     o Roman Danyliw to draft text to be posted on about reporting
       protocol vulnerabilities via an email alias and possible procedures
       on how to assign triage resources.

Roman: Please mark this as in progress.

     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 think Wes had a proposal. Keep this 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: Keep this in progress, thanks.

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

Alexey: Yes, we actually made some progress on this.

Warren: What would be helpful is talking to the tools team. We'll follow up off
list. Still in progress.

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

Alvaro: This isn't done but we will continue. Keep it as in progress.

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

Warren: Keep in progress.

     o Alexey Melnikov to organize IoT overview discussion with interested

Alexey: Keep this. I'll try to make some progress later.

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

Eric: Still in progress.

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

Magnus: In progress.

     o Suresh Krishnan to draft a "best errata practices" document and
       post it on the IESG Wiki.

Suresh: Keep it in progress, I'll get it done.

     o Roman Danyliw to find designated experts for RFC 7636 [IANA

Roman: I haven't done anything with this. Keep it in progress please.

     o Suresh Krishnan to write a draft of an IoT Systems charter.

Suresh: This should be up for reassignment; I can't get this done by next week.
Is anyone interested in this? I can write something up after next week if it
doesn't need to be an IESG member.

Eric: This is something with interest to my working groups. I will pick it up.

Suresh: Put Eric's name first and mine next and when I drop off I'll continue
working on it.

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

Suresh: This is in progress. I think I'll be able to get this done by next week.

     o Ben Kaduk, Alvaro Retana, and Suresh Krishnan to divide community
       suggestions in the "AD Workload" thread into workload-specific
       topics and workflow-related topics.

Ben: In progress. We're scheduled to talk about this next week.

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

Alvaro: This is in progress. We'll pick it up after next week.

     o Eric Vyncke to find designated experts for RFC 7401 [IANA #1164641].

Amy: This is provisionally done since it is on the agenda as a management item.

     o Benjamin Kaduk to find designated experts for RFC 8747 [IANA

Ben: In progress, please.

     o Barry Leiba to draft a proposal for NomCom Eligibility in light of
       IETF 107 becoming a virtual meeting.

Amy: I've seen a lot of mail on this and this one is done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-6man-icmp-limits-07  - IETF stream
   ICMPv6 errors for discarding packets due to processing limits
   (Proposed Standard)
   Token: Suresh Krishnan

Amy: We've cleared one discuss but there's one left. Do we need to discuss that?

Suresh: Yes, thank you. Alissa, thank you for clearing. Ben, did you get a
chance to look at the response from Tom on this?

Ben: I opened it up last night but didn't focus on it. I think I would prefer
additional textual changes for the first point but what he did to move section
5.1 up to the introduction is probably enough. I expect to clear that point and
the other point was not complicated so I assume I can clear.

Suresh: The IANA considerations changed, so if Ben clears put it in Point
Raised because I need to talk to Michelle with the newer text in there. Thank
you very much.

Amy: So it sounds like this is IESG Evaluation, Point Raised.

 o draft-ietf-lpwan-coap-static-context-hc-13  - IETF stream
   LPWAN Static Context Header Compression (SCHC) for CoAP (Proposed
   Token: Suresh Krishnan

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

Suresh: Just Magnus's, I think. They already took a shot at addressing it.
Magnus, have you had a chance to look at their message?

Magnus: I was just formulating my response. We're not on the same page. My
concern here with the COAP point is that your context establishment mechanism
actually ends up instead of working across one single layer, or between two
nodes across a particular network, you suddenly need to have two different
contexts and these contexts now run potentially across multiple networks.
That's a significant architectural change which isn't discussed in detail.

Suresh: It's probably just a misunderstanding or a lack of context. At least in
the WG, that's understood that it's the way things are going to go. The link
layers are really constrained. I think we can go discuss this a little further
and see what can get added.

Magnus: What I'm looking for really is just some text that says this has
additional implications on deployment architecture and you have a different
addressing plan, probably because you need to establish two different sets of

Suresh: That's fair.

Magnus: I will write up a response to them.

Suresh: The other thing I want to discuss with you and Mirja is I think we
should decouple the TSV-ART discussion from the other discussion we're having
about the RFC in auth-48. Dominic came up with a text proposal to leave some
room open for the future. I do think at some point instead of doing a must not
to compress this, we should be able to do it in the future if the parser
doesn't understand the UDP options. There's a text proposal that came out late
last night or early this morning, so if you and Mirja can see it. I'm holding
the document in auth-48 for this. I wanted to decouple this draft from the RFC.

Magnus: I will try to look at it.

Mirja: I looked at it and I think it's fine and addresses the point.

Suresh: I don't think I'll get the other Discusses cleared in time, so I'll
hand this off to Eric V and we'll talk about it.

Amy: Sounds like this will require a Revised ID.

 o draft-ietf-ntp-using-nts-for-ntp-24  - IETF stream
   Network Time Security for the Network Time Protocol (Proposed
   Token: Suresh Krishnan

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

Suresh: Yes. I think the authors have addressed all the issues in the
Discusses, but Ben I don't think you've gotten a mail yet. The authors are
tracking the issues. I'll send a mail formulating the changes or I'll get the
authors to send you one, but I do think they made changes to address all the
Discusses in here.

Ben: I was trying to look through the Gitlab repo they had. Most of them were
batched, but I didn't immediately see the issue for the first Discuss point
about the authentication and using RFC 6125 with the input DNS-ID. I wonder if
that just got missed while they were transferring the points into Gitlab issues.

Suresh: I'll send a summary email and if something is left out we can do
another round.

Ben: I also wanted to talk about the dedicated port Mirja had also raised. In
the Gitlab issue they said discovery is not in scope for this document, which
is fine, but if you want to leave discovery out of scope you could also leave
port discovery out of scope and not assign a port. I don't know if just saying
discovery is out of scope is responsive to the question of why do you need an
assigned port.

Suresh: I do have a little bit of opinions on this. Karen is on the
call--Karen, do you have any thoughts on this?

Mirja: Maybe I can say something. In general you don't need any fixed ports,
you can always find a discovery mechanism for it. We haven't been extremely
consistent with that guidance. The point is if this is supposed to be a widely
deployed, well-used internet service, which should be easy to discover by
having a dedicated port, it's usually okay and I'd see this in this range.
There was a port expert review and they did pick on the question if they could
not use any existing ports, but it's also okay in this case to assign a new
port because it's a different protocol for the key exchange. I'm fine with it.

Ben: Thanks; that makes me more comfortable.

Suresh: Mirja, where did the port review go out?

Mirja: That only went to IANA and we are still trying to define the process
here. Hopefully in future they will also go to mailing lists.

Suresh: I think all the Discuss points are addressed and if something is left
out I'll do another triage and get back to the Discussing folks and we'll go
forward from there. I've already pinged the authors to get back to you, Ben,
with a summary of changes they made. Karen, did you want to say something
further on this?

Karen O'Donoghue: I think Mirja addressed the port issue and in general the
authors are very responsive and very motivated to get this cleaned up and done,
so I think you'll get quick response times from them.

Suresh: And this is a document I really don't want to hand off so I'll try to
get this as closed off as possible before I go.

Karen: Thank you.

Suresh: I put it in Point Raised and I'll let you know if it requires a Revised

Amy: So that's going to stay in IESG Evaluation in AD Followup.

 o draft-ietf-6tisch-msf-12  - IETF stream
   6TiSCH Minimal Scheduling Function (MSF) (Proposed Standard)
   Token: Suresh Krishnan

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

Suresh: No, the authors have been unresponsive so I think you can just take
this off. There's not much to discuss here. I wasn't sure if I should push the
defer button myself.

Amy: We can just leave it in the state it's in now, IESG Evaluation and Revised
ID Needed, and move on.

Suresh: Pull it off the telechats too. This is something I have to hand off.

 o draft-ietf-dnsop-rfc2845bis-07  - IETF stream
   Secret Key Transaction Authentication for DNS (TSIG) (Internet
   Token: Warren Kumari

Amy: I have no Discusses, so unless there's an objection it looks like this is

Warren: Can I have Revised ID Needed?

Ben: I just wanted to check that I'm remembering the DNS layout and terminology
correctly. When we say that there's only one TSIG RR at all, exactly one, that
means that the R data structure only appears once; the R set is separate
records in the response in order to have different R data fields. Is that

Warren: Yes.

Ben: Initially I was confused about that and I was going to put a Discuss on.

Amy: So I'm hearing that this is Approved, Revised ID Needed. This IESG Note
that you have in the ballot writeup box, we're going to remove that. We also
have three documents to go into the downref; Proposed Standard is lower than
Internet Standard, so that's okay to put RFCs 4635, 2845 and 3597 into the
downref registry?

Barry: I don't think we'd be putting those things into the downref registry,
we'd just be putting them as downrefs for this document.

Amy: Isn't that what the downref registry is?

Warren: The registry is a list of things that even though they're at a lower
state we always allow; this is a case where we just say for this one we don't

Barry: We don't move documents to Internet Standards that often that PS
documents should go in the downref registry. This is a one-off. We should
generally be putting experimental and informational things in the downref

Amy: So when the Datatracker throws up the question of adding these to the
registry, we can just say no?

Warren and Barry: Yes.

Amy: Thank you.

2.1.2 Returning items

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

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

Ben: I had put this back on as a returning item to discuss really just the one
point about the IPv6 status as an extended feature. Eric, you had responded to
my email. Alissa or Adam, did you have any further thoughts on that?

Adam: Sorry, I lost context.

Deborah: It supports in the base model IPv4 and IPv6. Most of the IPv6 support
is an extension.

Ben: They're calling IPv6 support an "extended feature."

Adam: I didn't Discuss it, so I'm not going to stand in the way, but that still
seems a little problematic.

Eric: On this topic, LDP IPv6 is not really deployed or even implemented. I'm
not sure any vendor's got it. More importantly they changed the model, putting
v4 and v6 on the same level. So I'm quite satisfied there. But then I opened
another Discuss because of something I forgot to check at the first pass. It's
easy to fix.

Deborah: Yes, I got yours, Eric. Because it's not really deployed it should be
augmented or extended because it could just slow down everything below it.
[audio cutting out]

Ben: It sounds like I will clear for that point at least. Thanks for getting it
fully discussed here.

Deborah: Ben, can we go on to discuss your key string one?

Ben: Sure.

Deborah: That one also, they replied and didn't want to put that format in
there because everybody uses something different and they also wanted to allow
the flexibility that it was a string, not necessarily an MD5. I checked here
and people will say it's definitely a string, because the security folks will
say how you should encode/decode that algorithm so you don't want this
specified. [audio cutting in and out] A lot of times you're not using MD5 and
it's all done by the security folks, it has nothing to do with Yang itself. The
client and the server already know what the key is, you're just pushing it down.

Ben: I suppose so. There's a question of if we're trying to model
implementation behaviors in an implementation agnostic way, whether or not we
need to care a little bit about what the implementation--

Deborah: That's exactly why we keep it as just a string.

Ben: I'll try and double check today but I expect to clear that point.

Deborah: Okay. So Eric, yours is easy. I talked with the Routing WG chairs and
they'll move that up to normative.

Eric: That's perfect.

Deborah: The routing WG says they're not going to hold us up because they're
planning to Last Call that right now.

Eric: It just really needs to be normative because it's useless if it imports
something which is not standardized it breaks a lot of things. That's all.

Deborah: It's always very difficult for Yang because you don't want to put 100
RFCs there in normative. They're going to move that up.

Eric: That's fine. I'll clear my Discuss as soon as I see it.

Deborah: So we'll get Benjamin's cleaned up and then we'll be ready.

Alissa: If you could get them to respond to the Gen-ART review just as a
courtesy, that would be good. There were a lot of responses [audio cut out]

Deborah: Sure. And you can put this as Revised ID.

2.2 Individual submissions
2.2.1 New items


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


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


4.1.2 Proposed for approval


4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval


5. IAB news we can use

Alvaro: I'm the new liaison to the IAB. They met yesterday mostly about who's
going to be in charge of programs, liaisons, shepherds, etc. Important news is
that Mirja is the new IAB Chair and IAB stream manager. They haven't discussed
yet who's going to be the liaison to the IESG.

6. Management issues

6.1 [IANA #1161777] Management Item: Protocol Number for Transparent Inter
Process Communication (TIPC) (IANA)

Suresh: They're going to post a draft with some of the specifics. I just wanted
them to get an IETF draft posted as a specification. It will probably be done
in the next couple of days. Joe Touch did respond to my message with some
questions and I'm going to go back and get them to respond. It's on track. Just
make sure the issues are addressed before we do the allocation and there's a
specification. Right now the specification is on the website and some people
raised the issues hat this could change without us knowing. Keep it on hold; I
think this is good to go and I just want to make sure Joe's comments are
addressed and Ben gets a response with the protocol spec.

Amy: Should we keep this as a management item or should it move to an action
item for someone?

Suresh: I think you can take it off and I'll send a ticket with something to
minute if there's something to minute.

Eric: We can discuss in INT area.

Suresh: I did send mail to the intarea working group for comments but this came
though the IESG approval process not the intarea process. They do have their
own change control and that's why they used the other process. This is
maintained by the linux community and they don't want to come back to us for
every small thing they want to make. They have a significant performance issue
using UDP and that's why they want to move to IP.

6.2 Moving POP2 (RFC 937) to Historic (Alexey Melnikov)

Amy: This is to minute that we will be assigning an action item to Murray for
him to pick up after IETF 107.

Barry: I just looked at RFC 937 and saw that it is already Historic.

Alexey: In this case, I would still like to reallocate the port. It's a
separate port number; 109 instead of 110.

Barry: Once you step down, you can write a draft that does that.

Mirja: Can't we just approve that right now? Do we need an expert review for it?

Michelle: For IESG approval I don't think we do. We do this so infrequently.

Mirja: Given that this is an RFC and we know for sure it's not used I think
it's fine to just go with IESG approval without expert review here.

Michelle: That would be my guess as well.

Warren: I think IESG approval counts as a higher level than expert review, so I
think that's fine. Do we need an official management item?

Mirja: I think we can just take this one.

Barry: That management item includes it. For Amy, we should ask if anyone
objects to deallocating port 109.

Suresh: Can we edit the management item text?

Warren: Has anyone looked at data to see if port 109 happens to be being
actively used?

Barry: If 109 is being used it's being used by something else, because I assure
you no one is using POP2.

Warren: I don't know of anyone using POP2, but if you're sure then I'm happy.

Alexey: Pretty sure.

Amy: What should the title of the management item actually be, for the minutes?

Alexey: Deallocation of TCP/UDP ports 109 that was assigned to POP3 (RFC 937)

Magnus: I'm trying to read 6335 here. Depending on what process tree we are in
the RFC we need to follow that.

Mirja: IESG approval should always be valid for every registry but it should do
a call for comments, which we didn't do now.

Magnus: If it's a revocation it's a four week community call.

Warren: Just to confirm, to do that we don't need an RFC or anything.

Magnus: No, if it's our port and we're de-assigning it and moving it to
reserved we should be fine.

Warren: The question is not do we need to tell people, it's does it need to be
written up in the form of an internet draft?

Alexey: Just email.

Mirja: So the port currently is assigned to Joyce.

Magnus: Then I think we formally need to do a revocation because it's not our

Alexey: Joyce is no longer with us as far as I know. So last call is fine.

Mirja: We are the change controller anyway. Maybe we should take this together
with any port cleanup we're doing.

Michelle: In the RFC it says a community call concerning revocation of a port
number MAY be considered.

Magnus: We're not the assignee.

Mirja: If the assignee is not here anymore....

Magnus: Going around the community call process to take on that we are
considering ourselves the ... even if we're going to reassign it to ourselves I
think we should do a call on it.

Barry: So who's going to put out the last call message and manage that?

Mirja: This is one of the cases that we were trying to clean up anyway, right?

Murray: I can take it once I've got my dot.

Alexey: Send a last call message and Murray will own the item after that.

Barry: There's a list of ports we want to clean up. Why don't we put this with

Alexey: That will take forever.

Mirja: I don't think there's a huge benefit in marking this reserved.

Barry: Just put it with everything else. We're not going to reassign it for
something else anyway.

Murray: I'd just as soon we send it out and let Alexey close this issue, and
not hold up for a bigger process that's going to irritate people and hold it up
more. It's one email and then remembering to clean it up in four weeks, right?

Warren: There's currently a lot of grumpiness about the cleanup, and this one
is nice and simple and easy so my preference would be to do this one separate.
It also primes the pot for the others.

Mirja: Just to make the point, to avoid these kind of discussions, that's why
we want to do the cleanup. If we keep processing everything on a one by one
basis that's a counterpoint for doing the cleanup at some point.

Murray: I think the trigger here is that the RFC is historic, right?

Mirja: For a long time already.

Warren: In the amount of time we spent discussing this we could have sent the
email by now.

Alissa: Maybe the people who want to keep debating it can take it offline and
solve it amongst yourselves.

Amy: We'll keep this as an action item and assign it to Murray.

6.3 [IANA #1164641] Designated experts for RFC 7401 (HIPv2) (Eric Vyncke)

Amy: Are there any objections to approving Robert Moskowitz and Jeff Ahrenholz
as the designated experts for this registry? Hearing no objection so this is
approved and we will send note to IANA.

6.4 [IANA #1163248] renewing early allocations for
draft-ietf-idr-bgp-open-policy (IANA)

Amy: Is there any objection to renewing this early allocation? Hearing no
objection, so this is approved and we will send a note to IANA.

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

The IESG discussed who would be the Area Director in charge for several WGs and
area groups, as well as some Discusses on individual documents.