2007
Message-Id: <WED.24.JAN.2007.090254.0500.>
Date: Wed, 24 Jan 2007 09:02:54 -0500
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: [Model] 4.5.6 <alias> Element
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

That text probably does need cleaned up in that
regard.(SET/GET-Property vs SET/GET).

Yours,
Joel

At 08:55 AM 1/24/2007, Jamal Hadi Salim wrote:
>Actually now that i think about it, the text needs to be talking about
>setting/getting the properties of the alias (which changes the target)
>vs setting/getting the value of the alias. The former (which i referred
>to as #i) is achieved via S/GET-PROPERTY and the later via S/GET (as in
>#ii example).
>
>Thoughts?
>
>cheers,
>jamal



2007
Message-Id: <WED.24.JAN.2007.085558.0500.>
Date: Wed, 24 Jan 2007 08:55:58 -0500
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: [Model] 4.5.6 <alias> Element
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Actually now that i think about it, the text needs to be talking about
setting/getting the properties of the alias (which changes the target)
vs setting/getting the value of the alias. The former (which i referred
to as #i) is achieved via S/GET-PROPERTY and the later via S/GET (as in
#ii example).

Thoughts?

cheers,
jamal

On Tue, 2007-23-01 at 17:59 -0500, Joel M. Halpern wrote:
> Set and Get via Alias are supported so as to allow one to set / get
> the entire structure.
> Also, while the LFB structures defines the primary location of the
> information, it is entirely up to the CE (or the programmer of the
> CE) what path is used to set / get information.  I can easily imagine
> implementation techniques where it simplifies life to access the
> values through the alias.  (The simplest example is an LFB instance
> browser with set/get capability.)
>
> Mostly, I didn't think it was the model's job to control how the
> values were manipulated.  And there is no conflict, given that all
> the LFBs of an FE are under the control of a single CE.  Yes, I can
> imagine questions arising if we support split control.  But so many
> other issues arise that I see no point in planning for that.
>
> Yours,
> Joel
>
> At 11:05 AM 1/23/2007, Jamal Hadi Salim wrote:
>
> >- I think this section would benefit from an example right at this
> >point. It also makes it consistent since the other 4.5.x sections mostly
> >have  examples.
> >
> >- The text may be a little confusing.
> >Lets say i have an LFBx which uses an alias ifindex. Say the real
> >location (target) is in some portLFB:instanceI:a.b.c.d and the value at
> >that location is 0x12. Then:
> >On LFBx (given i have write permission)
> >i) I can change the target to be new path say portLFB:instanceJ:a.b.c.e
> >ii)I can SET the value of a.b.c.e (if i have write permissions)
> >
> >It almost seems to me you should never have the need for #ii (we have
> >been using aliases and have had no need to so far) and that you should
> >occasionally need to to do #i (for reasons i wont go into we  do it more
> >than occasionally).
> >
> >The text talks about #ii but not about #i.
> >
> >cheers,
> >jamal


2007
Message-Id: <WED.24.JAN.2007.084437.0500.>
Date: Wed, 24 Jan 2007 08:44:37 -0500
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: [Model] Section 4.5.3
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Tue, 2007-23-01 at 17:53 -0500, Joel M. Halpern wrote:

> These pieces of information are provided in the class definition, as
> XML attributes on the "arry" XML element.
> The only exception is the implementation specific maximum size, which
> is now a property rather than a capability attribute.
>

Ok, so something needs tracking there. I will open a tracker ticket.

cheers,
jamal


2007
Message-Id: <TUE.23.JAN.2007.175922.0500.>
Date: Tue, 23 Jan 2007 17:59:22 -0500
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: [Model] 4.5.6 <alias> Element
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Set and Get via Alias are supported so as to allow one to set / get
the entire structure.
Also, while the LFB structures defines the primary location of the
information, it is entirely up to the CE (or the programmer of the
CE) what path is used to set / get information.  I can easily imagine
implementation techniques where it simplifies life to access the
values through the alias.  (The simplest example is an LFB instance
browser with set/get capability.)

Mostly, I didn't think it was the model's job to control how the
values were manipulated.  And there is no conflict, given that all
the LFBs of an FE are under the control of a single CE.  Yes, I can
imagine questions arising if we support split control.  But so many
other issues arise that I see no point in planning for that.

Yours,
Joel

At 11:05 AM 1/23/2007, Jamal Hadi Salim wrote:

>- I think this section would benefit from an example right at this
>point. It also makes it consistent since the other 4.5.x sections mostly
>have  examples.
>
>- The text may be a little confusing.
>Lets say i have an LFBx which uses an alias ifindex. Say the real
>location (target) is in some portLFB:instanceI:a.b.c.d and the value at
>that location is 0x12. Then:
>On LFBx (given i have write permission)
>i) I can change the target to be new path say portLFB:instanceJ:a.b.c.e
>ii)I can SET the value of a.b.c.e (if i have write permissions)
>
>It almost seems to me you should never have the need for #ii (we have
>been using aliases and have had no need to so far) and that you should
>occasionally need to to do #i (for reasons i wont go into we  do it more
>than occasionally).
>
>The text talks about #ii but not about #i.
>
>cheers,
>jamal


2007
Message-Id: <TUE.23.JAN.2007.175313.0500.>
Date: Tue, 23 Jan 2007 17:53:13 -0500
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: [Model] Section 4.5.3
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Actually, the example you quote is one wehre we actually were using
the XML terrminology correctly and appropriately.

At 10:40 AM 1/23/2007, Jamal Hadi Salim wrote:
>- Everything that reads "attribute" in this section implies "property";
>so that lingering lingo issue is still distracting.
>[Example:
>"The array can be "fixed-size" or "variable-size", which is specified
>  by the "type" attribute of the <array> element. The default is
>  "variable-size".  For variable size arrays, an optional "max-length"
>  attribute specifies the maximum allowed length. This attribute
>  should be used to encode semantic limitations, not implementation
>  limitations. The latter should be handled by capability attributes .."
>]

These pieces of information are provided in the class definition, as
XML attributes on the "arry" XML element.
The only exception is the implementation specific maximum size, which
is now a property rather than a capability attribute.

Yours,
Joel


2007
Message-Id: <TUE.23.JAN.2007.110554.0500.>
Date: Tue, 23 Jan 2007 11:05:54 -0500
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: [Model] 4.5.6 <alias> Element
Comments: cc: Ellen M <ellen.m.deleganes@intel.com>, "Joel M. Halpern" <joel@stevecrocker.com>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

- I think this section would benefit from an example right at this
point. It also makes it consistent since the other 4.5.x sections mostly
have  examples.

- The text may be a little confusing.
Lets say i have an LFBx which uses an alias ifindex. Say the real
location (target) is in some portLFB:instanceI:a.b.c.d and the value at
that location is 0x12. Then:
On LFBx (given i have write permission)
i) I can change the target to be new path say portLFB:instanceJ:a.b.c.e
ii)I can SET the value of a.b.c.e (if i have write permissions)

It almost seems to me you should never have the need for #ii (we have
been using aliases and have had no need to so far) and that you should
occasionally need to to do #i (for reasons i wont go into we  do it more
than occasionally).

The text talks about #ii but not about #i.

cheers,
jamal


2007
Message-Id: <TUE.23.JAN.2007.104517.0500.>
Date: Tue, 23 Jan 2007 10:45:17 -0500
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: [model] Section 4.5.6
Comments: cc: "Joel M. Halpern" <joel@stevecrocker.com>, Ellen M <ellen.m.deleganes@intel.com>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

The heading 4.5.6 is repeated twice; first under "<alias> element" then
with title "Augmentations"

I didnt think there was need for discussion so i opened it as tracker
#108.


cheers,
jamal

PS:- If you use xml this wouldnt occur.


2007
Message-Id: <TUE.23.JAN.2007.104031.0500.>
Date: Tue, 23 Jan 2007 10:40:31 -0500
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: [Model] Section 4.5.3
Comments: cc: Ellen M <ellen.m.deleganes@intel.com>, "Joel M. Halpern" <joel@stevecrocker.com>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Continuing where i left off ...

- Glad to see you can have multiple keys as well as index at the same
time. I had totally forgotten where that long discussion ended.

- Everything that reads "attribute" in this section implies "property";
so that lingering lingo issue is still distracting.
[Example:
"The array can be "fixed-size" or "variable-size", which is specified
 by the "type" attribute of the <array> element. The default is
 "variable-size".  For variable size arrays, an optional "max-length"
 attribute specifies the maximum allowed length. This attribute
 should be used to encode semantic limitations, not implementation
 limitations. The latter should be handled by capability attributes .."
]

- readability/flow
a) The paragraph that goes:
 " Each key is declared with a keyID for use in the protocol,"

and
b) the example on ipPrefixInfo_table

Should really be in section 4.5.3.1

BTW, that example uses ipv4Prefix reference which is given as an example
in 4.5.4. It would be useful to point to that example.

I would like to enter this in the tracker unless there is disagreement.
If i dont hear any disagreements, it will go in the tracker.

cheers,
jamal


2007
Message-Id: <MON.22.JAN.2007.174638.0800.>
Date: Mon, 22 Jan 2007 17:46:38 +0800
From: Michael <mahuaiyuan@huawei.com>
Subject: draft-halpern-forces-lfblibrary-vpn--00.txt
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_hQqR7l4T3Ka0Ex9NjrXR6g)"

This is a multi-part message in MIME format.

--Boundary_(ID_hQqR7l4T3Ka0Ex9NjrXR6g)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_9gxGxTxQPf6kTUgIUd1lOw)"


--Boundary_(ID_9gxGxTxQPf6kTUgIUd1lOw)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi, All:

A new I-D draft named "draft-halpern-forces-lfblibrary-vpn--00.txt" () has been submitted, the draft supposes a solution to VPN in ForCES architecture. At the first step, a GRE tunnel & its configuration policies LFB definition has been given, please give some comments.

Best,

Michael



