Subject: RE: I-D Action:draft-ietf-6man-ipv6-subnet-model-00.txt

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 3 Jun 2008 16:50:26 -0400

Folks,

Could you please review this draft now that it's a 6man WG work item. So
far this version has taken care of comments on an earlier version that
the following folks reviewed. 

Suresh Krishnan
Jinmei Tatuya
Thomas Narten
Ralph Droms

Brian Carpenter sent us a private email on his review of this version.
We have taken care of his review as follows. 

At the end of section 2, the following paragraph has been changed from

[This case is analogous to the behavior
specified in the last paragraph of section 7.2.2 of
[RFC4861]: when address resolution fails, the host SHOULD
send an ICMPv6 Destination Unreachable indication as
specified in [RFC4861].  The specified behavior MAY be
extended to cover this case where address resolution cannot
be performed.]

to

[This case is specified in the last paragraph of section 4 of
[RFC4943]: when there is no route to destination, the host 
should send an ICMPv6 Destination Unreachable indication 
(for example, a locally delivered error message) as
specified in the Terminology section of [RFC4861].]

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, May 08, 2008 10:00 AM
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-6man-ipv6-subnet-model-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IPv6 Maintenance Working Group of the
IETF.

	Title           : IPv6 Subnet Model: the Relationship between
Links and Subnet Prefixes
	Author(s)       : H. Singh, et al.
	Filename        : draft-ietf-6man-ipv6-subnet-model-00.txt
	Pages           : 8
	Date            : 2008-05-08

IPv6 specifies a model of a subnet that is different than the IPv4
subnet model.  The subtlety of the differences has resulted in incorrect
implementations that do not interoperate.  This document spells out the
most important difference; that an IPv6 address isn't automatically
associated with an IPv6 on-link prefix.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-ipv6-subnet-model-00
.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 18 Jun 2008 16:57:05 -0400

Hi Hemant,
   I went through the document and it looks very good. There is just one 
thing I would like to comment on.

* The document claims to only clarify RFC4861 but it overreaches a bit. 
If you look at section 2 bullet 3, this lays out a NEW rule for a host 
to follow. This rule does not exist in RFC4861. I personally feel that 
this rule is intuitive and desirable, but it is certainly not backward 
compatible.

Cheers
Suresh

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Jun 2008 10:23:58 -0400

Suresh,

Thanks very much for the review. As per your feedback, here are the
changes we are making to the draft.

1. This sentence at the end of section 1 will be changed from:

[Finally, this document merely restates and clarifies [RFC4861].]

to  

[Finally, this document mainly restates and clarifies [RFC4861].]

2. Text of Bullet 3 in section 2 will change so that, as per your
request, we make it very explicit that this is a new rule. The old text
is shown below followed by new text.

       [On-link determination SHOULD NOT persist across IPv6 interface
       initializations.  Note that section 5.7 of [RFC4862] describes
       the use of stable storage for addresses acquired with stateless
       address autoconfiguration with a note that the Preferred and
       Valid Lifetimes must be retained if this approach is used.
       However no RFC suggests or recommends retaining the on-link
       prefixes.]

       [On-link determination SHOULD NOT persist across IPv6 interface
       initializations.  Note that this is a new rule specified by this
       document.  Further, section 5.7 of [RFC4862] describes the use of
       stable storage for addresses acquired with stateless address
       autoconfiguration with a note that the Preferred and Valid
       Lifetimes must be retained if this approach is used.  However no
       RFC suggests or recommends retaining the on-link prefixes.]

Regards.

Hemant

-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: Wednesday, June 18, 2008 4:57 PM
To: Hemant Singh (shemant)
Cc: [email-masked]; [email-masked]; Erik Nordmark;
[email-masked]
Subject: Re: I-D Action:draft-ietf-6man-ipv6-subnet-model-00.txt

Hi Hemant,

Cheers
Suresh

Hemant Singh (shemant) wrote:
> Folks,
> 
> Could you please review this draft now that it's a 6man WG work item. 
> So far this version has taken care of comments on an earlier version 
> that the following folks reviewed.
> 
> Suresh Krishnan
> Jinmei Tatuya
> Thomas Narten
> Ralph Droms
> 
> [This case is analogous to the behavior specified in the last 
> paragraph of section 7.2.2 of
> [RFC4861]: when address resolution fails, the host SHOULD send an 
> ICMPv6 Destination Unreachable indication as specified in [RFC4861].  
> The specified behavior MAY be extended to cover this case where 
> address resolution cannot be performed.]
> 
> to
> 
> [RFC4943]: when there is no route to destination, the host should send

> an ICMPv6 Destination Unreachable indication (for example, a locally 
> delivered error message) as specified in the Terminology section of 
> [RFC4861].]
> 
> 
> Thanks,
> 
> Hemant
>  
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of [email-masked]

> subnet model.  The subtlety of the differences has resulted in 
> incorrect implementations that do not interoperate.  This document 
> spells out the most important difference; that an IPv6 address isn't 
> automatically associated with an IPv6 on-link prefix.
>