Subject: [DNA] CONSENSUS CALL : Document merges

From: Suresh Krishnan <[email-masked]>
Date: Thu, 15 Jun 2006 18:36:10 -0400

Hi Folks,
    At the last meeting in Dallas lot of concerns were raised about the
number of documents being produced by the WG. The Consensus was to
reduce the number of documents to keep related information together.
    The chairs have identified two possible merger scenarios and would
like to know the opinion of the working group regarding these two.

Option A:
=========
Combine
1) Detecting Network Attachment in IPv6 Networks (DNAv6)
and
2) Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery
(draft-ietf-dna-protocol-00 + draft-ietf-dna-tentative-00)

into one document.

Merge
3) Detecting Network Attachment in IPv6 - Best Current Practices for hosts
and
4) DNA with unmodified routers: Prefix list based approach
(draft-ietf-dna-hosts-03 + draft-ietf-dna-cpl-02)

into another document.

Option B:
=========

Merge all the above mentioned documents

* draft-ietf-dna-protocol-00
* draft-ietf-dna-tentative-00
* draft-ietf-dna-hosts-03
* draft-ietf-dna-cpl-02

into a single document.

This consensus call will last for two weeks and will end on the 29th of
June 2006. Please respond to the list whether you

* Prefer Option A
* Prefer Option B

If you do not have a preference and you are ok with either option,
please respond with "Don't care ". If we have consensus on the Don't
cares the chairs will make the decision.

Thanks
Suresh and Greg

---

From: Sathya Narayanan <[email-masked]>
Date: Fri, 23 Jun 2006 15:03:55 -0400

I prefer option A.

As I mentioned earlier, I think option A is the more practical option.

thanks,
Sathya

---

From: Brett Pentland <[email-masked]>
Date: Sat, 24 Jun 2006 09:24:21 +1000

Though it's more work, I think option B will make it easier for 
developers to find what they need.

Brett.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 23 Jun 2006 19:33:46 -0700

I also agree that option B is preferrable.

>Though it's more work, I think option B will make it easier for developers 
>to find what they need.
>
>Brett.

---

From: Thomas Narten <[email-masked]>
Date: Sat, 24 Jun 2006 10:22:25 +0000

> As I mentioned earlier, I think option A is the more practical

Can you clarify? Does more practical   mean "less work for the current
authors", or does it mean something else?

Personally, I think we should go the route that makes the most sense
for implementors who will be implementing from the RFCs, long after
this WG goes away. Even if this is somewhat more work for the WG. 

> > (draft-ietf-dna-hosts-03 + draft-ietf-dna-cpl-02)

IMO, there should be one single document that tells implementors what
to implement. I don't think it is helpful to have 2 different
documents giving guidanace on this point. 

> > * draft-ietf-dna-hosts-03

That would be my preference.

Thomasu

---

From: James Kempf <[email-masked]>
Date: Mon, 26 Jun 2006 08:43:14 -0700

I agree as well.

            jak

----- Original Message ----- 
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Friday, June 23, 2006 7:33 PM
Subject: Re: [DNA] CONSENSUS CALL : Document merges

---

From: [email-masked]
Date: Mon, 26 Jun 2006 09:55:09 -0700

Greg already asked this question once before and i said
my preference is option A. 

-mohan

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>ext Sathya Narayanan
>Sent: Friday, June 23, 2006 12:04 PM
>To: [email-masked]
>Cc: Dna; Suresh Krishnan (QB/EMC); Greg Daley; Jari Arkko
>> 1) Detecting Network Attachment in IPv6 Networks (DNAv6) and
>> 2) Tentative Options for Link-Layer Addresses in IPv6 Neighbour 
>> Discovery (draft-ietf-dna-protocol-00 + draft-ietf-dna-tentative-00)
>>
>> into one document.
>>
>> Merge
>> 3) Detecting Network Attachment in IPv6 - Best Current Practices for 
>> hosts and
>> This consensus call will last for two weeks and will end on the 29th 
>> of June 2006. Please respond to the list whether you
>>
>> * Prefer Option A
>> * Prefer Option B
>>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 29 Jun 2006 15:53:45 +0300

My personal preference is option B. (Just registering one
opinion; as an AD I'd be fine with other ways to merge the
documents too as long as the group agreed on one. Some
merging is indeed needed, however.)

--Jari

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 29 Jun 2006 15:40:07 +0200

Hi,

I prefer option B, I think it is easier for implementers and readers.

Nicolas

---

From: [email-masked]
Date: Thu, 29 Jun 2006 09:33:13 -0700

I read these drafts quite sometime back, so can't answer
this question myself.

If i have to implement the DNA protocol (draft-ietf-dna-protocol),
should i need to read the "contents" of all the other three drafts ?
Assume the reader is familiar with RFC 2461 which is the basic
one without which none of this would make sense. It is still not
clear to me how merging will speed up the process ? It will sure
slow down the review process because folks are normally good at
reviewing smaller documents.

-mohan

>ext Suresh Krishnan
>Sent: Thursday, June 15, 2006 3:36 PM
>To: Dna
>Cc: Suresh Krishnan (QB/EMC); Greg Daley; Jari Arkko
>Subject: [DNA] CONSENSUS CALL : Document merges
>Importance: High
>
>Hi Folks,
>    At the last meeting in Dallas lot of concerns were raised 
>about the number of documents being produced by the WG. The 
>Consensus was to reduce the number of documents to keep 
>related information together.
>    The chairs have identified two possible merger scenarios 
>and would like to know the opinion of the working group 
>regarding these two.
>
>
>Option A:
>=========
>Combine
>2) Tentative Options for Link-Layer Addresses in IPv6 
>Neighbour Discovery (draft-ietf-dna-protocol-00 + 
>draft-ietf-dna-tentative-00)
>
>into one document.
>
>Merge
>3) Detecting Network Attachment in IPv6 - Best Current 
>Practices for hosts and
>This consensus call will last for two weeks and will end on 
>the 29th of June 2006. Please respond to the list whether you
>
>* Prefer Option A
>* Prefer Option B
>
>If you do not have a preference and you are ok with either 
>option, please respond with "Don't care ". If we have 
>consensus on the Don't cares the chairs will make the decision.
>
>Thanks
>Suresh and Greg
>

---

From: Greg Daley <[email-masked]>
Date: Thu, 29 Jun 2006 14:02:41 -0400

Hi Mohan,

Just clarifying the current situation.  I don't want
to show any bias here, and it's at a fairly important
time of the consensus call, so please consider these
efforts as personal view only.

The host side of draft-ietf-dna-protocol directly relies
on CPL today, as required for backward compatibility with
unmodified routers.

Currently draft-ietf-dna-protocol also relies on
draft-ietf-dna-tentative, for interactions with routers
while a host is still optimistic.

draft-ietf-dna-cpl and draft-ietf-dna-hosts are tackling
different aspects of the same problem (host change detection
procedures, for unmodified networks).

It may be worth thinking about that Neighbour Discovery
itself contains both the host and router side information
in the same document.  This may inform peoples' opinions of
the benefits and drawbacks of such a scheme.

On the timeliness:

I agree that the document review will be longer.  In
our projected timelines, we have accounted for this,
to some extent (for either decision).

The point of choice in my guess is some expedition,
with a useful merger into two documents, or merger
into one document, which some people see as producing
a better document at the cost of potential time and
effort.

I hope this helps,

Greg