[DNA] Document merger: next steps.

[Greg Daley <gregd@research.panasonic.com>]

Dear WG,

I've looked through the documents and it looks
like draft-ietf-dna-protocol-01 will make a good basis
for the document, with the revisions proposed by
JinHyeock, to the host's change detection procedures.


So while most of the document will have to be edited
to ensure consistency between original and externally
sourced content, certain sections will have limited
disruption.

Particularly, inspection of draft-ietf-dna-cpl-02
indicates only one subsection which refers to
router configuration variables:

section 3.1, which refers to safe delays for
CPL generation (MIN_DELAY_BETWEEN_RAS, etc).

Similarly draft-ietf-dna-hosts-03.txt refers to
router configurations only a few times:

In section 3.1, it describes justification of
why DNA is performed (restating goals from RFC4135),
regarding routers leaving prefixes out of
advertisements.

Sections 4.2.1, 5.4 and 5.6 make passing reference
to the RFC 3775 Advertisement Interval Option.
Given that CPL relies on underlying link-indications,
this is not necessary to use in the combined document.

Section 6.2 discusses inconsistencies between routers
on the same link in their configurations.  This is
probably useful to retain as a warning.


As such the descriptions of the DNA host algorithm
can be merged into that from draft-ietf-dna-protocol
without introducing further relationships between
host and router text in the combined document.

One possible exception if Tentative Options.

The existing Tentative Options document is divided
into host and router sections already, with the
host and router components being largely independent.

The remaining issues for tentative options are that
the security considerations (section 5) allow the
router to make assumptions of the router solicitation
intervals from the host, and appendix C describes
modified procedures which ignore neighbour cache entries.

SUGGESTED ACTIONS:


1.  Design the relationship between text sources for
     Host side operations (following JinHyeock's plan).
     (Subsection by subsection (not specific text)).

2.  Formalize the Table of Contents for the combined
     document.

3.  Merge (router side) Tentative Options into the
     (router side) protocol document.

4.  Identify if text from existing documents is close
     to what is needed for each subsection.

5.  Generate a task list of sub-sections which need
     (b) editing from existing sources
     (c) merger of multiple sources
     (d) complete rewrite
     (e) further consultation/issue resolution.

     I'm assuming that all sections need to be modified,
     and may then be placed in a category: (a) accepted text.


Once we have an idea of which class each subsection goes in,
we can make efforts to generate text for a new draft.

Does this make sense?

Greg