Situation with draft-ietf-v6ops-v6onbydefault-03.txt

[Pekka Savola <pekkas@netcore.fi>]

Hi,

Alain wanted to raise the issue on what's up with 
draft-ietf-v6ops-v6onbydefault-03.txt.

At the IESG evaluation, two people raised a particular significant 
concern: the document should not be discussing solutions to these 
problems, if the solution has not been advanced in the appropriate WGs 
or other fora.  (It would be OK to just write about the problems, 
however.)

These seem to be two ways forward here:

 1) make sure work on the solutions is moving forward in the 
appropriate WGs, etc., and wait until publishing this document, with 
mentioning the solutions.  Drawback is that it may take long time to 
get these merged in the specification efforts.

 2) remove all the references to solutions in this document (I believe 
most of this was already done in -03 revision).  Drawback is that the 
document is much less useful as it is, and we still need to make sure 
these things actually get fixed.  Just describing problems doesn't 
really help all that much unless they're also fixed...

I've personally favoured 1).

Are there opinions on the approach?

For what it's worth, the status wrt solutions is as follows:
 - draft-gont-tcpm-tcp-soft-errors-01.txt (presented twice at TCPM WG 
meetings) describes the "soft error" behaviour, and is being actively 
debated at TCPM WG right now.  Generally, these has been positive 
reaction, except from a particular TCP purist (or two)  who seem to be 
resisting very strongly making any TCP modifications and instead 
advocating changing all the applications, etc., and requiring all 
kinds of evidence that this fix does not have ill effects.

 - this has been raportedly integrated with SCTP spec (by the SCTP 
authors) as well (I haven't checked), and mentioned to DCCP people. 
I haven't checked whether newest DCCP specs conform to this behaviour.

 - the onlink assumption is dependent on rfc2461bis (which is OK now) 
which is now at WGLC.

 - no work has been done on RFC3484 rule wrt. "unreachable 
destination", but this didn't seem needed as the removal of onlink 
assumption and ICMP soft errors should do the job.  Should there be 
some?

 - the VPN problem is an implementation issue; has it been reported to 
the vendor?  Is there a PR or some other identification tag for it?

 - the application transition document is already done so application 
robustness is OK.

So, in summary, it seems all of this is in a relatively good swing, 
except for the TCP modification which is facing some resistance. 
Unfortunately, that is probably the most important fix that should go 
in...

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings