Subject: Re: WG draft Issues list

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Mon, 1 Nov 2004 22:04:27 -0800

Avri,

Some of these issues were already being discussed on the Protocol
mailing list. How would you propose we move forward with this ? Should
we continue the discussion on the protocol list or have the discussion
on the ForCES mailing list ? I wasn't sure...let us know your thoughts,

Thanks
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, November 01, 2004 8:30 AM
To: [email-masked]
Subject: [FORCES] WG draft Issues list

Hi,

An Issue tracker for ForCES is up and ready for use:

   http://www.mip4.org/issues/tracker/forces/

We have two drafts listed at the moment:

   draft-ietf-forces-model
   draft-ietf-forces-protocol

(more, like the applicabiilty draft can be added)

There is also an automatically updated WG drafts page for forces -

   http://www.mip4.org/other/drafts/forces/

Issues can only be entered from the web interface. You will have to
register to use the issue tracker.  This can be done on the web page.

The email interface is set up to pick up follow-ups containing
something like [Issue NN] from the [email-masked] list.
The list is setup to send notification of new issues to the Forces list
- though I don't think it is working at the moment.

Hopefully this will allow us make sure we catch all the issues with the
WG drafts.  The members of the two design teams have started entering
the issues we know of already.  This should be done, hopefully, in the
next few days.

My thanks go to Henrik Levkowetz for setting this all up.  Please let
me know if you have any difficulties with the system.

a.

---

From: [email-masked]
Date: Tue, 2 Nov 2004 01:10:11 -0500

Hi,

I don't know.  I suggest they be discussed in both places and elsewhere
as well.

Discussion on the list, will be folded into the issues database as long
as the [issue n] is in the header.  Of course just doing a reply will
be sufficient.

a.

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 2 Nov 2004 17:14:11 +0800

Hi all,

Below is some of the summary on the current debate on the 'path' , its usage
with the individual advantages:

1. Seems agreed that  a 'path' is a list of IDs and Indices (rathan than only
one 32 bit index as some might have thought). Therefore, the conclusion is a
path will be represented by a TLV like format.

2.  Seems agreed that the 'path' is composed of two pieces as:

        path := AttributeID <Index>+
(Jamal suggest to use some flags and count to more precisely represent it.
Because this belongs to the issue of  refinement,  just is skipped currently
here)
Where,
    AttributeID is an ID used to uniquely recognize different attributes in an
LFB, and will be defined during LFB definitions in the XML document (therefore
it's called a static ID by Jamal). Note that in a Query Message, path is also
used to query entities other than attributes,  including capabilities, and even
events, the AttributeID here also has a extensive meaning for IDs that represent
all entities operated, such as Capability ID, and Even Event ID( Weiming).
    An Index is used to index an entry of  a table, a array, and a structured
data type.  Because the data types can be recursively compounded, there is a
need for multiple level of indexing, which is represented as a list of indexes.

3. Two debated schemes to use the 'path' idea as below:

D1: To use a uniform 'path'  field in the Operation TLV in protocol to retrieve
all data (use query as example), as:

                OpTLV(value) := path <data>

Where, the 'path' is a TLV like format that includes AttributeID and Indexes,
and the two pieces are all MUST, even for attributes that are atomic, or tables
with few entires.

D2: To separate the 'path' into two pieces explicitly in the protocol definition
as:

                OpTLV(value) := AttributeID <Index(es)> <data>

The difference of D2 from D1 is, the AttributeID is MUST, while the <Index(es)>
is OPTIONAL in D2.  This means protocol users are allowed not to use Index to
retieve data from FE, but they definitely have to use AttributeID for it.
Because the <Index(es)> part is optional, it can be conceptually included in the
followed data field, which means the protocol will not explicitly define how the
Indexes are formated, leavine the model to do this just like other attribute
data.

Advantages for D1:

1) Can supply a direct and straight forward means for data retieving without
ambiguity.
 (Jamal, pls add more)

Advantages for D2:
1) Be more flexible to all kinds of attributes, where Index is not necessarily
needed, e.g., attributes of  atomic data type, of table or array with few
entries inside, especially for those attributes which do not originally have
indexes, like capabilities, events.
( I reviewed all of our discussions on the 'path' again (especially
Zsolt/Steve's Proposal for ForCES Data Encoding), just have a feeling that to
use Index in some cases, we really have a tradeoff for the complex Index
management. It seems Index will have to be assigned by CE, but capabilites and
events that originally exist in FE makes the assignment a total extra work for
CE to do).

2) Be clear in the architecture for LFB management. I think of the architecture
as below:

                                            LFB class
                                           /      \
                                    LFB Instance  ...
                                    /    \
                   Attribue ID   ...    ---- Above is the protocol layer
cared -----
                         /        \
Path to entry (Optional) ..        ---- Below is the model layer cared -----
                     /
               Entry

I see the artchitecture for D1 as:

                                        LFB class
                                       /      \
                                LFB Instance  ...
                                /        \
               Path to  entry   ...    ---- Above is the protocol layer
cared -----
                           /
                     Entry                 ---- Below is the model layer
cared -----

Best Regards,
Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 2 Nov 2004 07:14:34 -0500

> as the [issue n] is in the header.  Of course just doing a reply will

It is pointless really if that thing is going to capture all emails on
the discussion of a topic. We already have that in the form of archived
emails. I was hoping that its just a summary location to capture just
the start and the conclusion of the discussion. Emails are bad when a
thread is long because the essence is lost. I opened some of those
issues in order to capture them so they dont get lost 3 months from now.
I was hoping that at the end to close them with "resolution was reached
in the following way" - hoping discussions continue on the mailing list
(and not on that database).

cheers,
jamal