Re: [secdir] secdir review of draft-ietf-pce-wson-routing-wavelength-14

["Dan Harkins" <[e-mail]>]

  Hi Young,

On Tue, October 28, 2014 8:50 am, Leeyoung wrote:
> Hi Dan,
>
> Thanks a lot for your review and providing comments.
>
> Would the following work for you in Security Section to add:
>
> "Solutions that address the requirements in this document need to verify
> that existing PCEP security mechanisms adequately protect the additional
> network capabilities and must include new mechanisms as necessary."

  Yes, that's fine. Adrian had a good point (it's a requirements document)
and this puts the requirements where they should be-- on the solution
that addresses the requirements.

  thanks,

  Dan.

> Best regards,
> Young
>
> -----Original Message-----
> From: Dan Harkins [mailto:[e-mail]]
> Sent: Monday, October 27, 2014 12:04 PM
> To: [e-mail]; [e-mail];
> [e-mail]
> Subject: secdir review of draft-ietf-pce-wson-routing-wavelength-14
>
>
>   Hello,
>
>   I have reviewed draft-ietf-pce-wson-routing-wavelength 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.
>
>   This is a requirements document for additions to the PCEP protocol to
> support path computation in a wavelength-switched optical network. It
> describes what needs to be added to requests/responses to support
> routing and wavelength assignment to a path computation element (that
> supports both functions) for a path computation client.
>
>   The security considerations are basically a punt. There's information
> that an operator may not want to disclose and "[c]onsideration should be
> given to securing this information." That seems a little thin. At the
> very least some explanation of how this should be done. Do only the TLVs
> that represent these required additions require confidentiality?
> Is KARP a potential solution to this problem? If so it might be nice to
> explain that; if not, then why and what else would be required?
>
>   It is a well-organized and well-written document. I would say it is
> "ready with nits", my nits being the thinness of the Security
> Consideration section.
>
>   regards,
>
>   Dan.
>
>
>