Re: [Teas] Rtgdir last call review of draft-ietf-teas-yang-te-types-06

Ines Robles <mariainesrobles@googlemail.com> Wed, 10 April 2019 16:22 UTC

Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09B61203CD; Wed, 10 Apr 2019 09:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com
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 brCGXmnW44hH; Wed, 10 Apr 2019 09:22:46 -0700 (PDT)
Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0DD51203BA; Wed, 10 Apr 2019 09:22:45 -0700 (PDT)
Received: by mail-ed1-x543.google.com with SMTP id f53so1016690ede.4; Wed, 10 Apr 2019 09:22:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rPkWHX/e+f7HvktiU4VxYlflpKAhYxUwzQrsugv7wmI=; b=qzpQq6j1oJk533lLYkHO3fHtYQOq4/caBJxaN3GxnMgZG8ZMuR90oWWNlOv0assMYh Xr/HGH3MTfsUEOjA0OAjvBh6RZp0Bj9aesoeIlgwMxhP6wxrf0bXZpW9uYeF5NJKkMIO lzmxNqGY+lEZ8uuxtq8uE05X3UseIcmS3EcNmMglfau4Ezw7biY44PVluxSFAmERQk4U b/JWOKzUx/pGfsDRa8RZbXed2yHg5rL3iWWfO6xYpyzTBc4VXvgM/JQ/i4iv2Z0iwUTJ vsPM2MHX4hkzMh+CV11tq1hDi01/gRAaUwDinn0lD/IDcOwFAPuGLNz9Fa/ooTdVnU0w xFAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rPkWHX/e+f7HvktiU4VxYlflpKAhYxUwzQrsugv7wmI=; b=sPHMbg/B3gcyo2M7507tRGsG3u7hq8wUnS7FaIHKNgcgNDjw2+eR4yddEsY8j/QoLh E2xRIDOKCOMX70KxrhcABA5GN2tn/q73//gA1O3MKTJlAOiougGb1Kk5ij/ay2WW/LVq 3H2Xr3+BSxj5E423Zdse85SMSa1U5UZWY81WWbCSo8Kba9V3ba0/gxvZCyD+GIOzdbow j03p1YUQ2J2+jAOwW5ROFpb6VT9eWC/S5rdL5dJxM+bpyM5iEUyQjhu8lXN7Q6pw2FXf l+c9Wpp/BA7WYCMQ2c7Me4V436gUSuhF90+VDNe/o+9DTmUijYCIGxS4pxVIDFnkOtnM lzdw==
X-Gm-Message-State: APjAAAX478wd+h+3gWp4dBx4Ci1XQmcLklQHg9ruwyUc0tadsr9qmbx+ BsPvrvAOuLNwwcD0CpNZB/GrfNaWfBLU9Jrtb50=
X-Google-Smtp-Source: APXvYqxAzNz8V2GlozfKE/9V47DQoOI5vdBWt+EvZDYFXDptmZLOLZO5w/lA6auxrpjXp8Gcq9n4pvYZeLXQiMB3yk4=
X-Received: by 2002:a17:906:a291:: with SMTP id i17mr23215845ejz.180.1554913364034; Wed, 10 Apr 2019 09:22:44 -0700 (PDT)
MIME-Version: 1.0
References: <155419068227.6270.4463422400569037872@ietfa.amsl.com> <BN8PR06MB628983DD0CC924475B803EACFC2D0@BN8PR06MB6289.namprd06.prod.outlook.com>
In-Reply-To: <BN8PR06MB628983DD0CC924475B803EACFC2D0@BN8PR06MB6289.namprd06.prod.outlook.com>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Wed, 10 Apr 2019 19:22:32 +0300
Message-ID: <CAP+sJUfjjDSCOCA1tVGf094ZTRnUYL5NPLo20Wnb90PDUbpUBA@mail.gmail.com>
To: Tarek Saad <tsaad.net@gmail.com>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-teas-yang-te-types.all@ietf.org" <draft-ietf-teas-yang-te-types.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "teas@ietf.org" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b84c1b05862f7a6c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/JZxO-G5t2npkvuibjT17xs1kVoA>
Subject: Re: [Teas] Rtgdir last call review of draft-ietf-teas-yang-te-types-06
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2019 16:22:49 -0000

Hi Tarek,

Thank you, I agree with your comments.

Best regards,

Ines.

On Tue, Apr 9, 2019 at 3:23 AM Tarek Saad <tsaad.net@gmail.com> wrote:

> Hi Ines,
>
> Thank you very much for the detailed review and comments.
> We've uploaded new versions of the draft that will address them (latest
> version -08).
> Diff that shows changes is @
> https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-teas-yang-te-types-06.txt&url2=https://tools.ietf.org/id/draft-ietf-teas-yang-te-types-08.txt
>
> Please see inline for further responses and do let us know if there are
> further comments.
>
> On 4/2/19, 3:39 AM, "Teas on behalf of Ines Robles via Datatracker" <
> teas-bounces@ietf.org on behalf of noreply@ietf.org> wrote:
>
>     Reviewer: Ines Robles
>     Review result: Has Nits
>
>     The routing directorate will, on request from the working group chair,
> perform
>     an “early” review of a draft before it is submitted for publication to
> the
>     IESG. The early review can be performed at any time during the draft’s
> lifetime
>     as a working group document. The purpose of the early review depends
> on the
>     stage that the document has reached.
>
>     As this document is in working group last call, my focus for the
> review was to
>     determine whether the document is ready to be published. Please
> consider my
>     comments along with the other working group last call comments.
>
>     For more information about the Routing Directorate, please see
>     ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
>     Document: draft-ietf-teas-yang-te-types-06.txt
>     Reviewer: Ines Robles
>     Review Date: 02/04/2019
>     Intended Status: Standards Track
>
>     Summary:
>
>     I believe the draft is technically good. This document is well written
> and
>     clear to understand. The draft is quite complete.
>
>     The document defines a collection of common data types and groupings
> in YANG
>     data modeling language. These derived common types and groupings are
> intended
>     to be imported by modules that model Traffic Engineering (TE)
> configuration and
>     state capabilities.
>
>     I found some minor nits and have some minor questions, it would be
> nice if they
>     could be addressed.
>
>     Major issues: Not found
>
>     Minor issues: Not found
>
>     Nits/editorial comments:
>
>     - NBMA could be expanded in pag 14  NBMA (Non-broadcast multiple-access
>     network) or maybe added into Acronyms and Abbreviations section. Same
> for SF
>     (pag 32), SD (Pag 33), APS (pag 35) and PM (pag 46)
> [TS]: Added into acronyms, and expanded when necessary.
>
>     -In Pag. 43 identity oduc --> identity oducn ?
> [TS]: fixed.
>
>     - In pag 45, default forward --> default "forward" ?
> [TS]: fixed.
>
>     - Pag 58 ihe --> the  , ranage --> range
> [TS]: fixed.
>
>     Questions:
>
>     - In te-admin-status (pag. 12) is the status "unknown" not applicable
> in here?
> [TS]: We think it's useful so to identify a status that is not explicitly
> defined. We have added it.
>
>     - In te-recovery-status (pag 17)  the status reversion-succeeded woud
> be not
>     necessary in this case, cause we have recovery-succeeded status
> available?
> [TS]: We have added reversion-succeeded to explicitly indicate
> successful completion of reversion.
>
>     - In pag 25, the lsp-state-type does not have a reference is that ok?,
> because
>     it is used as base for other parameters.
> [TS]: Yes, in general the intention was the derived from base indentities
> would be explicitly referenced.
>
>     - In general, I see some parameters that do not have reference
> specified, it is
>     because the reference is already specified in the base, for example,
> pag 25,
>     objective-function-type has reference, but then of-minimize-load-path,
>     of-maximize-residual-bandwith do not have it. Is it because by default
> is the
>     one of the base, in this case RFC4657? or it is because they are
> defined in
>     this document? But for example lsp-protection-type is used as base and
> does not
>     have reference added.
> [TS]: Yes, as mentioned earlier, identities derived would be explicitly
> referenced. That said, I went ahead and made sure missing references are
> added.
>
>     -In pag. 34, in the description for protection-external-commands,
> should
>     include in the description the word "base", since it is used as base.
> [TS]: addressed as per suggestion.
>
>     - In pag. 55 the description "RFC 3209 and others", should be added
> additional
>     rfcs, instead of "others"?
> [TS]: yes, replaced others by the intended RFCs.
>
> Regards,
> Tarek
>
>     Thanks for this document,
>
>     Ines.
>
>     _______________________________________________
>     Teas mailing list
>     Teas@ietf.org
>     https://www.ietf.org/mailman/listinfo/teas
>
>