ietf
[Top] [All Lists]

Re: IPv4 outage at next IETF in Chicago

2017-01-26 11:03:07
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