Subject: [forces] Feedback needed WAS(Fwd: New Version Notification for draft-ietf-forces-protoextension-02.txt

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 3 Jun 2014 12:06:07 -0400

Folks,

Please provide some feedback in particular on having to deal with a CE or FE
not being able to deal with result TLVs. We have not implemented what
is described
in this document in terms of updating FEPO. At the moment we are just assuming
EXTENDEDRESULT-TLV because both sides of the implementation are ours.

My thinking on this subject is:
If i was to do things from scratch, given our current deployment experience
I would just do EXTENDEDRESULT and totally throw out RESULT TLV.
Using FEPO components and capabilities is one way to address this; it
is a little
cluttered and requires an update. Any other suggestions welcome.

Thoughts?

cheers,
jamal

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Tue, Jun 3, 2014 at 12:00 PM
Subject: New Version Notification for draft-ietf-forces-protoextension-02.txt
To: Jamal Hadi Salim <[email-masked]>

A new version of I-D, draft-ietf-forces-protoextension-02.txt
has been successfully submitted by Jamal Hadi Salim and posted to the
IETF repository.

Name:           draft-ietf-forces-protoextension
Revision:       02
Title:          ForCES Protocol Extensions
Document date:  2014-06-03
Group:          forces
Pages:          23
URL:
http://www.ietf.org/internet-drafts/draft-ietf-forces-protoextension-02.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-forces-protoextension/
Htmlized:       http://tools.ietf.org/html/draft-ietf-forces-protoextension-02
Diff:
http://www.ietf.org/rfcdiff?url2=draft-ietf-forces-protoextension-02

Abstract:
   Experience in implementing and deploying ForCES architecture has
   demonstrated need for a few small extensions both to ease
   programmability and to improve wire efficiency of some transactions.
   This document describes extensions to the ForCES Protocol
   Specification[RFC 5810] semantics to achieve that end goal.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Haleplidis Evangelos" <[email-masked]>
Date: Fri, 6 Jun 2014 17:34:09 +0300

Greetings Jamal and to the list,

I just read the protocol extension draft and have the following
comments/questions:

1. Considering the table ranges, I tried to find in the original RFC 5810 as
well whether we allow nested PATH-DATA when you have a KEYSELECTOR. 
There is no clear text (at least I didn't find any) that allows or disallows
further nesting of PATH-DATA after a KEYSELECTOR. 

The same applies to the table ranges. Do we allow nested path-datas when a
table range is present? I'm trying to think of a use case where such case.
E.g. where I want from these specific rows one or more specific components
(e.g. in the case of a struct) or rows in a specific array.

Whatever we decide, it may make sense to explicitly define it in the text.

2. This more of a musing than a comment. Does it make sense to have more
than one table ranges TLV in one path-data TLV?
E.g. if you want rows 5-100 and 400-500. Agreed that this can be done with
two PathDatas, and having multiple range TLVs may confuse, e.g. asking for
40-100 and 60-70.
I'm mostly pro into having it as it is (only one table range).

3. Why limit the response in a table range be ONLY within a SPARSEDATA? You
can use FULLDATA with the index prefixed.

4. Regarding the Extended Result Backward compatibility. You are adding
knobs that change the nature of the protocol itself (e.g. Support only
Extended Results) and that may complicate the FEPO unnecessary.
The question is whether that consists of a protocol change. On the other
hand we have only 4 bits for protocol changes and this may not constitute
such a big change for a new protocol version.

Regards,
Evangelos Haleplidis.

> -----Original Message-----
> From: forces [mailto:[email-masked]] On Behalf Of Jamal Hadi
> Salim
> Sent: Tuesday, June 03, 2014 7:06 PM
> To: [email-masked]
> Subject: [forces] Feedback needed WAS(Fwd: New Version Notification for
> draft-ietf-forces-protoextension-02.txt
> 
> Folks,
> 
> Please provide some feedback in particular on having to deal with a CE
> or FE not being able to deal with result TLVs. We have not implemented
> what is described in this document in terms of updating FEPO. At the
> moment we are just assuming EXTENDEDRESULT-TLV because both sides of
> the implementation are ours.
> 
> If i was to do things from scratch, given our current deployment
> experience I would just do EXTENDEDRESULT and totally throw out RESULT
> TLV.
> is a little cluttered and requires an update. Any other suggestions
> welcome.
> 
> Thoughts?
> 
> cheers,
> jamal
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> forces mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/forces

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 9 Jun 2014 07:47:06 -0400

Greetings Evangelos,

> Whatever we decide, it may make sense to explicitly define it in the text.

So we've never had need to mix both. Either we use KEYSELECTOR or
RANGE or classical path. I cant think of any use case that would need at
least two of those together. Joel?

> I'm mostly pro into having it as it is (only one table range).

I think for starters a single range should be sufficient in my opinion.
We did start with this great multi path approach, in practise with
this particular
approach simplicity seems to trump the efficiency.

> can use FULLDATA with the index prefixed.

Mostly because the response itself is SPARSE. A FULLDATA could be used;
but my experience so far on usability vs efficiency - Ive almost given up on
FULLDATA for a table row. People dont think through their model sometimes
and it makes it hard to use FULLDATA in such a case.
Joel was very much against the idea of FULLDATA in the early days and
i was for it.
Having gone through the experience, I would say the return on the investment is
not worth the effort. In our implementation, we still will
receive/process FULLDATA
rows, but we never send them out.
I am not sure if this document is the right place to describe this.

> such a big change for a new protocol version.

Yes, this is the biggest worry I have. You are right, we could go and
define a new protocol
version - but like you say, soon we will run out of protocol numbers if we have
to make these changes for every little protocol extension.
So what i just added is atrocious but saves us from doing that.
There's probably a better way.

cheers,
jamal

---

From: Joel <[email-masked]>
Date: Mon, 09 Jun 2014 10:02:54 -0400

I can construct use cases where you might want that information.
But at least at first glance the prasing complexity seems to exceed the 
value gained by allowing it.

Yours,
Joel