Narrative Minutes interim-2019-iesg-09 2019-05-02 14:00
narrative-minutes-interim-2019-iesg-09-201905021400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2019-05-02 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
Alissa Cooper (Cisco) / IETF Chair, General Area
Michelle Cotton (ICANN) / IANA Liaison
Roman Danyliw (CERT/SEI) / Security Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Wes Hardaker (USC/ISI) / IAB Liaison
Ted Hardie (Google) / IAB Chair
Benjamin Kaduk (Akamai Technologies) / Security Area
Suresh Krishnan (Kaloom) / Internet Area
Mirja Kuehlewind (Ericsson) / Transport Area
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Huawei) / Applications and Real-Time Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Huawei) / Routing Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Martin Vigoureux (Nokia) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area

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

OBSERVERS
---------------------------------
Andre Cedik
Greg Wood

1.2 Bash the agenda

Amy: Does anyone need to add anything new to today's agenda? I did see we had a
document that was deferred a few minutes ago. Any other changes? No other
changes.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes from the April 11
teleconference being approved? Hearing no objection, so those are approved. I
saw narrative minutes; is there any objection to those being approved for
posting? Hearing no objection to that either.

1.4 List of remaining action items from last telechat

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

Suresh: Keep this in progress, please.

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

Barry: That is in progress.

     o Alissa to draft a revision to the Meeting Room Policy and
       communicate it to the LLC Board.

Alissa: It has been communicated. Perhaps you should assign me an action to
report back to the IESG after the LLC Board has its retreat and considers all
of its policies, so I remember to do it. That's happening next week.

