Subject: Re: [netmod] Feedback on draft-ietf-ipfix-configuration-model-07

From: Gerhard Muenz <[email-masked]>
Date: Tue, 10 Aug 2010 10:05:41 +0200

Hi Lada,

Thank you for your comments.

> Hi Gerhard,
> 
> I have the following comments/questions:
> 
> 1. You only have one revision covering the entire history of the module.
> I would expect at least one revision of the module for each revision of
> the I-D.

The only official (and hopefully bug-free) module will be the one
published in the RFC.

The change log text only exists to keep track of changes during the
development process. It will be delete in the RFC in order not to
confuse any user.

> 2. Given the large number of declared features (17), perhaps it would be
> better to have multiple modules, e.g. separate modules for "meter",
> "exporter", "collector" and "psamp". Have you considered this option?

I have not thought about this.

There are a lot of dependencies and restrictions which would then be
defined across module boundaries. Therefore, I'm not sure whether your
suggestion works.

Maybe you can sketch how you would split the configuration.

Gerhard

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 10 Aug 2010 14:29:56 +0200

> development process. It will be delete in the RFC in order not to

OK, fair enough, this is clearly the majority opinion.

> Maybe you can sketch how you would split the configuration.

You can get the respective data models by turning on the features
"collector", "meter" and "exporter" selectively, so any must-have
dependencies among them would be a problem anyway. 

module  collector {
  ...
  list collectingProcess {
    ...
  }
}

module meter {
  ...
  list observationPoint {
    ...
  }
  list selectionProcess {
    ...
  }
  list cache {
    ...
  }
}

module exporter {
  ...
  list exportingProcess {
    ...
  }
}

The only thing you would lose this way is the top-level "ipfix"
container, right? In order to keep it, you could also have a wrapper
module "ipfix" and define the three modules above as augments of the
top-level element, e.g.

module collector {
  ...
  import ipfix {
    prefix ipfix;
  }
  augment "/ipfix:ipfix" {
    list collectingProcess {
      ...
    }
  }
}

But, in my opinion, the original "unrooted" modules should be just fine.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Aug 2010 15:15:52 +0200 (CEST)

> defined across module boundaries. Therefore, I'm not sure whether your

I think one module for ipfix is fine.  I do not understand what
problem is solved by splitting into more modules.

If the problem is the size of the module, or that individual parts may
be updated individually, you could split the module into submodules,
but as I said, I do not think it is necessary.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 10 Aug 2010 15:47:47 +0200

> problem is solved by splitting into more modules.

Smaller relatively independent modules are IMO easier to understand. The
present approach with features is like a C source file with a lot of
ifdefs. From the practical point of view, flow-handling devices most
often implement either the meter&exporter part or the collector part.
  
> but as I said, I do not think it is necessary.

Using the same logic, someone could start writing an all-encompassing
"router" module:

module router {
  ...
  feature static;
  feature bgp;
  feature ospf;
  ...
}

I hope we all agree it shouldn't (and won't) be done this way. So what's
the difference? Overall size, of course, but the "ipfix" module is quite
long, too - its tree representation from pyang is 8 pages long.

Lada

> 
> 
> /martin
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Aug 2010 17:21:37 +0200

> problem is solved by splitting into more modules.

Same feeling here. Perhaps there is also an implicit request for tools
that can help with making the feature partitions easier to inspect and
analyze.

The downside of many modules is the number of namespaces that need to
be dealt with - especially by humans (machines have it easier to sort
out many namespaces). Another level of modularization are submodules
but it is unclear whether or how they work in the IETF since we lack
operational experience with them.

/js 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>