[{"author": "Carsten Bormann", "text": "

At least the audio from the chairs' mic is fine!

", "time": "2024-07-22T16:30:48Z"}, {"author": "Lorenzo Miniero", "text": "

Yep fixing the videos now

", "time": "2024-07-22T16:31:02Z"}, {"author": "Chris Lemmons", "text": "

I just assumed that everybody was hiding under their chairs. :)

", "time": "2024-07-22T16:31:17Z"}, {"author": "Ted Hardie", "text": "

Still wrong video of the room.

", "time": "2024-07-22T16:31:36Z"}, {"author": "Watson Ladd", "text": "

more people

", "time": "2024-07-22T16:33:39Z"}, {"author": "Mallory Knodel", "text": "

Mic1 camera is correct

", "time": "2024-07-22T16:33:44Z"}, {"author": "Chris Lemmons", "text": "

It's people!

", "time": "2024-07-22T16:33:46Z"}, {"author": "Watson Ladd", "text": "

well, it's at least a room of people :P

", "time": "2024-07-22T16:33:55Z"}, {"author": "Tommy Jensen", "text": "
\n

I just assumed that everybody was hiding under their chairs. :)

\n
\n

From alldispatch? Not a chance :D

", "time": "2024-07-22T16:33:59Z"}, {"author": "Murray Kucherawy", "text": "

Away we go!

", "time": "2024-07-22T16:37:10Z"}, {"author": "Daniel Smullen", "text": "

Could I kindly ask that someone provide the URL for the non-lite version of this alldispatch group? The URL https://meetecho-or.ietf.org/lite/?group=alldispatch seems to still be borked...

", "time": "2024-07-22T16:37:18Z"}, {"author": "Watson Ladd", "text": "

https://meetecho-or.ietf.org/client/?session=33220

", "time": "2024-07-22T16:37:57Z"}, {"author": "Daniel Smullen", "text": "

Thank you.

", "time": "2024-07-22T16:38:09Z"}, {"author": "A.J. Stein", "text": "

As an aside from alldispatch meta conversation itself, I would love a slide with light Python-ish pseudocode that really summarize a procedural change for IETF process and policy for all such presentations, but that is probably a niche view. I will start doing that where it counts for my own slides.

", "time": "2024-07-22T16:41:12Z"}, {"author": "Watson Ladd", "text": "

in DKG voice we're here for dispatch

", "time": "2024-07-22T16:42:57Z"}, {"author": "Jari Arkko", "text": "

FWIW, I agree with Lars

", "time": "2024-07-22T16:44:20Z"}, {"author": "Mike Bishop", "text": "

Does the expert have veto? Is the expert's input presented to the approving body?

", "time": "2024-07-22T16:44:28Z"}, {"author": "Martin Vigoureux", "text": "

we can assume that the expert is de facto included when going through the different policies which include ietf review

", "time": "2024-07-22T16:44:56Z"}, {"author": "Carsten Bormann", "text": "

Yes; I would hope so

", "time": "2024-07-22T16:44:57Z"}, {"author": "Carsten Bormann", "text": "

Martin: We can't.

", "time": "2024-07-22T16:45:12Z"}, {"author": "Arnaud Taddei", "text": "

+1 with Lars

", "time": "2024-07-22T16:45:17Z"}, {"author": "Martin Vigoureux", "text": "

why can't we Carsten?

", "time": "2024-07-22T16:45:33Z"}, {"author": "Watson Ladd", "text": "

but that's a discussion for wherever we dispatch this to!

", "time": "2024-07-22T16:45:34Z"}, {"author": "Carsten Bormann", "text": "

Experience shows that the review bodies don't do this

", "time": "2024-07-22T16:45:48Z"}, {"author": "Jonathan Lennox", "text": "

Perhaps there needs to be some process to flag the expert explicitly for the ietf review process, in case they're not paying attention?

", "time": "2024-07-22T16:45:50Z"}, {"author": "Arnaud Taddei", "text": "

+1 to Mike Bishop

", "time": "2024-07-22T16:45:50Z"}, {"author": "Carsten Bormann", "text": "

Jonathan: Yes! That's what this doc does.

", "time": "2024-07-22T16:46:09Z"}, {"author": "Jonathan Lennox", "text": "

Watson: there needs to be some discussion of the substance in order to decide whether the dispatch resolution should be \"nowhere\".

", "time": "2024-07-22T16:46:37Z"}, {"author": "Yoav Nir", "text": "

For most of the cases I know about, the \"expert review\" is a way of saying \"don't bother the WG with this stream of registrations\". I don't see the benefit of expert + committee. Presumably, the expert would be part of the committee

", "time": "2024-07-22T16:46:44Z"}, {"author": "Martin Vigoureux", "text": "

I mean that if the draft goes through ietf LC / iesg telechat, we should assume that it has gone through the correct set of eyes, otherwise we are assuming these step don't fulfill there role, aren't we?

", "time": "2024-07-22T16:47:18Z"}, {"author": "Carsten Bormann", "text": "

\"I don't have this problem\" is not a relevant answer; we do.

", "time": "2024-07-22T16:47:22Z"}, {"author": "Watson Ladd", "text": "

Yoav: i think the issue is registries with complex rules for being well fromed

", "time": "2024-07-22T16:47:22Z"}, {"author": "Carsten Bormann", "text": "

+1 Watson

", "time": "2024-07-22T16:47:31Z"}, {"author": "Pete Resnick", "text": "

This sounds to me like it's more complicated and has more implications than just a short little document will address. Make it part of a fuller 8126bis review and put that in a WG.

", "time": "2024-07-22T16:47:35Z"}, {"author": "Cullen Jennings", "text": "

Given the track record of slow responses from many experts, I think this takes us the wrong direction. I would rather see us moving toward better model so I am not seeing the need for this work

", "time": "2024-07-22T16:47:35Z"}, {"author": "Jonathan Hoyland", "text": "

What about an (informational) BCP that says \"in some cases it's a good idea to have both\"?

", "time": "2024-07-22T16:47:38Z"}, {"author": "Carsten Bormann", "text": "

Yes, but wwhat does that mean? (Please check the draft.)

", "time": "2024-07-22T16:48:20Z"}, {"author": "Yoav Nir", "text": "

It has to be a WG because we don't agree whether it's a good idea or not. That does not say \"AD sponsored\" to me

", "time": "2024-07-22T16:48:28Z"}, {"author": "Murray Kucherawy", "text": "

I'll volunteer to drive chartering.

", "time": "2024-07-22T16:48:34Z"}, {"author": "Carsten Bormann", "text": "

Def not AD sponsored

", "time": "2024-07-22T16:48:39Z"}, {"author": "Murray Kucherawy", "text": "

Yeah, I'm not sponsoring this. :)

", "time": "2024-07-22T16:48:51Z"}, {"author": "Martin Duke", "text": "

If an RFC is published with no expert review, that process is broken

", "time": "2024-07-22T16:48:56Z"}, {"author": "Carsten Bormann", "text": "

Martin: Enterprise numbers

", "time": "2024-07-22T16:49:14Z"}, {"author": "Murray Kucherawy", "text": "

Martin: An RFC?

", "time": "2024-07-22T16:49:18Z"}, {"author": "Martin Duke", "text": "

Murray: if it's rfc required I think that implies expert review

", "time": "2024-07-22T16:49:47Z"}, {"author": "Martin Thomson", "text": "

I think that Martin's point is that \"RFC Required with Expert Review\" is redundant.

", "time": "2024-07-22T16:49:55Z"}, {"author": "Murray Kucherawy", "text": "

Oh you mean an IANA action within an RFC Required document.

", "time": "2024-07-22T16:50:04Z"}, {"author": "Martin Thomson", "text": "

Something I agree with

", "time": "2024-07-22T16:50:06Z"}, {"author": "Murray Kucherawy", "text": "

Me too.

", "time": "2024-07-22T16:50:16Z"}, {"author": "Watson Ladd", "text": "

Is there a stage where IANA would contact experts for RFC required? no guarrentee they saw it

