Narrative Minutes interim-2021-iesg-11 2021-05-20 14:00
narrative-minutes-interim-2021-iesg-11-202105201400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2021-05-20 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
Ben Campbell (Independent Consultant) / IAB Liaison
Michelle Cotton (ICANN) / IANA Liaison
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (F5 Networks Inc) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General 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
Martin Vigoureux (Nokia) / Routing Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
John Scudder (Juniper) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area

OBSERVERS
---------------------------------
Peter van Dijk
Ketan Talaulikar
Matthaus Wander
Greg Wood

1.2 Bash the agenda

Roman: Do we need to swap document order based on who's partially at the
meeting?

Amy: I don't think so; I didn't get any requests but if we come to a document
for someone who's not here we can shuffle it.

1.3 Approval of the minutes of past telechats

Amy: Is there any objection to approving the minutes from May 6? I'm hearing no
objection. I also saw final narrative minutes come through this week; any
objection to approving those? Hearing no objection to that either. We will get
those posted.

1.4 List of remaining action items from last telechat

     o Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy to look at
       updating the I-D Checklist.

Murray: I think it's ready to go. I have one or two issues left open in the
tracker to make sure they were covered. It probably needs one more week and
then that's it.

     o Warren Kumari, Deborah Brungard, Stephen Farrell, and Jay Daley to
       investigate ways to recruit, recognize, and retain volunteers in the
       IETF.

Warren: I guess let's leave this here. People got busy with other stuff and
we've been trying to schedule meetings.

     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.

Amy: I think we've done a statement on this recently, right?

Alvaro: Yes, this [first item] is the second step. Martin and I have been
working on it. The second item, which is the next step, is in progress too. We
should have something in the next week or so for everyone to see.

     o John Scudder and Martin Duke to review the document shepherd
       templates and propose changes to include updated questions and
       cross-area checks.

Martin D: I don't remember if there's been progress on this. We did make some
effort to put together a strawman and we're still iterating on it, but not very
quickly.

     o Rob Wilton to draft text to expand the document shepherd write-up
       section on use of YANG Models.

Rob: That's in progress.

     o Zahed Sarker and Michelle Cotton to draft text for prospective
       Designated Experts on the basics of the IANA request process and
       "how to be a designated expert."

Michelle: I have information ready to go as soon as Zahed comes back.

     o Michelle Cotton to add conflict of interest text to the introductory
       email sent to new Designated Experts.

Michelle: I'm just waiting on one more internal approval for updating some of
our standard form language we send out. We'll be sending that additional
conflict of interest text to new experts very soon. This will probably be done
by the next telechat.

     o Michelle Cotton to follow up on the documentation of IANA registries
       and non-IETF publication streams.

Michelle: Just before the call I dropped an email to the IESG with information
about text that I've found, and actually just the lack of information about
creating IANA registries from other streams. If everybody could take a look at
that in the coming days and weeks, maybe that's a good topic to add to an
informal telechat?

Ben: The lack of documentation is an interesting point. I think I remember in
previous discussions there was some reference to a legal document or a contract
or a memo of understanding between ICANN and somebody about IANA was supposed
to serve the requests from the IETF or something vaguely described, which might
limit it to just the IETF and not other things. But if we don't know where that
is, we can't refer to it.

Michelle: I know where that document is. Part of the question would be when you
look at IAB and IRTF, does that fall under the IETF purview? Other streams and
non-IETF documents are different. I didn't look into that as part of this
action item, I stuck strictly to the different RFC streams, but I can expand
that if you'd like.

Ben: I'm not going to ask you to do that right now. I'll take a look at the
email and see if anything else pops up.

Michelle: Lars was the one who was pushing this action item so I'm interested
in what he wants to do here too. Maybe adding it to an informal telechat for
discussion might be the right way to go. Can we mark this as done and then if
there's a followup action item for me we can add it as soon as we know what the
next steps are.

     o Rob Wilton to follow up with the IESG on small group project
       assignments regarding topics identified through the poll taken at
       the IESG retreat.

Amy: I did see email on this; is this done?

Rob: I think it's sort of done but I'd like you to keep it open for a while. We
might want to have separate actions for each of those groups. Keep it open for
the moment and probably I'll have some discussion on next week's informal to
confirm people are happy.

     o Martin Duke to draft a proposal for 360 degree reviews of the IESG
       members.

Martin D: That's been out to the group for a little over a week now and we got
some comments from Eric V and Lars; thanks both of you. For anyone else who
wants to review, how long do you need before I can push it to Jay? Or is
everyone else content with it?

Ben: I haven't had a chance to look at it yet.

Martin D: Should we give it another week?

Alvaro: Can you put it on the agenda for next week so I don't forget? Without a
deadline it's hard for me to get to it.

Martin D: Sure. Let's do it in two weeks.

     o Eric Vyncke and Francesca Palombini to draft text for guidelines/
       best practices for directorate reviewers.

Francesca: We have no update for this one yet, so keep it in progress.

     o The IESG to report on the RFC 8989 experiment.

Amy: I've seen a lot of mail on this and it seems like it's still going on and
still in progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-idr-bgp-flowspec-oid-14  - IETF stream
   Revised Validation Procedure for BGP Flow Specifications (Proposed
   Standard)
   Token: Alvaro Retana

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

Ben: I saw that I got a response about is a route-reflector more trusted than
the other routers, and I would like a chance to respond to that but I just ran
out of time.

Alvaro: No problem. I was going to say we were going to need a Revised ID
anyway. I was going to make sure anything that wasn't concluded concludes
before we move forward.

Ben: Thank you.

Amy: That goes into Approved, Announcement to be Sent, Revised ID Needed.

 o draft-ietf-bess-datacenter-gateway-11  - IETF stream
   Gateway Auto-Discovery and Route Advertisement for Segment Routing
   Enabled Site Interconnection (Proposed Standard)
   Token: Martin Vigoureux

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

Martin V: It depends on the other ADs. I have the impression that Adrian is
really responsive and on top of everything. I also see that some of the
Discusses are related or have some common aspects. I'm not sure what more I can
add to the discussion. But if you want to discuss it, I'm happy to discuss.
[pause] Seems like a no.

Ben: I will just note I did not get to review this one. I skimmed it and I
think Roman covered the important points so I didn't push the defer button but
I'll take a closer look in the next few days just in case.

Martin V: Thanks Ben. So this one will be Revised ID Needed, please.

 o draft-ietf-babel-yang-model-10  - IETF stream
   YANG Data Model for Babel (Proposed Standard)
   Token: Martin Vigoureux

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

Martin V: Warren, yours is quite easy and had been spotted early on so it's an
easy fix. Ben, thank you for catching that. Honestly that's beyond my
competency so it's great you can help discuss it.

Ben: It should also be an easy fix, I hope.

Martin V: I'll let Barbara and Mahesh come back to you on that. I expect them
to address it. And I believe you have raised a discuss on each and every babel
document.

Ben: I was worried that was the case!

Martin: But all of them were really good.

Rob: I still need to finish reviewing this document. I don't think I'll have
any DISCUSS comments but I have other comments I'll put on to a ballot.

Martin V: That's okay, no problem. So this one will be IESG Evaluation, Revised
ID Needed.

 o draft-ietf-lsr-isis-srv6-extensions-14  - IETF stream
   IS-IS Extension to Support Segment Routing over IPv6 Dataplane
   (Proposed Standard)
   Token: Alvaro Retana

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

Alvaro: Ben, yours is going to be addressed and Peter said he's going to add
some text around that. Erik, your discuss which is related to Ben's comment on
abstain, I first want to say that I don't think we should re-litigate 8986
today here. Or 4291 or 8200 or any of those. All of you said that, riffing off
Ben's text there, that in the absence of uses cases we can't really go on with
this. Peter did send some use cases last night; I don't know if you had a
chance to look at that. Let's start there. If you saw them, the use cases are
around things that ISIS would not do, but that ISIS is providing information
which is why the sub-sub-TLV is defined here, so the network from an
operational point of view can actually do some things. It can provide
information to the controller to do different things. you can go read the use
cases in the answer Peter provided. My first approximation to this is if you
think we can move forward by fleshing these out, or at least mentioning these
in the draft, that's the first question. Can we move forward with this?

Warren: I can't remember who pointed it out, it might have been Rob. My concern
is actually it's already in 8986 and this is just exposing it. I think I'm okay
converting my abstain to a 'I really don't like this, but whatever.' I'm grumpy
with 8986 and I should not have balloted Abstain on it, but that's water under
the bridge at this point.

Erik: The internal structure of the SID is not programmed with this option,
though. In slack John said that's not what LSR is for. So why is LSR better for
reporting? If it's being programmed by other means, should those other means be
used for these use cases?

Alvaro: That's a possibility. There's a possibility we don't need to advertise
anything and we can just control everything. We don't need to do any of this,
the central controller programs the whole thing. So I probably agree that if
the controller is the one who knows, and wants to assign the SIDs anyways, it
probably should know many of these things. I do know, because it's one of the
things I asked to the authors last night, is there are implementations of this
and there are deployments. So whether the controller could do it or not, sure,
the answer is probably yes. The point is that there are already implementations
using this, this sub-sub-TLV, for some of these actions.

Erik K: And the things they're using it for, are they the things Peter puts in
his email here?

Alvaro: I don't know exactly. I can't say that it's use case number 1 or number
2. But as far as I know, yes, it is around verification and validation of the
SID updates. The example Peter had given me before is if the structure looks
like the last 32 bits are arguments, and you get a SID that has something in
those last 32 bits, something happened and it shouldn't be that way. So you can
use it to verify things like that, that was the example he gave me originally.

Erik K: Somehow that seems a little weak to me. Maybe it is a little closing
the barn door after the horse at this point.

Alvaro: That's why I was saying we shouldn't go back to 8986 and re-litigate
that, because we already included the SID structure there whether we like it or
not.

Ben: In my mind it's a question of where you define the abstraction barrier.
What the abstraction barrier is in my head may or may not correspond to what's
in 8986. In my head you could draw the boundary around the IPv6 entity that is
assigning the SID, and outside of that node is just an IP address and behaves
exactly as an IP address. Maybe there's some internal structure and we document
it for the convenience of people implementing these nodes but that structure in
my head is contained within this abstraction barrier. Now what we're proposing
to do here is redefine where the abstraction barrier is and include a lot more
stuff in it and that's why I'm having trouble coming to grips with it. I'm
happy to take some time and read over the responses and think about it some
more.

Alvaro: Okay. Do you want these use cases to at least be listed somehow as
examples? Do we want to flesh them out a little more? I think the other point
Peter made in email is that the actual use is not something that ISIS would
use, we're just using it to transport information around. That's why we didn't
flesh any of this out because it would be somewhere else.

Ben: I suspect I'd be more comfortable with this if we had a separate dedicated
document that could define the extension and also talk about the use cases and
have an extended treatment and have it just be a document that's pretty focused
on this. Right now it feels a little bit like it's veering into something not
super related. It's a controversial thing and it's kind of buried in a corner
of the document and easy to overlook.

Erik K: I'm wondering also if there could be a statement that none of this in
any way impacts the data plane; there's no SR-aware host, for example,  or node
in the middle of the network which actually needs this information for anything
other than some kind of control plane, something that's piggybacking off of
this information for other programming purposes. [crosstalk] ...then it's not a
v6 address anymore.

Alvaro: Yes. No one in the data plane needs to be aware of this, it's all in
the control plane. If we talk about filtering, for example, at the domain
boundary, that's still the control plane even though it acts on the data plane.

Erik K: On the filtering though, forgive me for not understanding ISIS well
enough, but aren't these all supposed to be sub-sub-TLVs of a locator that has
itself the prefix in there, and wouldn't that prefix be enough to set up
filtering?

Alvaro: Yes, so again, I'm not sure exactly how that specific use case would be
implemented. The locators are subset of the SIDs. Usually yes, you're going to
filter all that at the SR domain boundary, which is going to be usually the
ISIS network, not just a level of the ISIS network. We can all come up with
examples of how you may let some things out of the level of ISIS that's still
inside the IGP because you need reachability for those things. So one of the
things that came in this draft is that you advertise reachability to the
prefix. Not because the SIDs are prefixes. There's one part that talks about
how you don't need to duplicate the reachability and the locator advertisement.
In other words, even though a SID is a locator and you may want to filter it
from a level, if the level is only the SR domain, you may still want to let
that route because it's an IPv6 address. There are different things that you
could do.

Erik K: They're saying you could filter on locator plus function, is what you
could do, if you knew where the function and argument boundaries are?

Alvaro: That's one of the things you could do, right. So I can ask Peter to
include some of these examples just as examples. You said you maybe wanted to
add some specific text around this information not being used by the data plane
of the network, something like that. Maybe if you could come up with a sentence
or two it might be better to reflect what you want it to reflect.

Erik K: Peter's email was at 4:58 AM so I haven't had a chance to digest it. I
can do that and reply.

Roman: The other piece that would be helpful is I think the one you just were
explaining, the finesse of when the locator is what, that frankly might be
remedial for folks deeply steeped in this but for me that would document the
traceability for why this was okay to do, which was I think the central
question that some of us commented on.

Alvaro: You mean the locator vs the reachability of the actual routes? Okay.
I'll talk to Peter about that and see if we can come up with something. So I
think we're going to leave it like this. We'll need a Revised ID, and Erik,
you'll reply to Peter with some text, Ben will think about it a little more,
and I will figure it out when that happens.

Amy: So this is IESG Evaluation, Revised ID Needed.

 o draft-ietf-bess-mvpn-msdp-sa-interoperation-07  - IETF stream
   MVPN and MSDP SA Interoperation (Proposed Standard)
   Token: Martin Vigoureux

Amy: There are no Discusses in the tracker, so unless there's an objection now,
it looks like this document is approved. I also have no notes in the tracker,
is anything further needed before this goes to the RFC Editor?

