From nobody Wed Jul 1 01:22:37 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691B61A003B; Wed, 1 Jul 2015 01:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Kj2DEp9L-N9F; Wed, 1 Jul 2015 01:22:35 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34DEE1A0041; Wed, 1 Jul 2015 01:22:35 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id C05A0DA006F; Wed, 1 Jul 2015 08:22:34 +0000 (UTC) Received: from [64.89.227.170] (64.89.227.170) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 1 Jul 2015 01:22:33 -0700 From: Ralf Weber To: Date: Wed, 1 Jul 2015 10:22:27 +0200 Message-ID: <689859D4-3AE3-4B1E-A4C2-E3CEA946A2D8@nominum.com> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300533E109@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <489D13FBFA9B3E41812EA89F188F018E1CB41327@xmb-rcd-x04.cisco.com> <02895A28-D94F-4553-8F35-BBC59F32BD08@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1CB5216E@xmb-rcd-x04.cisco.com> <787AE7BB302AE849A7480A190F8B93300533E109@OPEXCLILMA3.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "Bernie Volz \(volz\)" , "int-ads@ietf.org" , "int-dir@ietf.org" , "Christopher LILJENSTOLPE \(cdl@asgaard.org\)" , "draft-vinapamula-softwire-dslite-prefix-binding@tools.ietf.org" , "jeanmichel.combes@gmail.com" Subject: Re: [Int-dir] INT Directorate - Seeking Directorate reviews X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 08:22:36 -0000 Moin! On 30 Jun 2015, at 9:03, mohamed.boucadair@orange.com wrote: > A misbehaving CPE can indeed vary the source IPv6 address it uses to > send its IPv4-in-IPv6 packets to the DS-Lite AFTR. If the AFTR > maintains state for each new softwire (from the same B4), then varying > the source IPv6 address can be a source of DoS attack that may exhaust > the AFTR resources. > > A first mitigation to this attack vector is to limit the number of > softwire per B4 (already recorded in the draft). This countermeasure > should be complemented with rate limiting softwires with new source > IPv6 from the same CPE. > > A new version that includes changes to address your comment is > available online: That addresses my concern. IMHO it would be clearer to replace CPE with prefix, so that section 5 would say: Enforcing the recommendations documented in Section 4 together with rate limiting softwires with new source IPv6 addresses from the same prefix to defend against DoS attacks that would result in varying the B4's IPv6 address to exhaust AFTR resources. But that's just minor wording issue. So long -Ralf --- Ralf Weber Principal Architect, Special Projects office: +49 6446 4392053 mobile: +49 151 22659325 us: +1 650 817 5895 Nominum www.nominum.com ralf.weber@nominum.com From nobody Wed Jul 1 08:20:46 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC681A00E3; Wed, 1 Jul 2015 01:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 j0L8ORYZ7C0u; Wed, 1 Jul 2015 01:31:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9B581A006D; Wed, 1 Jul 2015 01:31:47 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 33C5E22C32A; Wed, 1 Jul 2015 10:31:46 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 0133D35C045; Wed, 1 Jul 2015 10:31:46 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0235.001; Wed, 1 Jul 2015 10:31:45 +0200 From: To: Ralf Weber Thread-Topic: INT Directorate - Seeking Directorate reviews Thread-Index: AQHQs9cXWA/zgBSsrUO3YR99tv+Rpp3GSJnw Date: Wed, 1 Jul 2015 08:31:44 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933005351728@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <489D13FBFA9B3E41812EA89F188F018E1CB41327@xmb-rcd-x04.cisco.com> <02895A28-D94F-4553-8F35-BBC59F32BD08@nominum.com> <489D13FBFA9B3E41812EA89F188F018E1CB5216E@xmb-rcd-x04.cisco.com> <787AE7BB302AE849A7480A190F8B93300533E109@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <689859D4-3AE3-4B1E-A4C2-E3CEA946A2D8@nominum.com> In-Reply-To: <689859D4-3AE3-4B1E-A4C2-E3CEA946A2D8@nominum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.1.75416 Archived-At: X-Mailman-Approved-At: Wed, 01 Jul 2015 08:20:45 -0700 Cc: "Bernie Volz \(volz\)" , "int-ads@ietf.org" , "int-dir@ietf.org" , "Christopher LILJENSTOLPE \(cdl@asgaard.org\)" , "draft-vinapamula-softwire-dslite-prefix-binding@tools.ietf.org" , "jeanmichel.combes@gmail.com" Subject: Re: [Int-dir] INT Directorate - Seeking Directorate reviews X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 08:31:49 -0000 Dear Ralf, Deal! I made this change in my local copy: s/CPE/prefix. Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Ralf Weber [mailto:ralf.weber@nominum.com] > Envoy=E9=A0: mercredi 1 juillet 2015 10:22 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: Bernie Volz (volz); jeanmichel.combes@gmail.com; int-ads@ietf.org; > Christopher LILJENSTOLPE (cdl@asgaard.org); int-dir@ietf.org; draft- > vinapamula-softwire-dslite-prefix-binding@tools.ietf.org > Objet=A0: Re: INT Directorate - Seeking Directorate reviews >=20 > Moin! >=20 > On 30 Jun 2015, at 9:03, mohamed.boucadair@orange.com wrote: > > A misbehaving CPE can indeed vary the source IPv6 address it uses to > > send its IPv4-in-IPv6 packets to the DS-Lite AFTR. If the AFTR > > maintains state for each new softwire (from the same B4), then varying > > the source IPv6 address can be a source of DoS attack that may exhaust > > the AFTR resources. > > > > A first mitigation to this attack vector is to limit the number of > > softwire per B4 (already recorded in the draft). This countermeasure > > should be complemented with rate limiting softwires with new source > > IPv6 from the same CPE. > > > > A new version that includes changes to address your comment is > > available online: > That addresses my concern. IMHO it would be clearer to replace CPE with > prefix, so that section 5 would say: >=20 > Enforcing the recommendations documented in Section 4 together with > rate limiting softwires with new source IPv6 addresses from the same > prefix to defend against DoS attacks that would result in varying the > B4's > IPv6 address to exhaust AFTR resources. >=20 > But that's just minor wording issue. >=20 > So long > -Ralf > --- > Ralf Weber > Principal Architect, Special Projects > office: +49 6446 4392053 > mobile: +49 151 22659325 > us: +1 650 817 5895 > Nominum > www.nominum.com > ralf.weber@nominum.com From nobody Wed Jul 1 10:11:00 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547361A90F0; Wed, 1 Jul 2015 10:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 9QZxHrl4kFsb; Wed, 1 Jul 2015 10:10:57 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (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 DD03B1A1A52; Wed, 1 Jul 2015 10:10:56 -0700 (PDT) Received: by laar3 with SMTP id r3so45166663laa.0; Wed, 01 Jul 2015 10:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=MK/vqAO8UPfDyIZ1inD05HgRUVotqYs85U94ZEd/Isk=; b=hyxQjkh57NLCKeWZ9QzNBlR/SJYOKTNOiL0q7rzsZmt9DsSNwnQeQp6Rss0y1/CgV1 5SUB6uysPW6ah0qiykC52MMvLH2ovyl+QV21VJ0llD2bhyx8eRXEWbalpLFRccpTYaAn qwv6NP6FKBHP3uyWpRdTORbgykUrU380FeH/b7yQZbyQKJxNCtO0xwzr/oxklJMBdzP4 dN0DPyxjxU/nXcJM9Zq9WbLNCxvQsVnOwLAcO3pH9o98K76KQU3U1vnFKkisL7kw5YSF 2SIbqTTMXq8zulKkVHEkT42DOc/wtMiyCIGgS5aLP5gSvQB1S8287hOAtCKmED/nBZse X8YA== MIME-Version: 1.0 X-Received: by 10.112.199.10 with SMTP id jg10mr26244892lbc.24.1435770655359; Wed, 01 Jul 2015 10:10:55 -0700 (PDT) Received: by 10.25.140.6 with HTTP; Wed, 1 Jul 2015 10:10:55 -0700 (PDT) Date: Thu, 2 Jul 2015 01:10:55 +0800 Message-ID: From: Hui Deng To: "Bernie Volz (volz)" , Christopher LILJENSTOLPE , terry.manderson@icann.org, Brian Haberman , int-dir@ietf.org, int-ads@ietf.org, draft-ietf-homenet-dncp.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c2ade6e44a7c0519d367f9 Archived-At: Subject: [Int-dir] INT Dir review: draft-ietf-homenet-dncp-06.txt X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 17:10:59 -0000 --001a11c2ade6e44a7c0519d367f9 Content-Type: text/plain; charset=UTF-8 Hello, all. I am an assigned INT directorate reviewer for . These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) 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 on the INT Directorate, see http://www.ietf.org/iesg/directorate.html Document: draft-ietf-homenet-dncp-05.txt Reviewer: DENG Hui Review Date: July 1st, 2015 Intended Status: Standards Track Summary: The DNCP will coexist with HNCP (DNCP profile protocol) and is designed for a generic purpose. Also it doesn't conflict with Multiple Provision domain design in the MIF WG. I support this work to move forward after some better shaping. Comments: 1) It's not easy for the audience of this document to understand DNCP profile throughout the document, sometime we read like the definition of terminology: "set of rules and values", later we read it like an HNCP protocol. if possible, I would like to recommend that the document will clearly state this two things respectively, for example by adding a new terminology DNCP profile protocol which indicate future HNCP, we may also explain more clearly about the relationship between DNCP and DNCP profile protocol. and also in HNCP document, it could explain how it relates to DNCP protocol by mentioning the DNCP profile protocol. 2) this document is not easy to read for a layman, cause there are many places mentioned about later part of the document, for example in terminology DNCP profile, it says section 9, readers have to jump to later section to understand what exactly it means. one way to improve by briefly listing some rule and values here. 3) this protocol doesn't mention a port number, it may rely on DNCP profile protocol to specify it, I recommend this document could help to clarify it. 4) the text as below in Section 2 Endpoint a locally configured use of DNCP on a DNCP node. I don't understand 'configured use of DNCP'. Does that mean 'a specific DNCP configuration entity used by a DNCP node'? 5) 'Sequence number' is mentioned for the first time in the definition of 'Node state'. After reading through the draft I found out 'sequence number' is in Node State TLV called 'update sequence number'. Would it be better if the value field called 'sequence number' and the 'update' part explained in the context? Meanwhile, the terminology of 'update number' is used several time in the context (i. e. explaining the calculation of network state hash). I assume this also imply 'update sequence number' field in Node State TLV, would you clarify this? 6) In Section 5.1, it is mentioned a condition of highest node identifier on a link. There are 2 points need to be clarified here. First, what does a higher node identifier represent? Second, what kind of node identifiers are classified as the node identifier on a link? Since 'link' is defined in Section 3 as the link-layer media over which directly connected nodes can communicate, it seems to me that only 2 nodes (identifiers) are 'on' the link? 7) For fragmentation, this draft hasn't mention how security protection will influence the fragmentation. Best regards, DENG Hui --001a11c2ade6e44a7c0519d367f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello, all.

I am an assi= gned INT directorate reviewer for <draft-ietf-homenet-dncp-06.txt>.
These comments were written primarily for the benefit of the Inter= net
Area Directors. Document editors and shepherd(s) should treat= these
comments just like they would treat comments from any othe= r IETF
contributors and resolve them along with any other Last Ca= ll comments
that have been received. For more details on the INT = Directorate,

Document: draft-ietf-homenet-dncp-05.txt
Reviewer: DENG Hui
Review Date: July 1st, 2015

Intended Status= : Standards Track

Summary:=C2=A0
The DNC= P will coexist with HNCP (DNCP profile protocol) and is designed=C2=A0
for a generic purpose. Also it doesn't conflict with Multiple Pro= vision=C2=A0
domain design in the MIF WG. I support this work to = move forward after
some better shaping.

= Comments:
1) It's not easy for the audience of this document = to understand DNCP=C2=A0
profile throughout the document, sometim= e we read like the definition
of terminology: "set of rules = and values", later we read it like an HNCP protocol.
if poss= ible, I would like to recommend that the document will clearly=C2=A0
<= div>state this two things respectively, for example by adding a new termino= logy DNCP profile=C2=A0
protocol which indicate future HNCP, we m= ay also explain more clearly
about the relationship between DNCP = and DNCP profile protocol.=C2=A0
and also in HNCP document, it co= uld explain how it relates to DNCP protocol
by mentioning the DNC= P profile protocol.=C2=A0

2) this document is not = easy to read for a layman, cause there are many places
mentioned = about later part of the document, for example in terminology=C2=A0
DNCP profile, it says section 9, readers have to jump to later section to= =C2=A0
understand what exactly it means. one way to improve by br= iefly listing some
rule and values here.

3) this protocol doesn't mention a port number, it may rely on DNCP pr= ofile protocol to specify it, I recommend this document could help to clari= fy it.

4) the text as below in Section 2
Endpoint =C2=A0 =C2=A0 =C2=A0 =C2=A0a locally configured use of DNCP on a = DNCP node.
I don't understand 'configured use of DNCP'= ;. Does that mean 'a specific DNCP=C2=A0
configuration entity= used by a DNCP node'?

5) 'Sequence number= ' is mentioned for the first time in the definition
of 'N= ode state'. After reading through the draft I found out 'sequence
number' is in Node State TLV called 'update sequence numbe= r'. Would it
be better if the value field called 'sequenc= e number' and the 'update'
part explained in the cont= ext? Meanwhile, the terminology of 'update=C2=A0
number' = is used several time in the context (i. e. explaining the=C2=A0
c= alculation of network state hash). I assume this also imply 'update=C2= =A0
sequence number' field in Node State TLV, would you clari= fy this?

6) In Section 5.1, it is mentioned a cond= ition of highest node=C2=A0
identifier on a link. There are 2 poi= nts need to be clarified here.=C2=A0
First, what does a higher no= de identifier represent? Second, what kind
of node identifiers ar= e classified as the node identifier on a link?=C2=A0
Since 'l= ink' is defined in Section 3 as the link-layer media over which
directly connected nodes can communicate, it seems to me that only 2=C2= =A0
nodes (identifiers) are 'on' the link?

=
7) For fragmentation, this draft hasn't mention how security= protection
will influence the fragmentation.

Best regards,

