There was no "quiet" admission and no "approval". This is still very much an open question. However, Sprint (atleast) will not sit by and do nothing. We have created potential choke points in the Internet architecture and it would be irresponsible of us (as a community) to not do anything about it. Given the fact that .... a) NAP operators need traffic numbers (preferably a NSP-NSP matrix but atleast aggregate counts at small time granularities) to ensure capacity keeps ahead of demand and b) there is a *legitimate* concern about security of data collection mechanisms and privacy, availability of collected data, The questions is "How can we serve both interests?" I think one scalable solution is for NSPs, which presumably collect data for their own requirements, to report on traffic traversing NAPs. Compiling statistics across all NSPs at a cross connect point could provide us with an accurate picture of traffic levels. NAP providers must be held responsible for ensuring that data is protected, even from sister organizations (such as Ameritech v/s AADS IP service, or Sprint v/s SprintLink etc.) Of course, if you don't trust NAP providers themselves, we have a slightly bigger problem :)- ATM NAPs today will not allow a central collection point for network layer stats (per PVC cell counts are presumably available). The Sprint NAP will be similarly constrained when we move to a central FDDI switch. What is the right threshold between data collection and privacy/security ? -- Bilal
John Scudder then discussed some modeling he and Sue Hares have done on the projected load at the NAPs. The basic conclusions are that the FDDI technology (at Sprint) will be saturated sometime next year and that load-balancing strategies among NSPs across the NAPS is imperative for the long term viability of the new architecture. John also expressed concern over the lack of expressed policy for the collection of statistical data by the NAP operators. All of the NAP operator are present and stated that they will collect data, but that there are serious and open questions concerning the privacy of that data and how to publish it appropriately. John said that collecting the data was most important. Without the data, there is no source information from which publication become possible. He said that MERIT/NSFNET had already tackled these issues. Maybe the NAP operators can use this previous work as a model to develop their own policies for publication.
Merit/NSFNet already tackled these issues in an insufficent and unopen manner.
MarkFedor/ColeLibby from PSI said there was a "quiet" admission that the old methodology was already "approved" for the SPRINT NAP.
Marty