[GROW] Martin Vigoureux's No Objection on draft-ietf-grow-wkc-behavior-07: (with COMMENT)

Martin Vigoureux via Datatracker <noreply@ietf.org> Thu, 13 June 2019 09:12 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Vigoureux via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-grow-wkc-behavior@ietf.org, Job Snijders <job@ntt.net>, grow-chairs@ietf.org, job@ntt.net, grow@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Vigoureux <martin.vigoureux@nokia.com>
Message-ID: <156041716252.12673.1483974766958569799.idtracker@ietfa.amsl.com>
Date: Thu, 13 Jun 2019 02:12:42 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/K0itnDvYpWjW3eeFU2uU0qPXjHo>
Subject: [GROW] Martin Vigoureux's No Objection on draft-ietf-grow-wkc-behavior-07: (with COMMENT)

Martin Vigoureux has entered the following ballot position for
draft-ietf-grow-wkc-behavior-07: 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 IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-grow-wkc-behavior/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

thank you for this document.

I'm not clear about something and would like to better understand.

I read this:
   Vendors MUST ensure that their implementations' "set" directive
   treatment of any specific community does not change if/when that
   community becomes a new Well-Known Community through future
   standardization.  For most implementations, this means that the "set"
   directive MUST continue to remove the community; for those
   implementations where the "set" directive removes no communities,
   that behavior MUST continue.
as saying "do not change your implementation behaviour for the existing WKC,
and also apply that same behaviour to any future WKC that might be defined".

If this reading is correct, I am under the impression that:
   When establishing new [RFC1997]-like attributes (large communities,
   wide communities, etc.), RFC authors should state explicitly how the
   > new attribute is to be handled.
is in conflict with the above.
I know it's not a 2119/8174 keyword, but still, this seems to allow authors to
specify how a future WKC should be treated by 'set' or 'delete *:*' and thus,
for some implementations, that behavioral requirement will be in conflict with
their current behaviour (which must not change).

Thank you

[GROW] Martin Vigoureux's No Objection on draft-i… Martin Vigoureux via Datatracker