Subject: RE: [Forces-protocol] RE: GET/SET in one msg ?

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 15 Oct 2004 18:26:56 -0700

Does anyone else have an opinion on this, especially if it is different
from what Joel suggested ?
Pls do let us know asap. 

I am fine with this, just want to make sure there are no contradicting
opinions in the Model team.

Thanks
Hormuzd 
P.s. BTW, I don't think I still got a real example on how this would be
useful.

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Friday, October 15, 2004 6:20 PM
To: [email-masked]
Cc: Khosravi, Hormuzd M; Yang, Lily L; [email-masked]; Steve
Blake; Alan DeKok; Deleganes, Ellen M; [email-masked];
[email-masked]
Subject: Re: [Forces-protocol] RE: GET/SET in one msg ?

That would be my suggestion.

To be specific, I would not have a Query and a Modify message, but
rather 
would have an Operation message which can carry whatever operations we 
decide we need.  We may make specific rules that say "for sanity, never 
combine X and Y".

I believe this will keep the protocol simpler.

Yours,
Joel

At 08:40 PM 10/15/2004 -0400, Jamal Hadi Salim wrote:
>Joel,
>We are sort of in a rush here to beat a deadline ;-> Give it to us in
>boolean logic please ;->
>
>Did i read correctly that since we may have multiple operations (we
have
>been discussing event un/subscribe as something that would appear as an
>operation for example) then the way to go forward is have GET as an
>operation?
>
>cheers,
>jamal
>
>On Fri, 2004-10-15 at 20:11, Joel M. Halpern wrote:
> > If we are sure that the only two operations we will ever need are
GET and
> > SET, then we could probably simply declare that a message was either
a GET
> > message or a SET message.
> > However, we have had suggestions of INSERT operations, and I would
hate to
> > design the protocol so that we could not add other operations later.
And
> > some combinations of operations may make sense together (insert item
> > A.  Add reference to A in item B.  Delete obsoleted item C.)
> > Thus, I tend to think that it makes sense to structure the protocol
so 
> that
> > a single emssage can carry multiple operations.
> > At the same time, as I said earlier, I would either prohibit or warn
> > against combining update and read operations in the same 
> request.  Requests
> > to read, for example to confirm the results of an update, ought to
be sent
> > separately so that the FE does not need to worry about the order of
> > application.
> >
> > Yours,
> > Joel
> >
> > At 03:55 PM 10/15/2004 -0700, Khosravi, Hormuzd M wrote:
> > >No, I don't that's why I asked...since this was coming from Joel's
> > >proposal.
> > >I didn't get a good reason from his email either, but it seems like
he
> > >would like to have it supported by the protocol anyway.
> > >
> > >Joel, do you have any examples for us ?
> > >
> > >
> > >Thanks
> > >Hormuzd
> > >
> > >-----Original Message-----
> > >From: Yang, Lily L
> > >Sent: Friday, October 15, 2004 3:52 PM
> > >To: Khosravi, Hormuzd M; 'Joel M. Halpern'; [email-masked]';
> > >'Steven Blake'; 'Alan DeKok'; Deleganes, Ellen M;
[email-masked]'
> > >Cc: [email-masked]'
> > >Subject: RE: GET/SET in one msg ?
> > >
> > >I don't understand why you would want to do such a thing. Do you
have
> > >any example in mind?
> > >
> > > > -----Original Message-----
> > > > From: Khosravi, Hormuzd M
> > > > Sent: Friday, October 15, 2004 2:04 PM
> > > > To: Joel M. Halpern; [email-masked]; Steven Blake;
> > > > Yang, Lily L; Alan DeKok; Deleganes, Ellen M;
[email-masked]
> > > > Cc: [email-masked]
> > > > Subject: GET/SET in one msg ?
> > > >
> > > > Hi Folks,
> > > >
> > > > We (protocol team) are finalizing some of the msgs and one of
> > > > the issues which is being discussed is whether GET/SET
> > > > operation need to be combined in a single msg...(currently we
> > > > have them as separate msgs). I have never seen this being
> > > > done in practice i.e. command bundling of GET/SET, but if you
> > > > guys have some experience/opinions on this, pls do let us know.
> > > >
> > > >
> > > > Thanks a lot,
> > > > Hormuzd
> > > >
> > > >
> >
> >
> > _______________________________________________
> > Forces-protocol mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/forces-protocol

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: Steven Blake <[email-masked]>
Date: Sat, 16 Oct 2004 00:24:03 -0400

> opinions in the Model team.

My problem about allowing a config command in the same PL-message as a
query command (and I think Zsolt agrees with me), is that it complicates
handling of any responses.  I believe that, for any PL message with
config commands, all of the possible exception responses can fit into
a single PL message, and therefore we can correlate at the PL layer.
However, it could be typical that a small query command message could
result in several PL messages being returned (e.g., GET an entire
table).

For simplicity, I would like to see PL messages typed as either
CONFIG-REQUEST, CONFIG-RESPONSE, QUERY-REQUEST, QUERY-RESPONSE,
ASYNC-EVENT, ...

Regards,

// Steve		http://www.petri-meat.com/slblake/

---

From: Jamal Hadi Salim <[email-masked]>
Date: 16 Oct 2004 07:56:10 -0400

> result in several PL messages being returned (e.g., GET an entire

Sounds like consensus is to put a note in the draft that such a case may
be hazardous and to be avoided.

> CONFIG-REQUEST, CONFIG-RESPONSE, QUERY-REQUEST, QUERY-RESPONSE,

Ok, you still have a QUERY-REQUEST, QUERY-RESPONSE there - which is core
to this discussion; an alternative to that is a CONFIG-REQUEST with
operation = GET as well as CONFIG-RESPONSE with operation = GET.
So far theres a leaning towards CONFIG-*; if you disagree please
explain.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 16 Oct 2004 11:29:01 -0400

folks,

I have updated the notes i put up earlier based on last discussions.

Outstanding:
1) Steve/Zsolt please look at a note for you in the text
2) KEY and BLOCK mode to get consensus
3) DATA representation. This is a tough nut to crack. I dont think 
we (protocol side) need to totaly flush this out, but heavy discussion
needed for it with everybody involved.

cheers,
jamal

---

From: Zsolt Haraszti <[email-masked]>
Date: Sat, 16 Oct 2004 20:40:24 -0400

> > CONFIG-REQUEST, CONFIG-RESPONSE, QUERY-REQUEST, QUERY-RESPONSE,
Yes, I find this solution very clean.

> So far theres a leaning towards CONFIG-*; if you disagree please

A query operation (GET) is not a config operation, so if you include
GET as one of the many operations inside the CONFIG-REQUEST, then you
should not call it CONFIG-REQUEST, but something else (e.g., OPERATION-
REQUEST, which is ugly BTW).

It seems we have consensus that we need an open-ended design that
allows us to introduce new operations later.  But merging all
the operations under a single PL message type is not the only
way to achieve this!

GET is fundamentally different from the rest of the currently outlined
operations (SET/ADD/DEL):
- A QUERY always requires a response.  For CONFIG operations you may
  elect to suppress response, or request for response only if error
  occurs, or select between detailedness of response based on success
  or failure.  Nothing of which makes sense for QUERY operations.
- For QUERY the response is typically as long as the request, more
  often much longer (e.g., GET content of a table).  It is therefore
  expected that slightly different protocol behavior will be needed
  (e.g., multiple PL response to a single PL request).
  For CONFIG operations, the response is typically smaller (if any)
  then the request.

Defining CONFIG-REQUEST/RESPONSE and QUERY-REQUEST/RESPONSE as
two pairs of messages does not preclude later introduction of new
operators.

As a start we have GET as the allowed operator in QUERY-REQUEST:s,
and SET/ADD/DEL as the allowed operators in CONFIG-REQUEST:s.
Both sets can be extended later as needed.

The internal structure of the two PL messages can be very similar
if not identical:  PL<LFB<OP<path,data>+>+>

/zsolt

---

From: Zsolt Haraszti <[email-masked]>
Date: Sat, 16 Oct 2004 23:45:36 -0400

Jamal,

Good progress!  See my comments embedded.

> needed for it with everybody involved.
Not that bad, I think.  We have a working implementation for this
at MN already, which is rather efficient and not terribly complex
either.

> 
> This doc builds up on what was posted by Steve/Zsolt[1] to
> try to map to protocol.
> It by no means imposes a decision i.e tghis is merely here
> as a discussion place holder with the a desire to speed things
> up.
> 
> NOTE:
> -----
> 
> A small reminder on layout:
> 
> main hdr (eg type = config)
>      |
>      |
>      +--- T = LFBselect
>      |        |
>      |        +-- LFBCLASSID = 0x45 
>      |        |
>      |        |
>      |        +-- LFBInstance = 0x1234
>      |        |
>      |        +-- T = ADD //operation
>      |        |   |
>      |        |   +--  // path target X
>      |        |        // with data to be added
>      |        |        // This is the discussion point 
>      |        |
>      |        +-- T = ADD //operation
>      |        |   |
>      |        |   +--  // path target Y
>      |        |        // with data to be added
>      |        |        // This is the discussion point 
>      |        |
>      |        |
>      |        +-- T  = DEL //operation
>      |        .   |
>      |        .   +--  // path target Z
>      |        .        // This is the discussion point 
>      |            
> 
> 1) There could be multiple operations on any instance
> 2) path-data comes after the operation.
> 3) there is only one path-data per operation.

Great so far.

> 
> A possible path-data layout. 
> ----------------------------
> 
> OPER_TLV : = <PATH-DATA>
> PATH-DATA := flags IDcount <IDs> [BLOCK_OR_KEY_NOTATION] [DATA]
> 
> The operational TLV contains an opcode in the T part. Its V
> contains the PATH-DATA.
> Opcodes discussed so far:
> * SET (create, modify or both depending on PATH-DATA flags}
> * DEL (remove an existing entity specified by PATH-DATA }
> * GET (Access a entity specified in PATH-DATA }
> * EV_S (subscribe to an event defined in PATH-DATA }
> * EV_U (unsubscribe to an event defined in PATH-DATA }

An alternative to EV_S/U would be to model this via special
LFB attributes, i.e., a ADD-ing/DEL-eting entries in a
subscription table, modeled as an ARRAY attribute of the
respective LFB.  Then there is no need for a separate
operations.

> 
> -> IDs := a series of 32bit IDs (whose size is given by IDcount)
> defining the path.
> -> flags are used to further refine the operation to be applied
> on the ID_TLV.

Things that come to mind for SET/ADD/DEL:
- PARTIAL_OK (1-bit): to select how partial success should be handled:
  "partial-ok" or "all-or-nothing".  E.g., when the operation
  is to add a bunch of elements to a table, and only a portion
  succeeds, should the already added ones kept or should
  they be removed.  Or for a more practical example:  when a block
  delete is issued and only a subset of the specified indices are
  actually valid, delete the valid ones or not.

Things that come to mind for GET:
- EXISTENCE-ONLY (1-bit): if set, an existence flag should be
  returned instead of the full content of the selected data node.
  This is useful for the CE when exploring if a given path is
  valid.
- INDICES-ONLY (1-bit): if <path> refers to an ARRAY node and
  this bit is set, then the RESPONSE should contain only the
  list of currently valid indices instead of the full content of
  the ARRAY.  This is useful for the CE when exploring what indices
  are valid in a given ARRAY.  It can also be used to obtain the
  indices that correspond to a KEY, if KEY operations are supported.

> -> BLOCK_OR_KEY_NOTATION := optional different BLOCK or KEY extension
> defined in section 4.2 and 4.3 of [1]
> -> DATA : = Optional variable sized data dependent on PATH
> and applied operations (eg GET will not have DATA).
> 
> Some Clarification in relation to [1]:
> -------------------------------------
> 
> [1] represents a requirement gathering/place holder.
> This document is into details closer to implementation.
> 
> flags
> -----
> 
> Derived from netlink and BSD route sockets to meet requirements
> defined in [1]:
> 
> --> F_EXCL: 
> The exclusive flag.
> Donot replace the config attribute(s) if already exists -
> Report back error instead.
> 
> A CREATE operation with this flag is equivalent to 
> INS_IDX if index is passed and equivalent to  INS if index is 
> not passed in the IDs.
> A DEL with this flag is equivalent to DEL! in [1]. Without
> this flag the equivalency is to DEL.
> 
> --> F_REPLACE: 
> Replace existing matching config attribute(s) with passed 
> data.  An index must be passed. In the case of key operations, a 
> KEY must be passed.
> A CREATE operation with this flag is equivalent to a SET
> or a INS_IDX!.
> 
> Steve/Zsolt please double check that this is matching to your
> doc.

Assuming the SET/ADD/DEL CONFIG-REQUEST operators (I use ADD
here instead of INS, because I slightly prefer ADD over INS;
but otherwise it has the same meaning as INS in all previous
discussions), all we need for the above purpose is a single flag:
F_PEDANTIC (or F_PICKY).  (We can choose the inverse meaning, but
I could not come up with a good word to describe that...)

Before further discussing the meaning of this flag, a couple of
notes:

1. For SET operations this flag plays a role only if path
   refers to an entry in an ARRAY data element, i.e., when
   path[:-1] refers to an ARRAY (in which case path[-1] is the
   index to be used inside the ARRAY).  In all other cases the flag
   must be ignored.

   (Notation hint: path refers to the list of IDs, path[-1] refers
   to the last element of the list, and path[:-1] means the
   first part of the list without the last element.)

   So the meaning of the flag in this scope is as follows:

	if element[path] exists:
		element[path] = data
		report success/failure of assignment
	else:
		if OP_FLAGS & F_PEDANTIC:
			report error
		else:
			# attempt to add new element to array:
			add(element[path[:-1]], # ARRAY
			    index=path[-1],	# INDEX
			    value=data)		# initial value
		report success/failure of assignment

   In words, if F_PEDANTIC is cleared, create entry if it
   does not yet exist.  If F_PEDANTIC is set, report error
   if entry does not yet exist.

2. For ADD/DEL operations:
   We will have actually two forms of ADD/DEL operations:
   a  One where path specifies the entry in an ARRAY which is
      to be added/deleted, i.e., path[-1] is the entry index
      within the ARRAY, and path[:-1] is the reference to the
      ARRAY itself.
   b  Another where path refers to the ARRAY itself and the
      index/indices of the entries to be added/removed are given
      as part of the [block] description.  (For the ADD the
      indices may not be provided at all, in which case the FE
      can pick the indices; a.k.a. INS vs. INS_IDX.)
      Obviously this b) form is meant for block operations,
      though b. can do what a. can.  I still would like to
      allow both forms because in single-entry operations the
      a. form is more staright-forward.

   BTW, we will have to signal in the OP TLV header
   which form we mean, because in the special case when
   both path[:-1] and path refer to an ARRAY (i.e., path[:-1]
   is an ARRAY of ARRAYs), the above two forms collide.  This
   can be done via an F_BLOCK flag indicating b. when set,
   or separate SET/SET-BLOCK, ADD/ADD-BLOCK, and DEL/DEL-BLOCK
   operations (T's).  Flags are OK.

   Now, the meaning of the F_PEDANTIC flag (assuming the above
   scope conditions are satisfied) is as follows:

   For ADD as in a.:

	if element[path] does not exists:
		add(element[path[:-1]], # ARRAY
		    index=path[-1],	# index
		    valude=data)	# initial value
		report success/failure of assignment
	else:
		if OP_FLAGS & F_PEDANTIC:
			report error
		else:
			element[path] = data # over-write element value
			report success/failure of assignment

   For ADD as in b.:

	for index in BLOCK: # Take each index specified in BLOCK
		# Do the same as above pseudo code, but replace
		# path with path+index, path[:-1] with path,
		# and path[-1] with index
		if element[path + index,] exists:
			add(element[path], index, data)
			report success/failure
		else:
			if OP_FLAGS & F_PEDANTIC:
				report error
			else:
				element[path + index,] = data
				report success/failure

   For DEL as in a.:

	if element[path] exists:
		del(element[path[:-1]], index=path[-1])
		report error
	else:
		if OP_FLAGS & F_PEDANTIC:
			report error
		else:
			report success

   For DEL as in b.:

	for index in BLOCK:
		if element[path + index,] exists:
			del(element[path], index)
		else:
			if OP_FLAGS & F_PEDANTIC:
				report error
			else:
				report success

By now you can infer the overall meaning of the F_PEDANTIC flag:
If cleared, the FE should try to correct/ignore the element existence
issue if there is one; if set, the FE must regard any entry existence
issues as error and handle it accordingly.

> 
> A CREATE operation with F_EXCL|F_REPLACE is equivalent to SET!
> 
> ** Other flags used for block operations mentioned in the BLOCK
section.
> 
> BLOCK and KEY path selection
> -----------------------------
> 
> The <all> variant described in [1] is not needed. To get access
> to all of table contents, the IDs merely need to point to the table.

True.  But with whatever notation you will come up to define the
BLOCK, it will always allow for encoding the ALL case as an extreme
case.  And I don't think we should make that case illegal.

> Therefore to access a range, the IDs field will contain the ID
> leading to a table and an optional TLV will include the range
> information.
> 
> - Additional flags needed:
> 1)F_BLOCK_ON, to indicate block selector embeded
> 2)F_KEY_ON, to indicate a key selector embeded

ACK

> #1 and #2 are mutually exclusive.

I agree provided that the KEY can include multiple keys of the
same key type.

> 3) F_REV_TRAVERSE, to indicate reverse progress in the access.

I guess this would be meaningful only in QUERY (GET) operations,
but I would NOT bother with this option.

> 4) F_KEY_MODE (2 bits or more) to select the KEY mode in case #2 is
> on.
> 5) F_BLOCK_MODE (1 bit); indicates count or range for second
> parameter of BLOCK Notation.
> 

It may be cleaner to encode these modes inside the respective TLV,
either as separate T values or as a special flag in the value part.

> In the case of block operations: 
> 
> Two modes exist. [a,b] or [a,N]
> We introduce a block TLV
> 
> T = BLOCK_TLV
>     start // "a"
>     end // "b" or "N"
> 
> The flag F_BLOCK_ON will indicate the presence of this TLV.
> F_BLOCK_MODE will indicate that "end" is an "a" or "N"
> F_REV_TRAVERSE will indicate whether reverse or forward progress
> 
> In the case of the associative paths: 
> the flag F_KEY_ON will indicate that we are using associative approach
> F_KEY_MODE will define the mode .
> 
> We introduce a KEY_INFO TLV.
> 
> T = BLOCK_TLV

You meant KEY_INFO_TLV, I assume.

>     KEY
>     KEY_DATA
> 
> The length of the TLV will help deducing the size of the KEY_DATA.

I presume KEY specifies the key-type (in case more than one type
of keys are allowed on the target).  Remember: each key type is a
collection of the struct fields that together can form a key.

KEY_DATA is one **or more** data blocks satisfying the KEY definition.
Each data block contains the necessary field values according to
the KEY definition.

> 
> DATA:
> -----
> Not discussing the optional data right now; a lot of details
> above need ironing out first.
> DATA is complex twist when it comes with variable sized data.

Steve and I will propose an encoding soon, to start that discussion.

> 
> $Log: path-data-oper.txt,v $
> Revision 1.2  2004/10/16 14:03:25  hadi
> incoporating feedback from Joel et al
> 
> Revision 1.1  2004/10/14 13:12:32  hadi
> Initial revision
> 

/zsolt

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 17 Oct 2004 00:42:03 -0400

A minor comment.
I think we should never have a request with ~respond only if an error 
occurs~. My reasoning is that if one has such a request, you never know how 
long to wait to allow for the error response.
I am doubtful of the value of a set with no response.  But if one wants a 
response, it should not be conditional.

Yours,
Joel

PS: On the structuring of messages and operations, I can live with creating 
two kinds of operations, one type for query operations, used in query 
messages, and one type for manipulation  operations, used in config 
messages.  Clearly, we want the structures to be the same, even if we do 
use two message types.

At 08:40 PM 10/16/2004 -0400, Zsolt Haraszti wrote:
>or CONFIG operations you may
>   occurs,

---

From: Jamal Hadi Salim <[email-masked]>
Date: 17 Oct 2004 10:22:22 -0400

> REQUEST, which is ugly BTW).

Ok, this is a fair semantic view. I am gonna stay indifferent; if people
wanna go this path i am fine with it.

> if not identical:  PL<LFB<OP<path,data>+>+>

They would be identical. It would probably be a little uggly to have one
type with differentiation happening at the operation level.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 17 Oct 2004 10:50:37 -0400

> at MN already, which is rather efficient and not terribly complex

We have one also but i would call it ugly ;->
Heres the litmus test

Two data tables
-Table1: has dummy struct with foo1 and foo2 being u32s
-Table2: has dummy2 struct with a u32 foo3, varibale sized foo4,
variable sized foo5 and u32 foo6.

> respective LFB.  Then there is no need for a separate

The assumption here is the model team will have events defined as
attributes (on a per LFB basis).
For the same semantical reasons as having a query being a separate type,
I think that the events should be separate operation. This also helps so
that if i am running a sniffer/debuger I could easily tell it is an
event vs other attributes.

>   actually valid, delete the valid ones or not.

In the same vein:
Do we need a commit flag as well as an atomic flag? 

>   This is useful for the CE when exploring if a given path is

Sounds valuable; How does F_PEEK sound?

>   indices that correspond to a KEY, if KEY operations are supported.

