Subject: Re: [3]Re: path data textt update

From: Weiming Wang <[email-masked]>
Date: Mon, 31 Jan 2005 21:25:54 +0800

Joel,

----- Original Message -----
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: [3]Re: path data textt update

> I would ask at the same time whether you can live with a more restricted
> form of content addressing.

I actually agree that to use Key like restriction for  allocating FE's searching
ability would benifit FE implementation in some cases, as well as the protocol
appearance, but what bother me a little  when I think of it more, is:

1. seems a little redundant when we define the Keys.
Still take an example as:

table2: type array, ID = 4
elements are:
j1, type u32, ID = 10
j2, type u32, ID = 20

Now, if we allow j1 and j2 as KEYs, then I suppose the KEY definition might
become something like:

table2: type array, ID = 4
Keys are:
Key1, type u32, ID=1, Value=10     ; the Key1 value is the ID of j1
Key2, type u32, ID=2, Value=20     ; the Key2 value is the ID of j2
elements are:
j1, type u32, ID = 10
j2, type u32, ID = 20

Then we can use following format to delete  first 10 entries with j1=100, and
j2=200 in table 2, starting at index 10 as:

Path: IDCount = 1, IDs=4
SELECTOR :=
BLK_CNT_INDEX TLV = {10,10}
KEYINFO = {KEYID =1 KEY_DATA=100}
KEYINFO = {KEYID =2 KEY_DATA=200}

To check the Key definitions above, I just have a feeling that it more or less
shows a feeling of some repetitions, especially when in the cases where all
fields might have to be set as Keys.

2. In the cases where Keys are more than more FieldIDs to represent, it may also
makes the XML definition quite complex. For example,

table2: type array, ID = 4
elements are:
j1, struct SomeAdd, ID = 10
j2, type u32, ID = 20

where,
struct SomeAdd {
d1, type ... ID=1
d2, type ... ID=2
}

Now we need to limit  j1.d1 as the Key, then, the definition might become as:

Key1, type u32, ID=1, Value=10.1     ; the Key1 value is the subpath of j1.d1

I'm just still not very clear if it's easy or not to have XML to do this work.

I also noticed that you mentioned last time that it's may be impractical to use
things like property of "Search allowed" "Search not allowed" for FieldID
definitions, because above SomeAdd struct may be used by more than one LFBs.

To summarize my views on the Key, I just think there may lay some details to
address with the use of Key still, and if we can not find a better way for
searching restriction and still think it is quite necessary, I then can live
with the use of Key.

Yours,
Weiming

---

From: Weiming Wang <[email-masked]>
Date: Mon, 31 Jan 2005 22:34:00 +0800

Jamal,

Pls allow me to reply your two posts in this one, because I see the focus is the
same.

----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>
To: <[email-masked]>
Sent: Monday, January 31, 2005 4:05 AM
Subject: Re: path data textt update

>
> KEYINFO does not set any value; it is merely describing how to search
> and find what to delete.
I see the points now. I think it is the Message Type and the Operation TLV Type
together that will define "SET", "DELETE", or "QUERY"(which actually a find),
rather than the operations will be implied by KEYINFO or SUBPATHINFO.   When the
command is "SET", the SUBPATH-DATA defines the the fields and the data to be
set. When the command is a "DELETE" or "QUERY", the SUBPATH-DATA or the KEY-DATA
can  then be used as a content searching fields and matching data. Anyway, I
think SUBPATH is only an expression instead of an operation, and a KEY is only a
special field for searching.

> KEYINFO = {KEYID =2 KEY_DATA=200}

I think your above expression actually fit for following table field definition:

Instead of:
> j1, type u32, ID = 1
> j2, type u32, ID = 2

I'm afraid if you have a different understanding of KEY definition as:

> j1, type u32, ID = 1, searchKey="YES",
> j2, type u32, ID = 2, searchKey="YES",

This was a method I ever proposed before, but just being pointed by Joel of some
practical problem (when some fields may be globally defined, which makes it hard
to do so). I'm quite sure that Joel's current Key idea is not as above.

To use a subpath to define above operation to include the KEY is also possible,
as:

OpTLV Type="Delete"            ; note this limits the followed subpath-data is
not for setting values.
 Path: IDCount = 1, IDs=4
 SELECTOR :=
 BLK_CNT_INDEX TLV = {10,10}
 SUBPATHINFO TLV V = {IDcounts(1), IDs(1), Data(100)}   ; here, ID=1 points to
the Key1 field
 SUBPATHINFO TLV V = {IDcounts(1), IDs(2), Data(200)}   ; here, ID=2 points to
the Key2 field

Apart from adding IDcounts, the format is actually identical to KEYINFO TLV.

Cheers,
Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 2 Feb 2005 00:04:36 -0500

A typical key declaration would be in the array declaration.
For example, suppose we have
    structure foostruct
        ipv4address: id = 1, type = bytestring4
        ipv4prefixlength: id = 2, type = integer 0..32
        addressmatchclass: id = 3, type = int
        assoicatedinfo: id = 4, type = somestructure

Then in some LFB we have an array declaration
     lfbtable: id = 1, array, variable,
        type = foostruct
        key akey: keyid = 1, ipv4address, ipv4prefixlength
declares that the array has a key, made up of the ipv4 address and ipv4 
prefix length.  And the keyid for this key is 1  (The name akey is just for 
human consumption).
If there is another unique field or field combination that can be used as a 
key, that would be an additional key line.  Maybe somestruct has a entryid 
field, so we get
        key bkey: keyid = 2, associatedinfo.entryid
assuming that entryids are unique.

There is no need to declare the type of the key because the key is not a 
field distinct from those within the structure of the array 
element.  Rather, the key is a declaration about information within that 
structure.

Thus, when one finds a path that references lfbtable, with content keying, 
then if one finds keyid 1 in the keying TLV, the FE knows that the 
reference is to the ipv4address and prefix length, and that the data will 
be the combination of those two fields as if they were a structure.  If the 
keyid in the TLV is 2, then the FE knows that the entryid is being used, 
and that the information is whatever type entryid was declared with.

The use of the keyid in the array declaration means that in this array, the 
field or field combination declared as a key will never be duplicated 
across entries within the array.

Does this make more sense?
(Translating this into the XML is pretty easy, once we have agreed on the 
meaning.)

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 2 Feb 2005 10:12:18 -0500

I think that there are only three operations at the moment:
GET
SET
NOTIFY

In terms of the format I presented, the structure of these operations is as 
follows.
A GET request includes one or more base path TLVs and each may include one 
or more nested path TLVs.  Each path TLV may include a KEY TLV for content 
selection, where the data in the key TLV is the value of the selected key 
field.
A GET response will look like a GET request, with DATA filled in along with 
each terminal PATH TLV.

A SET request include one or more base path TLVs each of which may include 
one or more nested path TLVs.  Each Path TLV may include a KEY TLV to 
indicate which element of the table is being selected, where the data value 
in the KEY TLV represents a value being sought.  Flags indicate what should 
happen if the selected entry (index or content selected) is not found.  The 
flags can allow or prohibit creation of an entry that does not exist, and 
allow or prohibit modification of an entry that does exist.  (The 
combination must not create and must not modify is not particularly useful.)
Each terminal path TLV will also have a data block providing the 
information that is to be placed into the selected element.
The selected element may be the whole item identified by a key.  It may be 
a field in the structured identified by a key.

There are a couple of interesting cases to be covered.
1) It would be nice to be able to say "create, and give me an index".  This 
would be a case where no index and no key is provided, but a single element 
is being created.  It would seem that we can cover this with the 
flags.  The returned result will include the information as to what index 
was assigned to the value
2) Any create operation in a table must be checked by the FE logic to 
ensure that all key values of the new data content are unique in the 
table.  This is a consequence of the requirement that keys be unique.  This 
applies whether the create is using indexing or content keying to identify 
the new value.
3) Similarly, any modify operation that modifies a table key must be 
checked by the FE to ensure that uniqueness is met.
3') The corollary to the above is that swapping the key values between two 
entries may be a little tricky.  If both SETs are in the same OPERATION TLV 
should we require the FE to be smart enough to realize that the values are 
unique after both changes?  Or should we require that one of them get 
changed to an unused value first?
4) It is perfectly valid to specify a create operation for an entire entry 
in a table, and specify a key.  Depending upon flag settings this will 
either ensure that the key is not used, or allow overwriting of the entry 
if it is already there.  It is actually valid for the data being written to 
have a different (but still unique) key value.  (It would probably only be 
useful in a modify operation.)  Said another way, changing keys on entries 
is allowed as long as uniqueness is preserved.

Yours,
Joel

PS: No, I did not talk about Notify.  I expect it looks a lot like a GET 
response, but I have not thought about it much.

At 08:34 AM 2/2/2005, Weiming Wang wrote:
> > What about SET | REPLACE? This is not DEL or QUERY ....
> > Example: "replace all entries which match key1=10 with 1111"
> > or "for all entries with KEY1=10.0.0.24/32, replace table.nh with value
> > 3"
> >
> > I think these are valid operations - therefore search key needs to
> > be represented separately from subpath and should not have dependence of
> > what the msg type is.
>I'm afraid You'v raised a very good point that we need to address 
>specifically,
>that is, how a MODIFY/REPLACE operation will affect our current BNF. 
>Obviously a
>MODIFY operation usually needs to include two data parts in the message: 
>the old
>data(or condition), the new data. I now understand what you are trying is 
>to use
>the KEY to specifically INDICATE it is the old data (or condition) part. I
>understand more that this kind of INDICATE is actually realized by the type in
>the "KEYINFO TLV" T. In another word, I can say that the "KEYINFO TLV" is
>specified for the old data (or condition) only. With this thought, I 
>suppose you
>may also mean every field in an LFB attribute can be a KEY, because every 
>field
>can probably be replaced/modified.
>
>As a result, I have to say yes, such KEYINFO TLV is necessary, or in another
>word, should be separately expressed in BNF, but I also have to say the data
>format for the KEYINFO TLV is actually the same as the general PATH-DATA 
>format,
>that is, the KEYID there is actually a subpath instead of only a KeyID.
>
>Now come back to the KEY idea Joel proposed. I think a best way to say Joel's
>idea is "not all subfields are allowed as searching indices". I'm sure 
>this kind
>of Keys are only a subset of keys used in the KEYINFO TLV for MODIFY/REPLACE
>operations, because as I mentioned above, we should allow all writable 
>fields in
>an attributes replacable, though we not allow some fields as searching 
>indices.
>As a result, to better solve this, I'm afraid we need to see how KEYINFO TLV
>should actually be composed. My idea is, for MODIFY operations, the old 
>data (or
>condition) part may include general subpath-data, as well as KEYs as Joel
>proposed.
>
>I'm keeping thinking of this ...
>
>Cheers,
>Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 2 Feb 2005 10:37:46 -0500

On Wed, 2005-02-02 at 08:34, Weiming Wang wrote:
> I'm afraid You'v raised a very good point that we need to address specifically,
> that is, how a MODIFY/REPLACE operation will affect our current BNF. Obviously a
> MODIFY operation usually needs to include two data parts in the message: the old
> data(or condition), the new data. I now understand what you are trying is to use
> specified for the old data (or condition) only.

Indeed.
The selector is essentialy a set of *filters* to refine the path towards
the data.
- field and index dont require any extra computation i.e the map reads
"go left, turn right, go left and at the stop sign is where the treasure
is found"
 vs
- keyinfo requires computation at the FE to draw the map i.e "go left
onto the freeway, every time you see a green sign reading Weiming turn
left to get to the treasure repeat this until you see a red sign which
reads Joel"

We are saying the selector can have both path filters. We are also
restricting what keys(green, red) can be used.

>  With this thought, I suppose you
> may also mean every field in an LFB attribute can be a KEY, because every field

