John Scudder has entered the following ballot position for draft-ietf-lisp-sec-26: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I generally found this a well-written and pleasant to read document. I do have some additional comments on it and tomorrow I'll update the comments section of my ballot to reflect them, but wanted to post the DISCUSS portion tonight. I would like to understand the motivation behind what seems to me to be a curious inconsistency. On the one hand, §6.7 and §6.7.1 mention that While processing the Map-Request, the Map-Server can overwrite the KDF ID field if it does not support the KDF ID recommended by the ITR. and similar for the HMAC ID. They then go on to detail all the other work the Map-Server does to create a well-formed Map-Reply (if replying directly) or Map-Request (if sending the message to an ETR to take action). This seemed fine, until I got to §6.9, which told me that after the Map-Server (and often, ETR) went to all that work to create those messages... If the KDF ID in the Map-Reply does not match the KDF ID requested in the Map-Request, the ITR MUST discard the Map- Reply and similar for the HMAC ID. Why did you tell the Map-Server to spend cycles and bandwidth doing the work to produce a fully-formed Map-Reply in this case where you know the ITR is just going to discard the result? Why doesn't the Map-Server simply send a bare-bones "I don't support your algorithm, here's the one I do like" message? _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
