Hi Pierrick, I personally prefer the idea of adding a dedicated section to describe the scenarios, since the scenarios may help people to understand where the problem is which is the goal of the PS document. Regarding to the classification of the scenarios, I guess it is ok for me. thanks. BR, Dapeng Liu > 2009/10/20, pierrick.seite at orange-ftgroup.com > <pierrick.seite at orange-ftgroup.com>: >> >> >> >> Hello, >> >> During Stockholm meeting, we've decided to include scenarios from >> section 3 of draft-williams within MIF problem statement draft. >> >> After having discussed with authors of req and scenarios drafts, we >> concluded that, _from problem statement perspective_, these scenarios >> can be classified into two use-cases: >> 1. "Services shared between all provisioning domains" (corresponds to >> draft-williams/scenario 3.1) >> Or >> 2. "Services shared by a limited number of provisioning domain" (we've >> considered that scenarios 3.3 to 3.5 lead to the same use-case when >> considering the high-level description of the ps). >> >> >> So we have simply updated the MIF host definition in >> draft-ietf-problem-statement with the following statement: >> " Communications using these IP addresses may be tied on all the >> possible provisioning domains, or, at least, on a limited number of >> provisioning domains." >> >> >> Now, it may be not sufficient for a good understanding of the issue, so >> before submitting a new version, we wish to have the feeling of the WG >> on the following: >> - Do you agree with the classification of the scenarios into two >> use-cases, considering the high-level description of the ps? >> - Do you think the statement in host definition is clear enough or do >> you thing a dedicated section for scenarios is also required? >> >> >> >> Comments are welcomed. >> >> Best Regards, >> Pierrick >> _______________________________________________ >> mif mailing list >> mif at ietf.org >> https://www.ietf.org/mailman/listinfo/mif >> >
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.