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. *Summary: Ready with nits* I think the proposed security mechanism is a reasonable solution, but I think that the document could benefit from few clarifications in few places: * Page 6, Section 5 Solution, first paragraph, second sentence: "so a simple solution would be to retain the keys for AS64510 on PE1,..." I guess by "keys for AS64510" you mean the private key associated with PE1; is that correct? Are there any other keys? if so, could you please clarify what other keys? * Page 7, Section 5 Solution, third paragraph, third sentence: "Each routing update that is received from or destined to an eBGP neighbor that is still using the old ASN (64510) will be signed twice, once with the ASN to be hidden and once with the ASN that will remain visible. " I am assuming that the routing update will be signed using the private key associated with the specific ASN. If so, could you please clarify that? * Page 7/8, Section 5 Solution, third paragraph, fifth sentence: "This will result in a properly secured AS Path in the affected route updates, because the PE router will be provisioned with valid keys for both AS64500 and AS64510." I am assuming that by "keys" you mean the two private keys: one associated with AS64500 and another with AS64510; is that correct? * page 10, notations: "The origin BGPSEC signature attribute takes the form: sig(, Origin ASN, pCount, NLRI Prefix) key" Is there any significance to the use of angle brackets around the first attribute ()? Also, I guess the "key" provided at the end of the attributes is the private key of the router signing the update message; you might want to explicitly state that. * page 11: "CE-2 to PE-2: sig(<64500>, O=64499, pCount=1, N)K_64499-CE2 [sig1]" The value of the last attribute is 'N'; I guess this is a short for Null, because there is no previous signatures to point to? * page 9, second paragraph, second sentence: "This requires any router using this solution to be provisioned with valid keys for both the migrated and subsumed ASN so that it can generate valid signatures for each of the two ASNs it is adding to the path. " I think that the first part of the above sentence might be clearer by stating that "... any router *that is being migrated* using this solution...", because all other routers are not affected by this change;right? Nits ---- Page 3, section 2, second paragraph, first sentence: Remove one of the reference to section 5.4. Page 4, section 3.1, first paragraph, first sentence: "Route Origin Validation as defined by RFC 6480 [RFC6480] does not modification..." Did you mean to say "...does not *allow* modification..."? Regards, Rifaat