Re: [CCAMP] 2nd WG Last Call comments on ospf-g709v3 (editorial only)

Lou Berger <lberger@labn.net> Thu, 04 July 2013 15:15 UTC

Return-Path: <lberger@labn.net>
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 9E27121F9F58 for <ccamp@ietfa.amsl.com>; Thu, 4 Jul 2013 08:15:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.279
X-Spam-Level:
X-Spam-Status: No, score=-101.279 tagged_above=-999 required=5 tests=[AWL=0.986, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
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 b8VRcfflP0wa for <ccamp@ietfa.amsl.com>; Thu, 4 Jul 2013 08:15:19 -0700 (PDT)
Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 0ED6E21F9ED8 for <ccamp@ietf.org>; Thu, 4 Jul 2013 08:15:18 -0700 (PDT)
Received: (qmail 30982 invoked by uid 0); 4 Jul 2013 15:14:55 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 4 Jul 2013 15:14:55 -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:CC:To:MIME-Version:From:Date:Message-ID; bh=XmEPNICHYjCkf1thOji80O4h4aNDh4PUQm8IK8RABwk=; b=A2CvBL6nOfEpP3wYoNQA/tyubpg9ljzKVyHKITqBHB+pVvFSkYQcrmyfIEVjnCF80WYRg8YZ8mXjny+YQSxS8ar+2gjEtnNN0C0P5hdCbnZN3BIBCTNtdL7TFBxPF0Lf;
Received: from box313.bluehost.com ([69.89.31.113]:46652 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1UulFG-0003CK-Ok; Thu, 04 Jul 2013 09:14:55 -0600
Message-ID: <51D59167.5050702@labn.net>
Date: Thu, 04 Jul 2013 11:14:47 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
References: <4A1562797D64E44993C5CBF38CF1BE480EEBF7@ESESSMB301.ericsson.se> <51C9DD01.2030605@labn.net> <4A1562797D64E44993C5CBF38CF1BE480FD0A0@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE480FD0A0@ESESSMB301.ericsson.se>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: CCAMP <ccamp@ietf.org>, "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" <draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org>
Subject: Re: [CCAMP] 2nd WG Last Call comments on ospf-g709v3 (editorial only)
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, 04 Jul 2013 15:15:23 -0000

Thanks Daniele.


On 7/4/2013 5:13 AM, Daniele Ceccarelli wrote:
> Hi Lou, CCAMP,
> 
> A new version of the draft has been uploaded addressing the comments below.
> 
> BR
> Daniele
> 
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: martedì 25 giugno 2013 20:10
>> To: Daniele Ceccarelli
>> Cc: CCAMP; draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org
>> Subject: Re: 2nd WG Last Call comments on ospf-g709v3 (editorial only)
>>
>>
>> Daniele,
>>
>> Please see below.  I trimmed the text down a bit, let me know if I missed any
>> discussion points.
>>
>> On 6/25/2013 5:59 AM, Daniele Ceccarelli wrote:
>>> Hi Lou,
>>>
>>> All comments addressed. Some comments in line below.
>>>
>>
>> Much thanks:
>>
>> The following nits will need to be fixed in the next rev (and before going to
>> the IESG)
>>
>>   == Missing Reference: 'RFC5226' is mentioned on line 1162, but not defined
>>
>>   == Unused Reference: 'RFC4202' is defined on line 1237, but no explicit
>>      reference was found in the text
>>
> done 
> 
>>
>>> BR
>>> Daniele
>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> Sent: venerdì 14 giugno 2013 22.32
>>>> To: CCAMP; draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org
>>>> Subject: 2nd WG Last Call comments on ospf-g709v3 (editorial only)
>>>>
>>>> Hi,
>>>> The following are comments as part of my LC review of
>>>> draft-ietf-ccamp-gmpls-ospf-g709v3-06.  Note that I'm the document
>>>> shepherd, see RFC 4858 for more information.
>>>>
>>>> Please see
>>>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft
>>> -ietf-ccamp-gmpls-ospf-g709v3-06.txt
>>>> for line numbers used in this message.
>> ...
>>
>>>> Lines 192/3:
>>>>  "The TE-Link is referred to as OTUk-TE-Link."
>>>>  This term is used just once in the document.  Suggest dropping it.
>>>>
>>>
>>> OK
>> still TBD.	
> I don't know why it was still there. Removed now.
> 
>>
>>>
>>>> Lines 193/4:
>>>>  Doesn't the TE link for an OTUk physical Link always provide ODUk
>>>> capacity? Either way this text needs to be fixed/clarified.
>>>
>>> What about dropping all of this text:
>>> The TE-Link is
>>> 193    referred to as OTUk-TE-Link.  The OTUk-TE-Link advertises ODUj
>>> 194    switching capacity.  The advertised capacity could include ODUk
>>> 195    switching capacity.
>> sure.
>>
>> ...
> Done
> 
>>
>>>>
>>>> Lines 210-212,221:
>>>>  ODUj vs ODUk.  Isn't it the case that a multi hop TE link could
>>>> represent either ODUj or ODUk resources?  This isn't clear from the
>>>> current text/usage of ODUj/k.
>>>>
>>>
>>>
>>> New text:
>>>
>>>        It is possible to create TE-Links that span more than one hop
>>> by creating  FA between non-adjacent nodes.
>>>  As in the one hop case, these types of ODUk-TE-Links also advertise
>>> ODU switching  capacity.
>>
>> why not just align with the figure name and use "Multiple hop TE-Link"
>> rather than introduce a new otherwise unused term "ODUk-TE-Links"?
>>
>> ...
> Agree. Modified accordingly
>>
>> Thanks,
>> Lou
> 
> 
> 
>