Subject: [secdir] SecDir review of draft-ietf-ccamp-assoc-info-03

From: Yoav Nir <[email-masked]>
Date: Sun, 13 May 2012 09:46:39 +0300

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 13 May 2012 22:08:34 +0100

Thanks Yoav,

RFC Editor note entered for your observation.

Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Yoav
> Nir
> Sent: 13 May 2012 07:47
> To: [email-masked] list; [email-masked];
[email-masked]
> 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=