Subject: [p2p-sip] Revised concepts draft

From: dean.willis at softarmor.com (Dean Willis)
Date: Fri, 18 Aug 2006 16:31:27 -0500

I've submitted -01 of the concepts and terminologies draft.  It  
should show up in the IETF archive next week. Until then, a copy is  
available at:

http://www.softarmor.com/dwillis/docs/draft-willis-p2psip- 
concepts-01.txt

I made no substantive changes in this document -- just corrections  
and clarifications resulting from discussion on the list.

I'm still not completely happy with the reference model and its  
handling -- I think it's still inadequate to show the defined words  
"in context".

I started to add a use-cases section that takes a couple of the  
simpler use-cases and presents them using the terminology in this  
draft. But I didn't quite get there by my self-imposed 01 deadline  
(today). What do you fols think of adding this sort of discussion to  
this draft? Or do you have better ways to render the reference model  
and its discussion?

--
Dean

---

From: hu.xinyu at huawei.com (Seaward Hu)
Date: Mon, 21 Aug 2006 09:42:28 +0800

I'd like to provide some use cases to your draft if you will to discuss it.

Thanks.

Seaward 

> -----Original Message-----
> From: p2p-sip-bounces at cs.columbia.edu 
> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Dean Willis
> Sent: Saturday, August 19, 2006 5:31 AM
> To: p2p-sip at cs.columbia.edu
> Subject: [p2p-sip] Revised concepts draft
> 
> 
> I've submitted -01 of the concepts and terminologies draft.  
> It should show up in the IETF archive next week. Until then, 
> a copy is available at:
> 
> I made no substantive changes in this document -- just 
> corrections and clarifications resulting from discussion on the list.
> 
> I'm still not completely happy with the reference model and 
> its handling -- I think it's still inadequate to show the 
> defined words "in context".
> 
> I started to add a use-cases section that takes a couple of 
> the simpler use-cases and presents them using the terminology 
> in this draft. But I didn't quite get there by my 
> self-imposed 01 deadline (today). What do you fols think of 
> adding this sort of discussion to this draft? Or do you have 
> better ways to render the reference model and its discussion?
> 
> --
> Dean
> 
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Mon, 21 Aug 2006 09:36:46 -0500

I'm amenable, but it is possible that the group might think we should  
revise the use cases draft using the language of the concepts and  
terminology draft rather than putting use cases into the concepts and  
terminology draft.

What is the "happy medium" here, folks?

--
Dean

---

From: swb at employees.org (Scott W Brim)
Date: Mon, 21 Aug 2006 11:06:44 -0400

> What is the "happy medium" here, folks?

Concepts and terminology make it possible to talk about use cases and
have some confidence that we agree on what they actually mean.  Use
cases clarify the scope and test the C&T to make sure they are useful
when applied to the real world.  In general for most WGs I think these
two should be together in one draft (call it a "framework").  You're
going to be iterating back and forth anyway, since each depends on and
supports the other.  I think we should try the experiment of putting
them all in one draft.  If it turns out to be more confusing than
having them separate, we can easily separate them again.

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Mon, 21 Aug 2006 11:11:37 -0400

>terminology draft rather than putting use cases into the concepts and  
I agree to this.
We are planning to revise the use case draft before the next IETF meeting.
If Seaward provides use cases, we would be happy to think how to
incorporate them into the use case draft.
Thanks.

Eunsoo

---

From: br at brianrosen.net (Brian Rosen)
Date: Mon, 21 Aug 2006 11:28:47 -0400

I'd agree with Scott.

Dean, might it be possible for you to work with Eunsoo and possibly Seaward
to get a combined draft out so we could see what it looked like?

Brian

> From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-
> bounces at cs.columbia.edu] On Behalf Of Scott W Brim
> Sent: Monday, August 21, 2006 11:07 AM
> To: Dean Willis
> Cc: p2p-sip at cs.columbia.edu
> Subject: Re: [p2p-sip] Revised concepts draft
>

---

From: bryan at ethernot.org (David A. Bryan)
Date: Mon, 21 Aug 2006 12:08:37 -0400

Seems my earlier message a few hours ago from my BlackBerry is stuck
in moderator land...I'll send again and kill that one...sorry if it
ends up through twice

Personally, my initial thought was that keeping the drafts seperate
might make more sense, simply because of the size of these things. As
Eunsoo pointed out, we plan to rev this -- Eunsoo felt he didn't have
time until September when I last approached him, otherwise we would
have reved already (since it is expired).

If we do merge them, as one of the other two authors on the use cases
draft I'm happy to help (and can start work today, if we feel time is
critical)

My main suggestion however is that Seaward should mention the other
use cases he was interested in to the list. There are a large number
of cases in the draft, and we can start a discussion thread with
Seaward's suggestion to see if we have gaps.

--David

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Mon, 21 Aug 2006 12:06:57 -0400

I think we need to think about what we look for from documenting use cases.

In my understanding, the current use case draft focuses on listing all
possible (and significant) use cases of P2P SIP. It was an effort to
convince people of importance and usefulness of P2P SIP in a sense. I
think documenting them has some value at least for a while.
Another motivation for the draft was to help in identifying the use
cases the group should/want to focus on. I am not sure whether this is
critical any more considering that the group made a significant progress
in defining the work items for the initial charter. I wonder what other
people think about this.

Since we introduced many new terms in the terminology and concept draft,
there arised a need for illustration of the terms, in particular, the
roles of the architectural components. However, an illustration of the
role of particular architectural component like the P2PSIP Overlay Peer
Protocol does not have to depend on details of specific use cases. For
example, it does not require to say whether it is used in a corporate
network environment or in the global Internet scale. So I am not sure we
need to integrate the current use case draft and the terminology and
concept draft.

