Ben, Apologies for the late reply - I lost track of this email.
I think the requirement below comes a bit "after the fact" in the sense that it used to be relevant at a time when a protocol selection was performed. Meanwhile the IETF has specified the ANCP protocol (based on GSMP), so this requirement has lost most of its relevance. The very high level requirement would be: "The ANCP MUST be designed in such a way that it is simple and lightweight." I agree that it's pretty hard to evaluate compliance or non-compliance to such a requirement. So in that case, I propose to omit it. Regards Sven -----Original Message----- From: Ben Campbell [mailto:[email protected]] Sent: woensdag 12 augustus 2009 17:35 To: OOGHE Sven Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Jari Arkko; [email protected] Subject: Re: Gen-ART LC review of draft-ietf-ancp-framework-10 Hi, I think we are in agreement on all except the following: On Aug 12, 2009, at 9:56 AM, OOGHE Sven wrote: > > >> -- 4.3, first bullet: >> >> Can you characterize how "limited"? >> >> <Sven> Basically, the protocol must be designed to only require a >> software upgrade, not a hardware upgrade. Perhaps the requirement >> should >> be reworded to the following: >> "The ANCP MUST be simple and lightweight enough to allow an >> implementation on Access Nodes that does not specifically require >> additional control plane resources (e.g. additional CPU and memory >> requirements). " > > This still seems vague to me without some characterization of a > typical access node platform. I would be surprised if there are not a > broad range of device "size" for this sort of thing. I'm not looking > for precise hardware specs, but it would help to have some idea of the > typical range of CPU and memory resources you are thinking about. > > <Sven> I'm not sure we should start writing about hardware > components / > memory sizes / CPU types in the draft. How about I write the > following: > > "The ANCP MUST be simple and lightweight enough to allow an > implementation on Access Nodes to run without specifically requiring a > hardware upgrade" How would you test compliance with a requirement like that? Is there a way you can recast it to describe certain aspects of the protocol itself? For example statefulness, encoding types, etc? Another approach might be to make it even more general, and say the protocol specification should discuss imbedded system implementation considerations--which I suspect is close to the intent of the original language. Thanks! Ben. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
