Thanks Dimitri, >>> - Section 3 (Definitions): "Inter-domain path computation may involve >>> the correlation of topology, routing and policy information between >>> domains." >>> What exactly do you mean by correlation? More descriptive text is >>> needed here, may be an example. >> >>Hmmm. I guess that by "correlation" we meant that there may be a need to >>bring together in mutual realtionship the topology, routing and policy >>information that exists in the separate domains. I suppose an example >>would be that in order to perform inter-domain path computation we might >>need to pull together routing information from both domains. >> >>I'm sturggling to find a way to say this different from what I typed. >>Maybe someone else can suggest some text. > > [dp] the notion of correlation could be replaced by "association of > topology, routing and policy information of two or more domains from which > specific relationships may be deduced in order to help in performing path > computation."
If the working group thinks "association" is a more acceptable word than "correlation", I'm easy with that. The second half of your sentence is useful. Thanks. >>> - Section 6.3: Synchronization is a bad term for this section. You >>> definitely are not suggesting we compute paths based on a synchronized >>> global clock ;) Suggest "Simultaneous path computation" for the section >>> title, "simultaneous processing of path computation requests" for >>> "synchronized path computation", and "sequential processing of path >>> computation requests" for "non-synchronized path computation" >> >>Synchronization is from the verb, to synchronize. >>Synchorinze - to make synchronous >>Synchronous - happening at the same time; occurring together; simultaneous >> >>So I don't see that changing "synchronized" for "simultaneous" has any >>gain. >> >>In fact, in the third paragraph we use both "synchronized" and >>"simultaneous" to make double sure that we are understood. > > [dp] don't think the issue is on sync'ing computation but on combining > e.g. protected and protecting path computation to avoid trap problem; so i > would suggest making use of the term "separated" or "disjoint" vs "joined" > path computation I don't get it. None of these terms (including the one we currently have in the I-D) has any meaning without an accompanying definition. So why is it so important to change the word? I prefer to use a word that sits naturally in the language. >>> - Section 6.6: Perhaps reliability instread of level of robustness? >>Oooh! >> >>This sent me scampering to the CCAMP P&R drafts to find the definitions of >>reliable and robust. Unfortunately not there :-( > > [dp] p&r deals with resiliency issues and to clarify these terms > > resiliency = ability of a system to reach and maintain an acceptable level > of functioning and structure with one or more of its components > malfunctioning > > reliability = ability of a system or component to perform consistently its > required functions under stated conditions for a specified period of time > > robustness = the degree to which a system or component can function > correctly in the presence of invalid inputs or stressful environment > conditions Well, given that statement, I guess our text should read... - the levels of resiliency, reliability and robustness of the path resources ... which should satisfy Payam as well. Cheers, Adrian _______________________________________________ Pce mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pce