Martin V: I didn't check; has Jeffrey addressed all your comments? That's a
question to the other ADs.

Ben: I don't think I got a response yet.

Martin V: Can we put it in Point Raised so I can do a final check?

Amy: Okay, we can put this in Approved, Announcement to be Sent, AD Followup
and you can let us know when that's ready.

 o draft-ietf-idr-eag-distribution-17  - IETF stream
   Distribution of Traffic Engineering Extended Administrative Groups
   using BGP-LS (Proposed Standard)
   Token: Alvaro Retana

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

Alvaro: We're going to need a Revised ID; there are still some security
comments that need to be addressed.

Amy: Okay, this is going in Approved, Announcement to be Sent, Revised ID
Needed.

 o draft-ietf-netmod-geo-location-08  - IETF stream
   A YANG Grouping for Geographic Locations (Proposed Standard)
   Token: Robert Wilton

Amy: I have some Discusses in the tracker; do we need to discuss any of these
today?

Rob: Yes please. I think it would be useful. Thank you everyone for the
reviews, they've been useful. I think the main one I want to cover is Roman's
comment, which is about having a stable reference for this astronomical body.
I'm not sure what the answer is and what to do there. I've looked at their
website and it doesn't seem to have useful lists to reference. It seems to have
various names for the different bodies like planets and stars and things but no
stable list.

Francesca: I had the same comment as Roman but I didn't put it into a Discuss.
While I was looking for it I found a page that has, for example, the names for
the stars, but I didn't find something equivalent for everything else. But at
least for the stars I found one. Maybe there is, it's just we didn't find it.

Roman: What I was going to say is really simple; it's very clear the IAU is the
only entity that is reasonable as a reference here. I completely get that. I'm
flexible. If there's no way to get a stable reference, tough, that's still the
only place where the names come from. I'm willing to accommodate. If there's a
better reference that's fine, I think it's just a process thing of how to make
sure we say this is okay.

Francesca: I have a problem with that, because if we can't find what the names
are, we're just assuming that people will find them.

Roman: You're right. I made an assumption that there was a lot of content
behind the login portal that was on that website. If that's not true, I don't
know what other entity canonically names things other than this entity.

Rob: I don't think we want an IANA registry of astronomical bodies, it would be
a mistake to go down that path. We also couldn't use YANG identities. So I
think we need to have some text. Maybe we could define some of the common ones
and say these are some of the well known ones and if you want to go further,
these are places to look. I'm not sure otherwise how to tie this down to
something. It does make sense that they are defining what these names are and
we don't want to be duplicating that.

Francesca: We definitely don't want an IANA registry for it. Have you heard
from the authors that these pages exist or do not exist? I think we're just
looking for clarity here, maybe some more text indication on where to find this
list would be enough.

Rob: I've not heard back from Chris yet, so I can follow up with him. We'll
check if he knows any more references. My concern is if there isn't, what do we
do, and I guess we'll just have to try and find some text that is acceptable in
terms of where people can look. There are book pages that have the terms,
they're just not in an easy to consume list of terms, is the issue I have. On
some of the other points, I think Lars had some comments about a couple of
references and whether they should be normative. I think they can be
informative references, since they're only used as references in the registry
entries and I don't think they need to be normative. And Francesca, you also
raised the question as to whether we needed a separate registry for the CRS, I
think it's called. It looks to me that the aim of that was because Chris has
tried to make this flexible and allow this model to be used in other naming
systems it needed more flexibility. I noted even in his initial registry
entries he had multiple versions. So already he had expanded terms and I think
he was just trying to be pragmatic in allowing that. I think a separate
registry is probably the right answer.

Martin D: It says that it's unstable in the way that an IANA registry is
unstable. Things change, they add new stuff, when they discover new things,
they'll occasionally rename something and deprecate old names, but it's not
like if you have a Star 12345 that that's ambiguous between two different
astronomical bodies. They try to manage these sorts of collisions, because it
is a registry. I don't think there's a real issue here.

Rob: Is this for the first one, the IAU reference?

Martin D: Yes.

Rob: For me when I was looking, I just couldn't find an easy list. There's an
easy list for stars, but there's not an easy list for planets or stars on
planets or other astronomical bodies. Someone says if you log in they exist and
we can find that information out and then it's okay, but it's not an easy
reference to look at and if you're writing code against this it's hard to know
if it's valid or not, you just have to trust that the person entering it knows
what they're talking about.

Francesca: To go back to the registry, this really was just the paragraph I
quoted here, where it calls out this RFC 5870. If the authors hadn't written
this paragraph I wouldn't have realized, they pointed out themselves that
there's also this other registry with a stricter modification policy. So the
authors of this document have decided to create this registry that has a looser
modification policy and that to me is a warning sign. Are these registries used
for different things? It looks like they're registering basically the same
thing but with different registration policies.

Rob: I think the registry they were referencing is used for the geo URI and
they want that one to be quite strict, so that one they're not using. Whereas
in this particular case the registry is being used just to define the valid
terms to be used within that Yang model. And in some cases, if you wanted to
create a geolocation that was tied to Second Life or some abstract system, you
wouldn't want to add something into that main registry but you might want to
define a coordinate system for that. They just need a way to have names and
this new registry should be tied particularly to using this Yang model. Maybe
that should be made clearer.

Francesca: If there was some text about that, that would be completely fine.
Thank you.

Rob: Okay, so I think that solves the main ones. Ben had some questions about
precision vs accuracy; I think those are probably best discussed with Chris.
I'm not sure further discussion here is helpful; I understand Ben's query and
Ben understands where I'm coming from.

Ben: Yeah, there are at least a few nodes in the module where we should say a
little bit more about what we mean by them and that's probably enough.

Rob: To me it seemed like accuracy was what it meant, but the question in my
mind was then whether hypothetically we should have another leaf about
precision or whether that is not necessary or could be added in future.

Ben: I don't think that when you're talking about a coordinate system it makes
sense to have both accuracy and precision. The distinction is really only
relevant if you're taking measurements, and in order to take measurements you
need the reference frame to be fixed. I think this is really about within the
reference frame, how much precision can you get from any given measurement or
data point against that reference frame? So then it's just a question of these
numbers we put in there, are these measured in meters or a fraction of the
reported value, or what do I actually do with this number?

Rob: In terms of what the number is used for, I think it's just documentation.
That's what I feel this is used for, when somebody is deploying a route in the
field somewhere they're going to put in a location, and they're going to say
what the system is and to the nearest 5 meters or 10 meters or something.

Ben: Right, you'll put it in a map and have a ring and say this is how
confident I am. You have to take the number that's in the module and translate
it into the actual ring you're going to draw, or what your uncertainty is. We
only list units for one of them.

Warren: When I've deployed stuff, I use netbox to keep a list of where I have
all my widgets and I stick it in there and it has a spot for this sort of info.
What I do is I find the address of where I've stored the router, I put it in
Google maps, and then I copy and paste what it thinks the rough latitude and
longitude are. I don't really care that I can find the router exactly, I want
to know what building it's in and maybe what floor it's on. The rest of it
doesn't seem like accuracy or precision is what's needed. It's cool and sexy,
but I don't know if it's practically going to be used to that level of detail.

