[netmod] I-D Action: draft-ietf-netmod-syslog-model-21.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : A YANG Data Model for Syslog Configuration
Authors : Clyde Wildes
  Kiran Koushik
Filename: draft-ietf-netmod-syslog-model-21.txt
Pages   : 34
Date: 2018-02-14

Abstract:
   This document defines a YANG data model for the configuration of a
   syslog process.  It is intended this model be used by vendors who
   implement syslog in their systems.

   The YANG model in this document conforms to the Network Management
   Datastore Architecture defined in [I-D.ietf-netmod-revised-
   datastores].

Editorial Note (To be removed by RFC Editor)

   This document contains many placeholder values that need to be
   replaced with finalized values at the time of publication.  This note
   summarizes all of the substitutions that are needed.  No other RFC
   Editor instructions are specified elsewhere in this document.

   Artwork in this document contains shorthand references to drafts in
   progress.  Please apply the following replacements:

   o  "I-D.ietf-netconf-keystore" --> the assigned RFC value for draft-
  ietf-netconf-keystore


   o  "I-D.ietf-netconf-tls-client-server" --> the assigned RFC value
  for draft-ietf-netconf-tls-client-server


   o  "" --> the assigned RFC value for this draft



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-21
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-21


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20

[Kent Watsen]

Buggers, I thought we caught that tree-diagrams informative/normative thing 
before.

Regardless, Clyde, please note that I think I was wrong before from the 
shepherd write-up regarding idnits having a problem:

"""
  == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line 1340,
 but no explicit reference was found in the text
 '[I-D.ietf-netconf-keystore] Watsen, K., "YANG Data Model for a "Keys...'

   This is a bug in idnits, whereby a reference that splits two lines is
   not found.
"""

Looking at the XML, it seems that references are not specified correctly.

CURRENT:

This module imports typedefs from [RFC7223], groupings from
[I-D.ietf-netconf-keystore], and [I-D.ietf-netconf-tls-client-server], 
and it references [RFC5424],
[RFC5425], [RFC5426], and [RFC5848] and [Std-1003.1-2008].

SHOULD BE:

This module imports typedefs from , 
groupings from
, and , and it references ,
, , and  and .

Right?

And while you're at it, please update the reference to the tree-diagrams draft 
(-06 is current).  Also, missing is an RFC Editor note requesting that the I-D 
reference to be updated to reflect the assigned RFC number.

Please also address these issues when posting -21 to address Benoit's issues.  
Please post -21 ASAP as Benoit has already placed this draft on the IESG 
telechat in a couple weeks.

Thanks,
Kent // shepherd


On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise" 
 on behalf of 
bcla...@cisco.com> wrote:

Dear all,

- the draft is NMDA compliant, right? It should be mentioned.
Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro

   The YANG model in this document conforms to the Network Management

   Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.


- As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams] should be 
an informative reference, not normative.

- Editorial:
OLD:
This draft addresses the common leafs
NEW:
This document addresses the common leafs

Please publish a new version asap.
In the mean time, I'm sending this draft to IETF LC.

Regards, Benoit


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

[netmod] AD review of draft-ietf-netmod-rfc6087bis Part 2

[Benoit Claise]

Dear all,

Here is the part 2 of the AD review, from section 4.21 on.

Regarding the part 1, thanks Andy for addressing all comments in version 17.

- section 4.22 "Data Correlation.

Not sure what you mean by the section title and "Data can be correlated in various 
ways"?
Which data? YANG modules, YANG objects, object instances, from different YANG 
server, etc.
I guess I miss a sentence or two regarding this "correlation" objective and 
which guidelines this section
is going to provide to "authors and reviewers of Standards Track specifications 
containing YANG data model modules".
Note: I read that section multiple times.

- section 4.22
   It is sometimes useful to separate configuration data and operational
   state, so that they do not not even share the exact same naming
   characteristics.  The correlation between configuration the
   operational state that is affected by changes in configuration is a
   complex problem.  There may not be a simple 1:1 relationship between
   a configuration data node and an operational state node.  Further
   work is needed in YANG to clarify this relationship.  Protocol work
   may also be needed to allow a client to retrieve this type of
   information from a server.  At this time the best practice is to
   clearly document any relationship to other data structures in the
   "description" statement.

Isn't it clarified with NMDA. It's not inline with 4.23.2, which says:

   Designers SHOULD describe and justify any NMDA exceptions in detail,
   such as the use of separate subtrees and/or separate leafs.

... and I guess confusing in light of the real guidelines in 4.23.3
Btw, why is this paragraph in 4.22 and not in 4.23?

- section 4.23

Operational state is now modeled using YANG according to new NMDA,

Please add a reference to the draft.

- section 4.26 "YANG 1.1 Guidelines"
I'm confused by the title. The entire document is about 1.1, right?
I guess you want to express something such as "YANG 1.1 specific Constructs 
Guidelines"

- section 4.26.1

 Multiple revisions of the same module can be imported, provided that
 different prefixes are used.

Reading https://tools.ietf.org/html/rfc7950#section-7.1.5. Any contradiction?
Then reading:
   This MAY be done if the authors can
   demonstrate that the "avoided" definitions from the most recent of
   the multiple revisions are somehow broken or harmful to
   interoperability.

"avoided" definitions?
I simply don't understand this sentence.

- section 4.26.4
   The NETCONF Access Control Model (NACM) [RFC6536 
] does not support
   parameter access control for RPC operations.

Let's use draft-ietf-netconf-rfc6536bis


- Appendix B

   YANG Module Registry: Register the YANG module name, prefix,
 namespace, and RFC number, according to the rules specified
 in [RFC7950 ].

I guess this is [RFC6020] in this case. Indeed the "YANG Module Names" registry 
is specified in RFC6020/.
See for example 
https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-6

- Appendix B
References -- verify that the references are properly divided
  between normative and informative references, thatRFC 2119 
  is
  included as a normative reference if the terminology defined
  therein is used in the document

Refer to RFC8174

- Appendix B (and maybe some more text somewhere else.
To refer to Tom Petch latest email to NETMOD, we should need a few words about:
  If a YANG module has a Reference or Description clause specifying an
  I-D, and the I-D is listed as an Informative Reference.

Regards, Benoit

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

[netmod] Last Call: (A YANG Data Model for Syslog Configuration) to Proposed Standard

[The IESG]

The IESG has received a request from the Network Modeling WG (netmod) to
consider the following document: - 'A YANG Data Model for Syslog
Configuration'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2018-02-28. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   This document defines a YANG data model for the configuration of a
   syslog process.  It is intended this model be used by vendors who
   implement syslog in their systems.

Editorial Note (To be removed by RFC Editor)

   This draft contains many placeholder values that need to be replaced
   with finalized values at the time of publication.  This note
   summarizes all of the substitutions that are needed.  No other RFC
   Editor instructions are specified elsewhere in this document.

   Artwork in this document contains shorthand references to drafts in
   progress.  Please apply the following replacements:

   o  "I-D.ietf-netconf-keystore" --> the assigned RFC value for draft-
  ietf-netconf-keystore


   o  "I-D.ietf-netconf-tls-client-server" --> the assigned RFC value
  for draft-ietf-netconf-tls-client-server


   o  "" --> the assigned RFC value for this draft





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information: 
draft-ietf-netconf-tls-client-server: YANG Groupings for TLS Clients and 
TLS Servers (None - IETF stream)
draft-ietf-netconf-keystore: YANG Data Model for a "Keystore" Mechanism 
(None - IETF stream)



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

[netmod] A mean to match many entries would ease the writing of rules

[otilibil]

Hello all,
I reviewed draft-ietf-netconf-rfc6536bis-09; it seems the draft misses  
a way to match many entries under the same rule. For example, instead  
of,


  
permit-get-config
ietf-netconf
get-config
exec
permit

  Permits invocation of the NETCONF 'get-config'.

  
  
permit-get
ietf-netconf
get
exec
permit

  Permits invocation of the NETCONF 'get'.

  

It would ease the writing to have a keyword (or a white space, as for  
'access-operations') to match many entries at the same time:


  
permit-get
ietf-netconf
get get-config
exec
permit

  Permits invocation of the NETCONF 'get' & 'get-config'.

  

So, the valid values will become (for 'rpc-name', 'notification-name',  
and 'path'):


 * A string for one entry
 * A string for more than one entry (a white space separates entries)
 * Or, the catch-all '*'.

How do you see my proposal?

Regards,
Ariel



---
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr

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

[netmod] AD review of draft-ietf-netmod-syslog-model-20

[Benoit Claise]

Dear all,

- the draft is NMDA compliant, right? It should be mentioned.
Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro

   The YANG model in this document conforms to the Network Management
   Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.

- As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams] 
should be an informative reference, not normative.


- Editorial:
OLD:
This draft addresses the common leafs
NEW:
This document addresses the common leafs

Please publish a new version asap.
In the mean time, I'm sending this draft to IETF LC.

Regards, Benoit

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

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Ladislav Lhotka]

Robert Wilton  writes:

> Hi Alex,
>
> I see no real advantages to putting this directly in YANG library bis, 
> but I think that augmenting the YANG library bis structure is just fine 
> (in the same way that the latest version of schema mount has proposed to 
> do).
>
> Generally, I think that it is good that NETCONF/YANG is built up of 
> fairly loosely coupled components.  E.g. implementations can choose 
> which subset of features are required for their particular circumstances 
> (e.g. protocol, encoding, schema mount, YANG push, with-defaults, etc).  
> If over time it becomes clear that it is critical for good interop that 
> particular features must always be supported then we can define NETCONF 
> 2.0 or 3.0 that mandates that a particular set of technologies must be 
> implemented to meet the standard.
>
> The added bonus of having these components loosely coupled is that they 
> can be improved and refined independently, potentially allowing IETF to 
> move a bit quicker advancing the technologies.
>
> Finally, even if there is common meta-data structure that is shared by 
> multiple features, that still doesn't mean that it has to go in the base 
> YANG library spec, that can still just be shared common extension.

+1

Lada

>
> Thanks,
> Rob
>
>
> On 13/02/2018 21:25, Alexander Clemm wrote:
>> My proposal is to add this to the YANG data model.  I think this logically 
>> belongs to YANG library which is why I would like to see it there.  I also 
>> think it will be useful to many implementations.  All, probably not, but 
>> they have also survived without YANG library for a while:-) Of course, it is 
>> always possible to write another draft or do a bisbis.
>> Cheers
>> --- Alex
>>
>>> -Original Message-
>>> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
>>> Sent: Tuesday, February 13, 2018 12:29 PM
>>> To: Alexander Clemm 
>>> Cc: Mahesh Jethanandani ; NETCONF WG
>>> ; NETMOD WG 
>>> Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
>>>
>>> I must have missed your actionable proposal that is relevant for _all_ 
>>> NETCONF
>>> and RESTCONF implementations.
>>>
>>> YANG data models are extensible so lets use that.
>>>
>>> /js
>>>
>>> On Tue, Feb 13, 2018 at 07:58:37PM +, Alexander Clemm wrote:
 Well, we need a general solution for that.  YANG-push is just one use case.
>>> There are other cases where there will be "metadata" (that does not pertain 
>>> to
>>> instance data)  and capabilities that clients want to discover.  YANG 
>>> library (in
>>> itself providing "metadata" about what a server supports and is capable of) 
>>> is an
>>> excellent place to maintain this information.  It also provides the 
>>> opportunity to
>>> be systemic about it, as opposed to requiring everyone to define their own 
>>> little
>>> custom extensions.
 --- Alex

> -Original Message-
> From: Juergen Schoenwaelder
> [mailto:j.schoenwael...@jacobs-university.de]
> Sent: Tuesday, February 13, 2018 11:48 AM
> To: Alexander Clemm 
> Cc: Mahesh Jethanandani ; NETCONF WG
> ; NETMOD WG 
> Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
>
> Alexander,
>
> I disagree. This YANG Library is mandatory for all implementations;
> what you talk about seems to concern only implementations that
> support YANG push. Hence, this is an extension that should go in its own
>>> module.
> /js
>
> On Tue, Feb 13, 2018 at 07:38:31PM +, Alexander Clemm wrote:
>> Hi,
>>
>> I have taken a look at this document.
>>
>> My main comment is that one aspect that is missing, that I believe
>> should be
> added, concerns the inclusion of certain metadata about the modules.
> Specifically, in the context of YANG-Push we had a discussion about
> being able to mark nodes that are notifiable on change.  This is
> just one particular use case of a more general issue; in YANG-Push
> after much debate the conclusion was for now to simply make
> implementors aware of this issue and advise that a solution to this
> must be provided, with the clear understanding that eventually a standard
>>> solution should be defined.
>> Since the goal of YANG-Library is to allow clients to find out
>> what is actually
> supported on a given server, this is the right place to keep this
> information.  One possible way to address this would be, for a given
> module, to maintain a list of "meta-info", with a key "meta-tag",
> and a list with references to the nodes to which the metadata
> applies.  In the case of notifiable-on-change, you would have a list
> with one entry "notifiable-on-change", and then the list with the node
>>> definitions to which 

[netmod] Draft Informative references in a YANG module

[t.petch]

If a YANG module has a Reference or Description clause specifying an
I-D, and the I-D is listed as an Informative Reference, as many are
outside the
NETCONF/Netmod WGs, then will the I-D be published with that reference
still as a draft e.g. with text such as

 reference "I-D.ietf-netconf-tls-client-server: TLS Client and Server
