Subject: [forces] forces encapsulation issues that need to be discussed

From: "Chuanhuang Li" <[email-masked]>
Date: Fri, 25 Feb 2011 08:41:15 +0800

Hi, All
	 Through the interop test in yeaterday, We found some encapuslation issues that need to
 be discussed.  
1: When CE send a config/query forces message, Whether should FE send the same pathdata 
encapsulation format response to FE? We think it should.(RFC5810 does not describe it.)
For example: If our CE send a query message with only one path(FEID.LFBClassid.LFBinstanseID:1.1.1) 
to Ken's FE, then we think FE should send the same encapsulation format, and the value with FULL/SPARSE data, 
but not the format of many paratactic pathdata TLV and nested pathdata TLV.
SHOULD:
   PATH DATA (id:1.2)
        FULL DATA(a,b)
But Not:
   PATH DATA
      PATH DATA 
         FULL DATA 
      PATH DATA
         FULL DATA 
      ...... 
2: About the operation for array:
If CE want to create a new entry, should FE support the encapsulation format of pathdata TLV nested
paratactic pathedata TLV. From implementation view, we think CE should use the simplest 
format to encap. Then it will decrease FE's inconvenient operation.  (Does RFC5810 need some specification?)
For example: A component is array, and there are two elements(a and b) in one entry, CE should send
the message like this:
SET:
   PATH DATA (id:1.2)
        FULL DATA(a,b)
But not:
SET:
   PATH DATA
      PATH DATA(id:1) 
         FULL DATA (a)
      PATH DATA(id:2) 
         FULL DATA (b)

What's your opion?  Thanks!

Yours,
Chuanhuang

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 24 Feb 2011 20:31:13 -0500

Hi Chuanhuang,

> but not the format of many paratactic pathdata TLV and nested pathdata TLV.

Is the query for 1.2 or 1.1.1?
Ignoring the path data construction, if the response is correct then:
I think a receiver (CE in this case) must be able to parse/handle all formats.
It would be nice if the FE responded in the same format, but is should
not be mandatory.

> What's your opion?  Thanks!

My opinion is the same as before, i.e for minimal interop:
The FE should be able to handle/parse all legitimate syntax.
It may send out only one way, but should support all legitimate
path data it receives.
It is the principle of robustness - A good summary:
https://secure.wikimedia.org/wikipedia/en/wiki/Robustness_principle
and my favorite part (that wont fit on a tshirt):
"assume that the network is filled with malevolent entities that will
send in packets designed to have the worst possible effect"

cheers,
jamal

---

From: "Chuanhuang Li" <[email-masked]>
Date: Fri, 25 Feb 2011 10:38:39 +0800

Hi,Jamal
    For the first issue, the query path is 1.1.1,CE wants to get all the components 
information. 
    Of course, according RFC5810, there are many path data encapsulation formats 
are available. All the issues i raised was based on an implementation user. I think we 
had better do some constraint(or description) on these issues in RFC. It will be useful 
(or be a guideline) to a user. Also, I think we should recommend user to use the simplest 
format, but not make the things complicated. 
	In the second issue, if user uses the encapsulation format of pathdata TLV nested 
paratactic pathedata TLVs to create one entry of an array, it is so strange. User maybe 
have to do two operations to complete it.

Yours,
Chuanhuang

======= 2011-02-25 09:26:50 Jamal Hadi Salim, wrote: =======

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 24 Feb 2011 22:44:00 -0500

Hi Chuanhuang,

>    For the first issue, the query path is 1.1.1,CE wants to get all the components

ok

> format, but not make the things complicated.

IMO: If over the years we find that certain grammar is not good we
should remove it.

> have to do two operations to complete it.

The interop result draft should say these things. The important thing is that
the receiver MUST handle any form of legitimate syntax it receives. It may
not be efficient to compute - but that likely depends on implementation.
If all people attending interop agree that certain encoding is a bad idea,
then this should be highlighted in the draft.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 26 Feb 2011 10:42:22 -0500

I just want to reiterate and paraphrase Jamal's point.

Unless we want to remove some of the encapsulations from the document (a 
step I am strongly against), a receiver should be prepared to accept and 
process information (requests and responses) that use any legitimate 
structure.  A sender is free to choose whatever structure best suits its 
implementation strategy.

Yours,
Joel

On 2/24/2011 10:44 PM, Jamal Hadi Salim wrote:
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces
>