Narrative Minutes interim-2019-iesg-07 2019-03-14 14:00
narrative-minutes-interim-2019-iesg-07-201903141400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2019-03-14 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Deborah Brungard (AT&T) / Routing Area
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Spencer Dawkins (Wonder Hamster Internetworking) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Ted Hardie (Google) / IAB Chair
Benjamin Kaduk (Akamai Technologies) / Security Area
Mirja Kuehlewind (ETH Zurich) / Transport Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Eric Rescorla (Mozilla) / Security Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Jeff Tantsura (Apstra) / IAB Liaison
Martin Vigoureux (Nokia) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Magnus Westerlund (Ericsson) / Incoming Transport Area

REGRETS
---------------------------------
Ignas Bagdonas (Equinix) /  Operations and Management Area
Ben Campbell (Oracle) / Applications and Real-Time Area
Roman Danyliw (CERT/SEI) / Incoming Security Area
Heather Flanagan / RFC Series Editor
Suresh Krishnan (Kaloom) / Internet Area
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Huawei) / Incoming Applications and Real-Time Area
Terry Manderson (ICANN) / Internet Area
Alvaro Retana (Huawei) / Routing Area
Eric Vyncke (Cisco) / Incoming Internet Area
Portia Wenze-Danley (ISOC) / Interim LLC Executive Director

OBSERVERS
---------------------------------
Greg Wood

1.2 Bash the agenda

Amy: Does anyone want to add anything new to today's agenda? Any other changes?

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to approving the minutes from March 7? I
know that was only last week, so if anyone needs more time to review them let
us know. Hearing no objection and no request for more time, so it sounds like
these are approved. Any objection to approving the narrative minutes from March
7? Hearing no objection there either; those will both be posted.

1.4 List of remaining action items from last telechat

Amy: I don't think any of the people holding these action items are present
today.

Alissa: Could we ask about these by email? Would you mind sending that mail?

Amy: Sure. Do you want targeted emails or a group?

Alissa: Just one mail is fine. And perhaps also ask if any of these require
discussion in Prague. Thanks.

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

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

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

     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.

     o Roman Danyliw and Barry Leiba to identify and catalogue common
       problematic and inappropriate behaviors from individuals in the IETF
       community both at in-person meetings and on email lists.

     o Barry Leiba talk with the EDU Team on the Working Group Chairs
       Forum agenda, possibly adding an item to discuss agenda conflicts
       and unstructured time.

     o Suresh Krishnan to report on the progress of the response to the
       Liaison Statement on "Request to update the IoT and SC&C Standards
       Roadmap and the list of contact points."

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-mpls-lsp-ping-lag-multipath-06  - IETF stream
   Label Switched Path (LSP) Ping/Trace Multipath Support for Link
   Aggregation Group (LAG) Interfaces (Proposed Standard)
   Token: Deborah Brungard

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

Deborah: I don't think so, unless someone wants to. The authors are in
communication.

 o draft-ietf-6lo-nfc-13  - IETF stream
   Transmission of IPv6 Packets over Near Field Communication
   (Proposed Standard)
   Token: Suresh Krishnan

Amy: I have several Discusses in the tracker, and Suresh is not on the call. Do
we have a feeling this will require a Revised ID?

Ekr: I cannot see how it would not.

Amy: That would have been my feeling too. We'll put that in IESG Evaluation,
Revised ID Needed.

 o draft-ietf-kitten-pkinit-alg-agility-06  - IETF stream
   PKINIT Algorithm Agility (Proposed Standard)
   Token: Benjamin Kaduk

Amy: There are no Discusses in the tracker, so unless there's an objection it
looks like this one is approved.

Benjamin: Please put it in Revised ID Needed.

Ekr: To close the loop on this, I do think the security considerations
improvement is important. If you'd like me to take a look at a revised version
I'm happy to do it.

Benjamin: Thanks, I may take you up on that; although I think I have a pretty
good understanding of what you want to see, and I agree with you.

Ekr: That was intended merely to help take some load off, since I will have
free time.

