RFC 2026 specifically permits the IETF to "prepare derivative works that are based on or incorporate all or part of the contribution” (Section 10.3.1.1). The “ contribution” in this case is the old ID.
The language in 2026 was based on language in RFC 1602 (section 5.4.1.1). i.e., use of the old ID to make the new one is authorized by RFC 2026 RFC 3667 (and RFC 3668) was produced to clarify the specific details in RFC 2026 section 10. The mandate given to the IPR working group that produced it was to clarify but not to change the intent of RFC 2026. Scott > On Feb 14, 2016, at 6:27 AM, t.petch <[email protected]> wrote: > > ----- Original Message ----- > From: "Scott O. Bradner" <[email protected]> > To: "t.petch" <[email protected]> > Sent: Saturday, February 13, 2016 1:53 PM >> RFC 2026 was in force in 1997 - see section 10 > > Indeed, and RFC1602 was in force in October 1996 when -00 of this I-D > was produced, but what I am missing is what it is that those two RFC are > missing that caused us to produce RFC3667/RFC3668. To quote the latter > two, > " In the years since [RFC 2026] was > published there have been a number of times when the exact intent of > Section 10 has been the subject of vigorous debate within the IETF > community. " > So, do we have a sufficient grant of rights to take > draft-grant-tacacs-02.txt > and publish it with the necessary changes to bring it in line with > current IETF practice or do we have to go back to the editors thereof, > perhaps their affiliation, to get permission? With SSLv3 and RFC6101, > that was not a problem; with this I-D, I do not know. > > Tom Petch > >> Scott >> >> >> >>> On Feb 13, 2016, at 7:39 AM, t.petch <[email protected]> wrote: >>> >>> ---- Original Message ----- >>> From: "Robert Drake" <[email protected]> >>> To: <[email protected]> >>> Sent: Saturday, February 13, 2016 2:52 AM >>>> >>>> On 2/12/2016 10:46 AM, Eliot Lear wrote: >>>>> Hi Stefan, >>>>> >>>>> Unless it is absolutely determined that the current work can't >>> doesn't >>>>> meet criteria for an IETF standard, I would be opposed to such an >>>>> exercise. For one thing, we all have other things to do. For >>> another, >>>>> and as or more important, we would be denying the reality of the >>>>> situation. I would rather understand now what sort of changes are >>>>> being proposed in order for the current work to come up to snuff. >>>>> >>>>> Eliot >>>>> >>>> Is there anything in this that is incorrect or incomplete? If not, >>> then >>>> can it be resubmitted for informational status to define the > protocol >>> as >>>> it currently exists? >>>> >>>> https://tools.ietf.org/html/draft-grant-tacacs-02 >>> >>> No! Our procedures have moved on a lot since then and the I-D would > need >>> substantial editing. This is problematic. Nowadays - Note Well - >>> anything you or I or anyone else says or writes can be used in an > I-D >>> without any breach of copyright. This I-D is 1997 - before my > time - >>> and I was looking yesterday to try and find out what rules the IETF > was >>> operating under then and could not find them. So, who owns the >>> copyright in the text? Who has permission to edit and publish it? > I do >>> not know (and have seen this issue take a while to resolve in other >>> circumstances). >>> >>> And then there is the question of IPR; reading RFC1492, which I > think >>> would be a Normative Reference in modern parlance, I would expect a >>> manufacturer to be taking an interest in this and submitting an IPR >>> claim. >>> >>> These are surmountable difficulties. The TLS WG decided that it > wanted >>> a specification of SSLv3 some 15 years after the event and we now > have >>> RFC6101 but it takes time and effort. >>> >>> Tom Petch >>> >>> _______________________________________________ >>> OPSAWG mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/opsawg >> > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