", "time": "2024-07-22T16:50:25Z"}, {"author": "Watson Ladd", "text": "

any WG could register in any RFC required registry and inboxes are messy

", "time": "2024-07-22T16:50:40Z"}, {"author": "Eliot Lear", "text": "

But \"RFC Required with Expert Review\" is not redundant because different streams may not be expert on the code point being allocated (says the ISE).

", "time": "2024-07-22T16:50:52Z"}, {"author": "Murray Kucherawy", "text": "

Watson: IANA will do whatever the registry policy says they have to do.

", "time": "2024-07-22T16:51:02Z"}, {"author": "Harald Alvestrand", "text": "

Unfortunately we have \"RFC required\" where all the steps in the RFC process are oblivious to the possible issues with the registration.

", "time": "2024-07-22T16:51:17Z"}, {"author": "Eliot Lear", "text": "

On the other hand, \"Expert Review\" is sufficient

", "time": "2024-07-22T16:51:17Z"}, {"author": "Mike Bishop", "text": "

I can see a place for \"This person must review during IETF LC.\"

", "time": "2024-07-22T16:51:20Z"}, {"author": "Martin Thomson", "text": "

My understanding is that the ISE tries very hard to obtain expert review of documents. They might not be required to do that, but then that is perhaps a reason that RFC Required is a bad policy to set.

", "time": "2024-07-22T16:51:58Z"}, {"author": "Cullen Jennings", "text": "

Chairs, it seems to me hearing from a few people and mic when the mic line was cut hardly seems like a measurement of what the room full of people think - I would have gone to the mic had I known there was not going to be any question to the room.

", "time": "2024-07-22T16:52:05Z"}, {"author": "Jonathan Lennox", "text": "

This (Klensin's proposal) sounds kind of like a generalization of the TLS registries' recommended Y/N/D?

", "time": "2024-07-22T16:52:06Z"}, {"author": "Carsten Bormann", "text": "

I don't want to task an expert with enforcing a \"RFC required\" instruction.

", "time": "2024-07-22T16:52:08Z"}, {"author": "Martin Duke", "text": "

For iesg review, ADs can find a relevant expert ad hoc, and that is probably less work than maintaining an expert slot just in case

", "time": "2024-07-22T16:52:11Z"}, {"author": "Harald Alvestrand", "text": "

the illusion that (not designated) experts will notice a Last Call is just that - an illusion.

", "time": "2024-07-22T16:52:19Z"}, {"author": "Peter Koch", "text": "

RFC required does not imply expert review. We should consider the requirements of \u201eresource stewardship\u201c rather than in deriving those from the available tools for solutions

", "time": "2024-07-22T16:52:34Z"}, {"author": "Martin Thomson", "text": "

Mike Bishop: I do not want to create a process whereby a single person can block progress.

", "time": "2024-07-22T16:52:37Z"}, {"author": "Mike Bishop", "text": "

If the Designated Expert is unresponsive, they should be replaced anyway.

", "time": "2024-07-22T16:53:00Z"}, {"author": "Rich Salz", "text": "

The IESG can overrule/replace ddsignated experts

", "time": "2024-07-22T16:53:09Z"}, {"author": "Harald Alvestrand", "text": "

If a single person designated by a governing body blocks progress, then we know exactly how to deal with it.

", "time": "2024-07-22T16:53:14Z"}, {"author": "Jim Fenton", "text": "

@Cullen what do you suggest, a hum/poll?

", "time": "2024-07-22T16:53:17Z"}, {"author": "Carsten Bormann", "text": "

The small could do the patches first and then the big BCP26bis

", "time": "2024-07-22T16:53:27Z"}, {"author": "Erik Nygren", "text": "

We went through a bunch of this for defining the SVCB ServiceParam registry as well. Agreed that a WG to revisit BCP26 would be worthwhile.

", "time": "2024-07-22T16:53:37Z"}, {"author": "Martin Thomson", "text": "

It's not about being unresponsive, but about checks and balances, as per Harald.

", "time": "2024-07-22T16:53:38Z"}, {"author": "Martin Duke", "text": "

If something is so intricate it can only be done by an expert, than either do DE or require a standard

", "time": "2024-07-22T16:53:57Z"}, {"author": "Peter Koch", "text": "

And, heaven forbid, we might want to think about a review of the registration policies for the various registries - there are costs attached to maintaining them

", "time": "2024-07-22T16:54:17Z"}, {"author": "Carsten Bormann", "text": "

\"Experts\" can be teams

", "time": "2024-07-22T16:54:18Z"}, {"author": "Mike Bishop", "text": "

I think \"must provide feedback\" is a different tier from \"veto power.\" And that's what a WG would hash out.

", "time": "2024-07-22T16:54:22Z"}, {"author": "Carsten Bormann", "text": "

I want an expert to be able to say \"this is broken, it shall not pass\".

", "time": "2024-07-22T16:54:56Z"}, {"author": "Martin Duke", "text": "

\"must provide feedback\" is pocket veto power

", "time": "2024-07-22T16:55:09Z"}, {"author": "Martin Thomson", "text": "

Any system that has a singular expert (or a very small set of experts) without the necessary documentation that might allow others to make a similarly-good determination is really broken.

", "time": "2024-07-22T16:55:11Z"}, {"author": "Michael Richardson", "text": "

Hi. I like what Barry suggested.

", "time": "2024-07-22T16:55:19Z"}, {"author": "Carsten Bormann", "text": "

All procedures in 8126 can be built at any point.

", "time": "2024-07-22T16:55:45Z"}, {"author": "Carsten Bormann", "text": "

So why did we write 8126?

", "time": "2024-07-22T16:55:52Z"}, {"author": "Eliot Lear", "text": "

@Martin, yes, the ISE tries to get good review of all documents, but still adheres to IANA policies. Again, \"expert review\" in those cases is certainly sufficient.

", "time": "2024-07-22T16:56:17Z"}, {"author": "Michael Richardson", "text": "

Yoav Nir said:

\n
\n

It would be really sad is alldispatch was this empty.

\n
\n

We were waiting for ChatGPT to draw a room full of usual suspects.

", "time": "2024-07-22T16:56:17Z"}, {"author": "Jonathan Lennox", "text": "

Off-mic: I asked Harald if he's volunteering, and he very definitevely said \"no\"

", "time": "2024-07-22T16:57:16Z"}, {"author": "Jari Arkko", "text": "

In general the approach of spinning up a working group is good. But I'm not getting a very large 'urgency' or 'we have a big problem' feeling from the presented cases.

", "time": "2024-07-22T16:58:30Z"}, {"author": "Martin Duke", "text": "

If we wanna do these (I am not convinced we do) just do a GEN WG for 8126 issues

", "time": "2024-07-22T16:58:51Z"}, {"author": "Roman Danyliw", "text": "

I've heard that some elements of these need to happen \"fast\". What is the burning driver requiring quick resolution? \"How fast is fast\"?

", "time": "2024-07-22T16:59:03Z"}, {"author": "Carsten Bormann", "text": "

Roman: RFCs being published that have some variant of this.

", "time": "2024-07-22T16:59:26Z"}, {"author": "Pete Resnick", "text": "

Agree with @Jari Arkko. I think we're really going to end up tackling the whole 8126bis instead of doing these point solutions, but I have no objection to attempting the point solutions.

", "time": "2024-07-22T16:59:28Z"}, {"author": "Roman Danyliw", "text": "

@Carsten: right. we're already handling it ad hoc. What makes it a burning issue?

", "time": "2024-07-22T17:00:02Z"}, {"author": "Michael Richardson", "text": "

Mike Bishop said:

\n
\n

If the Designated Expert is unresponsive, they should be replaced anyway.

\n
\n

I think one of the bugs is that the IANA issue tracker for allocations is not visible to the experts, if it were, then I think we'd get better metrics about how responsive DE are.

", "time": "2024-07-22T17:00:17Z"}, {"author": "John Klensin", "text": "

Roman, Jari the only concern is that, as has been pointed out, these things are going to happen because there is not (and should not be) a requirement in 8126 to use its canned procedures. But having small variations on similar rules in many different specs is a source of confusion for all concerned, including WGs, reviewers, and, I imagine IESG and IANA

", "time": "2024-07-22T17:01:45Z"}, {"author": "Kathleen Moriarty", "text": "

Thank you, Mallory. Representing on matters and research demonstrates this time and again.

", "time": "2024-07-22T17:02:21Z"}, {"author": "Carsten Bormann", "text": "

Roman: We are handling it chaotically.

", "time": "2024-07-22T17:02:24Z"}, {"author": "Carsten Bormann", "text": "

This is a bit like saying \"we are handling notating IPv6 addresses\" before someone finally wrote up the rules.

", "time": "2024-07-22T17:03:19Z"}, {"author": "A.J. Stein", "text": "

So to understand the past and address the dispatch question, previous NomCom RFCs were maintained through the concluded iasa2 wg mostly, others?

", "time": "2024-07-22T17:04:34Z"}, {"author": "Rich Salz", "text": "

FOCUS ON THE DISPATCH QUESTIONS

", "time": "2024-07-22T17:07:05Z"}, {"author": "Nick Doty", "text": "

I don't think anything in the proposed draft changes the number or composition of volunteers, just how the committee is selected from the group of volunteers

", "time": "2024-07-22T17:07:11Z"}, {"author": "Jean Queralt", "text": "

Rich +1

", "time": "2024-07-22T17:07:22Z"}, {"author": "Daniel Smullen", "text": "

I applaud the effort here. Maybe the framing could be considered in an alterative way: the goal is not to impose a restriction on the participation pool, but rather an active effort to encourage those who do not identify as men. I believe that this framing problem requires a working group (but I'm a newbie, so take this with a grain of salt).

", "time": "2024-07-22T17:07:42Z"}, {"author": "Kyle Rose", "text": "

We shouldn't be discussing the merits of this in dispatch: we should just be figuring out where, if anywhere, to send it.

", "time": "2024-07-22T17:08:01Z"}, {"author": "Lixia Zhang", "text": "

Gender balance in nomcom: may be better addressed in earlier stages instead of member selection stage (given the member selection by random drawing). agree with the nomcom chair on working on participation.

", "time": "2024-07-22T17:08:01Z"}, {"author": "Joel Halpern", "text": "

I am a little concerned that the chair's phrasing assumes it should be dispatched. While I understand the concern, it is not at all clear to me this should be dispatched.

", "time": "2024-07-22T17:08:12Z"}, {"author": "A.J. Stein", "text": "

So re Rich's polite ALL CAPS suggestion: so is there another approach than \"let's establish iasa2.5?\"

", "time": "2024-07-22T17:08:18Z"}, {"author": "Kyle Rose", "text": "

This is time-limited, right?

\n

Right? ;-)

", "time": "2024-07-22T17:09:01Z"}, {"author": "Pete Resnick", "text": "

DISPATCH question please.

", "time": "2024-07-22T17:09:01Z"}, {"author": "Jim Fenton", "text": "

@joel sorry, didn't mean to imply that, will watch my wording

", "time": "2024-07-22T17:09:04Z"}, {"author": "Yoav Nir", "text": "

I don't see how we make this change without a working group.

", "time": "2024-07-22T17:09:07Z"}, {"author": "Rich Salz", "text": "

resurrect elegy and send it there.

", "time": "2024-07-22T17:09:30Z"}, {"author": "Kyle Rose", "text": "

I can very quickly see this going off the rails. Dispatch chairs: make a dispatch decision and nix discussions of the merits

", "time": "2024-07-22T17:09:37Z"}, {"author": "Pete Resnick", "text": "

We're not supposed to be discussing the topic, but how to dispatch it.

", "time": "2024-07-22T17:09:40Z"}, {"author": "Mallory Knodel", "text": "

Correction: My draft doesn't accuse the IETF of gender discrimination.

", "time": "2024-07-22T17:09:46Z"}, {"author": "Francesca Palombini", "text": "

@Joel: right, however \"don't do anything about it\" is also considered \"dispatched\". But good reminder.

", "time": "2024-07-22T17:09:57Z"}, {"author": "John Klensin", "text": "

The question is not only how many people would participate in a WG but whether such a WG and its participants would be reassembly representative of the views of the community.

", "time": "2024-07-22T17:10:17Z"}, {"author": "Kathleen Moriarty", "text": "

I disagree with Dan

", "time": "2024-07-22T17:10:34Z"}, {"author": "Jean Queralt", "text": "

I'd be concerned, in any circumstance, to establish (or start a path towards) quotas instead of actual merit and capacities.

", "time": "2024-07-22T17:10:34Z"}, {"author": "Tommy Jensen", "text": "

+1 Barry

", "time": "2024-07-22T17:10:59Z"}, {"author": "Mike Bishop", "text": "

Jean, NomCom is explicitly a random sampling of the community and not merit/capacities.

", "time": "2024-07-22T17:11:12Z"}, {"author": "Andrew Campling", "text": "

+1 to AD sponsorship (and to disagreeing with Dan\u2019s comments)

", "time": "2024-07-22T17:11:31Z"}, {"author": "Bryan Newbold", "text": "

+1 Barry, and thank you Mallory for bringing this work forward

", "time": "2024-07-22T17:11:33Z"}, {"author": "Jean Queralt", "text": "

@Mike: For now.

", "time": "2024-07-22T17:11:34Z"}, {"author": "Yoav Nir", "text": "

There's a general issue with poorly-attended working groups making policy for the entire IETF, but I don't see an alternative. We don't want to just give the IESG (or IETF chair) the authority to make these decisions by themselves.

", "time": "2024-07-22T17:12:13Z"}, {"author": "Kathleen Moriarty", "text": "

+1 to Ted, there are methods to consider that can be discussed in a short lived WG

", "time": "2024-07-22T17:12:24Z"}, {"author": "Watson Ladd", "text": "

NomCom is not random: serving on NomCom requires sponsorship from employeers that can be hard to get

", "time": "2024-07-22T17:12:55Z"}, {"author": "Kathleen Moriarty", "text": "

My comment is specific to the dispatch question

", "time": "2024-07-22T17:13:18Z"}, {"author": "Jari Arkko", "text": "

+1 to Ted. There are other axis of diversity. A WG would be useful here to think about this, along the question of how to solve the issue.

", "time": "2024-07-22T17:13:31Z"}, {"author": "Kyle Rose", "text": "

+1 to Rich

", "time": "2024-07-22T17:13:44Z"}, {"author": "John Klensin", "text": "

Voav, on disagreement there.

", "time": "2024-07-22T17:14:10Z"}, {"author": "Watson Ladd", "text": "

+1 to Rich

", "time": "2024-07-22T17:14:17Z"}, {"author": "Yoav Nir", "text": "

@Watson NomCom is not random, but it's randomly chosen from a pool of 200 people.

", "time": "2024-07-22T17:14:21Z"}, {"author": "John Klensin", "text": "

s/on/no/

", "time": "2024-07-22T17:14:33Z"}, {"author": "Roman Danyliw", "text": "

now closed Elegy WG = https://datatracker.ietf.org/wg/elegy/about/

", "time": "2024-07-22T17:14:37Z"}, {"author": "Ted Hardie", "text": "

Sorry, I was apparently unclear. I don't think this should be used for other types of diversity. I was pointing out that if we started down this path, there was a risk that people who want to argue for that would assume it was easy to just keep adding skip rules.

", "time": "2024-07-22T17:14:52Z"}, {"author": "Yoav Nir", "text": "

Having a working group does not excuse you from getting consensus on the wide IETF.

", "time": "2024-07-22T17:15:08Z"}, {"author": "Harald Alvestrand", "text": "

part of the theory behind nomcom is that the IETF is willing to live with any group selected from the volunteers.

", "time": "2024-07-22T17:15:13Z"}, {"author": "John Klensin", "text": "

@Yoav, in practice recently, that often does not work.

", "time": "2024-07-22T17:15:49Z"}, {"author": "Harald Alvestrand", "text": "

@yoav, in reality, for ~any subject sent to IETF Last Call, the majority of the IETF community will ignore it.

", "time": "2024-07-22T17:16:34Z"}, {"author": "Yoav Nir", "text": "

@John Klensin : \"Oh, we discussed it in the WG - y'all just rubber-stamp it\"

", "time": "2024-07-22T17:16:37Z"}, {"author": "Dan Harkins", "text": "

Agree with Christian

", "time": "2024-07-22T17:16:57Z"}, {"author": "Yoav Nir", "text": "

@Harald - that is true even if there wasn't a WG

", "time": "2024-07-22T17:17:05Z"}, {"author": "John Klensin", "text": "

Exactly

", "time": "2024-07-22T17:17:44Z"}, {"author": "Mallory Knodel", "text": "

At least there were 15 and not zero eligible volunteers. So the skip rule would have worked :)

", "time": "2024-07-22T17:18:00Z"}, {"author": "Alison Becker", "text": "

^ +1

", "time": "2024-07-22T17:18:14Z"}, {"author": "Harald Alvestrand", "text": "

@yoav that's my point. WGs and IETF Last Calls are both examples of processes that attempt to capture \"the sense of the community\", and both have failure modes where something that the IETF as a whole disagrees with can make it past the gates.

", "time": "2024-07-22T17:18:59Z"}, {"author": "Jean Queralt", "text": "

Why \"non male\"?

", "time": "2024-07-22T17:19:00Z"}, {"author": "Mike Bishop", "text": "

Outside the scope of DISPATCH.

", "time": "2024-07-22T17:19:01Z"}, {"author": "Jean Queralt", "text": "

Are \"males\" not fit for liaisons?

", "time": "2024-07-22T17:19:19Z"}, {"author": "Mirja K\u00fchlewind", "text": "

I guess he is proposing a liaison from the systers group

", "time": "2024-07-22T17:19:23Z"}, {"author": "Rich Salz", "text": "

the nomcom chair can appoint advisors, subject to the nomcom committee approving them.

", "time": "2024-07-22T17:19:54Z"}, {"author": "Jean Queralt", "text": "

That's a different framing for the question.
\nWould be good to have a clarification on that.

", "time": "2024-07-22T17:19:56Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Liaison are non-voting, so I think that\u2019s actually a good idea

", "time": "2024-07-22T17:20:05Z"}, {"author": "Rich Salz", "text": "

advisors are allowed to do everything but vote; that's limited to the people picked from the pool

", "time": "2024-07-22T17:20:32Z"}, {"author": "Rich Salz", "text": "

I would suggest that @Dean talk to the systers and see if there are volunteers, and then the nomcom decides (pribvately) if they want to do it

", "time": "2024-07-22T17:21:09Z"}, {"author": "Robert Sparks", "text": "

I think you should ask Dean what he meant - I heard something else than adding some new liaison.

", "time": "2024-07-22T17:21:25Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Rfc8713: \u201e Any committee member may propose the addition of a liaison from other unrepresented organizations to participate in some or all of the deliberations of the committee. The addition must be approved by the committee according to its established voting mechanism. Liaisons participate as representatives of their respective organizations.\u201c

", "time": "2024-07-22T17:22:20Z"}, {"author": "Francesca Palombini", "text": "

gentle reminder: especially for speakers at the mic (chat has more freedom, since it does not take meeting time) please keep the \"dispatch\" goal in mind when speaking

", "time": "2024-07-22T17:22:27Z"}, {"author": "Rich Salz", "text": "

What did you hear robert?

", "time": "2024-07-22T17:22:37Z"}, {"author": "Chris Lemmons", "text": "

Speaking as a recent NomCom member, access to more viewpoints is of significant value, both as voting members and as liasons. The perspectives of people with gender identities other than my own are very valuable for a variety of issues that can come up.

\n

I'm looking forward to the working group.

", "time": "2024-07-22T17:22:46Z"}, {"author": "Francesca Palombini", "text": "

(packed agenda, etc)

", "time": "2024-07-22T17:23:07Z"}, {"author": "Robert Sparks", "text": "

that the bodies that have already established liaisons consider if they might want to change who they have assigned.

", "time": "2024-07-22T17:23:16Z"}, {"author": "Rich Salz", "text": "

oh. that's an intereting interpretation that did not occur to me at all but it could be what he meant :)

", "time": "2024-07-22T17:23:53Z"}, {"author": "Rich Salz", "text": "

BTW here's the liaison list: https://datatracker.ietf.org/nomcom/2024/

", "time": "2024-07-22T17:24:57Z"}, {"author": "Francesca Palombini", "text": "

