Skip to main content

Narrative Minutes interim-2023-iesg-22 2023-10-05 14:00
narrative-minutes-interim-2023-iesg-22-202310051400-00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2023-10-05 14:00
Title Narrative Minutes interim-2023-iesg-22 2023-10-05 14:00
State (None)
Other versions plain text
Last updated 2024-02-23

narrative-minutes-interim-2023-iesg-22-202310051400-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2023-10-05 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Jenny Bui, Secretariat

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jenny Bui (AMS) / IETF Secretariat
Roman Danyliw (CERT/SEI) / Security Area
Dhruv Dhody (Huawei) / IAB Liaison
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Routing Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
√Čric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Martin Duke (Google) / Transport Area
Warren Kumari (Google) / Operations and Management Area

OBSERVERS
---------------------------------
Brendan McMillion
Greg Wood
Jeffrey Zhang

1.2 Bash the agenda

Liz: Does anyone have anything to add to today's agenda or any changes?

1.3 Approval of the minutes of past telechats

Liz: Does anyone have any objections to the minutes of the September 21st
teleconference being approved? Hearing no objections so we'll get those posted.
We also have narrative minutes, does anyone have any objections to the
narratives minutes being approved? Hearing no objections, we'll get those
posted as well. This time we also have the minutes from the BoF coordination
call for approval which you've seen a couple of versions of in email. Does
anyone have any objections to the BoF minutes being approved? Hearing no
objections from there either so we will get all of those posted.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED


        o Rob Wilton to find designated experts for RFC 9445 (RADIUS
      Extensions for DHCP-Configured Services) [IANA #1279159]

Eric: Rob told us he'll be late in the call so we might want to push this back
to the end.

Liz: Sure, we can just leave this in progress for him.


        o Roman Danyliw to find designated experts for draft-yee-ssh-iana-
      requirements-03 (Key Exchange Method Names) [IANA #1281831].
        o Roman Danyliw to find designated experts for RFC 9447, ACME
      Authority Token Challenge Types" [IANA #1281679].

Roman: I have some names planned, I just haven't closed the loop with a
position yes so i'll get this sorted out. It's more than normal in progress.


   * OPEN ACTION ITEMS


        o Warren Kumari to follow up on a bis document for RFC 8126 regarding
      designated experts.

Liz: Warren is not with us today so we'll leave this in progress for him.

    o Roman Danyliw to open a Datatracker issue suggesting a feature to
      better signal individual contributions.

Roman: Needed to sync with the LLC, with Greg on the CAUSEPLAN? they were
working on. They've given me feedback that were all clear. I'm just looking at
my retreat notes because I feel like we made the right words for this but in
the Datatracker, i've been unable to locate them. I just need a little more
time to keep searching.

    o Andrew Alston, Murray Kucherawy, Zahed Sarker, Martin Duke, John
      Scudder, and Jim Guichard to draft text regarding document
      authorship/editorship with regards to the number of authors listed.

Andrew: I have just sent to the IESG some draft text that myself and the other
guys who are working on it have done some edits. Still in progress and we'll
need to have a discussion about it and what what we're doing to do about it. I
proposed that i'll probably put it in the informal agenda next week.

    o Lars Eggert to facilitate a community discussion on priorities for
      IESG processes.

Liz: we don't have Lars yet, so we'll leave this in progress for him.

    o Lars Eggert and Warren Kumari to 1) draft a revision of RFC 4858,
      2) draft a revised IESG Statement on Document Shepherds (original
      statement October 2010), and 3) update the WG Chairs wiki to point
      to the new IESG Statement.

Liz: Neither of them are here so we'll leave in progress.

    o Warren Kumari to follow up with the tools team regarding removing
      the requirement of needing an author email for deceased authors.

Liz: We'll skip that.


        o Martin Duke to draft an email to the community about the ART/TSV
      Area merger.

Liz: I know this is done. Martin is not here, so we'll just mark that as done
for him.

    o John Scudder to update the NomCom instructions from the IESG with
      information about the ART/TSV merger.

John: That is done.

    o John Scudder to follow up on the RSWG Chair appointment.

John: Also done.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

  o draft-ietf-bess-mvpn-evpn-aggregation-label-13  - IETF stream
    MVPN/EVPN Tunnel Aggregation with Common Labels (Proposed Standard)
    Token: Andrew Alston

Liz: There are no discusses in the Tracker unless there is an objection it
looks like this one is approved.

Andrew: Yep, and all of the comments from what I can see has been resolved as
well. This one can move ahead.

