Re: Running code (Was: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt)

[Simon Hobson <[e-mail]>]

Manfredi (US), Albert E <[e-mail]> wrote:

> Which says, I have no peripherals configured which require IPv4

how do you know in advance that there are no peripherals that the user might want to connect to which are IPv4 only ?

> I have no old IPv4 PCs with which I'm sharing drives

how do you know that the user won't want to connect to an IPv4 only share ?

> I have access to one or more IPv6 default routers

describes pretty well every dual-protocol network)

> so I don't need to use IPv4 for anything.

So your user of a device on a dual-protocol network goes into whatever UI they have to find local devices (printers, file shares, etc). They didn't previously have any persistent IPv4 connections defined*, the network is dual-protocol so you have at least one default router for IPv6 - by your heuristics the user will not find any IPv4 only devices. So you have broken the network for them.

Using the administratively set flag model, they will not have a problem because (unless he's a twit) the admin won't have set this flag for this network.

* For whatever reason - it may be that this device is new to the network and so has no prior knowledge of the devices on it. Or may be a freshly imaged device which is effectively the same thing.


> A possible counterargument being, possibly, the flag creates errors, that would require troubleshooting.
> 
> True story. Years ago, when I was still watching and/or recording TV programs the old-fashioned way, my Philips recording device would sometimes fail to record the program I had set up. I tried updating its software, I was super careful to set it up recording sessions correctly, and yet, sporadically, no recording when I went to watch. Irritation!
> 
> So I had to do some research. Come to find out, even though the US Supreme Court had decided that time-shift recording is perfectly legal, a "do not copy" flag was still configured, in these recording devices. So, I called the engineer from the one station giving me this problem, and the nice guy on the other end had no idea they were transmitting this blasted flag. But, the problem did go away after that.
> 
> Lesson learned (for me, anyway): best to avoid flags that aren't really essential.

The lesson learned from this is that the flag is the right way to do it. The flag was incorrectly set causing a **hard** fault, it was diagnosed and unset, problem solved.

The alternative ? Your recorder makes guesses and indeterminately fails to record programs that it thinks (according to some obscure heuristics) shouldn't be copied. Harder to diagnose as it's a soft fault, and even harder to fix.

Had the station not turned the flag off, then your option to work around the misconfiguration would have been the same as if the heuristics model been used - you'd need to hack the recorder to disable the feature.