Hi all: I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft's Expiry Date is November 2014. It's generally clear in what it says, and it's certainly useful. However, I feel that there are a few aspects that could be made a little clearer for implementors. Abstract: "This document provides Generalized Multiprotocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing enhancements to support signal compatibility constraints associated with Wavelength- Switched Optical network (WSON) elements. These routing enhancements are applicable in common optical or hybrid electro-optical networks where not all of the optical signals in the network are compatible with all network elements participating in the network. This compatibility constraint model is applicable to common optical or hybrid electro optical systems such as Optical-Electronic-Optical (OEO) switches, regenerators, and wavelength converters since such systems can be limited to processing only certain types of WSON signals." The Introduction mentions WSON-Encode and GEN-OSPF; these are Normative references, presumably to Drafts that will eventually be Standards Track RFCs? This comment also applies to GEN-Encode in section 3. Section 2 defines values for sub-TLVs of the Optical Node Property TLV. Their values are all shown as TBA; using something like TBA1, TBA2, .. TBA5 would make it clearer to IANA that they're different values. Also in section 2, you have sub-sections for the last four sub-TLV values, but not the first (Resource Block Information). Why not? Again in section 2, you say that the sub-TLVs may appear in any order. You don't say whether all of them are required - is that what's intended, or may any subset be specified? In section 3.1 you use the acronym SCSI to mean 'Switching Capability Specific Information,' which I found confusing. It would help to add (SCSI) as part of that sub-section's title. In section 4 you say "In a rare case where the TLV exceed the IP MTU, IP fragmentation/reassembly can be used, which is an acceptable method." That's probably true for IPv4, but what about IPv6, where fragmentation must be done by the source node? There are also a few tiny typos: s2.2 s/may have a limited/may have limited/ s2.4 s/Resources blocks/Resource blocks/ (?) s4 s/that exceeds the/that exceed the/ s6.1 s/New IANA registry/A new IANA registry/ s6.1.1 s/new IANA registry/a new IANA registry/ s6.2 s/Refenrence/Reference/ (also, its value should be [This.ID]) Cheers, Nevil Ex-co-chair, EMAN and IPFIX WGs -- --------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland 1142, New Zealand