Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-wson-encode

[Leeyoung <[e-mail]>]

Hi Lou,

Please see inline for my responses to your comments. Let me know if there are still further issues. 

Thanks.
Young

-----Original Message-----
From: Lou Berger [mailto:[e-mail]] 
Sent: Tuesday, October 29, 2013 1:27 PM
To: CCAMP; [e-mail]
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-wson-encode

Authors,
	I have some comments on this document. Many 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

YOUNG>> Done. See Terminology Section changed as follows: 

Refer to [RFC6163] for CWDM, DWDM, RWA, WDM. 
Refer to Section 5 of [Gen-Encode] for the terminology of Resources, Resources Blocks, and Resource Pool.

- section 1
   This document makes
   use of the Label Set Field encoding of [Gen-Encode] and refers to it
   as a Wavelength Set Field.
  Why?  Why not just refer to it as Label Set?  Perhaps you mean that a
  Wavelength Set Field is a Label Set Field that MUST carry a label as
  defined in RFC6205?  If so, this needs to be made explicit. (probably
  in a section other than the introduction.)

YOUNG>> Moved the text from introduction to Section 3.1 and added the : 
"The For the Input and Output Link Set Fields, the Link Set Field encoding defined in [Gen-Encode] is to be used. A Label Set Field MUST carry a label as defined in [RFC6205]."


- section2/3 section alignment with rwa-info
  It's probably a good idea to align naming and ordering wherever
  possible.

YOUNG>> Aligned where possible. 

- section 2
  1st two paragraphs.  Why does this section try to introduce concepts
  that are defined in 6163 and in [WSON-INFO]?  Is something missing
  from those documents?  If so, at least wson info should be fixed.  If
  not, these paragraphs should be replaced with simple
  terminology/concept references.

YOUNG>> Added "Refer to Section 5 of [Gen-Encode] for the terminology of Resources, Resources Blocks, and Resource Pool." (Terminology Section).
YOUNG>> Added the following paragraph in the beginning of Section 2. 
"This section provides encodings for the information elements defined in [RWA-INFO] that have applicability to WSON.  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) [RFC5440]. 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, same comment WRT TLVs as made on general-constraint-
  encode: The text reads:
   This document defines the following sub-TLVs pertaining to resources
   within an optical node:

   All references to sub-TLVs should dropped, again see related comment
   in my may on general-constraint-encode.  This doesn't hold for
   sub-sub-TLVs, and I'll get to this below.

YOUNG>> sub-TLVs dropped. 

- Section 3.1
    0 1 2 3 4 5 6 7 8
    | Connectivity  |
  Why is connectivity a byte here, but only a bit in section 2.1?
  Either it should be a bit here to, or section 2.1 should be a byte.
  Note, that this can be fixed in a compatible way by defining it here
  as:
    0 1 2 3 4 5 6 7 8
    |   Reserved  |C|

YOUNG>> Your suggested encoding accepted. 

- Section 4.
  The definitions of sub-sub-TLVs are a bit underspecified.  Some
  specific questions to address:

  - Are there any sub-sub-TLV ordering requirements?

YOUNG>> No.

  - How are multiple sub-sub-TLVs of the same type to be handled?

YOUNG>> I don't see why there are multiple sub-sub-TLVs of the same type. In case where there are multiple sub-sub-TLVs of the same type, there would be no error as these information are not order-sensitive. Is this what you have in mind? 

  - What is the sub-sub-TLV header (TL format)?

YOUNG>> Added TLV format

  - Are there any alignment requirements?

YOUNG>> Not sure what this is. 

  - What happens when a sub-sub-TLV is larger than 256 bytes?
    (There are already systems that advertise 192 wavelengths on a
    fiber and an application code takes 8 bytes, right? But
    of course this presents a problem when carried within an RSVP
    object too.)

  If you find you need more specifics, we can discuss / I can propose
  new text.  Feel free to discuss the details on or off list (your
  choice.)


YOUNG>> Please see the other email response to this comment. 

- Section 4.1
  Title and 1st sentence don't agree on the element's name.

YOUNG>> Aligned. 

- Section 3.4, 4.1
  - Bits I & E are defined here, but I & O are used in parallel ways in
    Section 3.2. For consistency it should be I & O everywhere (to
    match input and output).

YOUNG>> Corrected to I & O.

- Section 4.2.1
  s/[ITU-G.695.1]/[ITU-G.695]

YOUNG>> Done. 

- Section 4.2.2, 4.2.3
  Why do you use bit names that are different than the ITU-T
  definitions for p and s (rather than D and F)?

YOUNG>> Changed to D and F now. 

WRT Section 8:
-  [RFC3471] is an informative reference.
- [Gen-Encode] needs to be normative, this document reuses its definitions.
- I'm surprised  [WSON-Info] is informative (and not normative).  Do you think this is correct?

YOUNG>> All corrected. [WSON-Info] is normative. 

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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>