Subject: Re: Protocol Operations

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Thu, 10 Feb 2005 00:37:25 -0800

Jamal,

I'll try to keep my response short since seems like this thread is
causing you some frustration. Just to clarify...that was not my
intention, I resisted posting some of these comments last week till I
thought some of the bigger issues were resolved...sorry for the trouble.

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

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.

[Yes this is true as the grammar currently stands. But do we really need
to have F_SELBLK and F_SELKEY in the same Op TLV? I did see some use
cases around this, but the reason for F_SELKEY was basically for content
based Query in a Query msg. So if we restrict this combination and if
there is only 1 F_SELBLK in an Op TLV for a Config msg then we should be
able to eliminate the need for Flags in each PATH. I was thinking along
these lines...let me know if this makes sense to you?]

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. [understood]

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. 
[Yes, this is what I am trying to achieve...so we are on the same page
here]

Removing just the operation
enhancing flags is of cosmetic/philosophical value and should be defered
to a later discussion.
[I believe there is still value in this, Weiming and David pointed out
some reasons as well]

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. 
[Some of these things are not crystal clear in the doc, I think it could
be improved]

Overall comment, as the doc stands today there are too many alternatives
for doing the same thing which is not good for interoperability and
causes some confusion to the reader as well. We should try and improve
this aspect, restrict some of the alternatives if possible.

Regards
Hormuzd

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 10 Feb 2005 09:53:11 -0500

Hormuzd,

On Thu, 2005-02-10 at 03:37, Khosravi, Hormuzd M wrote:

> to have F_SELBLK and F_SELKEY in the same Op TLV? 

So far yes; I am actually not sure you can get rid of this. You could
have nested paths with nestings which need to further path nesting as
an example it's  possible to select a cell within a table within a table
and use content keying for the second table. 

> I did see some use

You could do things like above, but because you need nesting and to
further refine paths as you nest paths, then the flags are a must have.
Otherwise we end up overlooking some scenarios.

> [I believe there is still value in this, Weiming and David pointed out

I havent seen any value in what Weiming proposed either. I dont recall
seeing Davids reasons. What i told Weiming is it should be fine (if
theres semi good reasons) to move the operational bits only outside but
not every bit like you are suggesting. The problem is both of you quote
efficiency as the driver for moving bits and i see none. Find another
reason. 

> [Some of these things are not crystal clear in the doc, I think it could

It would be very helpful and appreciated if you point me particular
sections so i can clean them up. To quote Joel "if we cant explain it
they cant understand it".

> this aspect, restrict some of the alternatives if possible.

Agreed - although "restrict some of the alternatives if possible" is too
wide a term though. I think the biggest culprit in alternatives is:
a) efficiency of manipulating our most common data structures - the
table 
b)content keys
and
c) ability to nest paths. 

I dont see us getting rid of any of the above.
Getting rid of the above desires will surely reduce a lot of the
"alternatives".

The challenge as i see it for the moment though, is to get 3 people who
have vastly different but strong views of the BNF to agree to one. That
would be a great accomplishment
(I posted on the list asking for the chairs to put a time limit for this
goal - unfortunately got no response).
I think once we get a good starting point, it would be fair to go back
and review again. At least there will be a starting point we can base
that discussion on. The reason i keep adding those use cases is to make
sure that every counter example given by anyone is expressable via the
BNF. Otherwise its not complete.

cheers,
jamal