--Boundary_(ID_9gxGxTxQPf6kTUgIUd1lOw)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2900.3020" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>
<DIV><FONT size=2>Hi, All:</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>A&nbsp;new I-D draft named
"draft-halpern-forces-lfblibrary-vpn--00.txt" ()&nbsp;has been submitted, the
draft supposes a solution to VPN in ForCES architecture.&nbsp;At the first step,
a GRE tunnel &amp; its configuration&nbsp;policies LFB definition&nbsp;has been
given, please give some comments.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Best,</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Michael</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></FONT></DIV></BODY></HTML>

--Boundary_(ID_9gxGxTxQPf6kTUgIUd1lOw)--

--Boundary_(ID_hQqR7l4T3Ka0Ex9NjrXR6g)
Content-type: text/plain; name=draft-halpern-forces-lfblibrary-vpn--00.txt
Content-transfer-encoding: 7BIT
Content-disposition: attachment;
 filename=draft-halpern-forces-lfblibrary-vpn--00.txt

Network Working Group
Internet Draft                                                 J.Halpern
Expires: July 2007                                                  Self
                                                             Huaiyuan Ma
                                            Huawei Technologies Co., Ltd
                                                        January 16, 2007

          A VPN Library for use with the ForCES Protocol and Model
                  draft-halpern-forces-lfblibrary-vpn--00




Status of this Memo

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79.



   This document may only be posted in an Internet-Draft.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html

   This Internet-Draft will expire on July 16, 2007.

Abstract

   The forwarding and Control Element Separation (ForCES) protocol
   defines a standard communication and control mechanism through which
   a Control Element (CE) can control the behavior of a Forwarding
   Element (FE). That control is accomplished through manipulating



Halpern,Ma              Expires July 16, 2007                 [Page 1]
.
Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt  January 2007


   attributes of Logical Function Blocks (LFBs), whose structure is
   defined in a model RFC produced by the working group. In order to
   build an actual solution based on this protocol, defining a set of
   Logical Function Block definitions that can be instantiated by FEs
   and controlled by CEs is welcome. A base library definition of LFBs
   is already given in library [5]. VPN (Virtual Private Network)
   services, as a kind of important services widely employed in Internet,
   will certainly be implemented in routers using this protocol. This
   document provides an initial set of VPN LFB definitions  in
   particular, a set of tunnel encapsulator and decapsulator LFBs. It is
   anticipated that additional VPN-related LFB definitions like L2VPN,
   L3VPN can be defined over time.





Conventions used in this document



   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119.



Table of Contents


   1. Introduction................................................3
   2. Tunnel Definitions..........................................3
      2.1. GRE Tunnel Definitions.................................3
   3. Security Considerations.....................................11
   4. Acknowledgments.............................................11
   5. References..................................................11
      5.1. Normative References...................................11
      5.2. Informative References.................................12
   Author's Addresses.............................................12
   Intellectual Property Statement................................12
   Disclaimer of Validity.........................................13
   Copyright Statement............................................13
   Acknowledgment.................................................13






Halpern,Ma              Expires July 16, 2007                 [Page 2]
.
Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt  January 2007


1. Introduction

   In a solution using ForCES protocol, Control Elements (CEs) can
   control the behavior of Forwarding Elements (FEs) through
   manipulating attributes of Logical Function Blocks (LFBs). LFB's
   structure and abstract semantics is defined in Model [6]. That
   document also defines a single LFB Class for gaining access to FE
   properties including the set of LFBs and their interconnection. A LFB
   class is defined to manipulate the protocol properties of the FE in
   the protocol [4].

   In I-D draft [5], a set of LFBs which are necessary to implement
   basic forwarding process are defined. This draft is intended to
   define an initial set of LFBs for a kind of important Internet
   service, Virtual Private Network (VPN). It is expected that other
   VPN-related definitions will be developed over time.





2. Tunnel Definitions

2.1.  GRE Tunnel Definitions

   GRE tunnel specification and its extension are described in RFC 2784
   and RFC 2890 respectively. A GRE tunnel is composed of three parts:
   outer delivery header, followed by a GRE header which is followed by
   a payload packet. The format of outer delivery header is determined
   by the corresponding delivery protocol, IPv4 or IPv6. In GRE header,
   there are two important optional fields: one is called GRE key which
   is intended to be used for identifying an individual traffic flow
   within a tunnel; the other is called Sequence Number, the Sequence
   Number MUST be used by the receiver to establish the order in which
   packets have been transmitted from the encapsulator to the receiver.
   The intended use of the Sequence Field is to provide unreliable but
   in-order delivery. The payload packet would be IPv4, IPv6 etc.



   When forwarding an IP packet in a next-hop applicator LFB, the
   matched FIB entry indicates the packet should be transmitted over a
   GRE tunnel and a correct tunnel index can be found out in the FIB
   entry.   The original packet will be fed to GRE tunnel encapsulator
   with tunnel index as meta-data together in the downstream forwarding
   process. Tunnel index points to the correct tunnel entry in tunnel
   configuration table which stores the information of each tunnel. Each


Halpern,Ma              Expires July 16, 2007                 [Page 3]
.
Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt  January 2007


   tunnel entry maintains a management flag called "TunnelState"
   indicating whether the current tunnel is administratively up.

   GRE tunnel maintains a fragmentation permitted flag. Before
   encapsulating a payload packet GRE tunnel encapsulator will check the
   size of that payload packet against MTU. If the size of tunnelled
   packet is larger than MTU and at this moment that fragmentation
   permitted flag should be checked, if that flag is set, then chop the
   original packet into small packets with appropriate size, otherwise,
   send ICMP message to notify the appropriate receiver of some error.
   If the delivery protocol is IPv4, then the format of outer delivery
   header would be IPv4, otherwise, it would be IPv6.



   Once a IP packet with GRE is produced from an output port from GRE
   tunnel encapsulator, a meta-data called "NextHopReference" which
   points to the index of correct FIB entry is accompanied at the same
   time, that is, an alias entry pointing to the next-hop table so that
   it can use the predetermined route to the tunnel end-point.



   When a classifier LFB identifies the incoming packet is an IP packet
   with GRE at the GRE tunnel exit point, it will feed that packet to
   the GRE tunnel decapsulator, which will find out the correct tunnel
   index which maintains a local VPN ID field, the GRE tunnel
   decapsulator then strips off the outer delivery header and GRE header
   and feed it to the forwarding-related LFB with local index ID as
   meta-data indicating which VPN that payload packet belongs to.



   The actual GRE tunnel LFB class is defined as below.

   <LFBLibrary provides="GRE_Tunnel_LFB">
     <load library="Base"/>
     <dataTypeDefs>
       <dataTypeDef>
       <name>NextHopIndex</name>
       <synopsis>
         An index used by the next hop table.
         Typically stored in and generated as metadata by
         the longest-prefix-match LFB
       </synopsis>
       <typeRef>int32</typeRef>


Halpern,Ma              Expires July 16, 2007                 [Page 4]
.
Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt  January 2007


       </dataTypeDef>
       <dataTypeDef>
         <name>VPNID</name>
         <synopsis>
             An ID used to provide context for
             VPN specific Packet processing.
         </synopsis>
         <typeRef>int32</typeRef>
       </dataTypeDef>
       <dataTypeDef>
         <name>GRETunnelTableType</name>
         <synopsis>
            GRE tunnel configuration table
            Each table entry describes a single GRE tunnel.
            The table Index is input meta-data for the encapsulator.
         </synopsis>
         <array type="variable-size">
         <struct>
           <element elementID="1">
             <name>TunnelValid</name>
             <synopsis>
                It is enabled or disabled by FIB indicating whether the current tunnel is permitted to
                be used in forwarding process.
             </synopsis>
             <typeRef>boolean</typeRef>
           </element>
           <element elementID="2">
             <name>FragmentationPermitted</name>
             <synopsis>
               it indicates whether it permits fragmentation when the size of a packet exceeds
               the tunnel's MTU.
             </synopsis>
             <typeRef>boolean</typeRef>
           </element>
           <element elementID="3">
             <name>ChecksumNeeded</name>
             <synopsis>
               it indicates whether a checksum is needed.
             </synopsis>
             <typeRef>boolean</typeRef>
           </element>
           <element elementID="4">


Halpern,Ma              Expires July 16, 2007                 [Page 5]
.
Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt  January 2007


             <name>PacketType</name>
                         ...needs definition ...
                  ... probably for decapsulator error checking? ...
           </element>
           <element elementID="5">
             <name>SrcAddr</name>
             <synopsis>
                IP Address for local end of tunnel
             </synopsis>
             <typeRef>IPAddress</typeRef>
           </element>
           <element elementID="6">
             <name>DstAddr</name>
             <synopsis>
                Address for remote End of Tunnel
             </synopsis>
             <typeRef>IPAddress</typeRef>
           </element>
           <element elementID="7">
             <name>GREKey</name>
             <synopsis>
                 Key for this specific GRE Tunnel
                 The presence of this element indicate this tunnel uses
                 keyed GRE format.
             </synopsis>
             <optional/>
             <typeRef>int32</typeRef>
           </element>
           <element elementID="8">
             <name>NextHopReference</name>
             <synopsis>
                Reference to the correct NextHopIndex
                This points to a LPM where the next hop is maintained.
                The information is put in the encapsulator meta-data.
             </synopsis>
             <alias>NextHopIndex</alias>
           </element>
           <element elementID="9">
             <name>MTU</name>
             <synopsis>
                  Maximum Transmit Unit Used in conjunction with the flags
                  to decide if large packets should be encapsulated, fragmented,
                  or errored.
             </synopsis>
             <typeRef>uint32</typeRef>
           </element>
           <element elementID="10">


Halpern,Ma              Expires July 16, 2007                 [Page 6]
.
Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt  January 2007


             <name>LocalVPNID</name>
             <synopsis>
                 VPN ID used by decapsulator as generated
                 meta-data
             </synopsis>
             <typeRef>VPNID</typeRef>
           </element>
        <element elementID="11">
             <name>TunnelState</name>
             <synopsis>
                 It indicates whether the current tunnel is administratively up or down.
             </synopsis>
             <typeRef>Boolean</typeRef>
           </element>
        <element elementID="12">
             <name>SequencingNeeded</name>
             <synopsis>
               it indicates whether a sequence field to differentiate different traffic flows in a
               tunnel is needed.
             </synopsis>
             <typeRef>boolean</typeRef>
        </element>
        <element elementID="13">
             <name>SequenceNumber</name>
             <synopsis>
               a sequence field to differentiate different traffic flows in a tunnel.
             </synopsis>
             <optional/>
             <typeRef>int32</typeRef>
        </element>
        <element elementID="14">
             <name>Checksum</name>
             <synopsis>
               The Checksum field contains the IP (one's complement) checksum sum of the all the 16 bit
               words in the GRE header and the payload packet.
             </synopsis>
             <optional/>
             <typeRef>int16</typeRef>
        </element>
        </struct>
        </array>
       </dataTypeDef>
     </dataTypeDefs>


Halpern,Ma              Expires July 16, 2007                 [Page 7]
.
Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt  January 2007


     <LFBClassDefs>
       <LFBClassDef LFBClassID="0x00010010">
         <name>GRE_Encapsulator</name>
         <synopsis>
           It specifies how to encapsulate an IP packet so that it can be transmitted over GRE tunnel.
         </synopsis>
         <version>0.0</version>
         <inputPorts>
           <inputPort>
             <name>PacketIn</name>
             <synopsis>
               Normal packet in.
             </synopsis>
             <expectation>
               <frameExpected>
                 <ref>IPv4</ref>
                 <ref>IPv6</ref>
               </frameExpected>
               <metadataExpected>
                 <ref>Tunnel_Index</ref>
               </metadataExpected>
             </expectation>
           </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort>
              <name>PacketOut</name>
              <synopsis>
                IP packet with GRE
              </synopsis>
              <product>
                <frameProduced>
                 <ref> GREFrame </ref>
                </frameProduced>
                <metadataProduced>
                  <ref>NextHopReference</ref>
                </metadataProduced>
              </product>
             </outputPort>
         <outputPort>
              <name>FailOutput</name>
              <synopsis>
                error prompt information to indicate whether some operations like fragmentation are


Halpern,Ma              Expires July 16, 2007                 [Page 8]
.
Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt  January 2007


            permitted.
              </synopsis>
              <product>
                <frameProduced>
                  <ref>taggedFrame</ref>
                </frameProduced>
                <metadataProduced>
                  <ref>errorid</ref>
                </metadataProduced>
              </product>
             </outputPort>
         </outputPorts>
         <attributes>
             <attribute access="read-write" elementID="1">
                 <name>GRETunnelTable</name>
                 <synopsis>
                     Table of GRE Tunnels supported by this
                     encapsulator
                 </synopsis>
             <typeRef>GRETunnelTableType</typeRef>
             </attribute>
         </attributes>
         <description>
           when fowarding a IP packet, a matching FIB entry has a GRE tunnel flag which indicates it
           should be transmitted over a GRE tunnel, then according to the constrains, TTL, MTU,
           fragmentation flag etc in the GRE tunnel entry to encapsulate a IP packet in its payload
           part.
         </description>
        </LFBClassDef>
        <LFBClassDef LFBClassID="0x00010011">
         <name>GRE_Decapsulator</name>
         <synopsis>
           It specifies the procedure how to decapsulate a tunnelled packet.
         </synopsis>
         <version>0.0</version>
         <inputPorts>
           <inputPort>
             <name>PacketIn</name>
             <synopsis>
               A IP packet with GRE.
             </synopsis>
             <expectation>



Halpern,Ma              Expires July 16, 2007                 [Page 9]
.
Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt  January 2007


               <frameExpected>
                 <ref>GREFrame</ref>
               </frameExpected>
             </expectation>
           </inputPort>
         </inputPorts>
         <outputPorts>
           <outputPort>
             <name>PacketOut</name>
             <synopsis>
               original packet output
             </synopsis>
             <product>
               <frameProduced>
                 <ref>IPv4</ref>
                 <ref>IPv6</ref>
               </frameProduced>
               <metadataProduced>
                  <ref>LocalVPNID</ref>
               </metadataProduced>
             </product>
           </outputPort>
           <outputPort>
              <name> FailOutput </name>
              <synopsis>
                 error prompt information generated when a GRE packet cannot match a GRE tunnel
                 state
              </synopsis>
              <product>
                <frameProduced>
                  <ref>taggedFrame</ref>
                </frameProduced>
                <metadataProduced>
                  <ref>errorid</ref>
                </metadataProduced>
              </product>
           </outputPort>
         </outputPorts>
         <attributes>
          <attribute access="read-write" elemendID="x">
          <name>GRETunnelTable</name>
          <synopsis>
               Reference to the GRE Tunnel Table this decapsulator uses


Halpern,Ma              Expires July 16, 2007                [Page 10]
.
Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt  January 2007


               which is stored in the corresponding encapsulator.
          </synopsis>
          <alias>GRETunelTableType</alias>
          </attribute>
         </attributes>
         <description>
           Once the classifier has determined the content of an incoming packet is GRE, it will be fed
           to a GRE decapsulator, which can achieve the local VPN ID to which the packet belongs and
           strip off the outer IP header and GRE shim, at the same time, treat local VPN ID as meta-
           data and then feed it and original packet to the down-stream LFBs.
         </description>
       </LFBClassDef>
     </LFBClassDefs>
   </LFBLibrary>




3. Security Considerations



   These definitions if used by an FE to support ForCES create
   manipulable entities on the FE, Manipulation of such objects can
   produce almost unlimited effects on the FE. FEs should ensure that
   only properly authenticated ForCES protocol participants are
   performing such manipulations. Thus, largely, the security issues
   with this protocol are defined in Protocol [2].



4. Acknowledgments

   Thanks Zengjie,Kou for providing some comments.

5. References

5.1. Normative References

   [1]  Khosravi, et al. Requirements for Separation of IP Control and Forwarding,
         RFC 3654, November 2003.

   [2]  L. Yang, et al. ForCES Architectural Framework, RFC 3746, April 2004.




Halpern,Ma              Expires July 16, 2007                [Page 11]
.
Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt  January 2007


   [3]  Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., and S. Blake,
         "ForCES Forwarding Element Model", Feb. 2005.

   [4]  A. Doria, et al. ForCES Protocol Specification, draft-ietf- forces-
         protocol-06.txt, December 2005.

   [5]   Joel M.Halpern, A base Library for use with the ForCES Protocol
         and Model, draft-halpern-forces-lfblibrary-base-01.txt, March,
         2006

   [6]   L.Yang, et al. ForCES Forwarding Element Model, draft-ietf-
         forces-model-06.txt

5.2. Informative References





Author's Addresses

   Joel M. Halpern
   Self
   P. O. Box 6049
   Leesburg, VA 20178
   US

   Huanyuan Ma
   Huawei Technologies Co., Ltd
   mahuaiyuan@huawei.com

   Zengjie Kou
   Huawei Technologies Co., Ltd
   kouzengjie@huawei.com




Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information



Halpern,Ma              Expires July 16, 2007                [Page 12]
.
Internet-Draft draft-halpern-forces-lfblibrary-vpn--00.txt  January 2007


   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.










Halpern,Ma              Expires July 16, 2007                [Page 13]
.

--Boundary_(ID_hQqR7l4T3Ka0Ex9NjrXR6g)--


2007
Message-Id: <MON.22.JAN.2007.174348.0800.>
Date: Mon, 22 Jan 2007 17:43:48 +0800
From: Michael <mahuaiyuan@huawei.com>
Subject: draft-halpern-forces-lfblibrary-vpn--00.txt
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_6VWoqaF792x/R+V0x2XI2A)"

This is a multi-part message in MIME format.

--Boundary_(ID_6VWoqaF792x/R+V0x2XI2A)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi, All:

A new I-D draft named "draft-halpern-forces-lfblibrary-vpn--00.txt" has been submitted, the draft supposes a solution to VPN in ForCES architecture. At the first step, a GRE tunnel & its configuration policies LFB definition has been given, please give some comments.

Best,

Michael

--Boundary_(ID_6VWoqaF792x/R+V0x2XI2A)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2900.3020" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2>Hi, All:</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>A&nbsp;new I-D draft named
"draft-halpern-forces-lfblibrary-vpn--00.txt" has been submitted, the draft
supposes a solution to VPN in ForCES architecture.&nbsp;At the first step, a GRE
tunnel &amp; its configuration&nbsp;policies LFB definition&nbsp;has been given,
please give some comments.</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Best,</FONT></DIV>
<DIV><FONT size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2>Michael</FONT></DIV></BODY></HTML>

--Boundary_(ID_6VWoqaF792x/R+V0x2XI2A)--


2007
Message-Id: <TUE.9.JAN.2007.124406.0500.>
Date: Tue, 9 Jan 2007 12:44:06 -0500
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: [MODEL] Resolutions to nouns describing LFB class definitions?
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
Comments: cc: "tom.petch" <cfinss@dial.pipex.com>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

How about "ForcesElement" for the cases in the definitions where
there is a fit for the element being a component of a structure or
property? One could probably do a s/element/ForcesElement/g and get away
with it.

The other more bothersome one is "attributes" which is clearly a
"property" of an "element" (pun intended). i.e we have both
"property" (lucky for us, thats not taken by XML), and "attribute" all
over the map - sometimes morphed to the same semantic.

For that:
LFBAttributes would fit nicely for the case of attributes as defined in
the LFBClassDefs. For consistency, why dont we prefix everything under
LFBClassDefs with "LFB" (eg LFBCapabilities, etc).

This still leaves us with the dilema of properties (of ForcesElement) as
defined in XMLish speak such as
<array type="variable-size" max-length="8"> vs the forces model speak of
arrayElementProperties  (which has attributes/properties like
highestUsedSubscript).

It will be _tricky_, but nonetheless tempting, to say leave those in XML
speak but still allow for the protocol operations to target them to
simplify life. The other alternative is to get rid of XML variant maybe?
Or maybe we need both?

cheers,
jamal

