Narrative Minutes interim-2018-iesg-14 2018-07-05 14:00
narrative-minutes-interim-2018-iesg-14-201807051400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2018-07-05 IESG Teleconference

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

1. Administrivia
1.1 Roll call

Amy: We've received regrets from Spencer, Sandy, Alvaro, and Ted.

1.2 Bash the agenda

Amy: I did get a late breaking management item for approving experts from
Alexey, which I added to the agenda. Any other changes? The only other change
we have is the status change was put off again because I believe Alexey didn't
get a response to the question he asked. That will be to the August telechat
and we will pick that up then.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the June 21 teleconference
being approved? Hearing none, we will get those posted. I also saw revised
narrative minutes go out a few days ago. Any objection to approving those?
Hearing none, we will get those posted. Last time I missed the approval of the
BOF coordination call minutes from June 5. Any objection to approving those
revised BOF coordination call minutes so we can get those posted? Hearing none,
we will get those posted as well.

1.4 List of remaining action items from last telechat

   OUTSTANDING TASKS

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

Benjamin: We should leave this in progress. It sounds like Russ and Stanislav
will be willing and able to do this, but I didn't send mail or anything and
it's not urgent. We can finish resolving it next time.

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

Amy: This is on the agenda later as a management item so we'll call this
provisionally done.

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

Ekr: I haven't done anything there.

Amy: Okay, we'll keep that in progress.

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

Alexey: In progress.

     o Ben Campbell to find designated experts for RFC 7845 [IANA
       #1114867].

Ben: I'm aware that's on my plate and it's in progress.

Amy: It's also on as a management item.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-lamps-rfc5751-bis-10  - IETF stream
   Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
   Message Specification (Proposed Standard)
   Token: Eric Rescorla

Amy: I have an open Discuss for this. Do we need to discuss that today?

Ekr: No.......sorry, can we come back to this in a second? I'll be ready after
this next document.

Ekr: Benjamin, how do you want to proceed here?

Benjamin: I don't really object to using that phrase, I just wanted to make
sure there was visibility to the IESG that we were explicitly using political
reasons to justify a technical decision. If we think that's okay, I think it's
the first time we're going to do it. We can do that. If nobody is going to
speak up and object, I can clear my Discuss.

Ben: I almost hit Discuss on that same point and then I decided it's true so
what can I object to?

Benjamin: Right, it is true.

Alissa: I don't think it's the first time we're doing it, but maybe it's the
first time we're saying it. If you want to change the words it's not going to
change the reality. It might be better to change the words.

Ekr: I was a little sad about this rationale. I did push back on it in my
review but I didn't get real pushback.

Benjamin: So do we want to ask them to change the words?

Warren: Doesn't that kind of make it worse if we ask people to change it? Seems
more politically weird.

Ekr: There are 2 pieces of text here, there's the text that says it's political
and there's the text that says that their community doesn't like the NIST
curves because of seeds. There are perfectly valid reasons to be using the
EdDSA curves even if you have high confidence in the NIST curves.

Ben: The statement that this is political is not nearly as inflammatory as the
statement that the community doesn't trust NIST. And I would be hesitant to ask
them to take it out because it's the reason.

Ekr: I think people who think the NIST curves were good think we should be
moving to the CRFG curves. Good is a complicated term. People who think the
NIST curves were generated safely think we should move to CFRG curves.

Ben: I suppose the text could simply say some members of the community have
preference for the other curve.

Ekr: I think IETF policy is a preference for the other curves. That's true.

Mirja: I think there are political things involved, why people are skeptical
about it. But the actual reason why it's not in the document is technical
reasons, so I don't think the sentence is even true.

Ekr: This text is not very clear. What is the thing that's allegedly political
here? To be honest I'm not even clear about that. Clearly there must be some
curve, so there are 3 choices:  NIST only, CFRG only, or both. It's not
entirely clear to me what they're saying is the political part of this. Is it a
decision to continue using NIST curves? Mandate the CFRG curves? I don't know.

Benjamin: My original sense was that the political thing was the lack of
confidence in the NIST curves. But as you point out we have a general
preference for CFRG curves to a large extent independent of the politics.

Alissa: My interpretation was that the political thing was the continued
requirement to support the NIST curves. Which is not an IETF requirement, this
is an external...

Ekr: If I were forced to take a read on this, that's what I'd say this means
too. In that case it's not clear why we'd have to say there are people who
really don't like the NIST curves.

Alissa: So at a minimum this is unclear.

Mirja: I think it's unclear and also it's a little bit inappropriate to make a
judgment about the political part in this document. If we want to do that it
would be a separate document.

Benjamin: Do you want me to edit my ballot position to reflect the discussion
we had, or Ekr do you want to contact the authors?

Ekr: I think it'd be good if you continued to take point on this.

Benjamin: I don't know if it's better to do that in my ballot position or over
email.

Ekr: We could wait for them to respond I suppose. Also we're all going to be in
the same place in a week and a half.

Amy: Sounds like this is going to require a revised ID, right?

Ekr: Definitely. There are other comments people had too.

Amy: This is going in IESG Evaluation, Revised ID Needed.

 o draft-ietf-mpls-spring-entropy-label-11  - IETF stream
   Entropy label for SPRING tunnels (Proposed Standard)
   Token: Deborah Brungard

Amy: I have no discusses in the tracker so unless there's an objection it looks
like this one is approved.

Deborah: We'll do it as Point Raised, Revised ID Needed.

Amy: Approved, Announcement to be sent, Point Raised, Revised ID Needed.
Deborah you can let us know when you're all set.

 o draft-ietf-bfd-multipoint-18  - IETF stream
   BFD for Multipoint Networks (Proposed Standard)
   Token: Martin Vigoureux

Amy: I have a couple of discusses in the tracker, do we need to discuss those?

Martin: Yes possibly. Thank you all for your reviews and comments. Benjamin,
let me know if I'm wrong but I'm under the impression that the four points of
your discuss were addressed by Greg. That requires an update to the document
but you seemed to be satisfied by his proposed update.

Benjamin: I believe that's correct, yes. I don't know if you wanted to have a
posting approved during the blackout.

Martin: Honestly for all the documents I own today there is no specific
urgency, so I plan to let the authors publish after the blackout period.

Benjamin: Do you want me to hold onto my Discuss until then?

Martin: I'm perfectly fine with that, yes. Mirja, the authors haven't chimed in
yet and I want them to. Do you want us to discuss your points today or give the
opportunity to the authors to speak up before?

Mirja: Did you say you replied? I didn't see that email yet. What did you say?

Martin: Your first point, I was saying that the multipoint spec doesn't change
the base spec, so 5880, for the setting of the desired interval. So it will be
set at 1 second. So I didn't feel there was a need to explicitly restate that.

Mirja: What I would like to see is to restate that it will also not change, it
will always stay at one second.

Martin: That's fine but I think it's already stated somewhere. I can pull out
from the draft that specific text. I believe at least your concern is already
addressed by the spec.

Mirja: The spec read a little bit like you can actually change it. If you
change it you also have to set the p-bit, which makes me think people actually
could change it.

Martin: Of course you can set by configuration the desired ntp interval. But
because of the 5880 requirements, which is kept implicitly, it cannot be
configured at a value lower than 1 second.

Mirja: I would like to have that stated explicitly.

Martin: On your second point, it's a bit more difficult in the sense that just
like 5880, that spec doesn't make much -- on the encapsulation. If we start by
specifying TTL and hop count in that spec, I think we would go beyond its scope.

Mirja: I think if that is true what needs to be done here is clarify that given
restrictions we have based on the base spec, this approach only applies to
single hop scenarios. And that you must implement a way to ensure that the
packets don't go further than 1 hop. Depending on the encapsulation used you
can use the TTL or hop count.

Martin: On the one hop limitation, I'm a bit concerned by that.

Mirja: I can understand but that's what the base spec says. If that's not the
scenario you have then you need to find another way to implement congestion
control.

Martin: Another way is to change the requirement of the base spec.

Mirja: Yeah but then you have to find another way to implement congestion
control because you cannot send random packets everywhere in the network at a
fixed rate without any congestion control forever.

Martin: So this is where I think we have covered by the previous situation,
because I'm not sure how we can congest the network by sending a packet every 1
second.

Mirja: If you do this on multiple sessions on multiple hosts it can lead to
high congestion.  If you do this for a thousand sessions it's a thousand
packets per second. And more if you do more sessions. I'm not saying this will
usually happen but the spec should not allow it to happen.

Martin: Okay, I think maybe we will take it on the list. Even if you multiply 1
packet by a thousand you don't congest your network.

Mirja: It depends on the kind of network you have and so on. I'm just relying
on the base spec. If you think you need to change the base spec that's a
different thing.

Suresh: I want to point out something. In RFC 5883 which is the BFD multipoint
spec, there's text which says the operator needs to provision this thing at the
rate in which the BFD is transmitted. If text like that could work you could
use that, take a look.

Mirja: That could be a solution as well as some sort of egress filtering to
make sure those packets don't leave the network.

Suresh: That's 5883 section 2.

Martin: I think the 3rd point is in the same line of ideas and I have proposed
some text in response to that. You can take a look and tell me whether it's
okay or not.

Mirja: I think here the problem is also about a reasonable upper bound. I would
rather see an upper bound or give a more explicit recommendation about what
such an upper bound could be.

Martin: Fixing a number is not realistic.

Mirja: I know, but maybe you need more discussion about in which scenarios
which ranges of numbers might be reasonable.

Martin: That's why the number of initiated sessions should be defined by the
operator of the network who knows its environment and is in the best position
to define what should be done. Rather than setting an upper bound on
implementation that could be limiting in certain environments.

Ekr: Mirja, I'm trying to understand what you think would be acceptable. Is
your position that you shouldn't be allowed to send packets at any rate without
some sort of feedback or is it just that you think there should be some
specified maximum packet rate?

Mirja: There should be a specified max. And just because you can have an
unspecified number of sessions there is no max anymore.

Ekr: So you think there should be a global max?
Mirja: It could be a global max, yeah. The recommendation we give in RFC 8085
is that if you don't have any feedback and no congestion control you should not
send more than one packet per 3 seconds, so sending 1 packet per second is
already higher than the recommendation we give. And then you multiply it by the
number of sessions.....

Martin: Even if you have 10k sessions, that's only 10k packets that are going
out of your ....

Mirja: I understand that this is in practice not a problem, but in theory if
your network is tiny and you don't have a lot of bandwidth this can be a
problem. You have to more clearly specify what the assumptions are of your
deployment and where this applies.

Martin: Yeah, but that would impose on the authors to list all the possible
network configurations ... that doesn't seem realistic.

Mirja: No, but at least providing more guidance about what needs to be
considered when setting the upper bound and make sure that there is an upper
bound implemented are important points. Because just saying a reasonable upper
bound is completely in the blue. What's reasonable, how can I figure out what's
reasonable for my network?

Warren: I think there should be some advice to the operator, like if you're
doing 1000 of these your control plane might become sad. I think mine's an
easier one to do. But you used the example of only 1000 packets, if you have
1000 sessions at one packet per session per second, that 1000 packets generated
by the control plane might make them sad. Operator, keep in mind you could
shoot yourself in the foot here.

Martin: Okay but every vendor that I know has an upper bound for the number of
sessions it can reach, and that mostly depends on the system capabilities, not
on the network in which the system would be deployed. So I'm perfectly fine
saying implementation must have an upper bound, in the sense that it's not
possible to create an infinite number of sessions, but giving a value for that
upper bound is ....

Mirja: What you can also say is they must have an upper bound, the default must
be set to this value, and then explain that this value was chosen based on
these considerations and give operators some idea about if they want to change
it, what it should be. So not restricting what the value can be but setting a
default value which is what is currently used in many cases.

Martin: Okay, I'm afraid that we are moving from a protocol specification to an
operational specification by giving guidance on how to configure and how many
sessions and so on. That in my view is definitely not the scope of this
document.

Ekr: I have some sympathy for Mirja's point here. Generally I don't think we
should be designing protocols which have potential to make the internet really
bad, and if we do we have to have guidance about how not to make the internet
really bad, like in QUIC we go to a lot of trouble to make it so you cant use
QUIC as an amplifier. I don't know quite what to do here but I think we need to
do something to make sure this doesn't cause congestion problems.

Martin: I completely fail to understand what congestion can we generate by
sending 24 bytes of data per second anywhere.

Ekr: As Mirja says if you have a pile of different connections on the same
bandwidth network that can certainly happen.

Martin: But if that packet is creating congestion then your network is
congested already by the data traffic.

Ekr: I assume the case Mirja had in mind is that you have a pile of concurrent
sessions and each is generating 1 pps. Obviously this wouldn't be a problem
ordinarily on a fast network, but say you have a reroute onto a slower network
and now there's cascading .... I don't think it's crazy. I agree it's a little
bit not obvious how that would happen in practice, but it's not crazy.

Mirja: There are three ways forward. The minimum is to explain the problem,
even if it's not realistic for all networks, and make the reader aware of it.
Another option is to have an applicability statement and say this is
environments where you can use it and where it makes sense, but even if you
have an applicability statement you need a very high upper bound. The third is
to address the problem by making sure this cannot happen it all. But the
document needs to say more about it.

Martin: Ok, point taken. I will try to work with the authors along those lines.

Mirja: Thank you.

Amy: It sounds like this one requires a revised ID anyway, right?

Martin: Definitely.

 o draft-ietf-bfd-multipoint-active-tail-09  - IETF stream
   BFD Multipoint Active Tails. (Proposed Standard)
   Token: Martin Vigoureux

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

Martin: No I think it's been addressed. Ben had a process Discuss because this
was updating the multipoint and these two are being pushed at the same time so
Ben suggested we simply use the references rather than updating. That was a
valid Discuss so we will do that. I will let Ben decide whether or not that
addresses his Discuss.

Ben: I saw an email from the authors yesterday but I haven't had a chance to
read it yet. On a quick scan it looks like it's on the right track.

Martin: Thank you Ben. I'm sure that will require a revised ID.

Amy: This will go into Revised ID Needed.

 o draft-ietf-6man-rfc6434-bis-08  - IETF stream
   IPv6 Node Requirements (Best Current Practice)
   Token: Suresh Krishnan

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

Suresh: I think it's very clear, I'm just waiting for the authors to respond.
The discuss is very reasonable. All the changes are editorial and we can do
them in a revised ID. I'm just waiting for the authors to respond. Just put it
in Revised ID Needed and we can pick it up.

 o draft-ietf-bfd-yang-16  - IETF stream
   YANG Data Model for Bidirectional Forwarding Detection (BFD)
   (Proposed Standard)
   Token: Martin Vigoureux

Martin: I'd like to start with Benjamin's. But I think it's the proposed
resolution was okay.

Benjamin: There was a new sentence to put in the security concerns.

Martin: Yeah. So just like for the first document I'm fine if you keep the
discuss until we have a new revision posted. Some of you have made comments.
Some still need to be addressed but I'm sure they will be. Alissa, you have a
discuss on the use of IANA. How do you want to proceed?

Alissa: The question is whether the name of the module and all associated
identifiers. .. if that has to be the name. I understand t hats the convention
thus far but I couldn't find anything that says things hav to be named that
way. Is there a possibility to change it?

Martin: Honestly I don't understand the implications of changing it vs keeping
it. I don't have any objection at all with changing it but then i would welcome
two things: you or we decide what to put there instead and that we then define
some form of policy that would apply to all future Yang documents so we have a
consistent rule going forward.

Alissa: That sounds like a good plan.

Ignas: There doesn't appear to be any history as such. ..... [audio cut out]

Martin: In the meantime, Alissa, if we change will we also apply the change to
all the already registered yang modules? Or we would keep them?

Alissa: I don't think it makes sense to do a retroactive change, but this was
was more about changing the convention going forward. I think it just makes
sense to have a neutral identifier in there that's not registry operator
specific.

Martin: Do you have any idea on what we could write down here?

Alissa:  I don't really care. I think what's trying to be conveyed by this name
is not that it's managed by the registry operator but that the module will be
automatically updated when a separate registry is updated. If that's actually
the semantic people are going for then something like auto-update or something
that signifies that wold make more sense than IANA. Maybe we should take this
to email because we don't seem to have Ignas.

Amy: I'm hearing this requires a revised ID on at least one of those points.
This discussion is going to continue online.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-tsvwg-rfc4960-errata-06  - IETF stream
   RFC 4960 Errata and Issues (Informational)
   Token: Spencer Dawkins

Amy: I have no discusses so unless theres an objection now it looks like this
one is approved. Hearing none, and as Spencer is not with us today, we will put
this in Point Raised.

Mirja: I have to double check with Spencer but I've also been talking to the
authors and WG chair and they've been concerned this doesn't get published. I
can see the argument about the value but I also think it's possible to use the
process as we usually do. I think they are aware of that and I would recommend
Spencer just publish it and hopefully we don't see that again.

Ekr: I marked this Abstain but I'm sad Spencer isn't here because I think it's
worth a 5 min conversation about whether or not we publish this. That's
probably worth some brief discussion.

Mirja: I think this is a case of they made up their own process and it worked
once, so they did it again. I wouldn't want to block publication but I think
they understand the IESG's position now.

Adam: Between the creation of that process and the request to publish this
document, there was a statement basically saying don't do this. It's not like
this is a surprise.

Ekr: my point is that I do object to the publication of this document and I
think other people do. I marked abstain because I think that's the appropriate
thing at this point and I think blocking isn't really appropriate. But I'd like
Spencer to look at the things we said and come to the conclusion it shouldn't
be published, not to have this go through on inertia because that's what the
formal rules of the ballot say. If people want me to mark this Discuss so that
happens, I'm fine with that,  or we can discuss it now.

Alissa: If someone wants to block the publication of this document until we
have time to discuss it, Discuss is the right option. It always makes me
uncomfortable when we have a bunch of people abstain and then have this
discussion.

Mirja: Spencer is not available this week and it will not be the first action
he does, clicking publish. But I don't think this document has any harm so even
if it gets published we can still discuss it afterward. It's Spencer's
decision. If you just send him a mail he will wait.

Ekr: My position has changed based on the fact the majority of the IESG has
abstained.

Mirja: The statement doesn't say you can't do it, just that we recommend you
not publish these kinds of documents.

Alissa: The balloting rules for an informational document are such that this
is.....

Ekr: I agree that in the current process, with its current ballot it can move
forward. I'm now going to mark it Discuss so it cannot. Then we can discuss it.

Alissa: That's better if that's ....

Mirja: You can do that but I think that's kind of the wrong signal to the
authors because it's a good group of authors who care very much about this
protocol. They've worked with a lot of implementers and they were not aware of
this process change. And to give them a lot of pushback and try to hinder the
publication of this document, I think doesn't have any value besides making
them frustrated about the process. And I don't know why we should do that.

Ekr: My position is that this document is bad. I propose we discuss this in
Montreal and once we've had this discussion I'll give it to Spencer.

Mirja: But you said this document is bad in the sense that it's not helpful for
you. It's not bad in the sense that it hurts or breaks anything.

Alissa: There was some feedback from some of the reviewers that they felt it
made it more confusing to understand if they wanted to implement the updates,
how they were supposed to do it. In any event the discussion will not be in
Montreal bc Spencer will not be with us, so ti will have to be after.

Ekr: I'm also happy to do it over email.

Mirja: The technical comment here was that there were points in this document
where something is updated and then updated again alter on which makes it hard
to read. If you want to discuss on that point, changing the content of the
document, that's a valid point. But just the general idea of this document is
not very helpful, but it's not harmful, so I don't see the point.

Adam: I'm not sure that we need 100 extra pages in the RFC editor's queue in
front of other documents at this point. The argument that it causes no harm
after it exists as an RFC I can get behind. The fact that it's going to use
resources on the way, I can see.

Alissa: We put the statement out quite some time ago now and we had a bunch of
documents come through shortly after we put the statement out and so we had
some discussion there where the authors noted the IESG had put out this
statement. Now there's been a lot of time and I think it just highlights again
we all need to be keeping an eye on this in the WGs and flagging it for people
as new documents come through. Because the more time that passes since the
statement came out the less the argument makes sense that people didn't know or
weren't aware. People should be aware.

Ekr: In any case I just balloted Discuss and said I think we should discuss it,
and if we discuss it and Spencer thinks we should vote yes, I will clear. I
don't think that's an unreasonable burden to the authors.

Mirja: I'm even more uncomfortable because this is also a milestone in the
charter of the WG. They've been working on this for a while and we could have
told them earlier. It's not like there were only a couple of documents right
after the statement was published, it's over and over again. So if we want to
stop this happening just taking a random document and saying now we don't
publish it anymore is not the right way forward.

Alissa: It's not a random document, we've had this discussion over and over
again.

Mirja: But why is it this document you want to hinder publication now?

Ekr: I want to resist the notion that a Discuss until we can have a discussion
with the sponsor on a telechat is hindering publication. We discuss things all
the time for relatively modest reasons. I think coding this as hindering
publication is not accurate.

Mirja: If you are discussing a meta discuss that you can't discuss with the
responsible AD that doesn't make sense to me either.

Ekr: The purpose of my discuss in this case is that otherwise this document is
approved. I would like to have a discussion before it is approved.

Mirja: But what is the discussion about?

Ekr: I think we should not publish this document and I'd like to hear Spencer's
response to the various comments that have been made in the tracker.

Alissa: Spencer is the only person with a Yes ballot, so we kind of need him
involved in order to resolve it if there's going to be one discuss and one yes.

Warren: Can someone please remind me what the actual problem with errata type
documents is? I personally find them useful because I don't have to then go
rummaging through 500 different places. I know there was a statement but other
than the harm of taking up RFC editor time, I'm still somewhat confused about
the harm in the document.

Ekr: If your position is that documents which don't cause any harm should be
published, I'm not sure we're on the same page. This document is being marked
as a product of the IETF we think is a good thing. That's what the boilerplate
means. I don't think a document that's a linear time series of diffs against
the original RFC is a good thing.

Warren: I thought there was actually noticeable value in that, but that's I
guess where we differ.

Mirja: But I don't think what you put in your discuss here is valid discuss
criteria. To be honest, I don't understand why we're having this discussion
because if you send Spencer an email saying can you please hold this
publication until we discuss it, he will surely do it. I don't think putting a
Discuss and giving the authors a signal that there's a huge issue here which
might not be the case is the right thing to do.

Ekr: Well fortunately the Discuss criteria don't apply to informational
documents, so that's not really appropriate in this particular case. The
authors have received several emails from us saying we think this is bad, I
don't think a Discuss is the equivalent of me stabbing them in the eye.

Ben: There's a discuss criteria for saying they haven't responded to reviews.

Mirja: They did, and they took the abstains seriously.

Ben: Responsiveness does not mean they responded.

Alissa: If the state that this document is going into is that it will await a
discussion with Spencer, they should be aware of that. We shouldn't keep them
from that if that's whats going to happen.

Mirja: That's Spencer's decision.

Alexey: Can I just defer it? Then it will be in August on the next telechat.

Suresh: I think the point is that there's a clarity issue with the document
because of the time series diffs. I think that needs to get fixed. Whether or
not that's a discuss...

Mirja: If you want to put a discuss in for that point you can do it. But the
current discuss is very inappropriate. Hitting the Defer button would have been
more appropriate.

Ekr: I don't agree it's inappropriate.

Alissa: I think we're getting into diminishing returns here. We each have
autonomy to ballot as we wish and we can disagree about whether other people's
ballots are appropriate or not. Let's continue this discussion with Spencer.

Amy: I'm going to put it in the substate of AD Followup, so Spencer can follow
up with everybody when he is back online.

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
3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-song-yeti-testbed-experience-01
   IETF conflict review for draft-song-yeti-testbed-experience
     draft-song-yeti-testbed-experience-09
     Yeti DNS Testbed (ISE: Informational)
   Token: Terry Manderson

Amy: I have no discusses so if there's no objection it looks like the conflict
review can go back to the ISE. Hearing no objection to sending this conflict
review message back to the ISE so this is approved and the message can be sent.

Mirja: We already discussed that somebody will talk to Adrian about some stuff.
Did we ever have a returning conflict review? Is that what we want? If we send
a conflict review that's what we say and it's the ISE's decision anyway to
address concerns or publish anyway.... I would prefer him to try for all these
things before we have the conflict review.

Suresh: I think Mirja has a point. But you're going to have a 1:1 with Adrian,
right Alissa? Maybe this can be a point you raise with him.

Alissa: Yes, we have several things to talk about. This will be one question
for him.

3.4.2 Returning items

 NONE

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

 NONE

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Babel routing protocol (babel)

Amy: This is ready without external review, that the changes are small enough
that babel doesn't need external review. I have no blocking comments. Unless
there's an objection now it looks like the recharter is approved. Hearing no
objection, this is approved. Your milestones are old milestones--do you want to
update the dates or are they still working on those?

Martin: I asked the chairs to take a look at the milestones and change them if
needed. I think what is important is that new dates be set but I think we can
always do that after the charter has been published.

Amy: You definitely can, I was just pointing out that they're all out of date.

Martin: Yes, I believe we can publish as is and then update them later.

Amy: Great. Then the WG action announcement will be sent.

 o Source Packet Routing in Networking (spring)

Amy: I do have a blocking comment for this rechartering effort. Do we need to
discuss it?

Martin: Yes, it came at the last minute. You will need to educate me on what is
cryptographic assurance of the integrity of the routing information. Let me say
a few words before that. Spring as you can see from the charter, spring is the
central place to discuss segment routing, but it doesn't do any protocol work.
At best it will do functional specs and it will be up to the different WGs to
define the protocol mechanics. As an example, segment routing using MPLS
labels, it's up to the former ISIS/LSR to do. The extensions of the BGPs to
distribute the identifiers that then enable to build the labels .... So maybe I
don't understand what you mean by cryptographic integrity and identity but I
believe that it's not the responsibility of spring, it's the responsibility of
the IGP to resolve that part. Spring doesn't define the targeted header and it
was taken out of the charter because of that. It's being dealt with by 6man. I
believe the cryptographic assurance should be handled by 6man. So while I'm
very sympathetic with your expectation I'm not really sure what Spring can do
beyond identifying the security aspects and putting requirements on the other
WGs.

Benjamin: That's a fair point. I was not entirely clear this morning that this
was just a coordination point and the actual protocol descriptions would need
to be in the other WGs, so thank you for the clarification.

Martin: Except on very special cases which would need the agreement of the
different WG chairs and ADs, spring will not do any protocol work.

Suresh: One thing that might be relevant is the network programming draft. Even
though it doesn't specify actual implementation it has instructions set inside
and probably requires some kind of security rating. That's probably what you
should spend some time on to look at it.

Martin: Okay, that's a good point. Making it general to spring might be a bit
difficult as I tried to say. On the other hand I agree there might be some
documents in spring for which we need to take special measures. How do you
think we could deal with this as part of the charter?

Benjamin: One of the last comments you made in your initial statement is pretty
insightful, which is that a WG in this position can describe the security
properties and requirements that are needed for these other routing protocols
that will be carrying its information. In particular because of the nature of
the source routing the requirements might be different than some of the other
traditional routing, and anything that goes wrong has local effects. With the
source routing you've got the entire route described in the packet header and
if something goes wrong you could have more far reaching effects. One could
imagine there would be different requirements for making sure the info in the
packet header is actually produced by someone who you trust to do so and that
the integrity of that is maintained throughout the packet's progression through
the network. So I think there's probably room in the charter for analyzing the
security requirements and how they differ from the existing underlying
technology that's going to be used.

Martin: Okay.

Mirja: Sounds like a great idea if you have more assurance about the route;
this is a completely different protocol then and you probably need a new WG.

Benjamin: It's possible that I should take some more time to look at this
offline because I just learned several new things on the call today and it
might be better for me to take more time to process it and come back with a
better proposal.

Martin: Okay, I'd be fine with that and I'm happy to interact with you about
that. The old SR-MPLS and SR-IPv6 are about to be defined. There is no plan to
define any other updated thing. The base functionality has already been
defined. Alvaro has already handled the first bunch of specs from spring and
also from lsr/isis. I'm not sure if we have a lot of margin to influence these
base specifications concerning the security viewpoint.

Benjamin: There will always be cases where pragmatic consideration causes us to
go forward with something even if there's some security thing we want to do
with it. In such cases we can make sure to document any security or other
properties that you are maybe not sure about or not comfortable about to make
sure that even if we go forward with something suboptimal we are clear about on
what it does or does not do.

Martin: I agree and I think that it relates to what I was saying earlier. Going
forward spring could at least work on identifying all the security aspects it
can and formulate relevant requirements to the WG if extensions need to be done.

Suresh: If you want some pointers Martin, take a look at RFC 5095. It explains
why we deprecated the type zero headers in v6 so that's something you can take
as input.

Martin: Benjamin, take the time you need -- not all the time you need, but some
time -- I don't want this to spend a month on that but if you need to take time
to take a look at spring please do, and in the meantime we can interact on that
aspect and try to find a piece of text to add that would satisfy you.

Benjamin: That sounds good.

Amy: Sounds like the spring WG recharter is not approved and we'll be waiting
for instructions from Martin.

Martin: Yes and I will be waiting for Benjamin.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Deborah: The only item is what Alissa sent out, the management item on the SG2
liaison.

6. Management issues

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

Alexey: Can we please approve changing the change controller for ipp to be IESG?

Amy: Any objection to that?

Amy: I'm hearing no objection so it looks like that is approved. And we need to
send an official note to IANA, is that right Michelle?

Michelle: Yes, thank you.

6.2 IANA #1114867] Designated experts for RFC 7845 (IANA)

Amy: We talked about this at the top of the call with Ben and that is on his
radar to do.

6.3 SG2 liaison statement (Alissa Cooper)

Alissa: I sent a mail about this a couple of days ago which had the context in
it. There's a proposal to SG2 which seems problematic from a few perspectives.
Folks are trying to have IANA allocate either slash 8 or slash 4 for this
routing experiment hey want to relating to embedding in the v6 prefix. They
have already approached IANA about this.

Michelle: to clarify, we have not received the request. We're aware of it
because somebody brought it to our attention but we have not been approached
yet.

Alissa: Sorry, I misremembered your email. In any case, you and I and Ted have
been in contact already. Together with Scott Mansfield we drafted a liaison
statement which we're proposing to send on behalf of Ted and myself. The IAB
has already reviewed it and everybody on the IAB seemed fine with that approach
and text. I wanted to see if anyone here had an objection to sending that
statement. Suresh: Looks good to me, Alissa.

Benjamin: The only question I had, it talked about this document to refer to
some ID but it isn't clear from the context what document that is going to be.

Alissa: Thank you. I'll bring that back to Ted. It might be we can be more
specific, or maybe it's already referenced in the submission.

Suresh: That came out of an EU research project, it's got no official standing
anywhere in the IETF.

Martin: Those EU projects have a tendency to be evaluated based on multiple
criteria, one of them being impact. Impact can be measured by publication to
SDOs, so that's also why I think there's a misunderstanding on the status of
the document. They've probably published a draft and believe that is
sufficient. I believe they're also publishing something at the ITU which is
being discussed today or tomorrow. This is why I was also thinking one of us
could reach out to them. I'm fine with sending that note to ITU.

Alissa: We knew they were meeting so we wanted to get the liaison in front of
the whole group. We can reach out to the authors as well so we're sure they're
aware of it.

Amy: Anything to record in the minutes, or just that it was discussed is
sufficient?

Alissa: You can record the IESG was fine with proceeding with the liaison.

6.4 IESG approval for service name registration ipps (Mirja Kuehlewind)

Mirja: This is the second part of the ipp cleanup. RFC 7472 already defines the
service name of ipps and it's widely used and it uses the same ports as ipp. If
you look at the port registration guidelines it's not what we have recommended
common practice anymore. That you use the same port for the secured and
unsecured version of the protocol. We'd like to add a second entry in the
registry to make sure to register the service name to reflect reality.

Amy: Hearing no objection to this change, it sounds like the IESG has approved
the service name registration. We'll send an official note. Was there specific
wording you'd like?

Mirja: "Registration of the ipps as service name for port 631 has been approved
by the IESG with the IESG as the Change Controller."

6.5 Designated Expert for RFC 8323 (CoAP Signaling Codes) [IANA #1108770]
(Alexey Melnikov)

Amy: Any objection to approving experts Klaus Hartke and Alexander Pelov?
Hearing none, those are approved.

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

Martin: I will soon close i2rs which was supposed to be closed back in March.

Ekr: People may wish to be aware that despite my telling people we wouldn't
figure out how to encrypt an SNI, in May we figured out how to do that so
there's a proposal in tls now for how to do it.

Alissa: If anyone has any last minute agenda items for the IESG to discuss in
Montreal, please send them to me or post in the wiki. Also putting together pre
meeting report and blog post I usually do before each meeting. I'll send those
to you for review. If you have particular hot topics in your area you think
should be highlighted in such documents, send them to the list and I'll make
sure they get included.