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 > >
- [Teas] Rtgdir last call review of draft-ietf-teas… Ines Robles via Datatracker
- Re: [Teas] Rtgdir last call review of draft-ietf-… Tarek Saad
- Re: [Teas] Rtgdir last call review of draft-ietf-… Ines Robles