[dhcwg] Intdir early review of draft-ietf-dhc-rfc3315bis-10

Zhen Cao <zhencao.ietf@gmail.com> Wed, 01 November 2017 07:40 UTC

Return-Path: <zhencao.ietf@gmail.com>
X-Original-To: dhcwg@ietf.org
Delivered-To: dhcwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E52713FAEE; Wed, 1 Nov 2017 00:40:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Zhen Cao <zhencao.ietf@gmail.com>
To: <int-dir@ietf.org>
Cc: dhcwg@ietf.org, ietf@ietf.org, draft-ietf-dhc-rfc3315bis.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.63.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150952203714.25993.17333137226492207681@ietfa.amsl.com>
Date: Wed, 01 Nov 2017 00:40:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/2KD2Okl1CbuoOzwnpipNai65AZs>
Subject: [dhcwg] Intdir early review of draft-ietf-dhc-rfc3315bis-10
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 01 Nov 2017 07:40:37 -0000

Reviewer: Zhen Cao
Review result: Ready with Issues

I am an assigned INT directorate reviewer for this draft. These
comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherds should treat these comments
just like they would treat comments from any other IETF contributors
and resolve them along with any other Last Call comments that have
been received. For more details of the INT directorate, see

This version is quite ready to go, with a small issue that I would like to

In Section. 15 (Reliability of Client Initiated Message Exchanges), I strongly
recommend that implementation MUST NOT set both MRC or MRD to ZERO, which
attaches a possible risk that the client continues to send this message without
a stop.    So I would like to propose the following change:

" If both MRC and MRD are zero, the client continues to transmit the
   message until it receives a response."
"The client must be informed with a limit of its retransmission behavior, and
MUST NOT set both MRC and MRD to zero"