Hi, I read the draft and think the approach is good.
The first comment I have is related to the periodic and reactive stabilization. The reload base draft is section 10.2 discuss the topic and mention that the current approach in the reload base draft is for reactive and that more input is needed. Yet section 10.7.2 describes periodic stabilization. I think that we need to decide on the approach for the base reload and if it is periodic we need to see if the text from the self tuning draft should fold to the base draft. Other comments 1. In section 4.1 the update message includes the send-id. I am not sure why it is needed since the sender is attached to the receiving peer and I assume the receiver of the updates knows this information. This parameter is not part of the update message in the reload base draft. 2. In section 4.1 the update answer has an option to send the predecessor or successor lists. What is the benefit for it since the receiver is also part of the periodic stabilization and will need to send it anyhow, so this may be a duplicate of messages. I can see the use case for the message in the reactive stabilization case. 3. I am not sure how a peer knows which topology is used in the overlay, is this a different overlay algorithm type that need to be registered in the IANA section. 4. This draft defines different parameters for update and update answer but uses the same message code name and I assume the same code value. Is that the approach and the peer knows the parameters based on the overlay algorithm type or should we have another code name and code value. Regards Roni Even
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
