Hi, I read the draft and came up with the following concerns. I did not review all other comments on the list but it looks like some of them were mentioned by others
According to section 1 Reload is based on the concepts introduced in ietf-p2psip-concepts. The concept draft is currently expired and I noticed some contradictions between the two drafts. I think that the reload draft should progress with the concept draft. According to the concepts draft "The P2PSIP WG will not standardize how the peer-ID and the credentials are obtained, but merely standardize at least one acceptable format for each. To ensure interoperability, it is expected that at least one of these formats will be specified as "mandatory-to-implement"." According to RELOAD the node-id is mandated as a 128 bit value. According to the concept draft it can be as mandatory to implement format but others should be allowed. I also think that section 5.4.1 allows for different node-id length (see "o The length of the Resource-IDs and Node-IDs. For DHTs, the hash algorithm to compute the hash of an identifier." In section 5.2 on symmetric recursive routing says that "An overlay may be configured to use alternative routing algorithms, and alternative routing algorithms may be selected on a per-message basis." Yet I noted that in some of the text the assumption is that symmetric recursive is the only routing algorithm. For example in section 5.2.2 it says "When a peer sends a response to a request, it MUST construct the destination list by reversing the order of the entries on the via list.". This is true only for recursive routing. Another example is that the text allows an intermediary peer to decide to keep a per transaction state (see section 5.1.2) which will work for recursive routing but may break other routing algorithms. If the text in section 5.2 is the objective I suggest that in 5.2.2 it will say that in the case of recursive routing this procedure must be used. I also suggest that since 5.2.2 allows alternative algorithms on per-message basis than the requesting peer should be allowed to prevent state keeping by intermediary peers in order to support other routing mechanisms. The intermediary peers do not know what routing is used and may choose wrong behavior. I noticed that the overlay link layer MUST use TLS/DTLS. I am not sure where the requirement to mandate TLS and DTLS is coming from, more specifically the requirement to encrypt the signaling. One of the objectives of RELOAD is to minimize the burden of becoming a peer and TLS with encryption does not help that. I think that TLS or DTLS can be specified as mandatory to implement security but optional to use based on the security level required by the implementation which may chose different security that may be available in other layers of the network. If there are specific security requirements based on a specific usage than the requirements to use TLS/DTLS should be in the usage. I looked at draft-irtf-p2prg-rtc-security and did not see that TLS/DTLS must be used. I see cases like when using routing mechanisms which are not recursive that some of the paths will not need TLS. Section 3.3 mentions that client promoting to peers may be used for routing, in the case of passive promotion the establishment of trust relation may bring different requirements. So I think that mandating using one solution does not fit all. Section 3.6.1 details the initial configuration establishment, from the text it this paragraph and in section 3.6 above it looks like this is the only allowed procedure, was that the meaning or is that an example. Looking at section 10 I am not sure what a new configuration file means, is this new values to the elements, in this case how can the configuration document defined in section 10 be extended with new elements that may be needed for new features. Section 8 discusses TURN server usage. I was wondering if a peer can be a TURN server it can also be a "supernode" or a relay peer, so why not publish the general capability that this node is publicly reachable. Roni Even _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
