Re: Comments on the Protocol version 10

Greetings again,

Thank you for your response, and sorry for this late reply.

I should mention that the EU Flexinet Project has finished succesfully and
also my initial simple implementation of ForCES in Java of the 06-protocol
(no metadata, three LFB's and simple configuration commands). One CE and one
FE using TCP as TML.

Now I am participating in the EU Phosphorus Project, in which we will
implement ForCES to manage an Intel IXP2850 network processor for a
token-based authentication scheme as part of the in-band signaling in a
Policy Enforcement Point (PEP) from a Authorisation Authentication
Accounting (AAA) framework (RFC 2904).

Please see comments inline.

Regards,
Evangelos Haleplidis

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email protected]] 
Sent: Thursday, June 14, 2007 9:36 PM
To: Evangelos Haleplidis
Cc: [email protected]
Subject: Re: Comments on the Protocol version 10

Greetings Evangelos,

On Wed, 2007-13-06 at 21:34 +0300, Evangelos Haleplidis wrote:

> =============================
> Editorials:
> 
[..]

> E6. Pages 72 & 74.
> The figures have some errors.
> 
> E7. Pages 65, 69, 71, 72, 74, 75, 77, 78, The figures lack numbers on 
> top of them.

These are all very good and valid - but can you add them to the tracker?
Can you be more explicit in E6 and E7 when you enter the issue in the
tracker? Example saying the figure has errors is not as good a description
as explaining that the "|" needs to be indented out etc

[EH]: Ok, I have added them in the tracker as issue 114.

> =============================
> Comments:
> 
> C1. Page 61:
> In the FE Protocol LFB the LFB Class ID is assigned the value 0x1. In 
> the model draft (page 82) it is stated that the FE Protocol LFB is 
> assigned the Class id 0x2 while the FE Object LFB is assigned the Class id
0x1.

The model draft will follow the protocol. So the protocol is the authority
on that id.

[EH]: Ok, thank you.

> C2. Page 67 - Association Setup:
> When the CE sends an association setup and within the setup message, 
> the CE requests the FE to send information in an unsolicited manner 
> about some attributes. Since the Association Setup Result contains 
> only the answer, how the FE sends back the requested attributes? It is 
> considered a one-time event (since it is a report type)?
> 

I wasnt actually clear on the essence of your question. It is the FE that
sends association setup not the CE and looking at that question in a view of
association setup response didnt ring a bell. Can you look at
4.4.1 and see if what you are asking is addressed?

[EH]: I am sorry about the question. Although I have implemented it, it is
still confusing when I re-read it having in mind that the ForCES Protocol is
a master-slave protocol. Why is it that the FE should inititate the
association procedure? Shouldn't it be the other way around? The CE
requesting the FE to associate with it?

> =============================
> Questions:
> 
> Q1. About the Transactions, when does the FE keep state? When a commit 
> is received or when the FE has acknowledged that the operation can be
executed?
> If the second is true, then what happens after an abort message? 
> Should it be followed by a clear state message?

Look at 4.3.1.2.2 and refer to the ABT and TRCOMP approaches both of which
allow the FE state to be cleared. Does that answer your question?

[EH]: From what I can discern, the FE(s) should keep state after a COMMIT is
issued and before actually commiting the configs. That way there is no need
to delete state with a failure. Am I correct? 

[EH]: Also something else, it is written that the ABT TP flag with a COMMIT
operation signals the FE(s) to rollback a previously comminted transaction.
However later in the document (in the same page) it is written that to abort
a failed transaction the CE sends a COMMIT with an ABT flag. 
So, the COMMIT & ABT flag has two meanings:
1. Rollback the commited transaction
2. Abort the transaction.
Can that be defined more explicitly in the beginning? E.g.:

When used with an ABT TP flag, the COMMIT operation signals the FE(s) to
rollback (i.e. un-COMMIT) a previously commited transaction, or abort a
failed transaction.

> Q2. Page 25 Figure 1. The Example is quite good for the All-or-none case.
> What happens with the Execute-until-failure or
Continue-Execute-on-failure?
> It is the same? If the FE does not validate one request what happens? 
> In the EUF case does the CE send a Commit without sending any more
commands?

A transaction, where a commit would be involved, typically falls under a
execute-all-or-none mode. 
In the other modes failure is more tolerated; in one case execution
continues and in the other the CE stops on first failure. Typically these
non-transactional approaches would target a single FE.

[EH]: Thank you.

> Q3. Page 30 Figure 9. In the first heartbeat, the arrow is pointing in 
> both directions. What happens? Both FE and CE send HBs? Shoulnd't the 
> CE send first?
> 

Either can send a HB - refer to section 4.3.3 Do you think we need to say
something within the diagram to clear anything?

[EH]: Ok. I found it strange at first. Perhaps in the figure, the first
arrow should point only in one direction, preferably CE-->FE, at least to
keep the initial default values that the FE doesn't send any HBs until
requested.

> Q4. Properties (SET-PROP, GET-PROP)
> What exactly is the definition of property? What is the diference 
> between the attribute and the property? The SET-PROPs are for events only?

properties are metadata associated with attributes. Example a table count
would be a property of the table attribute.

[EH]: Thank you. An example would be great in the document. Or at least a
refering to the model. Is there a limit to property changes? I mean, can the
CE change the accessPermissionValue Property of an element to make it from
READ-ONLY to READ-WRITE?

> =============================
> XML Parsing:

The other email talks also about the xml - can you add these details to the
tracker as well?

cheers,
jamal