Narrative Minutes interim-2018-iesg-12 2018-06-07 14:00
narrative-minutes-interim-2018-iesg-12-201806071400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Minutes of the 2018-06-07 IESG Teleconference

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

1. Administrivia

Cindy: If Amy sounds weird to you today, it's because this is actually Cindy.
Amy is on vacation, so you get me today.

1.1 Roll call

ATTENDEES
---------------------------------
Ignas Bagdonas (Equinix) /  Operations and Management Area
Ben Campbell (Oracle) / Applications and Real-Time Area
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Spencer Dawkins (Wonder Hamster Internetworking) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Ted Hardie (Google) / IAB Chair
Benjamin Kaduk (Akamai Technologies) / Security Area
Suresh Krishnan (Kaloom) / Internet Area
Warren Kumari (Google) / Operations and Management Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Huawei) / Routing Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Alice Russo (AMS) / RFC Editor Liaison
Martin Vigoureux (Nokia) / Routing Area

OBSERVERS
---------------------------------
Charles Eckel
Pete Resnick
Greg Wood

Cindy: We received regrets today from Amy, Deborah, Heather, Mirja, Portia,
Ekr, Jeff, Ted, and Terry, but it looks like everybody else is here.

NARRATIVE MINUTES
---------------------------------

1.2 Bash the agenda

Cindy: Does anyone have anything new to add to today's agenda? Any other
changes? If not, we can move on.

1.3 Approval of the minutes of past telechats

Cindy: Does anyone have an objection to the minutes from the May 24
teleconference being approved? Liz sent out the narrative minutes from May 24,
any objections to approving those? Hearing none, we'll get those posted.

1.4 List of remaining action items from last telechat

   OUTSTANDING TASKS

     o Benjamin Kaduk to find an additional designated expert for the AEAD
       Parameters registry and ask them to update the registry noting that
       draft-nir-cfrg-rfc7539bis will obsolete RFC 7539.

Benjamin: The original expert reappeared and the registry has been updated, but
I'm still looking for candidates for alternate / additional experts to add to
the registry. That's in progress.

Cindy: Should we update this action item to note the second part has been
updated and you're just looking for an expert?