Amy: Okay, this will go into Revised ID Needed and you can let us know when
it's ready.

 o draft-ietf-uta-smtp-require-tls-07  - IETF stream
   SMTP Require TLS Option (Proposed Standard)
   Token: Alexey Melnikov

Amy: I have a couple of Discusses in the tracker; it sounds like this may need
a Revised ID?

Benjamin: I think we've been waiting for a revised ID for a while now. Even
though Alexey isn't here, do we want to talk about the general topic of having
one Proposed Standard try to stick its fingers into a different Proposed
Standard and change how it works, without any sort of updates relationship or
other indication? I think it's mostly been Alexey, Ekr, and me on the mailing
lists; I don't have a sense if other people have thoughts about that.

Ekr: My Discuss will expire quite soon, but Ben and I have talked and I think
he understands my position enough. We need a new ID, basically.

Benjamin: We're basically coming from the same place.

(Later, once Alexey has joined)

Alexey: Benjamin, can you provide a summary of what you think the outstanding
issues are?

Benjamin: I think there are basically 2 or 2.5 issues. One is just that we need
to be very clear about what the validation procedure actually is for the
various cases. The DANE case is quite clear, but there are also some cases
where you're using normal web PKI certificate chain validation and I didn't
have a clear sense what the rules were for that validation. The other one is
this more generic bit about when can one protocol reach its fingers into
another protocol and change how it works? What are the requirements
procedurally for how we make that happen? Do we see this as being a bug fix
that's updating the behavior of these other specs or is it a new thing that's
overriding them? This is essentially the same issue as Ekr is raising. And then
the half issue is this thing at the end about the tag and the header being
mutually exclusive, which is not really a Discuss level point.

Alexey: I agree with your first and last issues and that should be relatively
easy to resolve. As far as whether this is updating the base text, it's an
extension. The hopes are it's going to be used, and we'll see how widespread
it's going to be. I personally doubt it will be as widespread as TLS. I think
it's improving some use cases, especially the case of actually saying "I want
TLS all the way through."

Benjamin: That's the part that's not worrisome. I don't necessarily need TLS.
I'm not objecting to the desire to do that, I'm objecting to the way we are
specifying it and the procedural aspect. I understand Victor's stance to be
essentially that DANE and MTA-STS are essentially buggy in that they prioritize
strict confidentiality over actually delivering the messages. The current mail
infrastructure is designed to prioritize actually delivering the messages.
There's a bug in the existing spec and we need a workaround for it.

Alexey: The difficulty also is DANE and MTA-STS provide a host level
granularity and this extension is more likely to apply to a specific recipient.

Benjamin: It's message level granularity.

Alexey: It is message level but it's also likely to be used with special
accounts, like postmaster. At the moment there is no way of expressing the
policy, "please always send me TLS but you can use non TLS for postmaster," for
example.

Ekr: Why not put that policy there? MTA-STS and DANE overreached and should
have had exceptions. This is now adding exceptions in an odd way.

Alexey: So you are saying there's a missing piece on the recipient side to
advertise this?

Ekr: If you can say "Use TLS except for these accounts," then the version of
this that says "I don't care if you use TLS" would be entirely unnecessary.

Alexey: I think I need to think about this. This is the first time you've
phrased it this way. This way it's actually actionable. We might disagree at
the end but this is something the WG can discuss.

Benjamin: It's unclear to me the use case would entirely go away, but it would
drastically diminish. We had some examples about "Do you want to go have
lunch?" from one user to another user that was raised as a case where you don't
necessarily care about TLS.

Ekr: This is a thing I do want to beef up a little bit. I think it's generally
a mistake to assume only one party in a communication can decide this
communication isn't sensitive. Both sides need to agree. As evidenced by the
data leaks you see in Strava when people on a military base get shown.

Benjamin: I wasn't saying I accept it, just that's a potential case.

Ekr: I feel like the sense of our documents is we should bias towards things
being secure, so that's why I'm sad about this.

Alexey: Even if the text is edited to say the recipient's policy on MTA might
override the RequireTLS, that also probably needs a text edit. I think that's
probably going to be less controversial. Okay, so I think I probably need to
discuss this with the WG. If you have specific suggestions that would be much
appreciated. The discussion was a bit abstract and on some level people were
disagreeing with the whole philosophy and it was difficult to figure out what
was actionable.

Benjamin: My attempt at a minimum viable suggestion was to add an updates
header and say we're proposing this new mechanism because we need to update the
behavior of these existing specs because they do not work for us in this way.

Alexey: If it was a new protocol I wouldn't mind, but this will have a side
effect of saying that all these other wonderful extensions which are way more
widespread are not updating the base spec. People will start asking why is
that. I think we need something more nuanced here.

Benjamin: When you say extension, you mean SMTP extensions specifically?

Alexey: Yes.

Benjamin: I wasn't saying to update SMTP, I was saying to update DANE and
MTA-STS.

Alexey: Oh, I see. That makes more sense. Fine, maybe updating STS and DANE
might be a reasonable thing to do, yes. Did you mention this in email?

Benjamin: I thought I did, but given that we're having this discussion I should
check.

Ekr: We are between two cases: one is the case where the sender thinks the data
is insensitive and doesn't care if encryption is used, and the other case where
something is actually going seriously wrong and this is effectively a control
channel, and you're trying to keep the control channel alive. Those are the
postmaster cases. It would be good to distinguish which one this is for. If
it's for the former, the philosophical point is that senders should be able to
mark things as not sensitive regardless of the desires of the recipient. If the
point is we just want these control channels to work, that point is much more
strongly addressed by trying to carve out an exception on the receiving side.
I'd like to tease out whether or not the proponents of this are actually trying
to solve the former case or just trying to solve the latter case but figured
this was the easiest way to solve the former.

Alexey: It was originally started as the former case, and then the latter case
was added. As we started going through it, we realized there are more subtle
differences than people anticipated for the latter case.

Ekr: I'm having trouble understanding how the "require TLS: no" bit practically
gets set? Surely it's not going to get set by users pushing a button. Right?
That doesn't seem practical.

Alexey: The user aspects are difficult.

Ekr: What I was assuming was somehow this flag gets set and then they get
processed differently. I don't understand how it gets set other than in the
case where I've repeatedly tried to deliver to postmaster and I keep getting a
bounce and now I'm going to un-set it.

Alexey: It has to be set by the sender because intermediaries are not supposed
to mess with this.

Ekr: But when you say sender you mean I, Ekr, am the administrator of my
domain. I'm sending to your domain and I keep getting bounces from TLS
failures. Now I go in and I have some header that says ignore the TLS failures
and deliver to them now.

Alexey: You have a checkbox saying "send this email, dammit, I don't care about
TLS."

Ekr: That actually clarifies it and I think that makes my argument more
compelling. I'll draft an email.

Alexey: Thank you.

Ekr: I think this was a good discussion, thank you.

Alexey: This will need a new revision.

 o draft-ietf-mpls-sr-over-ip-03  - IETF stream
   SR-MPLS over IP (Proposed Standard)
   Token: Deborah Brungard

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

Deborah: I don't think so, unless someone wants to ask something. This can just
stay in IESG Evaluation, Revised ID Needed.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 o draft-faltstrom-unicode11-08  - IETF stream
   IDNA2008 and Unicode 11.0.0 (Proposed Standard)
   Token: Alexey Melnikov

Amy: I have a couple of Discusses in the tracker; is there anyone who can speak
to this?

Alissa: I was just talking to Alexey and he got the time zones mixed up, can we
come back to this and he might be able to join?

(Later, once Alexey has joined)

Spencer: We waited for me to clear my discuss until you were on the call so you
could celebrate. Please clear mine.

Alexey: Excellent. I hope people had a chance to read my summary email of the
discussions. I think people on the internationalization directorate are happy
for IANA tables to be approved up to Unicode 11, and have this document as a
reference. The document itself will need a few tweaks. People prefer to
incorporate Unicode 12 into it and that would require another IETF last call.
Do people have any questions?

