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

Lou Berger <lberger@labn.net> Mon, 20 January 2014 19:52 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 C05741A0267 for <ccamp@ietfa.amsl.com>; Mon, 20 Jan 2014 11:52:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
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 0BA99t00kO3y for <ccamp@ietfa.amsl.com>; Mon, 20 Jan 2014 11:52:53 -0800 (PST)
Received: from alt-proxy11.mail.unifiedlayer.com (alt-proxy11.mail.unifiedlayer.com [74.220.211.241]) by ietfa.amsl.com (Postfix) with SMTP id 17A811A0263 for <ccamp@ietf.org>; Mon, 20 Jan 2014 11:52:53 -0800 (PST)
Received: (qmail 2019 invoked by uid 0); 20 Jan 2014 19:52:53 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy16.mail.unifiedlayer.com with SMTP; 20 Jan 2014 19:52:53 -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=jIt4imtkRc4Wj8xMWZ50ElN5Hziz85UM+vbOt76qqbg=; b=QiNErSBMnTejXIcYJBDBg2ZPL0QkVPRAhatmoUYzi1BIAeIEbaJtBbQ1fWYjmI7uVGqxrKReJgKAMIgbHbkpbHWRAr/z3xulW5u7uoqe6Ekj+wRyK9c9qK41WxsOiHb2;
Received: from box313.bluehost.com ([69.89.31.113]:53974 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1W5Ktx-0007Pd-49; Mon, 20 Jan 2014 12:52:53 -0700
Message-ID: <52DD7E93.1000805@labn.net>
Date: Mon, 20 Jan 2014 14:52:51 -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-info@tools.ietf.org" <draft-ietf-ccamp-rwa-info@tools.ietf.org>
References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> <526FFDBB.4020504@labn.net> <7AEB3D6833318045B4AE71C2C87E8E17291E1BD8@dfweml511-mbs.china.huawei.com>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E17291E1BD8@dfweml511-mbs.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-info
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: Mon, 20 Jan 2014 19:52:54 -0000

Young, (all),

Now that the IPR issues are resolved on the document set, it's time to
get these documents published.

There are few minor items in this document.

On 11/7/2013 5:32 PM, Leeyoung wrote:
> Hi Lou,
> 
> Here's my response to specific comments to draft-ietf-ccamp-rwa-info. 
> 
> Thanks.
> Young
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net] 
> Sent: Tuesday, October 29, 2013 1:26 PM
> To: CCAMP; draft-ietf-ccamp-rwa-info@tools.ietf.org
> Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info
> 
> 
...

> 
> YOUNG>> [Switch] moved to normative reference section.

A normative reference to a a journal paper, are you sure?  I would have
just changed the language to make it informative, but it's your call.
(Unless the RFC editor chimes in on it...)

> 
...

> 
> - Section 5: I found it hard to parse the following:
>    As resources are the smallest identifiable unit of
>    processing resource, one can group together resources into blocks if
>    they have similar characteristics relevant to the optical system
>    being modeled, e.g., processing properties, accessibility, etc.
>   Do you perhaps mean?
>    A resource is the smallest identifiable unit of
>    allocation. One can group together resources into blocks if
>    they have similar characteristics relevant to the optical system
>    being modeled, e.g., processing properties, accessibility, etc.
> 
> YOUNG>> Agreed. Changed.

I think you have a bad cut and paste.

s/resource./allocation.

> -Section 5.1: States: " Note that except for <ResourcePoolState>
>   all the other components of <ResourcePool> are relatively static."
>   But the related definitions are:
> 
>    <ResourcePool> ::= <ResourceBlockInfo>...
>    [<ResourceAccessibility>...] [<ResourceWaveConstraints>...]
>    [<RBPoolState>] (section 5)
> 
>    <DynamicNodeInfo> ::=  <NodeID> [<ResourcePoolState>] (section 7.2)
> 
>    What's the intent here?
> 
> YOUNG>> See the cleaned text in Section 7.2:
>    Currently the only node information that can be considered dynamic
>    is the resource pool state and can be isolated into a dynamic node
>    information element as follows:
> 
>    <DynamicNodeInfo> ::=  <NodeID> [<ResourcePool>]
> 
>    Where
> 
>    <ResourcePool> ::= <ResourceBlockInfo>...[<RBPoolState>] 

sorry, I didn't mean for you to incorporate the <ResourcePool>
definition into the document.  this was just for our discussion.  I
don't think adding a duplicate/incomplete definition here is the right
thing.  So I'd drop it (starting with Where.)


> 
> 
> - Section 5.2: What is the asterisk "*" all about.
> 
> YOUNG>> That means whatever within () can be repeated. 
> 

I don't recall this syntax definition in BNF/RBNF. Take a look at
http://tools.ietf.org/html/rfc5511#section-2.2.5.

Also you list [<ResourceSet>] as optional, yet it is mandatory in
section 4.1 of
http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-23

...
> 
> - Section 6.6.  I think you have a BNF problem here.  The BNF says
> restriction parameters are always optional, but your text says that
> there are requirements based on <RestrictionTypes>.  I think the BNF
> needs to be aligned with the text and reflect the requirements.
> 
> YOUNG>> Made all mandatory element. 

The new text says:

   <PortLabelRestriction> ::= <GeneralPortRestrictions>...
   <MatrixSpecificRestrictions>...

This now says that a PortLabelRestriction MUST (and always) include
*both* GeneralPortRestrictions and MatrixSpecificRestrictions.  Is this
correct in all cases?

also:

   <RestrictionParameters> ::= <LabelSet>... <MaxNumChannels>
   <MaxWaveBandWidth>

So all parameters MUST be included for all RestrictionTypes?  I suspect
you mean to say there alternatives based on RestrictionType.  If
correct, syntax is covered in
http://tools.ietf.org/html/rfc5511#section-2.2.4.

Also the RestrictionParameters object/field naming doesn't match
draft-ietf-ccamp-general-constraint-encode-13.txt, this section should
be updated to match.

...
I think this covers all open points on this one.

Lou