Narrative Minutes interim-2021-iesg-17 2021-08-12 14:00
narrative-minutes-interim-2021-iesg-17-202108121400-00

INTERNET ENGINEERING STEERING GROUP (IESG)

Narrative minutes for the 2021-08-12 IESG Teleconference

These are not an official record of the meeting.

Narrative Scribe: Liz Flynn, Secretariat

1. Administrivia

1.1 Roll call

ATTENDEES

---------------------------------

Jenny Bui (AMS) / IETF Secretariat

Michelle Cotton (ICANN) / IANA Liaison

Roman Danyliw (CERT/SEI) / Security Area

Martin Duke (F5 Networks Inc) / Transport Area

Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe

Sandy Ginoza (AMS) / RFC Editor Liaison

Benjamin Kaduk (Akamai Technologies) / Security Area

Erik Kline (Google) / Internet Area

Murray Kucherawy (Facebook) / Applications and Real-Time Area

Mirja Kuehlewind (Ericsson) / IAB Chair

Warren Kumari (Google) / Operations and Management Area

Alvaro Retana (Futurewei Technologies) / Routing Area

John Scudder (Juniper) / Routing Area

Amy Vezza (AMS) / IETF Secretariat

Martin Vigoureux (Nokia) / Routing Area

Eric Vyncke (Cisco) / Internet Area

REGRETS

---------------------------------

Ben Campbell (Independent Consultant) / IAB Liaison

Jay Daley / IETF Executive Director

Lars Eggert (NetApp) / IETF Chair, General Area

Cindy Morgan (AMS) / IETF Secretariat

Francesca Palombini (Ericsson) / Applications and Real-Time Area

Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area

Robert Wilton (Cisco Systems) / Operations and Management Area

OBSERVERS

---------------------------------

Toerless Eckert

Adrian Farrel

David Millman

Lee-Berkeley Shaw

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 the minutes from the July 15 telechat
being approved? Hearing no objection, so it looks like those were approved. We
also had final narrative minutes; any objection to approving those? Hearing no
objection so it looks like those are approved as well. We will get those posted
in the public archive.

1.4 List of remaining action items from last telechat

     o Warren Kumari, Deborah Brungard, Stephen Farrell, and Jay Daley to

       investigate ways to recruit, recognize, and retain volunteers in the

       IETF.

Warren: At this point I think let’s just remove this from the to-do list. We
were doing something but I think EMO-DIR is taking it over.

Amy: Okay, we will drop that action item.

     o John Scudder, Martin Duke, and Robert Wilton to review the document

       shepherd templates and propose changes to include updated questions,

       cross-area checks, and an expanded section on the use of YANG models.

John: No updates on this.

     o Alvaro Retana and Martin Vigoureux to draft a note to wgchairs

       asking them to always confirm author/contributor status.

     o Alvaro Retana and Martin Vigoureux to draft text to include in the

       I-D submission tool warning about too many authors.

Alvaro: These two are pending; [we’re waiting on the previous item to be done
first.]

     o Eric Vyncke and Francesca Palombini to draft text for guidelines/

       best practices for directorate reviewers.

Amy: I know work has been done on this; is it done?

Eric V: No, we still need to complete it but we are on vacations now. It’s in
progress but not finished yet.

     o The IESG to report on the RFC 8989 experiment after the 2021 NomCom

       is seated (likely July 2021).

Amy: The 2021 NomCom is seated; any report on this? Is this still with Lars?

Alvaro: I thought I saw something on a list, or he showed some slides at the
plenary?

Amy: Right, but I’m not sure if the action item is done. Let’s keep this here
for Lars and he can let us know.

     o Murray Kucherawy to update BCP 97 to provide guidance about handling

       normative references to non-SDO documents.

