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

Leeyoung <leeyoung@huawei.com> Mon, 27 January 2014 23:47 UTC

Return-Path: <leeyoung@huawei.com>
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 427681A0164 for <ccamp@ietfa.amsl.com>; Mon, 27 Jan 2014 15:47:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Level:
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, J_CHICKENPOX_21=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 c7LW_FIPSFso for <ccamp@ietfa.amsl.com>; Mon, 27 Jan 2014 15:47:11 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 43AF81A008F for <ccamp@ietf.org>; Mon, 27 Jan 2014 15:47:09 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCZ60501; Mon, 27 Jan 2014 23:47:06 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Jan 2014 23:46:47 +0000
Received: from DFWEML701-CHM.china.huawei.com (10.193.5.50) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Jan 2014 23:47:02 +0000
Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.193]) by dfweml701-chm.china.huawei.com ([169.254.1.21]) with mapi id 14.03.0158.001; Mon, 27 Jan 2014 15:46:57 -0800
From: Leeyoung <leeyoung@huawei.com>
To: Lou Berger <lberger@labn.net>, CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-rwa-info@tools.ietf.org" <draft-ietf-ccamp-rwa-info@tools.ietf.org>
Thread-Topic: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info
Thread-Index: AQHPFhk5SibPPk0qa0SourRWd8AFq5qQ+nOA
Date: Mon, 27 Jan 2014 23:46:57 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BB4511@dfweml706-chm.china.huawei.com>
References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> <526FFDBB.4020504@labn.net> <7AEB3D6833318045B4AE71C2C87E8E17291E1BD8@dfweml511-mbs.china.huawei.com> <52DD7E93.1000805@labn.net>
In-Reply-To: <52DD7E93.1000805@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.142.230]
Content-Type: multipart/mixed; boundary="_002_7AEB3D6833318045B4AE71C2C87E8E1729BB4511dfweml706chmchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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, 27 Jan 2014 23:47:17 -0000

Hi Lou,

Here's my comments to your comments. Please see inline for detail. Enclosed is a working draft that reflects all the changes per your comments.
Let me know if this is ready to be published.

Thanks,
Young

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net] 
Sent: Monday, January 20, 2014 1:53 PM
To: Leeyoung; CCAMP; draft-ietf-ccamp-rwa-info@tools.ietf.org
Subject: Re: [CCAMP] WG Last Call: WSON documents - draft-ietf-ccamp-rwa-info

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...)

> 
...

YOUNG>> It was a mistake I think that took place while I was shifting some references around. I will put [Switch] back to informative reference section. 

> 
> - 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.

YOUNG>> Agree. Done. "A resource is the smallest... 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.)

YOUNG>> OK. "Where..." is dropped. Also changes in Section 5.1: 
Original: <RBPoolState> ::=(<ResourceBlockID> <NumResourcesInUse> <InAvailableWavelengths> <OutAvailableWavelengths>)...
Changed:  <RBPoolState> ::=(<ResourceBlockID> <NumResourcesInUse> [<InAvailableWavelengths>] [<OutAvailableWavelengths>])*

As <InAvailableWavelengths> <OutAvailableWavelengths> are only used in the cases of shared input or output access to the particular block.



> 
> 
> - 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.

YOUNG>> Yes, I replaced "*" with "..." (per 2.2.5) which means 'repetition.' 

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

YOUNG>> <ResourceSet> is optional. I don't think section 4.1 of wson-encode-23 treats this as mandatory. Wson-encode-23 document simply provides encoding details irrespective of whether it is mandatory or optional. Let me know if you disagree with this. 

...
> 
> - 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?

YOUNG>> No. Actually <PortLabelRestriction> is an optional information. It will be corrected as follows:

   <PortLabelRestriction> ::= [<GeneralPortRestrictions>...] [<MatrixSpecificRestrictions>...]
----------------------------------------------------------------------------------------------------
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.

YOUNG>> No. Indeed these parameters appear only if they match with Restriction Types. So it should be as follows:

<RestrictionParameters> ::= (<LabelSet>...) | <MaxNumChannels> | <MaxLabelRange> | (<LabelSet>... <MaxNumChannels>) | <LinkSet> (Note: this is arranged to be consistent with draft-ietf-ccamp-general-constraint-encode-13.txt in the naming and order)

In Section 6.6, this is a summary of all encoding changes: 

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

<GeneralPortRestrictions> ::= <RestrictionType> <RestrictionParameters>  (RestictionType and one of the parameters corresponding to the RestrictionType must be there)

<MatrixSpecificRestriction> ::= <MatrixID> <RestrictionType> <RestrictionParameters> (the same rational apples as above) 

<RestrictionParameters> ::= 
(<LabelSet>...) | <MaxNumChannels> | <MaxLabelRange> | (<LabelSet>... <MaxNumChannels>) | <LinkSet> 



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

YOUNG>> RestrictionParameters are now matching with draft-ietf-ccamp-general-constraint-encode-13.txt.

s/PortSet/LinkSet
s/MaxWaveWidth/MaxLabelRange

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

Lou