Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

[Iftekhar Hussain]

Hi Rob,

Regarding " Were you looking for any additional specific statistics?". 
As long as RFC7223 interface statistics - relevant to a  given subinterface are 
picked and are available on per subinterface level  that should be fine.

"However, it would probably be useful to have a counter on the parent trunk to 
indicate the number of packets that haven't been matched to any sub-interface, 
so I think that I should add that."

Yes - I think, this would be useful.

Thanks,
Iftekhar

-Original Message-
From: Robert Wilton [mailto:rwil...@cisco.com] 
Sent: Friday, December 16, 2016 4:14 AM
To: Iftekhar Hussain; Lou Berger; NetMod WG
Cc: NetMod WG Chairs; draft-wilton-netmod-intf-vlan-y...@ietf.org
Subject: Re: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

Hi Iftekhar,

Thanks for the comments and support, please see inline ...


On 15/12/2016 18:55, Iftekhar Hussain wrote:
> Yes/support.
>
> I have read this draft and believe it would be very useful for enabling many 
> Layer 2 and Layer 3 services.
>
> However, I do have few comments and that I would like the authors to address 
> once the document is a WG document.
>
> a)  Suggest to replace this text:
>  "These modules allow IETF forwarding protocols (such as IPv6 and VPLS) 
> ..."
>   with the following text:
>  " These modules allow configuration Layer 2 and Layer 3 subinterfaces 
> (e.g., attachment circuits) for providing for IETF L2VPN (e.g., VPWS, VPLS, 
> EVPN) and L3VPN services".
Yes, OK.  I think that this text can be tweaked.

>
> b) The document should clearly identify the scope. For example, suggest 
> replace this text:
>  "... to interoperate with VLAN tagged traffic orginated from an IEEE 
> 802.1Q compliant bridge".
> with the following text:
> "... to interoperate with traffic originated from an IEEE 802.1D, 
> 802.1Q, or 802.1AD compliant bridge."
>
> Note: In the data model, the draft is talking about untagged as 
> well as 802.1AD (see  "tag type (802.1Q or 802.1ad)")
Yes, it should mention 802.1D.  802.1ad is part of 802.1Q.  The draft would be 
best referring to S-VLANs vs C-VLANs rather than 802.1Q vs 802.1ad.

>  
>   c)  Are there any sub-interface level common statistics counters that the 
> model should address?  Currently, I don't see any.
A sub-interface is still just an interface, so by default it would pick up all 
of RFC7223 interface statistics.  Were you looking for any additional specific 
statistics?

However, it would probably be useful to have a counter on the parent trunk to 
indicate the number of packets that haven't been matched to any sub-interface, 
so I think that I should add that.

Thanks,
Rob

>
> Thanks,
> Iftekhar
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
> Sent: Monday, December 12, 2016 3:32 PM
> To: NetMod WG
> Cc: NetMod WG Chairs
> Subject: [netmod] WG adoption poll 
> draft-wilton-netmod-intf-vlan-yang-04
>
> All,
>
> This is start of a two week* poll on making
> draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group document.
>
> Please send email to the list indicating "yes/support" or "no/do not 
> support".  If indicating no, please state your reservations with the 
> document.  If yes, please also feel free to provide comments you'd like to 
> see addressed once the document is a WG document.
>
> * Given the holiday, the poll ends December 28.
>
> Thank you,
> NetMod WG Chairs
>
> ___
> 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-entity issue #11

[Randy Presuhn]

Hi -

On 12/16/2016 12:53 AM, Martin Bjorklund wrote:

Randy Presuhn  wrote:

Hi -

My recollection is that part of the motivation for the use of
zero-length strings as sentinel values in situations like this
in MIB modules (rather than skipping the object instance) was
to permit a clear distinction between "information not available"
and "access denied".


Ok.  But if this is an important use case, maybe we should try to have
generic support for it, instead of using special values.  Not all
types have a natural value for "not available".


Just providing background.  I don't know whether the distinction is
needed in netconf-managed environments.


I think that people often used these kinds of constructs in MIBs
to avoid "holes" in the tables; I don't know if that applied to this
MIB though.


I think the fear of holes belongs in the "folklore" category.

Due to the way access control works in SNMP, holes in tables
are always a possibility when retrieving information.  Employing
sentinel values can't change that reality.  However, for some
objects (by no means all) the distinction between "I don't know"
and "I won't tell you" was important to SNMP-based management.
Whether this is also true in netconf-land is a another question.

Randy

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

Re: [netmod] WG Last Call: draft-ietf-netmod-yang-model-classification-04

[Lou Berger]

[resend]
All,

This WG LC is closed.

Authors,

Please update your document per any (on & off list) comments received as
well as ensure it passes ID nits, preferably without any warnings.  If
there are issues to be discussed based on comment, please do so on the
list. Once the document is updated to address all comments, please let
us (all) know by sending a  message to the list summarizing resolution
of issues raised and changes.  Publication will be requested at that point.

Thank you!
Lou


On 11/30/2016 12:35 PM, Lou Berger wrote:
> All,
> This starts a two-week working group last call on
> draft-ietf-netmod-yang-model-classification-04.
> 
> The working group last call ends on December 14. Please send your
> comments to the netmod mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and
> believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Thank you,
> Netmod Chairs
> 
> ___
> 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] RFC 7277: ip-address-origin

[William Lupton]

FYI the TR-181 “Device:2” data model (a TR-069 data model) defines a 
conceptually similar IPv6 address origin parameter (*):

