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

From: Carlos Pignataro <[email-masked]>
Date: Wed, 12 Sep 2018 20:26:54 -0700

Reviewer: Carlos Pignataro
Review result: Has Nits

This is a very well written and detailed document.

I have only one concern, which I believe should be addressed before moving this
document forward:

I found the rational and specific details on what this document "Updates" from
three previous RFCs to be lacking, and confusing.

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
RFCs. At least, something more inline with current thinking as per
https://www.ietf.org/mail-archive/web/ietf/current/msg109106.html

Thanks,

Carlos Pignataro.

---

From: Eric C Rosen <[email-masked]>
Date: Thu, 13 Sep 2018 09:52:44 -0400

> three previous RFCs to be lacking, and confusing.

Carlos,

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 ;-)

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.

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.

I think this justifies the "Updates" status.

> RFCs.

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

Eric

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 13 Sep 2018 17:10:55 +0000

Hi, Eric,

On Sep 13, 2018, at 9:52 AM, Eric C Rosen <[email-masked]<mailto:[email-masked]>> wrote:

Carlos,

Thanks for your review.

Anytime!

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 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 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.

Eric

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

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