What we need is general illusrations of the roles of the architectural
components in example architectures. Fortunately there is already a
draft doing it, even though using different terms. The architecture
described in draft-shim-sipping-p2p-arch-00.txt is almost the same as or
at least very close to the concepts in the terminology and concept
draft. The architecture draft is already being revised to use the same
terms defined in the terminology and concept draft.

We might want to keep the terminology and concept draft as a collection
of the terms and basic concepts with their concise definitions so that
it can be referred to in most (possibly all) P2P SIP related drafts. And
we can collect architecture illustrations in the architecture draft,
possibly listing some architecture variations. Some stuff like a data
format for user location can be removed from the architecture draft.

The final details of what a particular component MAY/SHOULD/MUST do and
not do will be described in the protocol specification drafts.
Eventually people will come up with lots of creative use cases and
architecture variations we don't think of now.

My 2 cents.
Thanks.

Eunsoo

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Mon, 21 Aug 2006 12:24:09 -0400

I think that for now the use-cases draft should remain separate and,
if there are significant new use cases proposed to add to it, they
should be added.  We should also revise it to reflect the current
terminology, of course.  A number of decisions were made about what
will be in-scope and out-of-scope at the last ad hoc.  In the process
of forming the WG and finalizing the charter, those decisions will be
re-examined and formalized/changed.  My understanding is that the
use-cases document will need to be trimmed, updated, merged, etc at
that point to reflect use-cases that fall within the proposed scope of
the charter.  I think merging it with the terminology draft at this
point would be premature.

Bruce

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Mon, 21 Aug 2006 10:00:39 -0700

I agree the two drafts should remain separate.

Thanks, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Bruce Lowekamp
Sent: Monday, August 21, 2006 11:24 AM
To: Eunsoo Shim
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Revised concepts draft

Bruce

---

From: bryan at ethernot.org (David A. Bryan)
Date: Mon, 21 Aug 2006 10:11:49 -0700

I think I'd have to differ a bit here. I think the use cases draft is
still quite valuable, and should be expanded going forward, possibly
with some context about which cases are being addressed by the current
scoped work and by combining with the requirements document as I
mention below.

The architecture draft you mention (which I actually think should be
considered more of a proposed design or solution than a generic
architecture draft) is a good bit more about details of a particular
vision of how to put something together than details of how things
P2PSIP would be used. (in that way, I view it as very much like the
non-normative parts of my p2p registration draft) My thought is that
the use cases (and possibly the requirements
draft-baset-sipping-p2preq-00) drafts that are out there should be
about what people would like to do with P2PSIP, and the concepts and
terminology document can be more about where we are going and the
architecture.

Since there is already a good bit of architecture work in that
document, and architecture that reflects discussion of a larger group
(Dean, Philip and myself, obviously, but many others through
discussion), I'd argue expanding the architecture work in that
document would be the best way to move toward a new architecture
draft, rather than merging it with earlier work. I would then suggest
combining the existing use cases and requirements into one draft. The
new architecture can of course combine elements of the particular
solution proposed in shim-sipping-p2p-arch, as I would hope it would
from other proposed approaches so far such as my own
draft-bryan-sipping-p2p, but I think that we have made lots of headway
on the work and architecture in draft-willis-p2psip-concepts being
accepted by many parties, particularly in our discussions at the last
ad-hoc, and would like to see that used as the foundation going
forward, rather than merging in older (and more contentious) work.

David

I

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Mon, 21 Aug 2006 14:05:48 -0400

> scoped work and by combining with the requirements document as I

If we want to add requrements analysis in the use cases draft, I think
there are two possible paths:
One path is that we analyze requirements of all the use cases, compare
them, and reorganize use cases according to similarity of requirements.
I am not sure whether the exercise is necessary considering it is a
significant work and we have made a significant progress in defining
work items.
Another path is that we somehow select some use cases we want to make
sure feasible with the protocol to be produced and prune all other use
cases from the use cases draft. Then we add analysis of the requirements
of those use cases. I would prefer this path.
In any case, the documented use cases will be just references, putting
no restrictions on how people will use the protocols in creative ways.

> P2PSIP would be used. 

Well, I am not sure I agree to this. The intention was to provide a
general architecture description, concrete enough for charter
discussion. Anyway...

> (in that way, I view it as very much like the
> draft, rather than merging it with earlier work.

I am not sure whether this is an important point but please let me say
this. In terms of architecture in the two drafts, I think they are
almost the same except terminology. Only architectural difference may be
about whether there may be NATs between Peers (or Super Nodes).

> I would then suggest
I think the contention was pretty much resolved since the concept in the
terminology and concept draft is almost the same as what is described in
the work. We should reuse what was already done rather than redo it.

Anyway I think we should discuss what needs to be done more regarding
architecture rather than how to organize documents about architecture.
Once we know it, we will know better about proper organization.

Thanks.

Eunsoo

---

From: bryan at ethernot.org (David A. Bryan)
Date: Mon, 21 Aug 2006 11:49:54 -0700

Let me just leave it at I don't think it is at all true that the
architecture in your original draft and the one in the concepts and
terminology document are at all the same. Your earlier design draft
presupposes solutions to a number of still contentious points
including NAT locations, separation of lookup and signaling, SIP vs.
non-SIP protocol, and even detailed message formats and APIs. I'm not
suggesting we throw that work out, but I very strongly disagree that
it is the same as the concepts and terminology architecture or should
therefore be incorporated.

That aside, I fully agree on your suggestion that we should focus on
the discussion itself rather than which documents to merge. We are way
off in the weeds here arguing about exactly how to do this and should
refocus on what is needed to move the group forward. The debate about
exactly how to build this comes later. Lets stop this and refocus on
getting toward a charter.

--David