[apps-discuss] APPSDIR review of draft-ietf-dhc-dhcpv6-redundancy-consider-02

"Jiankang YAO" <yaojk@cnnic.cn> Sat, 28 January 2012 10:22 UTC

Return-Path: <yaojk@cnnic.cn>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E674721F846E for <apps-discuss@ietfa.amsl.com>; Sat, 28 Jan 2012 02:22:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.596
X-Spam-Level:
X-Spam-Status: No, score=-98.596 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_50=0.001, J_CHICKENPOX_83=0.6, MIME_BASE64_TEXT=1.753, 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 S2bPx-uKvdLZ for <apps-discuss@ietfa.amsl.com>; Sat, 28 Jan 2012 02:22:11 -0800 (PST)
Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 9C01E21F853A for <apps-discuss@ietf.org>; Sat, 28 Jan 2012 02:22:07 -0800 (PST)
X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn
Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Sat, 28 Jan 2012 18:22:05 +0800
Message-ID: <662D4412BFDE422285267DB54B3313E9@LENOVO47E041CF>
From: "Jiankang YAO" <yaojk@cnnic.cn>
To: <apps-discuss@ietf.org>, <john_brzozowski@cable.comcast.com>, <jf@jftremblay.com>, <jack.chen@twcable.com>, <tomasz.mrugalski@gmail.com>
Date: Sat, 28 Jan 2012 18:21:53 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Cc: iesg@ietf.org
Subject: [apps-discuss] APPSDIR review of draft-ietf-dhc-dhcpv6-redundancy-consider-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Jan 2012 10:22:12 -0000

I have been selected as the Applications Area Directorate reviewer 
for this draft (for background on appsdir, please 
see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate 
).  
Please resolve these comments along with any other comments 
you may receive. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft.

Document: draft-ietf-dhc-dhcpv6-redundancy-consider-02

Title: 
DHCPv6 Redundancy Deployment Considerations

Reviewer: Jiankang Yao
Review Date: Jan 28, 2012

Summary:

This draft is almost ready for publication as a BCP. But before publication, the following 
issues should be considered or addressed.

Major issue:

1) The distinction between definition of the service provider model and definition of the enterprise model are not very clear.

section 2.1 Service provider model said 
"
   The service provider model represents cases, where end-user devices
   may be configured directly, without any intermediate devices (like
   home routers used in service provider model). 
"
section 2.1 Enterprise model said  
   "The enterprise model represents cases where end-user devices are most
   often configured directly without any intermediate devices (like home
   routers used in service provider model). 
"
The difference between these two difinitions are "may be configured" and "often configured".

According to the current definition "may be configured" and "often configured"
, the reader can not easily judge "what the service provider model is" or "what the enterprise model is".

Another problem for the definition of Service provider model is that 
it seems to be a circular definition. We define what the service provider model is, but the defintion say: (like home routers used in service provider model).


Discussion issue:

1)In section 4, there introduces 3 prefixes:Split Prefixes,Multiple Unique Prefixes and Identical Prefixes in parallel way.

 In section 4.1, it introduces
"In the split prefixes model, each DHCPv6 server is configured with a
   unique, non-overlapping range derived from the /64 prefix deployed
   for use within an IPv6 network."

 In section 4.2, it introduces
  "In the multiple prefix model, each DHCPv6 server is configured with a
   unique, non-overlapping prefix.  A /64 range equal to the prefix is
   configured on each server. "

Based on the above definitions, the multiple prefix model seems to be a pecial
case of the split prefixes model.

If it is, I think that section 4.1 and 4.2 need to merge together and restructure.

Question issue:

 This document said "At the time of this writing a standards-based DHCPv6 redundancy protocol and implementations are not available. " I am wondering
why the solution in this document should be BCP. Are there a lot of implementations? Is this one the best one? 


Minor Issues:


1) There are 14 "must" in this document,but all are in lower case. I am sure
that some should be "MUST", pls check it.

2) In section 2.1 "(CMTS for cable or DSLAM/BRAS for DSL for example) "

The abbreviation needs some explaination or reference. Pls also check other abbreviations in this document.