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

meetecho: speaker?

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

Thanks!

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

Joyce also worked with Bod Braden.

", "time": "2024-07-26T16:42:12Z"}, {"author": "Adrian Farrel", "text": "

We are very sorry. We have an updated slide with Joyce on it.

", "time": "2024-07-26T16:42:30Z"}, {"author": "Ted Hardie", "text": "

Bob Braden, sorry for the typo.

", "time": "2024-07-26T16:42:33Z"}, {"author": "Adrian Farrel", "text": "

There seems to be a Meetecho cache problem that the new slideset did not show

", "time": "2024-07-26T16:43:01Z"}, {"author": "Adrian Farrel", "text": "

This was a chairs error

", "time": "2024-07-26T16:43:21Z"}, {"author": "Alissa Cooper", "text": "

sometimes our mistakes reveal volumes

", "time": "2024-07-26T16:43:28Z"}, {"author": "Andy Malis", "text": "

The slides on the meeting materials page are up to date.

", "time": "2024-07-26T16:50:16Z"}, {"author": "Lars Eggert", "text": "

Could we move the presentation along? I expect we will need time for discussion.

", "time": "2024-07-26T17:09:04Z"}, {"author": "Adrian Farrel", "text": "

We are ahead of schedule

", "time": "2024-07-26T17:09:18Z"}, {"author": "Lars Eggert", "text": "

Still :-)

", "time": "2024-07-26T17:09:36Z"}, {"author": "Deb Cooley", "text": "

crypto primitives (as @nick sullivan suggested)

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

That doesn't actually show much to report participants, because of the camera placement.

", "time": "2024-07-26T17:16:02Z"}, {"author": "Ted Hardie", "text": "

We could see only Martin.

", "time": "2024-07-26T17:16:08Z"}, {"author": "Dave Thaler", "text": "

https://www.rfc-editor.org/about/ISEB/ lists members

", "time": "2024-07-26T17:16:32Z"}, {"author": "Orie Steele", "text": "

Several people stood up.

", "time": "2024-07-26T17:16:32Z"}, {"author": "Adrian Farrel", "text": "

The board members are listed on the web page hanging under the rfc-editor.org site

", "time": "2024-07-26T17:16:34Z"}, {"author": "Dhruv Dhody", "text": "

https://www.rfc-editor.org/about/iseb/

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

@Ted, I am also on the board and stood up.

", "time": "2024-07-26T17:16:44Z"}, {"author": "Adrian Farrel", "text": "

Thanks Dave and Dhruv

", "time": "2024-07-26T17:16:49Z"}, {"author": "John Klensin", "text": "

As am I, but you can't see me standing

", "time": "2024-07-26T17:17:22Z"}, {"author": "Alissa Cooper", "text": "

Agree 100% Jim Fenton

", "time": "2024-07-26T17:21:18Z"}, {"author": "Heather Flanagan", "text": "

That\u2019s a problem with the entire stream structure, and arguably a problem with the tracks. If we want to split out ISE docs, there is an argument to also split out IRTF and IAB docs.

", "time": "2024-07-26T17:22:24Z"}, {"author": "Dave Thaler", "text": "

+1 Heather

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

Is the issue Jim referred to actually more that many non-IETF people do not differentiate between any of the different types of RFCs - eg treat informational the same as standard etc?

", "time": "2024-07-26T17:22:43Z"}, {"author": "Heather Flanagan", "text": "

Which would be fine, but I don\u2019t think we should focus on just one of the streams for this purpose.

", "time": "2024-07-26T17:22:45Z"}, {"author": "Suzanne Woolf", "text": "

Also agree, but the string \"RFC\" is confused/confusing in lots of ways. :-(

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

+1 Heather

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

Glad for the IETF stream to be the one that publishes RFCs

", "time": "2024-07-26T17:23:19Z"}, {"author": "Heather Flanagan", "text": "

I\u2019d be fine with that, too.Though I would then want to have a conversation about whether the other streams have value to the Internet (I think they do) and if so, how their handling will be funded. Which is way out of scope for this meeting, but it\u2019s something we\u2019d need to get to.

", "time": "2024-07-26T17:24:29Z"}, {"author": "David Schinazi", "text": "

Meetecho: it would be great to significantly increase the Offline timeout where someone falls off the queue. We just had someone disappear because they walked to the microphone

", "time": "2024-07-26T17:25:27Z"}, {"author": "Dave Thaler", "text": "

@Heather there's BCP, STD etc numbering series. So by analogy one could just use other numbering series without assigning an RFC # for other streams. Not sure that's what I'd want, just brainstorming.

", "time": "2024-07-26T17:26:37Z"}, {"author": "Michael StJohns", "text": "

Notionally, this isn\u2019t a discussion about naming a standards stream, but about who gets to keep the branding. We have a naming structure for standards, which no one really uses as a reference.

", "time": "2024-07-26T17:26:40Z"}, {"author": "Lorenzo Miniero", "text": "

David: this should be 40s but only for the full client, if you use the onsite tool (also on desktop) there's no timeout

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

meetecho: it would be very useful if the onsite tool (and maybe the full tool) had a way to show meeting materials

", "time": "2024-07-26T17:27:05Z"}, {"author": "Michael StJohns", "text": "

It\u2019s a land grab\u2026..

", "time": "2024-07-26T17:27:08Z"}, {"author": "Lorenzo Miniero", "text": "

Martin: we actually had this in previous version, but removed it after feedback we got from the community (it caused confusion with the slide sharing functionality)

", "time": "2024-07-26T17:28:10Z"}, {"author": "Lorenzo Miniero", "text": "

*versions

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

You will observe that I did not make a statement about whether or not publication of dissent needs an RFC. Though I do hold the view that dissent does not require publication as RFC.

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

Lorenzo: ah, the continuous push and pull... I get that. I don't know how to manage that.

", "time": "2024-07-26T17:29:12Z"}, {"author": "Richard Barnes", "text": "

i would gladly sacrifice the April 1 RFCs if we never had a pretend-standard IS RFC

", "time": "2024-07-26T17:30:01Z"}, {"author": "Richard Barnes", "text": "

maybe the fact that RFCs matter now means that we can't have so much fun with them any more

", "time": "2024-07-26T17:30:35Z"}, {"author": "Martin Thomson", "text": "

I don't think that crypto is the only thing. I'm seeing the same problems in virtually all IS RFCs

", "time": "2024-07-26T17:30:43Z"}, {"author": "Martin Thomson", "text": "

crypto is not special

", "time": "2024-07-26T17:30:51Z"}, {"author": "Richard Barnes", "text": "

(speaking as one of the very select group of authors with two April 1 RFCs)

", "time": "2024-07-26T17:30:52Z"}, {"author": "Heather Flanagan", "text": "

We have the stream/track discussion every few years. Has something changed from the last time that makes this a viable thing to spend time on again? I\u2019d love that, but it just drowned in politics last time (and the times before).

", "time": "2024-07-26T17:31:16Z"}, {"author": "Richard Barnes", "text": "

@Heather the balance of community opinion may have changed

", "time": "2024-07-26T17:31:48Z"}, {"author": "Heather Flanagan", "text": "

@Richard that\u2019s fair

", "time": "2024-07-26T17:31:59Z"}, {"author": "Richard Barnes", "text": "

the idea that anyone not in this room understands the minutiae of types of RFCs is absurd

", "time": "2024-07-26T17:32:35Z"}, {"author": "Heather Flanagan", "text": "

@harald - you\u2019re fired

", "time": "2024-07-26T17:32:46Z"}, {"author": "Heather Flanagan", "text": "

;-)

", "time": "2024-07-26T17:32:49Z"}, {"author": "Robert Sparks", "text": "

@heather - there has been a real shift in the way information can be and is disseminated and much of the community is recognizing that.

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

+1 Harold

", "time": "2024-07-26T17:33:07Z"}, {"author": "Pete Resnick", "text": "

Probably an unpopular suggestion, but perhaps the solution is to simply lose the marketing status of RFC numbers by simply not using them as references anymore. Basically, we could devalue RFC numbers and instead use a stream specific numbering scheme.

", "time": "2024-07-26T17:34:05Z"}, {"author": "Ben S", "text": "

Richard Barnes said:

\n
\n

the idea that anyone not in this room understands the minutiae of types of RFCs is absurd

\n
\n

https://xkcd.com/2501/

", "time": "2024-07-26T17:34:14Z"}, {"author": "Richard Barnes", "text": "

@Pete - I'm 100% with you, just keep RFC for the IETF and move the other streams to other labels :)

", "time": "2024-07-26T17:34:39Z"}, {"author": "Michael StJohns", "text": "

@richard. That\u2019s not what Pete said I think

", "time": "2024-07-26T17:35:04Z"}, {"author": "Pete Resnick", "text": "

@Richard - I'm suggesting everybody loses use of the RFC label.

", "time": "2024-07-26T17:35:17Z"}, {"author": "Richard Barnes", "text": "

@Mike - it was a friendly amendment

", "time": "2024-07-26T17:35:17Z"}, {"author": "Pete Resnick", "text": "

For interesting values of \"friendly\" ;)

", "time": "2024-07-26T17:35:33Z"}, {"author": "Heather Flanagan", "text": "

@Pete there\u2019s a lot of risk in that. It\u2019s actually like the point that people don\u2019t understand the minutiae of RFCs, and yet they have a perception of it. Changing their perception and rebuilding a brand with similar power is _hard_.

", "time": "2024-07-26T17:35:36Z"}, {"author": "Christopher Patton", "text": "

Is there any public information available on the PQ algorithm selection process in China and what algorithms were selected? With a bit of Googling I found https://en.qapp.tech/help/cacr, which suggests that there is not much information yet.

", "time": "2024-07-26T17:36:03Z"}, {"author": "Richard Barnes", "text": "

@Pete - more seriously: throwing the baby out with the bathwater. as Heather says

", "time": "2024-07-26T17:36:03Z"}, {"author": "Pete Resnick", "text": "

I guess my question is whether there's actually an interesting baby in that bathwater.

", "time": "2024-07-26T17:36:41Z"}, {"author": "Alissa Cooper", "text": "

Let's not throw away our strongest brand, let's make that brand stronger

", "time": "2024-07-26T17:36:47Z"}, {"author": "Michael StJohns", "text": "

I\u2019d argue there\u2019s as much of a minutia issue within the IETF stream between standards tr@ck, bops, informational etc at there is between streams.

", "time": "2024-07-26T17:36:59Z"}, {"author": "Heather Flanagan", "text": "

@Pete if there wasn\u2019t, I don\u2019t think we\u2019d be having this conversation.

", "time": "2024-07-26T17:37:08Z"}, {"author": "Stephen Farrell", "text": "

I've no idea what \"new\" thing David means - ISTM proposals are to regularise what's been done with crypto algs

", "time": "2024-07-26T17:37:12Z"}, {"author": "Richard Barnes", "text": "

@MSJ - one step at a time :)

", "time": "2024-07-26T17:37:14Z"}, {"author": "Richard Barnes", "text": "

