Subject: Re: Protocol Operations

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Tue, 8 Feb 2005 22:27:41 -0800

Jamal,

I did look at example 15, it was similar to what I sent out.
Here is how that would be encoded without using Flags in PATH...

15) Selective setting 
on table 4 -- for indices 1, 3, 5, 7, and 9.
Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is.

operation = REPLACE | F_SELBLK
	Path-data TLV 
		IDCount = 1, IDs=6
		// select the rows
		BLK_LIST_INDEX, L = XXX
			V = {1,3,5,7,9}
		// select individual columns and set
		Path-data TLV : 
			IDCount = 1, IDs=1
			DATARAW TLV: L=XXXX, V = {100}
		Path-data TLV : 
			IDCount = 1, IDs=2
			DATARAW TLV: L=XXXX, V = {200}
		Path-data TLV : 
			IDCount = 1, IDs=3
			DATARAW TLV: L=XXXX, V = {300}
 
Pls feel free to point out if something is broken in what I am
proposing. I am open to hear about that. Right now your questioning
makes me feel like I am giving some high school test again:))

Regards
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Jamal Hadi Salim

> Hopefully this is a satisfactory explanation.

Not so fast.
Pick one with nested TLVs. Take Example 15. Maybe the meanings of the
flags will become obvious after that.

cheers,
jamal

---

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

On Wed, 2005-02-09 at 01:27, Khosravi, Hormuzd M wrote:
> proposing. I am open to hear about that.

The details are in the doc Hormuzd but because you tried i will 
try to be more patient with this response.

F_SELBLK is per path. The document says: 

-----
-->00: indicates absence of the selector 
This is the only case where the path is allowed to have a
mix of field IDs and indexes.
-->01(F_SELTAB): indicates what follows is a table. The
path should be sufficient to point to a table; so this flag
is redundant but here for completion sake
-->10(F_SELBLK): indicates that what follows is a BLKINFO
-->11(F_SELKEY): Indicates what follows is a KEYINFO
-----

As you can see all the other paths in that example do not need a
F_SELBLK except for the outer/first one. 
And only items with data need a replace but not ones with pure paths.
To make it more inmteresting, there are examples where you would have
F_SELBLK flags first and then F_SELKEY next and then REPLACE at the most
inner nest where the data is to be found.
This was why earlier i said you cant get rid of the flags from
the path because they are used to refine the path, and not just the
operation.
So removing the replace and create and putting them in the operations
T,  while looks of value, it does not change anything in terms of
reducing the bit count because those flags are needed regardless.
Hence my statement earlier that i didnt see they were any different in
merit precisley because you are *not* gonna be able to remove the flags
with path semantics; again if you could remove _all flags_ then what you
are proposing will be valuable. Removing just the operation
enhancing flags is of cosmetic/philosophical value and should be defered
to a later discussion.
The other thing i pointed out was that infact you could have both a
create refinement to SET as well as replace within the same operation
TLV (but that was a side effect more than a design intent).

Having said all the above, if the document is unclear it needs to be
fixed; it is not acceptable for the doc to do a poor job at explaining
things. 

>  Right now your questioning

Did you mean "taking" high school test? ;->

I didnt wanna go here, but i have plenty of time this morning:
My reaction is out of frustration. 
a) I feel this is a distraction from our biggest show stopper and we are
close to nailing that one. 
i.e I dont think this is big enough an issue to be taking the bandwidth
it is taking (at least not at this moment). Its like focussing on a
pebble when theres a rock to be moved. 
b) I honestly dont feel we are having a meaningful discussion - because
i perceive that you havent read the document or if you have then you
just did a 1 minute scan.

Actually i think i could live with b) if we didnt have issue a). 

cheers,
jamal

PS:-
Dont get me wrong because this may sound elitist: 
Even at the IETF meetings there are things done to improve the focus of
the discussion - I am sure you have walked into a meeting where they
would reserve the two front rows for "people who have read the draft". 
You could walk to the mike and start with "I havent read the document
but .." or "I have quickly scanned the document  but ..' On the list
such disclaimers are still acceptable (Alistair for example does a good
job at that).. And the eventual answer to someone who walks to the mike
maybe "read the document for details". 

I see my views as no different from any of the above.