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

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

In line...

On 2007-10-04 04:34, Marc Blanchet wrote:
> 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.

I would suggest making the reference to RFC 3964 more specific, e.g.

2.7.  6to4

   2002::/16 are the 6to4 addresses [RFC4291][RFC3056].  The 6to4
   addresses may be advertised when the site is running a 6to4 relay or
   offering a 6to4 transit service.  However, the provider of this
   service should be aware of the implications of running such
   service[RFC3964], which includes some specific filtering rules for
   6to4. IPv4 addresses disallowed in 6to4 prefixes are listed
   in section 5.3.1 of [RFC3964].

In reference to Joe's list, I think it's out of place to mention
14/8, but in any case, if the list is incomplete, we need to fix
RFC 3964. Having a different list here would be confusing.

    Brian

> 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