[Nemops-interest] Re: [arch-d] Re: NEMOPS Workshop Report

[Arnaud Taddei <[e-mail]>]

Likewise this is very interesting report.

There are many things I like in this report and I particularly like point 3
of 3.4.1 as we have the exact same problem in security and I find 3.4.4
very real.

Thank you

Arnaud Taddei

Global Security Strategist | Enterprise Security Group | ITU-T SG17 chair

mobile: [phone]

Geneva, Switzerland

[e-mail] | broadcom.com


On Thu, Feb 20, 2025 at 8:37 PM Michael Richardson <[e-mail]>
wrote:

>
> Thank you for the write up.
>
> Dhruv Dhody <[e-mail]> wrote:
>     > Wes and I have posted the initial version of the NEMOPS Workshop
> Report -
>
>     > https://datatracker.ietf.org/doc/draft-iab-nemops-workshop-report/
>     >
> https://www.ietf.org/archive/id/draft-iab-nemops-workshop-report-01.html
>
>     > We’d appreciate your feedback, ideally on the
> [e-mail] list
>     > or directly to the authors. You can also submit a PR on GitHub:
>
> }   Many operators
> }   prioritize operational conferences over standards development
> }   organizations (SDOs), such as RIPE, NANOG, APRICOT, LACNIC, AutoConn,
> }   etc.
> }
> }   To address this, the IAB workshop's Program Committee (PC) planned
> }   outreach initiatives to foster discussions and gather interest by
> }   engaging with operators at these venues and conducting information/
> }   requirement-gathering sessions.  Participants were encouraged to
>
> Did we succeed in getting more operators to the workshop?
> I observed the PC outreach at RIPE89, but I'm not sure it resulted in the
> groundswell that was desired.
>
> Yesterday, I walked a new (very young) network admin through adding a new
> [not new to us, just been sitting in a box since 2019] switch CREDIL.org's
> network monitoring tool... That is, we connected it to SNMP...
> The level of idiosyncracy is great, caused in large part by
> heterogeneous equipment which is definitely not new.
> We (had to) fixed quite a number of things along the way, so it took about
> 5 hours.
> This was the new person's first experience with Cisco-style router CLIs,
> and
> she was really impressed with how useful completion was.  We used a Web
> interface for a bit to add a static IPv6 for the control access, but the
> Web
> interface *did the wrong thing*.  We never spoke of YANG.
> We use tftp to backup configurations, which we then manually check into
> git.
> ("git app -p" is very good way to review what you actually did, and also to
> learn what went wrong with the web interface attempt)
>
> We'd love to use scp, but the security posture of it is almost worse.
> We also never get ssh access to our switches to work consistently, so
> serial
> consoles are mandatory as backup, and guess what: RESTCONF does not work
> across that link.   RFC8994 would be nice.
> (Yes, I have running code)
>
> I don't think section 3.1.3 really articulates this well enough:
> "Additionally, the lack of
>  simple tools for smaller networks operating under tight timelines and
>  budgets was emphasized."
>
> this is just insufficient emphasis here.
> I could think to replace all of section 3.1.x with:
>   "Additionally, the lack of
>    simple tools other than Net-SNMP for smaller networks operating under
>    tight timelines, a mix of older and newer systems and very small budgets
>    was emphasized."
>
> Organizations slightly larger than CREDIL typically "solve" these problems
> by buying all same-vendor equipment every ~10 years or so.  It comes with a
> thick manual which one person reads, just before being lured away by higher
> salary to be an Application Engineer for said vendor.  If they were rich at
> the time, or the discount was large, they bought the management platform
> with
> a pretty interface, but in practice no ability to do anything really
> useful.
>
> section 3.2 seems to all be about problems with managing systems at larger
> scale.  My complaint all along is that RESTCONF(YANG) does not scale.
> Scale doesn't
> mean "big", it means, something can work from smallest to largest scale.
> RESTCONF
> doesn't work in the small.  One never starts a three switch network with
> RESTCONF, and then use it as you grow.  One starts with a three hundred
> switch network.
>
> Lots of talk about open source, but not really any mention of how such a
> thing could be funded.  That's really the problem.
>
>
> }   1.  In network deployments, operations are typically at the bottom of
> }       the ladder.  It's the most squeezed for time and resources.
> }       Network engineers are not typically seasoned developers.
>
> It's way way worse than that.  Most government and NGO network engineers
> are
> prevented by policy (from their own organization!) from even having
> developer
> tools on their desktop.  Getting access to equipment to do testing on (like
> developing new tools) is essentially impossible in many places.
>
> }   4.  It was suggested that other domains (e.g., K8N/automation) are
> }       years ahead of the current network engineering stack.
>
> k8n has useless networking.  It's "years ahead", in that it does a few
> things
> autonomically, but does them wrong.  Managers are told the wrong way is
> "better"
>
> }   5.  There was a point about navigating non-device-specific models
> }       being difficult.  If understood correctly, the Network Engineer
> }       knows the CLI command but has trouble grepping for it in YANG
> }       modules defined by SDOs.
>
> I can discover most anything in the CLI by hitting TAB/? enough.
> One switches and routers which I've never touched or read the manual for.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT
> architect   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
>
>
>
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
> _______________________________________________
> Architecture-discuss mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.