If you limited RFC to IETF stream, at least you would essentially ensure IETF consensus (vs \"Eliot sez\"), which would be a huge step

", "time": "2024-07-26T17:38:02Z"}, {"author": "Michael StJohns", "text": "

@richard. In that case it\u2019s simply a land grab for the brand.

", "time": "2024-07-26T17:38:04Z"}, {"author": "Stephen Farrell", "text": "

there's clearly a range of different views in the community about the RFC series generally that's informing things here

", "time": "2024-07-26T17:38:07Z"}, {"author": "John Klensin", "text": "

@Pete: there have been several proposals over the years that would have done that by, e.g., assigning STD numbering at Proposed Standard times and then having the standards track IETF documents referred to explicitly by STD and BCP numbers. Whether, to take an extreme case, an Experimental document in the IETF stream is inherently of better quality or authority than something published in the Independent Stream is an open question.

", "time": "2024-07-26T17:38:42Z"}, {"author": "Heather Flanagan", "text": "

@stephen of course?

", "time": "2024-07-26T17:38:50Z"}, {"author": "Richard Barnes", "text": "

@MSJ - I might phrase it as a realignment of the brand to what the market expects

", "time": "2024-07-26T17:38:52Z"}, {"author": "Pete Resnick", "text": "

@Heather - It certainly has value now, but only by dint of us using it for important things. If the IETF started using \"IETF Standard Number\" instead, that would be the valuable thing.

", "time": "2024-07-26T17:39:00Z"}, {"author": "Heather Flanagan", "text": "

@Pete Eventually. Maybe. But I\u2019d argue you\u2019d lose a powerful brand at a time when standards development is facing some globally challenges.

", "time": "2024-07-26T17:39:46Z"}, {"author": "Michael StJohns", "text": "

@pete but may need 10 years to get there.

", "time": "2024-07-26T17:39:49Z"}, {"author": "Stephen Farrell", "text": "

@pete: if we restart with number <thing>001 I want that one:-)

", "time": "2024-07-26T17:39:51Z"}, {"author": "Chunchi Liu", "text": "

Christopher Patton said:

\n
\n

Is there any public information available on the PQ algorithm selection process in China and what algorithms were selected? With a bit of Googling I found https://en.qapp.tech/help/cacr, which suggests that there is not much information yet.

\n
\n

Honestly this is the part where could be improved. If the IETF/ISE would like more openness in the process we are happy to take the message back.

", "time": "2024-07-26T17:40:15Z"}, {"author": "Jay Daley", "text": "

@Richard - I agree, the proposal is a realignment to the brand not a rebrand.

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

Once upon a time, there was actually a discussion as to whether IETF \"standards\" should be published as RFCs, instead re-inventing the idea of IENs or a new series for that purpose. Every time we have this discussion, I wonder if the wrong decision was made.

", "time": "2024-07-26T17:42:07Z"}, {"author": "Michael StJohns", "text": "

@jay - it would be a rebrand to the non ietf streams.

", "time": "2024-07-26T17:42:07Z"}, {"author": "Heather Flanagan", "text": "

A re-brand to the non IETF streams and a marketing opportunity to strengthen the IETF stream itself.

", "time": "2024-07-26T17:42:44Z"}, {"author": "Richard Barnes", "text": "

we could call it the Loser Stream :sunglasses:

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

@John, that's a great point. Do we need to separate out consensus standards from Requests For Comments.

", "time": "2024-07-26T17:43:47Z"}, {"author": "Nick Sullivan", "text": "

9999 seems like an appropriate number for a \u201clast RFC\u201d

", "time": "2024-07-26T17:43:48Z"}, {"author": "Richard Barnes", "text": "

avoids the RFC Y2K problem

", "time": "2024-07-26T17:44:16Z"}, {"author": "Heather Flanagan", "text": "

But he said there should be more! (Sarcasm was appreciated, but still, I can\u2019t help but remember the informal classification in an older IESG of \u201cHBU\u201d = harmless but useless. There were so many, and that doesn\u2019t do anything to help the reputation of the series.)

", "time": "2024-07-26T17:45:20Z"}, {"author": "Michael StJohns", "text": "

The RFC series numbering is possibly the worst way of tagging standards we could use. Sadly, ansi, iso and others have a number8ng label system that are more logical and consistent than simply assigning a sequence number. Perhaps we stop having the RFC brand discussion and start having a non sexy library science discussion

", "time": "2024-07-26T17:45:47Z"}, {"author": "Christopher Patton", "text": "

Chunchi Liu said:

\n
\n

Christopher Patton said:

\n
\n

Is there any public information available on the PQ algorithm selection process in China and what algorithms were selected? With a bit of Googling I found https://en.qapp.tech/help/cacr, which suggests that there is not much information yet.

\n
\n

Honestly this is the part where could be improved. If the IETF/ISE would like more openness in the process we are happy to take the message back.

\n
\n

Speaking as an individual, not on behalf of any organization or WG: I think knowing what algorithms were selected would be a necessary first step. Studying them will help decide whether they should be deployed.

", "time": "2024-07-26T17:46:22Z"}, {"author": "Jay Daley", "text": "

@msj point taken

", "time": "2024-07-26T17:47:15Z"}, {"author": "Pete Resnick", "text": "

