Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

[Alex Campbell]

I am considering to implement the data model in this draft.

I have reviewed this draft and found the following issues. In approximately 
decreasing order of severity:

* In the "selector-facility" choice statement the cases have misleading names - 
the case where no facility is matched is named "facility", and the case where 
specific facilities are matched is named "name". I suggest "no-facilities" and 
"specified-facilities", or similar.

* I disagree with the premise of the "no-facilities" case, which is that it can 
be used to disable a log action, according to the description:

 description
"This case specifies no facilities will match when
 comparing the syslog message facility. This is a
 method that can be used to effectively disable a
 particular log-action (buffer, file, etc).";

  If an administrator wants to disable a log action they should do it by either 
removing it from the configuration, or by setting an "enabled" leaf to false.
  With that in mind, there is no reason for the "no-facilities" case to exist.

* What is the behaviour of a selector if neither "no-facilities" nor 
"facility-list" is present?
* In the "selector" grouping it is not clear how the facility and pattern 
conditions are combined to decide whether a message is selected.
  Must they both match the message, or is it sufficient for either one to match 
the message?
* Not all servers have a console; there should be a feature to indicate whether 
logging to the console is supported.
* Likewise, not all servers may support logging to user sessions.
* Likewise, not all servers may support a user-accessible filesystem.
* RFC 5424 states that the severity and protocol values are not normative. 
* It's not clear to me why this needs to be split into two modules. Is it so 
that other modules can define logging parameters but still be usable on a 
device without syslog?
* "log-severity" defines a severity filter, not a severity, so its name is 
misleading.
* Perhaps the "severity" type and the facility identities should have 
"reference" statements referring to RFC 5424, rather than referring to it in 
the description.
* In section "8.2", "admisintrator" is a typo.

I assume that the means of accessing the memory buffer and log files are out of 
scope of this data model.

Alex


From: netmod  on behalf of Kent Watsen 

Sent: Wednesday, 14 December 2016 2:01 p.m.
To: netmod@ietf.org
Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

This is a notice to start a two-week NETMOD WG last call for the document:

A YANG Data Model for Syslog Configuration
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11

Please indicate your support or concerns by Tuesday, December 27, 2016.

We are particularly interested in statements of the form:
  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...

As well as:
  * I have implemented the data model in this draft.
  * I am implementing the data model in this draft.
  * I am considering to implement the data model in this draft.
  * I am not considering to implement the data model in this draft.

Thank you,
NETMOD WG Chairs



___
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

[netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

[Kent Watsen]

This is a notice to start a two-week NETMOD WG last call for the document:
 
A YANG Data Model for Syslog Configuration
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11
 
Please indicate your support or concerns by Tuesday, December 27, 2016.
 
We are particularly interested in statements of the form:
  * I have reviewed this draft and found no issues.
  * I have reviewed this draft and found the following issues: ...
 
As well as:
  * I have implemented the data model in this draft.
  * I am implementing the data model in this draft.
  * I am considering to implement the data model in this draft.
  * I am not considering to implement the data model in this draft.
 
Thank you,
NETMOD WG Chairs
 


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Regarding IPR on draft-ietf-netmod-syslog-model-11

[Clyde Wildes (cwildes)]

Kent,

No, I'm not aware of any IPR that applies to this draft

Thanks,

Clyde

On 12/13/16, 4:15 PM, "Kent Watsen"  wrote:


Authors, Contributors, WG,
 
This IPR disclosure requests is being made as part of the preparation
for WG Last Call of draft-ietf-netmod-syslog-model-11.

Are you aware of any IPR that applies to draft identified above? 

Please state either:
"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?

If yes to the above, please state either:
"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"
 
 
If you answer no, please provide any additional details you think
appropriate.
 
If you are listed as a document author or contributor, please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS
MESSAGE'S TO LINES.
 
If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under the
IETF IPR rules which encourages you to notify the IETF if you are aware
of IPR of others on an IETF contribution, or to refrain from participating
in any contribution or discussion related to your undisclosed IPR. For
more information, please see the RFCs listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
 
Thank you,
NETMOD WG Chairs
 
PS Please include all listed in the headers of this message in your 
response.
 




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00

[Mehmet Ersue]

Technically spoken actually both options work for me: 

Keeping current concept in 6241 or having everything in one document.

I prefer the latter.

 

We actually don’t want to remove , only solve issues.

Any change to  is for sure subject to WG decision.

 

Mehmet

 

From: Andy Bierman [mailto:a...@yumaworks.com] 
Sent: Tuesday, December 13, 2016 10:52 PM
To: Mehmet Ersue 
Cc: Eric Voit (evoit) ; Ladislav Lhotka ; 
NetMod WG Chairs ; NetConf WG Chairs 
; NetMod WG ; Netconf 

Subject: Re: [netmod] [Netconf] WG adoption poll 
draft-nmdsdt-netmod-revised-datastores-00

 

 

 

On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue  > wrote:

Hi Andy,

 

> This architectural change needs to be implemented in various protocols.

> I am not sure a 6241bis is the best approach because it is not clear which

> servers really need to implement the revised datastores.  

 

I agree fully. This is the reason why I wrote in my mail:

 

>> - a new protocol- and language-independent standard document (RFC XYZ) 
>> defining the generic datastore concept and framework and describing its use 
>> (based on and following the DT solution draft),

>> - a RFC6241bis draft removing the current datasore concept specification, 
>> and getting rid of well-known issues e.g. with the  operation,

 

I do not agree with the text you wrote.

I do not want to remove candidate, running, and startup from RFC 6241.

IMO the new datastores can be defined in a new document that does not redefine 
the existing datastores.

 

I also do not want to get rid of ,  It works as intended.

It is not a problem on small devices.  It is not a problem on large devices if

sufficient filtering is used.  It does not differentiate between intended and 
applied config

or understand different types of config=false nodes.  Use a new operation to

add these features.

 

 

 

 

 

Mehmet

 

 

Andy

 

 

 

From: Andy Bierman [mailto:a...@yumaworks.com  ] 
Sent: Dienstag, 13. Dezember 2016 18:38
To: Eric Voit (evoit)  >
Cc: Ladislav Lhotka  >; MehmetErsue 
 >; NetMod WG Chairs 
 >; NetConf WG Chairs 
 >; NetMod WG 
 >; Netconf  >
Subject: Re: [netmod] [Netconf] WG adoption poll 
draft-nmdsdt-netmod-revised-datastores-00

 

 

 

On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit)  > wrote:

I support adoption, and like Mehmet's thinking as well.

Also worth focusing on is transport protocol independent yang filtering.  So 
along with how to frame get operations against one of the datastores, how do 
you know which subtrees/nodes should be included/excluded.

 

 

This architectural change needs to be implemented in various protocols.

I am not sure a 6241bis is the best approach because it is not clear which

servers really need to implement the revised datastores.  Since RD is purely 
optional

to implement, it should not obsolete 6241 in any way.  It should be possible

to add new operations and/or new parameters to existing operations without

needing to redefine what is already there.

 

The new protocol features need to explain how to include/exclude subtrees.

IMO we should only support YANG defined data.  This allows the solutions

to be generalized and reusable across protocols (e.g., using YANG extensions).

 

 

Eric

 

 

Andy

 


> From: Netconf, December 9, 2016 7:49 AM
>
> Hi Mehmet,
>
> I think I could just sign your text at the bottom.
>
> Lada
>
> > On 9 Dec 2016, at 13:25, MehmetErsue  >  > wrote:
> >
> > Hi All,
> >
> > I think the adoption of the DT draft is fine. We agreed in IETF 97 to adopt 
> > and
> finalize the DT draft in NETMOD WG, which I still support.
> >
> > I believe the bigger issue is to agree on a plan concerning the related work
> and the re-organization of existing standards. As a matter of fact this plan 
> will
> lead to updating the charter of two WGs and the work we are going to start.
> >
> > I see the DT document as a datastore solution proposal. There are different
> gaps and issues which still need to be addressed and the solution proposal
> needs yet to be discussed and finalized. The document is providing information
> on the history, explaining the need for a generic solution as well as is 
> discussing
> different scenarios. As such I believe the datastore solution proposal from 
> the
> DT should be published with the intended status Informational RFC.
> >
> > Based on the finalized and agreed 

Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00

