Subject: FW: I-D ACTION:draft-ietf-forces-model-02.txt

From: "Putzolu, David" <[email-masked]>
Date: Fri, 12 Mar 2004 09:03:58 -0800

Bounced due to new email address, forwarding to list: 

-----Original Message-----
From: Steven Blake [mailto:[email-masked]] 
Sent: Thursday, March 11, 2004 4:48 PM
To: Cain, Gamil
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-forces-model-02.txt

On Fri, 2004-02-27 at 12:10, Cain, Gamil wrote:

Hi Gamil; sorry for the delay responding.  I'm only responding to
some of your comments. 

> Lily et all,
> 
> Here's my feedback on the latest FE model:
>
> -  Section 2.4, first sentence is a bit confusing and should probably
> be broken into two sentences.

Ok.

> - Section 3.2.3, the first paragraph mentions "frame type".  I would
> suggest staying consistent with terms.  Either use "frame type" or
> "packet type" but not both.

Agreed.

> - Last paragraph before section 3.2.4.3, is this "harmonization" out 
> of scope for ForCES?  Does ForCES assume this is something that will
> be taken up by some external organization (i.e. NPF)?

No.  This harmonization refers to how the LFB classes will be defined
within ForCES.  Two LFB classes that might have a producer-consumer
relationship should be specified such that their metadata tags are
consistent.  Of course, it is hoped that other relevant organizations
(i.e., NPF) will also harmonize as appropriate with the LFB class specs.

[snip]

> Section 4.7.3:  Does the LFB class need to also specify what metadata
it
> passes through?  I would think not, but it might be good to add a
> paragraph describing the LFB classes behavior wrt pass-through
metadata.

Agreed.

> Section 4.7.5:  Is there (or should there be) a requirement for an
> instance of an LFB class to specify capabilities for all attributes it
> supports?  If not, should there at least be some guidance in this
> document that describes what types of capability information should be
> exposed?

Agreed.

> Section 6.1:  What is meant by the static attribute "port type"?
> Examples would be helpful.

When writing this I was undecided about whether there should be a single
LFB port class, where each port instance has a type (technology)
attribute (e.g., Ethernet, SONET/SDH, etc.) vs. a set of technology
specific sub-classes.  I have decided on the latter and will clean this
up in the next revision.

> Section 6.1:  In some devices, the physical port link speed is a
> configurable, as opposed to static, attribute (e.g. a framer that can
do
> DS3 and OC-3 or OC-12).  How would one go about modeling such a
device,
> using the current Port LFB class definition?  Or would you not model
> such a device as a single LFB, but rather as multiple LFBs that can be
> enabled/disabled (e.g. a DS3 Port LFB, a OC-3 Port LFB, etc. all
> managing the same physical device)?

No, any device whose port speeds can be dynamically reconfigured should
be modeled as a single LFB, with a configurable speed attribute.  An
exception to this might be something like a framer that could support
either Ethernet or SONET (is there such a beast?), since the interesting
attributes of the different technologies differ so much.  If such a
device could be reconfigured on-the-fly, I suppose that would be a case
that would need to be covered by modification of the LFB topology.

[snip]

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                +1 919-472-991

You wouldn't be seeing the following text if my employer
didn't block ports 25 and 110.

This communication is confidential and intended solely for the
addressee(s). Any unauthorized review, use, disclosure or distribution
is prohibited. If you believe this message has been sent to you in
error, please notify the sender by replying to this transmission and
delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption,
interruption, unauthorized amendment, tampering and viruses, and we only
send and receive e-mails on the basis that we are not liable for any
such corruption, interception, amendment, tampering or viruses or any
consequences thereof.