—— 
Mechanism via which the IP address was assigned. Enumeration of:
AutoConfigured (Automatically generated. For example, a link-local address as 
specified by SLAAC [Section 5.3/RFC4862], a global address as specified by 
SLAAC [Section 5.5/RFC4862], or generated via CPE logic (e.g. from delegated 
prefix as specified by [RFC3633]), or from ULA /48 prefix as specified by 
[RFC4193])
DHCPv6 (Assigned by DHCPv6 [RFC3315])
IKEv2 (Assigned by IKEv2 [RFC5996])
MAP (Assigned by MAP [RFC7597], i.e. is this interface's MAP IPv6 address)
WellKnown (Specified by a standards organization, e.g. the ::1 loopback 
address, which is defined in [RFC4291])
Static (For example, present in the factory default configuration (but not 
WellKnown), created by the ACS, or created by some other management entity 
(e.g. via a GUI))
This parameter is based on ipOrigin from [RFC4293].
——

Rather than defining a “slaac” value we defined AutoConfigured to include SLAAC 
and other auto-configuration mechanisms. We also listed some other protocols 
via which the address might be assigned. We perhaps should have defined an 
“Other” value but the thinking might have been that it was better to extend the 
enumeration with other specific protocols rather than use “Other”.

This is intended for IPv6 only. We also defined an IPv4 addressing type 
parameter (**) with enumerations {DHCP, IKEv2, AutoIP, IPCP, Static}.

William

(*) 
https://www.broadband-forum.org/cwmp/tr-181-2-11-0.html#D.Device:2.Device.IP.Interface.%7Bi%7D.IPv6Address.%7Bi%7D.Origin
(**) 
https://www.broadband-forum.org/cwmp/tr-181-2-11-0.html#D.Device:2.Device.IP.Interface.%7Bi%7D.IPv4Address.%7Bi%7D.AddressingType

> On 16 Dec 2016, at 14:13, Ladislav Lhotka  wrote:
> 
> 
>> On 16 Dec 2016, at 15:05, Martin Bjorklund  wrote:
>> 
>> Ladislav Lhotka  wrote:
>>> 
 On 16 Dec 2016, at 14:39, Juergen Schoenwaelder 
  wrote:
 
 Lada,
 
 when would I use link-layer and when link-local? Perhaps all needed is
 a clarification of the description of link-layer? (Perhaps link-local
>>> 
>>> The distinction between SLAAC and link-local address is IMO also important.
>>> 
 would have been a better name but too late now...)
>>> 
>>> That's why I believe the draconian update rules in sec. 11 of RFC
>>> 7950 are seriously counterproductive (at this stage at least). We
>>> should simply fix such mistakes and omissions in a new revision of
>>> ietf-ip, because otherwise the modules will soon be full of
>>> rubbish.
>> 
>> I agree w/ Acee that the name 'link-layer' is more appropriate for the
>> *origin* of the address.
> 
> That's possible for link-local but not for SLAAC, which is an L3 mechanism.
> 
> So a fix might be:
> 
> 1. Change description of "link-layer" to include link-local addresses.
> 
> 2. Add a new enum, e.g. "slaac".
> 
> Lada
> 
>> 
>> If you manually configure a link-local address the origin would be
>> 'static'.
>> 
>> 
>> /martin
>> 
>> 
 An RFC 3927 address could also be a 'random' address. In fact, the
 169.254/16 prefix kind of hings at RFC 3927 addresses falling under
 'random'.
>>> 
>>> OK, so adding 3927 to "reference" should suffice in this case.
>>> 
>>> Lada
>>> 
 
 /js
 
 On Fri, Dec 16, 2016 at 02:33:04PM +0100, Ladislav Lhotka wrote:
> Hi,
> 
> I think that one important enum is missing in the "ip-address-origin" 
> typedef:
> 
> enum link-local {
>  description
>"Indicates a link-local address.";
>  reference
>"RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses
> RFC 4291: IP Version 6 Addressing Architecture";
> 
> Would an erratum be possible/useful?
> 
> Lada
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
 
 -- 
 Juergen Schoenwaelder   Jacobs University Bremen gGmbH
 Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
 Fax:   +49 421 200 3103 
>>> 
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> 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] RFC 7277: ip-address-origin

[Ladislav Lhotka]

> On 16 Dec 2016, at 15:05, Martin Bjorklund  wrote:
> 
> Ladislav Lhotka  wrote:
>> 
>>> On 16 Dec 2016, at 14:39, Juergen Schoenwaelder 
>>>  wrote:
>>> 
>>> Lada,
>>> 
>>> when would I use link-layer and when link-local? Perhaps all needed is
>>> a clarification of the description of link-layer? (Perhaps link-local
>> 
>> The distinction between SLAAC and link-local address is IMO also important.
>> 
>>> would have been a better name but too late now...)
>> 
>> That's why I believe the draconian update rules in sec. 11 of RFC
>> 7950 are seriously counterproductive (at this stage at least). We
>> should simply fix such mistakes and omissions in a new revision of
>> ietf-ip, because otherwise the modules will soon be full of
>> rubbish.
> 
> I agree w/ Acee that the name 'link-layer' is more appropriate for the
> *origin* of the address.

That's possible for link-local but not for SLAAC, which is an L3 mechanism.

So a fix might be:

1. Change description of "link-layer" to include link-local addresses.

2. Add a new enum, e.g. "slaac".

Lada

> 
> If you manually configure a link-local address the origin would be
> 'static'.
> 
> 
> /martin
> 
> 
>>> An RFC 3927 address could also be a 'random' address. In fact, the
>>> 169.254/16 prefix kind of hings at RFC 3927 addresses falling under
>>> 'random'.
>> 
>> OK, so adding 3927 to "reference" should suffice in this case.
>> 
>> Lada
>> 
>>> 
>>> /js
>>> 
>>> On Fri, Dec 16, 2016 at 02:33:04PM +0100, Ladislav Lhotka wrote:
 Hi,
 
 I think that one important enum is missing in the "ip-address-origin" 
 typedef:
 
 enum link-local {
   description
 "Indicates a link-local address.";
   reference
 "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses
  RFC 4291: IP Version 6 Addressing Architecture";
 
 Would an erratum be possible/useful?
 
 Lada
 
 --
 Ladislav Lhotka, CZ.NIC Labs
 PGP Key ID: E74E8C0C
 
 
 
 
 ___
 netmod mailing list
 netmod@ietf.org
 https://www.ietf.org/mailman/listinfo/netmod
>>> 
>>> -- 
>>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200 3103 
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] RFC 7277: ip-address-origin

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> 
> > On 16 Dec 2016, at 14:39, Juergen Schoenwaelder 
> >  wrote:
> > 
> > Lada,
> > 
> > when would I use link-layer and when link-local? Perhaps all needed is
> > a clarification of the description of link-layer? (Perhaps link-local
> 
> The distinction between SLAAC and link-local address is IMO also important.
> 
> > would have been a better name but too late now...)
> 
> That's why I believe the draconian update rules in sec. 11 of RFC
> 7950 are seriously counterproductive (at this stage at least). We
> should simply fix such mistakes and omissions in a new revision of
> ietf-ip, because otherwise the modules will soon be full of
> rubbish.

I agree w/ Acee that the name 'link-layer' is more appropriate for the
*origin* of the address.

If you manually configure a link-local address the origin would be
'static'.


/martin


> > An RFC 3927 address could also be a 'random' address. In fact, the
> > 169.254/16 prefix kind of hings at RFC 3927 addresses falling under
> > 'random'.
> 
> OK, so adding 3927 to "reference" should suffice in this case.
> 
> Lada
> 
> > 
> > /js
> > 
> > On Fri, Dec 16, 2016 at 02:33:04PM +0100, Ladislav Lhotka wrote:
> >> Hi,
> >> 
> >> I think that one important enum is missing in the "ip-address-origin" 
> >> typedef:
> >> 
> >>  enum link-local {
> >>description
> >>  "Indicates a link-local address.";
> >>reference
> >>  "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses
> >>   RFC 4291: IP Version 6 Addressing Architecture";
> >> 
> >> Would an erratum be possible/useful?
> >> 
> >> Lada
> >> 
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >> 
> >> 
> >> 
> >> 
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> > 
> > -- 
> > Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103 
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> 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] RFC 7277: ip-address-origin

[Ladislav Lhotka]

> On 16 Dec 2016, at 14:39, Juergen Schoenwaelder 
>  wrote:
> 
> Lada,
> 
> when would I use link-layer and when link-local? Perhaps all needed is
> a clarification of the description of link-layer? (Perhaps link-local

The distinction between SLAAC and link-local address is IMO also important.

> would have been a better name but too late now...)

That's why I believe the draconian update rules in sec. 11 of RFC 7950 are 
seriously counterproductive (at this stage at least). We should simply fix such 
mistakes and omissions in a new revision of ietf-ip, because otherwise the 
modules will soon be full of rubbish.

> 
> An RFC 3927 address could also be a 'random' address. In fact, the
> 169.254/16 prefix kind of hings at RFC 3927 addresses falling under
> 'random'.

OK, so adding 3927 to "reference" should suffice in this case.

Lada

> 
> /js
> 
> On Fri, Dec 16, 2016 at 02:33:04PM +0100, Ladislav Lhotka wrote:
>> Hi,
>> 
>> I think that one important enum is missing in the "ip-address-origin" 
>> typedef:
>> 
>>  enum link-local {
>>description
>>  "Indicates a link-local address.";
>>reference
>>  "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses
>>   RFC 4291: IP Version 6 Addressing Architecture";
>> 
>> Would an erratum be possible/useful?
>> 
>> Lada
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] RFC 7277: ip-address-origin

[Acee Lindem (acee)]

On 12/16/16, 8:39 AM, "netmod on behalf of Juergen Schoenwaelder"
 wrote:

>Lada,
>
>when would I use link-layer and when link-local? Perhaps all needed is
>a clarification of the description of link-layer? (Perhaps link-local
>would have been a better name but too late now...)
>
>An RFC 3927 address could also be a 'random' address. In fact, the
>169.254/16 prefix kind of hings at RFC 3927 addresses falling under
>'random'.

Actually, I think Œrandom¹ is a more semantically correct classification
for RFC 3927 addresses than the proposed Œlink-local¹.

Acee


>
>/js
>
>On Fri, Dec 16, 2016 at 02:33:04PM +0100, Ladislav Lhotka wrote:
>> Hi,
>> 
>> I think that one important enum is missing in the "ip-address-origin"
>>typedef:
>> 
>>   enum link-local {
>> description
>>   "Indicates a link-local address.";
>> reference
>>   "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses
>>RFC 4291: IP Version 6 Addressing Architecture";
>> 
>> Would an erratum be possible/useful?
>> 
>> Lada
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
>> 
>> 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>-- 
>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

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

Re: [netmod] RFC 7277: ip-address-origin

[Acee Lindem (acee)]

Semantically, link-local seems more like a type of address than the origin
of the address. Also, the enum already has the type ³link-layer².

Thanks,
Acee 

On 12/16/16, 8:33 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>Hi,
>
>I think that one important enum is missing in the "ip-address-origin"
>typedef:
>
>  enum link-local {
>description
>  "Indicates a link-local address.";
>reference
>  "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses
>   RFC 4291: IP Version 6 Addressing Architecture";
>
>Would an erratum be possible/useful?
>
>Lada
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>___
>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] top-level mandatory nodes

[Juergen Schoenwaelder]

On Fri, Dec 16, 2016 at 02:36:50PM +0100, Ladislav Lhotka wrote:
> 
> > On 16 Dec 2016, at 14:24, Juergen Schoenwaelder 
> >  wrote:
> > 
> > On Fri, Dec 16, 2016 at 12:48:56PM +0100, Ladislav Lhotka wrote:
> >> Hi,
> >> 
> >> 6087bis says in sec. 5.10:
> >> 
> >>  Top-level database data definitions MUST NOT be mandatory.
> >> 
> >> It think this makes sense only for config=true nodes. It is absolutely OK 
> >> to have mandatory top-level state data, and some published modules already 
> >> have them, e.g. ietf-yang-library.
> >> 
> >> Also, I wonder - should the text use "datastore" rather than "database"?
> >> 
> > 
> > We should not use the term 'database'. I do no think 'datastore' is
> > the appropriate replacement. Since this document talks about YANG, I
> > think the proper terms are data tree and schema tree (or any other
> > terms that the YANG specification defines).
> 
> Right - I think the following should do:
> 
> OLD
> 
>   Top-level database data definitions MUST NOT be mandatory.
> 
> NEW
> 
>   Top-level data nodes that represent configuration MUST NOT be mandatory.
>

There are a few more occurances of the word 'database' that should all
be rewritten to use YANG terminology.

/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] RFC 7277: ip-address-origin

[Juergen Schoenwaelder]

Lada,

when would I use link-layer and when link-local? Perhaps all needed is
a clarification of the description of link-layer? (Perhaps link-local
would have been a better name but too late now...)

An RFC 3927 address could also be a 'random' address. In fact, the
169.254/16 prefix kind of hings at RFC 3927 addresses falling under
'random'.

/js

On Fri, Dec 16, 2016 at 02:33:04PM +0100, Ladislav Lhotka wrote:
> Hi,
> 
> I think that one important enum is missing in the "ip-address-origin" typedef:
> 
>   enum link-local {
> description
>   "Indicates a link-local address.";
> reference
>   "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses
>RFC 4291: IP Version 6 Addressing Architecture";
> 
> Would an erratum be possible/useful?
> 
> Lada
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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] top-level mandatory nodes

[Ladislav Lhotka]

> On 16 Dec 2016, at 14:24, Juergen Schoenwaelder 
>  wrote:
> 
> On Fri, Dec 16, 2016 at 12:48:56PM +0100, Ladislav Lhotka wrote:
>> Hi,
>> 
>> 6087bis says in sec. 5.10:
>> 
>>  Top-level database data definitions MUST NOT be mandatory.
>> 
>> It think this makes sense only for config=true nodes. It is absolutely OK to 
>> have mandatory top-level state data, and some published modules already have 
>> them, e.g. ietf-yang-library.
>> 
>> Also, I wonder - should the text use "datastore" rather than "database"?
>> 
> 
> We should not use the term 'database'. I do no think 'datastore' is
> the appropriate replacement. Since this document talks about YANG, I
> think the proper terms are data tree and schema tree (or any other
> terms that the YANG specification defines).

Right - I think the following should do:

OLD

  Top-level database data definitions MUST NOT be mandatory.

NEW

  Top-level data nodes that represent configuration MUST NOT be mandatory.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

[netmod] RFC 7277: ip-address-origin

[Ladislav Lhotka]

Hi,

I think that one important enum is missing in the "ip-address-origin" typedef:

  enum link-local {
description
  "Indicates a link-local address.";
reference
  "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses
   RFC 4291: IP Version 6 Addressing Architecture";

Would an erratum be possible/useful?

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] top-level mandatory nodes

[Juergen Schoenwaelder]

On Fri, Dec 16, 2016 at 12:48:56PM +0100, Ladislav Lhotka wrote:
> Hi,
> 
> 6087bis says in sec. 5.10:
> 
>   Top-level database data definitions MUST NOT be mandatory.
> 
> It think this makes sense only for config=true nodes. It is absolutely OK to 
> have mandatory top-level state data, and some published modules already have 
> them, e.g. ietf-yang-library.
> 
> Also, I wonder - should the text use "datastore" rather than "database"?
>

We should not use the term 'database'. I do no think 'datastore' is
the appropriate replacement. Since this document talks about YANG, I
think the proper terms are data tree and schema tree (or any other
terms that the YANG specification defines).

/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] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

[Robert Wilton]

Hi Iftekhar,

Thanks for the comments and support, please see inline ...


On 15/12/2016 18:55, Iftekhar Hussain wrote:

Yes/support.

I have read this draft and believe it would be very useful for enabling many 
Layer 2 and Layer 3 services.

However, I do have few comments and that I would like the authors to address 
once the document is a WG document.

a)  Suggest to replace this text:
 "These modules allow IETF forwarding protocols (such as IPv6 and VPLS) ..."
  with the following text:
 " These modules allow configuration Layer 2 and Layer 3 subinterfaces (e.g., 
attachment circuits) for providing for IETF L2VPN (e.g., VPWS, VPLS, EVPN) and L3VPN 
services".

Yes, OK.  I think that this text can be tweaked.



b) The document should clearly identify the scope. For example, suggest replace 
this text:
 "... to interoperate with VLAN tagged traffic orginated from an IEEE 802.1Q 
compliant bridge".
with the following text:
"... to interoperate with traffic originated from an IEEE 802.1D, 802.1Q, or 
802.1AD compliant bridge."

Note: In the data model, the draft is talking about untagged as well as 802.1AD (see  
"tag type (802.1Q or 802.1ad)")
Yes, it should mention 802.1D.  802.1ad is part of 802.1Q.  The draft 
would be best referring to S-VLANs vs C-VLANs rather than 802.1Q vs 802.1ad.


 
  c)  Are there any sub-interface level common statistics counters that the model should address?  Currently, I don't see any.
A sub-interface is still just an interface, so by default it would pick 
up all of RFC7223 interface statistics.  Were you looking for any 
additional specific statistics?


However, it would probably be useful to have a counter on the parent 
trunk to indicate the number of packets that haven't been matched to any 
sub-interface, so I think that I should add that.


Thanks,
Rob



Thanks,
Iftekhar
-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
Sent: Monday, December 12, 2016 3:32 PM
To: NetMod WG
Cc: NetMod WG Chairs
Subject: [netmod] WG adoption poll draft-wilton-netmod-intf-vlan-yang-04

All,

This is start of a two week* poll on making
draft-wilton-netmod-intf-vlan-yang-04 a NetMod working group document.

Please send email to the list indicating "yes/support" or "no/do not support".  
If indicating no, please state your reservations with the document.  If yes, please also feel free 
to provide comments you'd like to see addressed once the document is a WG document.

* Given the holiday, the poll ends December 28.

Thank you,
NetMod WG Chairs

___
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] top-level mandatory nodes

[Ladislav Lhotka]

Hi,

6087bis says in sec. 5.10:

  Top-level database data definitions MUST NOT be mandatory.

It think this makes sense only for config=true nodes. It is absolutely OK to 
have mandatory top-level state data, and some published modules already have 
them, e.g. ietf-yang-library.

Also, I wonder - should the text use "datastore" rather than "database"?

Lada
 
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] draft-ietf-netmod-entity issue #13

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Fri, Dec 16, 2016 at 10:31:31AM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Thu, Dec 15, 2016 at 05:26:09PM +0100, Martin Bjorklund wrote:
> > > > Juergen Schoenwaelder  wrote:
> > > > > On Thu, Dec 15, 2016 at 04:15:00PM +0100, Martin Bjorklund wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Issue https://github.com/netmod-wg/entity/issues/13
> > > > > > 
> > > > > >   Should the model support pre-configuration of hardware components?
> > > > > >   The current model supports pre-configuration of components 
> > > > > > provided
> > > > > >   the operator knows the name of the component to be installed. A 
> > > > > > more
> > > > > >   useful model would use the parent component, class, and
> > > > > >   parent-rel-pos as identification. If the system detects a 
> > > > > > component
> > > > > >   and there is configuration available for the parent component,
> > > > > >   class, and parent-rel-pos then the system would instatiate the
> > > > > >   component with the provided name, and optionally additional
> > > > > >   parameters.
> > > > > > 
> > > > > > See also various mails from Timothy Carey and Bart Bogaert on this
> > > > > > issue.
> > > > > > 
> > > > > > Personally, I think that we should add these nodes, since the ML
> > > > > > comments indicated that pre configuration is pretty useful.
> > > > > >
> > > > > 
> > > > > I am still not sure what exactly this will do. I have been looking at
> > > > > .
> > > > > I am provisioning mfg-name (Preferred value is the manufacturer name
> > > > > string actually printed on the component itself (if present).) but all
> > > > > I have is that something of a certain expected class has been plugged
> > > > > into a certain position of the parent container. Also note that
> > > > > mfg-name scopes comparisons of other properties. I would have similar
> > > > > questions concerning the model-name; how can a provisioning system
> > > > > predict the 'vendor-specific model name identifier'? Or is the whole
> > > > > idea that if I plug something that does not match, the component is
> > > > > left in a special state (which one)? If this is the intention, then
> > > > > this needs to be spelled out clearly somewhere.
> > > > 
> > > > The current model works fine if the user looks into the state list and
> > > > finds a component that he wants to configure.  To do this, he uses the
> > > > name of the component as found in the state list, and writes the
> > > > config for this component.
> > > > 
> > > > The current model also supports pre-configuration if the user somehow
> > > > can predict the name of a component to-be-inserted.  In this case he
> > > > can write the config, and when the component is plugged in, the system
> > > > will derive the component name, and check the config list for this
> > > > name.  This is a fragile model.
> > > > 
> > > > In the proposed model, the user can provide configuration for a tuple
> > > > (parent, class, parent-rel-pos).   If the server finds a component in
> > > > the state list (or such a component is later plugged in), then the
> > > > corresponding config leafs are used for the state of this component
> > > > (including the name).
> > > > 
> > > > If you plug in something that doesn't match the config list, well that
> > > > just means that nothing has been configured for this component, and
> > > > the system will populate the state list accordingly.
> > > >
> > > 
> > > Well, this is not what I read out of
> > > 
> > > https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html
> > > 
> > > since there are leafs like mfg-name and model-name that seem to be
> > > hardware component properties.
> > 
> > The description statements in this email are just copied from the
> > corresponding config false nodes.  I think they need to be rewritten;
> > compare with serial-num.  This text can probably be further improved.
> > The idea is that the user probably would configure say mfg-name only
> > if the system cannot detect it automatically.
> 
> I still wonder why it could be useful to provision things like the
> mfg-name or the serial-num. I would rather like to know what is really
> there instead of overwriting these properties.

Note that entPhysicalSerialNum is read-write in the MIB.  I assume
that the reason for this is that operators can use this as an
inventory list, and manually enter the values that the system cannot
detect automatically.

> > > And the config list is still indexed by
> > > a name; so for list elements that have a (class, parent, position)
> > > triple, the name would be arbitrary and not necessarily matching the
> > > component name.
> > 
> > I think that the idea is that if there is a matching triple, then the
> > system MUST use the configured 'name' as the 'name' also in the state
> > list.  One reason for pre-confiugring these components is to be able
>

Re: [netmod] draft-ietf-netmod-entity issue #13

[Juergen Schoenwaelder]

On Fri, Dec 16, 2016 at 10:31:31AM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Thu, Dec 15, 2016 at 05:26:09PM +0100, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  wrote:
> > > > On Thu, Dec 15, 2016 at 04:15:00PM +0100, Martin Bjorklund wrote:
> > > > > Hi,
> > > > > 
> > > > > Issue https://github.com/netmod-wg/entity/issues/13
> > > > > 
> > > > >   Should the model support pre-configuration of hardware components?
> > > > >   The current model supports pre-configuration of components provided
> > > > >   the operator knows the name of the component to be installed. A more
> > > > >   useful model would use the parent component, class, and
> > > > >   parent-rel-pos as identification. If the system detects a component
> > > > >   and there is configuration available for the parent component,
> > > > >   class, and parent-rel-pos then the system would instatiate the
> > > > >   component with the provided name, and optionally additional
> > > > >   parameters.
> > > > > 
> > > > > See also various mails from Timothy Carey and Bart Bogaert on this
> > > > > issue.
> > > > > 
> > > > > Personally, I think that we should add these nodes, since the ML
> > > > > comments indicated that pre configuration is pretty useful.
> > > > >
> > > > 
> > > > I am still not sure what exactly this will do. I have been looking at
> > > > .
> > > > I am provisioning mfg-name (Preferred value is the manufacturer name
> > > > string actually printed on the component itself (if present).) but all
> > > > I have is that something of a certain expected class has been plugged
> > > > into a certain position of the parent container. Also note that
> > > > mfg-name scopes comparisons of other properties. I would have similar
> > > > questions concerning the model-name; how can a provisioning system
> > > > predict the 'vendor-specific model name identifier'? Or is the whole
> > > > idea that if I plug something that does not match, the component is
> > > > left in a special state (which one)? If this is the intention, then
> > > > this needs to be spelled out clearly somewhere.
> > > 
> > > The current model works fine if the user looks into the state list and
> > > finds a component that he wants to configure.  To do this, he uses the
> > > name of the component as found in the state list, and writes the
> > > config for this component.
> > > 
> > > The current model also supports pre-configuration if the user somehow
> > > can predict the name of a component to-be-inserted.  In this case he
> > > can write the config, and when the component is plugged in, the system
> > > will derive the component name, and check the config list for this
> > > name.  This is a fragile model.
> > > 
> > > In the proposed model, the user can provide configuration for a tuple
> > > (parent, class, parent-rel-pos).   If the server finds a component in
> > > the state list (or such a component is later plugged in), then the
> > > corresponding config leafs are used for the state of this component
> > > (including the name).
> > > 
> > > If you plug in something that doesn't match the config list, well that
> > > just means that nothing has been configured for this component, and
> > > the system will populate the state list accordingly.
> > >
> > 
> > Well, this is not what I read out of
> > 
> > https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html
> > 
> > since there are leafs like mfg-name and model-name that seem to be
> > hardware component properties.
> 
> The description statements in this email are just copied from the
> corresponding config false nodes.  I think they need to be rewritten;
> compare with serial-num.  This text can probably be further improved.
> The idea is that the user probably would configure say mfg-name only
> if the system cannot detect it automatically.

I still wonder why it could be useful to provision things like the
mfg-name or the serial-num. I would rather like to know what is really
there instead of overwriting these properties.
 
> > And the config list is still indexed by
> > a name; so for list elements that have a (class, parent, position)
> > triple, the name would be arbitrary and not necessarily matching the
> > component name.
> 
> I think that the idea is that if there is a matching triple, then the
> system MUST use the configured 'name' as the 'name' also in the state
> list.  One reason for pre-confiugring these components is to be able
> to refer to them in other config.

This may make sense.

> > Well, if you understand the edits,...
> 
> I think the idea would be explained along these lines:
> 
> The sytem conceptually behaves like this:
> 
> 1.  When a physical component is detected, the system will initialize
> an entry in the /hardware-state/component list.
> 
> If there is an entry in /hardare/component list with a matching
> (class,parent,parent-rel-pos) triple, then t

Re: [netmod] Modelling different "levels" of data in YANG

[Robert Wilton]

Hi,

A variant on your suggestion:

Rather than "diagnostics true;" a potentially more general way of 
handling this could be a generalized schema flag to indicate that a 
particular node (and its children) is never returned unless explicitly 
requested.  E.g. "hidden: true" instead of "diagnostics: true".  The 
data would only be returned if either (i) the filter explicitly 
indicated that hidden data should be returned (as per Kent's 
suggestion), or possibly also (ii) if the request path (or filter) 
explicitly specified the hidden node(s).


Thanks,
Rob


On 15/12/2016 19:23, Vladimir Vassilev wrote:

Hi,

Here is a summary of the proposed solutions so far:

* The solution with introduction of YANG statement "diagnostics 
true;", additional datastore and NETCONF protocol change. IMO that 
sounds heavy but valid solution.
* The solution with RPC returning the data as output. IMO has the 
limitation of not presenting the diagnostics data in the data tree (no 
valid instance-identifiers to be used in notifications). But is the 
simplest to have in place.
* The solution with RPC enabling the containers only for a certain 
session.


I thought also of this alternative solution:  The solution is to avoid 
clobbering the replies to s without filter or s with filter 
matching only parent nodes of the "diagnostics state" container data  
and not return those nodes in the reply except in the cases the filter 
matches data nodes part of the diagnostics data explicitly.


Example for /interfaces-state/interfaces/diagnostics (using xpath 
filter for brevity but valid for the "subtree" case):


These skip "diagnostics":



These return "diagnostics":

select="/interfaces-state/interface/diagnostics"\>



This looks like a violation of RFC 6241 6.2.5 bullet 12 but IMO the 
container is non-mandatory diagnostics data so returning it only when 
someone really wants it and not otherwise is the definition of the 
solution to the problem.


/Vladimir

On 12/12/2016 05:47 PM, Kent Watsen wrote:


Hi Robert,

You’re right, it should’ve been the  (not ).   
However, I think that it’s better to use a flag on the 
 datastore, rather than to define a new 
datastore.  Not only would it mimic how with-defaults works, but it 
also seems more intuitive from a retrieval perspective, as the 
diagnostics nodes could be sprinkled throughout a data model, and a 
single  could return all nodes (not just the diagnostics) 
for a given subtree.Thoughts?


Separately, from a modelling perspective, presumably there would have 
to be an additional flag to go with the config false flag, something 
like the below.  Is this what you were envisioning?


container thermostat {

leaf configured-temperature {

type int8;

}

leaf current-temperature {

config false;

type int8;

}

container diagnostics {

config false;

diagnostics true;<-- new flag here

...

}

Is all this leading up to a draft?  ;)

Kent  // contributor

*From: *Robert Wilton 
*Date: *Monday, December 12, 2016 at 6:10 AM
*To: *Kent Watsen , Andy Bierman 


*Cc: *"netmod@ietf.org" 
*Subject: *Re: [netmod] Modelling different "levels" of data in YANG

Hi Kent,

On 10/12/2016 00:59, Kent Watsen wrote:

> I prefer not to use specialized  operations.

Agreed, I was thinking something more along the lines of:

   

  

 

  

<--- note this flag here

  

 http://example.com/schema/1.2/config";
>



  



 

  

   

Thus explicitly requesting all the extra stuff get returned...

Yes, that is roughly along the lines that I was thinking.

Or building on draft-nmdsdt-netmod-revised-datastores:
- presuming the existing of a  operation to generically 
return the contents of any datastore,
- defining a new  datastore that contains the contents 
of the  along with all config false schema nodes 
labelled as "diagnostics true".


   

  

 

  

  



  


Thanks,
Rob



> In the usage model that Rob described, the service tech will be

> setting diag-mode to 'system'  then retrieving the extra
'diag-stats',

>then setting diag-mode back to 'user'.

Right, but this does not seem ideal as the diag-mode toggle is a
global setting that would affect all clients for some window of
time, or do we envision diag-mode dropping the system down to
single-user mode?

Kent  // contributor


.



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

Re: [netmod] [Netconf] Leaf-list usage

[Martin Bjorklund]

Rohit R Ranade  wrote:
> Whether condition as below:
> 
>  
>fred
>barney
>  
> 
> Can select below record ?
> 
>barney
>fred
>  
> 
> Basically , whether leaf-list with [barney, fred] are treated as same
> as leaf-list with [fred, barney] ? In ordered-by system the order does
> not matter to user, so it can be treated as same ?
> I think in the ordered-by user case, this treatment cannot be
> extended. Please clarify.

For subtree filtering, the order of elements does not matter,  so in
the example above, the record will be selected.  Whether the leaf-list
is defined as ordered-by user or ordered-by system does not matter for
the filter result.


/martin


> 
> 
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com] 
> Sent: 16 December, 2016 18:47
> To: Rohit R Ranade
> Cc: lho...@nic.cz; netmod@ietf.org
> Subject: Re: [netmod] [Netconf] Leaf-list usage
> 
> Rohit R Ranade  wrote:
> > Hi,
> > Consider we have 2 records as given below  
> >(Rec1)
> > 10
> > fred
> >   
> >(Rec2)
> > 20
> > fred
> > barney
> > wilma
> > someother
> >   
> > 
> > Q1 : Using subtree filtering which condition on the leaf-list node can
> > the user give such that he selects the record which contains foo=fred
> > only...
> >[we can assume user does not know the value of "name"]
> 
>  
>fred
>  
> 
> 
> > Q2 : Also about the leaf-list, I have tried searching but have not
> > found how this leaf-list originated ?
> 
> 1 instance of a scalar type  => leaf
> N instances of a scalar type => leaf-list
> 1 instance of a structure=> container
> N instances of a structure   => list
> 
> >  Whether XSD list is the
> > representation for leaf-list in xsd ?
> 
> No.
> 
> >  The XSD list is represented slightly differently as per
> >  http://www.w3schools.com/xml/el_list.asp : I love XML
> >  Schema
> 
> Correct.
> 
> 
> /martin
> 

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

Re: [netmod] [Netconf] Leaf-list usage

[Rohit R Ranade]

Whether condition as below:

 
   fred
   barney
 

Can select below record ?

   barney
   fred
 

Basically , whether leaf-list with [barney, fred] are treated as same as 
leaf-list with [fred, barney] ? In ordered-by system the order does not matter 
to user, so it can be treated as same ?
I think in the ordered-by user case, this treatment cannot be extended. Please 
clarify.


-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: 16 December, 2016 18:47
To: Rohit R Ranade
Cc: lho...@nic.cz; netmod@ietf.org
Subject: Re: [netmod] [Netconf] Leaf-list usage

Rohit R Ranade  wrote:
> Hi,
> Consider we have 2 records as given below  
>(Rec1)
> 10
> fred
>   
>(Rec2)
> 20
> fred
> barney
> wilma
> someother
>   
> 
> Q1 : Using subtree filtering which condition on the leaf-list node can
> the user give such that he selects the record which contains foo=fred
> only...
>[we can assume user does not know the value of "name"]

 
   fred
 


> Q2 : Also about the leaf-list, I have tried searching but have not
> found how this leaf-list originated ?

1 instance of a scalar type  => leaf
N instances of a scalar type => leaf-list
1 instance of a structure=> container
N instances of a structure   => list

>  Whether XSD list is the
> representation for leaf-list in xsd ?

No.

>  The XSD list is represented slightly differently as per
>  http://www.w3schools.com/xml/el_list.asp : I love XML
>  Schema

Correct.


/martin

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

Re: [netmod] [Netconf] Leaf-list usage

[Martin Bjorklund]

Rohit R Ranade  wrote:
> Hi,
> Consider we have 2 records as given below  
>(Rec1)
> 10
> fred
>   
>(Rec2)
> 20
> fred
> barney
> wilma
> someother
>   
> 
> Q1 : Using subtree filtering which condition on the leaf-list node can
> the user give such that he selects the record which contains foo=fred
> only...
>[we can assume user does not know the value of "name"]

 
   fred
 


