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
[email protected] 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
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
