Hi Benoît,
Thank you for the interest and also for digging into the practicalities.
Please see inline.
Cheers,
Med
De : Benoit Claise <benoit.cla...@huawei.com>
Envoyé : mardi 1 avril 2025 15:31
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>;
ops-...@ietf.org; opsawg@ietf.org; adr...@olddog.co.uk
Cc : Carlos Pignataro <cmpig...@ncsu.edu>; me <benoit.cla...@huawei.com>
Objet : Re: [OPSAWG]RFC5706 (Refresh): Guidelines for Considering Operations
and Management
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
[Med] :-)
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
[Med] Agree
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?
[Med] No. These will be developed in NMOP and should not be covered in this
document.
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
[Med] This can be be used by the opsdir, but this is not the main target.
2.3 Or maybe the goal is to impose a compulsory Manageability Considerations
section in all IETF drafts?
[Med] Yes. We need to find the right balance between providing clear guidance
while avoiding some rigidity. We will explore that path together with other
areas.
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?
[Med] This is not the main objective, but we can discuss if it is worth
educating the community about the new approach in OPSAWG.
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.
[Med] Agree.
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.
[Med] We are in agreement. More details to come in the plan I will be sharing
this week.
4. The appendix A should be part of the core document.
[Med] Carlos also asked for this.
Regards, Benoit
On 3/28/2025 8:09 AM,
mohamed.boucad...@orange.com<mailto: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:
1. More clarity on the terminology and leverage the work led by Adrian in
NMOP
2. IM part
3. More guidance on the importance of DMs
4. Soften the MIB part
5. Add more YANG
6. 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<mailto:opsawg@ietf.org>
To unsubscribe send an email to
opsawg-le...@ietf.org<mailto:opsawg-le...@ietf.org>
____________________________________________________________________________________________________________
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 to opsawg-le...@ietf.org
