[{"author": "Rich Salz", "text": "

GENDISPATCH at IETF 117

", "time": "2023-07-25T22:04:12Z"}, {"author": "Pete Resnick", "text": "

Shuping, can you hear us?

", "time": "2023-07-25T22:04:31Z"}, {"author": "Lorenzo Miniero", "text": "

Shuping, can you try to speak?

", "time": "2023-07-25T22:05:51Z"}, {"author": "Shuping Peng", "text": "

@ Pete, yes. I can hear you. Just the audio is not working. I cannot control it. I need to restart.

", "time": "2023-07-25T22:06:11Z"}, {"author": "Shuping Peng", "text": "

Sorry about the first slides. It has been updated.

", "time": "2023-07-25T22:06:27Z"}, {"author": "Lorenzo Miniero", "text": "

Shuping, if you reconnect, check if during the preflight section you can see the bars moving when you talk: that should be an indication of whether the browser is getting audio from your mic

", "time": "2023-07-25T22:07:40Z"}, {"author": "Shuping Peng", "text": "

now it should be working. Thank you!

", "time": "2023-07-25T22:09:09Z"}, {"author": "Michael Richardson", "text": "

@Charles Eckel about your document. You could easily replace \"github\" with \"git\" in almost all instance, and that will probably make many people happier. But, more to the point, are you aware of code.ietf.org? It died for reasons I never learnt of.

", "time": "2023-07-25T22:10:09Z"}, {"author": "Michael Richardson", "text": "

The last point, \"No time spent building the leadership\" is actually the most important issue. The rest of the issues are the consequences of lack of confidence by ADs in WG leadership (particularly for WGs they do not manage), and the result is micromanagement, and a culture of \"we have to fix everything\"

", "time": "2023-07-25T22:12:12Z"}, {"author": "Benjamin Kaduk", "text": "

Document-review workload is a result of micromanagement?

", "time": "2023-07-25T22:12:55Z"}, {"author": "Michael Richardson", "text": "

Benjamin Kaduk said:

\n
\n

Document-review workload is a result of micromanagement?

\n
\n

Yup. If you trusted the WGs and the SECDIR to do the document-review, and the RFC2026 PS/IS process, then you wouldn't worry about making every document quite so perfect. \"If I don't fix this, it won't get fixed\"

", "time": "2023-07-25T22:14:20Z"}, {"author": "Stephen Farrell", "text": "

Lots of reasonable diagnosis of the problem in that draft, not sure the suggestions would have any noticeable effect though

", "time": "2023-07-25T22:16:24Z"}, {"author": "Benjamin Kaduk", "text": "

Ah, I see the point you're trying to make, thanks.
\nThere may be a circular dependency, though, as it is hard as AD to step back and trust people when recent memory included so much stuff that only got caught at the IESG

", "time": "2023-07-25T22:16:51Z"}, {"author": "Michael Richardson", "text": "

It's okay for the IESG to make mistakes. The long document cycle makes it harder to fix things quickly. We are very much not agile here. (Shoot, Aim, Shoot, Aim)... the difficulty in fixing things contribute to \"must fix it or else\"... need to come back to RF-COMMENTS... and understanding that PS is never the end.

", "time": "2023-07-25T22:18:44Z"}, {"author": "Michael Richardson", "text": "

My infant son was at the 2005 NEWTRK dinner meeting. He is 18 now.

", "time": "2023-07-25T22:20:22Z"}, {"author": "Robert Sparks", "text": "

@Michael Richardson : 1 std level

", "time": "2023-07-25T22:20:28Z"}, {"author": "Benjamin Kaduk", "text": "

Is \"Stop the focus on nittery
\n\u2022 Continue to reject documents with significantly bad grammar\" saying that the IESG should just not review documents that are hard to comprehend due to language issues?

", "time": "2023-07-25T22:21:14Z"}, {"author": "Michael Richardson", "text": "

Robert Sparks said:

\n
\n

Michael Richardson : 1 std level

\n
\n

If you are saying we have evolved towards there is only 1 std level, then I agree. It's wrong. If you are suggesting that we eliminate IS, then I'd like to hear more.

", "time": "2023-07-25T22:21:15Z"}, {"author": "John Klensin", "text": "

@Ben, there is another issue, which is that one of the IETF's historical strengths is strong cross-area/ cross-speciality review. Expecting a WG to do careful review of things its participants don't know about (much less understand) is unrealistic. At least historically, IETF LC and discussions amnog ADs (from their different areas of expertise) are our only checks on something that makes sense within one perspective but not across the range of protocols.

", "time": "2023-07-25T22:21:56Z"}, {"author": "Michael Richardson", "text": "

Benjamin Kaduk said:

\n
\n

Is \"Stop the focus on nittery
\n\u2022 Continue to reject documents with significantly bad grammar\" saying that the IESG should just not review documents that are hard to comprehend due to language issues?

\n
\n

Yeah, send them back to the WG. Ask the sponsoring AD, WTF. It's why I suggest getting an RPC pass during WGLC.

", "time": "2023-07-25T22:22:51Z"}, {"author": "Benjamin Kaduk", "text": "

mic: I like the proposal to do small increments and be adaptive. Can we publish a short document laying out a framework and do some lightweight process (IETF LC) to get community buy-in for individual \"experiments\"/increments?

", "time": "2023-07-25T22:23:15Z"}, {"author": "Pete Resnick", "text": "

The IESG has resolutely refused to write a charter.

", "time": "2023-07-25T22:23:35Z"}, {"author": "Harald Alvestrand", "text": "

This presentation could have been given in 2003 so far.

", "time": "2023-07-25T22:24:09Z"}, {"author": "John Klensin", "text": "

And, since Michael mentioned NEWTRK, resolutely refused to consider things that would bring about significant change.

", "time": "2023-07-25T22:24:38Z"}, {"author": "Martin Thomson", "text": "

The IESG having self-selected into a system of oppression is maybe not the right group of people to set the policy for the future, I get that.

", "time": "2023-07-25T22:24:46Z"}, {"author": "Harald Alvestrand", "text": "

Charter: update, not write. https://datatracker.ietf.org/doc/html/rfc3710

", "time": "2023-07-25T22:24:49Z"}, {"author": "Michael Richardson", "text": "

Harald Alvestrand said:

\n
\n

This presentation could have been given in 2003 so far.

\n
\n

yeah, exactly. The IESG can not reform itself, because it doesn't have time, because... it doesn't have time.

", "time": "2023-07-25T22:24:53Z"}, {"author": "Benjamin Kaduk", "text": "

Strategic thinking for the IESG is really hard when retreats are all-virtual.
\n(It's merely hard when we're in-person.)

", "time": "2023-07-25T22:26:01Z"}, {"author": "Murray Kucherawy", "text": "

These aviation analogies are hitting home.

", "time": "2023-07-25T22:26:42Z"}, {"author": "John Klensin", "text": "

Of course, one really effective way to reduce the workload is for the IETF (not just the IESG) to get better at prioritizing whatever work is important and decided we really don't need to do the rest.

", "time": "2023-07-25T22:26:59Z"}, {"author": "Harald Alvestrand", "text": "

I would say that they are being driven into the ground.....

", "time": "2023-07-25T22:27:07Z"}, {"author": "Benjamin Kaduk", "text": "

I sure hope no engine parts are falling on your house, @Murray Kucherawy !

", "time": "2023-07-25T22:27:07Z"}, {"author": "Martin Thomson", "text": "

Ummmm, I cannot possibly claim with any confidence that the IETF has not produced bad documents; the opposite in fact, I KNOW that the IETF has produced bad documents

", "time": "2023-07-25T22:28:06Z"}, {"author": "Jari Arkko", "text": "

If everyone in the queue makes a long statement, we will not get out of this topic or room before the meeting ends...

", "time": "2023-07-25T22:29:14Z"}, {"author": "Benjamin Kaduk", "text": "

Jari, are you trapped in the past?

", "time": "2023-07-25T22:29:33Z"}, {"author": "Jari Arkko", "text": "

Oopsie yes

", "time": "2023-07-25T22:29:49Z"}, {"author": "Michael Richardson", "text": "

Benjamin Kaduk said:

\n
\n

Jari, are you trapped in the past?

\n
\n

Jari prefers winter meetings, when there is snow.

", "time": "2023-07-25T22:29:57Z"}, {"author": "Martin Thomson", "text": "

Just curious, which IETF meeting was in Kobe?

", "time": "2023-07-25T22:30:07Z"}, {"author": "Jari Arkko", "text": "

If everyone in the queue makes a long statement, we will not get out of this topic or room before the meeting ends...

", "time": "2023-07-25T22:30:15Z"}, {"author": "Harald Alvestrand", "text": "

Martin, Kobe: IAB meeting following INET'92. Described in https://www.rfc-editor.org/rfc/rfc1640.html

", "time": "2023-07-25T22:31:08Z"}, {"author": "Pete Resnick", "text": "

Harald Alvestrand said:

\n
\n

Charter: update, not write. https://datatracker.ietf.org/doc/html/rfc3710

\n
\n

Not a BCP.

", "time": "2023-07-25T22:32:32Z"}, {"author": "Erik Kline", "text": "

@Martin Thomson you referring to RFC 1396?

", "time": "2023-07-25T22:33:01Z"}, {"author": "Harald Alvestrand", "text": "

Pete, not a BCP. But you did not qualify your statement of \"having a charter\" by saying \"a BCP\".

", "time": "2023-07-25T22:34:30Z"}, {"author": "Benjamin Kaduk", "text": "

I think he said BCP one time, but not all times, he mentioned charter

", "time": "2023-07-25T22:35:03Z"}, {"author": "Michael Richardson", "text": "

\"tell me how you'll measure me, and I'll tell you how I'll behave\" (Goldratt says that Demming said that, but it was someone else)

", "time": "2023-07-25T22:35:07Z"}, {"author": "Pete Resnick", "text": "

@Harald Alvestrand I thought I did, but my mistake if I didn't.

", "time": "2023-07-25T22:35:10Z"}, {"author": "Harald Alvestrand", "text": "

I wrote that charter as info because there was no chance in hell of declaring IETF consensus on it (or any slight variation of it) at the time.

", "time": "2023-07-25T22:35:51Z"}, {"author": "Harald Alvestrand", "text": "

I was asked \"what is a charter\" at the time, and never found a good answer.

", "time": "2023-07-25T22:36:38Z"}, {"author": "Benjamin Kaduk", "text": "

I think polling former ADs would be a decent way to get some suggestions for potential improvements

", "time": "2023-07-25T22:36:40Z"}, {"author": "Harald Alvestrand", "text": "

didn't we do metrics for where the time goes at one time?

", "time": "2023-07-25T22:37:50Z"}, {"author": "Benjamin Kaduk", "text": "

Yes, Christian Huitema wrote a thing

", "time": "2023-07-25T22:38:18Z"}, {"author": "Harald Alvestrand", "text": "

is it still running?

", "time": "2023-07-25T22:38:35Z"}, {"author": "Erik Kline", "text": "

The reading load for telechats, in my personal experience, varies between 100 pages and 400 pages every two weeks.

", "time": "2023-07-25T22:38:56Z"}, {"author": "Benjamin Kaduk", "text": "

Er, I should clarify; he wrote RFC 8963 as a point-in-time analysis, rather than a tool

", "time": "2023-07-25T22:38:57Z"}, {"author": "Pete Resnick", "text": "

To answer Cullen: The purpose from my point of view is to get ADs to use more of there time doing management and less doing document review.

", "time": "2023-07-25T22:38:57Z"}, {"author": "Harald Alvestrand", "text": "

Pete: review teams .... ?

", "time": "2023-07-25T22:39:35Z"}, {"author": "Pete Resnick", "text": "

s/there/their

", "time": "2023-07-25T22:39:38Z"}, {"author": "Harald Alvestrand", "text": "

we've only had them for 20 years.

", "time": "2023-07-25T22:40:19Z"}, {"author": "Pete Resnick", "text": "

@Harald Alvestrand Review teams have not seemed to have helped reduce the percentage of time that is spent.

", "time": "2023-07-25T22:40:19Z"}, {"author": "Martin Thomson", "text": "

aviate, navigate, communicate

", "time": "2023-07-25T22:40:21Z"}, {"author": "Martin Thomson", "text": "

controlled descent into terrain

", "time": "2023-07-25T22:40:38Z"}, {"author": "Harald Alvestrand", "text": "

Pete, do ADs with review teams actually read all the documents? I hope not.

", "time": "2023-07-25T22:41:08Z"}, {"author": "Michael Richardson", "text": "

hear hear!

", "time": "2023-07-25T22:41:25Z"}, {"author": "Benjamin Kaduk", "text": "

I have seen ADs ballot \"No objection, I trust the [directorate] review\"

", "time": "2023-07-25T22:41:30Z"}, {"author": "Jim Reid", "text": "

How about having another (Nomcom chosen?) group do the doc reviews and leave the ADs do other stuff?

", "time": "2023-07-25T22:41:34Z"}, {"author": "Harald Alvestrand", "text": "

(if output is 100 pages/week, review at 500 pages/2 weeks seems about right - average number of trips through the iesg is probably ~2)

", "time": "2023-07-25T22:41:38Z"}, {"author": "Murray Kucherawy", "text": "

@Martin: CFIT is the new DISCUSS.

", "time": "2023-07-25T22:42:28Z"}, {"author": "Benjamin Kaduk", "text": "

I think ~2 is overstating it, but the 500 is the maximum, not the average

", "time": "2023-07-25T22:42:32Z"}, {"author": "John Klensin", "text": "

I'm inclined to agree with Murray -- figuring out how to export some of the management and refereeing would probably be more productive than trying to offload document review. I might feel differently if the quality of review team output was higher, but I just don't see that happening.

", "time": "2023-07-25T22:42:53Z"}, {"author": "Mark Nottingham", "text": "

A WG might be a good venue to collect that data; let it recharter once done. If collection is done outside the process, it's harder to resource / trust the results.

", "time": "2023-07-25T22:44:08Z"}, {"author": "Colin Perkins", "text": "

The RASPRG in IRTF https://datatracker.ietf.org/rg/rasprg/about/ has understanding the standards process as its focus. If people are interested in systematically collecting data about how the process work, and the effectiveness of the process, they might wish to participate.

", "time": "2023-07-25T22:44:15Z"}, {"author": "Murray Kucherawy", "text": "

The concern I've heard in response to the idea of offloading refereeing is, in effect, \"We need to keep this in the family.\"

", "time": "2023-07-25T22:44:25Z"}, {"author": "Murray Kucherawy", "text": "

or \"Only the IESG has the right context.\"

", "time": "2023-07-25T22:44:37Z"}, {"author": "John Klensin", "text": "

or \"only the IESG has the community-selected collection of perspectives to figure things out in combination\".

", "time": "2023-07-25T22:45:29Z"}, {"author": "Mark Nottingham", "text": "

Yeah, that's concerning

", "time": "2023-07-25T22:45:30Z"}, {"author": "Murray Kucherawy", "text": "

That's more precise, but yeah, same idea.

", "time": "2023-07-25T22:45:44Z"}, {"author": "Pete Resnick", "text": "

No objection to BOF.

", "time": "2023-07-25T22:46:21Z"}, {"author": "Michael Richardson", "text": "

We don't ever dispatch to a WG anyway... it's always via a BOF, right :-)

", "time": "2023-07-25T22:46:49Z"}, {"author": "Mark Nottingham", "text": "

It might be helpful to start working on a straw-man charter on the GENDISPATCH list

", "time": "2023-07-25T22:47:03Z"}, {"author": "Stephen Farrell", "text": "

If a BoF I'd still love to see some credible proposals going in -expecting them to arise seems a bit like magical thinking

", "time": "2023-07-25T22:47:06Z"}, {"author": "Mark Nottingham", "text": "

It's an IESG honeypot!

", "time": "2023-07-25T22:49:51Z"}, {"author": "Pete Resnick", "text": "

A plenary BOF?

", "time": "2023-07-25T22:49:59Z"}, {"author": "Murray Kucherawy", "text": "

I count at least six current ADs in the room.

", "time": "2023-07-25T22:50:06Z"}, {"author": "Stephen Farrell", "text": "

what? have you ADs no real work to be doing? :-)

", "time": "2023-07-25T22:50:28Z"}, {"author": "Benjamin Kaduk", "text": "

We had a plenary ~BoF for one of the RFC-Editor/RFC-Series things, IIRC

", "time": "2023-07-25T22:50:46Z"}, {"author": "John Scudder", "text": "

I took myself out of the queue owing to Martin\u2019s plea to get back on schedule.

\n

I have two main things I was going to say. First, I agree with people like Pete, Stephen, and Fluffy who spoke in favor of not trying to micromanage IESG process, and disagree with David for the same reason.

\n

The second is to say that IMO the most meaningful thing the community could do is change the expectations of the IESG\u2019s work product. My own reading of 2026 is that the IESG\u2019s job is (in large part) to make sure the IETF work product \u2014 the RFCs \u2014 are of high quality. If the community is ok with the quality of published RFCs being in some cases lower and in any case more variable, that\u2019s meaningful and actionable. (I might not agree with that change, as a community member, but perhaps I\u2019m in the rough).

\n

The suggestions that are of the form \u201cwork smarter not harder\u201d? Unless the desired output is changed, that\u2019s doomed. See RFC 1925 Section 2 (2).

", "time": "2023-07-25T22:50:52Z"}, {"author": "Benjamin Kaduk", "text": "

@Stephen Farrell they are multitasking, obviously

