On Wed, 24 Mar 2004, J-F C. (Jefsey) Morfin wrote:
> What you say makes the intented RFC also a Best Practice
> or an RFC for infromation?
The intended category as expressed by the chairs is Informational.
(btw, I clarified the applicability of this document by adding in the
introduction:)
<t>The purpose of this document is to give information about
important issues and considerations related to DNS operations with
IPv6; it is not meant to be a normative specification or standard for
IPv6 DNS.</t>
> > > | 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?
(This was in context of reverse DNS records.)
I was not sure whether you were objecting to the contents of this
section or not so I'm assuming you could be.. so..
I think all the main arguments have been fairly portrayed (in more
detail in other documents). If you believe otherwise, please raise a
specific objection.
> >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.
Please specify the exact paragraphs and issues where you're raising a
point, possibly giving some context, and let's see if we can flesh
these out. It's difficult if we don't understand each others'
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.
OK; I tried to fuel the thinking a bit:
<t>A problem with defining the clean-up process is that it is
difficult to ensure that a specific IP address and the corresponding
record are no longer being used. Considering the huge address space,
and the unlikelyhood of collision within 64 bits of the interface
identifiers, a process which would remove the record after no traffic
has been seen from a node in a period of time (e.g., a year) might be
one possible approach.</t>
> 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.
I've tried to keep these debates out of this document (in the
interests of not delaying it, and giving possibility to fully discuss
it in other documents), just summarizing the situation if applicable.
When concerned, one should check the references pointed at in the
paragraphs for more information.
Of course, in some cases (e.g., this janitorial process) there has not
been much formal work on that. It's unfortunate, but hopefully some
new documents, in the future could be kick-started in the future.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
