Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

"Bernie Volz (volz)" <volz@cisco.com> Tue, 27 June 2017 23:23 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F7D126B7F for <dhcwg@ietfa.amsl.com>; Tue, 27 Jun 2017 16:23:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPcJBF2h_oG1 for <dhcwg@ietfa.amsl.com>; Tue, 27 Jun 2017 16:23:51 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ADF91201FA for <dhcwg@ietf.org>; Tue, 27 Jun 2017 16:23:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5592; q=dns/txt; s=iport; t=1498605831; x=1499815431; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9ZyhqM3BQKXNbqHEdUdBy3vkSYzjIsomnChB9BzEdvU=; b=FFRTjwP6af8jQVM5RhtxJNmow7hDZDzC9b7GV8gL7ag9j9ZG/tlnNw36 w/XMQWin2MW5NHn7n65cB5pqL4AvbHqNCsYFTmKZWaEJXgwvbpwG4l4PM bnv3TCH8nopHENdseAG+2aI6MJYrHojsmhZWPDIx1yhPKmAZLBWEoaRr+ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAQB06FJZ/5RdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1hjgQ4Hg2WKGZFGIoMkklaCESELhXACGoJpPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUZAQEBAgEBASEROgsQAgEGAhoCJgICAiULFRACBA4FiigIEJMinWKCJotdA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4IchS0rC4JugTyDCyMXgnwwgjEBBJ5?= =?us-ascii?q?vApNpggqQCokri3gBHziBCnQVSRIBhQqBdnaGXoExgQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.40,272,1496102400"; d="scan'208";a="266227131"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2017 23:23:50 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v5RNNoNK015686 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Jun 2017 23:23:50 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 27 Jun 2017 18:23:49 -0500
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Tue, 27 Jun 2017 18:23:49 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: =?utf-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
CC: "dhcwg@ietf.org" <dhcwg@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017
Thread-Index: AdLI0aZmS0Xgn7D6S1m3YZ8hZorkbQLWe7cAAIVlReABPEJZgAKF0ckgAGu0AYAACFfvgACNW58A///BWQCAAEkOAP//zF+A//gVIMD/66epAAUqtWAAAA4C24A=
Date: Tue, 27 Jun 2017 23:23:49 +0000
Message-ID: <44C31F53-9D69-4110-BEB6-65AE902EB2B8@cisco.com>
References: <8418750467ae490ea50e342380a565be@XCH-ALN-003.cisco.com> <CAJE_bqcMLz7JBaSA2h6_xiB3AyxQzkMGfL87WeqKzwxKoSeD-w@mail.gmail.com> <67c761541b674041ba5a2eb0b9ea41fa@XCH-ALN-003.cisco.com> <CAJE_bqeBg-va5zr=4HNrecECg_mmGpWECAc8V5UL0ckhHnJcNQ@mail.gmail.com> <7f897317e79e4576bebc772c45edb703@XCH-ALN-003.cisco.com> <CAJE_bqd72=wKwe3_i3=rArJys1eWLizVdn_q+Dz9yaHFouP_WA@mail.gmail.com> <3227281E-1FC2-448F-A9D2-9E7603A24E15@cisco.com> <m2o9tjrhfn.wl%jinmei.tatuya@gmail.com> <F0056821-DF5B-400E-ABAC-88BCA0EF68C7@cisco.com> <CAOSSMjWMJt1-qJM35kk3Eut=UHSPp-hizR0_nDE87ZMPJaf1vg@mail.gmail.com> <72E71872-9AC3-4D74-B889-B13CE05F62E4@cisco.com> <d64e4247d2bc4fc18a83a3f80591f95c@XCH-ALN-003.cisco.com> <af0871015b7d4e6d9325ac91226e1436@XCH-ALN-003.cisco.com> <CAJE_bqfYN3OpKtSW90Xpjt1CSRH4OfJgXwAa+J3rXxq4nuZZ_Q@mail.gmail.com>
In-Reply-To: <CAJE_bqfYN3OpKtSW90Xpjt1CSRH4OfJgXwAa+J3rXxq4nuZZ_Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.22.0.170515
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.253.126]
Content-Type: text/plain; charset="utf-8"
Content-ID: <18461F4205462342BC24E860A71EB482@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/9Q1rx0tNRwsCu8tCQf05vurFkAY>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jun 2017 23:23:54 -0000