> Q2 : Also about the leaf-list, I have tried searching but have not
> found how this leaf-list originated ?

1 instance of a scalar type  => leaf
N instances of a scalar type => leaf-list
1 instance of a structure=> container
N instances of a structure   => list

>  Whether XSD list is the
> representation for leaf-list in xsd ?

No.

>  The XSD list is represented slightly differently as per
>  http://www.w3schools.com/xml/el_list.asp : I love XML
>  Schema

Correct.


/martin

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

Re: [netmod] draft-ietf-netmod-entity issue #13

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Thu, Dec 15, 2016 at 05:26:09PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Thu, Dec 15, 2016 at 04:15:00PM +0100, Martin Bjorklund wrote:
> > > > Hi,
> > > > 
> > > > Issue https://github.com/netmod-wg/entity/issues/13
> > > > 
> > > >   Should the model support pre-configuration of hardware components?
> > > >   The current model supports pre-configuration of components provided
> > > >   the operator knows the name of the component to be installed. A more
> > > >   useful model would use the parent component, class, and
> > > >   parent-rel-pos as identification. If the system detects a component
> > > >   and there is configuration available for the parent component,
> > > >   class, and parent-rel-pos then the system would instatiate the
> > > >   component with the provided name, and optionally additional
> > > >   parameters.
> > > > 
> > > > See also various mails from Timothy Carey and Bart Bogaert on this
> > > > issue.
> > > > 
> > > > Personally, I think that we should add these nodes, since the ML
> > > > comments indicated that pre configuration is pretty useful.
> > > >
> > > 
> > > I am still not sure what exactly this will do. I have been looking at
> > > .
> > > I am provisioning mfg-name (Preferred value is the manufacturer name
> > > string actually printed on the component itself (if present).) but all
> > > I have is that something of a certain expected class has been plugged
> > > into a certain position of the parent container. Also note that
> > > mfg-name scopes comparisons of other properties. I would have similar
> > > questions concerning the model-name; how can a provisioning system
> > > predict the 'vendor-specific model name identifier'? Or is the whole
> > > idea that if I plug something that does not match, the component is
> > > left in a special state (which one)? If this is the intention, then
> > > this needs to be spelled out clearly somewhere.
> > 
> > The current model works fine if the user looks into the state list and
> > finds a component that he wants to configure.  To do this, he uses the
> > name of the component as found in the state list, and writes the
> > config for this component.
> > 
> > The current model also supports pre-configuration if the user somehow
> > can predict the name of a component to-be-inserted.  In this case he
> > can write the config, and when the component is plugged in, the system
> > will derive the component name, and check the config list for this
> > name.  This is a fragile model.
> > 
> > In the proposed model, the user can provide configuration for a tuple
> > (parent, class, parent-rel-pos).   If the server finds a component in
> > the state list (or such a component is later plugged in), then the
> > corresponding config leafs are used for the state of this component
> > (including the name).
> > 
> > If you plug in something that doesn't match the config list, well that
> > just means that nothing has been configured for this component, and
> > the system will populate the state list accordingly.
> >
> 
> Well, this is not what I read out of
> 
> https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html
> 
> since there are leafs like mfg-name and model-name that seem to be
> hardware component properties.

The description statements in this email are just copied from the
corresponding config false nodes.  I think they need to be rewritten;
compare with serial-num.  This text can probably be further improved.
The idea is that the user probably would configure say mfg-name only
if the system cannot detect it automatically.

> And the config list is still indexed by
> a name; so for list elements that have a (class, parent, position)
> triple, the name would be arbitrary and not necessarily matching the
> component name.

I think that the idea is that if there is a matching triple, then the
system MUST use the configured 'name' as the 'name' also in the state
list.  One reason for pre-confiugring these components is to be able
to refer to them in other config.

> Well, if you understand the edits,...

I think the idea would be explained along these lines:

The sytem conceptually behaves like this:

1.  When a physical component is detected, the system will initialize
an entry in the /hardware-state/component list.

If there is an entry in /hardare/component list with a matching
(class,parent,parent-rel-pos) triple, then the state entry is
initialized with the configured values for all configured leafs
(name, mfg-name, ...).

If there is no such matching entry, the system assigns a 'name'
in an implementation-specific manner.

If there is an entry in /hardare/component list with a matching
'name' and where the triple (class,parent,parent-rel-pos) is not
set, then the state entry is initialized with the configured
values for all configured le

Re: [netmod] BBF work depending on draft-ietf-netmod-entity-01

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Fri, Dec 16, 2016 at 09:38:35AM +0100, Martin Bjorklund wrote:
> > Hi,
> > 
> > William Lupton  wrote:
> > > The current draft-ietf-netmod-entity-01 defines ietf-hardware and
> > > iana-entity modules. Is it intended that iana-entity will become
> > > iana-hardware? Thanks, W.
> > 
> > I don't have a strong opinion, but it probably makes sense.  In the
> > MIB, the word "entity" is just present in the MIB name:
> > 
> >   IANA-ENTITY-MIB defines the TC IANAPhysicalClass
> > 
> > So in YANG we can do:
> > 
> >   iana-hardware defines the base identity physical-class (+ derived
> >   identities)
> >
> 
> Should the base identity be called 'entity-physical-class'? Or would
> 'hardware-class' be more appropriate? OK, all the descriptions talk
> about 'physical entity class'.

I think it's ok to change both the name and descriptions to 'hardware'.

> I guess the question is how far we go
> with renaming. We also have features called entity-state and
> entity-sensor.

I think it makes sense to rename them as well.  Then the word "entity"
would be used wwhen referring to the MIBs.

> (Also the short page title should probably be changed
> from 'YANG Entity Management' to 'YANG Hardware Management'.)

Yes, I found and fixed this bug yesterday.


/martin

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

Re: [netmod] [Netconf] Leaf-list usage

[Rohit R Ranade]

Hi,
Consider we have 2 records as given below  
   (Rec1)
10
fred
  
   (Rec2)
20
fred
barney
wilma
someother
  

Q1 : Using subtree filtering which condition on the leaf-list node can the user 
give such that he selects the record which contains foo=fred only...
   [we can assume user does not know the value of "name"]

Q2 : Also about the leaf-list, I have tried searching but have not found how 
this leaf-list originated ? Whether XSD list is the representation for 
leaf-list in xsd ?
 The XSD list is represented slightly differently as per 
http://www.w3schools.com/xml/el_list.asp  : I love XML 
Schema



-Original Message-
From: Ladislav Lhotka [mailto:lho...@nic.cz] 
Sent: 16 December, 2016 17:40
To: Rohit R Ranade
Cc: NETMOD WG
Subject: Re: [Netconf] Leaf-list usage

Hi,

> On 16 Dec 2016, at 06:44, Rohit R Ranade  wrote:
> 
> I was going through the ietf discussion for leaf-list subtree and found a 
> link (https://www.ietf.org/mail-archive/web/netmod/current/msg01982.html)

Your question belongs to to the NETMOD mailing list, so I am moving it there.

>  
> A question that I have :
> 1)  Consider leaf-list f1= [1, 2, 3] in DB.. If I provide condition on 
> leaflist f1=[1],  will it select [1,2,3] ? Will it always be sub-set match   
> ? How to get an exact match for the whole leaf-list.

I assume you mean condition expressed in XPath. In this case you cannot test 
whole lists on equality, but if you have

must "f1 = 1";

then

"f1": [1, 2, 3]

would satisfy that condition. You could also write, for example,

must "f1 = 1 and count(f1) = 1";

and then only

"f1": [1]

will match.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] draft-ietf-netmod-entity issue #11

[Martin Bjorklund]

Randy Presuhn  wrote:
> Hi -
> 
> My recollection is that part of the motivation for the use of
> zero-length strings as sentinel values in situations like this
> in MIB modules (rather than skipping the object instance) was
> to permit a clear distinction between "information not available"
> and "access denied".

Ok.  But if this is an important use case, maybe we should try to have
generic support for it, instead of using special values.  Not all
types have a natural value for "not available".

I think that people often used these kinds of constructs in MIBs
to avoid "holes" in the tables; I don't know if that applied to this
MIB though.


/martin



> 
> Randy
> 
> On 12/15/2016 7:21 AM, Juergen Schoenwaelder wrote:
> > I do not think the goal should be to emulate SMIv2 compliance levels
> > using features. So I propose to do nothing about entity4CRCompliance.
> >
> > The other question (which should perhaps have been a separate issue)
> > is whether non-existing values are indicated by zero-length strings or
> > non-existing objects. I think in general we prefer to simply not
> > report those objects in the YANG world. If so, I am not sure whether
> > the goal to not depart too much from the ENTITY-MIB overrules
> > this. Note that there are a couple of objects where non-existing
> > values lead to zero-length string or other special values. (The
> > 'alias' description is kind of interesting - the server may set the
> > value of this node to a locally unique value; entPhysicalAlias says
> > something different, namely On the first instantiation ... is set to
> > the zero-length string.)
> >
> > Looking at the YANG fragment, I am also not sure how useful it is to
> > carry the 32 'something' restriction forward. Note that 32 means
> > unicode characters in YANG but space of the UTF-8 encoding of
> > characters for SMIv2 (since it all ends up being a restriction for the
> > OCTET STRING). Perhaps this deserves a feature, namely, whether an
> > implementation supports flexible names or restricts names according to
> > the SMIv2 ENTITY-MIB rules.
> >
> > /js
> >
> > On Thu, Dec 15, 2016 at 04:01:10PM +0100, Martin Bjorklund wrote:
> >> Hi,
> >>
> >> Issue https://github.com/netmod-wg/entity/issues/11
> >>
> >>   RFC 6933 introduced a new compliance level for constrained resources
> >>   - entity4CRCompliance. Do we need a corresponding feature?
> >>
> >> In YANG, we cannot to the equivalent of compliance levels, so we would
> >> need to mark all nodes with some optional feature, except the few
> >> nodes that a constrained device would implement.
> >>
> >> OTOH, most nodes are already optional and config false.  So a
> >> constrained server that doesn't know the serial number for example
> >> could just no return it.  There is one catch though; the current text,
> >> copied from the MIB, says e.g.:
> >>
> >>If the manufacturer name string associated with the
> >>physical component is unknown to the server, then this
> >>node will contain a zero-length string.
> >>
> >> Maybe we should change this so that the object isn't returned at all
> >> instead of returning a zero-length string.
> >>
> >>
> >>
> >> /martin
> >>
> >> ___
> >> 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 mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF work depending on draft-ietf-netmod-entity-01

[Juergen Schoenwaelder]

On Fri, Dec 16, 2016 at 09:38:35AM +0100, Martin Bjorklund wrote:
> Hi,
> 
> William Lupton  wrote:
> > The current draft-ietf-netmod-entity-01 defines ietf-hardware and
> > iana-entity modules. Is it intended that iana-entity will become
> > iana-hardware? Thanks, W.
> 
> I don't have a strong opinion, but it probably makes sense.  In the
> MIB, the word "entity" is just present in the MIB name:
> 
>   IANA-ENTITY-MIB defines the TC IANAPhysicalClass
> 
> So in YANG we can do:
> 
>   iana-hardware defines the base identity physical-class (+ derived
>   identities)
>

Should the base identity be called 'entity-physical-class'? Or would
'hardware-class' be more appropriate? OK, all the descriptions talk
about 'physical entity class'. I guess the question is how far we go
with renaming. We also have features called entity-state and
entity-sensor. (Also the short page title should probably be changed
from 'YANG Entity Management' to 'YANG Hardware Management'.)

/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] BBF work depending on draft-ietf-netmod-entity-01

[Martin Bjorklund]

Hi,

William Lupton  wrote:
> The current draft-ietf-netmod-entity-01 defines ietf-hardware and
> iana-entity modules. Is it intended that iana-entity will become
> iana-hardware? Thanks, W.

I don't have a strong opinion, but it probably makes sense.  In the
MIB, the word "entity" is just present in the MIB name:

  IANA-ENTITY-MIB defines the TC IANAPhysicalClass

So in YANG we can do:

  iana-hardware defines the base identity physical-class (+ derived
  identities)


/martin

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

Re: [netmod] [Netconf] Leaf-list usage

[Ladislav Lhotka]

Hi,

> On 16 Dec 2016, at 06:44, Rohit R Ranade  wrote:
> 
> I was going through the ietf discussion for leaf-list subtree and found a 
> link (https://www.ietf.org/mail-archive/web/netmod/current/msg01982.html)

Your question belongs to to the NETMOD mailing list, so I am moving it there.

>  
> A question that I have :
> 1)  Consider leaf-list f1= [1, 2, 3] in DB.. If I provide condition on 
> leaflist f1=[1],  will it select [1,2,3] ? Will it always be sub-set match   
> ? How to get an exact match for the whole leaf-list.

I assume you mean condition expressed in XPath. In this case you cannot test 
whole lists on equality, but if you have

must "f1 = 1";

then

"f1": [1, 2, 3]

would satisfy that condition. You could also write, for example,

must "f1 = 1 and count(f1) = 1";

and then only

"f1": [1]

will match.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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