Narrative Minutes interim-2019-iesg-03 2019-02-07 15:00
narrative-minutes-interim-2019-iesg-03-201902071500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2019-02-07 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
Roman Danyliw (CERT/SEI) / Incoming Security Area
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
Barry Leiba (Huawei) / Incoming Applications and Real-Time 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
Jeff Tantsura (Apstra) / IAB Liaison
Martin Vigoureux (Nokia) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Incoming Internet Area
Magnus Westerlund (Ericsson) / Incoming Transport Area

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

OBSERVERS
---------------------------------
Mehmet Ersue
Greg Wood

1.2 Bash the agenda

Amy: Anyone have anything to add to thee agenda? Any changes? Great, we'll move
on.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the January 24
teleconference being approved? Hearing no objection, so those are approved and
we'll get those posted. I also saw narrative minutes; any objection to
approving those? Hearing no objection, so those are approved as well.

1.4 List of remaining action items from last telechat

Amy: The first four here are a management item at the end of the call so we
will mark them as provisionally done.

     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 send email to the IESG with proposed re-labeling of
       scheduling conflicts.

Alvaro: I've been making progress and talking to the Secretariat.

     o Suresh Krishnan to discuss naming experts for the registries created
       by draft-irtf-icnrg-ccnxsemantics with Allison Mankin.

Suresh: I did have that conversation and I think Allison is leaning towards the
RG chairs doing it, but she's asking IRSG chairs for input. Keep it in progress
for now but she's leaning towards the RG chairs recommending experts.

     o Alissa Cooper to send a message to the community about plenary
       transcripts for the Q&A sections of the plenary (IAB, LLC Board, and
       IESG).

Amy: I saw this email so I believe we can mark this as done.

Alissa: Yes, thank you.

     o Ben Campbell to write up text on the IESG's expectations regarding
       conflicts of interest and the disclosure of funding sources.

Ben: That one is still in progress and my next one is done.

     o Ben Campbell to send the email on what updates means to the IETF
       Community.

     o Warren Kumari and Spencer Dawkins to develop the spherical routing
       topic.

Warren: Still ongoing; we're making progress and meeting every Friday morning
to discuss it. If anyone else is desperate to join, let me know.

Amy: Should we keep this as in progress since it's an ongoing topic?

Warren: Sure.

     o Deborah Brungard to summarize the discussion with the WG chairs on
       community relations and escalating issues.

Amy: I saw this so I think this done, right?

Deborah: Yes, this is done.

      o Suresh Krishnan to draft a new proposed IESG Statement on the
        procedure to reference material behind a paywall, that includes the
        existing text and adds comments from the discussion, Eric Rescorla,
        and Barry Leiba.

Suresh: I haven't gotten to this yet.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-pce-wson-rwa-ext-12  - IETF stream
   PCEP Extension for WSON Routing and Wavelength Assignment (Proposed
   Standard)
   Token: Deborah Brungard

Amy: I have a number of Discusses in the tracker; do we need to discuss those
today?

Deborah: I just added that because Michelle requested it. I don't know.
Discussion is going on on the list, so unless Benjamin has something specific I
think we should just keep discussion with the authors.

Benjamin: Keeping it on the list sounds fine to me. Unfortunately I have not
gotten to read the response at all, so I think I have an action item for that.

Deborah: Okay. And Benjamin, thank you very much for your very detailed
analysis.

Amy: So it sounds like this is going to require a Revised ID?

Deborah: Definitely Revised ID.

Amy: Thank you, we'll move on.

2.1.2 Returning items

 o draft-ietf-lisp-rfc6830bis-26  - IETF stream
   The Locator/ID Separation Protocol (LISP) (Proposed Standard)
   Token: Deborah Brungard

Amy: I have a couple of Discusses in the tracker; do we need to discuss any or
all of those today?

Deborah: Again, I'd say I prefer to let the discussion continue with the
authors and chairs, but if there's anything in particular anyone wants to
discuss we can do it now.

Benjamin: I guess I will just express my sentiment that it's pretty frustrating
to have explicit concrete points in the discuss ballot text and have an email
discussion that we agree to change them, and then have the document come back
with that exact text still in place.

Deborah: I can understand. It's difficult because there were a lot of threads
and some of them, the authors asked if this was good enough and to please
acknowledge. I don't know if that's the one you were talking about but they
didn't get a response. I told them to   stop revising and constantly uploading.
One of them is up to 29 versions now. It was probably a miscommunication.

Benjamin: I definitely understand it's frustrating all around.

Deborah: I think we have to nail down which ones have not been addressed and
why. I told them not to upload any more, just get the text and do an
acknowledgement and we'll do one big update.

Barry: There are certainly times when you want to hold back updates but just in
general, if we're on 29 versions so what? I personally would rather see the
update and if it's not quite right they can be updated again. Updates are cheap.

Alissa: In this case it didn't help, actually. Batching them together into a
larger set of changes would have made the reviews easier and would have made
the load on ADs trying to re-review less.

Deborah: I agree with you Barry, but this one is a special case.

Barry: I've got you. I didn't review this one. Sorry to interrupt.

Warren: I usually agree with Barry but this is a special case. At this point
everybody is really frustrated with the document and it feels like suggestions
that are being provided to make the document more useful are being dismissed.
There are a lot of things where providing two or three words of guidance, like
"most implementations have turned this off because it's easy to shoot yourself
in the foot with it" are getting a [reaction of] "implementers can work it out
for themselves." I currently have a Discuss and I don't know if holding it is
going to improve the document any more. Comments are being addressed but it
doesn't feel like they're being addressed in a way that's making it easier for
interoperability or easier for implementers, they're being addressed so ADs
stop asking for changes.

Deborah: Your comments were at the end here and I'll have the authors look at
them more because they're very good comments. I think everyone has been
spinning their wheels trying to get Mirja's and Benjamin's included.  We will
take a look at it.

Warren: I think everyone's just frustrated at this point and I fully understand
that.

Alissa: I wanted to ask about the dependencies on LISP-SEC and the map
versioning documents and what the plan is going forward for these. Is the
expectation that all four of those will come back again on one telechat or do
you think there's going to be further email back and forth to resolve the
concerns on these? I know I'm generalizing both of the ones on the telechat. Do
we think we're going to have all four of them come back together or will the
discusses on these be resolved over email?

Deborah: I'm hoping we can resolve them over email. These are the two core
documents so they're just waiting to get them there. Hopefully we don't have to
bring them back on a telechat.

Ekr: I'm pretty uncomfortable approving a document that has a dependency on
security properties on some document which has an unspecified date of approval.
Unfortunately because of the way these things are designed they're not
orthogonal, so I'm not sure how to proceed there.

Deborah: What's often done with a lot of routing documents is it's really an
extra bit if you're supporting the security or not. So it's really independent
that from these documents. And what they did do for you because you were
concerned is they did put that it's mandatory to implement. But the bit is
there so folks that don't want to implement it, they don't have to. It's
mandatory to implement but it's optional to actually do it. And the document
was made so it's really independent of these documents. If you really look at
how it's done now, they're purely independent. And it's the same with the
mapping. The mapping one is an optional capability, the map versioning. These
documents are really independent.

Benjamin: I have to disagree with the claim that they are independent. I'm
going to give two examples and then shut up. For the list security, depending
on how LISP-SEC itself goes it's decently likely you'll need an authenticated
signal of downgrade, that ITR wants to use LISP-SEC and ETR doesn't. With the
current way things are set up, if you try to do that you just fail to
communicate entirely. You would want an authenticated signal to the ITR that it
should try again without LISP-SEC and in order to do that I believe you will
probably want to make a change to 6833. The other example I have is with
versioning, where you've got the information in 6830bis about the locator
status bits and if the version information changes, the way you interpret those
status bits is also going to change, if I understand correctly, so it's
plausible to me that the way the versioning stuff is going to play out might
make some changes to 6830bis. So to say there's a clear isolation between the
documents is not something that's clear to me.

Ekr: I agree with that. If people want to have that, then these documents need
to state extremely clearly what they believe the properties of the allegedly
orthogonal thing is so we can review against that interface boundary and then
again on the other side. It's not clear to me that a mandatory to implement but
not mandatory to use security mechanism actually meets the Proposed Standard
bar at this time. I understand that in many cases we approve routing protocols
that are historic and for technical reasons cannot operate in a secured manner,
but this seems to be a situation where they absolutely can operate in a secure
manner and I don't understand why it can't. That the IETF in 2019 is going to
approve a routing security protocol with midrange security strikes me as
dubious.

Deborah: We've done approvals of other documents where we have exactly the same
approach.

Ekr: But those are documents that were either extensions of historical
documents where we decided not to force retrofitted security, or they were
documents where there were technical arguments presented of why security could
not be provided and I've seen neither of those cases here.

Deborah: This was taken back to the WG and the consensus was that they agreed
to do the mandatory to implement, but it had to be optional whether or not it
was actually used.

Ekr: This is an IETF consensus document, not a WG consensus document. It's a
question of what the IETF consensus requirements are.

Deborah: We'll continue to discuss it. This is not how we in the Routing area
view that we have to always implement and deploy security.

Ekr: I'm not espousing that position, I'm saying I think in the past when we've
agreed not to implement security there have been technical reasons why the
security is difficult to implement and I'm unaware of any such reason in this
case.

Deborah: So possibly what we could do is come up with some text to explain the
tradeoffs and the use cases to say why they feel that way.

Ekr: That would be useful.

Deborah: That's how we've gotten around it before, we say this is a closed
environment and we're not going to force anybody to implement.

Spencer: For what it's worth we did the same thing right after I became an AD,
where we had these screaming matches about congestion avoidance and the key
thing seemed to be describing: what's the deployment scenario where this is
going to be used, and if there's more than one, how do the congestion control
considerations differ between them? We've been doing that for four or five
years now. That was an early point that I saw made in someone else's ballot,
which is that this doesn't seem to be intended for deployment at internet scale
but the documents don't reflect that. Am I hearing what I thought I was hearing?

Ted: In terms of the document not reflecting it, I think if you go back and
look at the charter, it says very much the opposite of that. It in fact calls
out the need for review by security experts I think in part because of the
intention of at least a part of this community to deploy this as widely as
possible. In the charter there is no charter text which would justify a claim
that this was intended for deployment only in limited environments or without
security.

Alissa: As far as the limited environments go, we are at the point where the WG
authors and IESG are all agreeing that is the scope for this. I thought we had
already gotten to that point.

Ekr: I think we have but I want to distinguish between the limited environments
in terms of how many people are involved and limited environments in terms of
the network environment in which it is deployed. My understanding was that it
was a closed system and it wasn't internet scale, but that doesn't mean it's
not run over open networks. The security considerations are tainted the minute
the network isn't secure, not the minute that it's an internet scale system.

Deborah: In the beginning of the document it says if you're doing this outside
of a closed environment, that's why it's mandated for the vendors to support
the security, but for the deployment it's for the operator to decide. We do
have the appropriate text there. The document describes the different
scenarios. I think we need to have text added to scope it.

Ted: I think you may have added it to just the specific docs in front of you,
but the charter still says out loud "hence the LISP technology is applicable in
both data centers and both public internet environments." I think somebody
coming to this work at this stage where these two pieces are not done, it may
very well run into the problem Ekr is posing here.

Deborah: We've added text to these documents to scope it but we can look at it
to see what more has to be done.

Warren: I hadn't clearly seen anything narrowing the scope to this, so it
seemed wider. That seems to be a thread running through a lot of this
discussion, that the authors have been doing it for a while so they're not
viewing it through the eyes of someone interested in deploying it who's reading
the document and has open questions. There seems to be a fair bit of: we
discussed this a while back and people should know it. There are a couple of
instances where it points to something in the mail list archives, which is cool
if you've been involved with LISP development, but if you're new to it you
don't know. Examples of this include things like all implementations have this
option turned off. Why don't you mention that? Well, it says it's optional,
that's the same thing. I think this could do with a read with fresh eyes.

Deborah: I think for your comments we need to look at it and see what we can
add. It's no different than the wavelength one we just finished; Benjamin's
different pair of eyes really helped to add some clarification. We should
definitely be including that type of text, there's no reason not to. I've been
following every email but if you feel your comments aren't being looked at
twice let me know.

Benjamin: So if we could jump back to the security impasse topic, one thing we
will frequently do to work around the impasse is to switch the focus from the
technology to the properties. An example would be with the one-time keys that
are used in the list control plane. We have this property where the
confidentiality of that key needs to be preserved in transit between the ITR
and the map resolver and again between the map server and the ETR. If we could
just flat out say there's a requirement for the confidentiality of this
material, that leaves it open for the operators to say that requirement is met
by the physical network and then we also provide a technology mechanism that
would enforce that confidentiality even if the network itself is not secure.
That generalizes to all sorts of security properties we require from this sort
of technology.

Deborah: That would be great. I think that's a perfect way to say it. Mirja was
commenting on the MTU size, and of course the LISP group doesn't want to say
that everybody has to have these minimum message sizes, because you'll never be
able to transfer anything. The worst case scenario. So we came up with some
wording to say that's only if the deployment operator is uneasy and doesn't
know what the MTU size is. We can go in and provision MTU sizes on equipment
and we don't want to be doing that every time. We have to put the right context
there.

Mirja: I hadn't had a chance to reply yet from a technical point of view. The
comment was on the LISP control packet, so packets that are rather small
anyway. I assume most of the control packets are smaller than the main MTU so
it can be restricted. It wasn't meant for the tunneling part because those are
different documents. I would double check the text and send feedback.

Deborah: If you all could try to propose some specific text I think it helps a
lot; otherwise the authors don't see what it is they should be adding.

Mirja: Coming back to the beginning of the conversation, I find it frustrating
they said they couldn't do it instead of trying to figure out if there was a
solution. That's why we went back and forth a lot.

Deborah: So this one definitely remains in IESG Evaluation and revised ID
needed.

 o draft-ietf-lisp-rfc6833bis-24  - IETF stream
   Locator/ID Separation Protocol (LISP) Control-Plane (Proposed
   Standard)
   Token: Deborah Brungard

Amy: Did we just discuss this document in conjunction with the last one or are
there new thoughts?

Benjamin: I do have one new thought. For a technical perspective on the crypto,
this is having a scheme that has a long-term pre-shared key directly to key the
protocol level cryptographic operation and we have this BCP 107 that suggests
you should be using a key derivation hierarchy so you have a shorter lived key
that's being used for the actual on the wire cryptographic message protection.
I don't really want to be a hardass and say you need to change this before we
can publish it all because that's not very fair to them, but it does seem like
we should have a path towards complying with the BCP. I don't have a good sense
for do we want to just talk about this now and maybe there's going to be a
document in the future, or do we want to try to get some actual concrete work
started on what the new mechanism would look like.

Spencer: Let me ask the dumb question, which is the common theme on all this
stuff has been that someone says something and someone else says "yes that's
true, but." For what Benjamin just said is pointing out in this document that
the BCP says they should be doing something else, so the people who read the
document have the benefit of what Benjamin just said instead of having to
figure it out on their own. Is that at all helpful?

Benjamin: It seems helpful to me.

Ekr: It's helpful, but I'd like them to do the right things. We write these
documents for a reason and it's like a should - you'd better have a good reason
not to do it, so what's the good reason?

Deborah: They may not be aware, and they just need a sentence to say how it
should be. I don't see any reason you can't add a sentence to say it should be
considered.

Spencer: And I'm not saying doing the right thing is the wrong answer.

Benjamin: To jump on that, adding a sentence is helpful but it doesn't mean we
need to stop at adding a sentence.

Ekr: I would like to float again that the easiest way to resolve these issues
would be to recycle this document as experimental. There's a vanishing level of
widespread interest in using this document and we could simply say we are
willing to live with the security properties if we use this as experimental, so
I suggest the authors reconsider that.

Deborah: The difficulty with that is I think all of these problems are coming
about because these documents have been experimental for way too long. When I
took over this group four years ago, I said why are you having experimental
documents going on with lifetimes of five, six years? Either the document
becomes PS or it doesn't. It might as well go away. The problem with
experimental documents is you have people out there using this and it think
we're doing a disservice to them keeping these experimental documents out there
so long. I think this should either go PS or maybe we put it over into the
independent stream. It's wrong for IETF to have these documents just hanging
there. We should do our due diligence, get them up to PS quality so people have
something to go on.

Ekr: I'm not familiar with how much ["interest" or "deployment", muffled] if
there's a lot them presumably we can do something. What I'm trying to avoid is
an enormous amount of back and forth on these security properties for something
that doesn't have a lot of deployment.

Deborah: I think it's really important we get these cleaned up. Why should
people use an experimental protocol? I think we should do our best and get
these on the PS track.

Ted: I think the point is you and Ekr are having a fundamental disagreement
about what it means to bring it up to PS quality. Ekr's point, and one I
personally agree with, is that to bring it up to PS quality in 2019 actually
means to bring up the security properties to something that actually is
deployable appropriately in whatever environment is being described. If there's
a fundamental disagreement on what that is, then there's a reality check about
whether the WG can bring it up to PS quality in the way the IETF currently sees
that.

Deborah: I think right now we're getting really close. Let's just see if we can
hammer it out, and if it takes another sentence to say they should not be using
long term keys we can put that there. It's really important to scope these so
people understand when they read it why they shouldn't be using them. I think
we're really close so let's just see if we can get there and if we can't let's
figure out something else to do with these documents. I think it's wrong to
have them hanging out as experimental.

Ekr: I'm certainly happy to spend more time on this. I'm perhaps less sanguine
that we're really close on this.

Deborah: Okay. Thank you, everybody. Definitely this also stays as IESG
Evaluation, Revised ID Needed.

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-rmcat-video-traffic-model-06  - IETF stream
   Video Traffic Models for RTP Congestion Control Evaluations
   (Informational)
   Token: Mirja Kuehlewind

Amy: I have no Discusses in the tracker, so unless there's an objection now it
looks like this one is approved. Hearing no objection. Are there any notes
needed for this version?

Mirja: Please put it in Point Raised. There are a couple of comments that need
either a note or a new version but I don't know yet.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-gutmann-scep-13  - IETF stream
   Simple Certificate Enrolment Protocol (Informational)
   Token: Alexey Melnikov

Amy: There are a few Discusses in the tracker; do we need to discuss any of
those today?

Alexey: I think this needs to be discussed on the mailing list. It will
definitely need a new revision. If people think we need to discuss anything,
let me know.

Adam: The one thing I wanted to bring up because it requires IESG approval is
that this document talks about a handful of out in the field, been used for a
long time media types that are unregistered and they are application/x-. The
registry allows them to go in for legacy uses like this but we do need IESG
signoff. I just wanted to check if anyone would object to approving four or
five mime types in here under the application tree.

Alexey: I think I made the same argument and I wanted to register them but I
got pushback from the editor. Maybe he's changed his mind.

Adam: Well regardless of what the editor wants to do, registering anything that
is application/x- requires IESG signoff. That's why I wanted to make certain it
was explicitly raised on the call.

Alexey: I would be happy to do that.

Adam: Thanks.

Alexey: The document is slightly worse because it's using x- version of media
types which are already registered as well. I think there's one of them. I
asked why it's not using the already registered one.