On Mon, 2007-08-01 at 16:09 -0500, Joel M. Halpern wrote:
> Let me just restate the problem.
> There are a number of model components which all behave in similar
> fashions, and frequently need to be referred to in some easily
> understood fashion.  These include the components of structures and
> properties.  They include the attributes and capabilities of the LFB
> class.  They include items in arrays in one of the above.
>
> So I had used "element" for that.  Tom rightly raised the concern
> that this (and attribute) have very clear XML meanings, and we can
> end up sometimes talking about XML elements and sometimes tlaking
> about ForCES elements.  Even if we are careful, this seems likely to
> lead to confusion.
> So we need some term for the ForCES element.  (Since we are not going
> to change the XML terminology :-)
>
> But no one has come up with proposed terminology.  If no one comes up
> with anything else, I will try using component, and see how that
> works.  (I doubt that is a good choice.)
>


2007
Message-Id: <MON.8.JAN.2007.163645.0100.>
Date: Mon, 8 Jan 2007 16:36:45 +0100
From: "tom.petch" <cfinss@dial.pipex.com>
Subject: Re: [MODEL] Resolutions to nouns describing LFB class definitions?
Comments: To: hadi@znyx.com
Comments: cc: "Joel M. Halpern" <joel@stevecrocker.com>, Ellen M <ellen.m.deleganes@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

----- Original Message -----
From: "Jamal Hadi Salim" <hadi@znyx.com>
Cc: "tom.petch" <cfinss@dial.pipex.com>; "Joel M. Halpern"
<joel@stevecrocker.com>; "Ellen M" <ellen.m.deleganes@intel.com>
Sent: Monday, January 08, 2007 5:14 PM
Subject: Re: [MODEL] Resolutions to nouns describing LFB class definitions?
>
> Can we discuss this and resolve it? It is a little more difficult for me
> to read 4.5.3 (and i am gonna assume the rest of 4.5.x).
>
> Joel, what are your thoughts on the subject?
>

To quote myself from last October

"I think anything using XML then has a problem with the words 'element' and
'attribute' since they have a technical, XML meaning and yes, prefixing or
adding a second word is a good solution to that.

Specifically, the part that confuses me most is the shift in terminolgy between
s4 - (operational) attributes and capabilities (attributes) - versus s3 -
capabilities and capacities, respectively, and s7.  I prefer to avoid the word
attribute in its entirety here but recognise that that means changing the
schema; for me, capabilities and capacities (or constraints), as used in s3, is
better.

This also ripples back into -protocol where in some places, attributes and
capabilities are used, in others attributes would seem to cover both
(operational attributes and capability attributes), while element is widely used
and seems to mean the atomic piece of data that the ForCES protocol operates on.

'element' as used in -model may cause confusion with arrays when arrays consist
of multiple elements which are not necessarily XML elements."

I think that is still the best summation of my thinking.

Tom Petch

> cheers,
> jamal
>
> On Fri, 2007-05-01 at 11:06 -0500, Jamal Hadi Salim wrote:
> > Thanks Tom. I know Joel has it under control but i've just put this
> > discussion in the tracker (issue #103) so it is not forgotten when
> > people get busyed out.
> >
> > cheers,
> > jamal
> >
> > On Fri, 2007-05-01 at 08:57 +0100, tom.petch wrote:
> > > Jamal
> > >
> > > There was general agreement that using the same terms as had technical
meaning
> > > in XML was likely to cause confusion but there was no consensus on what to
> > > replace the ones in -model with.
> > >
>
>


2007
Message-Id: <MON.8.JAN.2007.160903.0500.>
Date: Mon, 8 Jan 2007 16:09:03 -0500
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: [MODEL] Resolutions to nouns describing LFB class definitions?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Let me just restate the problem.
There are a number of model components which all behave in similar
fashions, and frequently need to be referred to in some easily
understood fashion.  These include the components of structures and
properties.  They include the attributes and capabilities of the LFB
class.  They include items in arrays in one of the above.

So I had used "element" for that.  Tom rightly raised the concern
that this (and attribute) have very clear XML meanings, and we can
end up sometimes talking about XML elements and sometimes tlaking
about ForCES elements.  Even if we are careful, this seems likely to
lead to confusion.
So we need some term for the ForCES element.  (Since we are not going
to change the XML terminology :-)

But no one has come up with proposed terminology.  If no one comes up
with anything else, I will try using component, and see how that
works.  (I doubt that is a good choice.)

Yours,
Joel

At 10:36 AM 1/8/2007, tom.petch wrote:
>----- Original Message -----
>From: "Jamal Hadi Salim" <hadi@znyx.com>
>Cc: "tom.petch" <cfinss@dial.pipex.com>; "Joel M. Halpern"
><joel@stevecrocker.com>; "Ellen M" <ellen.m.deleganes@intel.com>
>Sent: Monday, January 08, 2007 5:14 PM
>Subject: Re: [MODEL] Resolutions to nouns describing LFB class definitions?
> >
> > Can we discuss this and resolve it? It is a little more difficult for me
> > to read 4.5.3 (and i am gonna assume the rest of 4.5.x).
> >
> > Joel, what are your thoughts on the subject?
> >
>
>To quote myself from last October
>
>"I think anything using XML then has a problem with the words 'element' and
>'attribute' since they have a technical, XML meaning and yes, prefixing or
>adding a second word is a good solution to that.
>
>Specifically, the part that confuses me most is the shift in
>terminolgy between
>s4 - (operational) attributes and capabilities (attributes) - versus s3 -
>capabilities and capacities, respectively, and s7.  I prefer to avoid the word
>attribute in its entirety here but recognise that that means changing the
>schema; for me, capabilities and capacities (or constraints), as
>used in s3, is
>better.
>
>This also ripples back into -protocol where in some places, attributes and
>capabilities are used, in others attributes would seem to cover both
>(operational attributes and capability attributes), while element is
>widely used
>and seems to mean the atomic piece of data that the ForCES protocol
>operates on.
>
>'element' as used in -model may cause confusion with arrays when
>arrays consist
>of multiple elements which are not necessarily XML elements."
>
>I think that is still the best summation of my thinking.
>
>Tom Petch
>
> > cheers,
> > jamal
> >
> > On Fri, 2007-05-01 at 11:06 -0500, Jamal Hadi Salim wrote:
> > > Thanks Tom. I know Joel has it under control but i've just put this
> > > discussion in the tracker (issue #103) so it is not forgotten when
> > > people get busyed out.
> > >
> > > cheers,
> > > jamal
> > >
> > > On Fri, 2007-05-01 at 08:57 +0100, tom.petch wrote:
> > > > Jamal
> > > >
> > > > There was general agreement that using the same terms as had technical
>meaning
> > > > in XML was likely to cause confusion but there was no
> consensus on what to
> > > > replace the ones in -model with.
> > > >
> >
> >


2007
Message-Id: <MON.8.JAN.2007.111455.0500.>
Date: Mon, 8 Jan 2007 11:14:55 -0500
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: [MODEL] Resolutions to nouns describing LFB class definitions?
Comments: cc: "tom.petch" <cfinss@dial.pipex.com>, "Joel M. Halpern" <joel@stevecrocker.com>, Ellen M <ellen.m.deleganes@intel.com>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

folks,

Can we discuss this and resolve it? It is a little more difficult for me
to read 4.5.3 (and i am gonna assume the rest of 4.5.x).

Joel, what are your thoughts on the subject?

cheers,
jamal

On Fri, 2007-05-01 at 11:06 -0500, Jamal Hadi Salim wrote:
> Thanks Tom. I know Joel has it under control but i've just put this
> discussion in the tracker (issue #103) so it is not forgotten when
> people get busyed out.
>
> cheers,
> jamal
>
> On Fri, 2007-05-01 at 08:57 +0100, tom.petch wrote:
> > Jamal
> >
> > There was general agreement that using the same terms as had technical meaning
> > in XML was likely to cause confusion but there was no consensus on what to
> > replace the ones in -model with.
> >


2007
Message-Id: <MON.8.JAN.2007.110534.0500.>
Date: Mon, 8 Jan 2007 11:05:34 -0500
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: [Model] Section 4.5
Comments: cc: Ellen M <ellen.m.deleganes@intel.com>, "Joel M. Halpern" <joel@stevecrocker.com>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Nit pick:

 "Compound data types can be defined in one of
      four ways ..."

I think it would be cleaner to enumerate the 4 ways as in bullet format
or numbered list.

cheers,
jamal


2007
Message-Id: <FRI.5.JAN.2007.113958.0500.>
Date: Fri, 5 Jan 2007 11:39:58 -0500
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: [Model] Section 4.2
Comments: To: "Joel M. Halpern" <joel@stevecrocker.com>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Sounds reasonable.

I may be getting into bean counting now - but is it fair to
ask just to cutnpaste what you said below into the text?

cheers,
jamal

On Fri, 2007-05-01 at 11:27 -0500, Joel M. Halpern wrote:
> I believe that there is no point in defining an LFBLibrary with no
> content.  However:
> 1) It doesn't hurt anything for that to be a compliant document
> 2) More importantly, getting the schema to allow each piece to be
> optional, but requiring something, was going to be a lot of work.
> So, since it was hard to get right, and basically didn't matter, the
> schema allows empty content.
>
> Yours,
> Joel
>
> At 11:17 AM 1/5/2007, Jamal Hadi Salim wrote:
>
> >Although the first paragraph says "one or more blocks" within the root
> >element <LFBLibrary>, the following text indicates "zero or more" since
> >all elements are optional (except for the description, which seems
> >unintended to be non-optional).
> >- which one is correct?
> >- what would be the point to defining an LFB that has zero elements?
> >- Should there be some that are a must-have in order to allow for
> >something meaningful?
> >
> >
> >I am going to stop flooding the list with new issues just so we can pick
> >up on the ones i have been posting so far. In the meantime, on the ones
> >where a known path has been defined - I will enter entries into
> >the tracker.
> >
> >cheers,
> >jamal


2007
Message-Id: <FRI.5.JAN.2007.112704.0500.>
Date: Fri, 5 Jan 2007 11:27:04 -0500
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: [Model] Section 4.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

I believe that there is no point in defining an LFBLibrary with no
content.  However:
1) It doesn't hurt anything for that to be a compliant document
2) More importantly, getting the schema to allow each piece to be
optional, but requiring something, was going to be a lot of work.
So, since it was hard to get right, and basically didn't matter, the
schema allows empty content.

