NFD

I agree with note-8 change.

I'm looking at current Forwarder API and I think I shouldn't introduce a setRegionNames setter method and put matching logic inside Forwarder, because region names are part of the forwarder's state, and state should go into a table.

I plan to add a table as follows:

class RegionSet : public std::set<Name>
{
public:
  /** \brief determines whether an Interest has reached a producer region
   */
  bool
  isInProducerRegion(const Interest& interest) const;
};

This allows optimizations on the table without affecting Forwarder.

This also allows future management protocol to manipulate the table, or create dataset out of the table, without requiring direct access to Forwarder.

nfd::general::processConfigFile will receive a reference to this table, instead of Forwarder&.

20150817 conference call approves design in note-10.

In commit:ec82530b4e1deaf51104a87b2ea013e13bbf6821, reviewer suggests renaming RegionSet to NetworkRegions, with the following reasons:

1. "producer region" is a little bit general term. I would at least add "network" in the middle.
   here there is no context and "producer region name" can mean "North America", "Los Angeles", "UCLA", "backbone", etc.

2. call it just NetworkRegions
   set is even worse, as it has suggestion that it is a set. It can be other data structure.
   at least one of our tables is using plural case and for table it is expected to have plural meaning.

I agree with the first statement.

I disagree with the second statement.
It's bad to name a container as the plural form of the item it contains, because the difference between an item and a container is not obvious enough.
For example, in .NET Framework, a collection of XmlAttribute is named XmlAttributeCollection, and a collection of AccessControlEntry is named AccessControlList.

However, I agree that set should not be used because this table is not necessarily an std::set.

I propose the following candidate names: NetworkRegionList, NetworkRegionTable, ProducerRegionList, ProducerRegionTable.

20150821 conference call decides to call the table NetworkRegionTable.

On commit:472726cc684d50488f0fd27e2114e274bba1928d, reviewer has pointed out that Interest::getLink and Interest::getSelectedDelegation can throw exceptions if the Interest packet is malformed, although the @throw declaration of these functions indicates that they can throw only if the field is missing.

I think the solution is:

1. Add the missing condition to Interest::getLink and Interest::getSelectedDelegation as a @throw declaration.
2. Ensure the entire Interest is well-formed, before entering any forwarding pipelines.
3. To avoid the overhead of parsing Link multiple times when Interest::getLink is called multiple times, a unique_ptr<Link> field should be stored within Interest class.

In item 2, it's important that the packet format validation is completed before entering any forwarding pipelines, because forwarding shouldn't process a malformed packet at all.
Partially processing a packet, only to find it malformed later and drop it later in the pipeline, is not only expensive (eg. ContentStore lookup), but also complex (eg. how to undo the PIT entry? violates NFD design goal "simplicity").

The short-term solution is: in Forwarder::onInterest function, call Interest::getLink and Interest::getSelectedDelegation after checking the field exists.

The long-term solution is: in Interest::wireDecode and Data::wireDecode, introduce a "deep parsing" mode which parses every sub-element and ensures they are correct; NFD face system should use "deep parsing" mode.

At 20150827 conference call, Alex didn't disagree with note-15 solution, but also offered with an alternate solution:

A malformed Link can be ignored (as if it doesn't exist) during packet processing.

I disagree with this alternate solution.

A malformed packet indicates that the sender has violated the protocol.
Attempting to serve such packets wastes network resources, and may cause security concerns.

Note that this discussion is only about a field that is recognized but malformed.
Unrecognized fields are out of scope.

20150901 conference call approves note-15 solution.

We also decide to change the return type of Interest::getLink to const Link& which references the Link object in unique_ptr.

What is the status for NetworkRegionTable management (do we have an issue for that)?