Re: [netmod] draft netmod charter update proposal

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

Hi Kent,

> We do, however, have a "YANG Next" discussion on the agenda, which may or may not lead to the creation of a milestone for it.
It would be good to extend the charter proposal after this discussion with agreed goals for 7950bis.
We also need to know what exactly is going to be separated from 7950. E.g. one of the topics we discussed on the maillist was guidance on using YANG with specific protocols. This can be done in the protocol document.

> > > > >>>>>>>    Oct 2017 - Submit draft-ietf-netmod-revised-datastores
> > > > >>>>>>> to IESG
Another question is whether this should be earlier, e.g. August.
As it is a high-priority topic needed at least by 2 WGs, we were saying that revised-datastores should be finalized within 4 months and NC/RC-bis will take another 4-5 months.

Thanks,
Mehmet

> -----Original Message-----
> From: Kent Watsen [mailto:[e-mail]]
> Sent: Wednesday, March 22, 2017 9:48 PM
> To: Mehmet Ersue <[e-mail]>; 'Lou Berger' <[e-mail]>;
> [e-mail]
> Cc: 'Benoit Claise' <[e-mail]>; 'Mahesh Jethanandani'
> <[e-mail]>
> Subject: Re: [netmod] draft netmod charter update proposal
> 
> Hi Mehmet,
> 
> From a charter perspective, we have:
> 
>  a) Maintaining the data modeling language YANG.  This effort
>     entails periodically updating the specification to address
>     new requirements as they arise.
> 
> From a milestone perspective, you are correct that we don't have a
> milestone for 7950bis as of yet.  We do, however, have a "YANG Next"
> discussion on the agenda, which may or may not lead to the creation of a
> milestone for it.
> 
> As for NETCONF/RESTCONF revisions depending on a 7950bis, if that is true,
> then it will likely force us to create the milestone in the near-term for it.  That
> withstanding, I think that NETCONF WG could take the lead by
> moving/copying the NETCONF-specific parts from RFC7950 into an rfc6241bis.
> It would be nice if we could decouple the refactoring of these documents
> across our WGs.
> 
> Kent // co-chair hat
> 
> 
> 
> -----ORIGINAL MESSAGE-----
> 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
> > > > >>>>>>
> > > > >>>
> > > > >>>
> > > > >
> > > > >
> 
> 
>