>>>>> On Tue, 22 Jun 2004 16:36:10 -0700,
>>>>> Bob Hinden <[EMAIL PROTECTED]> said:
>> This draft seems to adopt all the three approaches. Does this mean we
>> gave up on choosing a single particular approach for this purpose, or
>> even gave up on specifying one "default" approach? If so, then I
>> guess implementors will need to implement all the approaches (if it
>> needs implementation support) and/or operators will need to be
>> familiar with all possible approaches. Is my understanding correct?
> As described by Ralph and Dave, this was not the intent of this
> document. It was to provide a description of each approach and what the
> proponents for each approach thought their advantages and disadvantages were.
Okay, please see also my separate comment to Dave then.
>> 5. Section 3.1
>>
>> The configuration of DNS server address can be
>> performed manually by operator or automatically DHCPv6 client
>> running on the router.
>>
>> We need some clarification here to apply "dynamic *HOST* configuration
>> protocol" to the *router*. Yes, we did a similar usage for prefix
>> delegation (RFC3633) where a requesting *router* acts as a DHCPv6
>> client. In my understanding, however, that was a very special case
>> which can be considered as an exception. Even if we agree on using
>> the same logic again, I still believe this document should clarify the
>> point explicitly.
> I am not sure it's that useful at this point to try to define this in more
> detail. I think DHCPv6 would be fine for this, but there are many other
> ways this could be done including pushing/pulling a configuration file,
> network management protocols, CLI, and various proprietary methods. It
> would be good to revise the text to say there are a number of ways of doing
> this and not try to be very specific about which one is best.
I'm personally fine with this approach.
>> 6. Section 3.1.1 (Advantages of the RA option)
>>
>> The draft says
>>
>> 1) The RA option is a simple extension of existing ND/Autoconfig
>> mechanisms [3][4]. No new protocol mechanisms are needed and
>> extending an ND implementation to support this option should be
>> very simple.
>>
>> I don't think this is a valid statement. I'd rather remove this item,
>> or at least I'd heavily reword it to be fair.
> The intent of "no new protocol mechanisms" text was it was only necessary
> to define a new option, not change the ND protocol. Just the same as if
> one was to define a new DHCP option, the protocol mechanisms of the DHCP do
> not need to change. Does that help?
Yes, please then consider the fairness comment of mine.
>> Secondly, even if we decide to keep this advantage, I would reword
>> it without using the term "simple." I often feel people tend to use
>> this word when they just prefer something over some other things by
>> saying the former is "simpler" than the latter. At very least,
>> "simple" is a subjective term and is in general inappropriate in a
>> technical document. (The same comment could apply to all the other
>> occurrences of "simple" in the document, but I think this one here is
>> particular important since this is explicitly counted as an
>> "advantage" of a particular approach).
>>
>> Without having "simple", this statement would be just like this:
>>
>> 1) No new protocol mechanisms are needed.
> Well the extension seems simple enough to me :-)
As I said, you can safely think so, but it's hard to prove that (but I
won't too much insist on the appropriateness of the word "simple" if
the analysis in the next revision is fair enough).
>> Note that my first comment still holds.
>>
>> 7. Section 3.1.2 (Disadvantages of the RA option)
>>
>> I think this document should include another disadvantage of the RA
>> option: we need to configure the RDNSS addresses at least at one
>> router on every link where this information needs to be configured by
>> this mechanism.
> I think this is a reasonable comment. I happen to think this isn't a very
> significant issue as many routers may already have this information for
> their own use, but I agree it should be stated.
Okay.
>> If there is a hidden assumption that the router can be autoconfigured
>> with the RDNSS addresses by DHCPv6, see comment 5 above. Also, if we
>> take this approach, one of the advantages of the RA option may
>> plummet: address renumbering case, since DHCPv6 may not be able to
>> update the address quickly.
> Considering all of the other things that have to be updated in a router
> when one renumbers this doesn't seem like a significant problem to
> me. Much of the other information advertised by ND would also have to be
> updated.
I was talking about renumbering DNS servers addresses, not renumbering
routers or the whole (or most) part of the network. So I believe my
comment still stands.
>> With DHCPv6, we can mitigate the configuration load with multicast
>> routing. Of course, deploying multicast routing can be another
>> barrier of deployment, so there is a tradeoff.
> Right. Automatic renumbering is a big issue, even with DHCPv6 the
> addresses of the relay agent will need to be updated. I don't think
> renumbering is a very useful evaluation criteria.
I'm afraid we're talking about different things. See my comment above.
>> 11. From Section 3.2.3 (DHCPv6 Observations),
>>
>> I have an impression that the use of the RA option approach will be
>> very limited to "special applications". However, I have a different
>> impression from Section 3.1, which seems to say the RA option is a
>> generic solution.
>>
>> If my understanding is correct, then I hope the document will be
>> consistent on this. Even if it can't, then it should clarify why two
>> different opinions (which might even contradict with each other)
>> appear in this single document.
> I think it's better given the nature of the document to leave the
> observation sections to be what the "proponents" think makes a good overall
> solution. Maybe we need to say something about this in the introduction.
Okay. I can live with this as long as the introduction (or in some
appropriate part of the document) clarifies "the nature of the document".
>> 17. Normative References
>>
>> There are two work-in-progress documents:
>>
>> draft-jeong-dnsop-ipv6-dns-discovery-01.txt
>> draft-ohta-preconfigured-dns-01.txt
>>
>> Can't we have these as normative references unless these are published
>> as a stable document (presumably an RFC) before the publication of
>> this document or at least synchronously? Or is that actually the
>> plan?
> I think the normative issue only applies if this document is to become a
> BCP or Standard. If it's just informational, these can be listed as work
> in progress. Input from the chairs and/or ADs here would be useful.
I guess we've already fully discussed this point in this thread
(though I myself did not actively participated in it).
In any event, I personally do not have a particular opinion on the
dependency issue. I just wanted to point out a possible pitfall.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
