David Carrel and Lol Grant are both on linkedin.
Lol Grant is listed as retired and may have absolutely no interest in
trying to resolve copyright problems from 20 years ago, but maybe it
would amuse both of them to get back involved. Or maybe not..
On 2/14/2016 6:58 AM, Scott O. Bradner wrote:
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 <ie...@btconnect.com> wrote:
----- Original Message -----
From: "Scott O. Bradner" <s...@sobco.com>
To: "t.petch" <ie...@btconnect.com>
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 <ie...@btconnect.com> wrote:
---- Original Message -----
From: "Robert Drake" <rdr...@direcpath.com>
To: <opsawg@ietf.org>
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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
