date:20180216

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

2018-02-16 Thread Ladislav Lhotka

Robert Wilton  writes:

> I should add, as a contributor, I have read this document and think that 
> is ready for advancement.
>
> I have three minor comments:
>
> 1) module "feature" in YANG library is a leaf-list, but currently it is 
> a list in YANG libary bis. I suspect that this is due to one of the 
> incarnations when it contained additional information.  I think that we 
> should revert it back to being a leaf list for consistency.
>
> 2) Lada recommended that module "deviation" be made a leaf-list. I also 
> support changing this for consistency with "feature" above, but don't 
> feel too strongly on this one.

I agree to have both as leaf-lists.

>
> 3) I think the "modules" list is also allowed to included modules that 
> don't actually contain any nodes that require implementation.  Hence, it 
> might be useful of the "modules" description statement explicitly stated 
> this.  I.e. perhaps something like:
>
> "This list may contain modules that do not contain any schema nodes that 
> require implementation.  For example, it could contain a module that 
> only defines types and not any data nodes, RPCs, actions, notifications, 
> or deviations."

Hmm, such modules belong to the other list "import-only-modules", don't
they?

Lada

>
> Thanks,
> Rob
>
>
> On 02/02/2018 13:51, Kent Watsen wrote:
>>
>> As co-author, I am not aware of any IPR related to this document.
>>
>> As a contributor, I have read this document and think that it is ready 
>> for advancement.
>>
>> Kent
>>
>> On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton" 
>> mailto:netconf-boun...@ietf.org> on behalf 
>> of rwil...@cisco.com > wrote:
>>
>> I am not aware of any IPR related to this document.
>>
>> Thanks,
>> Rob
>>
>> On 01/02/2018 18:59, Mahesh Jethanandani wrote:
>>
>> 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 draft
>> 
>> .
>> The LC will end on February 15.
>>
>> Please send your comments on this thread. Reviews of the document,
>> and statement of support are particularly helpful to the authors.
>> If you have concerns about the document, please state those too.
>>
>> Authors please indicate if you are aware of any IPR on the document.
>>
>> Thanks.
>>
>> [1]
>> https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
>> 
>> 
>>
>> Mahesh & Kent
>>
>>
>>
>>
>> ___
>>
>> Netconf mailing list
>>
>> netc...@ietf.org 
>>
>> https://www.ietf.org/mailman/listinfo/netconf
>> 
>> 
>>
>>
>>
>
> ___
> Netconf mailing list
> netc...@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

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

2018-02-16 Thread Ladislav Lhotka

Andy Bierman  writes:

> On Thu, Feb 15, 2018 at 10:09 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
>> On Thu, Feb 15, 2018 at 05:03:32PM +, Robert Wilton wrote:
>> >
>> > 1) module "feature" in YANG library is a leaf-list, but currently it is a
>> > list in YANG libary bis. I suspect that this is due to one of the
>> > incarnations when it contained additional information.  I think that we
>> > should revert it back to being a leaf list for consistency.
>> >
>> > 2) Lada recommended that module "deviation" be made a leaf-list. I also
>> > support changing this for consistency with "feature" above, but don't
>> feel
>> > too strongly on this one.
>> >
>>
>> I suggest we either make both leaf-lists or keep both as lists. I am
>> fine with making both lead-lists.
>>
>>
>
> The reason the deviation is a list is because it has a name and revision.
> Or it did until it was removed.
>
> I prefer to keep the contents of the "module" list the
> same as RFC 7895.  The "improvement" is much worse --
> harder to use by clients and provides less information to clients.

So we currently have:

1. "deviation": [
 {
   "module": "foo-devs"
 },
 {
   "module": "bar-devs"
 }
   ]

and the proposal is to have instead

2. "deviation-module": [
 "foo-devs",
 "bar-dev"
   ]

I fail to see why #2 is harder to use for clients, I would say it is the
opposite. Also, #2 doesn't provide less information than RFC 7895 - the
revision parameter is readily available in the "module" list.

I also expect that this data will be used not only in machine-to-machine
communication but could also be perused by humans - see
e.g. draft-lengyel-netmod-yang-instance-data. For this purpose, #2 is a
clear winer.

Lada

>
>
>
>> /js
>>
>
>
> Andy
>
>
>>
>> --
>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103 
>>
>> ___
>> Netconf mailing list
>> netc...@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

[netmod] YANG modules publication: what to focus on next? Feb 16th

2018-02-16 Thread Benoit Claise


Dear all,

At the last IETF meeting, Alia, Deborah and I looked at the publication 
status of most YANG modules.
Since that time, I've been keeping a summary of the situation. Let me 
share it with everybody.


Before publishing YANG modules, we have two series of bottlenecks:
- the YANG module import (shown by tooling below)
- the normative references (MISSREF in the RFC editor queue 
)


We now have many YANG modules in RFC editor queue:**
**draft-ietf-netconf-rfc6536bis-09 (AUTH48) 
**
draft-ietf-netmod-revised-datastores-10 (AUTH48) 

*draft-ietf-netmod-yang-tree-diagrams-05 (expedited processing) 

**draft-ietf-lime-yang-connectionless-oam-18 
**
draft-ietf-lime-yang-connectionless-oam-methods-13 
**
draft-ietf-i2rs-yang-l3-topology-16 
**
draft-ietf-i2rs-yang-network-topo-20 
**
draft-wu-l3sm-rfc8049bis-11 

*draft-ietf-netmod-rfc7223bis-03 

draft-ietf-netmod-rfc7277bis-03 

draft-ietf-rtgwg-yang-vrrp-09 

draft-ietf-rtgwg-yang-rip-08 

draft-ietf-netmod-rfc8022bis-10 

draft-ietf-netmod-entity-08 

draft-ietf-rtgwg-ni-model-06 

draft-ietf-rtgwg-lne-model-05 
 
(actually, almost in the RFC editor queue)



Here are the YANG module dependencies 
 
for these RFC editor modules, as requirement before publishing.


Some more YANG modules are on the IESG table:
    draft-ietf-pim-yang has a DISCUSS (Jan 11th IESG telechat)

Assuming this one is in the RFC editor queue, this is the new set of 
YANG module dependencies 
.
It takes a little bit of re-arrangering the elements, but all the 
information regarding YANG module dependency is there.


The next bottlenecks for publishing those YANG modules are:
    draft-ietf-netmod-schema-mount
    ietf-bfd-yang (currently in WG LC)
    draft-ietf-ospf-yang
    draft-ietf-isis-yang-isis-cfg
Please progress those documents asap

Some more updates below.

_NETMOD:_
draft-ietf-netmod-syslog-model-17 
 (in 
IETF LC)
draft-ietf-netmod-acl-model-15

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

2018-02-16 Thread Robert Wilton


Hi Lada,


On 16/02/2018 09:06, Ladislav Lhotka wrote:

Robert Wilton  writes:


I should add, as a contributor, I have read this document and think that
is ready for advancement.

I have three minor comments:

1) module "feature" in YANG library is a leaf-list, but currently it is
a list in YANG libary bis. I suspect that this is due to one of the
incarnations when it contained additional information.  I think that we
should revert it back to being a leaf list for consistency.

2) Lada recommended that module "deviation" be made a leaf-list. I also
support changing this for consistency with "feature" above, but don't
feel too strongly on this one.

I agree to have both as leaf-lists.


3) I think the "modules" list is also allowed to included modules that
don't actually contain any nodes that require implementation.  Hence, it
might be useful of the "modules" description statement explicitly stated
this.  I.e. perhaps something like:

"This list may contain modules that do not contain any schema nodes that
require implementation.  For example, it could contain a module that
only defines types and not any data nodes, RPCs, actions, notifications,
or deviations."

Hmm, such modules belong to the other list "import-only-modules", don't
they?

So my reasoning is that either is valid.

I.e. a module being listed under "modules" means that it implements all 
data nodes, RPCs, actions, notifications, deviations, etc.  If a module 
doesn't contain any data nodes, RPCs, actions, notifications, 
deviations, etc then it is trivially implemented :-)


As an aside, RFC 7950 states in 5.6.5:

 A server implements a module if it implements the module's data
   nodes, RPCs, actions, notifications, and deviations.


I wonder whether identities shouldn't also be on this list, since 
section 9.10.2 states:


On a particular server, the valid values are further restricted
to the set of identities defined in the modules implemented by the server.


Thanks,
Rob




Lada


Thanks,
Rob


On 02/02/2018 13:51, Kent Watsen wrote:

As co-author, I am not aware of any IPR related to this document.

As a contributor, I have read this document and think that it is ready
for advancement.

Kent

On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton"
mailto:netconf-boun...@ietf.org> on behalf
of rwil...@cisco.com > wrote:

I am not aware of any IPR related to this document.

Thanks,
Rob

On 01/02/2018 18:59, Mahesh Jethanandani wrote:

 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 draft
 
.
 The LC will end on February 15.

 Please send your comments on this thread. Reviews of the document,
 and statement of support are particularly helpful to the authors.
 If you have concerns about the document, please state those too.

 Authors please indicate if you are aware of any IPR on the document.

 Thanks.

 [1]
 https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
 


 Mahesh & Kent




 ___

 Netconf mailing list

 netc...@ietf.org 

 https://www.ietf.org/mailman/listinfo/netconf
 





___
Netconf mailing list
netc...@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


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

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

2018-02-16 Thread Ladislav Lhotka

Robert Wilton  writes:

> Hi Lada,
>
>
> On 16/02/2018 09:06, Ladislav Lhotka wrote:
>> Robert Wilton  writes:
>>
>>> I should add, as a contributor, I have read this document and think that
>>> is ready for advancement.
>>>
>>> I have three minor comments:
>>>
>>> 1) module "feature" in YANG library is a leaf-list, but currently it is
>>> a list in YANG libary bis. I suspect that this is due to one of the
>>> incarnations when it contained additional information.  I think that we
>>> should revert it back to being a leaf list for consistency.
>>>
>>> 2) Lada recommended that module "deviation" be made a leaf-list. I also
>>> support changing this for consistency with "feature" above, but don't
>>> feel too strongly on this one.
>> I agree to have both as leaf-lists.
>>
>>> 3) I think the "modules" list is also allowed to included modules that
>>> don't actually contain any nodes that require implementation.  Hence, it
>>> might be useful of the "modules" description statement explicitly stated
>>> this.  I.e. perhaps something like:
>>>
>>> "This list may contain modules that do not contain any schema nodes that
>>> require implementation.  For example, it could contain a module that
>>> only defines types and not any data nodes, RPCs, actions, notifications,
>>> or deviations."
>> Hmm, such modules belong to the other list "import-only-modules", don't
>> they?
> So my reasoning is that either is valid.
>
> I.e. a module being listed under "modules" means that it implements all 
> data nodes, RPCs, actions, notifications, deviations, etc.  If a module 
> doesn't contain any data nodes, RPCs, actions, notifications, 
> deviations, etc then it is trivially implemented :-)

OK, so if a module contains only groupings and typedefs, it can appear
either in "modules" or in "import-only-modules", and the effect is the
same, right?

This sounds reasonable.

>
> As an aside, RFC 7950 states in 5.6.5:
>
>   A server implements a module if it implements the module's data
> nodes, RPCs, actions, notifications, and deviations.
>
>
> I wonder whether identities shouldn't also be on this list, since 
> section 9.10.2 states:

Yes, and extensions as well.

Lada

