Thanks Yoav, RFC Editor note entered for your observation. Adrian > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Yoav > Nir > Sent: 13 May 2012 07:47 > To: ietf@xxxxxxxx list; secdir@xxxxxxxx; draft-ietf-ccamp-assoc-info@xxxxxxxxxxxxxx > Subject: SecDir review of draft-ietf-ccamp-assoc-info-03 > > 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. > > The document does not define any new procedures or mechanisms, and > mentions this fact three times throughout the document. It formalizes an email > by Adrian Farrel clarifying the procedures for processing an ASSOCIATION object > on a path message. > > The security considerations section repeats that the document does not define > new procedures, and concludes that no security considerations are added. This is > not a valid deduction, as clarification often involves prohibiting non-functional or > insecure interpretation of the original document text. However, in this case the > clarification is not about such insecure configurations, so the document is fine. > > One textual comment, though: section 2.2 near the bottom of page #5 lists 3 > possible values for association ID. The second option is "The LSP ID of the LSP > protecting an LSP". This is not clear. I suggest rewording as "The LSP ID of the > protecting LSP" without an indefinite "an LSP". > > Yoav=