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

[Lou Berger <[e-mail]>]

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