I have a couple of comments on the draft:
- I think the draft explains the motivation of introducing the new
scope. It will also help understand the vague term of the
"Network-Specific" scope, or "defined automatically from the network
topology". I've checked the ML archive and understood
On 23/07/2013 20:14, Ralph Droms wrote:
> I have reviewed the document; in my opinion it is ready to be sent to the
> IESG.
>
> I suggest that RFC 6775 (6LoWPAN-ND) be mentioned in section 4 along with
> draft-ietf-6man-dad-proxy as a way in which "the scope of DAD may be extended
> to a set of
On 23/07/2013 18:32, JINMEI Tatuya / 神明達哉 wrote:
> At Tue, 23 Jul 2013 13:09:50 +1200,
> Brian E Carpenter wrote:
>
>>> I have one comment that may improve the clarity of the document: the
>>> latter half of Section 4 is not very understandable to me:
>>>
>>>There is one case in RFC 4862 that
As I do not attend meetings, perhaps someone at the meeting could ask the
author these questions:
1)
> 10 - discard the packet and, regardless of whether or not the
> packet's Destination Address was a multicast address, send an ICMP
> Parameter Problem, Code 2, message to the packet's Source Ad
I have reviewed the document; in my opinion it is ready to be sent to the IESG.
I suggest that RFC 6775 (6LoWPAN-ND) be mentioned in section 4 along with
draft-ietf-6man-dad-proxy as a way in which "the scope of DAD may be extended
to a set of links." For completeness, RFC 6775 could be cited a