Erik K: This is for orbiting bodies though. Some of this is about estimating
the possible accuracy of the altitude.

Rob: The original aim for this model was for real life on Earth, to effectively
be able to identify where devices are. I think it was just expanded to cover
other bodies as well. Whether it had to, I don't know. But its main focus is
meant to be on earth.

Erik K: It's missing a few things to have a full orbital element set of
information necessary to compute the orbit, but it has some of the information.

Warren: Do you really think people are going to compute orbits based on this
data?

Erik K: No. There are other formats for that information.

Warren: It feels like we've gone fairly down the rathole that we should have
infinite amount of precision because you might need to be able to target it
directly.

Michelle: Just curious, do you know what the expected rate of requests we might
receive for this registry?

Rob: I thought it was going to be low. I don't expect there to be many entries.
This is just defining a Yang grouping so it depends how much it's actually used.

Michelle: Thank you.

Rob: I think we're probably at a point where we finished discussing. Everything
else I can take up in email. Thank you everyone for the discussion.

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

 o draft-ietf-opsawg-finding-geofeeds-10  - IETF stream
   Finding and Using Geofeed Data (Proposed Standard)
   Token: Robert Wilton

Amy: I have a few Discusses in the tracker for this document.

Rob: Thank you for all the comments, again. I think all the discussions are in
progress; thanks to Ben and Roman for the security things and I think the
others are fairly easy to resolve, I don't know if we need to discuss them.

Warren: Is Murray on the call? I think there was a misunderstanding there and I
think he's okay now, but I would like to check with him.

Rob: I think he had to step out.

Ben: He sent mail. He did have to step out, but I believe you're correct that
he's okay. He sent some suggested text to spell it out for 'people like me,' in
his words.

Roman: I cleared my Discuss on this because the validation steps got added in
the latest version but Ben, you still want some finesse on those validation
steps and that makes sense. So I think we're looking at at least another round
here.

Amy: Okay, so it sounds like this will be IESG Evaluation, Revised ID Needed.

 o draft-ietf-dnsop-nsec-ttl-04  - IETF stream
   NSEC and NSEC3 TTLs and NSEC Aggressive Use (Proposed Standard)
   Token: Warren Kumari

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

Warren: Can people remind me if there were any comments that really needed
addressing, or if the authors have done it? I can't remember. I suspect Revised
ID Needed just so I can go through and double check, just in case.

Peter van Dijk: May I speak up as author? I posted a new revision this morning
that should address all comments.

Warren: Thank you. I've seen that but haven't had a chance to check it yet.

Amy: Warren, do you still want this Approved, AD Followup?

Warren: Yes, I'll approve it by the end of the week.

 o draft-ietf-avtcore-multi-party-rtt-mix-18  - IETF stream
   RTP-mixer formatting of multiparty Real-time text (Proposed
   Standard)
   Token: Murray Kucherawy

Amy: I have a Discuss here.

Murray: No need to cover it; I'm waiting to hear what the authors say. This is
for the WG to answer, so we're good here.

Amy: So this will require a Revised ID?

Murray: Let's do AD Followup first, please.

Amy: Okay; IESG Evaluation, AD Followup. Thank you.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 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-yao-regext-bundling-registration-00
   IETF conflict review for draft-yao-regext-bundling-registration
     draft-yao-regext-bundling-registration-05
     Extensible Provisioning Protocol (EPP) Domain Name Mapping
   Extension for Strict Bundling Registration (ISE: Informational)
   Token: Murray Kucherawy

Amy: I have no Discusses for this conflict review, so unless there's an
objection now, this can go back to the ISE. Okay, this is approved.

3.4.2 Returning items

 NONE

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

 o Serialising Extended Data About Times and Events (sedate)

Amy: This is in the ART area and Francesca is shepherding this proposed WG. I
have no blocks for external review, so unless there's an objection now it looks
like external review is approved.

Francesca: Thanks everybody for the comments. I'd like to include all the
comments I got before we go for the next state. Is there a revise charter or
something like that?

Amy: It can go into Approved, Pending Edits, so we'll wait for your okay to
send this to external review.

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 o Limited Additional Mechanisms for PKIX and SMIME (lamps)

Amy: This is in SEC and Roman is the AD of record. I have no blocks on
approving this recharter.

Roman: I wanted to follow up with Eric V on his comment. Did you see my comment
about why we're naming NIST specifically and not anyone else, and are you okay
with me just dropping that sentence that created confusion?

Eric V: I will need to read it. I read it on my phone so I will read it again
after the telechat. What I read I'm fine with, I was just asking why NIST and
are we limiting us only to work on NIST algorithms? I think your reply was okay
but I need to read it again.

Roman: Okay, thanks. Let me know.

Eric V: I'm not blocking.

Roman: No, it's not a block, but it's important to have clarity so if there's
editorial polish that can make it cleaner about what we're doing to finesse,
I'm willing to spend a little time to make sure the editorial explanation of
what we're doing is worth it because this is important signaling to the
community.

Eric V: Okay, I'll do it.

Roman: Thank you.

Amy: I'm hearing this is Approved, pending possible edits? We'll just wait for
you to let us know it's ready, Roman.

5. IAB news we can use

Amy: Martin had to leave the call but he did send a note to the mailing list.

6. Management issues

6.1 Publishing COI guidelines and statements (Lars Eggert)

Lars: This is a proposal. Zahed is not back and I think he will need another
week or so at least. I'm undecided. We can either publish this now and add
Zahed's COI information when we have it, or we let it sit for another week or
so until he's back. I don't really care, I just wanted to discuss what we
should do.

Alvaro: Isn't this published already? It's already on the website.

Lars: Is it? I thought we were still waiting for all the COI information to be
collected before we published it.

Warren: It's up.

Lars: Is it including COI information or is it just the statement?

Amy: It does include the COI information we had. You gave me the instruction to
publish it without Zahed.

Lars: So we're just waiting on the announcement, then.

Amy: Right. We're waiting on the announcement and pointing people to it. It's
linked from the IESG webpage but I don't know how many people go there on any
given day.

Lars: Okay. So maybe that text is overtaken by events then. So let's wait on
the announcement until we get Zahed's information in, so we don't get a million
questions about why is one AD missing.

Mirja: I think Zahed is slowly starting to check mail so I can ping him if you
want.

Lars: It's not that urgent.

Warren: I thought I'd seen this announced somewhere.

Amy: You announced the conflict of interest guidelines, but you didn't say 'and
here are all of the conflicts of interest for this year.' The page has been
there for several weeks, when you finalized the COI guideline text.

Lars: Did we email out an announcement? We did? Huh.

Warren: Nobody has yet noticed or complained, surprisingly. Oh, I think it
might have just showed up on the IESG list.

Lars: I think it was only on the IESG list. We added it to the webpage but we
didn't announce it yet. Let's wait for Zahed and announce it.

Francesca: If it's already on the page, doesn't it make sense to announce it as
soon as possible?

Lars: The only thing I want to prevent is the conversation about why Zahed is
not listed.

Warren: But the other risk is that people will stumble across it and think
we're trying to hide it.

Martin D: I think people would assume it's been there forever or they'd missed
the announcement. I don't think it's going to create a kerfuffle.

Lars: If anybody complains I'll take the blame.

6.2 Finalizing IESG information for the NomCom (Lars Eggert)

Lars: You all saw the email. Gabriel wants a few things from us. He wants the
list of incumbents and I sent him the old one copied out of the last
announcement, so Erik's affiliation is wrong. He also wanted to know from the
incumbents who isn't running again. I know Ben isn't running and I've seen some
emails from some people that they're checking with their management. If you
still need to decide whether you can run again please decide soon, because
Gabriel wants to send he announcement soon.

Ben: It's not super critical to have a solid answer by then, you can always
change things after the call for nominations goes out.

Lars: If the announcement says the incumbent stands again you typically get a
smaller pool, so if you're doing that and pulling out we need to really make
sure the community knows the incumbent isn't really standing again so we get
viable candidates. That's really the only little reason why good information
early is better, but as Ben said it's not 100%.

Ben: I think in the past we've reversed the sense of how we talk about it, like
we put an asterisk for people who are not or may not be standing again. Just
from memory.

Lars: I don't recall. Do whatever has been done in the past. Gabriel asked for
information in the form I described and what goes in the announcement, I don't
know.

Ben: I don't want to distract our discussion right now from the other part of
the ask which is the job descriptions and which might take more time or effort
to go over, so it would be good for people to look those over by the end of the
week and give us a heads up if you think edits will be needed.

Lars: Every AD should look at your own description at the very least, but feel
free to look at the others, and put changes in email so we can give Gabriel an
updated list of descriptions. We'll need to be finished by next week so it'll
need to be done by email. That's it for this management item.

6.3 The update header (Francesca Palombini)

Francesca: I don't know if everyone has seen my email. I wanted to have a
moment to talk about this again because every time I have to review a document
which updates another document I do this over and over again and I thought we
can do better. Basically what I'm talking about is the updates. I know the IESG
has already talked about it and I think Ben Campbell was the one leading the
discussion on the IETF mailing list. I only looked in the IESG archives and I
didn't go into the depths of that discussion. I only read the conclusion from
Ben saying there is no consensus to have the IESG statement that says what
these updates header actually is intended to mean. I saw the IESG statement
that didn't get published and I saw the IESG internal discussion and I saw
Ben's conclusion that there is no consensus about that statement. Here I
reported that two current documents we can leverage as IESG when we don't
really understand what the authors or WG intended with the updates header. The
part that is most relevant is in RFC 2223, which described in a bit more detail
but that RFC is now obsoleted, so that cannot be leveraged as a valid
reference. Also I know of Mirja and Suresh's draft and I was chairing
Gendispatch when that came there. I'm not sure what happened with it. I think
Mirja said you still wanted to continue with this effort so I think that draft
is great but maybe we can do something in parallel at the same time. I think
the IESG statement I saw was very....maybe Ben C, you can summarize the main
problem people had with it, but in my opinion it was very specific and we don't
know that IETF people don't want to be told what they are supposed to do and we
want the flexibility. Maybe rather than telling what it means but giving them
different options they could use in their draft and giving us in the IESG a
reference to say I don't understand how your draft updates the other draft,
could you please explicitly state a more clear reference to this type of
request will be more helpful in my opinion.

Mirja: Maybe we had multiple draft versions of statements, but the latest
statement we came up with was actually not very specific. It was saying please
note, update is not defined so there's no clear meaning for it and no
implications, you can use it as you will. That's where we are. That was the
statement we wanted to put out because as you said, we had over and over the
same discussion about what updates means and everyone has their own opinion and
thinks they are completely right. Just something that says there is no
definition would have already been helpful. But then what happened is that we
did send this statement out on the IETF mailing list and asked for feedback
before publishing it as a statement. We had agreement on the IESG but then we
sent it out on the mailing list and people said no, this doesn't help, we
should define it more clearly. That's when we started writing the document, and
we got a lot of pushback on the document. Suresh wanted to do a survey about
how updates is used, which means looking into thousands of drafts, and he
didn't have time for it. So we somehow got lost in the weeds. I still want to
move on, just not sure when.

Francesca: I think that makes total sense, to move on with this document. In
the meantime, we keep bumping into this again and again.

Warren: What I've been doing is a) I make sure if somebody uses updates, they
explain in the abstract how it updates the document. Partly that's useful for
the reader but also partly it makes people think about it, they're not sure,
and they remove updates from the document, which makes my life easier.

Francesca: Sometimes that's really necessary, because as we've seen, updates
can mean the document is just an optional feature building on something else
you have to have read, sometimes it means this document obsoletes parts of the
other document and it's fixing a bug or something and you really have to read
it. Sometimes it's a mandatory read and sometimes it's not a mandatory read,
for the 'updated by' document. I got your comment, Warren, that you just do it.
When you review and it's not clear enough you just tell the authors to clarify.

Warren: I say I won't progress your document unless you do this.

Francesca: So you put it at the Discuss level?

Warren: No, I do it when I'm the responsible AD. They send me the document, I
say 'you used [updates] here, but unless you explain to me exactly how, sorry
I'm not going to do anything.' If we all do that, I think that would help.

Lars: Francesca, you just said something that I'm not sure I agree with, or my
understanding might be different. Sometimes updates means you have to read this
document if you want to implement this spec, and sometimes you don't have to.
But if you update something you need to normatively cite it, and a normative
citation implies that it's required.

Francesca: Let's say you have document A and document B where document B
updates A. If you read B then you always have to read A, I agree with that. But
sometimes you use update so that it obsoletes part of A, so you have to read B
because this is fixing a bug for A.

Mirja: But it provides a forward reference from the old document to the new
document. It just adds that to the metadata, but it doesn't mean anything about
being mandatory or not. If the document is important to you you have to go
through the list of updating documents and you have to look at the abstract and
hopefully the abstract will provide you enough information if you have to read
the whole document or not.

Lars: That's part of the problem. We put the updates into the newer document
and then you rely on metadata in the datatracker or RFC markup to provide the
updated by stuff which is actually interesting, so you're alerted to newer
stuff. There are two arrows and we're putting it in the wrong place because we
can't change RFCs.

Francesca: We all know that updates is used in different ways. Mirja and Suresh
have been working on actually having a proposal to clarify how it works. I
think we all agree that it's not very clear and the authors are responsible for
explaining this into the document. And what I was looking for is can we just
give authors and WG chairs some different options that they could pick from
that will also give us an easier way to say your draft doesn't explain it well
enough? Sometimes I'm pretty sure we'll end up in situations where an AD thinks
this is a good enough explanation of why this updates that, and then another AD
will not agree. This will also clarify in the IESG's opinion what updates mean,
because we don't always agree it's necessary, as we've seen in this week's
telechat.