everybody but ADs think AD sponsored is easier (usually it's not)

", "time": "2024-07-22T17:25:03Z"}, {"author": "Watson Ladd", "text": "

it's easier for everyone who isn't an AD, who usually is suggesting it

", "time": "2024-07-22T17:25:31Z"}, {"author": "Jean Queralt", "text": "

@Chris: Adding variety of thought/ideas/positions is not the issue. Hardly anyone would be against that. The issue at hand is how to achieve that without falling into a system that stops the best minds to be there.

", "time": "2024-07-22T17:25:32Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Yes I actually also understood Robert\u2019s interpretation but just adding an additional liaison might be easier

", "time": "2024-07-22T17:25:34Z"}, {"author": "Jari Arkko", "text": "

Moderation: Yes we should have a WG on this. It still won't be easy, but it is the only way.

", "time": "2024-07-22T17:26:39Z"}, {"author": "Kathleen Moriarty", "text": "

AD sponsored requires support for that AD. A designated and attentive, knowledgeable shepherd makes a significant difference.

", "time": "2024-07-22T17:26:44Z"}, {"author": "Francesca Palombini", "text": "

@Watson: it might be easier to get things started, but when it's time to get comments and evaluate consensus it is not easier for anyone IMO

", "time": "2024-07-22T17:27:02Z"}, {"author": "Chris Lemmons", "text": "

@Jean: The NomCom is a random selection of acceptable minds, not the best minds. (I know this, because they let me be there. :P)

", "time": "2024-07-22T17:27:11Z"}, {"author": "Harald Alvestrand", "text": "

just history commentary!

", "time": "2024-07-22T17:27:17Z"}, {"author": "Watson Ladd", "text": "

oh, i don't disagree. I was snarking about why we hear it suggested so often

", "time": "2024-07-22T17:27:33Z"}, {"author": "Jean Queralt", "text": "

@Chris: Fair point.
\nLet me rephrase then towards \"acceptable minds\" without starting a path that may lead us towards specific, infinite subcategorizations of quotas.

", "time": "2024-07-22T17:28:48Z"}, {"author": "Yoav Nir", "text": "

This session is recommending spinning up so many working groups...

", "time": "2024-07-22T17:29:25Z"}, {"author": "Jim Fenton", "text": "

yes indeed

", "time": "2024-07-22T17:30:04Z"}, {"author": "Robert Sparks", "text": "

sometimes lots of new working groups is the right thing to do.

", "time": "2024-07-22T17:30:47Z"}, {"author": "Nick Doty", "text": "

currently I strongly discourage any new participants from ever joining or looking at the plenary lists. so we should either improve those lists or shut them down.

", "time": "2024-07-22T17:30:51Z"}, {"author": "Rich Salz", "text": "

and there is no guarantee that all these WGs will be approved by the IESG

", "time": "2024-07-22T17:31:11Z"}, {"author": "Chris Lemmons", "text": "

@Jean: There's a difference between infinite subcategorizations and one. Doing one thing does not require anyone to do other things.

", "time": "2024-07-22T17:31:27Z"}, {"author": "Watson Ladd", "text": "

i have an email to hit send on about Nick's observation

", "time": "2024-07-22T17:31:28Z"}, {"author": "Jean Queralt", "text": "

Is there an RFC defining \"toxic behavior\"?

", "time": "2024-07-22T17:31:36Z"}, {"author": "Nick Doty", "text": "

maybe we could talk to eodir about outreach as one question of needing better moderation

", "time": "2024-07-22T17:32:19Z"}, {"author": "A.J. Stein", "text": "

Jean Queralt said:

\n
\n

Is there an RFC defining \"toxic behavior\"?

\n
\n

I was reminded for my Python if-else comment getting into the weeds on another dispatch topic the goal here is where to dispatch, not the context and work items of the work requesting dispatch.

\n

Are we not \"there\" yet with the content and context of that presentation three back?

", "time": "2024-07-22T17:32:56Z"}, {"author": "Kathleen Moriarty", "text": "

@Jean maybe acceptable behavior would be easier to achieve and not miss some behavior that\u2019s unne

", "time": "2024-07-22T17:32:59Z"}, {"author": "Kathleen Moriarty", "text": "

unacceptable - allow lists are easier than deny

", "time": "2024-07-22T17:33:40Z"}, {"author": "Jean Queralt", "text": "

@AJ: I am trying to understand the scope of the previous presentation.

", "time": "2024-07-22T17:33:56Z"}, {"author": "A.J. Stein", "text": "

Jean Queralt said:

\n
\n

@AJ: I am trying to understand the scope of the previous presentation.

\n
\n

That's for the pending work group or wherever that work ends up, it's been dispatched from here.

", "time": "2024-07-22T17:34:34Z"}, {"author": "Kathleen Moriarty", "text": "

AJ - it\u2019s ok for higher bandwidth comments in chat

", "time": "2024-07-22T17:35:00Z"}, {"author": "Nick Doty", "text": "

+1 Kathleen, it's also useful to identify the behavior you want to encourage and recommend

", "time": "2024-07-22T17:35:03Z"}, {"author": "Carsten Bormann", "text": "

Wo don't have a good process for wiki pages; that is something we should aggressively experiment in

", "time": "2024-07-22T17:35:52Z"}, {"author": "Harald Alvestrand", "text": "

BCP 83 has a description of \"abusive or otherwise inappropriate postings\" - it is surprisingly vague.

", "time": "2024-07-22T17:36:40Z"}, {"author": "Joel Halpern", "text": "

There is no such thing as an \"experimental working group\" Rather, there are working groups that are chartered to produce experimental RFCs.

", "time": "2024-07-22T17:36:51Z"}, {"author": "Joel Halpern", "text": "

(What Adrian said.)

", "time": "2024-07-22T17:36:59Z"}, {"author": "Jean Queralt", "text": "

Thx for the pointer, @Harald. Will have a look.

", "time": "2024-07-22T17:37:09Z"}, {"author": "Daniel Smullen", "text": "

Whether behavior is acceptable or not is highly contextual and is not at all robust over time. I don't think it's possible to specify in anything but vague language.

", "time": "2024-07-22T17:37:18Z"}, {"author": "Ted Hardie", "text": "

I think IESG statement after community review (for the IETF stream)

", "time": "2024-07-22T17:38:54Z"}, {"author": "Dan Harkins", "text": "

The definition of\"toxic\" is like the Supreme Court's definition of pornography, \"you know it when you see it.\"

", "time": "2024-07-22T17:39:02Z"}, {"author": "Jari Arkko", "text": "

Adrian, Toerless, we did have RFC 5111 for exploratory WGs. It was an experiment itself... concluded and found (in my experience) somewhat confusing. But Adrian of course is talking about experimental RFCs which is a different thing. Plus 1 to providing better guidance for that!

", "time": "2024-07-22T17:39:05Z"}, {"author": "Andrew Campling", "text": "

@Daniel Smullen IIRC The RIPE behaviour doc does give some examples of unacceptable behaviour but makes it clear that the list is non-exhaustive

", "time": "2024-07-22T17:39:24Z"}, {"author": "Jari Arkko", "text": "

+1000 on what Cullen said about non-experiment experimental RFCs :-)

", "time": "2024-07-22T17:40:22Z"}, {"author": "Mike Bishop", "text": "

Lack of consensus or lack of implementation.

", "time": "2024-07-22T17:40:32Z"}, {"author": "Mohamed Boucadair", "text": "

Agree with Cullen

", "time": "2024-07-22T17:40:35Z"}, {"author": "Martin Vigoureux", "text": "

agree too, but is EXPERIMENTAL the right category?

", "time": "2024-07-22T17:41:43Z"}, {"author": "Jessica Krynitsky", "text": "

failed experiments are still helpful to document! I do feel like the term experimental may be overloaded

", "time": "2024-07-22T17:42:09Z"}, {"author": "Joel Halpern", "text": "

\"Failed experiment\" sounds like \"historic\".

", "time": "2024-07-22T17:42:13Z"}, {"author": "Yoav Nir", "text": "

INFORMATIONAL - how we thought it should be done in 2022

", "time": "2024-07-22T17:42:14Z"}, {"author": "Martin Duke", "text": "

Wait, did Cullen say Informational was a higher bar than experimental?

", "time": "2024-07-22T17:42:20Z"}, {"author": "Martin Vigoureux", "text": "

understood this as well, but not sure

", "time": "2024-07-22T17:42:41Z"}, {"author": "Cullen Jennings", "text": "

I did say that but I could be way wrong on that :-)

", "time": "2024-07-22T17:42:52Z"}, {"author": "Martin Thomson", "text": "

it's not linear

", "time": "2024-07-22T17:43:14Z"}, {"author": "Cullen Jennings", "text": "

I think both Experimental and BCP are bad labels for how we often use them but I don't think it is worth the pain to fix that.

", "time": "2024-07-22T17:43:45Z"}, {"author": "John Klensin", "text": "

Curiously, some of these descriptions of \"experiment\" are fairly close to what was intended for \"Proposed Standard\" 30-odd years ago.

", "time": "2024-07-22T17:44:39Z"}, {"author": "Martin Duke", "text": "

\"this should be written down though it's not a standard\" is what Informational is for.

", "time": "2024-07-22T17:44:54Z"}, {"author": "Andrew Campling", "text": "

+1 to dispatch to a BoF

", "time": "2024-07-22T17:45:17Z"}, {"author": "Lucas Pardue", "text": "

if I wrote an experimental RFC that included the experiment conditions, would I write an update doc after the experiment ended?

", "time": "2024-07-22T17:45:43Z"}, {"author": "John Klensin", "text": "

Martin, I'd suggest that informational is misused almost as often as experimental

", "time": "2024-07-22T17:45:48Z"}, {"author": "Martin Thomson", "text": "

Is this GENDISPATCH?

", "time": "2024-07-22T17:46:24Z"}, {"author": "Martin Thomson", "text": "

Where are the new protocols?

", "time": "2024-07-22T17:46:31Z"}, {"author": "Toerless Eckert", "text": "

+1 on Romans mailing list

", "time": "2024-07-22T17:46:34Z"}, {"author": "Watson Ladd", "text": "

ask the authors :P

", "time": "2024-07-22T17:46:45Z"}, {"author": "Ted Hardie", "text": "

Note that he did not use the term \"enthusiast\" in the introduction of the topic....

", "time": "2024-07-22T17:46:58Z"}, {"author": "Yoav Nir", "text": "

@Martin: They tacked on a couple of SEC documents at the end.

", "time": "2024-07-22T17:47:01Z"}, {"author": "Martin Vigoureux", "text": "

it's nearly gendipatch, but not entirely

", "time": "2024-07-22T17:47:16Z"}, {"author": "Tom Hill", "text": "

'SUPERMEGADISPATCH' made me smile. Proposal to rename this session henceforth.

", "time": "2024-07-22T17:47:18Z"}, {"author": "Shuping Peng", "text": "

@Martin, this is the last one in the GEN area

", "time": "2024-07-22T17:47:28Z"}, {"author": "Martin Thomson", "text": "

The number of GEN area dispatches is <insert meme here>

", "time": "2024-07-22T17:47:57Z"}, {"author": "Nick Doty", "text": "

haha first alphabetically with out of date info, picks a group that starts with a number

", "time": "2024-07-22T17:48:30Z"}, {"author": "Mirja K\u00fchlewind", "text": "

I\u2018m not sure I understand fully what problem Adrian tries to fix.

", "time": "2024-07-22T17:48:34Z"}, {"author": "Yoav Nir", "text": "

All the non-gen documents are sec area

", "time": "2024-07-22T17:49:20Z"}, {"author": "Tom Hill", "text": "

\"We have standardised $contentious_thing\"

", "time": "2024-07-22T17:49:34Z"}, {"author": "Pete Resnick", "text": "

Mirja K\u00fchlewind said:

\n
\n

I\u2018m not sure I understand fully what problem Adrian tries to fix.

\n
\n

Experimental documents have haphazard approaches to documenting how they're doing their experiments. Adrian is proposing to publish some guidance.

", "time": "2024-07-22T17:49:43Z"}, {"author": "Carsten Bormann", "text": "

what are dates for: ordering deliverables

", "time": "2024-07-22T17:49:52Z"}, {"author": "Tom Hill", "text": "

Spoiler: it's experimental, but no-one outside of the IETF understands what that means

", "time": "2024-07-22T17:50:03Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Yes I understand his proposal but I don\u2019t understand the problem this would solve

", "time": "2024-07-22T17:50:20Z"}, {"author": "Daniel Smullen", "text": "

I would personally, as a newbie, enjoy some clarification on what \"experimental\" means.

", "time": "2024-07-22T17:50:20Z"}, {"author": "Carsten Bormann", "text": "

As a chair, I have been reminding people to think about their experiments

", "time": "2024-07-22T17:50:46Z"}, {"author": "Toerless Eckert", "text": "

Tom: thats fine. outside IETF people often do not understand the difference between other tracks, or why an informational document can be more important for a customer than a standards track one.

", "time": "2024-07-22T17:50:51Z"}, {"author": "Lucas Pardue", "text": "

the non-dated milestones are ordered

", "time": "2024-07-22T17:51:01Z"}, {"author": "Carsten Bormann", "text": "

Lucas: It's like a basic program

", "time": "2024-07-22T17:51:19Z"}, {"author": "Mirja K\u00fchlewind", "text": "

That\u2019s the labels are not clear is a problem I understand but I guess my solution would be to get rid of them\u2026

", "time": "2024-07-22T17:51:24Z"}, {"author": "Tom Hill", "text": "

Is it fine if it's being sold as something other than an experiment, Toerless?

", "time": "2024-07-22T17:51:25Z"}, {"author": "Daniel Smullen", "text": "

What is an experiment?

", "time": "2024-07-22T17:51:53Z"}, {"author": "Adrian Farrel", "text": "

I think that one thing we could do better is make clear that an Experiment is an experiment beyond simply putting a tag on the RFC

", "time": "2024-07-22T17:52:09Z"}, {"author": "Lucas Pardue", "text": "

but literally, when you manage the non-dated milestones, you have to order them in the datatracker

", "time": "2024-07-22T17:52:26Z"}, {"author": "Carsten Bormann", "text": "

Experiment = (1) What do we want to learn? (2) How?

", "time": "2024-07-22T17:52:42Z"}, {"author": "Michael Richardson", "text": "

Can /dev/random replace IESG DISCUSS? I'm thinking a D20 roll.

", "time": "2024-07-22T17:53:11Z"}, {"author": "Mirja K\u00fchlewind", "text": "

I think Cullen and toerless actually made the point that not all experimental RFC are actual experiments

", "time": "2024-07-22T17:53:13Z"}, {"author": "Kathleen Moriarty", "text": "

As an example, HTTPAuth published several experimental drafts to see if traction could be made on improved HTTP authentication methods. Some of those never got traction and done had limited traction. It might help to put a Datatracker marker at some defined time period on the result of such experiments.

", "time": "2024-07-22T17:53:13Z"}, {"author": "Daniel Smullen", "text": "

Are both (1) and (2) essential components of an experiment (seems yes) and what are the specifications on the output? Is such a specification required for it to be an experiment?

", "time": "2024-07-22T17:53:23Z"}, {"author": "Carsten Bormann", "text": "

Maybe \"can we make this work with a fuzzy spec\" is also an experiment

", "time": "2024-07-22T17:53:49Z"}, {"author": "Daniel Smullen", "text": "

Thanks, this is helpful.

", "time": "2024-07-22T17:54:19Z"}, {"author": "Sean Turner", "text": "

+1 to what Chris said

", "time": "2024-07-22T17:54:28Z"}, {"author": "Harald Alvestrand", "text": "

Once this is approved, we can suggest adopting Marshall Rose's 2002 suggestion of closing any WG for which milestones are 6 months in the past.

", "time": "2024-07-22T17:54:49Z"}, {"author": "Carsten Bormann", "text": "

Daniel: It is nice if (2) is in the document, but we don't need always consensus on it, just a shared feeling that it can be done.

", "time": "2024-07-22T17:55:06Z"}, {"author": "Carsten Bormann", "text": "

Milestones \u2794 Deliverables

", "time": "2024-07-22T17:56:17Z"}, {"author": "A.J. Stein", "text": "

The milestone updates work is great, AD sponsored or not is a nice small change to reduce toil. I like the pragmatism of Bron's comments, but yeah.

", "time": "2024-07-22T17:56:20Z"}, {"author": "Mike Bishop", "text": "

+1, Carsten -- the name becomes inaccurate without dates.

", "time": "2024-07-22T17:56:42Z"}, {"author": "Carsten Bormann", "text": "

(I want to put dates there, BTW.)

", "time": "2024-07-22T17:57:00Z"}, {"author": "Carsten Bormann", "text": "

But all WGs are different, so I would not make you do that

", "time": "2024-07-22T17:57:17Z"}, {"author": "Carsten Bormann", "text": "

Make the milestones' font fade out if not confirmed

", "time": "2024-07-22T17:57:42Z"}, {"author": "John Border", "text": "

I don't like specific dates but some concept of ordering is useful.

", "time": "2024-07-22T17:57:51Z"}, {"author": "Harald Alvestrand", "text": "

in 2002, there was wide support for the idea of closing overdue WGs, but fierce resistance to closing any specific working group.....

", "time": "2024-07-22T17:58:08Z"}, {"author": "Carsten Bormann", "text": "

Dates are fine if this is planning information and not a commitment

", "time": "2024-07-22T17:58:09Z"}, {"author": "Toerless Eckert", "text": "

Mirja: I am not sure if we need to introduce new words for \"experiments\" whose goal is to increase consensus (Cullen) or confidence (Toerless). But both are important cases for which the guidance that Adrian wants to create might need to specify different required detauls.

", "time": "2024-07-22T17:58:12Z"}, {"author": "Carsten Bormann", "text": "

Making the AD approve = make them pay attention

", "time": "2024-07-22T17:58:54Z"}, {"author": "Christian Huitema", "text": "

Without milestone, how do we decide that a WG is lost in the woods?

", "time": "2024-07-22T17:59:13Z"}, {"author": "Adrian Farrel", "text": "

