> Question for you NOC folks: when I report a problem, how much information > do you need? > For instance, I can say, ³Jabber failed.² > Or I can say, ³Jabber failed, here¹s my account.² > Or I can say, ³Here¹s a packet capture of trying to log into Jabber.² > But I don¹t want to provide more data than is useful. maximize data to allow to reproduce, but minimize PII. and if it is a well-known problem, e.g. skype, just X on platform Y does not work over ssid Z on date D. > Also, I don¹t know of any reporting on tickets like that. i think it would be nice if the ipv6 folk put in a little work here. maybe a wiki or whetever. please remember the noc folk on whom you are leaning are also unpaid volunteers. though we can put up a service (wiki or whatever) for you to use. > That kind of reporting would help us understand what still breaks on > IPv6-only or NAT64, and therefore how much pain it would be to make > one of those configurations be the default SSID. when a significant number of folk have actually tested, reported, and problems have been fixed sufficiently that the masses can get their MTV, let's talk mucking with the default network. > Would you folks give us some guidance on how to report issues, and > provide some reports, so we can have metrics telling us when we can > reasonably make changes? we have a ticket system and there is a way for you to generate tickets. but, imiho, tickets are not a great way to document the space. when you have a particular issue and are working on getting it fixed, tickets are great. but they's an unintelligible mess for tryingt to make a matrix of whether X works on network flavor Y with platform Z. > I understand the primary requirement for the IETF network is to let > people get their work done. So I¹m trying to figure out how to list > stuff that wouldn't work, so we can clear the way, so we don't > interfere with work. solid plan randy