Subject: [GSMP] 2nd WG Last Call for draft-ietf-gsmp-dyn-part-reqs

From: avri <[email-masked]>
Date: Fri, 06 Dec 2002 10:46:34 +0100

As discussed previously on this list and in the WG meeting in Atlanta,
Requirements for the Dynamic Partitioning of Switching Elements,
draft-ietf-gsmp-dyn-part-reqs-03.txt
is ready to go through a second WG last call.

This last call is scheduled to end 20 Dec.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-gsmp-dyn-part-reqs-03.txt

Please send comments to the list.

Thanks
a.
-- 
Avri Doria
http://www.sm.luth.se/~avri/

_______________________________________________
GSMP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gsmp

---

From: "Natale, Robert C (Bob)" <[email-masked]>
Date: Fri, 6 Dec 2002 12:56:18 -0500

Hi,

I apologize if the questions/comments herein reflect
ignorance of preceding WG discussions...I decided to
take a look at the draft at this last call stage....

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."

...Especially in light of the many-to-many relationships
between PMs and Controllers and Controllers and Partitions.

...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."

"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?

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.

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

Cheers,

BobN
- - - - -
> -----Original Message-----
> From: avri [mailto:[email-masked]]
> Sent: Friday, December 06, 2002 4:47 AM
> To: [email-masked]
> Subject: [GSMP] 2nd WG Last Call for draft-ietf-gsmp-dyn-part-reqs
> 
> 
> 

Thanks
a.

---

From: "Anderson, Todd A" <[email-masked]>
Date: Fri, 6 Dec 2002 14:37:44 -0800

> "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.
 
> 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.

> 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.
 
> 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.

> 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.

> to the otherwise very helpful list of defined terms already

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