Well, thats where we started ;->
But since keyinfo is now restricted to a few things in the LFB ..
This is why i asked you in one email if you changed your position ;->
 
> format for the KEYINFO TLV is actually the same as the general PATH-DATA format,

But then i see this as a contradiction with key restriction.
Of course it could be done, all you would need is the flag to say "this
subpath is a search";

> idea is "not all subfields are allowed as searching indices". I'm sure this kind
> operations, because as I mentioned above, we should allow all writable fields in
> an attributes replacable, though we not allow some fields as searching indices.
> should actually be composed. My idea is, for MODIFY operations, the old data (or

Joel?

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 2 Feb 2005 10:42:31 -0500

I think there are two very separate questions.
Structurally, all fields need to be writeable.  (Certain LFB definitions 
may make some fields read only, and some implementations may make 
additional fields read only, but that is handled by capabilities and 
errors, not by protocol structures.)
However, "searching" (key fields) needs to be carefully restricted. 
"Searches" must match 0 or 1 element (keys must be unique) and both the CE 
and the FE must know what is expected with regard to supported keys 
(predeclaration, plus possibly some capability information.)

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 2 Feb 2005 11:15:51 -0500

> A GET response will look like a GET request, with DATA filled in along with 

Whatever the dump coming back is, it should be a syntacticaly legit
SETable view. i.e i should be able to s/GET/SET and have valid format
that i can shove at the FE.

> information that is to be placed into the selected element.

Should be noted that given an LFB definition, a receiver of a path -
once derived(eg computed from content key) should be able to
decode/encode data to such a path target.
Wasnt sure if "terminal" would be the right term in this case since it
could be a full tree at the hierachy root (example table)or a leaf
(example a cell in a table). Maybe a "path target" would be more
descriptive. 

> is being created.

IMO, This should be possible with current grammar. If you create entry
at a table for example, you dont need to specify the IDXINFO.i.e  path
is tableid. FE gives you the next available Index

> It would seem that we can cover this with the 

We do have flags in the main header already that cover this.
You can ask for a brief response back (which will just give you an ACK)
or 
a verbose response which will give you things like the full created
info.
Unless you want to refine this further and move it to the operation
flags.

> applies whether the create is using indexing or content keying to identify 

I would say this is a necessary part of boundary/error checking. Any
implementation that doesnt check for bounds is problematic - i wouldnt
call it a interop issue. 

> changed to an unused value first?

Not sure i followed this one:
Are we talking atomic transactions? If they are independent
transactions, why care?

> is allowed as long as uniqueness is preserved.

You have a path and a selector. Together they tell you how to get to the
data. Why would you want to introduce information that is not used?
In the case of content based table, the KEYINFO will refine which entry
is of interest and the DATA will overwrite the key value in the table if
needed.

Theres another one:
In some cases it may not make sense to create. Example - you can modify
a table cell but you cant create it --> it has to exist. Its existence
is dependent on a row being created first. The other approach would be
to intepret the creation of the cell as an implict creation of the row.
I prefer the former because it simplifies the logic.

cheers,
jamal

---

From: Alistair Munro <[email-masked]>
Date: Wed, 2 Feb 2005 17:29:20 +0000

Hi All,

>> I think that there are only three operations at the moment:
....
> that i can shove at the FE.

I would like to see this.

Do we not need sequence( or request/action?) ids and stuff like that per 
operation to accommodate timeouts and FE failures/refusals, and link 
transactions across multiple FEs? Apologies if I missed this but the path 
data exchange got a bit involved and I nodded off.

Regards,

Alistair

--
Alistair Munro,
Principal Engineer, U4EA Technologies Ltd.
City Point, Temple Gate, Bristol, BS1 6PL, U.K.
E-mail: [email-masked]
Tel: (work) +44-117-373-6765, (home) +44-1275-462707, (mobile)
+44-7974-922-442;
Fax: +44-117-373-6751
Web: http://www.u4eatech.com

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 2 Feb 2005 12:52:50 -0500

Alistair,

> data exchange got a bit involved and I nodded off.

The main header's seq number is intended to cover the transaction of all
operations within a message.
I would say the combo of the FEID+LFBID+instanceID+sequence number
should provide sufficient corelation data to maintain state and handle
atomicity of a transaction across FEs. At least for unicast FEID it is.
For Multi/Broadcast FEIDs an extra state corelation in my opinion would
need to be maintained at the CE LFB level.
Not sure if i am on target for what you were asking.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 2 Feb 2005 12:42:56 -0500

All we are saying here (assuming the simple case where there are no errors) 
is that
we start with a GET operation TLV.  It contains a collection of PATH-DATA 
TLVs that identify items of interest.
we get a GET-RESPONSE operation TLV.  It contains a collection of PATH-DATA 
TLVs for those same items, which include the actual data that was request.
The arrangement of the PATH-DATA TLVs and the data within them is such that 
if you replace the GET-RESPONSE code with a SET code, the contents of the 
GET-RESPONSE are valid contents for a SET request to set the identified 
items to the values that they had.  (Of course, if you do it immediately 
nothing will happen since those are the values.  But if you changed things, 
and then did the set, you would get what you expect.)

The are caveats o course.  Some of the elements may not be writeable.  If 
content keying is used and keys have changed, then there may be no targets 
for some sets.  Jamal's point was not that it must always work, but rather 
that syntactically the structure should be the same.
Which it should.
And which I believe it is with the structure we are discussing.

Yours,
Joel

---

From: Weiming Wang <[email-masked]>
Date: Wed, 2 Feb 2005 21:34:25 +0800

Jamal,

----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>
Subject: Re: path data textt update

specified for the old data (or condition) only. With this thought, I suppose you

Cheers,
Weiming

---

From: Robert Haas <[email-masked]>
Date: Fri, 4 Feb 2005 18:15:59 +0100

Joel M. Halpern wrote:

>
>
> The use of the keyid in the array declaration means that in this 
> array, the field or field combination declared as a key will never be 
> duplicated across entries within the array.
>
I'd argue against forcing the uniqueness of the content keys. For 
instance, it is useful to be able to change in one shot the DSCP-marking 
of all classification rules matching packets from a certain origin (= 
the non-unique key).

In order to uniquely address an entry, its index should be used, for 
which ForCES can and will guarantee uniqueness,  unlike content keys 
that depend on the actual data.

Regards,
-Robert

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 4 Feb 2005 12:21:18 -0500

This seems to require that the FE be able to search its tables for 
arbitrary information.
Given that the CE has the knowledge, and has the more powerful environment, 
I am inclined to think it is more sensible to make the CE do the work.

Yours,
Joel

At 12:15 PM 2/4/2005, Robert Haas wrote:
>Joel M. Halpern wrote:
>
>>
>>
>>The use of the keyid in the array declaration means that in this array, 
>>the field or field combination declared as a key will never be duplicated 
>of all classification rules matching packets from a certain origin (= the 
>non-unique key).
>
>In order to uniquely address an entry, its index should be used, for which 
>ForCES can and will guarantee uniqueness,  unlike content keys that depend 
>on the actual data.
>
>
>Regards,
>-Robert

---

From: Alistair Munro <[email-masked]>
Date: Fri, 4 Feb 2005 17:31:46 +0000

Hi Jamal,

> Not sure if i am on target for what you were asking.

Fine, thanks, on the identification side. I can see the mechanisms in place 
even if they need to be filled in a bit.

Not so fine on the atomicity issues, because I'm not so clear about the 
possible combinations of the operations delimited by the sequence number in 
the "main header", nor about how the all-or-none is achieved.

My references are your e-mailed documents: config+response.txt (12/20/2004) 
and data_path2.txt (02/03/2005) - are these the ones I should be reading?

I don't see (from config+response.txt) how rollback and commit functions 
are achieved. There is a lot of mention of 2-phase commit but I haven't 
been able to identify the phases from the description so far.

I wondered also about recovery, but I don't see any mention of this.

Please point me to anything I missed, and I don't want to disrupt the 
current thread with this (orthogonal) issue.

Regards,

Alistair

---

From: Robert Haas <[email-masked]>
Date: Fri, 4 Feb 2005 19:13:13 +0100

> This seems to require that the FE be able to search its tables for 

I did not mean arbitrary information: this information would have to be 
declared as key too. Only that such keys are not necessarily leading to 
an always unique match.

> Given that the CE has the knowledge, and has the more powerful 
> environment, I am inclined to think it is more sensible to make the CE 
> do the work.

This is a tradeoff between protocol efficiency vs complexity imposed on 
the FE, clearly.
I certainly agree that the mere fact of supporting complex content 
search keys does not improve protocol efficiency (the CE can do the SQL 
work and figure out the index of the entry to set, instead of asking the 
FE to do this), and in fact it worsens FE complexity.
But I see gains in protocol efficiency if a SET operation for multiple 
matching entries can be executed with a single PATH/SUBPATH vs as many 
PATH/SUBPATHS as there are entries to be changed.

Irrespectively of whether keys lead to unique matches or not: if a 
search is done on a content key for which the underlying LFB does not 
implement efficient lookup (i.e., it must traverses all 100k entries to 
find the matching one), then trouble is on the way. Do we assume here 
that the only allowed content-search keys are the well-known datapath 
keys for which lookup is (anyway) optimized ?

Regards,
-Robert

>>> array, the field or field combination declared as a key will never 
>>> be duplicated across entries within the array.
>>
>> instance, it is useful to be able to change in one shot the 
>> DSCP-marking of all classification rules matching packets from a 
>> certain origin (= the non-unique key).
>>

-- 
Dr. Robert R. Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 4 Feb 2005 16:54:24 -0500

Hi Alistair,

> the "main header", nor about how the all-or-none is achieved.

I suppose this is as good time as any to discuss this - I was hoping we
could get the datapath stuff out of the way first.

There are two schools of thoughts which are being tossed around. We try
to support both and leave the details to implementation (the
intelligence is at the CE).

1) The CE knows exact details about the resources at the FE (memory
etc). When it says "ADD" it knows that would work etc. In this scenario,
it is contended by the proponents of this optimization that when a CE
decides to send a command to an FE it will work %100. so the all or none
compute is done at the CE. 