Liz: Do you want to check it over one last time or this ready to go?

Andrew: I did that this afternoon. I'm comfortable, this is ready to go.

Liz: This one is approved and actually ready. We will send that announcement.

  o draft-ietf-ohai-svcb-config-06  - IETF stream
    Discovery of Oblivious Services via Service Binding Records
    (Proposed Standard)
    Token: Murray Kucherawy

Liz: There's no discusses in the Tracker, so if there's no objection this one
is also ready to be approved.

Murray: AD follow-up please, I just want to check with them one more time to
see if they have anything pending but after i'll approve it

Liz: Great. This will be approved announcement to be sent, AD follow-up and you
can let us know when this is ready to go.

  o draft-ietf-regext-rdap-openid-25  - IETF stream
    Federated Authentication for the Registration Data Access Protocol
    (RDAP) using OpenID Connect (Proposed Standard)
    Token: Murray Kucherawy

Liz: We do have a couple of discusses for this document, do we need to discuss
it today?

Murray: No, I expected one from Roman. Thank you for your detailed work; both
of you. I will take it up with the working group. Unless one of you want the
airtime.

Liz: We'll keep this in IESG evaluation. Is this going to require a revised ID?

Murray: Almost certainly, so go ahead. I'll change it if I have to.

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

  o status-change-lisp-eid-block-to-historic-00  - IETF stream
    Move RFC7954 and RFC7955 to Historic (None)
    Token: Jim Guichard

Liz: The consensus is unknown so we can go ahead and change this to yes for you.
We have no disccues in the tracker so unless there's an objection I think this
one is ready to go.

Andrew: This is most yeses i've been on a document, particularly one that
doesn't officially have consensus.

Murray: It's not technically a document otherwise I would've made the same
observation.

Jim: It's a record.

Liz: Jim, is this ready to go as is? Do you want check anything over first?

Jim: There's a couple of text changes I need to add, very minimal. There was
one comment on the last call that I wanted to add some text, if that's ok. Once
I've done that, it's ready to go.

Liz: Ok great. We'll put this in AD follow-up for you and you can let us know
when it's ready to go.

3.3.2 Returning items

  NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

  o conflict-review-irtf-icnrg-pathsteering-00
    IETF conflict review for draft-irtf-icnrg-pathsteering
      draft-irtf-icnrg-pathsteering-07
      Path Steering in CCNx and NDN (IRTF: Experimental)
    Token: Erik Kline

Liz: We do have a discuss here, do we want to discuss it now?

Erik: Zahed, I didn't notice this until not too long ago. Just by looking
through the document for congestion control, I saw that they made claims that
they support congestion control.  That is even supports or enables something to
happen for congestion control with better information. Not that it particularly
participates in congestion control. Could add CCWG, if you want to jump in.

Zahed: I wasn't sure what they're doing so that's why I came up this idea
because it relates to CCWG. They use art multiple control algorithm, I don't
know what that is. If there is some reference document published somewhere that
is straight-up art then I don't know. I think this is conflicting because how
transport AD sees the congestion control and multiple congestion control
algorithm right now, and what it is right there. That is the one thing that I
was discussing over email, I think if somehow there are multiple congestion
control algorithms then definitely the need approval for their work that should
some how relate to CCWG. My thing is if we write this relation and someone
later picks it up. Right now i'm not sure.

Andrew: I will say stating state of the art anything, particularly in documents
that are going to live for a long time is kind of concerning. Erik, another
thing is we obviously looking at this from a conflict perspective, but reading
I do think they need to do something about a glossary or something because
reading it without was sort of a headache.

Erik: so those are comments for the document, but there wasn't comments for the
conflict nature of the document. I agree state of the art probably shouldn't be
in there, but we can say it conflicts with something. We can definitely say it
has overlap with CCWG, but I didn't detect that it claims it was doing any
congestion control in here.

Zahed: That's what my problem is, i'm not sure what they're doing.

Erik: So my read of this, with my layman's understand of this stuff and having
have done a couple of view but by no means understanding it with any depths.
This is kind of like recordroute, ICO and ICOP option recordroute. Recordroute
gets sent in the interest message and resulting route gets returned back to the
original sender. You can then use that resulting route information to basically
send a packet along the same route again.

Zahed: They are also saying that kind of information could be helpful for their
congestion control algorithm. Two things, straight-up art and multiple
congestion control, I think this is really vague. For the straight-up art, I
think i'm having a discussion with Dirk on what they'll do about it. I don't
think this is conflicting right now but you should add CCW to the review

Erik: Yeah, I absolutely can. Sure, can say everything relate in the work done
in CC and Spring WG. But the important part of this sentence this relationship
does not prevent publishing.

Zahed: Yeah, that's fine. If they don't change the straight-up art and the
multiple congestion control, I do see that is conflicting with my view. I told
them to say this is just an example, and not say this is straight-up art.
Hopefully they will listen, I don't know if it's too late for them to do
anything about it.

Erik: Uh no, I think included some comments and nits, and they published a
revised version so they're not beyond making changes or least they weren't for
my small comments. I will CCWG to the list. Do we have a revised conflict as a
state?

Liz: No, we don't have for conflict reviews but we can just keep this in
evaluation until it's ready to go and the discuss has cleared.

Roman: Hold on, I want to talk to about process efficiency. Is all we need is
CCWG added to the ballot and we're good to go? Is there any other changes to
do, if not, can you just change it in real time now and not bring this back?

Erik: That's what I doing. Updated.

Roman: So if you clear then we don't need to bring it back

Zahed: Let me find out and clear this up.

Roman: I'm going to be honest with you, the reason i'm primarily asking because
I just went through this with the next conflict review. There's this vibe that
we need to include every kind of working group and I don't have the result of
this is going ahead anyway, do we in fact need to list every possible working
here and do we block on that? Is my philosophical kind of question.

Erik: Zahed, if you click on it, you should see there's a dash 01.  I've change
it to say work done in CC and SPRING WGs.

Zahed: Changed my ballot to no object with a comment.

Liz: So I see green here which means this has now been approved. This is ready
to go as is, you don't need to make any other changes?

Zahed: I'll have the discussion with Dirk if there's any changes.

Liz: Ok great, so this is approved and we'll send the no problem message to the
RFC Editor.

  o conflict-review-irtf-t2trg-iot-edge-02
    IETF conflict review for draft-irtf-t2trg-iot-edge
      draft-irtf-t2trg-iot-edge-10
      IoT Edge Challenges and Functions (IRTF: Informational)
    Token: Roman Danyliw

Liz: We don't have any active discusses. If there's no objection then is is
approved.

Roman: I added a bunch of working groups in real time, I updated the ballot
last call.

Eric: Thank you for adding IOT ops, I appreciate it.

Liz: Ok, so this is approved and we'll send the standard no problem message to
the RFC editor with the note that's currently in the tracker.

3.4.2 Returning items

  NONE

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

  o vCon (vcon)

Liz: We do have a block, do we need to discuss it now?

Murray: No, thank you for the reviews. I will take all the comments back to the
proponents and hack this together before we move it to the next step.

Lliz: Ok so we'll just wait for instructions from you Murray.

4.1.2 Proposed for approval

  o Key Transparency (keytrans)

Liz: No blocking comments, so if there's no objections now then this working
group can be created.

Roman: So Paul since you abstained do you want to say something in real time?

Paul: Sure. The reason I abstained is that I find two things really hard to
match here. One is that, the system that they want to add for the transparency
of end user and identity. That it should be more automatic and invisible to the
user but on the other hand, all the messages in the system could go throug the
service provider. Let's say you're using WhatApp or Signal, you go through the
provider and unless you somehow verify with another client that you somehow not
being the man in the middle then putting your own personal group in the middle
then this doesn't actually work. This does sort of work if you use third party
that is independent of the service provider and you're just adding trusted
parties but still not guarantee that you're having key transparency. I was on
the fence for a long time, and did a bunch of talking with Eckert yesterday. I
think there's some use for it, but the core goal it's set out to do is actually
not achievable with the current requirements and the charter. Hence my
abstained, because I still see limited use not having a trusted third party in
the system that is hopefully independent enough to add some value.

Roman: Thanks Paul and thanks for the iterations with the community offline and
online. I'm still going to proceed primarily I think we have that consensus
from the community that they want to explore this. There's a lot of energy
around that. Administratively, if we're going to approve this, can we leave it
in the state it currently is? I have partial commitments from a chairing team,
but I need to button all that up before we do official announcements. I don't
think we're going to end up with the full team that's currently in there right
now.

Liz: Sure thing, we can leave this where it is now and wait for further
instructions.

  o Structured Email (sml)

Liz: We do have a blocking comment, do we need to discuss it now?

Murray: Yes, that's very minor. I will make that slight change and let Eric
know and we can launch this.

