Skip to main content

Narrative Minutes interim-2018-iesg-13 2018-06-21 14:00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2018-06-21 14:00
Title Narrative Minutes interim-2018-iesg-13 2018-06-21 14:00
State (None)
Other versions plain text
Last updated 2024-02-23

Narrative minutes for the 2018-06-21 IESG Teleconference

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

1. Administrivia
1.1 Roll call

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
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
Eric Rescorla (Mozilla) / Security Area
Alvaro Retana (Huawei) / Routing Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Alice Russo (AMS) / RFC Editor Liaison
Jeff Tantsura (Nuage Networks) / IAB Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area

Heather Flanagan / RFC Series Editor
Sandy Ginoza (AMS) / RFC Editor Liaison
Portia Wenze-Danley (ISOC) / Interim IAD

Greg Wood

Amy: I don't see Mirja yet, and we have regrets only from Sandy.

1.2 Bash the agenda

Amy: We have two items that were deferred overnight, a conflict review and a
status change. Any other changes?

1.3 Approval of the minutes of past telechats

Amy: Any objections to the June 7 minutes being approved? Hearing none, these
are approved and will be posted. Any objections to the June 7 Narrative minutes
being approved? Hearing none, these are approved and will be posted.

1.4 List of remaining action items from last telechat


     o Benjamin Kaduk to find an additional designated expert for the AEAD
       Parameters registry.

Benjamin: Still in progress. I've been asking for feedback and suggestions but
still need to hear back.

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

Alexey: In progress.

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

