Re: [netmod] draft netmod charter update proposal

[Benoit Claise <[e-mail]>]

Mehmet,

As long as the WG items are in the milestones, we're good.

Regards, Benoit
> Hi Lou, Kent,
>
> I promised to provide some minimal text which can be used as WG item
> description.
> I'm fine with any fine tuning.
>
> See below:
>
>     a) Maintaining the data modeling language YANG.  This effort entails
>        periodically updating the specification to address new requirements
>        as they arise. ADD<This work is planned to address with a revision of
> RFC 7950./>
>
>     b) Maintaining the guidelines for developing YANG models.  This effort
>        is primarily driven by updates made to the YANG specification.
> ADD<This continuous effort has been recently addressed with a revision of
> RFC 6087./>
>
>     c) Maintaining a conceptual framework in which YANG models are used.
>        This effort entails describing the generic context that in YANG
>        exists and how certain YANG statements interact in that context.
>        An example of this is YANG's relationship with datastores. ADD<The
> revised datastore draft will provide a conceptual framework for the handling
> of datastores, which can be adopted by other WGs for their usage scenario./>
>
> . . .
>
>     e) Maintaining YANG models used as basic YANG building blocks.  This
>        effort entails updating existing YANG models (ietf-yang-types and
>        ietf-inet-types) as needed, as well as defining additional core YANG
>        data models when necessary. ADD<The WG will finalize ongoing work on
> the models for Syslog, ACL and Common Interface Extensions as well as the
> model for hardware management. The Schema mount draft will provide a
> mechanism to combine YANG modules into the schema defined in other YANG
> modules./>
>
> BTW: There is no topic description (in a)-f) covering YANG module
> classification.
> I assume it can be added with a sentence to a) or b).
>
> Thanks,
> Mehmet
>
>> -----Original Message-----
>> From: Mehmet Ersue
>> Sent: Thursday, March 16, 2017 11:59 PM
>> To: Lou Berger <[e-mail]>; 'Kent Watsen' <[e-mail]>;
>> [e-mail]
>> Cc: 'Benoit Claise' <[e-mail]>; 'Mahesh Jethanandani'
>> <[e-mail]>
>> Subject: RE: [netmod] draft netmod charter update proposal
>>
>>> From: Lou Berger [mailto:[e-mail]] Mehmet,
>>>     see below.
>>> On 3/16/2017 2:24 PM, Mehmet Ersue wrote:
>>>> Lou,
>> . . .
>>>> I actually provided a very simple proposal. You guys can fill the
>>>> idea with minimal text better than me. I'm fine whatever the text is.
>>>> If you think the high-level topic description a)-f) does already
>>>> define the WG item clearly you can simply say "this is achieved with
>>>> WG
>>> item XY".
>>>> If not, you can keep the high-level focus text but set additionally
>>>> the borders of the WG item with a few concrete words.
>>> I really can't tell for sure, but it feels to me that this comment
>>> boils down to a style comment and you have a preference for different
>>> contents in the charter.  I'd like to be sensitive to this.  As our
>>> style differs, having a concrete proposal on specific text changes
>>> would be really helpful in us (and the WG) evaluating the changes
>>> you'd like to see.  Without such specific examples and think we're
>>> left with the charter as currently proposed.  Perhaps someone else who
>> has similar feelings can chime in and provide proposed text.
>>> Anyone else have any comments or proposed changes?
>> I think the wording depends on the time period is for which the charter is
>> prepared.
>> I can try some text once I have time tomorrow.
>>
>> . . .
>>>> I think the DS draft provides a conceptual framework for diverse DS
>>>> usage scenarios to be used by many protocols, where IETF WGs may
>>>> actually decide using a subset of the DS framework for their purpose
>>>> and for their protocol standardization.
>>>> Based on this the conceptual framework cannot be standardized as it
>>>> is but the protocols using a consistent subset have to be
> standardized.
>>>> Following this consideration I think the intended status of the DS
>>>> draft should be changed to: Informational RFC If you agree please
>>>> indicate this change accordingly.
>>> I think Juergen's reply to your previous message highlights that there
>>> is a difference of opinion here based on the technical specifics of
>>> the draft.  My position as chair is that I'll support whatever makes
>>> sense based on the document produced by the WG.  Today the document
>>> authors believe PS is appropriate, once we have a version that is
>>> stabilizing for LC -- which hopefully will be the next version or two
>>> -- then will be a good time to revisit this.
>> There are indeed different opinions concerning the goal of the DS draft.
>> I agree with the document introduction and see it as a conceptual
> framework
>> covering many usage scenarios.
>> Such a conceptual framework describing possible solutions is informational
> in
>> nature and is not relevant for standardization.
>>
>>>>>> This is as I think also important to avoid an overlapping between
>>>>>> NETCONF and NETMOD charters.
>>>>> I don't follow this point.  Certainly I'd hope that the protocol
>>>>> impact of revised DS are covered in a PS document, unless for some
>>>>> reason there are no "on-the-wire" changes needed.  TI wouldn't
>>>>> expect that the document status of the base revised data store
>>>>> document would
>>> impact that.  Do you?
>>>>> If so, how?
>>>> My comment is actually superfluous if you agree with my
>>>> considerations above.
>>>> The worst case would in my opinion happen if the DS conceptual
>>>> framework covering many high-level DS usage scenarios would be
>>>> attempted to standardize, which at the end would prescribe protocol
>>>> WGs what they should be standardizing.
>>> Yang presumes a certain set of functions for the protocols it operates
> over.
>>> I'm not sure why having a document that specifies this would be an
> issue.
>> This is again an interesting discussion which SHOULD be discussed in a
> joint
>> session.
>> I don't have a strong opinion but it can be seen differently.
>>
>>>> In such a case the conceptual framework would most likely cause a
>>>> competing situation with protocol WG's goals and documents and
>>>> cannot be adopted successfully.
>>> If a protocol doesn't provide full support for yang (requirements) it
>>> can't fully support all yang features.  If your point is that when
>>> NetMod changes basic yang functions/operations that this might
>>> constrain the protocols (and related WGs) over which it operates, then
>>> I agree that this is the case. How could it be otherwise?
>> Usually modeling languages provide many language constructs and people
>> modeling models choose which one is best for their purpose.
>> The same applies to the DS concept framework. The protocol WGs would like
>> to have the freedom to choose the subset to adopt from the protocol pov.
>>
>>> Thanks,
>>>
>>> Lou
>>>
>>>> Thanks,
>>>> Mehmet
>>>>
>>>>>> PS: I expect that most of the Netconf WG member read also the
>>> Netmod
>>>>>> maillist and therefor skip sending to both ML.
>>>>>>
>>>>> Great.
>>>>>
>>>>> Thanks.
>>>>> Lou
>>>>>> Thanks,
>>>>>> Mehmet
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Mehmet Ersue
>>>>>>> Sent: Thursday, March 9, 2017 7:36 PM
>>>>>>> To: Lou Berger <[e-mail]>; 'Kent Watsen'
>>>>>>> <[e-mail]>; [e-mail]
>>>>>>> Cc: 'Benoit Claise' <[e-mail]>; 'Mahesh Jethanandani'
>>>>>>> <[e-mail]>
>>>>>>> Subject: RE: [netmod] draft netmod charter update proposal
>>>>>>>
>>>>>>> Hi Lou,
>>>>>>>
>>>>>>>> The charters from the last couple of years don't have the
>>>>>>>> intended
>>>>>> status --
>>>>>>> at least the ones we checked.
>>>>>>>> I actually feel pretty strongly about this (which of course can
>>>>>>>> be easily overruled by our AD).  It's my experience that
>>>>>>>> premature discussions on intended status, i.e., before a
>>>>>>>> document is sufficiently
>>>>>>> mature, leads to process-focused arguments that detracts from
>>>>>>> making technical progress.  While once a document is mature and
>>>>>>> core direction/content is fixed, it is generally obvious what
>>>>>>> status is
>>>>>> appropriate.
>>>>>>> The charters from the last couple of years have a short WG item
>>>>>> definition,
>>>>>>> which would be IMO sufficient.
>>>>>>> You are right the intended status is not available since a few
>>>>>>> years, but
>>>>>> IMO it
>>>>>>> is part of the target definition and would be very useful for the
>>>>>>> draft
>>>>>> authors
>>>>>>> and WG members to regard.
>>>>>>>
>>>>>>>>> It would be good to bring the high-level topics in relation to
>>>>>>>>> the WG
>>>>>>> items.
>>>>>>>> I'm sorry, I don't understand this last sentence can you rephrase
> it?
>>>>>>> What I meant is that the high-level topics a)-f) might be good as
>>>>>>> WG focus description but are not sufficient as draft target
> definition.
>>>>>>> If you think the high-level topic description is more or less the
>>>>>>> WG item definition, then we could simply write "this is achieved
>>>>>>> with WG
>>>> item
>>>>> XY".
>>>>>>> If not, we could keep the high-level focus text but set
>>>>>>> additionally the borders of the WG item with some concrete words.
>>>>>>>
>>>>>>>>> BTW: We agreed in diverse discussions that the DS concept is
>>>>>>> Informational in nature.
>>>>>>>>> I think this should be corrected in the draft.
>>>>>>>> So this sounds like an objection to a specific document.  This
>>>>>>>> is a fair point to raise, but in our opinion it is not a charter
>>>>>>>> impacting point or discussion.  If this is in fact the issue
>>>>>>>> you'd like to raise and discuss, lets do so under a document
>>>>>>>> specific thread, e.g.,
>>>>>> "Subject:
>>>>>>> intended status of revised-datastore".
>>>>>>>
>>>>>>> I am actually raising this point since November meeting. There
>>>>>>> are
>>>>>> different
>>>>>>> threads where I explained why it is appropriate as Informational.
>>>>>>> The last thread I remember is at:
>>>>>>>
>> https://mailarchive.ietf.org/arch/msg/netmod/1ju_CamUPnzCCeqmlFR5JH1
>>>>>>> 1xcY
>>>>>>> The recent position of NETCONF co-chairs is in
>>>>>>>
>> https://mailarchive.ietf.org/arch/msg/netconf/oMBYwr5GMsmBfotKJ_2_cd
>>>>>>> 8qr5k
>>>>>>>
>>>>>>> Thank you for your consideration.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mehmet
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Lou Berger [mailto:[e-mail]]
>>>>>>>> Sent: Wednesday, March 8, 2017 11:28 PM
>>>>>>>> To: Mehmet Ersue <[e-mail]>; 'Kent Watsen'
>>>>>>>> <[e-mail]>; [e-mail]
>>>>>>>> Subject: Re: [netmod] draft netmod charter update proposal
>>>>>>>>
>>>>>>>> Hi Mehmet,
>>>>>>>>
>>>>>>>> On 3/8/2017 4:47 PM, Mehmet Ersue wrote:
>>>>>>>>> Kent,
>>>>>>>>>
>>>>>>>>>> we understand that this is how NETCONF charters are
>>>>>>>>>> structured, but it is not our practice,
>>>>>>>>> AFAIK it was the NETMOD practice for the charters until today.
>>>>>>>> The charters from the last couple of years don't have the
>>>>>>>> intended status -- at least the ones we checked.
>>>>>>>>
>>>>>>>> I actually feel pretty strongly about this (which of course can
>>>>>>>> be easily overruled by our AD).  It's my experience that
>>>>>>>> premature discussions on intended status, i.e., before a
>>>>>>>> document is sufficiently mature, leads to process-focused
>>>>>>>> arguments that detracts
>>>>>> from
>>>>>>> making technical progress.
>>>>>>>> While once a document is mature and core direction/content is
>>>>>>>> fixed, it is generally obvious what status is appropriate.
>>>>>>>>
>>>>>>>>
>>>>>>>>> I did not ask
>>>>>>>>> more than written in the current charter.
>>>>>>>>> It would be good to bring the high-level topics in relation to
>>>>>>>>> the WG
>>>>>>> items.
>>>>>>>> I'm sorry, I don't understand this last sentence can you rephrase
> it?
>>>>>>>>>> as the information is available at the top of each draft, and
>>>>>>>>>> also because
>>>>>>>> this information need not be fixed when the milestone is added.
>>>>>>>>
>>>>>>>>> I believe a WG charter should be self-sufficient covering the
>>>>>>>>> target definition and intended status of the WG items.
>>>>>>>>> Otherwise one can change the target for a WG item by simply
>>>>>>>>> editing the draft abstract anytime.
>>>>>>>> Per IETF process, all it ever takes to make a change in document
>>>>>>>> status is WG consensus, and then IESG and IETF buy-in as part of
>>>>>>>> the
>>>>>>> publication process.
>>>>>>>>> BTW: We agreed in diverse discussions that the DS concept is
>>>>>>>>> Informational in nature.
>>>>>>>>> I think this should be corrected in the draft.
>>>>>>>> So this sounds like an objection to a specific document.  This
>>>>>>>> is a fair point to raise, but in our opinion it is not a charter
>>>>>>>> impacting point or discussion.  If this is in fact the issue
>>>>>>>> you'd like to raise and discuss, lets do so under a document
>>>>>>>> specific thread, e.g.,
>>>>>> "Subject:
>>>>>>>> intended status of revised-datastore".
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Lou
>>>>>>>>
>>>>>>>>> Mehmet
>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: netmod [mailto:[e-mail]] On Behalf Of
>>> Kent
>>>>>>>>>> Watsen
>>>>>>>>>> Sent: Wednesday, March 8, 2017 7:45 PM
>>>>>>>>>> To: [e-mail]
>>>>>>>>>> Cc: [e-mail]
>>>>>>>>>> Subject: Re: [netmod] draft netmod charter update proposal
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi NETMOD WG,
>>>>>>>>>>
>>>>>>>>>> Please find below draft-4 having the following change:
>>>>>>>>>>
>>>>>>>>>>   - added "(e.g., I2RS, RTGWG)" to a sentence.
>>>>>>>>>>
>>>>>>>>>> Hi Sue, Lou and I looked at the proposed charter and found a
>>>>>>>>>> sentence that nicely describes our WG's intent to work with
>>>>>>>>>> and support other WGs (beyond NETCONF), but we felt that the
>>>>>>>>>> text could be made more clear by adding in the above-mentioned
>>> change.
>>>>>>>>>> Beyond this, and the existing a),
>>>>>>>>> b),
>>>>>>>>>> and c), we believe that the charter proposal covers our
>>>>>>>>>> support for I2RS,
>>>>>>>>> do
>>>>>>>>>> you agree?
>>>>>>>>>>
>>>>>>>>>> Hi Mehmet, regarding putting a short description and the
>>>>>>>>>> intended status
>>>>>>>>> for
>>>>>>>>>> each draft into the charter, we understand that this is how
>>>>>>>>>> NETCONF
>>>>>>>>> charters
>>>>>>>>>> are structured, but it is not our practice, as the information
>>>>>>>>>> is
>>>>>>>>> available at the
>>>>>>>>>> top of each draft, and also because this information need not
>>>>>>>>>> be fixed
>>>>>>>>> when
>>>>>>>>>> the milestone is added.
>>>>>>>>>>
>>>>>>>>>> All, Any other comments?
>>>>>>>>>>
>>>>>>>>>> Kent
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Network Modeling (NETMOD)
>>>>>>>>>> -------------------------
>>>>>>>>>>
>>>>>>>>>> Charter
>>>>>>>>>>
>>>>>>>>>> Current Status: Active
>>>>>>>>>>
>>>>>>>>>> Chairs:
>>>>>>>>>>     Lou Berger <[e-mail]>
>>>>>>>>>>     Kent Watsen <[e-mail]>
>>>>>>>>>>
>>>>>>>>>> Operations and Management Area Directors:
>>>>>>>>>>     Benoit Claise <[e-mail]>
>>>>>>>>>>     Joel Jaeggli <[e-mail]>
>>>>>>>>>>
>>>>>>>>>> Operations and Management Area Advisor:
>>>>>>>>>>     Benoit Claise <[e-mail]>
>>>>>>>>>>
>>>>>>>>>> Secretary:
>>>>>>>>>>     Zitao (Michael) Wang <[e-mail]>
>>>>>>>>>>
>>>>>>>>>> Mailing Lists:
>>>>>>>>>>     General Discussion: [e-mail]
>>>>>>>>>>     To Subscribe:
>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>>>>     Archive:
>>>>>> https://mailarchive.ietf.org/arch/browse/netmod/
>>>>>>>>>> Description of Working Group:
>>>>>>>>>>
>>>>>>>>>>     The Network Modeling (NETMOD) working group is responsible
>>>>>>>>>> for the YANG
>>>>>>>>>>     data modeling language, and guidelines for developing YANG
>>>>> models.
>>>>>>>> The
>>>>>>>>>>     NETMOD working group addresses general topics related to
>>>>>>>>>> the use of
>>>>>>>> the
>>>>>>>>>>     YANG language and YANG models, for example, the mapping of
>>>>> YANG
>>>>>>>>>> modeled
>>>>>>>>>>     data into various encodings.  Finally, the NETMOD working
>> group
>>>>>>>>>>     also defines core YANG models used as basic YANG building
>>>>>>>>>> blocks,
>>>>>>> and
>>>>>>>>>>     YANG models that do not otherwise fall under the charter of
>>>>>>>>>> any
>>>>>> other
>>>>>>>>>>     IETF working group.
>>>>>>>>>>
>>>>>>>>>> The NETMOD WG is responsible for:
>>>>>>>>>>
>>>>>>>>>>     a) Maintaining the data modeling language YANG.  This
>>>>>>>>>> effort
>>>>>> entails
>>>>>>>>>>        periodically updating the specification to address new
>>>>>> requirements
>>>>>>>>>>        as they arise.
>>>>>>>>>>
>>>>>>>>>>     b) Maintaining the guidelines for developing YANG models.
>>>>>>>>>> This
>>>>>> effort
>>>>>>>>>>        is primarily driven by updates made to the YANG
> specification.
>>>>>>>>>>     c) Maintaining a conceptual framework in which YANG models
>>>>>>>>>> are
>>>>>>> used.
>>>>>>>>>>        This effort entails describing the generic context that
>>>>>>>>>> in
>>>> YANG
>>>>>>>>>>        exists and how certain YANG statements interact in that
>>>>>> context.
>>>>>>>>>>        An example of this is YANG's relationship with datastores.
>>>>>>>>>>
>>>>>>>>>>     d) Maintaining encodings for YANG modeled data.  This
>>>>>>>>>> effort
>>>>>> entails
>>>>>>>>>>        updating encodings already defined by the NETMOD working
>>>>>>>>>> (XML
>>>>>>> and
>>>>>>>>>>        JSON) to accommodate changes to the YANG specification,
>>>>>>>>>> and
>>>>>>>> defining
>>>>>>>>>>        new encodings that are needed, and yet do not fall under
>>>>>>>>>> the
>>>>>> charter
>>>>>>>>>>        of any other active IETF working group.
>>>>>>>>>>
>>>>>>>>>>     e) Maintaining YANG models used as basic YANG building
>> blocks.
>>>>>> This
>>>>>>>>>>        effort entails updating existing YANG models
>>>>>>>>>> (ietf-yang-types
>>>>>> and
>>>>>>>>>>        ietf-inet-types) as needed, as well as defining
>>>>>>>>>> additional core
>>>>>> YANG
>>>>>>>>>>        data models when necessary.
>>>>>>>>>>
>>>>>>>>>>     f) Defining and maintaining YANG models that do not fall
>>>>>>>>>> under
>>>> the
>>>>>>>>>>        charter of any other active IETF working group.
>>>>>>>>>>
>>>>>>>>>>     The NETMOD working group consults with the NETCONF
>> working
>>>>>>> group
>>>>>>>> to
>>>>>>>>>>     ensure that new requirements are understood and can be met
>>>>>>>>>> by
>>>>> the
>>>>>>>>>>     protocols (e.g., NETCONF and RESTCONF) developed within
>>>>>>>>>> that
>>>>>>> working
>>>>>>>>>>     group.  The NETMOD working group coordinates with other
>>>>>>>>>> working
>>>>>>>> groups
>>>>>>>>>>     (e.g., I2RS, RTGWG) on possible extensions to YANG to
>>>>>>>>>> address
>>> new
>>>>>>>>>>     modeling requirements and, when needed, which group will
>>>>>>>>>> run
>>> the
>>>>>>>>>>     process on a specific model.
>>>>>>>>>>
>>>>>>>>>>     The NETMOD working group does not serve as a review team
>>>>>>>>>> for
>>>>>>> YANG
>>>>>>>>>>     modules developed by other working groups. Instead, the
>>>>>>>>>> YANG
>>>>>>>> doctors,
>>>>>>>>>>     as organized by the OPS area director responsible for network
>>>>>>>>>>     management, will act as advisors for other working groups
>>>>>>>>>> and
>>>>>> provide
>>>>>>>>>>     YANG reviews for the OPS area directors.
>>>>>>>>>>
>>>>>>>>>> Milestones:
>>>>>>>>>>
>>>>>>>>>>     Done     - Submit draft-ietf-netmod-rfc6087bis to IESG for
>>>>>> publication
>>>>>>>>>>     Mar 2017 - Submit
>>>>>>>>>> draft-ietf-netmod-yang-model-classification
>>>>>>>>>> to
>>>>>> IESG
>>>>>>>>>>                for publication
>>>>>>>>>>     Mar 2017 - Submit draft-ietf-netmod-acl-model to IESG for
>>>>>> publication
>>>>>>>>>>     Apr 2017 - Submit draft-ietf-netmod-entity to IESG for
>>>> publication
>>>>>>>>>>     Apr 2017 - Submit draft-ietf-netmod-syslog-model to IESG
>>>>>>>>>> for
>>>>>>>>> publication
>>>>>>>>>>     Oct 2017 - Submit draft-ietf-netmod-schema-mount to IESG
>>>>>>>>>> for
>>>>>>>>> publication
>>>>>>>>>>     Oct 2017 - Submit draft-ietf-netmod-revised-datastores to
>>>>>>>>>> IESG
>>>> for
>>>>>>>>>>                publication
>>>>>>>>>>     Dec 2017 - Submit draft-ietf-netmod-intf-ext-yang to IESG for
>>>>>>>>>>                publication
>>>>>>>>>>     Dec 2017 - Submit draft-ietf-netmod-sub-intf-vlan-yang to
>>>>>>>>>> IESG
>>>> for
>>>>>>>>>>                publication
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> netmod mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>>> _______________________________________________
>>>>>>>>> netmod mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>>>
>>>>>>
>>>>
>
> .
>