Narrative Minutes interim-2020-iesg-24 2020-10-22 14:00
narrative-minutes-interim-2020-iesg-24-202010221400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2020-10-22 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Deborah Brungard (AT&T) / Routing Area
Jenny Bui (AMS) / IETF Secretariat
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (F5 Networks Inc) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Wes Hardaker (USC/ISI) / IAB Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline (Loon LLC) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area
Martin Vigoureux (Nokia) / Routing Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Futurewei Technologies) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director

OBSERVERS
---------------------------------
Adrian Farrel
Mohit Sethi
Greg Wood

1.2 Bash the agenda

Amy: Anyone have any additions to the agenda? Any other changes? Hearing none.

1.3 Approval of the minutes of past telechats

Amy: Any objection to approving the minutes from October 8? Hearing no
objection. Any objection to approving the narrative minutes from October 8?
Hearing no objection. You've also had the BoF coordination call minutes for a
few weeks; any objection to approving those? Hearing no objection so we will
post all of those.

1.4 List of remaining action items from last telechat

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

Warren: In progress.

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

Eric V: Work in progress.

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

Murray: No progress since the last call, but it's in progress.

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

Alvaro: We've started on this and it's in progress.

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

Alvaro: This is in progress as well.

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

Roman: In progress.

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

Barry: Alvaro, do we remember what best practices we're talking about drafting
here?

Alvaro: That's a good question. Because of the other action item I have with
Martin, I started going through the retreat minutes. I'm pretty confident it's
in there.

Ben: I think I remember at least part of what this was. We have the new inline
errata display mode for RFCs with the errata applied, but it's limited to
verified errata. We were trying to rethink for editorial things does it make
sense to be verified, and a flowchart for how you categorize and process
different types of things. Understanding that it would be inherently incomplete.

Barry: Thank you, that's very helpful. Now that you say it I remember. Mark
this 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: Work in progress.

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

Rob: I think this is done.

Warren: It's already in the Datatracker as a thingy. We can now probably move
it to internal review. I'll chat with Rob.

     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
       #1178766].

Murray: In progress.

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

