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

From: "Benoit Claise" <[email-masked]>
Date: Thu, 06 Aug 2015 03:38:22 -0700

Benoit Claise 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:
----------------------------------------------------------------------

For the sake of recording the ongoing discussion between the Nevil
Brownlee, as OPS-DIR reviewer, and the author (YOUNG)

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.

YOUNG>> Yes. Actually they have already become RFCs. Need to update the
reference. 
WSON-Encode is now RFC 7581 and GEN-OSPF RFC 7580. 

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.

YOUNG>> Good point. Will work with IANA on this. 

Also in section 2, you have sub-sections for the last four sub-TLV
values, but not the first (Resource Block Information).  Why not?

YOUNG>> Actually you are correct. Will add a sub-section for the Resource
Block Information with the following text:

   As defined in [RFC7446], the Resource Block Information
   <ResourceBlockInfo> field is used to represent resource signal
   constraints and processing capabilities of a node.

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?

YOUNG>> They are optional TLVs. How about:

OLD
	It is comprised of a set of sub-TLVs.

NEW
	It is comprised of a set of optional sub-TLVs.

END

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.

YOUNG>> Sure. It will be like:

OLD

	3.1. Switching Capability Specific Information

New

	3.1. Switching Capability Specific Information (SCSI)
END

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?

YOUNG>> I am not IPv6 expert. You are probably right on this. How about
adding this:

NEW

	For IPv6, a node may use the IPv6 Fragment header to fragment the packet
at the source and have it 
      reassembled at the destination(s).

END

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])

YOUNG>> Will correct in the next revision. Thanks.