Benjamin: Please do, yes.

     o Alexey Melnikov to find a designated expert for RFC 8323 [IANA
       #1108770]

Alexey: In progress.

     o Alexey Melnikov to find a designated expert for RFC-ietf-core-senml
       [IANA #1112601]

Alexey: This is also in progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-mtgvenue-iaoc-venue-selection-process-15  - IETF stream
   IETF Plenary Meeting Venue Selection Process (Best Current Practice)
   Token: Alissa Cooper

Cindy: It looks like there are no objections.

Alissa: I think we can approve this and put it into Point Raised. I don't think
there's anything to discuss on the call, but we do have the shepherd. Anything
from you, Pete or Charles?

Pete: No, sounds like we have everything in hand. It mostly comes down to
editorial stuff and clarifying some things. Easy enough to go forward with.

Cindy: This will go into Approved, Announcement to be Sent, Point Raised, and
you can let us know when it's ready to go.

 o draft-ietf-mtgvenue-meeting-policy-06  - IETF stream
   High level guidance for the meeting policy of the IETF (Best
   Current Practice)
   Token: Alissa Cooper

Cindy: There are no active discusses, so unless there's an objection this is
approved.

Suresh: Alvaro sent in some comments yesterday and there are changes to be
made. I'll make the text proposal. I think it's a valid point and I tried to
bring it up in the WG a while ago but the WG didn't want to specify a given
venue. I think it's probably a little bit of work to put an actual procedure in
there. It's wishy washy by design right now but maybe it can use some more
specificity. AT the time the thinking was this was going to be a long lived
document so don't put in specifications. Maybe there's a middle ground there.
I'll try to come up with some text. Martin had the same kind of comments. For
the security considerations I'll put them in and like Spencer's thing is
changes we can include too. There will be a new rev as soon as possible.

Alissa: Sounds good, thank you.

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

 o draft-ietf-teas-yang-te-topo-16  - IETF stream
   YANG Data Model for Traffic Engineering (TE) Topologies (Proposed
   Standard)
   Token: Deborah Brungard

Cindy: Deborah could not be with us today. Martin, did you want to state a
position on this document?

Martin: No, I didn't have time to review it properly.

Cindy: We've got enough without you, I just wanted to double check. There are
no discusses so unless there's an objection this will be approved. Since
Deborah's not here we'll put this in Approved, Announcement to be Sent, Point
Raised, Writeup Needed so she can double check.

 o draft-ietf-httpbis-replay-03  - IETF stream
   Using Early Data in HTTP (Proposed Standard)
   Token: Alexey Melnikov

Cindy: Warren, did you want to state a position on this document?

Warren: No, I managed to forget it. Sorry.

Cindy: There are no active discusses, so unless there is an objection this one
is approved.

Alexey: Can I have this in Point Raised please? I think there are interesting
comments and I want to make sure they are addressed.

Cindy: We'll put this in Approved, Announcement to be Sent, Point Raised,
Writeup Needed.

 o draft-ietf-extra-imap-status-size-02  - IETF stream
   Internet Message Access Protocol (IMAP) - STATUS=SIZE Extension
   (Proposed Standard)
   Token: Alexey Melnikov

Cindy: There are no active discusses, so unless there is an objection this one
is approved.

Alexey: Yeah, I think this one is ready to go.

Cindy: Great, we will get this sent Monday as per normal.

 o draft-ietf-extra-imap-unauth-00  - IETF stream
   IMAP UNAUTHENTICATE for Connection Reuse (Proposed Standard)
   Token: Alexey Melnikov

Cindy: There are no open discusses, so unless there is an objection this one is
approved.

Alexey: Can I have this in Point Raised, I think there are some comments that
need to be addressed.

Cindy: This will go into Approved, Announcement to be Sent, Point Raised,
Writeup Needed, and you can let us know when it's ready to go.

 o draft-ietf-extra-specialuse-important-03  - IETF stream
   IMAP $Important Keyword and \Important Special-Use Attribute
   (Proposed Standard)
   Token: Alexey Melnikov

Cindy: There are no open positions or active discusses, so unless there is an
objection this one is approved.

Alexey: Yeah, I think this one is ready to go as well.

Cindy: We will get this sent on Monday, thank you.

 o draft-ietf-extra-imap-list-myrights-07  - IETF stream
   IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST
   (Proposed Standard)
   Token: Alexey Melnikov

Cindy: No open positions or active discusses, so unless there is an objection
this one is approved.

Alexey: I think the latest version addresses all the comments, so this is ready
to go.

Cindy: This will go into Approved, Announcement to be sent.

 o draft-ietf-httpbis-h2-websockets-06  - IETF stream
   Bootstrapping WebSockets with HTTP/2 (Proposed Standard)
   Token: Alexey Melnikov

Cindy: No open positions or active discusses, so unless there is an objection
this one is approved.

Alexey: For this one I would like Point Raised, please.

Cindy: This will go into Approved, Announcement to be Sent, Point Raised,
Writeup Needed, and you can let us know when it's ready to go.

 o draft-ietf-tsvwg-iana-dscp-registry-06  - IETF stream
   IANA Assignment of DSCP Pool 3 (xxxx01) Values to require
   Publication of a Standards Track or Best Current Practice RFC
   (Proposed Standard)
   Token: Spencer Dawkins

Cindy: No open positions or active discusses, so unless there is an objection
this one is approved. There are no notes in the tracker, are there any needed
for this version?

Spencer: This needs to be AD Followup, the author for this has been in the QUIC
interim this week as a remote participant and there's at least one ballot he
has not replied to yet, so I'll follow up on that.

Cindy: Can I negotiate your AD Followup into a Point Raised?

Spencer: Sounds like a deal.

Cindy: This will go into Approved, Announcement to be Sent, Point Raised,
Writeup Needed, and you can let us know when it's ready to go.

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

 NONE

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-hakala-urn-nbn-rfc3188bis-01  - IETF stream
   Using National Bibliography Numbers as Uniform Resource Names
   (Informational)
   Token: Alexey Melnikov

Cindy: There are a couple of discusses in the tracker, would you like to
discuss those now?

Alexey: Yes please. Benjamin's discuss, let's defer this to email; I would like
to hear what the authors have to say. That should be relatively easy to clear,
I hope. Ben, can you talk about your Discuss a little bit?

Ben: Yes I can. My concern here is that this document, being a IETF
informational stream document, is very prescriptive about the behavior of
bodies which we don't typically talk about, in this case the National
Libraries. There's quite a bit of normative language in here about things the
national libraries must do with their identifiers. That seemed to me something
that an informational draft is questionable about having standing to do it.
Second, I question whether the IETF has standing to do it. The authors and
Peter have pointed out that the draft this replaces already had a lot of that
language, although it was not in uppercase keywords, etc. My concern isn't
really that it's uppercase keywords, that's related, but that we seem to be
telling someone who's not in our normal space what to do, and we're doing it in
an informational RFC. I'd be happier if it talked about existing practices or
assumptions, or assuming certain behavior in order for this document to work
properly. The authors have also come back and said this is the only document
that defines this stuff and they'd like it to have this prescriptive
information. I think they've offered to lowercase it. I'm curious what people
think about whether what they want to do is appropriate.

Alexey: I'm thinking of National Libraries as entities that opt in into
supporting this protocol, so if they want to participate in NBNs they have to
comply with requirements.

Ben: Why isn't it a standard then?

Alexey: Just because the previous one was informational. If you're suggesting
we should re- Last Call it as a proposed standard then ...

Ben: For example when we talk about what network administrators must and must
not do we also put that in BCPs. Honestly I think the status of the document is
a bit of a technicality. I understand that this needs to be documented
somewhere and the authors have, I think, if I understand their response
correctly they were considering removing the normative stuff. If i'm the only
one who's worried about this I will clear.

Benjamin: I don't believe you're the only one worried about it.

Alissa: I was worried about it too. If they were fine with a non-normative
description as existed in 3188 that seems like the best resolution here. The
way some of the statements are made in this document make me uncomfortable.
What if instead of national libraries we were talking about national numbering
authorities for telephone numbers, or something? If you do that substitution in
your head and look at it you'd say that's not something we want to have in an
IETF document. The fact that the current set of parties feels okay about it
doesn't make me feel okay about it.

Benjamin: In one sense you could say we're defining this thing as extension to
the NBN, and you don't have to use it, but if you want to use it you have to
meet these requirements. I'm still a little worried about that in context of
one of my other ballot comments, which is the process of turning an NBN into a
URN:NBN is pretty deterministic and algorithmic and someone who is not the
actual national library might attempt to do so, so there'd be some worry about
non authoritative parties attempting to generate noncompliant URNs.

Alexey: Speaking of this discuss specifically, is getting rid of the normative
language the only way of addressing people's concern? I want to give authors as
many options as possible. Is re-Last Calling it as proposed okay or is it not
going to address people's issues?

Warren: It feels like that would require a fair bit of rewriting. Could there
simply just be weasel words at the beginning that says this doesn't put
requirements on them, it's just reflecting how it currently works?

Ben: i was going to propose that too, in particular if we were...I commented in
my discuss that merely lowercasing the words doesn't really make me happy , but
lowercasing the words and then adding a paragraph of scope to it towards the
beginning of the document would help.

Alexey: Can you communicate with the authors and shepherd to try to come up
with some text?

Ben: I can try, but I may have to disappear offline for a few days. But I will
do that to the best of my abilities.

Alexey: that's fine, I don't think it's particularly urgent. If you disappear
for two months Adam and I will have other issues.

Ben: I think we can move the discussion to email at this point.

Alexey: I think this will definitely need a new revision.

Cindy: We will keep this one in IESG evaluation, Revised ID Needed.

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 NONE

3.4.2 Returning items

 NONE

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

 NONE

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o IP Security Maintenance and Extensions (ipsecme)

Cindy: The token here is Ekr who couldn't be with us today, but there are no
blocks so if there are no objections this will go ahead for external review.
Okay, hearing no objections, this will be set for external review. We'll just
check with Ekr one last time.

4.2.2 Proposed for approval

 o Limited Additional Mechanisms for PKIX and SMIME (lamps)

There are no blocking comments so unless there's an objection this recharter is
approved. Again, since Ekr is not here, we'll check with him before sending
that announcement.

Benjamin: He definitely has edits to make on both of them.

5. IAB news we can use

Cindy: Deborah could not be with us today but she did send email with her one
piece of news, which is that the IAB will not be having technical talks during
the plenary. Alissa, anything else people should know from the IAB?

Alissa: I don't think so.

6. Management issues

6.1 IETF 103 Important Dates Approval (Secretariat)

Cindy: This was approved at last week's informal call.

6.2 [IANA #1112601] Designated expert for RFC-ietf-core-senml (IANA)

Cindy: This is in progress; it's been assigned to Alexey and we referenced it
at the top of the call.

6.3 Next steps when an AD removes a doc from a telechat agenda (IESG Secretary)

Cindy: We sent email on this earlier this week and wanted to close the loop so
everyone is on the same page. The Secretariat is now managing the telechat
queue and our trigger to add to the agenda is when a ballot is issued. However,
in cases where an AD removes a doc from the agenda without putting it on a
later agenda, that also removes it from the secretariat's queue. It'll be the
AD's responsibility to either put the document back on the agenda in the
Datatracker or email the Secretariat to let us know we should do it, but we
won't get the automatic trigger because the ballot was already issued. Any
questions or discussion?

Spencer: Does anyone object to having the ADs be responsible for adding the
re-added document back on the agenda using the datatracker?

Ben: I think that's constructively what this is. We've always had the ability
to send email to the Secretariat asking them to push buttons for us.

Benjamin: The only question is if we explicitly want to deny that so as to
force the Secretariat's queue length management function to be invoked. If the
AD directly puts it on an agenda that could put the page count very high.

Ben: Hopefully we would just ...

Benjamin: Not do that.

Ben: Or have some peer pressure, like we did in the past. Hopefully the
secretariat, when they make queuing assignments, will be aware that document is
already there and eating pages.

Cindy: If you add something back to an agenda and it causes an agenda to go
over 400 pages we will see that and follow up with the person who added it to
see if they really needed to add it there, and re-juggle accordingly.

Spencer: Friendly amendment: Check with the IESG. The reason we're having the
secretariat manage the queue at all is because some of the ADs thought it was
fine to add a lot of pages.

Cindy: Right, we'll keep the 400 page goal in mind.

Spencer: But I was saying also include the IESG in the conversation, not just
the AD who put the document on.

Cindy: Yes, okay. We can do that. Unless there's anything else on this item, I
think that's all we needed from you and we can move on.

6.4 [IANA #1112621] renewing early allocations for
draft-ietf-bess-evpn-optimized-ir (IANA)

Michelle: Because we're doing an additional extension we have to get IESG
approval for it. Any objection to approving this for another year?

Martin: The document has passed WG last call, so there won't be another one.
It's the last one I guess. I'd appreciate if all of you could approve it.

Michelle: It's on its way, so hopefully this will be the last one.

Cindy: Unless there are any objections, this is approved, and we will get a
note sent to IANA.

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

Alissa: I have one small request. I sent a note to a few random people trying
to get some folks who are not IETF regulars but who interact with RFCs to join
the rfcplusplus list in advance of the BOF. If other people could do that too I
think that would be quite useful to get thoughts, anecdotes, experiences, from
people you work with to provide a little bit of their perspective. I have a
form email I can send to you if you want it, if that makes it easier to forward
on.