[Forces-protocol] RE: Section 6 update

["Khosravi, Hormuzd M" <[e-mail]>]

Robert,
 
Thanks for your comments below. I am mostly fine with them, will
incorporate the changes in the text. BTW, any status update from you ?
Should I assume you are not working on Section 6 at the moment ?
 
Pls see a few of my comments/clarifications below...
 
regards
Hormuzd

________________________________

From: Robert Haas [mailto:[e-mail]] 
 
 I think we should now make our terminology consistent and use "FE LFB"
and "FE Protocol LFB" instead of Object or Managed Object. I know it
will make Weiming unhappy, but I find it less confusing. The reason is
that we treat regular LFBs and the FE Object and FE Protocol Object in
the same manner in the protocol ("Everything is an LFB").
 [HK] I am fine with whatever terminology you guys decide, as long as it
is consistent in the draft. LFB is definitely cleaner, so I agree. 

6.1.1  Association Setup Message

To me, FE Name is an attribute of the FE Protocol Object/LFB (not the FE
Object/LFB) that can be advertised by the FE. Let's define a new "SHOW"
operation for that purpose.  [Do we need to have an Operation ? If yes
then SHOW is fine by me] 

The message would therefore look like:

main hdr (eg type =  Association setup)
     |
     |
     +--- T = LFBselect
              |
              +-- LFBCLASSID = FE object
              |
              |
              +-- LFBInstance = 0x1
              |
              |
              +-- T = operation SHOW
                  |
                  +-- FE NAME (path target)

What do you think ? A better name than "SHOW" ?       [Fine by me if we
need an Operation] 

6.3  Configuration Messages
   
6.3.1  Config Message

      Event Type (16 bits):
       For SUBSCRIBE, UNSUBSCRIBE Events Type TLVs, an Event Type field
       will define the Events of interest.  Examples of Event Type
       include, All Events, FE Events, LFB Events, Packets, Packet
       Mirroring.
  I am not comfortable with these Event Type flags that appear for every
operation (ADD, GET, DEL, etc) but are only used for EV_S and EV_U.

I propose to do this differently:  [Ok, I'll make this change] 

main hdr (eg type = config)
     |
     |
     +--- T = LFBselect
     |        |
     |        +-- LFBCLASSID = target LFB class
     |        |
     |        |
     |        +-- LFBInstance = target LFB instance 
     |        |
     |        |
     |        +-- T = operation = EV_S
     |        |   |
     |        |   +--  // one or more path targets (i.e., events to
subscribe) 
     |        |        // under discussion

And define the following attributes in their respective LFB/Objects:
 - in each specific LFB (including the FE Object), an attribute for each
event it can fire, and possibly an attribute for "AllLFBEvents" that can
be subscribed to and corresponds to subscribing to all events of that
LFB (model team should look at this).
I don't know what a "Packets", or "Packet Mirroring" event corresponds
to. If this is a redirected packet, then we have already a special
message type for it.
 [HK] We need some way to Subscribe, Unsubscribe for Packets...so I
decided to put it here...however based on your comment I think it would
be cleaner to define 2 more operations PACKET SUBSCRIBE, PACKET
UNSUBSCRIBE...let me know what you think ?


	 6.3.2  Config Response Message 
	But you have multiple overall results in the same config
message. This should be fixed.
	 [The overall results are per operation, I think I will change
the terminology] 

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