[Andy Bierman]

On Tue, Dec 13, 2016 at 1:41 PM, Mehmet Ersue  wrote:

> Hi Andy,
>
>
>
> > This architectural change needs to be implemented in various protocols.
>
> > I am not sure a 6241bis is the best approach because it is not clear
> which
>
> > servers really need to implement the revised datastores.
>
>
>
> I agree fully. This is the reason why I wrote in my mail:
>
>
>
> >> - a new protocol- and language-independent standard document (RFC XYZ)
> defining the generic datastore concept and framework and describing its use
> (based on and following the DT solution draft),
>
> >> - a RFC6241bis draft removing the current datasore concept
> specification, and getting rid of well-known issues e.g. with the 
> operation,
>
>
I do not agree with the text you wrote.
I do not want to remove candidate, running, and startup from RFC 6241.
IMO the new datastores can be defined in a new document that does not
redefine the existing datastores.

I also do not want to get rid of ,  It works as intended.
It is not a problem on small devices.  It is not a problem on large devices
if
sufficient filtering is used.  It does not differentiate between intended
and applied config
or understand different types of config=false nodes.  Use a new operation to
add these features.






> Mehmet
>


Andy



>
>
> *From:* Andy Bierman [mailto:a...@yumaworks.com]
> *Sent:* Dienstag, 13. Dezember 2016 18:38
> *To:* Eric Voit (evoit) 
> *Cc:* Ladislav Lhotka ; MehmetErsue ;
> NetMod WG Chairs ; NetConf WG Chairs <
> netconf-cha...@ietf.org>; NetMod WG ; Netconf <
> netc...@ietf.org>
> *Subject:* Re: [netmod] [Netconf] WG adoption poll
> draft-nmdsdt-netmod-revised-datastores-00
>
>
>
>
>
>
>
> On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit) 
> wrote:
>
> I support adoption, and like Mehmet's thinking as well.
>
> Also worth focusing on is transport protocol independent yang filtering.
> So along with how to frame get operations against one of the datastores,
> how do you know which subtrees/nodes should be included/excluded.
>
>
>
>
>
> This architectural change needs to be implemented in various protocols.
>
> I am not sure a 6241bis is the best approach because it is not clear which
>
> servers really need to implement the revised datastores.  Since RD is
> purely optional
>
> to implement, it should not obsolete 6241 in any way.  It should be
> possible
>
> to add new operations and/or new parameters to existing operations without
>
> needing to redefine what is already there.
>
>
>
> The new protocol features need to explain how to include/exclude subtrees.
>
> IMO we should only support YANG defined data.  This allows the solutions
>
> to be generalized and reusable across protocols (e.g., using YANG
> extensions).
>
>
>
>
>
> Eric
>
>
>
>
>
> Andy
>
>
>
>
> > From: Netconf, December 9, 2016 7:49 AM
> >
> > Hi Mehmet,
> >
> > I think I could just sign your text at the bottom.
> >
> > Lada
> >
> > > On 9 Dec 2016, at 13:25, MehmetErsue  wrote:
> > >
> > > Hi All,
> > >
> > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to
> adopt and
> > finalize the DT draft in NETMOD WG, which I still support.
> > >
> > > I believe the bigger issue is to agree on a plan concerning the
> related work
> > and the re-organization of existing standards. As a matter of fact this
> plan will
> > lead to updating the charter of two WGs and the work we are going to
> start.
> > >
> > > I see the DT document as a datastore solution proposal. There are
> different
> > gaps and issues which still need to be addressed and the solution
> proposal
> > needs yet to be discussed and finalized. The document is providing
> information
> > on the history, explaining the need for a generic solution as well as is
> discussing
> > different scenarios. As such I believe the datastore solution proposal
> from the
> > DT should be published with the intended status Informational RFC.
> > >
> > > Based on the finalized and agreed datastore solution we should do
> different
> > updates to existing documents in NETCONF and NETMOD WGs. With this
> > action we can also fix well-known issues.
> > >
> > > Concerning the NETCONF WG I would see it as valuable if we develop:
> > > - a RFC6241bis draft removing the current datasore concept
> > > specification, and getting rid of well-known issues e.g. with the
> > >  operation,
> > > - a new protocol- and language-independent standard document (RFC XYZ)
> > > defining the generic datastore concept and framework and describing
> > > its use (based on and following the DT solution draft),
> > > - adding potential extensions to RFC6241bis (following the DT draft
> > > and with a normative reference to RFC XYZ),
> > > - adding potential extensions to a RESTCONF-bis RFC (following the DT
> > > draft and with a normative reference to RFC XYZ),
> > >
> > > Concerning the NETMOD WG I 

Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00

