Stephen Farrell has entered the following ballot position for draft-ietf-ospf-prefix-link-attr-12: 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-ospf-prefix-link-attr/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - The opaque ID field descriptions in sections 2 and 3 read a little oddly to me. What happens if someone decides to use up ID=0? Does that mean they can't overwrite that value until much later maybe? And what if a whole bunch of routers choose the same value (because it's configured or hard-coded)? I think you need a bit more text on that. And with only 24 bits the probability of a collision if you just pick randomly isn't that low, so I'm not sure if random selection is a good plan here either. (How often will a new one of these be seen?) - Do these opaque values get forwarded widely? If so, then I guess they may provide a covert channel. I didn't see that mentioned in the security considerations of RFC5250. Is it mentioned elsewhere? If not, is it worth a mention here? (Probably not, but thought I'd ask.) - Thanks for section 5. Nice to see. (Makes me wonder what those implementations do with the opaque ID though:-) _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
