[{"author": "Samuel Weiler", "text": "

I see a bunch of the usual suspects in queue....

", "time": "2023-11-09T12:08:31Z"}, {"author": "David Schinazi", "text": "

I plead not guilty

", "time": "2023-11-09T12:08:57Z"}, {"author": "Anthony Somerset", "text": "

replace expired with some variant of \"old\" ?

", "time": "2023-11-09T12:09:45Z"}, {"author": "Anthony Somerset", "text": "

perhaps stale

", "time": "2023-11-09T12:09:53Z"}, {"author": "Cullen Jennings", "text": "

Perhaps we could just have the date it was written , oh wait

", "time": "2023-11-09T12:10:08Z"}, {"author": "Mark Nottingham", "text": "

1/6th of the participants are in queue currently.

", "time": "2023-11-09T12:10:39Z"}, {"author": "Samuel Weiler", "text": "

And Martin suggested that this is the \"easy\" one...

", "time": "2023-11-09T12:10:41Z"}, {"author": "Richard Barnes", "text": "

the internet never forgets!

", "time": "2023-11-09T12:11:03Z"}, {"author": "Anthony Somerset", "text": "

Mark Nottingham said:

\n
\n

1/6th of the participants are in queue currently.

\n
\n

the party is obviously here!

", "time": "2023-11-09T12:11:05Z"}, {"author": "Jonathan Lennox", "text": "

I remember a situation where the expiration date was confusing for a newcomer in the opposite direction -- they cited (or perhaps even implementred?) a version of a draft that had been superseded several times, on the grounds that it hadn't expired yet.

", "time": "2023-11-09T12:11:22Z"}, {"author": "Mark Nottingham", "text": "

This is going to need some active queue management...

", "time": "2023-11-09T12:13:23Z"}, {"author": "Julian Reschke", "text": "

3FUN

", "time": "2023-11-09T12:13:54Z"}, {"author": "Shuping Peng", "text": "

Locked, thank you, @Mark

", "time": "2023-11-09T12:14:36Z"}, {"author": "John Klensin", "text": "

In case it isn't obvious, agree with Ted

", "time": "2023-11-09T12:15:06Z"}, {"author": "Richard Barnes", "text": "

+1 to mini WG

", "time": "2023-11-09T12:15:18Z"}, {"author": "Eliot Lear", "text": "

I just want to note that this draft would impact all streams. I'm not convinced that this approach is correct for independent submissions.

", "time": "2023-11-09T12:16:03Z"}, {"author": "Mark Nottingham", "text": "

Eliot: An I-D in the independent stream is under control of the ISE, they can mark an abandoned draft appropriately. All other drats are not in the independent stream.

", "time": "2023-11-09T12:17:39Z"}, {"author": "Eliot Lear", "text": "

Well, that's not true, Mark. Drafts go into the IAB stream, IETF stream, IRTF stream, and no stream.

", "time": "2023-11-09T12:18:39Z"}, {"author": "Robert Sparks", "text": "

Mark - the datatracker does very little with expiry other than \"not showing the txt page easily\" which I almost have enough support for to make different.

", "time": "2023-11-09T12:18:48Z"}, {"author": "Jari Arkko", "text": "

Can't be bothered to join the long queue, but I think we should do away with expiry dates. However, as Robert said... there are other things to do if we go ahead with this. For instance, I'd like the data tracker to display relevant material when I search something or look at the documents for a WG. It is already a problem to some extent, e.g. DHC WG data tracker web page shows 73 expired IDs dating back to 1995, and does so before even listing the most recent RFCs published from the WG :-)

", "time": "2023-11-09T12:20:00Z"}, {"author": "Robert Sparks", "text": "

My point about the archive (vs the repository) is that the archive is _massive_ - even if you filter it only to a single group.

", "time": "2023-11-09T12:20:06Z"}, {"author": "Pete Resnick", "text": "

Auto-expire is a bummer in some cases. If marking DEAD in the tracker auto-tombstoned, I wouldn't mind this at all.

", "time": "2023-11-09T12:20:37Z"}, {"author": "Pete Resnick", "text": "

(Or some other mechanism where I could easily tombstone.)

", "time": "2023-11-09T12:21:00Z"}, {"author": "Eric Rescorla", "text": "

60 years

", "time": "2023-11-09T12:21:15Z"}, {"author": "Harald Alvestrand", "text": "

one thing that bothers me is that we're sloppy about \"obsoleted by\" links in the tracker. Makes following chains to find the current draft (post adoption) difficult.

", "time": "2023-11-09T12:21:20Z"}, {"author": "Mark Nottingham", "text": "

Eliot - are you saying that there is no indpendent stream, or...?

", "time": "2023-11-09T12:21:23Z"}, {"author": "Jonathan Lennox", "text": "

2^31 years

", "time": "2023-11-09T12:21:29Z"}, {"author": "Eliot Lear", "text": "

@mnot obviously not. my point is that there are all of these other streams that this change would impact

", "time": "2023-11-09T12:23:00Z"}, {"author": "Mark Nottingham", "text": "

Eliot - Of course. But your statement was specifically about the independent stream.

", "time": "2023-11-09T12:23:36Z"}, {"author": "Mark Nottingham", "text": "

My draft that's relevant to this: https://mnot.github.io/I-D/draft-nottingham-where-does-that-come-from.html

\n

I'm tempted to suggest that it should be in-scope for such a WG.

", "time": "2023-11-09T12:24:06Z"}, {"author": "Cullen Jennings", "text": "

+1 EKR

", "time": "2023-11-09T12:24:22Z"}, {"author": "Mark Nottingham", "text": "

1) Remove the expiry
\n2) Look at how to present the status of our documents more clearly.

\n

(1) does not depend on (2).

", "time": "2023-11-09T12:25:10Z"}, {"author": "Marek Blachut", "text": "

Outside perspectives on how other communities (Lars mentioned academia, but there. are others) use / consume I-Ds seems like it would be very relevant to ensuring this work makes the situation better and not worse in terms of confusion to outsiders. Maybe getting that input is easier through mini-WG than AD sponsor?

", "time": "2023-11-09T12:25:14Z"}, {"author": "Jari Arkko", "text": "

+1 Mark. There's already a problem with how tooling presents things (see my DHC example above). We can maybe tackle the latter separately...

", "time": "2023-11-09T12:26:40Z"}, {"author": "Mark Nottingham", "text": "

I could see doing (2) in such a WG as long as it was clear it doesn't block (1).

", "time": "2023-11-09T12:27:03Z"}, {"author": "Mirja K\u00fchlewind", "text": "

I was actually initially assuming we were only remove expiry from wg doc, and i\u2018m in for that no question!

", "time": "2023-11-09T12:27:05Z"}, {"author": "Samuel Weiler", "text": "

Mark Nottingham said:

\n
\n

Eliot - are you saying that there is no indpendent stream, or...?

\n
\n

I'm thinking about i-d's submitted without knowing who will pick them up. I might not know if my i-d will be picked up by the IETF, the Independent Stream, or sit and rot on the vine.

", "time": "2023-11-09T12:27:07Z"}, {"author": "Eric Rescorla", "text": "

+1 mnot

", "time": "2023-11-09T12:27:12Z"}, {"author": "Eliot Lear", "text": "

Samuel Weiler said:

\n
\n

Mark Nottingham said:

\n
\n

Eliot - are you saying that there is no indpendent stream, or...?

\n
\n

I'm thinking about i-d's submitted without knowing who will pick them up. I might not know if my i-d will be picked up by the IETF, the Independent Stream, or sit and rot on the vine.

\n
\n

Yes. That's a problem with this proposal.

", "time": "2023-11-09T12:27:50Z"}, {"author": "Pete Resnick", "text": "

Disagree with EKR only insofar as expiration may be serving (perhaps stupid) purposes that are going to simply be ignored if you don't address those purposes before publication. If you can convince yourself that there are no such reasonable purposes, fine. But the WG needs to address those.

", "time": "2023-11-09T12:27:53Z"}, {"author": "Samuel Weiler", "text": "

Eliot Lear said:

\n
\n

Samuel Weiler said:

\n
\n

Mark Nottingham said:

\n
\n

Eliot - are you saying that there is no indpendent stream, or...?

\n
\n

I'm thinking about i-d's submitted without knowing who will pick them up. I might not know if my i-d will be picked up by the IETF, the Independent Stream, or sit and rot on the vine.

\n
\n

Yes. That's a problem with this proposal.

\n
\n

I don't think it is. I think the IETF can, as the maintainer of the i-d repo and baseline submission rules, make this change.

", "time": "2023-11-09T12:28:41Z"}, {"author": "Mark Nottingham", "text": "

Eliot - what is the nature of the problem? As was pointed out, they're already archived, and their status is not clearly reflected. I agree there are problems there, but they are pre-existing.

", "time": "2023-11-09T12:28:54Z"}, {"author": "Eliot Lear", "text": "

Mark Nottingham said:

\n
\n

Eliot - what is the nature of the problem? As was pointed out, they're already archived, and their status is not clearly reflected. I agree there are problems there, but they are pre-existing.

\n
\n

I said that I'm not convinced that this is a good idea for the independent stream. In partiuclar, I use the expiration as a signal of interest of someone wanting to continue their efforts.

", "time": "2023-11-09T12:30:55Z"}, {"author": "Eric Rescorla", "text": "

@Eliot Lear nothing stops you from looking at the last update time

", "time": "2023-11-09T12:31:10Z"}, {"author": "Jay Daley", "text": "

The biggest issue I can see is how people establish currency. While expiry dates are a crude way of doing that, they do at least do it and removing it entirely means that we need a new way to show currency.

", "time": "2023-11-09T12:31:55Z"}, {"author": "Mallory Knodel", "text": "

Given expiry date is only 6 months since last update it does seem superfluous

", "time": "2023-11-09T12:32:07Z"}, {"author": "Eliot Lear", "text": "

Also, I think it's a bad idea for things that are mean to be working documents to be misclaimed as archival.

", "time": "2023-11-09T12:32:10Z"}, {"author": "Eric Rescorla", "text": "

But not to put too fine a point in it, the vast vast majority of I-Ds are in the IETF, so having policies here that work for IETF is vastly more important than having ones that work for the IS

", "time": "2023-11-09T12:32:12Z"}, {"author": "Eric Rescorla", "text": "

Jay Daley said:

\n
\n

The biggest issue I can see is how people establish currency. While expiry dates are a crude way of doing that, they do at least do it and removing it entirely means that we need a new way to show currency.

\n
\n

in other contexts, nobody has any trouble looking at \"when was the last update\". See, for instance GitHub

", "time": "2023-11-09T12:32:29Z"}, {"author": "Mallory Knodel", "text": "

Mallory Knodel said:

\n
\n

Given expiry date is only 6 months since last update it does seem superfluous

\n
\n

Last update is enough; does the work of both.

", "time": "2023-11-09T12:33:12Z"}, {"author": "Eric Rescorla", "text": "

Eliot Lear said:

\n
\n

Also, I think it's a bad idea for things that are mean to be working documents to be misclaimed as archival.

\n
\n

this whole concept of \"archival\" in this context seems to me to be rather confused. In the modern Internet, effectively everything is archived

", "time": "2023-11-09T12:33:30Z"}, {"author": "Richard Barnes", "text": "

... especially for documents as small as I-Ds

", "time": "2023-11-09T12:33:59Z"}, {"author": "Ted Hardie", "text": "

Who does the fork is salient here. The ITU fork has a built in set of drivers that a W3C fork would not.

", "time": "2023-11-09T12:34:14Z"}, {"author": "Eric Rescorla", "text": "

and yet the ITU already knows how to fork

", "time": "2023-11-09T12:34:33Z"}, {"author": "John Klensin", "text": "

@Jay: agreed. I think there are problems with expiry dates as integral parts of the draft and that they are rather crude, but I'd rather see a discussion about currency (or the lack thereof) and how we establish/ document that than a discussion about removing the date.

", "time": "2023-11-09T12:35:06Z"}, {"author": "Ted Hardie", "text": "

And the arguments against it in nation-state circles have relied on the IETF's claim of exclusivity.

", "time": "2023-11-09T12:35:16Z"}, {"author": "Jay Daley", "text": "

Eric Rescorla said:

\n
\n

in other contexts, nobody has any trouble looking at \"when was the last update\". See, for instance GitHub

\n
\n

But we don't want to show a list going back decades, ordered by last update, we need some form of cutoff. When would that be?
\nWe also need to manage the situation where a new version is published, and the old version is automatically not current

", "time": "2023-11-09T12:35:20Z"}, {"author": "Mark Nottingham", "text": "

ETSI did use our documents; just by reference.

", "time": "2023-11-09T12:36:26Z"}, {"author": "Eliot Lear", "text": "

Eric Rescorla said:

\n
\n

and yet the ITU already knows how to fork

\n
\n

Were that the case, we wouldn't have had to use the license in the past to protect our works. These words were written because of abuse of other organizations. The adversarial model here is not being properly represented.

", "time": "2023-11-09T12:36:46Z"}, {"author": "Mirja K\u00fchlewind", "text": "

Given anybody can just write their own document and more important code, what\u2019s the problem that needs solving?

", "time": "2023-11-09T12:37:09Z"}, {"author": "Eric Rescorla", "text": "

Jay Daley said:

\n
\n

Eric Rescorla said:

\n
\n

in other contexts, nobody has any trouble looking at \"when was the last update\". See, for instance GitHub

\n
\n

But we don't want to show a list going back decades, ordered by last update, we need some form of cutoff. When would that be?
\nWe also need to manage the situation where a new version is published, and the old version is automatically not current

\n
\n

What do you mean \"show a list\"? Like in datatracker search? How do you think other people manage situations where searches have zillions of potential answers.

", "time": "2023-11-09T12:37:35Z"}, {"author": "Eric Rescorla", "text": "

Eliot Lear said:

\n
\n

Eric Rescorla said:

\n
\n

and yet the ITU already knows how to fork

\n
\n

Were that the case, we wouldn't have had to use the license in the past to protect our works. These words were written because of abuse of other organizations. The adversarial model here is not being properly represented.

\n
\n

Well, at least in the case of TLS, we didn't use our license

", "time": "2023-11-09T12:37:59Z"}, {"author": "Eliot Lear", "text": "

Mark Nottingham said:

\n
\n

ETSI did use our documents; just by reference.

\n
\n

If they want to reference, fine. But using our words in ways that misrepresent our views subverts the intent of the rough consensus process.

", "time": "2023-11-09T12:38:17Z"}, {"author": "Mark Nottingham", "text": "

Perhaps the strongest concern I have that support's Martin's position is that there's no guidance to the Trust regarding when it's appropriate to grant a license. If the HTTP community collectively decides that it doesn't like the taste of IETF cookies, it should be able to go elsewhere, but in the current arrangement, it's at the mercy of the Trust.

", "time": "2023-11-09T12:38:42Z"}, {"author": "John Levine", "text": "

Mark Nottingham said:

\n
\n

Perhaps the strongest concern I have that support's Martin's position is that there's no guidance to the Trust regarding when it's appropriate to grant a license. If the HTTP community collectively decides that it doesn't like the taste of IETF cookies, it should be able to go elsewhere, but in the current arrangement, it's at the mercy of the Trust.

\n
\n

The Trust does whatever the IETF tells it to do. The IESG seems like the right authority here.

", "time": "2023-11-09T12:39:28Z"}, {"author": "Jari Arkko", "text": "

+1 on the IESG-gets-to-request-this-on-case-by-case basis proposal

", "time": "2023-11-09T12:39:36Z"}, {"author": "Mark Nottingham", "text": "

Hmm.

", "time": "2023-11-09T12:39:53Z"}, {"author": "Rich Salz", "text": "

I wonder if the IETF has the rights to give other entities the rights that authors currently granted.

", "time": "2023-11-09T12:40:45Z"}, {"author": "Eric Rescorla", "text": "

@Rich Salz I think sort of

", "time": "2023-11-09T12:40:53Z"}, {"author": "Jari Arkko", "text": "

Trust indeed is supposed to work for the IETF community and listen to them. In practical terms, where IETF no longer is the right place to continue maintenance of protocol X is probably a recommendation that IESG could make.

", "time": "2023-11-09T12:41:14Z"}, {"author": "John Levine", "text": "

@Rich Salz see RFCs 5377 and 5378. Usually, not always.

", "time": "2023-11-09T12:41:26Z"}, {"author": "Tara Tarakiyee", "text": "

What about situations when the iesg is in disagreement with the respective technical community (like in Mark's http example)

", "time": "2023-11-09T12:42:00Z"}, {"author": "Stephan Wenger", "text": "

@Rich: yes, the IETF has; section 5.3 third para of 5378

", "time": "2023-11-09T12:42:10Z"}, {"author": "Mark Nottingham", "text": "

That's where it gets sticky.

", "time": "2023-11-09T12:42:11Z"}, {"author": "Mirja K\u00fchlewind", "text": "

I think any group could just go away and publish their own documents with new text somewhere and we can\u2019t stop anybody from implementing it.

", "time": "2023-11-09T12:42:34Z"}, {"author": "Ted Hardie", "text": "

@Mirja do you oppose this as a result, since you see it as unnecessary?

", "time": "2023-11-09T12:43:00Z"}, {"author": "Eric Rescorla", "text": "

@Mirja K\u00fchlewind yes, that's definitely true

", "time": "2023-11-09T12:43:04Z"}, {"author": "Pete Resnick", "text": "

Of perhaps interest. On the bottom of the Ombudsteam page, you will find the following about RFC 7776:

", "time": "2023-11-09T12:43:18Z"}, {"author": "Tara Tarakiyee", "text": "

Mirja K\u00fchlewind said:

\n
\n

I think any group could just go away and publish their own documents with new text somewhere and we can\u2019t stop anybody from implementing it.

\n
\n

I'd like to see that explicitly stated as policy somewhere

", "time": "2023-11-09T12:43:22Z"}, {"author": "Pete Resnick", "text": "

\"*) If your organisation outside the IETF is interested in implementing similar anti-harassment procedures, the authors of the RFC have made a CC0-copyrighted version available at http://www.olddog.co.uk/anti-harassment-process.htm.\"

", "time": "2023-11-09T12:43:30Z"}, {"author": "Pete Resnick", "text": "

The authors are welcome to republish their own document.

", "time": "2023-11-09T12:44:09Z"}, {"author": "Mirja K\u00fchlewind", "text": "

We really don\u2019t control what people implement and deploy but I think we need to maintain control about the text that ietf participants have given to the ietf because that\u2019s what\u2018s our output

", "time": "2023-11-09T12:44:38Z"}, {"author": "John Levine", "text": "

@Tara Tarakiyee That is how copyright law works. It applies to the text, not the meaning.

", "time": "2023-11-09T12:44:45Z"}, {"author": "Rich Salz", "text": "

@Stephan Wenger I don't see where your reference allows the IETF to transfer thoose rights to a third party. I'm not a lawyer, but I'd expect to see the word \"transfer\" somewhgere.

", "time": "2023-11-09T12:45:07Z"}, {"author": "Richard Barnes", "text": "

Glenn totally missing the point here

", "time": "2023-11-09T12:45:28Z"}, {"author": "Eric Rescorla", "text": "

I really think MT is aware of all of this stuff

", "time": "2023-11-09T12:45:46Z"}, {"author": "Mirja K\u00fchlewind", "text": "

@ted I see the problem stated as not a problem. And I would like to make sure we understand the problem before we act, if there is one

", "time": "2023-11-09T12:46:05Z"}, {"author": "Ted Hardie", "text": "

@mirja Thanks for the clarification.

", "time": "2023-11-09T12:46:19Z"}, {"author": "Eric Rescorla", "text": "

Yes, the idea here is that we would tie the use of the text to the name.

", "time": "2023-11-09T12:46:21Z"}, {"author": "Eric Rescorla", "text": "

as a quid pro quo

", "time": "2023-11-09T12:46:25Z"}, {"author": "John Levine", "text": "

@Rich Salz RFC 5378 sec 3.3

", "time": "2023-11-09T12:46:49Z"}, {"author": "John Levine", "text": "

The word is \"derivative\"

", "time": "2023-11-09T12:47:06Z"}, {"author": "Jari Arkko", "text": "

+1 on Glenn's point about lack of protection on names. We don't have that level of control.

", "time": "2023-11-09T12:47:11Z"}, {"author": "Tara Tarakiyee", "text": "

John Levine said:

\n
\n

Tara Tarakiyee That is how copyright law works. It applies to the text, not the meaning.

\n
\n

It gets sticky when the new text can only be so different from a derivative work that it creates a chilling effect.

", "time": "2023-11-09T12:47:25Z"}, {"author": "Eric Rescorla", "text": "

@Jari Arkko you're right we don't know.

", "time": "2023-11-09T12:47:26Z"}, {"author": "Richard Barnes", "text": "

The product of the IETF is consensus, not documents

", "time": "2023-11-09T12:47:34Z"}, {"author": "Eric Rescorla", "text": "

The point of this clause would be that we would permit people to use the text in return for not using the name

", "time": "2023-11-09T12:48:01Z"}, {"author": "Eric Rescorla", "text": "

And that in fact we could do

", "time": "2023-11-09T12:48:08Z"}, {"author": "Jay Daley", "text": "

Eric Rescorla said:

\n
\n

What do you mean \"show a list\"? Like in datatracker search? How do you think other people manage situations where searches have zillions of potential answers.

\n
\n

My point is that we benefit from being able to clearly define a set of \"current stuff\" (acknowledging that this is very crude, and that some things not in \"current\" might still be being worked on, and some things in \"current\" have actually been replaced or abandoned). Lists in DT are one example yes, but there are others. Sure, there are mechanisms that manage huge search results, but they don't identify currency, it is something each individual has to assess based on their reading of the list. Moving from a shared, albeit flawed, definition of currency to no shared definition seems to me to introduce multiple issues.

", "time": "2023-11-09T12:48:25Z"}, {"author": "John Levine", "text": "

@eric that would be quite a tricky license to write

", "time": "2023-11-09T12:48:25Z"}, {"author": "Jari Arkko", "text": "

+1 Cullen's point

", "time": "2023-11-09T12:48:58Z"}, {"author": "John Levine", "text": "

Is the name TLS, TLS 1.3, TLS1.<whatever> ?

", "time": "2023-11-09T12:49:02Z"}, {"author": "Eric Rescorla", "text": "
\n

ure, there are mechanisms that manage huge search results, but they don't identify currency, it is something each individual has to assess based on their reading of the list. Moving from a shared, albeit flawed, definition of currency to no shared definition seems to me to introduce multiple issues.

\n
\n

Wait what? you don't think Google uss currency as part of their sorting algorithm?

", "time": "2023-11-09T12:49:33Z"}, {"author": "Rich Salz", "text": "

Yes, this is the key phrase \" The IETF may also decide to permit others \" permit others, not just derivative.

", "time": "2023-11-09T12:49:57Z"}, {"author": "Jari Arkko", "text": "

NFS folks could already do that, if they requested and the IETF clearly expressed they wanted to do that, and then trust would for sure follow that advice.

", "time": "2023-11-09T12:51:32Z"}, {"author": "Mark Nottingham", "text": "

Maybe this should turn into 'guidance to the IESG when deciding whether to allow licensing'

", "time": "2023-11-09T12:51:43Z"}, {"author": "Stephan Wenger", "text": "

+1 to Harald

", "time": "2023-11-09T12:51:59Z"}, {"author": "Anthony Somerset", "text": "

i think its far better to deal with this on a case by case basis on its own merits - which i think is possible now through the licensing request processes?

\n

its far too complex to do as a general default

", "time": "2023-11-09T12:52:11Z"}, {"author": "Jay Daley", "text": "

@Eric Rescorla Let me try again. Yes \"last update\" encodes currency but the using it in this way switches from two sets - current and not-current - to one very large set with a spectrum of currency. No one person can cope with the full set even in the context of a single topic/wg/etc and so they need to choose a cutoff point, so we then lose that shared understanding of where that should be.

", "time": "2023-11-09T12:52:29Z"}, {"author": "Andrew Campling", "text": "

+1 to Anthony\u2019s comment about case-by-case approach, presumably via the Trust

", "time": "2023-11-09T12:53:05Z"}, {"author": "Mark Nottingham", "text": "

When a distinct community wants to walk away, that should be respected -- the IESG is going to have strong incentives to preserve work here even when it may not be the right thing to do.

", "time": "2023-11-09T12:53:08Z"}, {"author": "Mallory Knodel", "text": "

Sounds like a dare, Richard

", "time": "2023-11-09T12:54:30Z"}, {"author": "Mark Nottingham", "text": "

Notice he's not in the room

", "time": "2023-11-09T12:54:43Z"}, {"author": "Pete Resnick", "text": "

@Richard Barnes Your github thing has documents that are changed in some way?

", "time": "2023-11-09T12:54:54Z"}, {"author": "Harald Alvestrand", "text": "

I think Richard's hack can be described as a \"performance\" of the RFC series :-)

", "time": "2023-11-09T12:54:57Z"}, {"author": "Cullen Jennings", "text": "

what was the website

", "time": "2023-11-09T12:54:58Z"}, {"author": "Mallory Knodel", "text": "

Having myself had to answer to the Trust (we put out a report with the logo oops) (it now doesn\u2019t have the logo)

", "time": "2023-11-09T12:55:00Z"}, {"author": "Jari Arkko", "text": "

What's your alternative, Mark, because I see only two options. Either the community has that power to decide when this is ok, or it is ok all the time.

", "time": "2023-11-09T12:55:04Z"}, {"author": "Eliot Lear", "text": "

Richard, the idea that the Trust doesn't come after you doesn't mean that they shouldn't go after others. I doubt your stylistic changes will cause interoperability concerns...

", "time": "2023-11-09T12:55:23Z"}, {"author": "Mirja K\u00fchlewind", "text": "

@Richard Barnes it\u2019s not only consensus either. It also technical expertise. And those technical ideas are regelrechtes in documents

", "time": "2023-11-09T12:55:33Z"}, {"author": "Anthony Somerset", "text": "

rfcs.online

", "time": "2023-11-09T12:55:39Z"}, {"author": "Mark Nottingham", "text": "

My 'alternative' suggestion was guidelines to the IESG

", "time": "2023-11-09T12:55:43Z"}, {"author": "Jane Coffin", "text": "

Case by case seems wise.
\nHaving been involved in the MPLS OAM fun in ITU. There was a lot more going on w that than creating a derivative work product

", "time": "2023-11-09T12:55:49Z"}, {"author": "Mark Nottingham", "text": "

AD: rfc.fyi

", "time": "2023-11-09T12:55:55Z"}, {"author": "Jari Arkko", "text": "

Ok Mark. I could live with that.

", "time": "2023-11-09T12:56:07Z"}, {"author": "Michael B", "text": "

I appreciate everyone's insight here, but can people please mention what they think the dispatch outcome should be?

", "time": "2023-11-09T12:56:07Z"}, {"author": "Jay Daley", "text": "

I don't see anything in rfc.online or rfc.fyi that violates the TLP

", "time": "2023-11-09T12:56:28Z"}, {"author": "Richard Barnes", "text": "

ooh, i look forward to the IETF-3GPP lawsuit!

", "time": "2023-11-09T12:56:44Z"}, {"author": "Richard Barnes", "text": "

how to make friends and influence people

", "time": "2023-11-09T12:56:51Z"}, {"author": "Timothy Terriberry", "text": "

Fair use is pretty US-specific. Not every jurisdiction has something equivalent.

", "time": "2023-11-09T12:57:14Z"}, {"author": "Mallory Knodel", "text": "

Fair use isn\u2019t iron clad. And it can be a slippery slope which is why it is often successfully challenged.

", "time": "2023-11-09T12:57:16Z"}, {"author": "Jari Arkko", "text": "

Dispatch: Not ready, controversial. Next step: Document options (current, various changes) and their implications, both positive and negative. Have a discussion at a future IETF about it. See if a consensus emerges.

", "time": "2023-11-09T12:57:27Z"}, {"author": "Ted Hardie", "text": "

The idea that a single non-WG forming bof would drain the queue of these concerns seems optimistic in the extreme.

", "time": "2023-11-09T12:57:34Z"}, {"author": "Mallory Knodel", "text": "

Mallory Knodel said:

\n
\n

Fair use isn\u2019t iron clad. And it can be a slippery slope which is why it is often successfully challenged.

\n
\n

^^ Even in the US

", "time": "2023-11-09T12:57:37Z"}, {"author": "Richard Barnes", "text": "

@Jay Daley how is https://rfcs.online/#6919 not a derivative work?

", "time": "2023-11-09T12:57:51Z"}, {"author": "Tara Tarakiyee", "text": "

Case by case didn't preclude having guidance, it's not good governance to just assume the trust and the iesg will make the right choice for each case without guidance.

", "time": "2023-11-09T12:58:00Z"}, {"author": "Jay Daley", "text": "

Richard Barnes said:

\n
\n

Jay Daley how is https://rfcs.online/#6919 not a derivative work?

\n
\n

Because it reproduces it in full

", "time": "2023-11-09T12:58:24Z"}, {"author": "Anthony Somerset", "text": "

Richard Barnes said:

\n
\n

Jay Daley how is https://rfcs.online/#6919 not a derivative work?

\n
\n

the documents are not changed

\n

its a derivative of the rfc website though - clearly thats a difference

", "time": "2023-11-09T12:58:49Z"}, {"author": "Richard Barnes", "text": "

oh i forgot to mention it also does cloud2butt, see https://rfcs.online/#6208

", "time": "2023-11-09T12:59:04Z"}, {"author": "Richard Barnes", "text": "

now is the trust going to sue me?

", "time": "2023-11-09T12:59:28Z"}, {"author": "Mark Nottingham", "text": "

LOL

", "time": "2023-11-09T12:59:32Z"}, {"author": "Stephan Wenger", "text": "

I would recommend you stop this discussion, as it may force the Trust's hand. Provocations help only that much...

", "time": "2023-11-09T12:59:46Z"}, {"author": "Anthony Somerset", "text": "

https://xkcd.com/927/

", "time": "2023-11-09T13:00:08Z"}, {"author": "Mark Nottingham", "text": "

If the Trust decided to use the IETF's legal resources to pursue this, I think people would be very interested in that.

", "time": "2023-11-09T13:00:12Z"}, {"author": "Jay Daley", "text": "

But there is nothing there to sue about - those are not derivative works

", "time": "2023-11-09T13:00:23Z"}, {"author": "Richard Barnes", "text": "

@Jay Daley even when i change words in the document?

", "time": "2023-11-09T13:00:38Z"}, {"author": "Andrew Campling", "text": "

This definitely needs input from the Trust, given the subject matter expertise that it has

", "time": "2023-11-09T13:01:23Z"}, {"author": "Jay Daley", "text": "

Oh I get it now - Ianal but yes that is a derivative

", "time": "2023-11-09T13:01:31Z"}, {"author": "Richard Barnes", "text": "

If you need expertise, you need lawyers not trustees

", "time": "2023-11-09T13:01:42Z"}, {"author": "Rich Salz", "text": "

Richard you have made your point, perhaps stop antagonizing the people you claim you want to work with to change things.

", "time": "2023-11-09T13:01:43Z"}, {"author": "Rich Salz", "text": "

Just a friendly sugesitons

", "time": "2023-11-09T13:02:14Z"}, {"author": "Mark Nottingham", "text": "

\"You had one job...\"

", "time": "2023-11-09T13:03:25Z"}, {"author": "Richard Barnes", "text": "

@Glenn Deen I find your comment about \"getting the IETF's work done\" pretty offensive -- the IETF's job is promoting introperability, not making RFCs. if more innovative use of RFCs does that, great. @Cullen Jennings was on point that the question is whether this is good for the internet.

", "time": "2023-11-09T13:04:26Z"}, {"author": "Richard Barnes", "text": "

I feel like people are not appreciating that the derivative works prohibition prohibits any innovation with RFCs, even just presenting them in a prettier format.

", "time": "2023-11-09T13:05:35Z"}, {"author": "Richard Barnes", "text": "

Permissionless innovation for me, but not for thee

", "time": "2023-11-09T13:05:58Z"}, {"author": "Samuel Weiler", "text": "

should we chip it to get Rich a better cutting tool?

", "time": "2023-11-09T13:06:25Z"}, {"author": "Eliot Lear", "text": "

Thee may always take the work and use in the IETF process. No permission required.

", "time": "2023-11-09T13:06:31Z"}, {"author": "Eliot Lear", "text": "

(modulo attached IPR)

", "time": "2023-11-09T13:06:51Z"}, {"author": "Eliot Lear", "text": "

But if interoperability is the goal, then the last thing we should encourage is dueling derivatives that have no means to converge.

", "time": "2023-11-09T13:07:51Z"}, {"author": "Shuping Peng", "text": "

In the current queue, please remove yourself if you were for the last topic. Thank you!

", "time": "2023-11-09T13:08:35Z"}, {"author": "Richard Barnes", "text": "

@Eliot Lear as martin said, people can make dueling protocols even with the current state. you're not getting the protection you think you are, and you're cutting off innovation

", "time": "2023-11-09T13:08:38Z"}, {"author": "Richard Barnes", "text": "

the current provision is all downside. I struggle to think of a scenario where the Trust would actually enforce it.

", "time": "2023-11-09T13:11:59Z"}, {"author": "John Scudder", "text": "

I\u2019m going to assume @Mallory Knodel meant \u201cno women who are voting members\u201d. :-(

", "time": "2023-11-09T13:12:20Z"}, {"author": "Alison Becker", "text": "

+1 Mallory

", "time": "2023-11-09T13:13:07Z"}, {"author": "Mallory Knodel", "text": "

Of course I would never forget Mirjam but she doesn\u2019t vote

", "time": "2023-11-09T13:14:01Z"}, {"author": "Eliot Lear", "text": "

Richard Barnes said:

\n
\n

Eliot Lear as martin said, people can make dueling protocols even with the current state. you're not getting the protection you think you are, and you're cutting off innovation

\n
\n

This has happened time and time again with TCP, IPSEC, and (if memory serves) even IPFIX, where we actually did stop the work. You are underestimating the inertial forces involved.

", "time": "2023-11-09T13:14:08Z"}, {"author": "Ted Hardie", "text": "

@Mallory Sagaricka, the ISOC Board liaison is also a woman (from Sri Lanka)

", "time": "2023-11-09T13:14:45Z"}, {"author": "Eliot Lear", "text": "

This having been said, I could envision loosening things somewhat. Especially for work that the IETF doesn't want to maintain.

", "time": "2023-11-09T13:15:10Z"}, {"author": "Richard Barnes", "text": "

@Eliot Lear what do you mean? why did work stop?

", "time": "2023-11-09T13:15:14Z"}, {"author": "Timothy Terriberry", "text": "

Pete Resnick said:

\n
\n

The authors are welcome to republish their own document.

\n
\n

That outlet is only useful if the set of authors is clear, small, and does not have complications caused by their employment by a large multinational corporation with ossified IP policies.

", "time": "2023-11-09T13:15:21Z"}, {"author": "Mallory Knodel", "text": "

Thanks, Ted! I wasn\u2019t aware so that\u2019s helpful. Also not voting, however.

", "time": "2023-11-09T13:15:36Z"}, {"author": "Eliot Lear", "text": "

Richard Barnes said:

\n
\n

Eliot Lear what do you mean? why did work stop?

\n
\n

The competing and confusing standards that were proposed in other treaty organizations were dropped (ITU, ISO).

", "time": "2023-11-09T13:15:48Z"}, {"author": "Richard Barnes", "text": "

What does that have to do with copyright?

", "time": "2023-11-09T13:16:03Z"}, {"author": "Mallory Knodel", "text": "

Obviously my example had flaws but I don\u2019t think the larger diversity problem for the sake of this argument does.

", "time": "2023-11-09T13:16:18Z"}, {"author": "Eliot Lear", "text": "

let's go to email or otherwise discuss on a call or two or even in a bof. I'd be totally ok with all of those.

", "time": "2023-11-09T13:16:49Z"}, {"author": "Harald Alvestrand", "text": "

I think I was making the point sound extreme......

", "time": "2023-11-09T13:16:51Z"}, {"author": "Mallory Knodel", "text": "

Less turnover makes more shallow the pool and we should be talking about ways of doing the opposite.

", "time": "2023-11-09T13:17:33Z"}, {"author": "Richard Barnes", "text": "

@Eliot Lear Totally get that there are issues with competing standards. My point is that the trust copyright provisions have absolutely nothing to do with those issues; they neither help or hinder them.

", "time": "2023-11-09T13:17:41Z"}, {"author": "Andrew Campling", "text": "

@Mallory That\u2019s of course merely one of many diversity problems. Unusually this one is potentially solvable if we address the lack of diversity of the wider community.

", "time": "2023-11-09T13:18:02Z"}, {"author": "Eliot Lear", "text": "

Richard Barnes said:

\n
\n

Eliot Lear Totally get that there are issues with competing standards. My point is that the trust copyright provisions have absolutely nothing to do with those issues; they neither help or hinder them.

\n
\n

We actually used those very provisions to stop the work.

", "time": "2023-11-09T13:18:05Z"}, {"author": "Martin Thomson", "text": "

@Eliot Lear that only suggests that your adversary was weak in that case.

", "time": "2023-11-09T13:18:34Z"}, {"author": "Samuel Weiler", "text": "

Harold, re: nothing we could do: 1) there is the confirmation process as a bit of a backstop. 2) we could start the recall process for all of the problematic Gen 1 appointees... But while we could kick out problematic appointees, if we asked the nomcom to replace them, those would come from the same nomcom.

", "time": "2023-11-09T13:18:46Z"}, {"author": "Eliot Lear", "text": "

And it's not like we said, \u201cyou can't work on this\u201d. What we said was that \u201cyou can't use our text to advance your competing standard.\u201d That was enough.

", "time": "2023-11-09T13:19:01Z"}, {"author": "Harald Alvestrand", "text": "

Sam, good point. we have multiple fences, so I was exaggerating quite a bit.

", "time": "2023-11-09T13:19:30Z"}, {"author": "Harald Alvestrand", "text": "

and the reaction to explaining our model isn't \"it's insanely complicated\", it's more \"it's insane\" ... until they get the idea....

", "time": "2023-11-09T13:20:07Z"}, {"author": "Mallory Knodel", "text": "

(deleted)

", "time": "2023-11-09T13:20:10Z"}, {"author": "Eliot Lear", "text": "

Martin Thomson said:

\n
\n

Eliot Lear that only suggests that your adversary was weak in that case.

\n
\n

Well, we'd like to think so. They certainly didn't have the depth of expertise to redo the whole work, or even to make referential changes. But it was enough, and it kept us out of regulatory messes.

", "time": "2023-11-09T13:20:31Z"}, {"author": "Pete Resnick", "text": "

I don't mind the 3 year chairs (if they're willing to do so). The 5+5 2 year members makes me a bit more queasy, though not because it's more complicated; more for Harald's reasons. Don't mind this being dispatched to a group (since there are other nomcomish things that could be handled).

