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

> =============================
> 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.

> 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?

> =============================
> 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?

> 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.

> 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?

> 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.

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

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

cheers,
jamal