Subject: Re: [IPFIX] review of YANG module ietf-ipfix-psamp@2010-10-25

From: Gerhard Muenz <[email-masked]>
Date: Sun, 02 Jan 2011 21:01:53 +0100

Hi Lada,

>>> My main concern is the size of the module. I believe that splitting the
>>> data model into smaller coherent modules makes it more understandable
>>> and manageable - also in terms of the standardisation process. It
>>> seems that the present module could relatively easily be divided into
>>> two modules, one describing the collector subsystem and the other
>>> dealing with the remaining functionality. As a matter of fact, flow
>>> collectors are in most cases implemented in a separate device, so
>>> their configuration won't be mixed with configurations of the other
>>> parts. This change would also remove one level of containment in the
>>> schema, at a very reasonable price of adding one more namespace.
>>
>> With the upcoming IPFIX mediators, we will have devices implementing 
>> Collecting Processes, Intermediate Processes, and Exporting Processes.
>> Therefore, I think that keeping the configuration data of all IPFIX 
>> processes in one module makes sense.
> 
> All functions could be combined anyway, even if they are defined in
> different modules, by advertising all modules that apply in the hello
> message rather than having just one module and using various
> combinations of features. By way of analogy, entire router configuration
> could also be specified in one module and various routing protocols
> selected by means of features - I just don't think this is the right
> approach.

There are groupings which are used in Exporter and Collector
configurations (e.g. TransportSession, TransportLayerSecurity).

Furthermore, the output of a Collecting Processes can be directed to an
Exporting Processes, using leafrefs. As far as I understand, leafref
cannot point to another module which is not imported.

Ersue and Bernd argued that the list of Selectors is very long. Hence,
instead of splitting the entire module, I would rather create a
submodule for the different Selectors.

What do you think about this?

Gerhard

---

From: Benoit Claise <[email-masked]>
Date: Thu, 06 Jan 2011 14:12:33 +0100

Dear all,

OLD:
"If omitted or zero, the Information Element is registered in the IANA 
registry of
IPFIX Information Elements."

NEW:
"If omitted, the Information Element is registered in the IANA registry of
IPFIX Information Elements."

What is the problem with the simple solution?

Regards, Benoit.
>>> - The description of "ieEnterpriseNumber" leafs says: "If omitted or
>>>     zero, the Information Element is registered in the IANA registry of
>>>     IPFIX Information Elements." Why not define a default value of "0"
>>>     here (perhaps in a special typedef)?
>> I'm not sure whether 0 is a valid enterprise number.
>>
>>
>> In http://www.iana.org/assignments/enterprise-numbers , we have:
>>
>> Decimal
>> | Organization
>> | | Contact
>> | | | Email
>> | | | |
>> 0
>>     Reserved
>>       Internet Assigned Numbers Authority
>>         iana&iana.org
>>
>> Does this mean that 0 can be used to refer to IANA?
>> If yes, we could use 0 as a default value. Otherwise, I would rather
>> remove "or zero" and create a type that does not allow zero values.
> I don't know but the text as it is now sounds exactly like zero is the
> default value for this leaf.
>
> Lada
>

---

From: Brian Trammell <[email-masked]>
Date: Thu, 6 Jan 2011 14:27:35 +0100

Hi, Benoit, all,

PEN zero is taken to be a default value meaning "in the IANA registry" in RFC 5610, section 3.8, and in the definition of IE 346 privateEnterpriseNumber at http://www.iana.org/assignments/ipfix/ipfix.xhtml. "Or 0" should be retained to remained consistent.

Best regards,

Brian

On Jan 6, 2011, at 2:12 PM, Benoit Claise wrote:

> Dear all,
> 
> OLD:
> "If omitted or zero, the Information Element is registered in the IANA registry of
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Benoit Claise <[email-masked]>
Date: Thu, 06 Jan 2011 14:45:48 +0100

Hi Brian,

Thanks for the clarification.
So as Lada mentioned, 0 should be the default value.

Regards, Benoit.

---

From: Paul Aitken <[email-masked]>
Date: Thu, 06 Jan 2011 16:25:13 +0000

Benoit,

I agree with Brian: the value zero should be retained.

For two reasons:

1. This isn't actually an IANA EnterpriseNumber. It's actually an IPFIX 
ieEnterpriseNumber which builds on the IANA EnterpriseNumber by adding 
the extra definition for 0.

2. There should be a way to export "in the IANA registry" without 
requiring a new template - which would be necessary if the 
ieEnterpriseNumber must be omitted.

Cheers,
P.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 06 Jan 2011 17:27:48 +0100

Paul,
> 1. This isn't actually an IANA EnterpriseNumber. It's actually an 
> IPFIX ieEnterpriseNumber which builds on the IANA EnterpriseNumber by 
> adding the extra definition for 0.
>
I'm convinced now

Regards, Benoit

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 10 Jan 2011 11:58:15 +0100

Hi Gerhard,

> configurations (e.g. TransportSession, TransportLayerSecurity).

Such groupings could be put to a separate module and imported where
necessary, right?
 
> cannot point to another module which is not imported.

This is a good point which is actually somewhat unclear in RFC 6020.
Sec. 9.9.1 defines the accessible tree for leafrefs in config data in
terms of configuration datastores, e.g. the last bullet:

o  Otherwise, the tree is all state data on the device, and the
   <running/> datastore.  The XPath root node has all top-level data
   nodes in all modules as children.

This seems to imply that the parts of the configuration datastore coming
from another module are also accessible, even if the latter module is
not imported by the module containing the leafref.

On the other hand, if you don't import the other module, you don't have
the prefix of the other module that you need for the 'path' statement.

> submodule for the different Selectors.

This is an option, just keep in mind that any new revision of the
submodule implies a change in the main module, so the modularity is not
as good as for (main) modules:
http://tools.ietf.org/html/draft-ietf-netmod-yang-usage-11#section-3.5.2

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C