headers
Weiming Wang | 1 Sep 2005 15:53
Picon

Re: [Issue 51]Operation Summary table

Jamal,

----- Original Message ----- 
From: "Jamal Hadi Salim" <hadi <at> znyx.com>

> Hi Weiming,
> 
> Since you MAY have this already in your text.
> 
> So what happens if someone adds a new TLV or operation that goes in
> addition with the already defined one? I think we need to specify the
> behavior. Example it could be "Ignore". Actually i think it should be
> "Ignore" for backward compatibility reasons.
Very sorry, but I just cannot make it very clearly. Could you show more of your thoughts on this?
I'm not sure where other than in the protocol more op TLVs can be defined.
 
Thanks,
Weiming
> 
> cheers,
> jamal
> 
> 
> > +----------------------------+-----------+----------------------------+
> > |          Messages          |    TLVs   |         Operations         |
> > +----------------------------+-----------+----------------------------+
> > |      Association Setup     | LFBselect |           REPORT           |
> > |                            |           |                            |
> > | Association Setup Response | ASRresult |            None            |
> > |                            |           |                            |
(Continue reading)

Permalink | Reply | 8 comments |
headers
Weiming Wang | 1 Sep 2005 16:11
Picon

Re: [issue 34] Header flags

Jamal,

----- Original Message ----- 
From: "Jamal Hadi Salim" <hadi <at> znyx.com>
 
> > 
> >        - ACK: ACK indicator(2 bit)
> >            The ACK indicator flag is only used by a Config Message
> >            sender to indicate the message receiver whether or not a
> >            config response is required by the sender.  Note that all
> >            other messages than Config Message MUST ignore this flag.
> > 
> 
> I apologize to bring this up at the last minute; I missed following up
> this discussion that you had with Joel.  Also, in your discussion with
> Joel you said the flag was for "acknowledgement rather than response"; 
> I dont see the difference between the two.
This is more semantically based I think. We now define a response more as an operation response, while an ack
as a whole message. Whereas I agree with you that it may be not very vital for us to distinguish them.

> Must we use such strong language above? Example, while probably not very
> likely, a) I could send a heartbeat (which is not a Config msg) that i
> request a response for - setting the ACK flag allows me to 
The thought I use MUST here is trying to avoid leading to complex discussion of  interoperability problem.
I'm not very sure if we use SHOULD here will result in some problem of this. For instance, as your example
above, I don't know if it will make the both CE(one vendor) and FE(another vendor) parts at a loss what to do
if FE sets the heartbeat ACK as 'AlwaysACK', some CE may reply but some may not, while the FE is always
waiting for the ACK then.

>and b) I may not wish to recieve a response for a certain config.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jamal Hadi Salim | 1 Sep 2005 16:41

Re: [Issue 51]Operation Summary table

Hi Weiming,

On Thu, 2005-01-09 at 21:53 +0800, Weiming Wang wrote:
> Jamal,
> 
> ----- Original Message ----- 
> From: "Jamal Hadi Salim" <hadi <at> znyx.com>
> 
> > Hi Weiming,
> > 
> > Since you MAY have this already in your text.
> > 
> > So what happens if someone adds a new TLV or operation that goes in
> > addition with the already defined one? I think we need to specify the
> > behavior. Example it could be "Ignore". Actually i think it should be
> > "Ignore" for backward compatibility reasons.
> Very sorry, but I just cannot make it very clearly. Could you show more of 
> your thoughts on this?
> I'm not sure where other than in the protocol more op TLVs can be defined.
>  

The possibility is there to add new TLVs that could be actually be
future extensions (protocol updates). This could happen after the
protocol becomes RFC. If someone implements the protocol according to
current spec and meet some of these TLVs in the field in the future, how
should they handle them? Typically with other protocols which dont use
TLVs, this would be hard to handle and may require strict versioning and
even rewriting of existing implementations.
We dont have this kind of problem since we use TLVs - but to deal with
this well, we need to define the behavior of how an implementation deals
(Continue reading)

Permalink | Reply | 7 comments |
headers
Jamal Hadi Salim | 1 Sep 2005 17:02

Re: [issue 34] Header flags

Weiming,

