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

Lou Berger <lberger@labn.net> Tue, 28 January 2014 22:35 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A55D1A0476 for <ccamp@ietfa.amsl.com>; Tue, 28 Jan 2014 14:35:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level:
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsJpADFmGr3G for <ccamp@ietfa.amsl.com>; Tue, 28 Jan 2014 14:35:36 -0800 (PST)
Received: from oproxy14-pub.mail.unifiedlayer.com (oproxy14-pub.mail.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id D9C2E1A0467 for <ccamp@ietf.org>; Tue, 28 Jan 2014 14:35:35 -0800 (PST)
Received: (qmail 17379 invoked by uid 0); 28 Jan 2014 22:35:32 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.mail.unifiedlayer.com with SMTP; 28 Jan 2014 22:35:32 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=556pAvIwiUQq6eqoZGXhMmo/7pU6+MIA2K8imrREvEk=; b=Yy2nDE9/EfDdfbO+wNViNIBP5vVRxdZ9TA1V0FTkMvzvoo0oFHkaqfj0GMwsjJ8BWbCUmIKjFbQgLaAmr2jQbexJ/ShR/U1CV8r6WSwvfn2Lq7e9BgThMajBMb96yHNj;
Received: from box313.bluehost.com ([69.89.31.113]:54756 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1W8HFj-0000fY-Qm; Tue, 28 Jan 2014 15:35:31 -0700
Message-ID: <52E830AE.60002@labn.net>
Date: Tue, 28 Jan 2014 17:35:26 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Leeyoung <leeyoung@huawei.com>, CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org" <draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org>
References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> <526FFE06.20207@labn.net> <7AEB3D6833318045B4AE71C2C87E8E17291E3AF2@dfweml511-mbs.china.huawei.com> <52DD7EC4.9050801@labn.net> <7AEB3D6833318045B4AE71C2C87E8E1729BB4575@dfweml706-chm.china.huawei.com>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1729BB4575@dfweml706-chm.china.huawei.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-wson-encode
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 22:35:38 -0000

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:lberger@labn.net] 
> Sent: Monday, January 20, 2014 1:54 PM
> To: Leeyoung; CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org
> 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:lberger@labn.net]
>> Sent: Tuesday, October 29, 2013 1:27 PM
>> To: CCAMP; draft-ietf-ccamp-rwa-wson-encode@tools.ietf.org
>> 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
>