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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, Eric,

On Sep 13, 2018, at 9:52 AM, Eric C Rosen <erosen@xxxxxxxxxxx> 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.

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

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, carlos@xxxxxxxxx

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



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux