----- 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
