Hi Med,
I re-read the document before answering.
My conclusion:
yes, it's time to update this document.
yes, I am ready to drive this, as this topic is close to my heart
A couple of high level points.
1. It's time to update this document, as it mainly focuses on MIB
developments
Example 1:
Most of the existing IETF management standards are focused on using
Structure of Management Information (SMI)-based data models (MIB
modules) to monitor and manage networking devices.
...
For years the IETF community has used the IETF Standard Management
Framework, including the Simple Network Management Protocol
[RFC3410 <https://www.rfc-editor.org/rfc/rfc3410>], the Structure of Management
Information [RFC2578 <https://www.rfc-editor.org/rfc/rfc2578>], and MIB
data models for managing new protocols.
Example 2:
https://datatracker.ietf.org/doc/statement-iesg-writable-mib-module-iesg-statement-20140302/
has been written 5 years after this document, and should be integrated
in a new version.
Because this documents was produced in 2009, it missed some new
OPS-related technologies (protocols and data models): BMP, Alt Mark,
NETCONF/RESTCONF, YANG
2. Here is the main important to me: what do we want to achieve with
this document?
2.1 I see for example this requirement, stemming from RFC3535 (see
section 3, req 4)
Protocol designers should consider how to enable operators to
concentrate on the configuration of the network as a whole rather
than on individual devices.
*So is the goal to include those RFC 3535 requirements in RFC5706bis?*
If yes, should we include the NEMOPS
<https://datatracker.ietf.org/group/nemopsws/about/>requirements,
mentioned in draft-iab-nemops-workshop-report-01
<https://datatracker.ietf.org/doc/draft-iab-nemops-workshop-report/> ?
But then, where do we stop? For example, in NEMOPS, we discussed at
length the need for tools: are we going to mention something such as
"protocol designers should have tools developed at the hackathon". Sure,
this is common sense, but also just wishful thinking, and we have no way
to enforce this
Note also the existence of draft-boucadair-nmop-rfc3535-20years-later
<https://datatracker.ietf.org/doc/draft-boucadair-nmop-rfc3535-20years-later/>
Personally, I believe there is no point to duplicate all requirements in
RFC5706bis
2.2 *Or maybe the only goal is to help the OPS directorate?*
https://wiki.ietf.org/en/group/ops/Directorates clearly mention RFC 5706
2.3 *Or maybe the goal is to impose a compulsory Manageability
Considerations section in all IETF drafts?*
IIRC, I tried to push that idea when I was AD but I guess that the
community was not ready at that time. Interestingly, the security
considerations is compulsory ;-)
I obviously still believe we should pursue this goal, pushing for RFC
6123 for all documents.
How many times did I hear: "if I can't automate this feature, it doesn't
exist!"
If there are no "Manageability Considerations" required, then at least
the shepherd write-up should justify why.
2.4 *Or maybe the goal is to set the direction for the community? *
As just one example: IM (as mentioned by Med).
There is right now a discussion about IM vs DM (based on RFC3444)
regarding Information and Data Models for Packet Discard Reporting
<https://datatracker.ietf.org/doc/draft-ietf-opsawg-discardmodel/>where
the authors decided to go for a YANG IM, and subsequence YANG and IPFIX
DMs. This is the first occurrence: Do we as a community, or do the ADs,
have some guidelines to provide here, in this document?
If yes, this document would provide a set of guidelines for future
documents.
One note on setting the direction. I read:
Protocol designers
should avoid having manageability pushed for a later phase of the
development of the standard."
That also come from the charter, where the OPS ADs should strive to have
manageability document deliverables, part of the charter.
3. Depending on what we want to achieve in point 2, we will have to
decide on the intended status.
If the goal is to push a new manageability section, then "Informational"
is not right.
4. The appendix A should be part of the core document.
Regards, Benoit
On 3/28/2025 8:09 AM, mohamed.boucad...@orange.com wrote:
Hi all,
15 years after the publication of this important document, I think
that it is time to consider a refresh.
I’m sending this note to gauge interest and hopefully find volunteers
to explore this path with the aim to produce a bis. Areas that can be
easily revisited are:
* More clarity on the terminology and leverage the work led by
Adrian in NMOP
* IM part
* More guidance on the importance of DMs
* Soften the MIB part
* Add more YANG
* Consider if we can generalize the approach in RFC6123 (edited by
Adrian)
Suggestions/thoughts are welcome.
Cheers,
Med
PS: Thanks Carlos for planting the seed in my head.
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
OPSAWG mailing list --opsawg@ietf.org
To unsubscribe send an email toopsawg-le...@ietf.org
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
