[p2p-sip] Revised concepts draft

[bryan at ethernot.org (David A. Bryan)]

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

On 8/21/06, Eunsoo Shim <eunsoo at research.panasonic.com> wrote:
> David A. Bryan wrote:
>
> > 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.
>
> 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.
>
> >
> > 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.
>
> 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
> > 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 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
> > 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.
> >
> 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
>
> >
> > I
> >
> > On 8/21/06, Eunsoo Shim <eunsoo at research.panasonic.com> wrote:
> >
> >> 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
> >> Scott W Brim wrote:
> >>
> >> >On 08/21/2006 10:36 AM, Dean Willis allegedly wrote:
> >> >
> >> >
> >> >>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?
> >> >>
> >> >>
> >> >
> >> >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.
> >> >_______________________________________________
> >> >p2p-sip mailing list
> >> >p2p-sip at cs.columbia.edu
> >> >https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> >> >
> >> >
> >>
> >> _______________________________________________
> >> p2p-sip mailing list
> >> p2p-sip at cs.columbia.edu
> >> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> >>
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>