>
> On a particular server, the valid values are further restricted
> to the set of identities defined in the modules implemented by the server.
>
>
> Thanks,
> Rob
>
>
>>
>> Lada
>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> On 02/02/2018 13:51, Kent Watsen wrote:
 As co-author, I am not aware of any IPR related to this document.

 As a contributor, I have read this document and think that it is ready
 for advancement.

 Kent

 On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton"
 mailto:netconf-boun...@ietf.org> on behalf
 of rwil...@cisco.com > wrote:

 I am not aware of any IPR related to this document.

 Thanks,
 Rob

 On 01/02/2018 18:59, Mahesh Jethanandani wrote:

  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 draft
  
 .
  The LC will end on February 15.

  Please send your comments on this thread. Reviews of the document,
  and statement of support are particularly helpful to the authors.
  If you have concerns about the document, please state those too.

  Authors please indicate if you are aware of any IPR on the document.

  Thanks.

  [1]
  https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
  
 

  Mahesh & Kent




  ___

  Netconf mailing list

  netc...@ietf.org 

  https://www.ietf.org/mailman/listinfo/netconf
  
 



>>> ___
>>> Netconf mailing list
>>> netc...@ietf.org
>>> https://www.ietf.org/mailman/lis

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

2018-02-16 Thread Robert Wilton




On 16/02/2018 15:33, Ladislav Lhotka wrote:

Robert Wilton  writes:


Hi Lada,


On 16/02/2018 09:06, Ladislav Lhotka wrote:

Robert Wilton  writes:


I should add, as a contributor, I have read this document and think that
is ready for advancement.

I have three minor comments:

1) module "feature" in YANG library is a leaf-list, but currently it is
a list in YANG libary bis. I suspect that this is due to one of the
incarnations when it contained additional information.  I think that we
should revert it back to being a leaf list for consistency.

2) Lada recommended that module "deviation" be made a leaf-list. I also
support changing this for consistency with "feature" above, but don't
feel too strongly on this one.

I agree to have both as leaf-lists.


3) I think the "modules" list is also allowed to included modules that
don't actually contain any nodes that require implementation.  Hence, it
might be useful of the "modules" description statement explicitly stated
this.  I.e. perhaps something like:

"This list may contain modules that do not contain any schema nodes that
require implementation.  For example, it could contain a module that
only defines types and not any data nodes, RPCs, actions, notifications,
or deviations."

Hmm, such modules belong to the other list "import-only-modules", don't
they?

So my reasoning is that either is valid.

I.e. a module being listed under "modules" means that it implements all
data nodes, RPCs, actions, notifications, deviations, etc.  If a module
doesn't contain any data nodes, RPCs, actions, notifications,
deviations, etc then it is trivially implemented :-)

OK, so if a module contains only groupings and typedefs, it can appear
either in "modules" or in "import-only-modules", and the effect is the
same, right?

Yes.



This sounds reasonable.


As an aside, RFC 7950 states in 5.6.5:

   A server implements a module if it implements the module's data
 nodes, RPCs, actions, notifications, and deviations.


I wonder whether identities shouldn't also be on this list, since
section 9.10.2 states:

Yes, and extensions as well.

Lada

Thanks,
Rob




On a particular server, the valid values are further restricted
to the set of identities defined in the modules implemented by the server.


Thanks,
Rob



Lada


Thanks,
Rob


On 02/02/2018 13:51, Kent Watsen wrote:

As co-author, I am not aware of any IPR related to this document.

As a contributor, I have read this document and think that it is ready
for advancement.

Kent

On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton"
mailto:netconf-boun...@ietf.org> on behalf
of rwil...@cisco.com > wrote:

I am not aware of any IPR related to this document.

Thanks,
Rob

On 01/02/2018 18:59, Mahesh Jethanandani wrote:

  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 draft
  
.
  The LC will end on February 15.

  Please send your comments on this thread. Reviews of the document,
  and statement of support are particularly helpful to the authors.
  If you have concerns about the document, please state those too.

  Authors please indicate if you are aware of any IPR on the document.

  Thanks.

  [1]
  https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
  


  Mahesh & Kent




  ___

  Netconf mailing list

  netc...@ietf.org 

  https://www.ietf.org/mailman/listinfo/netconf
  





___
Netconf mailing list
netc...@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

___
Netconf mailing list
netc...@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


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

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

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

[netmod] YANG modules publication: what to focus on next? Feb 16th

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

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

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

6 matches

Site Navigation

Mail list logo

Footer information