miscellaneous comments was Re: Model draft

"tom.petch" <cfinss@dial.pipex.com> Fri, 04 January 2008 13:35 UTC

Message-Id: <FRI.4.JAN.2008.143515.0100.>
Date: Fri, 4 Jan 2008 14:35:15 +0100
From: "tom.petch" <cfinss@dial.pipex.com>
Subject: miscellaneous comments was Re: Model draft
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Some comments, prefixed with **+, that do not relate to terminology:-)


3.2.   Logical Functional Block (LFB) Modeling
   An LFB can have one or more inputs, each of which takes a packet P,
   and optionally metadata M; and produces one or more outputs, each of
   which carries a packet P', and optionally metadata M'.

**+ I think that this is too restrictive; s3 says that output may be metadata
only.


4.2.  <LFBLibrary> Element
   In addition to the above main elements, a library document can import

**+ is this an XML import or XML include or both or neither? (this has
implications on namespaces)


4.5.4.  <struct> Element to Define Structures
   In
   addition, the component declaration contains the name of the
   component, a synopsis, an optional description,

**+ I see no <description> in the XML for <component> in <structType> but one is
present in <LFBComponentsType> ; is this intended?


4.5.6.  <alias> Element
   The target of a component declared by an >alias> element is
**+ <alias>


    Details of the alias property structure are described in the section
   of this document on properties.
**+ suggest making that explicit ie section 4.8


4.7.3.  <outputPorts> Element to Define LFB Outputs
   This is indicated by a "yes" value
   (the default value is "no").

**+ The XML has default of 0 - I see no indication which is yes and which no;
some XML users define a truthValue, of yes or no.


4.7.4.   <components> Element to Define LFB Operational Components
   The <component> element also MUST have an componentID attribute,
   which is a numeric value used by the ForCES protocol.

**+ The XML allows this to be a negative integer; is this intended?? ditto
eventid


   4.7.6.1.  <eventTarget> Element
**+ must <eventTarget> reside in the same LFBClass definition as the event
definition??


 **+/componet/component/ in the LFB.


            <dataTypeDef>
              <name>eventElementProperties</name>
              <struct>
                  <typeRef>uint32</typeRef>
**+ curious why registration of an event is not boolean??


                  <name>threshold</name>
                  </optional
                  <typeRef>uint32</typeRef>
**+ again curious why uint32 as it excludes a negative threshold??



4.8.5.2.   Event Hysteresis Filtering
      again until the field first becomes less than or equal to T - -V,
**+ /T - V/ ??



4.8.6.  Alias Properties
          <dataTypeDef>
            <name>aliasElementProperties</name>
                <synopsis>
                  the path to the component target
                  each 4 octets is read as one path element,
                  using the path construction in the PL protocol.

**+ suggest adding a ref to the protocol RFC


5.  FE Components and Capabilities
   Only one instance of
   this class will ever be present, and the instance ID of that instance

**+ suggest adding 'in an FE'


   Details of that class are defined in the ForCES protocol
   document.
**+ suggest adding a reference to the protocol RFC


5.1.   XML for FEObject Class definition
                  <component access="read-only" componentID="7">
                    <name>FEState</name>
                    <synopsis>model of this FE</synopsis>
**+ this synopsis does not look relevant for FEState


5.3.1.  FEStatus
**+ the element is <FEState> not FEStatus but the type is FEStatusValues - mmmm


7.5.  State Query of LFB Attributes
      This is primarily to refer to a single
      FE, but referring to a group of (or all) FEs may
**+ suggest /optional/optionally/ be supported.


8.  Example LFB Definition
   While some
   properties of LFBs are shown by the FE Object LFB, this endeavors to
   show how a data
**+/plain/plane/??


            <dataTypeDef>
              <name>PortStatusValues</name>
              <synopsis>
                  The possible values of status.  Used for both
                  administrative and
**+ suggest /operation/operational/ status

                  <specialValue value="1">
                    <name>Enable</name>
**+Enabled?? Enable is used in 8.1.1 but seems odd in contrast to Disabled

                    <synopsis>FE is operatively disabled</synopsis>
**+ /disabled/enabled/  ??


8.1.  Data Handling
   the LFB **+/too/to/ look up


8.4.  Events
   If a laser oscillates in power near the 15 mark, one could get a lot
   of notifications.  (If it flips back and forth between 9 and 10, each
   flip down will generate an event.)

**+why should oscillation between 9 and 10 generate any events? around 15 yes,
but I do not see the relevance of 10 and 9

Tom Petch

----- Original Message -----
From: "Joel M. Halpern" <joel@stevecrocker.com>
Sent: Sunday, October 07, 2007 11:27 PM
Subject: Model draft


> A revision of the model draft has been submitted to the repository,
> and has been accepted by it.
> Draft -08 repairs the confusion of XML terminology with ForCES
> components, and cleans up a number of other minor terminology items I
> found while doing that.
>
> Further review is likely needed.  Please read and comment.
>
> I have not changed the FE Status information, as I could not
> determine if there was a working group consensus for change, or what
> it would become if I was to change it.
>
> Yours,
> Joel M. Halpern