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

[Lou Berger <[e-mail]>]

Young,

It looks like you missed my in line comments. They still need to be
addressed.

Thanks,
Lou


On 1/27/2014 8:04 PM, Leeyoung wrote:
> Hi Lou,
> 
> All idinits have been corrected. 
> 
> Here's the working document (v.24). Let me know if this is ready for publication.
> 
> Regards,
> Young
> 
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]] 
> Sent: Monday, January 20, 2014 1:54 PM
> To: Leeyoung; CCAMP; [e-mail]
> Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-wson-encode
> 
> Young, (all),
> 
> There are few minor items in this document.
> 
> idnits says:
> (see
> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ccamp-rwa-wson-encode-23.txt)
>   == Line 497 has weird spacing: '...(number  of  r...'
>   == Missing Reference: 'RWA-INFO' is mentioned on line 154, but not defined
>   == Unused Reference: 'RFC2578' is defined on line 1248, but no explicit
>      reference was found in the text
> 
> On 11/12/2013 9:06 PM, Leeyoung wrote:
>> 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.
>>
> 
> you now have two section 1s.  Perhaps the second should be 1.1?
> 
> ...
> 
>> - 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. 
>>
> 
> I expected that the "C" bit would end up in the same bit location all things being equal.  The new text has the reserved field of 7 bits, the corresponding 'action' field is 8 bit's so I think you're one bit too
> short.   Either way, you should give the number of bits that are in each
> reserved field to make this unambiguous. Perhaps?
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |Reserved(8bits)|C|             Reserved  (23 bits)             |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>> - 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.
>>
> 
> Where is this stated?  Now that they are list as fields this is even less self evident.
> 
>>   - 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?
>>
> 
> Again, just looking for an explicit statement of processing requirements.
> 
>>   - What is the sub-sub-TLV header (TL format)?
>>
>> YOUNG>> Added TLV format
> 
> It looks like only the Optical Interface Class List field has a type and length field (neither of which are defined).  What about the other 3?
> (Acceptable Client Signal Type, Input Bit Rate List, Processing Capabilities List)
> 
> Also, note that you reference the "Processing Capabilities List" but don't define it.
> 
> 4.6. is titled "Processing Capability List Field", 4.6.1 is titled "Processing Capabilities Field" which defines the "processing capability field".  Clearly you need to pick just one.
> 
>>
>>   - Are there any alignment requirements?
>>
>> YOUNG>> Not sure what this is. 
> 
> It's part of a typical TLV definition.
> 
>>
>>   - 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. 
>>
> [copied]
>> YOUNG>> For the last dash item, "what happens when sub-sub-TLV is
> larger than 256 bytes", I guess you meant that the RB Info Field (in which to contain sub-sub-TLVs) can exceed 256 bytes as opposed to individual sub-sub-TLVs in the RB Info Field?
> 
> It was a general question, as the topic has showed up as a general in in ccamp. I'd expect it to be addressed as part of the TLV definition.
> 
>>
>> YOUNG>> As for the resolution for this case, should this be addressed
> in the respective routing and signaling drafts?
> 
> If it's likely to happen, then I think you need to say something about it.  If it should never happen, e.g., due to fixed sizes, then it can be ignored.
> 
>> YOUNG>> I am not familiar the method to resolve this kind of issues
> --- can you suggest some references or relevant text?  I think this issue would arise both routing and signaling.
> 
> Agreed.  Truncation and semantic fragmentation show up in a bunch of places. The real question is, is how worried do we need to be about this case?
> 
> 
> ...
> 
>>
>> - 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.
>>
> 
> You still have one case of an E-bit (rather than O-bit) in Section 4.3.
> 
> ...
> I think this covers all open points on this one.
> 
> Lou
>