Lars: So what are we doing? If I remember correctly there's a draft that's been
written in the past that people still seem to be interested in pushing forward.
Does that draft capture what we want it to capture?

Francesca: I think it's great if that draft moves forward. Another thing I just
thought about. My preference would be to go with an IESG statement and I know
you already tried that. Ben C, if you want to say a bit more why it failed
since I didn't read the whole discussion. Mirja said the statement was doing
less than what the people wanted the statement to do. Was that it? Can we not
have a simple statement with guidelines and a recommendation?

Warren: I think we can, and it kind of sounds like you've offered to write it.

Mirja: I don't think those guidelines are so easy because everyone has their
own definition and doesn't want to change it.

Warren: Possibly we could just do 'different interpretations of the updates
tag' and Francesca can list hers. I really want Roman, or was it John, to put
in his one that if you don't implement this you'll be a laughingstock.

Ben Campbell: At the time we had the discussion and took it to the IETF list,
you had a lot of people who wanted it to mean something specific but didn't
agree on what they wanted it to mean. I think it was exactly where we are now.
The discussion you're having here is very similar to the discussion we had
then. One of the things we ran into that made it hard was that people think
about this in terms of compliance instead of just interoperability. They start
getting into circles about whether their product managers are going to now say
they are compliant with a protocol because they didn't implement this thing
that was just updated. Some people were very worried about that.

Francesca: But we already have published RFCs that use updates in that certain
way.

Ben C: In every way you could imagine.

Francesca: Just collecting these ways, and not trying to define The Correct
Way, but just describing the ways updates has been used and asking people to
please clarify and these are possible ways that you can clarify. To me that
would be valid. can you foresee any strong reaction to that type of statement?

Ben C: I think that's where we ended up. That's what Mirja's draft was trying
to do.

Francesca: I think Mirja's draft had an even stronger approach.

Mirja: This is what we got from the followup IESG discussion and we wanted to
give it a try. Basically we had three options in there; amends, extends, and
something else, because these are the most known use cases and the most useful
ones.

Francesca: What I would like for us to do is describe the current use cases. It
doesn't have to contain every possible use, just the most common ones.

Mirja: The point of the statement was to say there is no well defined
definition. I think it did talk about different use cases people have. I'm not
sure what to do with that information.

Francesca: To me it would be a signal to the authors that it needs to be
something like this, if not one of these.

Mirja: But you can't really agree to that because there is a defined set based
on what we have but it's many uses. Whatever you say, it will not capture
everything.

Francesca: It would not capture everything but it would be better than what we
have now, which is a reference from a reference that gives us some sort of
ground for asking to please clarify what you mean by updates.

Warren: My earlier thing that I won't progress your document unless you do X,
isn't actually what I usually say. What I usually say is 'chances are when it
reaches IESG eval it won't go anywhere because blah blah.' Maybe instead of an
official thing we point at, we just have an agreement amongst ourselves and
when someone says 'I think updates means that' or 'I think it means this other
thing' you can say that might be right and doesn't seem unreasonable, but the
current view in the IESG is X. That is likely to be a lot easier to progress
than having the actual proper interpretation written down.

Francesca: That wasn't my suggestion, to have the proper interpretation. That's
probably what Mirja and Suresh's draft is aiming to define. For me it's more
about defining some current examples of how updates is used and ask authors to
do better at explaining. By writing this document we would also get to point
where we would have to explore our own interpretation.

Warren: I think what that sounds like is mostly asking Mirja and Suresh to
finish their document. It would be useful to have a better understanding, just
everybody seems to have their own personal one.

Francesca: Since we're talking about the I-D checklist, this could be part of
that. There is a section about updates.

Warren: I think we do need to be careful that we don't end up with the I-D
checklist becoming the way we secretly agree is our own policy without going
through the IETF process.

Francesca: You could see it as a clarification of the current I-D checklist.

Rob: I don't know if it would make sense but it could also be in the shepherd
writeup, to have some guidance in there and say it would be useful to clarify
at this stage.

Francesca: The shepherd writeup is already supposed to tell us things about the
status. If there's already a question about updates you could add something
there as well.

Lars: It sounds like Mirja and Suresh's document will solve this and it also
sounds like Francesca cares deeply so maybe she wants to help it along. We will
also have more discussions when it gets to IESG review.

Francesca: I wouldn't say I care deeply but I've identified something that to
me is easy to solve.

Mirja: There was pushback on this document mainly by one person, but also a
little bit by some others, who were kind of like why are you trying to solve a
problem that's not a problem for anybody but people on the IESG because they
get annoyed by it.

Rob: I think this is definitely worth solving for the IESG because we spend a
lot of time discussing it, and if we don't solve it now we're just going to
have this discussion in a a year's time with the new IESG. We need to find a
way to solve it.

Mirja: The point where we got stuck with the document is that this person who
was loudly complaining was asking for data, so we wanted to look at the
documents we have and categorize them a little bit. Suresh started with it and
then he got lost somewhere, so we need some help there.

Francesca: Why did I bring this up? Because I'm a relatively new AD and I did
the round of the wikis and statements trying to find this information about
what does updates mean. I've also done this type of research when I was
authoring a document and tried to figure out what to do. We discuss it over and
over and over again. I know maybe some people think it's a waste of time but if
we don't solve it now we're going to keep wasting time on it. I know Mirja has
a proposal on how to solve it. I support that we continue that work but at the
same time if we can do something shorter that doesn't require defining new
things, just explaining how it's used right now while we wait for this document.

Mirja: Having new clearly defined text would be the right thing to do but given
all the discussion we had I actually would be in favor of just having an IESG
statement because we could just point people to it. But we got a lot of
pushback on that. We don't have to ask for community feedback about IESG
statements, it's usually what the IESG thinks. For that one we asked and got a
lot of pushback, so just to publish it with different words doesn't look very
good.

Lars: Let's try it again and run it by only the chairs and ask if it matches
their understanding. Chairs have an interest here because they need to figure
out what it means to them and it's a smaller group. If we get consensus amongst
the chairs I'm pretty sure we can get consensus in the broader community.

Francesca: I can take the action item to try to take the IESG statement and go
through the discussion and try to formulate something that does what I was
thinking.

Lars: Is this a proposal to not publish Mirja's document?

Francesca: No, I think both things can move on in parallel.

Lars: But it will be confusing to have two things that will eventually not say
the same thing. I would rather do one and the document would be my preferred
way of doing it.

Francesca: But Mirja is bringing this forward as an individual but we as the
IESG right now can still have a statement how it works until now. We can have
an update later on.

Mirja: I think it would kind of make it impossible to publish this document.
We'd get even more pushback and people will say you already have the statement,
why do you need the document? It has been a lot of discussion. I have no idea
if this draft will ever make it or not.

Rob: I agree we should do one or the other. Doing both would be hard. The one
thing I thought was nice with your document, Mirja, is that I think you were
proposing new tags. I don't think we can introduce new tags as an IESG
statement, we can only say it has these meanings and you have to clarify in the
document. Having explicit tags in the metadata would be a stronger solution if
we could get there.

Francesca: Then if you think this will lower the chances of Mirja's document to
move forward, maybe we shouldn't do it. I still think we can do better.

Lars: We can maybe do better in the document. If there's something you're
missing in the document you can add it in there. I'm not sure how we could do
better by having a document and an IESG statement.

Ben K: The only thing I could see is if we put out an IESG statement very
quickly that acknowledges there is ambiguity and strongly encourages authors to
say what they mean. I think that could still be consistent with having a
document that follows later with more details and concrete changes.

Warren: That sounds like a fine idea.

Lars: We could put that in. We can already basically use that when we review
documents.

Francesca: That's exactly what I was looking for.

Eric V: You mean using plain text in the introduction and abstract?

Warren: I'll use an example. This document updates RFC 27 by specifying blah
blah. This document updates RFC 96 by removing the need to do X. I've found
that really useful because if I see in the abstract it changes something I
don't care about, it means I don't need to read this document. If I'm seeing a
document and it says it updates RFC 2119 by changing the font, I know I don't
care and don't need to read it.

Francesca: The thing is, sometimes documents motivate why this updates this
other document by giving the whole motivation of why this draft exists, not
just saying in what sense they are updating. That doesn't help, because it's
really good you're motivating why this document updates, but it's not very
helpful.

Warren: That's why for updates in general, at least in the abstract, I say
please make this one sentence. A while back we discussed doing shorter,
friendlier IESG statements. Should we see if we can just do a short, simple
IESG statement saying it's unclear what updates mean, it would be helpful if
authors could clearly specify something like this example, thanks.

Alvaro: Don't we already do this anyway? This is already in the checklist and
other places.

Mirja: I thought that was the content of the statement we proposed. I haven't
looked at recently.

Francesca: No, the I-D Checklist says if the document updates another document,
you have to have a sentence stating that's the case in the abstract and
introduction.

Warren: Nobody reads the I-D Checklist. I'll be happy to admit I don't know
where it is. I also think even if it's not a particularly helpful IESG
Statement, we should be in the habit of sending them more often.

Mirja: I think that was exactly the content of the statement we tried. I don't
want to stop you, I'm just saying.

Warren: Let's just publish it as is.

Mirja: That would be really bad, I think, because we went for community
feedback and the community feedback said not to do it, we should do it
differently, and then we do it anyway just two years later?

Francesca: I can volunteer to give a try to write an updated IESG Statement,
and that can help clarify what I'm looking for in such a statement as well.

Warren: I didn't think the community said no, don't do this, I thought the
community said this is fundamentally a useless statement, which is a very
different meaning. I think they said 'do better.' Maybe I should reread the
comments.

Mirja: In my memory 'do better' is probably the right summary, but still, we
got a lot of feedback and would be ignoring that feedback.

Rob: If we've asked for community feedback and they've said we don't like this,
I think us publishing this would come back and haunt us.

Warren: You're right. I'm looking through the feedback. I'd remembered the
feedback as 'I wish we had a better answer.' You're right.

Rob: The problem with us saying this is what we should do now, and by the way
we've got this document we're considering, they'll take this as the IESG
pushing that solution. That's hard to get that message across.

Warren: I think that I'm just sad we have a number of topics sufficiently
bike-shed-y that we can't make progress and we just keep kicking them down he
road.

Francesca: Anyway, if you are all okay with it I will give it a try. It doesn't
have to go anywhere but I'll try to bring it to the next IESG and then we don't
need to talk more about this.

6.4 Add Downref to RFC 7497 to the registry (Martin Duke)

Martin D: In the previous IESG ippm-capacity-metrics-method got a Discuss from
Magnus that was concerned about the congestion impact of what it did, so he
sent that to the WG for some reworking. That rework added a normative reference
to RFC 7497 which is Informational, which is basically the architecture and
approach. It needs to be normative. That's come back and thank you Lars for
catching that in your review. We added a downref and took it through a WG Last
Call but we did not take it through an IETF Last Call. Looking at RFC 8067 we
have the option of, as the IESG, waiving the IETF Last Call for the added
downref because that's a lot of procedure. The original Last Call had a couple
of directorate reviews and that was about it, there wasn't a ton of interest in
the document. This has constrained the use cases and hasn't made it more
expansive. I wanted to get the sense of the group if this was an appropriate
time to do an 8067 waiver or people really wanted to do another IETF Last Call,
before I put it on the ballot for the next telechat.

Lars: Remind me, the waiver means it's not getting added to the registry,
right? Because I think to be added it needs the Last Call. So it would unblock
this document but the next time they want to reference it again they'll need to
add a Last Call. Is that how the rules go?

Martin D: If the IESG decides not to repeat the LC, the status of the affected
downrefs is not changed and the process of 3967 will still apply when downrefs
are used in the future.

Lars So it would be a one shot moving this document forward but it would not
add anything to the downref registry. I'm fine with either way, I just want to
make sure we're not inadvertently violating the process we have for these
downrefs.

Martin D: It is the opinion of the authors that we will have more and more
downrefs to 7497, so we could just wait for next time, or we could bite the
bullet. I don't have super strong feelings about this.

Lars: I'm fine with a waiver and we'll catch it next time, and hopefully we'll
catch it early enough it won't be a problem.

Rob: Just to check, what's the cost of another Last Call? It doesn't need the
directorate reviews again. Is it just the extra two weeks you want to avoid?
I'm just trying to work out if it makes our life easier or not.

Martin D: I'm not going to argue it's super onerous. The authors have to suffer
a little more waiting and it's more spam on the IETF Last Call list, and I
guess the real risk is that someone reads it and has a huge problem with it,
and we have a thing we didn't have before.

Warren: There's also a cost to the community. We keep complaining that nobody
reads all of the documents going through IETF Last Call. If we re-do the ones
we don't expect people to read but we're just doing for process reasons, That
makes it easier for people to not bother reviewing.

Rob: I'm not actually trying to argue we need to put this through Last Call, I
don't mind what you do, but in that case we can easily specify at the top it's
only bing Last Called for this specific reason.

Francesca: I've just done the exact same thing to one of my docs that was in
auth 48. I just ran Last Call on a diff that was really minimal, just to follow
process. Otherwise why have the process?

Warren: If we do it we could just have a thing at the top of the Last Call text
to say no substantive changes.

Ben: I'm pretty sure we've done that before for exactly this downref reason.
The original Last Call did not note that there was a downref so we're re-doing
the Last Call with the downref.

Warren: I sometimes wonder if I'm re-doing a Last Call if I should explain why
at the top. Does anybody read that text?

Martin D: I don't have that strong an opinion on this. If you want me to run
Last Call again, that's fine, if not we can waive it. This is a four year old
RFC that updates 3967 and it says the requirement to explicitly mention
downrefs and refer to them in the Last Call message has proven to be
unnecessarily restrictive and has often resulted in unnecessary repetitions of
a Last Call with corresponding delay and no real benefit.

Warren: I think it should just be waived in this case. I don't see it causing
an issue.

Martin D: Does anyone think I should run it through Last Call? Okay, then I'm
hearing consensus we should follow the 8067 procedure. Thanks.

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

Martin D: I have one item. It came to my attention that there's a new interest
group in W3C called the web and networks interest group, which appears to be
very TAPS-ish. It's about network interfaces being presented to applications.
Informally I let the TAPS WG know, and that notice went to the chair of the W3C
interest group who is Dan Druta and not a stranger to IETF. So I just wanted to
know if people think we need some kind of liaison statement to document that
there's this collision, or are just the informal contacts I've already forged
good enough?

Mirja: That depends on what you want to achieve here. If you want to make sure
we can work together with this group if needed, it's better to just have people
participating in both groups and have a close relationship. If you have real
concerns about what they're doing and want to tell them not to do it, it's
better to raise those at the formal level.

Martin D: I don't think we're there yet. This is an interest group which
doesn't build specs, they just chat about stuff. Now that they're aware of this
work maybe they'll even leverage us to support their requirements. My sense is
that this is okay right now but I just wanted to run it by the group. If nobody
thinks we need a formal statement I'm happy not to do one.

Mirja: I think in cases where we send formal statements it's usually because eh
process of the other group requires it and we don't have another way to
communicate with them, or we want to be formal because we have real concerns we
want to be recorded somewhere.

Ben: This is just an interest group so we don't need to be all formal about it.

Martin D: Thanks.

Lars: I have one more thing before we go. I mentioned on a previous informal
call that the Secretariat was planing to do a test drive for hybrid meetings
during IETF 111 in San Francisco. There's now been a change and basically
that's not going to work anymore. They were going to have it at the Hilton
because the Hilton originally said they were open and could host distanced
meetings, and further discussions with the Hilton have turned out they're not
open. They will open next week and have one meeting before this test drive the
Secretariat had wanted to do theirs, which is a ten person event, so basically
the Hilton would use us to test drive their stuff rather than us using them. We
decided that's not going to be very great. There are a couple of ways we're
looking at for doing these tests for hybrid meetings. One is that the
Secretariat thought maybe there's a WG or a set of WGs having an interim that
will be a day or two long they could provide this support for to test out how
it would work, so they'd basically invite the Bay Area participants of those
WGs to some place to participate on site. I'm not aware of any WG that has
these long interims now that Quic doesn't have them anymore. If you guys have
some or you learn about them, keep this in mind. I also suggested they might
talk to Colin to do it for the ANRW, which is a slightly different event but
might work. Another idea was to see if the IESG and IAB end up having an
interim retreat in the fall, we might do it for that. Who would we stream it
to, is the question, since we'd really like everyone to show up in person.
There's another suggestion I can't remember. Basically the ask to the IESG is
if you know of any WGs who will have interims that are long, the Secretariat
would like to talk to the chairs and the ADs.

Warren: Whatever happens with this, keep in mind that a fair bit of the in
person / hybrid meetings are going to need a lot of work from the NOC. Normally
the NOC shows up on the Tuesday before. There's been a huge amount of changes
and it's going to be way more time than that.

Lars: Sean is involved in the discussions and the NOC is planning to be onsite
to support this and also do their test drive.

Martin D: What exactly is the concern with the Hilton testing their stuff with
us? That their IT infrastructure is going to collapse or something?

Lars: No, the advertising from the Hilton says we're fully open for your
socially distant meetings, but when you start talking and ask them 'so what are
the procedures at the Hilton?' they had very little to say. They haven't had
any meetings yet, so they have no experience with this. For example one thing
that's concerning is the Hilton says they require all staff to be vaccinated,
however they don't verify vaccination at all and take the word of the staff,
which is probably not going to be good enough for us. These very basic things
are not worked out, which makes the Secretariat nervous to go there. It seems
really like the Hilton would like to have meetings so that they can test their
approach to do these things rather than be available as a venue.

Ben: What is the concrete risk--that there's going to be some unforeseen
complication or inability to comply with requirements and we wouldn't be able
to do it?

Lars: I don't have the details because I wasn't involved in the discussion with
the Hilton, but Stephanie and Laura talked to them and basically said we can't
go there. Questions we asked about how social distance works during coffee
breaks, how are you organizing lunch, how are the bathroom facilities set up so
that distancing is possible, and there were very few answers.

Martin D: It's kind of a magic coincidence this thing is in San Francisco,
which is exactly where you want it to be to get a subcritical mass of people
and also have convenience for a lot of IETF staff to converge on this thing.
I'm not married to the Hilton particularly but getting something in the Bay
Area for this meeting seems like a really valuable opportunity we shouldn't
squander.

Lars: They want to do it in the Bay Area because the Secretariat is there and
there are enough participants that it can be done without anybody needing to
get on a plane. That's why they want to do it there. The Hilton was going to be
because we had a contract with them so we were going to use that contract to
avoid having to pay a penalty or some unrecoverable cost associated with not
meeting there in person. The Secretariat is now looking for another meeting
type that's close enough to an IETF hybrid meeting they could use to test drive
some of their procedures. The ask for the ADs is to keep that in mind if you
hear from WGs that want to have longer interims and have a significant presence
in the area. They're looking for about 30 participants to be on site.

Martin D: I understand the ask and can keep it in mind, but it seems like
finding another venue --

Lars: You don't need to find the venue. The Secretariat is going to do that and
they're already looking for alternatives. The ask is to find a group of people
to show up that are willing to test.

Warren: There's a group of people for IETF 111 who would be willing to show up.
Whatever the case, if we do something for an interim meeting it's going to
require NOC people and the NOC are probably going to require a couple of months
notice as well. If you're going to find an interim it should be one relatively
far out.

Lars: You should talk to Sean. The Secretariat has been talking to the NOC all
along. The change of plan about the Hilton is just from the last few days.

Mirja: I still don't understand why, even if they don't have 30 people coming,
whatever they test will be a closed setup with people they know well and can
check vaccination status before on their own, and they could still test some
procedures as they would set them up.

Lars: The Hilton isn't even able to guarantee the vaccination status or test
status of their employees that are going to cater to us. What else have they
not thought about? We couldn't just show up and test the stuff we want to test,
we'd have to make sure the Hilton procedures are there and that's too heavy a
lift.

Martin D: If we're looking to have a small venue, I strongly encourage them to
just find something in the Bay Area for 111 rather than shopping for some other
meeting, just do the one that's already scheduled for the Bay Area and go to
whatever building is available.

Lars: Keep in mind that the Secretariat is looking for a group to be guinea
pigs for interims. They're already looking at ways to do this for 111 but one
other source of groups might be interims and that's where the ask comes from.

Mirja: I think from the feedback here there's probably not going to be an
interim that will work.

Francesca: HTTP has some two hour interims. We could combine some of the HTTP
groups into a longer interim, but that runs the risk of making a smaller IETF
meeting.

Lars: It's okay for a cluster of groups to meet together, as long as it's not
during the IETF meeting week.