Re: [v6ops] Barry Leiba's Discuss on draft-ietf-v6ops-nd-cache-init-04: (with DISCUSS and COMMENT)

[Barry Leiba <[e-mail]>]

> Thanks for reviewing the document so quickly!

And thanks for the quick reply, Jen, and for addressing all my comments.

For the DISCUSS bit:

> > This is a very clear document, and this DISCUSS is literally that: a discussion
> > I’d like to have before the IESG approves it.  My first thought was that this
> > document reads more like a Standards Track Applicability Statement than an
> > Informational document... but then there’s the 6man-grand “companion” that’s
> > Standards Track.  And what I don’t understand is what the relationship is
> > between this document and that one.  Why does this document exist?  Why isn’t
> > it all in 6man-grand, and what’s the reason to be publishing two separate RFCs
> > for this issue?  Neither the document nor the shepherd writeup explain that.
>
> Oh..That's been discussed a number of times at v6ops@ and 6man@ meetings.
> V6Ops WG consensus is that the problem statement shall belong to v6ops
> document, hence we have two separate drafts.
> (Actually I've just asked Warren to delay the telechat on this one, so
> both drafts can be reviewed by IESG together).
>
> Merging both of them into one 6man doc would simplify things, I agree.
> On the other hand the value of the -nd-cache-init as a separate one is
> that it discusses various approaches to solve the issue,
> and some of those approaches do not require any protocol changes, so
> they are more in scope of v6ops than 6man.

I understand the issue of which working group works on which parts,
but I do think that things can happen separately at earlier draft
levels, but the documents could be merged at a later point, before the
two working groups finish with them.  That v6ops is done with this
part already... makes it easy to transfer this finished piece to 6man
for inclusion in the other.  I'll discuss this with Warren and Erik,
and we'll collectively figure out what we think is best.  If we think
we should do a merge, we'll make a proposal to the two WGs.  (And to
be clear, I'm looking to make it easier for the reader to have the
relevant information in one place, without the reader's having to be
aware of the particular WG structure, charters, and scope.)

Barry