Re: [netmod] draft netmod charter update proposal

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

Hi Kent, Lou,

as I see 7950bis has not been mentioned in the charter text and the
milestones.
As you know NETCONF and RESTCONF revisions are dependent on the timing of
7950bis.
How is this essential deliverable and its timing going to be addressed in
the charter?

Mehmet

> -----Original Message-----
> From: Mehmet Ersue
> Sent: Friday, March 17, 2017 11:51 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, 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
> > > >>>>>>
> > > >>>
> > > >>>
> > > >
> > > >