From nobody Thu Jan 5 23:15:16 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52F5129C21; Thu, 5 Jan 2017 23:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUcWolv7rEMT; Thu, 5 Jan 2017 23:15:13 -0800 (PST) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::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 C6ED1128BA2; Thu, 5 Jan 2017 23:15:13 -0800 (PST) Received: by mail-pg0-x243.google.com with SMTP id g1so43181849pgn.0; Thu, 05 Jan 2017 23:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=LrwntxkQVkLbDxb3F0qPLcloediKbgUB3L4bOdaHxqg=; b=QSCStFrQxhv6xThozo76jHz4+7dnfcNplMXDyFXuj1zE+Ryi4iqpZbaAyYidRwMywP qYg8TOIRri+5X9L64hHbNJSHmNqsuMSjlztJabeaipVtZAYTED6VNqGBphBHlq/YsMHc pKLPCPy4j1WDOntW5ztWDxFvz7EAM5NfEztWtAnQ5e7bGi7R1IeL4z7+UequSwAPKiAd P0Bi+BJ3XV7+ZA3PWvm6ymI9d4ZigaEnPRjKhtWkFyhnCI6BOSwdQPVCm1yS1E/CY11A mVxMEb44XRrd20XLBMpGk+9i+G3yoQh0CbSJv3lRtpo9hz4XJA5N9pCScFGpea4EXKQ+ 25Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LrwntxkQVkLbDxb3F0qPLcloediKbgUB3L4bOdaHxqg=; b=RmAC5wcfqBBpBwnQZePi46vg0+Nj3bYzq4Bl7YJILZSd3AkTvnEcc6ikfOTD4sUlYu 7EGVg9q8GP1WJI2mrs+4bC3zbikXjZlnwrl3JGTtpL1ulMmTKJatPNi7C14WoiSTjqKP YRKVYj3rqUsVsJm+6DCNTTdXvf0/OPCCZXw8190fIS3zwWQpoMdCNGLJpQ9MQJyO/deU a8YBM8osare3kBewQ2NxVyIqj1+09Tmhz2HvrQcg24Y08ofyeOyhaZWqZmYo6362Hty1 GSsZ+1byEH/6q3scVc+3WykOVcq1GmrzZTaNp11rMzPNNM9lMX7LXQrAs4MmNkvH4Z3U W1hQ== X-Gm-Message-State: AIkVDXJLjvUIaMoMaXH3lgm6ChX6XNAbMFJPcWDSh2CZbgmwFGoMFRiE4XWc8W/aEWqp5Q== X-Received: by 10.84.172.67 with SMTP id m61mr161940875plb.60.1483686913351; Thu, 05 Jan 2017 23:15:13 -0800 (PST) Received: from [10.0.1.20] ([121.152.87.242]) by smtp.gmail.com with ESMTPSA id j130sm134138439pgc.2.2017.01.05.23.15.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2017 23:15:11 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7C1CF441-30A3-4DFA-B4C6-0369364C08DF" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Jong-Hyouk Lee In-Reply-To: <148217252412.12729.10717391067512660347.idtracker@ietfa.amsl.com> Date: Fri, 6 Jan 2017 16:15:07 +0900 Message-Id: References: <148217252412.12729.10717391067512660347.idtracker@ietfa.amsl.com> To: Jean-Michel Combes X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ietf-dmm-hnprenum.all@ietf.org, ietf@ietf.org, dmm@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] [DMM] Review of draft-ietf-dmm-hnprenum-03 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jan 2017 07:15:15 -0000 --Apple-Mail=_7C1CF441-30A3-4DFA-B4C6-0369364C08DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Jean-Michel Thanks for your kind comments. We have revised the draft and uploaded = it: https://tools.ietf.org/html/draft-ietf-dmm-hnprenum-04 = Plz see inline then. -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On 20 Dec 2016, at 3:35 AM, Jean-Michel Combes = wrote: >=20 > Reviewer: Jean-Michel Combes > Review result: Ready with Issues >=20 > Hi, >=20 > First, this is the first time I am trying this new tool for reviewers, > so, sorry if I am making process mistakes. >=20 > Please find the official text below: > > I am an assigned INT directorate reviewer for > draft-ietf-dmm-hnprenum-03. 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. >=20 >=20 > Please, find my review below: >=20 > *** Section 1, p2 *** > "However, a widespread use of PI addresses may cause Border Gateway > Protocol (BGP) scaling problems." > Any Ref? Thx for your point. The related reference (RFC7010) from 6renum WG has = been added in the revised draft (-04). >=20 > *** Section 7, p6 *** > "The protection of UPN and UPA messages in this document follows > [RFC5213] and [RFC7077]. This extension causes no further security > problem." >=20 > Sorry but, I must admit I don't agree: >=20 > [RFC5213] says: > "The Mobile IPv6 specification [RFC3775] requires the home agent to > prevent a mobile node from creating security associations or creating > binding cache entries for another mobile node's home address. In the > protocol described in this document, the mobile node is not involved > in creating security associations for protecting the signaling > messages or sending binding updates. Therefore, the local mobility > anchor MUST restrict the creation and manipulation of proxy bindings > to specifically authorized mobile access gateways and prefixes. The > local mobility anchor MUST be locally configurable to authorize such > specific combinations. Additional mechanisms, such as a policy store > or Authentication, Authorization, and Accounting (AAA) may be > employed, but these are outside the scope of this specification." >=20 > Based on the fact that an operator could set up internal check-ups > about the allowed HNP(s) for the MN, there could be strong > restrictions (e.g., not allowed roaming between operators) about the > mechanism described inside this document. >=20 > So, IMHO, additional text is needed regarding this point. Thx for your comment. As you mentioned, unlike MIPv6, PMIPv6 does not = allow the MN to be involved in creating security associations or = creating binding cache entries. The LMA assigns the HNP for the MN. The = assignment of the valid HNP is a responsibility of the LMA in PMIPv6.=20 To reflect your comment, we have revised a bit Section 7 (Security = Considerations) as: "The protection of UPN and UPA messages in this = document follows [RFC5213] and [RFC7077]. This extension thus causes no = further security problems for protecting of the messages.=E2=80=9D In = addition, we have added the following sentence in Section 6 (Other = Issues): "The LMA must assign only an authorized HNP for the MN.=E2=80=9D Thanks! >=20 > Best regards, >=20 > JMC. >=20 > >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm --Apple-Mail=_7C1CF441-30A3-4DFA-B4C6-0369364C08DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Jean-Michel

Thanks for your kind comments. We have revised the draft and = uploaded it: https://tools.ietf.org/html/draft-ietf-dmm-hnprenum-04

Plz see inline = then.

--
Jong-Hyouk Lee, living somewhere between /dev/null = and /dev/random
Protocol Engineering Lab., = Sangmyung University

#email: jonghyouk@gmail.com
#webpage: https://sites.google.com/site/hurryon

On 20 Dec 2016, at 3:35 AM, Jean-Michel Combes <jeanmichel.combes@orange.com> wrote:

Reviewer: Jean-Michel Combes
Review result: = Ready with Issues

Hi,

First, this is the first time I am trying this new tool for = reviewers,
so, sorry if I am making process mistakes.

Please find the official text below:
<JMC>
I am an assigned INT directorate = reviewer for
draft-ietf-dmm-hnprenum-03. 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.


Please, find my review = below:

*** Section 1, p2 ***
"However, a widespread use of PI addresses may cause Border = Gateway
Protocol (BGP) scaling problems."
Any = Ref?

Thx for your point. The related reference = (RFC7010) from 6renum WG has been added in the revised draft = (-04).


*** Section 7, p6 ***
"The protection of UPN and UPA messages in this document = follows
[RFC5213] and [RFC7077].  This extension = causes no further security
problem."

Sorry but, I must admit I don't agree:

[RFC5213] says:
"The Mobile IPv6 specification = [RFC3775] requires the home agent to
prevent a mobile node = from creating security associations or creating
binding = cache entries for another mobile node's home address. In the
protocol described in this document, the mobile node is not = involved
in creating security associations for protecting = the signaling
messages or sending binding updates. = Therefore, the local mobility
anchor MUST restrict the = creation and manipulation of proxy bindings
to = specifically authorized mobile access gateways and prefixes. The
local mobility anchor MUST be locally configurable to = authorize such
specific combinations.  Additional = mechanisms, such as a policy store
or Authentication, = Authorization, and Accounting (AAA) may be
employed, but = these are outside the scope of this specification."

Based on the fact that an operator could set up internal = check-ups
about the allowed HNP(s) for the MN, there could = be strong
restrictions (e.g., not allowed roaming between = operators) about the
mechanism described inside this = document.

So, IMHO, additional text is = needed regarding this point.

Thx = for your comment. As you mentioned, unlike MIPv6, PMIPv6 does not allow = the MN to be involved in creating security associations or creating = binding cache entries. The LMA assigns the HNP for the MN. The = assignment of the valid HNP is a responsibility of the LMA in = PMIPv6. 

To reflect your = comment, we have revised a bit Section 7 (Security Considerations) as: = "The protection of UPN and UPA messages in this document follows = [RFC5213] and [RFC7077].  This extension thus causes no further = security problems for protecting of the messages.=E2=80=9D In addition, = we have added the following sentence in Section 6 (Other Issues): "The = LMA must assign only an authorized HNP for the MN.=E2=80=9D

Thanks!


Best regards,

JMC.

</JMC>


_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

= --Apple-Mail=_7C1CF441-30A3-4DFA-B4C6-0369364C08DF-- From nobody Fri Jan 6 11:08:49 2017 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B63129611; Fri, 6 Jan 2017 11:08:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tatuya Jinmei To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148372972401.17454.8580929833890158319.idtracker@ietfa.amsl.com> Date: Fri, 06 Jan 2017 11:08:44 -0800 Archived-At: Cc: draft-ietf-dmm-4283mnids.all@ietf.org, ietf@ietf.org, dmm@ietf.org Subject: [Int-dir] Review of draft-ietf-dmm-4283mnids-03 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 06 Jan 2017 19:08:44 -0000 Reviewer: Tatuya Jinmei Review result: Ready with Nits I am an assigned INT directorate reviewer for draft-ietf-dmm-4283mnids. 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. I've reviewed the 03 version of the draft. I didn't find anything obviously wrong/incorrect, and it's generally well-written. So I think it's basically ready for ship. But I'd have to note that I'm not familiar with many of the lower-layer technologies referenced in the draft, so my review and conclusion are somewhat superficial. I found some minor points. The authors may want to address them: - Section 4.1: I guess the MNID is generally supposed to be unique (at least in the realm the ID is used), but not all IPv6 addresses are guaranteed to be unique (a link-local or unspecified address is an obvious example, an ULA may also be inappropriate depending on the usage context). It may be better to note the fact, and you may also want to impose some restrictions on the type of address that can be used as an MNID. - Section 4.5 2000, modulo 2^32. Since the link-layer address can be of variable length [RFC2464], the DUID-LLT is of variable length. I don't understand why RFC2464 is referenced in this context. This RFC is about IPv6 over Ethernet, and assumes a fixed (6 bytes) length of hardware address. - Section 4.9: s/is (GRAI)/(GRAI)/ The Global Returnable Asset Identifier is (GRAI) is defined by the From nobody Mon Jan 9 18:02:14 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6241129A35; Mon, 9 Jan 2017 18:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ybrQo5boEixb; Mon, 9 Jan 2017 18:02:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A37B129A2F; Mon, 9 Jan 2017 18:02:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYN00601; Tue, 10 Jan 2017 02:02:08 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 10 Jan 2017 02:02:07 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 10 Jan 2017 10:01:00 +0800 From: Sheng Jiang To: "int-dir@ietf.org" Thread-Topic: Review of draft-ietf-softwire-multicast-prefix-option Thread-Index: AdJq5VTi9A6ti/+aRFSoOq3vqZfY/Q== Date: Tue, 10 Jan 2017 02:00:49 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CC7F762@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CC7F762NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.587440A0.022D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 22ca00bbc7c8b039ffb674203981c866 Archived-At: Cc: "softwire@ietf.org" , "draft-ietf-softwire-multicast-prefix-option.all@ietf.org" Subject: [Int-dir] Review of draft-ietf-softwire-multicast-prefix-option X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jan 2017 02:02:13 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CC7F762NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reviewer: Sheng Jiang Review result: Almost Ready I am an assigned INT directorate reviewer for draft-ietf-dhc-dhcpv6-failove= r-protocol-03. 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 alo= ng with any other Last Call comments that have been received. For more details on the INT Directorate, see http://www.ietf.org/iesg/direc= torate.html. Review Date:2017-1-10 IETF LC End Date: 2017-1-12 IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC= . Major issues: Minor issues: "the specification of a DHCPv6 option that could be used to discover unicast PREFIX64s in environments where multicast is not enabled. Such side effect conflicts with the recommendation documented in Section 6 of [RFC7051]." It is unclear how the Section 6 of RFC7051 relevant with the content above.= It would be necessary to quote particular content of RFC7051 and give nece= ssary analysis. Nits: "the Pv4 multicast address is inserted in the last 32 bits of the IPv4-embe= dded IPv6 multicast address." Pv4//IPv4 Regards, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B927CC7F762NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reviewer: Sheng Jiang

Review result: Almost Ready<= o:p>

 

I am an assigned INT directo= rate reviewer for draft-ietf-dhc-dhcpv6-failover-protocol-03. These comment= s were written primarily for the benefit of the Internet Area Directors.

Document editors and shepher= d(s) should treat these comments just like they would treat comments from a= ny 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/i= esg/directorate.html.

 

Review Date:2017-1-10

IETF LC End Date: 2017–= 1-12

IESG Telechat date:

 

Summary: This draft is almos= t ready for publication as a standard track RFC.

 

Major issues:

 

Minor issues:

 

“the specification of a DHCPv6 option th= at could be used to discover
   unicast PREFIX64s in environments where multicast is not enabl= ed.
   Such side effect conflicts with the recommendation documented = in
   Section 6 of [RFC7051].”

 

It is unclear how the Section 6 of RFC7051 relevant with the content above.= It would be necessary to quote particular content of RFC7051 and give nece= ssary analysis.

 

Nits:

 

“the Pv4 multicast address is inserted i= n the last 32 bits of the IPv4-embedded IPv6
   multicast address.”

 

Pv4//IPv4<= /p>

 

Regards,

 

Sheng

--_000_5D36713D8A4E7348A7E10DF7437A4B927CC7F762NKGEML515MBXchi_-- From nobody Mon Jan 9 19:36:46 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8831295B9; Mon, 9 Jan 2017 19:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 14EdLYGYGloT; Mon, 9 Jan 2017 19:36:43 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76BDA1296F3; Mon, 9 Jan 2017 19:36:43 -0800 (PST) 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.1178.4; Mon, 9 Jan 2017 19:36:40 -0800 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.1178.000; Mon, 9 Jan 2017 19:36:40 -0800 From: Terry Manderson To: Sheng Jiang , "int-dir@ietf.org" Thread-Topic: [Int-dir] Review of draft-ietf-softwire-multicast-prefix-option Thread-Index: AQHSavLAmcT+hBo5ikKq80qdSwotuw== Date: Tue, 10 Jan 2017 03:36:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 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_3566900192_1698297802" MIME-Version: 1.0 Archived-At: Cc: "softwire@ietf.org" , "draft-ietf-softwire-multicast-prefix-option.all@ietf.org" Subject: Re: [Int-dir] Review of draft-ietf-softwire-multicast-prefix-option X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jan 2017 03:36:45 -0000 --B_3566900192_1698297802 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Thank you for your review Sheng! T. On 10/01/2017, 12:00 PM, "Int-dir on behalf of Sheng Jiang" wrote: Reviewer: Sheng Jiang Review result: Almost Ready =20 I am an assigned INT directorate reviewer for draft-ietf-dhc-dhcpv6-fai= lover-protocol-03. 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. =20 Review Date:2017-1-10 IETF LC End Date: 2017=E2=80=931-12 IESG Telechat date: =20 Summary: This draft is almost ready for publication as a standard track= RFC. =20 Major issues: =20 Minor issues: =20 =E2=80=9Cthe specification of a DHCPv6 option that could be used to discover unicast PREFIX64s in environments where multicast is not enabled. Such side effect conflicts with the recommendation documented in Section 6 of [RFC7051].=E2=80=9D =20 It is unclear how the Section 6 of RFC7051 relevant with the content ab= ove. It would be necessary to quote particular content of RFC7051 and give n= ecessary analysis. =20 Nits: =20 =E2=80=9Cthe Pv4 multicast address is inserted in the last 32 bits of the IPv= 4-embedded IPv6 multicast address.=E2=80=9D =20 Pv4//IPv4 =20 Regards, =20 Sheng =20 =20 --B_3566900192_1698297802 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+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFLEm pj97S+UpJL5q8mGqyeIw180vMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE3MDExMDAzMzYzMlowDQYJKoZIhvcNAQEBBQAEggEACZM7ovozqag24LwU7i9p gd+ybn1SaggsFJiCbDREUSkqAuh14tTa7huCpXAmiU2bkLvSCPs16bEO4E4VrhRHBXJn69nI ildBeziYABUjqGikYsjiDQ2dpqOLaHpyL5p+ikmZfZv4spbJxTBWqdOZMdUKPhpjC4+IXd44 XWj3foMbXkRf26beR675/mCa7lVflyMTGVXpWjzC/fLH/yrcL4WCFHTphirYCuXC/zxqn2k1 MHn6Xx2+fkBICCQ/NU06ZE/H+VCrsTzfVHsyEH28jswRyqNao7yoQyegYiOdSgGi0TnKN48e YglwQBpxyF+qphdJkSLJq92SDoesZDc79w== --B_3566900192_1698297802-- From nobody Tue Jan 10 08:32:12 2017 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E33129D1E; Tue, 10 Jan 2017 08:32:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Haberman To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2017 08:32:10 -0800 Archived-At: Cc: ipv6@ietf.org, ietf@ietf.org, draft-ietf-6man-rfc4291bis.all@ietf.org Subject: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 10 Jan 2017 16:32:11 -0000 Reviewer: Brian Haberman Review result: Ready with Nits I just have a few comments/questions on this draft. Overall, it is in pretty good shape... 1. Section 2.2.3 looks like a complete re-production of RFC 5952, but I don't see a reference to 5952. Is the intent to deprecate 5952 since its content is now contained within 4291bis? 2. Section 2.6.1 captures some information about reserved IPv6 multicast addresses, but not all of them. I think it would be beneficial to point to the IPv6 Multicast Address Allocation registry maintained by IANA, much like the way Section 2.3 points to the IANA registries. 3. Also in Section 2.6.1, the names of reserved addresses, like "All Nodes Addresses", were made all lowercase. Was that intentional? Given that IANA refers to them with capitalization, it would seem that we need to be consistent. So, I would either retain the capitalization in this document or ensure that Section 3 directs IANA to update the names in the registries. From nobody Tue Jan 10 16:48:28 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C251296A0; Tue, 10 Jan 2017 16:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28sb3QfnPVK3; Tue, 10 Jan 2017 16:48:22 -0800 (PST) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 952DF129642; Tue, 10 Jan 2017 16:48:19 -0800 (PST) Received: by mail-it0-x241.google.com with SMTP id q186so14600112itb.1; Tue, 10 Jan 2017 16:48:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=5hSK+HWimDLvWja1Ndt7Aj85zsyCrx0ugM/z8GhdpZ4=; b=iHBo8vXXWVPzIgerCrKt6/GUpFMNx8jXFThtGd4yT0dXW9Gr1dlrlyNjmCa9b/XWl9 SqND/mqH0AWkZDlkR7HdiNL+/rMReqldbxDD2b4nhxFrYfi1uU1GBWG/SHoHBQF/YGX0 YqgijPQHu4w08jkBBNLq9UQcZZ9IZT9agj98ir8kgKmxUPnoAEzFzzhTeYtcJOvUmYS2 0ajNB80hUgab8dj26ZtNRR9hDTf3TfA29lN6JX4PFdEHCoSEGj07Mo/yDtz2mbm+twIq Xk4fR8SwdAcPzuvxxYHwqmNvYIMuysAuukAWd6jxWtOL1AngJaQNDAdoTh6D54Sx7xgs ysUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5hSK+HWimDLvWja1Ndt7Aj85zsyCrx0ugM/z8GhdpZ4=; b=n3dz/vw7UgWDbm+43NCkQFNqWhaVQ2+MGq4gEbc6cXWC4Bp0YL56hnK8xDNASRMYkB v57ICzBhjKaNLOn6m48O1DrwIncZFeFAmGRjLPHIQc4forz7KtDKCpNPxbF+9QCpYaCm W9JL5mRjJ4OZjBw/9moqUsP/AtmcCkjAVcJNKxECK/OIrvs8L+3llSeUJ/MIGJuAv5az 4Kp0q4YxuZWc8dT1txNemkmh9iR9D4CQG8oFYtVNJH0NZ03cUJ0aJ5qkL/L+g4cOb1eH 3vuAQatLWJDLlymxegmL2ZsgYGilCKFR2Pxm8Yz4SPMEs8oyZzpa2kHyGeAfHRF+C6MV pr3Q== X-Gm-Message-State: AIkVDXJ4upYsBBa2j3Ck2bhmpQFr6kMarYC1xjLOVHoxuo0mLCUoomd/vI0qbrWVHDtbmg== X-Received: by 10.36.216.70 with SMTP id b67mr5971921itg.5.1484095698855; Tue, 10 Jan 2017 16:48:18 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id a23sm9082324itb.11.2017.01.10.16.48.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 10 Jan 2017 16:48:17 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_FD57D4D2-A77B-43A6-8C23-ADA2DCC4A99F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Bob Hinden In-Reply-To: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> Date: Tue, 10 Jan 2017 16:48:15 -0800 Message-Id: <64999467-1B39-4548-8E5F-A20005D022E2@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> To: Brian Haberman X-Mailer: Apple Mail (2.2104) Archived-At: Cc: draft-ietf-6man-rfc4291bis.all@ietf.org, IPv6 List , Bob Hinden , IETF , int-dir@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jan 2017 00:48:23 -0000 --Apple-Mail=_FD57D4D2-A77B-43A6-8C23-ADA2DCC4A99F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, Thanks for the review! > On Jan 10, 2017, at 8:32 AM, Brian Haberman = wrote: >=20 > Reviewer: Brian Haberman > Review result: Ready with Nits >=20 > I just have a few comments/questions on this draft. Overall, it is in > pretty good shape... >=20 > 1. Section 2.2.3 looks like a complete re-production of RFC 5952, but > I don't see a reference to 5952. Is the intent to deprecate 5952 since > its content is now contained within 4291bis? I didn=E2=80=99t include a direct reference in the Section as = incorporates the changes, but it is included in Appendix B describing = the changes. No current intent to deprecate RFC5952 as it updates RFC4291. I don=E2=80= =99t see very much value in deprecating (Historic?) the updating RFCs. >=20 > 2. Section 2.6.1 captures some information about reserved IPv6 > multicast addresses, but not all of them. I think it would be > beneficial to point to the IPv6 Multicast Address Allocation registry > maintained by IANA, much like the way Section 2.3 points to the IANA > registries. That makes sense. Something like a new paragraph at the end of the = section like: Additional defined multicast address can be found in the IANA IPv6 = Multicast Address Allocation registry [XXX] XXX: = http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-ad= dresses.xhtml. >=20 > 3. Also in Section 2.6.1, the names of reserved addresses, like "All > Nodes Addresses", were made all lowercase. Was that intentional? Given > that IANA refers to them with capitalization, it would seem that we > need to be consistent. So, I would either retain the capitalization in > this document or ensure that Section 3 directs IANA to update the > names in the registries. It was capitalized in RFC4291. It looks like the change was introduced = in draft-hinden-6man-rfc4291bis-01. I think may have been accidentally = part of changing the text addresses to lower case as part of the RFC5952 = update. I agree it should be the way it was in RFC4291. Will change. Thanks, Bob --Apple-Mail=_FD57D4D2-A77B-43A6-8C23-ADA2DCC4A99F 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 iQEcBAEBCgAGBQJYdYDQAAoJEK7rdBF357uoxNUH/0X0TiQzDX+Okc+KqDA193zx CRE1i6Did5E8nxJBxYpneCTPMz4gAFuqJGrIxileo9ULr/9utnqCWAOjzNM9ROeh 6FcshV+z5DazDroTEY+OsxTxLkvPOYzV3jSpky+FrA85OeS1eniWtRXbiAh5POTU y8oh/Q/Uo5UhaeQjKSwUYegM822rTEI+wqD+DVzjEjEbj4uf4ZFbxaGnfyxnv199 RQ906BAQCt08ZJas7K7TRlSyMHpw1iIaxukmR+iq2n4pi7byZlm3ObuYQq2FtnDW qNCINzt1KILpSmXVKiGGgZN2V1SmyZJrWRgQWXPjW1tvnbTjhrPrftQKigL0nvs= =io8B -----END PGP SIGNATURE----- --Apple-Mail=_FD57D4D2-A77B-43A6-8C23-ADA2DCC4A99F-- From nobody Tue Jan 10 17:53:03 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E328D12963D; Tue, 10 Jan 2017 17:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xEM-MP8rTVC4; Tue, 10 Jan 2017 17:52:52 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 19F931295A3; Tue, 10 Jan 2017 17:52:52 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cR85q-00039A-OG; Wed, 11 Jan 2017 01:52:51 +0000 Date: Wed, 11 Jan 2017 10:52:48 +0900 Message-ID: From: Randy Bush To: Brian Haberman In-Reply-To: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: draft-ietf-6man-rfc4291bis.all@ietf.org, ipv6@ietf.org, ietf@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jan 2017 01:52:53 -0000 > 1. Section 2.2.3 looks like a complete re-production of RFC 5952, but > I don't see a reference to 5952. Is the intent to deprecate 5952 since > its content is now contained within 4291bis? 5952 has much more very useful detail for those of us who write software to parse, compare, ... textual representations of ipv6 addresses, see section 4 of 5952. so i suggest the replacement of 2.2 with a reference to 5952. it is very cheering to see section 2.4.0, "96 more bits no magic" [credit gaurab]. but i am having a hard time reconciling 2.4.4's insistence on a mandatory 64-bit uuid in all unicast global addresses with 2.4.0, rfc 6141, widespread operational practice, ... clue bat please. randy From nobody Wed Jan 11 06:26:15 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F321F129ED4 for ; Wed, 11 Jan 2017 06:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.218 X-Spam-Level: X-Spam-Status: No, score=-5.218 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VppBQiKIThF9 for ; Wed, 11 Jan 2017 06:26:10 -0800 (PST) Received: from nm11-vm1.bullet.mail.bf1.yahoo.com (nm11-vm1.bullet.mail.bf1.yahoo.com [98.139.213.152]) (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 22401129482 for ; Wed, 11 Jan 2017 06:26:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1484144767; bh=AuIV8wUwqZyvgQhhhvgTy/YATXvuD5sYW7HsKXCOUAE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=dYGPCzsdnSPRqzWNzXqtSH3teFRKgIzvGXGizw0p0bWg7CMB/7MP4UlganZoCbqhisi6CokhMrbgFxf4VRucka+ySgz9IGQTf9hnl0UW0ZamuYwqDV4W4sBD4utR97LFfqlazkMg/QKwDygKet2j1KUfGb68yJ11JT8M8+GscbUOoaxb+ok5iRV3NTs4tA7iMu9HNPIhEpRNjFLv1Q9eeVXtlgEngozJPDyO+UR9GOMtAnBAxsnCrVRa2sAoJIbZCsnEExzSlQHueLOJgTOYY3wkZyq7uWIaVEzjlaMOHkrlWNtBxM8d1HYu7TQXEA9+mQEj0LoyQk33HY4ScsHBKg== Received: from [66.196.81.172] by nm11.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jan 2017 14:26:07 -0000 Received: from [98.139.212.196] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 11 Jan 2017 14:26:07 -0000 Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 11 Jan 2017 14:26:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 430819.38444.bm@omp1005.mail.bf1.yahoo.com X-YMail-OSG: ftQlEeAVM1nKlahdpEuPGdrLc7d8S02fF_77IG.fWmADHe5G.2wvwnjRMWGU4SR Jn3xO6VkTDN3tyxctUB0_VfMDc2u_qaF_eJmMkpl0w_wwVX5jdNfMPQFiIqpFJVzoRQsadf3LsLO iEfUZ4vH7x3ZIeqnjXf8m6rLWLBPGL9ymC.RP3r7nN0M9XWzCZn_5elKkvCAhJprxucaHZbGS6.c nCkoA6.fTKZIz7ggdryFDYCrzdpwT9wVcztnjq4NiqtRWk90dlZ4tOlB_y4fd6eJUkGzKNhv2r8R oby6jtrWdICDjW2dFqCHrGIvhVTxmf1bBPmv5y9LBVp_ZMnay0jGaOHH0RFZFW.fqaXIVIuz9bJ5 JxwXkF5VeGblSt1bT2pluF6bUchFIHVoB_OjyuhvPXY8Se26swKPMb4rxUv0rf6VyToalWRseM2l M9Pv8G6rVyWmUeG7vMG.tirJN._7llhYCdKen0qlZDuOqcGFsOxSccD3R5ypx5.tQea2V4b75Y3j er7wHurqg0BQ8DEQXMLa_ Received: from jws400085.mail.bf2.yahoo.com by sendmailws151.mail.bf1.yahoo.com; Wed, 11 Jan 2017 14:26:07 +0000; 1484144767.031 Date: Wed, 11 Jan 2017 14:24:34 +0000 (UTC) From: Punana Lebo To: Brian Haberman , "int-dir@ietf.org" Message-ID: <1817689823.74706.1484144674522@mail.yahoo.com> In-Reply-To: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_74705_1375753992.1484144674520" Archived-At: Cc: "ipv6@ietf.org" , "ietf@ietf.org" , "draft-ietf-6man-rfc4291bis.all@ietf.org" Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Punana Lebo 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, 11 Jan 2017 14:26:12 -0000 ------=_Part_74705_1375753992.1484144674520 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello=C2=A0I am new to this and I hope my comment is appropriate=C2=A0The e= xamples in recommendation 7 and 8 in section 2.2.3 have been swapped. In ot= her words, an example given for recommendation 7 (0:0:0:0:0:ffff:192.0.2.1 = should be shown as ::ffff:192.0.2.1) must be=C2=A0 for recommendation 8 (20= 01:0db8:0000:cd30:0000:0000:0000:0000/60 should be shown as 2001:0db8:0:cd3= 0::/60) and vise versa.=C2=A0Regards=C2=A0Keolebogile=C2=A0=C2=A0=20 On Tuesday, January 10, 2017 6:32 PM, Brian Haberman wrote: =20 Reviewer: Brian Haberman Review result: Ready with Nits I just have a few comments/questions on this draft. Overall, it is in pretty good shape... 1. Section 2.2.3 looks like a complete re-production of RFC 5952, but I don't see a reference to 5952. Is the intent to deprecate 5952 since its content is now contained within 4291bis? 2. Section 2.6.1 captures some information about reserved IPv6 multicast addresses, but not all of them. I think it would be beneficial to point to the IPv6 Multicast Address Allocation registry maintained by IANA, much like the way Section 2.3 points to the IANA registries. 3. Also in Section 2.6.1, the names of reserved addresses, like "All Nodes Addresses", were made all lowercase. Was that intentional? Given that IANA refers to them with capitalization, it would seem that we need to be consistent. So, I would either retain the capitalization in this document or ensure that Section 3 directs IANA to update the names in the registries. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- =20 ------=_Part_74705_1375753992.1484144674520 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello
 
I am new to this and I ho= pe my comment is appropriate
 
The examples in recommend=
ation 7 and 8 in section 2.2.3 have been swapped. In other words, an exampl=
e given for recommendation 7 (0:0:0:0:0:ffff:192.0.2.1 should be shown as :=
:ffff:192.0.2.1) must be  for recommendation 8 (2001:0db8:00=
00:cd30:0000:0000:0000:0000/60 should be shown as 2001:0db8:0:cd30::/60) an=
d vise versa.
 =

Regards
 
Keolebogile
 =
 


On Tuesday, January 10, 2017 6:32 PM, Brian Haberman <= brian@innovationslab.net> wrote:


Reviewer: Brian Haberman
Review result: Ready with = Nits

I just have a few comments/questions on this draft. Overall, it= is in
pretty good shape...

1. Section 2.2.3 looks like a complet= e re-production of RFC 5952, but
I don't see a reference to 5952. Is the= intent to deprecate 5952 since
its content is now contained within 4291= bis?

2. Section 2.6.1 captures some information about reserved IPv6<= br>multicast addresses, but not all of them. I think it would be
benefic= ial to point to the IPv6 Multicast Address Allocation registry
maintaine= d by IANA, much like the way Section 2.3 points to the IANA
registries.<= br>
3. Also in Section 2.6.1, the names of reserved addresses, like "All=
Nodes Addresses", were made all lowercase. Was that intentional? Given<= br>that IANA refers to them with capitalization, it would seem that we
n= eed to be consistent. So, I would either retain the capitalization in
th= is document or ensure that Section 3 directs IANA to update the
names in= the registries.

---------------------------------------------------= -----------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Ad= ministrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
----= ----------------------------------------------------------------

------=_Part_74705_1375753992.1484144674520-- From nobody Wed Jan 11 07:32:32 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1711294EC; Wed, 11 Jan 2017 07:32:25 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 O9YQ6YRtGqvV; Wed, 11 Jan 2017 07:32:24 -0800 (PST) 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 EC73F1294C5; Wed, 11 Jan 2017 07:32:24 -0800 (PST) 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 D679388124; Wed, 11 Jan 2017 07:32:24 -0800 (PST) Received: from clemson.local (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 2768C3280AE3; Wed, 11 Jan 2017 07:32:24 -0800 (PST) To: Bob Hinden References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <64999467-1B39-4548-8E5F-A20005D022E2@gmail.com> From: Brian Haberman Message-ID: <1059f68b-b7af-8261-304b-01515c340369@innovationslab.net> Date: Wed, 11 Jan 2017 10:32:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <64999467-1B39-4548-8E5F-A20005D022E2@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d59iFcoIMFGEF7arDNWKOmruGlNCQP7fF" Archived-At: Cc: draft-ietf-6man-rfc4291bis.all@ietf.org, IPv6 List , IETF , int-dir@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jan 2017 15:32:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d59iFcoIMFGEF7arDNWKOmruGlNCQP7fF Content-Type: multipart/mixed; boundary="KRSBGSPanMVkVfqXogoCt06H25rjrgRPc"; protected-headers="v1" From: Brian Haberman To: Bob Hinden Cc: int-dir@ietf.org, IPv6 List , IETF , draft-ietf-6man-rfc4291bis.all@ietf.org Message-ID: <1059f68b-b7af-8261-304b-01515c340369@innovationslab.net> Subject: Re: Review of draft-ietf-6man-rfc4291bis-06 References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <64999467-1B39-4548-8E5F-A20005D022E2@gmail.com> In-Reply-To: <64999467-1B39-4548-8E5F-A20005D022E2@gmail.com> --KRSBGSPanMVkVfqXogoCt06H25rjrgRPc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bob, On 1/10/17 7:48 PM, Bob Hinden wrote: > Brian, >=20 > Thanks for the review! >=20 >> On Jan 10, 2017, at 8:32 AM, Brian Haberman >> wrote: >>=20 >> Reviewer: Brian Haberman Review result: Ready with Nits >>=20 >> I just have a few comments/questions on this draft. Overall, it is >> in pretty good shape... >>=20 >> 1. Section 2.2.3 looks like a complete re-production of RFC 5952, >> but I don't see a reference to 5952. Is the intent to deprecate >> 5952 since its content is now contained within 4291bis? >=20 > I didn=E2=80=99t include a direct reference in the Section as incorpora= tes > the changes, but it is included in Appendix B describing the > changes. >=20 > No current intent to deprecate RFC5952 as it updates RFC4291. I > don=E2=80=99t see very much value in deprecating (Historic?) the updati= ng > RFCs. I will agree with Randy that there is useful info in 5952 that people need to see. Adding a reference to 5952 here would point people in the right direction. Regards, Brian --KRSBGSPanMVkVfqXogoCt06H25rjrgRPc-- --d59iFcoIMFGEF7arDNWKOmruGlNCQP7fF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYdlAHAAoJEBOZRqCi7goqHvoH/2R+eAfKkMxsRLgYCtJtmQmo dd7fTJuLbtUyXzdnut3AfYEt4NvfIap3WCYcjQh0qjnJZ8x+HudeFVZgCQEnR8Be EQ2pa7pIPBYPKykc/2hv+SRC91eCjjiWIX/RY0qm1s6JLHS1ozQMm4KfPYHPo1Cn 6NLMSymAw3WOhzqsSVMmpzE2hGOg9i312TqjdFX+PK4c9KAnWqxM2EvAP98KK0aB 2MI+bWnr+bBHFr/Gg+zByYxziT8v8yTAi39jOjfzgo3Sge4lNqJOPpC7djj2Yg7Z ygyNQRXdqC9P4ubHOy5ZwkUqtIBn+iRGP/rL8y6fFg8CVV45RbMOm44lM/QrqvQ= =oQ0c -----END PGP SIGNATURE----- --d59iFcoIMFGEF7arDNWKOmruGlNCQP7fF-- From nobody Wed Jan 11 12:27:09 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31E91297D0; Wed, 11 Jan 2017 12:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bd03gk1X4AWp; Wed, 11 Jan 2017 12:26:59 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7CD31289C4; Wed, 11 Jan 2017 12:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6137; q=dns/txt; s=iport; t=1484166418; x=1485376018; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=oUEQmMxfEFxCp788gMc1KHTMQc/JzCk0veG6MF4qdKc=; b=Lrln7g3gGt+pjx83cZCuetZK2JhIYl35uRpA5U3/yD/UQxUpR1k5Ldjz VAK7QNDqjf7t1t0ebJpfFBRJtN2FBiswmiyzkGGORJLmjfQbJlnvKP9+U UsHAdYXySMh6OHfr70sCs/6WpZ68JLAgmucOiLgceiX1Tofip7V6iHSIc Y=; X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208";a="191703649" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Jan 2017 20:26:58 +0000 Received: from dhcp-161-44-67-122.cisco.com (dhcp-161-44-67-122.cisco.com [161.44.67.122]) (authenticated bits=0) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v0BKQv12028626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2017 20:26:57 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: kkinnear In-Reply-To: <148256611461.16774.460244554047859645.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2017 15:26:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <93075E9F-B464-4829-98AA-12B2AA6793E1@cisco.com> References: <148256611461.16774.460244554047859645.idtracker@ietfa.amsl.com> To: Carlos Bernardos X-Mailer: Apple Mail (2.3124) X-Authenticated-User: kkinnear@cisco.com Archived-At: Cc: dhcwg@ietf.org, int-dir@ietf.org, ietf@ietf.org, draft-ietf-dhc-dhcpv6-failover-protocol.all@ietf.org, Kim Kinnear Subject: Re: [Int-dir] Review of draft-ietf-dhc-dhcpv6-failover-protocol-03 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 11 Jan 2017 20:27:01 -0000 Carlos, Thanks very much for reviewing the DHCPv6 Failover Protocol draft! To answer your question first, as Bernie mentioned, there is an implementation which is substantially identical to the protocol described in the draft. The on-the-wire packets are not compatible, since there are no IANA numbers for anything at this point, but it is essentially the same protocol. The experience I could report is simply that it *does* appear to work. There have certainly been bugs in the implementation, and there were some small issues early on that were also protocol issues, but any fixes that were made to the protocol were also rolled into previous versions of the draft, so that the draft has reaped the benefit of some real-world experience. There wasn't much, actually, that changed because of that. I expect that is because this DHCPv6 draft is very similar to the DHCPv4 Failover Protocol draft that went through 12 revisions before finally bogging down in its own weight. It finished at 133 pages, and I'll spare you more of that story. That said, the DHCPv4 version was implemented by several companies, and that draft contained much that was learned through those multiple implementations, which certainly informed the work on this DHCPv6 Failover Protocol. Regarding figures for Section 4. I have created one that tries to illustrate the example given in the text in Section 4.1.1. It shows both how the MCLT works as well as Lazy Update. I will publish it in the next version of the draft. Here it is: > Internet-Draft DHCPv6 Failover Protocol January = 2017 >=20 >=20 > Fundamental relationship: > lease time =3D floor(desired lifetime, ack-partner-lifetime + = MCLT) >=20 > Initial conditions: MCLT =3D 1h, desired lifetime =3D 3d >=20 > DHCPv6 Primary Secondary > time Client Server Server >=20 > | >-SOLICIT------> | | > | acknowledged partner lifetime =3D 0 | > | lease time =3D floor( 3d, 0 + 1h ) =3D 1h | > | <-----ADVERTISE-< | | > | lease-time=3D 1h | | > | >-REQUEST------> | | > t | <---------REPLY-< | | > | lease-time=3D 1h | | > | | >-BNDUPD------> | > | | partner-lifetime =3D 1/2h = + 3d > | | <----BNDREPLY-< | > | | partner-lifetime =3D 1/2h = + 3d > 1/2h passes ... ... ... > t+1/2h | >-RENEW--------> | | > | acknowledged partner lifetime =3D 3d | > | lease time =3D floor( 3d, 3d + 1h ) =3D 3d | > | <---------REPLY-< | | > | lease-time=3D3d | | > | | >-BNDUPD-------> | > | | partner-lifetime =3D 1.5d = + 3d > | | <----BNDREPLY-< | > | | partner-lifetime =3D 1.5d = + 3d > acknowledged partner lifetime =3D 1.5d + 3d > 1.5d passes ... ... ... > | | | > t+1.5d + 1/2h | >-RENEW--------> | | > | acknowledged partner lifetime =3D 3d | > | lease time =3D floor( 3d, 3d + 1h ) =3D 3d | > | <---------REPLY-< | | > | lease-time=3D3d | | > | | >-BNDUPD-------> | > | | partner-lifetime =3D 1.5d = + 3d > | | <----BNDREPLY-< | > | | partner-lifetime =3D 1.5d = + 3d > | acknowledged partner lifetime =3D 1.5d + 3d| >=20 > Figure 1: MCLT Example >=20 >=20 >=20 >=20 >=20 >=20 > Mrugalski & Kinnear Expires July 15, 2017 [Page = 17] > =0C I hope this helps folks get a better idea of some of the fundamental ideas on which the draft is based. =20 Thanks again for the thoughtful review! =20 Regards -- Kim > On Dec 24, 2016, at 2:55 AM, Carlos Bernardos wrote: >=20 > Reviewer: Carlos Bernardos > Review result: Ready >=20 > I am an assigned INT directorate reviewer for > draft-ietf-dhc-dhcpv6-failover-protocol-03. 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. >=20 > I'm not an expert in DHCPv6, so please consider this review as a light > one. Keeping this in mind, please find my review below. >=20 > Overall, I have not found any issue. I think the document is quite > complete and deep. Actually, my main overall comment is that it is > sometimes a bit hard to follow, due to its length and level of > complexity. Since a protocol specification has to be precise, my only > recommendation to address this would be to consider adding some > figures in Section 4, for the reader to get a first overall idea. >=20 > Question: is there any implementation available, so some experience > gained from it can be reported (maybe as an annex)? >=20 From nobody Thu Jan 12 12:52:11 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EE2129442; Thu, 12 Jan 2017 12:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRhuxpZokI4C; Thu, 12 Jan 2017 12:52:02 -0800 (PST) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::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 128CE129435; Thu, 12 Jan 2017 12:52:02 -0800 (PST) Received: by mail-qk0-x243.google.com with SMTP id u25so4395924qki.2; Thu, 12 Jan 2017 12:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3wAGyaYxKQLManmZq7r5ngCgFcE9I3MNbdtLqto4d8A=; b=qy12Nu7HoTWTZsjSZ18Gef3dQUvgDo+4f7FFH8Ca5RJYz67R6nlTTRhqjVbApba6BO MD9sAXV/DHd4LV85UhKTSSjmWgbJ4v4+srwXXoY2Istdi8y4SW+4UCS9Nejadm4FY2vC OGxgOCE0L0/NkUZRIeb7LVSjpLevZ/1J1ms8oiL3UQ3DZgjVP62SUL91zPmeJq1/uQPq ic7eqNnQzXaLM1SHN2nehpnEvH5gPF+cvVLq9wsEdlzgsJC5H8Jhiq7ZmgQjXmTl9gSg Lm6qhAKUkoaRA3EmgXFIjDHX5wuHAiQsWrRG75udXcyevmS/62pZE8a8lIGN/unAxsu4 APEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3wAGyaYxKQLManmZq7r5ngCgFcE9I3MNbdtLqto4d8A=; b=Rq1N2svxHqVcWAsTLQxwE187iphsp00eGV8y7pYaUQlfObaONbpGwk1padbAPBA/k+ 9huwK1ZCL/wI0O5NUX8r/yN/CvYQ41AR955hG1efsAQuYakcBABrSJ2dDP9lDpadCfRH n10lpaQCFzjg/APOmMQHKvzjYK7iCjr5rb5EIzsdRPRdDcYbQYbeNa+Wn8CNZzjzOiuB ilMDoTCclPm0nkamlEW0qNmIJqJTbPH5iMpU5GsXAsYvy8OH1g3kakVZEKftpCeHquXd MxftTIooenYAtE03kXsiiNmmIjZcT+cr+NKnAQM8sho+c2vUgmCpG/xGeL0UY3BXT5Zi FbYg== X-Gm-Message-State: AIkVDXLkLkK7KQpBdZHkJ2r/e5PhHerk+dUkpXmwqUFxVB60rz/tL/jSqScfn1hCUKfSaQ== X-Received: by 10.55.100.88 with SMTP id y85mr14447119qkb.194.1484254321246; Thu, 12 Jan 2017 12:52:01 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id f68sm3696330qkf.34.2017.01.12.12.51.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 12:52:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Bob Hinden In-Reply-To: <1817689823.74706.1484144674522@mail.yahoo.com> Date: Thu, 12 Jan 2017 12:51:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <521A0BF3-E8C8-4523-8CA7-4243DFA9AE82@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <1817689823.74706.1484144674522@mail.yahoo.com> To: Punana Lebo X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Brian Haberman , IPv6 List , IETF , "int-dir@ietf.org" , Bob Hinden , "draft-ietf-6man-rfc4291bis.all@ietf.org" Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 20:52:04 -0000 Keolebogile, You are correct. I will fix in the next version. Thanks, Bob > On Jan 11, 2017, at 6:24 AM, Punana Lebo wrote: >=20 > Hello > =20 > I am new to this and I hope my comment is appropriate > =20 > The examples in recommendation 7 and 8 in section 2.2.3 have been = swapped. In other words, an example given for recommendation 7 = (0:0:0:0:0:ffff:192.0.2.1 should be shown as ::ffff:192.0.2.1) must be = for recommendation 8 (2001:0db8:0000:cd30:0000:0000:0000:0000/60 should = be shown as 2001:0db8:0:cd30::/60) and vise versa. > =20 > Regards > =20 > Keolebogile > =20 > =20 >=20 >=20 > On Tuesday, January 10, 2017 6:32 PM, Brian Haberman = wrote: >=20 >=20 > Reviewer: Brian Haberman > Review result: Ready with Nits >=20 > I just have a few comments/questions on this draft. Overall, it is in > pretty good shape... >=20 > 1. Section 2.2.3 looks like a complete re-production of RFC 5952, but > I don't see a reference to 5952. Is the intent to deprecate 5952 since > its content is now contained within 4291bis? >=20 > 2. Section 2.6.1 captures some information about reserved IPv6 > multicast addresses, but not all of them. I think it would be > beneficial to point to the IPv6 Multicast Address Allocation registry > maintained by IANA, much like the way Section 2.3 points to the IANA > registries. >=20 > 3. Also in Section 2.6.1, the names of reserved addresses, like "All > Nodes Addresses", were made all lowercase. Was that intentional? Given > that IANA refers to them with capitalization, it would seem that we > need to be consistent. So, I would either retain the capitalization in > this document or ensure that Section 3 directs IANA to update the > names in the registries. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 >=20 From nobody Thu Jan 12 13:23:07 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23921294F9; Thu, 12 Jan 2017 13:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEscyawGqAVT; Thu, 12 Jan 2017 13:23:00 -0800 (PST) Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::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 1D4431289C4; Thu, 12 Jan 2017 13:23:00 -0800 (PST) Received: by mail-qt0-x243.google.com with SMTP id a29so3966717qtb.1; Thu, 12 Jan 2017 13:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R+VhdfW2filhZ56WH8Iu0cuAdQBr7128BRBknFIr6hQ=; b=EMC3SXU74Ui0oP1JlqisfW39sI3cv+SyTycq2rvTUaJeyUYLiP4DwYCKAXBSGHulCN JJGoJb+pwEceRtvdf+SJHsyAFy1sFB99/u1LlBg/ztSpB9rCMyKZjK+fAwCxB8H7Dyyb 8zJnyYTLYWlk1eDVI+94BXu2hwaDr5QTycEuigjDUiPLxNUTeK0C+F0NXPk4Kw2OlAst gsWjDJTk0w2WWR7H+SZHq2tkZwLS73bopT1812EgoPqzTTipNqHmqn7rsrQM+clJF7E7 GW4gHeQEjFYZQLZi1pi8DA2Kw6j93GZzqMrOCTPI66ez83naj0haxswbJYHfOzpp+opi hZeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R+VhdfW2filhZ56WH8Iu0cuAdQBr7128BRBknFIr6hQ=; b=DNrR5fLLMOpVA1wQGiqTGawU3ux/bNdCk77w3nafYSiZ7Y0fzSGfNdcqg8ITML0YEj eDFBrrIEss1GkeHig8hL3fvC7PiMZKyOdyO4caFFfYk327UHNByKmy7xSQyD75ebCT5h chQVQM8UAv7+XO2lUzv+2Wa5Wt2liIfH3/OuvccChUnV2mAJLsOSLVIpAwLcb9D9kKyS m9WUoXbrtVtNC5+hEP+VhjsUqqBcfo9uVBL5oVq4ulveec52cW74no0jWNZb5TuDDb32 7Dz0h1peuneQxCLa3ZnvymHQEdRv1P0scDl+PFQO1CcrZZT8uyAgOJ6NMo5OXFdjBA7U eeqQ== X-Gm-Message-State: AIkVDXJiaA81XsmNe8Jn0NPH9tqrTs1ahQoe7ATAmxL7e/4DQDiFPu+1bqQYSeynLwWauQ== X-Received: by 10.237.50.193 with SMTP id z59mr3325956qtd.102.1484256179217; Thu, 12 Jan 2017 13:22:59 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id z29sm7592799qtz.16.2017.01.12.13.22.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 13:22:58 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Bob Hinden In-Reply-To: Date: Thu, 12 Jan 2017 13:22:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> To: Randy Bush X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Brian Haberman , IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 21:23:02 -0000 Randy, > On Jan 10, 2017, at 5:52 PM, Randy Bush wrote: >=20 >> 1. Section 2.2.3 looks like a complete re-production of RFC 5952, but >> I don't see a reference to 5952. Is the intent to deprecate 5952 = since >> its content is now contained within 4291bis? >=20 > 5952 has much more very useful detail for those of us who write = software > to parse, compare, ... textual representations of ipv6 addresses, see > section 4 of 5952. so i suggest the replacement of 2.2 with a = reference > to 5952. Per your comment and Brian=E2=80=99s suggestion, I will add a reference = to RFC5952. RFC5952 doesn=E2=80=99t replace the definitions in RFC4291, = it make a recommendation on outputting IPv6 text representation, so I = don=E2=80=99t think it=E2=80=99s appropriate to replace 2.2 with just a = reference. >=20 > it is very cheering to see section 2.4.0, "96 more bits no magic" > [credit gaurab]. Good >=20 > but i am having a hard time reconciling 2.4.4's insistence on a > mandatory 64-bit uuid in all unicast global addresses with 2.4.0, rfc > 6141, widespread operational practice, ... clue bat please. >=20 This was discussed extensively in 6MAN and resulted in RFC7421 "Analysis = of the 64-bit Boundary in IPv6 Addressing=E2=80=9D. The text in = rfc4291bis is: For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. Background on the 64 bit boundary in IPv6 addresses can be found in [RFC7421]. Thanks, Bob From nobody Thu Jan 12 13:23:27 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC4C12952C; Thu, 12 Jan 2017 13:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ihmqukt2VTn1; Thu, 12 Jan 2017 13:23:05 -0800 (PST) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::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 3E94D129508; Thu, 12 Jan 2017 13:23:05 -0800 (PST) Received: by mail-qk0-x243.google.com with SMTP id a20so4523780qkc.3; Thu, 12 Jan 2017 13:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GPn2mmtkWbb7HcnLjVnLMoAjEEe6EW8/1dSGsa3/JjI=; b=T+u2Xv21uuW4Wj1OnQ4bDZaPJ6KjsRuaqV1FtfNNpOYtGoltMOpjw2juuFsOK6T3Dw HhnsXbvsi2aj4cqlA2H6UwQycpyTT90E2TMBy+t+GbGZ3eC0XcyLlG0459WYI6Yl0DG2 M4TQCKxWQ5znJt8phknmy3huf5sIZXa2Ef6DJpgAqhrRY7roJjpixZZzX5xSe0ET2h/Y g8hJp5nkfIpM5SSLzd2nuD0C/iwWZSFvWH0fUUV503uzYSpySuzk/vg+Cx6wSfVCGDKf s/Co1Z5VSMBRhc7pHgvnf6t/ZxDeqUJuQ8jxtYL/eZAc3QGrizmbBU86o0OXp2gJxwm/ 8PpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GPn2mmtkWbb7HcnLjVnLMoAjEEe6EW8/1dSGsa3/JjI=; b=qJWFjx88YcHj8rqdKyOj5zaVNeOFOkJcccxuAv/ilXqtADS24tvBbu2BrC+HojTYiH FYGxU56SggStd5y9pBMa+151l7z1tEc0IOCq4gejzbOkqOYfmL7yZQ1rswXtZjQlIAe3 tki99hG2dXefnE19aJEpRByiIqnPqLY1srYo9AAAYVyxEFGSCc49gvMDAPmtNrHF2NWU 1D5AMWPjxdc05QeHd3710b1p7crmekaOmHUE/jx7BlXJf5V4PzjBaXgrv2ZJxMOJ/y5c uj5FEZF5MzuBzQqFg8NrRt1rFK/rKYOxn/gubBpmf+u2e1y4y+ju9pUL6QziWbydSM+z 21XQ== X-Gm-Message-State: AIkVDXIHdr3nbHVBWX2PmU7g3xWxKpUIXY+FtGIZ5YBH8FYVe85tfJQUwL4AnlWDwDBuTg== X-Received: by 10.233.216.7 with SMTP id u7mr14905579qkf.220.1484256184466; Thu, 12 Jan 2017 13:23:04 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id z29sm7592799qtz.16.2017.01.12.13.23.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 13:23:03 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Bob Hinden In-Reply-To: <1059f68b-b7af-8261-304b-01515c340369@innovationslab.net> Date: Thu, 12 Jan 2017 13:23:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <64999467-1B39-4548-8E5F-A20005D022E2@gmail.com> <1059f68b-b7af-8261-304b-01515c340369@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ietf-6man-rfc4291bis.all@ietf.org, IPv6 List , Bob Hinden , IETF , int-dir@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 21:23:07 -0000 Brian, > On Jan 11, 2017, at 7:32 AM, Brian Haberman = wrote: >=20 > Hi Bob, >=20 > On 1/10/17 7:48 PM, Bob Hinden wrote: >> Brian, >>=20 >> Thanks for the review! >>=20 >>> On Jan 10, 2017, at 8:32 AM, Brian Haberman >>> wrote: >>>=20 >>> Reviewer: Brian Haberman Review result: Ready with Nits >>>=20 >>> I just have a few comments/questions on this draft. Overall, it is >>> in pretty good shape... >>>=20 >>> 1. Section 2.2.3 looks like a complete re-production of RFC 5952, >>> but I don't see a reference to 5952. Is the intent to deprecate >>> 5952 since its content is now contained within 4291bis? >>=20 >> I didn=E2=80=99t include a direct reference in the Section as = incorporates >> the changes, but it is included in Appendix B describing the >> changes. >>=20 >> No current intent to deprecate RFC5952 as it updates RFC4291. I >> don=E2=80=99t see very much value in deprecating (Historic?) the = updating >> RFCs. >=20 > I will agree with Randy that there is useful info in 5952 that people > need to see. Adding a reference to 5952 here would point people in the > right direction. Makes sense, I will add a reference to RFC5952 in the next version of = the draft. Thanks, Bob >=20 > Regards, > Brian >=20 From nobody Thu Jan 12 15:26:09 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BD7128BA2; Thu, 12 Jan 2017 15:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3un8lIYBLFpl; Thu, 12 Jan 2017 15:26:06 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 53AF2129439; Thu, 12 Jan 2017 15:26:06 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cRoku-0000P5-1S; Thu, 12 Jan 2017 23:26:04 +0000 Date: Fri, 13 Jan 2017 08:26:00 +0900 Message-ID: From: Randy Bush To: Bob Hinden In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP Archived-At: Cc: draft-ietf-6man-rfc4291bis.all@ietf.org, Brian Haberman , IPv6 List , IETF , int-dir@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 12 Jan 2017 23:26:07 -0000 >> but i am having a hard time reconciling 2.4.4's insistence on a >> mandatory 64-bit uuid in all unicast global addresses with 2.4.0, rfc >> 6141, widespread operational practice, ... clue bat please. > > This was discussed extensively in 6MAN and resulted in RFC7421 > "Analysis of the 64-bit Boundary in IPv6 Addressing$B!I(B. The text in > rfc4291bis is: > > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long. > Background on the 64 bit boundary in IPv6 addresses can be found in > [RFC7421]. thanks for the review that the wg came to this decision in conflict with operational practice and its own statement in 2.4.0. i did read the documents. since it is incorrect, ietf last call seems to be the time to fix it. to be clear, i have no problem with iids being 64-bit. my issue is with unicast globals being classful in 2.4.4. randy From nobody Thu Jan 12 16:29:22 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781FF12957D; Thu, 12 Jan 2017 16:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKOVtHmlE3mE; Thu, 12 Jan 2017 16:29:18 -0800 (PST) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 CDF7F129580; Thu, 12 Jan 2017 16:29:18 -0800 (PST) Received: by mail-pf0-x241.google.com with SMTP id 127so5550250pfg.0; Thu, 12 Jan 2017 16:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=nq2Yh0khVbpCnVF86f7EtEBwM8OsMRRZhQPC6rQAJ58=; b=fJwdA+GFBmpVQdICE14dIXwD83Nai+g5E/nJ+gki5JvAqkRUeIW22yFOL6Ksf19OBm xVWVvIJd7MuhGsxAUmO3T/8uMggk3FiYwsRr6kLA+TOEij9xdqlGMsXVJl3BFpVippI2 aNrydwKqGlml0QPQqy1zgAY4VdLgfBCdM4RFBMFum0Sc3eWGU7cY2u/CVE7e/cxJtvdz 9F3JlxUkFOUTOA6zi5zfJBfFWO+vvf+F0CuFL+yb5nkaIA+F5ED4mJ0mmkoAf0eTblln nQ5Z/K08d0Y/6Maqm5rxtqnrzBQ+2FKCP6Ij9h5VrSAbepuzL/rJgtL9aJU+iQRZRq8x DguA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=nq2Yh0khVbpCnVF86f7EtEBwM8OsMRRZhQPC6rQAJ58=; b=oVXEH9a3bXoN3HWLrXy+tdrJhx2pDgI9fHK8W5OD2HYsDqnw+e9ukt4nF9Rl8BljWd ZHYPAOFeIxXzaqB+dLbDXxAnkOXtQu9xUqvkmI5ECKzr6sPSIMLvH58d25jKrFDNx9ap C9Wb7ppVv/ZqJ83ebeleSxl/qEBOkHTe6eO0t+PUTVmjotx9QNA1ljbCMYifELLMvEJc kLBNtXGiU+GbBD8e2jkTonjuvULrxJUYqW5yiMnnS3ww+om6fafGDZ51yacdSuBMzbzC o3yDUiyXV1YJTjTwNnjFm3S5ah8hwK7kCGEDxAlp/H76dW8zBXSJKT/u3x8juL2Zow/x 2ROA== X-Gm-Message-State: AIkVDXLj8SAQIMc4otEZEcJykV3Uhi01Aujm0o8z+dqpju445OGgIn6EU/sZ9vRGb0028Q== X-Received: by 10.84.138.165 with SMTP id 34mr25534409plp.37.1484267357375; Thu, 12 Jan 2017 16:29:17 -0800 (PST) Received: from [192.168.178.21] ([118.148.127.232]) by smtp.gmail.com with ESMTPSA id t87sm19496296pfe.59.2017.01.12.16.29.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 16:29:16 -0800 (PST) To: Randy Bush , Bob Hinden References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> Date: Fri, 13 Jan 2017 13:29:21 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: int-dir@ietf.org, IPv6 List , draft-ietf-6man-rfc4291bis.all@ietf.org, IETF Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 00:29:20 -0000 On 13/01/2017 12:26, Randy Bush wrote: >>> but i am having a hard time reconciling 2.4.4's insistence on a >>> mandatory 64-bit uuid in all unicast global addresses with 2.4.0, rfc= >>> 6141, widespread operational practice, ... clue bat please. >> >> This was discussed extensively in 6MAN and resulted in RFC7421 >> "Analysis of the 64-bit Boundary in IPv6 Addressing=E2=80=9D. The tex= t in >> rfc4291bis is: >> >> For all unicast addresses, except those that start with the binary >> value 000, Interface IDs are required to be 64 bits long. >> Background on the 64 bit boundary in IPv6 addresses can be found in= >> [RFC7421]. >=20 > thanks for the review that the wg came to this decision in conflict wit= h > operational practice and its own statement in 2.4.0. i did read the > documents. >=20 > since it is incorrect, ietf last call seems to be the time to fix it. >=20 > to be clear, i have no problem with iids being 64-bit. my issue is wit= h > unicast globals being classful in 2.4.4. RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exc= eption. To be precise it says: The de facto length of almost all IPv6 interface identifiers is therefore 64 bits. The only documented exception is in [RFC6164], which standardizes 127-bit prefixes for point-to-point links between routers, among other things, to avoid a loop condition known as the ping-pong problem. I would suggest adding a similar exception statement in 4291bis. Brian From nobody Thu Jan 12 16:41:37 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3161295A7 for ; Thu, 12 Jan 2017 16:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAN7rd4-AzIQ for ; Thu, 12 Jan 2017 16:41:28 -0800 (PST) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 0F22912959B for ; Thu, 12 Jan 2017 16:41:25 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 8B895BAE for ; Fri, 13 Jan 2017 00:41:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClJDIMmKorDt for ; Thu, 12 Jan 2017 18:41:24 -0600 (CST) Received: from mail-vk0-f71.google.com (mail-vk0-f71.google.com [209.85.213.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 5C6B5B90 for ; Thu, 12 Jan 2017 18:41:24 -0600 (CST) Received: by mail-vk0-f71.google.com with SMTP id j12so20122237vkd.2 for ; Thu, 12 Jan 2017 16:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DrBxsjUKKvdM4bCytvb029AVfcukq9wPun1NBpnvlBM=; b=DxL6SNJ8/+I2baiTISRWEV32fEZVKiYDTb6NkpuLjgJRqfA/Yki/uhkrK9misSSXHS ZSRt6TsiH4tbofNFMC5yqjNq/pnVRqAISzYm+7nBwW+IuE4zAiclGapYATQ9nYS991ah 9Ge6eOONrsiXdMoMQjZnKFk3uwuOHanxY0gnKeAwPPhZu6yj5QmJwy/C4Y4Z/Kcl8mpn NMRgDrfq6xSHchblynam7eMZbWinEg+tFPbkhxKcOhDPIsGzNYHeNaehVvlomctsDG6P TqbGRs7Xvjx/2rZrgJAGNYQefRCGtvW7dNRfOc42blPS8sQUhemTOU6Ls5QE5cc5Yb17 kAPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DrBxsjUKKvdM4bCytvb029AVfcukq9wPun1NBpnvlBM=; b=oTBkNkY7ORU/dg58lWZDyPTmJhk4Q69kEkTJKfZRBeDKufCoeg9tLbFhD3mHUgG1L6 rP8gMooKl2yEKFEjK9nOy3VuKh2CTFd/x+U0SfAGEPk6yxMTQTe1dGWBeY52T0bNQG1j W/NW+gwuEio883KtdSIwXFsYAd1BjanBbqRUh8pHZRs6npzJg74FCplvOWRYer08bWbD F/iET0cU7d/t/Tnga+yY5HkEkqH/m8xygmsU0x81Oaw3GCyVjIzPAXwVZm+0ivTHo+WY dyuFVEdvTYTt1Jj7aTTyFXgha5GKLqEP9qWxQuW4CWpXsgqWh23EFdvDptGLLizkQkNW RQlA== X-Gm-Message-State: AIkVDXLRDnTFcJxCQsk2ybt7lbkemN/8K378Ddoj6+xwGKNXK4nO+3BOa52iUk2mHRuSX7WaXlSerRyE39aV6o2l05A1T4/VhUQiZHMzs71n/9Avdnup9zxldhszK9S+I7VC/Uge1oikzdAuFxFPMsM= X-Received: by 10.31.49.216 with SMTP id x207mr8272012vkx.82.1484268083739; Thu, 12 Jan 2017 16:41:23 -0800 (PST) X-Received: by 10.31.49.216 with SMTP id x207mr8272004vkx.82.1484268083510; Thu, 12 Jan 2017 16:41:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.15 with HTTP; Thu, 12 Jan 2017 16:41:23 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> From: David Farmer Date: Thu, 12 Jan 2017 18:41:23 -0600 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a114409b2de9ec50545ef17cb Archived-At: Cc: IPv6 List , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, IETF Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 00:41:30 -0000 --001a114409b2de9ec50545ef17cb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 12, 2017 at 5:26 PM, Randy Bush wrote: > >> but i am having a hard time reconciling 2.4.4's insistence on a > >> mandatory 64-bit uuid in all unicast global addresses with 2.4.0, rfc > >> 6141, widespread operational practice, ... clue bat please. > > > > This was discussed extensively in 6MAN and resulted in RFC7421 > > "Analysis of the 64-bit Boundary in IPv6 Addressing=E2=80=9D. The text= in > > rfc4291bis is: > > > > For all unicast addresses, except those that start with the binary > > value 000, Interface IDs are required to be 64 bits long. > > Background on the 64 bit boundary in IPv6 addresses can be found in > > [RFC7421]. > > thanks for the review that the wg came to this decision in conflict with > operational practice and its own statement in 2.4.0. i did read the > documents. > > since it is incorrect, ietf last call seems to be the time to fix it. > > to be clear, i have no problem with iids being 64-bit. my issue is with > unicast globals being classful in 2.4.4. > > randy > > Randy I take your point, but this supposed conflict isn't new, it's not introduced in 4291bis, it goes back to RFC3513. Do you have a suggestion how to change this within the context of advancing this to Internet Standard? --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a114409b2de9ec50545ef17cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 12, 2017 at 5:26 PM, Randy Bush <randy@psg.com> = wrote:
>> but i am having a hard ti= me reconciling 2.4.4's insistence on a
>> mandatory 64-bit uuid in all unicast global addresses with 2.4.0, = rfc
>> 6141, widespread operational practice, ...=C2=A0 clue bat please.<= br> >
> This was discussed extensively in 6MAN and resulted in RFC7421
> "Analysis of the 64-bit Boundary in IPv6 Addressing=E2=80=9D.=C2= =A0 The text in
> rfc4291bis is:
>
>=C2=A0 =C2=A0 For all unicast addresses, except those that start with t= he binary
>=C2=A0 =C2=A0 value 000, Interface IDs are required to be 64 bits long.=
>=C2=A0 =C2=A0 Background on the 64 bit boundary in IPv6 addresses can b= e found in
>=C2=A0 =C2=A0 [RFC7421].

thanks for the review that the wg came to this decision in conflict with operational practice and its own statement in 2.4.0.=C2=A0 i did read the documents.

since it is incorrect, ietf last call seems to be the time to fix it.

to be clear, i have no problem with iids being 64-bit.=C2=A0 my issue is wi= th
unicast globals being classful in 2.4.4.

randy


Randy= I take your point, but this supposed conflict isn't new, it's not = introduced in 4291bis, it goes back to RFC3513.=C2=A0 Do you have a suggest= ion how to change this within the context of advancing this to Internet Sta= ndard?

--
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Tele= communication Services
Office of Information Technology
University of= Minnesota=C2=A0=C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2= =A0 Phone: 612-626-0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612= -812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
--001a114409b2de9ec50545ef17cb-- From nobody Thu Jan 12 16:49:13 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDA71295AE; Thu, 12 Jan 2017 16:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JvX4lMZxvm7a; Thu, 12 Jan 2017 16:49:11 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 A96C4129476; Thu, 12 Jan 2017 16:49:11 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cRq3J-0000pc-Rw; Fri, 13 Jan 2017 00:49:10 +0000 Date: Fri, 13 Jan 2017 09:49:07 +0900 Message-ID: From: Randy Bush To: David Farmer In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IPv6 List , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, IETF Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 00:49:13 -0000 >> to be clear, i have no problem with iids being 64-bit. my issue is with >> unicast globals being classful in 2.4.4. > Randy I take your point, but this supposed conflict isn't new, it's not > introduced in 4291bis, it goes back to RFC3513. i know; and i have pushed back every cm of the way. it took years to get the other classful insanity, tls/nla, removed. the old cidr war continues. this last bit of classfulness (excuse the word) too will pass. > Do you have a suggestion how to change this within the context of > advancing this to Internet Standard? yes. simply remove the mandatory requirement for classful global unicast addresses. randy From nobody Thu Jan 12 16:50:49 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B033B1295B0; Thu, 12 Jan 2017 16:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 vmdWQc2N3Uke; Thu, 12 Jan 2017 16:50:40 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 8313C1294BC; Thu, 12 Jan 2017 16:50:40 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cRq4l-0000qE-8F; Fri, 13 Jan 2017 00:50:39 +0000 Date: Fri, 13 Jan 2017 09:50:36 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IPv6 List , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, IETF Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 00:50:42 -0000 > RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exception. > To be precise it says: > > The de facto length of almost all IPv6 interface identifiers is > therefore 64 bits. The only documented exception is in [RFC6164], > which standardizes 127-bit prefixes for point-to-point links between > routers, among other things, to avoid a loop condition known as the > ping-pong problem. > > I would suggest adding a similar exception statement in 4291bis. and then next year we will go through another draft and have another exception. just get rid of classful addressing. we went through this in the '90s. randy From nobody Thu Jan 12 17:56:13 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551911289C4; Thu, 12 Jan 2017 17:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VEYxB43s1Dp; Thu, 12 Jan 2017 17:56:02 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::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 403531296F9; Thu, 12 Jan 2017 17:55:56 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id y143so5855682pfb.1; Thu, 12 Jan 2017 17:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cXyVC6nbN/MBxf+WYJeO+dmtJOWSylI5XFI9pmVbiKg=; b=iiuWaEKr5yYNRrvQz9Erd3RLpi/fKFazsJMu4bw3do3uG9rC9FE4PxaUYpga38bk8N FpdHzgcY9DKly+Y/2AUFxQZU3XRk3qQMgaymXjVwGqZNAqRP+Q4F1mUtx271z7A7wPMD fDEzAVBzPhTe/peXDf4xJSt4P1hqhuLWOdvhElt0d4C0Zxy7Qed2izR+gFLvn73r7UJ+ m/9AuGUBfYXnrrNh5qZOAbEZEOAYk8lJOcnhhPNcTltsnsiEefgXmF/su+sombQTsxW9 d+S6TKro7jsXavwCsaogjxujGVcKahrOYY/wxTJBwGYIqPOoKzR0esQXtROeXfmqTgFt cBsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=cXyVC6nbN/MBxf+WYJeO+dmtJOWSylI5XFI9pmVbiKg=; b=EyS8yzZyIwkZDCWC7jp+mEbfpSffqMeIxlkN0J3/JPSr/MyIgCMdl4gjaUgVwLD4io Tm6HuRLNMbUbbuGGQdbTeE3hj/QI3PmfHuP5yHA3NqzTER4lxUXC8jcL6dvy4W1qB+6D p5HXiX/+0fQwMxs4wMWnEMbK0//hM+IrnHHqkbCPbFA54tB/GmjzHayI2Tn6FEEiME8s CyMCctfLw4UagDAiywReOXzL9eNHxWUEILRodzSQZ4XwWpxW4mGWqwQI4f2kmga9++j+ K01t3XdsOzGtREWuGslicqZ8rk5Lkzlg3aSsyoEuPmQdGbIYOq+9prZNpBQe5+Pmi+84 W0sw== X-Gm-Message-State: AIkVDXJu5911SCRNNihcqjYs4zzN2h2mke9k0hzQ6Yyo3HlqFH1UGGuH8XtKxgAlPoh3ng== X-Received: by 10.99.36.65 with SMTP id k62mr21031471pgk.13.1484272555852; Thu, 12 Jan 2017 17:55:55 -0800 (PST) Received: from [192.168.178.21] ([118.148.127.232]) by smtp.gmail.com with ESMTPSA id m67sm24451406pfc.64.2017.01.12.17.55.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 17:55:54 -0800 (PST) To: Randy Bush References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> Date: Fri, 13 Jan 2017 14:55:59 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 List , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, IETF Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 01:56:04 -0000 On 13/01/2017 13:50, Randy Bush wrote: >> RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exception. >> To be precise it says: >> >> The de facto length of almost all IPv6 interface identifiers is >> therefore 64 bits. The only documented exception is in [RFC6164], >> which standardizes 127-bit prefixes for point-to-point links between >> routers, among other things, to avoid a loop condition known as the >> ping-pong problem. >> >> I would suggest adding a similar exception statement in 4291bis. > > and then next year we will go through another draft and have another > exception. just get rid of classful addressing. we went through this > in the '90s. The problem is (and why we wrote 7421) is that stuff breaks with subnet prefixes longer than 64, *except* for the point-to-point case covered by 6164. Yes, I see the problem in enshrining this but I think we face signifcant issues if we do otherwise. What we could conceivably say is that /64 is mandatory except for links where SLAAC will never be used. (SLAAC itself is designed to work with any reasonable length of IID, but again in practice it only works with /64, because we need mix-and-match capability. So although IID length is a parameter in the SLAAC design, it's a parameter whose value needs to be fixed globally.) Brian From nobody Thu Jan 12 18:31:35 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5EC129871 for ; Thu, 12 Jan 2017 18:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSeV9zdi0uyR for ; Thu, 12 Jan 2017 18:31:32 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 43E5312986E for ; Thu, 12 Jan 2017 18:31:32 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id 35so28081446uak.1 for ; Thu, 12 Jan 2017 18:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7eO9vkoYTNje6jk2VrlC/5AynBNPZICg6UT4JIN9wsQ=; b=klU95R2LEDpWw/f3XnlXtr5gYmdS53CS8bzm2NjXi36qU+1yAr7oIusV5MqCu3knV2 QNNxQNeU/1mQO4zt/pOfJx1hj3WJrNs6cAkv/f4IT4iQhG9utDR6VpcN2xpo5jgKNV+f LNTfvRr9bFoSehBgCqzHPqydVpPAzb6AUFvReZVkzRd4rKo15y6xwlDPNzpKR7vt4tiC 5Ux4mm+lNn/QrK0+19qHoIAMPYWdLmVBpCTelnsUnT5+/HrtLPVbxKSOxI4BjRkO/ER7 nbb/Nty1OMUqICmP4EZQaE04/UmdvhSAyyDKu3NnPfRdcz9r1iPciVH+KJ5Zf4uGSmgq ID2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7eO9vkoYTNje6jk2VrlC/5AynBNPZICg6UT4JIN9wsQ=; b=g7XGDwu/9bg3BPxgd7frgJAbTyws24Y1q4aUvZ/Fm70LLkioOsc8Ukv9PKwdgsUteA 5MmhxmvaJ7Nt++1z+2Rshu4BAsBs6hroq4+xrkkdPW240/+uduFIK6MBTYzV/mQ84qxb WRawSFcgNrWzNnsIrsNdh2ufhiIF4Gt3338hYGbOjE/F9YOAQyggN0MHmdCR88EXEg36 5XMgvXH513FrY0gOaBmbrBCArGul1/B623pJgQMq5o61C0JFHO6814UElWdjWVDFfckC jpvBA/hESQCLCb3zEn4lk7Qje1JOBA1gtldloRO37ld9Vo1s5VNhw7OCFROE2NQ5z4Rs 4Quw== X-Gm-Message-State: AIkVDXL1MpImEAutbKTFpi302EzCxAOzpspcz3yb38+5Y9BYnbp94ib9tWLdOHKstsIrhAEJAAWdkFrw63Y7Ek0I X-Received: by 10.159.48.203 with SMTP id k11mr9273853uab.42.1484274691203; Thu, 12 Jan 2017 18:31:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.49.77 with HTTP; Thu, 12 Jan 2017 18:31:10 -0800 (PST) In-Reply-To: <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> From: Lorenzo Colitti Date: Fri, 13 Jan 2017 11:31:10 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f403045e34f4b8273e0545f0a1f6 Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , Randy Bush , draft-ietf-6man-rfc4291bis.all@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 02:31:34 -0000 --f403045e34f4b8273e0545f0a1f6 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 13, 2017 at 10:55 AM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > The problem is (and why we wrote 7421) is that stuff breaks with subnet > prefixes longer than 64, *except* for the point-to-point case covered > by 6164. Yes, I see the problem in enshrining this but I think we face > signifcant issues if we do otherwise. > Also, RFC7934 says that networks that provide service to general-purpose hosts should be assigned /64 prefixes to avoid address scarcity. Networks that provide service to general purpose hosts make up a lot of the Internet. What we could conceivably say is that /64 is mandatory except for > links where SLAAC will never be used. (SLAAC itself is designed > to work with any reasonable length of IID, but again in practice it > only works with /64, because we need mix-and-match capability. So > although IID length is a parameter in the SLAAC design, it's a > parameter whose value needs to be fixed globally.) > I don't think that's a good idea. I strongly believe that unlike most areas of the IPv6 protocol where it is a good idea to automatically apply the lessons we learned in IPv4, in the specific field of IP subnet sizing, we should *not* automatically translate IPv4 practices to IPv6. This is because the difference between 32 bits and 128 bits is large enough that the semantics are fundamentally different. We may be lured by the fact that 128 is just 4 times larger than 32, but the difference is huge - remember that even just the first 64 bits are 4 billion times larger than the whole of the current Internet. So while Randy may well be right that we will move away from classful eventually (we certainly never had it in the top 64 bite of the address), I don't think it's necessarily a good idea to do that now. Let's have that conversation when IPv6 deployment has reached 90% and we have experience running the whole Internet with IPv6. For now, I'd much prefer to just add a similar exception to the one we have in 7421. --f403045e34f4b8273e0545f0a1f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 13, 2017 at 10:55 AM, Brian E Carpenter <brian.e.carpent= er@gmail.com> wrote:
The problem is (and why we wrote 7421) is that stuff breaks wi= th subnet
prefixes longer than 64, *except* for the point-to-point case covered
by 6164. Yes, I see the problem in enshrining this but I think we face
signifcant issues if we do otherwise.

A= lso, RFC7934 says that networks that provide service to general-purpose hos= ts should be assigned /64 prefixes to avoid address scarcity. Networks that= provide service to general purpose hosts make up a lot of the Internet.

What we= could conceivably say is that /64 is mandatory except for
links where SLAAC will never be used. (SLAAC itself is designed
to work with any reasonable length of IID, but again in practice it
only works with /64, because we need mix-and-match capability. So
although IID length is a parameter in the SLAAC design, it's a
parameter whose value needs to be fixed globally.)
I don't think that's a good idea.

<= div>I strongly believe that unlike most areas of the IPv6 protocol where it= is a good idea to automatically apply the lessons we learned in IPv4, in t= he specific field of IP subnet sizing, we should *not* automatically transl= ate IPv4 practices to IPv6. This is because=C2=A0the difference between 32 = bits and 128 bits is large enough that the semantics are fundamentally diff= erent. We may be lured by the fact that 128 is just 4 times larger than 32,= but the difference is huge - remember that even just the first 64 bits are= 4 billion times larger than the whole of the current Internet.
<= br>
So while Randy may well be right that we will move away from = classful eventually (we certainly never had it in the top 64 bite of the ad= dress), I don't think it's necessarily a good idea to do that now. = Let's have that conversation when IPv6 deployment has reached 90% and w= e have experience running the whole Internet with IPv6.

For now, I'd much prefer to just add a similar exception to the o= ne we have in 7421.
--f403045e34f4b8273e0545f0a1f6-- From nobody Thu Jan 12 19:22:15 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45CC3129487; Thu, 12 Jan 2017 19:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 M9iuAphrVRim; Thu, 12 Jan 2017 19:22:09 -0800 (PST) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267A7129401; Thu, 12 Jan 2017 19:22:09 -0800 (PST) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 92E5587F5E; Fri, 13 Jan 2017 03:22:08 +0000 (UTC) Date: Fri, 13 Jan 2017 03:22:08 +0000 From: heasley To: Randy Bush Message-ID: <20170113032208.GA18762@shrubbery.net> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, David Farmer , Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 03:22:10 -0000 Fri, Jan 13, 2017 at 09:49:07AM +0900, Randy Bush: > > Do you have a suggestion how to change this within the context of > > advancing this to Internet Standard? > > yes. simply remove the mandatory requirement for classful global > unicast addresses. yes, please. From nobody Thu Jan 12 19:56:09 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52252129972; Thu, 12 Jan 2017 19:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcYnnabN_OpW; Thu, 12 Jan 2017 19:56:01 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD30B126BF7; Thu, 12 Jan 2017 19:56:00 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id 137so26175044vkl.0; Thu, 12 Jan 2017 19:56:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s822UKvoYi0+VtfpHcRcO1dh8gEFGkJnSjLjBOPFeAA=; b=NODKN09lzlcGv7ByOewW8rz8QeiZYqBmyem/T/3V+heo0xBAA28EoWm82cta2jhj6o UAUi7OxXsffUvrdt/OTDQ6w+kYfAxMxOHmlMi31hmnMmhw68hac0yMy1iKLeomM9W0vn wda4TmmLFrJTPGVDUGgVR8ajpV3Iwi30XA2tEMkJHKyUb2QpMr7bryKgA/cDaVbYgD3u yfnVi41nKbplsQZ2xwAVeyL4tWwcz5oKAIILIl+QWRV2dGPhEpC0kIJgiIT3E+5njrF2 vW/XywUE0wQMy1xmnYAHlmdUkdyrxpQR/h+hOWAp2gffkFkbBGoQJ8s7feat+O+JJmJR 3IAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s822UKvoYi0+VtfpHcRcO1dh8gEFGkJnSjLjBOPFeAA=; b=jXPd27OXgMVaxIesjFoKbXNY2fkz2/k435AYRFyiWLugpq9+KaRMstytbFEVZO1+Cm yACwgLZJb/6oPf+5QPVqC+sWIIAM0WjEztBfLM+oYjdhZektpIQJG8d+7cgTD8VlK6Nm +l8jqN824dXYCCu4axZxJ8uUAO/MDQU8/Idiiyb/Kvf+RqPak+2v7c0JTA/4UnYqvGJS 1l93M+JDcpgxI+mHDf5qcTPGVUYgIjzKUpOx3rsUEI0AxSLK6ycANoDbstKjOEjwlvoR uG3KbtJeon7BoyN0gtt2oseBGssXAMJEFjKQ+ZtC1H+KYWN5JN0WMkJlLdQedC+WqviK ifCg== X-Gm-Message-State: AIkVDXL4UK55Ih94rccW8pR1wVxe1w5vL184YZxEIjlJuqN7H2yg9qc51BykudHpeIf2+xAs6QvHOEP18P3vuQ== X-Received: by 10.31.149.145 with SMTP id x139mr7571659vkd.130.1484279759915; Thu, 12 Jan 2017 19:55:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.49.14 with HTTP; Thu, 12 Jan 2017 19:55:59 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> From: Suresh Krishnan Date: Thu, 12 Jan 2017 22:55:59 -0500 Message-ID: To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, David Farmer , Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 03:56:03 -0000 Hi Randy, On Thu, Jan 12, 2017 at 7:49 PM, Randy Bush wrote: >>> to be clear, i have no problem with iids being 64-bit. my issue is with >>> unicast globals being classful in 2.4.4. >> Randy I take your point, but this supposed conflict isn't new, it's not >> introduced in 4291bis, it goes back to RFC3513. > > i know; and i have pushed back every cm of the way. it took years to > get the other classful insanity, tls/nla, removed. the old cidr war > continues. this last bit of classfulness (excuse the word) too will > pass. > >> Do you have a suggestion how to change this within the context of >> advancing this to Internet Standard? > > yes. simply remove the mandatory requirement for classful global > unicast addresses. I do see your point but I do not feel it is equivalent to classful addressing in IPv4. i.e. Looking at the leading X bits does not directly determine the IID length. That said, I would like to understand better your exact concern with the text in 2.4.4. What exactly would you like to change (is it the m-bit verbiage)? Can you come up with a text change proposal so that we can discuss it in the 6man WG? Thanks Suresh P.S.: The document is not in IETF Last Call yet. It has completed WGLC and is in AD evaluation. Brian did his INT Dir review for the INT ADs. The IETF Last Call will start soon. From nobody Thu Jan 12 21:10:17 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16759129A18; Thu, 12 Jan 2017 21:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 GaMalI41yUgq; Thu, 12 Jan 2017 21:10:07 -0800 (PST) Received: from linfre.de (linfre.de [83.151.26.85]) (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 F0D0E129A16; Thu, 12 Jan 2017 21:10:06 -0800 (PST) Received: from [127.0.0.1] (109.45.0.162) by linfreserv (Axigen) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA id 2C8500; Fri, 13 Jan 2017 06:09:47 +0100 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20170113050947.6025298.97977.75536@linfre.de> Date: Fri, 13 Jan 2017 06:09:47 +0100 From: Karsten Thomann In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> To: Randy Bush , Brian E Carpenter X-AXIGEN-DK-Result: No records DomainKey-Status: no signature X-AxigenSpam-Level: 5 Archived-At: Cc: IETF , IPv6 List , draft-ietf-6man-rfc4291bis.all@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 05:10:09 -0000 =C2=A0 Originalnachricht =C2=A0 Von: Randy Bush Gesendet: Freitag, 13. Januar 2017 01:51 An: Brian E Carpenter Cc: IPv6 List; int-dir@ietf.org; Bob Hinden; draft-ietf-6man-rfc4291bis.all= @ietf.org; IETF Betreff: Re: Review of draft-ietf-6man-rfc4291bis-06 > RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exc= eption. > To be precise it says: >=20 > The de facto length of almost all IPv6 interface identifiers is > therefore 64 bits. The only documented exception is in [RFC6164], > which standardizes 127-bit prefixes for point-to-point links between > routers, among other things, to avoid a loop condition known as the > ping-pong problem. >=20 > I would suggest adding a similar exception statement in 4291bis. =C2=A0just get rid of classful addressing. we went through this in the '90s. =E2=80=8EI can only support this, while /127 is a good exception for ptp li= nks, it's still useless for small nets with 4-5 IPs like a network between = routers and a Firewall cluster. From nobody Thu Jan 12 23:03:16 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64908129AB7; Thu, 12 Jan 2017 23:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 7EAdrCYj8mY4; Thu, 12 Jan 2017 23:03:10 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 34388129AAC; Thu, 12 Jan 2017 23:03:10 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cRvtD-0003Ii-ME; Fri, 13 Jan 2017 07:03:08 +0000 Date: Fri, 13 Jan 2017 16:03:05 +0900 Message-ID: From: Randy Bush To: Brian E Carpenter In-Reply-To: <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IPv6 List , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, IETF Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 07:03:11 -0000 >> and then next year we will go through another draft and have another >> exception. just get rid of classful addressing. we went through >> this in the '90s. > > The problem is (and why we wrote 7421) is that stuff breaks with > subnet prefixes longer than 64, *except* for the point-to-point case > covered by 6164. Yes, I see the problem in enshrining this but I think > we face signifcant issues if we do otherwise. > > What we could conceivably say is that /64 is mandatory except for > links where SLAAC will never be used. i have no problem with this. i use slaac in environments where ip assignment is unimportant and there is only one exit, such as my home networks. fwiw, in racks, i use static addressing for ipv6 because dhcpv6 is broken. randy From nobody Thu Jan 12 23:09:02 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7159412948F; Thu, 12 Jan 2017 23:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Ntl5aEPLZtaH; Thu, 12 Jan 2017 23:09:00 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2B3B3129479; Thu, 12 Jan 2017 23:09:00 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cRvys-0003L2-Bp; Fri, 13 Jan 2017 07:08:58 +0000 Date: Fri, 13 Jan 2017 16:08:55 +0900 Message-ID: From: Randy Bush To: Lorenzo Colitti In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, Brian E Carpenter Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 07:09:01 -0000 > So while Randy may well be right that we will move away from classful > eventually that is the line i was fed 15+ years ago. i did not accept it then and i see no good reason to accept it now. > we certainly never had it in the top 64 bite of the address bzzt! you may want to look at rfc 2450. > For now, I'd much prefer to just add a similar exception to the one we > have in 7421. you'll need to start an iana registry. for p2p some use /127, some /126, and i have seen /120 on a multipoint mesh, worked fine. we have had to fight massively with vendors to make it classless. please do not give them excuses to break things. randy From nobody Thu Jan 12 23:17:03 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EFE1294AB; Thu, 12 Jan 2017 23:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 7GHnV5ceNUoQ; Thu, 12 Jan 2017 23:16:56 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by ietfa.amsl.com (Postfix) with ESMTP id D48CC126B6D; Thu, 12 Jan 2017 23:16:55 -0800 (PST) Received: from localhost (bizet.nethelp.no [IPv6:2001:8c0:9e04:500::1]) by bizet.nethelp.no (Postfix) with ESMTP id B49ACE6065; Fri, 13 Jan 2017 08:16:54 +0100 (CET) Date: Fri, 13 Jan 2017 08:16:54 +0100 (CET) Message-Id: <20170113.081654.41643721.sthaug@nethelp.no> To: randy@psg.com From: sthaug@nethelp.no In-Reply-To: References: <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: ipv6@ietf.org, ietf@ietf.org, int-dir@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-rfc4291bis.all@ietf.org, lorenzo@google.com Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 07:16:57 -0000 > > For now, I'd much prefer to just add a similar exception to the one we > > have in 7421. > > you'll need to start an iana registry. for p2p some use /127, some > /126, and i have seen /120 on a multipoint mesh, worked fine. /124 is also used, works fine. > we have had to fight massively with vendors to make it classless. > please do not give them excuses to break things. Agreed. IPv6 is classless. End of story. Steinar Haug, AS2116 From nobody Thu Jan 12 23:31:36 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61C712951F for ; Thu, 12 Jan 2017 23:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQGsm4s7X0Oj for ; Thu, 12 Jan 2017 23:31:29 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 0E3611294B3 for ; Thu, 12 Jan 2017 23:31:29 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id 35so31447708uak.1 for ; Thu, 12 Jan 2017 23:31:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IqCSEjiUsSlu7HVzTqOlaxXEBuwS//Hpb4oi5j6mB9U=; b=oVoAPQGUNtf6GhuIn6S8cUXBOA0pTOF02yyqBWYUucR/GfdNC1tMQz/AfPWVhLZ2Zr W3YXjAFcKInSpnndtKf8yx2lpmhyIbMXRoYc+RJ6h6vuVUjDWmBMmdob/HTTu6bFIbP0 WxkZNQVb/xiWUBVaDm1GoBP8R7pov/r46TEMUoFcMN/4XaSeuqVidNO6N/pRA9WDX9gE kjPZZjQ6d0Ykn9vjHwlLqbt1PPeNKuy7X8vbsg4Wle6BKOGHaFC+M5dAlano6lX2M5GI bbwItz/VgkTdkE45bGD16uSJYrI0C46eRVeeHWULJYGFDZoEDkwkmY85fyjm6QZyRmh8 2oYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IqCSEjiUsSlu7HVzTqOlaxXEBuwS//Hpb4oi5j6mB9U=; b=a6TvT42vNZNREkOzQoIadqZacJQZcLj1UhLXUnbHMTyrTA873wf8gNEaNQvllYMJmD cyVR/UAk9NtXDecQN+r5YGoraviILyyzSMm5Lo11VeqFamx5Z5u3/IZNwB1ht3PkXmBr Vu4kLMGN+8JedwTrvOZOEyX9Y4NTCELqZn9CFvKddrLup/8UmUeHhKUiMEXJ7UN9q2hq 9j9bK1OWMNLiWZSV9cx33AQvIOIBhwarIL7E8/Tj3kLgDUu/rz5CC2kOOhhDiY4qtVoi Bn99ZnY5I3CgcwPVlCymh7yQ94n7sBDWAtzIMcW7KwWfgj1LRvK79SSw03oCcIKKJfYI PWXg== X-Gm-Message-State: AIkVDXLYEHdnhpl3VFgi4B5ZF83k0+uP2epR+kTj8LAewXGQ4VlLXXWrpB8EgE5bvZ2cMo+lLTNWnxQHz+Zkpo/8 X-Received: by 10.159.48.203 with SMTP id k11mr9754814uab.42.1484292688018; Thu, 12 Jan 2017 23:31:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.49.77 with HTTP; Thu, 12 Jan 2017 23:31:07 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> From: Lorenzo Colitti Date: Fri, 13 Jan 2017 16:31:07 +0900 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=f403045e34f469bbf40545f4d233 Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, Brian E Carpenter Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 07:31:31 -0000 --f403045e34f469bbf40545f4d233 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 13, 2017 at 4:08 PM, Randy Bush wrote: > > So while Randy may well be right that we will move away from classful > > eventually > > that is the line i was fed 15+ years ago. i did not accept it then and > i see no good reason to accept it now. > You might in another 15 years :) > > we certainly never had it in the top 64 bite of the address > > bzzt! you may want to look at rfc 2450. > Oh wow. Yes, I had forgotten. But that was not just classful addressing, that would have been a much bigger change, with business implications as well. > > For now, I'd much prefer to just add a similar exception to the one we > > have in 7421. > > you'll need to start an iana registry. for p2p some use /127, some > /126, and i have seen /120 on a multipoint mesh, worked fine. > I'm sure they worked fine. I don't know if there will be consensus to change the documents to say that those lengths are in spec. > we have had to fight massively with vendors to make it classless. > please do not give them excuses to break things. > On a lot of hardware /65 - /126 is not very well-supported. --f403045e34f469bbf40545f4d233 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 13, 2017 at 4:08 PM, Randy Bush <randy@psg.com> wrote:
> So while Randy may w= ell be right that we will move away from classful
> eventually

that is the line i was fed 15+ years ago.=C2=A0 i did not accept it = then and
i see no good reason to accept it now.

= You might in another 15 years :)
=C2=A0
> we certainly never had it in the top 64 bi= te of the address

bzzt!=C2=A0 you may want to look at rfc 2450.
<= br>
Oh wow. Yes, I had forgotten. But that was not just classful = addressing, that would have been a much bigger change, with business implic= ations as well.
=C2=A0
> For now, I'd much prefer to just add a similar exceptio= n to the one we
> have in 7421.

you'll need to start an iana registry.=C2=A0 for p2p some use /1= 27, some
/126, and i have seen /120 on a multipoint mesh, worked fine.

I'm sure they worked fine. I don't know if t= here will be consensus to change the documents to say that those lengths ar= e in spec.
=C2=A0
we have had to fight massively with vendors to make it classless.
please do not give them excuses to break things.

<= /div>
On a lot of hardware /65 - /126 is not very well-supported.
=
--f403045e34f469bbf40545f4d233-- From nobody Thu Jan 12 23:34:21 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA3B1294EC; Thu, 12 Jan 2017 23:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 dQ2emMd4Mdyt; Thu, 12 Jan 2017 23:34:19 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 50CE4129AD3; Thu, 12 Jan 2017 23:34:14 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cRwNH-0003Y9-OR; Fri, 13 Jan 2017 07:34:12 +0000 Date: Fri, 13 Jan 2017 16:34:09 +0900 Message-ID: From: Randy Bush To: Lorenzo Colitti In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, Brian E Carpenter Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 07:34:20 -0000 >> we have had to fight massively with vendors to make it classless. >> please do not give them excuses to break things. > > On a lot of hardware /65 - /126 is not very well-supported. guess the business reason why. the classful spec gave them a good excuse to do a tcam rinse repeat. i pay to feed the darned chickens, it's time to break the egg. randy From nobody Thu Jan 12 23:40:54 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7205129AE4 for ; Thu, 12 Jan 2017 23:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpEMAvptRTsQ for ; Thu, 12 Jan 2017 23:40:43 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 A8A60129AD4 for ; Thu, 12 Jan 2017 23:40:41 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id r136so28439296vke.1 for ; Thu, 12 Jan 2017 23:40:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vgrydZisq0VfDIvgW3Ddd+gjpQx1+qhTo6aBnPcHvFM=; b=eEDWwbDfOe8DwVxqSEp5mnTWaXppc+yJafv9wQI9cmma+RPchKcupjyFzVbMICLmnz 4HH3u6C0eArrzRXrQ4imC5P4KW/pbxqIS536O0sMHHHTXiH4u/Fu4iZEKhhg1EXhKiRG nca0IG14H9vrQPGzT7w09PGZgWACAhTZ3QLP1vtNDg5SR8wM3lw2DXZNnCr+s6LGKLo0 A1VZu+7CNRPYCIsUK53bjKDk95aGC8CEUAUDgT4fRbd8wxECoMgLlakmMcAL/AY3kP4l H7L1mllua5/eJRZKS/GgSjU2LYEoOrS1bVVz5fzHRNcpX82fI8Qx1z9jeW8V4Axl3aL4 wKkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vgrydZisq0VfDIvgW3Ddd+gjpQx1+qhTo6aBnPcHvFM=; b=KfUXxjUxPvIFaoH82JUngUSX83+m+D+2WP/+XB9nJ33cCrDQaehte00pysIG/qNeww SUbrxlu1W6bYwleVv7E0iAd2yxSqs3u8hB89wtxNP6MRXBmIqLTKKVjorGVQYGXii3z6 QdRt+fpbTdFyI+hc56xGlIBkVFSoA4lzhVTBfRGa5nkVgnNQlHVeT/4qzQPmcKj1a8st Ify6QnWvpOVznqneNvquDZ9BNlpJIYkvNpmZ8db2wl+W5Sm4Kj6UD5j13sYlSZ2naAbQ NoFHHHGTc9OULqz6I/iWNvmkPx7NpUBpnjWJOcZi6Lsg/blnwfbXMfbFLMw22rU38fBg ZMSA== X-Gm-Message-State: AIkVDXIuUK9n8pzV7pz6k8hXdZY9eLd4f9kpnXUCknlaQmH3W3NNy11JvaPH9kydOXeynEbCPOOEpTjdXxlesFWv X-Received: by 10.31.88.1 with SMTP id m1mr9161178vkb.83.1484293240591; Thu, 12 Jan 2017 23:40:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.49.77 with HTTP; Thu, 12 Jan 2017 23:40:19 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> From: Lorenzo Colitti Date: Fri, 13 Jan 2017 16:40:19 +0900 Message-ID: To: Randy Bush Content-Type: multipart/alternative; boundary=001a114e5364595c7b0545f4f381 Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, Brian E Carpenter Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 07:40:46 -0000 --001a114e5364595c7b0545f4f381 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 13, 2017 at 4:34 PM, Randy Bush wrote: > >> we have had to fight massively with vendors to make it classless. > >> please do not give them excuses to break things. > > > > On a lot of hardware /65 - /126 is not very well-supported. > > guess the business reason why. the classful spec gave them a good > excuse to do a tcam rinse repeat. i pay to feed the darned chickens, > it's time to break the egg. > But it's true that supporting /65-/126 increases the cost of the device. The extra bits have to go somewhere. I think I've seen hardware that just converted all prefixes to 128 bit if there was at least one /65 - /126 prefix in the FIB. That costs money for RAM. Obviously that's silly if those prefixes are frequent, and you can save that money using better software engineering - but software engineering costs money too. Prefixes don't cost money, and if we know that we won't run out of them, what's the problem? --001a114e5364595c7b0545f4f381 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 13, 2017 at 4:34 PM, Randy Bush <randy@psg.com> wrote:
>> we have had to f= ight massively with vendors to make it classless.
>> please do not give them excuses to break things.
>
> On a lot of hardware /65 - /126 is not very well-supported.

guess the business reason why.=C2=A0 the classful spec gave them a g= ood
excuse to do a tcam rinse repeat.=C2=A0 i pay to feed the darned=C2=A0 chic= kens,
it's time to break the egg.

But it&= #39;s true that supporting /65-/126 increases the cost of the device. The e= xtra bits have to go somewhere. I think I've seen hardware that just co= nverted all prefixes to 128 bit if there was at least one /65 - /126 prefix= in the FIB. That costs money for RAM. Obviously that's silly if those = prefixes are frequent, and you can save that money using better software en= gineering - but software engineering costs money too. Prefixes don't co= st money, and if we know that we won't run out of them, what's the = problem?
--001a114e5364595c7b0545f4f381-- From nobody Fri Jan 13 11:34:05 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226C112940F; Fri, 13 Jan 2017 11:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfUM_Gnr_TVZ; Fri, 13 Jan 2017 11:34:01 -0800 (PST) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 933B81293FC; Fri, 13 Jan 2017 11:34:01 -0800 (PST) Received: by mail-pf0-x241.google.com with SMTP id 127so9551772pfg.0; Fri, 13 Jan 2017 11:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=McE9c4oc1E5g2S4SStJ9J3GKVvJGTupaBba1ji543qI=; b=boiLHfJmhNLeXv3Mrei5XLfHldfZClxRrzOUfeMGXAUAO8sHxElTGSf/TJjTXAbXbh rO7D6F7820o8qNfpyrbW0UXet4GBkRhEqgh949XmzfbkkNok8BW+6HFrrYy0pPWnR0VO vPO46+xejiZmJ7RzabsTsme56IAhadaZjzui8OdPxuJjBdrlGIIJOYqYe+jlaBMcfdP6 zgrMJNG0cMIf28sy2bfT2yyor5GUPKnsdTrEUOLwTHOXSHKQtpaP50hCR7BPBkfQ7oy9 LnF8vNAL7/7NkShnciMr4RLXlrIzt8NtPiCf/PmL0haAm22EoDR7KA6EPr/wgfBZl9E9 liMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=McE9c4oc1E5g2S4SStJ9J3GKVvJGTupaBba1ji543qI=; b=or9FVZikkdpkg9YmWQ4n86sZVoIVwKApO8dKongi0cLPac6+oOmVsj30SrScXAJlOR VrdL6b3s3VyFb2KKns6Is2yJygy3wlSZ2RO5fKAX2Jau7gMt5EUsZ0gFpGj0+GOxNDmQ P4bY1657n1T0ju4P0KNK3uTP9UTfKectixnOb8BWPXbrjHTqbkN+JWDwulKTKj5TQUoN 3SA9onAyGF+sMzUVbCLJ8e2yzFBOIKTuS3hmvmOpTsAFNVrTIyXywBBfKiUIAbW/T1DF ZZC7hin5OW9kHg+8GcpvEi7WWrz9rz5tG5ot/5Z+41VrIDSU/vWugpJwOMKXQjBawATe MJsw== X-Gm-Message-State: AIkVDXICifsqx3o18i9AHxxSLA007Rv77NfTyi7GeHdPTiMa+NNtjoyW9QHIyTm3EEYhnQ== X-Received: by 10.99.128.65 with SMTP id j62mr12339228pgd.87.1484336041039; Fri, 13 Jan 2017 11:34:01 -0800 (PST) Received: from [192.168.178.21] ([118.148.125.124]) by smtp.gmail.com with ESMTPSA id u14sm31047520pfg.18.2017.01.13.11.33.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 11:34:00 -0800 (PST) To: Karsten Thomann References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <20170113050947.6025298.97977.75536@linfre.de> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 14 Jan 2017 08:34:07 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170113050947.6025298.97977.75536@linfre.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF , IPv6 List , draft-ietf-6man-rfc4291bis.all@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 19:34:04 -0000 On 13/01/2017 18:09, Karsten Thomann wrote: >=20 > Originalnachricht =20 > Von: Randy Bush > Gesendet: Freitag, 13. Januar 2017 01:51 > An: Brian E Carpenter > Cc: IPv6 List; int-dir@ietf.org; Bob Hinden; draft-ietf-6man-rfc4291bis= =2Eall@ietf.org; IETF > Betreff: Re: Review of draft-ietf-6man-rfc4291bis-06 >=20 >> RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an = exception. >> To be precise it says: >> >> The de facto length of almost all IPv6 interface identifiers is >> therefore 64 bits. The only documented exception is in [RFC6164], >> which standardizes 127-bit prefixes for point-to-point links between >> routers, among other things, to avoid a loop condition known as the >> ping-pong problem. >> >> I would suggest adding a similar exception statement in 4291bis. >=20 > just get rid of classful addressing. we went through this > in the '90s. >=20 > =E2=80=8EI can only support this, while /127 is a good exception for pt= p links, it's still useless for small nets with 4-5 IPs like a network be= tween routers and a Firewall cluster. Please read RFC 7421. For example From an early stage, implementations and deployments of IPv6 assumed the /64 subnet length, even though routing was based on prefixes of any length. ... The main practical consequence of the existing specifications is that deployments in which longer subnet prefixes are used cannot make use of SLAAC-configured addresses and require either manually configured addresses or DHCPv6. Nobody is trying to un-CIDRise IPv6. But the price of not applying the /64 subnet size is that you lose automatic addressing. The 4291bis text doesn't yet explain this clearly enough. Brian From nobody Fri Jan 13 11:45:00 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AABC129DA2; Fri, 13 Jan 2017 11:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 orO-SYn_Pxtq; Fri, 13 Jan 2017 11:44:53 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E218129DA0; Fri, 13 Jan 2017 11:44:53 -0800 (PST) Received: from [192.168.3.95] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C981B82997; Fri, 13 Jan 2017 20:44:44 +0100 (CET) To: Brian E Carpenter , Randy Bush References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: <513edeeb-1713-13c5-3e44-97d79f19da6f@si6networks.com> Date: Fri, 13 Jan 2017 16:44:23 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Bob Hinden , IETF , IPv6 List , draft-ietf-6man-rfc4291bis.all@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 19:44:56 -0000 On 01/12/2017 10:55 PM, Brian E Carpenter wrote: > On 13/01/2017 13:50, Randy Bush wrote: >>> RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exception. >>> To be precise it says: >>> >>> The de facto length of almost all IPv6 interface identifiers is >>> therefore 64 bits. The only documented exception is in [RFC6164], >>> which standardizes 127-bit prefixes for point-to-point links between >>> routers, among other things, to avoid a loop condition known as the >>> ping-pong problem. >>> >>> I would suggest adding a similar exception statement in 4291bis. >> >> and then next year we will go through another draft and have another >> exception. just get rid of classful addressing. we went through this >> in the '90s. > > The problem is (and why we wrote 7421) is that stuff breaks with subnet > prefixes longer than 64, *except* for the point-to-point case covered > by 6164. Yes, I see the problem in enshrining this but I think we face > signifcant issues if we do otherwise. > > What we could conceivably say is that /64 is mandatory except for > links where SLAAC will never be used. (SLAAC itself is designed > to work with any reasonable length of IID, but again in practice it > only works with /64, because we need mix-and-match capability. So > although IID length is a parameter in the SLAAC design, it's a > parameter whose value needs to be fixed globally.) Well, yes and no. With the traditional slaac (embed the mac address) it only works with 64-bit IIDs. With something like RFC7217 (grab as many bits as needed to for an IID), it could work. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jan 13 11:46:14 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DAE129DA2; Fri, 13 Jan 2017 11:46:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 NgThEzuczR5F; Fri, 13 Jan 2017 11:46:05 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08380129DB0; Fri, 13 Jan 2017 11:46:05 -0800 (PST) Received: from [192.168.3.95] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6E08E829B9; Fri, 13 Jan 2017 20:45:59 +0100 (CET) To: Suresh Krishnan , Randy Bush References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> From: Fernando Gont Message-ID: <75eca52d-f908-6933-fd06-f86c2e7cfef2@si6networks.com> Date: Fri, 13 Jan 2017 16:45:49 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-6man-rfc4291bis.all@ietf.org, Bob Hinden , IPv6 List , IETF , int-dir@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 19:46:07 -0000 On 01/13/2017 12:55 AM, Suresh Krishnan wrote: > Hi Randy, > > On Thu, Jan 12, 2017 at 7:49 PM, Randy Bush wrote: >>>> to be clear, i have no problem with iids being 64-bit. my issue is with >>>> unicast globals being classful in 2.4.4. >>> Randy I take your point, but this supposed conflict isn't new, it's not >>> introduced in 4291bis, it goes back to RFC3513. >> >> i know; and i have pushed back every cm of the way. it took years to >> get the other classful insanity, tls/nla, removed. the old cidr war >> continues. this last bit of classfulness (excuse the word) too will >> pass. >> >>> Do you have a suggestion how to change this within the context of >>> advancing this to Internet Standard? >> >> yes. simply remove the mandatory requirement for classful global >> unicast addresses. > > I do see your point but I do not feel it is equivalent to classful > addressing in IPv4. i.e. Looking at the leading X bits does not > directly determine the IID length. Isn't that the case for the address block we're currently employing? - the IID is defined to be 64 bits. -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jan 13 11:58:21 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C285129DB7; Fri, 13 Jan 2017 11:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTWcGHsYiG0J; Fri, 13 Jan 2017 11:58:10 -0800 (PST) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::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 8739D129DB5; Fri, 13 Jan 2017 11:58:10 -0800 (PST) Received: by mail-pf0-x243.google.com with SMTP id f144so9627721pfa.2; Fri, 13 Jan 2017 11:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jkofa3rGA+MwK7LkC97hv+ioepk9JPqnZKSj8+z7N3g=; b=RZmXHIM5iGgsFJda34WeE+MNzYbuLZ079FkctnUjZCv+qh8vl9lpiTBwYpdxUh6OYK 3pDyrhZNiFmvy2xAOzat1c4Y5OuCuxFyAVspuuXtjPnTQGAItVOSYJH1QSNCTIqoBOKN tpkjYxq55o/pwVcsGXZVrpY4lVWwrfxv/dYQt0n2RcUIAnNhAUqd353D0R5X9b8f47Gk XxpVZdpbZTHbLNEkFf5aZD58wD9CzF5ApiJZJJ+0acvmbvi9u8YWmm8DPPyDerEaQEPZ t7Cd1BjMeE3YNTGNnM2YqtML7ocdNRzB6ZbPNTDOBdnF3P3lHw8ikOrOxCR22WLx+wv0 9qcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=jkofa3rGA+MwK7LkC97hv+ioepk9JPqnZKSj8+z7N3g=; b=pwvUyFTO2gMIyxeEF0+Ln+fgCOBRwWZ1CdL3vsQ4rf0i37HfXlHd5MJ4m3fyjtKpJS RonIOkWr4/iBuvO30CyRHNdf7GFqkuICTtoHe+6fpRorxyVSwpPb8TIp1P/27E8AsLO2 Z5X6jYpaK9nvg+9iN+gPEaY2tUfZsVj2zIVlBuWnlmNYuRCz0lP0uTjpbWmExjWxX8eo 44MUSdI6YUbJ8GubM6qOvL6i+M3KdnZJxI1Ou9waj+nErx2iYzLXG1yMU6GCsqS634xX gOkxLmv/L33gOkyXMYtbM+RuTEmdFvVca8KwYQeuQm0VDWSSRfJV/Tmc0y+Vqe4Pn+V6 L/nw== X-Gm-Message-State: AIkVDXIKywgVgndqf2gV4NXt6JHY0RBvb6kkRBSfrIGe8TRHZgD2vKHLFpEeWUo4st+zGA== X-Received: by 10.99.181.7 with SMTP id y7mr25739624pge.51.1484337490083; Fri, 13 Jan 2017 11:58:10 -0800 (PST) Received: from [192.168.178.21] ([118.148.125.124]) by smtp.gmail.com with ESMTPSA id x2sm31037494pfx.65.2017.01.13.11.58.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 11:58:09 -0800 (PST) To: Fernando Gont , Randy Bush References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <513edeeb-1713-13c5-3e44-97d79f19da6f@si6networks.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <23b17a55-35e1-cf1d-3ab7-dba6bf7390e3@gmail.com> Date: Sat, 14 Jan 2017 08:58:15 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <513edeeb-1713-13c5-3e44-97d79f19da6f@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Bob Hinden , IETF , IPv6 List , draft-ietf-6man-rfc4291bis.all@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 19:58:12 -0000 Regards Brian Carpenter On 14/01/2017 08:44, Fernando Gont wrote: > On 01/12/2017 10:55 PM, Brian E Carpenter wrote: >> On 13/01/2017 13:50, Randy Bush wrote: >>>> RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exception. >>>> To be precise it says: >>>> >>>> The de facto length of almost all IPv6 interface identifiers is >>>> therefore 64 bits. The only documented exception is in [RFC6164], >>>> which standardizes 127-bit prefixes for point-to-point links between >>>> routers, among other things, to avoid a loop condition known as the >>>> ping-pong problem. >>>> >>>> I would suggest adding a similar exception statement in 4291bis. >>> >>> and then next year we will go through another draft and have another >>> exception. just get rid of classful addressing. we went through this >>> in the '90s. >> >> The problem is (and why we wrote 7421) is that stuff breaks with subnet >> prefixes longer than 64, *except* for the point-to-point case covered >> by 6164. Yes, I see the problem in enshrining this but I think we face >> signifcant issues if we do otherwise. >> >> What we could conceivably say is that /64 is mandatory except for >> links where SLAAC will never be used. (SLAAC itself is designed >> to work with any reasonable length of IID, but again in practice it >> only works with /64, because we need mix-and-match capability. So >> although IID length is a parameter in the SLAAC design, it's a >> parameter whose value needs to be fixed globally.) > > Well, yes and no. With the traditional slaac (embed the mac address) it > only works with 64-bit IIDs. With something like RFC7217 (grab as many > bits as needed to for an IID), it could work. Technically that's true, but you can't mix IID sizes on a given link and expect it to work, so any legacy system will force the whole link to use /64. Brian From nobody Fri Jan 13 12:03:41 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46ED12711D; Fri, 13 Jan 2017 12:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 AWCtUPlaP03O; Fri, 13 Jan 2017 12:03:35 -0800 (PST) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F593127078; Fri, 13 Jan 2017 12:03:35 -0800 (PST) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id EE55E87CED; Fri, 13 Jan 2017 20:03:34 +0000 (UTC) Date: Fri, 13 Jan 2017 20:03:34 +0000 From: heasley To: Lorenzo Colitti Message-ID: <20170113200334.GO40198@shrubbery.net> References: <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , Randy Bush , draft-ietf-6man-rfc4291bis.all@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 20:03:37 -0000 Fri, Jan 13, 2017 at 04:40:19PM +0900, Lorenzo Colitti: > But it's true that supporting /65-/126 increases the cost of the device. > The extra bits have to go somewhere. I think I've seen hardware that just > converted all prefixes to 128 bit if there was at least one /65 - /126 > prefix in the FIB. That costs money for RAM. Obviously that's silly if > those prefixes are frequent, and you can save that money using better > software engineering - but software engineering costs money too. do such limited devices really need complex ribs/fibs? address, router, neighbors. all of which are needed regardless of the prefix length. > Prefixes > don't cost money, but, they do: https://www.arin.net/fees/fee_schedule.html > and if we know that we won't run out of them do we know this? and 640k RAM is plenty. i'm not convinced. > the problem? rfc6164 s5.1, s5.2. s5.2 applies to your ram-limited devices. end users that want to subnet can't w/o additional /64s. From nobody Fri Jan 13 12:55:26 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D149129E41; Fri, 13 Jan 2017 12:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W6XW6rtw6yv; Fri, 13 Jan 2017 12:55:20 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 99098129DD5; Fri, 13 Jan 2017 12:55:20 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id r136so41190997vke.1; Fri, 13 Jan 2017 12:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CaJ/v6v05QmyHsPWn0pFNO/XG1bOX6+iuIjT4hl9oa0=; b=Z9bgxrbNR1Vx1mqOHbJwO6M7vZD0e22dGf0hQCLaTdMoNbGlCPGsmCt7MFibXbJ0rN D7VMwr9f/kqVgYlb1x3QChikICOf5UEs9QBqWt/jaJMiU1JUQ01JzkyV+/PixiOub2WU 0ouP9SRHY2Nw07IA0l6G+6vTb5RBe4jjvDyOwS8mWh8LVPS7ZXLEAQj68G9VyeRH1eTD sk7E5X/WHgH5g7U36OqTJHRKI42FTJ4BQ1V/cXXrh/FRJDT2WptSxIWg9HTq7KaG0Jfj +1JHgLeKFD5K/2V7Q8ZsLVFuqhKFNol7wmCZVEBUc2YVZwgkY2xz1J0uPTvMa/0/YQ5t 3qtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CaJ/v6v05QmyHsPWn0pFNO/XG1bOX6+iuIjT4hl9oa0=; b=LuHS+ao7wh9K+F/287lAKvp8sycaICTcH/BMcvIh7FNqqynowJ15R4KAm41MQXeKOC LRwCxsjAWgPdjN8hDA/aFBFtMAGXaKoj6bGkHzIwtUCBHpt+MlIVoWVaiMkp+VraVCfW Tefaf46qLwhOsliYrk6oddINBiT3+JrBQ5T/2zLzxcSE4pZbR9/QOAX0dCInWdWxdHU1 BlKsQ1Lq/Q4L1ULX48PNubHzzi0aeYVTIW9zLI8Jh7miFAvL2Bj6oqxWUaVtn3u4h7PK JKszEnOBZ8K9Byr80MYyGB2oIgx+HY6SV1ZjfzC6toF9126f7pUa//Do+k+36yQR+fAi agAQ== X-Gm-Message-State: AIkVDXI70WSlFwc1JqGZZYdwoneqv4URa2CQ2vpj9c8I/bg8X6UO4f4FE3fnENxdAjuOg4YgKRGZ5Himz1v6Sg== X-Received: by 10.31.203.132 with SMTP id b126mr8754667vkg.75.1484340919640; Fri, 13 Jan 2017 12:55:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Fri, 13 Jan 2017 12:54:48 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> From: Mark Smith Date: Sat, 14 Jan 2017 07:54:48 +1100 Message-ID: To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, David Farmer , Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 20:55:22 -0000 On 13 January 2017 at 11:49, Randy Bush wrote: >>> to be clear, i have no problem with iids being 64-bit. my issue is with >>> unicast globals being classful in 2.4.4. >> Randy I take your point, but this supposed conflict isn't new, it's not >> introduced in 4291bis, it goes back to RFC3513. > > i know; and i have pushed back every cm of the way. it took years to > get the other classful insanity, tls/nla, removed. the old cidr war > continues. this last bit of classfulness (excuse the word) too will > pass. > >> Do you have a suggestion how to change this within the context of >> advancing this to Internet Standard? > > yes. simply remove the mandatory requirement for classful global > unicast addresses. > I think people are combining together in this thread two separate things: - the addressing structure - how addresses are processed by routers when the router is forwarding a packet. In IPv6 they're separate things, in classful IPv4 they weren't (if I recall correctly). I think unicast IPv6 could only be described as classful if the structure of the address dictated how processing of addresses for forwarding occurred. (You could describe the difference between IPv6 unicast and multicast forwarding to be classful as forwarding is different for those two types of addresses.) BCP198/RFC7608, "IPv6 Prefix Length Recommendation for Forwarding" makes it very clear that forwarding is to occur based on the longest match rule of an IPv6 address, with no consideration of what the structure of the address happens to be for the purposes of device configuration or anything else. "Abstract IPv6 prefix length, as in IPv4, is a parameter conveyed and used in IPv6 routing and forwarding processes in accordance with the Classless Inter-domain Routing (CIDR) architecture. The length of an IPv6 prefix may be any number from zero to 128, although subnets using stateless address autoconfiguration (SLAAC) for address allocation conventionally use a /64 prefix. Hardware and software implementations of routing and forwarding should therefore impose no rules on prefix length, but implement longest-match-first on prefixes of any valid length." Regards, Mark. From nobody Fri Jan 13 13:02:51 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA49129E45; Fri, 13 Jan 2017 13:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Sqr0IIxox-xd; Fri, 13 Jan 2017 13:02:44 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F74129496; Fri, 13 Jan 2017 13:02:44 -0800 (PST) Received: from [192.168.3.95] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2B25D829A0; Fri, 13 Jan 2017 22:02:35 +0100 (CET) To: Brian E Carpenter , Randy Bush References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <513edeeb-1713-13c5-3e44-97d79f19da6f@si6networks.com> <23b17a55-35e1-cf1d-3ab7-dba6bf7390e3@gmail.com> From: Fernando Gont X-Enigmail-Draft-Status: N1110 Message-ID: Date: Fri, 13 Jan 2017 17:59:45 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <23b17a55-35e1-cf1d-3ab7-dba6bf7390e3@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Bob Hinden , IETF , IPv6 List , draft-ietf-6man-rfc4291bis.all@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 21:02:47 -0000 On 01/13/2017 04:58 PM, Brian E Carpenter wrote: > > On 14/01/2017 08:44, Fernando Gont wrote: >> On 01/12/2017 10:55 PM, Brian E Carpenter wrote: >>> On 13/01/2017 13:50, Randy Bush wrote: >>>>> RFC7421 (which is Informational) calls out RFC 6164 (not 6141!) as an exception. >>>>> To be precise it says: >>>>> >>>>> The de facto length of almost all IPv6 interface identifiers is >>>>> therefore 64 bits. The only documented exception is in [RFC6164], >>>>> which standardizes 127-bit prefixes for point-to-point links between >>>>> routers, among other things, to avoid a loop condition known as the >>>>> ping-pong problem. >>>>> >>>>> I would suggest adding a similar exception statement in 4291bis. >>>> >>>> and then next year we will go through another draft and have another >>>> exception. just get rid of classful addressing. we went through this >>>> in the '90s. >>> >>> The problem is (and why we wrote 7421) is that stuff breaks with subnet >>> prefixes longer than 64, *except* for the point-to-point case covered >>> by 6164. Yes, I see the problem in enshrining this but I think we face >>> signifcant issues if we do otherwise. >>> >>> What we could conceivably say is that /64 is mandatory except for >>> links where SLAAC will never be used. (SLAAC itself is designed >>> to work with any reasonable length of IID, but again in practice it >>> only works with /64, because we need mix-and-match capability. So >>> although IID length is a parameter in the SLAAC design, it's a >>> parameter whose value needs to be fixed globally.) >> >> Well, yes and no. With the traditional slaac (embed the mac address) it >> only works with 64-bit IIDs. With something like RFC7217 (grab as many >> bits as needed to for an IID), it could work. > > Technically that's true, but you can't mix IID sizes on a given link > and expect it to work, so any legacy system will force the whole link > to use /64. Well, you could say that you don't need to mix IID sizes on the same link: the IID size is whatever the local router happens to advertise (i.e., 128-Prefix_Length). And, if you do manual configuration, you're supposed to know the prefix length... -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jan 13 19:07:10 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94F31296EE; Fri, 13 Jan 2017 19:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 Tj2V-G_Cf7-p; Fri, 13 Jan 2017 19:07:03 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36071296AA; Fri, 13 Jan 2017 19:07:03 -0800 (PST) Received: from [198.252.137.70] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1cSEgH-000Aga-5S; Fri, 13 Jan 2017 22:07:01 -0500 Date: Fri, 13 Jan 2017 22:06:54 -0500 From: John C Klensin To: Lorenzo Colitti , Randy Bush Message-ID: <2A5073777007277764473D78@PSB> In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.70 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: draft-ietf-6man-rfc4291bis.all@ietf.org, Bob Hinden , IPv6 List , IETF , int-dir@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jan 2017 03:07:06 -0000 --On Friday, January 13, 2017 16:40 +0900 Lorenzo Colitti wrote: > But it's true that supporting /65-/126 increases the cost of > the device. The extra bits have to go somewhere. I think I've > seen hardware that just converted all prefixes to 128 bit if > there was at least one /65 - /126 prefix in the FIB. That > costs money for RAM. Obviously that's silly if those prefixes > are frequent, and you can save that money using better > software engineering - but software engineering costs money > too. Prefixes don't cost money, and if we know that we won't > run out of them, what's the problem? Because you can pick the scenario -- lots of "things", an interplanetary network, both, or something else-- but we have been here before. Every time someone has said "there is so much address space that we will never run out no matter how inefficiently we use them", they have eventually been proven wrong. That history is obviously not just with the ARPANET/Internet or even computer networks: "if we know we won't ever run out of them" has a nasty tendency to prove that we didn't know and didn't get it right. john From nobody Fri Jan 13 19:33:37 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E472F1293F5; Fri, 13 Jan 2017 19:33:35 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atVacAo5chE4; Fri, 13 Jan 2017 19:33:34 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 6E5D6129436; Fri, 13 Jan 2017 19:28:05 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id 75so92459pgf.3; Fri, 13 Jan 2017 19:28:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=4wvoy4pf9lVSDxPLScnBOMbbfsRh3H6RxnqB/4xdoMY=; b=myVyOWO9VvyRYbELppXBcXgO5KWxDo1OiJS8RHKW0zgsB84+E46GSa8Of2neh89zhb EoYIDdF83bxFMYs9ejb5I5yDiFm+mgQi/p/quTPi0OwzrIDa0rZiuy+95DLKTdFoMDD0 CpKZ49q+zCI8wzBBSVU/zOERL2xZsJ8QBZPOe3VudQMm6pGRXs/5CgJR+KRx/mc1pqQ6 0IRnI9TLWBjmqzkUOuSg/D99v5fkZ57xqyLufyPQvlcTv33M5P+V30xIMtcGM5posM/a kRB12o5Ai63TEO7V/YItFO8a4FpcAyIwk3YioVwHg+Toyu12PxyQZNB2D1MGt2CcMnlI 3AAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=4wvoy4pf9lVSDxPLScnBOMbbfsRh3H6RxnqB/4xdoMY=; b=q2O+ENIR6ur8FHwsx5Mb37c7Bv9j4RWTfHlGz8HTZVRbEwBLMSJiA2jyiMoAdQ5D0O cBlQjMbyFehC8YM5wbTUdyiwu/VQV1eG+QHbYCEssyybmGZGdC2J3riU+vW9uoHHsfLS uKBjbLvEVH1J/rxUFu2MyAKVMiM0+mxgg7JnH85OWq1fDWPXOYididRFoIb3HuY+vIzR N9MfFa6jHNfbwB2U0T1KWF5L3gOVKEy7CYy8dL/5xobXcdbdv6+WWJ7/CTVHCEuW2als tZagw+ogTNeLU3J+tJ4saqAMmTzzvCYxdL466CnVsz71ua14QVZvaeF5XYFDnOP/Uet8 ymqw== X-Gm-Message-State: AIkVDXLzMHeQv9DYSOLGAUobqP+VnVuqUW5c0+agTlSQ2nvbkwQvoWArxVEKnq/0w2/tXw== X-Received: by 10.98.133.202 with SMTP id m71mr26533280pfk.102.1484364484772; Fri, 13 Jan 2017 19:28:04 -0800 (PST) Received: from [192.168.178.21] ([118.148.125.124]) by smtp.gmail.com with ESMTPSA id y6sm32286658pge.16.2017.01.13.19.28.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 19:28:04 -0800 (PST) To: John C Klensin , Lorenzo Colitti , Randy Bush References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> From: Brian E Carpenter Organization: University of Auckland Message-ID: <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> Date: Sat, 14 Jan 2017 16:28:10 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <2A5073777007277764473D78@PSB> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: IPv6 List , int-dir@ietf.org, Bob Hinden , draft-ietf-6man-rfc4291bis.all@ietf.org, IETF Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jan 2017 03:33:36 -0000 On 14/01/2017 16:06, John C Klensin wrote: > > > --On Friday, January 13, 2017 16:40 +0900 Lorenzo Colitti > wrote: > >> But it's true that supporting /65-/126 increases the cost of >> the device. The extra bits have to go somewhere. I think I've >> seen hardware that just converted all prefixes to 128 bit if >> there was at least one /65 - /126 prefix in the FIB. That >> costs money for RAM. Obviously that's silly if those prefixes >> are frequent, and you can save that money using better >> software engineering - but software engineering costs money >> too. Prefixes don't cost money, and if we know that we won't >> run out of them, what's the problem? > > Because you can pick the scenario -- lots of "things", an > interplanetary network, both, or something else-- but we have > been here before. Every time someone has said "there is so > much address space that we will never run out no matter how > inefficiently we use them", they have eventually been proven > wrong. That history is obviously not just with the > ARPANET/Internet or even computer networks: "if we know we won't > ever run out of them" has a nasty tendency to prove that we > didn't know and didn't get it right. Which is exactly why we have so far only delegated 1/8 of the IPv6 address space for global unicast allocation, leaving a *lot* of space for fixing our mistakes. Moving away from /64 as the recommended subnet size might, or might not, prove to be necessary in the long term future. That's why the point about routing being classless is fundamental. I do think we need to be a bit more precise on this point in 4291bis. Brian From nobody Fri Jan 13 20:35:38 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D40129622 for ; Fri, 13 Jan 2017 20:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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_MED=-2.3, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYqN9jymj0kE for ; Fri, 13 Jan 2017 20:35:29 -0800 (PST) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 C7BAE129863 for ; Fri, 13 Jan 2017 20:35:29 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id 3B9A5C35 for ; Sat, 14 Jan 2017 04:35:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8LJOFUtGeqS for ; Fri, 13 Jan 2017 22:35:29 -0600 (CST) Received: from mail-vk0-f69.google.com (mail-vk0-f69.google.com [209.85.213.69]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 09C32C30 for ; Fri, 13 Jan 2017 22:35:28 -0600 (CST) Received: by mail-vk0-f69.google.com with SMTP id x75so39667431vke.5 for ; Fri, 13 Jan 2017 20:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oN59oPvweuCcfvcoVPcu61J9ndm40GdhdczuJwCE1jg=; b=lF079WU0oNsWbBCUwBmI0UTK7Qyc5XXgUssuK4K+dfiATNmcyQ/Ajpqi61sG97CbTE 9a3tRtfHujMbcZXUa2y1DiXKLjx+vvnlLy/pLe6Rt8g6tCumE6FHA9eCbeFDF0ri4Tdj sLP5j05Khy9sR3GAsRvRx3uFvUy9Mtp5nOECtDC7B4SH92yObiRgiwxM61wrXx06eZx6 8+afR6dTN08s0kRIIXCS6xaQoiBo0zH2rx9eukbntuaE62aFPZvpdxnEmlA1/ROYodyz +cQOWTXQqjcIj/vT4t9VUvf9WGPpBpzGfoDcMRSMUDEHDhJ0dAg6nbgQa4OvCO9Qdmda 9VVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oN59oPvweuCcfvcoVPcu61J9ndm40GdhdczuJwCE1jg=; b=JJmT0g04eUeuVhsMmjgqal+kuGzb+gcby2AtKVtnGwTf+MZIRVfuW+IQ1i98sn1Qzu iYTGSVkBxlivJXKiXxhNQcSpd0f4VlfLEv/rDyczscYerdSNs2IFYzuYgwRagZ/Zu7aQ m1qkCjyD4DIvLSm88LxCucMAvU8tvCplZIgu1KYViAXGwjXxLFxPS4gTtDB4PD4EFAXr 9o38v3fPtWrINcBOyRW7KEyO+2FGNzfgMhM/AioQwBt02p9izWp1oP/RWc/sRG5d9nGC bUNZT5mLyTVikpgsVzk/krOkM9fTaMBXsjTXzaBF8KmsTCgssaWMZ/kav8TpMCnctImF xy6g== X-Gm-Message-State: AIkVDXK9e3JD+9lSHcsNYMJTlQTqXzgMNkzqXa9lvwl0V8vqL/4yqQ3bsKWZW/cm/85uOrS7L/t37nmcXdAxYrRmwtefBfTtSJb4NViJER91rqXexV6DVf7f2ZkjCBnk1io4ktGSjF4BG5O+PELOIaE= X-Received: by 10.159.49.92 with SMTP id n28mr10834456uab.95.1484368528483; Fri, 13 Jan 2017 20:35:28 -0800 (PST) X-Received: by 10.159.49.92 with SMTP id n28mr10834451uab.95.1484368528319; Fri, 13 Jan 2017 20:35:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.84.15 with HTTP; Fri, 13 Jan 2017 20:35:27 -0800 (PST) In-Reply-To: <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: David Farmer Date: Fri, 13 Jan 2017 22:35:27 -0600 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f403045dd9d8d8b9450546067aff Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , Randy Bush , draft-ietf-6man-rfc4291bis.all@ietf.org, John C Klensin , Lorenzo Colitti Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jan 2017 04:35:33 -0000 --f403045dd9d8d8b9450546067aff Content-Type: text/plain; charset=UTF-8 On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > .... > > Which is exactly why we have so far only delegated 1/8 of the > IPv6 address space for global unicast allocation, leaving a *lot* > of space for fixing our mistakes. Moving away from /64 as the > recommended subnet size might, or might not, prove to be necessary in > the long term future. That's why the point about routing being > classless is fundamental. I do think we need to be a bit more > precise on this point in 4291bis. > > Brian Exactly, /64 is the RECOMMENDED subnet size, or a SHOULD from RFC2119, and I'm fine with that, but that's not what the following says. For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. Background on the 64 bit boundary in IPv6 addresses can be found in [RFC7421 ]. It says REQUIRED, that is a MUST from RFC2119, and I believe it to be an Imperative as discussed in section 6 of RFC2119. I'm fine with /64, /127 and /128 as the RECOMMENDED subnet sizes, I support that and believe it to be the consensus of the IETF. Maybe even explicitly noting /65 through /126 are NOT RECOMMENDED subnet sizes, and not support by SLACC. But it is not correct to say the /64 is REQUIRED. I also believe RFC7608 supports this conclusion. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --f403045dd9d8d8b9450546067aff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com> wrote:
....

Which is exactly why we have so far only delegated 1/8 of the
IPv6 address space for global unicast allocation, leaving a *lot*
of space for fixing our mistakes. Moving away from /64 as the
recommended subnet size might, or might not, prove to be necessary in
the long term future. That's why the point about routing being
classless is fundamental. I do think we need to be a bit more
precise on this point in 4291bis.

=C2=A0 =C2=A0 Brian

Exactly, /64 is the REC= OMMENDED subnet size, or a SHOULD from RFC2119, and I'm fine with that,= but that's not what the following says.

   For all unicast addresses, except those tha=
t start with the binary
   value 000, Interface IDs are required to be 64 bits long.  Background
   on the 64 bit boundary in IPv6 addresses can be found in [RFC7421].

It says REQUIRED, that is a MUST from RFC2119, and I believe it = to be an Imperative as discussed in section 6 of RFC2119. =C2=A0
=
I'm fine with /64, /127 and /128 as the RECOMMENDED subn= et sizes, I support that and=C2=A0believe it to be the consensus of the IET= F. Maybe even explicitly noting=C2=A0/65 through /126 are NOT RECOMMENDED s= ubnet sizes, and not support by SLACC.=C2=A0 But it is not correct to say t= he /64 is REQUIRED.

I also believe RFC7608 support= s this conclusion.

Thanks.

-- =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication Ser= vices
Office of Information Technology
University of Minnesota=C2=A0= =C2=A0
2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626= -0815
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--f403045dd9d8d8b9450546067aff-- From nobody Fri Jan 13 22:37:29 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9793E1294D6; Fri, 13 Jan 2017 22:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpiCwNfpQVNI; Fri, 13 Jan 2017 22:37:25 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 4B223129412; Fri, 13 Jan 2017 22:37:25 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id x75so46689429vke.2; Fri, 13 Jan 2017 22:37:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pUT6QvioyyNww5EhWv2PJc9RZsRP1bvtGbAxNhFd3L4=; b=IvcL4rxvsCyDGtH81/4Mdf9qSqOwri6UYeQ3sPeD9zupwhRQLnI7Vj6h/PFi/2NkYT mYFuId8e8X8B3S4+B1URBh4H+hfZjGhKP/PUFk4jbgFQTCx/8Klmri+Ze54Xc0g6fPrL 0nPrLWAZEBhJqxEGMCd20bWN22vYud7E7YPC1WvsiIViXBggqoacLoWIH4Gh0yM5Ln1U tDWdytAVS/GjOmFLVScLjM3uZSajCr2JUQfWn02zAow5eFFP4HOuDlX/rIRJf4Y6NM3K kTXaIJKBfIiD2E8/b2hFCDfqrMB/Q8qgjXTWOvFp0Ght2xkupBjsjAowGtgwyXP4ceO4 K1RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pUT6QvioyyNww5EhWv2PJc9RZsRP1bvtGbAxNhFd3L4=; b=b+v0aWKVFSLD6Qts3XpSoroTMMksNwKqpzaltk9mo0qPJiWtLFu/y3uIPesm479URE tglrDnOvvIIkXlAQKeS1y4e8+3F+Lrkw3v0fQ9A0eVf86okGGtJAW0zuSaDjKLKgRpYw 1QerW9JRjjJJADxb445q3KupEO2oh61C+Na1d6wbWp032l2zTgWfWB3oxuGQZXbugWPF 5m+aD59GJFT8QqJPtR8JZgRAlejGQLe0l1m79E/NkYFDNtC4AWu+QblgOpULbEDkPjbU jLyb5tXXYoeAzPTRnoewB5Sf4uJzoSzX0v+BB6q/z3WCUzoWDVilptHu5Uj4mzKvUTqB 9GdA== X-Gm-Message-State: AIkVDXJqZa3/gBIYCMmFCwPy/rbfK8ElU5WPkdqmqvYWvxT0h2ewu/axgGtzhQypVQ5A7vWQhwDE5Gq2Elvinw== X-Received: by 10.31.79.132 with SMTP id d126mr11318853vkb.165.1484375844234; Fri, 13 Jan 2017 22:37:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.2.235 with HTTP; Fri, 13 Jan 2017 22:37:23 -0800 (PST) Received: by 10.176.2.235 with HTTP; Fri, 13 Jan 2017 22:37:23 -0800 (PST) In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: Mark Smith Date: Sat, 14 Jan 2017 17:37:23 +1100 Message-ID: To: David Farmer Content-Type: multipart/alternative; boundary=001a114dd4cce8a94b0546082efe Archived-At: Cc: 6man WG , IETF , int-dir@ietf.org, Bob Hinden , Randy Bush , draft-ietf-6man-rfc4291bis.all@ietf.org, John C Klensin , Brian E Carpenter Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jan 2017 06:37:27 -0000 --001a114dd4cce8a94b0546082efe Content-Type: text/plain; charset=UTF-8 On 14 Jan. 2017 15:36, "David Farmer" wrote: On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > .... > > > Which is exactly why we have so far only delegated 1/8 of the > IPv6 address space for global unicast allocation, leaving a *lot* > of space for fixing our mistakes. Moving away from /64 as the > recommended subnet size might, or might not, prove to be necessary in > the long term future. That's why the point about routing being > classless is fundamental. I do think we need to be a bit more > precise on this point in 4291bis. > > Brian > Exactly, /64 is the RECOMMENDED subnet size, or a SHOULD from RFC2119, and I'm fine with that, but that's not what the following says. For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. Background on the 64 bit boundary in IPv6 addresses can be found in [RFC7421 ]. It says REQUIRED, that is a MUST from RFC2119, and I believe it to be an Imperative as discussed in section 6 of RFC2119. I'm fine with /64, /127 and /128 as the RECOMMENDED subnet sizes, I support that and believe it to be the consensus of the IETF. Maybe even explicitly noting /65 through /126 are NOT RECOMMENDED subnet sizes, and not support by SLACC. But it is not correct to say the /64 is REQUIRED. I don't think /127s should really be recommended either. They don't guarantee that the ping pong problem is solved, because it depends on both ends being configured with the /127 prefix length by the operator or operators at each end if the link. There is no protocol requirement that both ends of a link have the same prefix and prefix length, nor is there any protocol checking of that condition. For example, if an ISP configures a /127 on their end of the customer's link, but the customer just configures a default route on their end over the link, it is a legitimate configuration by the protocols, Internet access will work (so the customer might assume the link is configured correctly), and yet the link is vulnerable to a ping pong attach despite it "having" a /127 prefix. So it is a mitigation, however it relies on the operator or operators being disciplined about the configuration, and comes at the cost of other things that may be useful if a 64 bit IID was available e.g. protect against discovery of link addresses via unsolicited inbound probing if the IIDs are random (which may include static configuration of an offline generated random 64 bit IID). Regards, Mark. I also believe RFC7608 supports this conclusion. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --001a114dd4cce8a94b0546082efe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 14 Jan. 2017 15:36, "David Farmer" <farmer@umn.edu> wrote:
=

On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpe= nter <brian.e.carpenter@gmail.com> wrote:
....


Which is exactly why we have so far only delegated 1/8 of the
IPv6 address space for global unicast allocation, leaving a *lot*
of space for fixing our mistakes. Moving away from /64 as the
recommended subnet size might, or might not, prove to be necessary in
the long term future. That's why the point about routing being
classless is fundamental. I do think we need to be a bit more
precise on this point in 4291bis.

=C2=A0 =C2=A0 Brian

Exactly, /64 is t= he RECOMMENDED subnet size, or a SHOULD from RFC2119, and I'm fine with= that, but that's not what the following says.

   For all unicast addresses, except those that start with the bin=
ary
   value 000, Interface IDs are required to be 64 bits long.  Background
   on the 64 bit boundary in IPv6 addresses can be found in [RFC7421].
=

It says REQUIRED, that is a MUST from RF= C2119, and I believe it to be an Imperative as discussed in section 6 of RF= C2119. =C2=A0

I'm fine with /64, /127 and /128= as the RECOMMENDED subnet sizes, I support that and=C2=A0believe it to be = the consensus of the IETF. Maybe even explicitly noting=C2=A0/65 through /1= 26 are NOT RECOMMENDED subnet sizes, and not support by SLACC.=C2=A0 But it= is not correct to say the /64 is REQUIRED.

I= don't think /127s should really be recommended either.

They don't guarantee that the pin= g pong problem is solved, because it depends on both ends being configured = with the /127 prefix length by the operator or operators at each end if the= link. There is no protocol requirement that both ends of a link have the s= ame prefix and prefix length, nor is there any protocol checking of that co= ndition.

For example, if= an ISP configures a /127 on their end of the customer's link, but the = customer just configures a default route on their end over the link, it is = a legitimate configuration by the protocols, Internet access will work (so = the customer might assume the link is configured correctly), and yet the li= nk is vulnerable to a ping pong attach despite it "having" a /127= prefix.

So it is a miti= gation, however it relies on the operator or operators being disciplined ab= out the configuration, and comes at the cost of other things that may be us= eful if a 64 bit IID was available e.g. protect against discovery of link a= ddresses via unsolicited inbound probing if the IIDs are random (which may = include static configuration of an offline generated random 64 bit IID).

Regards,
Mark.


I also believe RF= C7608 supports this conclusion.

Thanks.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=C2=A0 Email:farmer@umn.edu
Networking & Telecommunication ServicesOffice of Information Technology
University of Minnesota=C2=A0=C2=A0 <= br>2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815=
Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

-------------------------------------------------------------= -------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
-----------------------------------------------------------------= ---


--001a114dd4cce8a94b0546082efe-- From nobody Sat Jan 14 11:20:44 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2299D129D01; Sat, 14 Jan 2017 11:20:38 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zp2DkomxkgHY; Sat, 14 Jan 2017 11:20:36 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 8E3A6129D0E; Sat, 14 Jan 2017 11:20:35 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id 204so1525545pge.2; Sat, 14 Jan 2017 11:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NRCqXv1xP56HflJNjeS79cTQwn6m5hhABqCGv4Po2/Q=; b=kh68UXW5ckzUhsSi7DEoJ7SMJWpZbBp0txCigz0kuZ79YjYuvvZ1I7XuivV7acOPYG iCpCcmOjwQfyLA8VRxezqA6+5Ea+r9wuNbc7Ue4KZsHXR65FKWigCwcDpWhtJOAv1B7W VR36hEIb7H9MWNyW7RMGsHFR9HeWRz3w6O99zx9s97kum6FMZJ4hA7/LVTy+oJZ6en7o RlDpeuhvHrCd3lm4n1YwM1D9H+pYrMfg0XK8uF5Jv8kYez79Fh6WquhJRYZjC0OG5nbF zziqCIfyMi//6mhMGqInfC05c+qotGKezBVk/s/DdUy22qZYB8Mpg4FYnhj8+Unmnlik cwGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=NRCqXv1xP56HflJNjeS79cTQwn6m5hhABqCGv4Po2/Q=; b=W2PQCEKNgO6yt2rlBe8+zVugqBXC/A+/mtR/2Du8fZctZX3FmHcJa5LD4TAVGpVBwx pUzkmrxqcQzfJftA0F4j7y4AdmR8v6APvFeFXw2L1qQ63TFz3CEVsfQ5lwztfF13iMEv bL/A8Dh5Bh4qpbUIpj0SN613eUHo5ohD8aQkpI/QUjULEjXryCQ6C23rkezc/ETJPu8U tV259dmmC4qATHikJH8sZ0N6obZOhunSL1RuPNF31L5Fk1fyMWPWXXkkVdiutCa2g4FW UM3or80s+TF9yN+lANhX9T97DYXEZHl5K+X8EN5t5hJGsGCFFQkOHjcJ/zRTy+1K9fBt 4kSg== X-Gm-Message-State: AIkVDXLZbF4gWYYZSCWxGNW06e/ZHKQYqDA6LU7ad3o2PxNTeGd/PF20+0ISyvrxnH1wew== X-Received: by 10.84.206.37 with SMTP id f34mr38600991ple.35.1484421635047; Sat, 14 Jan 2017 11:20:35 -0800 (PST) Received: from [192.168.178.21] ([118.149.103.96]) by smtp.gmail.com with ESMTPSA id u14sm36905769pfg.18.2017.01.14.11.20.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Jan 2017 11:20:34 -0800 (PST) To: Mark Smith , David Farmer References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <142f07db-e053-2cc3-ec67-72dd93483220@gmail.com> Date: Sun, 15 Jan 2017 08:20:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: 6man WG , IETF , int-dir@ietf.org, Bob Hinden , Randy Bush , draft-ietf-6man-rfc4291bis.all@ietf.org, John C Klensin Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 14 Jan 2017 19:20:38 -0000 Mark, I think this thread has shown convincingly that there is a problem with the current wording of 4291bis about the 64 bit IID length. I suggest that we wordsmith it on the 6man list and come back to this broader CC list when we have a proposal. Regards Brian On 14/01/2017 19:37, Mark Smith wrote: > On 14 Jan. 2017 15:36, "David Farmer" wrote: > > > > On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> .... >> >> >> Which is exactly why we have so far only delegated 1/8 of the >> IPv6 address space for global unicast allocation, leaving a *lot* >> of space for fixing our mistakes. Moving away from /64 as the >> recommended subnet size might, or might not, prove to be necessary in >> the long term future. That's why the point about routing being >> classless is fundamental. I do think we need to be a bit more >> precise on this point in 4291bis. >> >> Brian >> > > Exactly, /64 is the RECOMMENDED subnet size, or a SHOULD from RFC2119, and > I'm fine with that, but that's not what the following says. > > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long. Background > on the 64 bit boundary in IPv6 addresses can be found in [RFC7421 > ]. > > > It says REQUIRED, that is a MUST from RFC2119, and I believe it to be an > Imperative as discussed in section 6 of RFC2119. > > I'm fine with /64, /127 and /128 as the RECOMMENDED subnet sizes, I support > that and believe it to be the consensus of the IETF. Maybe even explicitly > noting /65 through /126 are NOT RECOMMENDED subnet sizes, and not support > by SLACC. But it is not correct to say the /64 is REQUIRED. > > > I don't think /127s should really be recommended either. > > They don't guarantee that the ping pong problem is solved, because it > depends on both ends being configured with the /127 prefix length by the > operator or operators at each end if the link. There is no protocol > requirement that both ends of a link have the same prefix and prefix > length, nor is there any protocol checking of that condition. > > For example, if an ISP configures a /127 on their end of the customer's > link, but the customer just configures a default route on their end over > the link, it is a legitimate configuration by the protocols, Internet > access will work (so the customer might assume the link is configured > correctly), and yet the link is vulnerable to a ping pong attach despite it > "having" a /127 prefix. > > So it is a mitigation, however it relies on the operator or operators being > disciplined about the configuration, and comes at the cost of other things > that may be useful if a 64 bit IID was available e.g. protect against > discovery of link addresses via unsolicited inbound probing if the IIDs are > random (which may include static configuration of an offline generated > random 64 bit IID). > > Regards, > Mark. > > > I also believe RFC7608 supports this conclusion. > > Thanks. > From nobody Sun Jan 15 07:54:59 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207431295AB for ; Sun, 15 Jan 2017 07:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8-YquCiMx8y for ; Sun, 15 Jan 2017 07:54:54 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 D07B412945E for ; Sun, 15 Jan 2017 07:54:53 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id 96so66994926uaq.3 for ; Sun, 15 Jan 2017 07:54:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A/aiNMK6KzgNO/OZ9TKdlF1Bce6FkMDARouRcPxr3zk=; b=dLJeWpw36DL+BkInPLyJArnb0ueXSrkQ/yy0qzix1IWc1kURDJozCl1hO6XFbFin7l izPQegI8hjTWn6vsXJm3PXHSpRE08RTjMsDFjYeXm6Is3/ZbS9KxR0clvIPzi42CWm2e /eD6hI/3Dd75t/7gt3645qcP5ZGYwLSUcVyHuwyK2ZWzMCfQfPw/LUneFgvFFpeka3/f 7l/ud2Ybn/7Sbx4U/kR5Oqa++o4g6QPtSenSbpmX0VuZWBMZCI+SWt/AGQy23wHTaGos fQgVAPmLZM8mBOjFmkHqifqT04KEItE9uVIDIwOIipg8gKzhoo0eYaN2vXtoINnroNc1 fQ/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=A/aiNMK6KzgNO/OZ9TKdlF1Bce6FkMDARouRcPxr3zk=; b=VZ7YeXGYuBLnxdiyu40bwFVBVfzY7qDLL6ywDcisKJH01/ULrxKaAr7Os8W25Fn1tk 4qYAcqvrBWEoSaN1ZoKk5GjLO+3wGbPslcaOTvEiZV/aVp7e1LO3TpDfmPYjSAVvHGyB ZecWJozO5YjthszlamUWuvIMojPDc9RS+ixF1e43UHjTade2FrKyzFiorItRmGs+0d0g H8+KNFVOAplvaQhF618YIzBevYGRQLEspxzlboUQdpo7POnWNxIpaFSPcM+JDeMgItOh uCcB8Fkuu+WESSngQzMFNexae0GTaPYwL/6zD+apeHumr9EdvZDAVTDjMbVrk4fyzdyc sMKQ== X-Gm-Message-State: AIkVDXKv5V02oLTi7qGEYu2DxvzUUJyyfcq2Htm62OIdNASydvY6YeJm/2IoKZMc60PrX0Q3+ewLUHQPbbXKSx11 X-Received: by 10.176.5.138 with SMTP id e10mr12308210uae.109.1484495692536; Sun, 15 Jan 2017 07:54:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.171.2 with HTTP; Sun, 15 Jan 2017 07:54:31 -0800 (PST) In-Reply-To: <20170113200334.GO40198@shrubbery.net> References: <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <20170113200334.GO40198@shrubbery.net> From: Lorenzo Colitti Date: Mon, 16 Jan 2017 00:54:31 +0900 Message-ID: To: heasley Content-Type: multipart/alternative; boundary=94eb2c1247946fdc4405462416a4 Archived-At: Cc: IPv6 List , IETF , int-dir@ietf.org, Bob Hinden , Randy Bush , draft-ietf-6man-rfc4291bis.all@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jan 2017 15:54:55 -0000 --94eb2c1247946fdc4405462416a4 Content-Type: text/plain; charset=UTF-8 On Sat, Jan 14, 2017 at 5:03 AM, heasley wrote: > > But it's true that supporting /65-/126 increases the cost of the device. > > The extra bits have to go somewhere. I think I've seen hardware that just > > converted all prefixes to 128 bit if there was at least one /65 - /126 > > prefix in the FIB. That costs money for RAM. Obviously that's silly if > > those prefixes are frequent, and you can save that money using better > > software engineering - but software engineering costs money too. > > do such limited devices really need complex ribs/fibs? address, router, > neighbors. all of which are needed regardless of the prefix length. > The "/65 - /126 challenged" devices I'm talking about were very big iron routers. > > Prefixes don't cost money, > > but, they do: https://www.arin.net/fees/fee_schedule.html No, they don't. The link you provide says you get a /32 for $1000, which puts the cost of a /64 at $1000 / 2^32 or $0.0000002. --94eb2c1247946fdc4405462416a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Jan 14, 2017 at 5:03 AM, heasley <heas@shrubbery.net> w= rote:
> But it's true that supporting /65-/126 increases the cost o= f the device.
> The extra bits have to go somewhere. I think I've seen hardware th= at just
> converted all prefixes to 128 bit if there was at least one /65 - /126=
> prefix in the FIB. That costs money for RAM. Obviously that's sill= y if
> those prefixes are frequent, and you can save that money using better<= br> > software engineering - but software engineering costs money too.

do such limited devices really need complex ribs/fibs?=C2=A0 address= , router,
neighbors.=C2=A0 all of which are needed regardless of the prefix length.

The "/65 - /126 challenged" de= vices I'm talking about were very big iron routers.
=C2=A0
> Prefixes don't cost money,

but, they do: https://www.arin.net/fees/fee_s= chedule.html

No, they don't. The li= nk you provide says you get a /32 for $1000, which puts the cost of a /64 a= t $1000 / 2^32 or $0.0000002.
--94eb2c1247946fdc4405462416a4-- From nobody Sun Jan 15 11:25:13 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FE8129662 for ; Sun, 15 Jan 2017 11:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Hp2rKMMrOFF for ; Sun, 15 Jan 2017 11:25:07 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 B68CA129667 for ; Sun, 15 Jan 2017 11:25:04 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id r144so145883868wme.1 for ; Sun, 15 Jan 2017 11:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:cc:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=IgU4+jqUx0+7rPuiE6ZQ30ChWimMkoMae2kI6DnmGTQ=; b=p8eHHxtTTNhRSJr8U5QOidBgy5N1nOPswCaFDk7I8sF8fYFXMumXQ/gsw0EbH9LL0h RXJaEOaDlSe4Lzp3Zf80ei3koc5HRccBn/M6pgnjkVauWpwD2hPIZxJu9Fb/gAsKYPv+ RKKqRfOswjzmxF+rqCt643q/Y4vDgpRAk48bu9/C2pzGJ6RlSaUQbwOrbhJdWv1oNLDs tH6Y8uyCQkZJz7AVxXYatNjYYWe/tlbESi8wEqzttJocNiJRd8bb5wkhCo4G79knLr5a atR1AtuOSwoaJf3aOFhmAPFPk71HT0qPhVnfwlyVWQR/ogFTzUR7QMmw454KUCRdhFCM D9IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=IgU4+jqUx0+7rPuiE6ZQ30ChWimMkoMae2kI6DnmGTQ=; b=i08HYlewCF0rygmwrIr8wlAQrmoj5S/g11/5k4BNvgIlcYlloFLWYZTJqmu4LLrCOC uNcrXWSF0ncxBbNJboVyKSSqk4tdBBMG0GPalcfYT6YD7/gSoGbqPCLhXX6Y59rtELzf tx6sIxCGCBOlyd137JO1rsNN7ZVS92zHzyXfVA/nPwS97bLAFUcVWDeiERSEbwuxTGmo jIcHK7U89Mg4/OFPm/1M3MdHQJBXx6U394EgrS3tPtQaTksf7WgHV57Q4EM3kBDvrdw1 UPrx/ScQmu5yPbySH9JkT19q/jJ88YjKl960oMop9pcPUWhXQnOODtdGDeL0JaYINwtK JMBw== X-Gm-Message-State: AIkVDXJqw7yVgh2Pfl3UgHieUNsdTNx4+Y9i2jv5F/Wlc4uViNwmpbf6EtvhBQMR1c8R9OO3 X-Received: by 10.28.229.73 with SMTP id c70mr9027276wmh.82.1484508302987; Sun, 15 Jan 2017 11:25:02 -0800 (PST) Received: from cjbc_dell.lan (85.251.161.16.dyn.user.ono.com. [85.251.161.16]) by smtp.gmail.com with ESMTPSA id f126sm23012858wme.22.2017.01.15.11.25.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 15 Jan 2017 11:25:01 -0800 (PST) Message-ID: <1484508299.3758.14.camel@it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: kkinnear Date: Sun, 15 Jan 2017 20:24:59 +0100 In-Reply-To: <93075E9F-B464-4829-98AA-12B2AA6793E1@cisco.com> References: <148256611461.16774.460244554047859645.idtracker@ietfa.amsl.com> <93075E9F-B464-4829-98AA-12B2AA6793E1@cisco.com> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.3-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Cc: dhcwg@ietf.org, draft-ietf-dhc-dhcpv6-failover-protocol.all@ietf.org, ietf@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-dhc-dhcpv6-failover-protocol-03 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cjbc@it.uc3m.es 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, 15 Jan 2017 19:25:09 -0000 Hi Kim, Thanks a lot for the additional explanations. They definitely help. I also like the new figure. Thanks, Carlos On Wed, 2017-01-11 at 15:26 -0500, kkinnear wrote: > Carlos, > > Thanks very much for reviewing the DHCPv6 Failover Protocol draft! > > To answer your question first, as Bernie mentioned, there is an > implementation which is substantially identical to the protocol > described in the draft. The on-the-wire packets are not compatible, > since there are no IANA numbers for anything at this point, but it is > essentially the same protocol.  The experience I could report is > simply that it *does* appear to work.  There have certainly been bugs > in the implementation, and there were some small issues early on that > were also protocol issues, but any fixes that were made to the > protocol were also rolled into previous versions of the draft, so > that > the draft has reaped the benefit of some real-world > experience.  There > wasn't much, actually, that changed because of that.  I expect that > is > because this DHCPv6 draft is very similar to the DHCPv4 Failover > Protocol draft that went through 12 revisions before finally bogging > down in its own weight.  It finished at 133 pages, and I'll spare you > more of that story.  That said, the DHCPv4 version was implemented by > several companies, and that draft contained much that was learned > through those multiple implementations, which certainly informed the > work on this DHCPv6 Failover Protocol. > > Regarding figures for Section 4.  I have created one that tries to > illustrate the example given in the text in Section 4.1.1.  It shows > both how the MCLT works as well as Lazy Update.  I will publish it in > the next version of the draft.  Here it is: > > Internet-Draft          DHCPv6 Failover Protocol            January > > 2017 > > > > > >       Fundamental relationship: > >       lease time = floor(desired lifetime, ack-partner-lifetime + > > MCLT) > > > >       Initial conditions: MCLT = 1h, desired lifetime = 3d > > > >                  DHCPv6               Primary             Secondary > >           time   Client               Server               Server > > > >                    | >-SOLICIT------>    |                    | > >                    |  acknowledged partner lifetime = 0       | > >                    |  lease time = floor( 3d, 0 + 1h ) = 1h   | > >                    |   <-----ADVERTISE-< |                    | > >                    |     lease-time= 1h  |                    | > >                    | >-REQUEST------>    |                    | > >             t      |   <---------REPLY-< |                    | > >                    |     lease-time= 1h  |                    | > >                    |                     |  >-BNDUPD------>   | > >                    |                     |  partner-lifetime = 1/2h > > + 3d > >                    |                     |    <----BNDREPLY-< | > >                    |                     |  partner-lifetime = 1/2h > > + 3d > >       1/2h passes ...                   ...                  ... > >          t+1/2h    | >-RENEW-------->    |                    | > >                    |   acknowledged partner lifetime = 3d     | > >                    |   lease time = floor( 3d, 3d + 1h ) = 3d | > >                    |   <---------REPLY-< |                    | > >                    |   lease-time=3d     |                    | > >                    |                     | >-BNDUPD------->   | > >                    |                     |  partner-lifetime = 1.5d > > + 3d > >                    |                     |    <----BNDREPLY-< | > >                    |                     |  partner-lifetime = 1.5d > > + 3d > >                        acknowledged partner lifetime = 1.5d + 3d > >       1.5d passes ...                   ...                  ... > >                    |                     |                    | > >      t+1.5d + 1/2h | >-RENEW-------->    |                    | > >                    |  acknowledged partner lifetime = 3d      | > >                    |   lease time = floor( 3d, 3d + 1h ) = 3d | > >                    |   <---------REPLY-< |                    | > >                    |   lease-time=3d     |                    | > >                    |                     | >-BNDUPD------->   | > >                    |                     |  partner-lifetime = 1.5d > > + 3d > >                    |                     |    <----BNDREPLY-< | > >                    |                     |  partner-lifetime = 1.5d > > + 3d > >                    | acknowledged partner lifetime = 1.5d + 3d| > > > >                           Figure 1: MCLT Example > > > > > > > > > > > > > > Mrugalski & Kinnear       Expires July 15, > > 2017                [Page 17] > > > > I hope this helps folks get a better idea of some of the fundamental > ideas on which the draft is based.   > Thanks again for the thoughtful review!   > > Regards -- Kim > > > On Dec 24, 2016, at 2:55 AM, Carlos Bernardos > > wrote: > > > > Reviewer: Carlos Bernardos > > Review result: Ready > > > > I am an assigned INT directorate reviewer for > > draft-ietf-dhc-dhcpv6-failover-protocol-03. 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. > > > > I'm not an expert in DHCPv6, so please consider this review as a > > light > > one. Keeping this in mind, please find my review below. > > > > Overall, I have not found any issue. I think the document is quite > > complete and deep. Actually, my main overall comment is that it is > > sometimes a bit hard to follow, due to its length and level of > > complexity. Since a protocol specification has to be precise, my > > only > > recommendation to address this would be to consider adding some > > figures in Section 4, for the reader to get a first overall idea. > > > > Question: is there any implementation available, so some experience > > gained from it can be reported (maybe as an annex)? > > > > From nobody Sun Jan 15 21:09:28 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562AD12941C; Sun, 15 Jan 2017 21:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net 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 JQDLMDGGe4rd; Sun, 15 Jan 2017 21:09:20 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931871293FF; Sun, 15 Jan 2017 21:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1484543360; bh=hbSa6yKeBlDzCKt4tuINs7IOaR8JEZVM1uG7 9eZGd9g=; h=Received:Subject:To:References:Cc:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; b=GUrtthf Zw0tAXaBgVZXVYaCfLBt1wPav/xiy7KEtHF37JCcmI6CBwcUyRkPS9ZN+xasWr5Hd3U DxSeUH0b+pc59gsi4OwWRJLip8jq4JJpBppi3Y2stntsEwPQR88tbMqV1NknRSZV8UW /GXC2IQ+CUJ24Qe9W2sw+tz9yjhBjPRqFylVptywW0VVXms8FaTDaMLqNsUJ+3ttiTm sXXioZAran8felMM+39SyTtXoS6fw6LotQNdwWnFdMEVZ6f3XkPyexdGp2d7i8y2qZ5 lPuCaGc3jgLi+XCVm3DHpGhnwrr0RYw/uY9RAnaE0fK/g8lyua4SpwMqMc7K6MGTo1w == DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=fy81pY6bbZ9LK+jramqomGVz/gvTMcE+cRCyVEhWD/IMO0DCHpRO0KvgQlotJEbBcn0D18drXRxSVwDkvOAqSVtk/pQRaTPlJsnF7j/8m2lgimT5ZQb/GOb0hGbgiRPe7FeGhosfabFe5D724IQ0YkOsMY+1CH8H5otxi8nfJxUdQe3cpuuGE92c3c7/YF6N7iEo98/Sx1W0bhfHAzEHRQ1m67u88sxbIu86L3P2QQS2DR9XSz5cRzWye5N2vA2YmgkfbA9GKYze//CnXCk+z2Sq1nIprDjR3YM+Y+KRSQG5Q/5Vs4qd1X7RNl55pvelKV9JCGhoiXpvGh/1RlNeKQ==; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [50.203.2.195] (helo=[10.199.5.181]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1cSzX9-0000wv-27; Mon, 16 Jan 2017 00:08:43 -0500 To: Tatuya Jinmei , int-dir@ietf.org References: <148372972401.17454.8580929833890158319.idtracker@ietfa.amsl.com> From: Charlie Perkins Message-ID: <2cb3f151-f2c3-539f-fcc4-a40f64916bee@earthlink.net> Date: Sun, 15 Jan 2017 21:08:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <148372972401.17454.8580929833890158319.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac761934719e9a4fcfb7fb9c3e3284d692c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 50.203.2.195 Archived-At: Cc: dmm@ietf.org, ietf@ietf.org, draft-ietf-dmm-4283mnids.all@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-dmm-4283mnids-03 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 16 Jan 2017 05:09:22 -0000 Hello Tatuya, Thank you for the careful review. Follow-up below: On 1/6/2017 11:08 AM, Tatuya Jinmei wrote: > - Section 4.1: I guess the MNID is generally supposed to be unique > (at > least in the realm the ID is used), but not all IPv6 addresses are > guaranteed to be unique (a link-local or unspecified address is an > obvious example, an ULA may also be inappropriate depending on the > usage context). It may be better to note the fact, and you may > also > want to impose some restrictions on the type of address that can be > used as an MNID. This is correct. I will fashion some language as suggested. I think it is appropriate to allow ULAs, but multicast and unspecified addresses seem clearly inappropriate, and I am i favor of disallowing link-local addresses. > > - Section 4.5 > > 2000, modulo 2^32. Since the link-layer address can be of > variable > length [RFC2464], the DUID-LLT is of variable length. > > I don't understand why RFC2464 is referenced in this context. This > RFC is about IPv6 over Ethernet, and assumes a fixed (6 bytes) > length of hardware address. I don't quite know what to do about this. I actually just copied this language from RFC 3315. I think that the citation is also wrong in RFC 3315, for the same reason as given here. I could simply delete the reference to RFC 2464. > > - Section 4.9: s/is (GRAI)/(GRAI)/ > > The Global Returnable Asset Identifier is (GRAI) is defined by the > > Fixed. I also checked for other similar instances and did not find any. Regards, Charlie P. From nobody Mon Jan 16 05:17:49 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45C5129487; Mon, 16 Jan 2017 05:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mz0HALubk8rj; Mon, 16 Jan 2017 05:17:46 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13E64129431; Mon, 16 Jan 2017 05:17:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9114; q=dns/txt; s=iport; t=1484572666; x=1485782266; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pPCGTQRYVJKJcJBSbc+wyLYTBvkXsbXe4Sk9nE5svWE=; b=YneKAp3oxamuZ9onQvBQinkFe89PNhpBT69Xwtzq2k6y+Nz6PVRQ/uQQ K9dil0CxG1vDCdjCCjLSIeNXluR7b1nIm4kLX3GfKykvhK/1PiEKWuq3p 9B7Dr4cmG2zBkT6pOob+qDEaRJIREwaz7vkEondmWLqZQrZdmW+Cq/HIx I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CAAQD4xnxY/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAR9fgQmFV4gBkXaQIIUrggsfAQqEHoFaAoIhPxgBAgE?= =?us-ascii?q?BAQEBAQFjKIRqAgQBAWwLEAIBCA4xBycLFBECBA4FiGgDGA6waIoCAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWIRwiCXYJQhSuCMQWVL4YLAYZcgxeHa5BtkmsBHzi?= =?us-ascii?q?BRBU6EAGDbjUDHIFfc4huAQEB?= X-IronPort-AV: E=Sophos;i="5.33,239,1477958400"; d="scan'208,217";a="372517686" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jan 2017 13:17:45 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v0GDHjIo030823 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 Jan 2017 13:17:45 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 16 Jan 2017 07:17:44 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Mon, 16 Jan 2017 07:17:44 -0600 From: "Bernie Volz (volz)" To: Charlie Perkins Thread-Topic: [Int-dir] Review of draft-ietf-dmm-4283mnids-03 Thread-Index: AQHSaFBRXgHG4F7CUkmyt5JN4S/GpKE7ASmAgAAkDkc= Date: Mon, 16 Jan 2017 13:17:43 +0000 Message-ID: References: <148372972401.17454.8580929833890158319.idtracker@ietfa.amsl.com>, <2cb3f151-f2c3-539f-fcc4-a40f64916bee@earthlink.net> In-Reply-To: <2cb3f151-f2c3-539f-fcc4-a40f64916bee@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_BBD02A847AAA4632B5C3C3ADC10A3ED2ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Tatuya Jinmei , "draft-ietf-dmm-4283mnids.all@ietf.org" , "ietf@ietf.org" , "dmm@ietf.org" , "int-dir@ietf.org" Subject: Re: [Int-dir] Review of draft-ietf-dmm-4283mnids-03 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 16 Jan 2017 13:17:48 -0000 --_000_BBD02A847AAA4632B5C3C3ADC10A3ED2ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI: The RFC2464 reference in RFC3315 is about canonical order, not the lin= k-layer address length. "This type of DUID consists of a two octet type field containing the value 1, a two octet hardware type code, four octets containing a time value, followed by link-layer address of any one network interface that is connected to the DHCP device at the time that the DUID is generated. The time value is the time that the DUID is generated represented in seconds since midnight (UTC), January 1, 2000, modulo 2^32. The hardware type MUST be a valid hardware type assigned by the IANA as described in RFC 826 [14]. Both the time a= nd the hardware type are stored in network byte order. The link-layer address is stored in canonical form, as described in RFC 2464 [2]." - Bernie (from iPad) On Jan 16, 2017, at 12:09 AM, Charlie Perkins > wrote: Hello Tatuya, Thank you for the careful review. Follow-up below: On 1/6/2017 11:08 AM, Tatuya Jinmei wrote: - Section 4.1: I guess the MNID is generally supposed to be unique (at least in the realm the ID is used), but not all IPv6 addresses are guaranteed to be unique (a link-local or unspecified address is an obvious example, an ULA may also be inappropriate depending on the usage context). It may be better to note the fact, and you may also want to impose some restrictions on the type of address that can be used as an MNID. This is correct. I will fashion some language as suggested. I think it is= appropriate to allow ULAs, but multicast and unspecified addresses seem cl= early inappropriate, and I am i favor of disallowing link-local addresses. - Section 4.5 2000, modulo 2^32. Since the link-layer address can be of variable length [RFC2464], the DUID-LLT is of variable length. I don't understand why RFC2464 is referenced in this context. This RFC is about IPv6 over Ethernet, and assumes a fixed (6 bytes) length of hardware address. I don't quite know what to do about this. I actually just copied this lang= uage from RFC 3315. I think that the citation is also wrong in RFC 3315, f= or the same reason as given here. I could simply delete the reference to R= FC 2464. - Section 4.9: s/is (GRAI)/(GRAI)/ The Global Returnable Asset Identifier is (GRAI) is defined by the Fixed. I also checked for other similar instances and did not find any. Regards, Charlie P. _______________________________________________ Int-dir mailing list Int-dir@ietf.org https://www.ietf.org/mailman/listinfo/int-dir --_000_BBD02A847AAA4632B5C3C3ADC10A3ED2ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
FYI: The RFC2464 reference in RFC3315 is about canonical order, not th= e link-layer address length.

"T=
his type of DUID consists of a two octet type field containing the
   value 1, a two octet hardware type code, four octets containing a
   time value, followed by link-layer address of any one network
   interface that is connected to the DHCP device at the time that the
   DUID is generated.  The time value is the time that the DUID is
   generated represented in seconds since midnight (UTC), January 1,
   2000, modulo 2^32.  The hardware type MUST be a valid hardware type
   assigned by the IANA as described in RFC 826 [14].  Both the time and
   the hardware type are stored in network byte order.  The link-layer
   address is stored in canonical form, as described in RFC 2464 [2]."

- Bernie (from iPad)

On Jan 16, 2017, at 12:09 AM, Charlie Perkins <charles.perkins@earthlink.net> wrote:

Hello Tatuya,

Thank you for the careful review.  Follow-up below:


On 1/6/2017 11:08 AM, Tatuya Jinmei wrote:
- Section 4.1: I guess the MNID is generall= y supposed to be unique
(at
  least in the realm the ID is us= ed), but not all IPv6 addresses are
  guaranteed to be unique (a link= -local or unspecified address is an
  obvious example, an ULA may als= o be inappropriate depending on the
  usage context).  It may be= better to note the fact, and you may
also
  want to impose some restriction= s on the type of address that can be
  used as an MNID.

This is correct.  I will fashion some language as suggested. &nb= sp;I think it is appropriate to allow ULAs, but multicast and unspecified a= ddresses seem clearly inappropriate, and I am i favor of disallowing link-l= ocal addresses.

- Section 4.5

   2000, modulo 2^32.  = Since the link-layer address can be of
variable
   length [RFC2464], the DUI= D-LLT is of variable length.

  I don't understand why RFC2464 = is referenced in this context.  This
  RFC is about IPv6 over Ethernet= , and assumes a fixed (6 bytes)
  length of hardware address.

I don't quite know what to do about this.  I actually just copie= d this language from RFC 3315.  I think that the citation is also wron= g in RFC 3315, for the same reason as given here.  I could simply dele= te the reference to RFC 2464.



- Section 4.9: s/is (GRAI)/(GRAI)/

   The Global Returnable Ass= et Identifier is (GRAI) is defined by the



Fixed.  I also checked for other similar instances and did not f= ind any.

Regards,
Charlie P.

_______________________________________________
Int-dir mailing list
Int-dir@ietf.org
https://www= .ietf.org/mailman/listinfo/int-dir
--_000_BBD02A847AAA4632B5C3C3ADC10A3ED2ciscocom_-- From nobody Mon Jan 16 07:23:39 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD86129575; Mon, 16 Jan 2017 07:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.919 X-Spam-Level: X-Spam-Status: No, score=-5.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net 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 QalgOI3JQtRz; Mon, 16 Jan 2017 07:23:29 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AAB112957A; Mon, 16 Jan 2017 07:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1484580205; bh=LowWybMEldKGm0XZK6NVGH5UAS31dX5MeAfI nwv/Om0=; h=Received:Subject:To:References:Cc:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; b=B9WZObd KkjgqneSpspTwxQdRkXMr91YgJZclgFwcnpmswv8L1qsgHNogkqxV7uMaNxswvRbJaW 6OUB2r5DvlwkxZTdLASLpAEAx05/QGhUJIRAWWcxig1jG0yR4UmoDFPRyLv9iJXT4Q3 QLW0Ah6LfbLdZ0Y2wkQ9JIll5MpWHzUOM5RdDgYLL/ZpDhaw5SKiDULHK/rMZ+BHS1Z sFgYMFKYCbwmFjj3gtUvHt/xJ7rbMldkKLjma6MruOiRSpyq/ruQgOnVyLea7wH+wic BRG4MAAhWtPYK0Y6UCmUmFvYciUV5GWeYqbOV0WrgHbrLTE3hKC69gN6Bqer7lupJ8A == DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=CxcKIQE+rbY5M69iGKGoCM65HU8rhWuOEZBEtIj8bf750wM7zrg8jhPMBM8OGzeaxMySZfZLNz+JwxpOsAT16rowSOb5qD1226MIhLbAYvuBMXowAjq4XhVD7JrbNbhxu5pIev0ZeSrlUEacI1DDkhTst7OnaCQhV6a4Q6c3Xwe3755K16QJh1GoR/dg8ounefTrctbWFC8hgj09r5cbqA4E73l1PF1bvPFGr96JP/Ajm725VoPbhy1VfdWl3gXCoQQYbRPjmg2xnnEDOE5VfN0FcfveKFCDvxC95J900giOAHPJkAjh3/25+s8Sr1nfffyegd3Z/fby1tP+8JzqqQ==; h=Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [38.101.229.226] (helo=[10.100.20.249]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1cT97Z-00008O-GB; Mon, 16 Jan 2017 10:22:57 -0500 To: Tatuya Jinmei , int-dir@ietf.org References: <148372972401.17454.8580929833890158319.idtracker@ietfa.amsl.com> <2cb3f151-f2c3-539f-fcc4-a40f64916bee@earthlink.net> From: Charlie Perkins Message-ID: Date: Mon, 16 Jan 2017 07:22:56 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <2cb3f151-f2c3-539f-fcc4-a40f64916bee@earthlink.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7ee6371292b8aa9a368b813cb26a0354c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 38.101.229.226 Archived-At: Cc: draft-ietf-dmm-4283mnids.all@ietf.org, ietf@ietf.org, dmm@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-dmm-4283mnids-03 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 16 Jan 2017 15:23:31 -0000 Hello again Tatuya, Here is an updated description of the IPv6 address type when used as a MNID: > 4.1. Description of the IPv6 address type > > The IPv6 address [RFC4291] is encoded as a 16 octet string containing > the full IPv6 address. The IPv6 address MUST be a unicast routable > IPv6 address. Multicast addresses, link-local addresses, and the > unspecified IPv6 address MUST NOT be used. IPv6 Unique Local > Addresses (ULAs) MAY be used, as long as any security operations > making use of the ULA also take into account the domain in which the > ULA is guaranteed to be unique. Please let me know if this resolves your concern. Regards, Charlie P. On 1/15/2017 9:08 PM, Charlie Perkins wrote: > Hello Tatuya, > > Thank you for the careful review. Follow-up below: > > > On 1/6/2017 11:08 AM, Tatuya Jinmei wrote: >> - Section 4.1: I guess the MNID is generally supposed to be unique >> (at >> least in the realm the ID is used), but not all IPv6 addresses are >> guaranteed to be unique (a link-local or unspecified address is an >> obvious example, an ULA may also be inappropriate depending on the >> usage context). It may be better to note the fact, and you may >> also >> want to impose some restrictions on the type of address that can be >> used as an MNID. > > This is correct. I will fashion some language as suggested. I think > it is appropriate to allow ULAs, but multicast and unspecified > addresses seem clearly inappropriate, and I am i favor of disallowing > link-local addresses. ..... From nobody Mon Jan 16 10:30:06 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890C11295FC; Mon, 16 Jan 2017 10:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxXlZ1M3P0En; Mon, 16 Jan 2017 10:30:03 -0800 (PST) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (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 D5FB612947E; Mon, 16 Jan 2017 10:30:02 -0800 (PST) Received: by mail-qt0-x244.google.com with SMTP id f4so15797376qte.2; Mon, 16 Jan 2017 10:30:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UxnWFR6hIbYBrjXuHKVxY1iiLYObkPLq4qDToqFSQVY=; b=XjOrXZkrlvwqd2SA8AECdMFgp4tYGCY39Sq+6GIXU2GJaf30G7FC0CskRaA4GsoiGo lbwmQep8s8nspbIAPO9EgSFda6ugwD0qxwmZ+vN3D+HqoAw9Bvvq1gAYpvPhHGgezSr5 CtWTuA8pIxnTJgHA/8ZmKytqMjUaY87BmChuBqky7QTqjaUvUuZZHAoCTWgBuMUDfM2j DHCDuWDk1csW9PogYG4cGv6trMfM2dunOrcwi6yKfOgy4/POQuqi/6N5iYX5os2Nt2gC bWekZfiXZNaR0x6cVOqdOpMVWHgB28G3l5DTuf6YlrdyehpoQxAN+KihhuK1vgY1fch0 EHrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UxnWFR6hIbYBrjXuHKVxY1iiLYObkPLq4qDToqFSQVY=; b=sSOoz4d1so8P0Q/Nt/LKsXUhmvjONGYlUAVoF1eaOWszA1c4cVrRrEFajwsO0zC1AQ 3odwxCJF5UAMW5WLffxRPGPaNsqapJQxpD0yC/HW7dVequK9zdI5fU4pQkIX1gf362GB hUSyOVg0DEpVxuERlTmhOTn1QL3Xh/AFzoXClFPapnq0OsB8CQszV10kHeJfikr0CXb0 mbxGmyOdDICCLFFGuR4dGLHPWm+3Z3YdJd9pD3+Vfk6LwBxzo7sWQmV+vTf/5oPoX6A+ udDfG4PPkro/NaYyI7dLKLRtohPPBlOuQMjaEUyiiAaqmY/LWJRJG0AXHOI39bL2ZZ2x aweg== X-Gm-Message-State: AIkVDXL1YGEMR+xY1dNNDMBpfcysuxfMieEK9+/wGsYN9vmYaV53QSrOy76BBev6njsaZfHSMFczSJi6YIZoag== X-Received: by 10.55.3.14 with SMTP id 14mr30204048qkd.86.1484591401951; Mon, 16 Jan 2017 10:30:01 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Mon, 16 Jan 2017 10:30:01 -0800 (PST) In-Reply-To: References: <148372972401.17454.8580929833890158319.idtracker@ietfa.amsl.com> <2cb3f151-f2c3-539f-fcc4-a40f64916bee@earthlink.net> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 16 Jan 2017 10:30:01 -0800 X-Google-Sender-Auth: i_yQpb4i2LO5SBBTJqWJ6RQEPNA Message-ID: To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Tatuya Jinmei , dmm@ietf.org, IETF Discussion , draft-ietf-dmm-4283mnids.all@ietf.org, "" Subject: Re: [Int-dir] Review of draft-ietf-dmm-4283mnids-03 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 16 Jan 2017 18:30:04 -0000 At Mon, 16 Jan 2017 07:22:56 -0800, Charlie Perkins wrote: > Here is an updated description of the IPv6 address type when used as a MNID: > > > 4.1. Description of the IPv6 address type > > > > The IPv6 address [RFC4291] is encoded as a 16 octet string containing > > the full IPv6 address. The IPv6 address MUST be a unicast routable > > IPv6 address. Multicast addresses, link-local addresses, and the > > unspecified IPv6 address MUST NOT be used. IPv6 Unique Local > > Addresses (ULAs) MAY be used, as long as any security operations > > making use of the ULA also take into account the domain in which the > > ULA is guaranteed to be unique. > > Please let me know if this resolves your concern. Looks good to me. -- JINMEI, Tatuya From nobody Mon Jan 16 10:40:51 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5855312960C; Mon, 16 Jan 2017 10:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuK3G6xlnMwE; Mon, 16 Jan 2017 10:40:41 -0800 (PST) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (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 D10381295FA; Mon, 16 Jan 2017 10:40:40 -0800 (PST) Received: by mail-qt0-x244.google.com with SMTP id a29so15875211qtb.1; Mon, 16 Jan 2017 10:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=iYDrKVLDNU1cBirnMncIqo6MMZiVB/htki+ZJri4W38=; b=KJB62TbtBEcXrUEpHcNzPM6A/n72GY0mGp7sJXIVRirw5v9YyDV8ZJnxYyFTw9Ae58 jgPKcP2Yv3eKgPOhePUpUuIB6sE9sHwnzj3mOmyLfsoGG5SrgSngV7rqACEk/CC8M8GZ GjRcgb0FVfVZrPf/P5IX/YayqWnexlBqBJRZH1zsysXwRKfEP14mtAWjepFFI+YGz0kn 8paQ2O7aUmFi87sm+IN3JPRh2x9pv4xLKuKb39rQv+jxcvTjD/w9sCAr1WnobCPATSl8 bs+3Cff2PUalo4ueFNjJXAAer6thEJuNTI1lNFgdXMzotaCU1H36zy9InvORc9qnw4EO uxMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=iYDrKVLDNU1cBirnMncIqo6MMZiVB/htki+ZJri4W38=; b=LcEvfUwqABCNvActbBnv/J994kuw5GSLsZqXOACZJIaB+GeM76rOyh8JteFeRaruYm /7tGWLjQ0iB0hfiWzAaIKzTV+2wSomCyG1lrtG+fECW4ySyGYIfWZSV3UKeM/AWunAnJ N/pEB4rsmbcnj7K4AQicqNPrN571/YqOB7thqGYaLPlEDG/gv5/q8gK5rTgFLGCqQL/f YprUJOXjE9glJWcztIJBFvSOkNjq2oGK0IL6aHJMbKjNVsaDp5FZZwEj/kvf3n2Z6OdM J7H3aiXYXGJlzLTtbe7Ooxa4TD/U820Pc/88cR1I5E11ueSjacU7pEpNs+p7qBc6KcqJ +ZMw== X-Gm-Message-State: AIkVDXJBIjMZ4uw2zZcNdBiosiieC0Htvd5QLCy0WHwG7c6z9DdO4d8Ha81C8sYOMIHBNPEghjdWIdMcY/U2KA== X-Received: by 10.55.45.129 with SMTP id t123mr30190631qkh.311.1484592039680; Mon, 16 Jan 2017 10:40:39 -0800 (PST) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.29 with HTTP; Mon, 16 Jan 2017 10:40:39 -0800 (PST) In-Reply-To: <2cb3f151-f2c3-539f-fcc4-a40f64916bee@earthlink.net> References: <148372972401.17454.8580929833890158319.idtracker@ietfa.amsl.com> <2cb3f151-f2c3-539f-fcc4-a40f64916bee@earthlink.net> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Mon, 16 Jan 2017 10:40:39 -0800 X-Google-Sender-Auth: u5LJNL1WeGSwfJ-W0t9RRfNONoM Message-ID: To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Tatuya Jinmei , draft-ietf-dmm-4283mnids.all@ietf.org, IETF Discussion , dmm@ietf.org, "" Subject: Re: [Int-dir] Review of draft-ietf-dmm-4283mnids-03 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 16 Jan 2017 18:40:42 -0000 At Sun, 15 Jan 2017 21:08:41 -0800, Charlie Perkins wrote: > > - Section 4.5 > > > > 2000, modulo 2^32. Since the link-layer address can be of > > variable > > length [RFC2464], the DUID-LLT is of variable length. > > > > I don't understand why RFC2464 is referenced in this context. This > > RFC is about IPv6 over Ethernet, and assumes a fixed (6 bytes) > > length of hardware address. > > I don't quite know what to do about this. I actually just copied this > language from RFC 3315. I think that the citation is also wrong in RFC > 3315, for the same reason as given here. I could simply delete the > reference to RFC 2464. I don't see "Since the link-layer address can be of variable length [RFC2464], the DUID-LLT is of variable length." in RFC3315. See also the followup comment by Bernie. Deleting the reference will certainly address my concern, and I personally don't mind not having a reference here. -- JINMEI, Tatuya From nobody Mon Jan 16 11:42:04 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD121299BB for ; Mon, 16 Jan 2017 01:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6SwOjnVTsZ2 for ; Mon, 16 Jan 2017 01:45:10 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 C83EB1299BA for ; Mon, 16 Jan 2017 01:45:05 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id f73so29537559wmf.1 for ; Mon, 16 Jan 2017 01:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o5WFQl0TrkgmchzZMHGP10Rbm3MnuWacxprzE1RYr7Y=; b=LhCsjn4S1k8E8HvJB/DgQrjR1tm2HSvMUjKG7cMlc3/sTu+sAN7/6sMsN0epW1Cccs +fdUMSinMpOju1iS15cEXBuWFOixvnBof0zQo7niBamdyqhoPeZQBbb1OWYfu7xbYPPD IYuusWbmURPpnBwORB4jdH5WRvkoyKgOuRpubbrKP4+37uPbw6WEOeS1QKirQIqTca69 OH62dKMOoboRXKIE/oRiOCMMHaH/56vjn4xgl5466LsXtTdbRXeHHMuyMM8aNWGpnRGK ytY1Lf4MHyl7Xcy2sS1DxLWswXa0o2JfQGfIuma8M6lJLjp43lox8J9sKzg0awh24+t/ TwjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o5WFQl0TrkgmchzZMHGP10Rbm3MnuWacxprzE1RYr7Y=; b=eiiWJJfIUnX37mVl/8icGRTmd72w67Kb+ZznwPyHUoKLlfewLAVhL6v0QMODe+Aokj /2Oir9aitP+x1d0AlQT+n1Ytb9/PJC+JHWximcjtgnT4aYLRI/Wqq7qZ6QwEi9f+Rnwi zcbIzH0hW4Q0eiAzanALsRKWWJioqP6smzqLl18327ShdzhyY+hjPoWzZ4l70RZchUaB v5VY9UFPegN79ASwZecS2oqU8E1yphCJi1i9rtKieyHphJdlOdghQhHnfPIMkPFjZ2EW KQbTAmYuFr9l66oKWoIn6xdLtWYRr2lQ+UhZUJSP+NEp+N1N8woWobRQzLVe6mdzjaIu jaDg== X-Gm-Message-State: AIkVDXLUnjua4MyZoi6h0jJ+nJirpb4e4j7WPwyNiLAzUSiu8uY0opAHKb9p2cU37laTatfAKF7ZpOZ9gjyxt6o0 X-Received: by 10.223.128.202 with SMTP id 68mr22646843wrl.148.1484559903974; Mon, 16 Jan 2017 01:45:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.21.69 with HTTP; Mon, 16 Jan 2017 01:44:42 -0800 (PST) In-Reply-To: <142f07db-e053-2cc3-ec67-72dd93483220@gmail.com> References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <142f07db-e053-2cc3-ec67-72dd93483220@gmail.com> From: Erik Kline Date: Mon, 16 Jan 2017 18:44:42 +0900 Message-ID: To: Brian E Carpenter Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c082258bfbd40054633098c" Archived-At: X-Mailman-Approved-At: Mon, 16 Jan 2017 11:42:03 -0800 Cc: 6man WG , IETF , int-dir@ietf.org, David Farmer , Bob Hinden , Mark Smith , Randy Bush , draft-ietf-6man-rfc4291bis.all@ietf.org, John C Klensin Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 16 Jan 2017 09:45:14 -0000 --94eb2c082258bfbd40054633098c Content-Type: text/plain; charset=UTF-8 It would definitely be very good to see specific text. Since this is (IIRC) being done for Standards Track purposes, the primary goal crudely phrased is to collapse the diffs between the base document and all those that modify it. Or so I have thought. Text that illuminates surely seems fine, but text that alters stuff at this stage doesn't seem like too good an idea to me. On 15 January 2017 at 04:20, Brian E Carpenter wrote: > Mark, > > I think this thread has shown convincingly that there is a problem with > the current wording of 4291bis about the 64 bit IID length. > > I suggest that we wordsmith it on the 6man list and come back to this > broader CC list when we have a proposal. > > Regards > Brian > > On 14/01/2017 19:37, Mark Smith wrote: >> On 14 Jan. 2017 15:36, "David Farmer" wrote: >> >> >> >> On Fri, Jan 13, 2017 at 9:28 PM, Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> >>> .... >>> >>> >>> Which is exactly why we have so far only delegated 1/8 of the >>> IPv6 address space for global unicast allocation, leaving a *lot* >>> of space for fixing our mistakes. Moving away from /64 as the >>> recommended subnet size might, or might not, prove to be necessary in >>> the long term future. That's why the point about routing being >>> classless is fundamental. I do think we need to be a bit more >>> precise on this point in 4291bis. >>> >>> Brian >>> >> >> Exactly, /64 is the RECOMMENDED subnet size, or a SHOULD from RFC2119, and >> I'm fine with that, but that's not what the following says. >> >> For all unicast addresses, except those that start with the binary >> value 000, Interface IDs are required to be 64 bits long. Background >> on the 64 bit boundary in IPv6 addresses can be found in [RFC7421 >> ]. >> >> >> It says REQUIRED, that is a MUST from RFC2119, and I believe it to be an >> Imperative as discussed in section 6 of RFC2119. >> >> I'm fine with /64, /127 and /128 as the RECOMMENDED subnet sizes, I support >> that and believe it to be the consensus of the IETF. Maybe even explicitly >> noting /65 through /126 are NOT RECOMMENDED subnet sizes, and not support >> by SLACC. But it is not correct to say the /64 is REQUIRED. >> >> >> I don't think /127s should really be recommended either. >> >> They don't guarantee that the ping pong problem is solved, because it >> depends on both ends being configured with the /127 prefix length by the >> operator or operators at each end if the link. There is no protocol >> requirement that both ends of a link have the same prefix and prefix >> length, nor is there any protocol checking of that condition. >> >> For example, if an ISP configures a /127 on their end of the customer's >> link, but the customer just configures a default route on their end over >> the link, it is a legitimate configuration by the protocols, Internet >> access will work (so the customer might assume the link is configured >> correctly), and yet the link is vulnerable to a ping pong attach despite it >> "having" a /127 prefix. >> >> So it is a mitigation, however it relies on the operator or operators being >> disciplined about the configuration, and comes at the cost of other things >> that may be useful if a 64 bit IID was available e.g. protect against >> discovery of link addresses via unsolicited inbound probing if the IIDs are >> random (which may include static configuration of an offline generated >> random 64 bit IID). >> >> Regards, >> Mark. >> >> >> I also believe RFC7608 supports this conclusion. >> >> Thanks. >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --94eb2c082258bfbd40054633098c Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMf7MhR+6WMlT9cAZ4MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE2MTEyMjA2MzcwNloXDTE3MDUy MTA2MzcwNlowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMFGbCvV+u+in+H0HY3bqCemHVO+gk8MSoSt5cw8MyfvalJUBE+K8i0L KO7g5Tf0Hwxwin3Y78Fjurdr5ScXC3q2XKlu/KeOcKZ629BIHXR3Bc4P1kbeSBqtdP1hQsXutC3N LKA6HYfEAKX5La7jHPIPymFuzHi9jqRt1XPLBhUIx/BUgV2RaLkaLlKi1gilVaUzZ/bwKGEBPXd7 oqEa0bmYHg7nnH3c07Ka5FqwYFbFNH2B8N9qhsEvaidSWAYFR3c83MxaNvd0cc9VR+xkg4h9t4j8 kgMqch9g5WsqvEiB8X9avk0RfRrJXnLpGVE9SgWC+9g/4qHF7INLnWGpoGsCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBRSp79TZtpx4DfF6E+LlflJ0/FBvzAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAYNw4ea3dhqz3+6k7eFLEAto3ynoX iT5jeLl+/a9UeVSG5MQjruVO3LeqKKs3757hNcyfMZSooiOzamgE/W2G7gZMkCoT2NQbD7zSNB+S toUONsMQ8t6Awv9osq1WWoK/xZkHV8wMGDOun9Ia8vO+hOU5wMOnhvg5mbE1xbst7pK2P9HgFxY2 /5o3VcBn4M6T5omuaz6GVsQ4VssAWfnqVpholf+EQahap+3Fpue24kwL3/pWnDkp0UcvjfItSy9c UZdf/XOjI7X4DzroB3PFZ+rJSoRUjF2mKCLbHO0TLXtpEpr8ngGu8WwEAwf7eGHI6O5LCxrLYRdw jqaGMxZnxTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH+zIUfuljJU/XAGeDAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgBk59CfRexYUa+F9v99AZW7DujE5ZSJgW WpFyohZmCL8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwMTE2 MDk0NTA0WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAGW8n16d+J+QJN5jyL/qeoipvD+Ibqzuokty5I+TihDtfp6TdiZM L/rm7xHoGAKp7Yiu8PwLJEzD+4mb42UeMTN5xl7G/STV+pYvPIn/3fbtpy7blCF7xyETGQDdb3YD CHZ0qD+ulwHMNRAeN1PViUhwL0xN5QWGukjcA1VXB/kFdVKue6XgJN/TqeOTw90NVfP0Napl5jli TO9VhldH9Q50g74h59LLdsUj/HU6BC893nVyw69GL60MNfXvu8lPqtTjBibauQQ+5iA8Q8uhNPOX ALiMDdXo2f/jjv5lUNa5WMTT1DJ31tmur1MXX7bqIYEVQlTaPJeNxOhas4f+HEg= --94eb2c082258bfbd40054633098c-- From nobody Mon Jan 16 11:42:09 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE53129536; Mon, 16 Jan 2017 03:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.1 X-Spam-Level: X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 h-cW1Z2uiaWo; Mon, 16 Jan 2017 03:00:07 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 2830B129491; Mon, 16 Jan 2017 03:00:07 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from ) id 1cT518-0007jj-TD; Mon, 16 Jan 2017 11:00:03 +0000 Date: Mon, 16 Jan 2017 19:59:59 +0900 Message-ID: From: Randy Bush To: Erik Kline In-Reply-To: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <142f07db-e053-2cc3-ec67-72dd93483220@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: X-Mailman-Approved-At: Mon, 16 Jan 2017 11:42:03 -0800 Cc: 6man WG , IETF , int-dir@ietf.org, David Farmer , Bob Hinden , Mark Smith , draft-ietf-6man-rfc4291bis.all@ietf.org, John C Klensin , Brian E Carpenter Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 16 Jan 2017 11:00:08 -0000 > Since this is (IIRC) being done for Standards Track purposes, the > primary goal crudely phrased is to collapse the diffs between the base > document and all those that modify it. i am not a fan of incorporating the content from A into B. if you get it wrongly, we chase the confusion caused by the conflict(s) forever. and if you get it correctly, then why the heck not just refer to it? ymmv, of course. my impression is that the 6man chair and document author (beep) is trying to produce a stone tablet to be carried down the mountain. which is partially why i am being such a bleep about getting it correct. randy From nobody Thu Jan 19 01:55:43 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F18A129428; Thu, 19 Jan 2017 01:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 PH3ckRmbBvNF; Thu, 19 Jan 2017 01:55:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6682C127ABE; Thu, 19 Jan 2017 01:55:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZC76325; Thu, 19 Jan 2017 09:55:33 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 19 Jan 2017 09:55:14 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 19 Jan 2017 17:54:35 +0800 From: Sheng Jiang To: "draft-ietf-dmm-mag-multihoming.all@ietf.org" Thread-Topic: Review of draft-ietf-dmm-mag-multihoming-02 Thread-Index: AdJyOgI3fI973AFKRYaoXvLu0Irz8w== Date: Thu, 19 Jan 2017 09:55:11 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CC84BA0@NKGEML515-MBX.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CC84BA0NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58808D16.01DC, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8149c9dd47dfce7734105abefc0723ed Archived-At: Cc: "int-dir@ietf.org" Subject: [Int-dir] Review of draft-ietf-dmm-mag-multihoming-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 19 Jan 2017 09:55:41 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B927CC84BA0NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reviewer: Sheng Jiang Review result: Almost Ready I am an assigned INT directorate reviewer for draft-ietf-dmm-mag-multihomin= g-02. These comments were written primarily for the benefit of the Internet= Area Directors. Document editors and shepherd(s) should treat these commen= ts just like they would treat comments from any other IETF contributors and= resolve them along with any other Last Call comments that have been receiv= ed. For more details on the INT Directorate, see http://www.ietf.org/iesg/d= irectorate.html. Review Date:2017-1-19 Review Type : Early Review IESG Telechat date: Summary: This draft is almost ready for publication as a standard track RFC= . Major issues: Minor issues: The figure 2 seems imply a consecutive order of these steps, while some ste= ps could and should be parallel, such as establishing the two connectivitie= s, and the IP address assignment and data flow could and should start if on= e connectivity has established, but another is still in process. I guess au= thors have the same understanding. If so, adding some clarification text co= uld address this issue. The abstract seems to contain references, such as[RFC3963], etc., which it = shouldn't. These references should be replaced by straight textual mentions= of the documents. The IANA consideration seems not in normal format. However, the required ac= tions for IANA are described clearly. Nits: In abstract, "multiple Care-of Addresses (CoAs) capabilities of Mobile IP = an Network Mobility (NEMO)..." an // and In section 1, "In the continuation of [RFC4908], a Proxy Mobile IPv6 [RFC52= 13] based multihomed achitecture." achitecture // architecture also in section 1, "using GRE as mobile tuneling" Tuneling//tunneling Regards, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B927CC84BA0NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reviewer: Sheng Jiang

Review result: Almost Ready<= o:p>

 

I am an assigned INT directo= rate reviewer for draft-ietf-dmm-mag-multihoming-02. These comments were wr= itten primarily for the benefit of the Internet Area Directors. Document ed= itors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contribut= ors 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/i= esg/directorate.html.

 

Review Date:2017-1-19

Review Type : Early Review

IESG Telechat date:

 

Summary: This draft is almos= t ready for publication as a standard track RFC.

 

Major issues:

 

Minor issues:

 

The figure 2 seems imply a c= onsecutive order of these steps, while some steps could and should be paral= lel, such as establishing the two connectivities, and the IP address assign= ment and data flow could and should start if one connectivity has established, but another is still in process= . I guess authors have the same understanding. If so, adding some clarifica= tion text could address this issue.

 

The abstract seems to contai= n references, such as[RFC3963], etc., which it shouldn't. These references = should be replaced by straight textual mentions of the documents.

 

 

The IANA consideration seems= not in normal format. However, the required actions for IANA are described= clearly.

 

Nits:

 

In abstract, “multiple= Care-of Addresses  (CoAs) capabilities of Mobile IP an Network Mobili= ty (NEMO)…”

 

an // and<= /p>

 

In section 1, “In the = continuation of [RFC4908], a Proxy Mobile IPv6 [RFC5213] based

   multihomed achi= tecture.”

 

achitecture // architecture<= o:p>

 

also in section 1, “us= ing GRE as mobile tuneling”

 

Tuneling//tunneling

 

Regards,

 

Sheng

 

--_000_5D36713D8A4E7348A7E10DF7437A4B927CC84BA0NKGEML515MBXchi_-- From nobody Thu Jan 19 19:36:46 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BE91293F0; Thu, 19 Jan 2017 19:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 AYmZwcstQMFl; Thu, 19 Jan 2017 19:23:56 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 48CB012952D; Thu, 19 Jan 2017 19:23:56 -0800 (PST) X-AuditID: c618062d-aa3ff70000007359-79-5881898c6e95 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by (Symantec Mail Security) with SMTP id F9.AA.29529.C8981885; Fri, 20 Jan 2017 04:52:47 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0319.002; Thu, 19 Jan 2017 22:23:51 -0500 From: Suresh Krishnan To: Randy Bush Thread-Topic: Review of draft-ietf-6man-rfc4291bis-06 Thread-Index: AQHSbWvuCqVNPHOS30iin7FZujn7XaE2VvuAgAAA2YCAAAG5gIABRfEAgAAF8QCAABLMgIAAIhKAgADVMoCAAoPNAIAAFQmAgAXJ4oA= Date: Fri, 20 Jan 2017 03:23:51 +0000 Message-ID: References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <142f07db-e053-2cc3-ec67-72dd93483220@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-ID: <29BB651301F42B4D9E9D844F4FF8C636@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBIsWRmVeSWpSXmKPExsUyuXRPgm5/Z2OEwbllNhZb3+9js2i7uI/J 4umcr+wWn2/PY7do/b2c2eLZxvksFo+udLNYvDz7nsmi9dIfNoudR46yWzxrfcnkwO2xc9Zd do8Fm0o9liz5yeRxeeVrZo+pM2czelxd2MQewBbFZZOSmpNZllqkb5fAlbH080rWgns8FT/X XmRtYNzC08XIySEhYCLxp20bSxcjF4eQwHpGifXn10A5yxkl1n26wQhSxQZUtWHnZyYQW0RA TuLiiXeMIEXMAlOYJdY2n2YDSQgDFT2+vZAVoshUYuORM2wQdplEY/9MZhCbRUBV4mdTDzuI zStgL3Hq6gtmiG3X2SX+bfsCluAU0JJYuGYV2DZGATGJ76fWgNnMAuISt57MZ4K4W0BiyZ7z zBC2qMTLx/9YIWwliY+/5wPN4QCq15RYv0sfotVaYuazVVBjFCWmdD+EukFQ4uTMJywTGMVm IdkwC6F7FpLuWUi6ZyHpXsDIuoqRo7S4ICc33chgEyMwfo9JsOnuYLw/3fMQowAHoxIPb8GV hggh1sSy4srcQ4wSHMxKIrzTGhojhHhTEiurUovy44tKc1KLDzFKc7AoifPGrb4fLiSQnliS mp2aWpBaBJNl4uCUamDcJOC7uy2N0cou0MTtk5WmzgPfn2Gy3Hujnni/7bOS2dMtqBA8o3v6 kmTFw8vDMpzs9kyZLc8XtuG4WLTNi7ZJi0p414fEVTzPtv+eu63aoCvi6JVfE26abeKMv7X9 TpuApdW2oomvj0pe2XIvaaOmxLm3aSvEexNNJ7slFxqUnwnIipeuclNiKc5INNRiLipOBACS wrEo2wIAAA== Archived-At: X-Mailman-Approved-At: Thu, 19 Jan 2017 19:36:46 -0800 Cc: 6man WG , IETF , "int-dir@ietf.org" , David Farmer , Robert Hinden , Mark Smith , "draft-ietf-6man-rfc4291bis.all@ietf.org" , John C Klensin , Erik Kline , Brian E Carpenter Subject: Re: [Int-dir] Review of draft-ietf-6man-rfc4291bis-06 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jan 2017 03:23:57 -0000 SGkgUmFuZHksDQoNCj4gT24gSmFuIDE2LCAyMDE3LCBhdCA1OjU5IEFNLCBSYW5keSBCdXNoIDxy YW5keUBwc2cuY29tPiB3cm90ZToNCj4gDQo+PiBTaW5jZSB0aGlzIGlzIChJSVJDKSBiZWluZyBk b25lIGZvciBTdGFuZGFyZHMgVHJhY2sgcHVycG9zZXMsIHRoZQ0KPj4gcHJpbWFyeSBnb2FsIGNy dWRlbHkgcGhyYXNlZCBpcyB0byBjb2xsYXBzZSB0aGUgZGlmZnMgYmV0d2VlbiB0aGUgYmFzZQ0K Pj4gZG9jdW1lbnQgYW5kIGFsbCB0aG9zZSB0aGF0IG1vZGlmeSBpdC4NCj4gDQo+IGkgYW0gbm90 IGEgZmFuIG9mIGluY29ycG9yYXRpbmcgdGhlIGNvbnRlbnQgZnJvbSBBIGludG8gQi4gIGlmIHlv dSBnZXQNCj4gaXQgd3JvbmdseSwgd2UgY2hhc2UgdGhlIGNvbmZ1c2lvbiBjYXVzZWQgYnkgdGhl IGNvbmZsaWN0KHMpIGZvcmV2ZXIuDQo+IGFuZCBpZiB5b3UgZ2V0IGl0IGNvcnJlY3RseSwgdGhl biB3aHkgdGhlIGhlY2sgbm90IGp1c3QgcmVmZXIgdG8gaXQ/DQo+IA0KPiB5bW12LCBvZiBjb3Vy c2UuDQo+IA0KPiBteSBpbXByZXNzaW9uIGlzIHRoYXQgdGhlIDZtYW4gY2hhaXIgYW5kIGRvY3Vt ZW50IGF1dGhvciAoYmVlcCkgaXMNCj4gdHJ5aW5nIHRvIHByb2R1Y2UgYSBzdG9uZSB0YWJsZXQg dG8gYmUgY2FycmllZCBkb3duIHRoZSBtb3VudGFpbi4gIHdoaWNoDQo+IGlzIHBhcnRpYWxseSB3 aHkgaSBhbSBiZWluZyBzdWNoIGEgYmxlZXAgYWJvdXQgZ2V0dGluZyBpdCBjb3JyZWN0Lg0KDQpZ b3Uga25vdyB0aGF0IEkgcmVzcGVjdCB5b3VyIG9waW5pb24sIGJ1dCBJIHRoaW5rIHRoaXMgY2hh cmFjdGVyaXphdGlvbiBpcyBpbmFwcHJvcHJpYXRlLiBCb2IgaGFzIG5vdCBiZWVuIGludm9sdmVk IGluIHRoZSBkZWNpc2lvbiBtYWtpbmcgZm9yIHRoaXMgZG9jdW1lbnQgYXMgY2hhaXIuIFRoZSB0 ZXh0IGluIHRoZSBkb2N1bWVudCB3YXMgdGhlIHJlc3VsdCBvZiA2bWFuIFdHIGNvbnNlbnN1cy4g SSBhbSBwZXJmZWN0bHkgZmluZSBpZiB0aGUgV0cgcmV2aXNpdHMgaXRzIGNvbnNlbnN1cyBhcyBh IHJlc3VsdCBvZiB0aGUgcG9pbnRzIHRoYXQgY2FtZSB1cCBkdXJpbmcgQnJpYW4gSC7igJlzIElO VCBkaXJlY3RvcmF0ZSByZXZpZXcgYnV0IHJlc3QgYXNzdXJlZCB0aGF0IHRoZXJlIGlzIG5vIG1v dW50YWluIGFuZCBubyBzdG9uZSB0YWJsZXRzLiANCg0KVGhhbmtzDQpTdXJlc2gNCg0K From nobody Wed Jan 25 13:24:49 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F11129C19; Wed, 25 Jan 2017 13:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GC_XgxagE_Jg; Wed, 25 Jan 2017 13:24:34 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 1F3EA129C13; Wed, 25 Jan 2017 13:24:23 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id v96so24369604ioi.0; Wed, 25 Jan 2017 13:24:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=aXIdl2EoNyH6m1bgvVBGt3xEPGPvHm6Ns7BBMkeIY/g=; b=LXnN2PnkPv1T3rUAGqRq99DHX3gRdh0yKfdCD7gHl73ctrn6KnBOg2Xu2cDFZ6IXHA 7R0qtZHN7gptT9W+OG4V7+cc1hx/Yza7f8LFx8Ze3wEi20Zw9bU8nqsE/918YtHfLZQw JivWMbPBgQwoyVVGD6sd03vC6bZNxuDiJRiGo0A79saL5neM365PlqSrszuUUr/nP99Q 66Sw2V+u0JG0PWFujU0soY/H7YeagCJ2QLObZ9bHUwVy3h4IlfM8vW8S0lovs8KuxhXN /liQ3LIfFtlc7Yrn/UT/DmEjE7gEwcYLLQOvKIrhhF3VPUbtDSQXJZwutCVMa/tfOLix puSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=aXIdl2EoNyH6m1bgvVBGt3xEPGPvHm6Ns7BBMkeIY/g=; b=FI9U0Eoy0HzXz2PK/3TTmsvnlLDXtXdjPgAPU+fr3QkP53cCn29AX3Nt4EqqsfOc3V WNiJAAEPVQlrXN6mD/nliEmxbYHS4MOWkTXdiPO5A10hdwB2HBKLK1npg2PQ/KgFJ7dT 6I0Cq8k3mXIGbkE/aDOznrU496+pS6a/GSA0Qm6kfmUminRwHYQSlKnwbk3mun8ERjQq 9RMBH/aJH2I1pTmnXh6W7ViURlQWpXGRevjqoWbDSwasT77aigNRaJvW1wF4VN5XSoSc VQ9E0x2YnLg81MuxZJXM4Yh6g8v4EuN395GKtPTYuulfRLLqGFXJFCLZYmXuAq6VwYeA 3q1g== X-Gm-Message-State: AIkVDXKuLFBUk8dnSgltKHi/dXA1fL3rwHeQ2ruS9/GHQrptlwOl9TpJ+wboscuPSXL2D7OLuopgRH1IVAVUew== X-Received: by 10.107.19.8 with SMTP id b8mr30396ioj.16.1485379462151; Wed, 25 Jan 2017 13:24:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.41.72 with HTTP; Wed, 25 Jan 2017 13:24:06 -0800 (PST) From: Donald Eastlake Date: Wed, 25 Jan 2017 16:24:06 -0500 Message-ID: To: draft-ietf-6man-rfc1981bis.all@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: int-dir@ietf.org Subject: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 21:24:42 -0000 I am an assigned INT directorate reviewer for draft-ietf-6man-rfc1981bis-03.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. This document appears to be Ready with Nits. Add RFC 2119 to Reference and add corresponding boilerplate, probably to the Terminology section. Section 4, Page 6, next to last paragraph of Section 4: "should" -> "SHOULD" Section 5.1, Page 7, 2nd sentence of next to last paragraph of Section 5.1: delete superfluous comma Section 5.2, Page 7: just a wording suggestion: "must in fact represent" -> "represents" Section 5.2, Page 8: The indented Note about "security classifications" strikes me as probably an archaism left over from when it was the "US Department of Defense Internet". I suggest replacing "security classifications" with "quality of service markings" or the like. Security seems like one "quality" of service so I believe the new wording I am suggesting is a superset of the old. Section 5.2, Page 9: I am not entirely comfortable that earlier in the document it says that a Packet Too Big reporting a next hop MTU less than the IPv6 minimum link MTU should be discarded and that a node MUST NOT reduce its estimate of the Path MTU below the IPv6 minimum link MTU but in the top paragraph on page 9 it talks in an unrestricted way about reducing the PMTU based on Packet Too Big message next hop size. I suggest, at the top of page 9: "uses the value in the MTU field in the Packet Too Big message as a tentative PMTU" -> "uses the value in the MTU field in the Packet Too Big message, or the minimum IPv6 next hop MTU if that is larger, as a tentative PMTU" Section 5.3, Page 10, right after the indented Note: "must not" -> "MUST NOT" Section 5.4, Page 10: "should not" -> "SHOULD NOT" Section 5.4, Page 11, 1st paragraph: Expand "MSS" on first use; "must not" -> "MUST NOT" Section 5.4, Page 11, indented Note: in 1st paragraph "must not" -> "MUST NOT"; in 2nd paragraph "must" -> "MUST" Section 5.5, Page 12, 1st paragraph: "should" -> "SHOULD" Section 5.5, Page 12, 3rd paragraph: "recommended" -> "RECOMMENDED" Section 5.5, Page 12, 4th paragraph: If some NFS operations cannot be fragmented, "should not" -> "MUST NOT" Appendix B, 2nd sentence: "version that the change was made.:" -> "version where the change was made." Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Wed Jan 25 14:42:41 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7825D1293E0; Wed, 25 Jan 2017 14:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWhTsokTr4KE; Wed, 25 Jan 2017 14:42:39 -0800 (PST) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::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 3AB8D1293DB; Wed, 25 Jan 2017 14:42:39 -0800 (PST) Received: by mail-it0-x242.google.com with SMTP id e137so3547563itc.0; Wed, 25 Jan 2017 14:42:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MlU/7Lm/9sRWwbKhjiBZVWNJZWua6bClNuTbDGWOBCg=; b=OFo1NtQSerp2OWEW3gnAmHvUxosOiAJEPmrsEwC8XE8EjNbeeS3NW0BBiSMcgmobOz 6p9Ekd2DUP/qNSfCjaIlK7awRmfrTSNy4sCVqAU6PRYCilpF9TSX6q096nC7L3ji5xNk 9UJDMQXGY5AD/BPZNBh0qXsoxAprk4i1m6/DV8JD9pn34O0DN0iwPkkLRZyk/laAJjzo 62f/zxEq5S7r04MtF3CACGWhhuYM2rkxn27aUlJAfAJ3837OAXAFDVvTTqttWCyDDMZJ VPcdK5aKDSR7nhOlNyVB8RWMdOfH83QGx1kQhHkLAnPmCTooFc30PWZpIH3Nh/J7EAuj Dn5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MlU/7Lm/9sRWwbKhjiBZVWNJZWua6bClNuTbDGWOBCg=; b=rQiKDkAjvvcdNUqjoAvQRh3HFuoZ5PAw1BbMi7YA4L4IwOnXDIgcvFgso7uJWvjKJJ 26Md/qGoCrHHgtb7Je60Db675PqBcXswt10YtXwHNtiJ2YidEpUSRGbfMDzzHsqsQgQB QuczMlF/DSbvTnDpV17but/6xmnuBygT4n8xNUzWQi4AMOOQ/GFyKAXDhJzM4Wmvz3X3 Cw2MGs+jmkOyZ0f0uL0bcGDfq5ebTLOryMEMOLW41Vl/Stc+IAj7upGW4JCDnqPXohOc W6fEP5zeIFxdb4nihdFgr/OBQjfxfzYZXssQLUb+QTbTG779PaVC5p3wFQ0OIEbC/UD6 1BzA== X-Gm-Message-State: AIkVDXItbMfFg4ozLype5KeiVfdvPwDVeQNsb84Vm7AVdi+ytRo7kBOZKTNC/ezueffDDQ== X-Received: by 10.36.20.1 with SMTP id 1mr204662itg.121.1485384158337; Wed, 25 Jan 2017 14:42:38 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id g186sm11111512itb.4.2017.01.25.14.42.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 14:42:37 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Bob Hinden In-Reply-To: Date: Wed, 25 Jan 2017 14:42:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Donald Eastlake X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Bob Hinden , draft-ietf-6man-rfc1981bis.all@ietf.org, int-dir@ietf.org Subject: Re: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 22:42:40 -0000 Donald, Thanks for your comments! To set the background this, this is part of 6MAN work to advance the = core IPv6 specs from Draft Standard to Internet Standard. As part of = this, we were only trying to change things that where there were RFCs = that updated it, errata, and to make it consistent with the other RFCs = being advanced (for example rfc2460bis and rfc4291bis). We were trying = to change as little as possible. That why we kept the must/should language intact and did not include a = reference to RFC2119. RFC1981 was, of course, written before RFC2119. = It uses a mix of upper and lower case words, I am am reluctant to try to = change that. This is also consistent with how the w.g. handled this = issue with rfc2460bis and rfc4291bis. Comments inline below. Bob > On Jan 25, 2017, at 1:24 PM, Donald Eastlake wrote: >=20 > I am an assigned INT directorate reviewer for > draft-ietf-6man-rfc1981bis-03.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. >=20 > This document appears to be Ready with Nits. >=20 >=20 > Add RFC 2119 to Reference and add corresponding boilerplate, probably > to the Terminology section. See note above. >=20 > Section 4, Page 6, next to last paragraph of Section 4: "should" -> = =E2=80=9CSHOULD" ditto >=20 > Section 5.1, Page 7, 2nd sentence of next to last paragraph of Section > 5.1: delete superfluous comma Thanks, will fix. >=20 > Section 5.2, Page 7: just a wording suggestion: "must in fact > represent" -> =E2=80=9Crepresents" Makes sense to me, I will change. >=20 > Section 5.2, Page 8: The indented Note about "security > classifications" strikes me as probably an archaism left over from > when it was the "US Department of Defense Internet". I suggest > replacing "security classifications" with "quality of service > markings" or the like. Security seems like one "quality" of service so > I believe the new wording I am suggesting is a superset of the old. While I tend to agree with you, I think this is a change we don=E2=80=99t = have very much justification to make. >=20 > Section 5.2, Page 9: I am not entirely comfortable that earlier in the > document it says that a Packet Too Big reporting a next hop MTU less > than the IPv6 minimum link MTU should be discarded and that a node > MUST NOT reduce its estimate of the Path MTU below the IPv6 minimum > link MTU but in the top paragraph on page 9 it talks in an > unrestricted way about reducing the PMTU based on Packet Too Big > message next hop size. I suggest, at the top of page 9: "uses the > value in the MTU field in the Packet Too Big message as a tentative > PMTU" -> "uses the value in the MTU field in the Packet Too Big > message, or the minimum IPv6 next hop MTU if that is larger, as a > tentative PMTU=E2=80=9D >=20 I agree, thanks for catching this. This makes it consistent with the = earlier text in Section 4. > Section 5.3, Page 10, right after the indented Note: "must not" -> = "MUST NOT" >=20 > Section 5.4, Page 10: "should not" -> "SHOULD NOT" >=20 > Section 5.4, Page 11, 1st paragraph: Expand "MSS" on first use; "must > not" -> "MUST NOT=E2=80=9D Agree about MSS. >=20 > Section 5.4, Page 11, indented Note: in 1st paragraph "must not" -> > "MUST NOT"; in 2nd paragraph "must" -> "MUST" >=20 > Section 5.5, Page 12, 1st paragraph: "should" -> "SHOULD" >=20 > Section 5.5, Page 12, 3rd paragraph: "recommended" -> "RECOMMENDED" >=20 > Section 5.5, Page 12, 4th paragraph: If some NFS operations cannot be > fragmented, "should not" -> "MUST NOT" >=20 > Appendix B, 2nd sentence: "version that the change was made.:" -> > "version where the change was made.=E2=80=9D Thanks, will fix. >=20 > Thanks, > Donald > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com From nobody Wed Jan 25 15:15:41 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17DD1293F2; Wed, 25 Jan 2017 15:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNwBWAUud3fh; Wed, 25 Jan 2017 15:15:38 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B7F6126B6D; Wed, 25 Jan 2017 15:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8022; q=dns/txt; s=iport; t=1485386138; x=1486595738; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hHa0cy3qIV4qZqDb++Ji6MgI3J4ZZyR7pJvIVQoKDPo=; b=J2gvRzMNSM018uMURC/tONsDP3cqJNixiwG0Ka+aoe//LiLDN5mebLg7 IptBAr5HvwGlTto7TbPr+MY239UF2duSQts6Toah0g3uF9h9fcMrJaACc 7Djp6o7YTXVyos1PLuTW+yxaI59+B/K/vUbcyMJ1ZDldTujadUfhhES1T 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AQDUMIlY/40NJK1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM1AQEBAQEfYIEJB4NNigiSCogGjSiCDR8LhXgCGoIHPxgBAgE?= =?us-ascii?q?BAQEBAQFiKIRpAQEBAwEBASEEDToLBQcEAgEIEQQBAQECAiMDAgICHwYLFAEIC?= =?us-ascii?q?AIEAQ0FCAGIeAMQCA6ucYFrOodBDYMhAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYE?= =?us-ascii?q?Lii+CUYIPCiaCP4JfBZU8hVo4AY1mhAOQeIojiFYBHziBSBU7hDwcgWFzAYceg?= =?us-ascii?q?Q0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,286,1477958400"; d="scan'208";a="377265011" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Jan 2017 23:15:37 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v0PNFbax022965 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Jan 2017 23:15:37 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 25 Jan 2017 17:15:37 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Wed, 25 Jan 2017 17:15:36 -0600 From: "Bernie Volz (volz)" To: Bob Hinden , Donald Eastlake Thread-Topic: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review Thread-Index: AQHSd1F85bWwlL/Kz06HMvicjEigYaFKLpeA//+gwEA= Date: Wed, 25 Jan 2017 23:15:36 +0000 Message-ID: <484b4d11bea54ef1b0b0780d3cd1eab8@XCH-ALN-003.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.131.32.206] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-6man-rfc1981bis.all@ietf.org" , "int-dir@ietf.org" Subject: Re: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 25 Jan 2017 23:15:40 -0000 Qm9iOg0KDQpXaGlsZSBpdCBpcyBncmVhdCB0aGF0IHlvdSBrbm93IHRoaXMgaXNzdWUgd2l0aCBS RkMgMjExOSBrZXkgd29yZHMgLi4uIG90aGVycyByZWFkaW5nIHRoaXMgZG9jdW1lbnQgd2hlbiBp dCBiZWNvbWVzIGFuIFJGQyBtYXkgbm90IGtub3cgdGhhdCAoYW5kIFJGQzh4eHggb3Igd2hhdGV2 ZXIgaXQgd2lsbCBiZSBkb2VzIG5vdCBwcmVkYXRlIDIxMTkpIGFuZCBldmVuIGlmIHRoZSBSRkMg MjExOSByZWZlcmVuY2UgaXNuJ3QgZGlyZWN0bHkgaW4gdGhlIGRvY3VtZW50LCB3aGF0IHdpbGwg dGhleSBhc3N1bWUgKEkgbW9zdGx5IGFzc3VtZSBpZiBJIHNlZSBNVVNUIGluIGFuIElFVEYgZG9j dW1lbnQsIGl0IGlzIGEgUkZDIDIxMTkga2V5IHdvcmQpPw0KDQpJIHdvdWxkIHRoaW5rIHRoYXQg YXQgYSBtaW5pbXVtLCBhZGRpbmcgYSBub3RlIHRoYXQgdGhpcyBkb2N1bWVudCBkb2VzIE5PVCBt YWtlIGV4cGxpY2l0bHkgdXNlIG9mIFJGQyAyMTE5IGtleSB3b3JkcyBhbmQgdGhlcmVmb3JlIGhv dyBhIHJlYWRlciBpbnRlcnByZXRzIE1VU1QgdnMgbXVzdCBpcyB1cCB0byB0aGVtIChwcmVzdW1h YmxlIE1VU1QgaXMgbW9yZSBvZiBhIG11c3QgdGhhbiB0aGUgbG93ZXIgY2FzZSB2ZXJzaW9uKS4N Cg0KSSB0aGluayBpdCBtaWdodCBhbHNvIGJlIHBvc3NpYmxlIHRvIGFyZ3VlIHRoYXQgMjExOSBt aWdodCBoYXZlIGJlZW4gb24gdGhlIGhvcml6b24gYXQgdGhlIHRpbWUgYW5kIGFzIGl0IGRpZCBu b3QgeWV0IGV4aXN0IC4uLiAwMiBvZiB0aGUgMjExOSBkcmFmdCAob2xkZXN0IGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZykgd2FzIHB1Ymxpc2hlZCBpbiBBdWd1c3QgMTk5NiB3aGljaCBpcyB0 aGUgc2FtZSBtb250aCBpbiB3aGljaCAxOTgxIHdhcyBwdWJsaXNoZWQuIFNvIHNlZW1zIGxpa2Vs eSB0aGF0IHRoZXJlIGlzIHNvbWUgaW5mbHVlbmNlIGZyb20gdGhhdCB3b3JrIGhlcmU/DQoNCkkg Z3Vlc3Mgb25lIGNvbmNsdXNpb24gaXMgdGhhdCBldmVuIGlmIG5vdCBleHBsaWNpdGx5IGluZGlj YXRlZCwgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGV5IGFyZSAoaW4gdGhlIHNwaXJpdCBvZikgMjEx OSBrZXkgd29yZHMgaXMgbGlrZWx5IGNvcnJlY3QuDQoNCi0gQmVybmllDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJbnQtZGlyIFttYWlsdG86aW50LWRpci1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgQm9iIEhpbmRlbg0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5 IDI1LCAyMDE3IDU6NDMgUE0NClRvOiBEb25hbGQgRWFzdGxha2UgPGQzZTNlM0BnbWFpbC5jb20+ DQpDYzogQm9iIEhpbmRlbiA8Ym9iLmhpbmRlbkBnbWFpbC5jb20+OyBkcmFmdC1pZXRmLTZtYW4t cmZjMTk4MWJpcy5hbGxAaWV0Zi5vcmc7IGludC1kaXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb SW50LWRpcl0gZHJhZnQtaWV0Zi02bWFuLXJmYzE5ODFiaXMtMDMgSU5URElSIHJldmlldw0KDQpE b25hbGQsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cyENCg0KVG8gc2V0IHRoZSBiYWNrZ3Jv dW5kIHRoaXMsIHRoaXMgaXMgcGFydCBvZiA2TUFOIHdvcmsgdG8gYWR2YW5jZSB0aGUgY29yZSBJ UHY2IHNwZWNzIGZyb20gRHJhZnQgU3RhbmRhcmQgdG8gSW50ZXJuZXQgU3RhbmRhcmQuICBBcyBw YXJ0IG9mIHRoaXMsIHdlIHdlcmUgb25seSB0cnlpbmcgdG8gY2hhbmdlIHRoaW5ncyB0aGF0IHdo ZXJlIHRoZXJlIHdlcmUgUkZDcyB0aGF0IHVwZGF0ZWQgaXQsIGVycmF0YSwgYW5kIHRvIG1ha2Ug aXQgY29uc2lzdGVudCB3aXRoIHRoZSBvdGhlciBSRkNzIGJlaW5nIGFkdmFuY2VkIChmb3IgZXhh bXBsZSByZmMyNDYwYmlzIGFuZCByZmM0MjkxYmlzKS4gV2Ugd2VyZSB0cnlpbmcgdG8gY2hhbmdl IGFzIGxpdHRsZSBhcyBwb3NzaWJsZS4NCg0KVGhhdCB3aHkgd2Uga2VwdCB0aGUgbXVzdC9zaG91 bGQgbGFuZ3VhZ2UgaW50YWN0IGFuZCBkaWQgbm90IGluY2x1ZGUgYSByZWZlcmVuY2UgdG8gUkZD MjExOS4gIFJGQzE5ODEgd2FzLCBvZiBjb3Vyc2UsIHdyaXR0ZW4gYmVmb3JlIFJGQzIxMTkuICBJ dCB1c2VzIGEgbWl4IG9mIHVwcGVyIGFuZCBsb3dlciBjYXNlIHdvcmRzLCBJIGFtIGFtIHJlbHVj dGFudCB0byB0cnkgdG8gY2hhbmdlIHRoYXQuICAgVGhpcyBpcyBhbHNvIGNvbnNpc3RlbnQgd2l0 aCBob3cgdGhlIHcuZy4gaGFuZGxlZCB0aGlzIGlzc3VlIHdpdGggcmZjMjQ2MGJpcyBhbmQgcmZj NDI5MWJpcy4NCg0KQ29tbWVudHMgaW5saW5lIGJlbG93Lg0KDQpCb2INCg0KDQo+IE9uIEphbiAy NSwgMjAxNywgYXQgMToyNCBQTSwgRG9uYWxkIEVhc3RsYWtlIDxkM2UzZTNAZ21haWwuY29tPiB3 cm90ZToNCj4gDQo+IEkgYW0gYW4gYXNzaWduZWQgSU5UIGRpcmVjdG9yYXRlIHJldmlld2VyIGZv ciANCj4gZHJhZnQtaWV0Zi02bWFuLXJmYzE5ODFiaXMtMDMudHh0LiBUaGVzZSBjb21tZW50cyB3 ZXJlIHdyaXR0ZW4gDQo+IHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIEludGVybmV0 IEFyZWEgRGlyZWN0b3JzLiBEb2N1bWVudCANCj4gZWRpdG9ycyBhbmQgc2hlcGhlcmQocykgc2hv dWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSB0aGV5IA0KPiB3b3VsZCB0cmVhdCBj b21tZW50cyBmcm9tIGFueSBvdGhlciBJRVRGIGNvbnRyaWJ1dG9ycyBhbmQgcmVzb2x2ZSB0aGVt IA0KPiBhbG9uZyB3aXRoIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMgdGhhdCBoYXZlIGJl ZW4gcmVjZWl2ZWQuIEZvciANCj4gbW9yZSBkZXRhaWxzIG9uIHRoZSBJTlQgRGlyZWN0b3JhdGUs IHNlZSANCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL2RpcmVjdG9yYXRlLmh0bWwuDQo+IA0K PiBUaGlzIGRvY3VtZW50IGFwcGVhcnMgdG8gYmUgUmVhZHkgd2l0aCBOaXRzLg0KPiANCj4gDQo+ IEFkZCBSRkMgMjExOSB0byBSZWZlcmVuY2UgYW5kIGFkZCBjb3JyZXNwb25kaW5nIGJvaWxlcnBs YXRlLCBwcm9iYWJseSANCj4gdG8gdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb24uDQoNClNlZSBub3Rl IGFib3ZlLg0KDQo+IA0KPiBTZWN0aW9uIDQsIFBhZ2UgNiwgbmV4dCB0byBsYXN0IHBhcmFncmFw aCBvZiBTZWN0aW9uIDQ6ICJzaG91bGQiIC0+IOKAnFNIT1VMRCINCg0KZGl0dG8NCg0KPiANCj4g U2VjdGlvbiA1LjEsIFBhZ2UgNywgMm5kIHNlbnRlbmNlIG9mIG5leHQgdG8gbGFzdCBwYXJhZ3Jh cGggb2YgU2VjdGlvbg0KPiA1LjE6IGRlbGV0ZSBzdXBlcmZsdW91cyBjb21tYQ0KDQpUaGFua3Ms IHdpbGwgZml4Lg0KDQo+IA0KPiBTZWN0aW9uIDUuMiwgUGFnZSA3OiBqdXN0IGEgd29yZGluZyBz dWdnZXN0aW9uOiAibXVzdCBpbiBmYWN0IA0KPiByZXByZXNlbnQiIC0+IOKAnHJlcHJlc2VudHMi DQoNCk1ha2VzIHNlbnNlIHRvIG1lLCBJIHdpbGwgY2hhbmdlLg0KDQo+IA0KPiBTZWN0aW9uIDUu MiwgUGFnZSA4OiBUaGUgaW5kZW50ZWQgTm90ZSBhYm91dCAic2VjdXJpdHkgDQo+IGNsYXNzaWZp Y2F0aW9ucyIgc3RyaWtlcyBtZSBhcyBwcm9iYWJseSBhbiBhcmNoYWlzbSBsZWZ0IG92ZXIgZnJv bSANCj4gd2hlbiBpdCB3YXMgdGhlICJVUyBEZXBhcnRtZW50IG9mIERlZmVuc2UgSW50ZXJuZXQi LiBJIHN1Z2dlc3QgDQo+IHJlcGxhY2luZyAic2VjdXJpdHkgY2xhc3NpZmljYXRpb25zIiB3aXRo ICJxdWFsaXR5IG9mIHNlcnZpY2UgDQo+IG1hcmtpbmdzIiBvciB0aGUgbGlrZS4gU2VjdXJpdHkg c2VlbXMgbGlrZSBvbmUgInF1YWxpdHkiIG9mIHNlcnZpY2Ugc28gDQo+IEkgYmVsaWV2ZSB0aGUg bmV3IHdvcmRpbmcgSSBhbSBzdWdnZXN0aW5nIGlzIGEgc3VwZXJzZXQgb2YgdGhlIG9sZC4NCg0K V2hpbGUgSSB0ZW5kIHRvIGFncmVlIHdpdGggeW91LCBJIHRoaW5rIHRoaXMgaXMgYSBjaGFuZ2Ug d2UgZG9u4oCZdCBoYXZlIHZlcnkgbXVjaCBqdXN0aWZpY2F0aW9uIHRvIG1ha2UuDQoNCj4gDQo+ IFNlY3Rpb24gNS4yLCBQYWdlIDk6IEkgYW0gbm90IGVudGlyZWx5IGNvbWZvcnRhYmxlIHRoYXQg ZWFybGllciBpbiB0aGUgDQo+IGRvY3VtZW50IGl0IHNheXMgdGhhdCBhIFBhY2tldCBUb28gQmln IHJlcG9ydGluZyBhIG5leHQgaG9wIE1UVSBsZXNzIA0KPiB0aGFuIHRoZSBJUHY2IG1pbmltdW0g bGluayBNVFUgc2hvdWxkIGJlIGRpc2NhcmRlZCBhbmQgdGhhdCBhIG5vZGUgDQo+IE1VU1QgTk9U IHJlZHVjZSBpdHMgZXN0aW1hdGUgb2YgdGhlIFBhdGggTVRVIGJlbG93IHRoZSBJUHY2IG1pbmlt dW0gDQo+IGxpbmsgTVRVIGJ1dCBpbiB0aGUgdG9wIHBhcmFncmFwaCBvbiBwYWdlIDkgaXQgdGFs a3MgaW4gYW4gDQo+IHVucmVzdHJpY3RlZCB3YXkgYWJvdXQgcmVkdWNpbmcgdGhlIFBNVFUgYmFz ZWQgb24gUGFja2V0IFRvbyBCaWcgDQo+IG1lc3NhZ2UgbmV4dCBob3Agc2l6ZS4gSSBzdWdnZXN0 LCBhdCB0aGUgdG9wIG9mIHBhZ2UgOTogInVzZXMgdGhlIA0KPiB2YWx1ZSBpbiB0aGUgTVRVIGZp ZWxkIGluIHRoZSBQYWNrZXQgVG9vIEJpZyBtZXNzYWdlIGFzIGEgdGVudGF0aXZlIA0KPiBQTVRV IiAtPiAidXNlcyB0aGUgdmFsdWUgaW4gdGhlIE1UVSBmaWVsZCBpbiB0aGUgUGFja2V0IFRvbyBC aWcgDQo+IG1lc3NhZ2UsIG9yIHRoZSBtaW5pbXVtIElQdjYgbmV4dCBob3AgTVRVIGlmIHRoYXQg aXMgbGFyZ2VyLCBhcyBhIA0KPiB0ZW50YXRpdmUgUE1UVeKAnQ0KPiANCg0KSSBhZ3JlZSwgdGhh bmtzIGZvciBjYXRjaGluZyB0aGlzLiAgVGhpcyBtYWtlcyBpdCBjb25zaXN0ZW50IHdpdGggdGhl IGVhcmxpZXIgdGV4dCBpbiBTZWN0aW9uIDQuDQoNCg0KPiBTZWN0aW9uIDUuMywgUGFnZSAxMCwg cmlnaHQgYWZ0ZXIgdGhlIGluZGVudGVkIE5vdGU6ICJtdXN0IG5vdCIgLT4gIk1VU1QgTk9UIg0K PiANCj4gU2VjdGlvbiA1LjQsIFBhZ2UgMTA6ICJzaG91bGQgbm90IiAtPiAiU0hPVUxEIE5PVCIN Cj4gDQo+IFNlY3Rpb24gNS40LCBQYWdlIDExLCAxc3QgcGFyYWdyYXBoOiBFeHBhbmQgIk1TUyIg b24gZmlyc3QgdXNlOyAibXVzdCANCj4gbm90IiAtPiAiTVVTVCBOT1TigJ0NCg0KQWdyZWUgYWJv dXQgTVNTLg0KDQo+IA0KPiBTZWN0aW9uIDUuNCwgUGFnZSAxMSwgaW5kZW50ZWQgTm90ZTogaW4g MXN0IHBhcmFncmFwaCAibXVzdCBub3QiIC0+IA0KPiAiTVVTVCBOT1QiOyBpbiAybmQgcGFyYWdy YXBoICJtdXN0IiAtPiAiTVVTVCINCj4gDQo+IFNlY3Rpb24gNS41LCBQYWdlIDEyLCAxc3QgcGFy YWdyYXBoOiAic2hvdWxkIiAtPiAiU0hPVUxEIg0KPiANCj4gU2VjdGlvbiA1LjUsIFBhZ2UgMTIs IDNyZCBwYXJhZ3JhcGg6ICJyZWNvbW1lbmRlZCIgLT4gIlJFQ09NTUVOREVEIg0KPiANCj4gU2Vj dGlvbiA1LjUsIFBhZ2UgMTIsIDR0aCBwYXJhZ3JhcGg6IElmIHNvbWUgTkZTIG9wZXJhdGlvbnMg Y2Fubm90IGJlIA0KPiBmcmFnbWVudGVkLCAic2hvdWxkIG5vdCIgLT4gIk1VU1QgTk9UIg0KPiAN Cj4gQXBwZW5kaXggQiwgMm5kIHNlbnRlbmNlOiAidmVyc2lvbiB0aGF0IHRoZSBjaGFuZ2Ugd2Fz IG1hZGUuOiIgLT4gDQo+ICJ2ZXJzaW9uIHdoZXJlIHRoZSBjaGFuZ2Ugd2FzIG1hZGUu4oCdDQoN ClRoYW5rcywgd2lsbCBmaXguDQoNCj4gDQo+IFRoYW5rcywNCj4gRG9uYWxkDQo+ID09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCj4gRG9uYWxkIEUuIEVhc3RsYWtlIDNyZCAgICsxLTUw OC0zMzMtMjI3MCAoY2VsbCkNCj4gMTU1IEJlYXZlciBTdHJlZXQsIE1pbGZvcmQsIE1BIDAxNzU3 IFVTQSBkM2UzZTNAZ21haWwuY29tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpJbnQtZGlyIG1haWxpbmcgbGlzdA0KSW50LWRpckBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnQtZGlyDQo= From nobody Wed Jan 25 22:45:12 2017 Return-Path: X-Original-To: int-dir@ietf.org Delivered-To: int-dir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26947129497; Wed, 25 Jan 2017 22:45:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Jouni Korhonen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> Date: Wed, 25 Jan 2017 22:45:07 -0800 Archived-At: Cc: dhcwg@ietf.org, ietf@ietf.org, draft-ietf-dhc-relay-server-security.all@ietf.org Subject: [Int-dir] Review of draft-ietf-dhc-relay-server-security-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 06:45:07 -0000 Reviewer: Jouni Korhonen Review result: Not Ready Disclaimer: I have not followed recent DHC discussions to the extent that the existence this document was new to me. Issues: My issues with the document are the following. First, it actually updates a great deal of RFC3315 (Section 21.1) while there is RFC3315bis in progress. Why the DHCPv6 part of this document is not directly contributed to RFC3315bis work? There's even author overlap so there must be a good reason. Second, if there is a reason to keep the content of this document separate from RFC3315 body of work, at least this specification should then target to update RFC3315bis and not RFC3315. Other smaller nits: o This document updates both RFC3315(bis) and RFC1542. Those are not reflected in the document title page and abstract. o I would separate the new recommendation text for DHCPv4 and DHCPv6 into their own respective section. Having just a one-liner statement "also applies to DHCPv4 [RFC1542].." is kind of confusing in a middle of very DHCPv6 specific text. I recon the DHCPv4 section would be short, but definitely more clear in that way. o Although it should be obvious, but I would explicitly point it out in the Security Considerations that the security model here is hop-by-hop. If there are multiple relays then there will be multiple IPsec tunnels as well. o Section 14: s/section 14,/Section 14, o From nobody Thu Jan 26 02:24:43 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51388129517; Thu, 26 Jan 2017 02:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 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, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ab2mB-KPmrJC; Thu, 26 Jan 2017 02:24:36 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 39B42129448; Thu, 26 Jan 2017 02:24:33 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id c206so76080523wme.0; Thu, 26 Jan 2017 02:24:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=caoNdxm3lAOM6RKt3LPMOnP8x4nt4GkHlhD26IMyUUY=; b=dDhWG+EnmYibULKRq0d3v+DN4hM0g4MFQwjteZR5hGOauX6LKKA11zZfuw4f2JsXqO HzSw+XpXAssLcZLhnquwnxvEFiV2uNd1qxO3AU3vepTvoSBg7Yo8WIGkxdr8fLUwkbs8 u/ElaZDES+frLHgp0AdP2SsbtJW5DR2fe3w/wflNWCoCGUmkAXK9N2+4tuhdwSDSESEJ JFDKO8sGjgxnlLZv35ueMx0Y7b7WINAIJ35lf6r8bcixuo1aloHePavLPpdbC3FvUUdt 2hG56pkCN1HCgFq4jamaOcVxRobxtz5gWsObLPtPETYel/faz/b+fivWjGPyuAo+u46Z 8pIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=caoNdxm3lAOM6RKt3LPMOnP8x4nt4GkHlhD26IMyUUY=; b=Tlw3dcSjzEp18TPsl7C7HavMdHqRySLQtRWASRZO1Nvf9r1/brkFYpt5F+8PmCgNid B5vUNUwIR/kTSj/28dcCSxZAo1l0pvJwUyzemk09yisWGYf+Cd+6+mYgrW3GIpajZ33u 0UYYPLYOUErsAoC3MpOBOTt+4hBmZnvNX+BUg4wocbD0OCxVevGzQRerfW4uLcgsU9gq hr6Q1KwhhtHC+tWi9KOcImyqPTgBfsMlas9FmskV/U1WkQHSKoyVlCX5nBW/TUBS5HX+ 18Oqw6UMsuf9SqZWJm3n8FDz3/GzyrzwZay94Ykw6EtN11avXFt093b7HbYQbleZ0SP1 ZiAQ== X-Gm-Message-State: AIkVDXJ8EnnjXMqN3/tufYdDqScx9ffAvfg6apFIiK656cmUKHl1yXuEPgpX8lpUO0A6zg== X-Received: by 10.223.145.227 with SMTP id 90mr1974863wri.156.1485426271373; Thu, 26 Jan 2017 02:24:31 -0800 (PST) Received: from [192.168.0.9] (109241207033.gdansk.vectranet.pl. [109.241.207.33]) by smtp.googlemail.com with ESMTPSA id 33sm1791516wrd.34.2017.01.26.02.24.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 02:24:30 -0800 (PST) To: Jouni Korhonen , int-dir@ietf.org References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> From: Tomek Mrugalski Message-ID: Date: Thu, 26 Jan 2017 11:24:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: dhcwg@ietf.org, ietf@ietf.org, draft-ietf-dhc-relay-server-security.all@ietf.org Subject: Re: [Int-dir] Review of draft-ietf-dhc-relay-server-security-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 10:24:37 -0000
W dniu 26.01.2017 o 07:45, Jouni Korhonen pisze:
Reviewer: Jouni Korhonen
Review result: Not Ready

Disclaimer: I have not followed recent DHC discussions to the extent
that the existence this document was new to me.

Issues:

My issues with the document are the following. First, it actually
updates a great deal of RFC3315 (Section 21.1) while there is
RFC3315bis in progress. Why the DHCPv6 part of this document is not
directly contributed to RFC3315bis work? There's even author overlap
so there must be a good reason. Second, if there is a reason to keep
the content of this document separate from RFC3315 body of work, at
least this specification should then target to update RFC3315bis and
not RFC3315.
Hi Jouni,
First of all, thanks for doing the review.

I will leave it up to the authors to provide further details on this, but with my shepherd hat on, let me explain that this omission was made on purpose. The decision was made to not update 3315 and not bundle this into 3315bis on purpose. If we did that, then every DHCP server would HAVE to support IPSec. This would make implementation, certification and deployment much more complex and this is something we wanted to avoid. With the current approach, operators can be specific whether they need relay server security (by requiring their vendors to support both 3315 and this document) or not (just 3315).

This is also explained in the write-up:
(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No. Even though this I-D introduces changes to RFC3315, the WG doesn't
  want to enforce IPsec encryption on every DHCPv6 server. Therefore
  it does not update RFC3315.


Also, I'd like to clarify that 3315bis is not a wildcard that bundles every RFC related to DHCPv6 ever published. This document is 133 pages long and that size causes difficulties moving the work forward. We're thinking what are the things we can take out of it, rather what else we could add. The previous argument still stands here. We want to have the core spec and an additional RFC that people can point to when they require secure server-relay communication.

If that explanation is not acceptable for you, how do you propose to structure the text and possibly add updates 2131/3315 to achieve the goal or being a non-mandatory feature?

I'll let the authors comment on the nits.

Again, thanks for the review. It's good to receive one that shakes things up a bit once in a while :)
Tomek
Other smaller nits:

o This document updates both RFC3315(bis) and RFC1542. Those are not
reflected in the document title page and abstract. 

o I would separate the new recommendation text for DHCPv4 and DHCPv6
into their own respective section. Having just a one-liner statement
"also applies to DHCPv4 [RFC1542].." is kind of confusing in a middle
of very DHCPv6 specific text. I recon the DHCPv4 section would be
short, but definitely more clear in that way.

o Although it should be obvious, but I would explicitly point it out
in the Security Considerations that the security model here is
hop-by-hop. If there are multiple relays then there will be multiple
IPsec tunnels as well.

o Section 14:  s/section 14,/Section 14,

o


From nobody Thu Jan 26 05:38:47 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E08112957B; Thu, 26 Jan 2017 05:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.709 X-Spam-Level: X-Spam-Status: No, score=-17.709 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LY70GkkmHny; Thu, 26 Jan 2017 05:38:43 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F5C129579; Thu, 26 Jan 2017 05:38:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30028; q=dns/txt; s=iport; t=1485437922; x=1486647522; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dWXUMMt9nwXB0KpBFZjfhUX8ZXanEgyTDRL72WNJOTU=; b=jheaq1jLhCNCpQ4Q0C/Que4wih5J2v50ZRkt8k5T3HlMelKch3FS7dNu Sa+TpPj0ZSMpoIkxWRldy5dl4u3AND71wHbOyJCbVox8FwE+cCu0kyFyK CwBTsGnVMyDgRcvzhSkGrzmaaOx/k3kj6YdQWcuLizhecciFqn9SVe/do w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AQDf+olY/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm85DQEBAQEBH2CBCQeDTooJkgOIBo0ogg2GIgIaggI/GAECAQE?= =?us-ascii?q?BAQEBAWIohGkBAQEEIwpFBxACAQgOAwQBASEHAwICAh8RFAkIAgQBDQUIiH8DG?= =?us-ascii?q?K4RgiUrhxMNgycBAQEBAQEBAQEBAQEBAQEBAQEBAQEdizqCUYFiTIJQgl8FlT2?= =?us-ascii?q?FWzgBjWeEBYIAjnqIJIIAiFYBHziBSxUYhF8cgWF1hxSBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,289,1477958400"; d="scan'208,217";a="204043323" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2017 13:38:41 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v0QDcfP3014367 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 26 Jan 2017 13:38:41 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 26 Jan 2017 07:38:40 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 26 Jan 2017 07:38:40 -0600 From: "Bernie Volz (volz)" To: Tomek Mrugalski , Jouni Korhonen , "int-dir@ietf.org" Thread-Topic: Review of draft-ietf-dhc-relay-server-security-02 Thread-Index: AQHSd5+8iSisaOl5IUWbOnwv5FiO+aFK8haA///OnZA= Date: Thu, 26 Jan 2017 13:38:40 +0000 Message-ID: References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.197] Content-Type: multipart/alternative; boundary="_000_e996599692ff4584b8ace30a36ea6881XCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "dhcwg@ietf.org" , "ietf@ietf.org" , "draft-ietf-dhc-relay-server-security.all@ietf.org" Subject: Re: [Int-dir] Review of draft-ietf-dhc-relay-server-security-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 13:38:45 -0000 --_000_e996599692ff4584b8ace30a36ea6881XCHALN003ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGk6DQoNClRoYW5rcyBmb3IgdGhlIHJldmlldyBKb3VuaSAoYXMgSW50LURpciBjb29yZGluYXRv ciBhbmQgZG9jdW1lbnQgY29hdXRob3IpLg0KDQpSZWdhcmRpbmcgdGhlIG1haW4gaXNzdWUgYW5k IHRvIGV4dGVuZCBUb21la+KAmXMgY29tbWVudCDigKYNCg0KV2UgYWN0dWFsbHkgaGF2ZSB1c2Vk IHRoaXMgdGV4dCwgYnV0IHdpdGhvdXQgdGhlIE1VU1QsIGluIDMzMTViaXMgKHRoZSB1cGRhdGVk IHZlcnNpb24gaGFzIG5vdCBiZWVuIHB1Ymxpc2hlZCBhcyB0aGUgY29hdXRob3JzIGFyZSBzdGls bCB3b3JraW5nIHRocm91Z2ggdGhlIHJlbWFpbmluZyBvcGVuIGlzc3VlcyBmcm9tIHRoZSBhcHBy b3hpbWF0ZWx5IDMwMCB0aGF0IHdlIGNhcHR1cmVkIGR1cmluZyB0aGUgMzMxNWJpcyBXR0xDIGJh Y2sgaW4gQXVndXN0KS4gV2UgZG8gZXhwZWN0IHRvIHB1Ymxpc2ggYW4gdXBkYXRlZCB2ZXJzaW9u IGJlZm9yZSB0aGUgSUVURi05OCBkZWFkbGluZSAoaG9wZWZ1bGx5IHdpdGggYWxsIGlzc3VlcyBh ZGRyZXNzZWQsIGJ1dCB3ZeKAmWxsIHNlZSkuDQoNCkFuZCwgYXMgVG9tZWsgZXhwbGFpbmVkLCB0 aGlzIGlkZWEgaGVyZSB3YXMgdG8gbWFrZSB0aGlzIGFuIE9QVElPTkFMIGZlYXR1cmUgdGhhdCB2 ZW5kb3JzIGNvdWxkIGltcGxlbWVudCAobXVjaCBsaWtlIGFueSBuZXcgREhDUCBvcHRpb24pIOKA kyBidXQgaWYgd2UgbGVmdCB0aGUgdGV4dCBhcyBhIFNIT1VMRCBvciBzaW1pbGFyLCB2ZW5kb3Jz IGNvdWxkIGNsYWltIHRoZXkgc3VwcG9ydGVkIGl0IHdpdGhvdXQgYWN0dWFsbHkgaW1wbGVtZW50 aW5nIGl0LiBUaHVzLCB0aGlzIGRvY3VtZW50IGhhcyBhIE1VU1QuIEFuZCwgaXQgZG9lcyBub3Qg dXBkYXRlIOKAkyBidXQgcmF0aGVyIGV4dGVuZHMg4oCTIDMzMTUgYW5kIDE1NDIuDQoNCg0KbyBJ IHdvdWxkIHNlcGFyYXRlIHRoZSBuZXcgcmVjb21tZW5kYXRpb24gdGV4dCBmb3IgREhDUHY0IGFu ZCBESENQdjYNCg0KaW50byB0aGVpciBvd24gcmVzcGVjdGl2ZSBzZWN0aW9uLiBIYXZpbmcganVz dCBhIG9uZS1saW5lciBzdGF0ZW1lbnQNCg0KImFsc28gYXBwbGllcyB0byBESENQdjQgW1JGQzE1 NDJdLi4iIGlzIGtpbmQgb2YgY29uZnVzaW5nIGluIGEgbWlkZGxlDQoNCm9mIHZlcnkgREhDUHY2 IHNwZWNpZmljIHRleHQuIEkgcmVjb24gdGhlIERIQ1B2NCBzZWN0aW9uIHdvdWxkIGJlDQoNCnNo b3J0LCBidXQgZGVmaW5pdGVseSBtb3JlIGNsZWFyIGluIHRoYXQgd2F5Lg0KDQoNCg0KQlY+IEni gJlsbCBkaXNjdXNzIHRoaXMgd2l0aCBZb2dlbmRyYSDigKYgSSB0aGluayB3ZSBjYW4ganVzdCBt YWtlIHRoaXMgY2xlYXJlciBieSBlaXRoZXIgYnJlYWtpbmcgb3V0IHRoaXMgYXBwbGljYWJpbGl0 eSB0ZXh0IGZvciB2NC92NiBpbnRvIHNlcGFyYXRlIHBhcmFncmFwaHMuIEkgZG9u4oCZdCB0aGlu ayB0aGVyZSByZWFsbHkgc2hvdWxkIGJlIGEgbmVlZCB0byBkdXBsaWNhdGUgdGhlIG1haW4gbWF0 ZXJpYWwg4oCTIGkuZS4sIGhhdmUgc2VwYXJhdGUgc2VjdGlvbnMgd2hpY2ggYmFzaWNhbGx5IHdv dWxkIGJlIHRoZSBzYW1lIHRleHQgb24gdGhlIElQc2VjIGl0ZW1zLg0KDQoNCg0KbyBBbHRob3Vn aCBpdCBzaG91bGQgYmUgb2J2aW91cywgYnV0IEkgd291bGQgZXhwbGljaXRseSBwb2ludCBpdCBv dXQNCg0KaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHRoYXQgdGhlIHNlY3VyaXR5IG1v ZGVsIGhlcmUgaXMNCg0KaG9wLWJ5LWhvcC4gSWYgdGhlcmUgYXJlIG11bHRpcGxlIHJlbGF5cyB0 aGVuIHRoZXJlIHdpbGwgYmUgbXVsdGlwbGUNCg0KSVBzZWMgdHVubmVscyBhcyB3ZWxsLg0KDQoN Cg0KQlY+IFN1cmUsIHdlIGNhbiBhZGQgdGhhdC4NCg0KDQoNCm8gU2VjdGlvbiAxNDogIHMvc2Vj dGlvbiAxNCwvU2VjdGlvbiAxNCwNCg0KQlY+IE9LLCB0aGFua3MgZm9yIGNhdGNoaW5nIHRoYXQu DQoNCkFnYWluLCB0aGFua3MuDQoNCg0KLSAgICAgICAgICBCZXJuaWUNCg0KRnJvbTogVG9tZWsg TXJ1Z2Fsc2tpIFttYWlsdG86dG9tYXN6Lm1ydWdhbHNraUBnbWFpbC5jb21dDQpTZW50OiBUaHVy c2RheSwgSmFudWFyeSAyNiwgMjAxNyA1OjI0IEFNDQpUbzogSm91bmkgS29yaG9uZW4gPGpvdW5p a29yQGdtYWlsLmNvbT47IGludC1kaXJAaWV0Zi5vcmcNCkNjOiBkaGN3Z0BpZXRmLm9yZzsgaWV0 ZkBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5LmFsbEBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFJldmlldyBvZiBkcmFmdC1pZXRmLWRoYy1yZWxheS1zZXJ2ZXIt c2VjdXJpdHktMDINCg0KVyBkbml1IDI2LjAxLjIwMTcgbyAwNzo0NSwgSm91bmkgS29yaG9uZW4g cGlzemU6DQoNClJldmlld2VyOiBKb3VuaSBLb3Job25lbg0KDQpSZXZpZXcgcmVzdWx0OiBOb3Qg UmVhZHkNCg0KDQoNCkRpc2NsYWltZXI6IEkgaGF2ZSBub3QgZm9sbG93ZWQgcmVjZW50IERIQyBk aXNjdXNzaW9ucyB0byB0aGUgZXh0ZW50DQoNCnRoYXQgdGhlIGV4aXN0ZW5jZSB0aGlzIGRvY3Vt ZW50IHdhcyBuZXcgdG8gbWUuDQoNCg0KDQpJc3N1ZXM6DQoNCg0KDQpNeSBpc3N1ZXMgd2l0aCB0 aGUgZG9jdW1lbnQgYXJlIHRoZSBmb2xsb3dpbmcuIEZpcnN0LCBpdCBhY3R1YWxseQ0KDQp1cGRh dGVzIGEgZ3JlYXQgZGVhbCBvZiBSRkMzMzE1IChTZWN0aW9uIDIxLjEpIHdoaWxlIHRoZXJlIGlz DQoNClJGQzMzMTViaXMgaW4gcHJvZ3Jlc3MuIFdoeSB0aGUgREhDUHY2IHBhcnQgb2YgdGhpcyBk b2N1bWVudCBpcyBub3QNCg0KZGlyZWN0bHkgY29udHJpYnV0ZWQgdG8gUkZDMzMxNWJpcyB3b3Jr PyBUaGVyZSdzIGV2ZW4gYXV0aG9yIG92ZXJsYXANCg0Kc28gdGhlcmUgbXVzdCBiZSBhIGdvb2Qg cmVhc29uLiBTZWNvbmQsIGlmIHRoZXJlIGlzIGEgcmVhc29uIHRvIGtlZXANCg0KdGhlIGNvbnRl bnQgb2YgdGhpcyBkb2N1bWVudCBzZXBhcmF0ZSBmcm9tIFJGQzMzMTUgYm9keSBvZiB3b3JrLCBh dA0KDQpsZWFzdCB0aGlzIHNwZWNpZmljYXRpb24gc2hvdWxkIHRoZW4gdGFyZ2V0IHRvIHVwZGF0 ZSBSRkMzMzE1YmlzIGFuZA0KDQpub3QgUkZDMzMxNS4NCkhpIEpvdW5pLA0KRmlyc3Qgb2YgYWxs LCB0aGFua3MgZm9yIGRvaW5nIHRoZSByZXZpZXcuDQoNCkkgd2lsbCBsZWF2ZSBpdCB1cCB0byB0 aGUgYXV0aG9ycyB0byBwcm92aWRlIGZ1cnRoZXIgZGV0YWlscyBvbiB0aGlzLCBidXQgd2l0aCBt eSBzaGVwaGVyZCBoYXQgb24sIGxldCBtZSBleHBsYWluIHRoYXQgdGhpcyBvbWlzc2lvbiB3YXMg bWFkZSBvbiBwdXJwb3NlLiBUaGUgZGVjaXNpb24gd2FzIG1hZGUgdG8gbm90IHVwZGF0ZSAzMzE1 IGFuZCBub3QgYnVuZGxlIHRoaXMgaW50byAzMzE1YmlzIG9uIHB1cnBvc2UuIElmIHdlIGRpZCB0 aGF0LCB0aGVuIGV2ZXJ5IERIQ1Agc2VydmVyIHdvdWxkIEhBVkUgdG8gc3VwcG9ydCBJUFNlYy4g VGhpcyB3b3VsZCBtYWtlIGltcGxlbWVudGF0aW9uLCBjZXJ0aWZpY2F0aW9uIGFuZCBkZXBsb3lt ZW50IG11Y2ggbW9yZSBjb21wbGV4IGFuZCB0aGlzIGlzIHNvbWV0aGluZyB3ZSB3YW50ZWQgdG8g YXZvaWQuIFdpdGggdGhlIGN1cnJlbnQgYXBwcm9hY2gsIG9wZXJhdG9ycyBjYW4gYmUgc3BlY2lm aWMgd2hldGhlciB0aGV5IG5lZWQgcmVsYXkgc2VydmVyIHNlY3VyaXR5IChieSByZXF1aXJpbmcg dGhlaXIgdmVuZG9ycyB0byBzdXBwb3J0IGJvdGggMzMxNSBhbmQgdGhpcyBkb2N1bWVudCkgb3Ig bm90IChqdXN0IDMzMTUpLg0KDQpUaGlzIGlzIGFsc28gZXhwbGFpbmVkIGluIHRoZSB3cml0ZS11 cDoNCg0KKDE2KSBXaWxsIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQgY2hhbmdlIHRoZSBz dGF0dXMgb2YgYW55DQoNCmV4aXN0aW5nIFJGQ3M/IEFyZSB0aG9zZSBSRkNzIGxpc3RlZCBvbiB0 aGUgdGl0bGUgcGFnZSBoZWFkZXIsIGxpc3RlZA0KDQppbiB0aGUgYWJzdHJhY3QsIGFuZCBkaXNj dXNzZWQgaW4gdGhlIGludHJvZHVjdGlvbj8gSWYgdGhlIFJGQ3MgYXJlIG5vdA0KDQpsaXN0ZWQg aW4gdGhlIEFic3RyYWN0IGFuZCBJbnRyb2R1Y3Rpb24sIGV4cGxhaW4gd2h5LCBhbmQgcG9pbnQg dG8gdGhlDQoNCnBhcnQgb2YgdGhlIGRvY3VtZW50IHdoZXJlIHRoZSByZWxhdGlvbnNoaXAgb2Yg dGhpcyBkb2N1bWVudCB0byB0aGUNCg0Kb3RoZXIgUkZDcyBpcyBkaXNjdXNzZWQuIElmIHRoaXMg aW5mb3JtYXRpb24gaXMgbm90IGluIHRoZSBkb2N1bWVudCwNCg0KZXhwbGFpbiB3aHkgdGhlIFdH IGNvbnNpZGVycyBpdCB1bm5lY2Vzc2FyeS4NCg0KDQoNCiAgTm8uIEV2ZW4gdGhvdWdoIHRoaXMg SS1EIGludHJvZHVjZXMgY2hhbmdlcyB0byBSRkMzMzE1LCB0aGUgV0cgZG9lc24ndA0KDQogIHdh bnQgdG8gZW5mb3JjZSBJUHNlYyBlbmNyeXB0aW9uIG9uIGV2ZXJ5IERIQ1B2NiBzZXJ2ZXIuIFRo ZXJlZm9yZQ0KDQogIGl0IGRvZXMgbm90IHVwZGF0ZSBSRkMzMzE1Lg0KDQoNCkFsc28sIEknZCBs aWtlIHRvIGNsYXJpZnkgdGhhdCAzMzE1YmlzIGlzIG5vdCBhIHdpbGRjYXJkIHRoYXQgYnVuZGxl cyBldmVyeSBSRkMgcmVsYXRlZCB0byBESENQdjYgZXZlciBwdWJsaXNoZWQuIFRoaXMgZG9jdW1l bnQgaXMgMTMzIHBhZ2VzIGxvbmcgYW5kIHRoYXQgc2l6ZSBjYXVzZXMgZGlmZmljdWx0aWVzIG1v dmluZyB0aGUgd29yayBmb3J3YXJkLiBXZSdyZSB0aGlua2luZyB3aGF0IGFyZSB0aGUgdGhpbmdz IHdlIGNhbiB0YWtlIG91dCBvZiBpdCwgcmF0aGVyIHdoYXQgZWxzZSB3ZSBjb3VsZCBhZGQuIFRo ZSBwcmV2aW91cyBhcmd1bWVudCBzdGlsbCBzdGFuZHMgaGVyZS4gV2Ugd2FudCB0byBoYXZlIHRo ZSBjb3JlIHNwZWMgYW5kIGFuIGFkZGl0aW9uYWwgUkZDIHRoYXQgcGVvcGxlIGNhbiBwb2ludCB0 byB3aGVuIHRoZXkgcmVxdWlyZSBzZWN1cmUgc2VydmVyLXJlbGF5IGNvbW11bmljYXRpb24uDQoN CklmIHRoYXQgZXhwbGFuYXRpb24gaXMgbm90IGFjY2VwdGFibGUgZm9yIHlvdSwgaG93IGRvIHlv dSBwcm9wb3NlIHRvIHN0cnVjdHVyZSB0aGUgdGV4dCBhbmQgcG9zc2libHkgYWRkIHVwZGF0ZXMg MjEzMS8zMzE1IHRvIGFjaGlldmUgdGhlIGdvYWwgb3IgYmVpbmcgYSBub24tbWFuZGF0b3J5IGZl YXR1cmU/DQoNCkknbGwgbGV0IHRoZSBhdXRob3JzIGNvbW1lbnQgb24gdGhlIG5pdHMuDQoNCkFn YWluLCB0aGFua3MgZm9yIHRoZSByZXZpZXcuIEl0J3MgZ29vZCB0byByZWNlaXZlIG9uZSB0aGF0 IHNoYWtlcyB0aGluZ3MgdXAgYSBiaXQgb25jZSBpbiBhIHdoaWxlIDopDQpUb21law0KDQoNCk90 aGVyIHNtYWxsZXIgbml0czoNCg0KDQoNCm8gVGhpcyBkb2N1bWVudCB1cGRhdGVzIGJvdGggUkZD MzMxNShiaXMpIGFuZCBSRkMxNTQyLiBUaG9zZSBhcmUgbm90DQoNCnJlZmxlY3RlZCBpbiB0aGUg ZG9jdW1lbnQgdGl0bGUgcGFnZSBhbmQgYWJzdHJhY3QuDQoNCg0KDQpvIEkgd291bGQgc2VwYXJh dGUgdGhlIG5ldyByZWNvbW1lbmRhdGlvbiB0ZXh0IGZvciBESENQdjQgYW5kIERIQ1B2Ng0KDQpp bnRvIHRoZWlyIG93biByZXNwZWN0aXZlIHNlY3Rpb24uIEhhdmluZyBqdXN0IGEgb25lLWxpbmVy IHN0YXRlbWVudA0KDQoiYWxzbyBhcHBsaWVzIHRvIERIQ1B2NCBbUkZDMTU0Ml0uLiIgaXMga2lu ZCBvZiBjb25mdXNpbmcgaW4gYSBtaWRkbGUNCg0Kb2YgdmVyeSBESENQdjYgc3BlY2lmaWMgdGV4 dC4gSSByZWNvbiB0aGUgREhDUHY0IHNlY3Rpb24gd291bGQgYmUNCg0Kc2hvcnQsIGJ1dCBkZWZp bml0ZWx5IG1vcmUgY2xlYXIgaW4gdGhhdCB3YXkuDQoNCg0KDQpvIEFsdGhvdWdoIGl0IHNob3Vs ZCBiZSBvYnZpb3VzLCBidXQgSSB3b3VsZCBleHBsaWNpdGx5IHBvaW50IGl0IG91dA0KDQppbiB0 aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgdGhhdCB0aGUgc2VjdXJpdHkgbW9kZWwgaGVyZSBp cw0KDQpob3AtYnktaG9wLiBJZiB0aGVyZSBhcmUgbXVsdGlwbGUgcmVsYXlzIHRoZW4gdGhlcmUg d2lsbCBiZSBtdWx0aXBsZQ0KDQpJUHNlYyB0dW5uZWxzIGFzIHdlbGwuDQoNCg0KDQpvIFNlY3Rp b24gMTQ6ICBzL3NlY3Rpb24gMTQsL1NlY3Rpb24gMTQsDQoNCg0KDQpvDQoNCg0KDQoNCg== --_000_e996599692ff4584b8ace30a36ea6881XCHALN003ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9 DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFy YWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9y bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFu LkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEwODc5 MjA2MTY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0x MjM1Njg0NjY0IC05OTY4NzU2NjIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0 ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SGk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5UaGFua3MgZm9yIHRoZSByZXZpZXcgSm91bmkgKGFzIEludC1EaXIgY29vcmRpbmF0b3Ig YW5kIGRvY3VtZW50IGNvYXV0aG9yKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlJlZ2FyZGluZyB0aGUgbWFpbiBpc3N1ZSBhbmQgdG8gZXh0ZW5kIFRvbWVr4oCZ cyBjb21tZW50IOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ V2UgYWN0dWFsbHkgaGF2ZSB1c2VkIHRoaXMgdGV4dCwgYnV0IHdpdGhvdXQgdGhlIE1VU1QsIGlu IDMzMTViaXMgKHRoZSB1cGRhdGVkIHZlcnNpb24gaGFzIG5vdCBiZWVuIHB1Ymxpc2hlZCBhcyB0 aGUgY29hdXRob3JzIGFyZSBzdGlsbCB3b3JraW5nIHRocm91Z2ggdGhlIHJlbWFpbmluZw0KIG9w ZW4gaXNzdWVzIGZyb20gdGhlIGFwcHJveGltYXRlbHkgMzAwIHRoYXQgd2UgY2FwdHVyZWQgZHVy aW5nIHRoZSAzMzE1YmlzIFdHTEMgYmFjayBpbiBBdWd1c3QpLiBXZSBkbyBleHBlY3QgdG8gcHVi bGlzaCBhbiB1cGRhdGVkIHZlcnNpb24gYmVmb3JlIHRoZSBJRVRGLTk4IGRlYWRsaW5lIChob3Bl ZnVsbHkgd2l0aCBhbGwgaXNzdWVzIGFkZHJlc3NlZCwgYnV0IHdl4oCZbGwgc2VlKS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZCwgYXMgVG9tZWsgZXhwbGFp bmVkLCB0aGlzIGlkZWEgaGVyZSB3YXMgdG8gbWFrZSB0aGlzIGFuIE9QVElPTkFMIGZlYXR1cmUg dGhhdCB2ZW5kb3JzIGNvdWxkIGltcGxlbWVudCAobXVjaCBsaWtlIGFueSBuZXcgREhDUCBvcHRp b24pIOKAkyBidXQgaWYgd2UgbGVmdCB0aGUNCiB0ZXh0IGFzIGEgU0hPVUxEIG9yIHNpbWlsYXIs IHZlbmRvcnMgY291bGQgY2xhaW0gdGhleSBzdXBwb3J0ZWQgaXQgd2l0aG91dCBhY3R1YWxseSBp bXBsZW1lbnRpbmcgaXQuIFRodXMsIHRoaXMgZG9jdW1lbnQgaGFzIGEgTVVTVC4gQW5kLCBpdCBk b2VzIG5vdCB1cGRhdGUg4oCTIGJ1dCByYXRoZXIgZXh0ZW5kcyDigJMgMzMxNSBhbmQgMTU0Mi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT5vIEkg d291bGQgc2VwYXJhdGUgdGhlIG5ldyByZWNvbW1lbmRhdGlvbiB0ZXh0IGZvciBESENQdjQgYW5k IERIQ1B2NjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmludG8gdGhlaXIgb3duIHJlc3BlY3RpdmUg c2VjdGlvbi4gSGF2aW5nIGp1c3QgYSBvbmUtbGluZXIgc3RhdGVtZW50PG86cD48L286cD48L3By ZT4NCjxwcmU+JnF1b3Q7YWxzbyBhcHBsaWVzIHRvIERIQ1B2NCBbUkZDMTU0Ml0uLiZxdW90OyBp cyBraW5kIG9mIGNvbmZ1c2luZyBpbiBhIG1pZGRsZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm9m IHZlcnkgREhDUHY2IHNwZWNpZmljIHRleHQuIEkgcmVjb24gdGhlIERIQ1B2NCBzZWN0aW9uIHdv dWxkIGJlPG86cD48L286cD48L3ByZT4NCjxwcmU+c2hvcnQsIGJ1dCBkZWZpbml0ZWx5IG1vcmUg Y2xlYXIgaW4gdGhhdCB3YXkuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJWJmd0OyBJ4oCZ bGwgZGlzY3VzcyB0aGlzIHdpdGggWW9nZW5kcmEg4oCmIEkgdGhpbmsgd2UgY2FuIGp1c3QgbWFr ZSB0aGlzIGNsZWFyZXIgYnkgZWl0aGVyIGJyZWFraW5nIG91dCB0aGlzIGFwcGxpY2FiaWxpdHkg dGV4dCBmb3IgdjQvdjYgaW50byBzZXBhcmF0ZSBwYXJhZ3JhcGhzLiBJIGRvbuKAmXQgdGhpbmsg dGhlcmUgcmVhbGx5IHNob3VsZCBiZSBhIG5lZWQgdG8gZHVwbGljYXRlIHRoZSBtYWluIG1hdGVy aWFsIOKAkyBpLmUuLCBoYXZlIHNlcGFyYXRlIHNlY3Rpb25zIHdoaWNoIGJhc2ljYWxseSB3b3Vs ZCBiZSB0aGUgc2FtZSB0ZXh0IG9uIHRoZSBJUHNlYyBpdGVtcy48L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+byBBbHRob3VnaCBpdCBz aG91bGQgYmUgb2J2aW91cywgYnV0IEkgd291bGQgZXhwbGljaXRseSBwb2ludCBpdCBvdXQ8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5pbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgdGhhdCB0 aGUgc2VjdXJpdHkgbW9kZWwgaGVyZSBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmhvcC1ieS1o b3AuIElmIHRoZXJlIGFyZSBtdWx0aXBsZSByZWxheXMgdGhlbiB0aGVyZSB3aWxsIGJlIG11bHRp cGxlPG86cD48L286cD48L3ByZT4NCjxwcmU+SVBzZWMgdHVubmVscyBhcyB3ZWxsLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5CViZndDsgU3VyZSwgd2UgY2FuIGFkZCB0aGF0Ljwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5vIFNl Y3Rpb24gMTQ6Jm5ic3A7IHMvc2VjdGlvbiAxNCwvU2VjdGlvbiAxNCw8bzpwPjwvbzpwPjwvcHJl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CViZndDsgT0ssIHRoYW5rcyBmb3IgY2F0Y2hpbmcgdGhh dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFnYWluLCB0aGFu a3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlcm5pZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 d2luZG93dGV4dCI+IFRvbWVrIE1ydWdhbHNraSBbbWFpbHRvOnRvbWFzei5tcnVnYWxza2lAZ21h aWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDI2LCAyMDE3IDU6 MjQgQU08YnI+DQo8Yj5Ubzo8L2I+IEpvdW5pIEtvcmhvbmVuICZsdDtqb3VuaWtvckBnbWFpbC5j b20mZ3Q7OyBpbnQtZGlyQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBkaGN3Z0BpZXRmLm9yZzsg aWV0ZkBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5LmFsbEBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUmV2aWV3IG9mIGRyYWZ0LWlldGYtZGhj LXJlbGF5LXNlcnZlci1zZWN1cml0eS0wMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XIGRuaXUgMjYuMDEuMjAxNyBvJm5ic3A7MDc6NDUsIEpv dW5pIEtvcmhvbmVuIHBpc3plOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+UmV2aWV3 ZXI6IEpvdW5pIEtvcmhvbmVuPG86cD48L286cD48L3ByZT4NCjxwcmU+UmV2aWV3IHJlc3VsdDog Tm90IFJlYWR5PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmU+RGlzY2xhaW1lcjogSSBoYXZlIG5vdCBmb2xsb3dlZCByZWNlbnQgREhDIGRpc2N1c3Np b25zIHRvIHRoZSBleHRlbnQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGF0IHRoZSBleGlzdGVu Y2UgdGhpcyBkb2N1bWVudCB3YXMgbmV3IHRvIG1lLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPklzc3Vlczo8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5NeSBpc3N1ZXMgd2l0aCB0aGUgZG9jdW1l bnQgYXJlIHRoZSBmb2xsb3dpbmcuIEZpcnN0LCBpdCBhY3R1YWxseTxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPnVwZGF0ZXMgYSBncmVhdCBkZWFsIG9mIFJGQzMzMTUgKFNlY3Rpb24gMjEuMSkgd2hp bGUgdGhlcmUgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SRkMzMzE1YmlzIGluIHByb2dyZXNz LiBXaHkgdGhlIERIQ1B2NiBwYXJ0IG9mIHRoaXMgZG9jdW1lbnQgaXMgbm90PG86cD48L286cD48 L3ByZT4NCjxwcmU+ZGlyZWN0bHkgY29udHJpYnV0ZWQgdG8gUkZDMzMxNWJpcyB3b3JrPyBUaGVy ZSdzIGV2ZW4gYXV0aG9yIG92ZXJsYXA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zbyB0aGVyZSBt dXN0IGJlIGEgZ29vZCByZWFzb24uIFNlY29uZCwgaWYgdGhlcmUgaXMgYSByZWFzb24gdG8ga2Vl cDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZSBjb250ZW50IG9mIHRoaXMgZG9jdW1lbnQgc2Vw YXJhdGUgZnJvbSBSRkMzMzE1IGJvZHkgb2Ygd29yaywgYXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5sZWFzdCB0aGlzIHNwZWNpZmljYXRpb24gc2hvdWxkIHRoZW4gdGFyZ2V0IHRvIHVwZGF0ZSBS RkMzMzE1YmlzIGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm5vdCBSRkMzMzE1LjxvOnA+PC9v OnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBKb3VuaSw8 YnI+DQpGaXJzdCBvZiBhbGwsIHRoYW5rcyBmb3IgZG9pbmcgdGhlIHJldmlldy48YnI+DQo8YnI+ DQpJIHdpbGwgbGVhdmUgaXQgdXAgdG8gdGhlIGF1dGhvcnMgdG8gcHJvdmlkZSBmdXJ0aGVyIGRl dGFpbHMgb24gdGhpcywgYnV0IHdpdGggbXkgc2hlcGhlcmQgaGF0IG9uLCBsZXQgbWUgZXhwbGFp biB0aGF0IHRoaXMgb21pc3Npb24gd2FzIG1hZGUgb24gcHVycG9zZS4gVGhlIGRlY2lzaW9uIHdh cyBtYWRlIHRvIG5vdCB1cGRhdGUgMzMxNSBhbmQgbm90IGJ1bmRsZSB0aGlzIGludG8gMzMxNWJp cyBvbiBwdXJwb3NlLiBJZiB3ZSBkaWQgdGhhdCwgdGhlbg0KIGV2ZXJ5IERIQ1Agc2VydmVyIHdv dWxkIEhBVkUgdG8gc3VwcG9ydCBJUFNlYy4gVGhpcyB3b3VsZCBtYWtlIGltcGxlbWVudGF0aW9u LCBjZXJ0aWZpY2F0aW9uIGFuZCBkZXBsb3ltZW50IG11Y2ggbW9yZSBjb21wbGV4IGFuZCB0aGlz IGlzIHNvbWV0aGluZyB3ZSB3YW50ZWQgdG8gYXZvaWQuIFdpdGggdGhlIGN1cnJlbnQgYXBwcm9h Y2gsIG9wZXJhdG9ycyBjYW4gYmUgc3BlY2lmaWMgd2hldGhlciB0aGV5IG5lZWQgcmVsYXkgc2Vy dmVyIHNlY3VyaXR5DQogKGJ5IHJlcXVpcmluZyB0aGVpciB2ZW5kb3JzIHRvIHN1cHBvcnQgYm90 aCAzMzE1IGFuZCB0aGlzIGRvY3VtZW50KSBvciBub3QgKGp1c3QgMzMxNSkuPGJyPg0KPGJyPg0K VGhpcyBpcyBhbHNvIGV4cGxhaW5lZCBpbiB0aGUgd3JpdGUtdXA6PG86cD48L286cD48L3A+DQo8 cHJlPigxNikgV2lsbCBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50IGNoYW5nZSB0aGUgc3Rh dHVzIG9mIGFueTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmV4aXN0aW5nIFJGQ3M/IEFyZSB0aG9z ZSBSRkNzIGxpc3RlZCBvbiB0aGUgdGl0bGUgcGFnZSBoZWFkZXIsIGxpc3RlZDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPmluIHRoZSBhYnN0cmFjdCwgYW5kIGRpc2N1c3NlZCBpbiB0aGUgaW50cm9k dWN0aW9uPyBJZiB0aGUgUkZDcyBhcmUgbm90PG86cD48L286cD48L3ByZT4NCjxwcmU+bGlzdGVk IGluIHRoZSBBYnN0cmFjdCBhbmQgSW50cm9kdWN0aW9uLCBleHBsYWluIHdoeSwgYW5kIHBvaW50 IHRvIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnBhcnQgb2YgdGhlIGRvY3VtZW50IHdoZXJl IHRoZSByZWxhdGlvbnNoaXAgb2YgdGhpcyBkb2N1bWVudCB0byB0aGU8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5vdGhlciBSRkNzIGlzIGRpc2N1c3NlZC4gSWYgdGhpcyBpbmZvcm1hdGlvbiBpcyBu b3QgaW4gdGhlIGRvY3VtZW50LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmV4cGxhaW4gd2h5IHRo ZSBXRyBjb25zaWRlcnMgaXQgdW5uZWNlc3NhcnkuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7IE5vLiBFdmVuIHRob3VnaCB0aGlzIEkt RCBpbnRyb2R1Y2VzIGNoYW5nZXMgdG8gUkZDMzMxNSwgdGhlIFdHIGRvZXNuJ3Q8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsgd2FudCB0byBlbmZvcmNlIElQc2VjIGVuY3J5cHRpb24gb24g ZXZlcnkgREhDUHY2IHNlcnZlci4gVGhlcmVmb3JlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7IGl0IGRvZXMgbm90IHVwZGF0ZSBSRkMzMzE1LjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpBbHNvLCBJJ2QgbGlrZSB0byBjbGFyaWZ5IHRoYXQg MzMxNWJpcyBpcyBub3QgYSB3aWxkY2FyZCB0aGF0IGJ1bmRsZXMgZXZlcnkgUkZDIHJlbGF0ZWQg dG8gREhDUHY2IGV2ZXIgcHVibGlzaGVkLiBUaGlzIGRvY3VtZW50IGlzIDEzMyBwYWdlcyBsb25n IGFuZCB0aGF0IHNpemUgY2F1c2VzIGRpZmZpY3VsdGllcyBtb3ZpbmcgdGhlIHdvcmsgZm9yd2Fy ZC4gV2UncmUgdGhpbmtpbmcgd2hhdCBhcmUgdGhlIHRoaW5ncyB3ZSBjYW4gdGFrZSBvdXQgb2YN CiBpdCwgcmF0aGVyIHdoYXQgZWxzZSB3ZSBjb3VsZCBhZGQuIFRoZSBwcmV2aW91cyBhcmd1bWVu dCBzdGlsbCBzdGFuZHMgaGVyZS4gV2Ugd2FudCB0byBoYXZlIHRoZSBjb3JlIHNwZWMgYW5kIGFu IGFkZGl0aW9uYWwgUkZDIHRoYXQgcGVvcGxlIGNhbiBwb2ludCB0byB3aGVuIHRoZXkgcmVxdWly ZSBzZWN1cmUgc2VydmVyLXJlbGF5IGNvbW11bmljYXRpb24uPGJyPg0KPGJyPg0KSWYgdGhhdCBl eHBsYW5hdGlvbiBpcyBub3QgYWNjZXB0YWJsZSBmb3IgeW91LCBob3cgZG8geW91IHByb3Bvc2Ug dG8gc3RydWN0dXJlIHRoZSB0ZXh0IGFuZCBwb3NzaWJseSBhZGQgdXBkYXRlcyAyMTMxLzMzMTUg dG8gYWNoaWV2ZSB0aGUgZ29hbCBvciBiZWluZyBhIG5vbi1tYW5kYXRvcnkgZmVhdHVyZT88YnI+ DQo8YnI+DQpJJ2xsIGxldCB0aGUgYXV0aG9ycyBjb21tZW50IG9uIHRoZSBuaXRzLjxicj4NCjxi cj4NCkFnYWluLCB0aGFua3MgZm9yIHRoZSByZXZpZXcuIEl0J3MgZ29vZCB0byByZWNlaXZlIG9u ZSB0aGF0IHNoYWtlcyB0aGluZ3MgdXAgYSBiaXQgb25jZSBpbiBhIHdoaWxlIDopPGJyPg0KVG9t ZWs8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5PdGhlciBzbWFsbGVyIG5pdHM6 PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+byBU aGlzIGRvY3VtZW50IHVwZGF0ZXMgYm90aCBSRkMzMzE1KGJpcykgYW5kIFJGQzE1NDIuIFRob3Nl IGFyZSBub3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZWZsZWN0ZWQgaW4gdGhlIGRvY3VtZW50 IHRpdGxlIHBhZ2UgYW5kIGFic3RyYWN0LiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5vIEkgd291bGQgc2VwYXJhdGUgdGhlIG5ldyByZWNvbW1l bmRhdGlvbiB0ZXh0IGZvciBESENQdjQgYW5kIERIQ1B2NjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PmludG8gdGhlaXIgb3duIHJlc3BlY3RpdmUgc2VjdGlvbi4gSGF2aW5nIGp1c3QgYSBvbmUtbGlu ZXIgc3RhdGVtZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+JnF1b3Q7YWxzbyBhcHBsaWVzIHRv IERIQ1B2NCBbUkZDMTU0Ml0uLiZxdW90OyBpcyBraW5kIG9mIGNvbmZ1c2luZyBpbiBhIG1pZGRs ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm9mIHZlcnkgREhDUHY2IHNwZWNpZmljIHRleHQuIEkg cmVjb24gdGhlIERIQ1B2NCBzZWN0aW9uIHdvdWxkIGJlPG86cD48L286cD48L3ByZT4NCjxwcmU+ c2hvcnQsIGJ1dCBkZWZpbml0ZWx5IG1vcmUgY2xlYXIgaW4gdGhhdCB3YXkuPG86cD48L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+byBBbHRob3VnaCBpdCBz aG91bGQgYmUgb2J2aW91cywgYnV0IEkgd291bGQgZXhwbGljaXRseSBwb2ludCBpdCBvdXQ8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5pbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgdGhhdCB0 aGUgc2VjdXJpdHkgbW9kZWwgaGVyZSBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmhvcC1ieS1o b3AuIElmIHRoZXJlIGFyZSBtdWx0aXBsZSByZWxheXMgdGhlbiB0aGVyZSB3aWxsIGJlIG11bHRp cGxlPG86cD48L286cD48L3ByZT4NCjxwcmU+SVBzZWMgdHVubmVscyBhcyB3ZWxsLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPm8gU2VjdGlvbiAx NDombmJzcDsgcy9zZWN0aW9uIDE0LC9TZWN0aW9uIDE0LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPm8gPG86cD48L286cD48L3ByZT4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_e996599692ff4584b8ace30a36ea6881XCHALN003ciscocom_-- From nobody Thu Jan 26 10:25:56 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6ED129970; Thu, 26 Jan 2017 10:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Yh-WscksZgx; Thu, 26 Jan 2017 10:25:48 -0800 (PST) Received: from mail-pg0-x243.google.com (mail-pg0-x243.google.com [IPv6:2607:f8b0:400e:c05::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 D556312996A; Thu, 26 Jan 2017 10:25:48 -0800 (PST) Received: by mail-pg0-x243.google.com with SMTP id 204so22927306pge.2; Thu, 26 Jan 2017 10:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MV6aH6jnnJjC1jQEGh1SjGvdbBspjN+BBGcX+ZrfmZw=; b=ly7pbI4KZD8y75oAsiUJmZpOUKjdqLcC8GzpnAYJizuRbdCtH/pkU0Fxt6MQKL8pDx r/TICeynK/JWRrV5Bwmr3a5OCZnr8MYBbH8xjtvzfvKYtK15oFdrpXYIJg9LVbmJ+zfP aozbB37sDpX38HPR3JkKljkRsLlAYL6pbTjBiO6QdeGE9+9qrHl3tf+LMw05vkNb5BLL upsyfhkd9kRHRU7apcDwKHn9gnSa9vLPa+HC7D88bv+bgBdqinKzAZVxvo8+gbWjg9Uw Aj9yGGUp9Y7whHkzlCqr70nZx+qD+FJPW9SNx/PkosIImGjroOAkLUbyt/ScAC/Jq+nh k45Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MV6aH6jnnJjC1jQEGh1SjGvdbBspjN+BBGcX+ZrfmZw=; b=P7b/+zhv39stN/LXowuyKAbm+UTjA/kF+15z3UeRkc+Xr0oxCu1YjSJ3K6ON0qrW93 aAdBPXhICRS53CKpVdFLuRmq6/BP6mwwaNBZLkFjA6qL6qPfa25Lwam3tG5jqIGNTAXN 72hucGmYV1NNcT2MdoUmc0DZFr7Z3dOHeigo5E0GnMBDc52S0AMjtgQ7lSZ9eeo2cODe Qwga+MzK89f+vzvYkFfvmrEvdsYHs8GrdPF/zE3K60w012Eum5EnKhJCPZIpihqPqGjX Cj2iVW+AmE+061j76CLco+Sf5+nLuTh2oQi256IMSEuFke/1k1IPnPIYI0EG4WOrIOjJ Q3jw== X-Gm-Message-State: AIkVDXIlQqxJBhBbbGWGyRvQZuMtlWrxgtiRPd0Bdfgck8J3L4mYk4H0UsDNAofcFnSlkA== X-Received: by 10.84.179.99 with SMTP id a90mr6059857plc.139.1485455148314; Thu, 26 Jan 2017 10:25:48 -0800 (PST) Received: from [192.168.89.94] ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id d128sm5101368pfg.56.2017.01.26.10.25.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 10:25:47 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "jouni.nospam" In-Reply-To: Date: Thu, 26 Jan 2017 10:25:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> To: "Bernie Volz (volz)" , Tomek Mrugalski X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "dhcwg@ietf.org" , "draft-ietf-dhc-relay-server-security.all@ietf.org" , "ietf@ietf.org" , Jouni Korhonen , "int-dir@ietf.org" Subject: Re: [Int-dir] Review of draft-ietf-dhc-relay-server-security-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 18:25:51 -0000 Bernie, Tomek, > On Jan 26, 2017, at 5:38 AM, Bernie Volz (volz) = wrote: >=20 > Hi: > =20 > Thanks for the review Jouni (as Int-Dir coordinator and document = coauthor). > =20 > Regarding the main issue and to extend Tomek=E2=80=99s comment =E2=80=A6= > =20 > We actually have used this text, but without the MUST, in 3315bis (the = updated version has not been published as the coauthors are still = working through the remaining open issues from the approximately 300 = that we captured during the 3315bis WGLC back in August). We do expect = to publish an updated version before the IETF-98 deadline (hopefully = with all issues addressed, but we=E2=80=99ll see). > =20 > And, as Tomek explained, this idea here was to make this an OPTIONAL = feature that vendors could implement (much like any new DHCP option) =E2=80= =93 but if we left the text as a SHOULD or similar, vendors could claim = they supported it without actually implementing it. Thus, this document = has a MUST. And, it does not update =E2=80=93 but rather extends =E2=80=93= 3315 and 1542. Hmm.. I really do not like specification =E2=80=9Cgames=E2=80=9D like = this. If you cannot justify a MUST into RFC3315bis, then trying to = circumvent the fact in another document (that does not update the = RFC3315 or RFC3315bis) should not be a Standards Track document. I could = accept this as a BCP or a like. - Jouni > o I would separate the new recommendation text for DHCPv4 and DHCPv6 > into their own respective section. Having just a one-liner statement > "also applies to DHCPv4 [RFC1542].." is kind of confusing in a middle > of very DHCPv6 specific text. I recon the DHCPv4 section would be > short, but definitely more clear in that way. > =20 > BV> I=E2=80=99ll discuss this with Yogendra =E2=80=A6 I think we can = just make this clearer by either breaking out this applicability text = for v4/v6 into separate paragraphs. I don=E2=80=99t think there really = should be a need to duplicate the main material =E2=80=93 i.e., have = separate sections which basically would be the same text on the IPsec = items. > =20 > o Although it should be obvious, but I would explicitly point it out > in the Security Considerations that the security model here is > hop-by-hop. If there are multiple relays then there will be multiple > IPsec tunnels as well. > =20 > BV> Sure, we can add that. > =20 > o Section 14: s/section 14,/Section 14, > =20 > BV> OK, thanks for catching that. > =20 > Again, thanks. > =20 > - Bernie > =20 > From: Tomek Mrugalski [mailto:tomasz.mrugalski@gmail.com]=20 > Sent: Thursday, January 26, 2017 5:24 AM > To: Jouni Korhonen ; int-dir@ietf.org > Cc: dhcwg@ietf.org; ietf@ietf.org; = draft-ietf-dhc-relay-server-security.all@ietf.org > Subject: Re: Review of draft-ietf-dhc-relay-server-security-02 > =20 > W dniu 26.01.2017 o 07:45, Jouni Korhonen pisze: > Reviewer: Jouni Korhonen > Review result: Not Ready > =20 > Disclaimer: I have not followed recent DHC discussions to the extent > that the existence this document was new to me. > =20 > Issues: > =20 > My issues with the document are the following. First, it actually > updates a great deal of RFC3315 (Section 21.1) while there is > RFC3315bis in progress. Why the DHCPv6 part of this document is not > directly contributed to RFC3315bis work? There's even author overlap > so there must be a good reason. Second, if there is a reason to keep > the content of this document separate from RFC3315 body of work, at > least this specification should then target to update RFC3315bis and > not RFC3315. > Hi Jouni, > First of all, thanks for doing the review. >=20 > I will leave it up to the authors to provide further details on this, = but with my shepherd hat on, let me explain that this omission was made = on purpose. The decision was made to not update 3315 and not bundle this = into 3315bis on purpose. If we did that, then every DHCP server would = HAVE to support IPSec. This would make implementation, certification and = deployment much more complex and this is something we wanted to avoid. = With the current approach, operators can be specific whether they need = relay server security (by requiring their vendors to support both 3315 = and this document) or not (just 3315). >=20 > This is also explained in the write-up: > (16) Will publication of this document change the status of any > existing RFCs? Are those RFCs listed on the title page header, listed > in the abstract, and discussed in the introduction? If the RFCs are = not > listed in the Abstract and Introduction, explain why, and point to the > part of the document where the relationship of this document to the > other RFCs is discussed. If this information is not in the document, > explain why the WG considers it unnecessary. > =20 > No. Even though this I-D introduces changes to RFC3315, the WG = doesn't > want to enforce IPsec encryption on every DHCPv6 server. Therefore > it does not update RFC3315. >=20 >=20 > Also, I'd like to clarify that 3315bis is not a wildcard that bundles = every RFC related to DHCPv6 ever published. This document is 133 pages = long and that size causes difficulties moving the work forward. We're = thinking what are the things we can take out of it, rather what else we = could add. The previous argument still stands here. We want to have the = core spec and an additional RFC that people can point to when they = require secure server-relay communication. >=20 > If that explanation is not acceptable for you, how do you propose to = structure the text and possibly add updates 2131/3315 to achieve the = goal or being a non-mandatory feature? >=20 > I'll let the authors comment on the nits. >=20 > Again, thanks for the review. It's good to receive one that shakes = things up a bit once in a while :) > Tomek >=20 > Other smaller nits: > =20 > o This document updates both RFC3315(bis) and RFC1542. Those are not > reflected in the document title page and abstract.=20 > =20 > o I would separate the new recommendation text for DHCPv4 and DHCPv6 > into their own respective section. Having just a one-liner statement > "also applies to DHCPv4 [RFC1542].." is kind of confusing in a middle > of very DHCPv6 specific text. I recon the DHCPv4 section would be > short, but definitely more clear in that way. > =20 > o Although it should be obvious, but I would explicitly point it out > in the Security Considerations that the security model here is > hop-by-hop. If there are multiple relays then there will be multiple > IPsec tunnels as well. > =20 > o Section 14: s/section 14,/Section 14, > =20 > o=20 > =20 > =20 >=20 > _______________________________________________ > Int-dir mailing list > Int-dir@ietf.org > https://www.ietf.org/mailman/listinfo/int-dir From nobody Thu Jan 26 10:37:10 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFC912997E for ; Thu, 26 Jan 2017 10:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vImB7irQnXwB for ; Thu, 26 Jan 2017 10:37:03 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 17F11129981 for ; Thu, 26 Jan 2017 10:37:03 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id v23so89767160qtb.0 for ; Thu, 26 Jan 2017 10:37:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=U1zyNx1z2Mfc4fGygZL9pXhANg63kmSpZIgSSCHAS8A=; b=sYKPfgILzdSBD9OqZMDTVClCFuXVu56DZ4j7Xa+ceN2byVQ93jJq8T1/xL2BCjrtLR qxN41JDe4ASB61yuiYfsDeeTlCbXaIam8aWEtX4NbeREvyaNcOr4BrJ7V4CY/ZJpWIyg bn4LAzMXUjnXQWj4Xa0nAxFrPmow/zKCnlEeLvjQOGCCnis14xyM512ehBm3Jh7QG+Pj rsRe/+Oo4gX/aEol05uUF1Od5PLfygbhqmMy/inufppOmIP8nApqUIcEAcVBMXKabeF8 iOhQFnOyIlxBzJoZUP/TC6r/UYGLk1ngMaXiaft+yH1ft/tzXZ6LZGthWeSmGqCz8Yk1 ElGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=U1zyNx1z2Mfc4fGygZL9pXhANg63kmSpZIgSSCHAS8A=; b=BrgCuyqNFuBxENQD7Ne/zE+6SmYdBLQuQJesbWHMIfSuJ5oFVy0O4DCNn0f1vRRL+S FnT/s/2PtsuhsMByBo2za+ayMKiy33y5e8fQs67NEJ48OtDLSxuztsZmxPo8Xao09wwq 6nFaxiGgxLkBWua4C6ooJwEh2mS6lxnjUVL8ivNBX9aiiTlRHXWZy+6T8P+TI/fFwz88 rfgFXDVY6ynB09DM26UIwRW4cToo4zMK71Tc+0i5vQGRsET8Bfpsk/ECzYtGVYK4n8Ct FjGcfMM2jLXW6erH2sWOzZ2ezZPb86DpkmEZwXj6fr3kp8OW+iIKaQSMJzP1pJli4oGz XTTg== X-Gm-Message-State: AIkVDXKH7zZqRnK3hUys+19KV6CHPxThogWuFe8iz8O/2YmxfUgenNgxJakctXaIsnp2kg== X-Received: by 10.200.48.44 with SMTP id f41mr4098377qte.153.1485455822223; Thu, 26 Jan 2017 10:37:02 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id j129sm1861039qkd.47.2017.01.26.10.37.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 10:37:01 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3C878D77-1F36-4C34-B434-B02066DB4B48" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 26 Jan 2017 13:36:59 -0500 In-Reply-To: To: "jouni.nospam" References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "ietf@ietf.org" , "int-dir@ietf.org" , Tomek Mrugalski , Jouni Korhonen , "dhcwg@ietf.org" , "draft-ietf-dhc-relay-server-security.all@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [Int-dir] [dhcwg] Review of draft-ietf-dhc-relay-server-security-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 18:37:06 -0000 --Apple-Mail=_3C878D77-1F36-4C34-B434-B02066DB4B48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 26, 2017, at 1:25 PM, jouni.nospam = wrote: > Hmm.. I really do not like specification =E2=80=9Cgames=E2=80=9D like = this. If you cannot justify a MUST into RFC3315bis, then trying to = circumvent the fact in another document (that does not update the = RFC3315 or RFC3315bis) should not be a Standards Track document. I could = accept this as a BCP or a like. Hm, then you are saying that every extension ever done to a protocol = that, if it contains MUSTs, MUST update that protocol, even if = implementations that support the extension can interoperate with = implementations that do not and vice versa. What's your basis for = this? --Apple-Mail=_3C878D77-1F36-4C34-B434-B02066DB4B48 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 26, 2017, at 1:25 PM, jouni.nospam <jouni.nospam@gmail.com> wrote:
Hmm.. I really do = not like specification =E2=80=9Cgames=E2=80=9D like this. If you cannot = justify a MUST into RFC3315bis, then trying to circumvent the fact in = another document (that does not update the RFC3315 or RFC3315bis) should = not be a Standards Track document. I could accept this as a BCP or a = like.

Hm, then you = are saying that every extension ever done to a protocol that, if it = contains MUSTs, MUST update that protocol, even if implementations that = support the extension can interoperate with implementations that do not = and vice versa.   What's your basis for this?


= --Apple-Mail=_3C878D77-1F36-4C34-B434-B02066DB4B48-- From nobody Thu Jan 26 10:58:38 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC031129971; Thu, 26 Jan 2017 10:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2ZmZAeFRsIZ; Thu, 26 Jan 2017 10:58:35 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::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 3ECE612996D; Thu, 26 Jan 2017 10:58:35 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id 19so16930738pfo.3; Thu, 26 Jan 2017 10:58:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k3LRGTlbFZkGJypQcuUz7nLs+8K6DtWywgSIkfuyeuo=; b=WukSQ8PN78KNDxBOIHG9BOeEhdDh/+CVN0i1DLdP4MuLPYSx/2hGC3YzP13UiEHzpV gUr//b6TRgula8ZaNnm4kW0pit6DhsiQ2er+q2QPRVb2L1xC1m+sdlqxlG4Hp9iU0Ibf jLwzP8PVOeIbd5GEtYAGkTw4GyiZx8AG90cAskqhv3mJGpLsUe2EHRublsSPYJAOhAFu HchboA71qdY+L9g9yUx38cZKRF4qnF9ly1L7Cki4fAqs/o70fLS9vNZd4quDTL7BIM1z Yy3FoItJ3HhxiQqT2Y7u9xf7m0PZdaDfIRaAnlM1Mzkz3HoxS6kOd9eorx+BhAlC2wqm OwiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k3LRGTlbFZkGJypQcuUz7nLs+8K6DtWywgSIkfuyeuo=; b=JNV3D8aLugnh+5C8rPfANwi/kZ0/XKDCiwr2j3sDFoSmXRDj3V1MiOgUM4MEPt7b5r VLe4IRdDMcyUsrAcqdEXtTMK8xIfZKI4B0n/oOTuL8C9sA2CImoR3OBjbzmzFpiHt2bZ 8br/TFVbbyCZuY7eLzbzn6Gt7RlbJ4A/Txt9RjmkB5Boz9swb9P/TrUyFQugUMj8n0G5 jTCVbsiT/W8aI8zTKteP0I4giEwCVsrcVbO5zZS/Vx5YELhmWkuo+SDJxp+RPZGM1pXl 4MqNosSYCKMnCrK/37YYdV5YPdtyKswN5sM0dQHsWwRdecqogn4ZhUQQBVeTN4KNqc6d v02A== X-Gm-Message-State: AIkVDXK25YrBUI2t0+7n1ZVZx7SdxqXTs4XM1qyOhRzs5kK2xd02JKdb7/2C/oNtjOPENg== X-Received: by 10.99.53.195 with SMTP id c186mr4740712pga.24.1485457114833; Thu, 26 Jan 2017 10:58:34 -0800 (PST) Received: from [192.168.89.94] ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id s64sm5230235pfe.27.2017.01.26.10.58.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 10:58:33 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "jouni.nospam" In-Reply-To: Date: Thu, 26 Jan 2017 10:58:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <367DE531-AF9C-40A3-8B1F-5F595D804023@gmail.com> References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> To: Ted Lemon X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "ietf@ietf.org" , "int-dir@ietf.org" , Tomek Mrugalski , Jouni Korhonen , "dhcwg@ietf.org" , "draft-ietf-dhc-relay-server-security.all@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [Int-dir] [dhcwg] Review of draft-ietf-dhc-relay-server-security-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 18:58:37 -0000 > On Jan 26, 2017, at 10:36 AM, Ted Lemon wrote: >=20 > On Jan 26, 2017, at 1:25 PM, jouni.nospam = wrote: >> Hmm.. I really do not like specification =E2=80=9Cgames=E2=80=9D like = this. If you cannot justify a MUST into RFC3315bis, then trying to = circumvent the fact in another document (that does not update the = RFC3315 or RFC3315bis) should not be a Standards Track document. I could = accept this as a BCP or a like. >=20 > Hm, then you are saying that every extension ever done to a protocol = that, if it contains MUSTs, MUST update that protocol, even if = implementations that support the extension can interoperate with = implementations that do not and vice versa. What=E2=80=99s your basis = for this? No. But in this case there are pieces of text that change specific = places in the original document from SHOULDs to MUSTs, musts to MUSTs, = and adds few pieces of new stuff, etc. Now how that in not updating? = Changes or =E2=80=9Cextensions=E2=80=9D like that would be nice to = follow from the base document. - Jouni= From nobody Thu Jan 26 11:18:25 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C47F1299AD; Thu, 26 Jan 2017 11:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndmJ1COfNDII; Thu, 26 Jan 2017 11:18:11 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3973F129992; Thu, 26 Jan 2017 11:18:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3294; q=dns/txt; s=iport; t=1485458291; x=1486667891; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=j0dL5zsaMHfEVK9dwPOuj0hzsOEUkp4yaWbQf6OK4pk=; b=c2Lp0l34wo8qcRWNxPpQGFqxMscpGKLJJsLS6J5mm7a9nQvkfWcXURgq vEs0/nIt73ltqCCOT/kZ49QeCKfy1Nx82BDbBfU2ldbCiLRzlW9yRSYdT rPyrl3krRnmpTNbY1wOmSLhwMz7WovpQDleiSoNAVzjWeUk8Bbnpr60Rc Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlAQARS4pY/5tdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzUBAQEBAR+BageDTooJkgCIBo0ogg2GIgIaghM/GAECAQEBAQE?= =?us-ascii?q?BAWIohGkBAQEDASMRRQUHBAIBCBEEAQEBAgIjAwICAh8RFAEICAIEAQ0FCIk+A?= =?us-ascii?q?xAIrhSCJYc8DYMqAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELii+CUYFigxyCXwE?= =?us-ascii?q?Emxg4AY1nhAWCAI56iCSCAIhWAR84gUsVhnR1h2yBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,290,1477958400"; d="scan'208";a="200574266" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2017 19:18:10 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0QJIANi015240 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 26 Jan 2017 19:18:10 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 26 Jan 2017 13:18:09 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 26 Jan 2017 13:18:09 -0600 From: "Bernie Volz (volz)" To: "jouni.nospam" , Ted Lemon Thread-Topic: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02 Thread-Index: AQHSd5+8iSisaOl5IUWbOnwv5FiO+aFK8haA///OnZCAALfagIAAAyOAgAAGBgD//5wlwA== Date: Thu, 26 Jan 2017 19:18:09 +0000 Message-ID: <6ce93be0814a439d96ea9cbdd9f76ecf@XCH-ALN-003.cisco.com> References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> <367DE531-AF9C-40A3-8B1F-5F595D804023@gmail.com> In-Reply-To: <367DE531-AF9C-40A3-8B1F-5F595D804023@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ietf@ietf.org" , "int-dir@ietf.org" , Tomek Mrugalski , Jouni Korhonen , "dhcwg@ietf.org" , "draft-ietf-dhc-relay-server-security.all@ietf.org" Subject: Re: [Int-dir] [dhcwg] Review of draft-ietf-dhc-relay-server-security-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 19:18:13 -0000 SGk6DQoNCkl0IHNvdW5kcyBsaWtlIHdlIHNob3VsZCBub3QgdXNlOg0KDQoiVGhlIGZvbGxvd2lu ZyB0ZXh0IHJlcGxhY2VzIHRoZSB0ZXh0IGluIFJGQzMzMTUgc2VjdGlvbiAyMS4xIC4uLiINCg0K QnV0IGluc3RlYWQganVzdCB1c2Ugc29tZXRoaW5nIGNsb3NlIHRvIHRoZSBmb2xsb3dpbmcgd2hp Y2ggcmVwbGFjZXMgMXN0IHBhcmFncmFwaCBpbiBzZWN0aW9uIDM6DQoNCiAgIEZvciBESENQdjYg W1JGQzMzMTVdLCB0aGlzIHNwZWNpZmljYXRpb24gUkVRVUlSRVMgSVBzZWMgZW5jcnlwdGlvbiBv ZiByZWxheSB0bw0KICAgcmVsYXkgYW5kIHJlbGF5IHRvIHNlcnZlciBjb21tdW5pY2F0aW9uLg0K DQogICBGb3IgREhDUHY0IFtSRkMyMTMxXSwgdGhpcyBzcGVjaWZpY2F0aW9uIFJFUVVJUkVTIElQ c2VjIGVuY3J5cHRpb24gb2YgcmVsYXkgdG8NCiAgIHNlcnZlciBjb21tdW5pY2F0aW9uLg0KDQog ICBCeSB1c2luZyBJUHNlYyB3aXRoIGVuY3J5cHRpb24gZm9yIHRoaXMgY29tbXVuaWNhdGlvbiwg IHRoZSBwb3RlbnRpYWxseSBzZW5zaXRpdmUNCiAgIGNsaWVudCBtZXNzYWdlIGFuZCByZWxheSBp bmNsdWRlZCBpbmZvcm1hdGlvbiwgc3VjaCBhcyB0aGUgREhDUHY0IHJlbGF5LWFnZW50DQogICBp bmZvcm1hdGlvbiBvcHRpb24gKDgyKSwgdmVuZG9yLXNwZWNpZmljIGluZm9ybWF0aW9uIChmb3Ig ZXhhbXBsZSwgW0NhYmxlTGFicy1ESENQXSksDQogICBhbmQgQWNjZXNzLU5ldHdvcmstSWRlbnRp ZmllciBPcHRpb24ocykgW1JGQzc4MzldLCBhcmUgcHJvdGVjdGVkIGZyb20gcGVydmFzaXZlDQog ICBtb25pdG9yaW5nIGFuZCBvdGhlciBhdHRhY2tzLg0KDQpXaGF0IGlzIGluIG90aGVyIGRvY3Vt ZW50cyBkb2Vzbid0IHJlYWxseSBtYXR0ZXIgLi4uDQoNCi0gQmVybmllDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBqb3VuaS5ub3NwYW0gW21haWx0bzpqb3VuaS5ub3NwYW1A Z21haWwuY29tXSANClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI2LCAyMDE3IDE6NTkgUE0NClRv OiBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+DQpDYzogQmVybmllIFZvbHogKHZvbHopIDx2 b2x6QGNpc2NvLmNvbT47IFRvbWVrIE1ydWdhbHNraSA8dG9tYXN6Lm1ydWdhbHNraUBnbWFpbC5j b20+OyBkaGN3Z0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5 LmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgSm91bmkgS29yaG9uZW4gPGpvdW5pa29yQGdt YWlsLmNvbT47IGludC1kaXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZGhjd2ddIFtJbnQtZGly XSBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5LTAyDQoNCg0K PiBPbiBKYW4gMjYsIDIwMTcsIGF0IDEwOjM2IEFNLCBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5j b20+IHdyb3RlOg0KPiANCj4gT24gSmFuIDI2LCAyMDE3LCBhdCAxOjI1IFBNLCBqb3VuaS5ub3Nw YW0gPGpvdW5pLm5vc3BhbUBnbWFpbC5jb20+IHdyb3RlOg0KPj4gSG1tLi4gSSByZWFsbHkgZG8g bm90IGxpa2Ugc3BlY2lmaWNhdGlvbiDigJxnYW1lc+KAnSBsaWtlIHRoaXMuIElmIHlvdSBjYW5u b3QganVzdGlmeSBhIE1VU1QgaW50byBSRkMzMzE1YmlzLCB0aGVuIHRyeWluZyB0byBjaXJjdW12 ZW50IHRoZSBmYWN0IGluIGFub3RoZXIgZG9jdW1lbnQgKHRoYXQgZG9lcyBub3QgdXBkYXRlIHRo ZSBSRkMzMzE1IG9yIFJGQzMzMTViaXMpIHNob3VsZCBub3QgYmUgYSBTdGFuZGFyZHMgVHJhY2sg ZG9jdW1lbnQuIEkgY291bGQgYWNjZXB0IHRoaXMgYXMgYSBCQ1Agb3IgYSBsaWtlLg0KPiANCj4g SG0sIHRoZW4geW91IGFyZSBzYXlpbmcgdGhhdCBldmVyeSBleHRlbnNpb24gZXZlciBkb25lIHRv IGEgcHJvdG9jb2wgdGhhdCwgaWYgaXQgY29udGFpbnMgTVVTVHMsIE1VU1QgdXBkYXRlIHRoYXQg cHJvdG9jb2wsIGV2ZW4gaWYgaW1wbGVtZW50YXRpb25zIHRoYXQgc3VwcG9ydCB0aGUgZXh0ZW5z aW9uIGNhbiBpbnRlcm9wZXJhdGUgd2l0aCBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkbyBub3QgYW5k IHZpY2UgdmVyc2EuICAgV2hhdOKAmXMgeW91ciBiYXNpcyBmb3IgdGhpcz8NCg0KTm8uIEJ1dCBp biB0aGlzIGNhc2UgdGhlcmUgYXJlIHBpZWNlcyBvZiB0ZXh0IHRoYXQgY2hhbmdlIHNwZWNpZmlj IHBsYWNlcyBpbiB0aGUgb3JpZ2luYWwgZG9jdW1lbnQgZnJvbSBTSE9VTERzIHRvIE1VU1RzLCBt dXN0cyB0byBNVVNUcywgYW5kIGFkZHMgZmV3IHBpZWNlcyBvZiBuZXcgc3R1ZmYsIGV0Yy4gTm93 IGhvdyB0aGF0IGluIG5vdCB1cGRhdGluZz8gQ2hhbmdlcyBvciDigJxleHRlbnNpb25z4oCdIGxp a2UgdGhhdCB3b3VsZCBiZSBuaWNlIHRvIGZvbGxvdyBmcm9tIHRoZSBiYXNlIGRvY3VtZW50Lg0K DQotIEpvdW5pDQo= From nobody Thu Jan 26 11:27:09 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1FD1299A6 for ; Thu, 26 Jan 2017 11:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9738P_EYzU9 for ; Thu, 26 Jan 2017 11:27:07 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 1601312997E for ; Thu, 26 Jan 2017 11:27:07 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id k15so92725220qtg.3 for ; Thu, 26 Jan 2017 11:27:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=yhUSgd+YNPnWm+6I6yUwArKW77qmdQgo0WLcKiUJCMs=; b=ezzTO9EfzCsUCASoG6OIqsl5F9IMbpPL2rSin90Y1cgw0j0UiMJW18g5o15Gqzoc7R 9KzggzkyidHOOF3iBQIy+OiAbfhYTOVaDqJo43NznRKIhpZpMFYskyaU+CacRgR2V4Hy HhcMzvFZrzHONkLgl/HcevMYdBeZjkgJqCrItX35iJs6n8CAKBKCTGBpMIES+262qV78 Jnk+u4yC/gjXftTbmf8sbgCBXOI3nF1BH9quUXe1zMwuYkWKS1XnOlM/sLRf6DmGIftz 7mVCpG4LPFt1Ovq5OFuv63gP5HnVA4RLM64/78Ljgbpq5Dg4Pcn3BeawIDI66L48cjeU 7XpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=yhUSgd+YNPnWm+6I6yUwArKW77qmdQgo0WLcKiUJCMs=; b=J5Bl2FbEeR6REPdXHPa2KoJuVk3chs+VVPOUAKNWloeMBXFHwX5MqXbCss5ewZRxpU xdfD/BuqSNf5b4wJMVK8nZMwIhG2yct0cX8VvDgsGlLai1x37GyX8WPkGXIokI0XHqLp jTtf7HSMEW4dUyqJodkO82cjfs4UnfNd1bvKEgBmAmXv1+mMEScE4hSZzfggfaZKDhY/ /a+g+wt7uhldrpt8D4fDGav64zwIFK0KZJsQf7L5cPotYxqDD1obS7rBhJa5/AR8AKSi 3sziGWU/aSxvxs0B0zhHkp6YerwZuQeLmoCK5BsgElck+dArdmveAkrKGa/wO5NC+z/c P1iQ== X-Gm-Message-State: AIkVDXKV23VynyUHSc9nvh38KWhE7A1vwRIpYg4N2PruV6RTUIiDsKqhE/NXTVOX+EkG+w== X-Received: by 10.237.62.68 with SMTP id m4mr4177076qtf.171.1485458826205; Thu, 26 Jan 2017 11:27:06 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id d186sm2013056qka.7.2017.01.26.11.27.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 11:27:05 -0800 (PST) From: Ted Lemon Message-Id: <519FB5EF-52B0-4DEA-B670-2D2593C3FB66@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A4649E0F-9747-44AF-9D5B-8AECE3166C47" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 26 Jan 2017 14:27:02 -0500 In-Reply-To: <367DE531-AF9C-40A3-8B1F-5F595D804023@gmail.com> To: "jouni.nospam" References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> <367DE531-AF9C-40A3-8B1F-5F595D804023@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "ietf@ietf.org" , "int-dir@ietf.org" , Tomek Mrugalski , Jouni Korhonen , "dhcwg@ietf.org" , "draft-ietf-dhc-relay-server-security.all@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [Int-dir] [dhcwg] Review of draft-ietf-dhc-relay-server-security-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 19:27:08 -0000 --Apple-Mail=_A4649E0F-9747-44AF-9D5B-8AECE3166C47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 26, 2017, at 1:58 PM, jouni.nospam = wrote: > No. But in this case there are pieces of text that change specific = places in the original document from SHOULDs to MUSTs, musts to MUSTs, = and adds few pieces of new stuff, etc. Now how that in not updating? = Changes or =E2=80=9Cextensions=E2=80=9D like that would be nice to = follow from the base document. Okay, I see your point. But suppose the document were changed so that = rather than "updating" the document as you suggest, it simply referenced = the sections in question and then made the SHOULDs into MUSTs that way? = Wouldn't that mean "implementations of this extension MUST," and = wouldn't that be perfectly reasonable? --Apple-Mail=_A4649E0F-9747-44AF-9D5B-8AECE3166C47 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 26, 2017, at 1:58 PM, jouni.nospam <jouni.nospam@gmail.com> wrote:
No. But in this = case there are pieces of text that change specific places in the = original document from SHOULDs to MUSTs, musts to MUSTs, and adds few = pieces of new stuff, etc. Now how that in not updating? Changes or = =E2=80=9Cextensions=E2=80=9D like that would be nice to follow from the = base document.

Okay, I see your point.   But suppose the document were = changed so that rather than "updating" the document as you suggest, it = simply referenced the sections in question and then made the SHOULDs = into MUSTs that way?   Wouldn't that mean "implementations of this = extension MUST," and wouldn't that be perfectly reasonable?

= --Apple-Mail=_A4649E0F-9747-44AF-9D5B-8AECE3166C47-- From nobody Thu Jan 26 12:06:46 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB94D129A63; Thu, 26 Jan 2017 12:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSw58MycRqEB; Thu, 26 Jan 2017 12:06:42 -0800 (PST) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 DEA3A129A3D; Thu, 26 Jan 2017 12:06:41 -0800 (PST) Received: by mail-it0-x244.google.com with SMTP id o138so6191874ito.3; Thu, 26 Jan 2017 12:06:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=SLoNUZrR9z1Ch08RdkFn3ex4mch3fBDJyVWz0pu0VCg=; b=ApIb4s+KRVZtw+xHD+RPW/Wozfcoz5HlXARip7418tJUSW2NkkzVxJcIvG+ZCytulI m4F+t3itZ+d45cpSKgPIJqNqWSfqCNX6pQCNGiKjGF99pHR7ivoM/NYHLOeuZoHinqaR F7oVBIuTdQd2Ziy0aDfPGk50aZrLYTItEVzpXLkdM7iJOqR2AXnIaOWm0GACqt+UVM17 aAmC/E8lk9FH2nWV3XYzgrmzDL5XhIrJHLrmtzdc1EUWXIs6aVFCxZUiZx0OuBbL9Vkt 2t7SgQZsJ3N8aehKxJRXpCQ2H+s8i+BiWdiqqmj+DPUcNhjecH98sEZb4uoHPo70J16w xCoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=SLoNUZrR9z1Ch08RdkFn3ex4mch3fBDJyVWz0pu0VCg=; b=Lb20Eq8Fgdna1LOmxYmBOi+jYwW/pM+3ptDqIINAMcS7wBG6fhwdaDXnZC9vfUHHce qQoSZ4rfxhxp5hYk95YuwjG2X4scNz2U6xU8OjRPCRrCvyQyD3RV7Hmr8VdTRjSxyfFy D1CK1oFfDckBHhRj+uuTj5y8oEHL48VGorDkqwuMl5P+CYEZvePEOj+cvrq3suwXsMY3 2nTDFjUvHPkF4EJ0bFnvjwZJuRVnndUYM4/lj0BCn2k3dEqvRRUGVk9XEYodo4n1f1v5 2fvdYvQB7vipQ9gMm8VSSTvCNSyMNiQxX0OamYfQ2yxa+BrgeCqntG492TRVukPvW8iW lj2A== X-Gm-Message-State: AIkVDXJCChcO+qcy+cQ40aaci3w6dX3mqJRkQR3bCWhjgdPT885Ap55mHGAZwjqR/lLHkg== X-Received: by 10.36.12.11 with SMTP id 11mr254561itn.10.1485461201124; Thu, 26 Jan 2017 12:06:41 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id g82sm1953865ioa.13.2017.01.26.12.06.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 12:06:40 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9B08A87E-CDD2-403A-BCBC-37B629B49E90"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 26 Jan 2017 12:06:38 -0800 In-Reply-To: <484b4d11bea54ef1b0b0780d3cd1eab8@XCH-ALN-003.cisco.com> To: "Bernie Volz (volz)" References: <484b4d11bea54ef1b0b0780d3cd1eab8@XCH-ALN-003.cisco.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Donald Eastlake , Bob Hinden , "draft-ietf-6man-rfc1981bis.all@ietf.org" , "int-dir@ietf.org" Subject: Re: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 20:06:44 -0000 --Apple-Mail=_9B08A87E-CDD2-403A-BCBC-37B629B49E90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Bernie, inline > On Jan 25, 2017, at 3:15 PM, Bernie Volz (volz) = wrote: >=20 > Bob: >=20 > While it is great that you know this issue with RFC 2119 key words ... = others reading this document when it becomes an RFC may not know that = (and RFC8xxx or whatever it will be does not predate 2119) and even if = the RFC 2119 reference isn't directly in the document, what will they = assume (I mostly assume if I see MUST in an IETF document, it is a RFC = 2119 key word)? >=20 > I would think that at a minimum, adding a note that this document does = NOT make explicitly use of RFC 2119 key words and therefore how a reader = interprets MUST vs must is up to them (presumable MUST is more of a must = than the lower case version). I don=E2=80=99t object to a note. However, RFC2119 does not require = upper case, so making statements about the precedence of upper vs. lower = case it=E2=80=99s warranted. How about something like this: Note: This document is an update to RFC1981 that was published prior to = RFC2119 being published. Consequently while it does use "should/must" = style language in upper and lower case, the document does not cite the = RFC2119 definitions. This update does not change that. I guess this means I will have to add a reference to RFC2119 :-) >=20 > I think it might also be possible to argue that 2119 might have been = on the horizon at the time and as it did not yet exist ... 02 of the = 2119 draft (oldest available at tools.ietf.org) was published in August = 1996 which is the same month in which 1981 was published. So seems = likely that there is some influence from that work here? >=20 > I guess one conclusion is that even if not explicitly indicated, the = assumption that they are (in the spirit of) 2119 key words is likely = correct. I suspect that is true. The reason why we didn=E2=80=99t cite RFC2119 = in rfc1981bis, is that RFC1981 is very widely implemented using the = current language, and starting to change the =E2=80=9Cmust/should/etc.=E2=80= =9D to upper case, will likely cause some to think that this document is = intended to change implementation behaviour. That was not the intent of = the w.g. The changes in the bis document are very limited. Thanks, Bob >=20 > - Bernie >=20 > -----Original Message----- > From: Int-dir [mailto:int-dir-bounces@ietf.org] On Behalf Of Bob = Hinden > Sent: Wednesday, January 25, 2017 5:43 PM > To: Donald Eastlake > Cc: Bob Hinden ; = draft-ietf-6man-rfc1981bis.all@ietf.org; int-dir@ietf.org > Subject: Re: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review >=20 > Donald, >=20 > Thanks for your comments! >=20 > To set the background this, this is part of 6MAN work to advance the = core IPv6 specs from Draft Standard to Internet Standard. As part of = this, we were only trying to change things that where there were RFCs = that updated it, errata, and to make it consistent with the other RFCs = being advanced (for example rfc2460bis and rfc4291bis). We were trying = to change as little as possible. >=20 > That why we kept the must/should language intact and did not include a = reference to RFC2119. RFC1981 was, of course, written before RFC2119. = It uses a mix of upper and lower case words, I am am reluctant to try to = change that. This is also consistent with how the w.g. handled this = issue with rfc2460bis and rfc4291bis. >=20 > Comments inline below. >=20 > Bob >=20 >=20 >> On Jan 25, 2017, at 1:24 PM, Donald Eastlake = wrote: >>=20 >> I am an assigned INT directorate reviewer for >> draft-ietf-6man-rfc1981bis-03.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. >>=20 >> This document appears to be Ready with Nits. >>=20 >>=20 >> Add RFC 2119 to Reference and add corresponding boilerplate, probably >> to the Terminology section. >=20 > See note above. >=20 >>=20 >> Section 4, Page 6, next to last paragraph of Section 4: "should" -> = =E2=80=9CSHOULD" >=20 > ditto >=20 >>=20 >> Section 5.1, Page 7, 2nd sentence of next to last paragraph of = Section >> 5.1: delete superfluous comma >=20 > Thanks, will fix. >=20 >>=20 >> Section 5.2, Page 7: just a wording suggestion: "must in fact >> represent" -> =E2=80=9Crepresents" >=20 > Makes sense to me, I will change. >=20 >>=20 >> Section 5.2, Page 8: The indented Note about "security >> classifications" strikes me as probably an archaism left over from >> when it was the "US Department of Defense Internet". I suggest >> replacing "security classifications" with "quality of service >> markings" or the like. Security seems like one "quality" of service = so >> I believe the new wording I am suggesting is a superset of the old. >=20 > While I tend to agree with you, I think this is a change we don=E2=80=99= t have very much justification to make. >=20 >>=20 >> Section 5.2, Page 9: I am not entirely comfortable that earlier in = the >> document it says that a Packet Too Big reporting a next hop MTU less >> than the IPv6 minimum link MTU should be discarded and that a node >> MUST NOT reduce its estimate of the Path MTU below the IPv6 minimum >> link MTU but in the top paragraph on page 9 it talks in an >> unrestricted way about reducing the PMTU based on Packet Too Big >> message next hop size. I suggest, at the top of page 9: "uses the >> value in the MTU field in the Packet Too Big message as a tentative >> PMTU" -> "uses the value in the MTU field in the Packet Too Big >> message, or the minimum IPv6 next hop MTU if that is larger, as a >> tentative PMTU=E2=80=9D >>=20 >=20 > I agree, thanks for catching this. This makes it consistent with the = earlier text in Section 4. >=20 >=20 >> Section 5.3, Page 10, right after the indented Note: "must not" -> = "MUST NOT" >>=20 >> Section 5.4, Page 10: "should not" -> "SHOULD NOT" >>=20 >> Section 5.4, Page 11, 1st paragraph: Expand "MSS" on first use; "must >> not" -> "MUST NOT=E2=80=9D >=20 > Agree about MSS. >=20 >>=20 >> Section 5.4, Page 11, indented Note: in 1st paragraph "must not" -> >> "MUST NOT"; in 2nd paragraph "must" -> "MUST" >>=20 >> Section 5.5, Page 12, 1st paragraph: "should" -> "SHOULD" >>=20 >> Section 5.5, Page 12, 3rd paragraph: "recommended" -> "RECOMMENDED" >>=20 >> Section 5.5, Page 12, 4th paragraph: If some NFS operations cannot be >> fragmented, "should not" -> "MUST NOT" >>=20 >> Appendix B, 2nd sentence: "version that the change was made.:" -> >> "version where the change was made.=E2=80=9D >=20 > Thanks, will fix. >=20 >>=20 >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >=20 > _______________________________________________ > Int-dir mailing list > Int-dir@ietf.org > https://www.ietf.org/mailman/listinfo/int-dir --Apple-Mail=_9B08A87E-CDD2-403A-BCBC-37B629B49E90 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYilbOAAoJEK7rdBF357uoobgH/3e4c0xH8b1IcrBB/sMiYoio cIHFEdTJHhPn59E870MP7xtpn5vQlun+8T8WVQ0UZqTyWYO/Rtl2AJi+SAXU5eJn GrIY0FZBzb5w+UyGaIJjlN/bP6F/KZ1AXwpvUG8r84R4ZEBkpD3aSkuwVr5D2XLf YoIiYbOqksnQ7lUKq2QQMEs1vExa0d7xkxfAhR9Rgs8c3rdGOYUq0I0edbFlUXVM p3tyy6OJ5ha/HCmKoMk/Q3Dqxif7+SH6tq36YBqqA7fQj5ervd8zpECzhe+jv/Ct 8DjMRuM84eTMkfEnIwedduvy0xjT21C77uVMVjxYvXZnREcWnSIjB601JaxsFgs= =8AJI -----END PGP SIGNATURE----- --Apple-Mail=_9B08A87E-CDD2-403A-BCBC-37B629B49E90-- From nobody Thu Jan 26 12:30:54 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC53129ACB; Thu, 26 Jan 2017 12:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx8swliRn1tq; Thu, 26 Jan 2017 12:30:50 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5BC129AC7; Thu, 26 Jan 2017 12:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10724; q=dns/txt; s=iport; t=1485462650; x=1486672250; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AuBSC3oCZxPJaJJaRZl3vzbCF8qm7mZ5fwF5j+r+lp0=; b=jnR2XbEbv71w/MzgNDgDdMk9RkHOXeJTgh3lD7Jo74zunyb2nZarlUbs 8ReUuqg3Isyo8XhoEVVxahCnMhl8sQ6+khnSiDylqc1Ms4SxgAYewlayM JksBfYCuQ2fMZfwHormi7NyjM88qgIEqB42XRwlcy/+LQEKHz/Cc0rfpc k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BmAQBtW4pY/4UNJK1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM1AQEBAQEfYYEJB4NOigmSAIgGjSiCDR8LhXgCGoITPxgBAgE?= =?us-ascii?q?BAQEBAQFiKIRpAQEBAwEBASEEDToLBQcEAgEIEQQBAQECAiMDAgICHwYLFAEIC?= =?us-ascii?q?AIEDgUIAYk9AxAIDq10gWs6hz0NgywBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQu?= =?us-ascii?q?KL4JRgVQ7CiaCP4JfBZsYOAGNZ4QFggCOeogkggCIVgEfOIFLFTuEPByBYXUBh?= =?us-ascii?q?juBMIENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,291,1477958400"; d="scan'208";a="377018603" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 Jan 2017 20:30:49 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v0QKUnY5022030 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 26 Jan 2017 20:30:49 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 26 Jan 2017 14:30:48 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Thu, 26 Jan 2017 14:30:48 -0600 From: "Bernie Volz (volz)" To: Bob Hinden Thread-Topic: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review Thread-Index: AQHSd1F85bWwlL/Kz06HMvicjEigYaFKLpeA//+gwECAAcYCAP//ocxA Date: Thu, 26 Jan 2017 20:30:48 +0000 Message-ID: <70f2f8a012de43a4b35f625837b768b2@XCH-ALN-003.cisco.com> References: <484b4d11bea54ef1b0b0780d3cd1eab8@XCH-ALN-003.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Donald Eastlake , "draft-ietf-6man-rfc1981bis.all@ietf.org" , "int-dir@ietf.org" Subject: Re: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 20:30:53 -0000 SGkgQm9iOg0KDQpZb3VyIG5vdGUgd291bGQgd29yayB3ZWxsIGZvciBtZS4NCg0KTm90ZTogIFRo aXMgZG9jdW1lbnQgaXMgYW4gdXBkYXRlIHRvIFJGQzE5ODEgdGhhdCB3YXMgcHVibGlzaGVkIHBy aW9yIHRvIFJGQzIxMTkgYmVpbmcgcHVibGlzaGVkLiAgQ29uc2VxdWVudGx5IHdoaWxlIGl0IGRv ZXMgdXNlICJzaG91bGQvbXVzdCIgc3R5bGUgbGFuZ3VhZ2UgaW4gdXBwZXIgYW5kIGxvd2VyIGNh c2UsIHRoZSBkb2N1bWVudCBkb2VzIG5vdCBjaXRlIHRoZSBSRkMyMTE5IGRlZmluaXRpb25zLiAg VGhpcyB1cGRhdGUgZG9lcyBub3QgY2hhbmdlIHRoYXQuDQoNCi0gQmVybmllDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCb2IgSGluZGVuIFttYWlsdG86Ym9iLmhpbmRlbkBn bWFpbC5jb21dIA0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjYsIDIwMTcgMzowNyBQTQ0KVG86 IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb20+DQpDYzogQm9iIEhpbmRlbiA8Ym9i LmhpbmRlbkBnbWFpbC5jb20+OyBEb25hbGQgRWFzdGxha2UgPGQzZTNlM0BnbWFpbC5jb20+OyBk cmFmdC1pZXRmLTZtYW4tcmZjMTk4MWJpcy5hbGxAaWV0Zi5vcmc7IGludC1kaXJAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbSW50LWRpcl0gZHJhZnQtaWV0Zi02bWFuLXJmYzE5ODFiaXMtMDMgSU5U RElSIHJldmlldw0KDQpIaSBCZXJuaWUsDQoNCmlubGluZQ0KDQo+IE9uIEphbiAyNSwgMjAxNywg YXQgMzoxNSBQTSwgQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNvbT4gd3JvdGU6DQo+ IA0KPiBCb2I6DQo+IA0KPiBXaGlsZSBpdCBpcyBncmVhdCB0aGF0IHlvdSBrbm93IHRoaXMgaXNz dWUgd2l0aCBSRkMgMjExOSBrZXkgd29yZHMgLi4uIG90aGVycyByZWFkaW5nIHRoaXMgZG9jdW1l bnQgd2hlbiBpdCBiZWNvbWVzIGFuIFJGQyBtYXkgbm90IGtub3cgdGhhdCAoYW5kIFJGQzh4eHgg b3Igd2hhdGV2ZXIgaXQgd2lsbCBiZSBkb2VzIG5vdCBwcmVkYXRlIDIxMTkpIGFuZCBldmVuIGlm IHRoZSBSRkMgMjExOSByZWZlcmVuY2UgaXNuJ3QgZGlyZWN0bHkgaW4gdGhlIGRvY3VtZW50LCB3 aGF0IHdpbGwgdGhleSBhc3N1bWUgKEkgbW9zdGx5IGFzc3VtZSBpZiBJIHNlZSBNVVNUIGluIGFu IElFVEYgZG9jdW1lbnQsIGl0IGlzIGEgUkZDIDIxMTkga2V5IHdvcmQpPw0KPiANCj4gSSB3b3Vs ZCB0aGluayB0aGF0IGF0IGEgbWluaW11bSwgYWRkaW5nIGEgbm90ZSB0aGF0IHRoaXMgZG9jdW1l bnQgZG9lcyBOT1QgbWFrZSBleHBsaWNpdGx5IHVzZSBvZiBSRkMgMjExOSBrZXkgd29yZHMgYW5k IHRoZXJlZm9yZSBob3cgYSByZWFkZXIgaW50ZXJwcmV0cyBNVVNUIHZzIG11c3QgaXMgdXAgdG8g dGhlbSAocHJlc3VtYWJsZSBNVVNUIGlzIG1vcmUgb2YgYSBtdXN0IHRoYW4gdGhlIGxvd2VyIGNh c2UgdmVyc2lvbikuDQoNCkkgZG9u4oCZdCBvYmplY3QgdG8gYSBub3RlLiAgSG93ZXZlciwgUkZD MjExOSBkb2VzIG5vdCByZXF1aXJlIHVwcGVyIGNhc2UsIHNvIG1ha2luZyBzdGF0ZW1lbnRzIGFi b3V0IHRoZSBwcmVjZWRlbmNlIG9mIHVwcGVyIHZzLiBsb3dlciBjYXNlIGl04oCZcyB3YXJyYW50 ZWQuDQoNCkhvdyBhYm91dCBzb21ldGhpbmcgbGlrZSB0aGlzOg0KDQpOb3RlOiAgVGhpcyBkb2N1 bWVudCBpcyBhbiB1cGRhdGUgdG8gUkZDMTk4MSB0aGF0IHdhcyBwdWJsaXNoZWQgcHJpb3IgdG8g UkZDMjExOSBiZWluZyBwdWJsaXNoZWQuICBDb25zZXF1ZW50bHkgd2hpbGUgaXQgZG9lcyB1c2Ug InNob3VsZC9tdXN0IiBzdHlsZSBsYW5ndWFnZSBpbiB1cHBlciBhbmQgbG93ZXIgY2FzZSwgdGhl IGRvY3VtZW50IGRvZXMgbm90IGNpdGUgdGhlIFJGQzIxMTkgZGVmaW5pdGlvbnMuICBUaGlzIHVw ZGF0ZSBkb2VzIG5vdCBjaGFuZ2UgdGhhdC4NCg0KSSBndWVzcyB0aGlzIG1lYW5zIEkgd2lsbCBo YXZlIHRvIGFkZCBhIHJlZmVyZW5jZSB0byBSRkMyMTE5IDotKQ0KDQo+IA0KPiBJIHRoaW5rIGl0 IG1pZ2h0IGFsc28gYmUgcG9zc2libGUgdG8gYXJndWUgdGhhdCAyMTE5IG1pZ2h0IGhhdmUgYmVl biBvbiB0aGUgaG9yaXpvbiBhdCB0aGUgdGltZSBhbmQgYXMgaXQgZGlkIG5vdCB5ZXQgZXhpc3Qg Li4uIDAyIG9mIHRoZSAyMTE5IGRyYWZ0IChvbGRlc3QgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnKSB3YXMgcHVibGlzaGVkIGluIEF1Z3VzdCAxOTk2IHdoaWNoIGlzIHRoZSBzYW1lIG1vbnRo IGluIHdoaWNoIDE5ODEgd2FzIHB1Ymxpc2hlZC4gU28gc2VlbXMgbGlrZWx5IHRoYXQgdGhlcmUg aXMgc29tZSBpbmZsdWVuY2UgZnJvbSB0aGF0IHdvcmsgaGVyZT8NCj4gDQo+IEkgZ3Vlc3Mgb25l IGNvbmNsdXNpb24gaXMgdGhhdCBldmVuIGlmIG5vdCBleHBsaWNpdGx5IGluZGljYXRlZCwgdGhl IGFzc3VtcHRpb24gdGhhdCB0aGV5IGFyZSAoaW4gdGhlIHNwaXJpdCBvZikgMjExOSBrZXkgd29y ZHMgaXMgbGlrZWx5IGNvcnJlY3QuDQoNCkkgc3VzcGVjdCB0aGF0IGlzIHRydWUuICBUaGUgcmVh c29uIHdoeSB3ZSBkaWRu4oCZdCBjaXRlIFJGQzIxMTkgaW4gcmZjMTk4MWJpcywgaXMgdGhhdCBS RkMxOTgxIGlzIHZlcnkgd2lkZWx5IGltcGxlbWVudGVkIHVzaW5nIHRoZSBjdXJyZW50IGxhbmd1 YWdlLCBhbmQgc3RhcnRpbmcgdG8gY2hhbmdlIHRoZSDigJxtdXN0L3Nob3VsZC9ldGMu4oCdIHRv IHVwcGVyIGNhc2UsIHdpbGwgbGlrZWx5IGNhdXNlIHNvbWUgdG8gdGhpbmsgdGhhdCB0aGlzIGRv Y3VtZW50IGlzIGludGVuZGVkIHRvIGNoYW5nZSBpbXBsZW1lbnRhdGlvbiBiZWhhdmlvdXIuICBU aGF0IHdhcyBub3QgdGhlIGludGVudCBvZiB0aGUgdy5nLiAgVGhlIGNoYW5nZXMgaW4gdGhlIGJp cyBkb2N1bWVudCBhcmUgdmVyeSBsaW1pdGVkLg0KDQpUaGFua3MsDQpCb2INCg0KPiANCj4gLSBC ZXJuaWUNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEludC1kaXIg W21haWx0bzppbnQtZGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCb2IgDQo+IEhp bmRlbg0KPiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjUsIDIwMTcgNTo0MyBQTQ0KPiBUbzog RG9uYWxkIEVhc3RsYWtlIDxkM2UzZTNAZ21haWwuY29tPg0KPiBDYzogQm9iIEhpbmRlbiA8Ym9i LmhpbmRlbkBnbWFpbC5jb20+OyANCj4gZHJhZnQtaWV0Zi02bWFuLXJmYzE5ODFiaXMuYWxsQGll dGYub3JnOyBpbnQtZGlyQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbSW50LWRpcl0gZHJhZnQt aWV0Zi02bWFuLXJmYzE5ODFiaXMtMDMgSU5URElSIHJldmlldw0KPiANCj4gRG9uYWxkLA0KPiAN Cj4gVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIQ0KPiANCj4gVG8gc2V0IHRoZSBiYWNrZ3JvdW5k IHRoaXMsIHRoaXMgaXMgcGFydCBvZiA2TUFOIHdvcmsgdG8gYWR2YW5jZSB0aGUgY29yZSBJUHY2 IHNwZWNzIGZyb20gRHJhZnQgU3RhbmRhcmQgdG8gSW50ZXJuZXQgU3RhbmRhcmQuICBBcyBwYXJ0 IG9mIHRoaXMsIHdlIHdlcmUgb25seSB0cnlpbmcgdG8gY2hhbmdlIHRoaW5ncyB0aGF0IHdoZXJl IHRoZXJlIHdlcmUgUkZDcyB0aGF0IHVwZGF0ZWQgaXQsIGVycmF0YSwgYW5kIHRvIG1ha2UgaXQg Y29uc2lzdGVudCB3aXRoIHRoZSBvdGhlciBSRkNzIGJlaW5nIGFkdmFuY2VkIChmb3IgZXhhbXBs ZSByZmMyNDYwYmlzIGFuZCByZmM0MjkxYmlzKS4gV2Ugd2VyZSB0cnlpbmcgdG8gY2hhbmdlIGFz IGxpdHRsZSBhcyBwb3NzaWJsZS4NCj4gDQo+IFRoYXQgd2h5IHdlIGtlcHQgdGhlIG11c3Qvc2hv dWxkIGxhbmd1YWdlIGludGFjdCBhbmQgZGlkIG5vdCBpbmNsdWRlIGEgcmVmZXJlbmNlIHRvIFJG QzIxMTkuICBSRkMxOTgxIHdhcywgb2YgY291cnNlLCB3cml0dGVuIGJlZm9yZSBSRkMyMTE5LiAg SXQgdXNlcyBhIG1peCBvZiB1cHBlciBhbmQgbG93ZXIgY2FzZSB3b3JkcywgSSBhbSBhbSByZWx1 Y3RhbnQgdG8gdHJ5IHRvIGNoYW5nZSB0aGF0LiAgIFRoaXMgaXMgYWxzbyBjb25zaXN0ZW50IHdp dGggaG93IHRoZSB3LmcuIGhhbmRsZWQgdGhpcyBpc3N1ZSB3aXRoIHJmYzI0NjBiaXMgYW5kIHJm YzQyOTFiaXMuDQo+IA0KPiBDb21tZW50cyBpbmxpbmUgYmVsb3cuDQo+IA0KPiBCb2INCj4gDQo+ IA0KPj4gT24gSmFuIDI1LCAyMDE3LCBhdCAxOjI0IFBNLCBEb25hbGQgRWFzdGxha2UgPGQzZTNl M0BnbWFpbC5jb20+IHdyb3RlOg0KPj4gDQo+PiBJIGFtIGFuIGFzc2lnbmVkIElOVCBkaXJlY3Rv cmF0ZSByZXZpZXdlciBmb3IgDQo+PiBkcmFmdC1pZXRmLTZtYW4tcmZjMTk4MWJpcy0wMy50eHQu IFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiANCj4+IHByaW1hcmlseSBmb3IgdGhlIGJlbmVm aXQgb2YgdGhlIEludGVybmV0IEFyZWEgRGlyZWN0b3JzLiBEb2N1bWVudCANCj4+IGVkaXRvcnMg YW5kIHNoZXBoZXJkKHMpIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgdGhl eSANCj4+IHdvdWxkIHRyZWF0IGNvbW1lbnRzIGZyb20gYW55IG90aGVyIElFVEYgY29udHJpYnV0 b3JzIGFuZCByZXNvbHZlIA0KPj4gdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBMYXN0IENhbGwg Y29tbWVudHMgdGhhdCBoYXZlIGJlZW4gcmVjZWl2ZWQuIA0KPj4gRm9yIG1vcmUgZGV0YWlscyBv biB0aGUgSU5UIERpcmVjdG9yYXRlLCBzZWUgDQo+PiBodHRwOi8vd3d3LmlldGYub3JnL2llc2cv ZGlyZWN0b3JhdGUuaHRtbC4NCj4+IA0KPj4gVGhpcyBkb2N1bWVudCBhcHBlYXJzIHRvIGJlIFJl YWR5IHdpdGggTml0cy4NCj4+IA0KPj4gDQo+PiBBZGQgUkZDIDIxMTkgdG8gUmVmZXJlbmNlIGFu ZCBhZGQgY29ycmVzcG9uZGluZyBib2lsZXJwbGF0ZSwgcHJvYmFibHkgDQo+PiB0byB0aGUgVGVy bWlub2xvZ3kgc2VjdGlvbi4NCj4gDQo+IFNlZSBub3RlIGFib3ZlLg0KPiANCj4+IA0KPj4gU2Vj dGlvbiA0LCBQYWdlIDYsIG5leHQgdG8gbGFzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbiA0OiAic2hv dWxkIiAtPiDigJxTSE9VTEQiDQo+IA0KPiBkaXR0bw0KPiANCj4+IA0KPj4gU2VjdGlvbiA1LjEs IFBhZ2UgNywgMm5kIHNlbnRlbmNlIG9mIG5leHQgdG8gbGFzdCBwYXJhZ3JhcGggb2YgDQo+PiBT ZWN0aW9uDQo+PiA1LjE6IGRlbGV0ZSBzdXBlcmZsdW91cyBjb21tYQ0KPiANCj4gVGhhbmtzLCB3 aWxsIGZpeC4NCj4gDQo+PiANCj4+IFNlY3Rpb24gNS4yLCBQYWdlIDc6IGp1c3QgYSB3b3JkaW5n IHN1Z2dlc3Rpb246ICJtdXN0IGluIGZhY3QgDQo+PiByZXByZXNlbnQiIC0+IOKAnHJlcHJlc2Vu dHMiDQo+IA0KPiBNYWtlcyBzZW5zZSB0byBtZSwgSSB3aWxsIGNoYW5nZS4NCj4gDQo+PiANCj4+ IFNlY3Rpb24gNS4yLCBQYWdlIDg6IFRoZSBpbmRlbnRlZCBOb3RlIGFib3V0ICJzZWN1cml0eSAN Cj4+IGNsYXNzaWZpY2F0aW9ucyIgc3RyaWtlcyBtZSBhcyBwcm9iYWJseSBhbiBhcmNoYWlzbSBs ZWZ0IG92ZXIgZnJvbSANCj4+IHdoZW4gaXQgd2FzIHRoZSAiVVMgRGVwYXJ0bWVudCBvZiBEZWZl bnNlIEludGVybmV0Ii4gSSBzdWdnZXN0IA0KPj4gcmVwbGFjaW5nICJzZWN1cml0eSBjbGFzc2lm aWNhdGlvbnMiIHdpdGggInF1YWxpdHkgb2Ygc2VydmljZSANCj4+IG1hcmtpbmdzIiBvciB0aGUg bGlrZS4gU2VjdXJpdHkgc2VlbXMgbGlrZSBvbmUgInF1YWxpdHkiIG9mIHNlcnZpY2UgDQo+PiBz byBJIGJlbGlldmUgdGhlIG5ldyB3b3JkaW5nIEkgYW0gc3VnZ2VzdGluZyBpcyBhIHN1cGVyc2V0 IG9mIHRoZSBvbGQuDQo+IA0KPiBXaGlsZSBJIHRlbmQgdG8gYWdyZWUgd2l0aCB5b3UsIEkgdGhp bmsgdGhpcyBpcyBhIGNoYW5nZSB3ZSBkb27igJl0IGhhdmUgdmVyeSBtdWNoIGp1c3RpZmljYXRp b24gdG8gbWFrZS4NCj4gDQo+PiANCj4+IFNlY3Rpb24gNS4yLCBQYWdlIDk6IEkgYW0gbm90IGVu dGlyZWx5IGNvbWZvcnRhYmxlIHRoYXQgZWFybGllciBpbiANCj4+IHRoZSBkb2N1bWVudCBpdCBz YXlzIHRoYXQgYSBQYWNrZXQgVG9vIEJpZyByZXBvcnRpbmcgYSBuZXh0IGhvcCBNVFUgDQo+PiBs ZXNzIHRoYW4gdGhlIElQdjYgbWluaW11bSBsaW5rIE1UVSBzaG91bGQgYmUgZGlzY2FyZGVkIGFu ZCB0aGF0IGEgDQo+PiBub2RlIE1VU1QgTk9UIHJlZHVjZSBpdHMgZXN0aW1hdGUgb2YgdGhlIFBh dGggTVRVIGJlbG93IHRoZSBJUHY2IA0KPj4gbWluaW11bSBsaW5rIE1UVSBidXQgaW4gdGhlIHRv cCBwYXJhZ3JhcGggb24gcGFnZSA5IGl0IHRhbGtzIGluIGFuIA0KPj4gdW5yZXN0cmljdGVkIHdh eSBhYm91dCByZWR1Y2luZyB0aGUgUE1UVSBiYXNlZCBvbiBQYWNrZXQgVG9vIEJpZyANCj4+IG1l c3NhZ2UgbmV4dCBob3Agc2l6ZS4gSSBzdWdnZXN0LCBhdCB0aGUgdG9wIG9mIHBhZ2UgOTogInVz ZXMgdGhlIA0KPj4gdmFsdWUgaW4gdGhlIE1UVSBmaWVsZCBpbiB0aGUgUGFja2V0IFRvbyBCaWcg bWVzc2FnZSBhcyBhIHRlbnRhdGl2ZSANCj4+IFBNVFUiIC0+ICJ1c2VzIHRoZSB2YWx1ZSBpbiB0 aGUgTVRVIGZpZWxkIGluIHRoZSBQYWNrZXQgVG9vIEJpZyANCj4+IG1lc3NhZ2UsIG9yIHRoZSBt aW5pbXVtIElQdjYgbmV4dCBob3AgTVRVIGlmIHRoYXQgaXMgbGFyZ2VyLCBhcyBhIA0KPj4gdGVu dGF0aXZlIFBNVFXigJ0NCj4+IA0KPiANCj4gSSBhZ3JlZSwgdGhhbmtzIGZvciBjYXRjaGluZyB0 aGlzLiAgVGhpcyBtYWtlcyBpdCBjb25zaXN0ZW50IHdpdGggdGhlIGVhcmxpZXIgdGV4dCBpbiBT ZWN0aW9uIDQuDQo+IA0KPiANCj4+IFNlY3Rpb24gNS4zLCBQYWdlIDEwLCByaWdodCBhZnRlciB0 aGUgaW5kZW50ZWQgTm90ZTogIm11c3Qgbm90IiAtPiAiTVVTVCBOT1QiDQo+PiANCj4+IFNlY3Rp b24gNS40LCBQYWdlIDEwOiAic2hvdWxkIG5vdCIgLT4gIlNIT1VMRCBOT1QiDQo+PiANCj4+IFNl Y3Rpb24gNS40LCBQYWdlIDExLCAxc3QgcGFyYWdyYXBoOiBFeHBhbmQgIk1TUyIgb24gZmlyc3Qg dXNlOyAibXVzdCANCj4+IG5vdCIgLT4gIk1VU1QgTk9U4oCdDQo+IA0KPiBBZ3JlZSBhYm91dCBN U1MuDQo+IA0KPj4gDQo+PiBTZWN0aW9uIDUuNCwgUGFnZSAxMSwgaW5kZW50ZWQgTm90ZTogaW4g MXN0IHBhcmFncmFwaCAibXVzdCBub3QiIC0+IA0KPj4gIk1VU1QgTk9UIjsgaW4gMm5kIHBhcmFn cmFwaCAibXVzdCIgLT4gIk1VU1QiDQo+PiANCj4+IFNlY3Rpb24gNS41LCBQYWdlIDEyLCAxc3Qg cGFyYWdyYXBoOiAic2hvdWxkIiAtPiAiU0hPVUxEIg0KPj4gDQo+PiBTZWN0aW9uIDUuNSwgUGFn ZSAxMiwgM3JkIHBhcmFncmFwaDogInJlY29tbWVuZGVkIiAtPiAiUkVDT01NRU5ERUQiDQo+PiAN Cj4+IFNlY3Rpb24gNS41LCBQYWdlIDEyLCA0dGggcGFyYWdyYXBoOiBJZiBzb21lIE5GUyBvcGVy YXRpb25zIGNhbm5vdCBiZSANCj4+IGZyYWdtZW50ZWQsICJzaG91bGQgbm90IiAtPiAiTVVTVCBO T1QiDQo+PiANCj4+IEFwcGVuZGl4IEIsIDJuZCBzZW50ZW5jZTogInZlcnNpb24gdGhhdCB0aGUg Y2hhbmdlIHdhcyBtYWRlLjoiIC0+IA0KPj4gInZlcnNpb24gd2hlcmUgdGhlIGNoYW5nZSB3YXMg bWFkZS7igJ0NCj4gDQo+IFRoYW5rcywgd2lsbCBmaXguDQo+IA0KPj4gDQo+PiBUaGFua3MsDQo+ PiBEb25hbGQNCj4+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4+IERvbmFsZCBF LiBFYXN0bGFrZSAzcmQgICArMS01MDgtMzMzLTIyNzAgKGNlbGwpDQo+PiAxNTUgQmVhdmVyIFN0 cmVldCwgTWlsZm9yZCwgTUEgMDE3NTcgVVNBIGQzZTNlM0BnbWFpbC5jb20NCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEludC1kaXIgbWFp bGluZyBsaXN0DQo+IEludC1kaXJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pbnQtZGlyDQoNCg== From nobody Thu Jan 26 12:34:41 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88911129B0A; Thu, 26 Jan 2017 12:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwR9SGv5xJOf; Thu, 26 Jan 2017 12:34:37 -0800 (PST) Received: from mail-it0-x243.google.com (mail-it0-x243.google.com [IPv6:2607:f8b0:4001:c0b::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 288FD129AF9; Thu, 26 Jan 2017 12:34:37 -0800 (PST) Received: by mail-it0-x243.google.com with SMTP id o138so6271597ito.3; Thu, 26 Jan 2017 12:34:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LY2/vZrsZoNo6m02p9fMVjDxSdynIDd7xdOCZoagzE4=; b=s/4zrnT5fAWAbbY1D7qdt7GiTFczshMFhwfsfIpoRxYxm0ikUrg4Qx6gqqq7rJ9855 W9WG5YQmFSRCoUDQgCvYMxIYy895U3/detyFlwepc1eb85GB5BzR4Wg7kRlOaQH6nDsm LM8rNFJWRs9DvsWLVxLvscpj6WuGNCEEMvYaeFpHzjk5bTf7PKN/Xu+ZspFBUengcP75 DJdCfYMsf0PPJTv+T1H37M/asBKh/Wz2d9yagRxtrknxyeGNKtfh8L26rMnPoQLup+K6 QCMnXyhzuuo+qYOe9hFsnS6O1hd65N5BiDopukA+YMb03oXA0jrzbWGAc3rL8Qi17d5o 5vIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LY2/vZrsZoNo6m02p9fMVjDxSdynIDd7xdOCZoagzE4=; b=GCGkOOFicls22CyDXTmvsO48Zb7ikUk9xcqqpNaFYTIjnCtQR4YF6zYcP3vFk+RSps pw9Lup0g70f4maRNfY/bHrLk4l49OvCMbsP7JJXSxXrbwmWVWLzWfm8pGdWqRSNJ7+sh HpJvf2SXQc1/RTpityJlrsHQ5r6kNWlijpovz+9eJAqL6EIXPxa0eswnj11TzHal60d/ nOmdl1b7WkU53sg4wRtb6U3jAfQNnMLeR3BxJMPJbJWP3LnT2nHQ8y21nUfydWr1BO84 Q7S/2F1RjSBwIyAkXqtOPfheG2jNH0PgMnGPy9DSASswS9Sv7MKaG5OzvPYlSiC39Qvg /z5g== X-Gm-Message-State: AIkVDXKcwc0EFTTuSMvyMa36WXFpokV2IfYh2f5/i4Zzu96O8p4snZ9eiZUzYdIUGnlkvQ== X-Received: by 10.36.135.74 with SMTP id f71mr305369ite.101.1485462876432; Thu, 26 Jan 2017 12:34:36 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id p124sm1967403ioe.37.2017.01.26.12.34.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 12:34:35 -0800 (PST) From: Bob Hinden Message-Id: <7F94525A-BECA-4C30-A278-0B7366390087@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_EDF350BE-E239-4FA8-8A27-7B81A75EDE37"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 26 Jan 2017 12:34:33 -0800 In-Reply-To: <70f2f8a012de43a4b35f625837b768b2@XCH-ALN-003.cisco.com> To: "Bernie Volz (volz)" References: <484b4d11bea54ef1b0b0780d3cd1eab8@XCH-ALN-003.cisco.com> <70f2f8a012de43a4b35f625837b768b2@XCH-ALN-003.cisco.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Donald Eastlake , Bob Hinden , "draft-ietf-6man-rfc1981bis.all@ietf.org" , "int-dir@ietf.org" Subject: Re: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 20:34:40 -0000 --Apple-Mail=_EDF350BE-E239-4FA8-8A27-7B81A75EDE37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Great! Thanks, Bob > On Jan 26, 2017, at 12:30 PM, Bernie Volz (volz) = wrote: >=20 > Hi Bob: >=20 > Your note would work well for me. >=20 > Note: This document is an update to RFC1981 that was published prior = to RFC2119 being published. Consequently while it does use = "should/must" style language in upper and lower case, the document does = not cite the RFC2119 definitions. This update does not change that. >=20 > - Bernie >=20 > -----Original Message----- > From: Bob Hinden [mailto:bob.hinden@gmail.com] > Sent: Thursday, January 26, 2017 3:07 PM > To: Bernie Volz (volz) > Cc: Bob Hinden ; Donald Eastlake = ; draft-ietf-6man-rfc1981bis.all@ietf.org; = int-dir@ietf.org > Subject: Re: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review >=20 > Hi Bernie, >=20 > inline >=20 >> On Jan 25, 2017, at 3:15 PM, Bernie Volz (volz) = wrote: >>=20 >> Bob: >>=20 >> While it is great that you know this issue with RFC 2119 key words = ... others reading this document when it becomes an RFC may not know = that (and RFC8xxx or whatever it will be does not predate 2119) and even = if the RFC 2119 reference isn't directly in the document, what will they = assume (I mostly assume if I see MUST in an IETF document, it is a RFC = 2119 key word)? >>=20 >> I would think that at a minimum, adding a note that this document = does NOT make explicitly use of RFC 2119 key words and therefore how a = reader interprets MUST vs must is up to them (presumable MUST is more of = a must than the lower case version). >=20 > I don=E2=80=99t object to a note. However, RFC2119 does not require = upper case, so making statements about the precedence of upper vs. lower = case it=E2=80=99s warranted. >=20 > How about something like this: >=20 > Note: This document is an update to RFC1981 that was published prior = to RFC2119 being published. Consequently while it does use = "should/must" style language in upper and lower case, the document does = not cite the RFC2119 definitions. This update does not change that. >=20 > I guess this means I will have to add a reference to RFC2119 :-) >=20 >>=20 >> I think it might also be possible to argue that 2119 might have been = on the horizon at the time and as it did not yet exist ... 02 of the = 2119 draft (oldest available at tools.ietf.org) was published in August = 1996 which is the same month in which 1981 was published. So seems = likely that there is some influence from that work here? >>=20 >> I guess one conclusion is that even if not explicitly indicated, the = assumption that they are (in the spirit of) 2119 key words is likely = correct. >=20 > I suspect that is true. The reason why we didn=E2=80=99t cite RFC2119 = in rfc1981bis, is that RFC1981 is very widely implemented using the = current language, and starting to change the =E2=80=9Cmust/should/etc.=E2=80= =9D to upper case, will likely cause some to think that this document is = intended to change implementation behaviour. That was not the intent of = the w.g. The changes in the bis document are very limited. >=20 > Thanks, > Bob >=20 >>=20 >> - Bernie >>=20 >> -----Original Message----- >> From: Int-dir [mailto:int-dir-bounces@ietf.org] On Behalf Of Bob >> Hinden >> Sent: Wednesday, January 25, 2017 5:43 PM >> To: Donald Eastlake >> Cc: Bob Hinden ; >> draft-ietf-6man-rfc1981bis.all@ietf.org; int-dir@ietf.org >> Subject: Re: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review >>=20 >> Donald, >>=20 >> Thanks for your comments! >>=20 >> To set the background this, this is part of 6MAN work to advance the = core IPv6 specs from Draft Standard to Internet Standard. As part of = this, we were only trying to change things that where there were RFCs = that updated it, errata, and to make it consistent with the other RFCs = being advanced (for example rfc2460bis and rfc4291bis). We were trying = to change as little as possible. >>=20 >> That why we kept the must/should language intact and did not include = a reference to RFC2119. RFC1981 was, of course, written before RFC2119. = It uses a mix of upper and lower case words, I am am reluctant to try = to change that. This is also consistent with how the w.g. handled this = issue with rfc2460bis and rfc4291bis. >>=20 >> Comments inline below. >>=20 >> Bob >>=20 >>=20 >>> On Jan 25, 2017, at 1:24 PM, Donald Eastlake = wrote: >>>=20 >>> I am an assigned INT directorate reviewer for >>> draft-ietf-6man-rfc1981bis-03.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. >>>=20 >>> This document appears to be Ready with Nits. >>>=20 >>>=20 >>> Add RFC 2119 to Reference and add corresponding boilerplate, = probably >>> to the Terminology section. >>=20 >> See note above. >>=20 >>>=20 >>> Section 4, Page 6, next to last paragraph of Section 4: "should" -> = =E2=80=9CSHOULD" >>=20 >> ditto >>=20 >>>=20 >>> Section 5.1, Page 7, 2nd sentence of next to last paragraph of >>> Section >>> 5.1: delete superfluous comma >>=20 >> Thanks, will fix. >>=20 >>>=20 >>> Section 5.2, Page 7: just a wording suggestion: "must in fact >>> represent" -> =E2=80=9Crepresents" >>=20 >> Makes sense to me, I will change. >>=20 >>>=20 >>> Section 5.2, Page 8: The indented Note about "security >>> classifications" strikes me as probably an archaism left over from >>> when it was the "US Department of Defense Internet". I suggest >>> replacing "security classifications" with "quality of service >>> markings" or the like. Security seems like one "quality" of service >>> so I believe the new wording I am suggesting is a superset of the = old. >>=20 >> While I tend to agree with you, I think this is a change we don=E2=80=99= t have very much justification to make. >>=20 >>>=20 >>> Section 5.2, Page 9: I am not entirely comfortable that earlier in >>> the document it says that a Packet Too Big reporting a next hop MTU >>> less than the IPv6 minimum link MTU should be discarded and that a >>> node MUST NOT reduce its estimate of the Path MTU below the IPv6 >>> minimum link MTU but in the top paragraph on page 9 it talks in an >>> unrestricted way about reducing the PMTU based on Packet Too Big >>> message next hop size. I suggest, at the top of page 9: "uses the >>> value in the MTU field in the Packet Too Big message as a tentative >>> PMTU" -> "uses the value in the MTU field in the Packet Too Big >>> message, or the minimum IPv6 next hop MTU if that is larger, as a >>> tentative PMTU=E2=80=9D >>>=20 >>=20 >> I agree, thanks for catching this. This makes it consistent with the = earlier text in Section 4. >>=20 >>=20 >>> Section 5.3, Page 10, right after the indented Note: "must not" -> = "MUST NOT" >>>=20 >>> Section 5.4, Page 10: "should not" -> "SHOULD NOT" >>>=20 >>> Section 5.4, Page 11, 1st paragraph: Expand "MSS" on first use; = "must >>> not" -> "MUST NOT=E2=80=9D >>=20 >> Agree about MSS. >>=20 >>>=20 >>> Section 5.4, Page 11, indented Note: in 1st paragraph "must not" -> >>> "MUST NOT"; in 2nd paragraph "must" -> "MUST" >>>=20 >>> Section 5.5, Page 12, 1st paragraph: "should" -> "SHOULD" >>>=20 >>> Section 5.5, Page 12, 3rd paragraph: "recommended" -> "RECOMMENDED" >>>=20 >>> Section 5.5, Page 12, 4th paragraph: If some NFS operations cannot = be >>> fragmented, "should not" -> "MUST NOT" >>>=20 >>> Appendix B, 2nd sentence: "version that the change was made.:" -> >>> "version where the change was made.=E2=80=9D >>=20 >> Thanks, will fix. >>=20 >>>=20 >>> Thanks, >>> Donald >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >>=20 >> _______________________________________________ >> Int-dir mailing list >> Int-dir@ietf.org >> https://www.ietf.org/mailman/listinfo/int-dir >=20 --Apple-Mail=_EDF350BE-E239-4FA8-8A27-7B81A75EDE37 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYil1aAAoJEK7rdBF357uoLm4H/AufDu6OLJok+5BzbrJv/4hX wIEPA9F8doPOYhiKuhczC+8X7tYT1FvttoTemZajBFP1kb1Vln7UCgQBPAypg0J6 9M8jx6nEaMVv2dftFMghjYYRcBVnsSZjFp+3GVDuz2kZa3NZlplvFsXwHakcuMPX aOEagTJEk3KTVNcxxxiG4IL4S0HjWuONOrOry6vRPPlzWy5cucfwNFEUilEI+TcD ZRnl50QXxWjy9yTyyaigX5WMruCX9z7aWO1q1PaKWO2K7I2ppm/uw5biVhgd9uDV JEMgt3de+am5T6NJU1fYzYnM6CUOy2ma2OSe6WeEJgknq12l5ibW3etgRkA4xlw= =lijK -----END PGP SIGNATURE----- --Apple-Mail=_EDF350BE-E239-4FA8-8A27-7B81A75EDE37-- From nobody Thu Jan 26 14:16:44 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F67129C0B; Thu, 26 Jan 2017 14:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 nEtPtVunXlnY; Thu, 26 Jan 2017 14:16:41 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 D7E82129C04; Thu, 26 Jan 2017 14:16:40 -0800 (PST) X-AuditID: c6180641-e87ff70000000a0b-88-588a20d94eff Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by (Symantec Mail Security) with SMTP id 5A.71.02571.9D02A885; Thu, 26 Jan 2017 17:16:28 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0319.002; Thu, 26 Jan 2017 17:16:37 -0500 From: Suresh Krishnan To: Robert Hinden Thread-Topic: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review Thread-Index: AQHSd1Fza1cDUaJ5ZkeX1kCreqnQzKFKHdOAgAAJOgCAAV2IAIAABsEAgAABDICAAByDAA== Date: Thu, 26 Jan 2017 22:16:36 +0000 Message-ID: <5F93D303-B95A-4EF7-8F65-2E1FC9632C80@ericsson.com> References: <484b4d11bea54ef1b0b0780d3cd1eab8@XCH-ALN-003.cisco.com> <70f2f8a012de43a4b35f625837b768b2@XCH-ALN-003.cisco.com> <7F94525A-BECA-4C30-A278-0B7366390087@gmail.com> In-Reply-To: <7F94525A-BECA-4C30-A278-0B7366390087@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyuXRPoO4dha4Ig2sdYhZb3+9jszi4XdPi 2NrXLBaPrnSzWCyfoenA6jHl90ZWj52z7rJ7LFnykymAOYrLJiU1J7MstUjfLoEr4/DryYwF W2Ir5tw6ytbA2BDdxcjJISFgIrFs1Uq2LkYuDiGB9YwS779eZIJwljNKNN5azwpSxQZUtWHn ZyYQW0RAQ+LnnyOMIEXMAscYJWb1P2QESQgLOEnMb4MpcpZ4uG8yO4QdJvFqwyYwm0VAVWJa QyvQUA4OXgF7iUNTgyGW3WeS+HjsOAtIDaeArcTXG8fZQGxGATGJ76fWgM1kFhCXuPVkPhPE 2QISS/acZ4awRSVePv7HCmErScx5fY0ZZD6zgKbE+l36EKa1xOJ7YhBTFCWmdD8Eu4ZXQFDi 5MwnLBMYxWYhWTALoXkWQvMsJM2zkDQvYGRdxchRWlyQk5tuZLiJERhdxyTYHHcw7u31PMQo wMGoxMO74VpnhBBrYllxZe4hRgkOZiUR3jbFrggh3pTEyqrUovz4otKc1OJDjNIcLErivNdD 7ocLCaQnlqRmp6YWpBbBZJk4OKUaGOtv/nL/WnNQMcHto4v4yu9Je/g/ZnM4HVRuddpof8Yp 8r7mSu6IxGurtsRfNPodf55JhrXzGSOzyaGnzrd+CIZ2vY/axWzCmD3NuVmnhOHHlr1LP1W/ fy2/u8U+o8FYOC076c7V2V7mrJ4/pocnd5usnWg1x6vhWOqPlYUKQat4Un9vPDYnVYmlOCPR UIu5qDgRABReLzaqAgAA Archived-At: Cc: Donald Eastlake , Bernie Volz , "draft-ietf-6man-rfc1981bis.all@ietf.org" , "int-dir@ietf.org" Subject: Re: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 22:16:43 -0000 SGkgQm9iLA0KDQo+IE9uIEphbiAyNiwgMjAxNywgYXQgMzozNCBQTSwgQm9iIEhpbmRlbiA8Ym9i LmhpbmRlbkBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gR3JlYXQhDQoNCkEgbm90ZSBpbiB0aGUg c2hlcGhlcmQgd3JpdGV1cCB3b3VsZCBoYXZlIHdvcmtlZCBmb3IgbWUgYXMgd2VsbC4gVGhlIG9u ZSBjb25jZXJuIEkgaGF2ZSBpcyB0aGF0IGlmIHN1Y2ggdGV4dCBpcyBhZGRlZCB0byB0aGlzIGRv Y3VtZW50LCBzaG91bGQgaXQgYmUgYWRkZWQgdG8gMjQ2MGJpcyBhcyB3ZWxsPyANCg0KVGhhbmtz DQpTdXJlc2gNCg0KPiANCj4gVGhhbmtzLA0KPiBCb2INCj4gDQo+PiBPbiBKYW4gMjYsIDIwMTcs IGF0IDEyOjMwIFBNLCBCZXJuaWUgVm9seiAodm9seikgPHZvbHpAY2lzY28uY29tPiB3cm90ZToN Cj4+IA0KPj4gSGkgQm9iOg0KPj4gDQo+PiBZb3VyIG5vdGUgd291bGQgd29yayB3ZWxsIGZvciBt ZS4NCj4+IA0KPj4gTm90ZTogIFRoaXMgZG9jdW1lbnQgaXMgYW4gdXBkYXRlIHRvIFJGQzE5ODEg dGhhdCB3YXMgcHVibGlzaGVkIHByaW9yIHRvIFJGQzIxMTkgYmVpbmcgcHVibGlzaGVkLiAgQ29u c2VxdWVudGx5IHdoaWxlIGl0IGRvZXMgdXNlICJzaG91bGQvbXVzdCIgc3R5bGUgbGFuZ3VhZ2Ug aW4gdXBwZXIgYW5kIGxvd2VyIGNhc2UsIHRoZSBkb2N1bWVudCBkb2VzIG5vdCBjaXRlIHRoZSBS RkMyMTE5IGRlZmluaXRpb25zLiAgVGhpcyB1cGRhdGUgZG9lcyBub3QgY2hhbmdlIHRoYXQuDQo+ PiANCj4+IC0gQmVybmllDQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBG cm9tOiBCb2IgSGluZGVuIFttYWlsdG86Ym9iLmhpbmRlbkBnbWFpbC5jb21dDQo+PiBTZW50OiBU aHVyc2RheSwgSmFudWFyeSAyNiwgMjAxNyAzOjA3IFBNDQo+PiBUbzogQmVybmllIFZvbHogKHZv bHopIDx2b2x6QGNpc2NvLmNvbT4NCj4+IENjOiBCb2IgSGluZGVuIDxib2IuaGluZGVuQGdtYWls LmNvbT47IERvbmFsZCBFYXN0bGFrZSA8ZDNlM2UzQGdtYWlsLmNvbT47IGRyYWZ0LWlldGYtNm1h bi1yZmMxOTgxYmlzLmFsbEBpZXRmLm9yZzsgaW50LWRpckBpZXRmLm9yZw0KPj4gU3ViamVjdDog UmU6IFtJbnQtZGlyXSBkcmFmdC1pZXRmLTZtYW4tcmZjMTk4MWJpcy0wMyBJTlRESVIgcmV2aWV3 DQo+PiANCj4+IEhpIEJlcm5pZSwNCj4+IA0KPj4gaW5saW5lDQo+PiANCj4+PiBPbiBKYW4gMjUs IDIwMTcsIGF0IDM6MTUgUE0sIEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb20+IHdy b3RlOg0KPj4+IA0KPj4+IEJvYjoNCj4+PiANCj4+PiBXaGlsZSBpdCBpcyBncmVhdCB0aGF0IHlv dSBrbm93IHRoaXMgaXNzdWUgd2l0aCBSRkMgMjExOSBrZXkgd29yZHMgLi4uIG90aGVycyByZWFk aW5nIHRoaXMgZG9jdW1lbnQgd2hlbiBpdCBiZWNvbWVzIGFuIFJGQyBtYXkgbm90IGtub3cgdGhh dCAoYW5kIFJGQzh4eHggb3Igd2hhdGV2ZXIgaXQgd2lsbCBiZSBkb2VzIG5vdCBwcmVkYXRlIDIx MTkpIGFuZCBldmVuIGlmIHRoZSBSRkMgMjExOSByZWZlcmVuY2UgaXNuJ3QgZGlyZWN0bHkgaW4g dGhlIGRvY3VtZW50LCB3aGF0IHdpbGwgdGhleSBhc3N1bWUgKEkgbW9zdGx5IGFzc3VtZSBpZiBJ IHNlZSBNVVNUIGluIGFuIElFVEYgZG9jdW1lbnQsIGl0IGlzIGEgUkZDIDIxMTkga2V5IHdvcmQp Pw0KPj4+IA0KPj4+IEkgd291bGQgdGhpbmsgdGhhdCBhdCBhIG1pbmltdW0sIGFkZGluZyBhIG5v dGUgdGhhdCB0aGlzIGRvY3VtZW50IGRvZXMgTk9UIG1ha2UgZXhwbGljaXRseSB1c2Ugb2YgUkZD IDIxMTkga2V5IHdvcmRzIGFuZCB0aGVyZWZvcmUgaG93IGEgcmVhZGVyIGludGVycHJldHMgTVVT VCB2cyBtdXN0IGlzIHVwIHRvIHRoZW0gKHByZXN1bWFibGUgTVVTVCBpcyBtb3JlIG9mIGEgbXVz dCB0aGFuIHRoZSBsb3dlciBjYXNlIHZlcnNpb24pLg0KPj4gDQo+PiBJIGRvbuKAmXQgb2JqZWN0 IHRvIGEgbm90ZS4gIEhvd2V2ZXIsIFJGQzIxMTkgZG9lcyBub3QgcmVxdWlyZSB1cHBlciBjYXNl LCBzbyBtYWtpbmcgc3RhdGVtZW50cyBhYm91dCB0aGUgcHJlY2VkZW5jZSBvZiB1cHBlciB2cy4g bG93ZXIgY2FzZSBpdOKAmXMgd2FycmFudGVkLg0KPj4gDQo+PiBIb3cgYWJvdXQgc29tZXRoaW5n IGxpa2UgdGhpczoNCj4+IA0KPj4gTm90ZTogIFRoaXMgZG9jdW1lbnQgaXMgYW4gdXBkYXRlIHRv IFJGQzE5ODEgdGhhdCB3YXMgcHVibGlzaGVkIHByaW9yIHRvIFJGQzIxMTkgYmVpbmcgcHVibGlz aGVkLiAgQ29uc2VxdWVudGx5IHdoaWxlIGl0IGRvZXMgdXNlICJzaG91bGQvbXVzdCIgc3R5bGUg bGFuZ3VhZ2UgaW4gdXBwZXIgYW5kIGxvd2VyIGNhc2UsIHRoZSBkb2N1bWVudCBkb2VzIG5vdCBj aXRlIHRoZSBSRkMyMTE5IGRlZmluaXRpb25zLiAgVGhpcyB1cGRhdGUgZG9lcyBub3QgY2hhbmdl IHRoYXQuDQo+PiANCj4+IEkgZ3Vlc3MgdGhpcyBtZWFucyBJIHdpbGwgaGF2ZSB0byBhZGQgYSBy ZWZlcmVuY2UgdG8gUkZDMjExOSA6LSkNCj4+IA0KPj4+IA0KPj4+IEkgdGhpbmsgaXQgbWlnaHQg YWxzbyBiZSBwb3NzaWJsZSB0byBhcmd1ZSB0aGF0IDIxMTkgbWlnaHQgaGF2ZSBiZWVuIG9uIHRo ZSBob3Jpem9uIGF0IHRoZSB0aW1lIGFuZCBhcyBpdCBkaWQgbm90IHlldCBleGlzdCAuLi4gMDIg b2YgdGhlIDIxMTkgZHJhZnQgKG9sZGVzdCBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcpIHdh cyBwdWJsaXNoZWQgaW4gQXVndXN0IDE5OTYgd2hpY2ggaXMgdGhlIHNhbWUgbW9udGggaW4gd2hp Y2ggMTk4MSB3YXMgcHVibGlzaGVkLiBTbyBzZWVtcyBsaWtlbHkgdGhhdCB0aGVyZSBpcyBzb21l IGluZmx1ZW5jZSBmcm9tIHRoYXQgd29yayBoZXJlPw0KPj4+IA0KPj4+IEkgZ3Vlc3Mgb25lIGNv bmNsdXNpb24gaXMgdGhhdCBldmVuIGlmIG5vdCBleHBsaWNpdGx5IGluZGljYXRlZCwgdGhlIGFz c3VtcHRpb24gdGhhdCB0aGV5IGFyZSAoaW4gdGhlIHNwaXJpdCBvZikgMjExOSBrZXkgd29yZHMg aXMgbGlrZWx5IGNvcnJlY3QuDQo+PiANCj4+IEkgc3VzcGVjdCB0aGF0IGlzIHRydWUuICBUaGUg cmVhc29uIHdoeSB3ZSBkaWRu4oCZdCBjaXRlIFJGQzIxMTkgaW4gcmZjMTk4MWJpcywgaXMgdGhh dCBSRkMxOTgxIGlzIHZlcnkgd2lkZWx5IGltcGxlbWVudGVkIHVzaW5nIHRoZSBjdXJyZW50IGxh bmd1YWdlLCBhbmQgc3RhcnRpbmcgdG8gY2hhbmdlIHRoZSDigJxtdXN0L3Nob3VsZC9ldGMu4oCd IHRvIHVwcGVyIGNhc2UsIHdpbGwgbGlrZWx5IGNhdXNlIHNvbWUgdG8gdGhpbmsgdGhhdCB0aGlz IGRvY3VtZW50IGlzIGludGVuZGVkIHRvIGNoYW5nZSBpbXBsZW1lbnRhdGlvbiBiZWhhdmlvdXIu ICBUaGF0IHdhcyBub3QgdGhlIGludGVudCBvZiB0aGUgdy5nLiAgVGhlIGNoYW5nZXMgaW4gdGhl IGJpcyBkb2N1bWVudCBhcmUgdmVyeSBsaW1pdGVkLg0KPj4gDQo+PiBUaGFua3MsDQo+PiBCb2IN Cj4+IA0KPj4+IA0KPj4+IC0gQmVybmllDQo+Pj4gDQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+PiBGcm9tOiBJbnQtZGlyIFttYWlsdG86aW50LWRpci1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQm9iDQo+Pj4gSGluZGVuDQo+Pj4gU2VudDogV2VkbmVzZGF5LCBKYW51 YXJ5IDI1LCAyMDE3IDU6NDMgUE0NCj4+PiBUbzogRG9uYWxkIEVhc3RsYWtlIDxkM2UzZTNAZ21h aWwuY29tPg0KPj4+IENjOiBCb2IgSGluZGVuIDxib2IuaGluZGVuQGdtYWlsLmNvbT47DQo+Pj4g ZHJhZnQtaWV0Zi02bWFuLXJmYzE5ODFiaXMuYWxsQGlldGYub3JnOyBpbnQtZGlyQGlldGYub3Jn DQo+Pj4gU3ViamVjdDogUmU6IFtJbnQtZGlyXSBkcmFmdC1pZXRmLTZtYW4tcmZjMTk4MWJpcy0w MyBJTlRESVIgcmV2aWV3DQo+Pj4gDQo+Pj4gRG9uYWxkLA0KPj4+IA0KPj4+IFRoYW5rcyBmb3Ig eW91ciBjb21tZW50cyENCj4+PiANCj4+PiBUbyBzZXQgdGhlIGJhY2tncm91bmQgdGhpcywgdGhp cyBpcyBwYXJ0IG9mIDZNQU4gd29yayB0byBhZHZhbmNlIHRoZSBjb3JlIElQdjYgc3BlY3MgZnJv bSBEcmFmdCBTdGFuZGFyZCB0byBJbnRlcm5ldCBTdGFuZGFyZC4gIEFzIHBhcnQgb2YgdGhpcywg d2Ugd2VyZSBvbmx5IHRyeWluZyB0byBjaGFuZ2UgdGhpbmdzIHRoYXQgd2hlcmUgdGhlcmUgd2Vy ZSBSRkNzIHRoYXQgdXBkYXRlZCBpdCwgZXJyYXRhLCBhbmQgdG8gbWFrZSBpdCBjb25zaXN0ZW50 IHdpdGggdGhlIG90aGVyIFJGQ3MgYmVpbmcgYWR2YW5jZWQgKGZvciBleGFtcGxlIHJmYzI0NjBi aXMgYW5kIHJmYzQyOTFiaXMpLiBXZSB3ZXJlIHRyeWluZyB0byBjaGFuZ2UgYXMgbGl0dGxlIGFz IHBvc3NpYmxlLg0KPj4+IA0KPj4+IFRoYXQgd2h5IHdlIGtlcHQgdGhlIG11c3Qvc2hvdWxkIGxh bmd1YWdlIGludGFjdCBhbmQgZGlkIG5vdCBpbmNsdWRlIGEgcmVmZXJlbmNlIHRvIFJGQzIxMTku ICBSRkMxOTgxIHdhcywgb2YgY291cnNlLCB3cml0dGVuIGJlZm9yZSBSRkMyMTE5LiAgSXQgdXNl cyBhIG1peCBvZiB1cHBlciBhbmQgbG93ZXIgY2FzZSB3b3JkcywgSSBhbSBhbSByZWx1Y3RhbnQg dG8gdHJ5IHRvIGNoYW5nZSB0aGF0LiAgIFRoaXMgaXMgYWxzbyBjb25zaXN0ZW50IHdpdGggaG93 IHRoZSB3LmcuIGhhbmRsZWQgdGhpcyBpc3N1ZSB3aXRoIHJmYzI0NjBiaXMgYW5kIHJmYzQyOTFi aXMuDQo+Pj4gDQo+Pj4gQ29tbWVudHMgaW5saW5lIGJlbG93Lg0KPj4+IA0KPj4+IEJvYg0KPj4+ IA0KPj4+IA0KPj4+PiBPbiBKYW4gMjUsIDIwMTcsIGF0IDE6MjQgUE0sIERvbmFsZCBFYXN0bGFr ZSA8ZDNlM2UzQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBJIGFtIGFuIGFzc2lnbmVk IElOVCBkaXJlY3RvcmF0ZSByZXZpZXdlciBmb3INCj4+Pj4gZHJhZnQtaWV0Zi02bWFuLXJmYzE5 ODFiaXMtMDMudHh0LiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4NCj4+Pj4gcHJpbWFyaWx5 IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgSW50ZXJuZXQgQXJlYSBEaXJlY3RvcnMuIERvY3VtZW50 DQo+Pj4+IGVkaXRvcnMgYW5kIHNoZXBoZXJkKHMpIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50 cyBqdXN0IGxpa2UgdGhleQ0KPj4+PiB3b3VsZCB0cmVhdCBjb21tZW50cyBmcm9tIGFueSBvdGhl ciBJRVRGIGNvbnRyaWJ1dG9ycyBhbmQgcmVzb2x2ZQ0KPj4+PiB0aGVtIGFsb25nIHdpdGggYW55 IG90aGVyIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IGhhdmUgYmVlbiByZWNlaXZlZC4NCj4+Pj4g Rm9yIG1vcmUgZGV0YWlscyBvbiB0aGUgSU5UIERpcmVjdG9yYXRlLCBzZWUNCj4+Pj4gaHR0cDov L3d3dy5pZXRmLm9yZy9pZXNnL2RpcmVjdG9yYXRlLmh0bWwuDQo+Pj4+IA0KPj4+PiBUaGlzIGRv Y3VtZW50IGFwcGVhcnMgdG8gYmUgUmVhZHkgd2l0aCBOaXRzLg0KPj4+PiANCj4+Pj4gDQo+Pj4+ IEFkZCBSRkMgMjExOSB0byBSZWZlcmVuY2UgYW5kIGFkZCBjb3JyZXNwb25kaW5nIGJvaWxlcnBs YXRlLCBwcm9iYWJseQ0KPj4+PiB0byB0aGUgVGVybWlub2xvZ3kgc2VjdGlvbi4NCj4+PiANCj4+ PiBTZWUgbm90ZSBhYm92ZS4NCj4+PiANCj4+Pj4gDQo+Pj4+IFNlY3Rpb24gNCwgUGFnZSA2LCBu ZXh0IHRvIGxhc3QgcGFyYWdyYXBoIG9mIFNlY3Rpb24gNDogInNob3VsZCIgLT4g4oCcU0hPVUxE Ig0KPj4+IA0KPj4+IGRpdHRvDQo+Pj4gDQo+Pj4+IA0KPj4+PiBTZWN0aW9uIDUuMSwgUGFnZSA3 LCAybmQgc2VudGVuY2Ugb2YgbmV4dCB0byBsYXN0IHBhcmFncmFwaCBvZg0KPj4+PiBTZWN0aW9u DQo+Pj4+IDUuMTogZGVsZXRlIHN1cGVyZmx1b3VzIGNvbW1hDQo+Pj4gDQo+Pj4gVGhhbmtzLCB3 aWxsIGZpeC4NCj4+PiANCj4+Pj4gDQo+Pj4+IFNlY3Rpb24gNS4yLCBQYWdlIDc6IGp1c3QgYSB3 b3JkaW5nIHN1Z2dlc3Rpb246ICJtdXN0IGluIGZhY3QNCj4+Pj4gcmVwcmVzZW50IiAtPiDigJxy ZXByZXNlbnRzIg0KPj4+IA0KPj4+IE1ha2VzIHNlbnNlIHRvIG1lLCBJIHdpbGwgY2hhbmdlLg0K Pj4+IA0KPj4+PiANCj4+Pj4gU2VjdGlvbiA1LjIsIFBhZ2UgODogVGhlIGluZGVudGVkIE5vdGUg YWJvdXQgInNlY3VyaXR5DQo+Pj4+IGNsYXNzaWZpY2F0aW9ucyIgc3RyaWtlcyBtZSBhcyBwcm9i YWJseSBhbiBhcmNoYWlzbSBsZWZ0IG92ZXIgZnJvbQ0KPj4+PiB3aGVuIGl0IHdhcyB0aGUgIlVT IERlcGFydG1lbnQgb2YgRGVmZW5zZSBJbnRlcm5ldCIuIEkgc3VnZ2VzdA0KPj4+PiByZXBsYWNp bmcgInNlY3VyaXR5IGNsYXNzaWZpY2F0aW9ucyIgd2l0aCAicXVhbGl0eSBvZiBzZXJ2aWNlDQo+ Pj4+IG1hcmtpbmdzIiBvciB0aGUgbGlrZS4gU2VjdXJpdHkgc2VlbXMgbGlrZSBvbmUgInF1YWxp dHkiIG9mIHNlcnZpY2UNCj4+Pj4gc28gSSBiZWxpZXZlIHRoZSBuZXcgd29yZGluZyBJIGFtIHN1 Z2dlc3RpbmcgaXMgYSBzdXBlcnNldCBvZiB0aGUgb2xkLg0KPj4+IA0KPj4+IFdoaWxlIEkgdGVu ZCB0byBhZ3JlZSB3aXRoIHlvdSwgSSB0aGluayB0aGlzIGlzIGEgY2hhbmdlIHdlIGRvbuKAmXQg aGF2ZSB2ZXJ5IG11Y2gganVzdGlmaWNhdGlvbiB0byBtYWtlLg0KPj4+IA0KPj4+PiANCj4+Pj4g U2VjdGlvbiA1LjIsIFBhZ2UgOTogSSBhbSBub3QgZW50aXJlbHkgY29tZm9ydGFibGUgdGhhdCBl YXJsaWVyIGluDQo+Pj4+IHRoZSBkb2N1bWVudCBpdCBzYXlzIHRoYXQgYSBQYWNrZXQgVG9vIEJp ZyByZXBvcnRpbmcgYSBuZXh0IGhvcCBNVFUNCj4+Pj4gbGVzcyB0aGFuIHRoZSBJUHY2IG1pbmlt dW0gbGluayBNVFUgc2hvdWxkIGJlIGRpc2NhcmRlZCBhbmQgdGhhdCBhDQo+Pj4+IG5vZGUgTVVT VCBOT1QgcmVkdWNlIGl0cyBlc3RpbWF0ZSBvZiB0aGUgUGF0aCBNVFUgYmVsb3cgdGhlIElQdjYN Cj4+Pj4gbWluaW11bSBsaW5rIE1UVSBidXQgaW4gdGhlIHRvcCBwYXJhZ3JhcGggb24gcGFnZSA5 IGl0IHRhbGtzIGluIGFuDQo+Pj4+IHVucmVzdHJpY3RlZCB3YXkgYWJvdXQgcmVkdWNpbmcgdGhl IFBNVFUgYmFzZWQgb24gUGFja2V0IFRvbyBCaWcNCj4+Pj4gbWVzc2FnZSBuZXh0IGhvcCBzaXpl LiBJIHN1Z2dlc3QsIGF0IHRoZSB0b3Agb2YgcGFnZSA5OiAidXNlcyB0aGUNCj4+Pj4gdmFsdWUg aW4gdGhlIE1UVSBmaWVsZCBpbiB0aGUgUGFja2V0IFRvbyBCaWcgbWVzc2FnZSBhcyBhIHRlbnRh dGl2ZQ0KPj4+PiBQTVRVIiAtPiAidXNlcyB0aGUgdmFsdWUgaW4gdGhlIE1UVSBmaWVsZCBpbiB0 aGUgUGFja2V0IFRvbyBCaWcNCj4+Pj4gbWVzc2FnZSwgb3IgdGhlIG1pbmltdW0gSVB2NiBuZXh0 IGhvcCBNVFUgaWYgdGhhdCBpcyBsYXJnZXIsIGFzIGENCj4+Pj4gdGVudGF0aXZlIFBNVFXigJ0N Cj4+Pj4gDQo+Pj4gDQo+Pj4gSSBhZ3JlZSwgdGhhbmtzIGZvciBjYXRjaGluZyB0aGlzLiAgVGhp cyBtYWtlcyBpdCBjb25zaXN0ZW50IHdpdGggdGhlIGVhcmxpZXIgdGV4dCBpbiBTZWN0aW9uIDQu DQo+Pj4gDQo+Pj4gDQo+Pj4+IFNlY3Rpb24gNS4zLCBQYWdlIDEwLCByaWdodCBhZnRlciB0aGUg aW5kZW50ZWQgTm90ZTogIm11c3Qgbm90IiAtPiAiTVVTVCBOT1QiDQo+Pj4+IA0KPj4+PiBTZWN0 aW9uIDUuNCwgUGFnZSAxMDogInNob3VsZCBub3QiIC0+ICJTSE9VTEQgTk9UIg0KPj4+PiANCj4+ Pj4gU2VjdGlvbiA1LjQsIFBhZ2UgMTEsIDFzdCBwYXJhZ3JhcGg6IEV4cGFuZCAiTVNTIiBvbiBm aXJzdCB1c2U7ICJtdXN0DQo+Pj4+IG5vdCIgLT4gIk1VU1QgTk9U4oCdDQo+Pj4gDQo+Pj4gQWdy ZWUgYWJvdXQgTVNTLg0KPj4+IA0KPj4+PiANCj4+Pj4gU2VjdGlvbiA1LjQsIFBhZ2UgMTEsIGlu ZGVudGVkIE5vdGU6IGluIDFzdCBwYXJhZ3JhcGggIm11c3Qgbm90IiAtPg0KPj4+PiAiTVVTVCBO T1QiOyBpbiAybmQgcGFyYWdyYXBoICJtdXN0IiAtPiAiTVVTVCINCj4+Pj4gDQo+Pj4+IFNlY3Rp b24gNS41LCBQYWdlIDEyLCAxc3QgcGFyYWdyYXBoOiAic2hvdWxkIiAtPiAiU0hPVUxEIg0KPj4+ PiANCj4+Pj4gU2VjdGlvbiA1LjUsIFBhZ2UgMTIsIDNyZCBwYXJhZ3JhcGg6ICJyZWNvbW1lbmRl ZCIgLT4gIlJFQ09NTUVOREVEIg0KPj4+PiANCj4+Pj4gU2VjdGlvbiA1LjUsIFBhZ2UgMTIsIDR0 aCBwYXJhZ3JhcGg6IElmIHNvbWUgTkZTIG9wZXJhdGlvbnMgY2Fubm90IGJlDQo+Pj4+IGZyYWdt ZW50ZWQsICJzaG91bGQgbm90IiAtPiAiTVVTVCBOT1QiDQo+Pj4+IA0KPj4+PiBBcHBlbmRpeCBC LCAybmQgc2VudGVuY2U6ICJ2ZXJzaW9uIHRoYXQgdGhlIGNoYW5nZSB3YXMgbWFkZS46IiAtPg0K Pj4+PiAidmVyc2lvbiB3aGVyZSB0aGUgY2hhbmdlIHdhcyBtYWRlLuKAnQ0KPj4+IA0KPj4+IFRo YW5rcywgd2lsbCBmaXguDQo+Pj4gDQo+Pj4+IA0KPj4+PiBUaGFua3MsDQo+Pj4+IERvbmFsZA0K Pj4+PiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+Pj4+IERvbmFsZCBFLiBFYXN0 bGFrZSAzcmQgICArMS01MDgtMzMzLTIyNzAgKGNlbGwpDQo+Pj4+IDE1NSBCZWF2ZXIgU3RyZWV0 LCBNaWxmb3JkLCBNQSAwMTc1NyBVU0EgZDNlM2UzQGdtYWlsLmNvbQ0KPj4+IA0KPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gSW50LWRpciBt YWlsaW5nIGxpc3QNCj4+PiBJbnQtZGlyQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pbnQtZGlyDQo+PiANCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEludC1kaXIgbWFpbGluZyBsaXN0DQo+ IEludC1kaXJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pbnQtZGlyDQoNCg== From nobody Thu Jan 26 14:53:47 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A059129C48; Thu, 26 Jan 2017 14:53:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJAhutFmkc9T; Thu, 26 Jan 2017 14:53:43 -0800 (PST) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (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 14577129C4B; Thu, 26 Jan 2017 14:53:42 -0800 (PST) Received: by mail-it0-x241.google.com with SMTP id o185so6636097itb.1; Thu, 26 Jan 2017 14:53:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jOg556hSynp+XO6/c7iJVhaIJCy1V0InVXdQCb75esE=; b=QowVdFPfabeuPG5R8W2mtcYKMCgczwG+5CHKORZJKSiBNgxsp2AHrMbc/5BownsfKH W5UzE4LN0mVkZ1GEIfe4M+ZCE8YMQB4trFNYw3kQe3reWvmVpsoVXckyN1RrWM0fjUlq fvFhPhtiqO2buim9EvbGXT0JLR3AXvc8bE6RbPLQFcA934zKRvJg3+RopyQKFGY76BS3 YPgko+NC2GX7P72mAJx8kBpzPJ7osB1p8M8zlQk3nNMDXfpf3khAZwh0vUP8SFngYEI0 kzmUq304bJXEnNa8KyPb8ITxnQURMeV9dt647jco0SHza5MTsZ/HQJGRwhlY+h6eOyJG FvIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=jOg556hSynp+XO6/c7iJVhaIJCy1V0InVXdQCb75esE=; b=UcricjuPJsHBZwrATnE8xCpIt35Mva1MWUZugXUygxiwggSqlBuKdKoMBIZta/9/zQ ledvJrCl5cBnV3I7yNWtAsbNAJvlsK01ymGRv8pJw5zD7IRR7njSJ9tzZV+Bnh80Ykg7 zZHeZkhJSvA41Cn564KJf6z/1Sq1iDNgmOgAKVuloHJJGh3E3hc7CRd001R3n6xuGsXu 8kaOVA9Rofov7VCdL/z1uAwV0xjxd0z/5MuA5dOlP9VgJFqMtE9IHKuRj/OtmTHUf4Fb XnlKbO5QPqjy/oj77fhbR0q54sB3dncVI6wtPFfMk/OzSsRNGWJfpQ/Ee90xJJOdKtB9 C8Vw== X-Gm-Message-State: AIkVDXK+XzX2imt0pxXvay5ZDL6RH1+LwAvdlLL+S9/d+jQwbmdeogrJQlIyV1HfK34fEA== X-Received: by 10.36.170.68 with SMTP id y4mr834759iti.7.1485471221277; Thu, 26 Jan 2017 14:53:41 -0800 (PST) Received: from [172.16.224.219] ([209.97.127.34]) by smtp.gmail.com with ESMTPSA id 202sm306507ith.7.2017.01.26.14.53.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 14:53:40 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_EB63AE59-0232-45B5-9EB1-6E172B1D2A5B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 26 Jan 2017 14:53:38 -0800 In-Reply-To: <5F93D303-B95A-4EF7-8F65-2E1FC9632C80@ericsson.com> To: Suresh Krishnan References: <484b4d11bea54ef1b0b0780d3cd1eab8@XCH-ALN-003.cisco.com> <70f2f8a012de43a4b35f625837b768b2@XCH-ALN-003.cisco.com> <7F94525A-BECA-4C30-A278-0B7366390087@gmail.com> <5F93D303-B95A-4EF7-8F65-2E1FC9632C80@ericsson.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Donald Eastlake , Bob Hinden , Bernie Volz , "draft-ietf-6man-rfc1981bis.all@ietf.org" , "int-dir@ietf.org" Subject: Re: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 26 Jan 2017 22:53:45 -0000 --Apple-Mail=_EB63AE59-0232-45B5-9EB1-6E172B1D2A5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Suresh, > On Jan 26, 2017, at 2:16 PM, Suresh Krishnan = wrote: >=20 > Hi Bob, >=20 >> On Jan 26, 2017, at 3:34 PM, Bob Hinden wrote: >>=20 >> Great! >=20 > A note in the shepherd writeup would have worked for me as well. The = one concern I have is that if such text is added to this document, = should it be added to 2460bis as well? That=E2=80=99s a good point. I would also be fine with adding it to the = writeup. Your call. Thanks, Bob >=20 > Thanks > Suresh >=20 >>=20 >> Thanks, >> Bob >>=20 >>> On Jan 26, 2017, at 12:30 PM, Bernie Volz (volz) = wrote: >>>=20 >>> Hi Bob: >>>=20 >>> Your note would work well for me. >>>=20 >>> Note: This document is an update to RFC1981 that was published = prior to RFC2119 being published. Consequently while it does use = "should/must" style language in upper and lower case, the document does = not cite the RFC2119 definitions. This update does not change that. >>>=20 >>> - Bernie >>>=20 >>> -----Original Message----- >>> From: Bob Hinden [mailto:bob.hinden@gmail.com] >>> Sent: Thursday, January 26, 2017 3:07 PM >>> To: Bernie Volz (volz) >>> Cc: Bob Hinden ; Donald Eastlake = ; draft-ietf-6man-rfc1981bis.all@ietf.org; = int-dir@ietf.org >>> Subject: Re: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review >>>=20 >>> Hi Bernie, >>>=20 >>> inline >>>=20 >>>> On Jan 25, 2017, at 3:15 PM, Bernie Volz (volz) = wrote: >>>>=20 >>>> Bob: >>>>=20 >>>> While it is great that you know this issue with RFC 2119 key words = ... others reading this document when it becomes an RFC may not know = that (and RFC8xxx or whatever it will be does not predate 2119) and even = if the RFC 2119 reference isn't directly in the document, what will they = assume (I mostly assume if I see MUST in an IETF document, it is a RFC = 2119 key word)? >>>>=20 >>>> I would think that at a minimum, adding a note that this document = does NOT make explicitly use of RFC 2119 key words and therefore how a = reader interprets MUST vs must is up to them (presumable MUST is more of = a must than the lower case version). >>>=20 >>> I don=E2=80=99t object to a note. However, RFC2119 does not require = upper case, so making statements about the precedence of upper vs. lower = case it=E2=80=99s warranted. >>>=20 >>> How about something like this: >>>=20 >>> Note: This document is an update to RFC1981 that was published = prior to RFC2119 being published. Consequently while it does use = "should/must" style language in upper and lower case, the document does = not cite the RFC2119 definitions. This update does not change that. >>>=20 >>> I guess this means I will have to add a reference to RFC2119 :-) >>>=20 >>>>=20 >>>> I think it might also be possible to argue that 2119 might have = been on the horizon at the time and as it did not yet exist ... 02 of = the 2119 draft (oldest available at tools.ietf.org) was published in = August 1996 which is the same month in which 1981 was published. So = seems likely that there is some influence from that work here? >>>>=20 >>>> I guess one conclusion is that even if not explicitly indicated, = the assumption that they are (in the spirit of) 2119 key words is likely = correct. >>>=20 >>> I suspect that is true. The reason why we didn=E2=80=99t cite = RFC2119 in rfc1981bis, is that RFC1981 is very widely implemented using = the current language, and starting to change the =E2=80=9Cmust/should/etc.= =E2=80=9D to upper case, will likely cause some to think that this = document is intended to change implementation behaviour. That was not = the intent of the w.g. The changes in the bis document are very = limited. >>>=20 >>> Thanks, >>> Bob >>>=20 >>>>=20 >>>> - Bernie >>>>=20 >>>> -----Original Message----- >>>> From: Int-dir [mailto:int-dir-bounces@ietf.org] On Behalf Of Bob >>>> Hinden >>>> Sent: Wednesday, January 25, 2017 5:43 PM >>>> To: Donald Eastlake >>>> Cc: Bob Hinden ; >>>> draft-ietf-6man-rfc1981bis.all@ietf.org; int-dir@ietf.org >>>> Subject: Re: [Int-dir] draft-ietf-6man-rfc1981bis-03 INTDIR review >>>>=20 >>>> Donald, >>>>=20 >>>> Thanks for your comments! >>>>=20 >>>> To set the background this, this is part of 6MAN work to advance = the core IPv6 specs from Draft Standard to Internet Standard. As part = of this, we were only trying to change things that where there were RFCs = that updated it, errata, and to make it consistent with the other RFCs = being advanced (for example rfc2460bis and rfc4291bis). We were trying = to change as little as possible. >>>>=20 >>>> That why we kept the must/should language intact and did not = include a reference to RFC2119. RFC1981 was, of course, written before = RFC2119. It uses a mix of upper and lower case words, I am am reluctant = to try to change that. This is also consistent with how the w.g. = handled this issue with rfc2460bis and rfc4291bis. >>>>=20 >>>> Comments inline below. >>>>=20 >>>> Bob >>>>=20 >>>>=20 >>>>> On Jan 25, 2017, at 1:24 PM, Donald Eastlake = wrote: >>>>>=20 >>>>> I am an assigned INT directorate reviewer for >>>>> draft-ietf-6man-rfc1981bis-03.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. >>>>>=20 >>>>> This document appears to be Ready with Nits. >>>>>=20 >>>>>=20 >>>>> Add RFC 2119 to Reference and add corresponding boilerplate, = probably >>>>> to the Terminology section. >>>>=20 >>>> See note above. >>>>=20 >>>>>=20 >>>>> Section 4, Page 6, next to last paragraph of Section 4: "should" = -> =E2=80=9CSHOULD" >>>>=20 >>>> ditto >>>>=20 >>>>>=20 >>>>> Section 5.1, Page 7, 2nd sentence of next to last paragraph of >>>>> Section >>>>> 5.1: delete superfluous comma >>>>=20 >>>> Thanks, will fix. >>>>=20 >>>>>=20 >>>>> Section 5.2, Page 7: just a wording suggestion: "must in fact >>>>> represent" -> =E2=80=9Crepresents" >>>>=20 >>>> Makes sense to me, I will change. >>>>=20 >>>>>=20 >>>>> Section 5.2, Page 8: The indented Note about "security >>>>> classifications" strikes me as probably an archaism left over from >>>>> when it was the "US Department of Defense Internet". I suggest >>>>> replacing "security classifications" with "quality of service >>>>> markings" or the like. Security seems like one "quality" of = service >>>>> so I believe the new wording I am suggesting is a superset of the = old. >>>>=20 >>>> While I tend to agree with you, I think this is a change we don=E2=80= =99t have very much justification to make. >>>>=20 >>>>>=20 >>>>> Section 5.2, Page 9: I am not entirely comfortable that earlier in >>>>> the document it says that a Packet Too Big reporting a next hop = MTU >>>>> less than the IPv6 minimum link MTU should be discarded and that a >>>>> node MUST NOT reduce its estimate of the Path MTU below the IPv6 >>>>> minimum link MTU but in the top paragraph on page 9 it talks in an >>>>> unrestricted way about reducing the PMTU based on Packet Too Big >>>>> message next hop size. I suggest, at the top of page 9: "uses the >>>>> value in the MTU field in the Packet Too Big message as a = tentative >>>>> PMTU" -> "uses the value in the MTU field in the Packet Too Big >>>>> message, or the minimum IPv6 next hop MTU if that is larger, as a >>>>> tentative PMTU=E2=80=9D >>>>>=20 >>>>=20 >>>> I agree, thanks for catching this. This makes it consistent with = the earlier text in Section 4. >>>>=20 >>>>=20 >>>>> Section 5.3, Page 10, right after the indented Note: "must not" -> = "MUST NOT" >>>>>=20 >>>>> Section 5.4, Page 10: "should not" -> "SHOULD NOT" >>>>>=20 >>>>> Section 5.4, Page 11, 1st paragraph: Expand "MSS" on first use; = "must >>>>> not" -> "MUST NOT=E2=80=9D >>>>=20 >>>> Agree about MSS. >>>>=20 >>>>>=20 >>>>> Section 5.4, Page 11, indented Note: in 1st paragraph "must not" = -> >>>>> "MUST NOT"; in 2nd paragraph "must" -> "MUST" >>>>>=20 >>>>> Section 5.5, Page 12, 1st paragraph: "should" -> "SHOULD" >>>>>=20 >>>>> Section 5.5, Page 12, 3rd paragraph: "recommended" -> = "RECOMMENDED" >>>>>=20 >>>>> Section 5.5, Page 12, 4th paragraph: If some NFS operations cannot = be >>>>> fragmented, "should not" -> "MUST NOT" >>>>>=20 >>>>> Appendix B, 2nd sentence: "version that the change was made.:" -> >>>>> "version where the change was made.=E2=80=9D >>>>=20 >>>> Thanks, will fix. >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Donald >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D >>>>> Donald E. Eastlake 3rd +1-508-333-2270 (cell) >>>>> 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com >>>>=20 >>>> _______________________________________________ >>>> Int-dir mailing list >>>> Int-dir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/int-dir >>>=20 >>=20 >> _______________________________________________ >> Int-dir mailing list >> Int-dir@ietf.org >> https://www.ietf.org/mailman/listinfo/int-dir >=20 --Apple-Mail=_EB63AE59-0232-45B5-9EB1-6E172B1D2A5B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYin3yAAoJEK7rdBF357uo7K0H/Rq6lUB38ng42CwqDgipXRY2 D/agelK1OMxoyytjT1uMJwdZgy23U+Kix6ciUpXc+ATINpYT855laA3ya7tY/svS 1J6O/w6fbFulQ6eBAwfTnvbhVQCiP2mALhyOeKZUg1PzIrj7a4u32xHjk1dGVi56 40J8Wop6FHfuxXpHzz7GwlhLxt3jic+6HEp3u2QT6rREFvtCEXzull7wzPrCHiOR 6eracrDqNpG5grSbTXSNU4VQH08U6W5SKkXFcjkXiMO9fBHNietodB9nExz8XLla QPMgk47w9+9ZWwszmA951BJ7dssV44ctd6CGjCymZNMfGvZ3tTJIrWbm11f71r4= =tZmV -----END PGP SIGNATURE----- --Apple-Mail=_EB63AE59-0232-45B5-9EB1-6E172B1D2A5B-- From nobody Fri Jan 27 11:10:15 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688B212971E; Fri, 27 Jan 2017 11:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 4DWfNnjPR4zQ; Fri, 27 Jan 2017 11:10:12 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 1A0CC129715; Fri, 27 Jan 2017 11:10:09 -0800 (PST) X-AuditID: c6180641-e87ff70000000a0b-d2-588b46a1b0b2 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by (Symantec Mail Security) with SMTP id 4B.1C.02571.1A64B885; Fri, 27 Jan 2017 14:09:56 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0319.002; Fri, 27 Jan 2017 14:10:04 -0500 From: Suresh Krishnan To: "Dhananjay Patki (dhpatki)" , Ralph Droms , "int-dir@ietf.org" Thread-Topic: [Int-dir] Review of draft-ietf-dmm-lma-controlled-mag-params-02 Thread-Index: AQHSeND2RE5BgS32fESeyuUlVFmeUg== Date: Fri, 27 Jan 2017 19:10:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZXLrHT3eJW3eEwcy7ChYPbp5gt7j/qMbi zIcnLBaPrnSzWDRe62N1YPWY8nsjq8fOWXfZPZYs+ckUwBzFZZOSmpNZllqkb5fAlfG+o4m1 oEelomF6QgPjFOUuRk4OCQETiR2P29m7GLk4hATWM0r8P9jOBuEsZ5RouvuUDaSKDahqw87P TCAJEYFGRolrfWfBHGaBaYwSU5c+BKsSFvCReLlzASuILSLgK/Hm6TV2CFtPYt2734wgNouA qsT/NbeZQGxeAXuJ5rd/mUFsRgExie+n1oDFmQXEJW49mc8EcZ+AxJI955khbFGJl4//gc0X BZq58cI0doi4ksTH3/OBbA6gXk2J9bv0IUxriZP3aiAmKkpM6X7IDrFVUOLkzCcsExhFZyFZ NguheRZC8ywkzbOQNC9gZF3FyFFaXJCTm25kuIkRGEfHJNgcdzDu7fU8xCjAwajEw2ug0R0h xJpYVlyZe4hRgoNZSYS3Ph8oxJuSWFmVWpQfX1Sak1p8iFGag0VJnPd6yP1wIYH0xJLU7NTU gtQimCwTB6dUA2Po4x0WPV0sjNyRN5dcZ3ye9jtuW+iBztq/fXkdHIoXfCKXLZnyfU/SLT8f n5Sknkj2Kua/WXKHrpvn5XIyKibvMfm+u6Vbk3F631WmBR2zfS4t80pI8dT7ol8k7+rBpltj /0BrN4/gv4dRHtzi5/+0FzJ8LeDnd9jl5HX3OsP114teMQsLKrEUZyQaajEXFScCABvT76Gf AgAA Archived-At: Cc: "dmm@ietf.org" , "draft-ietf-dmm-lma-controlled-mag-params.all@ietf.org" Subject: Re: [Int-dir] Review of draft-ietf-dmm-lma-controlled-mag-params-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jan 2017 19:10:14 -0000 SGkgRGhhbmFuamF5L2F1dGhvcnMsDQogIEFueSBwcm9ncmVzcyBvbiB0aGlzPyBJIHdvdWxkIGxp a2UgdG8gZ2V0IHRoaXMgbW92aW5nIHNvb24uDQoNClRoYW5rcw0KU3VyZXNoDQoNCk9uIDEyLzIy LzE2LCA0OjM1IEFNLCAiSW50LWRpciBvbiBiZWhhbGYgb2YgRGhhbmFuamF5IFBhdGtpIChkaHBh dGtpKSIgPGludC1kaXItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZGhwYXRraUBjaXNj by5jb20+IHdyb3RlOg0KDQogICAgSGVsbG8sDQogICAgDQogICAgVGhhbmtzIGZvciB0aGUgcmV2 aWV3LiBXZSB3aWxsIGFkZHJlc3MgdGhlIGNvbW1lbnRzIGFuZCBnZXQgYmFjayB3aXRoIGEgbmV3 IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KICAgIC0tDQogICAgUmVnYXJkcywNCiAgICBEaGFuYW5q YXkNCiAgICANCiAgICANCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206 IFJhbHBoIERyb21zIDxyZHJvbXMuaWV0ZkBnbWFpbC5jb20+DQogICAgRGF0ZTogV2VkbmVzZGF5 LCAyMSBEZWNlbWJlciAyMDE2IGF0IDExOjUxIFBNDQogICAgVG86ICJpbnQtZGlyQGlldGYub3Jn IiA8aW50LWRpckBpZXRmLm9yZz4NCiAgICBDYzogImRtbUBpZXRmLm9yZyIgPGRtbUBpZXRmLm9y Zz4sICJpZXRmQGlldGYub3JnIiA8aWV0ZkBpZXRmLm9yZz4sICJkcmFmdC1pZXRmLWRtbS1sbWEt Y29udHJvbGxlZC1tYWctcGFyYW1zLmFsbEBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtZG1tLWxtYS1j b250cm9sbGVkLW1hZy1wYXJhbXMuYWxsQGlldGYub3JnPg0KICAgIFN1YmplY3Q6IFJldmlldyBv ZiBkcmFmdC1pZXRmLWRtbS1sbWEtY29udHJvbGxlZC1tYWctcGFyYW1zLTAyDQogICAgUmVzZW50 LUZyb206IDxhbGlhcy1ib3VuY2VzQGlldGYub3JnPg0KICAgIFJlc2VudC1UbzogPGRocGF0a2lA Y2lzY28uY29tPiwgPHNndW5kYXZlQGNpc2NvLmNvbT4sIDxqb25naHlvdWtAc211LmFjLmtyPiwg PGZ1cWlhbzFAb3V0bG9vay5jb20+LCA8bHlsZS50LmJlcnR6QHNwcmludC5jb20+LCA8am91bmku bm9zcGFtQGdtYWlsLmNvbT4sIDxtYXhwYXNzaW9uQGdtYWlsLmNvbT4sIDxzdXJlc2gua3Jpc2hu YW5AZXJpY3Nzb24uY29tPiwgPHRlcnJ5Lm1hbmRlcnNvbkBpY2Fubi5vcmc+LCBEYXBlbmcgTGl1 IDxtYXgubGRwQGFsaWJhYmEtaW5jLmNvbT4sIDxtYXgubGRwQGFsaWJhYmEtaW5jLmNvbT4NCiAg ICBSZXNlbnQtRGF0ZTogV2VkbmVzZGF5LCAyMSBEZWNlbWJlciAyMDE2IGF0IDExOjUxIFBNDQog ICAgDQogICAgUmV2aWV3ZXI6IFJhbHBoIERyb21zDQogICAgUmV2aWV3IHJlc3VsdDogUmVhZHkg d2l0aCBJc3N1ZXMNCiAgICANCiAgICBNYWpvciBpc3N1ZXM6ICBOb25lDQogICAgDQogICAgTWlu b3IgaXNzdWVzOg0KICAgIA0KICAgIFRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoaXMgZG9j dW1lbnQgaXMgZmFpcmx5IHNpbXBsZS4gIEkNCiAgICByZWNvbW1lbmQgdGhhdCB0aGUgc3BlY2lm aWMgc2VtYW50aWNzIG9mIHRoZSB1c2Ugb2YgdGhlIHBhcmFtZXRlcg0KICAgIG9wdGlvbnMgc2hv dWxkIGJlIGV4cGxhaW5lZCB3aXRoIGdyZWF0ZXIgY2xhcml0eSB0byBlbnN1cmUgY29ycmVjdCBh bmQNCiAgICBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy4gIEZvciBleGFtcGxlLCBJIGZv dW5kIHRoZSBkZXNjcmlwdGlvbg0KICAgIG9mIExNQSBiZWhhdmlvciBpbiBzZWN0aW9uIDUuMSB0 byBiZSBxdWl0ZSBjb252b2x1dGVkIGFuZCBjb25mdXNpbmcuIA0KICAgIFB1dHRpbmcgdGhlICJp Zi4uLnRoZW4uLi5lbHNlIiBjb25zdHJ1Y3QgaW4gdHdvIGJ1bGxldHMgc2VlbWVkIG9idHVzZS4N CiAgICAgSW4gdGhlIGZpcnN0IGJ1bGxldCwgdGhlIExNQSAiU0hPVUxEIGluY2x1ZGUiIHRoZSBz dWItb3B0aW9uLiAgQXJlDQogICAgdGhlcmUgY2lyY3Vtc3RhbmNlcyB1bmRlciB3aGljaCB0aGUg TE1BIHdvdWxkIG5vdCBpbmNsdWRlIHRoZQ0KICAgIHN1Yi1vcHRpb24gYW5kLCBpZiBzbywgd2hh dCBhcmUgdGhvc2UgY2lyY3Vtc3RhbmNlcz8gIENhbiB0aGUgTE1BDQogICAgZGVjaWRlLCBwZXJo YXBzIGZvciBlZmZpY2llbmN5LCB0byByZXR1cm4gdGhlIHN1Yi1vcHRpb24gaW4gb25seSwgc2F5 LA0KICAgIG9uZSBvZiB0ZW4gcmVzcG9uc2VzIHRvIHRoZSBNQUc/DQogICAgDQogICAgSXMgdGhl cmUgYSBzcGVjaWZpYyByZWFzb24gZm9yIGVuY29kaW5nIHRoZSBMQU0gQ29udHJvbGxlZCBNQUcg U2Vzc2lvbg0KICAgIFBhcmFtZXRlcnMgYXMgc3ViLW9wdGlvbnMgdW5kZXIgdGhlIExBTS1Db250 cm9sbGVkLU1BRy1QYXJhbWV0ZXJzDQogICAgb3B0aW9uPyAgV2lsbCBhZGRpdGlvbmFsIHN1Yi1v cHRpb25zIGJlIGRlZmluZWQgaW4gdGhlIGZ1dHVyZT8NCiAgICANCiAgICBFZGl0b3JpYWwgaXNz dWVzLg0KICAgIA0KICAgIEZvciBjbGFyaXR5LCB0aGUgZG9jdW1lbnQgc2hvdWxkIHVzZSBhY3Jv bnltcyBhbmQgbmFtZXMgZm9yIHN5c3RlbQ0KICAgIGNvbXBvbmVudHMgaW4gYSBjb25zaXN0ZW50 IHdheTogdXNlIGFjcm9ueW1zIHRocm91Z2hvdXQgYW5kIGV4cGFuZCB0aGUNCiAgICBhY3Jvbnlt IG9uIGZpcnN0IHVzZS4gIEZvciBleGFtcGxlLCBMTUEgYW5kICJsb2NhbCBtb2JpbGl0eSBhbmNo b3IiDQogICAgYXJlIHVzZWQgaW50ZXJjaGFuZ2VhYmx5IHRocm91Z2hvdXQgdGhlIGRvY3VtZW50 LCB3aGljaCB0aGlzIHJldmlld2VyDQogICAgZm91bmQgdG8gYmUgZGlzdHJhY3RpbmcuDQogICAg DQogICAgV2hhdCBpcyB0aGUgZXhwYW5zaW9uIGZvciAiUEJVIj8NCiAgICANCiAgICBUaGUgdXNl IG9mIHRoZSAiQ29uZmlndXJhdGlvbiBWYXJpYWJsZXMiIGRlZmluZWQgaW4gc2VjdGlvbiA0IGlz DQogICAgcmVwZWF0ZWQgaW4gc2VjdGlvbiA1LjEuICBUbyBhdm9pZCBpbnRlcm5hbCBpbmNvbnNp c3RlbmN5LCBJIHJlY29tbWVuZA0KICAgIHRoYXQgdGhlIHVzZSBvZiB0aGUgdmFyaWFibGUgYmUg ZGVzY3JpYmVkIG9ubHkgb25jZSwgd2l0aCBpbnRlcm5hbA0KICAgIHBvaW50ZXJzIHRvIHRoYXQg dGV4dCBmcm9tIG90aGVyIHBsYWNlcyBpbiB0aGUgZG9jdW1lbnQuDQogICAgDQogICAgSW4gc2Vj dGlvbiA2LCBpdCB3b3VsZCBoZWxwIHRoZSByZWFkZXIgdG8gaW5jbHVkZSB0aGUgbmFtZSBvZiB0 aGUNCiAgICByZWdpc3RyeSB0byBiZSBtb2RpZmllZCBpbiB0aGUgZmlyc3QgYnVsbGV0LiAgDQog ICAgDQogICAgDQogICAgDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgICBJbnQtZGlyIG1haWxpbmcgbGlzdA0KICAgIEludC1kaXJA aWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ludC1k aXINCiAgICANCg0K From nobody Fri Jan 27 12:20:09 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1520512987B; Fri, 27 Jan 2017 12:20:08 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFw_8-MIZCU6; Fri, 27 Jan 2017 12:20:07 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (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 E3265129873; Fri, 27 Jan 2017 12:20:06 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id 75so25759853pgf.3; Fri, 27 Jan 2017 12:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PBMHZD77YUPeJaNDnW9BH5uP2ReuPROwALQ4itelsns=; b=fmUquGL0XycZK3sDd5wSWzupSqe7p0Ycgw+w6rcNuVIkZnRDhL4QOd9vEdBx0wTjiW hH2gPktO6hWPsVwd+c8p93YaFUwZnLvDFZYhUkqFMr/NlwpLagXcGSLBSxdJkXURQ1Yq JB6Ty1I38JP7l5C8L8w/ykaLHoSsvRk2zly9BmYmtF3KCG912GkuZRAOhGJR5K8QH5ik D25Pdy37FhF/sAWvRA1fy9rJ2645uWiGAGqNAo0BQ5oIwdB9HBe6Vk8e+NjjvirV5S++ PqQMua1M4bkDtzgZ4pMnwgJLi0m+gOii0Q1Spn2pOqHS+kQvGT535DlNpD2irkhm/3xI ufAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PBMHZD77YUPeJaNDnW9BH5uP2ReuPROwALQ4itelsns=; b=jvBPnNrLIc065sxGw4o1X3HFQxQCj+cS5Ho374z2cecrUAwDA70EsbJT6qTOmpro01 cVeTJ1AAzSlY4RKE2GmlyYgb5wzj0qj3aKH60ei0y/1bn6US15b/dziwh+T/w2dt9698 WhM1PDAQKPCv1demeqOaOI0W8SEzrcnvz9/A5jOG1sNnVNzk2ZD9hFVaETFT2Yspxp8l AE4yuygat8rOXa2YYm5bdVqjKHFWjWMGq1fFEPMVEKu8BoUKugOOqO2LVwaijhN9YeHn BeXdWlJJl18RmNxR6XTILajnmjqMM0qSZY1gum0WuAYa1/+l5NW6NdEh8sYQZzZSk/sw 21XQ== X-Gm-Message-State: AIkVDXIxmBy4qOuEFFCclT8BSiuWyUBergbvG6oyKRaJRYtLOS3G5AJFfgyhDJmM1yS9cA== X-Received: by 10.84.218.5 with SMTP id q5mr14926051pli.80.1485548406480; Fri, 27 Jan 2017 12:20:06 -0800 (PST) Received: from [192.168.89.94] ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id u124sm13406037pgb.6.2017.01.27.12.20.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jan 2017 12:20:05 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "jouni.nospam" In-Reply-To: <519FB5EF-52B0-4DEA-B670-2D2593C3FB66@fugue.com> Date: Fri, 27 Jan 2017 12:20:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6DA7EAEF-C226-43E2-800A-9C3CB7F9FB6D@gmail.com> References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> <367DE531-AF9C-40A3-8B1F-5F595D804023@gmail.com> <519FB5EF-52B0-4DEA-B670-2D2593C3FB66@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "ietf@ietf.org" , "int-dir@ietf.org" , Tomek Mrugalski , Jouni Korhonen , "dhcwg@ietf.org" , "draft-ietf-dhc-relay-server-security.all@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [Int-dir] [dhcwg] Review of draft-ietf-dhc-relay-server-security-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jan 2017 20:20:08 -0000 > On Jan 26, 2017, at 11:27 AM, Ted Lemon wrote: >=20 > On Jan 26, 2017, at 1:58 PM, jouni.nospam = wrote: >> No. But in this case there are pieces of text that change specific = places in the original document from SHOULDs to MUSTs, musts to MUSTs, = and adds few pieces of new stuff, etc. Now how that in not updating? = Changes or =E2=80=9Cextensions=E2=80=9D like that would be nice to = follow from the base document. >=20 > Okay, I see your point. But suppose the document were changed so = that rather than "updating" the document as you suggest, it simply = referenced the sections in question and then made the SHOULDs into MUSTs = that way? Wouldn't that mean "implementations of this extension MUST," = and wouldn't that be perfectly reasonable? >=20 I would still argue that it updates specifically if the document here is = going to be standards track. If this document here would be more of a = recommendation e.g., BCP I would be fine without the =E2=80=9Cupdating=E2=80= =9D part (as I remember the MUST for IPsec in RFC3315bis was not = endorsed by the WG). - Jouni= From nobody Fri Jan 27 13:25:19 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33F712996A for ; Fri, 27 Jan 2017 13:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jcpbpy9hAewW for ; Fri, 27 Jan 2017 13:25:18 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 B3F5F129973 for ; Fri, 27 Jan 2017 13:25:16 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id w20so88551485qtb.1 for ; Fri, 27 Jan 2017 13:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=G6BHAHVvBBgaoa1pQ6rzPXDBLdcdblDk0IXCj7Tf/Ag=; b=vg/WmzYdo0mBbJFZf5zyXXQAwOD6rxkz0D+ceOTJul0hFxRRKujdzhpo8kOVDC6ij/ pt+A7YJk6IgAtuNcXnpOd/92fRnex0oEwmwoIUXRUfTGthiNLS+4tT027GgyqNrzTyPN K/n3ykTQh37ok1A3i6U5oWu3jRbEIL6aJ+DVn3sZ6b1w0nZeWLEGToNJ1+T5WjM3/e5J G46JhENpu++cuoqGhibT125P7BSi1/Z1oyrvgi3rPNEsg+vZ43uxyptWH+aXUqtizGVx Nilr6PXRAVyQopcgUfErUEN0z+6epo8wg9eQWQMbwUqWq6mwW2WjpIF78P+S0lwZoNaO /VVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=G6BHAHVvBBgaoa1pQ6rzPXDBLdcdblDk0IXCj7Tf/Ag=; b=USYTjZn/prSkZokPvcnVNT06+TfsL5A3pZ+YvkTKjMPqIesSDSEAZ2IB9xi5neRBZK A87wM9KYLaE3zjR/0orTKwjl5xTFPBkSOec/dM9/FhGmd9mjarvUZ5/PD2FRJwn0QARr 5d7uUUNjDcJPq+WXKRll6rP6S2Z706DACbQE8rNKn8h9+VZj/B4TNoRLUwGAyyO/eO+M Mu74c6Lsa7UlF0KnfHd7RcphgrLiiupByhD6POlak99nCgMOgX6BpW0id7qHIrQHCeGl G7EFOp9CaJqY1Sx/vWN4aaTdoZJdsS6kyhDvCHyJkmlAskrbbguHHrYw+Autlk1bu9K9 N9Kw== X-Gm-Message-State: AIkVDXLOkQSUlD5xwmSe81BmMAubJrPtYkTzPC3l5QeXosD9O+RW/InkCD34QwQfwwtkPQ== X-Received: by 10.200.42.200 with SMTP id c8mr10358755qta.156.1485552315541; Fri, 27 Jan 2017 13:25:15 -0800 (PST) Received: from [192.168.1.228] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 37sm5134478qto.43.2017.01.27.13.25.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jan 2017 13:25:14 -0800 (PST) From: Ted Lemon Message-Id: <3C1097F9-0F7A-4349-93E7-3A27BBDF1749@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C986E285-A393-455B-8E37-D224B64E4EA5" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 27 Jan 2017 16:25:12 -0500 In-Reply-To: <6DA7EAEF-C226-43E2-800A-9C3CB7F9FB6D@gmail.com> To: "jouni.nospam" References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> <367DE531-AF9C-40A3-8B1F-5F595D804023@gmail.com> <519FB5EF-52B0-4DEA-B670-2D2593C3FB66@fugue.com> <6DA7EAEF-C226-43E2-800A-9C3CB7F9FB6D@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "ietf@ietf.org" , "int-dir@ietf.org" , Tomek Mrugalski , Jouni Korhonen , "dhcwg@ietf.org" , "draft-ietf-dhc-relay-server-security.all@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [Int-dir] [dhcwg] Review of draft-ietf-dhc-relay-server-security-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 27 Jan 2017 21:25:19 -0000 --Apple-Mail=_C986E285-A393-455B-8E37-D224B64E4EA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 27, 2017, at 3:20 PM, jouni.nospam = wrote: > I would still argue that it updates specifically if the document here = is going to be standards track. If this document here would be more of a = recommendation e.g., BCP I would be fine without the =E2=80=9Cupdating=E2=80= =9D part (as I remember the MUST for IPsec in RFC3315bis was not = endorsed by the WG). Ok, but it's not a BCP, it's a standard, with requirements for interop. = So it can't be a BCP. Given that it can't be a BCP, the other choices are "informational" and = "experimental" and "updates the base spec." You are saying that you = want "updates the base spec," which would mean that everybody would have = to implement it to conform to the new, updated spec. But the argument = has been made that this is not desirable: not everybody needs to = implement this, and it is not desired that implementing this be a = requirement. So are you saying that you disagree with this=E2=80=94that you think it = should be MTI? Or are you saying that there is some other way to = accomplish this goal? --Apple-Mail=_C986E285-A393-455B-8E37-D224B64E4EA5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 27, 2017, at 3:20 PM, jouni.nospam <jouni.nospam@gmail.com> wrote:
I would still argue = that it updates specifically if the document here is going to be = standards track. If this document here would be more of a recommendation = e.g., BCP I would be fine without the =E2=80=9Cupdating=E2=80=9D part = (as I remember the MUST for IPsec in RFC3315bis was not endorsed by the = WG).

Ok, = but it's not a BCP, it's a standard, with requirements for interop. =   So it can't be a BCP.

Given that it can't be a BCP, the other = choices are "informational" and "experimental" and "updates the base = spec."   You are saying that you want "updates the base spec," = which would mean that everybody would have to implement it to conform to = the new, updated spec.   But the argument has been made that this = is not desirable: not everybody needs to implement this, and it is not = desired that implementing this be a requirement.

So are you saying that you disagree = with this=E2=80=94that you think it should be MTI?   Or are you = saying that there is some other way to accomplish this goal?

= --Apple-Mail=_C986E285-A393-455B-8E37-D224B64E4EA5-- From nobody Mon Jan 30 14:20:15 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A9A129C07; Mon, 30 Jan 2017 14:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NVlY_7mBVWg; Mon, 30 Jan 2017 14:20:09 -0800 (PST) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::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 CC2B2129C06; Mon, 30 Jan 2017 14:20:06 -0800 (PST) Received: by mail-pf0-x243.google.com with SMTP id 19so24359862pfo.3; Mon, 30 Jan 2017 14:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J5/u/wXPP4X5vQAOYHdCZ9RjUZsm5BYOp8m56BhJpDc=; b=pyva9aDO6MygEfObe/SZt6Q35FubyhEbuHbXzvOM/yY5vMfViesceTMfzBmqABFX20 Wge0aKZUhhWv1+VD+WLkdOznzSX0HJu26tMY6s9IH85qsvzZJBG50F9o4uhgMKCwipuI +YIIx3Bfu/IFi7TQ/0Muanb/dLcZUXG+w73kbp3u2h91CboGXldAJ8jBKnTqd9tkf4KU UvvVfUjsC9KBF6zt/8cfUHSJZkgjvOKOizs5EeL7ugjvkh7yYXrsnTBJEX8ZoMdaRwRI oMtj5Cjq2U3IyUbGiVyxQ1ul1haM6HPPfIaRJYktPEPoyyvFtdrljHZ7J9lkwBdlH43F hQ8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J5/u/wXPP4X5vQAOYHdCZ9RjUZsm5BYOp8m56BhJpDc=; b=f38B0I+52Tz5XbYe3lXI+MqgsbHelxnRs5vbh5L6BkiLsHkvn5Vtu3vzS9qx0hN0Cz TCSpnrITaOZ7lOjqo9FFcJDRNER3K5GCwSrGQkj+5+5dIucrfbrNCvuijVhzyxvdIDLe Q7V1fBOuElY9FmC1+cVaOE6lg7S3DGWZHtxLSaNVNL7cbaicMmJkzGHfk3mXBZjznSbj nkU19hDxP69T/8wpaWW2bDgyTGwefAPtUBiXFKTUqKN8fgrDAbzfs9WyILmCkM4RDZhG KL0plXEJESQa/vVBiLoahAdzDVONFB7zKC1ltvd0hOvaowuOpgA+2rkJOxf9r9woguXv pxhw== X-Gm-Message-State: AIkVDXK/p6MeVLlNRoKibadqvCWHHxUc/7+LnZj/npuqmyKbRAhprQZQJB7Z5L8VcUHtZQ== X-Received: by 10.99.172.85 with SMTP id z21mr26635610pgn.187.1485814806154; Mon, 30 Jan 2017 14:20:06 -0800 (PST) Received: from [192.168.89.94] ([216.31.219.19]) by smtp.gmail.com with ESMTPSA id j28sm35080355pfj.2.2017.01.30.14.20.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 14:20:04 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: "jouni.nospam" In-Reply-To: <3C1097F9-0F7A-4349-93E7-3A27BBDF1749@fugue.com> Date: Mon, 30 Jan 2017 14:20:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <24F2F434-05FE-4E71-A75E-55DF632EA1D8@gmail.com> References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> <367DE531-AF9C-40A3-8B1F-5F595D804023@gmail.com> <519FB5EF-52B0-4DEA-B670-2D2593C3FB66@fugue.com> <6DA7EAEF-C226-43E2-800A-9C3CB7F9FB6D@gmail.com> <3C1097F9-0F7A-4349-93E7-3A27BBDF1749@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "ietf@ietf.org" , "int-dir@ietf.org" , Tomek Mrugalski , Jouni Korhonen , "dhcwg@ietf.org" , "draft-ietf-dhc-relay-server-security.all@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [Int-dir] [dhcwg] Review of draft-ietf-dhc-relay-server-security-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 30 Jan 2017 22:20:11 -0000 Ted, > On Jan 27, 2017, at 1:25 PM, Ted Lemon wrote: >=20 > On Jan 27, 2017, at 3:20 PM, jouni.nospam = wrote: >> I would still argue that it updates specifically if the document here = is going to be standards track. If this document here would be more of a = recommendation e.g., BCP I would be fine without the =E2=80=9Cupdating=E2=80= =9D part (as I remember the MUST for IPsec in RFC3315bis was not = endorsed by the WG). >=20 > Ok, but it's not a BCP, it's a standard, with requirements for = interop. So it can't be a BCP. >=20 > Given that it can't be a BCP, the other choices are "informational" = and "experimental" and "updates the base spec." You are saying that = you want "updates the base spec," which would mean that everybody would = have to implement it to conform to the new, updated spec. But the = argument has been made that this is not desirable: not everybody needs = to implement this, and it is not desired that implementing this be a = requirement. The main differences in relay-server-security compared to rfc3315bis = are: 1) the addition of mandatory to implement encryption and authentication = algorithms 2) removal of IKEv1 3) removal of the availability statement 4) mixing IPv4 there as well Otherwise it is mainly about capitalizing rfc2119 keywords (well one = should changes to MUST, and one =E2=80=99use=E2=80=99 is preceded with a = MUST). Now if I decide to implement rfc3315bis *with* security, follow all = musts in Section 20.1, and listed =E2=80=9Cupdates=E2=80=9D in the = header, I have still no guarantee whether I can interoperate with = another rfc3315bis implementation because it decided to follow = relay-server-security. That is not good. > So are you saying that you disagree with this=E2=80=94that you think = it should be MTI? Or are you saying that there is some other way to = accomplish this goal? I am saying.. the intention of relay-server-security is good and I = support it. The way it is done is IMHO not good. What I would do is to = fix Section 20.1 in rfc3315bis with proper rfc2119 keywords and missing = pieces (like the algorithms), but still keeping the implementation of = 20.1 optional as it is now. Then I would do (i.e., = relay-server-security) as a BCP saying =E2=80=9Cimplementation of the = security in rfc3315bis as defined in Section 20.1 is REQUIRED and MUST = use the following profile..=E2=80=9D. This can be worded to cover both = DHCPv4 and DHCPv6. - Jouni From nobody Mon Jan 30 14:54:52 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4CA129671 for ; Mon, 30 Jan 2017 14:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RlUsxrXY9Qq for ; Mon, 30 Jan 2017 14:54:41 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 B1B64129692 for ; Mon, 30 Jan 2017 14:54:32 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id s140so146557845qke.0 for ; Mon, 30 Jan 2017 14:54:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Kb6jRvB2dP7tudp+XDMpLa61UB+IfdhSNubmOqeEbW8=; b=2FHGxVz0xIXUEZ1QbNy0qXoGOaobmWsJqmSzY+AWj6P/osE77Rr9Z8V07/Jlm9bgAy hkET9J06WcqdjdnX4xo8qGxt8p3KOaX9GtHKsmN5euv8+hh99ic/80SLecs99atTVDHT znd4GJLqkRnWurjobtLRHYAdx6dsljm0FmLEyeC9skw4ndEZjC5SpWMiQqG9XvA57aBN fUTZZZl7g2KnOeqQSBBVAdNso/QpnIVgYdix2uSysSnTf91hSPx8i6A7TFgw6M9d30vh 6efDvOw3+VmuunmpXPMvmMKeSSPwq9e3d7lvu+sPp3SEo+3l1ycXnqD3Wp6J0PeZgC1j T4dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Kb6jRvB2dP7tudp+XDMpLa61UB+IfdhSNubmOqeEbW8=; b=ithujjmLr3f/k1Dj4oyIF+wU5Fe08Un2ZSflz//RoQgwIUEd2YlBarGwB5LAmr3pOQ 9e2sECxr670W+WzmV8rTbbVA5rnxY8BdSr2FoG8xRXRrmSYFITps+Za42M1yJgOnDj6X oQspsY0XuoYeMnne73BlRq4gmtCuD4UjG317G+BSjTKg2CBnExKnzyRiYDfRZ8ew7km3 jSzQSDP7Z/6kBivU0sKThHntfvs6r5d24sqr7t/89ENKsflyKMnq/SdG8c6fzBw9yFzB KkPEkFQ21jtf4n1K28EB7P1P/Aby8nPsDEgjRBtWb3T9Nt9/j6rtjCUc29UqV+JaVixy TBcQ== X-Gm-Message-State: AIkVDXIFe7S0dyVsaS9mYJkA+CZ2+Pgoofg8QK/VRzFSH2NnmrOgntCYdB/jdl7RL/Qs1Q== X-Received: by 10.55.33.136 with SMTP id f8mr25059198qki.132.1485816871873; Mon, 30 Jan 2017 14:54:31 -0800 (PST) Received: from [10.70.104.179] ([64.94.31.206]) by smtp.gmail.com with ESMTPSA id s2sm13577712qts.25.2017.01.30.14.54.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 14:54:30 -0800 (PST) From: Ted Lemon Message-Id: <18BE1906-43BB-4505-A584-7A6F034852E3@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_75F4DA28-879D-4873-94E1-3049113659B3" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 30 Jan 2017 17:54:23 -0500 In-Reply-To: <24F2F434-05FE-4E71-A75E-55DF632EA1D8@gmail.com> To: "jouni.nospam" References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> <367DE531-AF9C-40A3-8B1F-5F595D804023@gmail.com> <519FB5EF-52B0-4DEA-B670-2D2593C3FB66@fugue.com> <6DA7EAEF-C226-43E2-800A-9C3CB7F9FB6D@gmail.com> <3C1097F9-0F7A-4349-93E7-3A27BBDF1749@fugue.com> <24F2F434-05FE-4E71-A75E-55DF632EA1D8@gmail.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "ietf@ietf.org" , "int-dir@ietf.org" , Tomek Mrugalski , Jouni Korhonen , "dhcwg@ietf.org" , "draft-ietf-dhc-relay-server-security.all@ietf.org" , "Bernie Volz \(volz\)" Subject: Re: [Int-dir] [dhcwg] Review of draft-ietf-dhc-relay-server-security-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 30 Jan 2017 22:54:42 -0000 --Apple-Mail=_75F4DA28-879D-4873-94E1-3049113659B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 30, 2017, at 5:20 PM, jouni.nospam = wrote: > Now if I decide to implement rfc3315bis *with* security, follow all = musts in Section 20.1, and listed =E2=80=9Cupdates=E2=80=9D in the = header, I have still no guarantee whether I can interoperate with = another rfc3315bis implementation because it decided to follow = relay-server-security. That is not good. Thanks. This is the clarification I was looking for. --Apple-Mail=_75F4DA28-879D-4873-94E1-3049113659B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 30, 2017, at 5:20 PM, jouni.nospam <jouni.nospam@gmail.com> wrote:
Now if I decide to = implement rfc3315bis *with* security, follow all musts in Section 20.1, = and listed =E2=80=9Cupdates=E2=80=9D in the header, I have still no = guarantee whether I can interoperate with another rfc3315bis = implementation because it decided to follow relay-server-security. That = is not good.

Thanks.   This is the clarification I was looking = for.

= --Apple-Mail=_75F4DA28-879D-4873-94E1-3049113659B3-- From nobody Mon Jan 30 15:09:05 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78552129672; Mon, 30 Jan 2017 15:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.719 X-Spam-Level: X-Spam-Status: No, score=-17.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miNQr5JAAotg; Mon, 30 Jan 2017 15:09:01 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D528129610; Mon, 30 Jan 2017 15:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17720; q=dns/txt; s=iport; t=1485817741; x=1487027341; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+4/BbzWcvdZc4fXJeuaQg18k1XsTDoBuKhYMk/p8bg0=; b=HSTvHAkU+OBd6PZMcNARKAEXiZtDpxAxM2wsFlUOYOm1atisjNCoNpnd n6h14+kdCQ51DULJ6Egck/7KYU8tySCjY/StzvUs+P9N1chbk53YWcLqL MhG5W5My4riXw45muphmNmz2yoKeCZo+C0pMskTQvEuNYyRoYxKH5vMq+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzAQB7xo9Y/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnA5K2GBCQeDTooJkgSICYd+hSuCDIYiAhqCDT8YAQIBAQEBAQE?= =?us-ascii?q?BYiiEaQEBAQQjCkwQAgEIDgMEAQEoAwICAh8RFAkIAgQBDQUIiUEDFatFgiWHO?= =?us-ascii?q?Q2DVAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2LOoJRgWJMglCCXwWbHDgBjWmECII?= =?us-ascii?q?Cjn6FZoJAggGIVwEfOIFLFTuGOXWHOoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.33,312,1477958400"; d="scan'208,217";a="202357653" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jan 2017 23:09:00 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0UN90oa006925 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 30 Jan 2017 23:09:00 GMT Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 30 Jan 2017 17:08:59 -0600 Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1210.000; Mon, 30 Jan 2017 17:08:59 -0600 From: "Bernie Volz (volz)" To: Ted Lemon , "jouni.nospam" Thread-Topic: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02 Thread-Index: AQHSd5+8iSisaOl5IUWbOnwv5FiO+aFK8haA///OnZCAAgWSr4AE2IICgABuJ4D//5w9YA== Date: Mon, 30 Jan 2017 23:08:59 +0000 Message-ID: <3c6cc9adffe14172954e69195f05c5dd@XCH-ALN-003.cisco.com> References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> <367DE531-AF9C-40A3-8B1F-5F595D804023@gmail.com> <519FB5EF-52B0-4DEA-B670-2D2593C3FB66@fugue.com> <6DA7EAEF-C226-43E2-800A-9C3CB7F9FB6D@gmail.com> <3C1097F9-0F7A-4349-93E7-3A27BBDF1749@fugue.com> <24F2F434-05FE-4E71-A75E-55DF632EA1D8@gmail.com> <18BE1906-43BB-4505-A584-7A6F034852E3@fugue.com> In-Reply-To: <18BE1906-43BB-4505-A584-7A6F034852E3@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.1.197] Content-Type: multipart/alternative; boundary="_000_3c6cc9adffe14172954e69195f05c5ddXCHALN003ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "ietf@ietf.org" , "int-dir@ietf.org" , Tomek Mrugalski , Jouni Korhonen , "dhcwg@ietf.org" , "draft-ietf-dhc-relay-server-security.all@ietf.org" Subject: Re: [Int-dir] [dhcwg] Review of draft-ietf-dhc-relay-server-security-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 30 Jan 2017 23:09:03 -0000 --_000_3c6cc9adffe14172954e69195f05c5ddXCHALN003ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGk6DQoNCkxldCdzIHRha2UgdGhlIDMzMTViaXMgb3V0IG9mIHRoZSBkaXNjdXNzaW9uIGFzIHdl IGRvbid0IHlldCBrbm93IHdoZW4gdGhhdCB3aWxsIGJlIGF2YWlsYWJsZSBhbmQgd2UnZCBsaWtl IHRvIHByb2dyZXNzIG9uIHRoaXMgZHJhZnQgc29vbmVyIHRoYW4gdGhhdCAoYXMgaXQgaXMgc2hv cnRlciBhbmQgZWFzaWVyIHRvIGRvKS4gV2UgY2FuIGdldCBiYWNrIHRvIGl0IGxhdGVyLCBidXQg bGV04oCZcyBmb2N1cyBmaXJzdCBvbiB0b2RheeKAmXMgaXNzdWUgd2l0aCBpcyB0aGUgZG9jdW1l bnQgd2l0aCBSRkMgMzMxNS4NCg0KU28gaWYgdGhpcyBpcyByZWxlYXNlZCBhcyBSRkM5OTk5LCB0 aGUgb25seSB3YXkgeW91IGFzIHNvbWVvbmUgbG9va2luZyBmb3IgcmVsYXkgb3Igc2VydmVyIGlt cGxlbWVudGF0aW9ucyAob3IgYm90aCkgY291bGQga25vdyB0aGF0IHRoaXMgaXMgc3VwcG9ydGVk IGlzIGJ5IGFza2luZyB0aGUgc3VwcGxpZXIgd2hldGhlciB0aGV5IHN1cHBvcnQgUkZDMzMxNSBh bmQgUkZDOTk5OS4gUkZDOTk5OSBkb2VzIG5vdCBoYXZlIHVwIHVwZGF0ZSAzMzE1LiBUaGlzIGlz IGp1c3QgbGlrZSBtYW55IG9mIHRoZSBvdGhlciBESENQIFJGQ3Mgd2hpY2ggZXh0ZW5kIHRoZSBm dW5jdGlvbmFsaXR5IOKAkyBMZWFzZXF1ZXJ5LCBidWxrIExlYXNlcXVlcnksIGFjdGl2ZSBMZWFz ZXF1ZXJ5LCBhbmQgdGhlIG1hbnkgb3B0aW9ucyBkb2N1bWVudHMuIElmIHlvdSB3YW50IGNlcnRh aW4gZmVhdHVyZXMgYW5kIHRoZXkgYXJlIGluIG90aGVyIGRvY3VtZW50cywgeW91IGhhdmUgdG8g c3BlY2lmeSB0aGUgY29tcGxldGUgbGlzdC4NCg0KU2F5aW5nIGl0IHVwZGF0ZXMgUkZDMzMxNSBk b2VzbuKAmXQgaGVscCBzaW5jZSB0aGVyZSBhcmUgcGxlbnR5IG9mIGV4aXN0aW5nIGltcGxlbWVu dGF0aW9ucyB0aGF0IGRvbuKAmXQgc3VwcG9ydCBJUHNlYy4NCg0KDQoNCkJhY2sgdG8gUkZDIDMz MTUgYmlzIChkcmFmdC1pZXRmLWRoYy1yZmMzMzE1YmlzKSwgdGhhdCBpcyBzdGlsbCBhIHdvcmsg aW4gcHJvZ3Jlc3MuIE91ciBwbGFucyB0byBkYXRlIGFyZSB0aGF0IHdl4oCZbGwgaW5jb3Jwb3Jh dGUgYWxsIG9mIHRoZSBjaGFuZ2VzIG9mIGRyYWZ0LWlldGYtZGhjLXJlbGF5LXNlcnZlci1zZWN1 cml0eSBidXQgbGVhdmUgaXQgT1BUSU9OQUwgdG8gaW1wbGVtZW50IElQc2VjLiBUaGlzIG1lYW5z IHRoYXQgb25jZSBkcmFmdC1pZXRmLWRoYy1yZmMzMzE1YmlzIGlzIHB1Ymxpc2hlZCBhcyBhbiBS RkMsIHRob3NlIHRoYXQgd2FudCBJUHNlYyB3aWxsIGhhdmUgdG8gY2hlY2sgdGhhdCB0aGUgaW1w bGVtZW50YXRpb24gc3VwcG9ydHMgYm90aCB0aGUgYmlzIFJGQyBhbmQgUkZDOTk5OSAob3Igd2hh dGV2ZXIgbnVtYmVyKS4gQnV0IHRoYXTigJlzIHRoZSBzYW1lIHRoYXQgc29tZW9uZSB3YW50aW5n IExlYXNlcXVlcnkgbXVzdCBkbyDigJMgdGhleeKAmWxsIG5lZWQgdG8gY2hlY2sgdGhhdCB0aGUg YmlzIFJGQyBhbmQgUkZDNTAwNyBhcmUgc3VwcG9ydGVkLg0KDQpUaGUgZHJhZnQtaWV0Zi1kaGMt cmZjMzMxNWJpcyBhbmQvb3IgZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5IGF1 dGhvcnMgY2FuIGFsd2F5cyByYWlzZSBpdCB0byB0aGUgREhDIFdHIHRvIHNlZSBpZiB0aGVyZSBp cyBzdWZmaWNpZW50IGNvbnNlbnN1cyB0byBtYWtlIElQc2VjIGEgTVVTVCBpbiB0aGUgYmlzIGRv Y3VtZW50LiBCdXQgdGhlcmUgaGFzbuKAmXQgYmVlbiBpbiB0aGUgcGFzdC4NCg0KDQotICAgICAg ICAgIEJlcm5pZQ0KDQpGcm9tOiBUZWQgTGVtb24gW21haWx0bzptZWxsb25AZnVndWUuY29tXQ0K U2VudDogTW9uZGF5LCBKYW51YXJ5IDMwLCAyMDE3IDU6NTQgUE0NClRvOiBqb3VuaS5ub3NwYW0g PGpvdW5pLm5vc3BhbUBnbWFpbC5jb20+DQpDYzogQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNp c2NvLmNvbT47IFRvbWVrIE1ydWdhbHNraSA8dG9tYXN6Lm1ydWdhbHNraUBnbWFpbC5jb20+OyBk aGN3Z0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5LmFsbEBp ZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgSm91bmkgS29yaG9uZW4gPGpvdW5pa29yQGdtYWlsLmNv bT47IGludC1kaXJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZGhjd2ddIFtJbnQtZGlyXSBSZXZp ZXcgb2YgZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5LTAyDQoNCk9uIEphbiAz MCwgMjAxNywgYXQgNToyMCBQTSwgam91bmkubm9zcGFtIDxqb3VuaS5ub3NwYW1AZ21haWwuY29t PG1haWx0bzpqb3VuaS5ub3NwYW1AZ21haWwuY29tPj4gd3JvdGU6DQpOb3cgaWYgSSBkZWNpZGUg dG8gaW1wbGVtZW50IHJmYzMzMTViaXMgKndpdGgqIHNlY3VyaXR5LCBmb2xsb3cgYWxsIG11c3Rz IGluIFNlY3Rpb24gMjAuMSwgYW5kIGxpc3RlZCDigJx1cGRhdGVz4oCdIGluIHRoZSBoZWFkZXIs IEkgaGF2ZSBzdGlsbCBubyBndWFyYW50ZWUgd2hldGhlciBJIGNhbiBpbnRlcm9wZXJhdGUgd2l0 aCBhbm90aGVyIHJmYzMzMTViaXMgaW1wbGVtZW50YXRpb24gYmVjYXVzZSBpdCBkZWNpZGVkIHRv IGZvbGxvdyByZWxheS1zZXJ2ZXItc2VjdXJpdHkuIFRoYXQgaXMgbm90IGdvb2QuDQoNClRoYW5r cy4gICBUaGlzIGlzIHRoZSBjbGFyaWZpY2F0aW9uIEkgd2FzIGxvb2tpbmcgZm9yLg0KDQo= --_000_3c6cc9adffe14172954e69195f05c5ddXCHALN003ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3Vs YXI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxl ZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE5NTE4ODkwMDg7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDEwODA5NzIwIC05ODIw NjQ3NjAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFy dC1hdDo0Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TGV0J3MgdGFrZSB0aGUgMzMxNWJpcyBvdXQgb2Yg dGhlIGRpc2N1c3Npb24gYXMgd2UgZG9uJ3QgeWV0IGtub3cgd2hlbiB0aGF0IHdpbGwgYmUgYXZh aWxhYmxlIGFuZCB3ZSdkIGxpa2UgdG8gcHJvZ3Jlc3Mgb24gdGhpcyBkcmFmdCBzb29uZXIgdGhh biB0aGF0IChhcyBpdA0KIGlzIHNob3J0ZXIgYW5kIGVhc2llciB0byBkbykuIFdlIGNhbiBnZXQg YmFjayB0byBpdCBsYXRlciwgYnV0IGxldOKAmXMgZm9jdXMgZmlyc3Qgb24gdG9kYXnigJlzIGlz c3VlIHdpdGggaXMgdGhlIGRvY3VtZW50IHdpdGggUkZDIDMzMTUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TbyBpZiB0aGlzIGlzIHJlbGVhc2VkIGFzIFJGQzk5 OTksIHRoZSBvbmx5IHdheSB5b3UgYXMgc29tZW9uZSBsb29raW5nIGZvciByZWxheSBvciBzZXJ2 ZXIgaW1wbGVtZW50YXRpb25zIChvciBib3RoKSBjb3VsZCBrbm93IHRoYXQgdGhpcyBpcyBzdXBw b3J0ZWQgaXMgYnkgYXNraW5nDQogdGhlIHN1cHBsaWVyIHdoZXRoZXIgdGhleSBzdXBwb3J0IFJG QzMzMTUgYW5kIFJGQzk5OTkuIFJGQzk5OTkgZG9lcyBub3QgaGF2ZSB1cCB1cGRhdGUgMzMxNS4g VGhpcyBpcyBqdXN0IGxpa2UgbWFueSBvZiB0aGUgb3RoZXIgREhDUCBSRkNzIHdoaWNoIGV4dGVu ZCB0aGUgZnVuY3Rpb25hbGl0eSDigJMgTGVhc2VxdWVyeSwgYnVsayBMZWFzZXF1ZXJ5LCBhY3Rp dmUgTGVhc2VxdWVyeSwgYW5kIHRoZSBtYW55IG9wdGlvbnMgZG9jdW1lbnRzLiBJZiB5b3UNCiB3 YW50IGNlcnRhaW4gZmVhdHVyZXMgYW5kIHRoZXkgYXJlIGluIG90aGVyIGRvY3VtZW50cywgeW91 IGhhdmUgdG8gc3BlY2lmeSB0aGUgY29tcGxldGUgbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNheWluZyBpdCB1cGRhdGVzIFJGQzMzMTUgZG9lc27igJl0 IGhlbHAgc2luY2UgdGhlcmUgYXJlIHBsZW50eSBvZiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMg dGhhdCBkb27igJl0IHN1cHBvcnQgSVBzZWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkJhY2sgdG8gUkZDIDMzMTUgYmlzIChkcmFmdC1pZXRmLWRoYy1yZmMzMzE1YmlzKSwg dGhhdCBpcyBzdGlsbCBhIHdvcmsgaW4gcHJvZ3Jlc3MuIE91ciBwbGFucyB0byBkYXRlIGFyZSB0 aGF0IHdl4oCZbGwgaW5jb3Jwb3JhdGUgYWxsIG9mIHRoZSBjaGFuZ2VzIG9mIGRyYWZ0LWlldGYt ZGhjLXJlbGF5LXNlcnZlci1zZWN1cml0eQ0KIGJ1dCBsZWF2ZSBpdCBPUFRJT05BTCB0byBpbXBs ZW1lbnQgSVBzZWMuIFRoaXMgbWVhbnMgdGhhdCBvbmNlIGRyYWZ0LWlldGYtZGhjLXJmYzMzMTVi aXMgaXMgcHVibGlzaGVkIGFzIGFuIFJGQywgdGhvc2UgdGhhdCB3YW50IElQc2VjIHdpbGwgaGF2 ZSB0byBjaGVjayB0aGF0IHRoZSBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0cyBib3RoIHRoZSBiaXMg UkZDIGFuZCBSRkM5OTk5IChvciB3aGF0ZXZlciBudW1iZXIpLiBCdXQgdGhhdOKAmXMgdGhlIHNh bWUNCiB0aGF0IHNvbWVvbmUgd2FudGluZyBMZWFzZXF1ZXJ5IG11c3QgZG8g4oCTIHRoZXnigJls bCBuZWVkIHRvIGNoZWNrIHRoYXQgdGhlIGJpcyBSRkMgYW5kIFJGQzUwMDcgYXJlIHN1cHBvcnRl ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBkcmFmdC1p ZXRmLWRoYy1yZmMzMzE1YmlzIGFuZC9vciBkcmFmdC1pZXRmLWRoYy1yZWxheS1zZXJ2ZXItc2Vj dXJpdHkgYXV0aG9ycyBjYW4gYWx3YXlzIHJhaXNlIGl0IHRvIHRoZSBESEMgV0cgdG8gc2VlIGlm IHRoZXJlIGlzIHN1ZmZpY2llbnQgY29uc2Vuc3VzIHRvDQogbWFrZSBJUHNlYyBhIE1VU1QgaW4g dGhlIGJpcyBkb2N1bWVudC4gQnV0IHRoZXJlIGhhc27igJl0IGJlZW4gaW4gdGhlIHBhc3QuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlcm5pZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVGVkIExlbW9uIFttYWlsdG86bWVsbG9uQGZ1 Z3VlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEphbnVhcnkgMzAsIDIwMTcgNTo1 NCBQTTxicj4NCjxiPlRvOjwvYj4gam91bmkubm9zcGFtICZsdDtqb3VuaS5ub3NwYW1AZ21haWwu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQmVybmllIFZvbHogKHZvbHopICZsdDt2b2x6QGNpc2Nv LmNvbSZndDs7IFRvbWVrIE1ydWdhbHNraSAmbHQ7dG9tYXN6Lm1ydWdhbHNraUBnbWFpbC5jb20m Z3Q7OyBkaGN3Z0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1kaGMtcmVsYXktc2VydmVyLXNlY3VyaXR5 LmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgSm91bmkgS29yaG9uZW4gJmx0O2pvdW5pa29y QGdtYWlsLmNvbSZndDs7IGludC1kaXJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtkaGN3Z10gW0ludC1kaXJdIFJldmlldyBvZiBkcmFmdC1pZXRmLWRoYy1yZWxheS1zZXJ2ZXIt c2VjdXJpdHktMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBKYW4gMzAsIDIwMTcsIGF0IDU6MjAgUE0sIGpvdW5pLm5vc3BhbSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmpvdW5pLm5vc3BhbUBnbWFpbC5jb20iPmpvdW5pLm5vc3BhbUBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtN ZW5sby1SZWd1bGFyJnF1b3Q7LHNlcmlmIj5Ob3cgaWYgSSBkZWNpZGUgdG8gaW1wbGVtZW50IHJm YzMzMTViaXMgKndpdGgqIHNlY3VyaXR5LCBmb2xsb3cgYWxsIG11c3RzIGluIFNlY3Rpb24gMjAu MSwgYW5kIGxpc3RlZCDigJx1cGRhdGVz4oCdIGluIHRoZSBoZWFkZXIsIEkgaGF2ZSBzdGlsbCBu byBndWFyYW50ZWUgd2hldGhlciBJIGNhbiBpbnRlcm9wZXJhdGUNCiB3aXRoIGFub3RoZXIgcmZj MzMxNWJpcyBpbXBsZW1lbnRhdGlvbiBiZWNhdXNlIGl0IGRlY2lkZWQgdG8gZm9sbG93IHJlbGF5 LXNlcnZlci1zZWN1cml0eS4gVGhhdCBpcyBub3QgZ29vZC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLiAm bmJzcDsgVGhpcyBpcyB0aGUgY2xhcmlmaWNhdGlvbiBJIHdhcyBsb29raW5nIGZvci48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3c6cc9adffe14172954e69195f05c5ddXCHALN003ciscocom_-- From nobody Tue Jan 31 10:38:36 2017 Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D75F129546; Tue, 31 Jan 2017 10:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv8Ur1j_I1GZ; Tue, 31 Jan 2017 10:38:24 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61EA4129447; Tue, 31 Jan 2017 10:38:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19278; q=dns/txt; s=iport; t=1485887904; x=1487097504; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vDqkMJwgR7RLr1gSCZpM4t/oHk4ZdhnESvmJZAh+vYo=; b=WdaPy99lDqcJj5Bd/w8ZvKN4cxLd6U6pMZmunrfZsCOigYGajswXOSRz TvxNVj0DirXxgkoK8bcwe01WKtvxr14DvwzOppnkL61gBKfFhXjccCecl NuJ6SMnKvW+mUAmFJhBx49SdrRwdV5d8het/d10Se/1tQqeppZl5EAl0p I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQAl2ZBY/4gNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm85K2GBCQeNWJIHiAqNKYINhiICgjU/GAECAQEBAQEBAWIohGk?= =?us-ascii?q?BAQEELUwQAgEIEQMBAQEoByERFAkIAgQBDQWJVgMVrlmHPQ2DaAEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2GS4RvglGBZTYWhS8Fj3SLKzgBjWmEFIF5jn+FZoJAggG?= =?us-ascii?q?IVwEfOIFLFTuGOXWHHoEMAQEB?= X-IronPort-AV: E=Sophos;i="5.33,315,1477958400"; d="scan'208,217";a="200972974" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 Jan 2017 18:38:22 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0VIcMlv003752 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 Jan 2017 18:38:22 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 31 Jan 2017 12:38:22 -0600 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 31 Jan 2017 12:38:21 -0600 From: "Yogendra Pal (yogpal)" To: "Bernie Volz (volz)" , Ted Lemon , "jouni.nospam" Thread-Topic: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-security-02 Thread-Index: AQHSd5+82dShQp2gUEerASIUIPJreqFK8haAgAA2QQCAAFA2gIAAAyOAgAAGBgCAAAf2AIABoSWAgAASNACABMZQAIAACZmAgAAEFICAAZjVgA== Date: Tue, 31 Jan 2017 18:38:21 +0000 Message-ID: References: <148541310715.6205.3276873953603821357.idtracker@ietfa.amsl.com> <367DE531-AF9C-40A3-8B1F-5F595D804023@gmail.com> <519FB5EF-52B0-4DEA-B670-2D2593C3FB66@fugue.com> <6DA7EAEF-C226-43E2-800A-9C3CB7F9FB6D@gmail.com> <3C1097F9-0F7A-4349-93E7-3A27BBDF1749@fugue.com> <24F2F434-05FE-4E71-A75E-55DF632EA1D8@gmail.com> <18BE1906-43BB-4505-A584-7A6F034852E3@fugue.com> <3c6cc9adffe14172954e69195f05c5dd@XCH-ALN-003.cisco.com> In-Reply-To: <3c6cc9adffe14172954e69195f05c5dd@XCH-ALN-003.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.42.134] Content-Type: multipart/alternative; boundary="_000_D4B6CD1221668yogpalciscocom_" MIME-Version: 1.0 Archived-At: Cc: "ietf@ietf.org" , "int-dir@ietf.org" , Tomek Mrugalski , Jouni Korhonen , "dhcwg@ietf.org" , "draft-ietf-dhc-relay-server-security.all@ietf.org" Subject: Re: [Int-dir] [dhcwg] Review of draft-ietf-dhc-relay-server-security-02 X-BeenThere: int-dir@ietf.org X-Mailman-Version: 2.1.17 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, 31 Jan 2017 18:38:27 -0000 --_000_D4B6CD1221668yogpalciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable With full due respect of conversation, I see Bernie's point, towards flexib= ility. For e.g: We see two operators primary wherein, device operator would= like to have base RFC3315 supported for n/w and security operator asking f= or security in n/w via RFC9999. Regards, Yogendra Pal From: "Bernie Volz (volz)" > Date: Tuesday, 31 January 2017 4:38 am To: Ted Lemon >, "jouni.nospam" <= jouni.nospam@gmail.com> Cc: Tomek Mrugalski >, "dhcwg@ietf.org" >, "draft-ietf-dhc-relay-server-security.all@ietf.org" >, "ietf@ietf.org" >, Jouni Korhonen = >, "int-dir@ietf.org" > Subject: RE: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-securi= ty-02 Resent-From: > Resent-To: >, Yogendra Pal >, >, >, >, Tomek Mrugalski > Resent-Date: Tuesday, 31 January 2017 4:39 am Hi: Let's take the 3315bis out of the discussion as we don't yet know when that= will be available and we'd like to progress on this draft sooner than that= (as it is shorter and easier to do). We can get back to it later, but let'= s focus first on today's issue with is the document with RFC 3315. So if this is released as RFC9999, the only way you as someone looking for = relay or server implementations (or both) could know that this is supported= is by asking the supplier whether they support RFC3315 and RFC9999. RFC999= 9 does not have up update 3315. This is just like many of the other DHCP RF= Cs which extend the functionality - Leasequery, bulk Leasequery, active Lea= sequery, and the many options documents. If you want certain features and t= hey are in other documents, you have to specify the complete list. Saying it updates RFC3315 doesn't help since there are plenty of existing i= mplementations that don't support IPsec. Back to RFC 3315 bis (draft-ietf-dhc-rfc3315bis), that is still a work in p= rogress. Our plans to date are that we'll incorporate all of the changes of= draft-ietf-dhc-relay-server-security but leave it OPTIONAL to implement IP= sec. This means that once draft-ietf-dhc-rfc3315bis is published as an RFC,= those that want IPsec will have to check that the implementation supports = both the bis RFC and RFC9999 (or whatever number). But that's the same that= someone wanting Leasequery must do - they'll need to check that the bis RF= C and RFC5007 are supported. The draft-ietf-dhc-rfc3315bis and/or draft-ietf-dhc-relay-server-security a= uthors can always raise it to the DHC WG to see if there is sufficient cons= ensus to make IPsec a MUST in the bis document. But there hasn't been in th= e past. - Bernie From: Ted Lemon [mailto:mellon@fugue.com] Sent: Monday, January 30, 2017 5:54 PM To: jouni.nospam > Cc: Bernie Volz (volz) >; Tomek Mruga= lski >; dhcwg= @ietf.org; draft-ietf-dhc-relay-server-security.all@= ietf.org; ietf@ie= tf.org; Jouni Korhonen >; int-dir@ietf.org Subject: Re: [dhcwg] [Int-dir] Review of draft-ietf-dhc-relay-server-securi= ty-02 On Jan 30, 2017, at 5:20 PM, jouni.nospam > wrote: Now if I decide to implement rfc3315bis *with* security, follow all musts i= n Section 20.1, and listed "updates" in the header, I have still no guarant= ee whether I can interoperate with another rfc3315bis implementation becaus= e it decided to follow relay-server-security. That is not good. Thanks. This is the clarification I was looking for. --_000_D4B6CD1221668yogpalciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <09A7AA1D7E477B468D0B2866EB781D0E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
With full due respect of conversation, I see Bernie’s point, tow= ards flexibility. For e.g: We see two operators primary wherein, device ope= rator would like to have base RFC3315 supported for n/w and security operat= or asking for security in n/w via RFC9999.

Regards, Yogendra Pal
From: "Bernie Volz (volz)"= ; <volz@cisco.com>
Date: Tuesday, 31 January 2017 4:38= am
To: Ted Lemon <mellon@fugue.com>, "jouni.nospam" <<= a href=3D"mailto:jouni.nospam@gmail.com">jouni.nospam@gmail.com>
Cc: Tomek Mrugalski <tomasz.mrugalski@gmail.com>, &quo= t;dhcwg@ietf.org" <dhcwg@ietf.org>, "draft-ietf-dhc-relay-server= -security.all@ietf.org" <d= raft-ietf-dhc-relay-server-security.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, Jouni Korhonen <jounikor@gmail.com>, "int-dir@ietf.org" <<= a href=3D"mailto:int-dir@ietf.org">int-dir@ietf.org>
Subject: RE: [dhcwg] [Int-dir] Revi= ew of draft-ietf-dhc-relay-server-security-02
Resent-From: <alias-bounces@ietf.org>
Resent-To: <volz@cisco.com>, Yogendra Pal <yogpal@cisco.com>, <tomasz.mrugalski@gmail.com>, <suresh.krishnan@ericsson.com>, <terry.manderson@icann.org= >, Tomek Mrugalski <tomasz.mrugalski@gmail.com>
Resent-Date: Tuesday, 31 January 20= 17 4:39 am

Hi:

 

Let's take the 3315bis out of the d= iscussion as we don't yet know when that will be available and we'd like to= progress on this draft sooner than that (as it is shorter and easier to do). We can get back to it later, but= let’s focus first on today’s issue with is the document with R= FC 3315.

 

So if this is released as RFC9999, = the only way you as someone looking for relay or server implementations (or= both) could know that this is supported is by asking the supplier whether they support RFC3315 and RFC9999. RFC999= 9 does not have up update 3315. This is just like many of the other DHCP RF= Cs which extend the functionality – Leasequery, bulk Leasequery, acti= ve Leasequery, and the many options documents. If you want certain features and they are in other documents, you have to = specify the complete list.

 

Saying it updates RFC3315 doesnR= 17;t help since there are plenty of existing implementations that don’= ;t support IPsec.

 

 

 

Back to RFC 3315 bis (draft-ietf-dh= c-rfc3315bis), that is still a work in progress. Our plans to date are that= we’ll incorporate all of the changes of draft-ietf-dhc-relay-server-security but leave it OPTIONAL to implement= IPsec. This means that once draft-ietf-dhc-rfc3315bis is published as an R= FC, those that want IPsec will have to check that the implementation suppor= ts both the bis RFC and RFC9999 (or whatever number). But that’s the same that someone wanting Lease= query must do – they’ll need to check that the bis RFC and RFC5= 007 are supported.

 

The draft-ietf-dhc-rfc3315bis and/o= r draft-ietf-dhc-relay-server-security authors can always raise it to the D= HC WG to see if there is sufficient consensus to make IPsec a MUST in the bis document. But there hasn’t= been in the past.

 

-