Re: [Last-Call] Last Call: <draft-koster-rep-06.txt> (Robots Exclusion Protocol) to Informational RFC

[George Michaelson <[e-mail]>]

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 <[e-mail]> 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
> <[e-mail]> 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 <[e-mail]>
> >> 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, [e-mail], Taughannock Networks,
> >> Trumansburg NY Please consider the environment before reading
> >> this e-mail. https://jl.ly
> >>
> >> --
> >> last-call mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/last-call
>
>
> --
> last-call mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call