Mirja: I have a quick question on the status, because I didn't see the
discussion on a mailing list. My understanding was that this was proposed as a
Proposed Standard and now it's Informational. Was it ever discussed to publish
this as Historic?

Benjamin: My recollection is that it was, but I do not have a link I can point
to to support that.

Alexey: I think it was.

Mirja: Because I think historic is the right status for this document.
Otherwise it should be explained clearly in the abstract and introduction that
this is not meant for deployment or for endorsement, only for documentation
purposes. I think historic would be right.

Benjamin: Again, my unsubstantiated recollection is that there was a claim
there were ongoing and existing new deployments where they are continuing to
use this.

Mirja: I see. But from your discuss it sounds like we've been expecting the
next version of this document.

Alexey: Yes.

Mirja: I'll wait for that.

Alexey: Thank you.

Alissa: Just one note on my comment. I think there's a difference between
putting some text up front in the introduction, and I understand the author
says this has been done many times and taken in and put out, and the question
of whether the standard boilerplate actually applies here. The standard
boilerplate will say this is the product of the IETF and represents the
consensus of the IETF community. To me, if the consensus is that we wanted this
to be published but we didn't want people to design their protocols this way,
that's kind of different from what the standard boilerplate would say. So I
think there are 2 questions, one is if this document should say something up
front about the general unfitness of some of the design decisions, and the
other question is about the representation of the consensus.

Ekr: I'm somewhat enthusiastic about removing the boilerplate. My complaining
in the discusses is about statements that cut against other IETF consensus
statements.

Alexey: So is your suggestion to move this to no consensus boilerplate and
possibly add more text explaining why?

Alissa: Yes. That's basically what I put in my comment.

Adam: That sounds good to me as well.

Alexey: I'm happy with that. Can you suggest some specific text? That would be
very helpful.

Alissa: Yeah. It's almost there in my ballot, but I can write it up.

Alexey: Then at least I can hammer on it a little. Okay, I think this will need
a new revision.

Amy: Okay, this will stay in IESG evaluation with Revised ID Needed.

 o draft-op3ft-leaptofrogans-uri-scheme-06  - IETF stream
   The 'leaptofrogans' URI Scheme (Informational)
   Token: Alexey Melnikov

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

Alexey: I don't think so. I think the last response from Alissa is very
sensible and we'll see how the editors reply to this. Just a general comment in
regards to documents that have URI registration; I actually started a
discussion with Adrian about getting some kind of agreement to publish URI
registrations which are not necessarily IETF consensus in ISE stream and I
think we have some kind of agreement with him. So this will never happen again,
hopefully.

Amy: Is it going to require a Revised ID?

Alexey: Yes, thank you.

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

 o Remote ATtestation ProcedureS (rats)

Amy: I have a block on this. Do we need to discuss that today?

Benjamin: I don't think we really need to discuss that today. There seemed to
be some good comments and I apologize for not participating on the email
discussion yet; I was pretty busy wrapping up my comments on the other
documents on this telechat. I think we can work on these comments over email.
From a procedural point of view, if we do make a change to the text that
resolves the block, then we can have the Secretariat send it to external review
without having it back on the telechat? Is that right?

Amy: That is correct. We can say we are waiting for instructions from you;
basically the pending edits state. We will wait to hear from you and we'll move
on. Thank you.

4.1.2 Proposed for approval

 o GitHub Integration and Tooling (git)

Amy: I have no blocks for this charter, so unless there's an objection now it
looks like this WG has been approved for action.

Alissa: Thank you.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Multiparty Multimedia Session Control (mmusic)

Amy: I have no blocking comments. Unless there's an objection now it looks like
it might be ready to just make the changes in the charter. Or does anyone feel
like it has to go for external review?

Ekr: I just object to the change, but I guess I'm willing to admit I'm in the
rough.

Ben: If I understand, your objection is that MMUSIC doesn't have the right
expertise to work on this but in reality, the people who were in ICE tend to
also go to MMUSIC.

