[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D ACTION:draft-ietf-v6ops-rfc3330-for-ipv6-01.txt

Le 07-10-03 à 17:09, Niall O'Reilly a écrit :


On 3 Oct 2007, at 14:13, Marc Blanchet wrote:
I understand your comment. However, the issues you are raising (as well as others) related to 6to4 are already in the 6to4 security RFC (RFC3964), which is already referenced in the 6to4 paragraph. Therefore, I would suggest not to add any additional text in order to not repeat what is already throughly discussed in RFC3964. 
	I understand your response, and have some sympathy with your point  
of view.

	I see two possible goals here: "communication" and  
"documentation".  I'm not
	sure whether both are intended goals of the document being  
drafted.  I think

	they should be.


	Repetition is a nuisance in documentation, as it involves parallel  
maintenance.
	OTOH, appropriate repetition is useful in communication, as it  
helps underline

	the message.


	My sense of the purpose of this document is that its readers ought  
to be
	adequately or even compellingly guided towards doing "the right  
thing".  What
	prompted me to comment as I did was that, in reading it, I didn't  
quite find

	the kind of guidance I was looking for.

I agree completly on the principle. If you refer to the first  
versions of the document, that was the intent and I covered more  
stuff around this to help people do the right thing concerning  
routing policies. Actually, the first title of the document was "IPv6  
routing policies guidelines". But there were people concerned about  
that direction. Therefore, it was decided to do something similar to  
RFC3330, which roughly documents the special IPv6 addresses with very  
few if any info on routing policies. that was the compromise to get  
the document with concensus. Therefore, I'm trying to stick to the  
guidance that was previously agreed on the scope/direction of the  
document , which is about near zero reference to routing policies.

summary: I agree with your comment, but to my knowledge, this is not  
the direction the wg wanted the document to have.

Marc.



	I'll read it again a couple of times, and consider whether I was  
simply in

	unreceptive form whenever I read it before.


	Best regards,

	Niall O'Reilly
	University College Dublin IT Services

	PGP key ID: AE995ED9 (see www.pgp.net)
	Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9




-----
IPv6 book: Migrating to IPv6, Wiley, 2006, http://www.ipv6book.ca