Hi JINMEI:

I like your revised text, “If the client uses a delegated …”.

However, I think I’d like to leave the preferred-lifetime definition as it was (without the “recommended”).

The reason is that:
1. Preferred lifetime does impact the protocol behavior in that it is used to derive the T1/T2 times (for PDs that can be renewed).
2. This also applies to the valid-lifetime; thus, if added should really be in both.
3. The “If the client uses” text is not “below” – that is in 6.3 and 18.2.10.1. I guess for completeness, we might want to reference that. So in 21.22, we could change:

   The values in the preferred and valid lifetimes are the number of
   seconds remaining for each lifetime. Refer to section 18.2.10.1 for
   more details on how these values are used for delegated prefixes.

- Bernie

On 6/27/17, 4:05 PM, "dhcwg on behalf of 神明達哉" <dhcwg-bounces@ietf.org on behalf of jinmei@wide.ad.jp> wrote:

    At Tue, 27 Jun 2017 18:15:29 +0000,
    "Bernie Volz (volz)" <volz@cisco.com> wrote:
    
    > 2nd try to see if there’s any comments on this. Trying to close out
    > the -09 version before the IETF-99 deadline (7/3).
    
    Sorry for the delay, I've been offline.  As for your proposed text:
    
          If the client assigns a delegated prefix to a link to which the
          router is attached, and begins to send router advertisements for
          the prefix on the link, the preferred and valid lifetime in
          those advertisements MUST be no larger than the remaining
          preferred and valid lifetimes, respectively, for the delegated
          prefix at the time the router advertisement is sent.
    
    it addresses my main concern.  I'd personally generalize it a bit,
    though.  For example:
    
       If the client uses a delegated prefix to configure addresses on
       interfaces on itself or other nodes behind it, the preferred and
       valid lifetimes of those addresses MUST be no larger than the
       remaining preferred and valid lifetimes, respectively, for the
       delegated prefix at any time.  In particular, if the delegated
       prefix or a prefix derived from it is advertised for stateless
       address autoconfiguration [RFC4862], the advertised valid and
       preferred lifetimes MUST NOT exceed the corresponding remaining
       lifetimes of the delegated prefix.
    
    Here I tried to not limit the use of lifetimes to SLAAC (for example,
    they could be used in DHCPv6 for the delegated site), while explicitly
    noting the SLAAC case as we now know there are implementations that
    violate it.
    
    I'd also update the description of the PD 'preferred-lifetime'
    (Section 21.22 in the 08 version) from:
    
          preferred-lifetime   The recommended preferred lifetime for the
                               prefix in the option, expressed in units of
                               seconds.  A value of 0xFFFFFFFF represents
                               infinity.
    
    to, for example:
    
          preferred-lifetime   The preferred lifetime for the
                               prefix in the option, expressed in units of
                               seconds.  This lifetime does not affect the
                               protocol behavior of prefix delegation, but
                               has implication on addresses generated
                               using the prefix (see below).  A value of
                               0xFFFFFFFF represents infinity.
    
    Here I avoided the term "recommended" as it's not clear what it means
    (I asked this before in this thread but no one answered) and provided
    the description of this value I envision.  "see below" refers to the
    additional note we're discussing above.
    
    --
    JINMEI, Tatuya
    
    _______________________________________________
    dhcwg mailing list
    dhcwg@ietf.org
    https://www.ietf.org/mailman/listinfo/dhcwg