Re: [Fwd: draft-ietf-v6ops-onlinkassumption and draft-ietf-v6ops-v6onbydefault]

[Pekka Savola <pekkas@netcore.fi>]

On Sat, 9 Apr 2005, Fred Baker wrote:
> So 2461bis has not even been submitted to the ADs (2462bis has been submitted 
> and sent back for revision). Your assertion is that at least part of the 
> problem is that 2461bis doesn't contain a discussion of why a certain change 
> was made. Well, would it be worthwhile to put that discussion into 2461bis, 
> perhaps in an appendix? Or are there other reasons to publish specifically 
> this document?

IMHO, the description is too long to be contained in the appendix. 
However, I do think that 2461bis appendix should mention that the 
assumption was removed and refer to this document.

I think it is important to document this kind of background, so that 
vendors realize why they should be removing the onlink assumption 
(when updating their 2461 implementation to 2461bis they might not 
bother or even notice it otherwise).  A document like this also serves 
as a way to document the arguments if someone later on brings this up 
again.

But see below.

> As to the following, yes, the 3484 comment might go in a separate document 
> and then refocus v6onbydefault to the second topic if the remainder of the 
> first part is OBE. I'm not sure the tense change in on-link-assumption is 
> worth the effort. I would focus on publishing it or not publishing it - 
> unless someone else in the WG has a different perspective.

I believe it is useful to have a document which provides brief 
discussion / pointers as well (first category).  I don't have strong 
preference whether onlink-assumption could be covered in this 
document, not a separate document.  But it seems to me that the log of 
major changes / issues that v6ops has brought up should be described 
somewhere.

> > Those last 2 sections are highlighting general deployment problems, 
> > not something special for v6 on by default.
> >
> > I can be convinced that if we put the issue with RFC3483 aside, the 
> > first part is now largely obe. Maybe we could re-focus the id on 
> > this second part if the wg thinks there is value here...

As above, I think there is value in also describing the background 
and/or providing points to issues which have been fixed or are in the 
process of being fixed.  This could be used by a user with an older 
implementation so see whether he's experiencing any of the issues 
described in the document.

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