RE: [GSMP] RE: [Fwd: IESG comments on draft-ietf-gsmp-dyn-part-re qs]

["Anderson, Todd A" <[e-mail]>]

A new revision is attached.  I will submit the new revision
to InternetDrafts once my questions about microsoftisms is
resolved.  See below for my responses to responses.

Todd

> >> >   o Requirements for the Dynamic Partitioning of 
> Switching Elements 
> >> >     (Informational)   
> >> >           <draft-ietf-gsmp-dyn-part-reqs-02.txt>
> >> >
> >> >are SEs only layer 2, or can a virtual router be an SE?
> > 
> > Originally I think there was some "router" verbage in this 
> draft with
> > the idea that this draft be inclusive of partitioning both 
> switches and
> > routers.  I think the requirements in this draft are 
> equally valid for
> > LPM forwarding controlled by a protocol such as ForCES.  
> However, there
> > may be requirements for forwarding devices that are not 
> listed in this
> > draft since they weren't necessary for the task at hand, namely
> > partitioning of switches for GSMP.  At some point, groups 
> like ForCES
> > and PPVPN should take a look at this draft/RFC and propose 
> any changes 
> > they feel are necessary to support LPM-based forwarding devices.
> 
> Perhaps a statement similar to this should be should be put in the 
> beginning of the document somewhere.

I added a statement to this effect in the first introductory paragraph.

> > Most likely, the only effected requirement will be 
> requirement #3 which
> > states that the partitioning protocol be able to partition resources
> > used by GSMP switches.  There are other resources commonly found on
> > media gateways and in routers that wouldn't be included in this 
> > requirement.
> 
> Is there any value in generalizing the requirement a little?  
> One thing 
> that concerns me is that should we decide to suggest GSMP as 
> a solution 
> to ForCES, something I am thinking about, it would require 
> additions to 
> these requirements.  Now, while we cannot require those yet, 
> it might be 
> reasonable to add a requirement that all future additions to the 
> protocol will need to include support for their particular 
> partitioning 
> requirements.

Just my own opinion but I don't think GSMP has much hope of satisfying
the ForCES requirements as currently listed.  In either case, if somebody
wants to partition a router they can just either suggest changes to the
mechanisms that are created for switch partitioning or define requirements
for those changes first.  I don't think it is necessary to make requirements
about how future partitioning endeavors should relate to this draft.

> >> >microsoftisms in the text
> > 
> > Egad, I've been brainwashed!  Tell me what they are and I will 
> > remove them.
> 
> I think I found 4 instances:
> partition's twice on page 2
> controller's on page 4
> PM's on page 5

I'm still confused becasue "partition", "controller" and "PM" occur much
more than twice, once, and once respectively on those pages.  Which
specific references in the new document need to be changed.  Anybody want
to highlight what they think needs to be changed?

> BTW while we are being typographical  there are also references to 
> [GSMPv3]  that should be changed to [RFC3292]

Fixed.

> >> >in intro para 2, the enumeration omits the case where a single
> >> >logical SE or controller might be implemented by multiple devices
> > 
> > The picture on page 4 indicates that multiple logical 
> controllers can
> > be attached to a single partition.  You could call this combination
> > of controllers itself a logical controller if you wanted 
> to. Likewise, 
> > a logical SE could be something like the combination of two 
> partitions 
> > of two different physical SEs.
> > 
> > I have no objection to adding such examples to the draft.  
> However, I 
> > think the draft as it is does not preclude someone from 
> doing either 
> > of the aforementioned aproaches.
> 
> I think that adding some of the more extreme examples is a good idea.

I added these examples.

> > Requirement #3 allows starvation?  If so, how?  I'm not seeing it.
> 
> I don't think this one does, but Req. 4 does.
> Though I think this is covered by the requirements for authentication 
> etc. ot eh PM.  but it might be worth mentioning in the 
> security section 
> that this is a possible problem that the authentication is 
> meant to cover.

Without requirement #8, requirement #4 could result in starvation even
in the presence of the required authentication.  It is required #8 that
addresses the starvation issue directly and I have added text in the
draft referencing those requirements from each other and saying
explicitly that requirement #8 addresses the potential starvation issue.

> >> >sec cons says
> >> >
> >> >   Only authorized PMs MUST be allowed to dynamically 
> repartition a
> >> >   SE
> >> >
> >> >etc.  but there is no hint of security relationships.  are SEs
> >> >statically bound to PMs and vice verse?
> > 
> > This issue was never specifically discussed but based on our
> > discussions I infer that we believed that the relationship could be
> > dynamic and configurable based on the preferences of the owner of
> > the resources.  The SE could be configured to know its PM through
> > a console (physical security) or via an existing, secure 
> configuration
> > protocol...take your pick.
> > 
> > There might be a potential requirement here when a SE is assigned to
> > a knew PM...does the SE forget all of its state or maintain 
> its state?
> > If it maintains the state then how is the new PM to discover how the
> > device is currently partitioned?
> > 
> 
> While we don't necessarily need to solve this now, it might 
> be good to 
> explore the problem and to add a requirement on the need to 
> establish a 
> secure process for PM discovery and binding.

I tried to add appropriate text to the security considerations section.

> To the editors:  How soon can we get a revision.

Poof!