Re: [Netmo] John Scudder's No Objection on charter-ietf-nmop-00-00: (with COMMENT)

Hi Rob,

Sorry I didn't reply to this earlier. I see what you're saying, but I continue to be unconvinced that "this is a placeholder for a possible future recharter" is a good use of space in the current charter. This is partly because I feel like the more a charter becomes a wall of text, the less useful it is. I'm not going to block on this basis though. I'll update my ballot accordingly.

--John

> On Dec 1, 2023, at 11:26 AM, Rob Wilton (rwilton) <rwilton@cisco.com> wrote:
> 
> Hi John,
> 
> Thanks for the feedback - my rational is simply that I can easily imaging that this WG may well be suitable to do small bits of protocol work (such to the constraints), but I don't know exactly what they are now.  Once the WG gets going, I will push the operators to help agree what it their topic priorities issues to focus on.  So, really I'm trying to put a stake in the ground now to say that is allowed rather than a future IESG claiming that, no, the WG was only ever chartered/intended as an Informational/BCP only WG.  So, perhaps it is just forward guidance?
> 
> To give some examples of the potential topics that the WG may focus on are:
> 
>> (1) YANG Telemetry/Kafka integration
> - The protocol updates for this is already happening in NETCONF and OPSAWG
> 
>> (2) Issues related to mapping configuration, and agreement on north bound
>> interfaces from the device (protocol and model families)
> - I don't know what will come out of this.
> 
>> (3) Anomaly detection and Incident management
> - This could involve defining small models for defining incidents - once we know the size of the work, it may become more clear if that should happen here or in a dedicated WG.
> 
>> (4) Issues related to deployment/usage of YANG topology modules (e.g.,
>> digital map)
> - This is likely to involve wanting to update the YANG topology RFC (that was standardized in I2RS), but this might be a reasonable home for that update (in RTG ADs agree).
> 
>> (5) Controller architectures for management of pluggable optics (there are
>> several drafts currently in CCAMP)
> - This is an architecture/framework doc rather than protocol work.
> 
>> (6) An update of operator requirements on Network Mgmt
>> protocols/modelling within the IETF.  E.g., something like RFC 3535-bis.
> - I see that Med has already started formulating a draft on this :-)
> 
>> (7) Handling capabilities.
> - I'm not sure exactly where this should go.  I think that this idea needs a place to incubate and then figure out whether it goes to NETMOD or a new WG.
> 
> I think that some of these could involve protocol work, and I will push the Operators/WG to choose 2 or 3 topics to focus on, hence it is possible in 6 months time the WG may recharter to list some specific protocol/model enhancements (e.g., updating the YANG topology module produced by I2RS maybe).
> 
> Does that shed any more light on why I'm somewhat keen to keep that text in?
> 
> Regards,
> Rob
> 
> 
>> -----Original Message-----
>> From: John Scudder <jgs@juniper.net>
>> Sent: Friday, December 1, 2023 4:08 PM
>> To: Rob Wilton (rwilton) <rwilton@cisco.com>
>> Cc: The IESG <iesg@ietf.org>; nmop-chairs@ietf.org; netmo@ietf.org
>> Subject: Re: [Netmo] John Scudder's No Objection on charter-ietf-nmop-00-
>> 00: (with COMMENT)
>> 
>> Hi Rob,
>> 
>> Yes, that’s a good improvement, thanks. I’m still a little baffled why it needs to
>> be there, since as I understand it, the whole thing could be summed up by the
>> first clause:
>> 
>>> The WG charter does not currently include any IETF protocol or data
>>> model work
>> 
>> Or even by no clause at all, since of course, you’re not going to enumerate all
>> the things the working group is not chartered to do.
>> 
>> It goes without saying, or should go without saying, that any work not in
>> scope for the current charter, could be in scope for a future recharter. So, I’m
>> not entirely sure why you’re saying it! I guess maybe all the sub-bullets are
>> way of saying “don’t do protocol work in this working group, take it to these
>> other working groups instead“? Kind of a mini-FAQ embedded in the charter?
>> 
>> Anyway, although I’m puzzled by the choice to go into these details, I don’t
>> see it as being a reason to hold up external review.
>> 
>> —John
>> 
>>> On Dec 1, 2023, at 10:47 AM, Rob Wilton (rwilton) <rwilton@cisco.com>
>> wrote:
>>> 
>>> Hi John,
>>> 
>>> I hope that I have addressed your comments.  The latest version of the
>> charter is here:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/charter-ietf-
>> nmop/00-01/__;!!NEt6yMaO-
>> gk!HkOOTRKLEdbTkT_fHYI3T_TzbMBjUhJC6mb_JFUO-nM-
>> 298NxtgzLt6wOv_QB5aeoJcN0o8G_7Br$
>>> 
>>>> -----Original Message-----
>>>> From: Netmo <netmo-bounces@ietf.org> On Behalf Of John Scudder via
>>>> Datatracker
>>>> Sent: Wednesday, November 29, 2023 7:55 PM
>>>> To: The IESG <iesg@ietf.org>
>>>> Cc: nmop-chairs@ietf.org; netmo@ietf.org
>>>> Subject: [Netmo] John Scudder's No Objection on charter-ietf-nmop-00-
>> 00: (with
>>>> COMMENT)
>>>> 
>>>> John Scudder has entered the following ballot position for
>>>> charter-ietf-nmop-00-00: No Objection
>>>> 
>>>> 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.)
>>>> 
>>>> 
>>>> 
>>>> The document, along with other ballot positions, can be found here:
>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/charter-ietf-
>> nmop/__;!!NEt6yMaO-gk!HkOOTRKLEdbTkT_fHYI3T_TzbMBjUhJC6mb_JFUO-
>> nM-298NxtgzLt6wOv_QB5aeoJcN0mluyTF2$
>>>> 
>>>> 
>>>> 
>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>> 
>>>> I have a few comments on this section:
>>>> 
>>>> ```
>>>> - Implement small protocol enhancements to help facilitate deployment,
>>>> subject to the following constraints:
>>>> 
>>>> - Protocol extensions for protocols in scope for existing working
>>>> groups must be taken to those working groups unless there is an
>>>> agreement by the working group’s responsible area director and the
>>>> Operations/Management area director to progress the enhancement
>>>> within this working group.
>>>> 
>>>> - More significant protocol work (on existing or new protocols) is
>>>> out of scope for this working group and must be done in another
>>>> existing or new WG.
>>>> ```
>>>> 
>>>> First, I don't think you mean "implement", I think you mean "specify". The
>> IETF
>>>> and its working groups generally does not do implementation.
>>> [Rob Wilton (rwilton)]
>>> Fixed (and moved).
>>> 
>>>> 
>>>> Second, at least in the rendering I looked at, all these bullets appeared at
>>>> the same level. My assumption is, bullets two and three in the text I
>> quoted
>>>> are supposed to be sub-bullets.
>>> [Rob Wilton (rwilton)]
>>> Effectively fixed by moving the paragraph.  Interestingly it looked fine on
>> github ...
>>> 
>>>> 
>>>> Third and most important, I don't see why this is in the charter at all, given
>>>> that the first sub-bullet says that enhancements must be done in their
>> home
>>>> working groups anyway. If the intent is to say that nmop is a venue for
>> doing
>>>> enhancement of orphan protocols, that could be said much more clearly.
>>> [Rob Wilton (rwilton)]
>>> 
>>> I've now moved that section out of scope and have this section instead:
>>> 
>>> The WG charter does not currently include any IETF protocol or data
>>> model work, but the WG may decide to work on such items in future,
>>> subject to the following constraints:
>>> 
>>> * Protocol extensions for protocols in scope for existing working groups
>>> must be taken to those working groups unless there is an agreement by
>>> the area director responsible for the working group and the
>>> Operations/Management area director to progress the enhancement within
>>> this working group.
>>> 
>>> * OPSAWG remains the default working group to take small maintenance
>>> work for orphan network management specifications produced by
>>> concluded working groups unless there is particular operator interest
>>> and explicit agreement of the Operations/Management area director to
>>> progress the work here.
>>> 
>>> * More significant protocol work (on existing or new protocols) should
>>> be taken to an existing or new working group. I.e., protocol work is
>>> not the core focus of this working group.
>>> 
>>> * The working group charter and milestones must be updated beforehand
>> to
>>> cover any protocol or data model work to be undertaken here.
>>> 
>>> Hopefully this addresses your comments.
>>> 
>>> Regards,
>>> Rob
>>> 
>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Netmo mailing list
>>>> Netmo@ietf.org
>>>> 
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/netmo__;
>> !!NEt6yMaO-gk!HkOOTRKLEdbTkT_fHYI3T_TzbMBjUhJC6mb_JFUO-nM-
>> 298NxtgzLt6wOv_QB5aeoJcN0slx8UrK$