", "time": "2023-07-25T22:51:01Z"}, {"author": "John Klensin", "text": "

We also drove POISED out of what was essentially a Plenary BOF too. FWIW.

", "time": "2023-07-25T22:51:29Z"}, {"author": "Ted Hardie", "text": "

@Murray There are four in my row--so I think you may be undercounting.

", "time": "2023-07-25T22:51:37Z"}, {"author": "Ted Hardie", "text": "

@Murray Sorry, i misread. The four in my row are ex-ADs

", "time": "2023-07-25T22:52:19Z"}, {"author": "Stephen Farrell", "text": "

WG to better define the problem seems pointless to me FWIW

", "time": "2023-07-25T22:52:29Z"}, {"author": "Harald Alvestrand", "text": "

The PROBLEM WG name is already used up.

", "time": "2023-07-25T22:53:12Z"}, {"author": "Michael Richardson", "text": "

John got it right: we need to change expectations, not only for the RFC series but also for ietf@ietf-like firefighting situation. The thing that keeps suffering is that WG chair mentoring/training and succession planning.

", "time": "2023-07-25T22:53:21Z"}, {"author": "Michael Richardson", "text": "

Harald Alvestrand said:

\n
\n

The PROBLEM WG name is already used up.

\n
\n

IAMTHEPROBLEMITSME.

", "time": "2023-07-25T22:53:38Z"}, {"author": "Benjamin Kaduk", "text": "

THEPROBLEMISINTHEROOM

", "time": "2023-07-25T22:53:55Z"}, {"author": "Tim Wicinski", "text": "

As a WG chair we should do more to assist our aDs

", "time": "2023-07-25T22:54:04Z"}, {"author": "Harald Alvestrand", "text": "

https://datatracker.ietf.org/wg/problem/about/

", "time": "2023-07-25T22:54:13Z"}, {"author": "Tim Wicinski", "text": "

Crazy talk i know

", "time": "2023-07-25T22:54:19Z"}, {"author": "Stephen Farrell", "text": "

WG names can be re-used

", "time": "2023-07-25T22:54:38Z"}, {"author": "Michael Richardson", "text": "

Harald Alvestrand said:

\n
\n

The PROBLEM WG name is already used up.

\n
\n

I think that the PROBLEM charter might be just fine, just reboot it.

", "time": "2023-07-25T22:54:50Z"}, {"author": "Pete Resnick", "text": "

Tim Wicinski said:

\n
\n

As a WG chair we should do more to assist our aDs

\n
\n

Agreed, but chairs need to be mentored to do this, presumably by ADs, who aren't spending their time doing that.

", "time": "2023-07-25T22:54:59Z"}, {"author": "Robert Sparks", "text": "

@Stephen Farrell re-using acronyms is not good

", "time": "2023-07-25T22:55:08Z"}, {"author": "John Klensin", "text": "

Process Optimization Going Onward (Principle)

", "time": "2023-07-25T22:55:37Z"}, {"author": "Harald Alvestrand", "text": "

it would be interesting to charter a WG with updating https://www.rfc-editor.org/rfc/rfc3774.html to describe the current state.

", "time": "2023-07-25T22:56:29Z"}, {"author": "Harald Alvestrand", "text": "

figuring out what has changed in 20 years.

", "time": "2023-07-25T22:57:25Z"}, {"author": "Michael Richardson", "text": "

AD sponsor this update.

", "time": "2023-07-25T22:58:51Z"}, {"author": "Stephen Farrell", "text": "

random.org is (or was) run by a colleague of mine - very trustable:-)

", "time": "2023-07-25T23:00:47Z"}, {"author": "Mark Nottingham", "text": "

I don't think we need this level of detail to dispatch, and there are several more slides.

", "time": "2023-07-25T23:02:21Z"}, {"author": "Stephen Farrell", "text": "

how does this differ from MT's this-year thing?

", "time": "2023-07-25T23:02:28Z"}, {"author": "Pete Resnick", "text": "

I am completely ambivalent about the actual solution, but I do wish to see this problem addressed.

", "time": "2023-07-25T23:02:35Z"}, {"author": "Michael Richardson", "text": "

Stephen Farrell said:

\n
\n

how does this differ from MT's this-year thing?

\n
\n

Same thing.

", "time": "2023-07-25T23:02:38Z"}, {"author": "Stephen Farrell", "text": "

seems ok so, document it right then AD sponsor

", "time": "2023-07-25T23:03:03Z"}, {"author": "Harald Alvestrand", "text": "

updating 3797 example code to eliminate the 16-bit dependency would be a Good Thing. (The C code will compute wrong on a modern computer)

", "time": "2023-07-25T23:03:40Z"}, {"author": "Andrew Campling", "text": "

Does the whole idea need to be explained in order to ask the dispatch question?

", "time": "2023-07-25T23:04:18Z"}, {"author": "Michael Richardson", "text": "

Andrew Campling said:

\n
\n

Does the whole idea need to be explained in order to ask the dispatch question?

\n
\n

no, it's enough. Let's go on.

", "time": "2023-07-25T23:04:47Z"}, {"author": "David Schinazi", "text": "

Agreed, can we skip ahead?

", "time": "2023-07-25T23:05:18Z"}, {"author": "Pete Resnick", "text": "

Only insofar as the dispatch answer is increasingly confirmed to be \"no WG needed\".

", "time": "2023-07-25T23:05:35Z"}, {"author": "Stephen Farrell", "text": "

well, I've seen time wasted in worse ways and we are talking publicly verifiable, so someone might benefit from the video someday

", "time": "2023-07-25T23:05:36Z"}, {"author": "Stephen Farrell", "text": "

but yeah, conclusion here's obvious

", "time": "2023-07-25T23:05:48Z"}, {"author": "Pete Resnick", "text": "

How many slides left?

", "time": "2023-07-25T23:06:20Z"}, {"author": "Stephen Farrell", "text": "

H(1)

", "time": "2023-07-25T23:06:26Z"}, {"author": "Pete Resnick", "text": "

If Lars is willing to AD sponsor, let it be done. Otherwise ELEGY quick.

", "time": "2023-07-25T23:07:38Z"}, {"author": "Harald Alvestrand", "text": "

Isn't dispatcing to a WG within the scope of GENDISPATCH???

", "time": "2023-07-25T23:08:58Z"}, {"author": "Pete Resnick", "text": "

@Harald Alvestrand Yep

", "time": "2023-07-25T23:09:11Z"}, {"author": "Michael Richardson", "text": "

@Eric Rescorla I'm surprised you think that there is enough to need a WG. I'd like to know more (on the list, I guess).

", "time": "2023-07-25T23:09:13Z"}, {"author": "Mark Nottingham", "text": "

RE-ELEGY would be fine.

", "time": "2023-07-25T23:09:17Z"}, {"author": "John Klensin", "text": "

@Pete +1. And if a WG, including ELEGYbis, it should come with a tight charter and schedule.

", "time": "2023-07-25T23:09:18Z"}, {"author": "Martin Thomson", "text": "

Having now run the hash chain thing, it is entirely unnecessary

", "time": "2023-07-25T23:09:43Z"}, {"author": "Harald Alvestrand", "text": "

there's always dreams of having a WG spin up, produce output and shut down between two IETFs. Never happens.

", "time": "2023-07-25T23:09:51Z"}, {"author": "Stephen Farrell", "text": "

I think AD sponsored would be enough to get it right but don't object if someone wants a WG

", "time": "2023-07-25T23:10:00Z"}, {"author": "Stephen Farrell", "text": "

@MT what's unnecessary? the doc or the hash chain?

", "time": "2023-07-25T23:10:11Z"}, {"author": "Mark Nottingham", "text": "

Dream the dream, @Harald Alvestrand

", "time": "2023-07-25T23:10:16Z"}, {"author": "Martin Thomson", "text": "

the hash chain

", "time": "2023-07-25T23:10:16Z"}, {"author": "John Klensin", "text": "

That is a case for AD sponsored and being done with it... especially with Martin's comment

", "time": "2023-07-25T23:10:25Z"}, {"author": "Martin Thomson", "text": "

at least for NomCom... there is a challenge period for each round of announcements and that period is long enough for you to arrange for at least a little more entropy

", "time": "2023-07-25T23:10:46Z"}, {"author": "Martin Thomson", "text": "

and the public entropy sources are fine, though it should also be easy to find a small set of people who might be trusted not to collaborate and have them publish hash commitments

", "time": "2023-07-25T23:11:27Z"}, {"author": "Mark Nottingham", "text": "

@Martin Thomson so a process clarification, rather than a cryptographic fix?

", "time": "2023-07-25T23:11:35Z"}, {"author": "Mike Bishop", "text": "

It seems like the hash method would be sufficient by itself, so long as the commitments happen prior to the list being assembled.

", "time": "2023-07-25T23:11:59Z"}, {"author": "Stephen Farrell", "text": "

I've no strong opinion on which good-enough solution gets chosen

", "time": "2023-07-25T23:12:18Z"}, {"author": "Martin Thomson", "text": "

Stephen Farrell said:

\n
\n

random.org is (or was) run by a colleague of mine - very trustable:-)

\n
\n

I assume that your intent was not to undermine the credibility of that resource, but your message might have had the opposite effect :)

", "time": "2023-07-25T23:12:29Z"}, {"author": "Pete Resnick", "text": "

Kathleen Moriarty and some others did something along the lines of what Charles is talking about. (CODEMATCH?)

", "time": "2023-07-25T23:12:29Z"}, {"author": "Michael Richardson", "text": "

Can someone from a few IESGs ago say how code.ietf.org died? This seems to bark up the same tree.

", "time": "2023-07-25T23:12:36Z"}, {"author": "Martin Thomson", "text": "

@Mark Nottingham something like that yes. Though I think that a PRF > sort method is going to be more reliable and easier to implement than 3797

", "time": "2023-07-25T23:13:04Z"}, {"author": "Martin Vigoureux", "text": "

I meant that I don't think it's up to gendispatch to decide for ELEGY

