Re: Rtgdir last call review of draft-ietf-bess-mvpn-expl-track-09

"Carlos Pignataro (cpignata)" <> Thu, 13 September 2018 17:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2273B130E08; Thu, 13 Sep 2018 10:11:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CmSbkaQ5sT3g; Thu, 13 Sep 2018 10:10:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A6CEF130934; Thu, 13 Sep 2018 10:10:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=11780; q=dns/txt; s=iport; t=1536858657; x=1538068257; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=seOWCI1LGssfdlIWz+E8W0uXGASRV8PpGJK0h9WLG1Y=; b=HSj3EgFQNTnQLvsQc2c1nJb4Esq+rHliQndX/HOgNjcmnQvJqrzQ5DJA KJt2cg4xHzalq+IIvLk6hh9upOMwKS2XBXmeVq4BswNetRfPxUqhB/y5f TTuU4ZnICOLnE1we9g9mByiqwBACI2i1qEpXyi/RDlECf14VXGKfl4La9 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AACamZpb/5FdJa1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYFOggiBZCgKg2iIFYwYkxaFNYF6C4RsAheDQSE0GAECAQE?= =?us-ascii?q?CAQECbSiFOQYjVhACAQg/AwICAjAUEQIEDgWDIYEeZKYHgS6KDIpoF4FBP4E?= =?us-ascii?q?5H4JMhH0YgmoxgiYCjTuFZIg7TAkCiTuGUxeBQYdIhXqIU4h6gj8CERSBJR0?= =?us-ascii?q?4gVVwFTsqAYJBPpAVb40AgR4BAQ?=
X-IronPort-AV: E=Sophos;i="5.53,369,1531785600"; d="scan'208,217";a="171283306"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Sep 2018 17:10:56 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w8DHAuji004366 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Sep 2018 17:10:56 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 13 Sep 2018 13:10:55 -0400
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Thu, 13 Sep 2018 13:10:55 -0400
From: "Carlos Pignataro (cpignata)" <>
To: Eric C Rosen <>
CC: "" <>, "" <>, "" <>, "" <>
Subject: Re: Rtgdir last call review of draft-ietf-bess-mvpn-expl-track-09
Thread-Topic: Rtgdir last call review of draft-ietf-bess-mvpn-expl-track-09
Thread-Index: AQHUS2kW/WRfGYHCyUaiVFFqHfByRqTutbKA
Date: Thu, 13 Sep 2018 17:10:55 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3445.9.1)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_CE5B4EC769B14B7496C2465FF021CFD0ciscocom_"
MIME-Version: 1.0
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Sep 2018 17:11:00 -0000

Hi, Eric,

On Sep 13, 2018, at 9:52 AM, Eric C Rosen <<>> wrote:

On 9/12/2018 11:26 PM, Carlos Pignataro wrote:
I found the rational and specific details on what this document "Updates" from
three previous RFCs to be lacking, and confusing.


Thanks for your review.


I don't want to get caught up in the neverending discussion of exactly what constitutes an "Update".  This is being discussed right now on the IETF list, and it's quite clear that there is no consensus.  As usual, every possible opinion is dogmatically held by someone ;-)

I agree — I support a pragmatic approach.

Someone reading RFC 6514 today will find nine RFCs updating it — with an aggregate of 186 pages (not including this document). The simpler that we can make the forward-linkage, the higher likelihood of people actually reading and robustly and interoperably implementing. No dogma or religion here. Simply, there’s a cost to spec complexity.

The introduction of the expl-track draft explicitly points out a number of situations that are not adequately addressed in the prior RFCs, and for which the prior RFCs do not provide clear guidance. This is a potential source of interoperability problems.

The introduction also indicates a number of new features that are added by the draft.

I agree that the Introduction section includes prose (and a bullet list) describing an intro as well as current shortcomings and new features. And from here the updates can mostly be inferred.

Anyone implementing RFCs 6514, 6625, and/or 7524 will certainly be well-advised to read this draft in order to (a) make sure that they properly handle the situations that are not explicitly addressed by the prior RFCs, and (b) to make sure that they are aware of the new features so they can make an informed decision of whether to implement them.

Indeed. She or he will be also well-advised to read other nine RFCs. And figure out how they are relevant to the code at hand.

I think this justifies the "Updates" status.

I agree it justifies the Updates status. I agree with the labeling of Updates for expl-track, as well as with the semantics of “read this too”.

I am simply suggesting, for your (plural) consideration, to be more explicit about what exactly is being updated in each case for each RFC being Updated.

I recommend an "Updates from RFC XYZ" section in which there is a textual
explanation and ideally Old/New specifics on how this document updates previous

I think the introduction covers this in the appropriate level of detail; I really don't know what could be added.

For your (plural) consideration, a new section titled “Updated RFCs” with three sub-sections, one for each RFC being updated, with a list of what is updated.


Carlos Pignataro,<>

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."