[dhcwg] Review of 3315bis (draft-ietf-dhc-rfc3315bis-05) for WGLC

Timothy Winters <twinters@iol.unh.edu> Tue, 23 August 2016 03:02 UTC

Return-Path: <twinters@iol.unh.edu>
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 2F46B12D0B0 for <dhcwg@ietfa.amsl.com>; Mon, 22 Aug 2016 20:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iol.unh.edu
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 T-kyRU3sLzA4 for <dhcwg@ietfa.amsl.com>; Mon, 22 Aug 2016 20:02:50 -0700 (PDT)
Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976DB124281 for <dhcwg@ietf.org>; Mon, 22 Aug 2016 20:02:50 -0700 (PDT)
Received: by mail-yb0-x235.google.com with SMTP id z10so46404671ybh.2 for <dhcwg@ietf.org>; Mon, 22 Aug 2016 20:02:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; h=mime-version:from:date:message-id:subject:to; bh=5ZKy7Z4QtxrrNv9cPkD1vEpHibIaladNxEhkGrgLiHo=; b=NwEAtaEfM6VNUgR+gCtVLkzlohD7Xuvdavhfj5iy43dBYJjveq0/cTxrcImZ4sPeND 3Z4sDqdzA9P1Uf3ciyTZqDjrSdLq+UgWqncf9Rnbr0nXIx49O4Xr2GWUueOFTIu0hu2Q o9G9jCSwf0kF/rNybYYtDMRwsAACGc43AaHpM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5ZKy7Z4QtxrrNv9cPkD1vEpHibIaladNxEhkGrgLiHo=; b=Sbe5vFpuctkO1bFy7gv8Rs+LgO3Tf7FWFdvkIFWbDlbqOF3FBomPNKwCZUjePAPCU1 B0jtoAzWZr9SpeL5ED1ofi5CpX4Ipi3+nm3kvFcGQLBq9E/pZ8CPxucboS46Qn6ccz9d Rxx1pdsbJjhm0mcGQzCiJZf9jS/72N/YoDhNsVhU4+iIsIk3yhmZ8yE7bK2NMilC9EIu bYWufHItGln2oCwoWBdeQKrB1gvsSpy14+cT253tUdIbvZE+wWX227mn/RbXMxBJ4EKC k3F8IbGUvUSPuTJXpS9Tet9BTQDb7PmnBvj6tRstbJi+S+gwG1uSZnWuSR/V1rfjcujJ ND6g==
X-Gm-Message-State: AEkooutjimdhWRRLscW4OwAM4p/ZuC8FSghX7BzjN9gpewWAHO/gmaxwRVN76+8q2xKShaLn9RNTZ2s2Yp4xypNh
X-Received: by 10.37.97.141 with SMTP id v135mr8381091ybb.141.1471921369474; Mon, 22 Aug 2016 20:02:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.154.138 with HTTP; Mon, 22 Aug 2016 20:02:48 -0700 (PDT)
From: Timothy Winters <twinters@iol.unh.edu>
Date: Mon, 22 Aug 2016 23:02:48 -0400
Message-ID: <CAOSSMjWf6WSAX-6v-i8qS_5sjcY=RQKdeZPDgC395XrD=vW-+Q@mail.gmail.com>
To: dhcwg@ietf.org
Content-Type: multipart/alternative; boundary="001a1142d8f25da2f0053ab46617"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/UdtOEpDYWhBly23AG7wt-3kkY34>
Subject: [dhcwg] Review of 3315bis (draft-ietf-dhc-rfc3315bis-05) for WGLC
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
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, 23 Aug 2016 03:02:52 -0000

Hi,

Previous comments covered all the Nits that I had, so I left them off.

There are three comments that I have about the document:

-  The document would be clearer with if Requesting Router/Delegating
Router were updated to Client/Server.   Since many IETF documents are
moving to this model.

Section 17.1.1 following text should probably be removed?
"  In the case of a Solicit message transmitted when DHCP is initiated by
   IPv6 Neighbor Discovery, the delay gives the amount of time to wait
   after IPv6 Neighbor Discovery causes the client to invoke the
   stateful address autoconfiguration protocol (see section 5.5.3 of
   [RFC4862]).  This random delay desynchronizes clients which start at
   the same time (for example, after a power outage)."

Text was for RFC 2461, which had M flag text.  Probably should be removed
with the updated RFC 4861.

- 13.2 for T1/T2 seems out of place as T1 and T2 are later defined.
Suggest moving it to 17.1.4.

~Tim
-- 

Now offering testing for SDN applications and controllers in our SDN switch
test bed. Learn more today http://bit.ly/SDN_IOLPR