Amy: Okay, we will add a new action item for Alissa to report back.

     o Benjamin Kaduk to identify designated experts for RFC 5580 [IANA
       #1139586].

Amy: This is on the agenda as a management item, so we'll mark that as
provisionally done.

     o Barry Leiba and Roman Danyliw to summarize the discussion on common
       problematic behaviors.

Amy: Is this done, because we discussed it at the retreat?

Barry: That's done, but there should be an action item from the retreat
following up on it.

Roman: There is, a bit further down.

     o Suresh Krishnan to follow up on proposed IESG Statement on the
       procedure to reference material behind a paywall.

Amy: I think we have a new action item that furthers this work so this item is
done; is that correct?

Suresh: Yes. I have the new text ready to go. I'll ship it off today so keep it
in progress, but I think you can close it next telechat.

Amy: Both of these action items? The new one from the retreat and this one?

Suresh: The old one is done; the new one will be done soon.

     o Ignas Bagdonas to propose an additional question on YANG Model
       format validation for each of the styles of document write-ups.

Ignas: This one is in progress.

     o Roman Danyliw to talk to the tools team to reset the counters on
       substate change for documents in AD Evaluation.

Roman: That one is in progress.

     o Roman Danyliw to draft text to be posted on ietf.org about reporting
       protocol vulnerabilities via an email alias and possible procedures
       on how to assign triage resources.

Roman: Likewise, in progress.

     o Suresh Krishnan to write a document on replacing the "updates" with
       new terminology (amends/amended by; extends/extended by; see also).

Suresh: I would say in progress but it's not yet started. Keep it in progress
please.

     o Warren Kumari and Ted Hardie to write a document on Implementation
       Target Sets (aka Living Documents).

Warren: Haven't done that yet.

     o Roman Danyliw and Barry Leiba to draft a starting point for the
       discussion on setting expectations with the WG Chairs in reference
       to responses to inappropriate or unacceptable behaviors.

Barry: That is in progress.

     o Martin Vigoureux to work with the IESG to create a list of possible
       IESG Tutorials and will prioritize them for scheduling on a series
       of Informal Telechats.

Martin: I haven't done anything, so keep it in progress.

     o Alissa Cooper and Alexa Morris to put together a Doodle Poll for
       possible dates and cost effective places for a second IESG retreat.

Alissa: This is in progress; I sent my availability to Alexa yesterday.

     o All IESG to coordinate with their co-ADs and send a list of specific
       "hot topic" items that should be checked. The list to be provided
       for document authors.

Amy: I know a couple of the areas have done this already.

Barry: You've got TSV and part of ART, but we have to consolidate ART and take
care of missing items.

Amy: I'm going to keep that still in progress for everyone else.

     o Eric Vyncke to write up draft text for the NomCom to help them
       understand the rules for the NomCom.

Eric: I would love to say in progress, but it is yet to start.

     o Suresh Krishnan to write up a NomCom Chair BCP (work with past
       chairs).

Suresh: I started something on this and reached out to Scott, who had some
discussions with Peter. We want to sit down the three of us and try to put
something together. That's in progress.

     o Eric Vyncke to draft text for a more coherent BoF Proposal for
       MEDIA OPS and add to the BoF Wiki.

Eric: This is in progress.

     o Roman Danyliw to shepherd the www.ietf.org analytics discussion
       with the community.

Roman: That's in progress.

     o Alissa Cooper to draft text back to the proponents of
       draft-moonesamy-recall-rev to talk about the outcome of the
       discussion at the retreat.

Alissa: That's done.

     o Warren Kumari, Alvaro Retana, and Mirja Kuehlewind with Spencer
       Dawkins to continue discussion of the next Deep Dive topic for
       IETF 105.

Alvaro: That's in progress.

     o Suresh Krishnan to update the text for material behind a paywall
       to update the reference to section 7.1; update the document shepherd
       writeup; and draft text for a possible IESG statement to circulate
       with the WG Chairs.

Suresh: Still in progress.

     o Alexey Melnikov, Warren Kumari, and Suresh Krishnan to work with the
       authors of the recall draft on next steps.

Alexey: In progress.

     o Ignas Bagdonas to find designated experts for RFC 8520 [IANA
       #1141661].

Amy: This is on the telechat as a management item so it's provisionally done.

     o Adam Roach to find designated experts for RFC-ietf-sipcore-sip-push
       [IANA #1141663].

Amy: This is on the telechat as a management item so it's provisionally done.

     o Alexey Melnikov to find designated experts for RFC-ietf-core-object-
       security [IANA #1141664].

Amy: This one just came in and Alexey, you know you're on the hook for that?

Alexey: Yes.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-roll-useofrplinfo-25  - IETF stream
   Using RPL Option Type, Routing Header for Source Routes and
   IPv6-in-IPv6 encapsulation in the RPL Data Plane (Proposed Standard)
   Token: Alvaro Retana

This document has been deferred.

 o draft-ietf-manet-dlep-multi-hop-extension-06  - IETF stream
   DLEP Multi-Hop Forwarding Extension (Proposed Standard)
   Token: Alvaro Retana

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

Alvaro: No, I don't think so. The authors are engaged, and because it's very
similar to the other draft it should be fairly easy to resolve. So no, thanks.

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

Alvaro: Yes, it will be.

 o draft-ietf-dots-signal-channel-31  - IETF stream
   Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal
   Channel Specification (Proposed Standard)
   Token: Benjamin Kaduk

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

Ben: I believe most of it is going to be on the list with the authors. Let me
skim through; I forget if it was this document or the other one I had a few
things to comment on.

Alexey: I think we need to discuss port number.

Ben: Yes, that was one. And possibly also the happy eyeballs bit. Before we do
either of those, a quick thank you to everyone for all the review. Several of
the points that were brought up I tried to mention in my AD review and the
authors were telling me it was all good, and I'm not enough of an expert to
track everything down. So I appreciate the carefulness of the review. So let's
talk about port numbers. I know there was a pretty extended interaction through
IANA with the experts, and I don't really have a great conclusion myself as to
how necessary a dedicated port number actually is.

Mirja: I saw a reply from the authors come in but I didn't read it yet. The
discussion with the experts was more about usage of Coap and you don't need a
separate port number for that. There was some discussion among the expert team
and people disagreed. I'm happy to assign a separate port for the service;
however, I'm really wondering if a fixed port is actually needed or if a fixed
port might even be counterproductive, because that makes it easier to block
dots traffic.

Ben: Right. I think I mentioned the attack surface risk in my earlier review. I
do remember the authors and general WG being pretty strong in the sense that
the discovery solution for using a dynamic port number was not going to be
applicable to all of the use cases.

Mirja: I don't think it has to be dynamic, but there is an assumption you have
to pre-configure the IP address or some kind of information about the dot
server anyway. So if you have to provide this information pre-configured
anyway, you can also provide port information.

Ben: That's true, I guess having an assigned port number makes it easier to
pick one that's not going to conflict with anything else on your network. But I
don't know if we have an obligation to make things easy for deployment in that
fashion.

Mirja: The port numbers have been used to distinguish services in the network,
but it's very much discouraged to actually use port numbers that way because
it's not reliable anyway. Similarly, they allow to use other port numbers for
dot services as well so you can never rely on that.

Alexey: I tend to think that although this is using Coap, this is going to be
quite a different service, and implement different software.

Mirja: I agree to that point.

Alexey: I'd rather assign a port number, to be honest. And regarding that, it's
easier to block a known port number, I think the argument applies to https and
everything else, so it's not really a very strong argument in my book.

Mirja: No but http is quite generic, where this is a very specific service, so
there might be more interest in blocking it. As I said, it doesn't seem there's
actually any benefit to have a fixed number given they need to discover the
service anyway. However, I need to check the reply from the authors and I'm not
super blocking on this point. I think we can come to a solution but it probably
would require to mention the risk of blocking somewhere in the security section.

Alexey: That sounds fair.

Ben: We can definitely get some discussion of the security risks, if there's
nothing there already. I kind of thought there was, but it sounds like there's
not.

Mirja: I didn't see anything about ports in the security considerations
section. Okay, I will reply to the authors.

Ben: Thanks. Did anyone want to talk about happy eyeballs on the call, or leave
that to email?

Adam: It's probably an email thing. I raised issues related to it. I have some
concerns that the responses that I got from the author on the three discuss
points I raised were either dismissive or didn't understand the points I was
making, so I fear this may be a relatively long conversation and I might need
your assistance in mediating that.

Ben: I've only skimmed the email responses thus far but I have a similar sense
and I will attempt to help out and keep things productive.

Adam: Thanks.

Alissa: The answer I got about the MUST requirements with exceptions, which I
think is a problem because MUST should be an absolute requirement; he said that
he talked to you about it, Ben, so we can talk about it now or he can respond
on the list. That wasn't really an explanation of why MUST with an exception is
okay in this document but not typically.

Ben: I think we do have a fair number of examples of things we've published
that are, MUST do this in all cases except this one, and we've seen it with
various ways. But the general concept that the default is to do this and
there's a very specific exception we call out, has a fair amount of precedent.
I'm not super happy with the precise wording in this case, so I'm happy to see
you objecting to that, but I'm not sure if you're unhappy with the wording
specifically or the general concept.

Alissa: I think if MUST implies an exception, we should change 2119.

Barry: I don't think we need to. What we've often done in this case is say
SHOULD with the exception, and I think that's wrong. I'd prefer MUST, UNLESS. I
think that's a perfectly good formulation and to me fits right in to 2119.

Alissa: Okay, then we just disagree about that.

Barry: In this particular situation, rewording might be appropriate. I'm
talking generally.

Ben: I'm sort of with Barry; rewording in this situation is appropriate, but
I'm not sure we know what we want to re-word to. Perhaps we should take this to
the email.

Alissa: Okay.

Suresh: Regarding my Discuss, I think there's some conversation that needs to
go on, because I'm worried about the repetition of text from happy eyeballs and
it's hard to see what's new. I'll write it over email.

Ben: Originally they were not mentioning happy eyeballs at all, they were just
having some text description of a thing that looks very similar, and I asked
them to add the reference and say it's similar, but I guess I missed the part
where the happy eyeballs BCP is normative and we're doing different things.

Suresh: The question is, I want to know why happy eyeballs is not enough. I
think it's a simple ask but we'll see how far we go.

Ben: Yeah, it's a perfectly good ask.

Mirja: I also had a point on this happy eyeball mechanism. What they changed
is, instead of trying one after another, they try all simultaneously, and that
actually has implications on congesting the network or sending uncontrolled
traffic. However, they didn't respond to my message. They said it's discussed
in the other thread but I don't think it is.

Suresh: I told them the figure was wrong and they were doing things out of
order, and they said no they were doing it at the same time. I agree with you
Mirja, this doesn't address your point, but what is suggested as a response to
my comment saying the figure and the text disagree, it's not one after the
other, it's all at once.

Mirja: In the reply they gave to my Discuss they said this was addressed in
another thread, but it's not.

Adam: Mirja, I want to draw your attention to their response to my Discuss,
because when I pointed out happy eyeballs says not to send these
simultaneously, they said we need to because we're doing this during an attack,
so the notion is they want to make sure they're sending additional traffic when
the network is congested, which seems to make the problem significantly worse.

Mirja: I agree and I wasn't aware this was in your Discuss as well. I'll check
there.

Ben: So we definitely have a lot of email discussion to keep going, but it
sounds like we should go on to the next one, which is more of the same.

Amy: It sounds like this is going to require a Revised ID. With that we'll move
on.

 o draft-ietf-dots-data-channel-28  - IETF stream
   Distributed Denial-of-Service Open Threat Signaling (DOTS) Data
   Channel Specification (Proposed Standard)
   Token: Benjamin Kaduk

Amy: I have a number of Discusses.

Ben: Again, I think we're going to need a fair bit of discussion in email with
the authors. With respect to the flags bitmask being 1 byte or 2 bytes, I do
remember looking at that and I was pretty sure there was an implicit length
somewhere that would let you know which encoding was used, and they have some
text about if you only have the one byte encoded, it's the byte that's pretty
dense in flags, and you ignore the byte that only has one or two flag bits. But
I did not get a chance to double check that before the telechat. Were there any
topics people wanted to discuss today or should we keep it in email?

Mirja: I didn't really understand why they need this bitmask at all. I don't
know if you want to explain it to me or if I should keep talking with the
authors. I understand the intention but I think it's only an implementation, I
don't think they need to change the Yang model.

Suresh: I agree with you, Mirja. And if they have it specified they need to do
a better job. I think if it needs to be there, better specification is
required. I have no idea how I would set this yang model to do what I want.

Ben: I don't think I can give you a quick explanation on the call, so I think
we'll have to do this over email.

Mirja: That's fine. Thanks.

Amy: Again, it sounds like that will require a Revised ID?

Ben: Yes.

 o draft-ietf-netconf-subscribed-notifications-25  - IETF stream
   Subscription to YANG Event Notifications (Proposed Standard)
   Token: Ignas Bagdonas

Amy: It looks like I have a number of Discusses; do we need to discuss any of
those today?

Ignas: I think the authors are engaging quite well with this. Magnus, if you
would like to talk about your congestion topic. We had quite a few discussions
previously, at the retreat and before that, and I think that both the authors
and I tried to explain the viewpoint of how all of the manageability system is
being built. There are two parts: one that was specified in the protocol
specifications, and the other that is implementation. Many of the aspects you
raise in your Discuss fall more into the implementation aspects. Would you
prefer to discuss this or leave it for the authors to address?

Magnus: There's one aspect I would like to discuss, and that has to do with the
intention to have any type of priority signaling from the receiver towards the
publisher about how important the view their subscription. I think that'a a
core part, if that matters or not.

Ignas: If I'm talking from the actual user of this technology point of view,
and that comes to a practical deployment, I don't see this as important and
that's not necessarily the way things are being deployed. From a theoretical
point of view, there appears to be a need to have ability to prioritize certain
events. A practical way of doing this to have two signaling channels, one for
one priority and the other for the other priority, and that's how that has been
used for a long time. What they want to have as a functionality adds complexity
quite substantially, with probably somewhat questionable gain.

Magnus: My concern here is that if what you're saying now matches that
perspective that there's an explicit dependency on what's called the dscp field
to indicate that priority, that's not really what the dscp says. There's a
coupling in here of something that's not actually coupled in that way. I think
it would be good to clarify that aspect of it. I just want to have some clarity
in how this thing is intended to be used.

Ignas: I think that's a very fair request. Let's ask the authors to clarify the
details then.

Magnus: Okay.

Ignas: For the rest of the Discusses, I think the authors are discussing those.
Unless anyone would like to discuss something right now. If not, then that
would definitely be a Revised ID Needed.

 o draft-ietf-netconf-yang-push-23  - IETF stream
   Subscription to YANG Datastores (Proposed Standard)
   Token: Ignas Bagdonas

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

Ignas: I'm not certain. A quick answer to Ben's comment about seven authors;
this has been discussed with the authors. I have reviewed their level of
involvement. Two are more involved than the other five, and the suggestion was
to move those to editor and the rest to contributors. We'll see how that goes.
As responsible AD I can share that all seven of the listed people have been
involved in the process. I was not happy to see seven there but if they insist
I would probably not be blocking that too much.

Ben: That part was sort of pro forma. I'm happy to not discuss it but we do
need to acknowledge it. I did have this other point about the indications of
support for on-change notifications at a object granularity. It's pretty weird
for me to be seeing and talk about it's the responsibility of people to ensure
this is going to happen when we are not covering any ways for that to happen in
the current document. It's left very open ended how that is going to happen.

Ignas: That was left vague intentionally by the authors. This has been raised a
couple of years ago on the sensibility side. What if we put into the Yang push
mechanism everything we can imagine from a telemetry side; that is not going to
happen in practical terms. I'm not certain I have a direct answer for this
right now. Personally I would be objecting to this but that's for the authors
to say.

Ben: So you want to take it to email?

Ignas: Yes.

Ben: I'm happy to do that.

Ignas: This one will be revised ID too.

 o draft-ietf-core-multipart-ct-03  - IETF stream
   Multipart Content-Format for CoAP (Proposed Standard)
   Token: Alexey Melnikov

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

Alexey: Yes, very briefly. Starting with Magnus. Magnus, there were responses
from the WG that recursion is intentional. Are you happy to clear, or would you
like some text to be added?

Magnus: In some sense I'm happy to clear, it would just be good to be explicit
about it.

Alexey: If you clear and make it a comment, I'll make sure it's addressed.
Thank you. Ben, just want to double check: did you see my followup discussion
about different use cases and trying to rationalize and distinguish
multipart/mixed where basically different parts equivalent in how they can be
used.

Ben: I did see the response but I'm not sure I have fully internalized it yet.
I do appreciate the multipart/mixed vs multipart/alternative. I think I'm
willing to accept your better experience about whether these are actually
useable in the current form, because I don't deal with multipart/alternative or
multipart/mixed much myself.

Alexey: I think I would like to follow up with the WG because I think multipart
alternative has different semantics and it would be important to know the
difference.

Ben: I'm happy to see that happen.

Adam: I had some vague misgivings along that line also, and the base mime has
several different things that fall under the same bucket. I had a hard time
putting together a concrete objection. If you can get this clarified, Alexey, I
think it would be great.

Alexey: Okay. I think this will need a new revision.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 o draft-housley-hkdf-oids-01  - IETF stream
   Algorithm Identifiers for the HMAC-based Extract-and-Expand Key
   Derivation Function (HKDF) (Proposed Standard)
   Token: Benjamin Kaduk

Amy: I have one open position for Eric. Did you want to state a position on
this document?

Eric: You said Eric?

Amy: I don't have a position for you in the tracker. You can decline to state a
position if you didn't get to it.

Eric: I had no time to do it.

Amy: No problem. There are currently no Discusses, so unless there's an
objection now it looks like this one is approved. Ben, there are no notes in
the tracker; is this ready to go as is?

Ben: It's ready to go.

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-sidrops-lta-use-cases-06  - IETF stream
   Use Cases for Localized Versions of the RPKI (Informational)
   Token: Warren Kumari

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

Warren: Yes please. I've looked through the Discusses and something I think is
possibly helpful to clarify is I think this is very different from the TLS man
in the middle type position. Largely because the RPKI, or the use of this,
doesn't involve encryption at all. I think this is much more similar to things
like DNSSEC, where an individual resolve operator can choose to accept a name
which shows up as DNSSEC bogus by installing a local trust anchor or a negative
trust anchor. This sort of use is specifically to take a route which is invalid
for some reason, but which the network operator thinks they would like to
accept anyway. So it in no way involves unencrypting stuff or exposing info,
it's more that I think the results of the validation are not correct and I
would like to override it using some method. I'm not sure if that helps clarify
on that particular point.

Roman: It doesn't help me so much primarily because the use case doesn't
describe it as such. The use case seems really clear about who's shunting the
traffic and what kind of traffic it's shunting, and I agree it's perhaps not
exactly man in the middle, because it's the routing fabric that's doing it, and
given how the use case kind of heated up I don't see any discussion relative to
the security considerations on what that means for the user's traffic and all
the end to end properties.

Warren: Okay. I'm thinking how we address that. Currently the way it works is
people just accept whatever routes come along. Moving to an internet where
people use the RPKI is a definite security win, but a number of people are not
doing it because it's unclear how you override when the RPKI fails or doesn't
do what you currently use. Currently people have complex policies for what
routes they will or will not accept and people will not move to them because
they need a way to override when this doesn't work. Another example is there's
no current way to do stuff like RFC 1918 in a sane manner. I guess we will need
to discuss it more.

Mirja: I don't really see a value of describing those use cases in that detail
and picking the specific cases and having them in the document. It would be
much more useful to describe the generic mechanism as you did, and leave it
open.

Ben: I'm not objecting to people having local overrides in general. I
understand there are definitely cases, especially in the 1918 address space,
and probably more as well, when you need to do this. I'm just uneasy with the
way the document is presented and it seems to give a biased perspective in that
it's promoting these specific handpicked use cases, when there are potentially
many possible use cases, and it's not giving a clear discussion of the
technical details of what are the implications of doing this and what are the
risks you take on.

Warren: Okay. I guess we're going to have to have more discussion with the
author. Hopefully I can take some of the comments from the call and relay back
to explain how the document could possibly be made something people would be
okay with. Thanks. We can move on.

Amy: It sounds like this might need a Revised ID?

Warren: Oh yeah.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-nottingham-safe-hint-00
   IETF conflict review for draft-nottingham-safe-hint
     draft-nottingham-safe-hint-09
     The "safe" HTTP Preference (ISE: Informational)
   Token: Barry Leiba

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

Barry: We do. In response to Alissa's comment in her Abstain, Adrian already
expressed willingness to work with us on text that makes it clear this is not
an IETF consensus document. I think it's appropriate to work with Adrian on
that. I think it pretty much covers Alvaro's Discuss if we do that; Alvaro, do
you think it does?

Alvaro: Yes, it does. Or, it will.

Barry: There is whether we have standing to hold a Discuss on that issue, but I
don't think we need to go to that bit of process at this point because Adrian
has agreed. For Mirja's Discuss, I think that's more general. This is kind of
exactly what the independent stream is for; the httpbis WG discussed this and
ultimately decided not to take it on; we have a mechanism for publishing
documents as RFCs outside the IETF stream. Unless we can argue that this harms
something, I think we don't have standing to block it.

Mirja: We don't have standing to block it anyway, it's the ISE's decision. I
think it's the wrong conflict review. Because if this was brought to the IETF
and there were concerns about publishing this document, we should mention there
is a conflict. That doesn't mean that Adrian cannot decide to publish it
anyway, but I think it's the wrong response to the conflict review.

Barry: Which response would you use? The choices are in the agenda.

Alissa: That's why I balloted Abstain, because none of the choices fit.

Barry: I agree that if you don't think 2 is appropriate, the others aren't
appropriate either. I'll just read the others: The IESG has concluded that
publication could potentially disrupt the IETF work done in some WGs, and
recommends not publishing.

Mirja: I'm looking at them myself now. I guess 3 could apply, because it was
discussed in the WG and the WG had concerns about it.

Barry: As I read 'disrupt,' I don't think that fits, but I understand what
you're saying.

Alvaro: What I want to ask is, this document already came through the WG, and
it came to the IESG. I found the old ballot; some discusses, some abstains, why
wasn't it published at the time?

Barry: We can certainly throw that at Adrian and have him chew on it. The main
issues were that the definition of safe is vague and there can't be a
consistent usage of safe. You don't know whether what you get back is safe or
not; all you're doing is asking that the responses be safe with no verification
that they are. Those were among the main concerns when it went through before.
This is actually in use, and it proves to be useful, which is the reason Mark
is pursuing getting this documented and having the header field put in the
registry. Everyone understands it's a best effort thing and the definition of
safe is very server dependent, culturally dependent, whatever, but it is doing
what it's intended to do in the cases where its used. That's the argument for
it.

Mirja: Is it used by multiple vendors?

Barry: Unfortunately I don't have the details of how many implementations there
are.

Alissa: There's an implementation list in the document. I didn't follow the
links.

Barry: The reason I agree it should not be standardized as an IETF standard is
that it's not an interoperable thing, other than interoperating and sending the
hint. I do think it's useful to publish the practice and reserve the header
field, and that's what the document is doing.

Mirja: This is not a standard, right, it's an informational document.

Barry: It's not in the IETF stream and I absolutely agree with Alissa's comment
that it would be good to make it extremely obvious in the header or
introduction of the document because it will otherwise look like an IETF
standard.

Mirja: I would actually prefer to publish this in the IETF stream, because then
it's under our control to make absolutely clear in the title, in the abstract,
in the introduction, that this is only to document the current deployment
status.

Barry: We do have standing to put an IESG comment in, that Adrian would be
required to include. I'd prefer to work with Adrian on text he agrees with, but
if the result is not something we're happy with, we can put in an IESG comment.
We've tried publishing this in the IETF stream and you know the result, we had
too much pushback and it went away.

Alvaro: Pointing at some issues in the last ballot would be useful beyond
saying just that this is not an IETF document.

Barry: I agree with that, and that's something we can try working out with
Adrian.

Mirja: I'm still not sure about the process as applied here because there is a
possibility to publish documents on the IETF stream without IETF consensus,
because it's an informational document. So there would have been another path
that could have been taken.

Barry: There is theoretically that, except we have not used that for years. We
do Last Call all informational documents, and they're all approved by the IESG.

Alissa: We almost did it with mmwg-encrypt.

Barry: So we do occasionally, then. I would rather not see this published in
the IETF stream because of the pushback we've had, which are legitimate
concerns.

Mirja: Because this document was brought to the IETF process and got so much
pushback, I think saying there's no conflict is not the right reply.

Barry: I don't see how I can honestly say number 3.

Alexey: There is no current work on this in IETF, so there is no conflict with
the current work and no planned work to address this same use case.

Barry: And I don't see this as disruptive of the work happening in httpbis, and
in fact I want to see it published, I don't want to recommend that it not be
published. I want to recommend that we have text in there that makes its status
abundantly clear. What I was going to say we should do is that I'd like to have
at least one of you hold our discuss for now, and let me work with Adrian and
Mark on some text that can go into the document and report back. Is that
acceptable?

Alvaro: That works for me.

Mirja: Yes.

Barry: If you want you can both hold your discusses. I'll get back with both of
you after I talk to Adrian.

Mirja: If everyone else agrees this is the right conflict review response, I
will resolve my discuss.

Barry: Okay. Does anyone other than Mirja think we should be using a conflict
review response other than the one we're using?

Suresh: I have not balloted on this because I kind of agree with Mirja's point.
There are a couple of things I want to bring up. One of them is the preferences
registry does not require an RFC be published to get this. I'm not fully
convinced this needs to get published. All they need is a registration so we
could leave this as a draft and that could be used to allocate the entry in the
preferences. The part that worries me, I don't know how to put this in a way
that's very clear, but the document looks awfully lot like a standards track
document. It's got 2119 language, and I'm really worried about people getting
confused by this document. If that's something you can work on, I would be okay
if it said there's a thing called safe, and these people have implemented it,
and it's used for parental control, is better than actually saying a proper
normative way of doing things.

Barry: Two things there; one is that I really don't like having long-lived
drafts, at least until we get to the living documents thing. I would not like
to have this live as a draft and I think it should be published somewhere, even
if it's just a Mark Nottingham blog post. Second, we have a lot of independent
stream documents that use 2119 language and reference 2119. I don't see that as
a problem as long as the status is clear. i don't think we should put whatever
we put in the boilerplate, I think I needs to go in the introduction where it's
more obvious and people are going to read it.

Suresh: That sounds good. If you want I can propose some text. I worked on some
conflict review text for the IESG and if you want I can put that in a ballot.

Barry: Sure, that would be useful.

Mirja: I'll hold my discuss until we know what we want to put in there.

Barry: I think that's fine. Any other discussion?

Alissa: If we could just talk about the note for as second; it wasn't really
clear to me from the ballots. If people want to talk about how the semantics
are not agreed or understood, that would also be a useful thing to say in the
note.

Barry: I agree.

Mirja: I'd like to see a note that said this document was discussed in the IETF
process and was rejected for this reason.

Barry: Let me see what we can work out with Adrian and Mark and I'll bring the
results back. Amy, I think we're done.

Amy: I think this is the equivalent of AD Followup because it's going to be
ongoing.

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 Autonomic Networking Integrated Model and Approach (anima)

Amy: I have a couple of Blocks on this recharter. Do we need to discuss those
today?

Ignas: Probably, if the block holders would like to. There is some engagement
from the WG chairs and they addressed some comments, some are still open.
Overall it seems the charter will need some work on codifying details.

Martin: From my part, I'm in discussion with the chairs and I believe it should
be resolved fairly easily. I don't think we need to discuss it here.

Magnus: I would like to discuss Alissa's second point. I interpret a charter as
allowing anything matching the current framework is fine, and I think that is
too wide.

Ignas: I would tend to agree it is quite wide. Historically, anima has been
branched from nmrg and it still has quite a lot of history of being run as a RG
and not necessarily a WG. Their topic is much more experimental than something
tangible, so from that point, the charter is quite broad. Whether it is too
broad, given the current developments in the next steps of BRSKI, so the
profiles of BRSKI usage, and that will be the main work target for a couple of
years. I think the WG will be busy on that topic and not necessarily look
elsewhere.

Magnus: But this work is still targeting proposed standards and not
experimental specifications.

Ignas: Some of them will be Proposed Standards, yes, although I believe the
bigger part of the work will not result in documents as such. That will be
either extensions to the BRSKI, or some use cases of it.

Alissa: If that's what people expect to focus on, and that's where the
deployment effort is going to be, wouldn't it make sense to scope the charter
to what people will work on and reevaluate the charter after that?

Ignas: Probably, but there is one tiny problem. The BRSKI developments
happening is mostly what we are talking about right now. They wanted to have a
BOF, they were not ready, and most of the proposals being drafted will be after
the Montreal time frame when something more concrete is available. There's
little tangible to be put into the charter at this point in time. We have two
options: one is to wait until after Montreal to see if something can go in, or
we leave the charter rather open to allow that work to get in right now.

Alissa: I guess I don't really see the rush, if they managed to do BRSKI itself
under the old charter.

Ignas: BRSKI was specifically listed as one of the deliverables.

Alissa: It seems like they could do their BOFing and then it would be more
clear what should be in scope.

Ignas: Probably.

Alissa: I think that's preferable. The point of the charter is to help people
focus, and all be talking about the same set of problems. I think that would be
better.

Ignas: Understood. From a focus perspective, anima historically has not that
much focus. It's a broad group trying to cover many things and that is one of
the reasons there are no specific deliverables. It's not known a few meeting
cycles in advance what the next interesting topic for the WG will be. So one
other comment for Deborah, you asked what about operated by professionals. This
is to differentiate from the homenet. Anima will specifically not look into the
topics that homenet is trying to do.

Deborah: But it needs to be clarified. The original was very clear; just saying
managed by professionals is not the definition in the framework. Either they
should go back to the original two paragraphs, which was very clear, or they
use something like what's in the framework document.

Eric: On the homenet side, while it contains the word home, it's also
applicable to very small enterprises with a couple of routers. So professional
small business would use homenet if it exists.

Ignas: That's a different interpretation of the word professional. In anima's
context it means managed professionally by somebody. Whereas home net is not
necessarily managed at all.

Magnus: I agree. So call it managed.

Deborah: It's probably just English. Professional can be interpreted many
different ways and it's just not a good descriptive word here.

Ignas: I get the point. So from the comments it seems the charter needs to be
reworked, and I'm not certain which state that should be.

Amy: I think it's just that we're waiting for instructions from you, so it will
sit until you're ready.

 o Limited Additional Mechanisms for PKIX and SMIME (lamps)

Amy: It looks like the choice is external review, is that correct?

Roman: Maybe I hit the wrong button. I'm not sure what I want. It's ready to
go, so external review means what?

Amy: When you're rechartering a WG, there are two choices you make at the
beginning: one that the changes to the charter are so small we can approve
this, and the other is a more significant change so it has to go for external
review before we come back and approve it.

Roman: Okay, so I picked the right button.

Amy: I have no blocking comments for external review so it looks like that's
ready to go, and we'll get that sent tomorrow.

4.2.2 Proposed for approval

 o JSON Mail Access Protocol (jmap)

Amy: I had a block that may have been cleared. So it looks like there are
currently no blocks and unless there's an objection now, this one is approved.
Hearing no objections, so this is approved and we will get that in production.

5. IAB news we can use

Mirja: The workshop I announced last time, which will happen on June 4 and 5 in
Finland, the deadline for submission is still open. Because there's a
Backstreet Boys concert they will release hotel information soon and you'll
probably need to book fast to get a room. The second item is that they are
organizing another workshop called ESCAPE, which stands for Exploring Synergies
Between Content Aggregation and the Publisher Ecosystem. That will be held in
Virginia in the US just before the Montreal IETF meeting. The goal here is to
get people into the room who usually don't come to IETF from the publishing
business an talk about the web ecosystem. The call for this workshop should
have gone out yesterday and there's also a blog post on the IETF website
following in a couple of weeks. That's it.

Alissa: The hotel info for Helsinki is on the workshop page right now.

6. Management issues

6.1 [IANA #1137877] Upcoming Parameter Expiration: Early IANA Allocation for
RFC 8111 (IANA)

Amy: It looks like we need IESG approval for a second renewal of this, is that
correct?

Michelle: That's correct. Deborah already indicated that we should get the
additional year renewal, so per the instructions in the RFC we just have to get
the IESG to approve that.

Deborah: I recommend approval because this is already done and in the RFC
Editor queue. It's just waiting for its references.

Amy: Any objection to approving the renewal? Hearing no objection, so this is
approved.

6.2 [IANA #1141661] Designated experts for RFC 8520 (Ignas Bagdonas/IANA)

Amy: We are here to approve Eliot Lear and Dan Romascanu in these roles. Any
objection to approving them? Hearing none, so they are approved.

6.3 [IANA #1141663] Designated experts for RFC-ietf-sipcore-sip-push (Adam
Roach/IANA)

Amy: This is to approve Christer Holmberg as a designated expert. Any objection
to approving them? Hearing none, so they are approved.

6.4 [IANA #1141664] Designated experts for RFC-ietf-core-object-security (IANA)

Amy: This was assigned to Alexey at the top of the call and we will move on.

6.5 [IANA #1139586] Designated experts for RFC 5580 (Ben Kaduk)

Amy: This is to approve Alan DeKok and Mohit Sethi as designated experts. Any
objection to approving them? Hearing none, so they are approved.

6.6 [IANA #1137011] Listing RFC 6281 as service name reference (IANA)

Deborah: Mirja, you responded to Amanda saying that maybe IESG shouldn't be the
assignee?

Mirja: My understanding was that because it was an informational document it
should not. I don't know if Magnus has had a look at this. Those are assigned
on a first come first served basis so I think it's less important to have the
IETF as the assignee there.

Michelle: So we can go ahead and use the original assignees that were
submitted, then we don't need the IESG to approve anything and we can mark this
as done.

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