Re: [CCAMP] [Gen-art] Gen-Art LC review draft-ietf-ccamp-gmpls-ospf-g709v3-09

Jari Arkko <jari.arkko@piuha.net> Wed, 20 November 2013 18:48 UTC

Return-Path: <jari.arkko@piuha.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 EC1591AE063; Wed, 20 Nov 2013 10:48:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.425
X-Spam-Level:
X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] 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 fYKQl7zc3kGQ; Wed, 20 Nov 2013 10:48:19 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4471AE04D; Wed, 20 Nov 2013 10:48:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7ADF72CCAE; Wed, 20 Nov 2013 20:48:11 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wp1LtGj9dQ38; Wed, 20 Nov 2013 20:48:10 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id BA7452CC48; Wed, 20 Nov 2013 20:48:08 +0200 (EET)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48163DD1@ESESSMB301.ericsson.se>
Date: Wed, 20 Nov 2013 15:48:06 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <18E856A7-DC79-40AF-8C4F-F8507F40133F@piuha.net>
References: <52581639.4050602@nostrum.com> <4A1562797D64E44993C5CBF38CF1BE48163DD1@ESESSMB301.ericsson.se>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Robert Sparks <rjsparks@nostrum.com>
X-Mailer: Apple Mail (2.1510)
Cc: General Area Review Team <gen-art@ietf.org>, draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org, ccamp@ietf.org
Subject: Re: [CCAMP] [Gen-art] Gen-Art LC review draft-ietf-ccamp-gmpls-ospf-g709v3-09
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: Wed, 20 Nov 2013 18:48:21 -0000

Many thanks for your review, Robert! Daniele, thank you for the modifications. However, I do not see the IANA section modification yet in -11. But maybe I missed it. Has that been incorporated to the latest version? (I thought your text suggestion looked fine.)

Jari

On Oct 15, 2013, at 5:21 AM, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> wrote:

> Hi Robert,
>  
> Many thanks for your review. Please find comments/replies in line.
>  
> BR
> Daniele (& co-authors)
>  
> From: Robert Sparks [mailto:rjsparks@nostrum.com] 
> Sent: venerdì 11 ottobre 2013 17:16
> To: General Area Review Team; ccamp@ietf.org; draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org
> Subject: Gen-Art LC review draft-ietf-ccamp-gmpls-ospf-g709v3-09
>  
> I am the assigned Gen-ART reviewer for this draft. For background on 
> Gen-ART, please see the FAQ at 
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. 
> 
> Please resolve these comments along with any other Last Call comments 
> you may receive. 
> 
> Document: draft-ietf-ccamp-gmpls-ospf-g709v3-09
> Reviewer: Robert Sparks
> Review Date: 11-Oct-2013
> IETF LC End Date: 16-Oct-2013
> IESG Telechat date: Not yet scheduled for a telechat
> 
> Summary: This draft is basically ready for publication, but has nits that should be fixed before publication.
> 
> This document is dense (as in it puts a lot of information in a small number of characters), but it reads clearly.
> I did not carefully review the contents of the example fields for editorial mistakes - please be sure someone in the group has done that.
> 
> The largest issue I see is on the border of being more than a nit. I'm calling it a nit because it should be very easy to fix:
> The sentence "Same type of modification needs to applied to the IANA-GMPLS-TC-MIB at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib" is not sufficient instruction to IANA to cause that registry to be modified. Please provide more precise
> instructions as to how this mib should change.
> 
> [[Authors]] How about the following?
> 
> OLD
> 
> Same type of modification needs to applied to the IANA-GMPLS-TC-MIB at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib
> 
> NEW
> 
> Same type of modification needs to applied to the IANA-GMPLS-TC-MIB at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib, where the value
> 
> OTN-TDM (110),     -- Time-Division-Multiplex OTN-TDM capable
> 
> Will be added to the IANAGmplsSwitchingTypeTC ::= TEXTUAL-CONVENTION syntax list.
> 
> 
> 
> I note also that the value 40 from RFC6060 didn't make it into the mib.
> 
> The rest of these are more nitty nits:
> 
> ---
> In section 4, I think you've repeated a MUST, and risk introducing confusion.
> It's awkward to point to this with paragraph numbers because of the interspersed tables, so I'll quote the relevant block:
> 
>    When supporting the extensions defined in this document, the
>    Switching Capability and Encoding values MUST be used as follows:
>  
>    - Switching Capability = OTN-TDM
>    - Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328]
>  
>    Both for fixed and flexible ODUs the same switching type and encoding
>    values MUST be used.
> If I read that correctly , those are the same MUST and you're saying it's a MUST no matter whether you're talking about fixed or flexible ODUs.
> If that's correct I suggest replacing this with:
> 
>    When supporting the extensions defined in this document, for both
>    fixed and flexible ODUs, the Switching Capability and Encoding values 
>    MUST be used as follows:
>  
>    - Switching Capability = OTN-TDM
>    - Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328]
> (or leave out the fixed and flexible clarification altogether - I would not have been confused without it). 
> [[Authors]] Comment correct. New text adopted.
> 
> 
> ---
> 
> In section 8.2, where you say "IANA will create and maintain a new registry", I suggest you say "new sub-registry".
> [[Authors]] OK
> 
> 
> RjS
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art