[Andy Bierman]

On Tue, Dec 13, 2016 at 5:37 AM, Eric Voit (evoit)  wrote:

> I support adoption, and like Mehmet's thinking as well.
>
> Also worth focusing on is transport protocol independent yang filtering.
> So along with how to frame get operations against one of the datastores,
> how do you know which subtrees/nodes should be included/excluded.
>
>

This architectural change needs to be implemented in various protocols.
I am not sure a 6241bis is the best approach because it is not clear which
servers really need to implement the revised datastores.  Since RD is
purely optional
to implement, it should not obsolete 6241 in any way.  It should be possible
to add new operations and/or new parameters to existing operations without
needing to redefine what is already there.

The new protocol features need to explain how to include/exclude subtrees.
IMO we should only support YANG defined data.  This allows the solutions
to be generalized and reusable across protocols (e.g., using YANG
extensions).


Eric
>


Andy


>
> > From: Netconf, December 9, 2016 7:49 AM
> >
> > Hi Mehmet,
> >
> > I think I could just sign your text at the bottom.
> >
> > Lada
> >
> > > On 9 Dec 2016, at 13:25, MehmetErsue  wrote:
> > >
> > > Hi All,
> > >
> > > I think the adoption of the DT draft is fine. We agreed in IETF 97 to
> adopt and
> > finalize the DT draft in NETMOD WG, which I still support.
> > >
> > > I believe the bigger issue is to agree on a plan concerning the
> related work
> > and the re-organization of existing standards. As a matter of fact this
> plan will
> > lead to updating the charter of two WGs and the work we are going to
> start.
> > >
> > > I see the DT document as a datastore solution proposal. There are
> different
> > gaps and issues which still need to be addressed and the solution
> proposal
> > needs yet to be discussed and finalized. The document is providing
> information
> > on the history, explaining the need for a generic solution as well as is
> discussing
> > different scenarios. As such I believe the datastore solution proposal
> from the
> > DT should be published with the intended status Informational RFC.
> > >
> > > Based on the finalized and agreed datastore solution we should do
> different
> > updates to existing documents in NETCONF and NETMOD WGs. With this
> > action we can also fix well-known issues.
> > >
> > > Concerning the NETCONF WG I would see it as valuable if we develop:
> > > - a RFC6241bis draft removing the current datasore concept
> > > specification, and getting rid of well-known issues e.g. with the
> > >  operation,
> > > - a new protocol- and language-independent standard document (RFC XYZ)
> > > defining the generic datastore concept and framework and describing
> > > its use (based on and following the DT solution draft),
> > > - adding potential extensions to RFC6241bis (following the DT draft
> > > and with a normative reference to RFC XYZ),
> > > - adding potential extensions to a RESTCONF-bis RFC (following the DT
> > > draft and with a normative reference to RFC XYZ),
> > >
> > > Concerning the NETMOD WG I would see it as valuable if we develop:
> > > - RFC7950bis deleting protocol-dependent details and specifying the
> > > datastore usage with YANG on a generic level (with a normative
> > > reference to RFC XYZ),
> > > - adding potential extensions to RFC7950bis, e.g. concerning the
> > > proposed  element,
> > > - possibly an RFC 6244bis to describe architectural aspects. However
> RFC6244
> > is Informational and a RFC6244bis would be still Informational. I'm not
> sure
> > whether this is really necessary. The DT proposal does already describe
> such a
> > solution and can be seen as an update to RFC 6244.
> > > - RFC6087bis giving guidelines on how to use YANG with the new
> datastore
> > concept.
> > >
> > > Referring to Lada's proposal concerning the spin off document from
> > > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be
> > provided in the corresponding protocol RFCs, i.e.
> > > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and
> > for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC.
> > >
> > > Hope this helps as a starting point on the way to a good plan.
> > >
> > > PS: As Benoit suggested some time ago we might also consider to rename
> > NETCONF WG as it is not only on NETCONF protocol anymore.
> > >
> > > Regards,
> > > Mehmet
> > >
> > > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman 
> > wrote:
> > > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder
> >  wrote:
> > > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote:
> > > >
> > > > >
> > > > > I disagree that the datastore model is a protocol specific aspect.
> > > > > I consider datastores an architectural component binding data
> > > > > models and protocols together. In fact, the 'traditional'
> > > > > datastore model
> > > >
> > > > I 

Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

