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

2017-08-09 Thread Kent Watsen 

Today's activity on this thread necessitates another response as well:

The WG LC is closed.  Authors, please address any comments that have
been received, and let the WG know how the issues have been addressed,
and when a version is available that is ready to be submitted for 
publication.

Thanks,
Kent (and Lou)



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

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

2017-08-09 Thread Kent Watsen 
Hi Clyde,

In my drafts that depend on more than one work in progress, I typically assign 
each of them a value (e.g., , , ) and then have RFC Editor 
instructions mapping each to a specific value.

Kent // contributor

--

Tom,

The agreement was that I should use “” until the two unapproved RFCs that 
the model depends on are assigned numbers.

 RFC : Keystore Management
 RFC : Transport Layer Security (TLS) Client";

Imported are:

  import ietf-tls-client {
prefix tlsc;
  }

  import ietf-keystore {
prefix ks;
  }


Have numbers been assigned?

Thanks,

Clyde

On 8/9/17, 4:32 AM, "t.petch"  wrote:

Clyde

You use  as a placeholder for three different RFC and two of these
do not appear AFAICT in the list of References.

This might be a challenge for the RFC Editor.

Tom Petch


- Original Message -
From: "Clyde Wildes (cwildes)" 
Sent: Wednesday, July 19, 2017 6:48 PM


> Hi Alex,
>
> Answers inline as [clyde]…
>
> On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell"
 wrote:
