Subject: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC?

From: Warren Kumari <[email-masked]>
Date: Mon, 15 Feb 2016 20:16:29 +0000

This is the third of 3 messages to determine what the OpsAWG should do with
TACACS+.

If the answer to the previous question is yes, should the RFC describing
the protocol itself (as opposed to any other document that might describe
appropriate use) be published as a standards track RFC?

Scott, Tianran and Warren

---

From: Joe Clarke <[email-masked]>
Date: Mon, 15 Feb 2016 15:39:45 -0500

On 2/15/16 15:16, Warren Kumari wrote:
> This is the third of 3 messages to determine what the OpsAWG should do
> with TACACS+.
>
> the protocol itself (as opposed to any other document that might
> describe appropriate use) be published as a standards track RFC?

I would rather see it be a standard, but I would be perfectly happy to 
see it published, in the current implementation, as an informational RFC 
(as stated in my previous answer).

In either event, I feel this work should continue, especially the 
security enhancements.

Joe

---

From: Edwin Mallette <[email-masked]>
Date: Mon, 15 Feb 2016 16:00:29 -0800

Yes.

From:  OPSAWG <[email-masked]> on behalf of Warren Kumari
<[email-masked]>
Date:  Monday, February 15, 2016 at 12:16 PM
To:  "[email-masked]" <[email-masked]>
Subject:  [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track
RFC?

If the answer to the previous question is yes, should the RFC describing the
protocol itself (as opposed to any other document that might describe
appropriate use) be published as a standards track RFC?

Scott, Tianran and Warren
_______________________________________________ OPSAWG mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/opsawg

---

From: Randy Bush <[email-masked]>
Date: Tue, 16 Feb 2016 12:08:09 +1300

> If the answer to the previous question is yes, should the RFC
> describing the protocol itself (as opposed to any other document that
> might describe appropriate use) be published as a standards track RFC?

it is a deployed and widely used protocol.  this question is silly.  of
course it should be standards track.

randy

---

From: Robert Drake <[email-masked]>
Date: Tue, 16 Feb 2016 00:04:04 -0500

> might describe appropriate use) be published as a standards track RFC?
Yes

> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Melinda Shore <[email-masked]>
Date: Mon, 15 Feb 2016 21:06:41 -0900

I'm a little concerned that what's taking place has the
appearance of voting, and I hope that the minority viewpoint
will be weighed on its merit.

That said, I think it's very clearly the case that TACACS+
ought to be published (indeed, probably needs to be published)
given its ubiquity and our interest in interoperability.  I
don't much care how (mostly because I'm unconvinced that anybody
not involved with the IETF cares very much about the distinctions
we make), but I do think that being careful about process helps
protect the working group and the broader organization against
appeals and such, which are a time and energy sink.

But the bottom line is: I think it needs to be published as an
RFC.

Melinda

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Tue, 16 Feb 2016 08:25:45 +0200

Yes

--
Tassos

Warren Kumari wrote on 15/2/16 22:16:
> This is the third of 3 messages to determine what the OpsAWG should do with TACACS+.
>
> If the answer to the previous question is yes, should the RFC describing the protocol itself (as opposed to any other document that might describe appropriate use) be published as a standards track RFC?
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 16 Feb 2016 11:43:04 +0100

Chairs,

> might describe appropriate use) be published as a standards track RFC?
I believe the answer to this question should at least initially be
“yes”.  If the WG comes to determine that the result is so disparate
that an informational document describing what is currently deployed is
also required, we can do that later.  My logic is quite simple: there
may not be energy for two documents, and the changes may be simple
enough to effect in common implementations that a second document may
not be necessary.

Eliot

---

From: Alan DeKok <[email-masked]>
Date: Tue, 16 Feb 2016 10:43:01 -0500

> If the answer to the previous question is yes, should the RFC describing the protocol itself (as opposed to any other document that might describe appropriate use) be published as a standards track…

  I would say "No".

  I'll repeat my reasoning here.

  I support publishing "historical TACACS+" as an informational RFC.  That makes it clear the protocol was developed outside of the IETF, and not under IETF change control.  Despite external people not differentiating between "informational" and "standards track", the IETF process does make that differentiation.  If we are to follow the process, we should follow the process.

  I believe any discussion of TACACS+ MUST remove all discussion of it as an "AAA protocol".  If it's an AAA protocol, then the requirements for AAA protocols should apply.  If (as many proponents claim), it's not an AAA protocol, then the requirements for AAA protocols shouldn't apply.  But the document then MUST NOT describe itself as an AAA protocol.

  I support publishing the "future TACACS+" as a standards track RFC.  But I think this work should be done outside of OPSAWG.

  New management protocols are not a "small, highly focused projects that don't merit a WG of their own".  They require special adoption processes due to the enormous costs they impose on the industry.

  If, on the other hand, OPSAWG published a standards track document titled "TLS transport profile for legacy network management protocols", that would fall within the charter.

  But defining a new (to the IETF and the world) network management protocol is entirely outside of the scope of OPSAWG.

  Or, if (as many people say) the protocol isn't new, then OPSAWG won't be making any changes to TACACS+.  It can't both be under IETF change control, and at the same time, 100% historical TACACS+ and nothing more.

  Alan DeKok.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Feb 2016 07:57:19 +1300

> appropriate use) be published as a standards track RFC?

If it is only an accurate description of the currently deployed protocol,
I couldn't care less whether it's Proposed Standard or Informational, as
long as the IETF can make derivative works.

If there are proposed extensions or changes, that should be standards track.

   Brian

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 16 Feb 2016 15:14:56 -0500

> long as the IETF can make derivative works.

It seems to me that 'proposed standard' is ok here, provided we outrun
the IPR torpedo.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 16 Feb 2016 20:28:58 +0000

On Tue, Feb 16, 2016 at 1:57 PM Brian E Carpenter <
[email-masked]> wrote:

> with

One thing to keep in mind is that, if the document describing the currently
deployed protocol is informational, we may have a tricky time making the
extensions be standards track; it would (presumably) require a downref.

W

---

From: joel jaeggli <[email-masked]>
Date: Tue, 16 Feb 2016 14:55:35 -0800

On 2/16/16 12:28 PM, Warren Kumari wrote:
> 
> 
> On Tue, Feb 16, 2016 at 1:57 PM Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     describing
>     describe
> One thing to keep in mind is that, if the document describing the
> currently deployed protocol is informational, we may have a tricky time
> making the extensions be standards track; it would (presumably) require
> a downref. 

it would; it is not logically a huge problem, merely wierd.

I doubt very much that a push for better securing of an existing mature
protocol is the likely source of controversy there.

>     > [email-masked] <mailto:[email-masked]>

---

From: Randy Bush <[email-masked]>
Date: Wed, 17 Feb 2016 12:08:56 +1300

> protocol is the likely source of controversy there.

what is amusing is that some folk seem to be contemplating that the
rfc of an old and widely distributed and used protocol should not be
standard.

randy

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 16 Feb 2016 18:14:44 -0500

+1 to Randy's observation.

It's almost as if we value our own opinions more than we value running
code...

-Benson

On Tuesday, February 16, 2016, Randy Bush <[email-masked]> wrote:

> [email-masked] <javascript:;>

---

From: joel jaeggli <[email-masked]>
Date: Tue, 16 Feb 2016 15:22:41 -0800

> rfc of an old and widely distributed and used protocol should not be

Occasionally I wonder if "this problem" is the hill I'm going to choose
to die on... Then I remember I'm at the IETF, and self-restraint
suggests otherwise.

---

From: Randy Bush <[email-masked]>
Date: Wed, 17 Feb 2016 12:24:18 +1300

> Occasionally I wonder if "this problem" is the hill I'm going to
> choose to die on...

sorry you have decided to die.  you'll be missed

randy

---

From: Alan DeKok <[email-masked]>
Date: Tue, 16 Feb 2016 18:28:34 -0500

On Feb 16, 2016, at 6:14 PM, Benson Schliesser <[email-masked]> wrote:
> It's almost as if we value our own opinions more than we value running code...

  I suggest posting links to the mailing list archives where someone suggests that the document be published as *only* an informational RFC.  Failing that, publicly withdrawing this claim.

  The only record of someone wanting *only* an informational RFC was me at the mic in Prague.  Discussions since then have convinced me to change my mind.  Which I've stated publicly, for anyone who cares to read my messages.

  The discussions in the last month have been around publishing (a) just a standards track RFC, or (b) a standards track RFC and an informational RFC.

  I'm still surprised at the level of vitriol, contradictory logic, and just plain false statements being made here.  I find such "arguments" entirely unconvincing.

  Alan DeKok.

---

From: joel jaeggli <[email-masked]>
Date: Tue, 16 Feb 2016 15:31:29 -0800

> sorry you have decided to die.  you'll be missed

HWÆT, WE GAR-DEna in geardagum,
þeodcyninga þrym gefrunon,
hu ða æþelingas ellen fremedon!
oft Scyld Scefing sceaþena þreatum,
monegum mægþum meodosetla ofteah,
egsode eorlas, syððanærest wearð
feasceaft funden; he þæs frofre gebad,
weox under wolcnum weorðmyndum þah,
oð þæt him æghwylc ymbsittendra
ofer hronrade hyran scolde,
gomban gyldan; þæt wæs god cyning!

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Feb 2016 16:14:19 -0800

> rfc of an old and widely distributed and used protocol should not be
I think some of us are confused by the use of the term "standard".
This sometimes refers to a process that is driven by requirements, and
open to multiple competing solution proposals which address the
requirements.
Usually the solution is not decided in advance.

Is that the process you have in mind? Doesn't sound like it at all.
Who decides that the draft represents the One True definition of TACACS+?
Is that open to debate, decided by WG consensus?

I am not questioning the value of publishing an RFC, but a standards track
RFC
requires a proper process.

> randy

Andy

---

From: "Scott O. Bradner" <[email-masked]>
Date: Tue, 16 Feb 2016 19:16:41 -0500

> On Feb 16, 2016, at 7:14 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> open to multiple competing solution proposals which address the requirements.

decided by WG consensus

Scott
> 
> I am not questioning the value of publishing an RFC, but a standards track RFC

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Feb 2016 16:21:39 -0800

> > Is that open to debate, decided by WG consensus?

sounds like standards track is OK then

Andy

---

From: Stefan Winter <[email-masked]>
Date: Thu, 18 Feb 2016 11:00:24 +0100

Hello,

> describe appropriate use) be published as a standards track RFC?

That's a trick question; "the protocol itself" definition is what is
under debate right now.

Is "the protocol itself" TACACS+ as deployed today?

Or is it TACACS+ with additions?

If the former: No, it should be Informational.

If the latter: My answer to Question 2 is now a No.

Greetings,

Stefan

-- 
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: William Herrin <[email-masked]>
Date: Thu, 18 Feb 2016 10:18:36 -0500

Greetings,

