Subject: [CCAMP] Ben Campbell's No Objection on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Mon, 03 Aug 2015 15:43:45 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-ccamp-wson-signal-compatibility-ospf-15: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signal-compatibility-ospf/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 5 (security considerations) says: "This document does not
introduce any further security issues other
   than those discussed in [RFC3630], [RFC4203]."

While I don’t doubt the statement is true, it would be helpful to show
the thought behind it. In this case, the draft adds new data elements to
the OSPF TE LSA. Please consider adding a very short discussion on how
the security implications of those elements is similar to or different
from the previously existing data elements.

Nits:

Please expand TE and LSA on first mention.

idnits thinks the reference to [G.694.1] is not cited in the body. Is the
reference needed?

---

From: Leeyoung <[email-masked]>
Date: Tue, 4 Aug 2015 18:43:16 +0000

Hi Ben,

Thanks for providing your good comments and idnits check. 

Please see inline for my response. 

Best regards,
Young

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Monday, August 03, 2015 5:44 PM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Ben Campbell's No Objection on draft-ietf-ccamp-wson-signal-compatibility-ospf-15: (with COMMENT)

YOUNG>> 

   As with [RFC4203], it specifies the
   contents of Opaque LSAs in OSPFv2.  As Opaque LSAs are not used for
   Shortest Path First (SPF) computation or normal routing, the
   extensions specified here have no direct effect on IP routing.
   Tampering with GMPLS TE LSAs may have an effect on the underlying
   Transport.  [RFC3630] notes that the
   security mechanisms described in [RFC2328] apply to Opaque LSAs
   carried in OSPFv2. 

   If you like, I can add these text in Section 5. Please let me know. 

Nits:

YOUNG>> Yes, TE (Traffic Engineering) and LSA (Link State Advertisement) will be expanded on first mention.

YOUNG>> The reference will be removed.