[Mahesh Jethanandani]

Support.

> On Dec 12, 2016, at 3:31 PM, Lou Berger  wrote:
> 
> All,
> 
> This is start of a two week* poll on making
> draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group
> document.
> 
> Please send email to the list indicating "yes/support" or "no/do not
> support".  If indicating no, please state your reservations with the
> document.  If yes, please also feel free to provide comments you'd like
> to see addressed once the document is a WG document.
> 
> * Given the holiday, the poll ends December 28.
> 
> Thank you,
> NetMod WG Chairs
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Management Operations on YANG modelled operational data

[Martin Bjorklund]

"Eric Voit (evoit)"  wrote:
> > From: Juergen Schoenwaelder: Monday, December 12, 2016 6:10 PM
> > 
> > The proper action in this case may be to kill the NETCONF session.
> > 
> > It can be debated whether simply deleting state created by some other
> > system
> > (the subscription in this case) is a proper management approach since
> > it may
> > lead to undefined or erratic behaviour of other systems or to loops
> > where some
> > systems create state that others delete and so on.
> 
> Wouldn't this have implications to I2RS or OpState?

I don't know about i2rs, but it doesn't impact "opstate".

> How would an
> Operator be able to focus only on the subset of dynamic state which is
> currently impacted?
> 
> An analogy might be someone with phone and faulty video service
> connected over their broadband connection.  They get on the phone with
> an operator to troubleshoot their video, but the operator can't reset
> the video CPE session without taking out the phone service as well.

Maybe this is a good reason for using separate sessions, and not try
to do too much in one.

The problem is how you expect the client (and maybe server) to recover
after a forced termination of an ongoing request.  Note that there's
no equivalent operation to kill an ongoing  for example.


/martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00

[Eric Voit (evoit)]

I support adoption, and like Mehmet's thinking as well.

Also worth focusing on is transport protocol independent yang filtering.  So 
along with how to frame get operations against one of the datastores, how do 
you know which subtrees/nodes should be included/excluded.

Eric