Murray: I don’t have anything to show yet but I’ve started working on text. In
progress.

     o Murray Kucherawy to find designated experts for RFC 9036

       [IANA #1199105]

Murray: I believe I have that; can you add a management item at the end to deal
with this?

Amy: Okay, sure.

     o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to

       the IESG on the impact of COVID-19 to the IETF in July 2021.

Amy: This one is done; did you want to keep this and roll it over from July to
October?

Warren: Let’s change the date.

     o Lars Eggert to update BCP 45.

Amy: We’ll keep this in progress for Lars.

     o Lars Eggert, John Scudder, Ben Kaduk, Mirja Kuehlewind, Murray

       Kucherawy and Warren Kumari to work on short-term improvements to

       "IETF Culture, Toxicity, Inclusion."

Mirja: I think we’re still waiting for Lars to schedule a meeting.

     o Eric Vyncke, Lars Eggert, and Rob Wilton to work on improvements to

       authoring and reviewing tools.

Eric V: It’s lingering, but it’s still a work in progress. Expect something
when I’m back from vacation.

     o Francesca Palombini to find designated experts for RFC 9039 [IANA

       #1201198].

Amy: We’ll keep this here for Francesca.

     o Murray Kucherawy to send the proposed updates to the I-D checklist

       out for community review.

Murray: No update since the last telechat; now that I’m back I’ll send this to
wgchairs today or tomorrow.

     o Francesca Palombini to find designated experts for RFC 8984 [IANA

       #1205430].

     o Francesca Palombini to find designated experts for RFC 9073 [IANA

       #1206462]

     o Francesca Palombini to find designated experts for RFC 9074 [IANA

       #1206466]

Amy: These are all for Francesca and she’ll pick those up when she’s back.

2. Protocol actions

2.1 WG submissions

2.1.1 New items

 o draft-ietf-6lo-plc-06  - IETF stream

   Transmission of IPv6 Packets over PLC Networks (Proposed Standard)

   Token: Erik Kline

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

Erik K: Perhaps, if people want to. The authors don’t seem to have replied to
any comments this week, so I don’t know if we should just wait for them to have
a chance to reply. I am trying to figure out what level of access folks had to
the various PLC specs during authorship and review. I assume the authors had
access. This is a persistent problem, though. I need to figure out some
repeatable approach.

Murray: My action item to deal with BCP 97 comes from the fact that we keep
running into this.

Erik K: Is that something with which I should help?

Murray: I don’t think it will help you at this point; I’m more being
sympathetic.

Erik K: This group in particular does work at this interface boundary, between
the IETF and other people’s link layers.

Warren: One of the things I think we keep noticing with this particular problem
is that there are sets of people in the IETF who participate in multiple
standards groups and they are the ones who need to know and understand this.
For example, people who are going to implement this presumably already work
with PLCs and already have access to the PLC knowledge and data set. However,
other people don’t. So whenever we do update the guidance, I think we are going
to have to keep in mind that there are sets of people who participate in both
places. As long as the people who are going to implement it are likely to have
knowledge of the space or access to the document, that’s the important part.
And presumably the IESG for when they review the document. Murray, I'm happy to
help with the writing of the new guidance, but we might want to ask the
Secretariat to please add me [to the action item] because otherwise I will
forget.

Murray: I’m happy to have the help. It doesn't matter to me if you want to
actually get listed as someone who needs to get pinged about it or if I just
ping you about it.

Warren: That’s easier. Thanks everybody.

Amy: I’m happy to add you to that action item, Warren, if you like. Getting
back to the document, it sounds like it’s going to get a revision.

Erik K: With any luck, yes.

Amy: This will stay in IESG Evaluation, Revised ID Needed.

 o draft-ietf-rtgwg-policy-model-30  - IETF stream

   A YANG Data Model for Routing Policy (Proposed Standard)

   Token: Alvaro Retana

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

Alvaro: We’re going to need a revised ID on this one.

Amy: This will go into Approved, Announcement to be Sent, Revised ID Needed and
Alvaro, you can let us know when that’s ready.

 o draft-ietf-httpbis-cache-header-09  - IETF stream

   The Cache-Status HTTP Response Header Field (Proposed Standard)

   Token: Francesca Palombini

Amy: I have no Discusses in the tracker, so unless there’s an objection it
looks like this one is approved. Hearing no objection to approving this. We’re
going to put this in Approved, Announcement to be Sent, AD Followup, because
Francesca could not be with us today and we generally let the AD check
everything over before we send it.

Ben: Mark has been pretty good about making updates to the draft in Github, so
I expect there will be a revised ID, but AD Followup sounds correct.

 o draft-ietf-6man-ipv6-alt-mark-08  - IETF stream

   IPv6 Application of the Alternate Marking Method (Proposed Standard)

   Token: Erik Kline

Amy: I have mostly Discusses for this document. Do we need to discuss any or
all of these today?

Erik K: I suspect people have things they’ll want to say.

Murray: I’ll start. This is the first time I've looked at a document that has
IPR declarations on it but the shepherd writeup says explicitly that they were
never discussed by anyone. I placed a Discuss because I just want to ask all of
us, doesn't there have to be some kind of discussion at least for the WG to
concur that there are no problems with what the licensing and terms are? It’s a
positive statement that the WG ignored this, and that scares me.

Warren: From my understanding, the WG doesn't need to discuss or acknowledge
it, it simply needs to be informed that there is IPR. With that said, I think
it’s probably not a good thing if the WG says there’s an IPR declaration but we
don’t really care. So I don’t think it’s strictly a process violation, as long
as the WG was informed, which I think it is because that happens through the
tool.

Murray: If that's just my misunderstanding of this, I’ll clear now. I just
remember every time I've ever been part of a WG where there has been one of
these, there’s been discussion like do we care, should we look at something
different, etc. The way that this presented itself just scared me.

Warren: I suspect that maybe the fact the shepherd explicitly noted that was
their way of calling out that maybe it should have been discussed.

John: As far as I can tell it really depends on WG culture. I can point to some
WGs where it’s pretty common for there to be IPR that’s not discussed. I’m not
saying it’s a good thing, but it’s allowed under our process.

Murray: I did look it up in BCP 79 and I realize there’s nothing normative that
says you have to go back and deal with this, the whole thing just scared me.
I’ll back down.

Erik K: I haven’t attempted to read the actual IPR statements but my
understanding for this document is that basically the 6man document is defining
a header option. Whatever the magic loss and congestion stuff you do with it is
not really what this document is about, it’s referring to other documents that
define those techniques. This is a hop-by-hop definition mostly. But like I
said, I haven't read the IPR declarations.

Murray: I’ll pull [my Discuss] off. Thanks for indulging me.

Warren: I think a number of the Discuss things are actually around the whole
limited domain bit. My Discuss point was that it feels as though you’ve just
waved the limited domain flag and said nope, i’m opting out of any
consideration as to what might happen if somebody spoofs that. The author’s
response to my question was largely along the lines of ‘the document says you
can only insert this if you’re within the control domain, so problem solved,’
which to me feels like it’s completely missing the point. Either the author
hasn’t actually understood the concern or what I think is more likely is people
are viewing it that we said that you can only do this in a limited domain, so
people aren’t allowed to send them from outside the limited domain, and
therefore never will. I don’t know what we do about that.

Eric V: I have the opposite position there. For me it can work across different
domains without causing any harm. If someone is injecting packets, even in the
hop-by-hop, they will be killed quite quickly. Nobody will ever be harmed and
you may reach the same organization on the other side and save some data. For
me it could work across multiple domains.

Warren: Maybe. The document says ‘do not send this outside the control domain.’
It says bad things will happen if you do. You can’t do it both ways.

Erik: He did try to soften a section, during IETF last call I said this don’t
send it outside the domain thing is, as Mark Smith said, somewhat aspirational.
Someone might, either on purpose or by accident, so if you did want to use it
outside, that’s why he added the text about using an authentication header with
the destination option if you want to attempt to make any use of this.

Roman: But that threaded language is a bit tricky because I don't know how to
mix that you  must not send outside, but if you do or by accident, you should
also do the following. So you’re pretty much acknowledging that it’s not a
limited domain because you’re providing normative guidance if you break the
guidance of putting it outside. I don’t know how to combine those.

Eric V: The ambiguity is pretty strong there. I agree, it needs to be fixed.

Warren: It also says ‘the precondition for the application is that it MUST be
applied in a specific control domain, thus confining the potential attack
vectors within the controlled network domain.’ If this gets implemented, I
certainly don’t want people sending packets through my network causing my
routers to do all of this work. It becomes a really great DOS vector. People
will start sending these packets with this hop-by-hop option set on all traffic
and suddenly my router has to process all of that.

Erik K: They can already attempt to send all manner of things.

Warren: Sure, but most of the extension headers, if they’re hop-by-hop, I can
simply say I don’t like that and I’m going to ignore it.  It’s not implemented.

Erik K: Why can’t you ignore this also?

Warren: Because I manually need to now go in and go through all of my filters
and say if it’s this hop-by-hop option, you have to drop it. This is either
going to end in one of two cases: all networks drop all hop-by-hop options at
their edge, or operators are going to have to gotten through and list every new
protocol that has something like this and blacklist each hop-by-hop option one
by one.

Erik K: Or allow list the options they do wish to permit.

Warren: Sure. so what you’re doing is either causing operators to do a bunch of
work, and you’re going to end up with ossification. Certain sets of protocols
will work through some sets of networks because they've manually been
whitelisted or blacklisted, or people will just drop them all.  I suspect the
answer will be that people will just drop them all, and I don't think that's
what we want to be moving towards.

Erik K: I don't think you can get to a world where they're all allowed, so I
don't see how you get to any other world where you both have hop-by-hop options
and do not have people granting the equivalents of allowed ports.

Warren: Then what's going to happen is people will implement a list of allowed
ones, like number 17 and number 42, and you'll never be able to define a new
one ever again because they won't actually work across the internet. What
you've basically ended up with is if we deploy more things like this where it's
simply expected that the router will process the packet because it's got the
specific hop-by-hop option, it's never going to be deployable across the
internet. It's just going to end up with the three allowed hop-by-hop options
and ossification of stuff, in which case, why are we even bothering with
hop-by-hop.

Erik K: To be clear, I don't think it actually could be expected to be used
across the internet.

Warren: This can't be. My point is that this creates it so that there will be
filters and only the specific allowed ones will happen and new ones won't be
able to work either.

Erik K: This argument applies to all of the hop-by-hop option work in 6man,
then, including the MTU option.

Warren: A fair bit of it. Stuff like this will make it so that other more
useful ones, like MTU, aren't likely to be deployable because it drives people
to simply have a whitelist of allowed. That's not going to be updated across
all operators all the time. Unless we start having ways that protocols make it
so that people can tell which hop-by-hop option should be allowed, or that the
hop-by-hop option is authenticated in some way, like for example it comes in
with a magic cookie, this basically is going to make it so hop-by-hop options
aren't going to be usable.

Erik K: I think the only way you could try to retain any of the usefulness
within a limited domain is to apply a filter at the edge.

Warren: Okay, so I apply a filter at the edge that says I allow this one and
this other one and a third one, and then when the IETF publishes five more RFCs
I'm never going to get around to updating them ever again.

Eric V: But there are two points. It's not only about allowing the transit of
the packet, it's passing it and processing it, that's more complex or even
easier, depending on how you want to look at it. There is no point for a
transit AS, right? You have a hop-by-hop, I'll completely ignore it, but I'll
forward it.

Erik K: My point about the filtering at the edge was that would be the only way
you could attempt to enforce that things don't leave your network and that
things don't enter your network that you aren't expecting.

Warren: Sure, but what you're saying is that either everybody has to manually
allow each new option one at a time, and you have to wait for all networks to
have done that, or you're saying that every time the IETF publishes a new
document, I have to go through and block stuff.

Erik K: I don't think that's what I'm saying.

Ben: I think Warren's point is that if we make the recommendation that your
limited domain should police the alt-mark hop-by-hop at the boundary of the
domain, people have a couple of different ways they might implement that, but
basically all them are going to involve some kind of fixed, static
configuration involving the particular hop-by-hop options. It might be an allow
list, it might be a deny list, but in either case it's going to be a new thing
with manual configuration.

Erik K: How is that different from the TCP ports?

Warren: TCP ports, if I'm a transit network, I can just ignore them. I just
take the packet in, it goes through my transit network, and it falls out the
other side. I don't care what's in it. If it's a hop-by-hop option, you're now
causing work throughout my network. The difference is that for TCP ports, the
router doesn't look at it, doesn't care, it just passes through. For this
you're causing work on all of the devices along the path.

Erik K: That's not the manually maintaining a list argument, then.

Warren: It is, because I don't want all of the packets to cause work on all of
my routers, I need to go through and apply filters at all of my edges.

Erik K: I see. So you're saying that there's no deployable hop-by-hop options
because either you have to deny them to not risk doing any work on them, or you
have to be sure you have a network that's configured so that you basically
never inspect a hop-by-hop option, or you have some kind of allow list
situation.

Warren: Yep. Or we need to come up with a way that a network device can figure
out if it should do work on the hop-by-hop option. For example, there is a
magic cookie attached to the hop-by-hop option, a 32-bit number or something
like that, and the router first makes sure that the hop-by-hop option includes
the right cookie, or something. There needs to be some incredibly cheap way for
the devices along the path to figure out if this hop-by-hop option should be
allowed within their network.

Eric V: The source address or the destination address for the return traffic,
is it one of mine?

Warren: That might work. Then I just need to make sure that I do source address
filtering on the edge so my own address doesn't come in through the edge, but
that's fairly standard. That's a reasonable thing.

John: Although that only enables a subset of use cases, which Warren's handwavy
solution would enable more. I don't expect you to come up with a real solution
live on the phone, but that particular solution wouldn't work.

Warren: That doesn't work for stuff like the MTU option, which I think might
have value, but I'm concerned that unless we figure out a way to solve this,
people aren't actually going to be willing to deploy the ones that actually
could have value.

Ben: Eric, in my reading at least was saying that having this as a hop-by-hop
option at all is maybe not necessary. We're only saying people are going to be
looking at it, and if it's a destination option people can look it at because
the bits are there and maybe 8200 says you're not supposed to look at it, but
you're looking at other parts of the packet to get the port number and whatnot
and if you're doing reporting on that, so is there a real strong case for
needing this to be hop-by-hop that you can't solve by putting the bits in
destination options and configuring the machines that need to look at it to
look at it?

Erik K: The issue is that the number space is the same for hop-by-hop and [DOs]
destination options.

Ben: Right, but this document doesn't have to say you should put it in
hop-by-hop.

Erik K: For something that's going to leave your network, yes. For something
you want in your network, for taking a measurement across the routers in your
network, I think that's the behavior that's desired.

Eric V: The destination option is simply to put a bit somewhere, right? You
cannot put bits back into the ipv6 header. If there were empty space in the
header, it would be enough for this bit, but there's not enough space so they
need to put an extension header somewhere. Honestly, in the Cisco device, and I
guess the same for Juniper and Nokia, etc, right, but I only know the ones from
Cisco. We can go very deep in the extension header chain and do IPFIX for it.
We can put in the numbers of the options that we see. In hardware. So while the
hop-by-hop will always be printed to the CPU. the reason why I say I don't see
it deployed, sorry to talk about my employer,  but under the one i know, with
hop-by-hop, because they will not be everywhere, it's an option. It's doable,
basically.

Erik K: Did you mean to say, Ben, that we should enforce that this codepoint is
only used in the destination option and not the hop-by-hop option, even though
the codepoints are the same, or to make some statement about that as it
transits the boundary of an administrative domain?

Ben: It's not clear to me if that would help with Warren's concern. Mostly, the
point I was trying to make was that in terms of getting the bits into the
packet we have a lot of options. It feels like we're constraining where we put
the bits based on an essentially arbitrary policy or procedures that we think
are in some other RFC. If that policy is causing problems for us maybe we
should revisit that policy instead of blindly following it.

Erik K: I'll have to review the minutes and think about that. The author is
currently attempting to respond to comments quite actively. Should we keep that
discussion going, or is there some other sort of meta action we can take? It
sounds like Warren thinks that any hop-by-hop action that operators are not
going to like is irredeemable.

Warren: No, I think any hop-by-hop option that could cause the router to do
significant work, or something where it might possibly get punted off of the
fast path, which is many of them. Unless it's something that has global utility
to the network, which maybe an NTU option does, people are going to have to
make a decision as to whether they allow it or not. I think for a transit
network for example, people aren't going to see the utility this provides the
transit network provider, so they're going to want to block it. Once there are
more than 2 or 3 or 4 of those options, people are going to move from a
blacklist to a whitelist, and only allow the ones they think have sufficient
value, and that whitelist is going to get baked into the network and not
changed. So it's going to limit future use. I think this kind of comes down to
at some point a beauty contest of does the option solve a problem that the
transit network operator is going to think has value, or is actually required
to make the network function? I'm not sure 'I'd like to measure some amount of
performance along a path' really falls into that.

Erik K: I don't know if this is the same standard that all of the previous
destination options and hop-by-hop options was applied to those when they were
pursuing publication. But that's not to say it shouldn't be the standard.

John: To me that sounds like it's taking all of the sins of the underlying
architecture and saying alt-mark must solve this. Fairness is maybe not our
first goal here, doing the right thing is. But it would be nice to be fair
also, and it seems like ideally maybe it would allow alt-mark to proceed on the
basis that everything else proceeded and say at the same time, we'd really like
6man to come up with a better story about this in the future.

Erik K: They are working toward publication on relaxing the hop-by-hop behavior
requirements, the requirement to actually examine it, which is pretty already
universally implemented. You either ignore them or you drop them. No modern
network devices should be doing excessive work for hop-by-hop options at this
point. At least major networks. If we're going to allow the MTU option I don't
know that …… There are lots of options. Should I permit those? Filter them? I
guess I don't see how we get away from a world where you don't say this ignore,
this drop, this process. And also somehow have hop-by-hop options transiting
the internet.

Warren: I think that's the big concern, is that there is value in having
hop-by-hop options, probably. MTU to me seems like a useful one. What I want to
make sure is that we don't end up breaking the utility of actually useful ones
by simply piling in so many that none of them work at all because everyone
filters them all out. I do like John's thing, maybe we just let this one go and
then we're going to have to be more careful with these or we need a better
answer before we do any more. It doesn't feel reasonable to stop on this one.

Erik K: I'm sympathetic to the global utility augment. If we acknowledge that
things can inevitably leave one's administrative domain, you could attempt to
take the stance that hop-by-hop options are because of their theoretical impact
on arbitrary devices anywhere in the network that they pass, they should have
global utility. That's a perfectly good discussion to have.

Ben: I dropped a note in slack that if we prime the ecosystem by getting enough
generally global utility hop-by-hop options in there, that will prime
implementationists to do the right thing, and then maybe it makes more sense to
start letting in other hop-by-hop options as well.

Warren: Part of the thing is, who decides what counts as global utility?

Erik K: There are follow on questions, and that was one of them.

Eric V: Global utility for you is not global utility for me.

Warren: That's why I was saying beauty contest at some point. It kind of feels
like what would have been a good idea is if the number space was broken up into
what's allowed within a network, what's filtered at an edge boundary, and
something experimental or private use. That way at all of my edge devices I
could simply say drop anything that's not supposed to transit a limited domain.

Eric V: The first 2 or 3 bits of the options ID is about, if I don't know it I
can proceed, or if I don't know it I can drop. It's kind of there. But without
any importance or credibility or whatever.

Warren: John is right, this is the transit bit for EH.

Erik K: So what should we tell the author to do? Should this go back to the WG?
Is there a path forward if he just keeps addressing comments? It doesn't sound
like Warren's comments will be addressed. On the other hand, if it's massive
ipv6 architecture changes that need to happen…

Eric V: I would suggest, we can keep the hop-by-hop in the paper. I'm against
it but if you want to use it, you can do it yourself. There are a lot of
inconsistencies regarding the limited domains and that needs to be fixed. The
rest, if you do something that's useless, it's up to you.

Erik K: Assuming we craft satisfying domain boundary text, if they escape your
domain anyway, perhaps by accident or perhaps because someone is running an
internet-wide measurement just to see what happens, is there an objection that
should just not be allowed because that would then become possible?

Warren: 2 things. One of the issues is specifically what you said, which I
think is the way a bunch of people have been viewing it. If it escapes your
limited domain, it should blah blah. I think it should be if it enters your
limited domain, then blah blah. That's exactly what happened with the authors.
They said people who are running this will be being responsible and won't let
it leave their limited domain. But that's not the concern. The concern is if I
am not running this, how do I stop it entering? I would be okay with there
being something in the document acknowledging the fact that this potentially
isn't a good long term solution, but we're willing to let this one go through
because it's unfair to change the rules while this one is actually progressing.
As John or someone said, we've allowed a number of these already. Changing the
rules while people are in IESG eval feels impolite. So I would be okay saying I
don't like this, I think it's a bad idea.

Erik K: John's point was that fairness is not the first objective, doing the
right thing is the first order objective.

Warren: I would be okay saying we'll allow this, but let's not allow any more
until we've figured out the larger architectural solution.

Eric V: If you think about the hop-by-hop the train is too late, it left the
station 20 years ago.

Warren: Yes, but this document has got all the way through 6man, WG last call,
IETF last call, it now enters IESG eval and we saw this is the straw that
breaks the camel's back?

Erik K: From my perspective as a regular 6man participant this is not
necessarily so different than all the other hop-by-hop options that got worked
on. Maybe it is time to change the standards of review. I just want to
understand what to say and what to do with the document. One thing I will do is
sync with the 6man chairs and Eric, but beyond that and beyond the author's
attempt to clarify and refine the text, it's not clear where we go from here.

Warren: One of the concerns, as Mirja said, didn't we already have this
conversation in 6man? And if we allow this document, aren't there like 27
queued up behind it that are also going to be defining hop-by-hop options?

Erik K: This discussion? No, i don't recall having this discussion. From 6man's
perspective this is just another hop-by-hop option.

Eric V: I don't think we should throw the [baby out with the bathwater] here.
Hop-by-hop is quite useful in a couple of places. Whether you use it, is more
of an operational issue. If you receive 1000 packets [crosstalk] and your
router goes belly-up, that's your problem, that's not a 6man problem.

Erik K: We do have this problem with router alert. If we send MTU options
across the internet you're going to have to filter router alerts.

Warren: It sounds like what you said, although I'm assuming that's not what you
meant, is that the IETF should be able to define anything, and if it happens to
make people's routers explode, that's not my problem. I’m not saying we should
ban all hop-by-hop and make it so that we can never do another one, I’m simply
saying adding more and more of them is eventually going to end badly for us.

Erik K: I am sympathetic to that. That seems like a 6man document retrospective
on hop-by-hop options. I'll take that up with Bob, Ole, and Eric and we'll
figure out what to do.

Eric V: It's only about 8 bits, right, and 2 are burned by the action-to-take
[see https://datatracker.ietf.org/doc/html/rfc8200#section-4.2]. So it's not
too many of them.

Erik K: Three are burned. There are only 5 bits, 32 options at the moment. And
8 of them are burned for experiments. If I have a meeting on what to do with
this document with the chairs, or this larger point about hop-by-hop options,
are there other folks who want to be part of it?

[crosstalk]

Eric V: I don't think it's really up to the IESG to decide this, it's more of a
WG decision.

Warren: To me it feels like it is a much larger concern. It's not just does
6man think it's okay to implement this, because it affects things like v6ops as
well.

Eric V: Agreed.

Warren: And I think it affects anything else that tries to use v6 as well, like
SPRING. If there's not a lot of care taken here as to what gets defined,
everybody will start filtering all hop-by-hop options, and that to me feels
like a larger thing than just a 6man issue. That feels like a do we want
hop-by-hop to work across the internet? Maybe we don't. If you don't, then
continue down this path. If we do, then ...

Erik K: Maybe not filter them, but continue to not process them. That's what
they're doing now, right? If I send a hop-by-hop option across the internet, I
certainly hope it's ignored.

Warren: Have you seen Fernando Gont's stats on how well extension headers are
currently working?

Erik K: They're largely dropped, absolutely.

Warren: It's not that they're dropped by default, it's that people are dropping
them because of this kind of issue.

Erik K: I don't know how much more of this telechat needs to be devoted to this
topic; I don't want to starve other documents.

Martin D: I'd like to verify something about this. Most of the threads in my
Discuss can be resolved with a little bit of text. I wanted to skip to where
people thought about the relationship of this draft to these IPPM RFCs. They
have an informative reference. The people who have chimed in on this, are we
agreed that it should update those IPPM RFCs?

Alvaro: My concern is that they seem to be defining the method here, in other
words they're not just doing an extension header, they're doing the AMA thing
here.

Martin D: They're bringing in stuff from those RFCs. IPPM has been consulted,
maybe not quite as much as I would have liked, but the key players do know
about it.

Alvaro: That's my concern because the IPPM docs are experimental. At the time
it said it wasn't scalable. If this is going to now result in the reference for
future things to use AMA, then we should review it a little bit more. IPPM
should review it a little more. If you say it's ok, I'm okay.

Martin D: I had a chat with the IPPM chairs and they didn't seem too worried
about it, so I think it's okay, but I think it should update those drafts.

Mirja: I saw it the other way around. This document is written by the same
authors and it was presented in IPPM a bunch of times. The procedure for ipv6
options is you go to 6man and if 6man is interested, then 6man specifies it in
their group; it was moved from IPPM to 6man at some point.

Martin D: The grammar of how you express this in ipv6 is definitely a 6man
thing. As you well know, Mirja, the way this normally works is there are
measurement techniques definitions in IPPM and then the specific protocol
grammar goes out to the different WGs. what happened here is because it was
experimental in IPPM, they couldn't just normatively reference that.

Mirja: Of course they can.

Martin D: Well, it's a proposed standard. I guess you could do a downref.

Ben: It's hard to see that the experimental documents are only informative
references. If you're going to implement this thing you basically need to know
what's going on with those other documents.

Martin D: So I guess there are a couple of options here. We can have it update
the IPPM RFCs. we can have it be a normative reference and eliminate some of
the text that's duplicative, to not have dueling references.

Mirja: When you say update the IPPM RFCs, what do you want it to update? A
status change of those documents?

Martin D: The update would say the parts of the IPPM RFCs that are replicated
in alt-mark would be upgraded to proposed standard. That's one possibility. The
second possibility you suggested, Mirja, which is that we remove the text
that's duplicative with the IPPM RFCs and have a normative downref to them. If
we did them in different statuses that's how we'd do them. I don't know what
the third option is, what they're doing now. The informative reference I think
we all agree is not the right answer.

Erik K: The other option would be to try to label this as experimental.

Ben: Can you register an IPv6 option with an experimental document? I forget
what the registration policy is.

Erik K: That's a good point. We've allocated stuff for experiments.

Martin D: Given the angst around this thing for other reasons, maybe that's the
right answer and it solves a bunch of problems. I don't know; I think we maybe
have achieved as much as we can achieve without more people in the room.

Erik K: Martin, to your understanding, does anything in this document alter
text?

Martin D: I haven't done a review so I'm not equipped to say definitively, but
my impression is that there's no gigantic change to what's in those IPPM docs.

Alvaro: So they're basically upgrading them to proposed standard through the
back door?

Mrija: I'm actually surprised that the IPPM document is experimental rather
than informational; it doesn't define an experimental protocol.

Alvaro: The reason I'm interested in all of this is that I have another
document that references the IPPM documents, normatively. I pushed it back
because from what I could see, IPPM thought it was an experiment, so I told the
authors to get IPPM to say it's good. Instead, they wrote this draft,
standardizing AMA here. My other document is going to then point to this one.

Mirja: That also seems wrong. It is possible to do a status change. If the IPPM
working group agrees it should not be experimental but it should be something
else, it can be done.

Erik K: So it sounds like there's other work that would be benefited by such
discussion with IPPM?

Alvaro: I think so, yes. Otherwise we're going to end up pointing to this draft
that wasn't really reviewed for that part of the text.

Mirja: For me the two reasonable options are either all the documents should be
experimental because this is an experiment, or if there's already enough
experience then the IPPM document should change status to something else.

Erik K: And that should be done through some kind of IPPM-originated action, I
assume?

Mirja: There needs to be WG consensus but it is initiated by the AD.

Erik  K:  Do IPPM folks have a preference for that? I'm willing to follow
whatever guidance. There are obviously several other things with this document
that need to be dealt with before we get to this discussion, but it does seem
like there's a related point for other work.

Martin: I read this document two days ago and quickly pinged the [IPPM] chairs
to make sure they've heard about this, so it's not a complete end run, but I
should probably circulate this to the whole WG and see what comes of it. I
think the first order question is what does IPPM think of the maturity of these
techniques, and if they're comfortable, maybe the right thing to do is to
elevate to standard and then we can worry about the document and whether we do
a status change on the IPPM stuff. Is it mature enough to be a standard? If
not, I think the right thing to do is for alt-mark to go down to experimental.
If the techniques at the heart of this are experimental then it needs to be
experimental.

Erik K: That makes sense to me.

Mirja: I agree. At some point we lost sync here, because this document was
presented in IPPM several times, so the right thing would have been to have a
joint WG last call.

Martin D: It's a lot of the same people in the two groups, so there are a lot
of people who knew this was happening. IPPM is a weird group too, with several
silos of interest. Anyway, maybe we should move on. I'll take an action item to
take this to IPPM and see what the status of this work should be.

Erik K: However that issue resolves itself, this document should wait to see
what that resolution is and take steps accordingly, after all of the other
issues have been addressed.

Amy: So for this document, it's going to remain in IESG Evaluation. Does this
need a Revised ID, or should it go back to the WG?

Erik: Definitely the former. I think I want to talk to the chairs and Eric. It
might go back to the WG.

Amy: For now we'll put it in Revised ID and we can take it from there.

2.1.2 Returning items

 o draft-ietf-dots-signal-call-home-14  - IETF stream

   Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal

   Channel Call Home (Proposed Standard)

   Token: Benjamin Kaduk

Amy: I have no Discusses in the tracker but this needs one more position to be
approved.

Warren: I'll ballot No Objection. I read the abstract and the writeup. I have
no objections.

Amy: Okay, so with Warren's no objection, it looks like this is approved.

Ben: Thank you, Warren.

Amy: Are there any notes needed or is this all set to go?

Ben: Leave it in AD Followup; I'm not confident I saw all of the traffic about
it.

Amy: Okay, this is Approved, Announcement to be Sent, AD Followup.

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

 NONE

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-smyshlyaev-tls12-gost-suites-00

   IETF conflict review for draft-smyshlyaev-tls12-gost-suites

     draft-smyshlyaev-tls12-gost-suites-13

     GOST Cipher Suites for Transport Layer Security (TLS) Protocol

   Version 1.2 (ISE: Informational)

   Token: Benjamin Kaduk

Amy: There are no Discusses, so unless there's an objection this can go back to
the ISE.

Ben: Interestingly enough, I have a message from the ISE from this morning and
he’s wondering what the best way to proceed is, if we should actually send him
this conflict review and then they'd update the document and then we'd do
another conflict review, or if we should just abandon this one and bring it
back later, or should we send this one and then they'll change the document, I
can look at it and we can proceed with only my review. I don't know if anyone
else has thoughts.

Alvaro: It seems to me that if you’re saying don’t publish, it would be good to
see it come back here.

Ben: So you think we should abandon this conflict review and have it come back
later?

Alvaro: That makes sense to me.

Ben: That sounds reasonable to me. Hearing nobody else speaking up, I will
email Adrian.

Warren: Sorry, I missed a bunch of that. What happens to the document after
this? If it violates our procedures for TLS cipher suites, are we saying you
can't do that? Or are we saying we'll talk about it in the IETF and then agree
it violates this and then we still won't allow it? What’s the long term?

Ben: I think the ISE at least has agreed in principle to changing the way the
document describes what it thinks should happen so there’s not a conflict with
IETF rules. I think everyone agrees we can change the text in the document to a
form that will not be problematic.

Warren: Will the document still be useful or is it just weasel wording out of
the problem?

Ben: Yeah, I think it will still be useful.

Warren: Okay. Does the ISE know what needs to change?

Ben: I think so. This is TLS ciphers using the Russian crypto algorithms, and
we had an RFC a year ago that was TLS ciphers using the Chinese crypto
algorithms. We basically had the same conflict review discussion, so that's
basically a template for how this works.

Warren: The ISE is here, can we check if he wants to say something?

Adrian: Not really. Ben represented exactly the situation. I believe I know
what flavor the document needs to be acceptable and not violate procedures, and
I just wanted to know how the IESG would like to verify that the authors get it
right. I believe I've heard from you how to do that.

Ben: Thank you.

Amy: Okay, so it sounds like the ISE is going to withdraw this document and it
will come back once some work has been done. With that, we can move on.

3.4.2 Returning items

 NONE

3.4.3 For action

 o conflict-review-irtf-icnrg-nrs-requirements-00

   IETF conflict review for draft-irtf-icnrg-nrs-requirements

     draft-irtf-icnrg-nrs-requirements-06

     Design Considerations for Name Resolution Service in ICN (IRTF:

   Informational)

   Token: Lars Eggert

Amy: This is here to find someone to do the RFC 5742 review. Do we have any
takers?

Erik K: Do we have any idea which direction this should go? I have another
ICNRG review I owe.

Martin D: It’s a name resolution service, so it seems kind of DNS-ish.

Mirja: There are actually two documents which belong together. It’s this one
and another one with NRS in the name.

Murray: I'm looking at the charter for ICNRG and there are words like naming
schemes, scalable routing schemes, congestion control, caching
strategies...this sounds kind of low level.

Warren: Many of those words sounded internetty or security. I can do this
particular document probably, but maybe the others are somewhere else and they
should go together.

Roman: We can dutifully review your conflict review text, Warren.

Amy: Thanks for taking this on, Warren.

4. Working Group actions

4.1 WG creation

4.1.1 Proposed for IETF review

 o MAC Address Device Identification for Network and Application Services
 (madinas)

Amy: I have no blocking comments, so this can go for external review if there
are no objections.

Eric V: I simply want to thank Alvaro, Ben, Mirja and Roman for their comments.
I think they do make sense because when you read and read and read the charter
things become a blur and a fresh pair of eyes is always important. I will need
to work with the current chairs of the BOF and update the charter to better fit
the comments from my fellow ADs. it won’t be done before the end of August.

Amy: I’m hearing that the external review is approved pending edits for the
charter, and you’ll get those to us at the end of August. Is that right?

Eric V: Correct. And thanks again for the review.

Amy: Okay, when you're ready, let us know and we can send that for external
review.

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering

4.2.1 Under evaluation for IETF review

 o Application-Layer Traffic Optimization (alto)

Amy: I have no blocking comments for this, so is this ready for external review?

Martin D: I am going to rewrite it a little based on some comments I got. I
will say this charter is a little unusual and calling out some things that are
kind of standard issue more than you might otherwise, and that’s to emphasize
the importance of establishing that this is under broad use before moving on to
further extensions of the work. I’m going to slim this charter down a bit
because there's some unnecessary text, and the comments that are in there are
good. Whatever we call Revised ID Needed for these is what it should be.

Amy: It sounds like external review still has to happen once you get your edits
done, right?

Martin D: Yes.

Amy: So this will be external review approved pending edits to the charter, and
you can let us know when it's ready.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Martin V: Just a quick note. The IAB had an interesting discussion yesterday on
liaisons and the possible need for introducing an explicit approval step in the
process. It’s not decided but it's an interesting discussion, we’ll see where
it leads and I’ll keep you updated.

Warren: As a quick follow on from that, and thank you for that summary, how
many people knew that WG chairs can just send a liaison without any other
interaction?

John: Knew it before Loa sent his last one, or before? I didn't know it before.

Ben: We talked about it a couple of weeks ago, but not before then.

Warren: I was surprised by that. Anyway, thank you.

Mirja: There are cases where it makes sense, if a liaison is sent straight to a
WG and the answer is straightforward and simple, the WG just sends something
back. My personal view is that we should always have an approval step, no
matter who sends it, so we just have a second person looking at it. I think
that's good because liaisons are important and it can go badly wrong.

John: The recent one from MPLS demonstrates that what to one person is simple
and doesn't need review to a different reviewer isn't so simple. I agree.

Mirja: There's a lot of trust in people not to do anything wrong, but as long
as we do activities within the Datatracker we're fine, but I think we should be
more careful when we send things outside the IETF. As Martin said, discussion
is ongoing.

6. Management issues

6.1 [IANA #1200145] Management Item: Acceptance of media type registration from
standards organization Gedcom (IANA)

Michelle: This is one that we had on the agenda before and Murray took the
lead, so now it's coming back. How do you want to deal with this one?

Murray: I’m just digging up the thread again. I emailed the IESG about this too
so people have seen it. I don’t understand why we would approve this. Virtually
none of the things we would expect to see being properties of an SDO are
present. This is one person's website. There’s no evidence Gedcom acts like a
standards organization and it sounds like a bunch of people who collected on
one document and haven't met since then, there are no policies….I don’t know if
we have a basic definition for an SDO, but any definition I invented in my
head, this did not meet it. I suggest we don’t approve this. We could approve
or the media type reviewers could approve what they’re trying to register, but
unless there’s a precedent of us being that generous, I don't see it here.

Michelle: So we would send the media type template to the reviewers and get
their thoughts, and then if they think that it should be approved in the
standards tree, that would come back to the IESG for the media type approval
itself.

Murray: I think that's right. The thing I'm hoping they'll look at is if the
reference definition for their media type they're trying to register is good
enough and someplace we consider to be stable?

Michelle: And they may come back saying that this would have to be a vendor
tree or a personal tree or something else.

Murray: Right, or they need to make a draft and get someone to sponsor it, or
something like that. That's just my opinion.

John: Three of us have said that sounds good in the chat.

Roman: What you just proposed sounds right.

Amy: Michelle, what do you need from us?

Michelle: If you could just respond back to us for the management item saying
that the request to add Gedcom to the list of standards orgs is not approved,
denied, whatever wording you'd like. Do you want me to put some text in the
chat?

Murray: Do you want me to write something?

Michelle: I'd like to see something that says the request to add Gedcom is
denied but we can still follow the normal processes in RFC 6838 which we know
what to do for that. I think that's about it.

Amy: Okay; we'll respond to the ticket on this.

Michelle: We'll get the advice of the media type experts and the IESG may or
may not see this in the future come to them, we'll see.

6.2 [IANA #1203389] renewing early allocations for draft-ietf-cose-x509 (IANA)

Ben: If I remember correctly this draft is Approved, Announcement to be Sent,
but there was one late breaking issue that we had to address and it sort of
stalled. A lot of the blame for it being stalled is on me. This document is
basically done and we should renew the early allocations because it will be
actually done really soon now.

Amy: Any objection to that? Great, sounds like this early allocation renewal is
approved and we will send the official note to IANA.

6.3 [IANA #1205430] Designated experts for RFC 8984 (IANA)

Amy: This is assigned to Francesca.

6.4 [IANA #1206462] Designated experts for RFC 9073 (IANA)

Amy: This is assigned to Francesca.

6.5 [IANA #1206466] Designated experts for RFC 9074 (IANA)

Amy: This is assigned to Francesca.

6.6 Important Dates for IETF 112 (Secretariat)

Amy: This you actually have to make a decision on today. Liz, did you want to
speak to this?

Liz: There have only been a couple of emails but it seemed like there was
general support for keeping both dates, the preliminary date and then the final
cutoff date for BOF approvals. Are we okay to go ahead and publish these dates
as-is? Does anyone have any more thoughts?

Ben: That seems like the continuity option. Some people expressed some level of
sentiment that going back to a single deadline would be preferred but we don't
have solid agreement on that.

Mirja: When we do the two deadline model, is the first deadline a soft deadline
and the second one is a hard deadline?

Warren: I'd think it should be a hard deadline, but as with pretty much all of
our hard deadlines, we can always fudge it if needed. If we tell people it's a
soft deadline, nobody will follow it. I think we just say there are hard
deadlines and we have an exception process.

Mirja: My proposal last time was to call the first one a registration deadline,
where you only need the BOF name and person responsible, and have the second
deadline be the deadline where you need to fill in all the information.

Martin D: The point of having two deadlines is we have the joint call and
figure out all the problems with it and give people however many weeks to fix
it, and then approve it at the second deadline. If you wait til the second
deadline then you don't have time to fix stuff, so if it's not perfect you're
going to get booted. Just making people type out the name isn't really going to
get what we need. Last time we had the one late submission and we didn't have a
meeting scheduled so we had to throw together the meeting. I'd like to try that
model at least once, where we have two joint meetings about the proposals. We
can cancel the second one if everyone comes in at the first deadline and we
approve or reject them all. That's what the two deadline thing was supposed to
accomplish and we haven't really tried that.

Mirja: What you're proposing is a hard deadline to get in your BOF request and
the second deadline is to do any additional edits?

Martin: The original intent was that you can have a second deadline submission
but if there's any problems we'll say you should have made the first deadline.
That was the original intent as I remember it. The only pushback to what you're
proposing is how early that is. The deadlines are September 10 and 24.

Warren: I'd assume that if people think they want to have a BOF they can put in
more words than just a title and then we can discuss it and refine it by the
second one.

Martin D: If people think it would not be too early to have something in by
September 10, then I don't have a strong objection to that.

Mirja: I think it can be challenging but we can try it. We can see if people
complain. We can make it appear like a hard deadline. The risk is people see
the deadline and don't submit at all.

Warren: Based upon what we know of most participants, if it's 2 days after the
deadline and they have a great idea, they're likely to send email anyway.

Martin D: I think that's fine.

Amy: So do you want to keep the preliminary BOF proposals on September 10? Do
you want to keep those words?

Mirja: I think the 10th of September should have the text we have for the hard
deadline, the cut-off, and then the other deadline should say something else.

Martin D: Maybe deadline for preliminary and revised proposals?

Mirja: I'm not sure I'd even use the word preliminary.

Amy: So the cutoff date for BOF proposals will be September 10, and then the
cutoff date for revised Bof proposals will be September 24?

Alvaro: Are we going to try and have IESG/IAB calls after both deadlines?

Martin D: I think we put them on the calendar and if everything looks good at
the first one we can cancel the second call.

Alvaro: That works for me.

Liz: Okay, great. So we'll keep both dates but change the words, look at
scheduling two joint calls, and Robert has the session request tool ready to go
so we can open session requests today. Thanks everyone.

6.7 [IANA #1203393] renewing early allocation for draft-ietf-6man-mtu-option
(IANA)

Erik K: This is for a document that's in WG Last Call. They were conducting
some internet measurements to see if the option could be used across the
internet. I'd like to re-up this assignment.

Amy: Any objection to renewing this early allocation? Hearing no objection, so
this is approved and we'll send that note to IANA.

6.8 [IANA #1199105] Designated experts for RFC 9036

Amy: We added this at the top of the call for Murray. Do you have a name for us?

Murray: Yes, Henning Schulzrinne has offered to sit in that position. If IANA
would like two people, I don't have a second, but I can keep looking.

Michelle: One is better than none, so we'll take it!

Amy: Any objection to approving Henning Schulzrinne as the designated expert
here? Hearing none, so he is approved and we'll get the official note sent to
IANA.

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

Murray: The charter for MEDIAMAN is sitting in a basically approved state until
I identify chairs. I have one but not two, Harald Alvestrand, who was involved
in some of the earliest media types work. Is anyone going to be upset if I
start the work with one chair and continue looking for a second?  I don't hear
anything, so that sounds like a plan.

Roman: I have one thing as your friendly Nomcom liaison. First of all, thank
you for the AD writeups for the qualifications. One of the things that's come
up I can use your help on is that very often ADs are pairs; you need a
collection of skills across two people. The Nomcom would be interested to know
what skill gaps should they focus on of the larger bucket of all skills
required, given the outgoing ADs? I'll send around a google document with all
of the AD descriptions and I'll ask you to highlight which ones we want to make
sure the Nomcom focuses on, as a suggestion to them.

Eric V: In INT we basically change the description every year.

Roman: Thank you. I don't think that's a consistent practice but that's very
helpful.

Eric V: I have one thing, you may have seen that Barbara Stark is retiring and
she will leave the chair position for DNSSD and HOMENET. I found Chris Box from
BT in the UK who will replace Barbara as chair for DNSSD. AFter IETF 112
Barbara will resign. Still looking for one for HOMENET, so if you have
suggestions, I'm all ears.