In this response, I'm also referring to the latest version of
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-dnsop-ipv6-dns-issues-05pre.txt
(the one whose MD5 hash value is 0f0dcc920186d1a01f923dd60aac168d).
Easy ones first:
>>>>> On Wed, 7 Apr 2004 11:38:34 +0300 (EEST),
>>>>> Pekka Savola <[EMAIL PROTECTED]> said:
>> 2. Section 2.2 (Privacy (RFC3041) Address)
(snip)
> Good point. Revised as follows:
> <t>Temporary addresses defined in <xref
> target="RFC3041">RFC3041</xref> (sometimes called "privacy addresses")
> use a random number as the interface identifier. Publishing DNS
> records relating to such addresses would defeat the purpose of the
> mechanism and is not recommended. If absolutely necessary, a mapping
> could be made to some non-identifiable name, as described in <xref
> target="RFC3041"/>.</t>
Forks for me. I'd also remove "RFC3041" from the section title:
2.2 Temporary Addresses
but this is not a strong opinion.
>> 4. Section 4.5 (Behaviour of Glue in Mixed IPv4/IPv6 Environments)
>>
>> (second paragraph)
(snip)
> Yes, the intent was "query name", as the additional length of the
> packet for other reasons was also discussed a bit. Possibly this
> would call for more text?
> <t>Consider the cases where the query name is so long, the
> number of he additional records (originated from "glue") is so high,
> or for other easons that the response must either be runcated (leading
> to a retry with TCP) or some of the additional data emoved from the
> reply. [...]
> I added "query name" there and "or for other reasons" -catchall, but
> if you have better ideas what to add here, I'm all ears :)
For me, adding "name" to "the query" is enough (in fact, I'm not sure
what "other reasons" are referring to). But again, it's not a strong
opinion and is up to you.
>> 5. Section 6 (Considerations about Forward DNS Updating)
>>
>> (second paragraph)
>> Typically forward DNS updates are more manageable than doing them in
>> the reverse DNS, because the updater can, typically, be assumed to
>> "own" a certain DNS name -- and we can create a form of security
>> association with the DNS name and the node allowed to update it to
>> point to a new address.
>>
>> (this is a mostly editorial comment) I think "security association" is
>> a misleading term here because it sounds like something related to
>> IPsec (but it seems to me that the original intention was more
>> generic). I guess the authors perhaps tried to express the intention
>> by adding "a form of" before "security association", but the text
>> could explicitly be clearer.
> Yes, this is the intent. I've changed "security association" to
> "security relationship" to make it clearer that the terms don't
> overlap :)
Okay.
>> 6. Section 7.5 (DDNS with Dynamic Prefix Delegation)
(snip)
> The wording "at the site where the prefixes are delegated" seems to be
> unclear. I've reworded it to "at the site where the prefixes are
> delegated to" to make it clearer. I've also tried to clarify the
> parentheses by spelling it out:
> 7.5 DDNS with Dynamic Prefix Delegation
> In cases where a prefix, instead of an address, is being used and
> updated, one should consider what is the location of the server where
> DDNS updates are made. That is, where the DNS server is located:
> 1. At the same organization as the prefix delegator.
> 2. At the site where the prefixes are delegated to.
> 3. Elsewhere, as specified by the delegated site; this is
> security-wise typically equivalent to the previous case.
> On one hand, securing the DDNS relationship for prefix delegation is
> simpler if DNS server and the prefix delegator are in the same
> administrative domain, and may be more difficult otherwise.
> On the other hand, if the DNS server resides where the prefixes are
> delegated to, it is easier to manage reverse DNS updates as they can
> be done within a single administrative entity. Similarly, then
> configuring the reverse DNS is typically simpler as well (e.g., if
> one wanted to insert a wildcard record).
The revised text basically looks okay except for one point: I'm not
sure about the rationale of the latter part of case 3: "this is
security-wise typically equivalent to the previous case."
>> 2. Section 6.2 (Dynamic DNS)
>>
>> (third paragraph)
>> for the hostname; the second must be configured explicitly unless one
>> chooses to trust the IP address -based authentication (not a good
>> idea);
>>
>> s/address -based/address-based/ ?
> I like how it is at the moment because it's 'IP address'-based rather
> than just address-based. But I've changed this as you say (two
> places) as I think this is rather equivalent in any case.
> (Same for section 7.3.)
Ah, I see. My comment actually came from consistency with other parts
("address-based" without "IP"), which I thought was natural notation.
If "address -based" was intentional, then I'm fine, though I
personally prefer "address-based". And, since the latest text matches
my preference, I'm just happy with it.
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