Amy: Provisionally done; this approval is a management item.

     o Alexey Melnikov to find designated experts for RFC 6143 [IANA

Amy: Provisionally done; this approval is a management item.

     o Eric Rescorla to find designated experts for RFC-ietf-oauth-
       discovery [IANA #1113497].

Ekr: In progress.

     o Adam Roach to designate a new team leader from current URN
       Namespaces expert pool [IANA #1113095].

Adam: Peter St. Andre has agreed to do this and we'll do it in the approval

     o Alexey Melnikov to find designated experts for RFC-ietf-uta-smtp-
       tlsrpt [IANA #1113903].

Alexey: In progress.

     o Alexey Melnikov to find designated experts for RFC-ietf-extra-specialuse-
       important [IANA #1114238]

Amy: Provisionally done; this approval is a management item.

     o Benjamin Kaduk to find designated experts for RFC 4681 [IANA #1112792]

Benjamin: I think this is just a case of churning all the TLS registries
anyway, so we wanted to make the experts match up for all the registries that
have experts. IANA noticed we haven't done this one yet so we're going to make
them consistent.

Amy: This might be in the management item itself. When we come to that we can
approve those.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-lamps-rfc5750-bis-06  - IETF stream
   Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0
   Certificate Handling (Proposed Standard)
   Token: Eric Rescorla

Amy: No open positions or active discusses, so unless there's an objection it
looks like this is approved.

Ekr: Please put it in the thing that says I'm going to look at it before we
actually push the button.

Amy: Approved, Announcement to be Sent, Point raised, Writeup Needed. Then you
can let us know when it's ready.

 o draft-ietf-spring-segment-routing-ldp-interop-13  - IETF stream
   Segment Routing interworking with LDP (Proposed Standard)
   Token: Alvaro Retana

Amy: I have a couple of open positions. Terry, did you want to state a position?

Terry: It must have fallen off my reading list, no.

Amy: Ekr, do you have a position?

Ekr: I won't be taking positions on things I'm not taking positions on.

Amy: I do have a Discuss in the tracker. Alvaro, do we need to discuss this

Alvaro: No I don't think so, we need to let the authors respond. We will need a
revised ID.

 o draft-ietf-idr-bgp-prefix-sid-25  - IETF stream
   Segment Routing Prefix SID extensions for BGP (Proposed Standard)
   Token: Alvaro Retana

Amy: I currently have a Discuss in the tracker. Do we need to discuss that

Alvaro: We might, I don't know.

Adam: We probably do. I'm happy to be told I'm in the weeds. Ignoring the plans
for publishing something in the future to rectify this, we pretty much all
agree we don't want to be publishing ipv4-only docs in 2018, right?

Alvaro: This is not an ipv4 only doc.

Adam: In that case I must have misunderstood the implications of the removals.

Alvaro: There are 2 flavors of segment routing. one that runs over mpls and one
over ipv6. In mpls you can run v4 or v6 or ethernet or whatever you want.
Basically the only thing that was removed here was the extensions for the
v6only network. You can still run ipv6 over mpls if you want, which is mostly
what's deployed out there.

Adam: Okay, thanks for clearing that up. I'll clear my Discuss.

Suresh: Adam, the v6 stuff that was there was kind of inconsistent, and that's
why they removed it. The sending behavior made something optional that was
required in the receiving behavior. I had a discuss on the previous version of
this document. This is kind of agnostic of the protocols currently of

Warren: I hand't balloted Discuss but now that I think about it more maybe I
should have. There's no discussion of whether this needs to be a transitive
attribute, and whether making it non transitive would stop...

Alvaro: Yes I saw that. Your audio cut out.

Warren: I did not ballot a discuss so there's nothing I can do now but I think
it would be useful if there was some answer.

Alvaro: yes, I've been tracking that discussion and the other one that sprung
out of that from Sue so I will hold this until that is settled somehow. The
other side thing that you didn't see is the question of whether we need to send
it back again. I'll see how much it changes before I make that decision. I
won't let it go through. We'll need a Revised ID.

 o draft-ietf-payload-rtp-vc2hq-06  - IETF stream
   RTP Payload Format for VC-2 HQ Profile Video (Proposed Standard)
   Token: Ben Campbell

Amy: No open positions or active discusses, so unless there's an objection it
looks like this is approved.

Ben: It's going to be Revised ID Needed, there are some comments that need to
be dealt with and hopefully we'll see authors responding soon.

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

 o draft-ietf-mmusic-sdp-simulcast-12  - IETF stream
   Using Simulcast in SDP and RTP Sessions (Proposed Standard)
   Token: Ben Campbell

Amy: I currently have an active discuss, do we need to discuss that today?

Ben: I think this can be dealt with over email, it just needs to happen. Do you
agree, Adam?

Adam: Yes.

Ben: Just fixing some inconsistencies with a dependency.

Amy: Will this require a revised ID?

Ben: Almost certainly.

 o draft-ietf-ippm-twamp-yang-11  - IETF stream
   Two-Way Active Measurement Protocol (TWAMP) Data Model (Proposed
   Token: Spencer Dawkins

Amy: I have two open discusses, do we need to discuss those today?

Spencer: I think that Ignas's discuss is large and well organized and well
presented. The authors are just starting to chew on the three large areas. I
think the right things will happen with that in email. Thank you for a clear
discuss. Adam's Discuss did knock one process question loose from Alissa, which
is that this doc was reviewed by the YANG Doctors in 2016. Whether it should
have been re-reviewed at IETF last call time or not, I don't have an opinion,
but I did notice that Alissa asked. Let's figure out what the right answer is.

Alissa: I don't know either, if it's typical that they re-review YANG models
when they go back into last call.

Spencer: This is my first one, so I have no idea. I went and looked at the
template and Adam is right; the authors will do the right thing. Thank you for
an excellent and actionable discuss.

Amy: It sounds like this will require a revised ID to fix.

Spencer: I'm almost sure that's true, yes.

Michelle: Spencer, do you want IANA to kick off a YANG module review with the
experts just to cover all bases?

Spencer: This is my first YANG model as responsible AD. Is that expert review
the same thing as the YANG Doctors review?

Michelle: Yes, it is the same as the YANG Doctors.

Spencer: That's what I'm confused about.

Michelle: How about I follow up with you offline and we'll make sure that
whatever review needs to happen gets done?

Spencer: We've already got Adam's discuss and I think we know something needs
to happen before it gets approved. Let's work though Adam's discuss before we
ask the YANG doctors for another look. Thank you so much for your help.

Amy: This will go into Revised ID Needed.

 o draft-ietf-pals-ethernet-cw-06  - IETF stream
   Use of Ethernet Control Word RECOMMENDED (Proposed Standard)
   Token: Deborah Brungard

Amy: I see no active discusses, if there are no objections this is approved.

Deborah: Let's do it Point Raised; the authors will be addressing comments.
We'll see if they need a revised draft or not.

Amy: This will go to Approved, Announcement to be Sent, Point raised, Writeup

 o draft-ietf-dcrup-dkim-crypto-13  - IETF stream
   A new cryptographic signature method for DKIM (Proposed Standard)
   Token: Alexey Melnikov

Amy: There are no active Discusses, so unless there's an objection this is

Alexey: Can I have it in Point Raised just to double check the remaining
comments are addressed.

Amy: Sure. Let's put it in Approved, Announcement to be Sent, Point raised,
Writeup Needed.

2.1.2 Returning items


2.2 Individual submissions
2.2.1 New items


2.2.2 Returning items


2.3 Status changes
2.3.1 New items

 o status-change-change-ipp-to-internet-standard-00  - IETF stream
   Internet Printing Protocol/1.1 to Internet Standard (None)
   Token: Alexey Melnikov

Amy: No discusses to this status change, so unless there are objections now it
looks like this one is approved. Hearing none, this is approved and we will
send it to the RFC Editor with the status change text in the Datatracker.

2.3.2 Returning items


3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-teas-actn-info-model-09  - IETF stream
   Information Model for Abstraction and Control of TE Networks (ACTN)
   Token: Deborah Brungard

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

Deborah: We'll do it again as Point Raised.

Amy: This will be Approved, Announcement to be Sent, Point raised, Writeup

 o draft-ietf-dprive-padding-policy-05  - IETF stream
   Padding Policy for EDNS(0) (Experimental)
   Token: Terry Manderson

Amy: I have an unknown consensus, Terry, should I mark it as yes?

Terry: Yes please, sorry.

Amy: Okay. I have a Discuss in the tracker. Do we need to discuss it today?

Terry: I think so, actually. I wanted to ask Ekr -- to be honest I'm quite
surprised the authors haven't jumped back on your Discuss. Given that there's
significant interaction with MTU size, maximal padding can't actually be used.
As experimental best effort, it's a block padding. so yes it's variable but
it's limited. So I don't believe it's trying to endorse random padding; it's
working with what we can work with. If you do maximal padding you're going to
hit up against the MTU size and you're going to fragment. It's kind of best
effort. I'm wondering what your thoughts are.

Ekr: Maybe I misunderstood. When I read this doc I thought it had a recommended
strategy in 4.1 which is this block length padding, which I think is
reasonable. In 4.2 it has this thing called Other Sensible Strategies, and
lists maximal padding, random length padding, random block length padding. So
it calls them all sensible, says maximal is not recommended, doesn't say
anything about random length, and nothing about random block length. What I'm
complaining about is that it endorses random padding and not ...

Terry: I see what you mean. Thank you for clarifying your discuss. I will
maintain that and ask the shepherd and authors to update the document pointing
out that those other two are in fact not recommended in the same way as 4.2.1
is not recommended.

Ekr: Do you want me to leave my discuss?

Terry: Leave your discuss and I'll follow up.

Amy: Sounds like that will require a Revised ID.

 o draft-ietf-sfc-hierarchical-09  - IETF stream
   Hierarchical Service Function Chaining (hSFC) (Informational)
   Token: Martin Vigoureux

Amy: Martin, I have a consensus unknown for you, should that be yes?

Martin: Yes, thank you.

Amy: I have a Discuss, do we need to discuss?

Martin: We can, but it's up to Benjamin.

Benjamin: The only thing it seems to make sense to talk about right now is if
we want to consider asking this to move to experimental. I don't have all the
background but with what I've heard so far it seems like this is laying out
some options that have not been deployed very much and we really do want to get
some extra experimental results to see how these things work, which have flaws,
which are better in which scenarios; and the conclusion of the experiment could
be to disrecommend some of these implementation options.

Martin: Personally I'm not opposed to that, but I'm wondering whether that
conflicts with other opinions that were expressed. Maybe there is not enough
information to start deploying one option for another.

Benjamin: Right. I guess the experiment would be to try out all these options
and the result might be to veto some of these, but we don't know yet.

Martin: I think Alvaro was saying some of the options we don't have enough
information to even start deploying or testing.

Alvaro: Its all very wide open, not specified. A lot of handwaving to me.

Martin: Benjamin, would changing the target in the status help clear your
discuss? Or are there more things?

Benjamin: That would help with at least one of the points in my discuss. The
first one, I think the authors provided an easy resolution. Moving to
experimental would help with the 2nd and 3rd points I made. The 4th one is
still a little unclear to me. You were saying just now that for some of these
options they're not even well enough specified to start deploying yet. I think
I would need to think about the implications of that some more.

Martin: Do you want to write .... I don't remember whether you explicitly
raised the option of moving to experimental to the authors.

Benjamin: I mentioned it almost in passing, the last sentence of one paragraph:
"Perhaps experimental status is more appropriate." I did not get a chance to
read their responses in detail yet.

Martin: Let's try to discuss that with them and see.

Benjamin: Sounds good.

Amy: So is this going to be a Revised ID needed?

Martin: Definitely. Thank you.

 o draft-ietf-ippm-2330-ipv6-05  - IETF stream
   IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric
   Framework (Informational)
   Token: Spencer Dawkins

Amy: I have a Discuss, do we need to discuss?

Spencer: I think we need to meta-discuss for a moment. Al has responded to
Suresh's Discuss since the telechat started, so that's a conversation that is
starting. He has I think a reasonable point about IPPM needing to be more
tolerant of things that are not standards compliant but exist on networks. He's
also raising the issue of the IPPM chartered work on in-situ OAM, having some
of the same issue with intermediate nodes with header extensions. I think
that's a conversation we're going to end up having to have before the In-situ
OAM material comes out of the WG. Suresh, do you have a good feel for how we
would want to do that? Is that an informal telechat, a Montreal meeting,
pistols at dawn?

Suresh: To be frank, every time I've brought this issue up I've gotten handwavy
answers without acknowledging the issues...I'm not taking a religious position
but I'm trying to be a nice person. Write it up, write how you do this in a
proper way. That has not happened. I would expect when the IPPM documents like
the in-situ OAM come true, I would expect that kind of discussion there. If
this can be made to work on the internet, say how to do it, otherwise say it's
only for private networks. put in an applicability statement that this is for a
private network. The reason I put this as a discuss is the doc actually takes
other cases of nodes mangling the packets. The 6lo and nat64, it talks about
how the packets get transformed and so on. As long as this document puts in a
thing that says this is how these packets are going to change and these are the
issues. As long as there's some kind of discussion about what the issues are
and how you plan to address them, I'm okay with it. 8200 doesn't use 2119
language and I'm unhappy about that. We don't have any restrictions in IETF
that we need to use 2119 language. But that's another discussion. This is
specifically because we couldn't find consensus on how we would actually safely
do this. I'm going to respond to Al. I think we can merge. Treat this like
another exception case and I'll take out the text. That would be enough to
resolve my discuss.

Spencer: The other thing for me to say is that IPPM is a WG that I've handed to
Mirja fairly recently and I'm taking the docs that were already in flight. I
think that means you can make me work harder on trying to get stuff like this
resolved if I'm not the responsible AD for IPPM. Please involve me in that.

Suresh: Sounds good, thank you.

Spencer: I would really like to get that worked out before IPPM requests
publication on the in situ OAM stuff.

Suresh: It's not like it's not workable. We know how to do encapsulation.

Spencer: We will do our best to do the right thing. Thank you for the clear
statement and for poking that particular bear on a doc where this is a
manageable discussion. If this doesn't end up as a Revised ID Needed I'll be
pleasantly surprised.

Amy: I'll put that into Revised ID Needed.

3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items


3.2.2 Returning items


3.3 Status changes
3.3.1 New items
3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-clausen-lln-rpl-experiences-00
   IETF conflict review for draft-clausen-lln-rpl-experiences
     Observations on RPL: IPv6 Routing Protocol for Low power and
   Lossy Networks (ISE: Informational)
   Token: Alvaro Retana

Amy: This has a Discuss, do we need to discuss today?

Alvaro: I think we do. Mirja, I saw the Discuss and sent email right before the

Mirja: I completely agree that it shouldn't be published. But I hope the ISE is
doing the right decision here. I don't think it actually has a conflict with
IETF work. It's related, but how does it conflict with IETF work?

Alvaro: Thats why I put in the response was that it could disrupt the work.
It's basically saying we don't think this protocol works.

Mirja: That's also a little bit what the ISE stream is for, right?

Alvaro: It doesn't say how it doesn't work because it doesn't provide details
on the experiments. To me it seems like this is not the first time it happens
with this group of authors, where they publish papers at conferences and then
come to the IETF to publish again.

Mirja: This is all understandable and it's not good practice. I hope the ISE
makes the right decision there. But I'm not comfortable saying there's a
conflict in the IETF.

Alvaro: What we're saying is it could potentially disrupt. The only options are
either it's related and it doesn't prevent publishing, or this one which is it
could disrupt and we recommend not to publish.

Mirja: I'm not sure if a even not very well written and already discussed in
the IETF experimentation report. It's a different case if you have a protocol
extension or a new protocol which got rejected, but an experimentation report
that's not followed on anymore in the IETF. If everyone else agrees this is a
conflict and that's the right proposal I will clear my discuss, but I have the
feeling it should rather be answered that it's related but it doesn't permit
publication. Hopefully the ISE will see all your comments and react.

Alvaro: We're seeing different sides of the coin here. I'd rather recommend not
publishing than just hope they don't.

Alissa: Even with the recommendation it is just a hope anyway. I agree with
you. I'm just saying that in response to Mirja's point, he still doesn't have
to do what we recommend. If it seems like it could be disruptive, this seems
like the right answer.

Mirja: The text says it could potentially be disrupted. If everyone else agrees
I can clear my discuss.

Spencer: That doesn't mean we don't understand what you're saying. What you're
saying made perfect sense to me.

Mirja: That reply is fine as well, I just wanted to have a discussion about it
to be sure.

Spencer: Conflict reviews are complicated.

Ekr: Mirja's point is right on some level. The IESG should have a relatively
expansive view of what conflict means. The question of conflict is, is this
going to screw up our work? If it's documents that don't conflict in a formal
sense but are going to disrupt our work, we should encourage the ISE not to
publish. I hear Alvaro saying this isn't actually going to override our
protocols, but it's going to screw up our work.

Mirja: The ISE will read Alvaro's comment and make a decision based on this
information. I don't know if people who just see this conflict reply and don't
have the context will understand why it's this way.

Alvaro: Hopefully no matter what response we give, they read the ballot. We can
ask them to put some statement in there but to paraphrase Adrian from another
conflict review, he said no one reads the boilerplate or IESG notes anyway.

Mirja: Which is a different problem.

Alvaro: Hopefully they not only see the boilerplate response but they actually
look at the ballots and even the other reviews. I also sent the review to the
authors several weeks ago and haven't received a reply.

Mirja: The thing about all those conflict reviews is basically how does Adrian
perform this? Does everything he gets ask for reviews, including conflict
review, or does he do a first look at the document?

Alvaro: I don't know exactly but I know there's a board that takes a look first
and he gets reviews from other people. In this particular case, Adrian was
actually the Routing AD when this doc was discussed in the WG six years ago.
There's always been conflict with the authors and Adrian recused himself from
this document. So Nevil is the one who's shepherding. I had a little discussion
with him about my review and the ballot. He thought it made sense and he wanted
to wait for the authors to reply and they haven't replied at all. So yes
there's some previous review before they get to us, and hopefully more
discussion after.

Suresh: What we put in here is a recommendation from the IESG. The ISE
sometimes goes ahead and publish anyway. He's not bound by our response. I know
there are cases of that happening.

Warren: There was a doc on the agenda which got pushed, the YETI. We don't add
notes that seem opinion, or we don't ask the ISE editor to add things which are
opinion. I admit I don't like the Yeti experiment but I'm concerned we might
end up doing .... (audio cut out)

Spencer: I had a side conversation with Adrian just before the telechat. I
think having a discussion about that would be fabulous. It's not totally
obvious from our procedures when we should be proposing an IESG note. Does that
go back as part of the conflict review response, or do we basically say this is
the conflict review response and the ISE says okay, in that case we need this
note. This document is done once we send the conflict review back. I think
having a conversation in Montreal on this could be brilliant.

Suresh: If I understand your concern correctly, Warren, you don't want us to do
the note? I think it's part of the process, because we have a technical
opinion, right?

Warren: Specifically for the Yeti one, it feels as though it's coming close to
our personal opinions on documents.

Alissa: Why are we having a discussion about the Yeti one right now? Didn't we
defer it so that we could avoid this?

Warren: Yes, that's true. Let's discuss it at the next chat then.

Amy: We've approved the 'please do not publish.' I have that the Discuss has
been cleared and we can move on with that. This is the approval of the 'do not
publish' with the note that's currently in the tracker.

 o conflict-review-mavrogiannopoulos-pkcs8-validated-parameters-02
   IETF conflict review for
     Storing validation parameters in PKCS#8 (ISE: Informational)
   Token: Eric Rescorla

Amy: No discusses, so unless there's an objection, it looks like the conflict
review message can go back. There's some in there just for you guys and ... The
note that should be included is that this document extends an IETF protocol in
a way that requires IETF review and should therefore not be published without
IETF review and IESG approval. We'd just remove the meta bit at the top there.
Is that right, or do you want the whole thing?

Ekr: I request some guidance from my friends here. The two pieces of context...

Mirja: Just put it in your ballot position.

Ekr: The other thing is that Adrian has apparently already read this and
emailed SECDISPATCH. So I don't know quite how it's going to shake out. I think
we should still send this.

Mirja: This was never presented previously in SECDISPATCH?

Ekr: Not to my knowledge, no.

Mirja: Did you say the authors already agreed to take it to SECDISPATCH?

Ekr: No, the authors emailed SECDISPATCH and asked them to comment on it.

Benjamin: Because SECDISPATCH didn't exist until a couple months ago. My take
is the authors originally came to IETF, presented at SAAG and got feedback, but
there wasn't a good place for them to publish in IETF so they went to ISE. Now
that there is a good way for them to publish in the IETF, we're inviting them
to take that route because we think it would be better through the IETF. But I
sympathize that it's an implementation detail that could be done outside the
IETF. I'm a little torn.

Ekr: It's a definition of semantics. It's a protocol.

Benjamin: It's in OID that anyone can assign...

Ekr: If they want to publish on their own website, go to town. But the document
as an RFC, to create confusion of if its an IETF thing or not.

Mirja: I think the conflict response as written is appropriate and ISE can
decide whether or not to publish.

Ekr: If people are happy with that I can take my part out and put it in my

Mirja: Makes sense to me.

Benjamin: It does seem like the best option.

Ekr: For the record I think both of these are revealing that there's a string
we're supposed to send back to the ISE, but needs commentary, and we don't seem
to know how to do that.

Alissa: But the commentary always goes on the ballot.

Ekr: The commentary in this case is that it;s the opinion of the IESG, not the
opinion of me.

Alissa: That's a problem with us being limited to canned responses.

Mirja: It's also not really an opinion, is it? It's advice.

Alissa: It says "I."

Ekr: I'll put it in my ballot. We can deal with this question if the ISE
continues to exist and publish RFCs.

Alissa: I would defer all of this high level discussion.

Suresh: One thing you could do is to put it in passive voice.

Ekr: I will do that.

Amy: Whether the conflict review message gets edited again or not, we're going
to send the 'do not publish' with this 'please bring this work to us' message.

3.4.2 Returning items


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


4.1.2 Proposed for approval


4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval


5. IAB news we can use

Deborah: Nothing I can think of right now.

6. Management issues

6.1 [IANA #1113496] Designated expert for RFC 6143 (Alexey Melnikov)

Amy: Alexey has suggested John Levine as the expert. Unless there's an
objection, it looks like this one may be approved. Hearing none, this is
approved and we will send the official note to IANA.

6.2 [IANA #1113497] Designated experts for RFC-ietf-oauth-discovery (IANA)

Amy: We discussed this at the top in action items.

6.3 [IANA #1113095] Designating new team leader from current URN Namespaces
expert pool (IANA)

Amy: Adam said that Peter Saint-Andre had agreed to be the new team lead.
Unless there's an objection now, it looks like this is approved. Hearing none,
this is approved and we will send the official note to IANA.

6.4 Change of Change Controller for port 631 (service "ipp") (Alexey Melnikov)

Alexey: Authors of the original RFC agreed that they represent the IEEE group
responsible for printing and they agree the IESG should be the change

Mirja: The person currently listed in the registry is not reachable anymore.

Benjamin: For the original address, is it that the email bounces and we've also
tried to reach the human?

Alexey:  It was somebody from Xerox. The port number is documented in two RFCs.
 I think the IESG is the right thing here anyway.

Benjamin: I also think so, I'm just wondering if we've done our due diligence
to find the original person to have them also authorize the change.

Mirja: The question is also if we have to do that. This came originally because
the new chairs, who are also the authors of the updated RFC, requested to
change the change control to themselves, and then we suggested the IESG and
they agreed.

Warren: Even if we don't have to have to do it, it seems like it cuts down on
potential liability issues in the future and is also a polite thing to do.

Mirja: It's kind of related to the port cleanup. It's 2 different things, who
is the original assignee and who is the change control. It's kind of mixed up
at the moment and probably should separate those things. We can put it in the
draft but it still needs an RFC to be published to make that change. The
current version of the draft says the original assignee should still be noted
in the notes to have it on record.

Alexey: So are we changing our recommendation to the original assignee without
email address and change control to IESG?

Mirja: We don't have a row in the table that says change control. That's kind
of the problem.

Michelle: In the port registry you do have two fields, registrant and contact.

Mirja: But they're supposed to be together, right? If not we can do that as

Benjamin: It seems pretty likely that if we tried to find the original person
we would succeed in contacting them.

Mirja: He might have reliability issues but we also should think about how much
effort to go into to contact him.

Benjamin: I don't want to insist we go through these huge efforts.

Alissa: I found his LinkedIn profile in 15 seconds, so it wouldn't be that much
effort. But it's not like we need to wait and see if he responds or anything.

Mirja: I guess if we publish the cleanup document we will have a number of
cases where we will not reach anybody and this will come up again. Fr this
case, the recommendation is to contact the original assignee once again and if
we don't get a response we get it back.

Benjamin: Make the additional attempt to contact the original assignee in
parallel with going ahead to make the IESG the change controller. Inform them
that we are in the process of changing this, and if you disagree we can revisit.

Alissa: That seems reasonable.

Alexey: This is a test case for our future bulk changes, so we might as well
try it. Can you add an action item for me to do this?

Mirja: Is it you or IANA?

Michelle: Is the action item reaching out to the current contact? I'll do that.

Alexey: Thank you.

Mirja: How long do we wait for a reply?

Michelle: Maybe 2 weeks?

Mirja: Fine for me.

Amy: So If we're going to wait 2 weeks for a possible reply from the current
listed contact do you want us to add this to the agenda for July 5 to check

Alexey: Let's do that, thanks.

6.5 [IANA #1113903] Designated experts for RFC-ietf-uta-smtp-tlsrpt (IANA)

Amy: We have assigned this to Alexey and it's on the outstanding tasks list.

6.6 Proposed Telechat Dates between IETF 102 and IETF 103 (IESG Secretary)

Amy: We really couldn't come up with a second proposal; it very clearly falls
in a pattern. Any questions or objections to this telechat schedule? Hearing
none, these dates are approved.

6.7 [IANA #1112792] Designated experts for RFC 4681 (Amanda Baber / IANA)

Michelle: For 6.7 you mentioned Benjamin was working on that but that's the one
where we already have 3 names because it's a TLS registry. Can we just approve

Amy: Yes, sorry. You have Yoav, Rich, and Nick listed as experts for other TLS
specification registries and you want to add them to this one? Hearing no
objection, this is approved.

6.8 [IANA #1114238] Designated experts for RFC-ietf-extra-specialuse-important
(Amanda Baber / IANA)

Amy: IANA added this but I believe Alexey has updated it with two experts.

Alexey: The latest version is both Barry and Bron.

Amy: Is there any objection to appointing Barry and Bron as the experts?
Hearing none, we will send the official note to IANA.

6.9 IANA #1112387] Management Item: Correction in the tsig-algorithm-names
registry (IANA)

Amy: We're looking for advice, correct?

Michelle: Alexey has suggested that we go ahead and make the correction, but I
didn't know if the IESG agrees with that. There's also an errata report that
was filed and is currently held for document update. I don't know whats
happening with that. We would like advice on whether we should just go ahead
and correct the registry.

Alissa: That seems fine.

Alexey: If people are using names from the registry I think it's better to have
it corrected because it's an obvious fix.

Amy: Do you need an official note or are you good with the instruction?

Michelle: A note back just saying to go ahead and update the registry would be
great. Usually when we fix a registry that pertains to an errata we put a
reference in pointing to that errata, so it would be great if there was some
type of movement to fix it so we could move on.

Alice: Would you like me to change the status to verified?

Michelle: That would work. We could point to that so people know where the
correction came from.

Alice: Typically when the IANA registries point to an erratum the erratum is
verified, correct?

Michelle: Yes that's correct.

6.11 Proposed Designated Expert for "SenML Units" and "SenML Labels" registries
(Alexey Melnikov)

Alexey would like to approve Ari Keranen as the designated expert. Any
objection? Hearing none, this is approved and we will send note to IANA.

6.12 IESG approval of .well-known allocation from draft-ietf-uta-mta-sts
(Alexey Melnikov)

Alexey: We talked about this, the document got approved. The rules for the
registry are changing but I don't want to hold this doc until the updated rules
are approved so I'd like an exception.

Adam: That sounds reasonable.

Benjamin: We informally talked about doing this previously, if I recall

Amy: Hearing no objection to approving the exception. What exactly does that

Alexey: Basically instead of approving a designated expert according to current
practice it's IESG exception. So we just need to tell IANA it's approved based
on IESG exception.

Michelle: Amy, you can just send that to and when it comes in
we'll merge it with our open ticket.

Amy: Basically it's sending an official note saying the IESG has approved this

6.10 IETF 102 Agenda Conflicts (Liz Flynn)

[Discussion of IETF 102 agenda conflicts not minuted]

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