Authors,
	I have some comments on this document. A number are strictly
editorial. Note that I'm the document shepherd, see RFC 4858 for more
information.

- Please address my general comments on the WSON document set

- I'm a bit surprised that this document does *not* reference the
rwa-info draft.  Given that it provides the context for this document,
it should be there, and probably as a normative reference.

- Your references to [Switch] seem almost normative in nature. I suspect
that this is not your intent as it is listed as an informative
reference.  Please revisit your references and ensure that the draft
does not depend on any informative references.  (Either change the text,
or move the reference to normative.) Perhaps these are places where a
reference to rwa-info are more appropriate.

- An editorial comment on section ordering:  Section 2 is ordered as
follows:

   2. Encoding.......................................................6
      2.1. Link Set Field............................................6
      2.2. Label Set Field...........................................8
      2.3. Available Labels Sub-TLV.................................11
      2.4. Shared Backup Labels Sub-TLV.............................11
      2.5. Connectivity Matrix Sub-TLV..............................12
      2.6. Port Label Restriction sub-TLV...........................13

  Is there a logical order to these sections? They don't seem to be
  aligned with the rwa-info draft which has:

   4. Node Information (General).....................................8
      4.1. Connectivity Matrix.......................................9
      4.2. Shared Risk Node Group...................................10

   6. Link Information (General)....................................17
      6.6. Port Label (Wavelength) Restrictions.....................18

   7. Dynamic Components of the Information Model...................21
      7.1. Dynamic Link Information (General).......................22

   Perhaps it makes sense from a readability standpoint to realign to
   match rwa-info?

- Section 2 says:
   A type-length-value (TLV) encoding of the general connectivity and
   label restrictions and availability extensions is given in this
   section. This encoding is designed to be suitable for use in the
   GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307] and in
   the PCE protocol PCEP [PCEP]. Note that the information distributed
   in [RFC4203] and [RFC5307] is arranged via the nesting of sub-TLVs
   within TLVs and this document makes use of such constructs...

 Yet there are no types or (sub)TLVs actually defined in this
 document.  As such, I think this document should not use the term
 "sub-TLV" for the information elements it defines. In most cases
 this just means substituting "the <XYZ_information_element> sub-TLV"
 with just "<XYZ_information_element>".

 Section 2 can be revised to read something along the lines of:
   This section provides encodings for the information elements defined
   in [RWA-INFO] that have general applicability.  The encodings are
   designed to be suitable for use in the
   GMPLS routing protocols OSPF [RFC4203] and IS-IS [RFC5307] and in
   the PCE protocol PCEP [PCEP]. Note that the information distributed
   in [RFC4203] and [RFC5307] is arranged via the nesting of sub-TLVs
   within TLVs and this document defines elements to be used within
   such constructs...

- section 2.2.
   Labels are variable in lengh and need not be 4 bytes long.  This
   needs to be represented and accounted for in the encodings defined
   in this section.

- Section 2.2.1 and 2.2.2 says "Num Labels (not used)" and
   "Num Labels is not used in this particular format since the Length
   parameter is sufficient to determine the number of labels in the
   list."

  Is there a reason to not set the Num Labels Field in these cases?
  Recall that labels are themselves variable length fields.

- section A.2
  s/With the Grid/Using the label format defined in [RFC 6205], with the
Grid...
  s/Num Wavelengths/Num Labels (multiple places)

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  0    | Num Wavelengths = 40  |    Length = 20 bytes          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  shouldn't Num Labels either be 0 (if unused) or = 7 (assuming num
  labels used in this case)?

That's it on this one,
Lou

On 10/22/2013 4:34 PM, Lou Berger wrote:
> 
> All,
> 	Given the recent draft submission deadline and only one comment being
> received to date, we'd like to extend the WG more time for review.
> 
> These drafts represent significant work by the authors and WG, so please
> review and let the WG know what you think (positive or negative)!
> 
> Please have all comments in by October 29.
> 
> Thank you,
> Lou (and Deborah)
> 
> On 10/1/2013 12:34 PM, Lou Berger wrote:
>> All,
>>
>> This mail begins working group last call on the WSON documents.  As
>> there are 6 documents in this set, the last call will be three weeks.
>> The documents included in the last call are:
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18
>> (Informational, IPR Disclosed)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-11
>> (Standards Track, IPR Disclosed)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21
>> (Standards Track)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05
>> (Standards Track, IPR Disclosed)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility-ospf-12
>> (Standards Track, IPR Disclosed)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 (Standards
>> Track) Also has one open issue that will need to be resolved as part of
>> LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52.
>>
>> This working group last call ends on October 22.  Comments should be
>> sent to the CCAMP mailing list.  Please remember to include the
>> technical basis for any comments.
>>
>> Positive comments, e.g., "I've reviewed this document and believe it is
>> ready for publication", are welcome!
>>
>> Please note that we're still missing some IPR statements.  Any
>> forthcoming publication request will be delayed by late IPR
>> statements/disclosures.
>>
>>
>> Thank you,
>> Lou (and Deborah)
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>