Spencer: My first question is, how badly do you think this needs a second IETF
last call for trivial additions?

Alexey: Basically between versions 7 and 8 there were some editorial changes
which I don't think need IETF last call, but some people argue you might have
to. For Unicode 12 you need one because it's extra unicode code points and more
description of them. The reason why people in the directorate prefer to fold
Unicode 12 into this is so when the RFC comes out of IETF it will be up to date
with versions of Unicode published so far.

Spencer: That seems very reasonable. If we are doing a Unicode 12 version in
six weeks, before the first RFC can even reasonably be published, then it's a
trivial update. It seems like that's the right thing to do. I saw Ted's thing
in the Jabber about adding Unicode 12 seeming obvious, and I think that is a
good point. Alexey is saying basically the differences are trivial. We've
certainly made bigger changes in IESG Evaluation without doing another last
call. That's what I was thinking about.

Alexey: I think we need to do a last call because this is AD sponsored. I'm not
convinced another four weeks are needed, so maybe we can do a 2 week last call
to look at the difference.

Spencer: You might want to make these changes in the Unicode 11 draft so it
would be a second last call for the same draft, not a two week last call for a
new AD sponsored draft.

Alexey: I'll figure out the logistics of it.

Spencer: I was trying to balance how responsive we can be vs how ugly it would
be to get a process appeal on Unicode 12.

Alexey: In general, we don't need to publish one of these documents for each
version of Unicode, unless experts find some incompatible changes. Which is why
this document was so problematic, because the expert wanted to have a
discussion about incompatible changes. Certain Unicode code points changed
their properties. For Unicode 12 in particular there are no code points that
changed their properties so it's going to be much more straightforward.

Benjamin: Ted had raised this issue about the relationship between the AD and
the I18NDir.

Ted: We've had a side conversation about that and I consider it resolved.

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-trans-rfc6962-bis-31  - IETF stream
   Certificate Transparency Version 2.0 (Experimental)
   Token: Eric Rescorla

Amy: I have a lot of Discusses in the tracker. Do we need to discuss those
today?

Ekr: Is Adam on the call?

Adam: Yes, I am.

Ekr: I'd like to understand what you think the scope of the change you'd like
is.

Adam: There's what I would like, and then there's the minimal change that would
satisfy the Discuss. What I'd like is for the specification of the use of URI
templates here, because that's really what the use they specified is begging
for. But I recognize that's a relatively large change. What people usually do
when they come across a BCP 190 violation like this, is they say fine, we'll
move it under .well-known and I think that would be an adequate, if somewhat
unsatisfying resolution.

Ekr: Maybe I don't understand. The effect of the URI template document would be
to effectively shove a system defined prefix in front of the paths that it
specified in this document?

Adam: No, when you provision the location of a log, you wouldn't just put a URL
prefix, you'd put a URI template. Which includes slots into which you would
insert the information like version and operation they're currently encoding as
hard coded strings.

Ekr: What do you mean "you"?

Adam: In the case of normal CT usage, it'd be the web browser.

Ekr: No, it's not the web browser.

Benjamin: The log operator, right?

Adam: The thing the log operator hands out to clients that would upload
certificates or check the validity of certificates.

Ekr: Maybe let's take a step back. The system here has a structure where the
log operator fixes a prefix, and all of the other URLs are defined essentially
by prepending that prefix to a fixed script, correct?

Adam: Right. That is precisely what BCP 190 says not to do.

Ekr: I'm trying to understand what the wire protocol impact of what you're
suggesting is.

Adam: Right now the log operator is handing out these prefixes. This is
admittedly a provisioning difference, but there's going to be a software impact
if you do it this way.

Ekr: I need to tell you, this is a dumb objection on the part of BCP 190.

Adam: These are two separate approaches.

Ekr: My point is that if it's accessible to have it in dot-well-known I don't
know why it's acceptable to have it anywhere else.

