>>>>> On Sat, 29 May 2004 12:22:13 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
>>> Though I personally think the last sentence is too much in the scope
>>> of rfc2462bis. But I can live with either
>>>
>>> 1. do nothing on this in rfc2462bis,
>>> 2. add the above note without the "further" notice, or
>>> 3. add the above note with the "further" notice
>> I understand your reservations regarding the scope of the sentence, but
>> w.r.t. to the "default router issue" I think that especially the
>> "further notice" section will relieve us of some pain because it
>> clarifies that we really do want forwarding nodes to send RAs in the
>> majority of cases. So I would vote for 3.. However, we could try to
>> clarify this issue in another document (something like a BCP?), if we
>> feel that it's out of scope for 2462bis.
>>> Are you happy with the clarification (with or without the "further"
>>> notice")? What do others think?
>> Yes, the clarification looks very good and I really think that it is
>> necessary. I'm curious to hear the others' opinions where it should be
>> placed (in 2462bis or someplace else).
> There seems to be no strong opinion except yours ("another" Christian
> wanted to leave this to ND-proxy, but I think this is not necessarily
> related to ND-proxy as I pointed out in the response to him).
> So I'll add the proposed clarification with the "further notice" in
> the next revision of rfc2462bis. We can still change the wording or
> even remove the text if someone finds a significant problem in it or a
> better place to describe that in reviewing the revision.
On second thoughts, I now think the "further notice" should rather go
to rfc2461bis (ND updates). In fact, this particular point is only
related to router discovery. So the next revision of rfc2462bis will
only contain the shorter version of the note in Section 5.5.2:
Note that it is possible that there is no router on the link in this
sense but is a node that has the ability to forward packets. In
this case, hosts must be manually configured about the forwarding
node's address to be able to send packets off-link, since sending
router advertisements is the only mechanism to configure the default
router's address automatically.
We could even move this part to rfc2461bis, but I personally think
this minimal note makes sense to be here because this is a direct note
on the case of "no router in the link".
In any event, we'll able to reconsider the details on this upon the
new revision or last call cycles.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
