Subject: [OPSAWG] Detangling - Q2: Publish TACACS+ as a RFC?

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

Dear OpsAWG:

This is the second of three messages [0] to determine what the OpsAWG
should do with TACACS+

Should the ID, as presented, or as revised by the WG, be published as one
or more RFCs?

Scott, Tianran and Warren

[0]: The first one was the IPR one ( "Untangling - Explicit call for IPR on
draft-ietf-opsawg-tacacs-00")

---

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

On 2/15/16 15:14, Warren Kumari wrote:
> Should the ID, as presented, or as revised by the WG, be published as
> one or more RFCs?

I like the idea of documenting TACACS+ the way it is today as its own 
informational RFC.  I also agree that extending it with the additional 
security measures is good, and separating any enhancements out into 
separate working items makes sense.

Joe

---

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

Yes.

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

Dear OpsAWG:

This is the second of three messages [0] to determine what the OpsAWG should
do with TACACS+

Should the ID, as presented, or as revised by the WG, be published as one or
more RFCs?

[0]: The first one was the IPR one ( "Untangling - Explicit call for IPR on
draft-ietf-opsawg-tacacs-00")
_______________________________________________ OPSAWG mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/opsawg

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Feb 2016 22:02:31 +0100

> Should the ID, as presented, or as revised by the WG, be published as

Yes, for reasons previously stated.

Eliot

---

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

> Should the ID, as presented, or as revised by the WG, be published as one

tacacs+ as we know and use it today should be ps today

future work good and should be encouraged.

randy

---

From: Robert Drake <[email-masked]>
Date: Mon, 15 Feb 2016 19:37:07 -0500

> Should the ID, as presented, or as revised by the WG, be published as 
Yes

> [0]: The first one was the IPR one ( "Untangling - Explicit call for 
> IPR on draft-ietf-opsawg-tacacs-00")
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

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

Yes!

--
Tassos

Warren Kumari wrote on 15/2/16 22:14:
> Dear OpsAWG:
>
> This is the second of three messages [0] to determine what the OpsAWG should do with TACACS+
>
> Should the ID, as presented, or as revised by the WG, be published as one or more RFCs?
>
> [0]: The first one was the IPR one ( "Untangling - Explicit call for IPR on draft-ietf-opsawg-tacacs-00")
>
>

---

From: t.petch <[email-masked]>
Date: Tue, 16 Feb 2016 11:28:20 +0000

--- Original Message -----
From: "Warren Kumari" <[email-masked]>
To: <[email-masked]>
Sent: Monday, February 15, 2016 8:14 PM
> Should the ID, as presented, or as revised by the WG, be published as
one
> or more RFCs?

No, it should not.

A similar situation arose with syslog, a widely used, well-understood
protocol without a standard definition.  In this case, the aim was for
the IETF to add security so first, it had to define the protocol, which
it did with RFC3164.  The I-D adding security seemed to progress well
until it ran into strong objections at IETF meetings which led to
substantial changes, essentially saying that RFC3164 got it wrong, that
it may describe one flavour of syslog but that it did not describe what
was in widespread use.  In due course, RFC5424 appeared and is an
excellent RFC.  But ... some time later, the question arose, on an IETF
list, did it describe what was happening in the Internet, and the
feeling was that it did not.

When the time came to model syslog in YANG, the authors of the I-D
looked at five implementations and then chose the obsoleted,
Informational RFC3164 as the best description of the protocol!

So is the IETF's Standards track specification of syslog of any benefit
to the Internet?

The problem is that for all the following of the correct procedures by
the syslog WG, documenting consensus, gaining participation and so on,
the end result is flaky.  With hindsight, I think that the syslog WG did
not have a wide enough participation to represent all the different
flavours of the protocol and that if it had have, then it might have
been clear that a single, Standards track specification was impossible.
You may have pairwise compatability between the products of six
different manufacturers with TACACS+ but that just may mean that each
manufacturer has learnt that, in the market place, they have to cope
with five other flavours of the protocol to sell a product and that a
single specification does not exist.  (Famously, there have been cases
of Microsoft getting a specification wrong and smaller manufacturers
then building faults into their products in order to interoperate - such
is the commercial world).

So, I believe that the IETF should not get involved with TACACS+; for
all the enthusiasm displayed on the list, we do not have sufficiently
wide skills.  I do not doubt the wishes of those on the list to have a
Standards track specification but that does not mean that it is possible
to produce such a specification that reflects what is happening on the
Internet.  (It would, of course, be different if, as has happened in
other cases, a trade body came to the IETF and asked for their work to
come under the change control of the IETF but I see no evidence that
such a body exists; or, if a manufacturer, say Xxx, wants to submit an
ISE I-D on "Xxx's implementation of TACACS+", then I would fine with
that).

Tom Petch

p.s. You do not say which I-D - I assume draft-ietf-opsawg-tacacs-00 and
not draft-grant-tacacs-02.txt - but from my perspective, that makes no
difference.

> [0]: The first one was the IPR one ( "Untangling - Explicit call for
IPR on
> draft-ietf-opsawg-tacacs-00")

------------------------------------------------------------------------
--------

---

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

> Should the ID, as presented, or as revised by the WG, be published as one or more RFCs?

  I'll say a guarded yes.

  I have previously explained my preferences for how this work should go forward.  I won't repeat them here.

  I'll also echo t.petch's concerns.

  There has been no discussion about TACACS+ implementations.  i.e. does the draft accurately document the protocol as it exists today?  We don't know.

  It would be good to get feedback from implementors as to whether or not the document is correct on it's technical content.  I see that information as critical to have.

  Alan DeKok.

---

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

> Should the ID, as presented, or as revised by the WG, be published as one

I find it impossible to answer this in a binary fashion, unfortunately.

Yes, it is useful to the community to publish an accurate description
of the currently deployed protocol. If that is what the current draft
is, go for it, if and only if it does not carry any restriction on
derivative works.

No, it is not useful to publish a description of the currently deployed
protocol mixed with proposed extensions. If that is what the current
draft is, split it.

   Brian

---

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

> is, go for it, if and only if it does not carry any restriction on

I think the derivatives work issue here is based on potential IPR
claims restricting use of TACACS+ beyond the currently documented (in
draft) protocol...

if that's the case then we're sunk :( (as operators who need current
functionality and want better security properties going forward)

If we're not sunk by the IPR torpedo, I would like to see the current
work finished as an RFC, yes.

---

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

On Tue, Feb 16, 2016 at 3:14 PM Christopher Morrow <
[email-masked]> wrote:

> draft) protocol..

We are still waiting to hear back from that authors on the explicit IPR
check (
https://mailarchive.ietf.org/arch/msg/opsawg/uJUQ4HfSohtJVV3SrR9Qcdnpn5k) ,
but I should point out that the (boilerplate) starts out with:
"This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79."

Due to the network issues in Prague I was not present at the OpsAREA /
OpsAWG meeting, but at 2:30 in the meeting audio recording Joel brought up
the Note Well, so presumably the authors are aware -- but we'll wait to
hear back on the explicit ACK.

---

From: Stefan Winter <[email-masked]>
Date: Thu, 18 Feb 2016 10:57:51 +0100

Hello,

> Should the ID, as presented, or as revised by the WG, be published as

Yes, in multiple RFCs.

The RFC describing the current state has to be Informational; if that's
not happening, my answer converts retroactively into 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:17:08 -0500

Greetings,

I would not object to an informational RFC documenting a widely used
protocol regardless of whether the IETF controls the standardization
of that protocol. I have two caveats:

1. Whoever controls standardization of the protocol must not object to the RFC.

2. If a vendor or other third party controls standardization of a
protocol and does not elect to cede standardization of the protocol to
the IETF then the IETF must not develop, revise or improve the
protocol in any way.

Regards,
Bill Herrin

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