Hi,

Nice to see progress. Here are things I want to point out and suggest:

1) Section 5.5.1.1, the definition IceCandidate.rel_addr_port does not 
conform with the current mmusic-ice-19 section 15.1, which has the 
following text:

"<rel-addr> and <rel-port>:  convey transport addresses related to the
      candidate, useful for diagnostics and other purposes. <rel-addr>
      and <rel-port> MUST be present for server reflexive, peer
      reflexive and relayed candidates."

Therefore, the definition of IceCandidate should be:

         struct {
           ...
           select (type){
             case host:
               ;          /* Nothing */
             case srflx:
             case prflx:
             case relay:
               IpAddressPort     rel_addr_port;
           }
           ...
         } IceCandidate;

   rel_addr_port
      corresponds to the related address and port of ICE, which MUST
      present for type "srflx", "prflx" and "relay".

2) In Section 13.6, IANA message codes for AppAttachReq and AppAttachReq 
are not added. I suggest fill these two values (app_attach_req=5, 
app_attach_ans=6) in the holes left by the abandoned tunnel_req and 
tunnel_ans.

3) In Section 6.4.1.2, if the store request has multiple kinds, the 
current answer structure will send replica node IDs multiple times. For 
efficiency, I suggest moving the replica node IDs to the outer layer as:

         struct {
           KindId                  kind;
           uint64                  generation_counter;
         } StoreKindResponse;

         struct {
           StoreKindResponse       kind_responses<0..2^16-1>;
           NodeId                  replicas<0..2^16-1>;
         } StoreAns;

4) It seems that mmusic-ice-tcp-07 has been abandoned. The key members 
of this draft should address the lack of ice-tcp standard in the next 
draft, meeting or on the mailing list. Assuming this group is no longer 
interested in mmusic-ice-tcp-07, something like this should be added  to 
section  5.5.1.5 to make things clear:

   For peers that support TCP/TLS, the ICE TCP host candidates are the addresses
   and port number of each network interface it listens to.  They may also be the
   address and port number accessible to other peers via methods described in 
   draft-lowekamp-mmusic-ice-tcp-framework.

   When forming ICE check candidate pairs, a local TCP candidate is paired with
   a remote TCP candidate of matching address type (IPv4 or IPv6).  In addition,
   for peers in "active" or "act-pass" role, a new port number MUST be allocate
   for the local candidate in the pair.  This is often done automatically by the 
   operating system when the program calls the connect() function of the socket
   library to creates a TCP connection to the remote candidate address.

That is it so far. Thanks

--Michael

Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF.
>
>
> 	Title           : REsource LOcation And Discovery (RELOAD) Base Protocol
> 	Author(s)       : C. Jennings, et al.
> 	Filename        : draft-ietf-p2psip-base-03.txt
> 	Pages           : 146
> 	Date            : 2009-07-13
>
> In this document the term BCP 78 and BCP 79 refer to RFC 3978 and RFC
> 3979 respectively.  They refer only to those RFCs and not any
> documents that update or supersede them.
>
> This document defines REsource LOcation And Discovery (RELOAD), a
> peer-to-peer (P2P) signaling protocol for use on the Internet.  A P2P
> signaling protocol provides its clients with an abstract storage and
> messaging service between a set of cooperating peers that form the
> overlay network.  RELOAD is designed to support a P2P Session
> Initiation Protocol (P2PSIP) network, but can be utilized by other
> applications with similar requirements by defining new usages that
> specify the kinds of data that must be stored for a particular
> application.  RELOAD defines a security model based on a certificate
> enrollment service that provides unique identities.  NAT traversal is
> a fundamental service of the protocol.  RELOAD also allows access
> from "client" nodes that do not need to route traffic or store data
> for others.
>
> Legal
>
> This documents and the information contained therein are provided on
> an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
> REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
> IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
> WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
> WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
> ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
> FOR A PARTICULAR PURPOSE.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip
>