Adam: Dot-well-known is carved out as the one exception, where it's basically
the escape valve. It's the equivalent of having the ISE; if we have
applications that are unwilling or for technical limitations unable to do
things in one of the other two ways mentioned in BCP 190, this is the catchall
thing you can do with two lines of prose in an IANA registration to solve the
problem. It's not a great solution, which is why I'm saying it's not my
preferred one. But it does address the situation that BCP 190 has normative
guidance in a BCP about how we treat URLs that went through IETF consensus.

Ekr: So did this document.

Benjamin: I think I can jump in and clarify somewhat. I'm taking Ekr's stance
as saying that in the current version, the server is providing you essentially
the URLs to use for these APIs. In the URI template version, the server is
still providing you URLs to use for these APIs, just in a slightly different
package. The main difference between the two is that if you're using a
template, the log server could change around the order of the parameters. The
log server is giving you stuff to use. The BCP 190 compliance aspect of that is
you're now enabling the server to chose these parameters vs path vs other
stuff, whereas in the current version it's just you have to use these
particular fixed strings and you have some control over where they appear, but
you don't have full control. Is that an accurate summary?

Adam: Yes.

Ekr: Okay, I think I understand this position. It's ironic that at my last
telechat I'm the one complaining about a late surprise. This document is a bis
of a document that's already widely on the internet, and we're already having
trouble getting people to do it. The reason this is experimental and not
standard is we're having trouble getting people to roll out the bis in a timely
fashion. I'm not in favor of doing something none of these people are going to
care about, so the URI template needs to be off the table. I can try to get
back to this with dot-well-known, but it strikes me as an elevation of
philosophy over reality. I'll go back to them with this. I'd like a management
item to discuss how the IESG doesn't get us into this situation again. How can
it be the case we have a standard being developed and we get to the point of
IESG approval and nobody knows about it? I'm trying to imagine a situation
where we're in QUIC and we discover at IESG time something this major. Can we
talk about that at the end of the call?

Adam: Sure. I'm pondering; we have a lot of similar things people get hit with
when things go through IESG evaluation.

Ekr: Sure, but I think this one is silly, so I'm willing to push on it. Some of
those are important and some of them are silly. Having this show up at the end
is painful.

Alissa: It sounds like you're just objecting to BCP 190?

Ekr: I more or less am, but I'm saying this needs to be caught earlier in the
system. What are we going to do to make that happen?

Alexey: Would you like an ART webpage describing common issues and this BCP
will be listed as one of them? Would that help? We used to have one of those
and people kept ignoring it anyway.

Mirja: I think this is why we have IESG evaluation, to catch these kinds of
problems. Of course if you can detect it earlier that's helpful, and needs more
cross-area work, but that's why we have this evaluation step.

Alexey: I'd like to automate validation of this BCP, but I don't think it's
realistic.

Adam: What kind of regular expression can I throw at drafts as they land in the
repository that would find this in particular?

Ekr: This strikes me as something that's very important to a small community.
Let me take a look at the archives and see how much support this actually had.
Here we have something which everybody who designs these protocols wants to do,
and yet we have some rules that they're not supposed to do that. That strikes
me that it's actually out of touch and not common practice.

Alissa: Isn't that how all squatting problems manifest? Every individual wants
their own thing to just work the way it has worked before, insofar as they were
squatting on some part of the space. But collectively we say if we keep letting
this happen, we're all going to be screwed, which is why we did BCP 190.

Ekr: I think the question is whether this in fact should share a resource. The
fact that Adam's letting us put it dot-well-known strikes me as not actually a
shared resource.

Adam: Dot-well-known is the escape valve.

Ekr: I don't think that's accurate. Dot-well-known's primary purpose is to be
something we believe is almost unconditionally controlled by the server. And
not controlled by random people on the site.

Alexey: It's a side effect. But it's a thing guaranteed not to be used unless
you want to use it for a specific purpose. If you want to run multiple services
on the same web server, you cannot use dot-well-known; you need to use a
different prefix.

Ekr: But we have dot-well-known foo and dot-well-known bar, right?

Adam: And there is a registry for that.

