Murray Kucherawy has entered the following ballot position for draft-ietf-ipsecme-multi-sa-performance-08: 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/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-ipsecme-multi-sa-performance/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I realize there's terminology imported from elsewhere, but it would be helpful (and cheap) to expand things like "SA" on first use anyway. In Section 6, "it is there for" should be "it is therefore". In Section 3: The SA_RESOURCE_INFO notify payload MAY be empty or MAY contain some identifying data. This identifying data SHOULD be a unique identifier within all the Child SAs with the same TS payloads and the peer MUST only use it for debugging purposes. So it MAY be empty; if it's not empty, it SHOULD be unique, and it MUST only be used for debugging. Two things are odd about this: (a) What if it's not unique? What's the interoperability benefit to uniqueness? (i.e., why is this "SHOULD"?) (b) The MUST doesn't seem to have anything to do with interoperability. Lastly, a minor point but I found this peculiar. Section 5 contains two instances of: * SPI Size (1 octet) - MUST be 0. MUST be ignored if not 0. Is this reserved for future use? Otherwise, I don't know why this isn't just "MUST be 0" or "ignored; assume 0 always". _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
