Subject: [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-tacacs-yang-10: (with DISCUSS)

From: Francesca Palombini via Datatracker <[email-masked]>
Date: Wed, 21 Apr 2021 09:29:30 -0700

Francesca Palombini has entered the following ballot position for
draft-ietf-opsawg-tacacs-yang-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for the work on this document.
This is a discuss DISCUSS - while reading this document and considering the
normative downref to RFC 8907 TACACS+, which is informational, I agree with
Elliot [1] that to me this document would make more sense as informational. I
have followed the mail thread and saw the authors' responses, which quoted RFC
3967 :

   o  A standards document may need to refer to a proprietary protocol,
      and the IETF normally documents proprietary protocols using
      informational RFCs.

I am not convinced that this is one of the cases that this bullet was supposed
to cover. Additionally, I could not find in meeting minutes that this was ever
discussed in the wg, as was suggested in the mail thread [2]. I'd like to know
if the resp AD is aware of any related discussion after this point was raised.

Another point the authors made in favor of keeping this std track was that they
haven't seen any YANG data model published as informational. Again, I am not
convinced that this is reason enough to progress this as std track.

I note that this was reported in the shepherd write up [3] and in the last call
[4], so won't block progress after a discussion, but I do think it is worth
talking about. Please let me know if I missed anything.

Thanks,
Francesca

[1] https://mailarchive.ietf.org/arch/msg/opsawg/2mRkaXy5M9XCPp4_wXNpQd9GLdk/
[2] https://mailarchive.ietf.org/arch/msg/opsawg/MOnCfYBS3j4wBnZWDjl_YQHfvzg/
[3]
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-yang/shepherdwriteup/
[4] https://mailarchive.ietf.org/arch/msg/opsawg/FJmtUtB0x8tV0MUdO9Uhvc2e1p0/

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 22 Apr 2021 09:02:22 +0000

Hi Francesca,

Thanks for your review and comments.  Happy to discuss this in today's telechat if that helps.  I have also provided some comments inline.  My comments are also somewhat inline with my comments to Roman's discuss, so perhaps worth seeing my reply to Roman if you have not already done so.

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Francesca Palombini via
> Datatracker
> Sent: 21 April 2021 17:30
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Joe Clarke (jclarke) <[email-masked]>; opsawg-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Francesca Palombini's Discuss on draft-ietf-opsawg-tacacs-yang-
> 10: (with DISCUSS)
> 
[RW] 

I don't know, but assuming that the discussion happening around the time of Eliot's message then that would have been before I was an AD.  I don't know if the WG chairs recall more of the discussion that occurred?

> convinced that this is reason enough to progress this as std track.
[RW] 

My personal opinion is that Stds Track is generally the right classification for YANG modules standardized in the IETF.

In this particular case, I think that there is a distinction between a proprietary protocol that has correctly been documented in an informational RFC (RFC 8907), and a standard management API (i.e., MIB or YANG model) for configuring and managing that protocol that has been developed and evolved in the IETF.

In addition, I understand that there is also a desire to improve some of the security aspects for how TACACS+ is configured.  Although from a technical perspective it doesn't matter at all, if IETF produces a YANG module that augments this YANG module with extra security parameters, I would expect such a document to be Stds Track, and building on this document as Stds Track may possibly be easier process wise in the future.

I suspect that there will be further examples of this over time, and whilst I am loathed to introduce any more process into the IETF, the routing ADs were also asking for guidance on what document status to use (in that case for an experimental protocol).  I suspect that agreeing some informal guidance within the IESG might be helpful (action for me).

Regards,
Rob

> [1]
> https://mailarchive.ietf.org/arch/msg/opsawg/2mRkaXy5M9XCPp4_wXNpQd9GLdk/
> [2]
> https://mailarchive.ietf.org/arch/msg/opsawg/MOnCfYBS3j4wBnZWDjl_YQHfvzg/
> [3]
> [4]
> https://mailarchive.ietf.org/arch/msg/opsawg/FJmtUtB0x8tV0MUdO9Uhvc2e1p0/
> 
> 
> 
>

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 22 Apr 2021 12:56:51 +0000

> I don't know, but assuming that the discussion happening around the time of Eliot's message then that would have been before I was an AD.  I don't know if the WG chairs recall more of the discussio…

I don't think a more recent conversation has occurred, but I do think a
downref is acceptable here given the additional text in 8067 that WGs
produce foundational documents at the Informational level that define
architecture and terminology.  While the T+ document is not a framework
per se, it is a foundational document that describes the T+ protocol as
it exists today in order to provide a basis for extending it. 

> In addition, I understand that there is also a desire to improve some of the security aspects for how TACACS+ is configured.  Although from a technical perspective it doesn't matter at all, if IETF…

I agree here.  I would also think the document that defines how real
security interacts with T+ would also be StdsTrack.

Joe