Ekr: This has nothing to do with SDP.

Ben: Well, it has historical roots in MMUSIC. For the most part we don't know
if there's going to be any actual work associated with this anyway.

Ekr: Then let's not do it at all.

Mirja: Why don't we keep the ICE group around for a while longer?

Ben: Because there's no energy to keep the group open and the chairs want to
stop.

Ekr: My point would be, let us not do this and if somebody says they want to
work on ICE we can return to it at that time, or start a new ICE working group.

Benjamin: You mean close ICE now, and not change MMUSIC?

Ekr: Yes.

Ben: This was discussed in MMUSIC and the WG wanted to do this. Obviously if we
don't think they should, that's a different thing entirely. But the way this is
worded, this is maintenance. If there's anything substantial that comes
forward, that would need to be addressed separately anyway. The kinds of things
that would show up here would be trivial things not worth opening up a WG for.

Mirja: In Transport we have the Transport WG where anything that doesn't fit
anywhere else or belongs to a closed WG just goes there automatically without
rechartering.

Ben: We expressly don't have a catchall work group in ART.

Magnus: I would disagree about the TSV WG, I don't think the charter is fully
open for anything, but it's definitely the place to start the discussion for
anything which doesn't have another home.

Ben: I'm sorry Magnus, I didn't hear which WG you mentioned?

Magnus: The Transport WG. In this matter I think either rechartering or not is
probably fine. In some degree I think it equally belongs to Transport and ICE
depending on what that chartering item becomes, so there is actually a point to
wait for chartering until we know.

Mirja: I don't have a strong opinion here but I also thought TRAM could be
another candidate, a WG that probably will be closed soon.

Ben: And I think those things would all make sense if we were talking about a
significant change or update to ICE instead of just maintenance.

Mirja: But then maybe the proposal Ekr did is better; don't change the charter
and wait until we get something.

Ben: Is anyone willing to put in a block over that? Because the WG did discuss
this and was interested in doing this.

Ekr: My position was that I didn't think it was helpful for me to stand in the
middle of the road if everyone else disagreed with me; if people in fact agree
with me and there's a formal need for me to file an objection I'm happy to do
so, but I don't want to be a jerk for no reason.

Ben: Let me characterize the discussion; there was some discussion about
whether it was required to put anything in here at all. The MMUSIC WG discussed
this in Canada and wanted to put it in. I'm perfectly happy to go back to the
WG and say maybe we don't need to do this, but that's already been discussed.
If we as the IESG think we should say no you can't do this, that's fine. It's
not a huge deal and I don't think makes any difference. It's just a matter of,
are you sure about this? They've already discussed this.

Mirja: Knowing now they don't have a concrete action item they want to work on,
I'm slightly tending towards not adding it to the charter at this point in
time. But I don't think it's a big deal so I wouldn't want to block it, I leave
that to your decision. I'm a little bit worried that putting it in without
knowing what will come up in the future opens up a discussion when something
comes up that shouldn't be in MMUSIC.

Ben: Why don't we keep this in whatever the equivalent is of Point Raised and
I'm going to have a discussion with the MMUSIC chairs one more round and see
what we come up with.

Amy: We'll just wait for instructions from you, Ben.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Deborah: I don't think there's any news this week. They're still busy
discussing plenary planning.

Ted: A couple of things I would add to that. It doesn't look like the IAB will
be able to co-locate with the IESG for our retreats. The first round of
discussion of whether or not the week you've picked will work yielded two
people who have probable conflicts for that week. We're going to run a Doodle
to see if there's another week that will be better.

Alissa: I'm sure the IAB will figure it out in short order but if this means
people would like to select the IAB liaison for next year before IETF 104 so
you can plan travel, we can do that. If anyone wants to do it you can speak up.

Barry: I think that's a good idea, rather than being dumped into an
already-planned retreat.

Deborah: I'd encourage anybody to be liaison, it's very interesting, and
worthwhile to be at the retreat. You should consider it if you're interested.

Warren: How much time other than the travel did it end up taking?

Deborah: It's just a matter of being on their calls, so usually there's a call
about once every two weeks for an hour or hour and a half. You're not mandated
to be on the call.

Barry: I'd be interested in putting my name in for IAB liaison.

Warren: Sounds like it might be interesting. I guess we should figure out how
we do this offline.

Alissa: Amy, can you give me an action item to schedule a discussion of this on
a future telechat?

Amy: Certainly.

6. Management issues

6.1 Request to add ITU-T to the Standards-related organizations that have
registered Media Types in the Standards Tree registry (IANA)

Amy: I know they asked on email if there were any objections and I didn't see
any. Michelle, where are we with that?

Michelle: I think I saw Barry say this was a no-brainer and I didn't see any
other comments.

Barry: You are not wrong.

Michelle: Just a double check to see if there are any objections.

Amy: I don't hear any objection. We'll send the official note to IANA.

6.2 [IANA #1133923] renewing early allocations for
draft-ietf-bess-evpn-bum-procedure-updates (IANA)

Amy: It looks like this is a second renewal.

Michelle: The additional renewal after the first one requires IESG approval.
We're just bringing it to you to approve renewal for another year and hopefully
the document will eventually make its way to officially register these. Looks
like you get to send another message, Amy.

Amy: Okay, looks like this is approved.

6.3 IETF LLC appointment by the IESG (Ted Hardie)

Ted: The IESG has appointed Alissa Cooper, the IETF Chair, to be its appointee
to the LLC board.

Alissa: Ted, will you send a note to the IETF list?

Ted: Yes, I can do that.

6.4 Possible Telechat Schedule Between IETF 104 and IETF 105 (Secretariat)

Amy: We looked at our calendar and there is really only one schedule that
works. Any objection to this?

Alissa: I don't have an objection but I have two questions. Sometimes we find
another day on the July 4 week to meet. This time it's an informal so maybe it
doesn't matter. The other question is that we haven't moved the time of this
call in many years but we have new ADs joining, so if the time of the call
doesn't work for somebody we can have that conversation as well.

Mirja: I just want to note there are two German holidays here; May 30 and June
20.

Amy: We will get those in the calendar.

6.5 Designated expert for mikey-payloads (Eric Rescorla)

Amy: Ekr, you added this to see if anyone has an objection to approving Daniel
Migault as expert. Any objection? Hearing no objection so it looks like Daniel
is approved.

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

Alissa: I have a couple of questions about things on the BOF wiki. I'm assuming
things on the spherical router and the SMART proposed RG are not items that
we're expected to review and discuss, is that right?

Amy: Allison indicated she wanted to discuss the proposed RG.

Alissa: That's fine. I thought it was a scheduling placeholder.

Mirja: I talked to the potential future chairs of this and they tried to figure
out a way to get a place on the agenda because if they don't have a Datatracker
page they can't request a slot on the agenda, but I don't know what Allison's
reasons are here.

Amy: Ace, you were going to say something about the spherical router?

Warren: That was largely put on there mostly as a placeholder but we'll
probably just like to try to convince people to try to champion it. Another
thing we can discuss is the KSK Futures one but I chatted with Paul Hoffman who
suggested we put it on here just for visibility. IT's not a WG-forming thing
but I do think it should get some time. Anyway, that's for next week.

Spencer: I have an NSFv4 document in last call that's a 100 page update to the
600 page NFSv4 RFC. This will conclude before IETF 104 and I'll try to get this
through so Magnus doesn't have it on his first telechat. If people would like
to take a look early it's out there and I want to let people know it's coming.
I'm hoping we'll have space on a telechat before 104 to do that.

Ben: We may end up with some competition; I've got two I just put into last
call so there's a good chance we may overflow the page count.

Mirja: I think the last telechat before the meeting is an informal so if we
really need more time and space maybe we can use that telechat as well.

Amy: The last telechat before 104 is an informal and we can change that to a
formal if you feel you need it; just let us know.