> From: Netconf, December 9, 2016 7:49 AM
> 
> Hi Mehmet,
> 
> I think I could just sign your text at the bottom.
> 
> Lada
> 
> > On 9 Dec 2016, at 13:25, MehmetErsue  wrote:
> >
> > Hi All,
> >
> > I think the adoption of the DT draft is fine. We agreed in IETF 97 to adopt 
> > and
> finalize the DT draft in NETMOD WG, which I still support.
> >
> > I believe the bigger issue is to agree on a plan concerning the related work
> and the re-organization of existing standards. As a matter of fact this plan 
> will
> lead to updating the charter of two WGs and the work we are going to start.
> >
> > I see the DT document as a datastore solution proposal. There are different
> gaps and issues which still need to be addressed and the solution proposal
> needs yet to be discussed and finalized. The document is providing information
> on the history, explaining the need for a generic solution as well as is 
> discussing
> different scenarios. As such I believe the datastore solution proposal from 
> the
> DT should be published with the intended status Informational RFC.
> >
> > Based on the finalized and agreed datastore solution we should do different
> updates to existing documents in NETCONF and NETMOD WGs. With this
> action we can also fix well-known issues.
> >
> > Concerning the NETCONF WG I would see it as valuable if we develop:
> > - a RFC6241bis draft removing the current datasore concept
> > specification, and getting rid of well-known issues e.g. with the
> >  operation,
> > - a new protocol- and language-independent standard document (RFC XYZ)
> > defining the generic datastore concept and framework and describing
> > its use (based on and following the DT solution draft),
> > - adding potential extensions to RFC6241bis (following the DT draft
> > and with a normative reference to RFC XYZ),
> > - adding potential extensions to a RESTCONF-bis RFC (following the DT
> > draft and with a normative reference to RFC XYZ),
> >
> > Concerning the NETMOD WG I would see it as valuable if we develop:
> > - RFC7950bis deleting protocol-dependent details and specifying the
> > datastore usage with YANG on a generic level (with a normative
> > reference to RFC XYZ),
> > - adding potential extensions to RFC7950bis, e.g. concerning the
> > proposed  element,
> > - possibly an RFC 6244bis to describe architectural aspects. However RFC6244
> is Informational and a RFC6244bis would be still Informational. I'm not sure
> whether this is really necessary. The DT proposal does already describe such a
> solution and can be seen as an update to RFC 6244.
> > - RFC6087bis giving guidelines on how to use YANG with the new datastore
> concept.
> >
> > Referring to Lada's proposal concerning the spin off document from
> > RFC7950 ("Adapting NETCONF for use with YANG"), I think this can be
> provided in the corresponding protocol RFCs, i.e.
> > for NETCONF a section on "Using NETCONF with YANG" in RFC6241bis and
> for RESTCONF "Using RESTCONF with YANG" in RESTCONF-bis RFC.
> >
> > Hope this helps as a starting point on the way to a good plan.
> >
> > PS: As Benoit suggested some time ago we might also consider to rename
> NETCONF WG as it is not only on NETCONF protocol anymore.
> >
> > Regards,
> > Mehmet
> >
> > On Mon, Dec 5, 2016 at 6:19 PM Andy Bierman 
> wrote:
> > On Mon, Dec 5, 2016 at 4:02 AM, Juergen Schoenwaelder
>  wrote:
> > On Mon, Dec 05, 2016 at 11:36:11AM +0100, Ladislav Lhotka wrote:
> > >
> > > >
> > > > I disagree that the datastore model is a protocol specific aspect.
> > > > I consider datastores an architectural component binding data
> > > > models and protocols together. In fact, the 'traditional'
> > > > datastore model
> > >
> > > I would agree with this if datastores were a general concept in YANG, but
> the revised-datastores draft explicitly introduces the "intended" and 
> "applied"
> datastores that may be irrelevant to other protocols using YANG, and even
> needn't be used in all NETCONF implementations. I wouldn't call this "an
> architectural component" of YANG.
> > >
> >
> > An architectural component of this new management framework (that does
> > not have a name). The fact that not all protocols may expose all
> > datastores is IMHO not a reason that the datastore model is not an
> > architectural framework.
> >
> > > If you are saying that it will have nontrivial impact on YANG, I would 
> > > like to
> see it explained in sec. 6.3. Without this information I am quite reluctant to
> agree with the adoption.
> >
> > An operational state datastore has implications how one writes data
> > models. It may not directly affect YANG itself but 

Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

[Acee Lindem (acee)]

Support. 
Thanks,
Acee

On 12/12/16, 6:31 PM, "netmod on behalf of Lou Berger"
 wrote:

>All,
>
>This is start of a two week* poll on making
>draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group
>document.
>
>Please send email to the list indicating "yes/support" or "no/do not
>support".  If indicating no, please state your reservations with the
>document.  If yes, please also feel free to provide comments you'd like
>to see addressed once the document is a WG document.
>
>* Given the holiday, the poll ends December 28.
>
>Thank you,
>NetMod WG Chairs
>
>___
>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

Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

[wangzitao]

I have read this document, and I support to adopt it.

Best Regards!
-Michael

-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Lou Berger
发送时间: 2016年12月13日 7:32
收件人: NetMod WG
抄送: NetMod WG Chairs
主题: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

All,

This is start of a two week* poll on making
draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group document.

Please send email to the list indicating "yes/support" or "no/do not support".  
If indicating no, please state your reservations with the document.  If yes, 
please also feel free to provide comments you'd like to see addressed once the 
document is a WG document.

* Given the holiday, the poll ends December 28.

Thank you,
NetMod WG Chairs

___
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