A List operation is what it sounds like.
Why restrict it to indices only? Doesnt it fall under some generic
operation which specifies what elements should be filtered in or out?  

> here instead of INS, because I slightly prefer ADD over INS;

Sure. 
Ok, Before i address the rest of your email, let me cut to define the
config operations. I think there are several operations and their
legitimacy depends on whether a targeted path is a terminal (eg array 7
index 3, foo1 - where foo1 is not another table) or not (array 7).

Operation beinfg ADD:
a). CREATE - valid only when the path is non-terminal such as if the
target path is an array. A terminal in  the case of an array is 
an element within an array row. A created entry may be initialized to
certain values.

b). UPDATE - valid at both terminal or non-terminal. Assumes an existing
entry.

Of course #1 and #2 can be combined in one atomic operation.

Operation DEL - valid only at a terminal location.

The protocol implementation should be able to tell from the IDs if
target is terminal or not. This is where the conditions of error
checking apply:
i.e does the element exist? is it a terminal?
F_EXEC and F_REPLACE flags combination apply and this should also take
care of whether an index was passed or not.

Let me cut here since email is long. I will continue rest in another
email.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 17 Oct 2004 11:18:29 -0400

> I could not come up with a good word to describe that...)

If you assume BSDism (probably std database table manipulation) then a
single flag is insufficient.
You need the equivalent of EXCL and REPLACE.
i.e an ADD with EXCL|REPLACE to a table implies create and update
with passed values. This allows you to at times just create and
have default values populated.
You seem to be saying a ADD = CREATEing an element and a SET is an 
update to an existing entry?

>    index to be used inside the ARRAY).  In all other cases the flag

We may be on the same page, you are refering to non-terminal in this
case.

>    if entry does not yet exist.

Ok, now i am sure we mean the same thing, except you have separated 
update from create.
I think it is valuable to keep them together.

> issues as error and handle it accordingly.

Ok, so the conclusion i reach is you have separated CREATE from UPDATE,
everything else seems to be the same (you didnt refer to terminals vs
non-terminals). In what i described earlier both are under the same
umbrella of ADD with differentiation being the flags. Is there any good
reason you are deviating from the norm (or what i consider to be the
norm). To compare against netlink and BSD route socket approach in
operations to ADD:

F_REPLACE: Replace existing matching config object with
         this request.
F_EXCL: Do not replace the config object if it already
         exists.
F_CREATE: Create config object if it does not already
         exist.

BSD ADD operation equates to F_CREATE or-ed with F_EXCL

BSD CHANGE operation equates F_REPLACE

BSD Check operation equates F_EXCL

BSD APPEND equivalent is actually mapped to F_CREATE

The existence of a passed index is actually in addition to the above.

> case.  And I don't think we should make that case illegal.

What i meant is if i wanted to get table 7 then my ID will be 7.
The BLCOK will be a further filter.

> I agree provided that the KEY can include multiple keys of the

Makes sense.

> but I would NOT bother with this option.

It was mentioned in the doc you guys posted; will restrict it to being a
flag.

> either as separate T values or as a special flag in the value part.

The start/end values are a TLV as shown below. Did you mean something
else?

> You meant KEY_INFO_TLV, I assume.

Of course ;-> That was intentionaly entered bug to see if people read
the doc ;-> Now i know you paid good attention ;->

> Each data block contains the necessary field values according to

The content aspect of things i dont have good clarity on. so provide me
with better definition on how things should be laid out and i will
update the doc.

> Steve and I will propose an encoding soon, to start that discussion.

Factor in the litmus test i provided in earlier email.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: 17 Oct 2004 14:13:10 -0400

On Sun, 2004-10-17 at 11:48, Zsolt Haraszti wrote:
> On Sun, 2004-10-17 at 10:50, Jamal Hadi Salim wrote:
> > <SNIP>
> I was talking about the subscribe/un-subscribe messages.
> 

I was as well, the difference being the operation; if i understood you
correctly you implied:

config/add/event_attribute for susbscription vs
config/evs/event attribute i was implying

or 
config/del/event_attribute vs
config/evu/event_attribute

I think its cleaner to have operation being event subscribe
say vs add etc.

> The actual asynchronous event notification should indeed be a
> separate PL type, as Steve called it out by EVENT.
> 

We have that already.

cheers,
jamal

---

From: Zsolt Haraszti <[email-masked]>
Date: Sun, 17 Oct 2004 11:48:28 -0400

/zsolt