Yours,
Joel

At 11:17 AM 1/5/2007, Jamal Hadi Salim wrote:

>Although the first paragraph says "one or more blocks" within the root
>element <LFBLibrary>, the following text indicates "zero or more" since
>all elements are optional (except for the description, which seems
>unintended to be non-optional).
>- which one is correct?
>- what would be the point to defining an LFB that has zero elements?
>- Should there be some that are a must-have in order to allow for
>something meaningful?
>
>
>I am going to stop flooding the list with new issues just so we can pick
>up on the ones i have been posting so far. In the meantime, on the ones
>where a known path has been defined - I will enter entries into
>the tracker.
>
>cheers,
>jamal


2007
Message-Id: <FRI.5.JAN.2007.111720.0500.>
Date: Fri, 5 Jan 2007 11:17:20 -0500
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: [Model] Section 4.2
Comments: cc: "Joel M. Halpern" <joel@stevecrocker.com>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Although the first paragraph says "one or more blocks" within the root
element <LFBLibrary>, the following text indicates "zero or more" since
all elements are optional (except for the description, which seems
unintended to be non-optional).
- which one is correct?
- what would be the point to defining an LFB that has zero elements?
- Should there be some that are a must-have in order to allow for
something meaningful?


I am going to stop flooding the list with new issues just so we can pick
up on the ones i have been posting so far. In the meantime, on the ones
where a known path has been defined - I will enter entries into
the tracker.

cheers,
jamal


2007
Message-Id: <FRI.5.JAN.2007.110614.0500.>
Date: Fri, 5 Jan 2007 11:06:14 -0500
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: [MODEL] Resolutions to nouns describing LFB class definitions?
Comments: To: "tom.petch" <cfinss@dial.pipex.com>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Thanks Tom. I know Joel has it under control but i've just put this
discussion in the tracker (issue #103) so it is not forgotten when
people get busyed out.

cheers,
jamal

On Fri, 2007-05-01 at 08:57 +0100, tom.petch wrote:
> Jamal
>
> There was general agreement that using the same terms as had technical meaning
> in XML was likely to cause confusion but there was no consensus on what to
> replace the ones in -model with.
>
> Tom Petch
>
>
> ----- Original Message -----
> From: "Jamal Hadi Salim" <hadi@znyx.com>
> Sent: Thursday, January 04, 2007 5:40 PM
> Subject: [MODEL] Resolutions to nouns describing LFB class definitions?
>
>
> > Joel,
> >
> > There was a discussion with Tom a while back on the naming conventions
> > of LFB attributes and their properties so we avoid conflicting with
> > the XML definitions ...
> > I cant find anything on the tracker - what was the resolution? As i
> > begin scouring section 4 i am finding it unsettling as well.
> >
> > Can you open a tracker on the change or respond to this and i will.
> >
> > cheers,
> > jamal


2007
Message-Id: <FRI.5.JAN.2007.085739.0100.>
Date: Fri, 5 Jan 2007 08:57:39 +0100
From: "tom.petch" <cfinss@dial.pipex.com>
Subject: Re: [MODEL] Resolutions to nouns describing LFB class definitions?
Comments: To: hadi@znyx.com
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Jamal

There was general agreement that using the same terms as had technical meaning
in XML was likely to cause confusion but there was no consensus on what to
replace the ones in -model with.

Tom Petch


----- Original Message -----
From: "Jamal Hadi Salim" <hadi@znyx.com>
Sent: Thursday, January 04, 2007 5:40 PM
Subject: [MODEL] Resolutions to nouns describing LFB class definitions?


> Joel,
>
> There was a discussion with Tom a while back on the naming conventions
> of LFB attributes and their properties so we avoid conflicting with
> the XML definitions ...
> I cant find anything on the tracker - what was the resolution? As i
> begin scouring section 4 i am finding it unsettling as well.
>
> Can you open a tracker on the change or respond to this and i will.
>
> cheers,
> jamal


2007
Message-Id: <THU.4.JAN.2007.115710.0500.>
Date: Thu, 4 Jan 2007 11:57:10 -0500
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: [Model] Section 4
Comments: cc: "Joel M. Halpern" <joel@stevecrocker.com>, Ellen M <ellen.m.deleganes@intel.com>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

I have brought this up with Joel before and we never reached a closure.
While playing an armchair lawyer trying to make language more explicit
in a document on this list, I am worried about people who read RFCs like
some religious scripture. This has bitten me in the past, so it will be
hard for me to stop bringing it up. And so in that spirit:

Last paragraph of section 4 (before 4.1):
** "It is not expected that ... will be exchanged over the wire"
- What is the relevance of that information? Can we get rid of it?

** "The model will serve as an important reference ... for design and
development ..."

The "development" part bothers me. It may be misconstrued as have other
RFCs. Can we tame it down or emphasize the information model (design)
aspect over the data model (close to the wire/development) aspect?

cheers,
jamal


2007
Message-Id: <THU.4.JAN.2007.114022.0500.>
Date: Thu, 4 Jan 2007 11:40:22 -0500
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: [MODEL] Resolutions to nouns describing LFB class definitions?
Comments: cc: Ellen M <ellen.m.deleganes@intel.com>, "Joel M. Halpern" <joel@stevecrocker.com>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Joel,

There was a discussion with Tom a while back on the naming conventions
of LFB attributes and their properties so we avoid conflicting with
the XML definitions ...
I cant find anything on the tracker - what was the resolution? As i
begin scouring section 4 i am finding it unsettling as well.

Can you open a tracker on the change or respond to this and i will.

cheers,
jamal




2007
Message-Id: <THU.4.JAN.2007.112619.0500.>
Date: Thu, 4 Jan 2007 11:26:19 -0500
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: [MODEL] Section 3.3.2
Comments: cc: Ellen M <ellen.m.deleganes@intel.com>, "Joel M. Halpern" <joel@stevecrocker.com>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

This is also editorial as well

Figure 7:

these figures dont really do justice to the concepts of:
1) capability and 2) good combination of encoded-state/topology
representation


Figure #7a shows only certain capabilities properly; example for the
forwarder, it is clear that it can be connected to by the classifier and
scheduler and that it can connect to the egress. But i am not sure if i
can see a meter connecting to a dropper or a marker for example ..

Figure #5c and #6a and #6b do a good job at achieving #2 but then this
gets lost in figure 7b and #7c.

I can enter this in the tracker if deemed important and even volunteer
to fix it if needed.

cheers,
jamal


2007
Message-Id: <THU.4.JAN.2007.111526.0500.>
Date: Thu, 4 Jan 2007 11:15:26 -0500
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: [MODEL] Section 3.3.1
Comments: cc: "Joel M. Halpern" <joel@stevecrocker.com>, Ellen M <ellen.m.deleganes@intel.com>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

A small issue:
Last paragraph, last sentence starts with "one way to encode .."
The text seems dated. I believe we have decided on the addressing
hierachy which involves a classid::instance.

If agreeable, I can enter this in the tracker or you could

cheers,
jamal


2007
Message-Id: <THU.4.JAN.2007.095225.0500.>
Date: Thu, 4 Jan 2007 09:52:25 -0500
From: Jamal Hadi Salim <hadi@znyx.com>
Organization: ZNYX Networks
Subject: Re: [model] section 3.2.4 Metadata
Comments: To: "tom.petch" <cfinss@dial.pipex.com>
Content-Type: text/plain
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Wed, 2007-03-01 at 16:23 +0100, tom.petch wrote:
> I had few problems with 3.2.4, it seemed mostly clear and well expressed.  I was
> less clear at the end of -model how much of it was needed.

That is the major problem i had as well. Actually more than that is i
was weeding through irrelevant text trying to get to the relevant points
unnecessarily. There are also a lot of relevant (to the model) points
missing. Having said that i dont see it an issue if this section or a
variation of it was in an appendix or even better off as a separate doc.

> Two points are made in 3.2.4.1 that I would not like to lose:
>
> - metadata may exist as part of the internal functioning of an FE but that is
> outside the scope of the model
> - the metadata defined in -model is only a model to make clear the operation
> of -protocol; it is -protocol to which a compliant implementation must conform
>

I think these are valuable points which need to be captured regardless
of how the text ends being.
Ellen, I have offered to take a crack at sanitizing this section. I
think it is more than just getting rid of that section. If you look at
other equivalent text such as one on events etc - you will see
preciseness and brevity that is called for. Give me some time since i am
prioritizing going over the draft sequentially.
So i am putting this as an action item for me which i will probably get
back to when i go past section 5. I could make it higher priority if you
think thats more important than going over the rest of the draft first.

> That said, there are examples, probably many, where the model in an RFC does get
> taken literally by implementors, probably because it can be understood with more
> confidence than the protocol.

Yes, this worries me a great deal as well and is subject of a different
thread of discussion with Joel.

> In this instance, I did not understand -protocol
> until I had read -model.

Which makes sense, IMO. For instance, the protocols hierachical
addressing concepts of class::instance::path certainly require knowledge
of the model.

cheers,
jamal

> Tom Petch
>
>
> ----- Original Message -----
> From: "Deleganes, Ellen M" <ellen.m.deleganes@intel.com>
> Sent: Tuesday, January 02, 2007 11:44 PM
> Subject: Re: [model] section 3.2.4 Metadata
>
>
> <Sorry if you get this twice - I removed the digital signature, which
> seems to cause problems in people being able to see the email>
>
> I see very little value in section 3.2.4.1 - mostly it is a long winded
> definition of metadata and only a small part of it says anything about
> how
> it relates to the ForCES model.
>
> Isn't the paragraph under 3.2.4 sufficient to describe what we mean by
> metadata in the ForCES model? (e.g. it is the per-packet state that is
> passed from one LFB to another and that the only metadata model that is
> of
> concern to the ForCES model is the metadata that is passed from one LFB
> to
> another within an FE).
>
> If no one will have heartburn about removing section 3.2.4.1, I will
> take it
> out and try to work on rewriting the rest of the section to make it more
> readable.
>
> Regards,
> Ellen
>
> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim
> Sent: Friday, December 29, 2006 7:56 AM
> To: FORCES@PEACH.EASE.LSOFT.COM
> Subject: Re: [model] section 3.2.4 Metadata
>
> On Thu, 2006-28-12 at 15:14 -0500, Joel M. Halpern wrote:
> > You could as well ask "where are the formal semantics of an LFB class
> > defined?"  After all, the CE has to understand what the FE will do
> > when asked to put an instance of an LFB class on a data path.
> >
> > The decision we took was to not formally define semantics.  Semantics
> > are defined textually.
> >
> > This is true of LFB operations.  It is also true of meta-data
> > semantics.  Typically, some LFB will produce the meta-data, with text
> > indicating that the meta-data is some result of manipulating a field
> > in a packet, or an entry in a table provided by the CE, or ...
> > (Yes, there is room for ambiguity.  Writers of the text describing
> > LFB classes need to do their best to make sure the English is clear.)
> > And another LFB might indicate that it uses some piece of meta-data
> > as an index in a table.
> >
>
> Actually looking further into the text, I think i have found my answer
> in the schema. Are we both exhausted of this text?
> The definition of the metadatum is done in the LFB class (section 4
> shows it). Your example has <metadataDefs> and its usage well done in
> section 8. That helped.
> I think it would do a lot of justice to have the text on metadatum to
> reflect the simplicity found in section 4. A cleanup of the text is
> certainly needed.
>
> More suggestion:  add some text on LFB capability of metadata - maybe a
> small extension to your example in section 8 would be useful.
>
> cheers,
> jamal


2007
Message-Id: <THU.4.JAN.2007.075316.0800.>
Date: Thu, 4 Jan 2007 07:53:16 -0800
From: "Deleganes, Ellen M" <ellen.m.deleganes@intel.com>
Subject: Re: [model] section 3.2.4 Metadata
Comments: To: hadi@znyx.com
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Jamal,

I think we're on the same page in terms of the entire text needing to be
rewritten or at least heavily edited. The section that I suggested
deleting was one of the obvious first things to do since only the two
items that Tom pointed out appeared to be of any value or meaning as far
as the model draft is concerned.

Throughout there is still a lot of superfluous and redundant text that
could be removed and/or streamlined. This section reads more like a
tutorial on metadata rather than how it is used in the context of the
ForCES model.=20

I hadn't realized that you volunteered to rewrite this, go ahead. I
don't really have the time in any case.

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim
Sent: Thursday, January 04, 2007 6:52 AM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: [model] section 3.2.4 Metadata

On Wed, 2007-03-01 at 16:23 +0100, tom.petch wrote:
> I had few problems with 3.2.4, it seemed mostly clear and well
expressed.  I was
> less clear at the end of -model how much of it was needed.

That is the major problem i had as well. Actually more than that is i
was weeding through irrelevant text trying to get to the relevant points
unnecessarily. There are also a lot of relevant (to the model) points
missing. Having said that i dont see it an issue if this section or a
variation of it was in an appendix or even better off as a separate doc.

> Two points are made in 3.2.4.1 that I would not like to lose:
>=20
> - metadata may exist as part of the internal functioning of an FE but
that is
> outside the scope of the model
> - the metadata defined in -model is only a model to make clear the
operation
> of -protocol; it is -protocol to which a compliant implementation must
conform
>=20

I think these are valuable points which need to be captured regardless
of how the text ends being.
Ellen, I have offered to take a crack at sanitizing this section. I
think it is more than just getting rid of that section. If you look at
other equivalent text such as one on events etc - you will see
preciseness and brevity that is called for. Give me some time since i am
prioritizing going over the draft sequentially.
So i am putting this as an action item for me which i will probably get
back to when i go past section 5. I could make it higher priority if you
think thats more important than going over the rest of the draft first.

> That said, there are examples, probably many, where the model in an
RFC does get
> taken literally by implementors, probably because it can be understood
with more
> confidence than the protocol. =20

Yes, this worries me a great deal as well and is subject of a different
thread of discussion with Joel.

> In this instance, I did not understand -protocol
> until I had read -model.

Which makes sense, IMO. For instance, the protocols hierachical
addressing concepts of class::instance::path certainly require knowledge
of the model.

cheers,
jamal

> Tom Petch
>=20
>=20
> ----- Original Message -----
> From: "Deleganes, Ellen M" <ellen.m.deleganes@intel.com>
> Sent: Tuesday, January 02, 2007 11:44 PM
> Subject: Re: [model] section 3.2.4 Metadata
>=20
>=20
> <Sorry if you get this twice - I removed the digital signature, which
> seems to cause problems in people being able to see the email>
>=20
> I see very little value in section 3.2.4.1 - mostly it is a long
winded
> definition of metadata and only a small part of it says anything about
> how
> it relates to the ForCES model.
>=20
> Isn't the paragraph under 3.2.4 sufficient to describe what we mean by
> metadata in the ForCES model? (e.g. it is the per-packet state that is
> passed from one LFB to another and that the only metadata model that
is
> of
> concern to the ForCES model is the metadata that is passed from one
LFB
> to
> another within an FE).
>=20
> If no one will have heartburn about removing section 3.2.4.1, I will
> take it
> out and try to work on rewriting the rest of the section to make it
more
> readable.
>=20
> Regards,
> Ellen
>=20
> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim
> Sent: Friday, December 29, 2006 7:56 AM
> To: FORCES@PEACH.EASE.LSOFT.COM
> Subject: Re: [model] section 3.2.4 Metadata
>=20
> On Thu, 2006-28-12 at 15:14 -0500, Joel M. Halpern wrote:
> > You could as well ask "where are the formal semantics of an LFB
class
> > defined?"  After all, the CE has to understand what the FE will do
> > when asked to put an instance of an LFB class on a data path.
> >
> > The decision we took was to not formally define semantics.
Semantics
> > are defined textually.
> >
> > This is true of LFB operations.  It is also true of meta-data
> > semantics.  Typically, some LFB will produce the meta-data, with
text
> > indicating that the meta-data is some result of manipulating a field
> > in a packet, or an entry in a table provided by the CE, or ...
> > (Yes, there is room for ambiguity.  Writers of the text describing
> > LFB classes need to do their best to make sure the English is
clear.)
> > And another LFB might indicate that it uses some piece of meta-data
> > as an index in a table.
> >
>=20
> Actually looking further into the text, I think i have found my answer
> in the schema. Are we both exhausted of this text?
> The definition of the metadatum is done in the LFB class (section 4
> shows it). Your example has <metadataDefs> and its usage well done in
> section 8. That helped.
> I think it would do a lot of justice to have the text on metadatum to
> reflect the simplicity found in section 4. A cleanup of the text is
> certainly needed.
>=20
> More suggestion:  add some text on LFB capability of metadata - maybe
a
> small extension to your example in section 8 would be useful.
>=20
> cheers,
> jamal


2007
Message-Id: <WED.3.JAN.2007.172739.0100.>
Date: Wed, 3 Jan 2007 17:27:39 +0100
From: "tom.petch" <cfinss@dial.pipex.com>
Subject: Re: [Model] Microsoft word cruft
Comments: To: hadi@znyx.com
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

The character you refer to is x'92' which, in Windows-1252 Code Page, is =
the
single curly quote right hand end.  Using WordPad to display -model, I ge=
t a
double quote which is, of course, what is required by the context.  At th=
e same
time, ASCII x'22' does the job just as well (and is the character used in=
 most
of -model).

Tom Petch

----- Original Message -----
From: "Jamal Hadi Salim" <hadi@znyx.com>
Sent: Thursday, December 28, 2006 6:07 PM
Subject: [Model] Microsoft word cruft


I actually entered this in the database since i dont see much
contention. It is recorded as issue #102.

Every time an xml definition that uses the "=3D" sign is used
in the document, the equality is surrounded by some control characters.
In my printout they look like "M-^RM-^R"

Example:
<events baseID=3D=EF=BF=BD=EF=BF=BDnumber=EF=BF=BD=EF=BF=BD>

Either get the output not to do that or fix it when you are submitting
the draft.

cheers,
jamal


2007
Message-Id: <WED.3.JAN.2007.162357.0100.>
Date: Wed, 3 Jan 2007 16:23:57 +0100
From: "tom.petch" <cfinss@dial.pipex.com>
Subject: Re: [model] section 3.2.4 Metadata
Comments: To: "Deleganes, Ellen M" <ellen.m.deleganes@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I had few problems with 3.2.4, it seemed mostly clear and well expressed.  I was
less clear at the end of -model how much of it was needed.

Two points are made in 3.2.4.1 that I would not like to lose:

- metadata may exist as part of the internal functioning of an FE but that is
outside the scope of the model
- the metadata defined in -model is only a model to make clear the operation
of -protocol; it is -protocol to which a compliant implementation must conform

That said, there are examples, probably many, where the model in an RFC does get
taken literally by implementors, probably because it can be understood with more
confidence than the protocol.  In this instance, I did not understand -protocol
until I had read -model.

Tom Petch


----- Original Message -----
From: "Deleganes, Ellen M" <ellen.m.deleganes@intel.com>
Sent: Tuesday, January 02, 2007 11:44 PM
Subject: Re: [model] section 3.2.4 Metadata


<Sorry if you get this twice - I removed the digital signature, which
seems to cause problems in people being able to see the email>

I see very little value in section 3.2.4.1 - mostly it is a long winded
definition of metadata and only a small part of it says anything about
how
it relates to the ForCES model.

Isn't the paragraph under 3.2.4 sufficient to describe what we mean by
metadata in the ForCES model? (e.g. it is the per-packet state that is
passed from one LFB to another and that the only metadata model that is
of
concern to the ForCES model is the metadata that is passed from one LFB
to
another within an FE).

If no one will have heartburn about removing section 3.2.4.1, I will
take it
out and try to work on rewriting the rest of the section to make it more
readable.

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim
Sent: Friday, December 29, 2006 7:56 AM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: [model] section 3.2.4 Metadata

On Thu, 2006-28-12 at 15:14 -0500, Joel M. Halpern wrote:
> You could as well ask "where are the formal semantics of an LFB class
> defined?"  After all, the CE has to understand what the FE will do
> when asked to put an instance of an LFB class on a data path.
>
> The decision we took was to not formally define semantics.  Semantics
> are defined textually.
>
> This is true of LFB operations.  It is also true of meta-data
> semantics.  Typically, some LFB will produce the meta-data, with text
> indicating that the meta-data is some result of manipulating a field
> in a packet, or an entry in a table provided by the CE, or ...
> (Yes, there is room for ambiguity.  Writers of the text describing
> LFB classes need to do their best to make sure the English is clear.)
> And another LFB might indicate that it uses some piece of meta-data
> as an index in a table.
>

Actually looking further into the text, I think i have found my answer
in the schema. Are we both exhausted of this text?
The definition of the metadatum is done in the LFB class (section 4
shows it). Your example has <metadataDefs> and its usage well done in
section 8. That helped.
I think it would do a lot of justice to have the text on metadatum to
reflect the simplicity found in section 4. A cleanup of the text is
certainly needed.

More suggestion:  add some text on LFB capability of metadata - maybe a
small extension to your example in section 8 would be useful.

cheers,
jamal


2007
Message-Id: <TUE.2.JAN.2007.144426.0800.>
Date: Tue, 2 Jan 2007 14:44:26 -0800
From: "Deleganes, Ellen M" <ellen.m.deleganes@intel.com>
Subject: Re: [model] section 3.2.4 Metadata
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<Sorry if you get this twice - I removed the digital signature, which
seems to cause problems in people being able to see the email>

I see very little value in section 3.2.4.1 - mostly it is a long winded
definition of metadata and only a small part of it says anything about
how
it relates to the ForCES model.

Isn't the paragraph under 3.2.4 sufficient to describe what we mean by
metadata in the ForCES model? (e.g. it is the per-packet state that is
passed from one LFB to another and that the only metadata model that is
of
concern to the ForCES model is the metadata that is passed from one LFB
to
another within an FE).

If no one will have heartburn about removing section 3.2.4.1, I will
take it
out and try to work on rewriting the rest of the section to make it more
readable.

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:FORCES@PEACH.EASE.LSOFT.COM] On Behalf Of Jamal Hadi Salim
Sent: Friday, December 29, 2006 7:56 AM
To: FORCES@PEACH.EASE.LSOFT.COM
Subject: Re: [model] section 3.2.4 Metadata

On Thu, 2006-28-12 at 15:14 -0500, Joel M. Halpern wrote:
> You could as well ask "where are the formal semantics of an LFB class=20
> defined?"  After all, the CE has to understand what the FE will do=20
> when asked to put an instance of an LFB class on a data path.
>=20
> The decision we took was to not formally define semantics.  Semantics=20
> are defined textually.
>
> This is true of LFB operations.  It is also true of meta-data=20
> semantics.  Typically, some LFB will produce the meta-data, with text=20
> indicating that the meta-data is some result of manipulating a field=20
> in a packet, or an entry in a table provided by the CE, or ...
> (Yes, there is room for ambiguity.  Writers of the text describing=20
> LFB classes need to do their best to make sure the English is clear.)
> And another LFB might indicate that it uses some piece of meta-data=20
> as an index in a table.
>=20

Actually looking further into the text, I think i have found my answer
in the schema. Are we both exhausted of this text?
The definition of the metadatum is done in the LFB class (section 4
shows it). Your example has <metadataDefs> and its usage well done in
section 8. That helped.
I think it would do a lot of justice to have the text on metadatum to
reflect the simplicity found in section 4. A cleanup of the text is
certainly needed.

More suggestion:  add some text on LFB capability of metadata - maybe a
small extension to your example in section 8 would be useful.

cheers,
jamal


