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

[Clyde Wildes (cwildes)]

Kent, Tom, Yaron, and Ron,

A new version of the draft-ietf-netmod-syslog-model has been published that 
addresses your concerns.

Thanks,

Clyde

On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen"  wrote:




> Kent
> 
> You illustrate beautifully the problem I would like a solution to.
>
> The current thinking AFAICT is that tree-diagrams
> should be an Informative Reference.
>
> Therefore, the RFC Editor will not hold publication until an RFC number
> is assigned.
> 
> Therefore, a note asking the I-D reference to be updated to reflect the
> assigned RFC number is null - the RFC can be published with the
> reference as an i-d and not as an RFC which is what I expect the RFC
> Editor to do.
> 
> QED


Except I know that this draft will be stuck in MISREF state and 
tree-diagrams
will in fact be assigned an RFC number by the time this draft is published.

K.


> Note that this is not the case of a Normative i-d reference being buried
> in the YANG module and not being.noticed by the RFC Editor; that problem
> I am content with.
>
>
>Tom Petch








>
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=cJ7MVnQVc1hgxpVF7oYiVn6Rbm-Qf2dDyrfYhL-s9io=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8=
>



___
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] I-D Action: draft-ietf-netmod-syslog-model-22.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-22.txt
Pages   : 34
Date: 2018-02-21

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 [draft-ietf-netmod-revised-
   datastores].


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-22
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-22

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


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] Secdir last call review of draft-ietf-netmod-syslog-model-21

[Gary Wu (garywu)]

>  Security Comments
>  
>  * I think almost all writable data nodes here are sensitive, because 
a network
>  attacker's first move is to block any logging on the host, and many 
of the data
>  nodes here can be used for this purpose.
> 
> [clw1] I will reword the security section to include all writeable nodes 
as sensitive.
> 
>  * Re: readable data nodes, I'm not
>  sure which are sensitive, and the document should give an example or 
two rather
>  than just say "some". Otherwise the security advice is not 
actionable. One
>  example: "remote" sections leak information about other hosts in the 
network.
> 
> [clw1] This text was lifted from another model. I will review the 
readable nodes and update.
> 
>  * Write operations... can have a negative effect on network 
operations. - I would
>  add "and on network security", because logs are often used to detect 
security
>  breaches.
> 
> [clw1] I will add this phrase.
> 

The fact that the syslog data nodes are write-sensitive can be made explicit in
the model by making the whole configuration tree nacm:default-deny-write, and
making read-sensitive subtrees nacm:default-deny-all.

Thanks,
Gary Wu

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

[netmod] Last Call: (Guidelines for Authors and Reviewers of YANG Data Model Documents) to Best Current Practice

[The IESG]

The IESG has received a request from the Network Modeling WG (netmod) to
consider the following document: - 'Guidelines for Authors and Reviewers of
YANG Data Model Documents'
   as Best Current Practice

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-03-07. 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 memo provides guidelines for authors and reviewers of Standards
   Track specifications containing YANG data model modules.  Applicable
   portions may be used as a basis for reviews of other YANG data model
   documents.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) and RESTCONF protocol
   implementations that utilize YANG data model modules.  This document
   obsoletes RFC 6087.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/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: 
rfc6021: Common YANG Data Types (Proposed Standard - IETF stream)
rfc7950: The YANG 1.1 Data Modeling Language (Proposed Standard - IETF 
stream)
rfc4741: NETCONF Configuration Protocol (Proposed Standard - IETF stream)
rfc4742: Using the NETCONF Configuration Protocol over Secure SHell (SSH) 
(Proposed Standard - IETF stream)



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

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

[Benoit Claise]

Thank you Andy.
Sending to IETF LC now.

Regards, Benoit

Hi,

I think draft-18 addresses all these issues.
A guideline about key leaf order has also been added.

Andy


On Wed, Feb 14, 2018 at 7:11 AM, Benoit Claise > wrote:


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.

Readinghttps://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 
examplehttps://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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod