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 <iesg-boun...@ietf.org> On Behalf Of Francesca Palombini via > Datatracker > Sent: 21 April 2021 17:30 > To: The IESG <i...@ietf.org> > Cc: opsawg@ietf.org; Joe Clarke (jclarke) <jcla...@cisco.com>; opsawg- > cha...@ietf.org; l...@cisco.com; draft-ietf-opsawg-tacacs-y...@ietf.org > Subject: Francesca Palombini's Discuss on draft-ietf-opsawg-tacacs-yang- > 10: (with DISCUSS) > > 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. [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? > > 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. [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 > > 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/ > > > > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
