Re: [netmod] draft netmod charter update proposal

Lou Berger <lberger@labn.net> Thu, 16 March 2017 21:52 UTC

Return-Path: <lberger@labn.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97CE129ABD for <netmod@ietfa.amsl.com>; Thu, 16 Mar 2017 14:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13A3eNj1rHD7 for <netmod@ietfa.amsl.com>; Thu, 16 Mar 2017 14:52:26 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id F2FCD129AB7 for <netmod@ietf.org>; Thu, 16 Mar 2017 14:52:25 -0700 (PDT)
Received: (qmail 14484 invoked by uid 0); 16 Mar 2017 21:52:23 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy5.mail.unifiedlayer.com with SMTP; 16 Mar 2017 21:52:23 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id wlsL1u0092SSUrH01lsPhm; Thu, 16 Mar 2017 15:52:23 -0600
X-Authority-Analysis: v=2.1 cv=R4+QR7hX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=N659UExz7-8A:10 a=xqWC_Br6kY4A:10 a=6Iz7jQTuP9IA:10 a=wU2YTnxGAAAA:8 a=OUXY8nFuAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=pGLkceISAAAA:8 a=xcTfSnc4AAAA:8 a=i0EeH86SAAAA:8 a=4MpHeDZdjMi4cHXfiloA:9 a=YKdk1Sg7XhWOeCST:21 a=1gaz9vBfT6dckGR0:21 a=pILNOxqGKmIA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=cAcMbU7R10T-QSRYIcO_:22 a=w1C3t2QeGrPiZgrLijVG:22 a=TSZmLRzkpGLBZRr3r8m8:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=AlSe2FwLBhvzWS46gZ1m:22 a=02toJ7V-nxh73JlV0Smw:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=w2xeodyG7BBJDUR9sVNdTnTfYisHEFc9Hzq95xIga8s=; b=HEE0KUv2QWWrQ3RhS0s8cLmrsf AI6+G21lQJm4raQ9CM+Et0c591JdPBVgtEA9GIKhytlev5gvxV/GbHoy17t3UYOGTITceEZpac/VS Ffxj9VpGwhzFa4HY+J3tyCITT;
Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:56758 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1codJe-0004x8-QW; Thu, 16 Mar 2017 15:52:20 -0600
To: Mehmet Ersue <mersue@gmail.com>, 'Kent Watsen' <kwatsen@juniper.net>, netmod@ietf.org
References: <B6359563-0649-453A-B29F-28375F2BD3A4@juniper.net> <0830e87c-ee4f-bf53-2c51-96c166d3955e@cisco.com> <9A9AD440-953D-46D4-9207-97619D054912@juniper.net> <9d7b60aa-1690-c598-7034-2e430c7a8e0a@cisco.com> <3C31A53A-6818-451E-9BEF-5E568C4DCB65@juniper.net> <030A7AF8-BA6E-4622-B008-F9624012C972@juniper.net> <EA565264-DBFE-4122-8E38-91307253300F@juniper.net> <01c601d29855$94b70470$be250d50$@gmail.com> <e3527c28-8c9f-9ef2-9b09-767b389f5dc5@labn.net> <02e701d29d93$0e770480$2b650d80$@gmail.com> <675654fd-1532-1755-621c-a3ecb06950e3@labn.net> <025a01d29e82$8549d070$8fdd7150$@gmail.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <d890d3fc-782f-1eee-652d-51c7f8fae26c@labn.net>
Date: Thu, 16 Mar 2017 17:51:59 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <025a01d29e82$8549d070$8fdd7150$@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.85.191
X-Exim-ID: 1codJe-0004x8-QW
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([IPv6:::1]) [100.15.85.191]:56758
X-Source-Auth: lberger@labn.net
X-Email-Count: 13
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/J430pmvxAfO_VrAPOx4eTLeAWZI>
Subject: Re: [netmod] draft netmod charter update proposal
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Mar 2017 21:52:30 -0000

Mehmet,
   see below.
On 3/16/2017 2:24 PM, Mehmet Ersue wrote:
> Lou,
>
>> Mehmet,
>>
>> On 03/15/2017 09:50 AM, Mehmet Ersue wrote:
>>> Hi Lou, Kent,
>>>
>>> it appears to me the issues I raised below are not closed.
>> it wasn't clear from your mail that a response was needed as it seemed to
> be
>> covering points otherwise discussed, and where we may not agree.
>> It's good that you are re-raising them now.
>>
>>> I believe at least a "minimal" WG item focus formulation is required
>>> to match to the high-level WG focus topics in a)-f). I was thinking my
>>> proposal below is acceptable.
>>>
>> I think we disagree on this point.  That said, perhaps our objection is in
> the
>> abstract and not the specific.  Can you propose specific text change you'd
> like
>> to see made to the charter and we can discuss it?
> I believe IETF WG charters need to be defined for a particular period of
> time with a specific target for development.
> The current charter proposal seems to provide a high-level WG focus
> definition without time limits.
> I think the WG items to develop in the planned time period need to be
> defined at least minimally, at least as an indication.
> This is the basis for me as a WG member by which I agree or object to the
> approval of a charter proposal for the planned development period.
>
> 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?

>>> Netconf WG will ensure avoiding double-work concerning the DS concept
>>> draft, however Netconf needs to specify what is required for the use
>>> of the DS concept from protocol standards pov.
>> okay.  I think we agree that the protocol aspects belong in NetConf - and
>> we're expecting those to be covered during the NetConf WG session in
>> Chicago.
>>
>>> That said different people including Netconf WG co-chairs think the DS
>>> concept document is Informational in nature and should be published as
>>> an Informational concept to be used in and adopted for the needs in
>>> diverse protocol WGs.
>> okay.
> I'm not sure whether your "okay" means the same as I meant.
it meant, "Okay, I heard you."  I've already responded to this comment
multiple times so didn't think it would add anything to say it again.

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

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

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

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 <lberger@labn.net>; 'Kent Watsen'
>>>> <kwatsen@juniper.net>; netmod@ietf.org
>>>> Cc: 'Benoit Claise' <bclaise@cisco.com>; 'Mahesh Jethanandani'
>>>> <mjethanandani@gmail.com>
>>>> 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:lberger@labn.net]
>>>>> Sent: Wednesday, March 8, 2017 11:28 PM
>>>>> To: Mehmet Ersue <mersue@gmail.com>; 'Kent Watsen'
>>>>> <kwatsen@juniper.net>; netmod@ietf.org
>>>>> 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:netmod-bounces@ietf.org] On Behalf Of Kent
>>>>>>> Watsen
>>>>>>> Sent: Wednesday, March 8, 2017 7:45 PM
>>>>>>> To: netmod@ietf.org
>>>>>>> Cc: netmod-chairs@ietf.org
>>>>>>> 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 <lberger@labn.net>
>>>>>>>    Kent Watsen <kwatsen@juniper.net>
>>>>>>>
>>>>>>> Operations and Management Area Directors:
>>>>>>>    Benoit Claise <bclaise@cisco.com>
>>>>>>>    Joel Jaeggli <joelja@bogus.com>
>>>>>>>
>>>>>>> Operations and Management Area Advisor:
>>>>>>>    Benoit Claise <bclaise@cisco.com>
>>>>>>>
>>>>>>> Secretary:
>>>>>>>    Zitao (Michael) Wang <wangzitao@huawei.com>
>>>>>>>
>>>>>>> Mailing Lists:
>>>>>>>    General Discussion: netmod@ietf.org
>>>>>>>    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
>>>>>>> netmod@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>
>>>
>>>
>
>