Subject: [OPSAWG] TACACS+, a suggestion

From: Stefan Winter <[email-masked]>
Date: Fri, 12 Feb 2016 15:12:15 +0100

Hello,

this debate has been going on for quite a while. It's multi-faceted,
which doesn't help coming to conclusions.

Maybe we can un-entangle one point: there are suggestions to either make
this Standards Track or Informational; and one wheteher the protocol
should be documented vs. improved.

Maybe there should be two (or more) drafts instead:

1) The TACACS+ Protocol as Deployed in 2016
   (Informational, *no changes*)

2-n) The New Feature X for TACACS+
   (possibly Standards Track, one document per bolt-on feature)

(one of the Xes being TLS encryption, but I'm sure there are more)

Those voices on the list who demanded documentation can then happily
accept Informational; the documentation is done either way. Those who
opposed Standards Track for the durrent draft because it's about a
protocol coming in from outside IETF can now go silent, because
Informational addresses their concern.

Those who demand new features can then put all their energy into a
proper, per-feature argument with all those arguments collated in a
per-topic document. Those who opposed the current draft for Standards
Track can continue to oppose those new documents; this time in a focused
discussion with less broadsides fired.

If you can follow my line of thinking to this point, let's take it even
one step further: we are now discussing a larger effort, involving
multiple RFCs, taking an existing technology to a level it wasn't
before. This is usually much rather a job for a working group in its own
right, with a charter detailing which work happens when; not a job for a
one-shot effort in the opsawg.

So my ultimate suggestion would be: have a BoF at IETF95, try to form a
working group, work on all issues that were brought up individually.

(FWIW, this is exactly how RADIUS came to be... from an undocumented
proprietary protcol to a successful IETF one. And guess what, even we
had lengthy discussions about TLS encryption; debating is simply part of
the culture)

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Alan DeKok <[email-masked]>
Date: Fri, 12 Feb 2016 10:00:58 -0500

> Maybe there should be two (or more) drafts instead:

  I support that.

> one-shot effort in the opsawg.

  I believe that a new WG would be required here.

  From the OPSAWG charter: 

https://datatracker.ietf.org/wg/opsawg/charter/

    " It is not within the scope of the OPSAWG to pick up failed WG work ..."

  From the AAA WG milestones

https://datatracker.ietf.org/wg/aaa/charter/

Done      Submission of evaluation document as an Informational RFC.
Done	Submission of requirements document as an Informational RFC.

  i.e. RFC 2989 and RFC 3127.

  I would argue that TACACS+ (the AAA protocol) is a failed WG item.  It was deemed insufficient by the AAA WG in 2001.

  If the argument is that TACACS+ is *not* an AAA protocol, and is instead a management protocol, then the document (#2 in Stefan's suggestion) should be updated to state that.  Further, development of new IETF standard protocols would also seem to be outside of the charter of the OPSAWG:

    The focus of the work will be on topics that govern the behavior or WGs
    in the O&M area (e.g., manageability requirements) and on small, 
    highly focused projects that don't merit a WG of their own or belong 
    to WGs that have already concluded (e.g. advancement of documents on 
    the standards track, application statements, extensions of MIB 
    modules).

  TACACS+ *may* be considered a "small, highly focussed project", but it definitely doesn't meet any of the other criteria.

  And I would argue that documenting a network administration protocol (new to the IETF) is not a "small, highly focussed project".  It's a serious effort which requires more than a review by OPSAWG, which has many other priorities.

  Alan DeKok.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 12 Feb 2016 16:46:14 +0100

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

On 2/12/16 3:12 PM, Stefan Winter wrote:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Alan DeKok <[email-masked]>
Date: Fri, 12 Feb 2016 11:34:40 -0500

> On Feb 12, 2016, at 10:46 AM, Eliot Lear <[email-masked]> 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.

  The reality is that the TLS portion documented in the draft isn't implemented anywhere.

  I find it telling that the work is important enough to push through the WG, but not important enough that (as you say) the authors have other things to do... and don't have the time to document old work as different from new work.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Fri, 12 Feb 2016 17:38:18 +0100

Hi,

> exercise.  For one thing, we all have other things to do.

Contrary to that, many people on this list are arguing for their life on
the do's or don't's in this area; it seems like they actually have
*nothing* better to do than to fight for (or against) TACACS+. Which is
a great start for a future working group, BTW; people with dedication
and attitude are the fuel for IETF work.

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

Sorry, I don't understand. The reality is that there's a TACACS+
protocol out there, and that there is a desirable TACACS+-to-be in some
people's heads.

I'm suggesting to split the documents exactly like reality does: one
document for the TACACS+ protocol as it exists, one (or more, depending
on the amount of things to be changed) for the future state of it.

How is that denying reality? It's much more working with reality as I
see it. Maybe my reality is different to yours.

Stefan

---

From: Robert Drake <[email-masked]>
Date: Fri, 12 Feb 2016 21:52:10 -0500

On 2/12/2016 10:46 AM, Eliot Lear wrote:
> 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

---

From: t.petch <[email-masked]>
Date: Sat, 13 Feb 2016 12:39:30 +0000

---- Original Message -----
From: "Robert Drake" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, February 13, 2016 2:52 AM
> 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

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sat, 13 Feb 2016 08:53:31 -0500

RFC 2026 was in force in 1997 - see section 10

Scott

> On Feb 13, 2016, at 7:39 AM, t.petch <[email-masked]> wrote:
>

---

From: t.petch <[email-masked]>
Date: Sun, 14 Feb 2016 11:27:09 +0000

----- Original Message -----
From: "Scott O. Bradner" <[email-masked]>
To: "t.petch" <[email-masked]>
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

> >> can it be resubmitted for informational status to define the
protocol
> > as

---

From: "Scott O. Bradner" <[email-masked]>
Date: Sun, 14 Feb 2016 06:58:35 -0500

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-masked]> wrote:
>

---

From: Robert Drake <[email-masked]>
Date: Mon, 15 Feb 2016 04:18:39 -0500

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