| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hesham, My personal opinion is that we're unlikely to come up with any sort of definition in advance that we can all agree on, particularly when it is a theoretical exercise. Rather, I suspect that what will ultimately happen is that we'll need to look at specific individual cases and then decide as a group whether or not we feel a particular change meets that definition. Put another way, I don't know that we can or should try to decide a strict definition now, but rather that we should wait until we have specific proposals and evaluate them with this in mind. Additionally, I have always looked at that statement as "the minimal necessary" augmentation to achieve our objectives. Admittedly that's not precisely what it says, but that's how I've viewed that statement, and one way in which I believe you could interpret it. Because in the end I think that's exactly what we need to do: make those changes that are necessary to enable our objectives, while showing restraint so that we don't make changes that are absolutely necessary. My $0.02 worth – I will be interested in hearing others' thoughts. Thanks. Matt From: Hesham ElBakoury <Hesham.ElBakoury@xxxxxxxxxx> Reply-To: Hesham ElBakoury <Hesham.ElBakoury@xxxxxxxxxx> Date: Thursday, August 9, 2012 5:47 PM To: "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx> Subject: [802.3_EPOC] Minimal MPCP Augmentation Through the discussions we had so far I do not see a common agreement on the definition of “minimal augmentation” to MPCP. For example which one of the following MPCP changes are considered “Minimal” augmentation to MPCP and why:
1.
Defining a new MPCP message. 2.
Adding a new field to an existing MPCP message. 3.
Change the interpretation/definition of existing field(s) in MPCP message. 4.
Using reserved/unused fields in existing messages. 5.
…. Comments are welcome. Thanks Hesham
|