On Oct 23, 2009, at 3:43 PM, James M. Polk wrote:
was giving the limitation of merging FLOWSPEC-A of 1,2,3 and FLOWSPEC-B of a,b,c the limitation of just how to you merge the two in the right order? I can't think of a solution now, but I believe we need to maintain the relative preference order within any one FLOWSPEC intact (for either all CL or all GS), agreed?
agreed on your second sentence. my inclination would be to recommend a merging that places the most aggressive request for resources on a top down basis. so if in your example above the values corresponded to units of requested resources and a=1, b=1.1, and c=4, then a merged set would appear as the following:
{c,3,2,b,1}
understood, and actually I did something similar ages ago, and was asked to remove it. Initially, I wasn't thrilled, but in the end you need to ask yourself what exactly is gained by showing the what has changed in the same document.well, it's not "...in the same document." but contrasting what's changed " ...by this document verses what's in RFCs previous to this document."Does that make more sense?
well, it makes sense, but not a convincing argument. However, this is not a deal-breaker by any means, and if you feel more comfortable with the information remaining inside the document, then leave it in as is to see if others feel differently.
-ken