Limit copyright restricted republication to informative/experimental. Never PS, STD, arguably never normative directions. If the document has normative form, then some kind of prequel stating the non-normative outcome due to copyright? If you want to provide normative protocol conforming advice to a community about structure of bits, and bits on a wire, then requiring no change in the standards body is nonsensical. On Wed, Mar 9, 2022 at 3:59 AM John C Klensin <john-ietf@xxxxxxx> wrote: > > Scott, > > You (or John) might have added one thing, which is that at least > as things have evolved, when we publish a company document under > that exception (whether it received IETF review and changes were > made during the process or not), those documents not only get > very clear text in the Abstract and/or Introduction explaining > what they are but get titles like "BigCo's Protocol for ..." as > another way to show who has the final say on the spec and where > change control lies. And, whether it might apply here or not > and AFAIK, we have never recognized either an informal > organization that consists of people working together on one > protocol or an industry consortium with no outside members as an > SDO. > > john > > > --On Tuesday, March 8, 2022 12:40 -0500 Scott Bradner > <sob@xxxxxxxxx> wrote: > > > fwiw - basically supporting what John said > > > > the intent was to be able to publish, for information only, > > company/SDO documents within the IETF process - of course the > > IETF would not have change control over most such documents > > but the intent was to not require that all such documents go > > through the independent stream > > > > and the intent was not that just any document would qualify > > but that would be up to the WG/IESG > > > > in any case, all standards track documents must be under IETF > > change control and cannot include the "no derivative works" > > label > > > > Scott > > > >> On Mar 8, 2022, at 11:59 AM, John R Levine <johnl@xxxxxxxxx> > >> wrote: > >> > >>>> I'm uncomfortable leaving change control for a key > >>>> interoperability mechanism in the search market in the > >>>> hands of one competitor, yet blessing it as part of the > >>>> IETF stream. I think the IETF as a whole should be > >>>> uncomfortable with that too, given current competition > >>>> enforcement trends. > >> > >> Putting on my trustee hat, I don't think this can be an IETF > >> document without IETF change control. RFC 5378 says > >> > >> The right to produce > >> derivative works, in addition to translations, is required > >> for all IETF Standards Track documents and for most IETF > >> non-Standards Track documents. There are two exceptions to > >> this requirement: documents describing proprietary > >> technologies and documents that are republications of the > >> work of other standards organizations. > >> > >> If it's a proprietary technology, Mark is right. If it's > >> not, we need change control. > >> > >> Another possibility would be to move it to the Independent > >> stream if Eliot agrees. > >> > >> Regards, > >> John Levine, johnl@xxxxxxxxx, Taughannock Networks, > >> Trumansburg NY Please consider the environment before reading > >> this e-mail. https://jl.ly > >> > >> -- > >> last-call mailing list > >> last-call@xxxxxxxx > >> https://www.ietf.org/mailman/listinfo/last-call > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
