Stephen Farrell has entered the following ballot position for draft-ietf-homenet-dncp-09: No Objection
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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 8.3 generally: I think this could be the basis for something quite good but that'll only become clear really (to me) when I go over it in a real protocol and not in the abstract. I'd also speculate that you might end up changing this if it gets more security review, but again that's hard to get in the abstract. Basically: be prepared for changes as this is made concrete and if that would be a problem please yell now. If you do yell, I'm fine with making this a DISCUSS so we're sure to resolve it. (I nearly did make this a DISCUSS, as I'm not sure this is all fully worked out, but I'm ok that we can fix that later. And you have enough DISCUSS ballots;-) - The write up notes various drafts were input to what became this one. I assume that none of those had associated IPR that hasn't trickled through to being noted as applying to this one? If not, as I expect, that's fine, no response is needed, I'm just noting this since I didn't see any "replaced by" entries in the history and it's those that cause IPR to be transitively visible. - section 2 - it's not clear to me why all node identifiers need to be the same length - some protocols using DNCP could I guess have variable length identifiers. IPv4 and IPv6 and Ethernet for example all have different lengths. - 4.2: seems to contradict itself. 1st para says that MC is not used for anything sensitive, but 2nd-last para of section says that network state TLVs can be sent "now and then." (Reason to ask is that (D)TLS won't work if sensitive data is sent via MC.) - 4.4, 2nd para: what is a "valid" address? - 8.1: do you mean one PSK per network or per pair of nodes? Better to say. I assume it's the former. - 8.3: This is an example of (a fairly complex) use of opportunistic security (RFC7435). Be good to note that. - 8.3: Calling this "certificate based" is I think a misnomer. I suspect all the same things could be done with raw public keys (RFC 7250). - 8.3: please do note that a concrete protocol might need changes to this distributed algorithm and that this section is guidance and not to be considered entirely fixed (when coding). _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