Maybe we should make this an agenda item for tommorows concal.
More inline.

On Thu, 2005-01-09 at 22:11 +0800, Weiming Wang wrote:
> Jamal,
> 
> ----- Original Message ----- 
> From: "Jamal Hadi Salim" <hadi <at> znyx.com>
>  
> > > 
> > >        - ACK: ACK indicator(2 bit)
> > >            The ACK indicator flag is only used by a Config Message
> > >            sender to indicate the message receiver whether or not a
> > >            config response is required by the sender.  Note that all
> > >            other messages than Config Message MUST ignore this flag.
> > > 
> > 
> > I apologize to bring this up at the last minute; I missed following up
> > this discussion that you had with Joel.  Also, in your discussion with
> > Joel you said the flag was for "acknowledgement rather than response"; 
> > I dont see the difference between the two.
> This is more semantically based I think. We now define a response more as 
> an operation response, while an ack as a whole message. Whereas I agree 
> with you that it may be not very vital for us to distinguish them.
> 

Then we need to explicitly define what an ACK vs response means like you
say above. Unfortunately we are using the English language (instead of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Weiming Wang | 1 Sep 2005 17:23
Picon

Re: [Issue 51]Operation Summary table

Jamal, 

Sorry, after reading your text below, I'm still not very sure what you mean. Can you just show how you suggest
we should do next on this?

Thanks a lot.
Weiming

> > > 
> > > Since you MAY have this already in your text.
> > > 
> > > So what happens if someone adds a new TLV or operation that goes in
> > > addition with the already defined one? I think we need to specify the
> > > behavior. Example it could be "Ignore". Actually i think it should be
> > > "Ignore" for backward compatibility reasons.
> > Very sorry, but I just cannot make it very clearly. Could you show more of 
> > your thoughts on this?
> > I'm not sure where other than in the protocol more op TLVs can be defined.
> >  
> 
> The possibility is there to add new TLVs that could be actually be
> future extensions (protocol updates). This could happen after the
> protocol becomes RFC. If someone implements the protocol according to
> current spec and meet some of these TLVs in the field in the future, how
> should they handle them? Typically with other protocols which dont use
> TLVs, this would be hard to handle and may require strict versioning and
> even rewriting of existing implementations.
> We dont have this kind of problem since we use TLVs - but to deal with
> this well, we need to define the behavior of how an implementation deals
> when it sees and unknown T.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Joel M. Halpern | 1 Sep 2005 21:15

Re: [Issue 51]Operation Summary table

The issue alluded to, assuming I am understand it properly, is that the 
protocol needs to specify what a receiver should do if it receives a TLV it 
does not understand in a message it does understand.
I believe we should simply have it be ignored.
We could allocate one bit from the type code space as a mandatory bit, and 
say that any enclosure of an unknwon mandatory TLV is to be treated as an 
error.

Yours,
Joel

At 11:23 AM 9/1/2005, Weiming Wang wrote:
>Jamal,
>
>Sorry, after reading your text below, I'm still not very sure what you 
>mean. Can you just show how you suggest we should do next on this?
>
>Thanks a lot.
>Weiming
>
> > > >
> > > > Since you MAY have this already in your text.
> > > >
> > > > So what happens if someone adds a new TLV or operation that goes in
> > > > addition with the already defined one? I think we need to specify the
> > > > behavior. Example it could be "Ignore". Actually i think it should be
> > > > "Ignore" for backward compatibility reasons.
> > > Very sorry, but I just cannot make it very clearly. Could you show 
> more of
> > > your thoughts on this?
(Continue reading)

Permalink | Reply | 5 comments |
headers
Weiming Wang | 2 Sep 2005 03:22
Picon

Re: [Issue 51]Operation Summary table


----- Original Message ----- 
From: "Joel M. Halpern" <joel <at> stevecrocker.com>
Subject: Re: [Issue 51]Operation Summary table


> The issue alluded to, assuming I am understand it properly, is that the 
> protocol needs to specify what a receiver should do if it receives a TLV it 
> does not understand in a message it does understand.
> I believe we should simply have it be ignored.
> We could allocate one bit from the type code space as a mandatory bit, and 
> say that any enclosure of an unknwon mandatory TLV is to be treated as an 
> error.
I think such thing as an unknown TLV appears during parsing of a received message will always possibly
happen, rather than happen at the Operaion TLV level.  All this should be treated as a kind of error,  the
parsing error.  I don't think we need to sepcify more on such error processing, or we may get  too much to deal with.

Thanks,
Weiming
> 
> Yours,
> Joel
> 
> At 11:23 AM 9/1/2005, Weiming Wang wrote:
> >Jamal,
> >
> >Sorry, after reading your text below, I'm still not very sure what you 
> >mean. Can you just show how you suggest we should do next on this?
> >
> >Thanks a lot.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Joel M. Halpern | 2 Sep 2005 04:16

Re: [Issue 51]Operation Summary table

Treating unknown TLVs as always being parsing errors is one feasible and 
consistent definition.
However, that means that if one is upgrading the protocol, one needs to 
either upgrade the CE and all the FEs at once, or once must do version 
negotiation.

It is often the case that there can be additions to the protocol (new TLVs) 
that can be ignored if they are not understood. In fact, it is usually 
argued that the biggest reason for using TLV encodings is to be able to 
ignore unknown elements.

Yours,
Joel M. Halpern

At 09:22 PM 9/1/2005, Weiming Wang wrote:

>----- Original Message -----
>From: "Joel M. Halpern" <joel <at> stevecrocker.com>
>Subject: Re: [Issue 51]Operation Summary table
>
>
> > The issue alluded to, assuming I am understand it properly, is that the
> > protocol needs to specify what a receiver should do if it receives a 
> TLV it
> > does not understand in a message it does understand.
> > I believe we should simply have it be ignored.
> > We could allocate one bit from the type code space as a mandatory bit, and
> > say that any enclosure of an unknwon mandatory TLV is to be treated as an
> > error.
>I think such thing as an unknown TLV appears during parsing of a received
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jamal Hadi Salim | 2 Sep 2005 16:21

Re: [Issue 51]Operation Summary table

On Thu, 2005-01-09 at 22:16 -0400, Joel M. Halpern wrote:
> Treating unknown TLVs as always being parsing errors is one feasible and 
> consistent definition.
> However, that means that if one is upgrading the protocol, one needs to 
> either upgrade the CE and all the FEs at once, or once must do version 
> negotiation.
> 
> It is often the case that there can be additions to the protocol (new TLVs) 
> that can be ignored if they are not understood. In fact, it is usually 
> argued that the biggest reason for using TLV encodings is to be able to 
> ignore unknown elements.
> 

Indeed.
Weiming, heres an example/analogy in XML that I have often seen used:

<emailheader>
<TO>Weiming</TO>
<From>Joel</From>
</emailheader>

Lets say you wrote an app that parsed and output the following:

Sender: Joel
Recipient: Weiming

Now lets say your app 10 years down the road met the following XML

<emailheader>
<TO>Weiming</TO>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wang,Weiming | 2 Sep 2005 16:28
Picon

Re: [Issue 51]Operation Summary table

Jamal and Joel,

That makes sense to me. I agree. I think the text of assumption to ignore unknown TLVs can be added at the
"protocol grammar" section, is it ok?

Thanks,
Weiming
----- Original Message ----- 
From: "Jamal Hadi Salim" <hadi <at> znyx.com>
To: <FORCES <at> PEACH.EASE.LSOFT.COM>
Sent: Friday, September 02, 2005 10:21 PM
Subject: Re: [Issue 51]Operation Summary table


> On Thu, 2005-01-09 at 22:16 -0400, Joel M. Halpern wrote:
> > Treating unknown TLVs as always being parsing errors is one feasible and 
> > consistent definition.
> > However, that means that if one is upgrading the protocol, one needs to 
> > either upgrade the CE and all the FEs at once, or once must do version 
> > negotiation.
> > 
> > It is often the case that there can be additions to the protocol (new TLVs) 
> > that can be ignored if they are not understood. In fact, it is usually 
> > argued that the biggest reason for using TLV encodings is to be able to 
> > ignore unknown elements.
> > 
> 
> Indeed.
> Weiming, heres an example/analogy in XML that I have often seen used:
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane