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

Leeyoung <leeyoung@huawei.com> Thu, 07 November 2013 22:32 UTC

Return-Path: <leeyoung@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BF521E8144 for <ccamp@ietfa.amsl.com>; Thu, 7 Nov 2013 14:32:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.221
X-Spam-Level:
X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWLdLCgTnMc7 for <ccamp@ietfa.amsl.com>; Thu, 7 Nov 2013 14:32:27 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 972EF11E8127 for <ccamp@ietf.org>; Thu, 7 Nov 2013 14:32:26 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXQ76520; Thu, 07 Nov 2013 22:32:25 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 22:31:41 +0000
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 7 Nov 2013 22:32:23 +0000
Received: from dfweml511-mbs.china.huawei.com ([169.254.15.141]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Thu, 7 Nov 2013 14:32:17 -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: AQHO1NRzGGBJAgcIt0SgSXb1ozCBGZoaWszA
Date: Thu, 07 Nov 2013 22:32:16 +0000
Message-ID: <7AEB3D6833318045B4AE71C2C87E8E17291E1BD8@dfweml511-mbs.china.huawei.com>
References: <524AF9A9.3040006@labn.net> <5266E138.8080605@labn.net> <526FFDBB.4020504@labn.net>
In-Reply-To: <526FFDBB.4020504@labn.net>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.136.143]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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.12
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: Thu, 07 Nov 2013 22:32:31 -0000

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


Authors,
	I have some comments on draft-ietf-ccamp-rwa-info. Most 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.

- You say: " relatively static on the time scales of
   connection establishment."  I suspect you mean:
   " relatively static and independent of connection establishment."

YOUNG>> Yes, and replaced with your suggestion.

- Your references to [Switch] seem almost normative in nature. I suspect that this is not your intent as it is listed as an informative reference.  Please revisit your references and ensure that the draft does not depend on any informative references.  (Either change the text, or move the reference to normative.)

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

- s/inputinput/input

- s/outputoutput/output

YOUNG>> Done.

- Section 4.1: " ...  and path computation [Encode]."
  While a normative reference to [Encode] is certainly just fine, I
  reference is unclear in this context.

YOUNG>> [Encode] deleted.

- Why say "potentially switched" vs just "switched"?  if "potentially"
doesn't add anything please drop it, otherwise please clarify.

YOUNG>> "potentially" removed.

- Section 4.2: SRNG
  I don't see SRNG in any other documents.  Am I missing it, is SRNG used anywhere?

YOUNG>> SNRG section removed. 

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

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


- Section 5.2: What is the asterisk "*" all about.

YOUNG>> That means whatever within () can be repeated. 

- Section 5.3.3 says
      <client-signal-list>::=[<GPID>]...
   should <client-signal-list> be <ClientSignalList> as defined in
   section 5.2?

YOUNG>> Yes; Changed to ClientSignalList.


- Section 5.3.4 repeats section 5.2.  replace:
  " as follows:

     <ProcessingCapabilities> ::= [<NumResources>]
     [<RegenerationCapabilities>] [<FaultPerfMon>] [<VendorSpecific>]"
  with "."


YOUNG>> Done.

- Section 6.5: I found the following language confused:
   This allows for the
   definition of one additional link metric value for traffic
   engineering separate from the IP link state routing protocols link
   metric.
  How about:
   This allows for the
   identification of a data channel link metric value for traffic
   engineering that is separate from the metric used for
   path cost computation of the control plane.

YOUNG>> Accepted the new text.

- Section 6.6: Drop "(Wavelength)" from the title, this can be confused with the "WSON" indication in section headings

YOUNG>> agreed. 

- Section 6.6.: You just say (Wavelength) and leave it to the reader to infer the relationship between it and a label. I suggest you make the relationship explicit.

YOUNG>> See the new text in the beginning of section 6.6: "Port label restrictions could be applied generally to any label
   types in GMPLS by adding new kinds of restrictions. Wavelength is a type of label."

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

- Section 7: You say " An example usage of this
   information in a WSON setting is given in [Shared]."

  References to URLs should be avoided (particularity when they aren't
  valid even at the time of publication, i.e., now).

YOUNG>> URL Reference removed. 

That's it on this one,
Lou

On 10/22/2013 4:34 PM, Lou Berger wrote:
> 
> All,
> 	Given the recent draft submission deadline and only one comment being 
> received to date, we'd like to extend the WG more time for review.
> 
> These drafts represent significant work by the authors and WG, so 
> please review and let the WG know what you think (positive or negative)!
> 
> Please have all comments in by October 29.
> 
> Thank you,
> Lou (and Deborah)
> 
> On 10/1/2013 12:34 PM, Lou Berger wrote:
>> All,
>>
>> This mail begins working group last call on the WSON documents.  As 
>> there are 6 documents in this set, the last call will be three weeks.
>> The documents included in the last call are:
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-info-18
>> (Informational, IPR Disclosed)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode
>> -11
>> (Standards Track, IPR Disclosed)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-rwa-wson-encode-21
>> (Standards Track)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-general-constraints
>> -ospf-te-05
>> (Standards Track, IPR Disclosed)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signal-compatibility
>> -ospf-12
>> (Standards Track, IPR Disclosed)
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 
>> (Standards
>> Track) Also has one open issue that will need to be resolved as part 
>> of LC, see http://trac.tools.ietf.org/wg/ccamp/trac/ticket/52.
>>
>> This working group last call ends on October 22.  Comments should be 
>> sent to the CCAMP mailing list.  Please remember to include the 
>> technical basis for any comments.
>>
>> Positive comments, e.g., "I've reviewed this document and believe it 
>> is ready for publication", are welcome!
>>
>> Please note that we're still missing some IPR statements.  Any 
>> forthcoming publication request will be delayed by late IPR 
>> statements/disclosures.
>>
>>
>> Thank you,
>> Lou (and Deborah)
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
>