Alissa: This is done.

     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: In progress; we've been working with Jay and Wes.

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

     o Erik Kline to find designated Experts for RFC 8915 [IANA #1179647].

Erik K: I've identified one volunteer and still looking for a second one. I
assumed it was required to have at least two experts, is that true?

Amy: Some have one, some have two, some have more.

Michelle: It depends. Getting one in initially is fantastic. If you can get
another one so we have backup that's [better], but if you need to submit it to
get the one person in there and you work on the second one later, that's fine
too. It's really up to you.

Erik K: Understood. Thank you.

     o Ben Kaduk to find designated experts for RFC 8411, SMI Security for
       Cryptographic Algorithms [IANA #1180561].

Amy: This is a management item at the end of the call so we'll come back to
this.

     o Barry Leiba to write up a request for change in the Datatracker
       behavior to automatically move a document to the state
       IESG Evaluation when the document ballot is issued.

Barry: In progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-6man-rfc4941bis-11  - IETF stream
   Temporary Address Extensions for Stateless Address
   Autoconfiguration in IPv6 (Proposed Standard)
   Token: Erik Kline

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

Erik K: I don't think so. Fernando already replied and I think we're all set on
what to do. I think it's just Revised ID Needed.

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-lwig-tcp-constrained-node-networks-11  - IETF stream
   TCP Usage Guidance in the Internet of Things (IoT) (Informational)
   Token: Erik Kline

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

Erik K: Carlos hasn't responded to all this feedback yet. He did respond to an
IoT Directorate review. None of this looks hugely controversial or complicated;
we'll have to see what he says, but unless somebody wants to talk about it
today, we can just mark it Revised ID Needed.

Eric V: My Discuss is trivial to fix.

Martin D: Fine with me.

Amy: Great, so we will put this in Revised ID Needed and move on.

 o draft-ietf-cose-x509-07  - IETF stream
   CBOR Object Signing and Encryption (COSE): Header parameters for
   carrying and referencing X.509 certificates (Informational)
   Token: Barry Leiba

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

Barry: We do need to discuss one of them. Ben, what is your thought on the
status of this document? The issue has been raised that it should be Proposed
Standard, not Informational.

Ben: I don't personally see it as problematic to put this as Informational.
We're defining some new header parameters and header algorithm parameters that
go in registry and we tell you what goes in them, but the actual rules for what
you do with that information is elsewhere. It's in 5280 procedures. I wouldn't
object if we wanted to put it on the standards track either, I'm just not sure
that I've seen a super compelling case to do that.

Barry: That was my thought when I reviewed it as well. Magnus, would you like
to comment?

Magnus: Isn't it defining the actual headers and their registrations? I don't
see anyone in the crypto world say this not really IETF work, we are just
documenting something else, which is the common Informational reason, so I
don't understand why this would be Informational and it does affect which part
of the IANA registry values it will get. I don't know if that's compelling. It
looks like a Standards track document to me.

Barry: In this area it's common to do these kinds of registrations of things in
Informational documents, where how you actually use them is documented
elsewhere. These are just adding registered values.

Magnus: But it's defining headers. It's saying use this data topped with this
identifier to contain this information.

Ben: The registration procedure is specification required, not standards action.

Magnus: There are two ranges, in my understanding. If it's standards track it
ends up being in the 1-255 range and...

Ben: It can be; it doesn't have to be.

Magnus: I guess it would affect it, it's not required. I'm aware of that.

Barry: I don't think we would be assigning these out of the standards track
range, even if we did it in a standards track document. I don't think that
really matters.

Magnus: To me it looks like standards track.

Barry: The other point I guess is that it was consensus in the WG to make it
Informational. We need to double check that but that is the bottom line.

Ben: In some sense there was consensus in the IESG to make it Informational,
since it's mentioned as such in the charter.

Magnus: I can easily see how between chartering it and what's actually produced
it's slightly off. From we think we can use something describing something
which is defined elsewhere, which is Informational, compared to no, we actually
need to specify what we are going to use. I read this as it's specifying the
data formats and naming, etc for these things that contain these different
certificates. That's the primary reason why I say Standards Track. I think it's
strange to create Informational which directly goes into the downref and is
anyway used as standards track document. If you're going to use this for
something else you'll get the downref and put it in the downref registry and
you still use the standards track. Why not just make it standards track from
the first?

Barry: We have to wait for responses to Roman's Discuss and the other comments
anyway, so let's see what the WG responds to both Discusses and go from there.

Ben: To the point about the downrefs, I don't remember any work in progress
that would introduce such a downref. Part of why this is Informational and
going for the larger valued code point, larger encoding, is because the use
case is somewhat of an obscure use case so it's not expected to be super
popular for the constrained ecosystems. I don't know that we will see downrefs
right away.

Magnus: Let's see what the WG says. I'm not going to die on this hill.

Barry: The discussion has been had for now and we'll let the WG chime in now.

Martin: The IANA numbers have not been assigned but I see that a lot of the low
numbers are standards action. If this was Informational they could not assign
those numbers from that range, right?

Barry: What I said earlier was that even if we made this standards track we
would not be assigning values from that range anyway. Because it's not a common
enough used thing to use up those code points. Okay, Amy, put this in AD
Followup please.

 o draft-ietf-opsawg-model-automation-framework-07  - IETF stream
   A Framework for Automating Service and Network Management with YANG
   (Informational)
   Token: Robert Wilton

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

Rob: I'm happy. Let's put this in Revised ID Needed though, since there are
some comments that need to be applied.

 o draft-ietf-v6ops-slaac-renum-04  - IETF stream
   Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash-
   Renumbering Events (Informational)
   Token: Warren Kumari

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

Warren: I will happily admit that I'm behind on my mail.

Ben: I can jump in. I don't think we need to discuss this. Fernando has
responded and we have a three word change that should make it fine.

Warren: Okay. I had seen that bit and wasn't sure if there was anything after
that. I think we're good.

Eric V: Should the other comments be addressed?

Warren: Of course. I meant after he addresses all the comments.

 o draft-ietf-v6ops-cpe-slaac-renum-05  - IETF stream
   Improving the Reaction of Customer Edge Routers to Renumbering
   Events (Informational)
   Token: Warren Kumari

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

Warren: Rob's one we're currently working on addressing.

Alissa: Can I ask about Rob's? By "addressing" do you mean you're going to
change the boilerplate?

Warren: We're still discussing. We don't quite know. What do people think --
this is copied and pasted from a previous document that was approved. The
previous one seems weird in the extreme. These look like 211 line but they're
not.

Barry: The issue is that either we make it Proposed Standard and change it so
they are BCP 14 keywords, or we decide that Informational is correct and just
make them lower case words. Those are the suggestions right now. Alissa thinks
it should be BCP.

Eric V: On the other hand, it updates a document which is Informational.

Alissa: I don't understand why that's relevant. You can't do both? You can't
say this is now the best current practice?

Warren: You can.

Erik: It wasn't Last Called that way. It wasn't WG Last Called that way either.

Alissa: It seems it was Last Called as Proposed Standard, in fact. I don't know
when it changed to informational.

Warren: The more I think about it, the more it seems that BCP is probably the
best final thing for it. Does anybody have a strong objection to BCP before I
ask the WG what they think?

Erik K: Does that make 7084 a BCP as well?

Warren: I don't believe it does.

Alissa: This is not obsoleting it, it's just updating.

Erik K: Right, but some of the behavior it relies upon from 7084, does that
become BCP?

Alissa: I don't think so.

Eric V: I agree with you Erik, they should either both be informational or both
BCP.

Erik K: I think 7084 probably should be BCP at some point. Or there should be a
version that everybody feels comfortable with BCP for 7084 at some point.

Warren: I don't think this being BCP requires 7084 to be BCP. That's a good
idea as well, but those are orthogonal. A BCP can refer to an informational
document and say it's a best common practice you do these bits of the
Informational document.

Ben: Procedurally they're independent. How much sense does this make ... [cut
off]

Warren: I don't remember it being Last Called as Proposed Standard.

Roman: As far as I could tell it was Last Called and WG Last Called as
informational. -2 was WG, -4 was IETF Last Call.

Alissa: Did it have two last calls?

Warren: No, I don't think so. I did have a discussion with the authors after
the last call on if it should have been Informational or BCP.

Ben: The Gen-ART review thread caused us to notice that the document header
said Informational but the datatracker said Proposed Standard.

Alissa: If you look at the Last Call announcement, it says Proposed Standard.

Warren: I had a discussion with the authors on whether it should have been BCP
instead, but since it was last called as Informational, we would have had to do
another Last Call and it didn't seem worth it to do all of that for making it
BCP.

Roman: The announcement for the IETF Last Call said Proposed Standard but the
document text said Informational. The announcement takes the datatracker status.

Ben: Yes, the announcement text is from the datatracker.

Warren: I don't see in the datatracker it saying Proposed Standard.

Ben: Fred changed it later on, in the history.

Warren: Oh. That's why. Well, seeing as it was last called as Proposed
Standard...

Barry: No, I've got to object to that one. If the last call message and the
document text differ, I don't think we can say that people reasonably reviewed
it as a Proposed Standard.

Warren: That sounds fair. What would folks like us to do? I can ask the WG if
they think it should be BCP, and we can re do a last call.  Or we can just
leave it as informational. I think what's more useful is to get it published
and then point people to it, but I could be wrong. BCP, since this is what
we're suggesting CPE people do, does seem better but is it worth the faff for
that?

Barry: The faff is a question of maybe two weeks asking the WG, two weeks last
call, and a returning item on a telechat which is 4-6 weeks. If you want to do
it quicker, I didn't object to informational when I reviewed it.

Warren: I think it will be longer because there's a meeting. But there's not an
infinite rush. I guess is should go ask the WG and if they are okay with it I
will do that. Does that sound good to everyone?

Alissa: Yes. I don't have a strong opinion, just because it came up I thought
it was worth discussing.

Eric V: If we do Informational, do we use lower case everywhere?

Warren: I don't think that Informational requires lower case.

Barry: But I think it doesn't work very well to say we're going to use those
upper case terms but we aren't going to use them the way BCP 14 says. Either
you say this is BCP 14 language or it's not and we're going to put them in
lower case.

Warren: I agree but that's orthogonal to whether or not the document is
Informational or BCP.

Barry: I agree with that.

Warren: Does everyone agree that the current usage of kind of using BCP 14
language but we're not treating it the same way, does everyone agree that that
should go away? [several yeses] I think I know what I'm doing then. I will take
this back to the WG, say we'd like this to be BCP, or we think BCP makes sense,
and make them all lower case or upper case, and bring it back assuming the WG
says it's ok. Anybody object? [no response]

Amy: Should this go to an earlier state or just put it in Revised ID Needed and
let the WG figure it out?

Warren: Let's just do Revised ID Needed. I'm 99% sure it will have to come back
as something else but let's just keep it there for now.

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

 o conflict-review-irtf-cfrg-argon2-00
   IETF conflict review for draft-irtf-cfrg-argon2
     draft-irtf-cfrg-argon2-12
     The memory-hard Argon2 password hash and proof-of-work function
   (IRTF: Informational)
   Token: Roman Danyliw

Amy: I have no Discusses for this conflict review, so unless there's an
objection now this can go back to the IRSG.

Roman: I appreciate everyone's review; thanks.

Amy: Thanks, this will go back to the IRSG with the note in the tracker.

 o conflict-review-irtf-nwcrg-network-coding-satellites-00
   IETF conflict review for draft-irtf-nwcrg-network-coding-satellites
     draft-irtf-nwcrg-network-coding-satellites-14
     Network coding for satellite systems (IRTF: Informational)
   Token: Martin Duke

Amy: I have no Discusses for this conflict review, so unless there's an
objection now this can go back to the IRSG with the note in the tracker.

Martin D: I would like to briefly discuss. I chose not to use the standard
language because I wanted to imply a weaker relationship than normal. FEC is a
kind of coding but it's not really a network coding. I don't know the norms
here, so if it's way better to use the boilerplate I can use the boilerplate.

Alvaro: The reason I brought that up is that in the past we have decided on the
side of being more conservative, and not expanding so much. For example from
Ben there was the question of some other work, do we include that here? Then we
end up with a really long answer and all the IRTF cares about is whether they
can publish or not. To me it doesn't matter, but it just goes back to a
discussion we've had before that we want to err on the side of being more
conservative and closer to what 5742 says.

Barry: I think the right way to do this is to use the text as specified in 5742
and put the other stuff in your own comments on the ballot.

Martin D: Okay, I can make that edit.

Amy: Okay, it sounds like the conflict review version will be 01 by the time we
send this in. That will probably be on Monday so you have time to edit.

3.4.2 Returning items

 NONE

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

 NONE

4.1.2 Proposed for approval

 o Building Blocks for HTTP APIs (httpapi)

Amy: I had a block, do I no longer have a block?

Alissa: I just cleared it, sorry.

Barry: The newest version is 00-04 and it addresses Alissa's comments, so it
should be ready.

Amy: Okay, unless there's an objection now, HTTPAPI is ready to become a WG.
Hearing no objection. I don't have milestones yet.

Barry: That's correct, the WG will be developing milestones as its first work
item.

Amy: Okay, this is approved and we'll get it sent tomorrow.

 o JSON Path (jsonpath)

Amy: This is version 00-01 and there are no blocking comments, so unless
there's an objection now this one is approved. Hearing no objection, so this is
approved. We'll get that sent out tomorrow.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Alvaro: Nothing to report today.

6. Management issues

6.1 [IANA #1180561] Designated expert for RFC 8411, SMI Security for
Cryptographic Algorithms (IANA)

Amy: Russ Housley is ready to stand as the expert for this, so unless there's
an objection it looks like Russ is approved.

Ben: This is a very low-traffic registry, so it's not a big burden.

Amy: I'm hearing no objection, so we will send the official note to IANA.

6.2 Next steps on Vulnerability Reporting Guidance (Roman Danyliw)

Roman: If we remember the history, we had agreed on some text to put on the
website and were waiting for the LLC to finish coordination on their statement.
That has completed, and we want to do a joint launch together to make the
announcement and raise awareness that we have all of these. We'd originally
decided that we were not going to ask for community consultation. I think we
need to back that up and ask for community feedback, so I had some text drawn
up to elicit feedback from the community and another pointer from the text. I
was looking for concerns from anyone for going to the community to ask for that
feedback, and then any feedback on that proposal for the text. Does anyone
raise an objection to going to the community for feedback? I'm hearing no. I
sent around then a pointer to text we could use for that. I want to launch
tomorrow, so if you have any concerns about how we ask for it, please polish
that Google doc for me.

Alissa: You're going to attach a PDF, or you're going to get the PDF posted?

Roman: Greg is going to help me post the PDF somewhere, so we can do it by
pointer. It doesn't work the other way. If anyone wants to help, make the
edits, and after we get the community feedback Greg has a more detailed comms
plan as to how we're going to generate some traffic around pointing out we have
these and a better way to engage with the IETF if you have any questions on
vulnerability reporting. Did you want to add anything, Greg?

Greg: No, sounds good.

Roman: Thanks everyone.

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

Amy: Any other business?

Ben: Probably everybody saw, but I did finally push the button on reopening
OPENPGP, although apparently I did not inform the WG about this in the way one
normally would so I may have to pull it off the next telechat if the WG is
unhappy about anything. So far it's looking promising.

Erik K: For the record, Ben, what is the proper procedure?

Ben: Generally you have the group of people who will form the WG get some
buy-in to the charter text before you send it out for broader review. This case
is a little bit weird because we already had a WG and this text is basically
the same as the last time around. That's part of why it's not as big of a deal.
But generally you propose charter text on the list and get consensus on the
list before you bring it to the IESG and IETF as a whole.

Erik K: Thanks.

Alissa: I sent mail about agenda items for our leadership meetings just prior
to IETF 109, so if you have things you want to discuss either jointly with the
IAB or just with the IESG, please add them to the wiki. I also had a question;
next week we have an informal agenda item to come back to the BOF proposals. I
was wondering if we'll have updated text that describes what the BOFS are going
too do? I think that would be useful.

Eric V: Regarding MADINAS, there's been a discussion with Jari, the proponents,
and Stephen. There will be a new description. It's a lot better.

Alissa: Great. Same for APN?

Martin V: Yes. I've been working with the proponents to refine their proposal,
specifically for specs on one use case. I'm pushing them to describe in detail
what they want to do and how they want to do it. Yesterday they engaged with
Tommy in the IAB so this is in progress. Let's hope we converge quickly enough.
There is still work to do.

Alissa: Okay, but something's going to get posted to the wiki or the mailing
list or something?

Martin V: Yes, the goal is to get an acceptable version and then we'll publish
it.

Alissa: Great. Thanks.

Mirja: From the brief discussion we had yesterday on the IAB call it seemed
like the communication towards Tommy wasn't working as well. It's on the
proponents to decide if they want to take the help of the IAB or not, but we
tried to help.

Martin V: What Robin told me was that he wasn't sure whether he should engage
with IAB or not. Communication with Tommy, at least from what I saw,
effectively only happened yesterday.

Mirja: My point was rather like you could have engaged more people from the
beginning which would probably help the proposal. If the BOF proponents don't
want to engage anybody from the IAB they don't have to.

Martin V: I'm not here to tell them who to discuss it with; they reached out to
me three or four days ago, I replied and worked with them, but they are
driving. I'm not doing the work for them.

Amy: Remember next week Europe will have ended Daylight Savings but not yet the
US. We'll make sure to put a time in the wiki for the meeting time.