Subject: [irs-discuss] draft-ward-irs-framework

From: Thomas Nadeau <[email-masked]>
Date: Sun, 29 Jul 2012 09:39:57 -0700

We wanted to kick off the discussion here about the framework draft. What do you think? How can this be improved? Are we on the right track?

	The (proposed) Framework can be found here:

http://lucidvision.com/draft-ward-irs-framework-00.txt

	We will be sending out a problem statement draft later today as well.

	--Tom, Alia, Ward

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 29 Jul 2012 12:44:35 -0400

As far as I can tell, the document could use signifiantly more clarity 
on the problem to be solved, and the information modeling gaps that 
appear to exist, and much less (maybe none) discussion of why a new 
protocol is needed.  It seems to me that the descriptions of existing 
protocols tend to be based on assumptions that are not borne out by the 
rest of the document.

As an example, the assumption that the solution must be some form of 
streaming (whatever that means) is not grounded in the document.

Yours,
Joel M. Halpern

On 7/29/2012 12:39 PM, Thomas Nadeau wrote:
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 30 Jul 2012 18:19:45 -0400

Joel,

Thanks for the feedback.  I think the problem-statement draft (now at
http://tools.ietf.org/html/draft-atlas-irs-problem-statement-00)
focuses a bit more on the problem and less on the protocol aspects.

The framework does try to describe the need for data models that have
semantic meaning included - and gives some ideas on what information
might want to be in some of those data-models.  To get the details
correct, I think we'll want to drive from agreed upon specific
vertical use-cases.

I do think that, assuming there is interest, we want to move forward
to use-cases and nail down a small set of data-models to focus on, at
least with their requirements.  There could be multiple transfer
protocols, if we needed them, but it's quite premature to focus on the
protocol specifics now.

As for the protocol, I tried to focus on the key aspects and/or goals
that we think the interface needs to have.  I do apologize for the
extensive use of "streaming" in the doc - I added the key aspects part
and obviously didn't prune out the streaming adjective everywhere.
The intent was to to imply the asynchronous, duplex nature - not, say,
TCP like streaming.

Alia

On Sun, Jul 29, 2012 at 12:44 PM, Joel M. Halpern <[email-masked]> wrote:
> As far as I can tell, the document could use signifiantly more clarity on
> the problem to be solved, and the information modeling gaps that appear to
> exist, and much less (maybe none) discussion of why a new protocol is
> needed.  It seems to me that the descriptions of existing protocols tend to
> be based on assumptions that are not borne out by the rest of the document.
>
>>         We wanted to kick off the discussion here about the framework
>> draft. What do you think? How can this be improved? Are we on the right
>> track?
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 30 Jul 2012 18:33:55 -0400

Sounds good.  Thank you.
Joel