Ted: I think the registry is an important piece of this, because it's where, in
addition to the carveout that these things occur in dot-well-known, it's that
these things occur in dot-well-known and here's the registry you look at to
know what I should be using and where it exists. The combination of those means
here's only a tiny part of the URI space that's carved out for this and how
it's carved out is determinable. If we just said we were going to carve out
dot-well-known and squat there, we'd have exactly the same problem we're trying
to avoid.

Ekr: I don't think this is an issue of squatting. Imagine a counterfactual
where we shift everything left by one and said that when people design a
protocol we're going to ensure you need to use this prefix on every IETF
protocol we choose for applications that use HTTP. You can have a registry
there. The not squatting impact would be the same. There's a question of
interference with non standardized applications, but for standardized
applications you could put the registry in slash.

Ted: If there were no non-standardized applications that would work, but that's
not the system we're trying to put forward.

Benjamin: I said something in jabber but it might be worth saying out loud.
Suppose we did make a well-known URI for this purpose, but we leave the
mechanism between the document in place. The server can assign a prefix and you
do this after it. If this server wants to have full control over its URI
namespace, it can use this well-known prefix and it's all isolated. But the
server can also choose to do what it wants. Would that scenario still be
considered a BCP 190 violation?

Adam: I think that's still problematic, but I'd have to think through it a
little more closely. It's prohibited by the words on their face in BCP 190. I'm
also trying to unwind the objection to just saying that these prefixes must
appear in dot-well-known, and have a registration for that.

Ekr: I think I've conceded that I'm going to push them to do that, but I think
this is a silly rule. I would like to understand how we get to the point where
we don't have a situation where people fall afoul of these silly rules at the
end of the process. You don't think it's a silly rule, but I do, so I feel
silly going back to the group to rejigger this. I'd like not to have to do that
again. In any case, I think this is not a well known rule. The evidence of that
is that the last two protocols I've seen that used HTTP I don't think do this.
They're both in the Security area, so maybe the problem is SEC. But it would be
nice if this was better understood.

Adam: So for the conversation which you want to return to later, I do want to
make certain we're teasing out the late surprise issue from the BCP 190 issue.
It's clear you don't agree with the provisions that are in there, but I think
that is orthogonal to the community being unaware of certain things that are
required in documents to get them published that they might not find out about
until IESG evaluation.

Ekr: Sure. My point is the second; the reason these two are intertwined are
there are things you ought to know when you're designing your protocol, that
your protocol will be extremely bad if you don't do them. Those things, they
should be better known. Also things that are just rules which I would be hard
pressed to say your protocol would be extremely bad if you didn't do this. So
those are the things where we end up with late surprises, that it won't work
without them, which this does not.

Adam: That's the case with almost any namespace issue. If someone gets to the
end of something and has squatted on the code point, their protocol is going to
work just fine. But that's still an issue we need to have addressed because you
can't just have uncoordinated chaos.

Ekr: This is the point where you and I disagree, but what I'm pointing out is
that it should be notified better.

Adam: I do not disagree with that. That's a large problem with just about
everything that we expect of documents when they come for IESG review. I'd
argue that the majority of Discusses we ever see fall into the category of
things WGs legitimately should have known before sending it to us, but we're
bad about having all of this knowledge disseminated across everyone who
participates.

Ekr: I suggest we table that question.

Adam: I think it kind of goes to the heart of the question about late surprises.

Ekr: If people want to have this conversation now we can, but maybe we should
go through the rest of the documents.

Alissa: I think maybe we should take this to Prague. People need some time to
think about what kinds of things could be done here, and whether to solve just
for this case or more generically things that are late surprises. We can add it
to our agenda for Prague.

Amy: Talking about this document in particular...

Ekr: Revised ID Needed.

Amy: Thank you.

 o draft-ietf-mpls-sfc-encapsulation-03  - IETF stream
   MPLS Transport Encapsulation For The SFC NSH (Informational)
   Token: Deborah Brungard

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

Deborah: I don't think so, unless someone wants to discuss it. I'll let the
authors respond in email.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 NONE

3.4.2 Returning items

 NONE