In my opinion, IETF standards track RFCs should be reserved for
protocols for which further development is expected to occur primarily
within the IETF framework. As I understand the situation (feel free to
correct me if I'm wrong), TACACS+ is a vendor maintained standard,
specifically Cisco. Regardless of publication, Cisco intends to retain
control of the standard and its future development.

If my understanding is correct, TACACS+ should not be presented as an
IETF standards track RFC.

I would remind folks that it's perfectly OK for a network protocol to
be a standard without it being an _IETF_ standard.

Regards,
Bill Herrin

-- 
William Herrin ................ [email-masked]  [email-masked]
Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>

---

From: joel jaeggli <[email-masked]>
Date: Thu, 18 Feb 2016 07:28:28 -0800

> control of the standard and its future development.

Assuming the document is split into to pieces here part of goal as I
understand it is address the issue of adding ssl to the existing
specification in an inter-operable fashion.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Feb 2016 12:02:47 -0800

On Thu, Feb 18, 2016 at 7:18 AM, William Herrin <[email-masked]> wrote:

> the

I think in order for WG consensus to determine decisions wrt/ this document,
it would no longer be a Cisco protocol.  Cisco would have to give all
change control
authority to the IETF.  Maybe an expert on IETF process (like Scott) can
clarify.

Andy

---

From: Eliot Lear <[email-masked]>
Date: Thu, 18 Feb 2016 21:08:01 +0100

On 2/18/16 9:02 PM, Andy Bierman wrote:
> authority to the IETF.  Maybe an expert on IETF process (like Scott)
> can clarify.
>

That is the deal, no matter the vendor, when something becomes an IETF
standard.  And this is why I say, let's see where we land before having
to cough up two documents, when one might do just fine.

Eliot

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 18 Feb 2016 12:16:37 -0800

Sent from my iPhone

> On Feb 18, 2016, at 12:08, Eliot Lear <[email-masked]> wrote:
> 
> 
> 

When we say something is adopted by the working group indeed the working group now has change control. Thier is bit of give and take required to bring work here.

---

From: "Scott O. Bradner" <[email-masked]>
Date: Thu, 18 Feb 2016 16:17:53 -0500

as requested:

the IETF requires the ability to make directive works and the submission of of the ID 
for publication did that 

the IETF does not require (but likes to have ) “change control” on the underlying technology
where the originating company agrees to not further develop a branch of the technology 
and call it by the same name - we have only officially gotten that in a very few cases
(e.g. NFS - see RFC 1790) The IETF did not even get change control in the case of
MPLS (a.k.a Tag Switching) but did go right ahead and develop MPLS

so in almost all cases the IETF proceeds with the assurance by the authors of an ID that they
have the right to contribute the text to the IETF 

note that any patent issues are completely separate from the copyright and “change control”

Scott

> On Feb 18, 2016, at 3:02 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> it would no longer be a Cisco protocol.  Cisco would have to give all change control
> authority to the IETF.  Maybe an expert on IETF process (like Scott) can clarify.
> 
> 
> Andy
> 
>

---

From: William Herrin <[email-masked]>
Date: Thu, 18 Feb 2016 16:25:19 -0500

> specification in an inter-operable fashion.

Hi Joel,

Is Cisco prepared to cede further change control of the core TACACS+
standard to the IETF process? I have no objection to the IETF
absorbing, standardizing and improving the TACACS+ protocol if that is
the vendor's desire. I would not want to see multiple standards bodies
in control of different little bits of the TACACS+ standard. I think
that would sow needless confusion among the folks trying to work with
it.

I respectfully observe that should Cisco wish to retain control of the
core TACACS+ standard, nothing prevents them from adopting a consensus
recommendation for security improvements into the standard without any
need for IETF publication. In such situations, IETF publication offers
little more than bragging rights.

Regards,
Bill Herrin

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Feb 2016 12:56:26 +1300

On 19/02/2016 10:25, William Herrin wrote:
> standard to the IETF process? 

The IETF deals with individual contributors, not companies. As Scott noted,
the authors have already given change control to the IETF by submitting a
draft with the appropriate boilerplate.

Of course, what any company chooses to actually implement is their own
business.

   Brian

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Feb 2016 13:52:22 +1300

> I think in order for WG consensus to determine decisions wrt/ this
> document, it would no longer be a Cisco protocol.  Cisco would have to
> give all change control authority to the IETF.  

andy, you have been around for a while.  where did you get the idea it
was otherwise in the case of this document?

this is just another ietf document.  it happens to document a protocol
used by many operators on many vendors' equipment.  where does all this
ipr, proprietary, ... paranoia come from?  [ that was a rhetorical
question; no need to answer ]

randy

---

From: William Herrin <[email-masked]>
Date: Thu, 18 Feb 2016 19:56:12 -0500

> Of course, what any company chooses to actually implement is their own

With due respect Brian, you're talking past the issue. If Cisco, the
company, intends to back away from maintaining the core TACACS+
standard in favor of the IETF's process then I see no problem with
bringing the protocol into the IETF process. If not, then only sorrow
will come from the IETF creating a _competing standard with the same
name_.

Regards,
Bill Herrin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Feb 2016 17:09:41 -0800

> was otherwise in the case of this document?
It is not that clear from the discussions where "documenting a proprietary
protocol" ends
and "WG makes whatever changes and additions they want" begins.
It is not clear how much backward compatibility with existing
implementations is expected.

If the WG was starting with a set of requirements, and was open to multiple
solution proposals, this would look more like a standards effort to me.
Working backwards from running code seems like more of an Informational RFC
task.

Andy

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Feb 2016 16:04:53 +1300

> will come from the IETF creating a _competing standard with the same

Yes, logically, those statements are true. But we have no way to
know what a company's true intentions are or to know whether they
will stick to those intentions, whatever some employees might say.
So I don't think these hypotheticals about possible futures affect
the decision to be taken now, which is, for once, genuinely about
rough consensus and running code.

otoh not many companies would want to knowingly market a product that
has the same name as an IETF standard but does not conform to that
standard.

OK, the bikeshed now has enough different colour samples on it that we
should stop.

    Brian

---

From: joel jaeggli <[email-masked]>
Date: Thu, 18 Feb 2016 20:51:36 -0800

On 2/18/16 5:09 PM, Andy Bierman wrote:
> 
> 
> On Thu, Feb 18, 2016 at 4:52 PM, Randy Bush <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> It is not that clear from the discussions where "documenting a
> proprietary protocol" ends

I'm not sure that imposing a particular model on standards work as a
whole rather than in specific is appropriate. Sometimes we draw
explicitly on sources that are already or largely fully formed on
arrival, sometimes we do not; sometimes we do waterfalls, in particular
if we need to converge, and some times we don't. We need to be fairly
careful to avoid a generalization that doesn't apply to some or a large
part of our efforts. On the Ops side of things we tend to be working
with and abundance of pre-existing work.

> Working backwards from running code seems like more of an Informational
> RFC task.
> 
>  
>

---

From: t.petch <[email-masked]>
Date: Fri, 19 Feb 2016 16:39:43 +0000

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 18, 2016 11:56 PM
> draft with the appropriate boilerplate.

And what I have seen more than once is a large, American company, which
shares an e-mail domain with IETF participants who have actively worked
on an I-D, submit an IPR claim late in the day.  When asked, the
participants have explained that American law is such that companies aim
to keep participants in the dark about possible IPR claims.  So the
participants have honestly and accurately answered all the questions
about IPR and yet the company (with the same e-mail domain) has put in a
late claim.

So until it is, or is just about to be, an RFC, I don't know whether or
not a technology will be encumbered by an IPR claim and I know of
nothing that the participants can say to allay my concerns (the
company's lawyers might be able to:-).

Tom Petch

---

From: William Herrin <[email-masked]>
Date: Fri, 19 Feb 2016 12:00:07 -0500

On Thu, Feb 18, 2016 at 10:04 PM, Brian E Carpenter
<[email-masked]> wrote:
> We have no way to

Hi Brian,

Respectfully, every company is capable of communicating its official
intentions and designating employees authorized to do so. Whether
they're likely to renege later is, I agree, an issue we can't
reasonably consider.

> rough consensus and running code.

Creating a derivative work of a vendor's product while keeping the
vendor's product name without the vendor's express consent? That's
solely and genuinely about rough consensus and running code?
Seriously?

Gain the vendor's formal consent to take over the standard.
Derive a new work from the vendor's standard under a different,
readily distinguished name.
Produce an informational RFC documenting the vendor's standard without change.

Depending on your goals, you have at least three satisfactory paths
forward. Why insist on an objectionable path instead?

Regards,
Bill Herrin

---

From: Eliot Lear <[email-masked]>
Date: Fri, 19 Feb 2016 18:40:31 +0100

Hi Andy,

> implementations is expected.

I understand your concern. 

My suggestion is that working group consensus (not any particular
individual's or company's point of view) determine what is in a proposed
standard.  Operational experience with what is running is going to
dictate what many people believe should and should not be in in that
doc.  Whether there is an informational document won't change this. 
That's a good thing.  If someone said we should rewrite TACACS+ to use 
EBCDIC encoding, for instance, I'm pretty sure you'd see a lot of people
complain.  If the WG diverges substantially from what is running code,
then two documents seem called for.  But I don't see that we've crossed
that bridge yet.

Eliot

---

From: Robert Drake <[email-masked]>
Date: Mon, 22 Feb 2016 10:02:04 -0500

> company's lawyers might be able to:-).

That seems like something you need to worry about no matter what the 
protocol is or where it originally came from.  If a company wants to 
torpedo the standards process then they've always got lawyers.  It 
doesn't matter how silly their claim is, they can tie it up in lawsuits 
for years.

The only thing we have to fight back is the threat to walk away from 
them as a customer if they don't use a standard for this.  Honestly, 
I've got enough troubles trying to get vendors to adopt tacacs+ without 
someone adding proprietary extensions.  If they want to try it I can see 
us staying on the existing tacacs+ for another 20 years.

The flip side to this is, if the IETF drags out this fight for too long, 
I could see major vendors making their own efforts to secure the 
protocol prior to anyone making a standard (possibly because a large 
customer demands the protocol be secured for whatever reason).  If that 
happens, we might be stuck with TACACS+TLS from one vendor that doesn't 
interoperate with TACACS+blowfish from another (hopefully all with the 
ability to fallback to the defacto standard if needed.. or perhaps we 
just run 3 separate servers with different extensions to support 
multiple vendors..)

Maybe not.  It's been 20 years.  It's possible it's just too obscure to 
worry about, but we won't know until it happens.
> Tom Petch
Robert

---

From: Alan DeKok <[email-masked]>
Date: Mon, 22 Feb 2016 10:29:26 -0500

On Feb 19, 2016, at 12:40 PM, Eliot Lear <[email-masked]> wrote:
> My suggestion is that working group consensus (not any particular individual's or company's point of view) determine what is in a proposed standard.  Operational experience with what is running is going to dictate what many people believe should and should not be in in that doc.  Whether there is an informational document won't change this.  That's a good thing.  If someone said we should rewrite TACACS+ to use  EBCDIC encoding, for instance, I'm pretty sure you'd see a lot of people complain.  If the WG diverges substantially from what is running code, then two documents seem called for.  But I don't see that we've crossed that bridge yet.

  Adding TLS is a substantial divergence, IMHO.  There are no TACACS+ servers I'm aware of which implement TLS.

  Why not document TACACS+ as a historical protocol, and then "TLS transport for legacy network admin protocols"?  If the changes are minor, then the TLS document is minor.

  If the work to add TLS is not minor, then I think that would fall under the rubric of it "diverges substantially from what is running code, then two documents seem called for."

  I'd like to just pick one path forward, and be done with it.  But the reasons for doing things change, depending on who's answering, and what the question is.  To me, this indicates that not only we don't have WG consensus on the document(s), but that the people *proposing* the document(s) can't even reach consensus among themselves as to what they're proposing.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 22 Feb 2016 10:37:18 -0500

On Feb 22, 2016, at 10:02 AM, Robert Drake <[email-masked]> wrote:
> That seems like something you need to worry about no matter what the protocol is or where it originally came from.  If a company wants to torpedo the standards process then they've always got lawyers.  It doesn't matter how silly their claim is, they can tie it up in lawsuits for years.

  True.

> The flip side to this is, if the IETF drags out this fight for too long, I could see major vendors making their own efforts to secure the protocol prior to anyone making a standard (possibly because a large customer demands the protocol be secured for whatever reason).  If that happens, we might be stuck with TACACS+TLS from one vendor that doesn't interoperate with TACACS+blowfish from another (hopefully all with the ability to fallback to the defacto standard if needed.. or perhaps we just run 3 separate servers with different extensions to support multiple vendors..)
> 
> Maybe not.  It's been 20 years.  It's possible it's just too obscure to worry about, but we won't know until it happens.

  I think since TACACS+ has waited 20+ years for standardization, it's worth waiting a few more months to be sure we get it right.

  And since TACACS+ is largely used *within* the enterprise, the issue of securing it is less relevant than (say) RADIUS, which is used across the wider internet.

  Alan DeKok.