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:43 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 DC2FD126B7F for <dhcwg@ietfa.amsl.com>; Tue, 27 Jun 2017 16:43:40 -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 Rmt84zjunvHC for <dhcwg@ietfa.amsl.com>; Tue, 27 Jun 2017 16:43:38 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BEFD1200ED for <dhcwg@ietf.org>; Tue, 27 Jun 2017 16:43:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6622; q=dns/txt; s=iport; t=1498607018; x=1499816618; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vPYEUCeAvjtWuHOR/2kWuXGgkKmPMaijpi8LV8K9K+E=; b=T0l7brtNGwxf/otrFsXbC/ucJqBLNR3KOiNzvQhRc5fSXNiCC0A6O8tC IBYuSQKyq1+NarZ8kvzCSkSZdI2MycfNfggqPWkTemTGB3YChvgJHANqV 3rULmLRChdzkrl/ENWl9mWT2Sk5vLbE58pEC/dEJcwGFbreILXT67Dvtv U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AwAQCx7FJZ/5JdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1hjgQ4Hg2WKGZFGIoMkklaCESENhR9PAhqCaT8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGQEBAQIBAQEhEToLEAIBBgIaAiYCAgIlCxUQAgQOBYooCBCTHZ1igiaLX?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuCHIUtKwuCboE8gwsjF4J8MIIxBZ5?= =?us-ascii?q?vAoc0jDWCCpAKiSuLeAEfOIEKdBVJEgGFCoF2dgWGWYExgQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.40,272,1496102400"; d="scan'208";a="446119219"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2017 23:43:37 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v5RNhbkb025235 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Jun 2017 23:43:37 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 27 Jun 2017 18:43:37 -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:43:37 -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/66epAAUqtWAAAA4C24AAG1T8gA==
Date: Tue, 27 Jun 2017 23:43:36 +0000
Message-ID: <11007951-E0AE-466C-ABE9-8A05ACE9E25D@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> <44C31F53-9D69-4110-BEB6-65AE902EB2B8@cisco.com>
In-Reply-To: <44C31F53-9D69-4110-BEB6-65AE902EB2B8@cisco.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: <CF553C0F703E364BAA7338FB9D5614CD@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/ceOs2dgR0jWzoQKo3C5sMyB1eNk>
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:43:41 -0000

FYI – The change can be viewed at:

https://github.com/dhcwg/rfc3315bis/commit/59a134acbbb3e2ad545e3296547707df3d32aecc

- Bernie

On 6/27/17, 4:23 PM, "dhcwg on behalf of Bernie Volz (volz)" <dhcwg-bounces@ietf.org on behalf of volz@cisco.com> wrote:

    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
        
    
    _______________________________________________
    dhcwg mailing list
    dhcwg@ietf.org
    https://www.ietf.org/mailman/listinfo/dhcwg