Models";

or

See section 4.2.1 of draft-ietf-ntp-packet-timestamps
?

The RFC Editor has a MISSREF status/procedure but that only applies to a
Normative Reference, not to an Informative one, so will the RFC appear
with the Reference or Description clause specifying the I-D?

Tom Petch


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

Re: [netmod] [Netconf] LC on YANG Library (bis)

[Robert Wilton]

Hi Alex,

I see no real advantages to putting this directly in YANG library bis, 
but I think that augmenting the YANG library bis structure is just fine 
(in the same way that the latest version of schema mount has proposed to 
do).


Generally, I think that it is good that NETCONF/YANG is built up of 
fairly loosely coupled components.  E.g. implementations can choose 
which subset of features are required for their particular circumstances 
(e.g. protocol, encoding, schema mount, YANG push, with-defaults, etc).  
If over time it becomes clear that it is critical for good interop that 
particular features must always be supported then we can define NETCONF 
2.0 or 3.0 that mandates that a particular set of technologies must be 
implemented to meet the standard.


The added bonus of having these components loosely coupled is that they 
can be improved and refined independently, potentially allowing IETF to 
move a bit quicker advancing the technologies.


Finally, even if there is common meta-data structure that is shared by 
multiple features, that still doesn't mean that it has to go in the base 
YANG library spec, that can still just be shared common extension.


Thanks,
Rob


On 13/02/2018 21:25, Alexander Clemm wrote:

My proposal is to add this to the YANG data model.  I think this logically 
belongs to YANG library which is why I would like to see it there.  I also 
think it will be useful to many implementations.  All, probably not, but they 
have also survived without YANG library for a while:-) Of course, it is always 
possible to write another draft or do a bisbis.
Cheers
--- Alex


-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Sent: Tuesday, February 13, 2018 12:29 PM
To: Alexander Clemm 
Cc: Mahesh Jethanandani ; NETCONF WG
; NETMOD WG 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)

I must have missed your actionable proposal that is relevant for _all_ NETCONF
and RESTCONF implementations.

YANG data models are extensible so lets use that.

/js

On Tue, Feb 13, 2018 at 07:58:37PM +, Alexander Clemm wrote:

Well, we need a general solution for that.  YANG-push is just one use case.

There are other cases where there will be "metadata" (that does not pertain to
instance data)  and capabilities that clients want to discover.  YANG library 
(in
itself providing "metadata" about what a server supports and is capable of) is 
an
excellent place to maintain this information.  It also provides the opportunity 
to
be systemic about it, as opposed to requiring everyone to define their own 
little
custom extensions.

--- Alex


-Original Message-
From: Juergen Schoenwaelder
[mailto:j.schoenwael...@jacobs-university.de]
Sent: Tuesday, February 13, 2018 11:48 AM
To: Alexander Clemm 
Cc: Mahesh Jethanandani ; NETCONF WG
; NETMOD WG 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)

Alexander,

I disagree. This YANG Library is mandatory for all implementations;
what you talk about seems to concern only implementations that
support YANG push. Hence, this is an extension that should go in its own

module.

/js

On Tue, Feb 13, 2018 at 07:38:31PM +, Alexander Clemm wrote:

Hi,

I have taken a look at this document.

My main comment is that one aspect that is missing, that I believe
should be

added, concerns the inclusion of certain metadata about the modules.
Specifically, in the context of YANG-Push we had a discussion about
being able to mark nodes that are notifiable on change.  This is
just one particular use case of a more general issue; in YANG-Push
after much debate the conclusion was for now to simply make
implementors aware of this issue and advise that a solution to this
must be provided, with the clear understanding that eventually a standard

solution should be defined.

Since the goal of YANG-Library is to allow clients to find out
what is actually

supported on a given server, this is the right place to keep this
information.  One possible way to address this would be, for a given
module, to maintain a list of "meta-info", with a key "meta-tag",
and a list with references to the nodes to which the metadata
applies.  In the case of notifiable-on-change, you would have a list
with one entry "notifiable-on-change", and then the list with the node

definitions to which this tag applies.

Editorial nit:
2nd paragraph Introduction: informaton --> information

Thanks
--- Alex

From: Netconf [mailto:netconf-boun...@ietf.org] On Behalf Of
Mahesh Jethanandani
Sent: Thursday, February 01, 2018 11:00 AM
To: NETCONF WG 
Cc: NETMOD WG 
Subject: [Netconf] LC on YANG Library (bis)

WG,

The authors of rfc7895bis have indicated that they believe the
document is

ready for LC[1].

This starts a two week LC on the