Andrew: One observation which I decided not to write a full comment on. I
really hope someone is going to be looking at the security very closely because
the charter mentions it in one line but reading this, we're creating a working
group to create APIs to make more efficient stem.

Murray: I dont think you should be shy about making a comment like that. If I
can't work something like that in the charter. I'll make sure they're thinking
about this. While we have a captive audience here, does anyone have any
suggestions with whom we might coordinate alay this here?

Roman: Well to me MOD seems which is in he charter would be the biggest and
easiest thing I would point to. Not things you can put in the charter, but
obviously here and other places that email is highly centralized across a
limited provided providers.

Murray: Yeah ok, that's satisfactory at all?

Andrew: I didn't quite know how to word that comment because I had no idea what
to suggest on it. That's how the document felt when I read it.

Murray: I'm inclined given the handover that's coming to find someway to find
something to say something a little more explicit in the charter. I don't want
to do something handshakey. I rather have it written somewhere for someone who
inherits this, i'll noodle on that. Thanks for the suggestion.

Andrew: Ping me if you want to run anything pass me, etc.

Murray: Please feel free. To answer the secretariat's question, i'll loop back
with Eric and get this cleared up and we can launch this by the time I do that,
i'll also have Andrew's thing dealt with.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

  NONE

4.2.2 Proposed for approval

  NONE

5. IAB news we can use

Roman: We have a couple of things in flight, just a heads up. I'm going to try
to do a better job at continuing to send forth those technical talks. I think
the satelite tech talk was well received. I'm impressed with the talks that the
IAB is doing, all of them would be of interest to the IESG so i'm going to be
sending them in advance of that. The IAB is working on a technical plenary of
data privacy rights and that coordination is still on flight. Under discussion
is minting a new "Admin Support Work for IETF and WC3 Coordination" this is a
kin to the admin support groups we already have to IEEE, for example. To do
that for WC3, and that's under discussion.

Eric: What is meant by administrative group? Is a person?

Roman: No I had to look it up, and the secretariat can correct me here. The
administrative group is akin to the thing that we have for IEEE and others,
where it gets a marker in the Datatracker. There's probably a mailing list and
it speaks to the counter party.

Mirja: This is the tone we split up our technical programs. We also have other
groups that were called programs in other times but it's more to help us with
our charters which includes liaison management.

Roman: Mirja, Andrew, is there a follow-up action on the client side scanning
with the IESG statement?

Cindy: It's listed as a management item for today.

Roman: The other thing the IAB is noodling over, is the response to the US
National Standards Strategy which just got published, and whether to respond to
that.

Mirja: Back to the coordinator group effort, this started because I was at WC3
a couple weeks ago and I figured out that there's much more overlap and we
should probably do some coordination or the liaison managers should sit
together and figure out if we should do more frequent coordination. We want to
create this group and give them a home in the Datatracker so they can meet once
every IETF cycle online. Create a mailing list and have the right people
involved. The point Lars raised yesterday in the IAB, was that this means
additional loads for some ADs especially the ones in SEC and ART probably
because there's the most overlap with WC3. So before approving this group, we
want to run it by the IESG. I am in touch with Martin Thompson who is our
liaison with WC3 to get better idea what the items are, so you can provide us
feedback. This is coming in the next days.

Mirja: And maybe I can one more small thing, I sent an email about this
yesterday. The people SVTA reached out to us because they have a meeting just a
few days earlier in Prague and asked if we want to have a joint leadership
meeting to figure out any overlap. I'm trying to set this up for Saturday and
meet for maybe an hour. Please indicate to me if you would like to join that
meeting, and if you have any time constraints.

Eric: And just for information during the regular MOPS working group meeting,
we typically get a couple of SVTA representatives and Glenn Deen, is both SVTA
and IETF also explains what SVTA is doing. We already get some loose
connections and getting a more close connection is even better. Thanks Mirja.

Mirja: I think from their side they might have the attention to establish
something more formal. From our side, if there's already collaboration, the
right people do the right thing then I don't think we need more formality.
However, this is something we discuss with them at the meeting. At this point,
I just see this as a one term time opportunity.

Eric: It's more social than doing something seriously.

Mirja: We already have a handful of people joining for this meeting which
probably good enough but it would be nice if some people show up so please
consider.

6. Management issues

6.1 Designated Experts for the "Privacy Pass Parameters" registry (Paul Wouters)

Paul: If I understand things correctly, there two documents in the Privacy Pass
universe. One is further ahead than the other one, but one that is trailing is
the one that is creating the registry. I think there's some confusion, IANA
tried to contact the experts and realized that those experts haven't been
requested yet. I'm sure if I can do a management item for the Privacy Pass that
are coming or doing them proactively for the document that's isn't far ahead
but there will be a privacy pass group where there will a registry. I've gor
these three people there who are willing to be designated experts. Can this be
created or do I have to wait for document to proceed?

Liz: Sabrina, is on the call hopefully, this is a question that Sabrina can
help us answer.

Sabrina: What we were asking to unofficially ask them to review it and once the
document has been approved and we can assign the experts then we can officially
add them there. Just right now to unofficially ask them to review the document.

Paul: Ok so that would mean that deciding would get postponed until the other
document gets further in the publication queue.

Sabrina: Yeah, we wouldn't be able to add them to the registry until it gets
created. If you want to go ahead and approve it today and it's ok with everyone
then we can definitely add it once the document is approved. We just got be
able to add the names to registry until it's up.

Paul: Well yeah, I think we'll wait until it's approved just so we don't have
any special process in place. If it's good for you, if you can contact these
people for any outstanding questions you have on the document then we'll deal
with the designated experts once the document is approved.

Sabrina: Ok well do.

Liz: Ok, we can bring this back once the document is ready for approval.

6.3 Subdomain for IETF Store (Greg Wood)

Paul: This might be a silly question, but the store is going to make money and
the money is going where?

Greg: This store is aiming to recover cost and small additional margin above
cost, but it's mostly about recovering cost so the money would go to the IETF
LLC and endowment. This isn't an issue we have yet.

Mirja: Have you consider any other words than store? Because store seems super
general to me, giftstore seems slightly better.

Greg: Yeah, we considered some others one but this is seems the most
straightforward and understandable, and what is generally used for sites where
you purchase physical goods.

Mirja: The only concern I have is we are not selling any other physical goods.
It feels like rather gadgets and gifts is where you would sell your actual
products. It's not a strong concern.

Lars: Store is pretty common, and if you don't like store please make a better
suggestion because otherwise it's unfair to Greg.

Mirja: Yeah, that's what I asked if you considered other terms and what were
the other terms.

John: maybe shop or something like that, but I don't really don't care.

Roman: I think it's a great idea to have a store for brand awareness.

Liz: Ok, I don't think I hear any other objections or suggestions.

Lars: Store it is. I also like to minute the domain that Robert picked for the
dmarc, that started with the underscore. Given it started with a underscore, I
don't think it conflicts with any names that we'll use for anything. I would
minute that we approved that as well.

Eric: Is it forwardingalgorithm? But there is no underscore before. It's enough
to look at the SMPT header, right?

Lars: No, this is a new thing.

Erics: This is not the one that broke the email to Gmail? I just put it in the
Slack.

Lars: That must be it then.

Liz: Does this something that needs to be officially approved>

Lars: Any  domain, the IESG needs to be formally approve.

Cindy: Ietf.org is not a domain though, I don't think.

Lars: It's being used as part of the dmarc rewriting. Robert isn't online, it
was either in email or Slack, but I can't find it now.

John: I just pasted it, September 26. IESG channel.

Lars: It is forwardingalgorithms, there isn't an underscore.

Eric: It's an email address, not really a domain name. But we approve it
anyways.

Lars: I think that's fine, let's approved that as well.

Liz: The IESG approved using forwardingalgorthims@ietf.org for tools team use.

6.4 [IANA #1281697] renewing early allocations for
draft-ietf-sidrops-aspa-profile (IANA)

Liz: Warren is the AD for this and he's not on the call. Does anyone happen to
know anything about this or this document? Do we need to bring this back the
next telechat when Warren is here or do we want to approve it?

Eric: It looks like it going to last call so it's making some progress.

Lars: I would in that case we approve it.

John: I don't know this particular document but aspa in general is moving
forward so I would say approve.

Liz: Ok, we'll officially note that we approved this and get the note to IANA.

6.5 IETF GitHub organizations for non-WGs (Secretariat)

Cindy: I have sent email about this earlier this week and a number of you have
replied. It looks like a pretty clear consensus not to do this. I just want to
put this on the agenda so we can minute that decision in case this comes up
again.

Eric: I guess we all approve to disapprove.

Lars: Only IETF things get IETF blessings.

6.6 IAB Statement on Encryption and Client-Side Scanning (Lars Eggert)

Andrew: This document makes me a little nervous, not because I disagree.

Lars: This is something IAB has worked on this for awhile, and Paul who is
the person from the IESG who was involved in this as well. The main idea that
Mallory as the main driver here is to make this a joint IESG and IAB statement
and I suggested to her if she wants the IESG to co-sign then she should have
the IESG involved in this as early as possible but that didn't quite happen. I
think Mallory assumed that Paul would channel every and all feedback of the
IESG which is little bit of an unreasonable expectation. Basically, we got a
copy of this awhile ago and some of you have concerns and weren't willing to
sign it in the form it was in and sent a bunch of comments. There was a
discussion on the IAB call yesterday and because the IAB wants to finalize
this, this is now just an IAB statement. The reason this is here, is in case
individual area directors wanted to co-sign this, you could individually. You
could just send Mallory individually comments, but she seems to be a bit
hesitant on applying things because she thinks she's done. If you want to
individually co-sign this, contact the IAB. Base on what I heard on email, I
don't think it's possible for the entire IESG to sign this thing in it's
current form.

Eric: And especially since all my comments are closed without further comments.

Paul: I'm also not sure if individually signing actually makes sense. It feels
like we're publicly sharing that the ISB (IESG/IAB) is divided on this and i'm
not sure if that's helpful to the document at all.

Mirja: I think why proposed that is mainly because this is a IAB statement so
there's IAB consensus but Paul, you also helped a lot with that and you have an
opinion, so you actually want express that I think it makes sense.

Andrew: In it's current form, I couldn't co-sign this. I certainly agree on the
sentiment behind the document, I kind of think the document says there's no
technical way to do this and doesn't elaborate of that at all. Further takes,
what I would consider an adversarial position where the document reads like the
IETF is going keep using standards to encrypt stuff and i'm not convinced
taking an adversarial positon like that is necessary politically conducive to
actually get change because it came across to me a adversarial take on things.

Zahed: Just to understand what we're discussing right now, I think the decision
was in the informal was we're not signing as IESG and I think Lars asked if
some the ADs would personally like to sign it then go ahead. I think we're not
revisiting those kind of things. I agree with Paul here, signing it personally.
I don't know what that means, so if it's an IAB statement then let's put it in
the IAB name.

Lars: It's just a heads up for you guys to see if you want to individually
co-sign it, and if nobody then that will be fine as well.

Mirja: No, we'll need to know who is interested in co-signing so we can work
with that set of people so we can we get the statement out. If you are
considering co-signing, please let us know now.

Roman: I provided very detailed feedback that I don't think even adjudicated.
The one thing I would caution the IAB on is I think the reference to that US
law, the way that sentence is written like i've said before is not entirely
accurate. There's a lot of extrapolation that's happening and the implications
of that proposed language versus what is actually in the language.

Mirja: You mean sentence in this sub-paragraph here "this statement is a
reaction to the policy proposals"?

Roman: There's a wide net being cast about picking up laws relative to
encryption to client-side scanning. I would urge the IAB to really read the
text of the bill and cross walk that how it's going to be bind and
philosophical positon relative to is it actually saying client-side scanning.

Mirja: I understand your point, but in the end in the end this is not a
reaction to specific proposal, it's a reaction to the whole discussion. A lot
of these proposals are at a state where they are abstract and the details are
not decided yet. That's a level we cannot discuss. And a reaction to your
comments, I just want to make people aware that it's not about client-side
scanning in general, we should revise the title of the statement. It's about
the fact the government or third party is required to have accessory to private
data and required in a way you do not have control of that access - thats the
important part. It's not about having parental control installed in your kid's
devices which is also about client-side scanning. It's really about giving
access in an uncontrolled way required by government.

Roman: I completely agree which is why, I don't think bad things about
client-side scanning but the narrative text to me doesn't kind support that
because slight of hand talking about QUIC, TLS and the rest of them because it
has nothing to do with this mandatory kind of thing. It's a nonsecular from as
far as I can tell.

Mirja: Ok, that paragraph is to mainly show that background in the IETF about
the importance encryption and privacy so that's just to give context. The IAB
needs to give a little more work into that. We put a lot of work, but I feel
like we're still not there given the comments from the IESG.

Zahed: I think you're right on that one. I felt that I didn't really understand
the motivation is educational or it's on the line where we have the technology
but you will not be able to do it anyway. That's a different kind of tone than
educational. I think that tone, i'm not sure. Like Lars said, we were not
involved, and I was not sure what the intention is educational or a statement
so it's a bit tough for me to say anything.

Lars: So basically Mirja asked if anyone is interested in co-signing then let
IAB know now.

Andrew: I understand this is an IAB statement, but I would miss not stating my
concerns that.

Lars: Andrew you need to take the pen to the IAB.

Andrew: Yes, but it is the IAB taking the position about the IETF.

Lars: And they can do that, right. They are the architect of the Internet is
task with, and you could argue that this is part of that. I would urge you to
send feedback to the IAB, and cc the IESG if you would like so we can see but
it's really IAB that needs to hear it.

Mirja: Ok, so it sounds like nobody from the IESG is intersted in co-signing.
Paul, you also think you shouldn't co-sign  as a single AD?

Paul: Yeah, that's right.  Personally, I would like to sign it, but I don't
think a single IESG member should sign it.

Mirja: Ok, I think this is perfectly fine as an IAB statement only. No problem
about this, I just want to confirm. Thank you.

6.2 IETF 118 Agenda Conflict Resolution (Secretariat)

The agenda conflict resolution was discussed.

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

Eric: You approved a couple of weeks all the ADD drafts, they are now in AUTH
48. I put one on hold because two implications when reading one sentence
differently. They were sending DNS information in either a compressed file or a
wide file. This is usually not good to have a document that is unclear and
ambiguous if you have two readings of one sentence. IPSECME and Paul because
they are using the same kind of thing there, transferring the same kind of
information in both cases IPSECME and my case is over HTTP4 and IPV6. There are
a couple of arguments in favor of one over the other. I was hoping to solve the
issue and get one way tonight European time, but I think I need to read a
little bit more. This is show that it's too not late to change a document even
after multiple reviews if there are ambiguities.

Roman: I think the document is mine because it's in IPSECME. I need to send a
note just to halt it. I see a lot of healthy discussions, I haven't been able
to catch up just to make sure the right things are happening across document
because that's obviously what we want.

Paul: I do think the consensus has been reached and that i'm in the rough.
Please do carefully look over all the feedback.

Lars: We should start planning the IESG and IAB agendas for Prague. There is
the WIKI page that everyone always forgets about which is the upcoming meeting
WIKI. Add topics on top and if you have any indications if this is for the IESG
only or the joint session with the IAB, indicate. At some point, Mirja and I
will do triage and bucket the things. I have one request from Elliot Lear who
wants to explain to us what the ISE is about and I said i'll put it on there as
tentative.

Lars: We also have an ART person that accepted the nominations, now we just
need another one.

Rob: On the topic on what the ISE does, I think it makes more sense to do when
the IESG is seated. Do we want to discuss the 6MAN document regarding zoning IP
adress. Do we want to discuss that document now or not?

Erik: Which document was that, Rob?

Rob: The one that Murray and I are holding discusses for which I will be moving
to abstained.

Murray: I said on the mailing list what my concerns is, the background here is
the 6MAN people want to do something the browser people feel like it's
wondering in their space. People from WC3 object, the authors are persisting
saying we have consensus to do this. Neither side are offering solutions that
the other side is consider workable. They have both threaten to appeal. I'm
holding a discuss on behalf of the WC3 people and is supported by a couple of
people. I move to abstained, it wouldn't actually stop this there would still
be appeals. The mess doesn't go away. The two people who are supporting my
abstained, who are Francesca and Andrew, you have to decide to you also move to
abstained or do you pick up the discuss or do you move to no objections. The
document still needs at least one ballot before it can be approved anyways. I
think there are 3-4 people who have not balloted yet, so two of us move out of
the way and there are no objections then it's off to the races. On the other
hand, if enough people move to abstained then it's dead.

Andrew: I would almost certainly swing mine to abstained.

Erik: From the author's perspective, they felt like they responded to all the
feedback that were technical feedback that they could respond to. From his
perspective, he feels like they're just throwing objections because they don't
want to do this and they don't want to do this ever. We do have people who do
want to do this, there is one toy implementation and one manufactor who wants
support for this.

Eric: It's not only about browser using this, right?

Erik: There are command utilities that would be fixed. In discussion with the
6MAN chairs and with Eric last Friday, we agreed to update the shepherd
write-up to get all the documents in a row for someone who is doing a peer
review could have a clear view of everything and capture all the state and to
bring it to a telechat.

John: Doesn't Warren have some unrelated discuss on it also?

Rob: It's me, my discuss is mainly about I don't like the fact that it changes
the effectively IP address from an integer to a string. It changes the link
local to device local scope and string identifier to add it on to differentiate
it. I think that's a bad thing to do and that's leeched down into the YANG
model.

Rob: That was done a long time ago, and they tried bringing URLs and do rework
and now they're trying to update it. For me, the better thing to do is kill IDs
and keep local addresses and find a different local addresses.

Erik: Local addresses are inherently scoped to an interface.

Rob: Yes.

(crosstalk)

Rob: Once you start referencing outside of that interface, outside of that
scope and you want to explicitly have a way to identify them outside of scope
userface. That's where the scope changes. This isn't a device scope address.

Erik: Because the interface is scoped to the device.

Rob: Yes.

Erik: There's nothing wrong with that. I don't think.

Rob: The thing I think is wrong keeps changing, the IP address being the
numerical identifier to a string. If you look at the YANG model at IETF, the IP
address, it doesn't take a numerical identifier. Sometimes it's right, and
sometimes is wrong. 90% of it in the IETF is wrong. They just add a load of
complexity that doesn't really help.

Erik: No, it doesn't add the complexity. The complexity is already there, it's
a subtle but important distinction.

Rob: I know, I have no issues with link address. I think the it's better to
have a allocated device to local addresses than numerical. That solves the
problem, you don't have to have any other issues because it just looks like
another local IP address rather than link local.

Erik: What is device local address?

Rob: Device local address is where after you do your ND exchange between your
peer, and you both agree how much unique on both devices and allocate an IP
address base on that. Local to each device and local to that and you can use
the local identifier.

Erik: What procotol for this IP adresses configuration mechanism?

Rob: I would suggest ND but i'm not an expert.

Erik: What you're talking about inventing something new from old cloth that
dosen't exist today.

Rob: Yes. Correct

Erik: Yeah, that doesn't seem like a workable suggestion to me.

Eric: What happens if you get a separation? Partion of the link, where you have
only one way link. So you can distinguish it because there's only one way.

Erik: You're adding a new category of addresses as well.

Rob: You sort of got that category of effectively with the identifier.

Erik: They exist today.

Eric: Even in IPV4 as well, but they exist.

Erik: Because Stewart Cheshire work them.

Rob: They exist today, but the way they've been referenced is a mistake. I have
no issues with like a YANG model underneath the interface with the local
address because the scoping information is carried elsewhere. The bit where I
think is wrong, is where you create a new identifier and bind those two things
together because it's not a numerical identifier. It's not like an IP address
anymore, it's something different. Then they stopped turning up in models, they
turn up elsewhere. They're used in a really small subset of cases.

Eric: They ask here for representation, we don't have addresses it says.

(crosstalk)

Erik: There's another problem where as well, it's the scope name syntax that
was created a long time and used in a lot of tools. There was never any ABNF
for interface names nor can there be.

Rob: And you can't up that in the URI

Erik: You can put that in the URI actually.

Rob: I thought what they're proposing here is does not allow percent scoping.
They're plan to restrict the set of identifiers we can use to interface names
They're purposing you can't use this on any large network devices.

Lars: Can I suggest that we take some time on an informal and get the authors
and the objectioners on call as well and see if we can make some progress on
this. It looks like there's appeals on both sides. The authors can rightly
appeal that the IESG isn't taking it forwarded and same happens if we take it
forwarded and get the appeal from the people that don't like it.

Murray: Is there such thing as abstained busting? If 6 of us decide we're not
going to support this but we're not going object to it either, but we're not
going to make the count. What's the appeal?

Lars: The IESG has to make the decision to not progress the document.

Erik: I don't about next week, it might be a bit early. Maybe the 26th, I could
try to start coordinating emails.

Murray: It's Mark and Martin on the WC3 side. I can see if they're available on
the 26th.

Erik: And Roy.

Murray: I actually haven't talked to Roy about this, it's mostly the two guys
i'm more familiar with.

Erik: It's Roy that Brian has been dealing with.

Cindy: The 26th is a formal telechat, you have two back-to-back since we get
into the meeting.

Murray: The 12th is our best option. We can also deal with this in Prague, if
they're ok waiting for another month.

Erik: We can put that in email. You can say the 12th or Prague.

Lars: We can also take an half hour at a formal. It's not something we can't
do, it's just we usually don't.

Murray: We can also just make a meeting just for that.

Lars: Why don't someone take an action item to get ahold of the individuals
involved to see what they prefer if Prague is preferred or do an interim call.

Erik: I can start emails and gather Doodle poll information. In progress.