Re: [netmod] draft netmod charter update proposal

["Mehmet Ersue" <[e-mail]>]

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
> > >>>>>>
> > >>>
> > >>>
> > >
> > >