2) the classical 2pc scheme; undo/rollback when things go wrong. undoing
happens by the CEs orders after an error response from any one FE being
synchronized is received.

I believe #2 is the scenario you are asking about, correct?

A 2 phase commit starts with a START | ATOMIC flag on its first message
of a transaction. A transaction may span multiple messages. Its up to
the CE to keep track of the different seq #s making up a transaction.
This may then be followed by more messages which are part of the same
atomic transaction.
The transaction terminates with an empty DONE msg type.
It is expected that any failure of resources would be detected before
the DONE msg is sent from the CE. i.e once the DONE is issued it is
expected that the FE will succesfully install the policies i.e the
commit will succeed. 
We may also need an ABORT message or maybe a done with an ABORT flag
to undo.
Does this sound sensible?

> and data_path2.txt (02/03/2005) - are these the ones I should be reading?

I think those two will pretty much get you into the thick of it (as far
as current discussion level is). I try to track state in those two so we
avoid conflict about what was said or agreed on later (which has slowed
us down in the past).

> been able to identify the phases from the description so far.

a lot of email exchanges on the list but nothing captured in a doc.
I will update as the discussions take effect.
Also a lot of deferal for later discussion trying to shoot the big 
issues first.

> current thread with this (orthogonal) issue.

We can certainly proceed with this as well.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Sat, 5 Feb 2005 16:39:06 +0800

Joel,

With theGET-RESPONSE and the SET-RESPONSE  in mind, I think of a possible
limitation by use of the format:
DATA := [DATARAW] | <PATH-DATA>+
because this format excludes the format instance as "data, nested path-data,
data". I just think this format instance is necessary for easy RESPONSE, i.e.,
just let added response data packed at the end of the data.
Based on this thought, I think if we should expand the above format to:

DATA:=  [DATARAW]  <PATH-DATA>*  [DATARAW]

Moreover, if we allow chained DATARAW TLVs format, then it is better with the
format:

DATA:=  <DATARAW TLV>*  <PATH-DATA>*  <DATARAW TLV>*

because I think the chained DATARAW TLVs may be more efficient than ested TLVs
in DATARAW  TLV here.

Cheers,
Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 5 Feb 2005 12:19:58 -0500

I believe that the case you want is already covered.  And the nesting makes 
the applicability clear.

For the operations that include data (SET Request and GET Response), the 
PATH-DATA information will include a DATA TLV.  If we have fully identified 
the target of the operation, then the DATA will be a DATARAW.
If we have not yet fully identified the target, then the DTA will be one or 
more PATH-DATA items, each of which will contain a DATA TLV.  Thus, these 
DATA TLVs can and will in turn contain either DATARAW or further 
elaborating PATH-DATA, such that eventually, down each branch, one arrives 
at a DATARAW.

If the reason for the second DATARAW was to handle some other case, then I 
am sorry but I do not know what that is.

Yours,
Joel M. Halpern

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 7 Feb 2005 10:53:56 -0500

I believe the example from Weiming is a corner case that is not needed
in the majority of the cases.

Could this not be achieved some other way example by having multiple
path-datas with data in them?
I have intentionaly avoided making the DATA lvalue a TLV; this is to allow
for some efficiency - by making it a TLV it means we always have
to have a DATARAW TLV encapsulated by a DATA TLV and none of the
examples (which in my opinion cover the majority of possible uses)
so far have needed it.

Again heres the BNF as described so far:

-------
i )  A TLV will have the word "TLV" following it
ii)  <> encloses a _mandatory_ component
iii) [] encloses an optional component
iv)  + implies "one or more"
v)   Missing <> or [] implies a literal/terminal

TODO: Fix this later to conform to the ABNF described in RFC 2234.

OPER TLV : = <PATH-DATA>+
PATH-DATA TLV := <PATH> [DATAINFO]
PATH := flags IDcount IDs 
DATAINFO := [SELECTOR] [DATA]
SELECTOR :=  [BLKINFO] | [KEYINFO] 
DATA := [DATARAW] | <PATH-DATA>+
KEYINFO TLV := KEYID KEY_DATA
BLKINFO TLV := [BLK_RANGE_INDEX] | [BLK_LIST_INDEX] | [BLK_CNT_INDEX]
DATARAW TLV := encoded data which may nest DATARAW TLVs
--

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 7 Feb 2005 15:13:39 -0500

An alternative thought:
Would it be acceptable that a DATA TLV will only be needed in the 
scenario when someone wants to nest either DATARAW or PATH-DATA?
I am not sure how to represent that in the BNF. I am also willing
to go on the DATA TLV always if this is going to cause any ambiguities
or is going to speed up progress so we can put closure to things.
I cant say i am thrilled with it though.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 7 Feb 2005 17:26:33 -0500

I actually think we could get away with:

DATAINFO := [SELECTOR] [<DATARAW> | <PATH-DATA>+]

and just leave out the "DATA" line.  I believe this allows the nesting, is 
decidable by the parser, and does what we need.

we can in fact collapse further in the BNF to:

PATH-DATA TLV := <PATH> [SELECTOR] [<DATA>+ | <PATH-DATA>+]

The length of the PATH-DATA TLV will keep us from falling off the end 
looking for something that is not part of this TLV.
If we treat an omitted SELECTOR as a single item selector, we can then 
state the rules.
On a SET Request or GET Response (or a verbose SET response) every 
PATH-DATA TLV must have a number of DATA or PATH-DATA TLVs equal to the 
number of "selected" items.
On a GET request each PATH-DATA TLV may have a number of PATH-DATA TLVs 
equal to the number of selectors, but must not have a DATA TLV.

If we want to allow the special case of mapping data across a selector, we 
could allow a selector of count greater than 1 and 1 DATA or PATH-DATA 
TLV.  I would prefer not to allow that.  But some of the examples have 
suggested it, and it is at least syntactically well formed.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 8 Feb 2005 06:59:25 -0500

You raise an interesting question of where the element by element SET 
results go.

One of the drawbacks of allowing multiple path-data elements inside a 
operation TLV is that it no longer suffices to return the response code at 
the operation TLV level.
Therefore, I would presume, we will have to return the response codes in 
the individual path-data TLVs.
I would not want to return the results as a separate parallel TLV, as that 
would imply some kind of matching that would get quite confusing.  I 
suppose that means that the actual syntax becomes:

DATAINFO := [SELECTOR] [<PATH-DATA>+ | <DATARAW>+ | <SETRESULT>+]

Where SET Result is used only in the response to a SET, and occurs where 
the DATARAW elements were in the set request, indicating for each dataraw 
whether it was successfully set.

Yours,
Joel

At 11:22 PM 2/7/2005, Wang,Weiming wrote:
>It quite gets to me that the list server often ate my posts. I do have 
>sent some mails but that cann't be seen on the list till now.
>
>Hopefully  this post can work.
>
>From: "Joel M. Halpern" <[email-masked]>
>Yes, this makes it more clear, but I still see the value to modify it to:
>
>PATH-DATA TLV := <PATH> [SELECTOR] [<PATH-DATA>+] [<DATA>+]
>
>I suppose  a SET request that has format as "path path-data1 path-data2 
>path-data3", whos response will have format as "path path-data1 path-data2 
>path-data3 data", the last data TLV is for the SET result responses.
>
>Cheers,
>Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 8 Feb 2005 09:16:08 -0500

I am not sure i got the SETRESULT; going by what Weiming asked for
earlier, we have the following facilities:

To set data to a 3-deep path offset:
path-data
	path1
	optional selector
	path-data
		path2
		optional selector
		path-data
			path3
			optional selector
			dataraw

