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
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