", "time": "2023-11-09T13:21:19Z"}, {"author": "Eliot Lear", "text": "

And keep in mind, in some organizations, no idea is ever bad enough not to be recycled. So we'll face these sorts of battles in the future.

", "time": "2023-11-09T13:21:42Z"}, {"author": "Samuel Weiler", "text": "

If any particular nomcom wanted more continuity, they could invite add'l past members or past chairs as advisors.... I'm fine leaving that discretion to the nomcoms.

", "time": "2023-11-09T13:22:01Z"}, {"author": "Andrew Campling", "text": "

+1 to dispatch to a group - for the 5+5 element. Could we just decide to make the chairs 3 years as per the proposal from Rich?

", "time": "2023-11-09T13:24:22Z"}, {"author": "Dhruv Dhody", "text": "

+1 to @Robert Sparks and also confidentiality between nomcoms

", "time": "2023-11-09T13:25:23Z"}, {"author": "Harald Alvestrand", "text": "

when I was appointed chair, I was invited as observer to the previous nomcom (for their last few weeks). Could the ISOC President make this change by simply appointing the chair 1 year ahead of time?

", "time": "2023-11-09T13:26:08Z"}, {"author": "Tara Tarakiyee", "text": "

Is it really random if the input is so limited

", "time": "2023-11-09T13:29:13Z"}]