Lee, This strongly suggests that it would be a good idea for the NOC to have a web-based reporting form that specifically asks for (or, when possible, automagically fills in) whatever information is needed to cause a ticket to make sense and be useful. I'd hate to see such a thing replace the email options -- if nothing else, if one is trying to work around a problem but still report it, it may be faster to get an email message out and that speed may make the difference between a useful "something is wrong' heads-up report and silence -- but the odds of many of us spontaneously remembering a list of things that should be included in a report are not very high. best, john --On Thursday, January 26, 2017 11:12 -0500 Lee Howard <lee@xxxxxxxxxx> wrote: > >> >> An IPv6-only SSID already exists -- it's even currently called >> "ietf-v6ONLY" (For users wanting pure IPv6 ). > > > I spend as much time as I can on that one, and have sent email > to the NOC about things that break. For me, Jabber was a key > one that kept me from staying there; I believe Google was > unable to authenticate my Jabber account over IPv6. > The unavailability of Github is another recurring problem, > when so many WGs store stuff there. > >> There is also >> "ietf-nat64" (IPv6 stack with NAT64). > > So I end up spending a lot of time on this one. Mostly works. > > 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. > > Also, I don¹t know of any reporting on tickets like that. > 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. It would also help us focus pressure on the apps and > tools that break in such scenarios; if my Jabber problem turns > out to be authentication at Google, I could find somebody > there who might be able to help. Or if it¹s my client, I > might be able to find (or fund) the needed update. > > 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? > > >> This information is regularly >> communicated -- for example: >> Jim's email "[97all] IETF 97 Network Information Seoul, >> South Korea" the IETF NOC reports - e.g: for IETF97 - >> https://www.ietf.org/proceedings/97/slides/slides-97-ietf-ses >> sa-noc-report -00.pdf >> , Slide 6 shows associations per SSID. 3 on ietf-v6ONLY and >> 19 on ietf-nat64. > > Thanks for that pointer; these reports often go by too fast. > I find it fascinating that ietf-legacy is significantly more > popular than ietf. Why is that? > >> As someone who's been involved in the NOC, I'm slightly >> irritated by the "You should really supply X, everyone wants >> it, how do I get this done?!" tone when it's been available >> (and not very widely used) for many years, and that a few >> seconds looking would have shown this. > > Fair enough, and 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. >...