Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I found one issue in various parts of the document (described below), but I'm not sure it's relevant to security. If it is, then I think this document is Almost Ready. If not, then I think this document is Ready With Nits. There are multiple places in the document where it's possible to encode semantically equivalent information in multiple ways, despite the word "canonical" being in the title of the document. Is there anything that relies on these addresses being canonical for security purposes? Multiple places in the document (sections 4.1, 4.5, and 4.8) specify mask lengths, but do not specify that the masked out bits MUST be set to zero. Section 4.4: The description of RTR RLOC Address gives two different ways to encode an address with zero RTRs. Section 4.10.5: If I understand the compatibility mode correctly, this explicitly creates a second way to encode a semantically identical address. Section 5.4: There are many different ways to encode equivalent JSON data here. Section 6 (Security Considerations): There is no discussion of these addresses being canonical, and what other systems might or might not rely on these addresses being canonical. I also have some questions/nits: Section 3: Shouldn't the LCAF sort-key of {afi, LCAF-Type} also include the RLOC-address or LCAF payload? Section 4.3: Altitude is described as a signed integer, but this document doesn't specify the encoding. I assume it's two's complement, but that should probably be made explicit. Section 4.7: The Key Count description talks about "Key sections," but doesn't say which fields are part of the key section (and can thus be repeated). I have a guess which fields are part of the key section, but it's not entirely clear. Section 4.7: The Key Algorithm description doesn't point to a registry of valid values or otherwise say how to interpret values in that field. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ Attachment: signature.asc Description: OpenPGP digital signature