Subject: [issue50] Fig.11 Sample operation layout: successive breakdown of the path-data

From: Robert Haas <[email-masked]>
Date: Fri, 10 Jun 2005 08:21:48 +0000

New submission from Robert Haas <[email-masked]>:

Sec 6.1.1.1.6 SET and GET Relationship
[...]
Fig. 11: Sample operation layout

Why is the path-data segmented 3 times for the SET-CREATE operation ? I 
thought that this was necessary only each time a different KEY was used ?
May need a better example ...

----------
category: Technical
draft: draft-ietf-forces-protocol
messages: 107
nosy: rha
priority: Should fix
status: No discussion
title: Fig.11 Sample operation layout: successive breakdown of the path-data

___________________________________________________
Forces issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/forces/issue50>
___________________________________________________

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 10 Jun 2005 08:04:47 -0400

> May need a better example ...

You must mean "6.1.2  Protocol Visualization"
The grammar says:
.
.
PATH-DATA-TLV := PATH  [DATA]
PATH := flags IDcount IDs [SELECTOR]
..
DATA := DATARAW-TLV / RESULT-TLV / 1*PATH-DATA-TLV
.
.

I dont see any thing that makes it illegal. Did we have some discussion which
reached a conclusion that it can only be done via KEY?

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Fri, 10 Jun 2005 14:14:17 +0200

Here is what I mean: in the example below (excerpt from Fig. 11), a 
reasonable approach would be to have a single longer path-data instead 
of 3 segmented ones. But if the tree had more branches, for instance 
under the first path-data segment or the second one, then I would 
understand why one would do so. So the current example is a bad example 
to my mind. Or am I missing sth ?

Regards,
-Robert

        T = SET-CREATE
        |  |
        |  +- T = Path-data
        |       |
        |       + -- flags
        |       + -- IDCount
        |       + -- IDs
        |       |
        |       +- T = Path-data
        |          |
        |          + -- flags
        |          + -- IDCount
        |          + -- IDs
        |          |
        |          +- T = Path-data
        |             |
        |             + -- flags
        |             + -- IDCount
        |             + -- IDs
        |             + -- T = KEYINFO
        |             |    + -- KEY_ID
        |             |    + -- KEY_DATA
        |             |
        |             + -- T = DATARAW
        |                  + -- data
        |
        |

-- 
Dr. Robert R. Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-44-724-8698  fax +41-44-724-8578  http://www.zurich.ibm.com/~rha

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 10 Jun 2005 08:24:04 -0400

> to my mind. Or am I missing sth ?

The motivation behind fig 11 is to show the different nesting levels a
path could take to get to the target path.
Can you redraw it so that we still show the deep nesting?
I actually didnt follow you completely - theres nothing i could see in
that tree that indicates it has few branches.

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Fri, 10 Jun 2005 14:53:30 +0200

I don't mean the example is illegal, I only think it is absurd, but I 
may be missing sth.
What about the following example of a tree with two branches ? I guess 
what I am saying is that a reasonable design would try to make the 
branches as short as possible.

       T = SET-CREATE
       |        |
       |       +- T = Path-data
       |          |
       |          + -- flags
       |          + -- IDCount
       |          + -- IDs
       |          |
       |          +- T = Path-data
       |           |    |
       |           |    + -- flags
       |           |    + -- IDCount
       |           |    + -- IDs
       |           |    + -- T = KEYINFO
       |           |    |    + -- KEY_ID
       |           |    |    + -- KEY_DATA
       |           |    |
       |           |    + -- T = DATARAW
       |           |         + -- data
       |           |
       |          +- T = Path-data
       |             |
       |             + -- flags
       |             + -- IDCount
       |             + -- IDs
       |             + -- T = KEYINFO
       |             |    + -- KEY_ID
       |             |    + -- KEY_DATA
       |             |
       |             + -- T = DATARAW
       |                  + -- data 

Regards,
-Robert

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 10 Jun 2005 16:21:24 -0400

Ok, there are two issues as i see it:
1) showing what is possible. Thats the goal of the example.
2) Showing whats sensible given what we know at the moment. This is what
you are striving for.

We should show #2 first, but we should show the possibilities
next. If we think it is ridiculous/absurd to have that flexibilty then 
the grammar shouldnt allow it - otherwise it's a poor design.  

cheers,
jamal