RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt

Dave Thaler <dthaler@microsoft.com> Wed, 16 November 2011 11:50 UTC

Return-Path: <dthaler@microsoft.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E184021F9537 for <ipv6@ietfa.amsl.com>; Wed, 16 Nov 2011 03:50:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.587
X-Spam-Level:
X-Spam-Status: No, score=-110.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4vPQf3aiFS8 for <ipv6@ietfa.amsl.com>; Wed, 16 Nov 2011 03:50:21 -0800 (PST)
Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id DE50721F9544 for <ipv6@ietf.org>; Wed, 16 Nov 2011 03:50:19 -0800 (PST)
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 16 Nov 2011 03:50:19 -0800
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.1.355.3; Wed, 16 Nov 2011 03:50:19 -0800
Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.162]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0355.003; Wed, 16 Nov 2011 03:50:19 -0800
From: Dave Thaler <dthaler@microsoft.com>
To: 6man <ipv6@ietf.org>
Subject: RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt
Thread-Topic: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt
Thread-Index: AQHMnnyA8bHdVFCXiUyuTF/wKIyRo5WrAv2AgADytwCAA3L0cIAABdmw
Date: Wed, 16 Nov 2011 11:50:18 +0000
Message-ID: <9B57C850BB53634CACEC56EF4853FF653B309227@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
References: <4EB9D332.1040003@gmail.com> <81C461F1-C088-446A-892C-D8B233CF1EB7@nttv6.net> <4EC0491C.2050406@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.42]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2011 11:50:22 -0000

A marked-up version with my full comments in context can be found at
http://research.microsoft.com/~dthaler/draft-ietf-6man-rfc3484-revise-05.pdf

-Dave

> -----Original Message-----
> From: Dave Thaler
> Sent: Wednesday, November 16, 2011 7:49 PM
> To: 6man
> Cc: 'Brian E Carpenter'; Arifumi Matsumoto
> Subject: RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt
> 
> I have read and reviewed -05.
> 
> The document is a good start, but I have some issues with it currently.
> 
> Summary of substantial technical issues:
> 
> 1) In the updated prefix policy table, the order of rows is ok, but the
> precedence values are a major problem that would make it difficult if not
> impossible for us to implement/deploy the current draft. Please change to
> preserve the precedence values to be the same as in RFC 3484 except where
> a change is actually required.
> For example, ::1/128 should remain 50. Teredo should be 5, which is what
> has
> been deployed for many years now.   The operational issues center around
> ways
> to configure nodes with additional rules.   Ones already exist in some
> implementations
> and changing the values means that you can't push a rule out to a host
> unless you
> know it's a new vs old host.   Avoiding gratuitous changes means you can
> have
> one new-row pushed out to all hosts.   I personally consider this a
> showstopper
> for the draft.
> 
> 2) The current Rule 5.1 text
> "Rule 5.1: Use an address assigned by the selected next-hop."
> is problematic for two reasons:
>    i) Next-hops don't assign addresses, they advertise prefixes. Addresses are
>       assigned by the hosts themselves (in SLAAC) or by DHCP servers.
>       It should say something like "Prefer addresses in a prefix advertised by
> the next-hop"
>    ii) nowhere does the doc have text about whether a host must remember
>      who it got an on-link prefix from. RFC 4861 section 5 doesn't say it does.
>      RFC 4191 section 3 doesn't either. And this document has no section
>      that's similar to either one. Note that 4191 section 3 defines some as
>      being optional. Is this one optional or required?    I don't have a concern
>      either way, my concern is that the document doesn't say anything like
>      what it ought to cover in order to enable this rule.
> 
> Summary of editorial issues:
> 
> 1) As Brian pointed out one instance of, many places in the doc say what
> _could_ be done.  A standards track document needs to instead specify what
> _is_ done.
> 
> 2) Several informative references (that are drafts not RFCs) are used in text
> in
> normative ways.   Rather than making them be normative references, the
> text
> should be updated so that the use is clearly informative.
> 
> 3) A number of grammar issues.  Parts of Appendix B are rather hard to read
> for instance.  Perhaps it can just be deleted.
> 
> 
> Also I prefer the Updates (not Obsoletes) option, where the document
> specifies the deltas.   This is the current approach in the doc.
> 
> -Dave
> 
> > -----Original Message-----
> > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
> > Brian E Carpenter
> > Sent: Monday, November 14, 2011 6:48 AM
> > To: Arifumi Matsumoto
> > Cc: 6man
> > Subject: Re: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt
> >
> > > So, which of update or replace do you prefer ?
> >
> > Hmm. If we want to go quickly, an update that makes it easy for the
> > implementer to find the changes is better.
> >
> > Regards
> >    Brian
> >
> > On 2011-11-13 21:19, Arifumi Matsumoto wrote:
> > > Brian,
> > >
> > > thank you for your comments.
> > >
> > > On 2011/11/09, at 10:11, Brian E Carpenter wrote:
> > >
> > >> Hi,
> > >>
> > >> I think I'm going to make myself unpopular.
> > >>
> > >> Reading this document as a proposed standard, I think it will confuse
> the
> > reader.
> > >> I think that what we actually need is a 100% replacement of RFC 3484,
> > >> that can be read on its own.
> > >>
> > >> (We've been here before - the same argument is why we ended up
> doing
> > >> 3697bis.)
> > >>
> > >> If that is not done, I would suggest reorganising the text so that
> > >> (after a short Introduction) the reader finds:
> > >>
> > >> - firstly, a complete but concise statement of the normative changes
> > >> made to 3484  (such as section 2.1.5, and the new rules 5.1 and 9)
> > >>
> > >> - secondly, the explanations (such as sections 2.1.1-2.1.4).
> > >>
> > >> An implementer would only need to read the first part.
> > >
> > > This document had started as an update, because there was not so many
> > > things to update at first.
> > >
> > > As the document gets older, it got a bit bigger than I had expected.
> > >
> > > So, which of update or replace do you prefer ?
> > >
> > >> Trivia:
> > >>
> > >> Needs a header: Updates: 3484 (if approved)
> > >>
> > >>> 4.  IANA Considerations
> > >>>
> > >>>   Address type number for the policy table may have to be assigned by
> > >>>   IANA.
> > >> You can't say "may", you have to tell IANA exactly what to do in which
> > registry.
> > >
> > > Thanks !
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------