", "time": "2023-07-25T23:13:18Z"}, {"author": "Shuping Peng", "text": "

@ Harald Alvestrand Probably Martin meant rechartering ELEGY is not in the scope of GENDISPATCH?

", "time": "2023-07-25T23:13:23Z"}, {"author": "Pete Resnick", "text": "

Neither is chartering a new WG. We can only recommend for any of these things.

", "time": "2023-07-25T23:14:01Z"}, {"author": "Michael Richardson", "text": "

(code had other goals beyond what Charles is doing)
\nI'm not sure that we need an RFC to make this happen, as much as just some tutorial slides for WG chairs.

", "time": "2023-07-25T23:14:25Z"}, {"author": "John Klensin", "text": "

Are we confident that GitHub and its repositories in their current form are forever?

", "time": "2023-07-25T23:14:45Z"}, {"author": "Martin Thomson", "text": "

@John Klensin why would that be necessary?

", "time": "2023-07-25T23:15:05Z"}, {"author": "Benjamin Kaduk", "text": "

No, which is why we have the secretariat make backups of WG repos and such

", "time": "2023-07-25T23:15:08Z"}, {"author": "Michael Richardson", "text": "

Shuping Peng said:

\n
\n

@ Harald Alvestrand Probably Martin meant rechartering ELEGY is not in the scope of GENDISPATCH?

\n
\n

Well, it's up the the GENDISPATCH AD, right. Lars can re-open it for rechartering... we DID ask repeatedly if anyone had anything they wanted to do...

", "time": "2023-07-25T23:15:13Z"}, {"author": "Martin Thomson", "text": "

\"forever\" is an unreasonably long period of time

", "time": "2023-07-25T23:15:30Z"}, {"author": "Pete Resnick", "text": "

Michael Richardson said:

\n
\n

Well, it's up the the GENDISPATCH AD, right. Lars can re-open it for rechartering... we DID ask repeatedly if anyone had anything they wanted to do...

\n
\n

The ELEGY AD, you meant.

", "time": "2023-07-25T23:16:11Z"}, {"author": "John Klensin", "text": "

Just concerned that this takes us into another chapter of the RSWG discussion on stable references/ links.

", "time": "2023-07-25T23:16:24Z"}, {"author": "Michael Richardson", "text": "

John Klensin said:

\n
\n

Are we confident that GitHub and its repositories in their current form are forever?

\n
\n

s/github/git/ 99% of what he wrote has nothing to do with gitHUB.

", "time": "2023-07-25T23:16:26Z"}, {"author": "Vittorio Bertola", "text": "

What if people wanted to use a different repo/platform than github.com?

", "time": "2023-07-25T23:17:26Z"}, {"author": "John Klensin", "text": "

@Michael: does not change the question of whether the repository and links into it are stable enough

", "time": "2023-07-25T23:17:40Z"}, {"author": "Pete Resnick", "text": "

Suggest bringing this to EODIR and talk about how it relates to code.ietf.org.

", "time": "2023-07-25T23:19:59Z"}, {"author": "Robert Sparks", "text": "

@Vittorio Bertola The ability to link is not limited to links to github

", "time": "2023-07-25T23:20:31Z"}, {"author": "Dhruv Dhody", "text": "

The errata part in Charles's talk is not clear to me.

", "time": "2023-07-25T23:20:41Z"}, {"author": "Andrew Campling", "text": "

@Pete: does this fit with education and outreach?

", "time": "2023-07-25T23:21:05Z"}, {"author": "Dhruv Dhody", "text": "

Would that be the right thing to do with our errata process?

", "time": "2023-07-25T23:21:14Z"}, {"author": "Pete Resnick", "text": "

@Andrew Campling Seems like it.

", "time": "2023-07-25T23:21:27Z"}, {"author": "Michael Richardson", "text": "

Robert Sparks said:

\n
\n

Vittorio Bertola The ability to link is not limited to links to github

\n
\n

openpgp WG uses gitlab instead. Probably many others too.

", "time": "2023-07-25T23:21:31Z"}, {"author": "Martin Vigoureux", "text": "

Pete, right, but ELEGY exists. even if it would maybe need to be rechartered I think we're in a slightly different situation than documents not having a home

", "time": "2023-07-25T23:21:38Z"}, {"author": "Eric Rescorla", "text": "

I concur with MT

", "time": "2023-07-25T23:21:59Z"}, {"author": "Eric Rescorla", "text": "

This is mission accomplished

", "time": "2023-07-25T23:22:09Z"}, {"author": "Stephen Farrell", "text": "

yeah seems right

", "time": "2023-07-25T23:22:12Z"}, {"author": "Dhruv Dhody", "text": "