If a response is asked back, thats exactly how the response would look
like as well.

The other way which is to set data on multiple nested paths:

path-data
	path1
	optional selector
	dataraw
path-data
	path2
	optional selector
	dataraw
path-data
	path3
	optional selector
	dataraw

Granted the end result will be grossly ineefficient since it will have a
lot of redundant information in the three path-datas above if path1 is
relative to path2 and path3 is realtive to path2.
For this we can use what i have seen in a few classifiers as an
optimization; these sorts of classifiers hacve a  "continue" construct
which translates to "continue looking up where you last left off".
We can have something similar as a flag - so on path2 and path3 it would
say "the previous path+selector counts as part of this path". So path1 +
its selectors will be part of path2+ its selectors, which is also part
of path3 and its selectors. Clearly the flag is not useful on the first
path-data it involves inheritance and can be ignored there.

Heres my worry: I think what Weiming wants in this case is a corner case
which while we must satisfy the end result should not break the simple
design rule of "optimize for the majority"

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 8 Feb 2005 11:08:49 -0500

The question I think we need to cover is "what happens if some of the SETs 
work, and some do not."

Given that the values are known by the requestor, I can not see any point 
in returning the dataraw elements in the SET response.

So I am suggesting that each dataraw in the request is replaced in the 
response with a success code.

For a GET response, get elements which succeed would have a dataraw, while 
those which fail would have a result TLV indicating what the problem was.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 8 Feb 2005 11:59:31 -0500

In the main header we have flags for this - if need be we can move some
of them to the path flags. Attached the text from earlier.

Refer to section which reads "Responses"; i really dont wana distract
the current discussion until we put closure to it, so if you think we 
oughta move the response flags in, we could although i think it will
introduce complexity. Maybe we should defer this discussion?

cheers,
jamal

---

From: Alistair Munro <[email-masked]>
Date: Tue, 8 Feb 2005 17:03:57 +0000

Hi Joel, all,

> The question I think we need to cover is "what happens if some of the
> SETs work, and some do not."

If we are going to be strict about commitment then the entire collection 
should be undone if any component fails. Is this being too severe?

Regards,

Alistair

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 8 Feb 2005 12:08:30 -0500

The last discussion I can recall about atomicity / rollback seemed to end 
up with:

Under normal circumstances multiple requests in a PDU can be performed / 
succedd / failed individually.
There would be flags to define transaction boundaries to allow a collection 
of requests to succeed / fail together, and this would cross PDU boundaries.

Yours,
Joel

---

From: "Wang,Weiming" <[email-masked]>
Date: Wed, 9 Feb 2005 14:50:12 +0800

Hi Jamal,David,Joel,et al,

I think Joel cought my worry well. It's really not a courner case. Maybe I can simplify my worry as where eventually we can put the 'Set Result" response in the BNF? Is it in the Dataraw along with the original set Dataraw? Now we have more than one Path-Datas nested, my suggestion is, instead of allowing separate 'Set Result" response in individual Dataraws in these Path-Datas, we even need a general 'Set result' response for all these Path-Datas which is nested in one top level Path-Data.

Pls allow me to use an example to show. Note that this example is different from the case Jamal's example is for. We show here is only a plane table rather than a nested table. 

 j3, type u32, ID = 3
 j4, type u32, ID = 4

Now, the configure task is: to set the j1 to 100, and j2 to 200, j3 to 300, and
remain j4 as it is,  for  Index of the table (1, 3, 5, 7, 9).

We can setup a Set message for this task as below: 

Op=Set
Path(4) IndexTLV(1,3,5,7,9) path(1)-Data(100) path(2)-Data(200) path(3)-Data(300)

Two ways to the Response to this Set message:
1.
Op=SetResponse
Path(4) IndexTLV(1,3,5,7,9) path(1)-{Data(100),DataSetResult} path(2)-{Data(200),DataSetResult}  path(3)-{Data(300),DataSetResult} 

2.
Op=SetResponse
Path(4) IndexTLV(1,3,5,7,9) path(1)-Data(100) path(2)-Data(200) path(3)-Data(300) DataTLVforSetResult

I just think that the 2 is more efficient.

Cheers,
Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 9 Feb 2005 07:06:50 -0500

There are actual several aspects to this example.

1) I do not think that SET responses need to carry the DATARAW.  The CE 
knows what it sent.
1') Therefore, I would think it suffices to replace the DATARAW with the 
SETRESULT TLV.  If we really want the data shipped back, we can put it 
inside the SETRESULT.
2) This particular example shows the combination of multiple target paths 
and multiple instances.  This cross mapping creates two problems such that 
I would strongly prefer not to do this.
2a) The FE in processing this request has to realize that the multiple 
inner path-data elements are not intneded to be used one each for he 
selector targets, but rather are all supposed to be used for all the 
selector targets.  This is actually a behavior (7) which I did not describe 
in my earlier note because it seems undecidable.
2b) Even if we used the simpler case that correspond to case (6), where all 
that is being set was j1 in each selector target, there is still a problem 
of how the result is returned.  The only thing I can see to do is for the 
FE to explode the single PATH-DATA into a collection of PATH-DATA, as many 
as the selector elements, to hold the SET RESULTS.  The complexity of this 
result is part of the cost of behaviors (3) and (6).

Yours,
Joel M. Halpern

At 01:50 AM 2/9/2005, Wang,Weiming wrote:
>I think Joel cought my worry well. It's really not a courner case. Maybe I 
>can simplify my worry as where eventually we can put the 'Set Result" 
>response in the BNF? Is it in the Dataraw along with the original set 
>Dataraw? Now we have more than one Path-Datas nested, my suggestion is, 
>instead of allowing separate 'Set Result" response in individual Dataraws 
>in these Path-Datas, we even need a general 'Set result' response for all 
>these Path-Datas which is nested in one top level Path-Data.
>
>Pls allow me to use an example to show. Note that this example is 
>different from the case Jamal's example is for. We show here is only a 
>plane table rather than a nested table.
>
>Path(4) IndexTLV(1,3,5,7,9) path(1)-{Data(100),DataSetResult} 
>path(2)-{Data(200),DataSetResult}  path(3)-{Data(300),DataSetResult}
>
>
>2.
>Op=SetResponse

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 9 Feb 2005 08:12:47 -0500

Weiming,

I just noticed that Joel responded on another email so i will follow up
there. Question:
Other than these new issues; is the BNF good for what you wanted?
Are you happy it can do path data interleaving that is sufficient for
what you want. If the answer is yes, that would be one chapter we can
close. 
Please respond when you get the time (I think I know where Joel stands).

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 9 Feb 2005 08:36:33 -0500

> SETRESULT TLV.  If we really want the data shipped back, we can put it 

We already have a verbosity flag on the main header that i posted on
earlier; a request for a verbose response indicates desire to have
DATARAW sent back.
i.e in a response to a config/set you get a configresponse/set with only
thing being different is the configs when the set is echoed back.

Is using the SETRESULT going to reduce the number of bits on the wire?
Reading Weimings example i see in fact it uses more bits than just
echoing back the the set operation (but that maybe unintended).
Does SETRESULT provide more simplicty than what we already have?
If i read Weiming correctly he wants to move this request flag into the
path flags. Thats going to create complexity IMO.

> result is part of the cost of behaviors (3) and (6).

Or to just echo back the operation on success when verbosity is
requested, no?

cheers,
jamal

> >Hi Jamal,David,Joel,et al,
[..]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 9 Feb 2005 09:28:02 -0500

If we adopt an "all or none" rule for SETs in a single operation TLV, then 
we don't need the SETRESULT TLV.
However, our current approach is that each inividual SET may succeed or 
fail individually.
In that case, the results must somehow indicate which ones succeeded and 
which ones failed.

The obvious place structurally to put the success or failure is with the 
indivdual item that succeeded or failed.  Which is why I am suggesting 
replacing the DATARAW items in the request with the SETRESULT in the 
response.  If the request wanted verbose response, then the DATARAW should 
be included inside the SETRESULT.

(As an aside, could someone explain the value of a verbose set response.  I 
seem to have missed the use case that motivates it?)

Thank you,
Joel

At 08:36 AM 2/9/2005, Jamal Hadi Salim wrote:
> > > > > I would not want to return the results as a separate parallel 
> TLV, as
> > > that

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 9 Feb 2005 10:58:56 -0500

I think it is safe to say we have moved on to a slightly different
discussion. So i changed the subject slightly.

> In that case, the results must somehow indicate which ones succeeded and 

Ok, Good point.
My take so far has been the granularity for atomicity at the operational
level. Within one operation theres an implicit all or none view and that
if you are sensitive about this then you will split things into
different operations (which maybe of the same type). However, I think
this may be insufficient.

> be included inside the SETRESULT.

Theres several verbosity levels to this:

1a) I may not care at all about the SET result. 
1b) Or i may care only to know if it got at the other end. In which case
i would just ask for a main header ACK to ensure that the FE received my
message but nothing more.

Use case:
Example unidirectional heartbeat.
A more involved heartbeat would occasionally ask for acknowledgement
or a full response(a pong to the ping) always but thats a se.

2a) If the error codes being returned are simple pass/failed type
then echoing back the SET in configresponse with a flag (currently
inside the operation) in my opinion should suffice.
2b) I should be able to request for the above but also get a shortcut in
the main header flags which says "you need to look at the operational
flags further". The NACK flag should suffice to indicate this in the
main header.

Use case:
Useful when execution success is certain and reliable delivery since
saves on bandwidth.
An example is when you are doing periodic sync updates in which you 
dont care if a message or two get lost. But you care if the update
didnt succeed. 

3)If the error code is to nail it down to details such as "we couldnt
install this entry because the table was full" then i can see we would
need per data being created/replaced a TLV of some form which would
describe what happened. Maybe the TLV is only needed in the case of a
failure.

An improvement over 2(same use case), just more bandwidth intensive.

4) Like mentioned so far you may want the dataraw to be reported back.

Essentially what sent is responded to in full with status regardless of
whether it failed or succeeded. 

Use case:
This is paranoia mode which uses a lot more bandwidth than other modes
(allows sender to validate what was sent).

> seem to have missed the use case that motivates it?)

Refer to 4 above.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 9 Feb 2005 11:11:12 -0500

I understand the description.

What I don't understand is why we need to support this mode.

If the CE is that paranoid, it can do a GET after it does the SET.  Having 
an option to echo the data back in the SET response adds more protocol 
complexity without an added value I can understand.

On the rest of it, the issue seems to come back to the ganularity.  If the 
WG agrees that an operation TLV always succeeds or fails together, then I 
am happy not to introduce SETRESULT TLVs buried inside the OPERATION response.

Yours,
Joel

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 10 Feb 2005 00:13:50 +0800

Hi Jamal,

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>
Subject: Re: Protocol Operations
> path flags. Thats going to create complexity IMO.
I'm afraid this is not the point at all. The actual point is, I think the #2 in my example as: 

#2:
Op=SetResponse

may also be a necessary format for set responses, hense our BNF should support it as well as #1 way.Then, if we define Path-Data TLV as:
PATH-DATA TLV := <PATH> [SELECTOR] [<DATA>+ | <PATH-DATA>+]
it will not support the #2 format. As a result, I suggest 
PATH-DATA TLV := <PATH> [SELECTOR] [<PATH-DATA>+] [<DATA>+]
which will support #2 format as well as #1 format.

But I have to say this is a sub issue currently, I can live with defer it later. 

Cheers,
Weiming

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 10 Feb 2005 00:16:46 +0800

Jamal,

As I'v already stated, the current Path-Data BNF meets my thoughts on the subpaths well. What we are now discussing are just some sub-issues, I think. Of course, they are also very important. These sub-issues may include:

1. Whether or not we should put Operation flags in Path flags.I'v just checked your mail to Hormuzd. One point I'm a little hard to agree with you is when you mention "because we have to have path flags, why not to have some flags in it also for operations". My thought is, even if we have bits room for the flags, it is still not valuable enough to make the operation structure more complex with one more parse level.

2.The BNF format for Response messages.

3.The flag for Index and Block operation may also need more discussion. I'm thinking if we only need one bit flag instead of 2 bits for this purpose.

That's that I currently can think of for the BNF. I hope other guys can provide more.

Cheers,
Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 9 Feb 2005 11:28:14 -0500

> complexity without an added value I can understand.

Ok, Joel we can kill it if noone wants it. I dont see it as added
complexity really - but lets move on.

> am happy not to introduce SETRESULT TLVs buried inside the OPERATION response.

I am fine with the way you had described it earlier i.e i dont think
granularity at the operation level is sufficient.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 9 Feb 2005 11:35:15 -0500

Weiming,

> Path(4) IndexTLV(1,3,5,7,9) path(1)-Data(100) path(2)-Data(200) path(3)-Data(300) DataTLVforSetResult

Whats in the DataTLVforSetResult? Maybe that will clarify things.

> But I have to say this is a sub issue currently, I can live with defer it later. 

However I see the above as belonging to the previous discussion - so we
cant close that chapter, yet.
Look at example 17 in the document i posted which addresses this issue
at the cost of more bits.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 9 Feb 2005 11:39:40 -0500

On Wed, 2005-02-09 at 11:16, Wang,Weiming wrote:
> Jamal,
> 
> As I'v already stated, the current Path-Data BNF meets my thoughts on the 
> subpaths well. What we are now discussing are just some sub-issues, 
> I think. Of course, they are also very important. These sub-issues may include:

Based on your last email i think we havent really closed the previous
discussion; can you look at example 17 and say if it is sufficient for 
you with current grammar? It does end up being a little inefficient.
What you list below are fine issues to followup next and i am going to
respond under a separate subject to them.

cheers,
jamal

> 1. Whether or not we should put Operation flags in Path flags.I'v just 
> checked your mail to Hormuzd. One point I'm a little hard to agree with 
> you is when you mention "because we have to have path flags, why not to 
> have some flags in it also for operations". My thought is, even if we have 
> bits room for the flags, it is still not valuable enough to make the operation 
> structure more complex with one more parse level.
> 
> 3.The flag for Index and Block operation may also need more discussion. I'm thinking 
> if we only need one bit flag instead of 2 bits for this purpose.
>

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 9 Feb 2005 11:58:17 -0500

Weiming,

On Wed, 2005-02-09 at 11:16, Wang,Weiming wrote:

> checked your mail to Hormuzd. 
> One point I'm a little hard to agree with you is when you 
> mention "because we have to have path flags, 
> why not to have some flags in it also for operations". My thought is, 
> even if we have bits room for the 
> flags, it is still not valuable enough to make the operation structure 
> more complex with one more parse level.

Hormuzds arguement has been that you save bits by moving the flags
therefore you are more efficient that way. This is not true unless you
move all flags out.
Your arguement is different in that you say it is complexity and an
extra parsing level. Parsing of  flags is something you MUST look at
everytime regardless when you encounter a path - so it is not adding
extra parsing level or complexity.

Heres what we should do: Lets have someone else respond and say they
feel strongly with some good reasons (in other words not a "me too"
response) then i will have no problem moving just the operation flags
out of the path but not every flag as indicated by Hormuzd.

> 3.The flag for Index and Block operation may also need more discussion. 
> I'm thinking if we only need one bit flag instead of 2 bits for this purpose.
> 

All valid points. I will add this to my list that i posted earlier for
Friday meeting (0r we can continue discussing here).

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 10 Feb 2005 21:45:40 +0800

Hi Jamal,

> Whats in the DataTLVforSetResult? Maybe that will clarify things.
The DataTLVforSetResult is the same as Joel's SetResult in that it responses back the Set result, different from Joel's SetResult in that I suppose we may need a general whole echo for every operation, rather than for every path-data echo.

> cant close that chapter, yet.
I can not understand your meaning here very well. What do you mean here by previous discussion? Do you mean the subpath issue? I think the subpath idea is really the idea we presented in the current BNF, therefore this point can be closed to me. Moreover,I don't see a fatal relation of the SetResult issue with subpath issue actually, therefore it's a sub-issue only to me for the big Paht-Data issue.
> at the cost of more bits.
I'v checked the example. I think we'v already discussed about this case. I'm not sure what's the relationship of the example with the topic we discussed here.

Cheers,
Weiming

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 10 Feb 2005 22:41:21 +0800

Jamal,

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>
Subject: Re: Protocol Operations

> you with current grammar? 

Sorry, but I do think you still have a misunderstanding of my question. I have no question with the BNF used in the example 17 at all. The problem now we discuss is what the response message should look like for Configure Messages with Set Operation. If you really want to me to ask a question about the example 17, I just want to ask what the response BNF should look like for this set message.

Cheers,
Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 10 Feb 2005 10:02:15 -0500

Weiming,

On Thu, 2005-02-10 at 08:45, Wang,Weiming wrote:
> The DataTLVforSetResult is the same as Joel's SetResult in that it responses back the Set result, 
> different from Joel's SetResult in that I suppose we may need a general whole echo for every operation, 
> rather than for every path-data echo.
> 

Ok, I will defer this for next discussion because it is trully a
subissue.

> I can not understand your meaning here very well. What do you mean here by previous discussion? 
> Do you mean the subpath issue? I think the subpath idea is really the idea we presented in the current BNF, 
> therefore this point can be closed to me. Moreover,I don't see a fatal relation of the SetResult issue with
> subpath issue actually, therefore it's a sub-issue only to me for the big Paht-Data issue.
> I'v checked the example. I think we'v already discussed about this case. I'm not sure what's the relationship 
> of the example with the topic we discussed here.

Heres why i said its not closed yet:

Current:

You suggest:

Theres some serious differences between the two. 

cheers,
jamal