Re: [netmod] [Gen-art] Genart telechat review of draft-ietf-netmod-yang-model-classification-07

[Alissa Cooper]

Pete, thanks for your review. I entered a No Objection ballot.

Alissa

> On May 22, 2017, at 11:08 AM, Pete Resnick  wrote:
> 
> Reviewer: Pete Resnick
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-netmod-yang-model-classification-07
> Reviewer: Pete Resnick
> Review Date: 2017-05-22
> IETF LC End Date: 2017-05-14
> IESG Telechat date: 2017-06-08
> 
> Summary: Ready
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments: None
> 
> Thanks for addressing my comments in the Last Call review.
> 
> 
> ___
> Gen-art mailing list
> gen-...@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

[netmod] Deborah Brungard's Yes on draft-ietf-netmod-yang-model-classification-07: (with COMMENT)

[Deborah Brungard]

Deborah Brungard has entered the following ballot position for
draft-ietf-netmod-yang-model-classification-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/



--
COMMENT:
--

My 2cents on the "type" discussion:

The sentence in Section 1 Introduction does cause confusion "A number of module
types have created substantial discussion" as it's describing the possible name
duplication of a module in two different "layers", not types. Will read better
if remove "types".

I'm very surprised that Adrian on his reading did not question the use of
"layers" to distinguish between services and network element modules. To me,
with my layer hat on, this is very confusing.

My suggestion would be to use the generic word "types" for "layers" and use
"class" to distinguish modules which are standard, vendor, user. Vendor/user
modules may/may not overlap with standard modules functionality-wise, they also
may be modules with no interest to be standardized, so they are not necessarily
associated with maturity/finer aging:-)


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

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

[Clyde Wildes (cwildes)]

Hi,

The latest draft-ietf-netmod-syslog-model-15 contains updates to the 
signing-options container as a result of a review by Kent Watsen and Alex Clemm.

Diffs can be seen at:
https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-syslog-model-14&url2=draft-ietf-netmod-syslog-model-15

Thanks,

Clyde 

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

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

[internet-drafts]

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

Title   : A YANG Data Model for Syslog Configuration
Authors : Clyde Wildes
  Kiran Koushik
Filename: draft-ietf-netmod-syslog-model-15.txt
Pages   : 29
Date: 2017-06-07

Abstract:
   This document describes a data model for the configuration of syslog.


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

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


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] draft-ietf-netmod-syslog-model-14 Signing Options

[Clyde Wildes (cwildes)]

Kent,

Yes! Sorry for the delay.

Clyde

On 6/7/17, 11:13 AM, "Kent Watsen"  wrote:

Hi Clyde,

Since no concerns have been raised, should we be expecting an updated 
syslog draft shortly?

Kent // as shepherd

--

Hi,

As part of the last few steps before again calling for last call for 
draft-ietf-netmod-syslog-model-14, we are adding certificate support to the 
signing-options container. RFC 5848: Signed Syslog Messages is the RFC that 
governs this section.

The signing-options container resides within the remote action destination 
list section of the model. This means signing-options will be configurable for 
each remote destination.

RFC 5848 supports four signature groups as defined in section 4.2.3 
Signature Group and Signature Priority of the RFC:
https://tools.ietf.org/html/rfc5848#section-4.2.3

We are proposing to limit our support to Signature Group 0 which covers the 
case for administrators who want all messages of a syslog stream to be signed 
and Signature Blocks to be sent to a single destination.  We believe this case 
covers all deployment scenarios that are commonly encountered.  

Support for Signature Groups 1 (each PRI value is associated with its own 
Signature Group), 2 (each Signature Group contains a range of PRI values), and 
3 (Signature Groups are negotiated through a private arrangement) could be 
added to the model later through augmentation.

Please let us know if you have any concerns about this.

Thanks,

Clyde


___
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] draft-ietf-netmod-syslog-model-14 Signing Options

[Kent Watsen]

Hi Clyde,

Since no concerns have been raised, should we be expecting an updated syslog 
draft shortly?

Kent // as shepherd

--

Hi,

As part of the last few steps before again calling for last call for 
draft-ietf-netmod-syslog-model-14, we are adding certificate support to the 
signing-options container. RFC 5848: Signed Syslog Messages is the RFC that 
governs this section.

The signing-options container resides within the remote action destination list 
section of the model. This means signing-options will be configurable for each 
remote destination.

RFC 5848 supports four signature groups as defined in section 4.2.3 Signature 
Group and Signature Priority of the RFC:
https://tools.ietf.org/html/rfc5848#section-4.2.3

We are proposing to limit our support to Signature Group 0 which covers the 
case for administrators who want all messages of a syslog stream to be signed 
and Signature Blocks to be sent to a single destination.  We believe this case 
covers all deployment scenarios that are commonly encountered.  

Support for Signature Groups 1 (each PRI value is associated with its own 
Signature Group), 2 (each Signature Group contains a range of PRI values), and 
3 (Signature Groups are negotiated through a private arrangement) could be 
added to the model later through augmentation.

Please let us know if you have any concerns about this.

Thanks,

Clyde


___
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] Question about ietf-routing

[Acee Lindem (acee)]

+YANG Routing Design Team

On 6/7/17, 2:25 AM, "Ladislav Lhotka"  wrote:

>Hi Alex,
>
>in earlier revisions of the ietf-routing module (up to
>draft-ietf-netmod-routing-cfg-17), we had a configuration item
>("recipient-ribs") that allowed for assigning RIBs to routing protocol
>instances. The reason for removing it is summarized in my presentation
>from IETF 92, slides 10 and 11:
>
>https://www.ietf.org/proceedings/92/slides/slides-92-netmod-9.pdf
>
>(and yes, I wasn't a big fan of this change).
>
>Maybe Acee can give additional background.

The RIBs which the control plane protocols populated are normally dictated
by the address family. In the case of multiple topologies, a specific RIB
(as identified by name) will need to be explicitly associated with the
topology in the control plane protocol as opposed to being connected to
the control plane protocol at a higher level.

Thanks,
Acee 




>
>Lada 
>
>> On 7 Jun 2017, at 01:43, Alex Campbell 
>>wrote:
>> 
>> Hi,
>> 
>> I noticed that the ietf-routing YANG (published in RFC 8022) allows for
>>multiple instances of each control plane protocol, as well as multiple
>>RIBs per address family.
>> However I don't see any way to associate one with the other. Without
>>additional configuration, protocols will only place their routes in
>>default RIBs.
>> Is it intended that this will be left to vendor-specific modules and/or
>>future standards?
>> 
>> Alex
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: 0xB8F92B08A9F76C67
>
>
>
>
>

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

Re: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-yang-model-classification-07: (with COMMENT)

[Ben Campbell]

Thanks for the response. Also in-line:

> On Jun 7, 2017, at 8:50 AM, Benoit Claise  wrote:
> 
> Hi Ben,
> 
> Thanks for your review. See in-line.
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-netmod-yang-model-classification-07: No Objection
>> 
>> 
[...]
>> Substantive:
>> 
>> -4: That seems almost a challenge :-) But seriously, I dont know if it makes
>> sense to discuss this sort of thing in this document-- but it seems like
>> sensitivity of content might be a consideration when "typing" models. For
>> example, models that include security credentials or keys. (An answer of
>> "that's not what we are talking about" would be perfectly sensible.)
> Actually, the security considerations related to the YANG module should not 
> influence the YANG module classification.
> I wrote "should" because I can't think of a single case.

I'm fine with that, as long as people have thought about it--and this shows 
evidence that they have.

> To complete the Security Considerations section, here is a proposal.
> OLD: 
>This document doesn't have any Security Considerations.
> 
> NEW:
>The document specifying the YANG module to-be-classified already contains 
> a Security Considerations
>section. This document doesn't add to or modify this Security 
> Considerations section.  
I'm okay with either version at this point.

>> Editorial:
>> 
>> -1, " A number of module types have created substantial discussion during   
>> the
>> development of this document including those concerned with   topologies."
>> 
>> I'm not sure I understand that sentence. Is the antecedent of "those" "module
>> types", or "discussions"? Are we talking about network topologies?
> OLD:
>A number of module types have created substantial discussion during
>the development of this document including those concerned with
>topologies. 
> 
> NEW:
>A number of module types have created substantial discussion during
>the development of this document: for example, those concerned with
>topologies. 
Would it make sense to say "... for example, modules concerned with 
topologies."?
>> The section ends with "See figure 1". But that figure seems more related to
>> section 2. Is the reference out of place?
> The reference is right. Positioning the YANG modules from a location point of 
> view (equipment vendor, controller, orchestrator) helps people grasp the 
> concepts of Network Element YANG Modules versus Network Service YANG Modules

So this was just an editorial comment, so feel free to ignore, but the bullet 
point containing the reference is not obviously about the concepts of element 
vs service modules. It does talk about relationships between models. The idea 
of service vs element models has not yet been explained at that point, and the 
figure is not sufficient by itself to explain that idea. Maybe saying 
"relationships between types of models" would tie the ideas together more 
closely. Or maybe consider changing the reference to Figure 1 to a reference to 
Section 2 in it's entirety.

> 
> Regards, Benoit
>> 
>> 
>> .
>> 
> 

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

Re: [netmod] Alia Atlas' Yes on draft-ietf-netmod-yang-model-classification-07: (with COMMENT)

[Benoit Claise]

On 6/7/2017 5:16 AM, Eric Rescorla wrote:
Module pedigree seems good. Other alternatives might be "module 
ownership" or "module origin"

Seeing this now, I agree with "module origin" :-)

Regards, B.



On Tue, Jun 6, 2017 at 9:30 PM, Alia Atlas > wrote:


Alia Atlas has entered the following ballot position for
draft-ietf-netmod-yang-model-classification-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut
this
introductory paragraph, however.)


Please refer to
https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/





--
COMMENT:
--

If there is a desire to change from "module types", which I agree
is likely to
be overused,  an alternate term might be "module pedigree". Thank
you for an
excellent, clear, and useful document; I remember the confusion
that generated
this.





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

Re: [netmod] Adam Roach's No Objection on draft-ietf-netmod-yang-model-classification-07: (with COMMENT)

[Benoit Claise]

On 6/7/2017 12:13 AM, Adam Roach wrote:

Adam Roach has entered the following ballot position for
draft-ietf-netmod-yang-model-classification-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/



--
COMMENT:
--

I'm not going to pick out a bike shed color, but I do support the assertions
that "module type" is a bit too ambiguous. When I got to section 3, I had to go
back to see what section 2 called its things, because "type" is so generic.

What about
OLD: 3. Second Dimension: Module Types
NEW: 3. Second Dimension: Module Origin Types


There are some places where the unexpanded acronyms lost me (VRF, MEF, UNI) --

Ack.
Note: MEF is not an acronym any longer since they want to move away from 
the narrow scope of Metro Ethernet


Regards, B.

consider expanding these on first use.


.



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

Re: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-yang-model-classification-07: (with COMMENT)

[Benoit Claise]

Hi Ben,

Thanks for your review. See in-line.

Ben Campbell has entered the following ballot position for
draft-ietf-netmod-yang-model-classification-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/



--
COMMENT:
--

Substantive:

-4: That seems almost a challenge :-) But seriously, I dont know if it makes
sense to discuss this sort of thing in this document-- but it seems like
sensitivity of content might be a consideration when "typing" models. For
example, models that include security credentials or keys. (An answer of
"that's not what we are talking about" would be perfectly sensible.)
Actually, the security considerations related to the YANG module should 
not influence the YANG module classification.

I wrote "should" because I can't think of a single case.
To complete the Security Considerations section, here is a proposal.
OLD:

   This document doesn't have any Security Considerations.

NEW:
   The document specifying the YANG module to-be-classified already contains a 
Security Considerations
   section. This document doesn't add to or modify this Security Considerations 
section.



Editorial:

-1, " A number of module types have created substantial discussion during   the
development of this document including those concerned with   topologies."

I'm not sure I understand that sentence. Is the antecedent of "those" "module
types", or "discussions"? Are we talking about network topologies?

OLD:

   A number of module types have created substantial discussion during
   the development of this document including those concerned with
   topologies.

NEW:
   A number of module types have created substantial discussion during
   the development of this document: for example, those concerned with
   topologies.



The section ends with "See figure 1". But that figure seems more related to
section 2. Is the reference out of place?
The reference is right. Positioning the YANG modules from a location 
point of view (equipment vendor, controller, orchestrator) helps people 
grasp the concepts of Network Element YANG Modules versus Network 
Service YANG Modules


Regards, Benoit



.



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