Slight change in FPC draft terminology and related re-organization of some introductory concepts

Hello folks,

Looking at the FPC draft 10, it has the following organization in section 4:

Version 10:

4    FPC Mobility Information Model
4.1    Model Notation and Conventions
4.2    Core Structure - Information Model Components
4.3    Topology
4.3.1    DPN
4.3.2    DPN-Type
4.3.3    DPN-Group
4.3.4    Domain
4.4    Policy
4.5    Configurable Policy
4.6    Mobility-Context
4.7    Monitors
4.8    Namespace and Format
4.9    Attribute Application

I'd like to reorganize this somewhat, while keeping most of the same 
kind of content with modifications according to recent discussion. Here 
is a proposed new organization.  Below the proposed reorganization of 
the sections, I have some comments that will, I hope, be agreeable.

  4    FPC Mobility Information Model
4.1    Model Notation and Conventions
4.2    Namespace and Format
4.3    Attribute Application
4.4    Information Model Components
4.4.1        Domain
4.4.2        Configurable Policy
4.4.3        DPN-Type
4.4.4        Interface
4.4.5        Interface-Group
4.5    Topology Information Model
4.6    DPN Information Model
4.7    Policy Information Model
4.8    Mobility-Context Information Model
4.9    Monitor Information Model

For this reorganization, the major concepts are Topology, DPN, Policy, 
Mobility-Context, and Monitor.  I have promoted each of these major 
concepts to have its own subsection of the FPC Information Model section.

I am proposing a change in the implied meaning of "Component".  In the 
new text, I would use "component" to mean a small-ish building block 
that is used in the major concepts of FPC.  They are secondary in nature 
(compared to the major concepts).  I think that the "Interface" 
component deserves its own small section, and then "Interface-Group" 
[was, DPN-Group] could use that in a natural fashion.

If Interface-Group seems "unlike" the other components, we could 
describe it as an "assembly".  On the other hand, just because something 
is described as a "component" doesn't mean it is unimportant.  For 
instance, "domain" is very important, but in the information model it 
looks like a component of the definition of a Topology.

The Namespace subsection seems to belong nearer the start before getting 
into the technical description of the Components and major sections.  A 
lot of the complication in this document is related to difficulty of 
describing abstract concepts, and naming is crucial to clarify and 
reduce the complications.  So namespace takes some priority.  I have 
more discussion about this later, but for now this is enough to justify 
moving that subsection closer to the front of section 4.

Finally, the method of applying Settings to complete the Attribute 
values of an Information Model object should be described more generally 
and then specialized to Embedded Rules and so forth.  I don't have good 
text for that yet [TBD!!], but it seems important also for the way we 
use Descriptors and Actions in the Policy Information Model.

Regards,
Charlie P.

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm