Dear Francis, I proposed comments as requested.
1. My point of view is the one of a user of the current TCP/IP technology,
not one of its designers. As a user I certainly consider first real life
aspects from ICANN, DARPA, Verisign, manuifacturers, WSIS, and
first of all from users feed backs.2. My contribution's interest is only to come from an informed user,
commenting the text (not the technicalities) as not being confusing. Its interest is not in commenting the technical solutions. I should
have shared in the debate. Its interest is that I did not shared in
the debate and I am not biased by the meanings you developed
and I read them as people who did not shared in the debate will
read them.At 10:50 24/03/04, Francis Dupont wrote:
| the meaning of the word "global" differs in American and in English. | the reference to RFC 2826 is inadequate. The reason why is that RFC 2826 | is for information, is ambiguous and over disputed. RFC 883 says the | same thing better - even if contradicted by RFC 882 at the time.
=> your ideas (to be polite) about RFC 2826 / ICANN ICP-3 are irrelevant.
Respectfully, I do not consider that your politeness about my comments has anything to do in here.
The text above is confusing because it revives here a controversy and opens a new one totally orthogonal to the matter. Whatever the root you use, the problems addressed in the proposed RFC will be the same.
The only reference which could be made would be to 882/883 the oppositions of wich are reduced by the globalization solutions as the ones discussed. Harping on 2826 is of no interest to the context, while using some general sentences of 883 would help the reader to understand this RFC is above this kind of outdated controversy.
At least this is my users point of view. But I certainly respect your faith as a member of whatever chapel.
However, there is some debate whether the addresses in Additional section could be selected or filtered using hints obtained from which transport was being used; this has some obvious problems because in many cases the transport protocol does not correlate with the requests, and because a "bad" answer is in a way worse than no answer at all (consider the case where the client is led to believe that a name received in the additional record does not have any AAAA records to begin with).
| this leads to accept a layer violation as a legitimate consideration. | the DNS is about resolving 0-Z strings into IP adresses. External issues | such as used protocols are orthogonal, except when a part of the | query - like for mail services and "MX". Phrasing should underline this?
=> I strongly disagree: glue, additional section, etc, are necessary in some contexts and have nearly always a real impact on performance: this is *not* a layer violation and the issue is real.
This is not my point. I do not comment the technical positions: I comment on the wording. The wording discuss what is a layer violation (to consider the DNS from a transport point of view) as if it was legitimate. An other wording would give the same result.
Saying "in relation to transport" rather than "from transport" would repect the independance between transport and DNS and achieving the same result. But I am speaking Franglish and I leave good wording to others.
Link-local addresses should never be published in DNS, because they have only local (to the connected link) significance [8].
| "should" ? Should it not be possible to enforce this in writing codes | voiding the concerned RRs if entered ?
=> this should be kept as an implementation choice. IMHO this is a bad idea to blindly enforce this...
Again, I do not comment the solution, I ask a question on the text. The should here is not used as saying that the technology should, but that the manager should. Unless this is a Best Practice, the text should say something like "confusion created by publication is such that Manager should care never to publish and designers could write code to prevent this from happening".
jfc
. dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
