-----Original Message-----
From: Kent Watsen [mailto:[email protected]]
Sent: Wednesday, March 22, 2017 9:48 PM
To: Mehmet Ersue <[email protected]>; 'Lou Berger' <[email protected]>;
[email protected]
Cc: 'Benoit Claise' <[email protected]>; 'Mahesh Jethanandani'
<[email protected]>
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 <[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, 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
