Narrative Minutes interim-2019-iesg-01 2019-01-10 15:00
narrative-minutes-interim-2019-iesg-01-201901101500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2019-01-09 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Ignas Bagdonas (Equinix) /  Operations and Management Area
Deborah Brungard (AT&T) / Routing 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
Sandy Ginoza (AMS) / RFC Editor Liaison
Ted Hardie (Google) / IAB Chair
Benjamin Kaduk (Akamai Technologies) / Security Area
Suresh Krishnan (Kaloom) / Internet Area
Mirja Kuehlewind (ETH Zurich) / Transport Area
Warren Kumari (Google) / Operations and Management Area
Terry Manderson (ICANN) / Internet Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alexa Morris (AMS) / IETF Secretariat
Eric Rescorla (Mozilla) / Security Area
Alvaro Retana (Huawei) / Routing Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Jeff Tantsura (Apstra) / IAB Liaison (WebEx only, not audio)
Martin Vigoureux (Nokia) / Routing Area
Amy Vezza (AMS) / IETF Secretariat

REGRETS
---------------------------------
Heather Flanagan / RFC Series Editor
Portia Wenze-Danley (ISOC) / Interim LLC Executive Director

OBSERVERS
---------------------------------
Marie-Jose Montpetit

1.2 Bash the agenda

Amy: Anything new to add to today's agenda?

Benjamin: Yes. We've been having some discussion about the netconf zero touch
document that might indicate we should discuss the IANA registry created by
dnsop-attrleaf document in terms of what we want to do there. That's going to
be a management item discussion.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the Dec 20 teleconference
being approved? Hearing no objection so we will get those posted. I resent the
narrative minutes; there were no comments or changes on those. Any objection to
approving the narrative minutes? Hearing no objection, so we will get those
posted as well.

1.4 List of remaining action items from last telechat

Amy: The first five or so are for Ekr to find experts. Any movement there?

Ekr: I'll try to get all of them for next time.

     o Eric Rescorla to find designated experts for RFC 8411 [IANA #1120853].

     o Eric Rescorla to find designated experts for RFC 6509 (mikey-payloads)
     [IANA #1121057].

     o Eric Rescorla to find designated experts for RFC 6043 (mikey-payloads)
     [IANA #1121239].

     o Eric Rescorla to find designated experts for RFC 6267 (mikey-payloads)
     [IANA #1121240].

     o Eric Rescorla to find designated experts for RFC 6309 (mikey-payloads)
     [IANA #1121241].

     o Alvaro Retana to follow up on discussion at IETF 103 about putting major
     discussion points and decisions in the IESG Wiki.

Alvaro: I did send some emails yesterday for this item and the next one. I want
to discuss them on the list and depending on how that goes we can schedule
something for the next informal. I would say we can take those two off.

Amy: We'll mark those as done, thank you.

     o Alvaro Retana to follow up on how to document decisions made during
     face-to-face IESG conversations.

     o Alissa Cooper to draft text informing the community about the ongoing
     discussion with the WG chairs about community relations,
        including information about what avenues are open to community members
        for escalating issues.

Alissa: I haven't done that yet. Can we talk about it for one second? I'm just
looking back at the wgchairs list. Oh there has been mail on this since the new
year. I was going to ask if people thought this was settled but there's mail
from today. Thanks.

Spencer: I think the conversation that's been happening is helpful, so I think
your pacing is just about right.

Alissa: Okay, I think letting people know it's happening now is fine.

     o Alvaro Retana to send email to the IESG with proposed re-labeling of
     scheduling conflicts.

Alvaro: That is still in progress.

     o Alissa Cooper to follow up with Michelle Cotton and Barry Leiba to
     update RFC 8126 to detail what information should be
        included in the IANA Registry.

Alissa: That's done.

     o Alexey Melnikov to find designated experts experts for RFC 5435 [IANA
     #1132764].

Amy: Just so you're aware this has been assigned to you, Alexey.

Alexey: I'm not quite done. I know the person but I haven't sent email yet, so
next time.

     o Benjamin Kaduk/Eric Rescorla to find designated experts for RFC 6844
     [IANA #1133642].

Amy: This one is for Benjamin or Ekr. Do we have an idea who would be best to
do that?

Benjamin: I can do that.

     o Warren Kumari to find designated experts for RFC-ietf-dnsop-attrleaf
     [IANA #1133794].

     o Warren Kumari to find designated experts for
     RFC-ietf-dnsop-session-signal [IANA #1133795].

     o Warren Kumari to find designated experts for
     RFC-ietf-dnsop-dns-capture-format [IANA #1133796].

Warren: I didn't know these were being assigned to me. I will take a look.

     o Eric Rescorla to find designated experts for RFC-ietf-acme-acme [IANA
     #1133797].

Ekr: That I can do. Two experts, or just one for that?

Amy: It's up to you. You can name one or two, as long as IANA has someone for
necessary expert reviews.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-bess-evpn-vpls-seamless-integ-05  - IETF stream
   (PBB-)EVPN Seamless Integration with (PBB-)VPLS (Proposed Standard)
   Token: Martin Vigoureux

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

Martin: I think we can exchange a few words. I don't agree this should be a
BCP. I understand why it might have come on the table but the document doesn't
describe new bits on the wire like we usually find in protocol specs, but it
defines the behavior of a node or a set of nodes and that results in how the
code behaves. I don't think that's a BCP because it has nothing to do with how
the operator should configure the network to do this and that; it's how the
node and the code should behave for the function to be realizable.  I
definitely don't think it is a BCP and I believe it is a proposed standard
because the behavior needs to be supported by a variety of nodes otherwise we
don't achieve interoperability.

Alissa: Would it be possible to clarify that better in the document?

Martin: I think we can try, yeah. It might be needed since the question came
up. I'll work with the authors to make sure it's clearer and you can review
that. Typically if I read the first few lines of section 3.1 I don't think how
we can be more clear. When they say EVPN PEs MUST advertise both the BGP VPLS
Auto-Discovery (A-D) route as well as the BGP EVPN Inclusive Multicast Ethernet
Tag, things like that you find throughout the doc that clearly set requirements
on what the nodes should do. Never mentioning intervention of the operator and
so on. We can always try to rework the document but I'm not sure how much
clearer we can make things. See what I mean?

Alissa: Basically what you just said at the top would help. Essentially I asked
for that because a few people had this reaction to this document, people who
aren't well steeped in the technology. After this gets published, nobody will
remember that we had this conversation and the record of why this one went to
PS instead of BCP when it comes up again for a different document in a
different context. I appreciate what you're saying but for non expert readers
it would be useful as a general clarification so if this question comes up
again it's recorded in this document why it was decided this way. The
implications on the code path are a really good reason. That's fine, it wasn't
obvious to me because I don't configure these things and so I don't know.
That's all.

Martin: Okay, I will work with the authors to have some clarifications along
these lines early in the doc. Thanks.

Amy: So that sounds like it's going to need a revised ID.

Martin: Yeah, most likely. Thank you.

 o draft-ietf-bess-evpn-df-election-framework-07  - IETF stream
   Framework for EVPN Designated Forwarder Election Extensibility
   (Proposed Standard)
   Token: Martin Vigoureux

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

Martin: Yes, again, we can if Benjamin wants to. Benjamin, on your first point,
which has been picked up by many others on the update, there has been a
discussion with the authors and they will change the document to update 7432.
Originally I was of the opinion that it was needed, they convinced me that it
was not needed, and in the end I think the paragraph in section 3.1 that you
picked up clearly mandates the update. So they will request the update of 7432.
That addresses your first point.

On your second point you seemed to be worried about the combinatory explosion
between algorithm type and capability. I'm not so worried, honestly, and I
don't see it as an explosion because it's really a compatibility between
algorithms and capability. On one side we have 31 different algorithms and if
someone comes with a new capability he only has to say whether the new
capability matches with these 31 algorithms, so that's not an explosion I would
say. If someone comes with an algorithm he only has to do that with 16
capabilities at most. In reality today we only have 2 algos and one capability
with no real plan to define anything much more beyond that. From a combinatory
perspective I think we are safe.

Benjamin: Yes. Having heard you say that, I agree. I had it my head there were
going to be thousands.

Martin: No, there won't be. On the third point you had a good question on how
do you ensure the autoderived values don't overlap. I did a bit of homework and
the first three types, type 1, 2, and 3 are unique values like MAC addresses.
These are clearly unique and they cannot overlap. The question comes indeed for
ESI type 0, 4, and 5, because all of them have an arbitrary value. The 0 is
nine octets of fully arbitrary values. 4 and 5 they use as a base the router ID
plus a local discriminator. To answer your question, the only way to avoid the
overlap across the different types would be by means of configuration, because
these values will be configured. So the operator needs to make sure whatever
value he uses for the local discriminator doesn't collide with other possible
values. That might be cumbersome; I don't know if the answer to that question
is enough for you to clear or would you want some means to mitigate the overlap
or at least to warn the user there could be an overlap. I fear if we do so we
go beyond the protocol spec.

Benjamin: I don't think we need an automatic way to algorithmically avoid the
overlap. I think it would probably be enough if we just had some text in the
document basically saying what you said, that the type 0 is fully arbitrary and
the type 4 and 5 involve a discriminator, so when the operator is setting these
they should be aware there's this risk. Given that these numbers are pretty
large number of bits, the risk of random collision is pretty low.

Martin: Okay good. I'll ask them to add that. Next point is very good on the
ESI that could be set to all zeros. I would have liked the authors to have
replied to that and I don't think they have. I will ping them. You have a very
good point here. We need to make sure we don't ruin the whole capability by
allowing that mode. I'll let the authors comment on that and you decide based
on their answer.

Benjamin: Sounds good.

Martin: Last one, good point as well, the AC-DF capability may be used with
any. I think we want to restrict that to any country defined at the time of the
document.

Benjamin: Sounds good. Thanks.

Martin: And thank you to everyone for your comments. This will require a
revised ID.

 o draft-ietf-softwire-yang-14  - IETF stream
   YANG Modules for IPv4-in-IPv6 Address plus Port (A+P) Softwires
   (Proposed Standard)
   Token: Terry Manderson

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

Terry: No, I don't think so. I've only just seen a response from Mohamed to Ben
about an hour ago and no response to Alissa's Discuss. At this stage no, but it
will need a Revised ID.

Benjamin: Do we need to talk about the author count?

Terry: No, it's going to be AD discretion. It's 2 extra authors and the IESG
likes to talk about authors approximately once every couple of years at a
retreat and I don't really want to talk about it again.

Spencer: If I could just make one suggestion, I've been asking shepherds to
explain that in their writeups and that's actually shortened a lot of
conversations for documents with more than five authors. As a heads up for
other ADs who might not have been doing that, asking the question and having it
written down going into the telechat seems to shorten those conversations.

Adam: I'll also point out 7322 says we're supposed to consider this explicitly.
If we think that's wrong, we should talk to the current version going on right
now.

Warren: I thought what we decided last time we discussed this was we would
think about it and we'd try to keep it under the recommended number, but in
exceptional cases we'll say, eh, this seems reasonable, and move on.

Alvaro: I think we decided we weren't going to talk about it anymore. If
there's more than five, we ask for justification, then push it forward.

Ekr: I suggest we take Terry's advice and not talk about this again.

Benjamin: Seeing no explanation in the shepherd review, I'm obligated to put a
cursory roadblock up and will happily clear once it comes up in the telechat. 
I think we should move on.

Amy: Okay, we'll move on and have that document put in the substate of Revised
ID Needed.

 o draft-ietf-extra-sieve-fcc-08  - IETF stream
   Sieve Extension: File Carbon Copy (Fcc) (Proposed Standard)
   Token: Alexey Melnikov

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

Alexey: Maybe quickly. Ben, I just replied to your message saying I think
filing messages to shared folders might be an issue and some text should be
added about this.

Ben: To be clear, I'm not saying I know what the considerations are, but it
seemed a red flag it said there were no considerations in addition to what was
in the base RFCs, but the base RFCs didn't describe those considerations for
that kind of action.

Benjamin: I did manage to come up with the filing into a shared folder point
that Alexey just mentioned, but I was saved from having to think about it more
completely.

Alexey: There are 2 possible issues I can think of; filing into a shared folder
because it might disclose that a person is on vacation or going somewhere,
collecting location information. The other thing is possibly going over quota
as Adam pointed out. I can't think of any other issues to be honest.

Ben: In general, since there are no considerations documented for the file into
action, other than the hint of danger, it might be worth saying the safety of
this depends on good practices for protecting the mailboxes in the first place.

Al: This is a bit nebulous; it's a very easy mistake to misfile to a mailbox
that can be accessed by someone else. I can talk to the WG about some specific
text.

Ben: Hopefully the WG would know more about this than I would, about what the
real implications might be.

Alexey: True. In the meantime if people can think of other examples that would
be great because those are the only two cases I can think of that are security
or privacy sensitive. I think this needs a new revision, and there are other
good comments, so I'll make sure the editors review them and revise the
document.

 o draft-ietf-nfsv4-mv0-trunking-update-03 (Has RFC Editor Note)  - IETF stream
   NFS version 4.0 Trunking Update (Proposed Standard)
   Token: Spencer Dawkins

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

Spencer: Benjamin, tell me if you disagree. I have not seen a response from the
authors on this. What I believe you're pushing on mostly is that the WG had a
vague notion of what trunking was in 4.0 and is now trying to come up with a
more solid definition in 4.1 that does more things, then try to back define
that in 4.0. I pushed on that at AD evaluation time and seems like I should
have pushed a little harder. I think that's the biggest thing in your discuss
and I agree with what you have there. I'm thinking we're waiting for the
authors to reply.

Benjamin: I think we're definitely waiting for the authors to reply and it's
probably reasonable to do this sort of thing in general, we just could have a
little more clarity about what exactly is supposed to happen.

Spencer: Yes. And like I said this is stuff I pushed on at AD evaluation time
and I'm sympathetic and I maybe should have pushed a little harder. But this is
a revised ID needed and we can move on.

 o draft-ietf-extra-sieve-special-use-04  - IETF stream
   Sieve Email Filtering: Delivering to Special-Use Mailboxes
   (Proposed Standard)
   Token: Alexey Melnikov

Amy: There are no Discusses in the tracker, so unless anyone has an objection
now this is approved.

Alexey: I would like to have this Point Raised so I can catch comments from the
tracker.

Amy: Great, you can let us know when that is ready.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 o draft-arkko-trip-registry-update-01 (Has RFC Editor Note)  - IETF stream
   Update to the TRIP IANA Registry Rules Regarding Postal Addresses
   (Proposed Standard)
   Token: Ben Campbell

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

Ben: Alexey, can you tell people what you told me? Or is it already in there?

Alexey: Basically I was checking with Michelle how postal addresses are used by
IANA and if there's a difference between collecting information vs displaying
them.

Michelle: I reread the document and after discussing with Alexey, the current
wording does limit collecting address information. We probably don't want to do
that bc if for some reason we needed to collect address information for either
a legal review or verifying if an organization has the same name as another
organization, we should be able to, even though we rarely do it. I think it's
just three words that need to be changed in the document. Focusing more on that
we're not required to publish the contact information, we want to avoid having
these addresses in the published registry, I think that would satisfy our needs.

Alissa: Didn't we kind of check around with everyone and basically decide
there's no need for the information right now? That it's not actually being
used for any purpose? If a new purpose did come up I feel like that would
warrant another update. That's the whole gist of the GDPR thing is that you
don't collect the data if you don't need it, and we definitely don't need it
right now.

Michelle: The question is more about if we needed to ask them for their address
to verify anything, that we could. But this document says that we will no
longer collect the postal address.

Ben: I assume that meant you would no longer collect it as a matter of routine
for registrations.

Ted: Section 13.5 of 3219 says the request must include the following but says
nothing about what IANA must publish. If the conclusion of the IESG after this
publication is that IANA need not publish this data, I don't think there's any
publication of this RFC required at all. It appears according to 13.5 of 3219
to be discretionary of what IANA publishes. I agree with Alissa though that the
discussion to date has basically come to the conclusion there's no real purpose
in collecting this info in the first place. Once the ITAD number is assigned,
if a successor in operation wants to use it, nobody really cares if their
contact information has changed. If they need a new one there's no need to link
the two organizations that did the request in the registry. I'm not going to
speak for Jari but we agreed to do this entirely because of the GDPR. My
understanding of the GDPR analysis was you don't collect info you don't have a
purpose for using. If we agree we don't have a purpose for using this then we
should publish this update and stop collecting it. If we believe there's a
purpose for using it, I'd prefer you delay this document while you reconfirm
either with IANA's lawyers or our lawyers or both, that that purpose is
sufficient for GDPR purposes so we don't end up recycling on this next time we
talk to the lawyers.

Ben: Michelle, are you talking about the need to have it collected as a routine
part of every registration, or are you talking about IANA may occasionally need
to ask to resolve some conflict?

Michelle: If we needed to go back and ask for that info to resolve an issue.

Ben: I have to wonder if that kind of asking as part of the registration
process is even in the scope of this document.

Ted: Let me presume to give an example. Your concern is you want to understand
whether organization example.com which has come to ask for an ITAD number is
actually the same as example.com of Madrid, Spain, who previously got an ITAD
number, so you can say you already have one, it's this. So you work out whether
or not they're they same by asking the new one if they are in Madrid, Spain,
and if they say no you say here's your new ITAD number. If they say yes, you
say you already have one and it's this.

Michelle: That's one purpose of being able to ask them what the address is, yes.

Ted: As long as the purpose is post facto request, that's just an interaction
between IANA and the registrant. If the only way you can get this is to have it
from the beginning, then it is a registration discussion.

Ben: And in the example you just gave, it's only useful if they had it from the
beginning.

Ted: You could ask each of them where they are and get the same result. Given
the number of registrations and the fact this is first come first served, color
me 'this document has gotten more attention than it needs.' I just want to say
if we go back to the theory where it's collected I'd really like to reconfirm
with the lawyers that that's okay and that the purpose meets one of the GDPR
purposes because at the moment my impression is it did not.

Ekr: We should err on that side.

Michelle: I think it's worth double checking this one before we approve and let
it go on.

Ben: I'm fine with that but what does double checking mean?

Michelle: I think I'm going to follow up with Ted and Alissa and maybe Alexey
can hold his discuss. If we decide it's not an issue Alexey can clear his
discuss, and if there's another path we have to take we'll let you know, Ben.
Alissa and Ted, does that sound all right with you both?

Alissa: Yes.

Ted: Sure. Who wants to talk to Jari about this?

Michelle: I'm happy to do it.

Ben: Obviously there's a Discuss sitting on this but I think we have whatever
the equivalent of Point Raised is.

Amy: That would be AD Followup. You can let us know when/if it's ready.

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-rtgwg-spf-uloop-pb-statement-09  - IETF stream
   Link State protocols SPF trigger and delay algorithm impact on IGP
   micro-loops (Informational)
   Token: Martin Vigoureux

Amy: Martin, I don't have a consensus set for this. Is this a yes?

Martin: Sorry I missed it. It is a yes.

Amy: Great. I don't have any Discusses so unless someone has an objection now,
this is approved.

Martin: I need to check but I think the authors have already agreed to
incorporate all the comments but I'm not sure they have published yet, so let's
wait for that.

Amy: This will go into Approved, Announcement to be sent, Revised ID needed.

 o draft-ietf-v6ops-transition-ipv4aas-13  - IETF stream
   Requirements for IPv6 Customer Edge Routers to Support IPv4
   Connectivity as-a-Service (Informational)
   Token: Warren Kumari

Amy: I have a number of Discusses. Do we need to discuss any of those today?

Warren: Yes, that would be helpful. I think Alissa's Discuss can be pretty
easily addressed but Suresh's Discuss, which is closely related to Benjamin's,
is a larger issue. I will happily admit I did not notice that at all and thanks
to Suresh for catching it. As for the resolution of it, it think it's going to
require more discussion and I suspect it's also going to require V6OPS chiming
in as well, whether they just take that section out or how we deal with it.
Suresh and Benjamin, I don't know if you've got any thoughts or comments.

Suresh: I brought up one issue but it's actually 2 issues with the same
manifestation. One of them is using a multicast option for a reason it's not
intended for. The second part is to actually change the semantics of that thing
without properly updating the standards. The third part, what Ben brought up,
is that it updates a proposed standard from a non proposed standard document.
Those three things are all closely related and by taking this away it goes
away, but it looks like the wg has to have the discussion. It looks like the
issue came up before in a different context in the wg, and the two people who
brought it up are in the rough. I don't know if that would change this time
around.

Warren: I will ask the wg chairs to help get consensus. And if you could also
please stay involved, you seem to know this a lot better than I do.

Suresh: Will do, thank you.

Adam: Do we need to discuss the status of BCP vs informational on this one?

Warren: I can't remember who was pushing for BCP.

Ben: I asked the question, I don't know if I was actually pushing.

Warren: To me it reads as though it could go either way. I'm not sure why it
was done as it was. I don't know.

Ben: Would BCP solve the updating proposed standard problem?

Adam: Well it's updating the informational draft, so I don't think that's it.

Ben: Never mind.

Adam: As long as the AD has thought about the issue, I'm good with the answer.

Ben: That was the point of me bringing it up, to make sure someone thought
about it.

Warren: I'll think about it some more but I think the main issue is going to be
fixing the other problem. The wg doesn't seem to be clamoring for BCP.

Suresh: One thought I had against BCP was that this is more a requirements
spec, and knowing the past history of this, like 7084, that was used as a
procurement tool. I'm not sure if it's the BCP role personally. I'm happy with
it staying informational, personally.

Warren: I think I am too.

Amy: Okay, so it sounds like we're finished with the discussion here and it's
going to require a revised ID.

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-icnrg-ccnxmessages-00
   IETF conflict review for draft-irtf-icnrg-ccnxmessages
     draft-irtf-icnrg-ccnxmessages-08
     CCNx Messages in TLV Format (IRTF: Experimental)
   Token: Suresh Krishnan

Amy: I have no Discusses in the tracker so unless there's an objection it looks
like the conflict review message can go back to the IRSG.

Suresh: There's one thing I wanted to discuss with Ben because he made an
interesting point on both the conflict reviews, and that's about the use of the
8174 boilerplate. I was digging around a little bit and I looked at 2119 and it
says it's for IETF documents. I'm not sure if we should talk to the IRTF about
it in a more general case, but in this case we should let it pass.

Ben: I meant it more in a generic case, is this something we should be thinking
about. It's a little odd to see 2119 keywords in ISE documents, or maybe it
should be a little odd. I don't have strong feelings about it.

Ekr: I don't know about these documents because I haven't read them but very
shortly in subsequent conflict reviews there are going to be documents from
CFRG that are algorithm specifications, and those do make sense to have
normative language. I have no position on the procedure of matters like that
but I think it's important that IRTF docs be able to reflect instructions to
people.

Ben: To be clear, I wasn't questioning whether we should have boilerplate at
all, I was just questioning whether we should encourage them to use 8174
instead of 2119.

Ekr: Great. I will leave that to people who understand this topic better than I
do.

Suresh: Sounds good Ben. I'll write up a note to Allison along with this,
especially the note about the abbreviations. I can send it to Allison as
shepherding AD so she knows about it.

Ben: Thank you.

Amy: Looks like the conflict review message is approved and we will get that
sent on Monday as we normally would.

 o conflict-review-irtf-icnrg-ccnxsemantics-00
   IETF conflict review for draft-irtf-icnrg-ccnxsemantics
     draft-irtf-icnrg-ccnxsemantics-09
     CCNx Semantics (IRTF: Experimental)
   Token: Suresh Krishnan

Amy: I have no Discusses in the tracker so unless there's an objection it looks
like the conflict review message can go back to the IRSG.

Michelle: Quick question, is the IESG okay with designating experts for the
registries in this document?

Suresh: I personally think it should be the IRSG doing it but I can talk to
Allison to figure it out.

Michelle: Okay, as long as somebody's in charge of the designating of the
experts we will be okay.

Suresh: Okay. Amy, can you put an action item on me to figure this out? Thank
you.

Amy: Excellent, this will get sent to the IRSG.

 o conflict-review-irtf-cfrg-gcmsiv-01
   IETF conflict review for draft-irtf-cfrg-gcmsiv
     draft-irtf-cfrg-gcmsiv-09
     AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption
   (IRTF: Informational)
   Token: Eric Rescorla

Amy: I have no Discusses in the tracker so unless there's an objection it looks
like the conflict review message can go back to the IRSG.

Ekr: I'm not objecting to my own review, but we discussed a little on the list
if it would be useful at some point to have a response like, thank you for
doing this work that's actually need in the IETF, and it's especially odd when
we have to say which groups its related to when in this case it's like any
security wg or rg could make use of this input. Do people think we need a 5742
update that is like adding a new thing? Should we just create a new response of
our own? Is this a waste of time?

Spencer: I've done slightly modified versions of responses in the past. I think
including the  words 'thank you so much' would be a friendly amendment.

Ben: We keep insisting on exact wording of these but I think the RFC actually
says these types of responses, instead of these exact wording responses.

Warren: I don't think anybody would fuss if we change it from 'this is related
to work but doesn't prevent publishing' and by the way it's really great work,
thank you for doing it.

Ekr: It's less the acknowledgment I want to give than the sense of these
reviews is very much like this is not a conflict, but the proper relationship
in this case is a dependency. I guess maybe no one wants to acknowledge it but
it's weird that we act as if these IRTF docs which really are inputs to our
work have the same kind of non overlapping relationship than the ISE documents.
But maybe I'm fussing about it too much.

Warren: I don't think it's worth updating the RFC. I think we can just change
the conflict review text to mean what we think it should mean. If anyone fusses
about it then we can update the RFC. I think calling it a conflict review but
changing the text to say what we believe, and then if anyone wants to appeal we
can fix it.

Alissa: Didn't we just write an appeal response part of which was premised on
the fact that we do feel like we have some fidelity to the five choices
specifically? I feel like that's where we landed on that.

Ben: I think that's the five categories, or types of choices, I don't think our
response said we had to stay word for word, but it did say we couldn't come up
with a completely new type.

Alissa: This sounds like a completely new type to me. It's not even really
about reviewing for conflict. It's about something else altogether.

Mirja: I don't think it's needed to reply differently because the only point of
this review is to answer the question if there's a conflict, and our reply is
no there isn't. It doesn't sound very positive but that's the only point,
answering this one question and that's what we're doing.

Alissa: If you want to channel feedback to the IRSG that this document is
really good and you should publish it, you can do that.

Spencer: We do say look at the datatracker for more notes, and if one of the
notes is thank you, I don't think that would offend anybody either.

Ekr: The only other thing that gave me pause was where I was supposed to list
the wgs that were related, which was very difficult.

Ben: I think I have at least once snuck by a multiple wgs without a list, and
no one noticed or cared.

Alissa: You could do 'multiple wgs including x, y, and z' as an example.

Spencer: Or 'related wgs'.

Mirja: The point of listing related wgs is to give the editor an opportunity to
look at wgs or talk to chairs or look at lists to figure out what's going on
there but if there's no concrete thing the editor should be looking at it's not
necessary to list them all one by one.

Ekr: Sorry for the detour.

Amy: Ekr, does that mean you're going to be editing that conflict review, or no?

Ekr: Let's keep it as it is.

Amy: We will send the no problem message back to the IRSG.

 o conflict-review-mcgrew-hash-sigs-00
   IETF conflict review for draft-mcgrew-hash-sigs
     draft-mcgrew-hash-sigs-15
     Hash-Based Signatures (IRTF: Informational)
   Token: Eric Rescorla

Amy: I have no Discusses in the tracker so unless there's an objection it looks
like the conflict review message can go back to the ISE. Hearing no objections,
so we will get that off on Monday as usual.

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

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Amy: Any news this week?

Deborah: No, I don't think so.

6. Management issues

6.1 [IANA #1132764] Designated experts for RFC 5435 (IANA)

Amy: We discussed that at the top of the call.

6.2 Plenary Transcripts (Alissa Cooper)

Alissa: To recap, we previously looked at the statistics for who was
downloading the minutes from the plenary and it was very minimal, only a
handful who had downloaded minutes from any plenary. We decided not to have
minutes taken at the plenary anymore but we did not tell the community, which
was a problem. What we did for 103 and 102 was we had auto generated
transcripts from the Youtube feed and asked AMS to clean those up and publish
them. It turns out that was actually more work than just transcribing the
plenary anyway. So thank you very much for doing that, Amy. Those have been
published to the datatracker. Now we are at the point where if we want to
reevaluate the prior decision of not taking minutes, we should do that. I
personally do think the experience of 103 was revelatory and having the written
record of that is useful, at least of the Q&A. That's why I wanted to bring it
back up again. If we do still want minutes to be taken we can figure out how to
do that, whether it's going back to finding a community volunteer every time or
having AMS do it.

Spencer: Is our steady state at this point that we would publish minutes for
104?

Alissa: Yes, because we haven't told the community otherwise.

Mirja: I'm +1 for AMS taking the minutes. It's always a pain to find someone to
take minutes and AMS surely can't take minutes for everything but for the
plenary we should use this resource.

Ekr: I concur with Mirja.

Alissa: The way this would work is that because the secretariat is basically
fully occupied during the plenary and at the meeting, somebody would watch the
recording afterward and produce the minutes.

Ekr: I'd like to move that person gets a bonus. In an ideal world AMS would
take all the minutes, but given that they can't do that, we should use them for
the plenary. For purposes of the record, having AMS do that is a really good
idea.

Ted: There is a youtube closed caption transcript they can use, so they don't
need to do it from zero.

Amy: Let me clarify that for you. What you get from the transcript is an entire
block of text with no capitalization or punctuation and no clue who's speaking.
So it's far easier to just listen to the recording and do it from that rather
than the transcript.

Ekr: I'd like to move that AMS knows what they're doing and have them deal with
this in the way they deem appropriate.

Spencer: I'm watching the video from the TSV area for the last several meetings
so that makes perfect sense to me.

Warren: What RIPE does is use a stenography service so AMS might want to
consider farming this out.

Alissa: Do people feel like this is just needed for the Q&A portion? If there's
a technical presentation we don't need for that to be minuted.

Spencer: I'd be okay with that.

Ekr: I think yes but we should state that to the community.

Alissa: I can take the action to send mail to the community about that, that
the secretariat is going to be producing minutes for the Q&A of plenaries going
forward, assuming this works out from the budget/SOW side, which we will leave
for Portia and Alexa to figure out.

6.3 [IANA #1133642] Designated experts for RFC 6844 (IANA)

Amy: We discussed this at the top of the call.

6.4 [IANA #1133794] Designated experts for RFC-ietf-dnsop-attrleaf (IANA)

Amy: We discussed this at the top of the call.

6.5 [IANA #1133795] Designated experts for RFC-ietf-dnsop-session-signal (IANA)

Amy: We discussed this at the top of the call.

6.6 [IANA #1133796] Designated experts for RFC-ietf-dnsop-dns-capture-format
(IANA)

Amy: We discussed this at the top of the call.

6.7 [IANA #1133797] Designated experts for RFC-ietf-acme-acme (IANA)

Ekr: I did this one! Richard Barnes.

Amy: Any objection to assigning Richard Barnes as the expert for this? With no
objection, we will send the official note to IANA.

6.8 Common List of Nominees (Alvaro Retana)

Alvaro: This topic started as a discussion on the iesg-only list but I also
sent mail to iesg. The discussion we had was that we in general thought it
would be a good idea to have a common list of nominees. If the nomcom is asking
for nominees for the Trust, for example, we could use the same list. I sent
that email yesterday and saw Alissa's response. I had made it more general, so
not just the IESG, but anyone else could use the nomcom list. Alissa made the
point that this should be specific, which is fine. Basically if you have a
chance you can take a look at the email. What it says is that if there's a
body, say the IESG, who wants to use the same public list of nominees the
nomcom has, it should tell the nomcom ahead of time before the call for
nominations is made. The chair would indicate that when the call for
nominations is made so nominees are aware they are involved in more than one
selection process. We should also look at 4071bis, and the IASA Trust update
draft. I took a quick look at that and there's a piece of text that says the
IESG is supposed to run an open selection process. I think that contradicts
what we wanted to hear because the nomcom does an open call and then we use the
list of nominees that accepted the nomination.

Spencer: It seems like at the very least I should thank you for taking the next
step on this.

Ted: I'm confused about what you're optimizing for here. In the past a concern
was overlap in the set of candidates and therefore there was always a race
condition between a candidate being selected by one process or another. If
you're making the candidate pool exactly the same, you're making sure the
candidates are always being raced between the two conditions. Let's say the
nomcom has to produce one and you have to produce one and there's one obvious
candidate in the pool, there's a race. I'm a little confused given that past
experience what it is you think this optimizes for.

Alvaro: This started as a discussion on the iesg-only list. We can probably say
now because Alissa already asked for feedback on the one person we're
considering as a trustee, that we didn't get as many nominations as the nomcom.
The discussion started around why that happened. I think someone informally
polled a couple of people and they said they missed the call, or didn't know it
was happening. So maybe it would be a good idea to have a common list. That's
how we got here.

Alissa: To further elaborate, it seems as though the community is dedicated to
having the race condition. People feel really strongly there should be IESG
appointments and nomcom appointments. I don't think reopening this question of
solving the race condition is worthwhile. So given we're going to have that
problem, the idea was it would be useful if the candidates for the nomcom
position were automatically made part of the pool fro the IESG. We could also
seek other candidates and try to stagger these in time a little more. If they
did want to stand for the Trust it's unclear that they have to put their name
into two separate processes that lead to the same body. It might make the race
condition worse but we shouldn't optimize it away.

Ted: I can point out at least one trivial reason; someone who's a current
sitting member of the IESG might decide it's a conflict of interest for them to
be appointed by the IESG but might do the nomcom process because it's not a
conflict of interest. We've definitely had sitting members of IAB who wanted to
be considered for the board of trustees to talk about how that would work.
There are cases where people might wish to be in only one or the other. If
you're going to do it you need a confirmation step from each candidate that
they're willing to be considered by both. Also someone on the nomcom can't be
considered for a nomcom position but they could be appointed by the IESG.

Spencer: Since Ted was not part of the conversation on the iesg-only list, it's
worth saying out loud this is all to keep from changing text that would just
ask the nomcom to pick two people.

Alvaro: Right now the nomcom selected three, the IESG confirms, then the IESG
picks one. Why don't we just change that and have the nomcom pick four?

Mirja: I also don't buy Ted's point because it's the same position people apply
for, it's just who's confirming the nomination. If you are on the IESG and you
want to put your name in for the IESG selected position you can do it but you
can't be part of the selection committee. I don't think there's a problem.

Ted: The Nomcom situation is different because they are forbidden from being
considered for any position for which they select. They can't simply recuse
from that one position; if you join the nomcom you can't be considered for any
position the nomcom has in front of it.

Alissa: The point is to say we can use this pool of nominees, but confirm by
each that they want to be confirmed by the IESG, but the IESG can also do their
own call for nominees.

Ekr: I want to push back a tiny bit on the claim that the community wants a
race condition. Do you think the community really wants us to draw from a
common pool? Is that something the community really needs to be consulted on?

Alissa: You could frame it a different way, but the sum of the things we are
pretty sure the community wants, namely for everyone to be seated at the same
time, for the nomcom timelines to be as they are defined, and to have
appointments both from the IESG and the Nomcom, the net result of that is
essentially high possibility of race condition. You would have to change one of
those things if you wanted to not be in that situation. Maybe the timeline is
what could be changed.

Ted: Given that you don't have a timeline and the Nomcom does a call for
comments, the simplest thing for you to do is when the call for comments goes
out, someone on the IESG to ask them whether they would also like to be
considered for the IESG process.

Ekr: There's supposed to be a month between Nomcom's completion and seating.

Alissa: Those are the same timelines as now. If we were to do our own process
we'd have to open it long before that month, which we essentially already do.

Ted: Speaking as a nominee for the Trust in the nomcom process and a member of
the IESG, I would not have put my name in front of the IESG because of conflict
of interest. Some confirmation step is useful and the easiest way to get it is
to ask each member from the Nomcom pool whether they're willing to be
considered by the IESG as well.

Alissa: And we can do that without any text changes to 7437?

Ted: It's arm twisting, we do that all the time.

Alissa: Okay. I just wanted to make sure.

Alvaro: I'll go check also. I think it sounds to me like we could do that.

Mirja: The only problem is that we need to remember to actually do it.

Alissa: I can add that to the wiki if that's what we decide to do. Alvaro, do
you want to make sure you're comfortable with that based on what 7437 says?

Alvaro: Sure. So that other message out to iasa2.0, they don't need to wait for
us anymore.

Alissa: I can send another mail to the list.

6.9  IANA Registry created by draft-ietf-dsop-attrleaf (Benjamin Kaduk)

Benjamin: I had a very long Discuss on the netconf-zerotouch and I had a great
exchange with the authors. We're down to just one item that relates to this
registry being created by dnsop-attrleaf. The netconf document uses two types
of DNS records, one of which is covered by the normal service name based serve
record discovery sort of thing, but it also uses a txt record that uses _TCP
global underscore name. The document that's in the RFC Editor queue that's
creating this registry lists an item to be in the registry which is for _TCP as
the global underscore label with the txt record type. That entry in the
registry is supposed to be for DNS service discovery. In the brief looking I
did, the usage for DNS discovery does not really match up with the usage the
netconf document is doing, but I believe they also don't conflict with each
other. The netconf thing is adding several more labels and I don't think
there's a way you could have them conflict with what DNS service discovery
does. The question for the IESG is when we recommended that we set up this
registry, did we expect there was going to be some kind of exclusivity for
these registered pairs of DNS record type and global label, or are we willing
to accept that there can be multiple registered uses for the same global label?

Adam: This came in yesterday and I haven't had time to review. To speak
specifically to the question there, I think one of the key purposes here is to
prevent these kinds of collisions. That's why we approved that doc. I don't
remember exactly how that relates to the zero touch document.

Benjamin: Would we need to require a sub registry for usages of txt records
with _TCP in order for these non-overlapping usages to be permitted?

Adam: Oh I see what you're asking. The document explicitly punted on that
point. That's going to require a bit more thought.

Benjamin: If we want to say we have to think about this more and punt it to
email, we can do that.

Adam: I think that's sort of where we are. I'm going to read through this
thread and see if I can untangle the specific issue and then I'll respond to
the thread.

Benjamin: If it was just up to me I'd be okay with listing multiple references
in the dnsop-attrleaf registry under the assumption that you might need to look
at both of those references, but it would still be unambiguous for any given
DNS record.

Warren: It would be totally unambiguous for any record, but what about
implementations that designed themselves before stuff was added? We don't want
to end up in a situation where someone looks at the registry and makes some
assumptions and then later on stuff gets added and their implementation breaks.

Benjamin: I think if we really wanted to we could squeeze this into the initial
registry contents, not that I'm suggesting we do so.

Warren: That would solve the problem for now. I don't know. I guess it needs
more thought.

Benjamin: Let's take it to the email list and I look forward to seeing
everyone's thoughts there.

Warren: Should we ask the RFC editor to hold off a bit?

Michell: That was my question too, since we've already created the registry for
DNS underscore global scoped entries. I was just asking Sandy if they should
make sure it doesn't get fully published yet in case it means adding anything
to the registry to further clarify any uses.

Sandy: That makes sense to us. We can put it on an IESG hold until we hear
further from you.

Warren: If it's on an IESG hold do you ever send a reminder in case we forget?

Sandy: We probably have not typically done that but we can do it.

Warren: Okay. We can also try to remember.

Sandy: I'm sure we can send a reminder.

Warren: Who do we tell once we've decided the hold can be lifted.

Sandy: For us it would be helpful if you send us an email and let us know if
there are any changes required.

Warren: How specifically should we tell you?

Sandy: Just send an email to the RFC editor.

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