Re: [netmod] draft netmod charter update proposal

"Mehmet Ersue" <mersue@gmail.com> Wed, 15 March 2017 13:50 UTC

Return-Path: <mersue@gmail.com>
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 9ED18131511 for <netmod@ietfa.amsl.com>; Wed, 15 Mar 2017 06:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 gD4ruk-Uglkr for <netmod@ietfa.amsl.com>; Wed, 15 Mar 2017 06:50:08 -0700 (PDT)
Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51004131512 for <netmod@ietf.org>; Wed, 15 Mar 2017 06:50:08 -0700 (PDT)
Received: by mail-wr0-x234.google.com with SMTP id u48so11448781wrc.0 for <netmod@ietf.org>; Wed, 15 Mar 2017 06:50:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=mdFPHQvBmEc3s6P25XKrZpb0E7+NtdUj7Ad7RazS344=; b=HXr+gFATGlL/dd79sjdMzFLk0aUNh/WXGB0aQpgixZuSP6FmRLHQ8RutsdIy6oBxSm Vwe9x28hNgYlr86cCYErPvHfp85oIRtzf/T8zyWnIyiSJ84A6rUhncYdAfSl+1GgTZDx 4SyQWXu9T5k9yJmZN9EwPy7m4FGlkFsF2MJ9xMIJcKV0NwbL6qH0kacSNnn/wi86wCNE iKUCMe6fkBQfYeB7LytgtHM7Y4jvk95wOXruDVcE6ioZTxtL9s2NUgs4oR0EO/1vhXrF 8pc8mOQBtTDiWMEAAD5lqv/TKbN64n2EBMvrIX/0bpUpeipFxGEDnaTsg5vjxFWiYPSB k/8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=mdFPHQvBmEc3s6P25XKrZpb0E7+NtdUj7Ad7RazS344=; b=c9VjP+SG2AEbwuFphdQk/9rmdx6KcRmvWJ+BAH8n4095YbBB6gH7wEoMj/+FuqQM7O 22/gfrrtwovqNN3AhwgseuZmuTnuDMb8+KFSOSk+twcdArRj9OWVnoFcgSSnQ/aWtdIB hEu66GudMduBAHDFFU1Qafw8y99XJToPWAf/ML0GNq2ensySPZkcpggyDLa4ogjJqxCF zgsrrdNYvxeHcTNW6W0EaVKqp7P6EzIjndcsMj9EXb+XQuOchZ3WKSLrXKO98JYvjW+/ VMoblH8b5Ryrrm3/CSMv5c3+XfF9fItCEZQ7uQNJioPXe5YHQohYamczLsPROJWc8ihC 6t6Q==
X-Gm-Message-State: AFeK/H1JikA9RwDMhaUhzo+jqcpxLsvK422C2AYx6W8lpt7PFfVNn/AFz2P2FTcPGMaQPg==
X-Received: by 10.223.129.230 with SMTP id 93mr3094152wra.41.1489585806611; Wed, 15 Mar 2017 06:50:06 -0700 (PDT)
Received: from DESKTOPFLHJVQJ (p5DCC645C.dip0.t-ipconnect.de. [93.204.100.92]) by smtp.gmail.com with ESMTPSA id o52sm2438561wrb.51.2017.03.15.06.50.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 06:50:06 -0700 (PDT)
From: Mehmet Ersue <mersue@gmail.com>
To: 'Lou Berger' <lberger@labn.net>, '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>
In-Reply-To:
Date: Wed, 15 Mar 2017 14:50:06 +0100
Message-ID: <02e701d29d93$0e770480$2b650d80$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH7oic/U5hpx/GFJ0RcyrWSlwEP7gFUc6bxAwunfXMCshfA6wGwTOtXApSHeBYBqgs5ngFezfO+ATSZUoqgvM/28IAKaKVw
Content-Language: de
X-AVK-Virus-Check: AVA 25.11068;244D8A0E
X-AVK-Spam-Check: 1; str=0001.0A0C0203.58C9468D.0273,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/B4TnkAniiEsp0GSRLDaUosZukhk>
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: Wed, 15 Mar 2017 13:50:12 -0000

Hi Lou, Kent,

it appears to me the issues I raised below are not closed.

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.

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.
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. This is as I think also important to avoid an overlapping
between NETCONF and NETMOD charters.

PS: I expect that most of the Netconf WG member read also the Netmod
maillist and therefor skip sending to both ML.

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