Hi Salman, >-----Original Message----- >From: Salman Abdul Baset >Sent: Monday, January 05, 2009 6:22 AM
>I agree with Bruce. In addition: > >Diagnostics are a combination of techniques. The methods specified in the >draft are one of them. They may well be other approaches such as state >acquisition of a node and overlay crawl through overlay operator managed >nodes. It is true if you have operator managed nodes, just as we did in our early SEP prototype. However, the methods defined in the diagnostics draft can accommodate different scenarios. E.g. you can use the Echo method defined in the diagnostics draft with the destination list set to a list of overlay managed nodes to retrieve the diagnostic information of them (or use the Path_Track iteratively) and only accept the Echo responses from the authorized nodes. >A node regularly needs to perform overlay maintenance operations. >It may need to be specified when does a node switch to a 'diagnostic mode'. I agree what you mentioned here is needed. IMHO, it is related to the usage scenarios of the diagnostics, especially that when does a node need to perform diagnostic operation. The diagnostic operation may be generated from the operator (that is part of the reason why we optionally need a diagnostic server) or from an overlay node itself due to some connectivity problem or other reasons. >An overlay operator may be interested in gathering a 'health report' of >the overlay. When the overlay size is 'small', such information can easily >be overlayed on a geographical map (we used this approach in our OpenVoIP >system). Diagnostics may play a role here. Yes, I agree that diagnostics can be used to gather proper information and do the connectivity monitoring for such a "health report". By the way, some coordinate system or an ALTO server can be used for building your geographical map. >As a procedural comment, I think the diagnostic document track should be >'Experimental' or 'Informational' until we have gained sufficient >understanding of the protocol methods and required information from >practical deployments. IMO, it will be "standard track", although it is not perfect at the moment, we still have a lot of work to do until we output the final revision. BR Haibin >-salman > > >On Sun, 4 Jan 2009, Bruce Lowekamp wrote: > >> I've been in favor of adoption, and I am not going to change my opinion now. >> >> However, I have some serious concerns about this draft, and the >> revisions have not addressed them. When the revision was posted, it >> should have been announced on the list and the changes made to it >> brought to the attention of the wg members for discussion. >> >> I have technical concerns with this draft that have been mentioned >> before (OWD can't be measured the way this draft proposes, and I don't >> believe the multiple-responses-for-an-echo-request technique should be >> supported). >> >> There are also some issues with duplication of functionality between >> base methods and the new methods defined. I think this is something >> we can address later as a working group. >> >> I don't understand why the "diagnostic server" material was added to >> this revision. I think it should be removed. If something like this >> is desired, it should be entirely separate. >> >> Bruce >> >> >> >> >> On Fri, Dec 26, 2008 at 5:13 PM, David A. Bryan <[email protected]> wrote: >>> Looking for objections, since we had consensus in the room in Minneapolis. >>> >>> Thanks for clarifying! >>> >>> David (as chair) >>> >>> On Fri, Dec 26, 2008 at 3:49 PM, Dan York <[email protected]> wrote: >>>> David, >>>> >>>> Are you expecting us to send messages to the list agreeing with this? Or >>>> are you taking the lack of *dissenting* messages as a sign of consensus? >>>> >>>> Dan >>>> >>>> P.S. I agree with this action, by the way, and did hum to adopt in the room >>>> in Minneapolis. >>>> >>>> On Dec 26, 2008, at 10:08 AM, David A. Bryan wrote: >>>> >>>>> In Minneapolis, there was a hum taken which indicated rough consensus >>>>> to move towards adopting the P2PSIP diagnostics draft as a working >>>>> group item. Since there were also a number of corrections/changes >>>>> requested, the chairs asked the authors to iterate the draft and post >>>>> it, and then we would verify the consensus on list. >>>>> >>>>> The authors posted the revisions to the draft a few weeks ago: >>>>> >>>>> http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-04.txt >>>>> >>>>> I'd like to ask for list consensus to verify the consensus from the >>>>> meeting in favor of adopting this work as a WG item. >>>>> >>>>> David (as chair) >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>>> -- >>>> Dan York, CISSP, Director of Emerging Communication Technology >>>> Office of the CTO Voxeo Corporation [email protected] >>>> Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com >>>> Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com >>>> >>>> Build voice applications based on open standards. >>>> Find out how at http://www.voxeo.com/free >>>> >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> P2PSIP mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> _______________________________________________ >> P2PSIP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/p2psip >> >> >_______________________________________________ >P2PSIP mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
