Wrong thread, so I changed the subject.. Thanks for feedback; most of these seem to be caused by confusion that this would be a normative reference for implementors, managers and users; it is not. Maybe this needs to be strengthened in the Introduction..
Dear Pekka, as explained in my response to Francis, I do not comment the solutions, but as requested, the final text. And from a non involved but - I suppose - informed (I dont say competent) user.
What you say makes the intented RFC also a Best Practice or an RFC for infromation?
On Tue, 23 Mar 2004, J-F C. (Jefsey) Morfin wrote: This document represent current practice and understanding, not what might be or could be, (or what some others may hope will never be).
Thus I do not see a need to make changes here.
Accepted in the context above, if this "current practice and understanding" is mentionned. We still are in RFC 882 perspective rather than 883.
> | 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?
Note that the latter paragraph only describes that there has been debate about a subject, and states why this is a bad idea. If you think this is insufficient (and as there was some other pushback about changes), could you propose text you'd like to see changed (and how)?
As indicated in the response to Francis, my only concern is to avoid legitimising a wrong debate. There is debate. I think the debate is of real interest but that its first problem is to be presented in wrong terms.
I only suggest not to feed the wrong presentation and to help the real debate in putting it into its real perspective (i.e. not "from transport" but "in relation to transport".
> | "should" ? Should it not be possible to enforce this in writing codes > | voiding the concerned RRs if entered ?
Enforcing anything is beyond the scope of this document. It may give hints to implementers and the DNS spec writers, but that's all about it.
Agreed. This is why I suggest to be more specific about what implementer and spec writers could do to avoid an operations management (the purpose of this RFC) bug.
> | it seems inadequate to publish a comprehensive document with such a > | lack of consensus. Or to mention that as a point for a further RFC.
This subject is out of scope for this work, and is being solved separately. I think the question is which is better, publishing a document describing current understanding or waiting for long time to get consensus so that every issue has already been decided. For informational purposes, I think publishing (even if still raw) results is appropriate.
Full agreement in the perspective quoted on top.
> | wording seems unadequate for an RFC? Should it not be afirmative? > | Saying "there are diferent positions" : as a developper or a > | manager, I cannot make any sense out of this?
That's as it should be, in this case: this document is not trying to be *normative* reference on how things must be done, but to point out different arguments (if there are more than one) to give the reader the opportunity to judge on his own.
Accepted in the pespective above with the provision that this document is to be of use. A normative RFC is for developpers. An information RFC is - as you said - for others to think. Not detailing all the positions with their con and pros does not really help?
> 7.3 DDNS with Stateless Address Autoconfiguration > > Dynamic DNS with SLAAC is a bit complicated, but manageable with a > rather low form of security with some implementation. > > | quite subjective, unprecise and uninformative "a bit", "rather low"?
Yes, but this is explained at more length below. Other suggestions? Note that anything is likely to be subjective here :-)
I just mean that the wording lead to think it is subjective. This is a real working document with a lof of efforts behind.
It is intended to point out that attacking is eas(y/ier) if you just use IP addresses as a form of authentication. I agree that this wording should be better. Maybe along the lines of:
. In this case the attacker would only need to be able to spoof the source address to be able to hijack a DDNS-managed name -- compared to obtaining breaking cryptographic keys if a more secure form of DDNS management was used.
Perfect! I am sure that all my points could be easily adressed this way, documenting the reason of the comments.
> | "some" ? Janitorial ? What is the process to specifically carry ? > | I should understand what I am to develop.
This document is not meant to be normative, so the details are left as an exercise of the reader; I don't think it is useful to try to specify the exact steps here, but if you have suggestions what to add here...?
Some hints at what kind of janitorial works is right now discussed.
As a general point, to be more specific. The texte often says there are opposed positions or different propositions, but does not document them, so it does not fuel the thinking.
The real problem for an non specialist is to know about _all_ what is discussed in an IETF environment where there is no state of the art/debate summary.
. dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
