Re: [netconf] draft-ietf-netconf.... YANG

["Hartley, Jeff" <[e-mail]>]

As a downstream consumer of the files, both as a BBF YANG author and further-downstream implementer, I'll offer a counterpoint:  All of your time and effort was worthwhile.

Every review comment, nit that was picked, etc. has produced a set of files that I/we have already been using for multiple applications - and indeed, incorporated into new standard interfaces / interconnections utilized by higher-layer protocols.  Multiple projects were in need of a variety of TCP, SSH, NETCONF, and RESTCONF client and server endpoints, with and without various cryptography features enabled.  This suite, and everyone's ~8 years of efforts have produced that.  The files work, and without them we'd have written up a dozen-plus different methodologies ourselves.  (In one case, that actually happened, BECAUSE the files were not yet "RFC-finalized" yet.)  I'd argue that we're at the point of the old cliché applying here re: "perfection-versus-good-enough," etc.  The reusable groupings alone are consistently useful.

I led a "IETF Client-Server Suite" intro/tutorial session at the BBF Q1 conference last week, and it was well-attended.  Since folks around the IETF often don't see the end-result of their efforts, perhaps that helps.  The massive set of inter-related gaps is largely satisfied by this set of inter-related YANG models.

So, Thanks!
-JH


From: netconf <[e-mail]> On Behalf Of tom petch
Sent: Thursday, March 30, 2023 7:44 AM
To: Kent Watsen <[e-mail]>
Cc: [e-mail]
Subject: [netconf] draft-ietf-netconf.... YANG

Kent This is more of a personal message but one I think, on balance, is worth sharing. When the in excess of 600 pages of netconf YANG were last called in the WG, I set out to review them but gave up
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=Y29tbXNjb3BlL2plZmYuaGFydGxleUBjb21tc2NvcGUuY29tLzdhYTg2MDY3YWI2OTIxZjY5MjEyODliZmEzYTNiMTE2LzE2ODAxNzY2ODAuMDQ=#key=080d8575cc63b95bcf4e59e94ab1f7bd>  FAQ<https://www.inky.com/banner-faq>  Protection by INKY<https://www.inky.com/protection-by-inky>


Kent



This is more of a personal message but one I think, on balance, is worth sharing.



When the in excess of 600 pages of netconf YANG were last called in the WG, I set out to review them but gave up - it was too time consuming.



When the Shepherd Reviews came out, I made another attempt - ditto,



When a fresh set appeared, 12dec2022, I made more of an effort but did not get very far.  Finally, after Christmas, I set my mind to it and completed the task this week.  It has taken most of the time I have available for IETF work for over two months to review them.  (I note that the AD reviews are taking their time too).



They are hard to review.  I mark up my copies and a frequent appearance is the work 'somersault' reflecting a very different way of doing things to an earlier version.  I recall commenting to the list that I had given up because of such changes, the complexity and so on.  The size, the structure, the approach all make it costly in time - I will be interested to see what the .art reviewers make of them in Last Call.  I wonder too how long Last Call will be - for me, even four weeks would not be enough.



I think I have responded, eventually, to all your comments except a query about CJK (the pictogram languages of the East where one character becomes many octet in the context of how long is a piece of string when used as a name).  If you think any are outstanding, then I need a reminder of them.



Was the review worth it?  Probably not.  I picked up some editorial issues but nothing significant, such as the problematic constraint on anchor time.  I would have picked up the incorrect port numbers but the Shepherd spotted those first.



I will not do it again.  I might look to see how my comments have been addressed in new versions but will not review them again.



At the end, I had two thoughts.   One is the obvious one, that changing requirements when the design is 'done' costs.  The other, more obscure, is of a relational database that the YANG can be viewed on many axes - TLS v SSH, persistent v periodic, initiate or listen, client v server and so on and I am uncertain which of those should take precedence over the others, which should be the key to the table.  The current structure of the modules reflects a certain view - I am unsure if it is the best one but that is not going to change now!



Tom Petch



637

_______________________________________________

netconf mailing list

[e-mail]<mailto:[e-mail]>

https://secure-web.cisco.com/1rVb6piogtfwSbk2pEu-DBlQTjnQGAbhv5_I2ilXcTQikRJJuS8Blhvs0a_mcbJKPtiaqYaPvsGV4tj1iRzIVG2NiXOXBuvPxc1hYZQfit0HvFfHXsxhVjoyLi6xiCP4b_SKdozGK7ZHCgneJMS2L4TOEl1I16TJlznAt-zsSWYJ4-uOIqyHCfL9Bxb_E4TEvz7bcNdou8Q1Qoq-9nmL5WzRYi2BOzJDPvDrh9YjmMJjsnlVvmd5imYA4cieB5ujSeoape6BQwmemDPRKj1r_TAfjO8ajSrpQoRV0ou-a4Fy8oLESEJH0O0rJkJ-4bpcj/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetconf