Subject: Re: [Issue 51]Operation Summary table

From: Weiming Wang <[email-masked]>
Date: Thu, 1 Sep 2005 21:53:00 +0800

Jamal,

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email-masked]>

> 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            |
> > |                            |           |                            |
> > |    Association Teardown    | ASTreason |            None            |
> > |                            |           |                            |
> > |           Config           | LFBselect |          SET, DEL          |
> > |                            |           |                            |
> > |       Config Response      | LFBselect | SET-RESPONSE, DEL-RESPONSE |
> > |                            |           |                            |
> > |            Query           | LFBselect |             GET            |
> > |                            |           |                            |
> > |       Query Response       | LFBselect |        GET-RESPONSE        |
> > |                            |           |                            |
> > |     Event Notification     | LFBselect |           REPORT           |
> > |                            |           |                            |
> > |       Packet Redirect      |  Redirect |            None            |
> > |                            |           |                            |
> > |          Heartbeat         |    None   |            None            |
> > +----------------------------+-----------+----------------------------+
> > 
> >    The following talbe summarises the applicability of the DATARAW TLV
> >    and the RESULT TLV to the Operation TLVs.
> > 
> >               +--------------+-------------+------------+
> >               |  Operations  | DATARAW TLV | RESULT TLV |
> >               +--------------+-------------+------------+
> >               |      SET     |     MUST    |  MUST NOT  |
> >               |              |             |            |
> >               | SET-RESPONSE |     MAY     |    MUST    |
> >               |              |             |            |
> >               |      DEL     |     MAY     |  MUST NOT  |
> >               |              |             |            |
> >               | DEL-RESPONSE |     MAY     |    MUST    |
> >               |              |             |            |
> >               |      GET     |   MUST NOT  |  MUST NOT  |
> >               |              |             |            |
> >               | GET-RESPONSE |     MUST    |     MAY    |
> >               |              |             |            |
> >               |    REPORT    |     MAY     |  MUST NOT  |
> >               +--------------+-------------+------------+

---

From: Weiming Wang <[email-masked]>
Date: Thu, 1 Sep 2005 22:11:18 +0800

Jamal,

----- Original Message ----- 
 
> > 
> >        - 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.   
Not very sure what you mean here. Can we just use 'NoACK' then?

> Shall we reduce it to a recommendation?:
> "The ACK indicator flag is used by the sender to indicate to the
> receiver how it wishes to see a response. As an example Config Message
> SHOULD always set this flag while other message types SHOULD NOT"
It may worth some more discussion here, regarding if using RECOMMEND may lead to some interoperability issues.

> 
> I used the word "example" because you have more clarifying text below.
> 
> >            The flag values are defined as below:
> > 
> >                'NoACK' (00) - to indicate the message receiver not to
> >                send any response message back to this message sender.
> 
> [..]
> 
> >            Also note that other messages than Config Message, whose
> >            requirements for responses are statistically prescribed by
> >            the message definitions in the followed Sections.  The ACK
> >            indicators in these messages MUST be ignored.
> > 
> 
> Another use of the term MUST above.
> 
> cheers,
> jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 1 Sep 2005 10:41:44 -0400

Hi Weiming,

> 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.
Does this makes sense?
 
cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Thu, 1 Sep 2005 11:02:38 -0400

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:
> 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
mathematics) so reducing ambiguity is useful.
 
> 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.
> 

yes, NoACK will do.

> lead to some interoperability issues.

I think if we explicitly say that the ACK flags override;
lets discuss tommorow.

cheers,
jamal

---

From: Weiming Wang <[email-masked]>
Date: Thu, 1 Sep 2005 23:23:51 +0800

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 1 Sep 2005 15:15:15 -0400

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
>
> > > >
> > > Very sorry, but I just cannot make it very clearly. Could you show 
> more of
> > > your thoughts on this?

---

From: Weiming Wang <[email-masked]>
Date: Fri, 2 Sep 2005 09:22:52 +0800

----- Original Message ----- 
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: [Issue 51]Operation Summary table

> say that any enclosure of an unknwon mandatory TLV is to be treated as an 
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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 1 Sep 2005 22:16:00 -0400

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:

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 2 Sep 2005 10:21:10 -0400

> argued that the biggest reason for using TLV encodings is to be able to 

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>
<From>Joel</From>
<CC>Jamal</CC>
</emailheader>

It should not die - rather ignore <CC> and still output:

Sender: Joel
Recipient: Weiming

It is good practise to log the extra <CC> tag that is not understood
but in practise specifying that it is to be ignored is a good idea.

Back to the draft:
We should recommend that unknown TLVs should be ignored.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Fri, 2 Sep 2005 22:28:45 +0800

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 2 Sep 2005 10:46:25 -0400

On Fri, 2005-02-09 at 22:28 +0800, Wang,Weiming wrote:
> 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?
> 

This is tricky;->
My instinct says section 2 where TLV is defined?
Right after text which describes 32 bit alignement a new paragraph 
with something like:

"TLVs are extensively used in the protocol and the different types 
of TLVs will be defined in this document. For purposes of future
extensibility, an implementation SHOULD ignore any TLVs it does
not recognize. It is good practise that a debugging log should be
emitted by the implementation to notify of the presence of unknown
TLVs." 

The last sentence may be pushing it a little to put in a standard
document. I used the term "debug" to imply it can be turned off.

cheers,
jamal

---

From: Avri Doria <[email-masked]>
Date: Sat, 3 Sep 2005 09:03:41 +0200

Hi,

Why is this a SHOULD, instead of a MUST?  If we are going to leave it  
as a SHOULD then we need to explain the case where it would be ok to  
not ignore it.

I think there should actually be a specific error that indicates it  
is a unknown TLV.  And I think it should be a different error then a  
parsing error since that might be an indication that it needs to be  
sent again.

a.