Mehmet,
As long as the WG items are in the milestones, we're good.
Regards, Benoit
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 <[email protected]>; 'Kent Watsen' <[email protected]>;
[email protected]
Cc: 'Benoit Claise' <[email protected]>; 'Mahesh Jethanandani'
<[email protected]>
Subject: RE: [netmod] draft netmod charter update proposal
From: Lou Berger [mailto:[email protected]] 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 <[email protected]>; 'Kent Watsen'
<[email protected]>; [email protected]
Cc: 'Benoit Claise' <[email protected]>; 'Mahesh Jethanandani'
<[email protected]>
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:[email protected]]
Sent: Wednesday, March 8, 2017 11:28 PM
To: Mehmet Ersue <[email protected]>; 'Kent Watsen'
<[email protected]>; [email protected]
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:[email protected]] On Behalf Of
Kent
Watsen
Sent: Wednesday, March 8, 2017 7:45 PM
To: [email protected]
Cc: [email protected]
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 <[email protected]>
Kent Watsen <[email protected]>
Operations and Management Area Directors:
Benoit Claise <[email protected]>
Joel Jaeggli <[email protected]>
Operations and Management Area Advisor:
Benoit Claise <[email protected]>
Secretary:
Zitao (Michael) Wang <[email protected]>
Mailing Lists:
General Discussion: [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