>
> I am considering to implement the data model in this draft.
(dependent on business priorities of course)
> I have reviewed this draft and found the following issues.
>
> * I see pattern-match is specified to use POSIX 1003.2 regular
expressions. This is presumably for compatibility with existing
implementations; however it is inconsistent with most of YANG (which is
specified to use XPath regular expressions) - unless these are the same.
>
> [clyde] I believe that my answer in the other thread explains why we
used Posix 1003.2 – it is commonly used.
>
> * pattern-match is inside the facility-filter container; common
sense says this is wrong as pattern-match has nothing to do with
facilities.
>
> [clyde] I will move pattern-match up one level in the next version of
the draft. Thanks for catching this!
>
> * The advanced-compare container groups together two nodes that
share a common "when" and "if-feature" statement, but don't seem to have
any semantic relation to each other. Are there general guidelines on
when to use a container?
>
> [clyde] The confusion may come as a result of the when clause
appearing before the if-feature clause which is set by the IETF
statement order recommendation.
>
> The when construct was suggested by Martin Björklund as a way of
solving the case that advanced-compare does not apply for the ‘all’ and
‘none’ case.
>
> The if-feature applies to the entire container – it is either
supported or not.
>
> * The advanced-compare container has a description starting with
"This leaf ..." even though it is not a leaf.
>
> [clyde] This will be fixed in the next draft.
>
> * The examples are missing  nodes.
>
> [clyde] This will be fixed in the next draft.
>
> * Perhaps there should be more consistent terminology for
receivers of syslog messages; both "collectors" and "actions" are used
in the draft. RFC 5424 uses "collector" for the ultimate recipient of a
log message - which might not be applicable, because the sending system
has no idea whether the receiving system is a collector or a relay.
>
> [clyde] The definition of “collector” in RFC 5424 is: A "collector"
gathers syslog content for further analysis.
>
> actions relate to the “further analysis” taken by the “collector”.
>
> “Collectors” appears in the model under the remote action and I
believe the usage is correct:
>   container remote {
> if-feature remote-action;
> description
>   "This container describes the configuration parameters for
>forwarding syslog messages to remote relays or
collectors.";
>
> I will revise the description of these terms in the next draft.
>
> Thanks,
>
> Clyde
>
> 
> From: netmod  on behalf of Kent Watsen

> Sent: Saturday, 8 July 2017 6:34 a.m.





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

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

2017-08-09 Thread Clyde Wildes (cwildes) 
Tom,

The agreement was that I should use “” until the two unapproved RFCs that 
the model depends on are assigned numbers.

 RFC : Keystore Management
 RFC : Transport Layer Security (TLS) Client";

Imported are:

  import ietf-tls-client {
prefix tlsc;
  }

  import ietf-keystore {
prefix ks;
  }


Have numbers been assigned?

Thanks,

Clyde

On 8/9/17, 4:32 AM, "t.petch"  wrote:

Clyde

You use  as a placeholder for three different RFC and two of these
do not appear AFAICT in the list of References.

This might be a challenge for the RFC Editor.

Tom Petch


- Original Message -
From: "Clyde Wildes (cwildes)" 
Sent: Wednesday, July 19, 2017 6:48 PM


> Hi Alex,
>
> Answers inline as [clyde]…
>
> On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell"
 wrote:
>
> I am considering to implement the data model in this draft.
(dependent on business priorities of course)
> I have reviewed this draft and found the following issues.
>
> * I see pattern-match is specified to use POSIX 1003.2 regular
expressions. This is presumably for compatibility with existing
implementations; however it is inconsistent with most of YANG (which is
specified to use XPath regular expressions) - unless these are the same.
>
> [clyde] I believe that my answer in the other thread explains why we
used Posix 1003.2 – it is commonly used.
>
> * pattern-match is inside the facility-filter container; common
sense says this is wrong as pattern-match has nothing to do with
facilities.
>
> [clyde] I will move pattern-match up one level in the next version of
the draft. Thanks for catching this!
>
> * The advanced-compare container groups together two nodes that
share a common "when" and "if-feature" statement, but don't seem to have
any semantic relation to each other. Are there general guidelines on
when to use a container?
>
> [clyde] The confusion may come as a result of the when clause
appearing before the if-feature clause which is set by the IETF
statement order recommendation.
>
> The when construct was suggested by Martin Björklund as a way of
solving the case that advanced-compare does not apply for the ‘all’ and
‘none’ case.
>
> The if-feature applies to the entire container – it is either
supported or not.
>
> * The advanced-compare container has a description starting with
"This leaf ..." even though it is not a leaf.
>
> [clyde] This will be fixed in the next draft.
>
> * The examples are missing  nodes.
>
> [clyde] This will be fixed in the next draft.
>
> * Perhaps there should be more consistent terminology for
receivers of syslog messages; both "collectors" and "actions" are used
in the draft. RFC 5424 uses "collector" for the ultimate recipient of a
log message - which might not be applicable, because the sending system
has no idea whether the receiving system is a collector or a relay.
>
> [clyde] The definition of “collector” in RFC 5424 is: A "collector"
gathers syslog content for further analysis.
>
> actions relate to the “further analysis” taken by the “collector”.
>
> “Collectors” appears in the model under the remote action and I
believe the usage is correct:
>   container remote {
> if-feature remote-action;
> description
>   "This container describes the configuration parameters for
>forwarding syslog messages to remote relays or
collectors.";
>
> I will revise the description of these terms in the next draft.
>
> Thanks,
>
> Clyde
>
> 
> From: netmod  on behalf of Kent Watsen

> Sent: Saturday, 8 July 2017 6:34 a.m.



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

Re: [netmod] Query about augmenting module from submodule in YANG 1.0

2017-08-09 Thread Andy Bierman 
On Wed, Aug 9, 2017 at 7:20 AM, Vladimir Vassilev 
wrote:

>
> On 08/08/2017 10:15 AM, Ivory, William wrote:
>
>>
>> Hi Vladimir,
>>
>> We have one YANG file that represents multiple components in the system.
>> Currently they are bundled together, so having a single YANG file is ok.
>> In future we’d like to be able to break this down into multiple daemons
>> each dealing with a subset of the YANG.  However, we don’t wish to change
>> the namespace of the YANG as that would not be backwards compatible.  So,
>> submodules looked to be a good way to do this.  I wouldn’t call it drastic
>> – it is one YANG file we are talking about breaking up into parts.
>>
>> I see your point. IMO the only real justification for people designing
> using submodules instead of modules is when they are limited to single
> namespace and need a workaround solution like in your case.
> I was hoping your problem could be something that can convince me that
> submodules existence in YANG can be justified with more then its function
> as a workaround replacement for modules in this particular case.
>
> My grudge against submodules is not only based on the significant
> implementation and support effort they require for something that is used
> very rarely. A completely separate source file quantum for YANG that lacks
> the key property of a module at the YANG level - modularity. For submodules
> are both non-reusable and interdependent. Very few organizations publish
> submodule based designs probably for the same reasons I avoid them.
> Submodules are great if you want to publish non-reusable YANG though.
>
> IETF went once for design with submodules in ietf-snmp.yang. Even in that
> case (well organized YANG module) I would have preferred a single file with
> some of the exotic features modularized in separate modules instead.
> Dynamic compilers still need to go through all submodules even in device
> that supports only the base SNMP functionality before features can be
> evaluated. As a result instead of the 10KB of actually implemented schema
> 60KB of additional YANG has to be retrieved in the worst case and compiled.
>
> Both submodules and alternative datastores are examples of how complexity
> is introduced with innocent intentions and how it eventually multiplies
> (ref. draft-nmdsdt-netconf-rfc7895bis-01).
>
> The biggest problem I have with submodules is they break the atomicity of
> the module concept. There is something that is not right with that. Worse
> than the unjustified implementation and standardization effort. A
> compromise that should have been avoided.
>
> IMO If you absolutely don't need submodules it is best to stay away from
> them.
>
>


I argued against submodules from the start.
They add a lot of complexity for implementors and module readers.
Too much cost for the 1 benefit of reusing a namespace.
Good summary about why they are quite rigid and not really modular at all.

They work even worse when include-without-revision is used.
In this most common case, the actual submodule revisions used
are very implementation-dependent.  There is no way to cross-check
the main module revision against the submodule revisions.
(i.e., no belongs-to foo@2017-01-01, just belongs-to foo).

I have seen companies start to use submodules, then undo it when they
figure out
that a monolithic YANG-ball is not as workable as a module-set.



> Vladimir
>
>

Andy


> Regards,
>>
>> William
>>
>> *From:*Vladimir Vassilev [mailto:vladi...@transpacket.com]
>> *Sent:* 07 August 2017 20:31
>> *To:* Ivory, William 
>> *Cc:* 'netmod@ietf.org' 
>> *Subject:* Re: [netmod] Query about augmenting module from submodule in
>> YANG 1.0
>>
>> Hello,
>>
>> IMO "submodule"s  are a striking example of redundant complexity in an
>> otherwise very close to perfection YANG (regardless if it is YANG 1.0 or
>> 1.1).
>>
>> Modules and submodules have been around for a while however the ratio of
>> the currently published modules compared with the submodules is about 40
>> modules to 1 submodule (if one ignores all the modules and submodules from
>> particular networking hardware manufacturer that is particularly keen on
>> using submodules). As a far but still relevant analogy Java has a
>> limitation of 1 file per class and this atomicity has proven to be an
>> advantage especially in terms of enforcing modularity. IMO there is nothing
>> that can be done with the help of submodules that can not be done without
>> them.
>>
>> For the sake of the argument can you provide a synthesized description of
>> the problem that lead you to a drastic solution like "we’ll look at trying
>> to put everything into submodules in this case."?
>>
>> Vladimir
>>
>> On 08/07/2017 04:37 PM, Ivory, William wrote:
>>
>> Hi Jan,
>>
>> Thanks – we’ll look at trying to put everything into submodules in
>> this case.
>>
>> Regards,
>>
>> William
>>
>> *From:*Jan Lindblad [mailto:j...@tail-f.com]
>> *Sent:* 07 August 2017 14:28
>> *To:* Ivor

Re: [netmod] Query about augmenting module from submodule in YANG 1.0

2017-08-09 Thread Juergen Schoenwaelder 
On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:
> 
> I remember that in early stages of YANG there was some irrational
> fear of introducing too many namespaces, and submodules may be a
> consequence of it. As you write, submodules provide no benefits
> whatsoever in terms of modularity, but the overhead in terms of
> metadata, IANA registration etc. is pretty much the same as for
> modules.

In case YANG 2.0 is ever done, I suggest someone files a proposal to
remove submodules if the cost/benefit ratio is at odds. There is
nothing wrong with removing stuff that has been found problematic.

The motivation for submodules was that organizations maintaining large
modules with multiple people can do so without having to mess around
with tools like m4 scripts to produce a single module from 'snippets'
and to avoid integration surprises. But perhaps using m4 scripts and
decent version control systems (that can integrate and compile on
checkin) is indeed cheaper than having submodules part of the YANG
language itself.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] Query about augmenting module from submodule in YANG 1.0

2017-08-09 Thread Ladislav Lhotka 
Vladimir Vassilev píše v St 09. 08. 2017 v 16:20 +0200:
> On 08/08/2017 10:15 AM, Ivory, William wrote:
> > 
> > Hi Vladimir,
> > 
> > We have one YANG file that represents multiple components in the 
> > system.  Currently they are bundled together, so having a single YANG 
> > file is ok.  In future we’d like to be able to break this down into 
> > multiple daemons each dealing with a subset of the YANG.  However, we 
> > don’t wish to change the namespace of the YANG as that would not be 
> > backwards compatible.  So, submodules looked to be a good way to do 
> > this.  I wouldn’t call it drastic – it is one YANG file we are talking 
> > about breaking up into parts.
> > 
> 
> I see your point. IMO the only real justification for people designing 
> using submodules instead of modules is when they are limited to single 
> namespace and need a workaround solution like in your case.
> I was hoping your problem could be something that can convince me that 
> submodules existence in YANG can be justified with more then its 
> function as a workaround replacement for modules in this particular case.
> 
> My grudge against submodules is not only based on the significant 
> implementation and support effort they require for something that is 
> used very rarely. A completely separate source file quantum for YANG 
> that lacks the key property of a module at the YANG level - modularity. 
> For submodules are both non-reusable and interdependent. Very few 
> organizations publish submodule based designs probably for the same 
> reasons I avoid them. Submodules are great if you want to publish 
> non-reusable YANG though.
> 
> IETF went once for design with submodules in ietf-snmp.yang. Even in 
> that case (well organized YANG module) I would have preferred a single 
> file with some of the exotic features modularized in separate modules 
> instead. Dynamic compilers still need to go through all submodules even 
> in device that supports only the base SNMP functionality before features 
> can be evaluated. As a result instead of the 10KB of actually 
> implemented schema 60KB of additional YANG has to be retrieved in the 
> worst case and compiled.

I agree. I have seen quite a few bugs (both in my and somebody else's code)
directly caused by submodules, e.g. in definition lookup. You are right that in
YANG 1.0 the "include" logic was really horrible but still we may be better off
with no submodules at all.

I remember that in early stages of YANG there was some irrational fear of
introducing too many namespaces, and submodules may be a consequence of it. As
you write, submodules provide no benefits whatsoever in terms of modularity, but
the overhead in terms of metadata, IANA registration etc. is pretty much the
same as for modules.

Lada

> 
> Both submodules and alternative datastores are examples of how 
> complexity is introduced with innocent intentions and how it eventually 
> multiplies (ref. draft-nmdsdt-netconf-rfc7895bis-01).
> 
> The biggest problem I have with submodules is they break the atomicity 
> of the module concept. There is something that is not right with that. 
> Worse than the unjustified implementation and standardization effort. A 
> compromise that should have been avoided.
> 
> IMO If you absolutely don't need submodules it is best to stay away from 
> them.
> 
> Vladimir
> 
> > Regards,
> > 
> > William
> > 
> > *From:*Vladimir Vassilev [mailto:vladi...@transpacket.com]
> > *Sent:* 07 August 2017 20:31
> > *To:* Ivory, William 
> > *Cc:* 'netmod@ietf.org' 
> > *Subject:* Re: [netmod] Query about augmenting module from submodule 
> > in YANG 1.0
> > 
> > Hello,
> > 
> > IMO "submodule"s  are a striking example of redundant complexity in an 
> > otherwise very close to perfection YANG (regardless if it is YANG 1.0 
> > or 1.1).
> > 
> > Modules and submodules have been around for a while however the ratio 
> > of the currently published modules compared with the submodules is 
> > about 40 modules to 1 submodule (if one ignores all the modules and 
> > submodules from  particular networking hardware manufacturer that is 
> > particularly keen on using submodules). As a far but still relevant 
> > analogy Java has a limitation of 1 file per class and this atomicity 
> > has proven to be an advantage especially in terms of enforcing 
> > modularity. IMO there is nothing that can be done with the help of 
> > submodules that can not be done without them.
> > 
> > For the sake of the argument can you provide a synthesized description 
> > of the problem that lead you to a drastic solution like "we’ll look at 
> > trying to put everything into submodules in this case."?
> > 
> > Vladimir
> > 
> > On 08/07/2017 04:37 PM, Ivory, William wrote:
> > 
> > Hi Jan,
> > 
> > Thanks – we’ll look at trying to put everything into submodules in
> > this case.
> > 
> > Regards,
> > 
> > William
> > 
> > *From:*Jan Lindblad [mailto:j...@tail-f.com]
> > *Sent:* 07 August 2017

Re: [netmod] Query about augmenting module from submodule in YANG 1.0

2017-08-09 Thread Vladimir Vassilev 


On 08/08/2017 10:15 AM, Ivory, William wrote:


Hi Vladimir,

We have one YANG file that represents multiple components in the 
system.  Currently they are bundled together, so having a single YANG 
file is ok.  In future we’d like to be able to break this down into 
multiple daemons each dealing with a subset of the YANG.  However, we 
don’t wish to change the namespace of the YANG as that would not be 
backwards compatible.  So, submodules looked to be a good way to do 
this.  I wouldn’t call it drastic – it is one YANG file we are talking 
about breaking up into parts.


I see your point. IMO the only real justification for people designing 
using submodules instead of modules is when they are limited to single 
namespace and need a workaround solution like in your case.
I was hoping your problem could be something that can convince me that 
submodules existence in YANG can be justified with more then its 
function as a workaround replacement for modules in this particular case.


My grudge against submodules is not only based on the significant 
implementation and support effort they require for something that is 
used very rarely. A completely separate source file quantum for YANG 
that lacks the key property of a module at the YANG level - modularity. 
For submodules are both non-reusable and interdependent. Very few 
organizations publish submodule based designs probably for the same 
reasons I avoid them. Submodules are great if you want to publish 
non-reusable YANG though.


IETF went once for design with submodules in ietf-snmp.yang. Even in 
that case (well organized YANG module) I would have preferred a single 
file with some of the exotic features modularized in separate modules 
instead. Dynamic compilers still need to go through all submodules even 
in device that supports only the base SNMP functionality before features 
can be evaluated. As a result instead of the 10KB of actually 
implemented schema 60KB of additional YANG has to be retrieved in the 
worst case and compiled.


Both submodules and alternative datastores are examples of how 
complexity is introduced with innocent intentions and how it eventually 
multiplies (ref. draft-nmdsdt-netconf-rfc7895bis-01).


The biggest problem I have with submodules is they break the atomicity 
of the module concept. There is something that is not right with that. 
Worse than the unjustified implementation and standardization effort. A 
compromise that should have been avoided.


IMO If you absolutely don't need submodules it is best to stay away from 
them.


Vladimir


Regards,

William

*From:*Vladimir Vassilev [mailto:vladi...@transpacket.com]
*Sent:* 07 August 2017 20:31
*To:* Ivory, William 
*Cc:* 'netmod@ietf.org' 
*Subject:* Re: [netmod] Query about augmenting module from submodule 
in YANG 1.0


Hello,

IMO "submodule"s  are a striking example of redundant complexity in an 
otherwise very close to perfection YANG (regardless if it is YANG 1.0 
or 1.1).


Modules and submodules have been around for a while however the ratio 
of the currently published modules compared with the submodules is 
about 40 modules to 1 submodule (if one ignores all the modules and 
submodules from  particular networking hardware manufacturer that is 
particularly keen on using submodules). As a far but still relevant 
analogy Java has a limitation of 1 file per class and this atomicity 
has proven to be an advantage especially in terms of enforcing 
modularity. IMO there is nothing that can be done with the help of 
submodules that can not be done without them.


For the sake of the argument can you provide a synthesized description 
of the problem that lead you to a drastic solution like "we’ll look at 
trying to put everything into submodules in this case."?


Vladimir

On 08/07/2017 04:37 PM, Ivory, William wrote:

Hi Jan,

Thanks – we’ll look at trying to put everything into submodules in
this case.

Regards,

William

*From:*Jan Lindblad [mailto:j...@tail-f.com]
*Sent:* 07 August 2017 14:28
*To:* Ivory, William 

*Cc:* netmod@ietf.org 
*Subject:* Re: [netmod] Query about augmenting module from
submodule in YANG 1.0

The submodule concept in YANG 1.0 is, well, not very useful, and
even less intuitive. That's why it saw major rework in YANG 1.1.

A YANG 1.0 submodule cannot reference the module that includes it,
directly or indirectly. This is because in YANG 1.0 the symbols in
other submodules of the same namespace are invisible to the
submodule unless they are explicitly included. And parent modules
can't be included by a submodule because that would lead to an
inclusion loop. It is possible to reference (augment, etc) other
sibling submodules, though. So if you split your modules cleverly,
you might be able to resolve your referential constraints anyway.

If you really want to take the submodule path, I'd recom

Re: [netmod] RFC 8199 on YANG Module Classification

2017-08-09 Thread Benoit Claise 

Dear all,

The good news is that the module-classification is already added as a 
metadata in the yangcatalog.org.


   leaf module-classification {
 type enumeration {
   enum network-service {
 description
   "Network Service YANG Module that describes the
   configuration, state
data, operations, and notifications of abstract
   representations of
services implemented on one or multiple network elements.";
   }
   enum network-element {
 description
   "Network Element YANG Module that describes the
   configuration, state
data, operations, and notifications of specific
   device-centric
technologies or features.";
   }
   enum unknown {
 description
   "In case that there is not sufficient information about
   how to classify the module.";
   }
   enum not-applicable {
 description
   "The YANG module abstraction type is neither a Network
   Service YANG Module
nor a Network Element YANG Module.";
   }
 }
 mandatory true;
 description
   "The high-level classification of the given YANG module.";
 reference
   "RFC8199 YANG Module Classification";
   }
   description
 "These leafs are shared among the yang-catalog and its API.";
 }


This metadata can't be extracted from the module, but must be populated.
That's the reason why you would see "unknown" for most modules right now.
Ex: 
https://yangcatalog.org:8443/search/modules/ietf-l3vpn-svc,2017-01-27,ietf


When populated, this will provide the ability to search for service 
versus network elements YANG modules.


Regards, Benoit

A new Request for Comments is now available in online RFC libraries.

 
 RFC 8199


 Title:  YANG Module Classification
 Author: D. Bogdanovic,
 B. Claise,
 C. Moberg
 Status: Informational
 Stream: IETF
 Date:   July 2017
 Mailbox:d...@voltanet.io,
 bcla...@cisco.com,
 camob...@cisco.com
 Pages:  11
 Characters: 23080
 Updates/Obsoletes/SeeAlso:   None

 I-D Tag:draft-ietf-netmod-yang-model-classification-08.txt

 URL:https://www.rfc-editor.org/info/rfc8199

 DOI:10.17487/RFC8199

The YANG data modeling language is currently being considered for a
wide variety of applications throughout the networking industry at
large.  Many standards development organizations (SDOs), open-source
software projects, vendors, and users are using YANG to develop and
publish YANG modules for a wide variety of applications.  At the same
time, there is currently no well-known terminology to categorize
various types of YANG modules.

A consistent terminology would help with the categorization of YANG
modules, assist in the analysis of the YANG data modeling efforts in
the IETF and other organizations, and bring clarity to the YANG-
related discussions between the different groups.

This document describes a set of concepts and associated terms to
support consistent classification of YANG modules.

This document is a product of the NETCONF Data Modeling Language Working Group 
of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
   https://www.ietf.org/mailman/listinfo/ietf-announce
   https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
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 Last Call for draft-ietf-netmod-syslog-model-15

2017-08-09 Thread t.petch 
Clyde

You use  as a placeholder for three different RFC and two of these
do not appear AFAICT in the list of References.

This might be a challenge for the RFC Editor.

Tom Petch


- Original Message -
From: "Clyde Wildes (cwildes)" 
Sent: Wednesday, July 19, 2017 6:48 PM


> Hi Alex,
>
> Answers inline as [clyde]…
>
> On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell"
 wrote:
>
> I am considering to implement the data model in this draft.
(dependent on business priorities of course)
> I have reviewed this draft and found the following issues.
>
> * I see pattern-match is specified to use POSIX 1003.2 regular
expressions. This is presumably for compatibility with existing
implementations; however it is inconsistent with most of YANG (which is
specified to use XPath regular expressions) - unless these are the same.
>
> [clyde] I believe that my answer in the other thread explains why we
used Posix 1003.2 – it is commonly used.
>
> * pattern-match is inside the facility-filter container; common
sense says this is wrong as pattern-match has nothing to do with
facilities.
>
> [clyde] I will move pattern-match up one level in the next version of
the draft. Thanks for catching this!
>
> * The advanced-compare container groups together two nodes that
share a common "when" and "if-feature" statement, but don't seem to have
any semantic relation to each other. Are there general guidelines on
when to use a container?
>
> [clyde] The confusion may come as a result of the when clause
appearing before the if-feature clause which is set by the IETF
statement order recommendation.
>
> The when construct was suggested by Martin Björklund as a way of
solving the case that advanced-compare does not apply for the ‘all’ and
‘none’ case.
>
> The if-feature applies to the entire container – it is either
supported or not.
>
> * The advanced-compare container has a description starting with
"This leaf ..." even though it is not a leaf.
>
> [clyde] This will be fixed in the next draft.
>
> * The examples are missing  nodes.
>
> [clyde] This will be fixed in the next draft.
>
> * Perhaps there should be more consistent terminology for
receivers of syslog messages; both "collectors" and "actions" are used
in the draft. RFC 5424 uses "collector" for the ultimate recipient of a
log message - which might not be applicable, because the sending system
has no idea whether the receiving system is a collector or a relay.
>
> [clyde] The definition of “collector” in RFC 5424 is: A "collector"
gathers syslog content for further analysis.
>
> actions relate to the “further analysis” taken by the “collector”.
>
> “Collectors” appears in the model under the remote action and I
believe the usage is correct:
>   container remote {
> if-feature remote-action;
> description
>   "This container describes the configuration parameters for
>forwarding syslog messages to remote relays or
collectors.";
>
> I will revise the description of these terms in the next draft.
>
> Thanks,
>
> Clyde
>
> 
> From: netmod  on behalf of Kent Watsen

> Sent: Saturday, 8 July 2017 6:34 a.m.

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