DENG Hui
--001a11c2ade6e44a7c0519d367f9-- From nobody Thu Jul 2 06:34:41 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDF81A6EE7; Thu, 2 Jul 2015 06:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 RxSKISuhDio6; Thu, 2 Jul 2015 06:18:21 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id E1D211A6F15; Thu, 2 Jul 2015 06:18:20 -0700 (PDT) Received: from poro.lan (80.220.64.126) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 552B87C904F32347; Thu, 2 Jul 2015 16:18:11 +0300 To: Hui Deng , "Bernie Volz (volz)" , Christopher LILJENSTOLPE , terry.manderson@icann.org, Brian Haberman , int-dir@ietf.org, int-ads@ietf.org, draft-ietf-homenet-dncp.all@tools.ietf.org References: From: Markus Stenberg Message-ID: <55953A0A.7030009@iki.fi> Date: Thu, 2 Jul 2015 16:18:02 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 06:34:39 -0700 Subject: Re: [Int-dir] INT Dir review: draft-ietf-homenet-dncp-06.txt X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 13:18:23 -0000 On 1.7.2015 20.10, Hui Deng wrote: > I am an assigned INT directorate reviewer for > . > These comments were written primarily for the benefit of the Internet > Area Directors. Document editors and shepherd(s) 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 on the INT Directorate, > see http://www.ietf.org/iesg/directorate.html > > Document: draft-ietf-homenet-dncp-05.txt > Reviewer: DENG Hui > Review Date: July 1st, 2015 > > Intended Status: Standards Track > > Summary: > The DNCP will coexist with HNCP (DNCP profile protocol) and is designed > for a generic purpose. Also it doesn't conflict with Multiple Provision > domain design in the MIF WG. I support this work to move forward after > some better shaping. First of all, thanks you for the review. Although the subject says -06, I believe the review is of -05 (Routing area got there first and we addressed their comments in -06.) > Comments: > 1) It's not easy for the audience of this document to understand DNCP > profile throughout the document, sometime we read like the definition > of terminology: "set of rules and values", later we read it like an HNCP > protocol. > if possible, I would like to recommend that the document will clearly > state this two things respectively, for example by adding a new > terminology DNCP profile > protocol which indicate future HNCP, we may also explain more clearly > about the relationship between DNCP and DNCP profile protocol. > and also in HNCP document, it could explain how it relates to DNCP protocol > by mentioning the DNCP profile protocol. dncp-06 has some changes in this direction. dncp-07 will have substantially more; using terms ‘DNCP profile’ for the DNCP-specific section in a ‘DNCP-based protocol’ specification. > 2) this document is not easy to read for a layman, cause there are many > places > mentioned about later part of the document, for example in terminology > DNCP profile, it says section 9, readers have to jump to later section to > understand what exactly it means. one way to improve by briefly listing some > rule and values here. The introduction and terminology sections were edited quite a bit in dncp-06, and an overview section was added to provide a general picture of what it does before diving to details. Terminology has also received number of updates. dncp-07 will have some further work done to address this. > 3) this protocol doesn't mention a port number, it may rely on DNCP > profile protocol to specify it, I recommend this document could help to > clarify it. In dncp-06, it is in the DNCP profile Section 9 (may have been before too). > 4) the text as below in Section 2 > Endpoint a locally configured use of DNCP on a DNCP node. > I don't understand 'configured use of DNCP'. Does that mean 'a specific > DNCP > configuration entity used by a DNCP node'? Addressed in dncp-06. New definition is much more verbose: Endpoint a locally configured communication endpoint of a DNCP node, such as a network socket. It is either bound to an Interface for multicast and unicast communication, or configured for explicit unicast communication with a predefined set of remote addresses. Endpoints are usually in one of the transport modes specified in Section 4.2. > 5) 'Sequence number' is mentioned for the first time in the definition > of 'Node state'. After reading through the draft I found out 'sequence > number' is in Node State TLV called 'update sequence number'. Would it > be better if the value field called 'sequence number' and the 'update' > part explained in the context? Meanwhile, the terminology of 'update > number' is used several time in the context (i. e. explaining the > calculation of network state hash). I assume this also imply 'update > sequence number' field in Node State TLV, would you clarify this? Will be in -07, thanks. Just using ‘sequence number’. (There was 'sequence number', 'update sequence number', and 'update number' in the text.) > 6) In Section 5.1, it is mentioned a condition of highest node > identifier on a link. There are 2 points need to be clarified here. > First, what does a higher node identifier represent? Second, what kind > of node identifiers are classified as the node identifier on a link? > Since 'link' is defined in Section 3 as the link-layer media over which > directly connected nodes can communicate, it seems to me that only 2 > nodes (identifiers) are 'on' the link? This text has been heavily edited in dncp-06 already, hopefully the intent is clearer now. > 7) For fragmentation, this draft hasn't mention how security protection > will influence the fragmentation. It does not - fragmentation occurs within the whole TLVs sent inside {D,}TLS that represent individual fragments. (MTU issues are heavily transport specific so I have chosen to omit them too). Cheers, -Markus From nobody Thu Jul 2 19:05:45 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0121B29DD; Thu, 2 Jul 2015 19:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yB1QDeh_BeFi; Thu, 2 Jul 2015 19:05:42 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B80D1B29DC; Thu, 2 Jul 2015 19:05:42 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 2 Jul 2015 19:05:40 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Thu, 2 Jul 2015 19:05:40 -0700 From: Terry Manderson To: Markus Stenberg , Hui Deng , "Bernie Volz (volz)" , Christopher LILJENSTOLPE , Brian Haberman , "int-dir@ietf.org" , "int-ads@ietf.org" , "draft-ietf-homenet-dncp.all@tools.ietf.org" Thread-Topic: INT Dir review: draft-ietf-homenet-dncp-06.txt Thread-Index: AQHQtCDywFzFxLtLfkmdPHGAF1t5l53IoCIAgAF+GAA= Date: Fri, 3 Jul 2015 02:05:39 +0000 Message-ID: References: <55953A0A.7030009@iki.fi> In-Reply-To: <55953A0A.7030009@iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3518769936_103372154" MIME-Version: 1.0 Archived-At: Cc: Ole Troan Subject: Re: [Int-dir] INT Dir review: draft-ietf-homenet-dncp-06.txt X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 02:05:44 -0000 --B_3518769936_103372154 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Markus, Thank you for your work on this! Please post -07. Once I see that I'll re-read front to back and likely progress the document. Hui, thank you for your careful review! Ole, when you return from leave on Monday I will look forward to your review - please review "-07". Thanks Terry On 2/07/2015 11:18 pm, "Markus Stenberg" wrote: >On 1.7.2015 20.10, Hui Deng wrote: >> I am an assigned INT directorate reviewer for >> . >> These comments were written primarily for the benefit of the Internet >> Area Directors. Document editors and shepherd(s) 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 on the INT Directorate, >> see http://www.ietf.org/iesg/directorate.html >> >> Document: draft-ietf-homenet-dncp-05.txt >> Reviewer: DENG Hui >> Review Date: July 1st, 2015 >> >> Intended Status: Standards Track >> >> Summary: >> The DNCP will coexist with HNCP (DNCP profile protocol) and is designed >> for a generic purpose. Also it doesn't conflict with Multiple Provision >> domain design in the MIF WG. I support this work to move forward after >> some better shaping. > >First of all, thanks you for the review. Although the subject says -06, >I believe the review is of -05 (Routing area got there first and we >addressed their comments in -06.) > >> Comments: >> 1) It's not easy for the audience of this document to understand DNCP >> profile throughout the document, sometime we read like the definition >> of terminology: "set of rules and values", later we read it like an HNCP >> protocol. >> if possible, I would like to recommend that the document will clearly >> state this two things respectively, for example by adding a new >> terminology DNCP profile >> protocol which indicate future HNCP, we may also explain more clearly >> about the relationship between DNCP and DNCP profile protocol. >> and also in HNCP document, it could explain how it relates to DNCP >>protocol >> by mentioning the DNCP profile protocol. > >dncp-06 has some changes in this direction. > >dncp-07 will have substantially more; using terms =8CDNCP profile=B9 for the >DNCP-specific section in a =8CDNCP-based protocol=B9 specification. > >> 2) this document is not easy to read for a layman, cause there are many >> places >> mentioned about later part of the document, for example in terminology >> DNCP profile, it says section 9, readers have to jump to later section >>to >> understand what exactly it means. one way to improve by briefly listing >>some >> rule and values here. > >The introduction and terminology sections were edited quite a bit in >dncp-06, and an overview section was added to provide a general picture >of what it does before diving to details. Terminology has also received >number of updates. > >dncp-07 will have some further work done to address this. > >> 3) this protocol doesn't mention a port number, it may rely on DNCP >> profile protocol to specify it, I recommend this document could help to >> clarify it. > >In dncp-06, it is in the DNCP profile Section 9 (may have been before >too). > >> 4) the text as below in Section 2 >> Endpoint a locally configured use of DNCP on a DNCP node. >> I don't understand 'configured use of DNCP'. Does that mean 'a specific >> DNCP >> configuration entity used by a DNCP node'? > >Addressed in dncp-06. > >New definition is much more verbose: > > Endpoint a locally configured communication endpoint of a > DNCP node, such as a network socket. It is either > bound to an Interface for multicast and unicast > communication, or configured for explicit unicast > communication with a predefined set of remote > addresses. Endpoints are usually in one of the > transport modes specified in Section 4.2. > >> 5) 'Sequence number' is mentioned for the first time in the definition >> of 'Node state'. After reading through the draft I found out 'sequence >> number' is in Node State TLV called 'update sequence number'. Would it >> be better if the value field called 'sequence number' and the 'update' >> part explained in the context? Meanwhile, the terminology of 'update >> number' is used several time in the context (i. e. explaining the >> calculation of network state hash). I assume this also imply 'update >> sequence number' field in Node State TLV, would you clarify this? > >Will be in -07, thanks. Just using =8Csequence number=B9. (There was >'sequence number', 'update sequence number', and 'update number' in the >text.) > >> 6) In Section 5.1, it is mentioned a condition of highest node >> identifier on a link. There are 2 points need to be clarified here. >> First, what does a higher node identifier represent? Second, what kind >> of node identifiers are classified as the node identifier on a link? >> Since 'link' is defined in Section 3 as the link-layer media over which >> directly connected nodes can communicate, it seems to me that only 2 >> nodes (identifiers) are 'on' the link? > >This text has been heavily edited in dncp-06 already, hopefully the >intent is clearer now. > >> 7) For fragmentation, this draft hasn't mention how security protection >> will influence the fragmentation. > >It does not - fragmentation occurs within the whole TLVs sent inside >{D,}TLS that represent individual fragments. > >(MTU issues are heavily transport specific so I have chosen to omit them >too). > >Cheers, > >-Markus --B_3518769936_103372154 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFEpJ 2sd9UIPRbRetsJT0qgEnAmfNMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE1MDcwMzAyMDUzNlowDQYJKoZIhvcNAQEBBQAEggEAR/blU0MTFHwuAok+0O3c Zd4nxxCI+T/x5i1+KlxFl5DclZP2qG29EMWtp13lMniGHV6v9ZV9x7HFYsvETn08/1b2e/RE M4uqp+2YWqHozEVgngDTlYqHdcAGsdZBtUGLkczNhmIodt+FDplS8mZgkR980fGfMRfYyB8M blrHpxYuUeIaLEt49MGGwVbqSmHjPMUmSY4CkzYLOVac2oMfby1jS1Tl8diJZWLbhoJbQ22p hTYETmPX9IZPsmF6CfTuX86rQVgApmbTIK7I1EX82RMukV7WsbhLtS2Jqa3x+ncwKsbvt9Fz 3D+cYTRpRhcDyGHDENIBzUSjn/Ugt7RCVw== --B_3518769936_103372154-- From nobody Fri Jul 3 05:49:38 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97ED81B2DB3; Thu, 2 Jul 2015 23:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 dsqvLCc7tOCX; Thu, 2 Jul 2015 23:52:04 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out1.inet.fi [62.71.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA3B1B2DAB; Thu, 2 Jul 2015 23:52:04 -0700 (PDT) Received: from suiren.local (80.220.64.126) by kirsi2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 5511FF6A00CBC7D4; Fri, 3 Jul 2015 09:51:55 +0300 To: Terry Manderson , Hui Deng , "Bernie Volz (volz)" , Christopher LILJENSTOLPE , Brian Haberman , "int-dir@ietf.org" , "int-ads@ietf.org" , "draft-ietf-homenet-dncp.all@tools.ietf.org" References: <55953A0A.7030009@iki.fi> From: Markus Stenberg Message-ID: <55963106.5030106@iki.fi> Date: Fri, 3 Jul 2015 09:51:50 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Fri, 03 Jul 2015 05:49:37 -0700 Cc: Ole Troan Subject: Re: [Int-dir] INT Dir review: draft-ietf-homenet-dncp-06.txt X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 06:52:05 -0000 On 03/07/15 05:05, Terry Manderson wrote: > Hi Markus, > > Thank you for your work on this! > > Please post -07. Once I see that I'll re-read front to back and likely > progress the document. > > Hui, thank you for your careful review! > > Ole, when you return from leave on Monday I will look forward to your > review - please review "-07". I posted the dncp-07 now. This draft has been in relatively much churn post WGLC (partially thanks to diligent reviewers, partially thanks to second independent implementor of the spec who did the implementation post WGLC), but I think it is getting better; given churn though, I am sure Ole will find things to fix :) Cheers, -Markus From nobody Sat Jul 4 16:33:03 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E88D1A8946; Sat, 4 Jul 2015 16:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 6Pa29pfwVw51; Sat, 4 Jul 2015 16:33:00 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (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 7105D1A8948; Sat, 4 Jul 2015 16:32:59 -0700 (PDT) Received: by laar3 with SMTP id r3so118616415laa.0; Sat, 04 Jul 2015 16:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O8f9tkQBjQ11K+fHCP8sfSjADncXgLjqdLSkY+5B8yQ=; b=KWQ+TjOiIrVFpDMMkWJBXCpSfXif2OZRo8mmxZiQuDX31Uo5vsh1Ne5XXGdkR2tF6A jJ2qzVUwxPA2VeDlGPVBs9NYzufEZo176HcTo+ZMg7jgeqT9uvC35Qe+35fy/BQkkqLE Q6Q6ZJP9LJHEz2zTQisJps/X3uE/gWRjqZgcqf1rK0fVWBCBI/NJGzEKjQ/KAkBIxf95 oFFOYU5KBsD4fdNinw/ICXFbG0gxg016YIK/B4iN8UkIM4ClMPM4OCjib6k1rU5fs4p3 QfnOWlY7fFRMvMHSSM4DLMy8y8FB8ut/5x3ZGdV7FiSspYDAnv2ufAPzvXI5v5UkHNEF CLyw== MIME-Version: 1.0 X-Received: by 10.152.37.228 with SMTP id b4mr41929108lak.117.1436052777947; Sat, 04 Jul 2015 16:32:57 -0700 (PDT) Received: by 10.25.140.6 with HTTP; Sat, 4 Jul 2015 16:32:57 -0700 (PDT) In-Reply-To: <55953A0A.7030009@iki.fi> References: <55953A0A.7030009@iki.fi> Date: Sun, 5 Jul 2015 07:32:57 +0800 Message-ID: From: Hui Deng To: Markus Stenberg Content-Type: multipart/alternative; boundary=089e014939fcb55909051a1517a3 Archived-At: Cc: Brian Haberman , "Bernie Volz \(volz\)" , int-ads@ietf.org, int-dir@ietf.org, draft-ietf-homenet-dncp.all@tools.ietf.org, Christopher LILJENSTOLPE , terry.manderson@icann.org Subject: Re: [Int-dir] INT Dir review: draft-ietf-homenet-dncp-06.txt X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 23:33:02 -0000 --089e014939fcb55909051a1517a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Markus, Thanks for your update suggestion, It looks good to me, I need to go cross GFW to access my gmail, so reply you late. Best regards, DENG Hui 2015-07-02 21:18 GMT+08:00 Markus Stenberg : > On 1.7.2015 20.10, Hui Deng wrote: > >> I am an assigned INT directorate reviewer for >> . >> These comments were written primarily for the benefit of the Internet >> Area Directors. Document editors and shepherd(s) 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 on the INT Directorate, >> see http://www.ietf.org/iesg/directorate.html >> >> Document: draft-ietf-homenet-dncp-05.txt >> Reviewer: DENG Hui >> Review Date: July 1st, 2015 >> >> Intended Status: Standards Track >> >> Summary: >> The DNCP will coexist with HNCP (DNCP profile protocol) and is designed >> for a generic purpose. Also it doesn't conflict with Multiple Provision >> domain design in the MIF WG. I support this work to move forward after >> some better shaping. >> > > First of all, thanks you for the review. Although the subject says -06, I > believe the review is of -05 (Routing area got there first and we address= ed > their comments in -06.) > > Comments: >> 1) It's not easy for the audience of this document to understand DNCP >> profile throughout the document, sometime we read like the definition >> of terminology: "set of rules and values", later we read it like an HNCP >> protocol. >> if possible, I would like to recommend that the document will clearly >> state this two things respectively, for example by adding a new >> terminology DNCP profile >> protocol which indicate future HNCP, we may also explain more clearly >> about the relationship between DNCP and DNCP profile protocol. >> and also in HNCP document, it could explain how it relates to DNCP >> protocol >> by mentioning the DNCP profile protocol. >> > > dncp-06 has some changes in this direction. > > dncp-07 will have substantially more; using terms =E2=80=98DNCP profile= =E2=80=99 for the > DNCP-specific section in a =E2=80=98DNCP-based protocol=E2=80=99 specific= ation. > > 2) this document is not easy to read for a layman, cause there are many >> places >> mentioned about later part of the document, for example in terminology >> DNCP profile, it says section 9, readers have to jump to later section t= o >> understand what exactly it means. one way to improve by briefly listing >> some >> rule and values here. >> > > The introduction and terminology sections were edited quite a bit in > dncp-06, and an overview section was added to provide a general picture o= f > what it does before diving to details. Terminology has also received > number of updates. > > dncp-07 will have some further work done to address this. > > 3) this protocol doesn't mention a port number, it may rely on DNCP >> profile protocol to specify it, I recommend this document could help to >> clarify it. >> > > In dncp-06, it is in the DNCP profile Section 9 (may have been before too= ). > > 4) the text as below in Section 2 >> Endpoint a locally configured use of DNCP on a DNCP node. >> I don't understand 'configured use of DNCP'. Does that mean 'a specific >> DNCP >> configuration entity used by a DNCP node'? >> > > Addressed in dncp-06. > > New definition is much more verbose: > > Endpoint a locally configured communication endpoint of a > DNCP node, such as a network socket. It is either > bound to an Interface for multicast and unicast > communication, or configured for explicit unicast > communication with a predefined set of remote > addresses. Endpoints are usually in one of the > transport modes specified in Section 4.2. > > 5) 'Sequence number' is mentioned for the first time in the definition >> of 'Node state'. After reading through the draft I found out 'sequence >> number' is in Node State TLV called 'update sequence number'. Would it >> be better if the value field called 'sequence number' and the 'update' >> part explained in the context? Meanwhile, the terminology of 'update >> number' is used several time in the context (i. e. explaining the >> calculation of network state hash). I assume this also imply 'update >> sequence number' field in Node State TLV, would you clarify this? >> > > Will be in -07, thanks. Just using =E2=80=98sequence number=E2=80=99. (Th= ere was 'sequence > number', 'update sequence number', and 'update number' in the text.) > > 6) In Section 5.1, it is mentioned a condition of highest node >> identifier on a link. There are 2 points need to be clarified here. >> First, what does a higher node identifier represent? Second, what kind >> of node identifiers are classified as the node identifier on a link? >> Since 'link' is defined in Section 3 as the link-layer media over which >> directly connected nodes can communicate, it seems to me that only 2 >> nodes (identifiers) are 'on' the link? >> > > This text has been heavily edited in dncp-06 already, hopefully the inten= t > is clearer now. > > 7) For fragmentation, this draft hasn't mention how security protection >> will influence the fragmentation. >> > > It does not - fragmentation occurs within the whole TLVs sent inside > {D,}TLS that represent individual fragments. > > (MTU issues are heavily transport specific so I have chosen to omit them > too). > > Cheers, > > -Markus > --089e014939fcb55909051a1517a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Markus,

Thanks for your update sugge= stion, It looks good to me,
I need to go cross GFW to access my g= mail, so reply you late.

Best regards,
<= br>
DENG Hui


2015-07-02 21:18 GMT+08:00 Markus Stenberg = <markus.stenberg@iki.fi>:
On 1.7.2015 20.10, Hui Deng wrote:
I am an assigned INT directorate reviewer for
<draft-ietf-homenet-dncp-06.txt>.
These comments were written primarily for the benefit of the Internet
Area Directors. Document editors and shepherd(s) 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 on the INT Directorate,
see http://www.ietf.org/iesg/directorate.html

Document: draft-ietf-homenet-dncp-05.txt
Reviewer: DENG Hui
Review Date: July 1st, 2015

Intended Status: Standards Track

Summary:
The DNCP will coexist with HNCP (DNCP profile protocol) and is designed
for a generic purpose. Also it doesn't conflict with Multiple Provision=
domain design in the MIF WG. I support this work to move forward after
some better shaping.

 First of all, thanks you for the review. Although the subject says -06, I b= elieve the review is of -05 (Routing area got there first and we addressed = their comments in -06.)

Comments:
1) It's not easy for the audience of this document to understand DNCP profile throughout the document, sometime we read like the definition
of terminology: "set of rules and values", later we read it like = an HNCP
protocol.
if possible, I would like to recommend that the document will clearly
state this two things respectively, for example by adding a new
terminology DNCP profile
protocol which indicate future HNCP, we may also explain more clearly
about the relationship between DNCP and DNCP profile protocol.
and also in HNCP document, it could explain how it relates to DNCP protocol=
by mentioning the DNCP profile protocol.

 dncp-06 has some changes in this direction.

