Subject: 6MAN WG Last Call: <draft-ietf-6man-impatient-nud-02.txt>

From: Bob Hinden <[email-masked]>
Date: Tue, 4 Sep 2012 10:28:24 -0700

All,

This message starts a two week 6MAN Working Group on advancing:

	Title           : Neighbor Unreachability Detection is too impatient
	Author(s)       : Erik Nordmark
                          Igor Gashinsky
	Filename        : draft-ietf-6man-impatient-nud-02.txt
	Pages           : 8
	Date            : 2012-07-31

        http://tools.ietf.org/html/draft-ietf-6man-impatient-nud-02

as Proposed Standard.  Substantive comments and statements of support for advancing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on September 18, 2012.

Regards,
Ole Troan & Bob Hinden

---

From: joel jaeggli <[email-masked]>
Date: Thu, 06 Sep 2012 19:12:19 -0700

I think this is an important change, and I think our work on the problem 
side of the things underscores that.

As a contributor I am in favor of advancing this document.

That said I'd also like to hear from implementers that this is a 
reasonable fix with few if any negative consequences (something I 
believe to be the case).

joel

On 9/4/12 10:28 AM, Bob Hinden wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Randy Bush <[email-masked]>
Date: Fri, 07 Sep 2012 19:27:32 +0900

have read.  support.

randy

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sun, 9 Sep 2012 21:43:48 +0000

I support this document - it's important work and the document is really close to ship to the IESG. 

I thought this document should be on Standards Track but the document does not say anything about the Intended Status of the document.  Please fix that so that document includes Intended Status.  Additionally, if the document is on Standards Track, do we have at least one implementation of the protocol changes covered in the document?  Or the protocol changes are deemed minor and one does not need at least one implementation? 

Comments included below.

COMMENTS:

1.  In the first paragraph of the Protocol Update section, please replace "route" by "router".  At least all of RFC 4861 works with a default router not a default route.

2. I think the following text in the Protocol Update section can be removed because the text is redundant with RFC 4861.

[The UNREACHABLE state is conceptual and not a required part of this
specification.  A node merely needs to satisfy the externally
observable behavior of this specification.]

Editorial comments:

1. In the first paragraph of the Introduction section, please add a space between the two words shown below.

[reachable.The].

2. In the Protocol Update section, change

"Cache Entry as any time"

to 

"Cache Entry at any time"

In the same section change

"no IPv6 packets"

To

"no IPv6 packet"

3. In the Example Algorithm section, do we need to change

"An Implementation"

to

"An implementation"?

4. In the Security Considerations section, "belived" is misspelled.

Regards,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Tuesday, September 04, 2012 1:28 PM
To: [email-masked] Mailing List
Cc: Bob Hinden
Subject: 6MAN WG Last Call: <draft-ietf-6man-impatient-nud-02.txt>

All,

Regards,
Ole Troan & Bob Hinden

---

From: "George, Wes" <[email-masked]>
Date: Mon, 10 Sep 2012 13:55:07 -0400

Read and support.

Thanks,

Wes

> as Proposed Standard.  Substantive comments and statements of support
> for advancing this document should be directed to the mailing list.
> Editorial suggestions can be sent to the authors.  This last call will
> end on September 18, 2012.
>
> Regards,
> Ole Troan & Bob Hinden
>
>

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Tina TSOU <[email-masked]>
Date: Fri, 14 Sep 2012 05:31:25 +0000

Here u go.

Tina

On Sep 13, 2012, at 9:58 PM, "Bob Hinden" <[email-masked]> wrote:

> Tina,
> 
> Please copy the w.g. mailing list when you comment on drafts in w.g. last call.  It's good that the whole working group sees the comments and discussion.
> 
> Thanks,
> Bob
> 
> On Sep 14, 2012, at 1:50 AM, Tina TSOU wrote:
> 
>> Hi Erik and Igor,
>> 
>> The draft is well explained in regards to the case when there is no alternative default router in the lest of default routers.
>> 
>> I wanted some clarification in the content below:
>> 
>> In the draft,
>> The recommended behavior is to have 5 attempts, with timing spacing
>>  of 0 (initial request), 1 second later, 3 seconds later, then 9, and
>>  then 27, and switch to UNREACHABLE after 3 transmissions, which
>>  represents:-------after the initial request, we transmit a packet after 1 sec, then another after 3 seconds, then another after 9 seconds and finally after 27 secs right?
>> 
>>     MAX_UNICAST_SOLICIT=5----This would imply 5 attempts?
>> 
>>     RETRANS_TIMER=1 (default)
>> 
>>     BACKOFF_MULTIPLE=3
>> 
>>     MARK_UNREACHABLE=3------Do we mark it unreachable after 9 secs OR 4 secs 0r 27 secs?
>> After marking unreachable, multicast NS will be send instead of Unicast NS right?
>> 
>> Since there will be 5 attempts, would it imply it will wait 27 seconds before declaring it unreachable?
>> 
>> I look forward hearing from you.
>> 
>> Tina
>> 
>> On Sep 10, 2012, at 10:55 AM, "George, Wes" <[email-masked]> wrote:
>> 
>>> Read and support.
>>> 
>>> Thanks,
>>> 
>>> Wes
>>> 
>>>