Mirja (and Cullen and Toerless): On the \"not all experimental RFCs are experiments\" discussion...
\nIf this is happening then we need to think a bit carefully. Things that are published for information (e.g., here is something we thought about and didn't pursue) then, well, Informational! Things that are published to record some history (e.g., here is something we tried, but failed) then, erm, Historic.
\nWhy would you call something Experimental if it is not experimental? Except, perhaps, \"Hey, here is a bucket let's put stuff in it.\"

", "time": "2024-07-22T17:59:14Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Protocol specs by the IRTF

", "time": "2024-07-22T18:00:16Z"}, {"author": "Toerless Eckert", "text": "

Adrian: it's ab out the goal of the experiment. Both cullen and my examples are likely to ultimately get to standards. Whether in the same document through later upgrade or later RFCs is a separate question

", "time": "2024-07-22T18:00:34Z"}, {"author": "Carsten Bormann", "text": "

DTN went to standard. v6 was an experiment

", "time": "2024-07-22T18:00:50Z"}, {"author": "Tom Hill", "text": "

Could we limit the use of Experimental to the IRTF?

", "time": "2024-07-22T18:00:50Z"}, {"author": "Carsten Bormann", "text": "

Tom: Not bad, because we have the license for research

", "time": "2024-07-22T18:01:15Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Or protocol specs that simply have not been well enough deployed yet to be confident we fit it fully right without a specific question in mind

", "time": "2024-07-22T18:01:16Z"}, {"author": "Carsten Bormann", "text": "

But not all experiments are research

", "time": "2024-07-22T18:01:24Z"}, {"author": "Carsten Bormann", "text": "

Mirja: So the question (1) would be \"can we get this deployed\"?

", "time": "2024-07-22T18:01:50Z"}, {"author": "Toerless Eckert", "text": "

Carsten: in something like BIER the \"experimental\" question really was \"can we get it implemented in hardware\"

", "time": "2024-07-22T18:02:22Z"}, {"author": "Carsten Bormann", "text": "

Great question (1)

", "time": "2024-07-22T18:02:37Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Transport published a lot of experimental because of limited deployment experience. We tried to change that and go directly to PS instead because we then never update to PS. But experimentisl is simply used as recording a different maturity level.

", "time": "2024-07-22T18:03:35Z"}, {"author": "Toerless Eckert", "text": "

In LISP i think it was a bit more convoluted. If i remember correctly, the original goal was the IETF's Locator Identifier Separation question, and there was not enough confidence and/or consensus we should even solve the problem. And then after chaterting, LISP managed to evolve through experimentation into more solid business models.

", "time": "2024-07-22T18:04:04Z"}, {"author": "Carsten Bormann", "text": "

Which is fine if the experiment is implicit but obvious

", "time": "2024-07-22T18:04:04Z"}, {"author": "Carsten Bormann", "text": "

(Which = Mirja's point)

", "time": "2024-07-22T18:04:26Z"}, {"author": "Kathleen Moriarty", "text": "

Geneve has no security baked in and relies on an IPsec layer. I read the draft and see the drivers for this. It\u2019s also pretty far along and will benefit from more review.

", "time": "2024-07-22T18:04:46Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Some RFCs have sections about the experiment which is fine. Again I don\u2019t understand the problem that needs solving besides the general question if these levels are useful at all.

", "time": "2024-07-22T18:05:28Z"}, {"author": "Joel Halpern", "text": "

I think clarifying the LISP hsitory would be a distraction. SUggice it to say that as co-chair I think the sequence of publishing experimental RFCs with clear observables followed by moving appropriate content to PS was very useful.

", "time": "2024-07-22T18:05:34Z"}, {"author": "Toerless Eckert", "text": "

I think our work would beenfit in general from more explicit description of the current maturity level and whats missing for the next level.

", "time": "2024-07-22T18:06:03Z"}, {"author": "Erik Nygren", "text": "

Is there a reason why SRv6 couldn't be used here, or does it lack an authentication/security model that would fit in well here?

", "time": "2024-07-22T18:06:10Z"}, {"author": "Yoav Nir", "text": "

Deriving a key from a traffic encryption key sounds fishy

", "time": "2024-07-22T18:06:12Z"}, {"author": "Kathleen Moriarty", "text": "

Is there a WH this fits?

", "time": "2024-07-22T18:06:17Z"}, {"author": "Kathleen Moriarty", "text": "

WG

", "time": "2024-07-22T18:06:26Z"}, {"author": "Joel Halpern", "text": "

SRv6 security requires a limited domain.

", "time": "2024-07-22T18:06:29Z"}, {"author": "Watson Ladd", "text": "

ipscme?

", "time": "2024-07-22T18:06:34Z"}, {"author": "Yoav Nir", "text": "

It's adjacent to IPsecME, but not exactly

", "time": "2024-07-22T18:06:54Z"}, {"author": "Watson Ladd", "text": "

how much of a shoehorn is needed?

", "time": "2024-07-22T18:07:07Z"}, {"author": "Yoav Nir", "text": "

We did similar things in I2NSF

", "time": "2024-07-22T18:07:44Z"}, {"author": "Jonathan Lennox", "text": "

For the topic I raised for the experimental issue, there was a spec we were doing in AVTCore that by the time we finally pushed it through publication, the browsers had all decided not to use it (in at least one case it had been in and then removed). (It took a very long time to get the authors to finish it exactly because no one was interested in using it). So we published it as experimental as \"a failed experiment\". Guidance for what to do in that case would be helpful.

", "time": "2024-07-22T18:08:10Z"}, {"author": "Martin Thomson", "text": "

How does \"lightweight\" match up with something that involves digital signatures on a per-packet basis?

", "time": "2024-07-22T18:08:21Z"}, {"author": "Toerless Eckert", "text": "

Joel: Sure. Just wanted to say that the experimental target label for initial LISP work was very helpful to set expectations right and allow the WG to evolve into something very useful. So i am primarily woried about limiting experimental work more by thinking about only a subset of possible use as being appropriate for it.

", "time": "2024-07-22T18:08:41Z"}, {"author": "Yoav Nir", "text": "

\"lightweight\" = \"no IKE\"

", "time": "2024-07-22T18:08:43Z"}, {"author": "Jonathan Hoyland", "text": "

So this is HMAC based, which means that only people with the secret key can validate the header, right?

", "time": "2024-07-22T18:09:03Z"}, {"author": "Jonathan Hoyland", "text": "

@Watson Ladd Happy to relay to MIC

", "time": "2024-07-22T18:09:31Z"}, {"author": "Martin Thomson", "text": "

The draft isn't particularly clear to me, but there is a section on digital signatures.

", "time": "2024-07-22T18:09:36Z"}, {"author": "Sophie Schmieg", "text": "

Yoav Nir said:

\n
\n

Deriving a key from a traffic encryption key sounds fishy

\n
\n

Yeah, that was my first reaction as well, don't reuse key material out of context

", "time": "2024-07-22T18:09:43Z"}, {"author": "Kathleen Moriarty", "text": "

IPsec is already the method used to provide a security layer on top of GENEVE, they are trying to add some directly at this layer.

", "time": "2024-07-22T18:09:44Z"}, {"author": "Toerless Eckert", "text": "

jonathan: if the RFC would simply state the experience gained and stating that the industry went a different wauy, then i think that would be fine.

", "time": "2024-07-22T18:09:50Z"}, {"author": "Watson Ladd", "text": "

my comment: I have poor confidence in this, but this feels very similar to AH from IPSeC, and we need a proper key negotiation mechanism

", "time": "2024-07-22T18:10:04Z"}, {"author": "Mike Bishop", "text": "

Watson was very understandable over MeetEcho, so I think it's an in-room issue.

", "time": "2024-07-22T18:10:09Z"}, {"author": "Jonathan Lennox", "text": "

It sounded like Watson was asking if this topic would fit in IPSECME.

", "time": "2024-07-22T18:10:14Z"}, {"author": "Kathleen Moriarty", "text": "

Could a design team be an option?

", "time": "2024-07-22T18:10:18Z"}, {"author": "Jonathan Lennox", "text": "

I could hear him reasonably clearly in the audience in the room.

", "time": "2024-07-22T18:10:23Z"}, {"author": "Kathleen Moriarty", "text": "

I do g think it belongs in IPsecMe

", "time": "2024-07-22T18:10:49Z"}, {"author": "Kathleen Moriarty", "text": "

Don\u2019t

", "time": "2024-07-22T18:10:57Z"}, {"author": "Watson Ladd", "text": "

how many packet layer security mechanisms do we need :P?

", "time": "2024-07-22T18:11:11Z"}, {"author": "Christian Huitema", "text": "

There is an issue that any serious proof requires at least 256 bits. If that's too much overhead, then the solution has to involve spreading the proof over multiple successive packets.

", "time": "2024-07-22T18:11:20Z"}, {"author": "Chris Lemmons", "text": "

One more.

", "time": "2024-07-22T18:11:21Z"}, {"author": "Martin Thomson", "text": "

all of them, obviously

", "time": "2024-07-22T18:11:23Z"}, {"author": "Yoav Nir", "text": "

It's kind of like the thing we did in I2NSF

", "time": "2024-07-22T18:11:24Z"}, {"author": "Kathleen Moriarty", "text": "

Design tran

", "time": "2024-07-22T18:11:43Z"}, {"author": "Alex Chernyakhovsky", "text": "

Watson Ladd said:

\n
\n

how many packet layer security mechanisms do we need :P?

\n
\n

https://xkcd.com/927/

", "time": "2024-07-22T18:11:45Z"}, {"author": "Kathleen Moriarty", "text": "

Team

", "time": "2024-07-22T18:11:57Z"}, {"author": "Dan Wing", "text": "

DTLS-SRTP does something similar; it leaves some of the RTP headers in the clear on purpose. For whatever it's worth, DTLS-SRTP was standardized in AVT (which standardized RTP), https://datatracker.ietf.org/doc/html/rfc5764

", "time": "2024-07-22T18:12:39Z"}, {"author": "Jonathan Hoyland", "text": "

So I'm worried that an attacker could remove the header / make a bad header, force the packet to go the wrong route, and then restore the header before it's received by B.

", "time": "2024-07-22T18:13:32Z"}, {"author": "Yoav Nir", "text": "

RFC 9061 was the I2NSF document I meant.

", "time": "2024-07-22T18:13:58Z"}, {"author": "Christian Huitema", "text": "

Cool. A not-ipsec-sec group!

", "time": "2024-07-22T18:14:03Z"}, {"author": "Kathleen Moriarty", "text": "

@Jonathan - there\u2019s no security now, maybe assist on a design team?

", "time": "2024-07-22T18:14:40Z"}, {"author": "Jonathan Hoyland", "text": "

@Kathleen Moriarty Happy to assist, but I really don't understand the threat model, so not sure how helpful I could be.

", "time": "2024-07-22T18:15:52Z"}, {"author": "Valery Smyslov", "text": "

Threat model is indeed unclear

", "time": "2024-07-22T18:16:27Z"}, {"author": "Kathleen Moriarty", "text": "

I think it matters when your endpoints for GENEVE do not match the endpoints for the IPsec layer.

", "time": "2024-07-22T18:19:11Z"}, {"author": "Jonathan Hoyland", "text": "

If you're going to have mismatched endpoints, then you're going to have horrible issues with compound authentication.

", "time": "2024-07-22T18:19:58Z"}, {"author": "Chris Lemmons", "text": "

I'd like to second those thoughts, but don't really need mic time. This just appears to move the credentials to another place and hopes the user agent does a better job presenting it.

", "time": "2024-07-22T18:20:53Z"}, {"author": "Jonathan Hoyland", "text": "

(Also, I the key transmission solution has a really high ick factor.)

", "time": "2024-07-22T18:20:55Z"}, {"author": "Robert Sparks", "text": "

@nick: confidence of confidence - nice.

", "time": "2024-07-22T18:21:01Z"}, {"author": "Kathleen Moriarty", "text": "

That\u2019s why I suggested a design team

", "time": "2024-07-22T18:21:38Z"}, {"author": "Jonathan Lennox", "text": "

I think the point of this draft as far as I can see is a way to resurrect userinfo parts without the danger of visually deceptive URIs.

", "time": "2024-07-22T18:21:41Z"}, {"author": "Nick Doty", "text": "

I think there might be good work to do on better authentication with different mechanisms, like databases. I'm not sure URIs are ever going to be the solution to that, so it seems like pretty different work.

", "time": "2024-07-22T18:22:12Z"}, {"author": "Alex Chernyakhovsky", "text": "

Jonathan Hoyland said:

\n
\n

If you're going to have mismatched endpoints, then you're going to have horrible issues with compound authentication.

\n
\n

It seems to me like the mismatched endpoints are primarily a) a desired property of the system being discussed b) the thing that I think makes the threat model really hard to nail down. My general experience with SDN systems is you don't give untrusted participants the ability to influence their routing over a network, overlay or otherwise, without some endpoint enforcing the policy. So I would have expected a solution in which a peer asks for some routing property, and then the first privileged node in the network either rewrites this to something that adheres to policy or validates it does and lets it through.

", "time": "2024-07-22T18:23:05Z"}, {"author": "Jonathan Lennox", "text": "

Are URIs WIT or ART? That's a bit unclear to me on the separation.

", "time": "2024-07-22T18:23:10Z"}, {"author": "Carsten Bormann", "text": "

URIs are WIT, any specific scheme is likely to be ART

", "time": "2024-07-22T18:23:48Z"}, {"author": "Jonathan Hoyland", "text": "

Alex Chernyakhovsky said:

\n
\n

Jonathan Hoyland said:

\n
\n

If you're going to have mismatched endpoints, then you're going to have horrible issues with compound authentication.

\n
\n

It seems to me like the mismatched endpoints are primarily a) a desired property of the system being discussed b) the thing that I think makes the threat model really hard to nail down. My general experience with SDN systems is you don't give untrusted participants the ability to influence their routing over a network, overlay or otherwise, without some endpoint enforcing the policy. So I would have expected a solution in which a peer asks for some routing property, and then the first privileged node in the network either rewrites this to something that adheres to policy or validates it does and lets it through.

\n
\n

I think the mismatched endpoints are going to make it impossible to even reliably describe the actors involved, and thus what properties you actually want.

", "time": "2024-07-22T18:24:27Z"}, {"author": "Zaheduzzaman Sarker", "text": "

As WIT area AD : I would also like to see more discussions and understand better!! and HTTPbis should be involved.

", "time": "2024-07-22T18:24:47Z"}, {"author": "Andrew Campling", "text": "

+1 to dispatch to side meeting

", "time": "2024-07-22T18:25:39Z"}, {"author": "Jonathan Lennox", "text": "

We can dispatch to \"more discussion needed\" generally

", "time": "2024-07-22T18:26:21Z"}, {"author": "Chris Lemmons", "text": "

We can dispatch to \"technically nowhere, but improve the clarity on the problem statement and the work being proposed and come back\", I\u00a0think.

", "time": "2024-07-22T18:26:48Z"}, {"author": "Francesca Palombini", "text": "

httpbis? witarea@ietf? art@ietf?

", "time": "2024-07-22T18:26:51Z"}, {"author": "Jonathan Hoyland", "text": "

Is there a difference to dispatch to non-WG forming BoF?

", "time": "2024-07-22T18:26:54Z"}, {"author": "Nick Doty", "text": "

I don't think you should start a new mailing list until we better understand the problem and what people want to talk about

", "time": "2024-07-22T18:27:18Z"}, {"author": "Francesca Palombini", "text": "

Jonathan: difference compared to?

", "time": "2024-07-22T18:27:47Z"}, {"author": "Jonathan Hoyland", "text": "

Unofficially dispatch to side meeting

", "time": "2024-07-22T18:28:02Z"}, {"author": "Nick Doty", "text": "

I thought gender representation had a rough WG conclusion, although there were certainly viewpoints for both WG and AD.

", "time": "2024-07-22T18:28:16Z"}, {"author": "Carsten Bormann", "text": "

Nick: So where do we discuss until there is a mailing list? (I'm after the pollution of other lists, combined with forum shopping.)

", "time": "2024-07-22T18:28:21Z"}, {"author": "Julien Maisonneuve", "text": "

wasn't gender diversity more a WG outcome ?

", "time": "2024-07-22T18:28:33Z"}, {"author": "Francesca Palombini", "text": "

non-WG forming BoF still needs IESG approval, side meeting has no standings (not a dispatch outcome)

", "time": "2024-07-22T18:28:40Z"}, {"author": "Nick Doty", "text": "

Carsten, I thought the suggestion was the wit list, before creating another mailing list

", "time": "2024-07-22T18:28:51Z"}, {"author": "Carsten Bormann", "text": "

Yes. I'd rather split this off as early as possible.

", "time": "2024-07-22T18:29:08Z"}, {"author": "Francesca Palombini", "text": "

Thank you chairs! and all the presenters, I think the presentations were much more focused and the result showed

", "time": "2024-07-22T18:29:39Z"}, {"author": "Carsten Bormann", "text": "

Thank you all!

", "time": "2024-07-22T18:29:58Z"}]