Subject: [p2p-sip] Issues in Draft Charter of 17 Jan 2006

From: royrr at us.saic.com (Roy, Radhika R.)
Date: Fri, 27 Jan 2006 11:29:46 -0500

Kindly take care of the FW/NAT issue as Michael pointed out.
 
BR/Radhika

  _____  

From: p2p-sip-bounces at cs.columbia.edu on behalf of Philip Matthews
Sent: Fri 1/27/2006 11:19 AM
To: P2P-SIP
Subject: [p2p-sip] Issues in Draft Charter of 17 Jan 2006

Folks: 

To try to bring some focus into our draft charter discussions, 
I have stolen an idea I saw used very effectively in the BGP WG and  
created a document 
that tracks the issues in the draft charter. Hopefully this will  
allow us 
to identify the issues and bring them to a resolution. 

I have reproduced this document below (it is just a text file). 

For issue #1, raised by Henry, I have marked it tentatively resolved 
because Henry has said he is happy with the existing text. Speak up 
on the mailing list if you disagree. 

The other issues are still open. 

I have tried to list all the issues that people have raised. If I  
have missed something, 
just sent me an e-mail with a pointer to the message and I will add  
it to the document. 
Going forward, I plan to add issues as I see them appear on the  
mailing list 
(again, if I miss something, just let me know) 

I will try to include an abbreviated version of the discussion in the  
document. 
By necessity, this abbreviation will be subjective, and people will  
need to look at the mailing list 
for the full discussion. However, if you feel your points have been  
misrepresented, 
then let me know. 

- Philip 

--------------------- 

Issues in proposed P2P-SIP charter draft 
(in the version posted by David Bryan on 17 Jan 2006) 

Summary: 
        - 6 issues in total 
        - 1 tentatively closed (pending confirmation by group) 
        - 5 still open 

Issue 1: Reference to P2PRG 
Existing Text: 
        The working group will operate in close cooperation with the SIP, 
        SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the 
        IRTF. 
Proposed Text: 
        (Unclear) 
Proposed by: Henry Sinnreich 
Discussion: Henry is now happy with the existing text. No one else  
has indicated 
that he/she would like to see a change. 
Resolution: CLOSED? 

Issue 2: Description of conventional SIP. 
Existing Text: 
        This is an alternative to the conventional SIP approach of 
        using a hierarchy of proxies where the mapping of users to proxies
is 
        determined by a combination of out-of-band and geographic
mechanisms. 
Proposed Text: 
        This is an alternative to the conventional SIP approach of 
        relying on service provider hosted proxies to which users get  
assigned by 
        out-of-band means, usually based on geography, association or  
business reasons. 
Proposed by: Aki Niemi 
Discussion: 
[Aki Niemi] 
        The [original] sentence is a bit too sophisticated to efficiently  
communicate 
        the message. How about simply saying that the conventional SIP
approach 
        relies on service provider hosted proxies to which users get  
assigned by 
        out-of-band means, usually based on geography, association or
business 
        reasons. 
Resolution: OPEN 

Issue 3: Namespace 
Existing Text: 
        1. Peer associations groups, which may be called "P2P networks".
'P2P 
           overlays", or "P2P federations" will provide namespaces within 
           which P2P-SIP resources are identified. These namespaces are 
           bounded by the identifier(s) of the peer association group, which

           generally map to domain-level identifiers in the DNS. 
Proposed Text: 
        (Nothing proposed yet) 
Proposed by Aki Niemi 
Related issues: #4 
Discussion: 
[Aki Niemi] 
        I find this a little hard to understand. I guess the meaning is to  
still 
        use a username at domain construct for user ids, and that each domain's

        name is rooted in the DNS? If so, why not just say that? 
Resolution: OPEN 

Issue 4: Namespace again 
Existing Text: 
        3. Some elements of each peer association group MAY be rooted in the

           DNS such that they can be used for bootstrapping operations. 
           However, a peer association group that is operating entirely in
an 
           isolated (or disconnected, or autonomous) mode will rely on 
           alternate means of bootstrapping the peer association group based

           on the "zeroconf" work. 
Proposed Text: 
        (Nothing proposed yet) 
Proposed by: Aki Niemi 
Related issues: #3 
Discussion: 
[Aki Niemi] 
        This isn't either or; perhaps it could also be mentioned that peers
can 
        very well sometimes be in disconnected mode, while other times in 
        connected mode. In such cases, the names should have global scope in

        both modes. 
        Maybe say that names should always have global scope? 

[Philip Matthews] 
        I would personally be reluctant to say in the charter that names  
must always have global 
        scope until I better understood the implications of that statement.

Currently, 
        I suspect that having user and resource names which are unique only

within 
        a specific P2P-SIP network are much more realistic. 

[Aki Niemi] 
        My point is that nodes can move around and be part of both  
disconnected and connected overlays. 
        It probably makes sense for that node to use the same name in each  
scenario, and that name to 
        not collide with other names. 
Resolution: OPEN 

Issue 5: Should Distributed Media Relays be part of the first set of  
deliverables? 
Existing Text: 
[In the section with the heading "The following topics are initially  
out of the Working Group's scope, 
but may be considered in possible future charters:"] 
        1. Using P2P mechanisms to manage groups of distributed media
relays. 
Proposed Text: 
        (Nothing proposed yet) 
Discussion: 
[Aki Niemi] 
        Hmm.. I understand this in terms of the charter being scoped to SIP

only 
        (initially), but this seems like cutting out a major part of where 
        distributing or sharing resources actually is a big benefit. 

        After all, running a SIP proxy is quite cheap; disk and cpu are
cheap 
        and SIP doesn't consume that much bandwidth. Running a TURN server
then 
        again is another thing entirely. I can't see a system that has 
        distributed rendezvous having to resort to centralized media relays.

        Shouldn't this rather be included in the first iteration already? 

[Philip Matthews] 
        I believe that we really need to have a small set of deliverables  
for the initial charter, 
        otherwise the charter won't get past the IESG. In my opinion, only  
really essential stuff 
        should be part of the first set of deliverables. So, for example, I

am personally very interested 
        in item 3 below (voicemail), but I am not objecting to leaving it  
for after a re-charter 
        because I don't consider it "essential". 
        In my opinion, item 1 (distributed media relays) are also not  
essential and 
        should wait until after a re-charter. 
        Does this make sense? Do you agree? 

[Aki Niemi] 
        Voicemail is hardly an essential feature. But media relays are  
needed to get around the most difficult 
        middleboxes. What fraction of nodes are we expecting to live behind

such boxes, and by not counting those 
        in does it represent a complete enough solution? 

        Because I just can't see a P2PSIP that requires centralized media  
relays to work properly getting 
        off the ground (any better than traditional SIP). 
Resolution: OPEN 

Issue 6: NAT Traversal milestone 
Existing Text: 
        (None) 
Proposed Text: 
[In the section with the heading "Specifically, the working group  
will:"] 
        5.  Investigate how NAT traversal techniques as described by MMUSIC

are to be implemented by P2PSIP. 
            Define requirements for enhancements, protocols, or partial  
interim solutions for submission to 
            all affected IETF working groups. 
[In the Milestones section] 
        Aug 2006    Submit Preliminary Functional Requirements For Meeting  
Proposed Use Cases to affected 
                    IETF working groups for their consideration. 
Proposed by: Michael Slavitch 
Discussion: 
[Michael Slavitch] (brief excerpts -- see e-mails for complete text) 
        ... The ability to do NAT traversal is a core requirement for P2PSIP

entities. Its absence jeopardizes 
        the ability of the WG to meet one of its key pressing goals. Nothing

else matters if peers can't 
        communicate through NAT firewalls. The success of P2PSIP largely  
depends on an item that is largely 
        not within its own mandate for which there is no current public  
standards based solution, no matter 
        how partial or interim. ... 
        ...The absence of a a general solution for a problem should not  
prevent partial solutions from being 
        developed and defined in the meantime,  especially if the partial  
solution does not preclude the 
        inclusion of a general solution  if and when such a solution becomes

available. ... 
        ... I believe that this issue is so important that an investigation

into how NAT traversal techniques 
        are to be implemented by P2PSIP entities should become part of the  
basic scope of the WG charter and 
        one of the initial activities of the group.  Naturally in keeping  
with the principles of the IETF 
        this investigation will be based on existing MMUSIC work. ... 
Resolution: OPEN 

_______________________________________________ 
p2p-sip mailing list 
p2p-sip at cs.columbia.edu 
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
<https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip>