Narrative Minutes interim-2024-iesg-21: Thu 14:00
narrative-minutes-interim-2024-iesg-21-202410171400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2024-10-17 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
Deb Cooley (DHS CISA) / Security Area
Roman Danyliw (CERT/SEI) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat
Mahesh Jethanandani (Arrcus) / Operations and Management Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Warren Kumari (Google) / Operations and Management Area
Jean Mahoney (AMS) / RFC Editor Liaison
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Web and Internet Transport Area
Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area
David Schinazi (Google) / IAB Liaison
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Éric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Routing Area
Tommy Pauly (Apple) / IAB Chair
Orie Steele (Transmute) / Applications and Real-Time Area
Gunter Van de Velde (Nokia) / Routing Area

OBSERVERS
---------------------------------
Adoulaye Moses
Greg Wood

1.2 Bash the agenda

Liz: Does anyone want to add anything new to today's agenda? We have a new
management item from Roman on 121 agenda topics; anything else? Any other
changes?

1.3 Approval of the minutes of past telechats

Liz: Does anyone have an objection to the minutes from the October 3
teleconference being approved? I'm not hearing any, so those will be approved
and posted. Does anyone have an objection to the narrative minutes from the
October 3 teleconference being approved? I'm not hearing any, so those will be
approved and posted. I had also sent around the BOF call minutes; we got a
couple of corrections from Eric V. Are we ready to go ahead and approve those
now pending those corrections or wait until next week and see a final copy
first.

Eric V: It was pretty minor, in my case.

Liz: I can go back and check the recording; if it's okay with you, I'll go back
and double check those and then we can get them posted.

Roman: Sounds good.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

         o Deb Cooley to find designated experts for draft-ietf-gnap-core-
           protocol (GNAP Grant Request Parameters) [IANA #1373603].

Liz: We can mark this one provisionally approved, since we have some names from
Deb to approve at the end of the telechat.

         o Zahed Sarker to find designated experts for RFC 9653  (Zero
           Checksum for the Stream Control Transmission Protocol) [IANA
           #1378063].

Zahed: In progress; I should have it by next week.

         o Deb Cooley to find designated experts for RFC 9635 (Grant Negotiation
           and Authorization Protocol (GNAP)[IANA #1382992]

Liz: This is a new item for Deb but we already have names for it, so this one
is also provisionally done.

   * OPEN ACTION ITEMS

         o Orie Steele, Francesca Palombini, Murray Kucherawy, Mahesh
         Jethanandani,
           Warren Kumari to write draft of IESG statement addressing issue of
           credit in documents & the importance of capturing and addressing all
           comments as a necessary part of the consensus process, mostly
           pointing at existing advice.

Liz: We have this on the agenda today to discuss, so this one is in progress.

         o Murray Kucherawy and Eric Vyncke to create a draft IESG statement
           about using 2119 language.

Liz: And we also have this one on today's agenda, so this is in progress as
well.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-bfd-unaffiliated-echo-12  - IETF stream
   Unaffiliated Bidirectional Forwarding Detection (BFD) Echo
   (Proposed Standard)
   Token: Eric Vyncke

Liz: We have a couple of Discusses here; do we want to discuss these now?

Eric V: Most probably yes as John and Roman are here, for addressing the
charter issue. As you may notice, I'm not normally the BFD AD, I took this over
from John. John proposed a resolution of Roman's point by updating the charter
after.

John: Roman and I have been discussing that offline. I don't know if Roman
wants to chime in.

Roman: I'm in the process. I just didn't finish writing Jeff back on the
response. I think the plan here was for the working group to go quiescent or
close after it finished this document. I would have certainly been willing to
be flexible if we were just talking about one document, but the challenge here
is that if you look at other documents that are in the queue, to include
another one that you're doing Eric, it's also not in scope. And then there's
another one that's in the working group last call that's not in scope. So it's
a bit of a problem that we have multiple documents that are not in scope. I
think the answer is we have to  step back and say, how did we end up here? And
I think the answer to that actually doesn't matter. I think the get well plan
is if we have a bunch of things that are adopted in the working group, let's
revise the charter to kind of cover that. And if there's some exigent situation
that we desperately need to get them out, let's talk. But if this is just that
we gotta run the administrative traps, I'm inclined to say we should recharter
to make the three documents that are out of scope in scope if that's what the
community wants.

John: That's already in flight. Personally, I wouldn't hold a Discuss under
those circumstances, but it's certainly your privilege to do so and either way
we'll get it cleared.

Roman: Okay.

Mahesh: There are three more of those BFD documents that are coming as a
cluster behind these three.

John: Okay, so, yeah, we'll, we'll scrub the whole list and try to make sure
that we have every one of them in scope for the next version. Thanks.

Eric V: And the other point, Zahed and a few others, it's about I think the
misunderstanding of what BFD is doing in this case. Because, and correct me
John, and I'm not sure whether there are authors on the call here. Basically,
one node is sending a packet to the IP address of itself, so it will be routed
back by the next layer tree up. I tried to convince the author to add this
thing and the address selection in the document during my AD review and to be
honest, and sorry if they are in the call, they declined. And I think it should
come back in the text to make this clearer Zahed, I think it will be clearing
your Discuss point here because basically you send a new EDP packet and the
next stop will send it back to you. So it's not really going very far away, or
maybe I misunderstood you.

Zahed: No, I think that there are a couple of things. Brian pointed out that he
misunderstood. This could be forwarded to anybody and that's true for any IP
packet forwarder you just tell to forward to something. That's kind of not the
case here. I think the Discuss point I'm making is that this is explicitly
saying this is a one hop thing and we don't need congestion control for this
one. And I have a problem with that one because in the UDP uses guideline you
should have congestion control and in cases we must have congestion control if
we are actually using UDP. In 5880 it says that congestion control is not only
a traffic phenomenon, it's also a competitional phenomenon. So this router that
you are looping back will be congested due to lack of resources and it may not
do the thing that it's supposed to do. And then it also says like even if it's
for one hop, you should consider congestion control, and now in this
specification we're scrapping all those things. So I have an issue with that.
So this is a different thing than what Brian and others are talking about. And
then also I think I see some sort of inconsistency in this specification, it
says like device A sending a packet to device B with the loopback IP coming
back to device A, right? That's the thing. Now device B sometimes says hey,
this doesn't need to understand or implement BFD. Sometimes it says ok, it's a
BFD session or not a BFD session. Sometimes it says ok, if you need
authentication, you need to do authentication sections according to the BFD.
Now my question is like, what is this device? It is very confusing. I didn't
put a Discuss on it because I think this is a kind of editorial thing we can
fix, but we need some very specific text. If we say we don't need congestion
control for this UDP, we need to be very specifically explaining why we think
so. That explanation is not there. I think we can remove it, that should be
also fine but then we just refer to 5880 saying all the operational things are
there.

Eric V: Just to be clear, do you think that the congestion control should be
sent at the sending nodes or the router A when it's sending the probe? Because
then it is SSAM control, but the router B which is simply looping back, it's
layer three.

Zahed: Exactly, the sending notes. And this is also a confusion for me when I'm
reading this specification. This specification is specifically for device A,
not device B, because device B could be anything.

Eric V: Okay, so I see a path to resolution with the authors, I mean, we see
how they react to this.. So if nobody else has had a point and they are the two
Discusses I think we have a path.

Mahesh: I just wanted to point out that to your question of the actual
methodology, I did have a related question, which was why is it a single hop
only? And I was asking for some clarification in the document and Jeff actually
provided two links. He said, first of all, you should read it in the context of
5880 and 5881 and he gave me two links. So if they add those two references in
the document, I think you have a better description of how the packet is
getting echoed back.

Eric V: Okay, thank you. Obviously revised I-D needed, right?

Liz: Great, so this one is staying in IESG evaluation with a substate of
revised I-D needed.

Eric V: Thank you Liz, and thank you everyone for reading it.

 o draft-ietf-jmap-calendars-20  - IETF stream
   JMAP for Calendars (Proposed Standard)
   Token: Murray Kucherawy

Liz: There is a Discuss here; do we want to discuss this now?

Murray: Nope, not necessary. I'm going to wait for the authors to get back. The
question is clear.

Liz: So this one will stay in IESG Evaluation; will there be a revised I-D
needed?

Murray: Put it in AD Followup and I'll switch it to Revised I-D Needed if
that's the outcome.

 o draft-ietf-mpls-rfc6374-sr-16  - IETF stream
   Performance Measurement for Segment Routing Networks with MPLS Data
   Plane (Proposed Standard)
   Token: Jim Guichard

Liz: There are no Discusses in the tracker, so unless there's an objection now
this one is ready to go. Since Jim isn't here today, we'll put this in AD
Followup in case there was anything else he wanted to do with it.

 o draft-ietf-extra-6855bis-03  - IETF stream
   IMAP Support for UTF-8 (Proposed Standard)
   Token: Murray Kucherawy

Liz: There are no Discusses in the tracker, so unless there's an objection now
this one is approved. Murray, is this ready to go or do you want to do anything
else to it?

Murray: Approved::AD Followup please, I'll check with them once more.

 o draft-ietf-avtcore-rtp-payload-registry-04  - IETF stream
   Closing the RTP Payload Format Media Types IANA Registry (Proposed
   Standard)
   Token: Zaheduzzaman Sarker

Liz: There is a Discuss here; do we want to discuss this now?

Zahed: Not really. I think this will be updated, so with that update my hope is
that it addresses Gunter's Discuss. The general question was why is this
standards track, and there has been discussion of this. The authors thought it
had the highest kind of status at the document level so that in future it
doesn't have trouble and we know how the registry was created. I think we're
fine here. Is Gunter on the call today?

Liz: No, he's not here today.

Zahed: Okay. I think I'm waiting for a response.

Liz: Okay, so this document will stay in IESG Evaluation::Revised I-D Needed.
And just as a warning, Zahed, this document does have a downref, so we will
need to know if 8088 should be added to the downref registry.

Zahed: Okay. This was called out in Last Call, right? I'll let you know when we
clear this.

2.1.2 Returning items

 o draft-ietf-sidrops-rrdp-desynchronization-04  - IETF stream
   Detecting RRDP Session Desynchronization (Proposed Standard)
   Token: Warren Kumari

Liz: There are no Discusses, so unless there's an objection now, this is
approved.

Warren: As a quick reminder, this document has already been through before,
everyone said it should come back as PS, and it's now done that. I believe it's
ready to go. Approved, Announcement to be sent.

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

 NONE

3.4.2 Returning items

 NONE

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

 o Update to IANA Considerations (ianabis)

Liz: I don't see any blocking comments, so I think this is ready for external
review.

Murray: I need like an hour to just look at the feedback Gunter gave and see if
I want to use any of it. I'll give you the go-ahead later this morning.

Liz: Okay, so we will wait to hear from you and send this for external review.

4.1.2 Proposed for approval

 o Standard Communication with Network Elements (scone)

Liz: I don't see any blocking comments, so this one is approved. Does anyone
want to discuss it now?

Zahed: I think I have a simple update that I need to add two more words in the
charter, which I'll do and let you know. Mahesh, are you happy with the
resolution we're ending on now?

Mahesh: Yes, Martin and I came to agreement last night about the last edits so
once those are updated I think we're good.

Zahed: Okay, so I just have those two words to add.

Liz: Great; Zahed, we'll wait for you and when you're ready it will be approved.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 o Messaging Layer Security (mls)

Liz: There are no blocking comments here so unless there's an objection now,
this recharter is approved.

Paul: The chair just added a few milestones to please Eric.

Liz: Paul, is this ready to go?

Paul: I just want to check the comments; I'll let you know later today or
tomorrow.

5. IAB news we can use

John: The things I noted down were: there's a limited domains document coming
from them and Suresh at some point and the IAB was talking about whether it's
time to try to engage the community at large considering that it's targeted
toward BCP. And there was a discussion about whether they should advertise it
during the IAB plenary report and the feeling was to publish the document first
and then start advertising it. So I think they're not going to do that. The
other thing is they were looking for anybody with contacts at Tesla to try to
get the Tesla people to talk about this TTPOE thing, so if any of you have
them, they're looking. Then [Ryan Polk, ISOC liaison] mentioned that Monday is
Global Encryption Day, so if you didn't know that now you know. They also
suggested nemops for the joint meeting agenda, and I don't know what they want
to talk about, but there it is. And finally, they're having a policy round
table breakfast and are hoping to get at least some IESG representation. Those
are all my notes. Any questions?

6. Management issues

6.1 [IANA #1376075] IESG approval for application/toml (IANA)

Liz: This is returning from last time; has anyone had a chance to look into
this further?

Roman: I have and Murray, thank you for talking to Alexey to give us a better
explanation of the deeper history of those kinds of media types. That's a lot
of archaic things that I didn't understand, so this is I guess exactly why we
have Alexey in that seat. So this looks good to me. Thanks for the extra time.

Murray: Same.

Liz: Okay, great. Any objections to approving this? (pause) Fantastic, so we'll
call that approved and we will get that official note sent to IANA.

6.2 [IANA #1375267] IESG approval for protocol number (homa) (IANA)

Liz: This item is also returning; has anyone looked into this?

Eric V: I contacted the requester late, to be honest, just this weekend. He
appears to be a professor at Stanford. I sent him an email asking him if he
considered making the specification of this homa protocol public, and if he
considered running it over UDP because if you want to do datagram only. No
reply yet. I suggest we wait until the next telechat and then de facto we
approve it, because we are not running out of IP numbers. As a side note, the
code is currently using the experimental protocol 254 and it works on v6, so I
cannot refuse anything. The last part is a joke, of course. So we defer to the
next telechat hoping to get a reply from John, and if not, I suggest we approve
it anyway.

Liz: Any objections to that path forward? Okay, so we'll bring this back one
more time to our next telechat.

6.3 [IANA #1373603] Designated experts for draft-ietf-gnap-core-protocol (GNAP
Grant Request Parameters) (Deb Cooley)

Liz: Deb has identified Justin Richer, Joe Salowey, and Sudesha Shetty as the
designated experts for this registry. Any objection to approving these three?
I'm not hearing any, so they are approved and we will get that official note
sent to IANA.

6.4 Approval of IESG Statement on Use of BCP 14 Key Words (Murray Kucherawy)

Murray: I circulated the link again after the last informal. I think it's ready
to rock.

Roman: I think I dropped a lot of different commentary on there. I'm
uncomfortable with the text as is. As we're pulling it up, one meta question I
have here is, what is the force with which we're publishing this statement? So
we have a published RFC, and we have a BCP on using those keywords and in this
document, we are refining BCP 14 and not sure what noun to use, claims, we're
setting guidance. We're doing something. So I guess the brass tacks for me
would be if I violate this statement, is that a Discuss?

Warren: No.

Roman: If I'm consistent with BCP 14, but not with this statement, what does
that mean?

Warren: It means that you're doing what the RFC says, but you're choosing to
ignore some friendly advice which this has, right? This is a narrative or
interpretation of what's actually said in the RFC to make it easier for people
to follow along. It's an IESG statement saying we think blah blah, blah, but if
you don't follow it…I mean it also can't be directly followed or not, it's more
background narrative.

Murray: The use of 14 stuff has changed over the years, even in the time that
I've been on the IESG there's been little adjustments to it. So some of this is
that the community needs some understanding of how we apply this stuff and also
incoming area directors, there's some background knowledge here that they
should probably have. I was surprised, for example, that security uses of these
keywords have nothing to do with interoperability. They're just really strong
security advice. But BCP 14 if you read it plainly, doesn't say that's what
that's supposed to be used for. And also like the operations of requirements
around mandatory logging and that kind of stuff, also not something that is in
there at all. In my early days on the IESG I was asking questions like, wait,
is this proper use or not? And it has come to be proper, can be considered
proper or acceptable use. So, that was some of the purpose of writing this
stuff, but also we see bad habits, like you shouldn't be using these words in
IANA considerations, or in an abstract, and this is that sort of collective
wisdom. Now, the stronger way to do this is to rewrite 14 again to include all
of this stuff as that, that makes it absolutely clear, there's community
consensus on all this. This statement has IESG consensus, it doesn't have
community agreement necessarily. So I'm fine with it if we wanna try to turn
this into an update of the BCP effort, great. But this is not meant to be that
strong. But to answer your original question, I would Discuss it. Once this
goes up, yes, I would Discuss on something that goes against these guidelines.

Warren: To me, this seems like the quick start guide when you buy a product,
right? You have the big thick instruction manual which nobody reads. This is
the quick start guide that gives you an overview.

Roman: But I just heard us say two different things. When I said, would we
Discuss on this, Warren said no, it's conformance to the RFC, this is friendly
advice. And Murray, I just heard you  said you would Discuss on this. So we're
suggesting that this carries different weight.

Warren: I think that anything you could Discuss on this is stuff you would be
able to Discuss on BCP 14 as well, right? This is a thing which summarizes it.
So if it's wrong in here, it's by definition wrong in 14 as well. So the
Discuss isn't you're Discussing on the stuff in the statement, you're
Discussing on the 14 stuff.

Francesca: Strong agreement, Warren, and by the way, I already Discuss BCP 14
words based on what's written in the statement. So it's already the case; to me
this just clarifies the thought process behind it.

John: Kust to take one example from this, I can't remember where it is in the
statement, but there's something that says, Look people, 2119 keywords are not
the only way to be normative. I think that's just bloody obvious and I'm pretty
sure it's there in the plain text of 2119, but there's like some kind of
assumption that authors who haven't actually read 2119 have come up with that
things have to be in capital letters because capital letters. So I think it's
helpful to restate these things even though they're supposed to be known.

Roman: So if we think that's the case, and I'm gonna set aside whether I agree
with that, I would strongly recommend we include a sentence to the effect of
not changing what BCP 14 says, this is just… This is the place where I don't
want to define it here on the fly, but something, right? So the letter of the
law is still BCP 14, we haven't invented anything new.

Murray: Right, sure we can say that.

Roman: But I want to talk about whether we've invented something new here. Like
my comment, I think it's my third one down on the screen. I think I said that
bullet point is literally the definition of how I understand SHOULD.

Murray: Oh, here it is. I see the distinction. Sometimes when you're writing a
doc, when I've seen this case, they want to stipulate that you have to do a
thing, but they're afraid of being that strong because if I am that strong and
I prescribe any other behavior, people aren't going to implement this. And so
they back off of MUST and go to SHOULD just for that reason, and that's not a
good reason to go to SHOULD. So we could find another way to say this.

Roman: I understand that. That's certainly not how I read it.

Murray: Okay. We can clarify that. To your larger point, none of this is
changing any behavior at all, and we can say that explicitly. A lot of this is
writing down how the IESG has come to use this BCP 14 stuff over the years and
it's more like drawing a line in the sand and saying this is how we interpret
it today. This is how it gets used. Sometimes you can get Discusses in ways you
might not expect. This is why. This is a distillation of my experience with BCP
14 over the last five years is another way to look at it.

Roman: I welcome having texts like this, I maybe should have opened with that.
I absolutely welcome this and I think it'll be very helpful to the community. I
just don't want to create confusion in the community that we have somehow
extended BCP 14 without revving the document. Just making that crystal clear.

Murray: Okay.

Deb: I think you might be able to do that by subtly changing the title of the
document.

Murray: Okay, I can look at that too.

Deb: Because then it's up front. So the trick is you've got it in the second
paragraph, and you haven't buried the lede exactly, but if you put it in the
title like this is clarifications or guidance or some weasel words like that,
then it's right in the title.

Eric V: I like clarification in the title indeed.

Murray: Okay.

Roman: I'm not married to the title, but I think Deb, you're exactly onto
something. The words that trip me in the second paragraph is providing guidance
"supplementary" to BCP 14. The way I read it is you have BCP 14, and now
there's this extra stuff that's supplementary, not that you're providing the
interpretation of BCP 14.

Deb:  I think things like clarifying guidance as opposed to just guidance,
taking out things like "supplementary" too, which sort of points to it like
it's meant to be a change, but you haven't made the change. I can take a look
at this, probably not till tomorrow.

Murray: That's fine, and feel free to make some suggestions in the doc for how
I can change the title and where should I make that, should the second
paragraph go up to the top or something like that. Can we just repeat this
action item in a week? Is that enough time? Roman in particular, is this
correctable in that period of time, do you think?

Roman: Yeah, absolutely. Do we have an informal next Thursday?

Murray: No, we have a formal.

Liz: That's our last telechat before Dublin, we have a back to back formal next
week.

Roman: I forgot that we're doing back to back. Let's put this on the agenda.

6.5 IESG Statement Addressing Comments and Crediting Contributions (Orie,
Francesca, Murray, Mahesh, and Warren)

Liz: This one looks like it's also not ready to go based on the Google
document. Do we want to discuss this now?

Francesca: Orie's not here, but I think we should discuss your comments, Roman.
I haven't had time to go through it.

Roman: My top line feedback is very similar to what Deb said in one of her
comments; I think there are distinct ideas being introduced here. Maybe if we
made section headers it would better organize it. Right now it's a flow I don't
understand. We're losing the point, we're repeating ourselves. I understand
sometimes we need to use the same supporting references to make a different
point but the message is getting lost in that flow. The easiest suggestion
might be to add some section headers with some top line statements about what
the guidance is after the section header.

Francesca: That sounds good; we can give it a try.

Deb: It just sort of looked like it was hopping all over the map. I've
unfortunately had a fair bit of experience trying to explain things to people
who don't have enough cycles. In my book, shorter is better and you've gotta
hit them in the face with it. Section headers help them to organize it, I think.

Francesca: There are different kinds of statements, that's not the right word,
but there are different things being said and I feel like not everything is
covered. Maybe that will help. I'm going to remove the "ship it" names and
we'll give it another try. Let's put it on the agenda for next week as well and
hopefully we can approve it by then. I guess Orie and I will send an email to
slack or the mailing list when we have done our homework.

Warren: I'll be at NANOG next week, but I'm fine with whatever people want to
do with either of these documents.

Zahed: Same as Warren; next week I'll be completely unavailable for any IETF
work but I trust you all to do the right thing.

Liz: Okay, so we will bring back both of these draft statements next week.

6.6 [IANA #1382992] Designated experts for RFC 9635 (Grant Negotiation and
Authorization Protocol (GNAP)) (IANA)

Liz: Deb has identified the same three names as for the last one, Justin, Joe,
and Sudesha. Any objection to approving them?

Eric V: I just want to say maybe Joe's email address is not correct? It should
be spelled the same as his last name.

Liz: Good catch. We can double check the spelling of his email address and
whichever one is correct, we will send that to IANA in the official note for
both of them. So they are approved here as well.

6.7 IESG Agenda for IETF 121 (Roman Danyliw)

Roman: Just quickly, please put any agenda topics you have on the wiki and
remember, we have two buckets we need to fill, things we want to talk about
with the IAB, things we wanna talk about ourselves, and hypothetically if we
want to bring someone else in, either have a longer conversation with IANA,
legal counsel or whatnot, I'm sure we could accommodate that if we can just
provide enough advanced notice. So please fill that out so folks can start
planning their meeting week.

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

Warren: We will be trying some new stuff on the IETF network in Dublin.
Specifically, we're going to be using the big shiny Juniper firewalls instead
of the routers. We think everything should be fine, but just a heads up, if you
notice anything weird or funky please let me/the NOC know. Especially with
nat64.