I always worry when I agree with MSJ, but yeah. If what we're arguing about is marketing and our value depends on that marketing, that's probably not a good thing. :(

", "time": "2024-07-26T17:47:23Z"}, {"author": "Ted Hardie", "text": "

Martin is correct that it doesn't need to be hosted at the IETF or part of the RFC series to be a dissenting view. Including it in the RFC series is a way to reinforce that the people who have the dissenting view are still part of the same community and in the same conversation. That's not needed in many cases, which is why documenting the processing and considering whether it needs to narrow is variable, but I think there are cases where it may still be needed. Having one that is rarely used is more valuable than one that is gone, at least to me.

", "time": "2024-07-26T17:47:54Z"}, {"author": "Michael StJohns", "text": "

@pete - Hah!

", "time": "2024-07-26T17:47:57Z"}, {"author": "Stephen Farrell", "text": "

How many ISE stream RFCs are really \"lost the standards game\" thuings? I didn't think it was many

", "time": "2024-07-26T17:48:02Z"}, {"author": "John Klensin", "text": "

Or, Mike, we take the mechanism we already have, allocate STD numbers at Proposed, then then shift further to referencing them (possibly augmenting them with ISO's date convention) rather than using the RFC numbers.

", "time": "2024-07-26T17:48:10Z"}, {"author": "Eliot Lear", "text": "

@Stephen VERY few, but there are some.

", "time": "2024-07-26T17:48:23Z"}, {"author": "Ted Hardie", "text": "

(above variable should be valuable, sorry)

", "time": "2024-07-26T17:48:45Z"}, {"author": "Stephen Farrell", "text": "

that's what I thought, and further think that weakens @MT's argument

", "time": "2024-07-26T17:48:45Z"}, {"author": "Adrian Farrel", "text": "

@stephen it is a small percentage of a small number

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

Ted: I think that we're 100% in agreement here, the disagreement is in the degree

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

we could stop using RFC numbers and refer to what we publish by ISSN....

", "time": "2024-07-26T17:49:24Z"}, {"author": "Stephen Farrell", "text": "

having a non-scaleable ISE is a good feature

", "time": "2024-07-26T17:49:26Z"}, {"author": "Martin Thomson", "text": "

Stephen: I see a lot of failed proposals in the IS RFCs and pending queue

", "time": "2024-07-26T17:49:58Z"}, {"author": "Jim Fenton", "text": "

Of course having the ISE not well known contributes to the confusion by external parties about what has IETF consensus and what doesn't.

", "time": "2024-07-26T17:50:14Z"}, {"author": "Martin Thomson", "text": "

You might say that GNS is not a failed proposal.

", "time": "2024-07-26T17:50:21Z"}, {"author": "Michael StJohns", "text": "

Do we remove AD sponsored documents from the IETF stream?

", "time": "2024-07-26T17:50:26Z"}, {"author": "Stephen Farrell", "text": "

so there's a divergence in views of the underlying situation

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

MSJ: AD sponsorship is a lightweight process, but it still requires IETF consensus

", "time": "2024-07-26T17:50:47Z"}, {"author": "Michael StJohns", "text": "

Since \u201cbroad consensus\u201d?

", "time": "2024-07-26T17:50:50Z"}, {"author": "Adrian Farrel", "text": "

AD-sponsored goes for IETF last call

", "time": "2024-07-26T17:50:50Z"}, {"author": "Ted Hardie", "text": "

(For some reason this discussion is making me remember various government's usage of different colored paper to distinguish the stages of a proposal. Symptom of an untidy mind, no doubt).

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

What I think Richard is saying would be much more helpful if every document published in the IETF stream really had broad community involvement, review, and consensus approval. I suggest that has not been true for many years but ought to be a separate problem.

", "time": "2024-07-26T17:51:50Z"}, {"author": "Martin Thomson", "text": "

+1 to Richard about government capability

", "time": "2024-07-26T17:51:50Z"}, {"author": "Michael StJohns", "text": "

Last call != broad consensus - imo.

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

An RFC is a stable reference and that is a reason why people may require an RFC versus a publication on their own website or blog, etc.

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

Russ had the valve on his slides.

", "time": "2024-07-26T17:52:30Z"}, {"author": "Chunchi Liu", "text": "

@Christopher Patton technically I think the PQ algorithm design progress is not close to converge to disclose the results

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

What is or isn't stable as a reference is highly contentious already. You don't need an RFC to meet the bar.

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

A blog or company whitepaper can't be used as a reference in many publications, including in academia in a review of literature for instance.

", "time": "2024-07-26T17:54:32Z"}, {"author": "Martin Thomson", "text": "

GitHub provides all of the things that Bron lists, including a community-provided editorial service

", "time": "2024-07-26T17:55:56Z"}, {"author": "Richard Barnes", "text": "

Big +1 to Bron

", "time": "2024-07-26T17:56:24Z"}, {"author": "Alexis Rossi", "text": "

Github does not provide the archival benefits Bron mentioned

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

Including archival that surpasses the IETF series

", "time": "2024-07-26T17:56:33Z"}, {"author": "Robert Wilton", "text": "

+1 to Bron

", "time": "2024-07-26T17:56:38Z"}, {"author": "Stephen Farrell", "text": "

github hasn't been around long enough IMO and depending on a commercial entity like that is not what we'd want I think

", "time": "2024-07-26T17:56:39Z"}, {"author": "Jim Fenton", "text": "

There's Internet Archive as well.

", "time": "2024-07-26T17:56:46Z"}, {"author": "John Klensin", "text": "

@Martin, but not clear, stable, carefully edited documents.

", "time": "2024-07-26T17:56:51Z"}, {"author": "Martin Thomson", "text": "

https://archiveprogram.github.com/arctic-vault/

", "time": "2024-07-26T17:56:54Z"}, {"author": "Martin Thomson", "text": "

JCK: maybe not consistency with the RFC series, but that should not be a goal

", "time": "2024-07-26T17:57:19Z"}, {"author": "Stephen Farrell", "text": "

@MT perhaps I'm more skeptical of company promises

", "time": "2024-07-26T17:57:23Z"}, {"author": "Dhruv Dhody", "text": "

@Bron - just a clarification, would you extend that to other streams like IAB and IRTF or it is specific to ISE only

", "time": "2024-07-26T17:57:31Z"}, {"author": "Martin Thomson", "text": "

FWIW, for cryptography: eprint.iacr.org

", "time": "2024-07-26T17:57:31Z"}, {"author": "Alexis Rossi", "text": "

Thr arctic vault only contains snapshots

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

Github wouldn't be accepted as a reference in a review of literature. +1 to Stephen on a corporate policy.

", "time": "2024-07-26T17:57:44Z"}, {"author": "Martin Thomson", "text": "

Alexis: so does the RFC series

", "time": "2024-07-26T17:57:56Z"}, {"author": "Alexis Rossi", "text": "

You also have zero control over what github snapshots or when

", "time": "2024-07-26T17:58:20Z"}, {"author": "Martin Thomson", "text": "

Look, I'm not saying that GitHub necessarily meets the bar, only that the bar is arbitrary

", "time": "2024-07-26T17:58:22Z"}, {"author": "Stephen Farrell", "text": "

preprints (incl. iacr's) are good places for reference docs yes

", "time": "2024-07-26T17:58:29Z"}, {"author": "John Klensin", "text": "

Most of the arguments I've heard for getting the Independent Stream out of the Series are also argument for getting the IAB and IRTF streams out .. and probably moving Editorial Stream documents somewhere else too. Is that what is intended?

", "time": "2024-07-26T17:59:00Z"}, {"author": "Jay Daley", "text": "

@stephen if the non-scalability is to stay, then my argument is that this effectively constrains the IS to a private stream for IETF insiders. This may be exactly what is intended (e.g. the relief valve comments) but I think that should be explicitly acknowledged.

", "time": "2024-07-26T17:59:49Z"}, {"author": "Michael StJohns", "text": "

Re stable references - sounds like a job for the RSWG to write a document defining what are acceptable references archives etc. \u2026

", "time": "2024-07-26T17:59:50Z"}, {"author": "John Klensin", "text": "

I wasn't talking so much about consistency with the RFC series but the tension between living documents and something that can be referenced in a stable way and as a stable object

", "time": "2024-07-26T18:00:20Z"}, {"author": "Pete Resnick", "text": "

If we make RFC numbers IETF-only, how long will it take for the brand to actually be usefully shifted? We've got about 10K referenceable documents that aren't going away.

", "time": "2024-07-26T18:00:26Z"}, {"author": "Jim Fenton", "text": "

@John Klensin The difference I see is that IAB documents don't usually look like protocol standards. I'm less clear on IRTF.

", "time": "2024-07-26T18:00:58Z"}, {"author": "Michael StJohns", "text": "

@jim - review most of the cfrg documents. Many are a standards in all but name.

", "time": "2024-07-26T18:02:03Z"}, {"author": "Mark Nottingham", "text": "

https://rfc.fyi/?stream=independent

", "time": "2024-07-26T18:02:11Z"}, {"author": "Andrew Campling", "text": "

Escape valve - also material which doesn\u2019t fit neatly into a working group but is nevertheless relevant to topics covered by the IETF?

", "time": "2024-07-26T18:03:11Z"}, {"author": "Richard Barnes", "text": "

@Andrew that's what AD sponsorship is for

", "time": "2024-07-26T18:03:38Z"}, {"author": "Richard Barnes", "text": "

or chartering new WGs

", "time": "2024-07-26T18:03:46Z"}, {"author": "Adrian Farrel", "text": "

Maybe John Klensin would note that we don't have enough appeals

", "time": "2024-07-26T18:03:49Z"}, {"author": "Christopher Patton", "text": "

Chunchi Liu said:

\n
\n

Christopher Patton technically I think the PQ algorithm design progress is not close to converge to disclose the results

\n
\n

I see. One benefit of the NIST competition's relative openness is that we've been able to follow along and prepare for what's coming.

", "time": "2024-07-26T18:03:51Z"}, {"author": "John Klensin", "text": "

@Jim One of the regular discussions within the ISE editorial process is around \"if this document, as written, clearly enough not an IETF standard?\". If that confusion is an issue, maybe the message is that we should get more clear about the distinction in the text of documents. However, I think the IETF often needs to look more closely at whether particular Experimental and Informational documents in that stream are adequately clear about that too.

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

Should we be improving efforts to move appropriate documents to full standards to have those stand out?

", "time": "2024-07-26T18:04:00Z"}, {"author": "Robert Wilton", "text": "

@Michael, regarding CFRG being standards, perhaps CFRG should be part of IETF rather than IRTF?

", "time": "2024-07-26T18:04:02Z"}, {"author": "Martin Thomson", "text": "

full standards like STD 25 ?

", "time": "2024-07-26T18:04:50Z"}, {"author": "John Klensin", "text": "

@Adrian, I have, of course, made that suggestion frequently :-(

", "time": "2024-07-26T18:04:51Z"}, {"author": "Stephen Farrell", "text": "

CFRG is a special case for IRTF but this is not an IRTF session

", "time": "2024-07-26T18:04:54Z"}, {"author": "Michael StJohns", "text": "

@andrew, also paths not taken and contrarian views on a topic or standard

", "time": "2024-07-26T18:05:01Z"}, {"author": "Andrew Campling", "text": "

@MSJ +1

", "time": "2024-07-26T18:05:27Z"}, {"author": "Harald Alvestrand", "text": "

One of the previous rounds of this discussion floated the idea of promoting the STD label as a distinguishing feature. Did not result in a rush to push the docs that the Internet actually runs on to STD.

", "time": "2024-07-26T18:05:28Z"}, {"author": "Michael StJohns", "text": "

@robert.., yeah, ve lost that argument at least three times.

", "time": "2024-07-26T18:05:43Z"}, {"author": "Stephen Farrell", "text": "

I guess AES was Belgian

", "time": "2024-07-26T18:06:12Z"}, {"author": "Richard Barnes", "text": "

lol @sftcd i was thinking the same thing

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

X25519 comes from djbistan

", "time": "2024-07-26T18:06:32Z"}, {"author": "Robert Wilton", "text": "

@Kathleen, I would like to retire \"Proposed Standard\" so that IETF only published full IETF standards (but keeping today's publication bar for PS). Hence all IETF RFCs would be able to use STDs numbers, and which would start to differentiate the IETF stream from the other streams. It would also potentially allow for more stable references.

", "time": "2024-07-26T18:06:40Z"}, {"author": "Christopher Patton", "text": "

I think national crypto should be considered, but at the moment it doesn't seem like the Chinese PQ progress can be reviewed by most in our community?

", "time": "2024-07-26T18:06:51Z"}, {"author": "John Klensin", "text": "

@Harald, but as I pointed out earlier, also did not result in assigning STD numbers to Proposed Standards, which might have made the label more useful.

", "time": "2024-07-26T18:07:09Z"}, {"author": "Pete Resnick", "text": "

@Martin - If the STD number was assigned at Proposed rather than Full as JCK indicated, I think we'd probably have a useful brand and could dump the whole reliance on RFC numbers being magical.

", "time": "2024-07-26T18:07:23Z"}, {"author": "Martin Thomson", "text": "

Getting the IETF to agree to publish cryptographic algorithms that it doesn't back could be done, but it is not a good use of IETF time.

", "time": "2024-07-26T18:07:40Z"}, {"author": "Deb Cooley", "text": "

CFRG doesn't do that!

", "time": "2024-07-26T18:07:48Z"}, {"author": "Harald Alvestrand", "text": "

I love the transctiption as \"non-wildly-reviewed\"....

", "time": "2024-07-26T18:07:48Z"}, {"author": "Richard Barnes", "text": "

@Deb - CFRG did X25519 and Ed25519

", "time": "2024-07-26T18:08:11Z"}, {"author": "Stephen Farrell", "text": "

is this a good room of people for discussing brand value? :-)

", "time": "2024-07-26T18:08:15Z"}, {"author": "Richard Barnes", "text": "

probably the most widely-deployed non-NIST algorithms

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

Pete but a proposed standard is not a standard !

", "time": "2024-07-26T18:08:24Z"}, {"author": "Pete Resnick", "text": "

I always wildly review my documents.

", "time": "2024-07-26T18:08:25Z"}, {"author": "Deb Cooley", "text": "

but not National Crypto

", "time": "2024-07-26T18:08:33Z"}, {"author": "Jim Fenton", "text": "

Where do we go to read the transcript once it has scrolled off the screen?

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

@Stepehn I did suggest at the mic that it would be useful to consult some marketing people on this \u2026..

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

@Martin - I'm up for more closely approximating reality.

", "time": "2024-07-26T18:09:03Z"}, {"author": "Deb Cooley", "text": "

@JimFenton there is a link in the meeting agenda to see the Zulip stream

", "time": "2024-07-26T18:09:28Z"}, {"author": "Colin Perkins", "text": "

CFRG doesn't produce standards \u2013 CFRG develops algorithms that the IETF might decide should be part of an IETF standard

", "time": "2024-07-26T18:09:45Z"}, {"author": "Pete Resnick", "text": "

I kinda like Rob's proposal on that score.

", "time": "2024-07-26T18:09:45Z"}, {"author": "Stephen Farrell", "text": "

@andrew: like many here I think I know better than marketing people:-) (but don't)

", "time": "2024-07-26T18:09:48Z"}, {"author": "John Klensin", "text": "

@Robert: unless you think Experimental specs for which the IETF consensus is \"good idea to publish and might be a good idea\" are as good as Internet Standards, then assigning STD numbers to all IETF Stream documents would not be a really hot idea.

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

If we are worried about branding, the ability to keep up what should become a full standard, STD, or what should be deprecated and have a STD number removed would require management. That may be a worthwhile effort.

", "time": "2024-07-26T18:10:05Z"}, {"author": "Lars Eggert", "text": "

This sounds a lot like the ISE is running an ad hoc semi-consensus process here?

", "time": "2024-07-26T18:10:07Z"}, {"author": "Jim Fenton", "text": "

@Deb I didn't mean the Zulip Stream (I'm using Zulip now), I wanted the transcript on the right side of the right screen

", "time": "2024-07-26T18:10:50Z"}, {"author": "Michael StJohns", "text": "

@lars. Elliot decides. How he decides is as he describes. That has been the case for all of the ISE going back to prehistory.

", "time": "2024-07-26T18:11:21Z"}, {"author": "Glenn Deen", "text": "

RFC is not a trademark, anyone can use it

", "time": "2024-07-26T18:11:54Z"}, {"author": "John Klensin", "text": "

Probably worth remembering that the RFC series predates the IETF by many years.

", "time": "2024-07-26T18:12:07Z"}, {"author": "Paul Hoffman", "text": "

https://datatracker.ietf.org/stream/ise/

", "time": "2024-07-26T18:12:14Z"}, {"author": "Robert Wilton", "text": "

@John, I would have 3 types of doc published by IETF:

\n\n

All PS docs become STD docs because that is what they really are.

", "time": "2024-07-26T18:12:24Z"}, {"author": "Stephen Farrell", "text": "

I do remember disliking what became RFC7974 (a lot:-)

", "time": "2024-07-26T18:12:38Z"}, {"author": "Glenn Deen", "text": "

RFC Series is also not a trademarked item

", "time": "2024-07-26T18:13:00Z"}, {"author": "Andrew Campling", "text": "

@Lars In my view that ambiguity /flexibility is a feature not a bug

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

@Robert I'm wondering if STD is an additional label that can be added or removed.

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

*could be

", "time": "2024-07-26T18:13:31Z"}, {"author": "Michael StJohns", "text": "

@kathleen - I believe it is. But requires an IESG action.

", "time": "2024-07-26T18:14:02Z"}, {"author": "Andrew Campling", "text": "

@Robert BCPs are pretty important too

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

@Mike Can it be removed?

", "time": "2024-07-26T18:14:16Z"}, {"author": "Adrian Farrel", "text": "

Queue is locked

", "time": "2024-07-26T18:14:22Z"}, {"author": "Lars Eggert", "text": "

I'm not saying it shouldn't be the ISE who decides, I wonder if creating a semi-public consensus finding activity here (with CC to the IAB) is making this even more indistinguishable from an IETF activity

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

I think it requires a new document now, doesn't it?

", "time": "2024-07-26T18:14:31Z"}, {"author": "Robert Wilton", "text": "

@Kathleen, yes, I think that STD # should be used as it is now. E.g., you could allocate a single STD number to BGP and all of its core extensions. I.e., a single STD number can represent many RFCs that can change over time.

", "time": "2024-07-26T18:14:43Z"}, {"author": "Michael StJohns", "text": "

I believe so, but I can\u2019t th8nk of an example\u2026 usual path is to historic rather than revoking standards status.

", "time": "2024-07-26T18:14:58Z"}, {"author": "Pete Resnick", "text": "

@Kathleen - Nope, it can be removed without a new doc.

", "time": "2024-07-26T18:15:04Z"}, {"author": "Pete Resnick", "text": "

(Don't know that it's ever been done.)

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

Thanks, Pete

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

Right, we're not good about adding it when it should be there either.

", "time": "2024-07-26T18:15:49Z"}, {"author": "Colin Perkins", "text": "

RFCs per stream:

\n

6892 IETF
\n1895 Legacy
\n 420 Independent
\n 129 IAB
\n 115 IRTF
\n 0 Editorial

\n

(as of a couple of months back)

", "time": "2024-07-26T18:16:17Z"}, {"author": "Martin Thomson", "text": "

A lot of the Internet runs on code or systems that are not documented anywhere but in the code that they run. A lot runs on code that is not documented in RFCs. Why do we feel like we need to provide people with RFC editing services, which are expensive, when they don't have IETF consensus?

", "time": "2024-07-26T18:16:25Z"}, {"author": "Robert Wilton", "text": "

@Andrew, yes, I should have included BCP, in the list but I would like us to basically stop publishing internal IETF process docs as BCPs, it convolutes internal facing docs vs external facing docs.

", "time": "2024-07-26T18:16:30Z"}, {"author": "Adrian Farrel", "text": "

Letting people know about upcoming work, and soliciting reviews seems good. There is already a pseudo-consensus bar of \"the preponderance of reviews\". How the ISE interprets that might be dependent on IAB guidance and individual ISEs

", "time": "2024-07-26T18:16:39Z"}, {"author": "John Klensin", "text": "

@Robert, as others have sort of pointed out, unless we can change the references and how we and others talk about things, having STD and BCP numbers assigned to some documents but leaving info and experimental without any additional labels is, IMO, fairly well demonstrated to not do the job you are, I think, looking for.

", "time": "2024-07-26T18:16:54Z"}, {"author": "Jay Daley", "text": "

If somebody wants to \u2018misuse\u2019 a non-STD RFC by claiming it is a standard, then the STD label has limited utility in mitigating that. For me the question is not how to stop that misuse but what level of misuse can be tolerated?

", "time": "2024-07-26T18:16:54Z"}, {"author": "Kesara Nanayakkara Rathnayake", "text": "

Jim Fenton said:

\n
\n

@Deb I didn't mean the Zulip Stream (I'm using Zulip now), I wanted the transcript on the right side of the right screen

\n
\n

@Jim Fenton You should be able to get the transcripts by going to \"Session Recordings\" in datatracker agenda after session is over.

", "time": "2024-07-26T18:17:08Z"}, {"author": "Adrian Farrel", "text": "

@Jay. Surely everyone outside the IETF says \"standard\" to refer to any IETF RFC

", "time": "2024-07-26T18:17:25Z"}, {"author": "Chunchi Liu", "text": "

Christopher Patton said:

\n
\n

I think national crypto should be considered, but at the moment it doesn't seem like the Chinese PQ progress can be reviewed by most in our community?

\n
\n

If IETF/ISE would like more reviews and procedural transparency improvements to China national crypto design process, we can try to improve that. But if all public reviews (or other procedural requirements) are done and still no publication, that does not look so fair...

", "time": "2024-07-26T18:17:47Z"}, {"author": "Ted Hardie", "text": "

I've removed myself from queue

", "time": "2024-07-26T18:17:53Z"}, {"author": "Mark Nottingham", "text": "

Thanks Ted

", "time": "2024-07-26T18:18:58Z"}, {"author": "Robert Wilton", "text": "

@John, but I think that there should be a clear distinction as to what is \"a real standard\" (or BCP) vs what an Info or Exp doc. Having said that, I think that some docs that we publish as Info today (e.g., architecture/framework docs) should be published as STDs, or some other category. I.e., Info docs should have IETF consensus, but be a lower bar.

", "time": "2024-07-26T18:19:51Z"}, {"author": "Jay Daley", "text": "

@adrian I think there is a set of implementers, outside of the IETF, to whom the statuses do matter because it is necessary to define the scope of their effort

", "time": "2024-07-26T18:20:05Z"}, {"author": "Michael StJohns", "text": "

Re national crypto - I don\u2019t actually expect the ise to validate it, but one of the uses for the RFC system has been for co publication of documents that might not be easily available That\u2019s less of a problem these days but I wouldn\u2019t eliminate it as a possibility.

", "time": "2024-07-26T18:20:33Z"}, {"author": "Adrian Farrel", "text": "

Heads up Tommy - we're about to call on you

", "time": "2024-07-26T18:20:44Z"}, {"author": "Robert Wilton", "text": "

+1 to Bron, many folks don't understand the nuances of the different doc categories.

", "time": "2024-07-26T18:20:58Z"}, {"author": "Ted Hardie", "text": "

We're running close on time, but I think we're starting the conversation from a use case (the cryptography work) rather than starting from a process. If we look at the process and don't like it, we can work together to update it (or conclude it). But looking at the recent data does include a narrow set of ones that I think do represent contributions to the conversation (the URN docs, the oblivious http work, and the centralization work).

", "time": "2024-07-26T18:21:01Z"}, {"author": "bengo", "text": "

With regard to the \u201cRFC\u201d brand\u2026. Pretty sure the vast majority of internet devs who have even seen it literally just think it is a \u201crequest for comments\u201d and best effort so far, and NOT a product of IETF consensus (which is a governance idiosyncrasy that many RFC readers don\u2019t know or care about)

", "time": "2024-07-26T18:21:31Z"}, {"author": "Robert Wilton", "text": "

Good luck Tommy ;-)

", "time": "2024-07-26T18:22:15Z"}, {"author": "Ted Hardie", "text": "

Work on the process so it yields those, and then I think we can discuss on how to mark that these are in conversation with the RFC series. That branding discussion seems to me to be logically something that occurs after that work is done.

", "time": "2024-07-26T18:22:17Z"}, {"author": "Stephen Farrell", "text": "

summary: #include <rfcplusplusbof> ;-)

", "time": "2024-07-26T18:22:40Z"}, {"author": "Michael StJohns", "text": "

@stephen +1

", "time": "2024-07-26T18:23:09Z"}, {"author": "Orie Steele", "text": "

lets keep that memory safe please

", "time": "2024-07-26T18:23:42Z"}, {"author": "John Klensin", "text": "

@Robert, then, unless we are going to move most standards track documents to either Internet Standards or deprecated/ (Historic?), we should attach those numbers earlier in the process, and then create a new numbering series (\"SSTD\" for \"substandard\"?) for IETF Stream info or experimental docs that look like technical specifications.

", "time": "2024-07-26T18:23:50Z"}, {"author": "Robert Wilton", "text": "

@John, yes I would propose that all existing PS RFCs become STDs and have STDs numbers allocated (perhaps proactively, perhaps reactively as new RFCs are published). The procedure of how to do this can obviously be worked out.

", "time": "2024-07-26T18:25:26Z"}, {"author": "Heather Flanagan", "text": "

Heh. MeetEcho has the transcript with Russ as Pete and Pete as Russ.

", "time": "2024-07-26T18:26:14Z"}, {"author": "Andrew Campling", "text": "

This feels like an area to move slowly and carefully, change with caution

", "time": "2024-07-26T18:26:15Z"}, {"author": "Lorenzo Miniero", "text": "

Heather: there's a real person transcribing in this session

", "time": "2024-07-26T18:26:46Z"}, {"author": "Robert Wilton", "text": "

But I don't agree that PS are sub-standards, otherwise surely IETF has failed in its job since it has seemingly published less than 100 standards over its entire existence.

", "time": "2024-07-26T18:26:49Z"}, {"author": "John Klensin", "text": "

@Robert, the \"substandard\" crack was intended to apply to IETF Stream experimental and informational documents that could be mistaken for protocol or best practice specs.

", "time": "2024-07-26T18:28:16Z"}, {"author": "Stephen Farrell", "text": "

On a very important point I prefer spelling out ISE over \"ICE\" :-)

", "time": "2024-07-26T18:28:21Z"}, {"author": "Robert Wilton", "text": "

@John, ah, okay. Then I agree that those are not real standards.

", "time": "2024-07-26T18:28:55Z"}, {"author": "John Klensin", "text": "

@Adrian: would you suggest the same process for IETF Stream documents, especially the Informational and Experimental ones?

", "time": "2024-07-26T18:29:20Z"}, {"author": "Suresh Krishnan", "text": "

I did go through all ISE documents at some point in 2018 and categorized them

", "time": "2024-07-26T18:29:47Z"}, {"author": "Adrian Farrel", "text": "

:-) Yes, but in another meeting

", "time": "2024-07-26T18:29:49Z"}, {"author": "Suresh Krishnan", "text": "

I\u2019ll dig up the info and will share.

", "time": "2024-07-26T18:29:58Z"}, {"author": "Alexey Melnikov", "text": "

Thank you Suresh!

", "time": "2024-07-26T18:30:17Z"}]