Spencer Dawkins has entered the following ballot position for draft-ietf-homenet-dncp-09: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This should be an easy Discuss to ... discuss ... I'm looking at this text: If keep-alives specified in Section 6.1 are NOT sent by the peer (either the DNCP profile does not specify the use of keep-alives or the particular peer chooses not to send keep-alives), some other existing local transport-specific means (such as Ethernet carrier- detection or TCP keep-alive) MUST be used to ensure its presence. and wondering if using TCP keep-alive for liveness detection is realistic in the use cases this specification is expecting to address. Unless I missed something, the default TCP keep-alive interval is still two hours (that's been true since RFC 1122, and also true in the relatively recent version of Linux I'm using). If that's OK, I'll clear. If you're assuming a keep-alive interval that's shorter, lots of implementations allow you to tune this, but it seems like the specification should say something about that. Given that the other example of "transport-specific means" is Ethernet carrier-detection, which would be orders of magnitude faster, I thought I should ask. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
