RE: AD Evaluation: draft-ietf-6man-multicast-addr-arch-update

<mohamed.boucadair@orange.com> Tue, 17 June 2014 11:39 UTC

From: mohamed.boucadair@orange.com
To: Brian Haberman <brian@innovationslab.net>, "draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org" <draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org>, 6man WG <ipv6@ietf.org>
Subject: RE: AD Evaluation: draft-ietf-6man-multicast-addr-arch-update
Thread-Topic: AD Evaluation: draft-ietf-6man-multicast-addr-arch-update
Thread-Index: AQHPiYdkikjiHka2y0iRmzGZkoiRcZt1LKuA
Date: Tue, 17 Jun 2014 11:39:03 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933001838D@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <539F2781.60000@innovationslab.net>
In-Reply-To: <539F2781.60000@innovationslab.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/2bF-6CzHBSK8MT2HMSKk9swRp6E
Precedence: list

Hi Brian,

Thank you for the review. 

The editorial comments will be fixed in -05.

We fixed idnits issues except these two ones (that we don't think are issues):

* Lack of a disclaimer for pre-RFC5378 work:
    When we specify the explicit changes we quote text from documents
    older than 2008, and the new next is largely the same as the old
    one. We don't think we want to contact all authors about BCP78 rights.

* Missing Reference: 'ADDRARCH':
    This is not a missing reference. It is only here because we quote
    some text from a document which has this reference.

The new version will be available online soon.

Cheers,
Med 

>-----Message d'origine-----
>De : ipv6 [mailto:ipv6-bounces@ietf.org] De la part de Brian Haberman
>Envoyé : lundi 16 juin 2014 19:21
>À : draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org; 6man WG
>Objet : AD Evaluation: draft-ietf-6man-multicast-addr-arch-update
>
>All,
>     I have completed my AD Evaluation of
>draft-ietf-6man-multicast-addr-arch-update as a part of the publication
>process.  Please review these comments, discuss as necessary, and
>resolve them.  Once a revision is available that addresses these
>comments, the document can proceed to the next phase of the publication
>process (IETF Last Call).
>
>
>* Re-word the Abstract to remove explicit reference to the reserved bits
>location.  Something like "...by re-defining the reserved bits as
>generic..."
>
>* Section 1 - This document updates the IPv6 addressing architecture
>(not the multicast addressing architecture) to change the reserved bits
>to flag bits.
>
>* Sections 1 & 2 - If the text contains the actual offset of the bits
>being changed, the document needs to indicate what reference point is
>being used.  For example, RFC 4291 refers to "high-order bits" to
>indicate the point of reference.
>
>* Section 2
>
>1. What is the rationale for the use of the term "so-called" in
>reference to Embedded-RP?
>
>2. I would suggest specifying that ff1 directly maps to flgs in 4291 &
>3956.
>
>* There is quite a bit of redundancy between sections 2 & 4, but not
>information is contained in 2. I would suggest re-structuring these
>sections so that one contains the rationale for this change and the
>other contains the complete list of updates being made to the affected
>documents.
>
>* This may be nit-picky, but I would like to see the names listed in the
>Acknowledgements be completely spelled out.
>
>* idnits indicates issues that need to be addressed.
>
>
>Regards,
>Brian

AD Evaluation: draft-ietf-6man-multicast-addr-arc… Brian Haberman
RE: AD Evaluation: draft-ietf-6man-multicast-addr… mohamed.boucadair