Hello Stephen Thanks for the comments,
See inline for my proposals. > Le 8 juil. 2015 à 17:37, Stephen Farrell <[email protected]> a écrit : > > Stephen Farrell has entered the following ballot position for > draft-ietf-homenet-prefix-assignment-07: 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-prefix-assignment/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - section 3: I expected some security text here, not to say that > this all needs to be encrypted but rather to say that because > this is flooding, you can't really encrypt it and that hence > this scheme is only suited for smaller deployments and/or those > with lower layer security already in place. (And hence also > probably small.) > > - section 3: Similarly, you could also add some privacy text to > the effect that this scheme only applies where the privacy > characteristics of the various prefixes involved are all > roughtly similar, that is, where there's no real privacy > difference in which prefixes end up with which nodes. (Mind you, > I need to ponder that a bit myself to see if it's really the > case;-) What about this addition to the applicability statement section: NEW: Finally, leaving the Flooding Mechanism or Node ID assignment process unsecured makes the network vulnerable to deny of service attacks, as detailed in Section 8. Additionally, as this algorithm requires all Nodes to know which Node has made which assignment, it may be unsuitable depending on privacy requirements among participating Nodes. > > - sections 4 & 5: I found this impossible to understand in a > (quick) linear reading. I'd find actual code easier tbh. It's > interesting that Barry found this clear though (I did not, > clearly:-) so this isn't a discuss. But why didn't you first > provide an overview of the algorithm? It is, indeed, not straightforward, but I personally believe the text has the merit of being unambiguous. I would recommend multiple pass anyway. And I believe it gets clearer when you try to implement it. > > - Where is the evidence that the algorithm converges? I'd have > thought there would be a reference to an academic publication > that also described the algorithm and a proof for convergence. > I wrote a proof, but could not find the time to publish it in a scientific paper. I am not sure describing the algorithm in a paper would be interesting, but the proof as well as best and worst case behaviors might be nice to have. Thanks, - Pierre
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