2007
Message-Id: <TUE.2.JAN.2007.144222.0800.>
Date: Tue, 2 Jan 2007 14:42:22 -0800
From: "Deleganes, Ellen M" <ellen.m.deleganes@intel.com>
Subject: Re: [model] section 3.2.4 Metadata
Comments: To: hadi@znyx.com
MIME-Version: 1.0
Content-Type: application/x-pkcs7-mime;smime-type=signed-data;name=smime.p7m; name="smime.p7m"; smime-type=signed-data
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEggnzQ29u
dGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9InVzLWFzY2lpIg0KQ29udGVudC1UcmFu
c2Zlci1FbmNvZGluZzogN2JpdA0KDQpJIHNlZSB2ZXJ5IGxpdHRsZSB2YWx1ZSBpbiBzZWN0aW9u
IDMuMi40LjEgLSBtb3N0bHkgaXQgaXMgYSBsb25nIHdpbmRlZA0KZGVmaW5pdGlvbiBvZiBtZXRh
ZGF0YSBhbmQgb25seSBhIHNtYWxsIHBhcnQgb2YgaXQgc2F5cyBhbnl0aGluZyBhYm91dCBob3cN
Cml0IHJlbGF0ZXMgdG8gdGhlIEZvckNFUyBtb2RlbC4NCg0KSXNuJ3QgdGhlIHBhcmFncmFwaCB1
bmRlciAzLjIuNCBzdWZmaWNpZW50IHRvIGRlc2NyaWJlIHdoYXQgd2UgbWVhbiBieQ0KbWV0YWRh
dGEgaW4gdGhlIEZvckNFUyBtb2RlbD8gKGUuZy4gaXQgaXMgdGhlIHBlci1wYWNrZXQgc3RhdGUg
dGhhdCBpcw0KcGFzc2VkIGZyb20gb25lIExGQiB0byBhbm90aGVyIGFuZCB0aGF0IHRoZSBvbmx5
IG1ldGFkYXRhIG1vZGVsIHRoYXQgaXMgb2YNCmNvbmNlcm4gdG8gdGhlIEZvckNFUyBtb2RlbCBp
cyB0aGUgbWV0YWRhdGEgdGhhdCBpcyBwYXNzZWQgZnJvbSBvbmUgTEZCIHRvDQphbm90aGVyIHdp
dGhpbiBhbiBGRSkuDQoNCklmIG5vIG9uZSB3aWxsIGhhdmUgaGVhcnRidXJuIGFib3V0IHJlbW92
aW5nIHNlY3Rpb24gMy4yLjQuMSwgSSB3aWxsIHRha2UgaXQNCm91dCBhbmQgdHJ5IHRvIHdvcmsg
b24gcmV3cml0aW5nIHRoZSByZXN0IG9mIHRoZSBzZWN0aW9uIHRvIG1ha2UgaXQgbW9yZQ0KcmVh
ZGFibGUuDQoNClJlZ2FyZHMsDQpFbGxlbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
RnJvbTogRm9yd2FyZGluZyBhbmQgQ29udHJvbCBFbGVtZW50IFNlcGFyYXRpb24NClttYWlsdG86
Rk9SQ0VTQFBFQUNILkVBU0UuTFNPRlQuQ09NXSBPbiBCZWhhbGYgT2YgSmFtYWwgSGFkaSBTYWxp
bQ0KU2VudDogRnJpZGF5LCBEZWNlbWJlciAyOSwgMjAwNiA3OjU2IEFNDQpUbzogRk9SQ0VTQFBF
QUNILkVBU0UuTFNPRlQuQ09NDQpTdWJqZWN0OiBSZTogW21vZGVsXSBzZWN0aW9uIDMuMi40IE1l
dGFkYXRhDQoNCk9uIFRodSwgMjAwNi0yOC0xMiBhdCAxNToxNCAtMDUwMCwgSm9lbCBNLiBIYWxw
ZXJuIHdyb3RlOg0KPiBZb3UgY291bGQgYXMgd2VsbCBhc2sgIndoZXJlIGFyZSB0aGUgZm9ybWFs
IHNlbWFudGljcyBvZiBhbiBMRkIgY2xhc3MgDQo+IGRlZmluZWQ/IiAgQWZ0ZXIgYWxsLCB0aGUg
Q0UgaGFzIHRvIHVuZGVyc3RhbmQgd2hhdCB0aGUgRkUgd2lsbCBkbyANCj4gd2hlbiBhc2tlZCB0
byBwdXQgYW4gaW5zdGFuY2Ugb2YgYW4gTEZCIGNsYXNzIG9uIGEgZGF0YSBwYXRoLg0KPiANCj4g
VGhlIGRlY2lzaW9uIHdlIHRvb2sgd2FzIHRvIG5vdCBmb3JtYWxseSBkZWZpbmUgc2VtYW50aWNz
LiAgU2VtYW50aWNzIA0KPiBhcmUgZGVmaW5lZCB0ZXh0dWFsbHkuDQo+DQo+IFRoaXMgaXMgdHJ1
ZSBvZiBMRkIgb3BlcmF0aW9ucy4gIEl0IGlzIGFsc28gdHJ1ZSBvZiBtZXRhLWRhdGEgDQo+IHNl
bWFudGljcy4gIFR5cGljYWxseSwgc29tZSBMRkIgd2lsbCBwcm9kdWNlIHRoZSBtZXRhLWRhdGEs
IHdpdGggdGV4dCANCj4gaW5kaWNhdGluZyB0aGF0IHRoZSBtZXRhLWRhdGEgaXMgc29tZSByZXN1
bHQgb2YgbWFuaXB1bGF0aW5nIGEgZmllbGQgDQo+IGluIGEgcGFja2V0LCBvciBhbiBlbnRyeSBp
biBhIHRhYmxlIHByb3ZpZGVkIGJ5IHRoZSBDRSwgb3IgLi4uDQo+IChZZXMsIHRoZXJlIGlzIHJv
b20gZm9yIGFtYmlndWl0eS4gIFdyaXRlcnMgb2YgdGhlIHRleHQgZGVzY3JpYmluZyANCj4gTEZC
IGNsYXNzZXMgbmVlZCB0byBkbyB0aGVpciBiZXN0IHRvIG1ha2Ugc3VyZSB0aGUgRW5nbGlzaCBp
cyBjbGVhci4pDQo+IEFuZCBhbm90aGVyIExGQiBtaWdodCBpbmRpY2F0ZSB0aGF0IGl0IHVzZXMg
c29tZSBwaWVjZSBvZiBtZXRhLWRhdGEgDQo+IGFzIGFuIGluZGV4IGluIGEgdGFibGUuDQo+IA0K
DQpBY3R1YWxseSBsb29raW5nIGZ1cnRoZXIgaW50byB0aGUgdGV4dCwgSSB0aGluayBpIGhhdmUg
Zm91bmQgbXkgYW5zd2VyDQppbiB0aGUgc2NoZW1hLiBBcmUgd2UgYm90aCBleGhhdXN0ZWQgb2Yg
dGhpcyB0ZXh0Pw0KVGhlIGRlZmluaXRpb24gb2YgdGhlIG1ldGFkYXR1bSBpcyBkb25lIGluIHRo
ZSBMRkIgY2xhc3MgKHNlY3Rpb24gNA0Kc2hvd3MgaXQpLiBZb3VyIGV4YW1wbGUgaGFzIDxtZXRh
ZGF0YURlZnM+IGFuZCBpdHMgdXNhZ2Ugd2VsbCBkb25lIGluDQpzZWN0aW9uIDguIFRoYXQgaGVs
cGVkLg0KSSB0aGluayBpdCB3b3VsZCBkbyBhIGxvdCBvZiBqdXN0aWNlIHRvIGhhdmUgdGhlIHRl
eHQgb24gbWV0YWRhdHVtIHRvDQpyZWZsZWN0IHRoZSBzaW1wbGljaXR5IGZvdW5kIGluIHNlY3Rp
b24gNC4gQSBjbGVhbnVwIG9mIHRoZSB0ZXh0IGlzDQpjZXJ0YWlubHkgbmVlZGVkLg0KDQpNb3Jl
IHN1Z2dlc3Rpb246ICBhZGQgc29tZSB0ZXh0IG9uIExGQiBjYXBhYmlsaXR5IG9mIG1ldGFkYXRh
IC0gbWF5YmUgYQ0Kc21hbGwgZXh0ZW5zaW9uIHRvIHlvdXIgZXhhbXBsZSBpbiBzZWN0aW9uIDgg
d291bGQgYmUgdXNlZnVsLg0KDQpjaGVlcnMsDQpqYW1hbA0KAAAAAAAAoIIRXzCCAyAwggKJoAMC
AQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgx
LTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05ODA4MjIx
NjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVpZmF4MS0w
KwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXguAHwTjTs
4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3wmgjHMxN
WTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8EaTBnMGWg
Y6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVxdWlmYXgg
U2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAEEzARgQ8y
MDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fYIyAQTzOY
kJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoGCSqGSIb2
fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1hdG54+CV
zCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv87n+iFlK1
Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3ODCCAz0w
ggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UEChMHRXF1
aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTA2
MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVs
IENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kgQ0EwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATDIsV2xDyt
30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUjZzTZFq2N
4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZvuSQ0E11y
YL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4lz36wOdN
Zn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+iC1HawJd
AgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0Vgaj7TdU
DDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3NlY3VyZWNh
LmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTADAQH/MA0G
CSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69tOkIP4Sg
DJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3jMfr900fX
ZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFYzCCBEugAwIBAgIKYSyUiQAAAAAABTAN
BgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24x
JzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wNjAzMjIyMjIyNDJa
Fw0xMjAzMjIyMjMyNDJaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jwb3JhdGlv
bjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQTCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAKvXqH/ah10uJc7YzQUh+XEDNqS6IsXOyqCtizr9x6F+v6iR
AbvddRRJRWixfV78qarSN9WMymJ90M8c9/Dfr1yzFuq95RgCAF3vdve3wKi7kJv6lkMJwyyB+uIY
cWtljYx2LDqbb9S6Z6He3q8W/aGKvu23I9ksNx+cmZcDNZwGdXVIEHpEMyA4bp0RvYtfp8BsGAyn
6YuK63HugeyYdeFL+4+Wz2tGUqw9OWhob6oV1oDH3zboLhHJiQ2oIj3jAJ3/LrIkzcWP2R20UIli
DAPAAl6MNWJPdsNK5EEeuxEuUSpdFsMj5rBmPHH4U8i8rUmi6GEOcX5rwAw64AzS3gECAwEAAaOC
AjUwggIxMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFAlpgTN7BnOPI0wKA9/3FoERghMFMAsG
A1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIBADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAf
BgNVHSMEGDAWgBQaxgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGsoIGphk5o
dHRwOi8vd3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFz
aWMlMjBQb2xpY3klMjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9z
aXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNybDCB4wYI
KwYBBQUHAQEEgdYwgdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRv
cnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNy
dDBsBggrBgEFBQcwAoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3NpdG9yeS9j
ZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0EuY3J0MA0G
CSqGSIb3DQEBBQUAA4IBAQCuNCnecJ+vDpXzsHOzMEyz4KgTNDbJROHag8H/ZVga7socoJyC+HKq
DfQgxifVorbTbSajCBEAxqg6bbNWBJ6qKOFHneBrXkENf5WdD50eCTCFWRV3EIsHEOQ1kP0eNYV5
Ed4hp9y6wASV6z2z86O4+qouLJiow4AIhoCKD8rEyD7ODgTvjvLCKpsVyPlG1jOVSsOSIF2VUmue
AmK3RFU4np83zerK/j0G37owhniEDT6ZhwkUd0XL45nt1m7yApMEbnXUTHNaXnE+P98kk3nDXdW2
5sB+5xWcYR3GpgMdQiZgP/f0KZ+yZKNE7gcp3I/O4pXqUNWIsLSYTi3soAR2MIIFjzCCBHegAwIB
AgIKbxPUggAAAAADuDANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50
ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0Eg
M0EwHhcNMDYxMDMwMTczMjQwWhcNMDkxMDI5MTczMjQwWjBJMRswGQYDVQQDExJEZWxlZ2FuZXMs
IEVsbGVuIE0xKjAoBgkqhkiG9w0BCQEWG2VsbGVuLm0uZGVsZWdhbmVzQGludGVsLmNvbTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAx0E8Yjepks3kSYx6il3czgdgDMG56PKqJ+PWV8U7YwSp
vWLxknVFP6AJAevwOuXNw9cvqTm25nkBschgh76fC7w6JCsFYzrdNPy9mbj4znMuSB41er3u0+TO
n1o3BD+Kr2YEZVvPTOkewIRL6YdiNLuvgai7PrVNmuw6R1h0k4sCAwEAAaOCAu4wggLqMAsGA1Ud
DwQEAwIHgDAdBgNVHQ4EFgQU7TMro2hBqE8Y+9Nz1mR1JJ2xGMMwPAYJKwYBBAGCNxUHBC8wLQYl
KwYBBAGCNxUIhsOMdYSZ5VGD/YEohY6fU4KRwAlngd69OZXwQwIBZAIBAzAfBgNVHSMEGDAWgBQJ
aYEzewZzjyNMCgPf9xaBEYITBTCByQYDVR0fBIHBMIG+MIG7oIG4oIG1hlRodHRwOi8vd3d3Lmlu
dGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5n
JTIwQ0ElMjAzQS5jcmyGXWh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29tL3JlcG9zaXRvcnkv
Q1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUyMDNBLmNybDCB7wYI
KwYBBQUHAQEEgeIwgd8waQYIKwYBBQUHMAKGXWh0dHA6Ly93d3cuaW50ZWwuY29tL3JlcG9zaXRv
cnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElzc3VpbmclMjBDQSUy
MDNBLmNydDByBggrBgEFBQcwAoZmaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3Np
dG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwSXNzdWluZyUyMENB
JTIwM0EuY3J0MB8GA1UdJQQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMCkGCSsGAQQBgjcVCgQc
MBowCgYIKwYBBQUHAwQwDAYKKwYBBAGCNwoDDDBTBgNVHREETDBKoCsGCisGAQQBgjcUAgOgHQwb
ZWxsZW4ubS5kZWxlZ2FuZXNAaW50ZWwuY29tgRtlbGxlbi5tLmRlbGVnYW5lc0BpbnRlbC5jb20w
DQYJKoZIhvcNAQEFBQADggEBAKJt6rY5eR3gkgKYAjFrfQU6gLSmW0grXZuDDllFuD9YSBdknV1v
Idu+3QUdpG0Yjw9SJf4tu+b8ydaYr4zp/x86WSMpdvBgol5kbY2FQwx55+Jl/hiRmfv1sfVsSAlb
TmNfxUvPVU5hI7kGbnuoUQp4jqblHyZz6w7to+mQVeUqBpTF2E7xIvMKLnGk8R2emvxMaGDoWY7k
rkZjZDofrlu1U2G8JeU+JDDk96Ks5LhROAU03QsE9VswMte+WNF9IUJhyjbBAxL2iJ2jCb7IOSc0
XL+i409/dFTZUnR7tUE4lEdMFY4aqIWUTd79gIlHReoRAipykasL7AEGuHxvHFoxggGQMIIBjAIB
ATBkMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jwb3JhdGlvbjErMCkGA1UEAxMi
SW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQQIKbxPUggAAAAADuDAJBgUrDgMCGgUA
oIGDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MDEwMjIyNDIy
MVowIwYJKoZIhvcNAQkEMRYEFKt4PEFLZIPE6Hd+6oHBnEzrBQtpMCQGCSqGSIb3DQEJDzEXMBUw
BwYFKw4DAhowCgYIKoZIhvcNAgUwDQYJKoZIhvcNAQEBBQAEgYC7QfVJDCdjGOgTRv6NfKs2ALq/
9zVkjLWqGsAdDvzJK/tW5myj2pjpXbED2vKarmLcnnlVW0k3rvN08teuaoFomIl8WwwBrZ6dRins
jPoVp+mpyUcolaqR98zofmXeHHUD/mjXCWEDIfJxdRFLBKZOe1yqNdCRQdhRxFFaPxKnRAAAAAAA
AA==