Hi Deb,
My view is slightly more positive. :-)
Some non-IETF protocols are documented with IETF RFCs. From there, the
IETF community can decide build on them or start fresh.
NetFlow to IPFIX: RFC 3954 => RFC 5101 => RFC 7101
Syslog: RFC 3164 => RFC 5424
Regards, Benoit
On 6/27/2025 8:02 PM, Deb Cooley wrote:
Thanks for the history of this (I didn't realize that tacacs+ wasn't
an IETF protocol). As it stands after this past telechat, it just
looks a little funny (nothing wrong with looking funny). The
weirdness is that you have a widely deployed protocol that is not even
PS (the same logic goes for radius and the other protocols
mentioned). It is (academically) interesting to see which protocols
update and evolve on some schedule and which are set in concrete.
Building protocols that allow evolution and transition is apparently
hard (shrug).
Thanks for the time and effort to reply,
Deb Cooley
On Fri, Jun 27, 2025 at 8:55 AM Benoit Claise
<[email protected]> wrote:
On 6/27/2025 2:11 PM, Alan DeKok wrote:
> On Jun 27, 2025, at 7:40 AM, [email protected] wrote:
>> I hear you, but the situation is more complex.
>> Upleveling the full protocol to PS is a distinct work item vs
what the WG agreed and committed to deliver. That work would end
up BTW with specifying “something” that is not interoperable with
the currently widely deployed TACACS+. I’m not sure we are ready
for TACACS+ to have the same situation we had with SYSLOG (RFC
3164, RFC5424), Cisco NETFLOW (RFC3954)/IPFIX(RFC5101-RFC7011),
and so on. That discussion should happen outside the rush of IESG
telechats :-)
>> Once we publish the TLS extension, the WG can start that
discussion (if it whishes so) and see if there are
volunteers/interest from the operators community to explore that path.
> On a strictly technical note, RFC8907 is simply documenting
the protocol which has been around for decades. Its status is
informational because the original specification was developed
outside of the IETF. i.e. the IETF did not have change control
over the specification.
>
> The TLS document is standards track, because it's entirely
new (i.e. no one implemented TLS support), and the spec is under
IETF change control.
Exactly.
"Cisco Systems NetFlow Services Export Version 9" (RFC3954) was
documenting a Cisco protocol: what exist(s/ed), with no change
control
given to the IETF. Hence Informational. IPFIX, on the hand, is
Standard
Track
Exactly the same for TACACS+ RFC8907, again a Cisco protocol.
I guess we would not have these discussions if RFC 8907 would be
called
"Cisco Systems TACACS+ Protocol"
I propose that we don't try to solve a problem that doesn't really
exist.
Regards, Benoit
>
> The question then, is what benefit is there to making the
base protocol standards track? We can't really change anything in
the protocol, as there are perhaps millions of deployments of it.
So we would be left with a very narrow set of choices:
>
> a) make RFC8907 standards track as-is, with no changes
>
> b) Publish the TLS document as standards track, but leave it as
just "wrapping" RFC8907 in TLS, and leave RFC8907 alone.
>
> c) Add the RFC8907 text to the TLS document, and make the
resulting document standards track.
>
> Option (b) is the least amount of work. It also means that
the base protocol is well documented, even if it has
"informational" status. I'll also note that most implementers
tend to blur the lines between "informational" and "standards" RFCs.
>
> Option (a) is relatively simple, but I don't know why it's
useful. Simply changing the document label won't affect much,
because we can't change the underlying protocol.
>
> Option (c) is just copying text, and has the same issues as
option (a).
>
> So I'm not sure why there's a push for the PS label. What
practical benefit does it have? And if the WG isn't prepared to
put in the effort to revisit / rewrite the document, it seems that
it won't happen anyways.
>
> I'll also note that RADIUS accounting (RFC2866) is also
informational. It's been much more widely deployed than TACACS+.
Do we want to revisit that, too?
>
> FWIW, RFC2866 was made informational because the IESG at the
time didn't want to standardize a protocol which could lose
accounting / billing data. 30+ years of deployments have shown
that this isn't much of an issue in practice.
>
> My $0.02 is to leave RFC8907 alone, and to publish the TLS
document as-is. IMHO there is insufficient resources to make
TACACS+ standards track. There is very little benefit to simply
putting a "PS" label on an un-changed RFC8907.
>
> Alan DeKok.
>
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