This was discussed in WGCHAIRS forum but publishing documents is not EODIR job

", "time": "2023-07-25T23:22:15Z"}, {"author": "Jay Daley", "text": "

Somewhat surprisingly, the Wayback Machine does not have an archive of code.ietf.org - does anyone have a pointer to a description?

", "time": "2023-07-25T23:22:59Z"}, {"author": "Dhruv Dhody", "text": "

https://codematch.ietf.org/

", "time": "2023-07-25T23:23:40Z"}, {"author": "Vittorio Bertola", "text": "

Robert Sparks said:

\n
\n

Vittorio Bertola The ability to link is not limited to links to github

\n
\n

Got it, thanks - if it's a generic mechanism to store links, then it makes more sense.

", "time": "2023-07-25T23:23:43Z"}, {"author": "Pete Resnick", "text": "

Bringing it to EODIR did not imply publishing as an RFC; I'm fine with a wikipage.

", "time": "2023-07-25T23:23:46Z"}, {"author": "Eric Rescorla", "text": "

Wikipeage

", "time": "2023-07-25T23:24:06Z"}, {"author": "Rich Salz", "text": "

Martin Thomson said:

\n
\n

Mark Nottingham something like that yes. Though I think that a PRF > sort method is going to be more reliable and easier to implement than 3797

\n
\n

One advantage of 3797 and your current hash-chain thing is that hash/digests are widely understood. I would not like a mechanism that most of the community cannot understand.

", "time": "2023-07-25T23:24:57Z"}, {"author": "Harald Alvestrand", "text": "

The nice thing about an RFC is that it won't change from under you. Individual I-Ds do that all the time.

", "time": "2023-07-25T23:25:11Z"}, {"author": "Harald Alvestrand", "text": "

That is also the disadvantage of an RFC :-)

", "time": "2023-07-25T23:25:28Z"}, {"author": "Michael Richardson", "text": "

Jay Daley said:

\n
\n

Somewhat surprisingly, the Wayback Machine does not have an archive of code.ietf.org - does anyone have a pointer to a description?

\n
\n

It was an effort that Kathleen led. It tried to match ID authors as mentors with coders (students mostly) who wanted to code protocols. It was a kind of \"dating\" service, and it would have resulted in a database mapping RFCs->RunningCode.

", "time": "2023-07-25T23:25:41Z"}, {"author": "Christian Ams\u00fcss", "text": "

The venue text is supporte by tools, but the metadata that create it are placed by the authors in the markdown explicitlyh.

", "time": "2023-07-25T23:25:54Z"}, {"author": "Martin Thomson", "text": "

MNOT!

", "time": "2023-07-25T23:25:56Z"}, {"author": "Martin Thomson", "text": "

MNOT!

", "time": "2023-07-25T23:25:59Z"}, {"author": "Eric Rescorla", "text": "

MNOT Time

", "time": "2023-07-25T23:26:09Z"}, {"author": "Pete Resnick", "text": "

MNOT!

", "time": "2023-07-25T23:26:10Z"}, {"author": "Pete Resnick", "text": "

3.5 minutes!

", "time": "2023-07-25T23:26:21Z"}, {"author": "Andrew Campling", "text": "

Seems reasonable

", "time": "2023-07-25T23:27:46Z"}, {"author": "Michael Richardson", "text": "

Sounds good on MNOT. AD sponsor. I hope all the ADs vote YES.

", "time": "2023-07-25T23:27:49Z"}, {"author": "Martin Thomson", "text": "

seems like we need an IESG working group

", "time": "2023-07-25T23:27:54Z"}, {"author": "Martin Thomson", "text": "

Against AD sponsor. This needs to have community consensus.

", "time": "2023-07-25T23:28:39Z"}, {"author": "Michael Richardson", "text": "

Martin Thomson said:

\n
\n

Against AD sponsor. This needs to have community consensus.

\n
\n

If you want to change the document, a 2.0, then fine, a BOF. The first one would be Informational, because not having IETF control.

", "time": "2023-07-25T23:29:22Z"}, {"author": "Benjamin Kaduk", "text": "

Martin Thomson said:

\n
\n

seems like we need an IESG working group

\n
\n

Some of the tooling already thinks there is an iesg WG, for what it's worth.
\nMaybe that was the old room-reservation system, though...

", "time": "2023-07-25T23:31:33Z"}, {"author": "Michael Richardson", "text": "

I basically did do that two weeks ago. I asked them to actually say DISCUSS rather than COMMENT that seem to actually be blocking.

", "time": "2023-07-25T23:31:47Z"}, {"author": "Michael Richardson", "text": "

What Fluffy said.

", "time": "2023-07-25T23:32:49Z"}]