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

Tarek Saad <tsaad.net@gmail.com> Tue, 09 April 2019 00:23 UTC

Return-Path: <tsaad.net@gmail.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 457151200B2; Mon, 8 Apr 2019 17:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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=gmail.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 i40MH6YpicEO; Mon, 8 Apr 2019 17:23:21 -0700 (PDT)
Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (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 C15641200C7; Mon, 8 Apr 2019 17:23:18 -0700 (PDT)
Received: by mail-qk1-x743.google.com with SMTP id c1so9208783qkk.4; Mon, 08 Apr 2019 17:23:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=slYjkN5BfJ4+b8tXqV5xkDvPdoR7fZOh6K33MV/xxkw=; b=XoOy+idxMSYbuFLo5BNoy4R4HhDg5lIEA11GCB5pZ+qNYV5eGnKdX9C85dEceZSAEJ GT0XDAo2s8nva6ghm9xttlSD7ZJYV4rJx8ZPCrPwLQ69PBGHzEPhX7l9GlLSW4n76H06 IaQ3v0jUrRm08X3kJ49qza3e4rDsrp0PyVF+LyfFzqkk4Pm74eBUv5gjCEMFFtdET3Ro M0rp3oGmvf6risTwEHhcJ9EeU9tih2agwj67Ol2HAoo8e7rgUyXHmBjXnvppv+qrN1g4 T7cMzSW5jxC0URVtLvB7dIkgwzSswR+LaWXwYk/hkNS+H/hNtVoCpCE2N8KtVqck6Pi+ BqQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=slYjkN5BfJ4+b8tXqV5xkDvPdoR7fZOh6K33MV/xxkw=; b=i+kYPLqcUtVjntpGtYZ+hH4/azm4T7tr7+xeBuAJXnrnTce+8KE0yHHBK8O4KspHic 9goZo1MJam8a5rmSKxFh+fSpP2JAkU5dwxhL8zO2EwbN60dysssaAZQ76psaAaX+8IGl JWv3sc4YF539eVOhjXqwHZ5hNDA5tBMvQdAouQ8wOj0GCX3hUvnGKF/GmCgBiFUJ43IQ 65QnZpEdPLHJir2sAMdW0AtFlCZ65Bms5cpGolVWMOFxruJBDphrkEsA7St+7snNikEf cdLFD5IZo8SR3/wYtYGJ7diKrHWUzPRzqpqFTIbJzsknaMA220/ClU7S+S2DQnBcLggb O71Q==
X-Gm-Message-State: APjAAAXEFUp0yx4sTTi2Cwo66GbM6ngOIXkjiScV/pJER76T96ShythR O5Xie0lqZk1UgLZcl0l11g0=
X-Google-Smtp-Source: APXvYqzkRc/U3mR6xA5Nu/Tq9uUYi4goUICrJAGO7tcH5krz5y1qTw9gym6lIiYrWjx9LFxYryQ3Fg==
X-Received: by 2002:a37:64a:: with SMTP id 71mr24487333qkg.41.1554769397914; Mon, 08 Apr 2019 17:23:17 -0700 (PDT)
Received: from BN8PR06MB6289.namprd06.prod.outlook.com ([52.96.29.13]) by smtp.gmail.com with ESMTPSA id t30sm18582164qkj.56.2019.04.08.17.23.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 17:23:17 -0700 (PDT)
From: Tarek Saad <tsaad.net@gmail.com>
To: Ines Robles <mariainesrobles@googlemail.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
CC: "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>
Thread-Topic: [Teas] Rtgdir last call review of draft-ietf-teas-yang-te-types-06
Thread-Index: ATI2NDc49j1/2nhoQroXOIwaJhMprsVwbGkr
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 9 Apr 2019 00:23:15 +0000
Message-ID: <BN8PR06MB628983DD0CC924475B803EACFC2D0@BN8PR06MB6289.namprd06.prod.outlook.com>
References: <155419068227.6270.4463422400569037872@ietfa.amsl.com>
In-Reply-To: <155419068227.6270.4463422400569037872@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/nZi1daCWQ0ZGuvYIUjDK4VadSjI>
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: Tue, 09 Apr 2019 00:23:24 -0000

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