3.4.3 For action

 o conflict-review-irtf-cfrg-re-keying-00
   IETF conflict review for draft-irtf-cfrg-re-keying
     draft-irtf-cfrg-re-keying-14
     Re-keying Mechanisms for Symmetric Keys (IRTF: Informational)
   Token: Alissa Cooper

Amy: This has been assigned to Benjamin and we will see it after IETF 104.

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

 NONE

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Deborah: I don't think there's anything.

Ted: Yesterday's meeting was a record for brevity, so there's nothing to report.

6. Management issues

6.1 Approve update to IDNA parameters registry of derived property values
(Alissa Cooper)

Alissa: The question is if anyone objects to us asking IANA to update the
tables once the expert validates them.

Ekr: I strongly endorse that.

Spencer: Whats the opposite of 'strongly object'? I'm doing the same thing.

Alissa: Okay. Do they need an email from us? Probably.

Amy: If it was any other IANA thing we'd send an official note on behalf of the
IESG, but this is after the expert validates them. Will you let us know when
they're validated and we can send that email? Or help us with the text of that
email?

Alissa: I think you can just take the text of the management item and put it in
the email. They know what to do.

Amy: So we can send that now so that when the expert validates to IANA and
they'll just update the tables.

Alissa: Alexey, are you on board with that?

Alexey: Yes, it seems reasonable.

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

Adam: I want to flag for the IESG that in the week or so since the 00 deadline,
on which three different drafts dealing with operational issues surrounding DOH
were submitted, there have been roughly 140 messages of a riot on five
different mailing lists. Two of those documents requested time in the DOH
session on Tuesday. I've called in Pete Resnick to help chair because one of my
chairs can't be in Prague and I don't want only one person at the front of the
room. Wanted to let everyone know there's a thing going on and if you search
DOH in the mail archive you'll get some notion of it.

Alissa: I'm wondering if this needs a little more steering. I was surprised to
see 20 minutes of DOH allocated for these drafts. I think if that's going to go
forward it seems like people need to be very clear about what the boundary of
the WG charter is vs. something people just want to talk about. Warren isn't
here but he was thinking of setting up a separate list for this discussion
because he was getting all these moderation messages from the various lists
people were CCing. If it doesn't fit squarely into any of the existing WGs that
might be a useful thing to do to cut down on the administrative load for people
on these lists.

Adam: There's also a side meeting these various draft authors have proposed
where they want to have a conversation on the topic, and I suspect the creation
of a mailing list will be predicated on how that goes.

Ted: I think they moved the side meeting to Wednesday.

Alissa: It's against the modern routing architecture session, which was meant
to draw some of those people.

Adam: In terms of concrete action items, if people have ideas about how to make
this more useful, I'd welcome input. I wanted to make everyone aware. I do
intend to work carefully with the DOH chairs so if this remains on the agenda,
the ground rules are very well set and made clear this is not within the scope
of the WG.

Alissa: I have another item. I wanted to call attention to the pre-IETF report.
It's in a Google doc and you should all be able to read it now. Please send
your comments; I'd like to post it early next week. I'll also be sending around
a draft of the pre IETF blog post soon.

Magnus: We have a liaison statement from 3GPP round two incoming, which is
related to ROC. I think we make a draft reply, circulate it later, and

Alissa: This came in already?

Magnus: It's submitted but not available yet.

Mirja: Gonzalo, who took the action, already forwarded it to the transport ADs,
so it should come in officially very soon.

Spencer: Do we know if we're having a 3GPP coordination meeting in Prague?

Adam: I haven't seen an invite yet, which now that you mention it, is kind of
surprising.

Spencer: They've done a handoff on their side on the liaison so the new guy may
not know he's supposed to push a button.

Mirja: Do we know who the new person is? I guess we can talk to Gonzalo. I can
ping him.

Amy: We have one gentle reminder that the Secretariat needs the area WG shuffle
for SEC, INT, and ART areas. We know some of you are meeting in Prague to work
that out, and we need that information by Sunday so we can prepare for the
changeover on Wednesday the 27th. That's it from us.