RE: 2nd WG Last Call for draft-ietf-gsmp-dyn-part-reqs

> 1.  I don't understand the rationale for this limitation
> of PMs and SEs (from the Introduction section):
> 
> "There is a one-to-many relationship between PMs and SEs."

PM is a logical entity.  We decided that _logically_ a single
PM would be responsible for a SE.  To say that multiple logical 
PMs could configure a SE would imply the need for some sort of
policy enforcement between them on the SE.  To avoid this, we
say that a single logical PM controls the SE and this logical
entity may be coresident with other PMs on the same physical
management station or in a very strange and rare case spread
across multiple physical management stations.  However, I don't
expect that this latter case would ever happen.
 
> ...Especially in light of the many-to-many relationships
> between PMs and Controllers and Controllers and Partitions.

These many-to-many relationships are derived naturally from
the ability to partition a SE and have each partition be
controlled by a different controller.

> ...And additionally in light of the following two statements
> referring to multiple PM considerations (from Intro and
> Security, respectively):
> 
> "Likewise, there may be multiple partition managers
> running on a single management workstation."

This is just describing a likely physical manifestation
of the logical entitites.  We try to talk about logical
entities because we don't want to limit what pieces can
be combined with what other pieces.  However, we do know
what the likely physical manifestation will be so we list
that just as an aid in understanding.
 
> "Only authorized PMs MUST be allowed to dynamically
> repartition a SE."
> 
> 2.  How is the "one-to-many" PM to SE relationship
> enforced in the protocol?

The SE will only accept commands from an authorized logical
PM.  It is up to the designers of the protocols how to provide
the necessary information for the SE to make this determination.

> 3.  The Security Considerations section is actually quite
> good in the sense of identifying some important protocol
> issues (which is something you don't always see).  However,
> that very quality raises the question of why aren't these
> issues dealt with in the protocol prior to going to Last
> Call?  I don't mean to be harsh here...it's outstanding
> that the issues have been identified and documented here...
> but then why not deal with them?  Or, can it be explained
> that they (some/all) must be resolved outside the protocol
> itself?  Again, I apologize if my ignorance of past WG
> discussions is a factor here.

This document defines requirements for the 6 interactions
between the logical entities, PM <=> SE, partition<=> controller,
PM <=> controller.  As such, this document defines requirements
on protocols but does not itself define a protocol.  We are
simply stating the issues that must be addressed by the protocols.

> 3.  I suggest adding a definition for "Partition Manager"
> to the otherwise very helpful list of defined terms already
> included.

Partition manager is defined in the 2nd paragraph of the
introduction section.  I can copy that text to the definitions
section if the group thinks this would be worthwhile.

Todd