dncp-07 will have substantially more; using terms =E2=80=98DNCP profile=E2= =80=99 for the DNCP-specific section in a =E2=80=98DNCP-based protocol=E2= =80=99 specification.

2) this document is not easy to read for a layman, cause there are many
places
mentioned about later part of the document, for example in terminology
DNCP profile, it says section 9, readers have to jump to later section to understand what exactly it means. one way to improve by briefly listing som= e
rule and values here.

 The introduction and terminology sections were edited quite a bit in dncp-0= 6, and an overview section was added to provide a general picture of what i= t does before diving to details.=C2=A0 Terminology has also received number= of updates.

dncp-07 will have some further work done to address this.<= br>
3) this protocol doesn't mention a port number, it may rely on DNCP
profile protocol to specify it, I recommend this document could help to
clarify it.

 In dncp-06, it is in the DNCP profile Section 9 (may have been before too).=

4) the text as below in Section 2
Endpoint=C2=A0 =C2=A0 =C2=A0 =C2=A0 a locally configured use of DNCP on a D= NCP node.
I don't understand 'configured use of DNCP'. Does that mean = 9;a specific
DNCP
configuration entity used by a DNCP node'?

 Addressed in dncp-06.

New definition is much more verbose:

=C2=A0 =C2=A0Endpoint=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a locally configure= d communication endpoint of a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0DNCP node, such as a network socket. It is either
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0bound to an Interface for multicast and unicast
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0communication, or configured for explicit unicast
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0communication with a predefined set of remote
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0addresses. Endpoints are usually in one of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0transport modes specified in Section 4.2.

5) 'Sequence number' is mentioned for the first time in the definit= ion
of 'Node state'. After reading through the draft I found out 's= equence
number' is in Node State TLV called 'update sequence number'. W= ould it
be better if the value field called 'sequence number' and the '= update'
part explained in the context? Meanwhile, the terminology of 'update number' is used several time in the context (i. e. explaining the
calculation of network state hash). I assume this also imply 'update sequence number' field in Node State TLV, would you clarify this?

 Will be in -07, thanks. Just using =E2=80=98sequence number=E2=80=99. (Ther= e was 'sequence number', 'update sequence number', and '= ;update number' in the text.)

6) In Section 5.1, it is mentioned a condition of highest node
identifier on a link. There are 2 points need to be clarified here.
First, what does a higher node identifier represent? Second, what kind
of node identifiers are classified as the node identifier on a link?
Since 'link' is defined in Section 3 as the link-layer media over w= hich
directly connected nodes can communicate, it seems to me that only 2
nodes (identifiers) are 'on' the link?

 This text has been heavily edited in dncp-06 already, hopefully the intent = is clearer now.

7) For fragmentation, this draft hasn't mention how security protection=
will influence the fragmentation.

 It does not - fragmentation occurs within the whole TLVs sent inside {D,}TL= S that represent individual fragments.

(MTU issues are heavily transport specific so I have chosen to omit them to= o).

Cheers,

-Markus

--089e014939fcb55909051a1517a3-- From nobody Mon Jul 6 18:55:48 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1461A00CA; Mon, 6 Jul 2015 18:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 If9Tpk3zliph; Mon, 6 Jul 2015 18:55:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2DA1A0018; Mon, 6 Jul 2015 18:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31942; q=dns/txt; s=iport; t=1436234142; x=1437443742; h=from:to:subject:date:message-id:mime-version; bh=Qzz3e/NRUuTTAlH3MMIJTg06Lilt7DOpFYuwZ3kRxWk=; b=DL2Fn3V8a88GK907Af+ATbhEi+wBcY3FfbVo/Ft6DMb0kHRK9PEkgIs+ CF10SbvwA4atpPNB/1R+Gflk5uPR54xhpfbFzf1swY2xPi4Hhy8EqlyWx 4cy7uCbfZz5iAPQ2ViHdIo+rIR8Qvd3it/eJZsqjdJG2IpBp+hu2h/u+i 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B1AwBQMZtV/4UNJK1cgkVNVGAGvVcJgW6FdwKBQzgUAQEBAQEBAYEKhCUBBC0aKRsBKhYBPyYBBAEaAYglDbcbkV4BAQEBAQEEAQEBAQEBHIpJhT0ag0+BFAWUFQGNIYQVjyqDXSaCB4F0bwGBRoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,419,1432598400"; d="scan'208,217";a="7501028" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP; 07 Jul 2015 01:55:40 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t671telP032461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Jul 2015 01:55:40 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Mon, 6 Jul 2015 20:55:40 -0500 From: "Bernie Volz (volz)" To: "int-ads@ietf.org" , "int-dir@ietf.org" , "draft-ietf-roll-mpl-parameter-configuration@tools.ietf.org" Thread-Topic: Int-Dir review of draft-ietf-roll-mpl-parameter-configuration-06 Thread-Index: AdC4UaruApjKSQZ9StWLLNYZyoozbQ== Date: Tue, 7 Jul 2015 01:55:39 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1CB60F88@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.1.199] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1CB60F88xmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: Subject: [Int-dir] Int-Dir review of draft-ietf-roll-mpl-parameter-configuration-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 01:55:47 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1CB60F88xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: I am an assigned INT directorate reviewer for draft-ietf-roll-mpl-parameter= -configuration-06. These comments were written primarily for the benefit of= the Internet Area Directors. Document editors and shepherd(s) should treat= these comments just like they would treat comments from any other IETF con= tributors and resolve them along with any other Last Call comments that hav= e been received. For more details on the INT Directorate, see http://www.ie= tf.org/iesg/directorate.html. Disclaimer: I'm primarily reading this draft primarily from the DHCP perspe= ctive. Thus, in some cases my questions might seem odd to those that unders= tand the MPL concepts and issues. I will admit that I have only minimally s= tudied the MPLs drafts. Executive Summary: I do not feel the document is ready. While there are no = significant issues, there are several medium issues that do require resolut= ion and may require some rework of the document. The document does follow R= FC 7227 guidelines. Significant Issues: * None. The document generally follows the requirements set forth i= n RFC 7227 for new DHCPv6 options and seems reasonably straight forward to = implement from the DHCPv6 client and server perspective. Medium: * General - This is one of the few options that is not a singleton = (see RFC 7227, section 16). The use of multiple options seems appropriate h= ere. However, it would be best to clarify that clients (section 2.2) and se= rvers (section 2.4) must be able to support multiple instances of this opti= on. * In section 2.6 (Operational Considerations), the text is a bit od= d. Why should a parameter set not be updated more often than twice the Info= rmation Refresh Time? Explain updated were (on the server by an administrat= or or ?). Also, how does the failure to refresh the option play with text i= n section 2.3 that indicates a missing option means to keep the previously = communicated settings? Perhaps defining what "failure to refresh" means (i.= e., I think it refers to lack of a DHCPv6 server response to a Renew or Inf= ormation Request). Note also that Information Refresh Time is only applicab= le to Information-Request messages (see RFC 4242) so work may be needed as = to how this this sections relate to Renew/Rebind operations? It would improve this section if it was clear as to WHOM the Operational Co= nsiderations listed apply? And, if these are mostly with respect to Client = behavior, why not include in section 2.2 or 2.3? * In section 2.3 (MPL Forwarder Behavior), perhaps this is clear to= people using this draft (and perhaps it should be added in 2.1 - see nit c= omment below) as to exactly what this MPL Domain Address is and how it matc= hes something (does the receipt of an option with an MPL Domain Address cau= se the creation of a new domain or is this something that must have been pr= eviously configured via some other means). Perhaps this is discussed in [I-= D.ietf-roll-trickle-mcast]; if so perhaps an appropriate reference is usefu= l? * I assume Appendix A is intended to be dropped when published as a= n RFC? So: o I would recommend swapping appendix A and B as I assume B is intended t= o stay as part of the RFC. o I would recommend explicit instructions to the RFC editor to remove the= appendix. If you didn't intend the appendix to be dropped, you should! The RFC is the= final product and how it got to be an RFC is a matter of other IETF archiv= es and not generally retained in the document. * In section 4 (Security Considerations), would a reference to [I-D= .ietf-roll-trickle-mcast]'s security considerations also be appropriate? Nits: * Abstract: Would "a network can easily be configured with a single= set of MPL parameters." be better? (Easily at the end is somewhat odd?) * While 2119 allows use of MUST and SHALL interchangeable, perhaps = sticking to MUST is better? But not a big deal. * In section 2.1, I think it would be best to include "MPL Domain A= ddress" in the list of fields and describe it here? * In section 2.2 (DHCPv6 Client Behavior), 2nd paragraph - why woul= d a client discard the option if the reserved bits are set? I would think y= ou'd want to use a new option if you're changing things drastically? But it= certainly is your choice as to whether you want to do that. Perhaps a bett= er reason is if one of the not-permitted values is used (such as 0 and 'all= -bits-set') where are clearly reserved? 0 in many of these case could be ba= d since that would yield 0 time values? This really is up to you, but do th= ink about what you might want to do any maintain backwards compatibility. A= dding a new flag bit to the reserved field is probably not going to break t= hings if existing implementations ignore the bit(s)? But it is always diffi= cult to say what the future will hold? * In section 2.3: o In 1st paragraph, "a node may fail is to join" ... I think "is" needs t= o be dropped? o In the last paragraph, "In the case," ... should be "In this case,". * In Section 3 (IANA Considerations), please include the URL for th= e DHCPv6 registry (http://www.iana.org/assignments/dhcpv6-parameters). It j= ust helps to reduce any possible chance of error. * In Appendix B, first sentence of 2nd paragraph, shouldn't it be "= sets" not set? Or something is odd about this sentence. - Bernie Volz --_000_489D13FBFA9B3E41812EA89F188F018E1CB60F88xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 

I am an assigned INT directorate reviewer for draft-= ietf-roll-mpl-parameter-configuration-06. These comments were written prima= rily for the benefit of the Internet Area Directors. Document editors and s= hepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and r= esolve them along with any other Last Call comments that have been received= . For more details on the INT Directorate, see http://www.ietf.org/iesg/dir= ectorate.html.

 

 

Disclaimer: I’m primarily reading this draft p= rimarily from the DHCP perspective. Thus, in some cases my questions might = seem odd to those that understand the MPL concepts and issues. I will admit= that I have only minimally studied the MPLs drafts.

 

Executive Summary: I do not feel the document is rea= dy. While there are no significant issues, there are several medium issues = that do require resolution and may require some rework of the document. The= document does follow RFC 7227 guidelines.

 

Significant Issues:

·         None. The document generally follows the req= uirements set forth in RFC 7227 for new DHCPv6 options and seems reasonably= straight forward to implement from the DHCPv6 client and server perspectiv= e.

 

Medium:

·         General - This is one of the few options tha= t is not a singleton (see RFC 7227, section 16). The use of multiple option= s seems appropriate here. However, it would be best to clarify that clients= (section 2.2) and servers (section 2.4) must be able to support multiple instances of this option.

·         In section 2.6 (Operational Considerations),= the text is a bit odd. Why should a parameter set not be updated more ofte= n than twice the Information Refresh Time? Explain updated were (on the ser= ver by an administrator or ?). Also, how does the failure to refresh the option play with text in section 2.3 t= hat indicates a missing option means to keep the previously communicated se= ttings? Perhaps defining what “failure to refresh” means (i.e.,= I think it refers to lack of a DHCPv6 server response to a Renew or Information Request). Note also that Information Re= fresh Time is only applicable to Information-Request messages (see RFC 4242= ) so work may be needed as to how this this sections relate to Renew/Rebind= operations?

It would improve this section if it was clear= as to WHOM the Operational Considerations listed apply? And, if these are = mostly with respect to Client behavior, why not include in section 2.2 or 2= .3?

·         In section 2.3 (MPL Forwarder Behavior), per= haps this is clear to people using this draft (and perhaps it should be add= ed in 2.1 – see nit comment below) as to exactly what this MPL Domain= Address is and how it matches something (does the receipt of an option with an MPL Domain Address cause the creati= on of a new domain or is this something that must have been previously conf= igured via some other means). Perhaps this is discussed in [I-D.ietf-roll-t= rickle-mcast]; if so perhaps an appropriate reference is useful?

·         I assume Appendix A is intended to be droppe= d when published as an RFC? So:

o   I would recommend swapping appendix A and B = as I assume B is intended to stay as part of the RFC.

o   I would recommend explicit instructions to t= he RFC editor to remove the appendix.

If you didn’t inten= d the appendix to be dropped, you should! The RFC is the final product and = how it got to be an RFC is a matter of other IETF archives and not generall= y retained in the document.

·         In section 4 (Security Considerations), woul= d a reference to [I-D.ietf-roll-trickle-mcast]’s security considerati= ons also be appropriate?

 

Nits:

·         Abstract: Would “a network can easily = be configured with a single set of MPL parameters.” be better? (Easil= y at the end is somewhat odd?)

·         While 2119 allows use of MUST and SHALL inte= rchangeable, perhaps sticking to MUST is better? But not a big deal.

·         In section 2.1, I think it would be best to = include “MPL Domain Address” in the list of fields and describe= it here?

·         In section 2.2 (DHCPv6 Client Behavior), 2nd paragraph – why would a client discard the option if the = reserved bits are set? I would think you’d want to use a new option i= f you’re changing things drastically? But it certainly is your choice as to whether you want to do that. Perhaps a bett= er reason is if one of the not-permitted values is used (such as 0 and R= 16;all-bits-set’) where are clearly reserved? 0 in many of these case= could be bad since that would yield 0 time values? This really is up to you, but do think about what you might want t= o do any maintain backwards compatibility. Adding a new flag bit to the res= erved field is probably not going to break things if existing implementatio= ns ignore the bit(s)? But it is always difficult to say what the future will hold?

·         In section 2.3:

o   In 1st paragraph, “a node m= ay fail is to join” … I think “is” needs to be drop= ped?

o   In the last paragraph, “In the case,&#= 8221; … should be “In this case,”.

·         In Section 3 (IANA Considerations), please i= nclude the URL for the DHCPv6 registry (http://www.iana.org/assignments/dhcpv6-parameter= s). It just helps to reduce any possible chance of error.

·         In Appendix B, first sentence of 2nd paragraph, shouldn’t it be “sets” not set? Or somethi= ng is odd about this sentence.

 

-     &= nbsp;    Bernie Volz

--_000_489D13FBFA9B3E41812EA89F188F018E1CB60F88xmbrcdx04ciscoc_-- From nobody Tue Jul 7 11:50:22 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5586A1A1EF6; Tue, 7 Jul 2015 11:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 NBsoFM9qVId6; Tue, 7 Jul 2015 11:50:19 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F55D1A1BF2; Tue, 7 Jul 2015 11:50:19 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id E301861A2; Tue, 7 Jul 2015 11:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=from :content-type:subject:date:message-id:cc:to:mime-version; s= selector1; bh=9j/bDFRu641KgPId27RfCYPGfEc=; b=It76/XJAfljZODXs0f Ggnnr5/G2Alp2rCXstCHhLOFZ0YeVn77NXHwTZwnHa32Fviqp4FbL93YDQvJr9id bfdJXYnzmB5Cx4rptd7oOIH09UlCABggs6PDt8UFNwb76O6rLBYE7TIW6XCfyS1U 9g+12cQ5tMGS27k0AKlhNlIPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=from :content-type:subject:date:message-id:cc:to:mime-version; q=dns; s=selector1; b=o1Lm5iw+LJ1nfAP/0iMW59RBCnk0zrleGJ4Zhj9f0gIATr/z uAYELwaggaoBolY1n5BzZCpBtL/ozWBHaoP/8T8r18hoZDx0JgFyn0Shm/7XubPM CAm/EdL9fAQVQcQtomiPBX4IIv+9aT5riwiJrDZaFz4JjVEFVs5/DlnJNOs= Received: from gomlefisk.localdomain (cm-84.215.10.233.getinternet.no [84.215.10.233]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 5217F619E; Tue, 7 Jul 2015 11:50:17 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by gomlefisk.localdomain (Postfix) with ESMTP id EE6FF48AF04E; Tue, 7 Jul 2015 20:50:12 +0200 (CEST) From: Ole Troan X-Pgp-Agent: GPGMail 2.5 Content-Type: multipart/signed; boundary="Apple-Mail=_967AA8F2-2E7A-425E-8325-D8103A675874"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 7 Jul 2015 20:50:11 +0200 Message-Id: <2097EA89-FA00-47BC-A7B0-B93525102DAB@employees.org> To: int-ads@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "homenet@ietf.org Group" , draft-ietf-homenet-dncp@tools.ietf.org, "" Subject: [Int-dir] IntDir review: draft-ietf-homenet-dhcp-07 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 18:50:21 -0000 --Apple-Mail=_967AA8F2-2E7A-425E-8325-D8103A675874 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have been selected as the Internet Directorate reviewer for this draft. The purpose of the review is to provide assistance to the Internet ADs. Although these comments are primarily for the use of the Internet ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-homenet-dncp-07.txt Reviewer: Ole Troan Review Date: July 7 16, 2015 The document now reads much better. I do get the impression that the = text is reverse engineered from code in a few places though. Given that it is an "Abstract protocol" specification, that must be combined with a profile specification to be a fully implementable, it is somewhat difficult to predict if the specification is complete or not. Juliusz Chroboczek is writing an independent implementation, and I'd recommend incorporating the very informative replies the authors = have made to his comments on the homenet list into the document. General comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D> Replace no affiliation with "Independent". If that's the case. =3D> It is unclear to me how multiple instances of DNCP is run on a link. Is that something that must be specified in the profile document, and each profile must support multiple instances? Given draft-stenberg-shsp, and the way it "hijacks" the HNCP profile, it appears that more formal multiple instance support would be needed. =3D> I can't help being left with the impression that fragmentation (section 6.3) is underspecified. Can fragmentation be left out of the protocol for now (and profiles requiring large TLVs can require a transport layer supporting segmentation and reassembly?) =3D> I do find the text on transport modes somewhat confusing, U, M+U and MulticastListen+U. I'd like to see more descriptive text Abstract: =3D=3D=3D=3D=3D=3D=3D=3D=3D OLD: This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol which uses Trickle and Merkle trees. DNCP leaves some details unspecified or provides alternative options. Therefore, only profiles which specify those missing parts define actual implementable DNCP-based protocols. NEW: This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol that uses Trickle and Merkle trees. DNCP is an abstract protocol, that must be combined with a specific profile to make a complete implementable protocol. =3D> The purpose of that change would be to make it clear what this is. A framework? A component that protocols can be built out of? =3D> Add a reference to Merkle trees? Section 4.2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D> This is confusing: o If using a stream transport, the TLV MUST be sent at least once, and it SHOULD be sent only once. OLD: * If only unreliable unicast transport is employed, Trickle state is kept per each peer and it is used to send Network State TLVs every now and then, as specified in Section 4.3. NEW: * If only unreliable unicast transport is used, Trickle state is kept per peer and it is used to send Network State TLVs intermittently, as specified in Section 4.3. s/every now and then/now and then/ s/employed/used/ Section 4.3: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D> reference to rfc6206? o the endpoint is in Multicast+Unicast transport mode, in which case the TLV MUST be sent over multicast. o the endpoint is NOT in Multicast+Unicast transport mode, and the unicast transport is unreliable, in which case the TLV MUST be sent over unicast. =3D> What do an implementation do if the endpoint is not in M+U transport mode, and the unicast transport is reliable? (I do find the transport modes confusing, and I'm not sure I understand the MulticastListen mode). s/when using also secure unicast/when using secure unicast/ Section 4.4: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D> What is meant by: "link with shared bandwidth"? o Any other TLV: TLVs not recognized by the receiver MUST be silently ignored. =3D> doesn't that mean it isn't stored in the Merkle tree? and the hashes don't compute? Section 4.6: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D> First mention of a topology graph. Section 5: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D o Endpoint identifier: the 32-bit opaque value uniquely identifying it within the local node. =3D> "it"? I think I'm still confused what is an endpoint, what is a peer and what is a node. o Range of addresses: the DNCP nodes that are allowed to connect. =3D> How does a range of addresses look like and how is it used? I find only one occurence in the document. Section 6.1: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A DNCP profile MAY specify either per-endpoint or per-peer keep-alive support. =3D> Again I'm confused over the usage of endpoint versus peer. What's the difference between per-peer and per-endpoint keepalives? Section 6.2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D s/actually uses/uses/ --Apple-Mail=_967AA8F2-2E7A-425E-8325-D8103A675874 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVnB9kAAoJEL7aWKiYQt926xEQAJKLDqJ8azE4C+EHi4Vc/QDN yTINooZSAhXF8d6ammFnK2Vr7b/18V3fnX08oDYAsra3cDnmBAJjB0CTeA824Hr4 VsxGNJvflPm/rQeA14j6I24n9UhRlTrVL3fuiPl76sWEmsFJttQZQ6AQtI6gwokQ RR7hPy9SW8PEcVSUCCC9Lv6oJuOX+QJ3h7KDO5Dav8Wtpo1xbBkLQG0xM+5yoDJY 7ucFWOJcgSr3atovqtctNOGRzyTKIHWkaZNKQxg2M0+kR6k3wI/5XG0n/OTtf8s0 iqhQPz7hF8/+GByhioVjZMXlMaAmgLO2L4bZ9qQbDu4y45BApL32bsVtR5m7uNmR 8igJy1x3Fsiq3i3NLu8IdWusrJKVI0fewvQHggOB78eLFpWDz3kAlnVJCItvjo98 JXSAn+YK2AJ1RwTMJN+X6pZ4ch6tsECNiVTbe6JYexc9rxaYURCSxkFreZ+w54b+ 6UuOFlYvt8IqHPq4+CaNEtdRYJjBLwSv/0844pUZT53lMyE4XxmH/1g+RGKrgs6N B7XJDtUcMV9Ihsj00mZkoapQYdzb/JSpqUMqjlJQaKpezw5KOlHnCVwo0tUCm/sX NqxB5/i/0FoZ4jtC2Akt8fWY47jHgR42Sa1HR3EoiKYJRcmQ5T168rFYN8cD4b8E d6C6brFcejWNY3htVnhX =JFmP -----END PGP SIGNATURE----- --Apple-Mail=_967AA8F2-2E7A-425E-8325-D8103A675874-- From nobody Tue Jul 7 19:08:12 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8551AD36A; Tue, 7 Jul 2015 14:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no 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 u86QIZ8165Ox; Tue, 7 Jul 2015 14:52:57 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 BCAE21AD369; Tue, 7 Jul 2015 14:52:57 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZCanN-00027s-3J with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Tue, 07 Jul 2015 23:52:53 +0200 Message-ID: <559C4A32.5050400@openwrt.org> Date: Tue, 07 Jul 2015 23:52:50 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ole Troan , ginsberg@cisco.com References: <2097EA89-FA00-47BC-A7B0-B93525102DAB@employees.org> In-Reply-To: <2097EA89-FA00-47BC-A7B0-B93525102DAB@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 07 Jul 2015 19:08:11 -0700 Cc: rtg-dir@ietf.org, "homenet@ietf.org Group" , rtg-ads@tools.ietf.org, int-ads@tools.ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] review: draft-ietf-homenet-dhcp-07 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 21:52:59 -0000 Hello Ole, hello Les, thank you both for your reviews. We will hopefully get back to you with a detailed reply and a list of changes we made based on your reviews by next week (due to vacations etc). Cheers, Steven From nobody Tue Jul 7 23:36:41 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FEB1B3140; Tue, 7 Jul 2015 23:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MBUpgns-PGfU; Tue, 7 Jul 2015 23:36:37 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1FF81B313F; Tue, 7 Jul 2015 23:36:37 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 7 Jul 2015 23:36:35 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Tue, 7 Jul 2015 23:36:35 -0700 From: Terry Manderson To: Ole Troan , "int-ads@tools.ietf.org" Thread-Topic: [Int-dir] IntDir review: draft-ietf-homenet-dhcp-07 Thread-Index: AQHQuOXVqyuypCmf8kaCgTsput76K53SPAYA Date: Wed, 8 Jul 2015 06:36:34 +0000 Message-ID: References: <2097EA89-FA00-47BC-A7B0-B93525102DAB@employees.org> In-Reply-To: <2097EA89-FA00-47BC-A7B0-B93525102DAB@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3519218188_116805449" MIME-Version: 1.0 Archived-At: Cc: "homenet@ietf.org" , "draft-ietf-homenet-dncp@tools.ietf.org" , "" Subject: Re: [Int-dir] IntDir review: draft-ietf-homenet-dhcp-07 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 06:36:39 -0000 --B_3519218188_116805449 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Thanks for your review Ole. Cheers Terry On 8/07/2015 4:50 am, "Ole Troan" wrote: >I have been selected as the Internet Directorate reviewer for this >draft. The purpose of the review is to provide assistance to the >Internet ADs. > >Although these comments are primarily for the use of the Internet ADs, >it would be helpful if you could consider them along with any other >IETF Last Call comments that you receive, and strive to resolve them >through discussion or by updating the draft. > >Document: draft-ietf-homenet-dncp-07.txt >Reviewer: Ole Troan >Review Date: July 7 16, 2015 > >The document now reads much better. I do get the impression that the text >is >reverse engineered from code in a few places though. > >Given that it is an "Abstract protocol" specification, that must be >combined with a profile specification to be a fully implementable, it >is somewhat difficult to predict if the specification is complete or >not. Juliusz Chroboczek is writing an independent implementation, and >I'd recommend incorporating the very informative replies the authors have >made to his >comments on the homenet list into the document. > >General comments: >================= >=> Replace no affiliation with "Independent". If that's the case. > >=> It is unclear to me how multiple instances of DNCP is run on a > link. Is that something that must be specified in the profile > document, and each profile must support multiple instances? > Given draft-stenberg-shsp, and the way it "hijacks" the HNCP > profile, it appears that more formal multiple instance support > would be needed. > >=> I can't help being left with the impression that fragmentation > (section 6.3) is underspecified. Can fragmentation be left out of > the protocol for now (and profiles requiring large TLVs can require > a transport layer supporting segmentation and reassembly?) > >=> I do find the text on transport modes somewhat confusing, U, M+U >and MulticastListen+U. I'd like to see more descriptive text > >Abstract: >========= > >OLD: > This document describes the Distributed Node Consensus Protocol > (DNCP), a generic state synchronization protocol which uses Trickle > and Merkle trees. DNCP leaves some details unspecified or provides > alternative options. Therefore, only profiles which specify those > missing parts define actual implementable DNCP-based protocols. > >NEW: > This document describes the Distributed Node Consensus Protocol > (DNCP), a generic state synchronization protocol that uses Trickle > and Merkle trees. DNCP is an abstract protocol, that must be > combined with a specific profile to make a complete implementable > protocol. > >=> The purpose of that change would be to make it clear what this >is. A framework? A component that protocols can be built out of? > >=> Add a reference to Merkle trees? > >Section 4.2: >============ > >=> This is confusing: >o If using a stream transport, the TLV MUST be sent at least once, > and it SHOULD be sent only once. > >OLD: >* If only unreliable unicast transport is employed, Trickle state > is kept per each peer and it is used to send Network State TLVs > every now and then, as specified in Section 4.3. > >NEW: >* If only unreliable unicast transport is used, Trickle state > is kept per peer and it is used to send Network State TLVs > intermittently, as specified in Section 4.3. > >s/every now and then/now and then/ > >s/employed/used/ > >Section 4.3: >============ >=> reference to rfc6206? > > > o the endpoint is in Multicast+Unicast transport mode, in which case > the TLV MUST be sent over multicast. > > o the endpoint is NOT in Multicast+Unicast transport mode, and the > unicast transport is unreliable, in which case the TLV MUST be > sent over unicast. > >=> What do an implementation do if the endpoint is not in M+U >transport mode, and the unicast transport is reliable? > >(I do find the transport modes confusing, and I'm not sure I >understand the MulticastListen mode). > >s/when using also secure unicast/when using secure unicast/ > >Section 4.4: >============ >=> What is meant by: "link with shared bandwidth"? > > > o Any other TLV: TLVs not recognized by the receiver MUST be > silently ignored. > >=> doesn't that mean it isn't stored in the Merkle tree? and the >hashes don't compute? > >Section 4.6: >============ >=> First mention of a topology graph. > >Section 5: >========== > >o Endpoint identifier: the 32-bit opaque value uniquely identifying > it within the local node. > >=> "it"? I think I'm still confused what is an endpoint, what is a >peer and what is a node. > >o Range of addresses: the DNCP nodes that are allowed to connect. > >=> How does a range of addresses look like and how is it used? > I find only one occurence in the document. > >Section 6.1: >============ > A DNCP profile MAY specify either per-endpoint or per-peer keep-alive > support. > >=> Again I'm confused over the usage of endpoint versus peer. >What's the difference between per-peer and per-endpoint keepalives? > >Section 6.2: >============ >s/actually uses/uses/ > > --B_3519218188_116805449 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFORl YoIQ3vK5J7TQsDqKKqtrqv1dMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE1MDcwODA2MzYyOFowDQYJKoZIhvcNAQEBBQAEggEAIfdyBagh+x1mVkuKk2zd kk4slM94u1ZLyofeA/3SYqyhpkehb7NrUKmDx0UFrJKHdyWreBjCKAe6vpNO+XhHl5TpYlGW QFu8pXL2hXqps5AyYyWh/5memJTI1UJUOn2iahgX0oFd9bMxE0OID9jMWaDRBBcgHZL+FKSD 7Xqwjz9K7hnBr9RVA0OZQimLYZEz2ZhDICdq2hCLuXgB5XTv2/4sL7XQjfohFjmLN9RwZ/sy j4G8C5dQpChBqoc+rU2v9bcQPVeygUSpl79mxY622w8+oQKbgGUMb4gw2k1ylfZDlUU/Atht eZfOauENr/vfTLvWVonj7mv+ahDkl2jynw== --B_3519218188_116805449-- From nobody Tue Jul 7 23:37:45 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BCA1B3145; Tue, 7 Jul 2015 23:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 K6rYyO0cgVEw; Tue, 7 Jul 2015 23:37:40 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580FC1B3143; Tue, 7 Jul 2015 23:37:40 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Tue, 7 Jul 2015 23:37:38 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Tue, 7 Jul 2015 23:37:38 -0700 From: Terry Manderson To: Steven Barth , Ole Troan , "ginsberg@cisco.com" Thread-Topic: [homenet] review: draft-ietf-homenet-dhcp-07 Thread-Index: AQHQuP9dGTPAdeseu06lKkGpoVi1wJ3SPCOA Date: Wed, 8 Jul 2015 06:37:37 +0000 Message-ID: References: <2097EA89-FA00-47BC-A7B0-B93525102DAB@employees.org> <559C4A32.5050400@openwrt.org> In-Reply-To: <559C4A32.5050400@openwrt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3519218255_116797519" MIME-Version: 1.0 Archived-At: Cc: "rtg-dir@ietf.org" , "homenet@ietf.org Group" , "int-dir@ietf.org" , "int-ads@tools.ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [Int-dir] [homenet] review: draft-ietf-homenet-dhcp-07 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 06:37:41 -0000 --B_3519218255_116797519 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Thanks Steven, ... as they say 'watching the thread' :-) Cheers Terry On 8/07/2015 7:52 am, "Steven Barth" wrote: >Hello Ole, hello Les, > >thank you both for your reviews. >We will hopefully get back to you with a detailed reply and a list of >changes >we made based on your reviews by next week (due to vacations etc). > > > >Cheers, > > >Steven > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet --B_3519218255_116797519 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFO95 Uq26BtTzpnaBbpD7zitcuKU0MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE1MDcwODA2MzczNVowDQYJKoZIhvcNAQEBBQAEggEAgzSZA0B0b21oJ+HAfrYa 8bA2NW0PGCrRxuUL+ACXLjDrl9RNNrDcvYePZvoAq1XgemkRWbMo+3YHGKxuOkBQZb1Ntvak dM+GwJ2jURT0dif2orOlwZDoAIx6hXxPWHFjHMmKsQS2stao12hnmOT1eiG4lp70fNBKse91 3M9guurkVRYXQ0tu84dajNiqmYiGl2/B5fQuchPExEJBy1j5OpJLaVq63eyjq8d2Kjp35Kh/ Z/Tqc/K3iiAhlhGIOK4j7+GrUx2DCU+jVJTQosmyeumV690GqKpIaj2viQSy1r+M6CV9Kdb8 /0Yp2aTO3XYxwnxXf80QLcCpUgk+DqCycA== --B_3519218255_116797519-- From nobody Thu Jul 9 06:31:55 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DF71AD28D; Thu, 9 Jul 2015 04:28:11 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 g_Ts7aZCrHTh; Thu, 9 Jul 2015 04:28:09 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (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 40FA41AD2EE; Thu, 9 Jul 2015 04:28:05 -0700 (PDT) Received: by lblf12 with SMTP id f12so3694410lbl.2; Thu, 09 Jul 2015 04:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=mWPbeLBajbIsIqcL5PS8KvJ2syx2JR1nDF1y8FcVaNs=; b=SoVcgxLOqKDuiqpL5Q7WT3OFtAOhgbKbWUT21M855GDTOB2veDu2mDug20fPkKYH2B 2uYybD7E1DK7QcUUGCyDn5OJh4ZcSPJ9P9SSu0bzChXatE8fxlI1mcM5bPL7g0CkiUYu J+mtB4txztMiJ8364P8l/Niq89fgERsvBPeMQx9JuKM5+iLstK1v3pLo3r9pxmhTRypH LHFs6J5VQ2K8RmEOCFRvPO9q+VqbR6+uWfginb4B8bxPUyU4fDmoFBEX8/0/m4DQiL0o xpNetaEXyv7cD1inob6YSV5z9s2qUjhJFOTO6YV9AN3tSsCOHAwJ2vTPHjptcHMKYH6G /Vhw== X-Received: by 10.112.163.129 with SMTP id yi1mr14531420lbb.77.1436441283385; Thu, 09 Jul 2015 04:28:03 -0700 (PDT) Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by smtp.googlemail.com with ESMTPSA id y1sm1344635lad.25.2015.07.09.04.28.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2015 04:28:02 -0700 (PDT) Message-ID: <559E5ABD.8040101@gmail.com> Date: Thu, 09 Jul 2015 13:27:57 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: int-ads@ietf.org, int-dir@ietf.org, draft-ietf-roll-mpl-parameter-configuration@tools.ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 09 Jul 2015 06:31:54 -0700 Subject: [Int-dir] Review of draft-ietf-roll-mpl-parameter-configuration X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 11:28:11 -0000 Hi, Brian asked me to review draft-ietf-roll-mpl-parameter-configuration-06. I'm not sure if I was an officially designated reviewer or not, so please treat my comments as regular IETF comments. Disclaimer: I'm DHCP guy and don't have any experience with MPL. Executive Summary: I do not feel the document is ready. It is of high quality, but there are several DHCP issues that should be addressed. I find this document well written, clear and easy to understand. There are certain DHCP aspects that should be improved. I particularly dislike the conditional formatting. Section 1: This document is intended to follow [RFC7227] the guideline. => This document is intended to follow the guideline of [RFC7227]. Section 2: Parameters listed should be described or a reference to their definition or description should be provided. As a DHCP implementor and someone completely unfamiliar with MPL, I'd like to have some basic description of those parameters. They don't need to be very thorough, but if I code support for them, I need to describe them somehow in the software documentation. Also, considering the bounds mentioned in Section 4, it would be useful to have recommended boundaries here. Unnumbered figure in Section 2.1. It should be numbered for easier reference. For fields that spawn multiple lines, DHCP drafts typically omit the inner lines. It's a bit difficult to see the boundaries of MPL Domain Address field. See figure in section 7 of RFC3315 for a nice example. Section 2.1: OPTION_MPL_PARAMETERS: DHCPv6 option identifier (not yet assigned) => OPTION_MPL_PARAMETERS: DHCPv6 option identifier (TBD). IANA finds it very useful to have values yet to be assigned designated as TBD. If there are more than one, please use TBD1, TBD2 etc. Generic question: I'm not familiar with the MPL protocol. Do you envision that there will be additional extensions or refinements defined in the future? Are those extensions likely to be configurable over DHCP? If that is so, you may consider adding support for encapsulated options. To do so, define extra field of unspecified length called encapsulated-options and add a text that encapsulated options MAY be included there. It's good to add a note that although currently there are no such options defined yet, but they may be defined in the future. That's actually pretty important as you allow multiple MPL domains. If you allowed only one, you could get away with simply defining new top level options, but then it would be impossible to say to which MPL domain they apply. I would do it to make the option processing simpler. You have one optional field: MPL Domain Address. Convert it to an encapsulated option. The option, as it stands now, uses conditional formatting (if len=32 parse domain address; else skip it). That's discouraged. See section 6 of RFC7227. As an implementor, I can tell you that adding new options, including encapsulated options is easy. That's something you very often can do with configuration file in existing implementations. That makes your options easier to adopt. Now, if you stick to the conditional formatting, you need dedicated code change. That's something frown upon. And it slows down adoption. Section 2.2 It was mentioned elsewhere, but it would be convenient to add text similar to this: Client MUST be able to process more than one instance in the server's responses. There are multiple uses of SHALL. As a non-native speaker, I think using MUST is easier to understand, especially be those less fluent in English. But I don't insist on it, if you want to keep the text as it is. Section 2.3 "MPL parameters may be updated occasionally. With stateful DHCPv6, updates can be done when the renewal timer expires. Information Refresh Time Option [RFC4242] shall be used to keep each forwarder updated." Is MPL client expected to use stateful (addresses and/or prefixes), stateless (just options) DHCP or both? Information Refresh Time Option is typically used for stateless. If your client gets prefixes or addresses, the renewal time is governed by T1 timer in respective IA containers (IA_NA or IA_PD), so there's no need for Information Refresh Time Option. Section 2.6 "A parameter set for an MPL domain SHOULD NOT be updated more often than twice of Information Refresh Time, even if the clients use longer Information Refresh Time to reduce DHCPv6 load on the network." That's doesn't seem right. If you don't want the parameters to be updated frequently, use lower T1 or Info Refrest Time values. May existing DHCP clients are flexible and could handle processing new options like this one without the source code being altered. They typically have the option format defined in their configuration file and call external script when the option is received. They can't do anything like ignore every second reception of the option. It doesn't make sense anyway. Section 4, second paragraph As a DHCP implementor, I don't understand what bounds I'm supposed to implement for the parameters. Section 4, third paragraph "The DHCP server or the network itself should be trusted by some means such as DHCPv6 authentications described in Section 21 of RFC3315 [RFC3315]." I'm not sure if you're aware of the RFC3315bis intiative (see draft-ietf-dhc-rfc3315bis for details). Please note the absence of delayed authentication protocol, that is in the process of being deprecated. Currently there's work in progress to define strong authentication in DHCPv6 in draft draft-ietf-dhc-sedhcpv6-08. It's with IESG now and should hopefully be published soon. You may reference that as well. Hope that helps. Tomek From nobody Thu Jul 9 09:25:10 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3EE1A903E; Thu, 9 Jul 2015 09:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 MWBtcMnp7Q7m; Thu, 9 Jul 2015 09:25:02 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676DD1B2A49; Thu, 9 Jul 2015 09:25:02 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 4A20288135; Thu, 9 Jul 2015 09:25:02 -0700 (PDT) Received: from brians-mbp.jhuapl.edu (swifi-nat.jhuapl.edu [128.244.87.133]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id CD9603520395; Thu, 9 Jul 2015 09:25:01 -0700 (PDT) To: Tomek Mrugalski , int-ads@ietf.org, int-dir@ietf.org References: <559E5ABD.8040101@gmail.com> From: Brian Haberman Message-ID: <559EA05C.8060301@innovationslab.net> Date: Thu, 9 Jul 2015 12:25:00 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <559E5ABD.8040101@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Cjq7fFEN0lhhT9wMIAhQCJlw66OGmviXH" Archived-At: Subject: Re: [Int-dir] Review of draft-ietf-roll-mpl-parameter-configuration X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 16:25:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Cjq7fFEN0lhhT9wMIAhQCJlw66OGmviXH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks, Tomek! Brian On 7/9/15 7:27 AM, Tomek Mrugalski wrote: > Hi, >=20 > Brian asked me to review draft-ietf-roll-mpl-parameter-configuration-06= =2E > I'm not sure if I was an officially designated reviewer or not, so > please treat my comments as regular IETF comments. >=20 > Disclaimer: I'm DHCP guy and don't have any experience with MPL. >=20 > Executive Summary: I do not feel the document is ready. It is of high > quality, but there are several DHCP issues that should be addressed. >=20 > I find this document well written, clear and easy to understand. There > are certain DHCP aspects that should be improved. I particularly dislik= e > the conditional formatting. >=20 > Section 1: > This document is intended to follow [RFC7227] the guideline. =3D> > This document is intended to follow the guideline of [RFC7227]. >=20 > Section 2: > Parameters listed should be described or a reference to their > definition or description should be provided. As a DHCP implementor > and someone completely unfamiliar with MPL, I'd like to have > some basic description of those parameters. They don't need > to be very thorough, but if I code support for them, I need to > describe them somehow in the software documentation. Also, considering > the bounds mentioned in Section 4, it would be useful to have > recommended boundaries here. >=20 > Unnumbered figure in Section 2.1. It should be numbered for easier > reference. >=20 > For fields that spawn multiple lines, DHCP drafts typically omit > the inner lines. It's a bit difficult to see the boundaries of > MPL Domain Address field. See figure in section 7 of RFC3315 for > a nice example. >=20 > Section 2.1: > OPTION_MPL_PARAMETERS: DHCPv6 option identifier (not yet assigned) =3D= > > OPTION_MPL_PARAMETERS: DHCPv6 option identifier (TBD). >=20 > IANA finds it very useful to have values yet to be assigned designated > as TBD. If there are more than one, please use TBD1, TBD2 etc. >=20 > Generic question: > I'm not familiar with the MPL protocol. Do you envision that there > will be additional extensions or refinements defined in the future? > Are those extensions likely to be configurable over DHCP? If that > is so, you may consider adding support for encapsulated options. > To do so, define extra field of unspecified length called > encapsulated-options and add a text that encapsulated options MAY > be included there. It's good to add a note that although currently > there are no such options defined yet, but they may be defined in the > future. >=20 > That's actually pretty important as you allow multiple MPL domains. > If you allowed only one, you could get away with simply defining new > top level options, but then it would be impossible to say to which > MPL domain they apply. >=20 > I would do it to make the option processing simpler. You have one > optional field: MPL Domain Address. Convert it to an encapsulated > option. The option, as it stands now, uses conditional formatting > (if len=3D32 parse domain address; else skip it). That's discouraged. > See section 6 of RFC7227. >=20 > As an implementor, I can tell you that adding new options, including > encapsulated options is easy. That's something you very often can > do with configuration file in existing implementations. That makes > your options easier to adopt. Now, if you stick to the conditional > formatting, you need dedicated code change. That's something frown > upon. And it slows down adoption. >=20 > Section 2.2 > It was mentioned elsewhere, but it would be convenient to add text > similar to this: Client MUST be able to process more than one instance > in the server's responses. >=20 > There are multiple uses of SHALL. As a non-native speaker, I think > using MUST is easier to understand, especially be those less > fluent in English. But I don't insist on it, if you want to keep the > text as it is. >=20 > Section 2.3 > "MPL parameters may be updated occasionally. With stateful DHCPv6, > updates can be done when the renewal timer expires. Information > Refresh Time Option [RFC4242] shall be used to keep each forwarder > updated." > Is MPL client expected to use stateful (addresses and/or prefixes), > stateless (just options) DHCP or both? Information Refresh Time Option > is typically used for stateless. If your client gets prefixes or > addresses, the renewal time is governed by T1 timer in respective > IA containers (IA_NA or IA_PD), so there's no need for Information > Refresh Time Option. >=20 > Section 2.6 > "A parameter set for an MPL domain SHOULD NOT be updated more often > than twice of Information Refresh Time, even if the clients use > longer Information Refresh Time to reduce DHCPv6 load on the > network." > That's doesn't seem right. If you don't want the parameters to be > updated frequently, use lower T1 or Info Refrest Time values. May > existing DHCP clients are flexible and could handle processing new > options like this one without the source code being altered. They > typically have the option format defined in their configuration file an= d > call external script when the option is received. They can't do anythin= g > like ignore every second reception of the option. It doesn't make sense= > anyway. >=20 > Section 4, second paragraph > As a DHCP implementor, I don't understand what bounds I'm supposed to > implement for the parameters. >=20 > Section 4, third paragraph > "The DHCP server or the network itself should be trusted by some mean= s > such as DHCPv6 authentications described in Section 21 of RFC3315 > [RFC3315]." > I'm not sure if you're aware of the RFC3315bis intiative (see > draft-ietf-dhc-rfc3315bis for details). Please note the absence of > delayed authentication protocol, that is in the process of being > deprecated. Currently there's work in progress to define strong > authentication in DHCPv6 in draft draft-ietf-dhc-sedhcpv6-08. It's with= > IESG now and should hopefully be published soon. You may reference that= > as well. >=20 > Hope that helps. >=20 > Tomek >=20 --Cjq7fFEN0lhhT9wMIAhQCJlw66OGmviXH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJVnqBcAAoJEBOZRqCi7goqFhEH/jheYiHel1KzA2UUrM1ucVKu RoNjuJHbv84+Sx83zU9grEkabD7b0q47cUER+PY623BFYoGgJl+9pLejhmcDjIrh KfsKZRuo+uIlH6C+bum2Pyt1R6opWwQAYMnH2tkWtTwrk1tdcG/qQgb0FbQVjGlb 0HjSOnfSwq4bzfX4ruUSGW8GQv8DmpGkkunk6ZA5AcBBe03cAPc0LTsT5gIHPERh IpRfTj8GLfhWcw6DrpZgzFlGpUiflFXkT21nQ14MOOQZ6qWpzUJC2AGnsxPftyEp A/vp6etwDj9xDwcKLUpkNZ1j0HnmO5Z+UVu7p/gst4IsXdCKG/tp0pkllNxH2Bw= =xOy2 -----END PGP SIGNATURE----- --Cjq7fFEN0lhhT9wMIAhQCJlw66OGmviXH-- From nobody Mon Jul 13 05:42:02 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F421ACEF1; Sun, 12 Jul 2015 08:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.75 X-Spam-Level: * X-Spam-Status: No, score=1.75 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, J_CHICKENPOX_21=0.6] autolearn=no 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 b-iG4whhsca3; Sun, 12 Jul 2015 08:05:37 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 5984A1ACEEF; Sun, 12 Jul 2015 08:05:37 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1ZEIou-0005lc-Gi with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Sun, 12 Jul 2015 17:05:32 +0200 Message-ID: <55A2823D.5050008@openwrt.org> Date: Sun, 12 Jul 2015 17:05:33 +0200 From: Steven Barth User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ole Troan , int-ads@tools.ietf.org References: <2097EA89-FA00-47BC-A7B0-B93525102DAB@employees.org> In-Reply-To: <2097EA89-FA00-47BC-A7B0-B93525102DAB@employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Mon, 13 Jul 2015 05:42:00 -0700 Cc: "homenet@ietf.org Group" , draft-ietf-homenet-dncp@tools.ietf.org, "" Subject: Re: [Int-dir] IntDir review: draft-ietf-homenet-dhcp-07 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 15:05:39 -0000 Hello Ole, thanks again for your review and sorry for the delay. Please find replies inline. Cheers, Steven & Markus > > Given that it is an "Abstract protocol" specification, that must be > combined with a profile specification to be a fully implementable, it > is somewhat difficult to predict if the specification is complete or > not. Juliusz Chroboczek is writing an independent implementation, and > I'd recommend incorporating the very informative replies the authors have made to his > comments on the homenet list into the document. -07 already included some of them and we've staged a few more for -08. > General comments: > ================= > => Replace no affiliation with "Independent". If that's the case. Done. > => It is unclear to me how multiple instances of DNCP is run on a > link. Is that something that must be specified in the profile > document, and each profile must support multiple instances? > Given draft-stenberg-shsp, and the way it "hijacks" the HNCP > profile, it appears that more formal multiple instance support > would be needed. Hmm, I think this is up to the specific protocol. Reuse of profiles is in theory possible but for standardisation would require either one protocol updating the other OR distinct TLV-spaces. The latter sounds a bit awkward e.g. IANA-wise. In any case , when sharing transport details such as port numbers, then a shared registry would need to be done anyway. SHSP should probably not be seen as a good example here. Since DNCP does not define defaults here an extra identifier seems unncessary and could or should probably be specified by the derived protocol. > > => I can't help being left with the impression that fragmentation > (section 6.3) is underspecified. Can fragmentation be left out of > the protocol for now (and profiles requiring large TLVs can require > a transport layer supporting segmentation and reassembly?) Agreed. > > => I do find the text on transport modes somewhat confusing, U, M+U > and MulticastListen+U. I'd like to see more descriptive text Okay, we will prepare something for -08. > Abstract: > ========= > > OLD: > This document describes the Distributed Node Consensus Protocol > (DNCP), a generic state synchronization protocol which uses Trickle > and Merkle trees. DNCP leaves some details unspecified or provides > alternative options. Therefore, only profiles which specify those > missing parts define actual implementable DNCP-based protocols. > > NEW: > This document describes the Distributed Node Consensus Protocol > (DNCP), a generic state synchronization protocol that uses Trickle > and Merkle trees. DNCP is an abstract protocol, that must be > combined with a specific profile to make a complete implementable > protocol. Done. > => Add a reference to Merkle trees? I'm not certain what would be a good source to quote here, maybe Merkle's paper from '87 or the ‘92 patent? At least there doesn't seem to be a really appropriate reference. > Section 4.2: > ============ > > => This is confusing: > o If using a stream transport, the TLV MUST be sent at least once, > and it SHOULD be sent only once. I staged "If using a stream transport, the TLV MUST be sent at least once per connection, but SHOULD NOT be sent more than once." for now. > > OLD: > * If only unreliable unicast transport is employed, Trickle state > is kept per each peer and it is used to send Network State TLVs > every now and then, as specified in Section 4.3. > > NEW: > * If only unreliable unicast transport is used, Trickle state > is kept per peer and it is used to send Network State TLVs > intermittently, as specified in Section 4.3. > > s/every now and then/now and then/ > > s/employed/used/ > > Section 4.3: > ============ > => reference to rfc6206? All done. > > > o the endpoint is in Multicast+Unicast transport mode, in which case > the TLV MUST be sent over multicast. > > o the endpoint is NOT in Multicast+Unicast transport mode, and the > unicast transport is unreliable, in which case the TLV MUST be > sent over unicast. > > => What do an implementation do if the endpoint is not in M+U > transport mode, and the unicast transport is reliable? Section 4.2 states "If only reliable unicast transport is employed, Trickle is not used at all." for unicast mode and ML+U mode references that as well. > > (I do find the transport modes confusing, and I'm not sure I > understand the MulticastListen mode). These modes, especially the listen one is only used for Dense Broadcast Link optimization. It is essentially the same as unicast, however the node listens for multicast traffic to detect the presence or abscence of a node with higher identifier on the underlying multicast-capable link. > > s/when using also secure unicast/when using secure unicast/ Done. > > Section 4.4: > ============ > => What is meant by: "link with shared bandwidth"? I changed it to "multiple access link" for now, I think that makes it more clear. > o Any other TLV: TLVs not recognized by the receiver MUST be > silently ignored. > > => doesn't that mean it isn't stored in the Merkle tree? and the > hashes don't compute? "Any other TLV" was intended do be applied to top-level TLVs only. Actual data TLVs are part of Node State TLVs and thus not meant here. Nevertheless I proposed "TLVs not recognized by the receiver MUST be silently ignored unless they are sent as part of the payload of one of the TLVs above (such as TLVs in the Node Data field of a Node State TLV)." > Section 4.6: > ============ > => First mention of a topology graph. It should be defined in the topology. > Section 5: > ========== > > o Endpoint identifier: the 32-bit opaque value uniquely identifying > it within the local node. Changed to "Endpoint identifier: the 32-bit opaque value uniquely identifying the endpoint within the local node." > > => "it"? I think I'm still confused what is an endpoint, what is a > peer and what is a node. I propose the following endpoint definition: "a locally configured communication endpoint of a DNCP node, such as a network socket. An endpoint may be bound to a set of predefined unicast Addresses representing remote DNCP nodes to individually connect to or to accept connections from whereby communication with each node is separated (e.g., an individual unicast UDP message flow per remote node). An endpoint may also be bound to a whole network interface, then multicast communication is used (in addition to individual unicast flows) to send certain messages to all DNCP nodes connected therewith at once as well as to automatically discover new DNCP nodes." > o Range of addresses: the DNCP nodes that are allowed to connect. > > => How does a range of addresses look like and how is it used? > I find only one occurence in the document. I changed it to "Set of addresses: the DNCP nodes from which connections are accepted." This should also align a bit better with the new endpoint definition. An example here would be a DNCP node which just listens on a port for incoming connections then that set would be, e.g., all IPv6 addresses for this node. On the other end the node connecting to it would have the addresses of the first node included in this set. > Section 6.1: > ============ > A DNCP profile MAY specify either per-endpoint or per-peer keep-alive > support. > > => Again I'm confused over the usage of endpoint versus peer. > What's the difference between per-peer and per-endpoint keepalives? I changed it to "A DNCP profile MAY specify either per-endpoint (sent using multicast to all DNCP nodes connected therewith) or per-peer (sent using unicast to each peer individually) keep-alive support." > > Section 6.2: > ============ > s/actually uses/uses/ Done. From nobody Mon Jul 13 05:42:03 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E75E1A893C; Sun, 12 Jul 2015 13:16:15 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 m07g1ZFdv9bM; Sun, 12 Jul 2015 13:16:13 -0700 (PDT) Received: from mail-pa0-x242.google.com (mail-pa0-x242.google.com [IPv6:2607:f8b0:400e:c03::242]) (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 B35AA1A8934; Sun, 12 Jul 2015 13:16:13 -0700 (PDT) Received: by paciu1 with SMTP id iu1so13082365pac.0; Sun, 12 Jul 2015 13:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2n9FCuOGaFNRXuVmAOV441roOMxbw1nxinvEzeYbm50=; b=i6SSvglXesglgNO0hL0HcYrJT+zIaq5xIYgTbM5jtv9vTUcgLUr6Rs3jRaeKEMcXkG di+RSnL6Ojvp0oZf7KEGwPkJukK7ej/J2qZVzGQn8CndvNLvEMfLeEI3lMfQtb+rYiib biWkvA5L1FRM4GJKU5w8AoHv1Ap0XHRPRvHAkOUADILw/9ARkfZwmKNKzuetUAOfKeH2 V4MHVUGEHGhW8fk3kR74k0/HKTyuqsKsr9T3tC88humKNcava94uRDtF5vP29RsqmMe7 omcfd9Dd6WrffKuKbP6wiXiD7S9D9bjCD38MhbFc6FDNJnqsF86kPer2jDmDapOfgCWB PSIg== X-Received: by 10.70.65.99 with SMTP id w3mr63341459pds.132.1436732173394; Sun, 12 Jul 2015 13:16:13 -0700 (PDT) Received: from ?IPv6:2406:e007:4be4:1:28cc:dc4c:9703:6781? ([2406:e007:4be4:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id k3sm16412675pde.18.2015.07.12.13.16.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Jul 2015 13:16:12 -0700 (PDT) Message-ID: <55A2CB05.4020708@gmail.com> Date: Mon, 13 Jul 2015 08:16:05 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Steven Barth , Ole Troan , int-ads@tools.ietf.org References: <2097EA89-FA00-47BC-A7B0-B93525102DAB@employees.org> <55A2823D.5050008@openwrt.org> In-Reply-To: <55A2823D.5050008@openwrt.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Mon, 13 Jul 2015 05:42:00 -0700 Cc: "homenet@ietf.org Group" , draft-ietf-homenet-dncp@tools.ietf.org, "" Subject: Re: [Int-dir] [homenet] IntDir review: draft-ietf-homenet-dhcp-07 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 20:16:15 -0000 On 13/07/2015 03:05, Steven Barth wrote: > Hello Ole, =2E.. >> =3D> Add a reference to Merkle trees? > I'm not certain what would be a good source to quote here, maybe Merkle= 's > paper from '87 or the =E2=80=9892 patent? At least there doesn't seem t= o be > a really appropriate reference. His PhD thesis seems to be the best formal reference: www.merkle.com/papers/Thesis1979.pdf http://dl.acm.org/citation.cfm?id=3D909000 If you want to actually know what a Merkle tree is: https://en.wikipedia.org/wiki/Merkle_tree Brian From nobody Mon Jul 13 05:42:05 2015 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01081A896F; Sun, 12 Jul 2015 13:24:28 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 vipkWQM3TW4Q; Sun, 12 Jul 2015 13:24:27 -0700 (PDT) Received: from mail-pa0-x243.google.com (mail-pa0-x243.google.com [IPv6:2607:f8b0:400e:c03::243]) (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 653581A8963; Sun, 12 Jul 2015 13:24:27 -0700 (PDT) Received: by pactm7 with SMTP id tm7so26843988pac.1; Sun, 12 Jul 2015 13:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RvnbcXt3W6sjx7LADU4vwMHnqovBSY+mb+1R05fYZGs=; b=oOiCpqCD2lo/88ioZckTVwJu4Bf/TYe3Ol/MkVb/r5u2sS5GXmgnbPmxxOwdUZswtU +OlFbmPAujgTAPHTpos97SknBnVpRBgq80cUcdP0FiaR3gVMoc0RAR3vDizHTfkINeuH F5ubWJwHt/oxwTmZtgtbqvjcwvz3/P7Ekc/xU1/N2X26Xn3/8utS69QRX1d+x0meRYDJ PYp2KJMSH3D+MCwYSyklVuEBDgEkjpFwJNTcDYwRAKy69D1qAAj8Kgm3zwZoOjb7+ko5 zeS3l1hoLBnIBrTaOkBJFw+6FR30g+2mLh9lqX75eH13tu8Xe82XjZDJwALsstziYSSI WfOg== X-Received: by 10.68.125.234 with SMTP id mt10mr19816820pbb.107.1436732667079; Sun, 12 Jul 2015 13:24:27 -0700 (PDT) Received: from ?IPv6:2406:e007:4be4:1:28cc:dc4c:9703:6781? ([2406:e007:4be4:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id w3sm9886607pdl.45.2015.07.12.13.24.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Jul 2015 13:24:25 -0700 (PDT) Message-ID: <55A2CCF4.30000@gmail.com> Date: Mon, 13 Jul 2015 08:24:20 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Steven Barth , Ole Troan , int-ads@tools.ietf.org References: <2097EA89-FA00-47BC-A7B0-B93525102DAB@employees.org> <55A2823D.5050008@openwrt.org> In-Reply-To: <55A2823D.5050008@openwrt.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Mon, 13 Jul 2015 05:42:00 -0700 Cc: "homenet@ietf.org Group" , draft-ietf-homenet-dncp@tools.ietf.org, "" Subject: Re: [Int-dir] [homenet] IntDir review: draft-ietf-homenet-dhcp-07 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is for discussion between the members of the Internet Area directorate." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2015 20:24:28 -0000 On 13/07/2015 03:05, Steven Barth wrote: ... >> => It is unclear to me how multiple instances of DNCP is run on a >> link. Is that something that must be specified in the profile >> document, and each profile must support multiple instances? >> Given draft-stenberg-shsp, and the way it "hijacks" the HNCP >> profile, it appears that more formal multiple instance support >> would be needed. > Hmm, I think this is up to the specific protocol. Reuse of profiles > is in theory possible but for standardisation would require either > one protocol updating the other OR distinct TLV-spaces. The latter > sounds a bit awkward e.g. IANA-wise. I don't see it as 'awkward', it just means being very systematic. > In any case , when sharing > transport details such as port numbers, then a shared registry would > need to be done anyway. That is the assumption in the current design of GDNP, which isn't even a DNCP profile but simply a protocol assumed to co-exist with DNCP. Whether reliance on a fiddly IANA registry is a good thing is of course a valid question, which we will definitely have to debate in Anima. Brian