Re: Éric Vyncke's No Objection on draft-ietf-rtgwg-policy-model-30: (with COMMENT)

Yingzhen Qu <yingzhen.ietf@gmail.com> Thu, 12 August 2021 04:45 UTC

Return-Path: <yingzhen.ietf@gmail.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C905F3A352F; Wed, 11 Aug 2021 21:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 S9e0FhVFSlhz; Wed, 11 Aug 2021 21:45:51 -0700 (PDT)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 A63AA3A352D; Wed, 11 Aug 2021 21:45:51 -0700 (PDT)
Received: by mail-pj1-x1029.google.com with SMTP id g12-20020a17090a7d0cb0290178f80de3d8so8621915pjl.2; Wed, 11 Aug 2021 21:45:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+YKlbg4S193HzwOcSZs9OPrY9frEMZvEPSLqOH3K+8Q=; b=FzcIGYor3IdwTliPkRD8icIjW2XhYc5Oe/596Bqd6jKlYpx4nUDb9LfABpYCDetBHg DuADQvMyEAwbSIwUSO63wwGIqK6udziXQ2PuI/eTxPDzAdr4a611c5jegG3m736kJ0S6 a1+ZZCE4Lc7Ty2SARS3uR3fmkilapKSF997WF0IZlqLfDKgx6NBw7TM9k9Y4dWW9+v8T tsDlazSNi7tOMh2vLowc/h1XSZSyyHX2hAt1lKotntOA9fmzuJggbvOYo2M52hEzixE7 EVIkNEzkFQDnZel50ru2oqhGyekL9cpkfi0XWcN1d9jYSkZPzATtFEBqgfEkmdNjekuR Vx4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+YKlbg4S193HzwOcSZs9OPrY9frEMZvEPSLqOH3K+8Q=; b=jk3k+SQpFTYu6xKR7rJ8sTG+ButyMK4zLPuHk61xKBro1p6R+sawY0o5nyzJn8kWlN V3aGreTcb0sdTMmu5TFovQonibAO1U7VcGveGsarxiT5Sg8x9bZRczJ2RCQPiDoMIEsS Xnza8HIdjEdsserxlDYsNBjkqW1G5FrFYNXoEjE12XQCECdTuos31MmZC4o3hBkFhjEk 9MkMH3bu+nwLQgJlmk9S1reCo9CQMJ5lk+M8KRe6YmnBko/kUQJpWTpYZ21DmVMKRbS6 flqVN6obgFicEMFIQYB+imiSOOL9fIZxcdXxDjqcnNs3J5emrs1XyUiE/bi4cR/TWWfc ukMg==
X-Gm-Message-State: AOAM531xJdXcWEKv/zgCrDgY5fPrnrVfZ32CorQsIowe/EEDaY1xFhi2 oZPdqoV8j9UxrD17s0kdNA==
X-Google-Smtp-Source: ABdhPJwMOQcoV4GOWxmVLOIy7czjA+/2JkkCumNdgD5MXyNcJnKGlQNiXC8c5i081QJnLq6HKukw2Q==
X-Received: by 2002:a17:902:7b93:b029:12b:a0a5:78d2 with SMTP id w19-20020a1709027b93b029012ba0a578d2mr2027499pll.51.1628743549281; Wed, 11 Aug 2021 21:45:49 -0700 (PDT)
Received: from ?IPv6:2601:646:9702:c61:d1:fd8c:dec2:db26? ([2601:646:9702:c61:d1:fd8c:dec2:db26]) by smtp.gmail.com with ESMTPSA id f6sm1334687pfv.69.2021.08.11.21.45.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Aug 2021 21:45:48 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
Subject: Re: Éric Vyncke's No Objection on draft-ietf-rtgwg-policy-model-30: (with COMMENT)
From: Yingzhen Qu <yingzhen.ietf@gmail.com>
In-Reply-To: <162869024727.4980.1992793255874141768@ietfa.amsl.com>
Date: Wed, 11 Aug 2021 21:45:46 -0700
Cc: The IESG <iesg@ietf.org>, draft-ietf-rtgwg-policy-model@ietf.org, rtgwg-chairs <rtgwg-chairs@ietf.org>, routing WG <rtgwg@ietf.org>, Chris Bowers <chrisbowers.ietf@gmail.com>, aretana.ietf@gmail.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <C670ACD0-7A05-4AFB-A026-C8A48C84B38C@gmail.com>
References: <162869024727.4980.1992793255874141768@ietfa.amsl.com>
To: Éric Vyncke <evyncke@cisco.com>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/XYKGfLx4FZJUEQWN9rCCyRJvHOI>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Aug 2021 04:45:57 -0000

Hi Eric,

Thank you for your review and comments, please see my answers inline.


Thanks,
Yingzhen

> On Aug 11, 2021, at 6:57 AM, Éric Vyncke via Datatracker <noreply@ietf.org> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-rtgwg-policy-model-30: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-policy-model/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document. I really admire the 4 authors
> managing to reach a consensus even while having different affiliations: IETF at
> its best!
> 
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated).
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> -- Section 2 --
> Having "Policy chain: A policy chain is a sequence of policy definitions
> (described in Section 4)." in the terminology section does not really help the
> reader…
[Yingzhen]: The language here is not clear. It means that policy definitions are descried in Section 4. I’ll remove “(described in Section 4)" in the next version.
> 
> -- Section 4.1 --
> While I am not a YANG expert, I wonder about the "*" (usually meaning 0 or
> more) for address in the neighbor-set container ? How can a neighbor exist w/o
> an address ? Why not using the "min-elements' YANG statement ?
> 
[Yingzhen]: neighbor-set allows you to define a list of neighbor-set keyed by “name”. In each neighbor-set, besides name, there is a list of address. We didn’t add the “min-elements” statement because this allows to create an “empty” neighbor-set. I understand it’s not really useful when being referenced, but might be convenient during configuration.
>