From nobody Wed Apr 6 04:53:37 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0125E12D7A5 for ; Wed, 6 Apr 2016 04:53:36 -0700 (PDT) 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 HdTBHTNx_98U for ; Wed, 6 Apr 2016 04:53:34 -0700 (PDT) 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 6B5F012D90A for ; Wed, 6 Apr 2016 04:53:33 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id u206so41978227wme.1 for ; Wed, 06 Apr 2016 04:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version; bh=mfNv5eh/YcUvEo0AqjtHEN7y0pHjqiQo5+8PizMo3wY=; b=MeOUzgM94bUnRP5/TkiEue5GntXjl914Ru73sZMjTOe3YRA+n/MKTdNQRN/4UA11Qy Vj80R67bZN6oEHMS5tQYJb79iRH1pkJm07HzifK4Ak0FQf5pxpB+wxQDGodTAdZf9Yfp IbhMG/fTCFodDPgF2XbhWYAyi4F9DgmZgiND+g4UFoamUgKSnkPfcIOYD2xxOkjDUiT0 DftEqG+/MaXjWs2zW65eE/PAHrJobc2aaOIQhYgtMIJ+vIvy6vJlhtBu8VRW226RBSqR hB/ij4/a0YN+0R+K135+zE4TLxc57D09hvybqQu2hGGMVhGIc9o0Ycc7PdJoicp2FzGk lIaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=mfNv5eh/YcUvEo0AqjtHEN7y0pHjqiQo5+8PizMo3wY=; b=UHz4oSdm3xgvqMOHwL5L75vQc8o4qtQrR19wpce/nCuKgXApjQ7dUAOv9SI4d7rLIi H24t3pd1/o70YAgu4KsbzFaRVd1wH7BGdpxpgwC2FYYusyw+qjAFTXZetuEuW8pyWesM GKI8p8c8+1nNudVNpMXxW4U3Um2u55PHCjqjZIWis7sXj+Fwi8+yjvUNywXqpKyMd0SF pya3fI9FJZPJRlGnnXaAqz3W17/fI33rLxvf6Brp2yeD46rjC3m1JJfjUohTKdGE+4Jk wt3D+ZRo4IydhT71mixt8fsoIAN9Wy10Xj5LYGQ8opyl0kZXkJRRZ+/SJ7t6x6E+xXkB oe8g== X-Gm-Message-State: AD7BkJLLy+WCoFbFh+kUtGGvMUXeIA/INDrVg4XluHtzPC8u1WRl+FMEUjHH0T7IG5aSvw== X-Received: by 10.194.84.66 with SMTP id w2mr29963472wjy.6.1459943611794; Wed, 06 Apr 2016 04:53:31 -0700 (PDT) Received: from ISOC-A1FD58.local ([92.109.65.245]) by smtp.googlemail.com with ESMTPSA id i11sm2878150wjn.36.2016.04.06.04.53.30 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 04:53:31 -0700 (PDT) To: sunset4@ietf.org From: Andrei Robachevsky Message-ID: <5704F8BA.20400@gmail.com> Date: Wed, 6 Apr 2016 13:53:30 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hO0gEUB4Rts9jrBDbkOjC42LLJovKBQi1" Archived-At: Subject: [sunset4] Mandating use of IPv6 in examples X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 11:53:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hO0gEUB4Rts9jrBDbkOjC42LLJovKBQi1 Content-Type: multipart/mixed; boundary="tePXL9J73MrMeF6ppE5FUKMrWtu8xS0tq" From: Andrei Robachevsky To: sunset4@ietf.org Message-ID: <5704F8BA.20400@gmail.com> Subject: Mandating use of IPv6 in examples --tePXL9J73MrMeF6ppE5FUKMrWtu8xS0tq Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I recently submitted an I-D draft-robachevsky-mandating-use-of-ipv6-examples-00.txt, mandating use of IPv6 in examples in RFCs. I was reading some pretty recent drafts and noticed that authors continue using IPv4 in their examples. This is probably more convenient, but is not really forward thinking. Also, the prevalence of IPv6 examples will send a strong message that IPv4 is essentially a legacy protocol. I wonder if this WG is interested in progressing this document as a WG item. Thanks, Andrei > Name: draft-robachevsky-mandating-use-of-ipv6-examples > Revision: 00 > Title: Mandating use of IPv6 in examples > Document date: 2016-03-21 > Group: Individual Submission > Pages: 3 > URL: https://www.ietf.org/internet-drafts/draft-robachevsky-= mandating-use-of-ipv6-examples-00.txt > Status: https://datatracker.ietf.org/doc/draft-robachevsky-mand= ating-use-of-ipv6-examples/ > Htmlized: https://tools.ietf.org/html/draft-robachevsky-mandating= -use-of-ipv6-examples-00 >=20 >=20 > Abstract: > IPv6 is a successor of the legacy IPv4 protocol. This document > mandates use of IPv6 in examples provided in RFCs. --tePXL9J73MrMeF6ppE5FUKMrWtu8xS0tq-- --hO0gEUB4Rts9jrBDbkOjC42LLJovKBQi1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlcE+LoACgkQljz5tZmtij82FACfTR0Hs3az7RCplnFwPcMECl+G OKQAnRjH+uRCCNclT22v/0wYYFsdkhjb =mTOe -----END PGP SIGNATURE----- --hO0gEUB4Rts9jrBDbkOjC42LLJovKBQi1-- From nobody Wed Apr 6 05:45:57 2016 Return-Path: X-Original-To: sunset4@ietfa.amsl.com Delivered-To: sunset4@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBCE12D09D for ; Wed, 6 Apr 2016 05:45:55 -0700 (PDT) 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, 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 Z7M76Jr8AUgE for ; Wed, 6 Apr 2016 05:45:52 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d: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 6B57A12D0A6 for ; Wed, 6 Apr 2016 05:45:52 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id k135so13070710qke.0 for ; Wed, 06 Apr 2016 05:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=KyR43nrK7SWX3UogKS8L969m+MVNb4Xv/5mNeeOpSj8=; b=0BH2y2/c/EYirRXq2wBmLDUAFIDuOTH3fo375g00hv9tMptusUEptISly4V1TkSKom ZzVhkZxTd8T520u8UCO4laZW5uF1IUA5YkltwGTPc+21shKFXOZCOfS6E8EmLPYozvkx RH9GKW/nq8A7xaOq7lkjd68eqRxHg6Biqkl7Ur6L/dQpQlliCJm26Q/TCWR2yWKMS/zY q/9fZnKSPhZjN6uwKT620L3W3c7ijEUa2FihHGJBg/zz1iguE63bRFYk54ZuE+o42CkO odARbDcdt6ekp9ziVYuwuUfgd9/k9tVfyw+Jy89lwdQ6ey//I9a+5ef331etZC/uiUuN pMAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=KyR43nrK7SWX3UogKS8L969m+MVNb4Xv/5mNeeOpSj8=; b=Dk3qs6O2RtrUu364TnNzTFIfLp0qydhneGo69hmxzXNw8j4YfR2F739dnkrwxr3d18 0J5gFgQXa1MRLU6Ky6efGJw6b7fUE+D1KhoHJE1osv60ODscp1l7/QFOOgpmYpEJtyrr 8vlh28qt3Jh4MNAwr1WotlvBX6s3+OHojNTG1d81hlWhZ+amzYWNyJaTU+xxboThXxbG NB6tRNfvRSYbogXEF4wLsVD7ny+jLkoM2HtvbDDXvocV2W3LW/8NgIhMWxUKQDN7oOJp nJCug5kKw4Sfjs5ZBsNGHD+5ARUydTX3uYp4YdvRSxTKHvTJjPVh9ffeEVTH21rrejDM YxTA== X-Gm-Message-State: AD7BkJKTtxIHgDcOj4wCmqb2L/JZUPIchOmvzxqbt777BTYNGgcNj+om3Yu3RX7MDvF0Ag== X-Received: by 10.55.54.14 with SMTP id d14mr29342020qka.64.1459946751490; Wed, 06 Apr 2016 05:45:51 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:ad59:f22d:f5cb:9753? ([2001:67c:370:176:ad59:f22d:f5cb:9753]) by smtp.googlemail.com with ESMTPSA id b74sm1191513qge.22.2016.04.06.05.45.48 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 05:45:49 -0700 (PDT) To: sunset4@ietf.org References: <5704F8BA.20400@gmail.com> From: Alejandro Acosta X-Enigmail-Draft-Status: N1110 Message-ID: <570504F7.1030708@gmail.com> Date: Wed, 6 Apr 2016 08:15:43 -0430 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <5704F8BA.20400@gmail.com> Content-Type: multipart/alternative; boundary="------------030200070401010305030904" Archived-At: Subject: Re: [sunset4] Mandating use of IPv6 in examples X-BeenThere: sunset4@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: sunset4 working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 12:45:55 -0000 This is a multi-part message in MIME format. --------------030200070401010305030904 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi, This makes sense to me. I totally agree. If I might suggest a minor change.., I would add in section 3 the text "section 4" after RFC 5952 [RFC5952]: --- RFC 5952 [RFC5952] section 4 recommends to use the compressed format for IPv6 address textual representation. For instance, leading zeros MUST be suppressed, the use of the symbol "::" MUST be used to its maximum capability and the characters "a", "b", "c", "d", "e", and "f" in an IPv6 address MUST be represented in lowercase. -- Regards, Alejandro, El 4/6/2016 a las 7:23 AM, Andrei Robachevsky escribió: > Hi, > > I recently submitted an I-D > draft-robachevsky-mandating-use-of-ipv6-examples-00.txt, mandating use > of IPv6 in examples in RFCs. > > I was reading some pretty recent drafts and noticed that authors > continue using IPv4 in their examples. This is probably more convenient, > but is not really forward thinking. Also, the prevalence of IPv6 > examples will send a strong message that IPv4 is essentially a legacy > protocol. > > I wonder if this WG is interested in progressing this document as a WG > item. > > Thanks, > > Andrei > > >> Name: draft-robachevsky-mandating-use-of-ipv6-examples >> Revision: 00 >> Title: Mandating use of IPv6 in examples >> Document date: 2016-03-21 >> Group: Individual Submission >> Pages: 3 >> URL: https://www.ietf.org/internet-drafts/draft-robachevsky-mandating-use-of-ipv6-examples-00.txt >> Status: https://datatracker.ietf.org/doc/draft-robachevsky-mandating-use-of-ipv6-examples/ >> Htmlized: https://tools.ietf.org/html/draft-robachevsky-mandating-use-of-ipv6-examples-00 >> >> >> Abstract: >> IPv6 is a successor of the legacy IPv4 protocol. This document >> mandates use of IPv6 in examples provided in RFCs. > > > _______________________________________________ > sunset4 mailing list > sunset4@ietf.org > https://www.ietf.org/mailman/listinfo/sunset4 --------------030200070401010305030904 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi,
  This makes sense to me.  I totally agree.
  If I might suggest a minor change.., I would add in section 3 the text "section 4" after RFC 5952 [RFC5952]:

---
RFC 5952 [RFC5952] section 4 recommends to use the compressed format for IPv6
   address textual representation.  For instance, leading zeros MUST be
   suppressed, the use of the symbol "::" MUST be used to its maximum
   capability and the characters "a", "b", "c", "d", "e", and "f" in an
   IPv6 address MUST be represented in lowercase.
-- 

Regards,

Alejandro,


El 4/6/2016 a las 7:23 AM, Andrei Robachevsky escribió:
Hi,

I recently submitted an I-D
draft-robachevsky-mandating-use-of-ipv6-examples-00.txt, mandating use
of IPv6 in examples in RFCs.

I was reading some pretty recent drafts and noticed that authors
continue using IPv4 in their examples. This is probably more convenient,
but is not really forward thinking. Also, the prevalence of IPv6
examples will send a strong message that IPv4 is essentially a legacy
protocol.

I wonder if this WG is interested in progressing this document as a WG
item.

Thanks,

Andrei



Name:		draft-robachevsky-mandating-use-of-ipv6-examples
Revision:	00
Title:		Mandating use of IPv6 in examples
Document date:	2016-03-21
Group:		Individual Submission
Pages:		3
URL:            https://www.ietf.org/internet-drafts/draft-robachevsky-mandating-use-of-ipv6-examples-00.txt
Status:         https://datatracker.ietf.org/doc/draft-robachevsky-mandating-use-of-ipv6-examples/
Htmlized:       https://tools.ietf.org/html/draft-robachevsky-mandating-use-of-ipv6-examples-00


Abstract:
   IPv6 is a successor of the legacy IPv4 protocol.  This document
   mandates use of IPv6 in examples provided in RFCs.


      

      

      

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


    

    

  


--------------030200070401010305030904--


From nobody Wed Apr  6 05:58:04 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E3112D1A8 for ; Wed,  6 Apr 2016 05:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=irs.gov
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 QB0988cFrDeW for ; Wed,  6 Apr 2016 05:58:01 -0700 (PDT)
Received: from emg4.irs.gov (emg4.irs.gov [IPv6:2610:30:2000:25::91]) (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 9B8A412D167 for ; Wed,  6 Apr 2016 05:58:01 -0700 (PDT)
Received: from MEM0200CP3XF01.ds.irsnet.gov (mem0200cp3xf01.ds.irsnet.gov [10.219.80.76]) by mem0200vprelay3.is.irs.gov (8.13.8/8.13.8) with ESMTP id u36Cvu11025752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Apr 2016 07:57:57 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irs.gov; s=irs-20130926; t=1459947477; bh=WLWJ/+Zslqxp+K5byJSF2g6/f2cbP4oSFfzbhGkDpD4=; h=From:To:Subject:Date:References:In-Reply-To; b=MkJZWgCqIIp0X/+qlfOeySocgexYWHYY+UScNH4fvXGQV2lPuMnS16lwn8s3aijIo E80oXibe80NpH0c5YLHQZe2IIHpgrBXo03Gu5s5os77blTIRkYzNcNdKLcHCcJ5P02 h4f5OH/oaW/E7cSqYreeQJUjeR0CFMpc4xsfbrNM=
Received: from MEM0200CP3XF03.ds.irsnet.gov (10.219.80.51) by MEM0200CP3XF01.ds.irsnet.gov (10.219.80.76) with Microsoft SMTP Server (TLS) id 14.3.279.2; Wed, 6 Apr 2016 07:57:56 -0500
Received: from MEM0200CP3XF01.ds.irsnet.gov ([fe80::fd56:8bb3:8512:7316]) by MEM0200CP3XF03.ds.irsnet.gov ([fe80::e551:8fb:d316:c8ab%15]) with mapi id 14.03.0279.002; Wed, 6 Apr 2016 07:57:56 -0500
From: Morizot Timothy S 
To: Andrei Robachevsky , "sunset4@ietf.org" 
Thread-Topic: [sunset4] Mandating use of IPv6 in examples
Thread-Index: AQHRj/r3GcXYuiiJb0KMGE36AljcaZ984iVw
Date: Wed, 6 Apr 2016 12:57:55 +0000
Message-ID: <968C470DAC25FB419E0159952F28F0C094ACAB23@MEM0200CP3XF01.ds.irsnet.gov>
References: <5704F8BA.20400@gmail.com>
In-Reply-To: <5704F8BA.20400@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.219.80.84]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [sunset4] Mandating use of IPv6 in examples
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Apr 2016 12:58:03 -0000

QW5kcmVpIFJvYmFjaGV2c2t5IDxhbmRyZWkucm9iYWNoZXZza3lAZ21haWwuY29tPiB3cm90ZToN
Cj5JIHdhcyByZWFkaW5nIHNvbWUgcHJldHR5IHJlY2VudCBkcmFmdHMgYW5kIG5vdGljZWQgdGhh
dCBhdXRob3JzDQo+Y29udGludWUgdXNpbmcgSVB2NCBpbiB0aGVpciBleGFtcGxlcy4gVGhpcyBp
cyBwcm9iYWJseSBtb3JlIGNvbnZlbmllbnQsDQo+YnV0IGlzIG5vdCByZWFsbHkgZm9yd2FyZCB0
aGlua2luZy4gQWxzbywgdGhlIHByZXZhbGVuY2Ugb2YgSVB2Ng0KPmV4YW1wbGVzIHdpbGwgc2Vu
ZCBhIHN0cm9uZyBtZXNzYWdlIHRoYXQgSVB2NCBpcyBlc3NlbnRpYWxseSBhIGxlZ2FjeQ0KPnBy
b3RvY29sLg0KDQpJIGFncmVlIHRoYXQgZXhhbXBsZXMgaW4gUkZDcyBzaG91bGQgYmUgcmVxdWly
ZWQgdG8gdXNlIElQdjYgZXhhbXBsZXMgKGFuZCBvcHRpb25hbGx5IGFsc28gaW5jbHVkZSBJUHY0
IGV4YW1wbGVzKS4gSWYgSVB2NiBpcyByZWFsbHkgdGhlIHN1Y2Nlc3NvciBzcGVjaWZpY2F0aW9u
LCB0aGVuIGNvbnRpbnVpbmcgdG8gcHVibGlzaCBSRkNzIHRoYXQgZG8gbm90IHByb3ZpZGUgZXhh
bXBsZXMgdXNpbmcgSVB2NiBpcyBhY3R1YWxseSBhIGRpc3NlcnZpY2UgdG8gdGhlIGNvbW11bml0
eS4gSXQgc2VlbXMgbGlrZSBhIHNlbnNpYmxlIHN0ZXAuDQoNCk9uZSBzbWFsbCBxdWliYmxlLCB0
aG91Z2guIEknbSBub3Qgc3VyZSB0aGF0IHRoZSBzZWN0aW9uIG9uIElQdjYgYWRkcmVzc2VzIHdp
dGggcG9ydHMgYWNjdXJhdGVseSByZWZsZWN0cyBSRkM1OTUyIGFuZCBSRkMzOTg2LiBUaGUgYnJh
Y2tldCBub3RhdGlvbiBNVVNUIGJlIHVzZWQgaWYgaXQgcmVwcmVzZW50cyBhIFVSSSBsaXRlcmFs
LiBJbiBvdGhlciBpbnN0YW5jZXMsIGl0IFNIT1VMRCBiZSB1c2VkIChhcyB0aGUgZHJhZnQgaW5k
aWNhdGVzKSwgYnV0IG90aGVyIGZvcm1hdHMgYXJlIGFjY2VwdGFibGUuIFBlb3BsZSBtYXkgdXNl
IHRoaXMgZG9jdW1lbnQgd2hlbiBkZXZlbG9waW5nIGV4YW1wbGVzIHdpdGhvdXQgcmVmZXJyaW5n
IHRvIHRoZSByZWZlcmVuY2UsIHNvIHRoZSBleHBsaWNpdCByZXF1aXJlbWVudCBzaG91bGQgYmUg
bm90ZWQuIChBbmQgSSB0aGluayB0aGUgY29udmVudGlvbiBpcyB0aGF0IHRoZSAnU0hPVUxEJyBz
aG91bGQgYmUgY2FwaXRhbGl6ZWQuKSBTbyBwZXJoYXBzIHNvbWV0aGluZyBsaWtlIHRoZSBmb2xs
b3dpbmcgdGV4dC4NCg0KIklQdjYgYWRkcmVzc2VzIGluY2x1ZGluZyBhIHBvcnQgbnVtYmVyIFNI
T1VMRCB1c2UgdGhlIGJyYWNrZXQgbm90YXRpb24gc3R5bGUgW1JGQzU5NTJdLiBVUkkgZXhhbXBs
ZXMgY29udGFpbmluZyBhbiBJUHY2IGxpdGVyYWwgTVVTVCB1c2UgZW5jbG9zZSBpdCBpbiBicmFj
a2V0cyBbUkZDMzk4Nl0uIg0KDQpBbmQgdGhlbiBwcm92aWRlIHRoZSBleGFtcGxlLiBJJ20gc3Vy
ZSBpdCBjb3VsZCBiZSBwaHJhc2VkIGJldHRlciB0aGFuIHRoZSBhYm92ZS4gSXQncyBlYXJseSB5
ZXQuIEJ1dCB0aGUgaWRlYSBpcyB0aGF0IHNvbWVvbmUgcmVhZGluZyB0aGlzIGRvY3VtZW50IHNo
b3VsZCBrbm93IHRoZXJlIGFyZSBzaXR1YXRpb25zIHdoZXJlIHRoZSBicmFja2V0IG5vdGF0aW9u
IGlzIGFjdHVhbGx5IHJlcXVpcmVkLg0KDQpTY290dCANCg==


From nobody Wed Apr  6 06:12:15 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD9112D0C7 for ; Wed,  6 Apr 2016 06:12:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 Ky49ZUh0BkOO for ; Wed,  6 Apr 2016 06:12:10 -0700 (PDT)
Received: from mail.consulintel.com (mail.consulintel.com [213.0.69.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74BC12D517 for ; Wed,  6 Apr 2016 06:11:39 -0700 (PDT)
X-MDAV-Processed: mail.consulintel.com, Wed, 06 Apr 2016 15:11:37 +0200
Received: from [10.10.10.26] by mail.consulintel.com (MDaemon PRO v11.0.3) with ESMTP id md50000387353.msg for ; Wed, 06 Apr 2016 15:11:36 +0200
X-Spam-Processed: mail.consulintel.com, Wed, 06 Apr 2016 15:11:36 +0200 (not processed: spam filter heuristic analysis disabled)
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Return-Path: prvs=1904b28184=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: sunset4@ietf.org
User-Agent: Microsoft-MacOutlook/0.0.0.160212
Date: Wed, 06 Apr 2016 10:11:27 -0300
From: JORDI PALET MARTINEZ 
To: 
Message-ID: 
Thread-Topic: [sunset4] Mandating use of IPv6 in examples
References: <5704F8BA.20400@gmail.com> <570504F7.1030708@gmail.com>
In-Reply-To: <570504F7.1030708@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [sunset4] Mandating use of IPv6 in examples
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Apr 2016 13:12:14 -0000

+1

Saludos,
Jordi









-----Mensaje original-----
De: sunset4  en nombre de Alejandro Acosta 
Responder a: 
Fecha: mi=C3=A9rcoles, 6 de abril de 2016, 9:45
Para: 
Asunto: Re: [sunset4] Mandating use of IPv6 in examples

>
> =20
>   =20
> =20
> =20
>    Hi,
>        This makes sense to me.  I totally agree.
>        If I might suggest a minor change.., I would add in section 3
>      the text "section 4" after RFC 5952 [RFC5952]:
>     =20
>      ---
>      RFC 5952 [RFC5952] section 4 recommends to use the compressed
>      format for IPv6
>         address textual representation.  For instance, leading zeros
>      MUST be
>         suppressed, the use of the symbol "::" MUST be used to its
>      maximum
>         capability and the characters "a", "b", "c", "d", "e", and "f"
>      in an
>         IPv6 address MUST be represented in lowercase.
>      -- =20
>     =20
>      Regards,
>     =20
>      Alejandro,
>     =20
>     =20
>      El 4/6/2016 a las 7:23 AM, Andrei Robachevsky escribi=C3=B3:
>   =20
>   =20
>      Hi,
>
>I recently submitted an I-D
>draft-robachevsky-mandating-use-of-ipv6-examples-00.txt, mandating use
>of IPv6 in examples in RFCs.
>
>I was reading some pretty recent drafts and noticed that authors
>continue using IPv4 in their examples. This is probably more convenient,
>but is not really forward thinking. Also, the prevalence of IPv6
>examples will send a strong message that IPv4 is essentially a legacy
>protocol.
>
>I wonder if this WG is interested in progressing this document as a WG
>item.
>
>Thanks,
>
>Andrei
>
>
>
>     =20
>        Name:		draft-robachevsky-mandating-use-of-ipv6-examples
>Revision:	00
>Title:		Mandating use of IPv6 in examples
>Document date:	2016-03-21
>Group:		Individual Submission
>Pages:		3
>URL:            https://www.ietf.org/internet-drafts/draft-robachevsky-man=
dating-use-of-ipv6-examples-00.txt
>Status:         https://datatracker.ietf.org/doc/draft-robachevsky-mandati=
ng-use-of-ipv6-examples/
>Htmlized:       https://tools.ietf.org/html/draft-robachevsky-mandating-us=
e-of-ipv6-examples-00
>
>
>Abstract:
>   IPv6 is a successor of the legacy IPv4 protocol.  This document
>   mandates use of IPv6 in examples provided in RFCs.
>
>     =20
>
>     =20
>     =20
>     =20
>     =20
>      _______________________________________________
>sunset4 mailing list
>sunset4@ietf.orghttps://www.ietf.org/mailman/listinfo/sunset4
>   =20
>
>   =20
> =20
>
>_______________________________________________
>sunset4 mailing list
>sunset4@ietf.org
>https://www.ietf.org/mailman/listinfo/sunset4



From nobody Wed Apr  6 06:46:15 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 404D112D580 for ; Wed,  6 Apr 2016 06:46:14 -0700 (PDT)
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, 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 w_1IV-0muKcm for ; Wed,  6 Apr 2016 06:46:04 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 12B4512D522 for ; Wed,  6 Apr 2016 06:46:01 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id o126so34134319iod.0 for ; Wed, 06 Apr 2016 06:46:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=zguK3A9tPZ0vvClxWHZ9iu9JkDiH69D4FqvWCShg1jk=; b=pKuoAB583ULMIxLUEua14HC3TiIlw6ncZf1IyilHswpnwaUs5h/ZPHBaNR50KM3NiC 4EpB2zlFWnjC5l/Ghqc3VqjW4sNOKqp954JDGyVXGPRGq0xGpJoUuzr+qtjLBJt+NciY pxGhZ+NUBNEWWSW7fh93ul8jE/8TzaMtiVOvUjzkkRTOBSk0Fg9l3FVQRCsBgvg9o6qg ac1A3z0aP8npjpXnPTsRkWnX25rcH+OTXOiSx86AaLsP763ZMC+Q4gOqCBjoo17JDqgd CFth00DO/3gcdCeQOa9yE+JGYY/kOct5HN1G0KhPhpmn4y7qZdvizPbMT6p+9pt0+0lu Kx7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zguK3A9tPZ0vvClxWHZ9iu9JkDiH69D4FqvWCShg1jk=; b=b2VGZMpGONB3UsFl5XlG/32LTal9lQkXfACNzuqaGmhSc5bVEZreGejTEHVPcC/PWm Zixobe7uYFeaf1pDQCnAw2QrX7Rlfg9B9tosCDLEGhigfIPEuZcRTssLbLQN1mZS4Nxm WSctXRNe5eLMxL5RpO8CCXDcFWjlZmHvIyOAcJI18daflc2H22auUUCBw40bMuILnJl2 oF56DVoxaQUuzg/eYMqZ83nJ9aJuymC5I/Fbg5MPzKymYLBJlO73AYzUj8ZBPmNKqWio qjCIMY339t94YG7y+AZFAwIVmZZ4IEukpKooRCmC1sKlUCs9Ali50G1vhEqsZ/FS6+xL yXeg==
X-Gm-Message-State: AD7BkJK4ifj7+S1QGJpLChOoDuQH15gnrMj6uoo1zvtJiqjezkZ0mWLN9LecVmT37j7O/DhwOhuosa98BjU0XQ==
X-Received: by 10.107.132.88 with SMTP id g85mr23154812iod.47.1459950360276; Wed, 06 Apr 2016 06:46:00 -0700 (PDT)
MIME-Version: 1.0
References: <5704F8BA.20400@gmail.com> <570504F7.1030708@gmail.com> 
In-Reply-To: 
From: Arturo Servin 
Date: Wed, 06 Apr 2016 13:45:50 +0000
Message-ID: 
To: jordi.palet@consulintel.es, sunset4@ietf.org
Content-Type: multipart/alternative; boundary=001a113f323c9d359f052fd12e11
Archived-At: 
Subject: Re: [sunset4] Mandating use of IPv6 in examples
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Apr 2016 13:46:14 -0000

--001a113f323c9d359f052fd12e11
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Andrei

I support your effort.

As someone that has tried in its own docs, I can tell that It won't be
easier as IPv6 addresses are a bit messier and longer than v4.

But worth the effort and I think is a good idea.

Regards
as



On Wed, 6 Apr 2016 at 14:12 JORDI PALET MARTINEZ 
wrote:

> +1
>
> Saludos,
> Jordi
>
>
>
>
>
>
>
>
>
> -----Mensaje original-----
> De: sunset4  en nombre de Alejandro Acosta <
> alejandroacostaalamo@gmail.com>
> Responder a: 
> Fecha: mi=C3=A9rcoles, 6 de abril de 2016, 9:45
> Para: 
> Asunto: Re: [sunset4] Mandating use of IPv6 in examples
>
> >
> >
> >
> >
> >
> >    Hi,
> >        This makes sense to me.  I totally agree.
> >        If I might suggest a minor change.., I would add in section 3
> >      the text "section 4" after RFC 5952 [RFC5952]:
> >
> >      ---
> >      RFC 5952 [RFC5952] section 4 recommends to use the compressed
> >      format for IPv6
> >         address textual representation.  For instance, leading zeros
> >      MUST be
> >         suppressed, the use of the symbol "::" MUST be used to its
> >      maximum
> >         capability and the characters "a", "b", "c", "d", "e", and "f"
> >      in an
> >         IPv6 address MUST be represented in lowercase.
> >      --
> >
> >      Regards,
> >
> >      Alejandro,
> >
> >
> >      El 4/6/2016 a las 7:23 AM, Andrei Robachevsky escribi=C3=B3:
> >
> >
> >      Hi,
> >
> >I recently submitted an I-D
> >draft-robachevsky-mandating-use-of-ipv6-examples-00.txt, mandating use
> >of IPv6 in examples in RFCs.
> >
> >I was reading some pretty recent drafts and noticed that authors
> >continue using IPv4 in their examples. This is probably more convenient,
> >but is not really forward thinking. Also, the prevalence of IPv6
> >examples will send a strong message that IPv4 is essentially a legacy
> >protocol.
> >
> >I wonder if this WG is interested in progressing this document as a WG
> >item.
> >
> >Thanks,
> >
> >Andrei
> >
> >
> >
> >
> >        Name:          draft-robachevsky-mandating-use-of-ipv6-examples
> >Revision:      00
> >Title:         Mandating use of IPv6 in examples
> >Document date: 2016-03-21
> >Group:         Individual Submission
> >Pages:         3
> >URL:
> https://www.ietf.org/internet-drafts/draft-robachevsky-mandating-use-of-i=
pv6-examples-00.txt
> >Status:
> https://datatracker.ietf.org/doc/draft-robachevsky-mandating-use-of-ipv6-=
examples/
> >Htmlized:
> https://tools.ietf.org/html/draft-robachevsky-mandating-use-of-ipv6-examp=
les-00
> >
> >
> >Abstract:
> >   IPv6 is a successor of the legacy IPv4 protocol.  This document
> >   mandates use of IPv6 in examples provided in RFCs.
> >
> >
> >
> >
> >
> >
> >
> >      _______________________________________________
> >sunset4 mailing list
> >sunset4@ietf.orghttps://www.ietf.org/mailman/listinfo/sunset4
> >
> >
> >
> >
> >
> >_______________________________________________
> >sunset4 mailing list
> >sunset4@ietf.org
> >https://www.ietf.org/mailman/listinfo/sunset4
>
>
> _______________________________________________
> sunset4 mailing list
> sunset4@ietf.org
> https://www.ietf.org/mailman/listinfo/sunset4
>

--001a113f323c9d359f052fd12e11
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Andrei

I support your effort.=C2=A0

As someone that has tried in its own docs, I can tell=
 that It won't be easier as IPv6 addresses are a bit messier and longer=
 than v4.

But worth the effort and I think is a go=
od idea.

Regards
as

=



On Wed=
, 6 Apr 2016 at 14:12 JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
+1



Saludos,

Jordi



















-----Mensaje original-----

De: sunset4 <sunset4-bounces@ietf.org> en nombre de Alejandro Acosta <alejandroaco=
staalamo@gmail.com>

Responder a: <alejandroacostaalamo@gmail.com>

Fecha: mi=C3=A9rcoles, 6 de abril de 2016, 9:45

Para: <sunset4@iet=
f.org>

Asunto: Re: [sunset4] Mandating use of IPv6 in examples



>

>

>

>

>

>=C2=A0 =C2=A0 Hi,

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 This makes sense to me.=C2=A0 I totally agr=
ee.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 If I might suggest a minor change.., I woul=
d add in section 3

>=C2=A0 =C2=A0 =C2=A0 the text "section 4" after RFC 5952 [RFC=
5952]:

>

>=C2=A0 =C2=A0 =C2=A0 ---

>=C2=A0 =C2=A0 =C2=A0 RFC 5952 [RFC5952] section 4 recommends to use the=
 compressed

>=C2=A0 =C2=A0 =C2=A0 format for IPv6

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0address textual representation.=C2=A0=
 For instance, leading zeros

>=C2=A0 =C2=A0 =C2=A0 MUST be

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0suppressed, the use of the symbol &qu=
ot;::" MUST be used to its

>=C2=A0 =C2=A0 =C2=A0 maximum

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0capability and the characters "a=
", "b", "c", "d", "e", and &qu=
ot;f"

>=C2=A0 =C2=A0 =C2=A0 in an

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPv6 address MUST be represented in l=
owercase.

>=C2=A0 =C2=A0 =C2=A0 --

>

>=C2=A0 =C2=A0 =C2=A0 Regards,

>

>=C2=A0 =C2=A0 =C2=A0 Alejandro,

>

>

>=C2=A0 =C2=A0 =C2=A0 El 4/6/2016 a las 7:23 AM, Andrei Robachevsky escr=
ibi=C3=B3:

>

>

>=C2=A0 =C2=A0 =C2=A0 Hi,

>

>I recently submitted an I-D

>draft-robachevsky-mandating-use-of-ipv6-examples-00.txt, mandating use<=
br>
>of IPv6 in examples in RFCs.

>

>I was reading some pretty recent drafts and noticed that authors

>continue using IPv4 in their examples. This is probably more convenient=
,

>but is not really forward thinking. Also, the prevalence of IPv6

>examples will send a strong message that IPv4 is essentially a legacy
>protocol.

>

>I wonder if this WG is interested in progressing this document as a WG<=
br>
>item.

>

>Thanks,

>

>Andrei

>

>

>

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dra=
ft-robachevsky-mandating-use-of-ipv6-examples

>Revision:=C2=A0 =C2=A0 =C2=A0 00

>Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mandating use of IPv6 in exampl=
es

>Document date: 2016-03-21

>Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission

>Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03

>URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-dra=
fts/draft-robachevsky-mandating-use-of-ipv6-examples-00.txt

>Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-robachevs=
ky-mandating-use-of-ipv6-examples/

>Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-robachevsky-mandating-=
use-of-ipv6-examples-00

>

>

>Abstract:

>=C2=A0 =C2=A0IPv6 is a successor of the legacy IPv4 protocol.=C2=A0 Thi=
s document

>=C2=A0 =C2=A0mandates use of IPv6 in examples provided in RFCs.

>

>

>

>

>

>

>

>=C2=A0 =C2=A0 =C2=A0 _______________________________________________
>sunset4 mailing list

>sunset4@ietf.orghttps://www.ietf.org/mailman/listinf=
o/sunset4

>

>

>

>

>

>_______________________________________________

>sunset4 mailing list

>sunset4@ietf.org<=
/a>

>https://www.ietf.org/mailman/listinfo/sunset4




_______________________________________________

sunset4 mailing list

sunset4@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/sunset4




--001a113f323c9d359f052fd12e11--


From nobody Wed Apr  6 07:23:22 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC4A12D66E for ; Wed,  6 Apr 2016 07:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 Oa2gWbadG73x for ; Wed,  6 Apr 2016 07:23:07 -0700 (PDT)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001: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 46E7D12D62F for ; Wed,  6 Apr 2016 07:23:04 -0700 (PDT)
Received: by mail-ig0-x22e.google.com with SMTP id gy3so79360514igb.0 for ; Wed, 06 Apr 2016 07:23:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=V8mEN1XPq99xpirObL1fB/kt2J7xoN0JXR1hNe38JMM=; b=hubKCP6aiLUi50PfKGkHrPD7JgukQudBZMkBUH0IFbKMU22Qq5I+bB3QymSndWctJt ni2BJk2hZ8CToXifbo6sRMsRmsAXIuFFsdgIEfc+TLDX/r/50HeXBr804jC+LJljgE0I e9TcgbiGUXp+SMHj5uJcvOerrS2nMFPPmGc4cdWhEf/tVaaRCaED1uQCs4xKLJINch+m NDgGmrMRexse8DclxuUzrdUC1eT+FyYMOMwhBS/tjl3Q+35aSNQgZ8MQ0g8yq7G72n32 ioq019yeXNgjczgYNzY4MrBs65ZMsZ1gd2WmHK1ijyySbvfYC34Pcicjl6wL8a7osbcG LbJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=V8mEN1XPq99xpirObL1fB/kt2J7xoN0JXR1hNe38JMM=; b=KxoslODQ37u3EQgr2h9SLnR2/prIE2EsAUj7B7U/NRBgOw7OOiuOIxJlW2lwdGGgCz G6SYgefwCHklzruIUPvN5AXqp60zrDtS7aJ14tYacOpFjTnrld+2GZz1X3iIjEwqdrRw ++ElJaU+5rT2Q4LQHdQMZIloRBUrgdWYzIF126RQAPVJRi1dsahG33EkcSnlP8/bWzWx cYtvt6lEKIHZdHesU3QG1dbHZi83ZefcZoU5qbZWb6hqD5Z9CKoFfxYHon3k3q2XUSxK 4mlPZCl/HgBDfUEIJk6gfLRn4/1UJy2pfDJ9WAox/JKIPtuHbGnBHsn/qRdFYKDxWoef qNCw==
X-Gm-Message-State: AD7BkJI8SdSOdmee9K8vuBysAuXZJDRUDJtS7tB5N5MpJFm1gEIrF7xCFn3BMdpO270zJ/S1MYJYmNsnp9tmzg==
MIME-Version: 1.0
X-Received: by 10.50.241.13 with SMTP id we13mr914518igc.66.1459952583583; Wed, 06 Apr 2016 07:23:03 -0700 (PDT)
Sender: nygren@gmail.com
Received: by 10.107.200.14 with HTTP; Wed, 6 Apr 2016 07:23:03 -0700 (PDT)
In-Reply-To: 
References: <5704F8BA.20400@gmail.com> <570504F7.1030708@gmail.com>  
Date: Wed, 6 Apr 2016 11:23:03 -0300
X-Google-Sender-Auth: eLSCPD_X1Ui4WqmlCL5NFXAMgi8
Message-ID: 
From: Erik Nygren 
To: Arturo Servin 
Content-Type: multipart/alternative; boundary=f46d04289e0b22401d052fd1b3db
Archived-At: 
Cc: sunset4@ietf.org, jordi.palet@consulintel.es
Subject: Re: [sunset4] Mandating use of IPv6 in examples
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Apr 2016 14:23:19 -0000

--f46d04289e0b22401d052fd1b3db
Content-Type: text/plain; charset=UTF-8

+1

This seems worthwhile.  Anecdotally, I've seen that engineering teams which
include IPv6 examples in their design docs
(eg, showing sample configurations or sample config screens or test case
examples) seem much more likely
to properly implement and test IPv6 support as a first-class feature.

   Erik



On Wed, Apr 6, 2016 at 10:45 AM, Arturo Servin 
wrote:

>
> >I recently submitted an I-D
>> >draft-robachevsky-mandating-use-of-ipv6-examples-00.txt, mandating use
>> >of IPv6 in examples in RFCs.
>> >
>> >I was reading some pretty recent drafts and noticed that authors
>> >continue using IPv4 in their examples. This is probably more convenient,
>> >but is not really forward thinking. Also, the prevalence of IPv6
>> >examples will send a strong message that IPv4 is essentially a legacy
>> >protocol.
>>
>

--f46d04289e0b22401d052fd1b3db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


+1=C2=A0=C2=A0=C2=A0 

This seems worthwh=
ile.=C2=A0 Anecdotally, I've seen that engineering teams which include =
IPv6 examples in their design docs
(eg, showing sample configu=
rations or sample config screens or test case examples) seem much more like=
ly 
to properly implement and test IPv6 support as a first-cl=
ass feature.

=C2=A0=C2=A0 Erik



On Wed, Apr 6, 2016 a=
t 10:45 AM, Arturo Servin <arturo.servin@gmail.com> wr=
ote:


>I recently submitted an I-D

>draft-robachevsky-mandating-use-of-ipv6-examples-00.txt, mandating use<=
br>
>of IPv6 in examples in RFCs.

>

>I was reading some pretty recent drafts and noticed that authors

>continue using IPv4 in their examples. This is probably more convenient=
,

>but is not really forward thinking. Also, the prevalence of IPv6

>examples will send a strong message that IPv4 is essentially a legacy
>protocol.


--f46d04289e0b22401d052fd1b3db--


From nobody Wed Apr  6 07:38:08 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC48312D15F for ; Wed,  6 Apr 2016 07:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level: 
X-Spam-Status: No, score=-14.53 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 sXCIV_JleZqh for ; Wed,  6 Apr 2016 07:38:02 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F6C12D1E4 for ; Wed,  6 Apr 2016 07:37:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4503; q=dns/txt; s=iport; t=1459953478; x=1461163078; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=y2US4GinWrjMM0titroTDozVSt6UybRi9xn89zUs4Kw=; b=jySJLD275eCGusiXypiS09/Fyw6rWZolvJxOxcGVQrCclcNc60SpWyCX GoTXqT1tNsqqOA07RPpL9BF8bTAv0zalNxk7dZZ4MZBQWq9vZkfyW6bD8 xqB3jgsYzNvR3dGBTs7ofCNQVwvIJ/bXC1ye50TZmN0xvi0isvxCks4O5 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgCgHgVX/5tdJa1cgzdTfYVGqS6LV?= =?us-ascii?q?wENgXIXAQmEFYENSgKBSDgUAQEBAQEBAWUnhEIBAQQBAQFrCxACAQgEOwchBgs?= =?us-ascii?q?UEQIEDgWIEgMSDrtXDYR8AQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSIFoJWgkGCK?= =?us-ascii?q?4J+gisFl1AxAYwVgXWPDodHh1kBHgEBQoFMghtsiHMBAQE?=
X-IronPort-AV: E=Sophos;i="5.24,447,1454976000";  d="scan'208,217";a="258033540"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2016 14:37:57 +0000
Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u36EbvW8022219 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2016 14:37:57 GMT
Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Apr 2016 09:37:56 -0500
Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1104.009; Wed, 6 Apr 2016 09:37:56 -0500
From: "Joel Bion (jpbion)" 
To: Erik Nygren 
Thread-Topic: [sunset4] Mandating use of IPv6 in examples
Thread-Index: AQHRj/r3cEI0KtbylEuxPLxyAtJnY599OFKAgAAHMICAAAmcAIAACmaA//+wV68=
Date: Wed, 6 Apr 2016 14:37:56 +0000
Message-ID: <565EB659-02A0-4E86-8B46-FA00D6291016@cisco.com>
References: <5704F8BA.20400@gmail.com> <570504F7.1030708@gmail.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
Content-Type: multipart/alternative; boundary="_000_565EB65902A04E868B46FA00D6291016ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: Arturo Servin , "jordi.palet@consulintel.es" , "sunset4@ietf.org" 
Subject: Re: [sunset4] Mandating use of IPv6 in examples
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Apr 2016 14:38:07 -0000

--_000_565EB65902A04E868B46FA00D6291016ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Maybe because in doing so they show they can actually think natively with I=
Pv6 addresses? (You'd perhaps be surprised by the number of people I run in=
to even today who treat each v6 address like it's something they have to se=
nd through  a translator to understand).

Sent from my iPhone

On Apr 6, 2016, at 7:23 AM, Erik Nygren > wrote:

+1

This seems worthwhile.  Anecdotally, I've seen that engineering teams which=
 include IPv6 examples in their design docs
(eg, showing sample configurations or sample config screens or test case ex=
amples) seem much more likely
to properly implement and test IPv6 support as a first-class feature.

   Erik



On Wed, Apr 6, 2016 at 10:45 AM, Arturo Servin > wrote:

>I recently submitted an I-D
>draft-robachevsky-mandating-use-of-ipv6-examples-00.txt, mandating use
>of IPv6 in examples in RFCs.
>
>I was reading some pretty recent drafts and noticed that authors
>continue using IPv4 in their examples. This is probably more convenient,
>but is not really forward thinking. Also, the prevalence of IPv6
>examples will send a strong message that IPv4 is essentially a legacy
>protocol.
_______________________________________________
sunset4 mailing list
sunset4@ietf.org
https://www.ietf.org/mailman/listinfo/sunset4

--_000_565EB65902A04E868B46FA00D6291016ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable







Maybe because in doing so they show they can actually think natively w=
ith IPv6 addresses? (You'd perhaps be surprised by the number of people I r=
un into even today who treat each v6 address like it's something they have =
to send through  a translator to
 understand).




Sent from my iPhone




On Apr 6, 2016, at 7:23 AM, Erik Nygren <erik+ietf@nygren.org> wrote:












+1    





This seems worthwhile.  Anecdotally, I've seen that engineering teams =
which include IPv6 examples in their design docs




(eg, showing sample configurations or sample config screens or test ca=
se examples) seem much more likely





to properly implement and test IPv6 support as a first-class feature.<=
br>





   Erik













On Wed, Apr 6, 2016 at 10:45 AM, Arturo Servin <=
span dir=3D"ltr">
<arturo.ser=
vin@gmail.com> wrote:













>I recently submitted an I-D

>draft-robachevsky-mandating-use-of-ipv6-examples-00.txt, mandating use<=
br>
>of IPv6 in examples in RFCs.

>

>I was reading some pretty recent drafts and noticed that authors

>continue using IPv4 in their examples. This is probably more convenient=
,

>but is not really forward thinking. Also, the prevalence of IPv6

>examples will send a strong message that IPv4 is essentially a legacy
>protocol.




























_______________________________________________

sunset4 mailing list

sunset4@ietf.org

https://www=
.ietf.org/mailman/listinfo/sunset4








--_000_565EB65902A04E868B46FA00D6291016ciscocom_--


From nobody Wed Apr  6 07:46:35 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB82D12D5DE for ; Wed,  6 Apr 2016 07:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 tKQogrWCnCl5 for ; Wed,  6 Apr 2016 07:46:33 -0700 (PDT)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 C093812D5EA for ; Wed,  6 Apr 2016 07:46:30 -0700 (PDT)
Received: by mail-io0-x233.google.com with SMTP id q128so58700289iof.3 for ; Wed, 06 Apr 2016 07:46:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:date:message-id:subject:from:to; bh=S4SJz/Mc7OXG6HYY6ko8BahQrleA+bVYIv5p9RQ2GLc=; b=rG7iO3DQBm9ALpsmkiIhuwTKLHgoSRu+EJhOYyHgTC0Smvno74JWI4PZ5FCqetE6UB egICOf8q/FyqTmTFn4PrGnqdg6pzDWl107/c9OghsnwbfVidO7OJEUDqXucELDW3rfCH 5HneDKPiDteUbibC35FEJdSWcnqvss9L3qnHYtyfJ6sTz6mDdA6b5VVcKdELbHre1JPv r47aJr656hKwJ9zT+ZYDe+kEKh23VKbo63vovjbGLbWI6MvcuLHzBmv80zmfG37TiWyg ApHCZAVPmeSKEkHenjUbOBub4DFaBJdJPb3WQC0r1wVnLCM+hbvSlNw318BtCnU6ZJT3 GgSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to; bh=S4SJz/Mc7OXG6HYY6ko8BahQrleA+bVYIv5p9RQ2GLc=; b=TBWeuZq5yQQgDiYYhyZUMoexkAXKsowBPpRD6GO2ykcEFdbsWs6VUkAF4ogHGSw6Yg MeB7kTHOBpmYpgkRUsGhLmCNZifAlMEhmdbTMfMjplgE0MjhCWDsm/ei6lrp6tDsvnaG 8xEu9lMSN6awCdBF/h7DyXWhVAnDt6k8gm7Q6oj9J1a7JsHNxphSJkDptEaIaZ3Y7oP6 6jmla5EavdWCh6fd7a4hfl03lPknTQcKnuO8MUrnVRhDzs8TGfnf4I7zcLZMHEi+KQTo OzdtKnCCSUv83I8KUBExDUogz8OFI8ys5B/O6y9sU04RFYkhBzGA1Vxw1LMQ+gAll2/s qN6Q==
X-Gm-Message-State: AD7BkJKvGj5gcJx4NbfMJJA2z8wBoQDHXcJKViX1/AlbXU+SEflUZwxPIxpeJFNwX9OPZhH91Ce1jaQi4aRIcw==
MIME-Version: 1.0
X-Received: by 10.107.164.205 with SMTP id d74mr16050686ioj.80.1459953989906;  Wed, 06 Apr 2016 07:46:29 -0700 (PDT)
Sender: nygren@gmail.com
Received: by 10.107.200.14 with HTTP; Wed, 6 Apr 2016 07:46:29 -0700 (PDT)
Date: Wed, 6 Apr 2016 11:46:29 -0300
X-Google-Sender-Auth: et7-8yDEK3UlqlpHUhmP4H_QRjc
Message-ID: 
From: Erik Nygren 
To: sunset4@ietf.org
Content-Type: multipart/alternative; boundary=001a1141c8d4f4f817052fd20698
Archived-At: 
Subject: [sunset4] IPv4 to Historic: sending a directional message rather than changing state
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Apr 2016 14:46:34 -0000

--001a1141c8d4f4f817052fd20698
Content-Type: text/plain; charset=UTF-8

Starting a discussion thread here as suggested by Lee Howard in the the
session yesterday.

My sense of the comments in the room (while I don't remember a hum) was
that while it was still too early to advance "IPv4 to Historic", there
would be value in sending a clear message that we are on a path to move
IPv4 to Historic at some point in the future.  This could either be through
sunset4 or preferably by an IETF governance statement.

Some topics for discussion seemed to be:

* Should there be clear guidance to IETF WGs and other standards bodies
that it is acceptable to develop IPv6-only protocols without consideration
for IPv4?   (With the caveat that practical deployments may still have a
need to inter-operate with IPv4, if only as providing IPv4-as-a-service
over IPv6.)  Are there particular efforts (eg, 5G) where we should be
encouraging an "IPv6-first" mindset as part of the design, and is this
something we can do?

* Do we set a time-table for moving to Historic or base this off some
adoption metric?  (80% global IPv6 adoption?  IPv6-only deployments
becoming commonplace in multiple scenarios outside of a few large
companies?)

* Are there other things we can do to reduce the time-window where everyone
has to deal with full dual-stack complexity?  (For example, fixing issues
that remain with some of the transition technologies that allow for
IPv6-only connectivity with IPv4-as-a-service?)

* What would be a good thing to call this: directionally historic,
end-of-engineering, "It's Complicated", to-be-deprecated, ...     (In
particular, we need to make sure the statement made sets expectations but
is is inline with present reality.)

--001a1141c8d4f4f817052fd20698
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Starting a discussion thread here as suggested b=
y Lee Howard in the the session yesterday.

My sense of t=
he comments in the room (while I don't remember a hum) was that while i=
t was still too early to advance "IPv4 to Historic", there would =
be value in sending a clear message that we are on a path to move IPv4 to H=
istoric at some point in the future.=C2=A0 This could either be through sun=
set4 or preferably by an IETF governance statement.

Some topics for discussion seemed to be:

* Should there be clear=20
guidance to IETF WGs and other standards bodies that it is acceptable=20
to develop IPv6-only protocols without consideration for IPv4? =C2=A0 (With=
 the caveat that practical=20
deployments may still have a need to inter-operate with IPv4, if only as pr=
oviding IPv4-as-a-service over IPv6.)=C2=A0 Are there particu=
lar efforts (eg, 5G) where we should be encouraging an "IPv6-first&quo=
t; mindset as part of the design, and is this something we can do? 

=

* Do we set a time-table for moving to=
 Historic or base this off some adoption metric?=C2=A0 (80% global IPv6 ado=
ption?=C2=A0 IPv6-only deployments becoming commonplace in multiple scenari=
os outside of a few large companies?) 

* Are there other things we can do to reduce the time-window where =
everyone has to deal with full dual-stack complexity?=C2=A0 (For example, f=
ixing issues that remain with some of the transition technologies that allo=
w for IPv6-only connectivity with IPv4-as-a-service?)

* What would be a good thing to call this: directionally =
historic, end-of-engineering, "It's Complicated", to-be-depre=
cated, ...=C2=A0=C2=A0=C2=A0=C2=A0 (In particular, we need to make sure the=
 statement made sets expectations but is is inline with present reality.)





--001a1141c8d4f4f817052fd20698--


From nobody Wed Apr  6 08:00:28 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151EB12D6A1 for ; Wed,  6 Apr 2016 08:00:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Level: 
X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 amMOr5leyhmx for ; Wed,  6 Apr 2016 08:00:18 -0700 (PDT)
Received: from cdcipgw02.twcable.com (unknown [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id D5D7512D69F for ; Wed,  6 Apr 2016 08:00:08 -0700 (PDT)
X-SENDER-IP: 10.64.163.144
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.24,447,1454994000"; d="scan'208";a="542098117"
Received: from unknown (HELO exchpapp03.corp.twcable.com) ([10.64.163.144]) by cdcipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 06 Apr 2016 10:58:13 -0400
Received: from EXCHPAPP06.corp.twcable.com (10.64.163.147) by exchpapp03.corp.twcable.com (10.64.163.144) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Wed, 6 Apr 2016 10:59:48 -0400
Received: from EXCHPAPP06.corp.twcable.com ([10.64.163.147]) by EXCHPAPP06.corp.twcable.com ([10.64.163.147]) with mapi id 15.00.1156.000; Wed, 6 Apr 2016 10:59:48 -0400
From: "George, Wes" 
To: Andrei Robachevsky , "sunset4@ietf.org" 
Thread-Topic: [sunset4] Mandating use of IPv6 in examples
Thread-Index: AQHRkBT2PgYQ2HCln0af+DqHT7cPNg==
Date: Wed, 6 Apr 2016 14:59:48 +0000
Message-ID: 
References: <5704F8BA.20400@gmail.com>
In-Reply-To: <5704F8BA.20400@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.64.163.239]
x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22242.005
x-tm-as-result: No--43.283700-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="utf-8"
Content-ID: <5EAFA4905771274CB811865B65C81FD5@twcable.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [sunset4] Mandating use of IPv6 in examples
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Apr 2016 15:00:25 -0000

U3BlYWtpbmcgYXMgYW4gaW5kaXZpZHVhbDoNCg0KWW91J2QgdGhpbmsgdGhpcyB3b3VsZG4ndCBi
ZSBjb250cm92ZXJzaWFsLCBidXQgSSdtIG5vdCBjb252aW5jZWQgdGhhdA0KdGhpcyBzb3J0IG9m
IGJ1cmVhdWNyYXRpYyBmb3JtYXR0aW5nIHJ1bGUgaXMgcmVhbGx5IHRoZSByaWdodCBzb2x1dGlv
biB0bw0KZ2V0IElFVEYgYXMgYSB3aG9sZSBtb3JlIGZvY3VzZWQgb24gSVB2NiBhbmQgcmVpbmZv
cmNpbmcgdGhlIGlkZWEgdGhhdA0KSVB2NCBpcyBub3cgYSBsZWdhY3kgcHJvdG9jb2wuIFllcywg
aW5jcmVhc2luZyBleHBvc3VyZSBhbmQgZmFtaWxpYXJpdHkNCndpdGggSVB2NiBhZGRyZXNzZXMg
YnkgdXNpbmcgdGhlbSBtb3JlIGNvbnNpc3RlbnRseSBpcyBhIGdvb2QgdGhpbmcsIGFuZA0KaXQg
c2VlbXMgaGFybWxlc3MgdG8gc3VnZ2VzdCB0aGF0IHdlIGRvIHRoaXMsIGJ1dCBpdCdzIHRoZSB3
b3JkIG1hbmRhdGUNCnRoYXQgYm90aGVycyBtZS4NCg0KQSBtYW5kYXRlIGltcGxpZXMgdGhhdCB0
aGVyZSBpcyBzb21lIHNvcnQgb2YgcmVjb3Vyc2UgdG8gZm9yY2UgaXQgdG8gYmUNCmNoYW5nZWQg
aWYgcGVvcGxlIGRvbid0IGNvbXBseSwgYW5kIGEgcXVlc3Rpb24gb2Ygd2hvIGVuZm9yY2VzIGl0
IC0gdGhlDQpJRVNHPyBUaGUgUkZDIGVkaXRvcj8gSUROSVRzIGNoZWNrPyBUaGUgZG9jdW1lbnQg
c2hlcGhlcmQ/IE1ha2luZyB0aGlzIGENCnN1Z2dlc3Rpb24gbWVhbnMgdGhhdCBpdCBpcyBzb21l
dGhpbmcgdGhhdCBpcyBlbmZvcmNlZCB2aWEgcGVvcGxlIGxvb2tpbmcNCmF0IGRyYWZ0cyBkdXJp
bmcgcmV2aWV3cywgV0dMQywgSUVURiBMQywgZXRjIGFuZCBhc2tpbmcsICJpcyB0aGVyZSBhbnkN
CnJlYXNvbiB3aHkgdGhlc2UgZXhhbXBsZXMgYXJlIElQdjQ/IiBhbmQgZmFpbGluZyBhbnkgYWNj
ZXB0YWJsZQ0KanVzdGlmaWNhdGlvbiwgc3VnZ2VzdGluZyB0aGF0IHRoZXkgdXBkYXRlIHRoZSBl
eGFtcGxlcyB3aXRoIHRoZSBjdXJyZW50DQpwcm90b2NvbCB2ZXJzaW9uLiBJIHRoaW5rIHRoaXMg
aXMgdmVyeSBzaW1pbGFyIHRvIHdoYXQgaGFwcGVucyB3aGVuIHBlb3BsZQ0KdXNlIHJhbmRvbWx5
IGNob3NlbiBJUCBhZGRyZXNzZXMgb3IgQVNOcyBmb3IgZXhhbXBsZXMgaW5zdGVhZCBvZiB0aGUN
CnByb3BlciBkb2N1bWVudGF0aW9uIG9uZXMgLSBzb21lb25lIHBvaW50cyBvdXQgdGhhdCBhIGNo
YW5nZSBuZWVkcyB0byBiZQ0KbWFkZSwgYW5kIHdlIGFsbCBtb3ZlIG9uLiBUaGF0IG1pZ2h0IG1l
YW4gdGhhdCBpdCBkb2Vzbid0IGFjdHVhbGx5IG5lZWQgdG8NCnByb2dyZXNzIGFzIGFuIFJGQywg
aGF2aW5nIHNlcnZlZCBpdHMgcHVycG9zZSBhcyBhbiBJLUQgdG8gc3RhcnQgdGhlDQpkaXNjdXNz
aW9uLg0KSXQncyBhbHNvIHBvc3NpYmxlIHRoYXQgdGhlIHJpZ2h0IHBsYWNlIGZvciB0aGlzIGlz
IGluIHRoZSBSRkMgc3R5bGUNCmd1aWRlLCB0aG91Z2ggdGhhdCdzIHByb2JhYmx5IGEgbG9uZ2Vy
IGRpc2N1c3Npb24gc2luY2UgYXMgZmFyIGFzIEkgY2FuDQp0ZWxsLCB0aGUgc3R5bGUgZ3VpZGUg
ZG9lcyBub3QgY3VycmVudGx5IGhhdmUgYW55IHJlY29tbWVuZGF0aW9uIGFib3V0IHVzZQ0Kb2Yg
ZG9jdW1lbnRhdGlvbiBhZGRyZXNzZXMsIG5vIHJlZmVyZW5jZXMgdG8gUkZDIDY4OTAsIGV0Yy4g
YW5kIHNvIGFkZGluZw0KYSBkaXNjdXNzaW9uIGFib3V0IHdoaWNoICp0eXBlKiBvZiBkb2N1bWVu
dGF0aW9uIGFkZHJlc3NlcyB0byB1c2UgbWlnaHQgYmUNCmdvaW5nIHRvbyBmYXIuDQoNCg0KVG8g
dGhlIGNvbnRlbnQgb2YgdGhlIGRvY3VtZW50Og0KRnJvbSBhIHN0cmljdCBSRkMyMTE5IG5vcm1h
dGl2ZSBrZXl3b3JkIGludGVycHJldGF0aW9uLCBJJ20gZG9uJ3QgdGhpbmsNCnRoYXQgTVVTVCBp
cyB0aGUgcmlnaHQgd29yZCBoZXJlLCBzaW5jZSB5b3UgY2F2ZWF0IHRoYXQgTVVTVCB3aXRoDQoi
dW5sZXNzLi4uIg0KTVVTVCBkb2Vzbid0IGhhdmUgZXhjZXB0aW9ucy4gU0hPVUxEIGFuZCBNQVkg
ZG8uDQpTbyBJIHRoaW5rIHlvdSBwcm9iYWJseSB3YW50IGEgIlNIT1VMRC4uLiB1bmxlc3MiLiBB
bmQgdGhlcmUncyBhbHNvIHRoZQ0KcHJvYmxlbSB0aGF0IDIxMTkgd29yZHMgYXJlLCBieSBzdHJp
Y3Rlc3QgaW50ZXJwcmV0YXRpb24sIGludGVuZGVkIHRvDQpkZXNjcmliZSBiZWhhdmlvciB0aGF0
IGlzIHJlcXVpcmVkIGZvciBpbnRlcm9wZXJhYmlsaXR5LCBub3QgImVhdCB5b3VyDQp2ZWdldGFi
bGVzIiBpbXBlcmF0aXZlcywgYW5kIHBlb3BsZSB0ZW5kIHRvIHJhaXNlIG9iamVjdGlvbnMgdG8g
dGhlaXIgdXNlDQppbiB0aGUgbGF0dGVyIHdheS4gTm90IHNheWluZyB0aGF0IHRoZXJlIGFyZW4n
dCBkb2N1bWVudHMgdGhhdCB1c2UgMjExOSBhDQpsaXR0bGUgb2ZmLWxhYmVsLCBidXQgdGhlIGJ1
cmRlbiBvZiBqdXN0aWZpY2F0aW9uIGlzIGhpZ2hlci4NClBlcmhhcHMgUkZDIDY5MTkgaXMgYSBi
ZXR0ZXIgY2hvaWNlIGZvciB5b3VyIG5vcm1hdGl2ZSBrZXl3b3Jkcz8gOi0pDQoNClRoYW5rcywN
Cg0KV2VzDQoNCg0KDQoNCk9uIDQvNi8xNiwgNzo1MyBBTSwgInN1bnNldDQgb24gYmVoYWxmIG9m
IEFuZHJlaSBSb2JhY2hldnNreSINCjxzdW5zZXQ0LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm
IG9mIGFuZHJlaS5yb2JhY2hldnNreUBnbWFpbC5jb20+IHdyb3RlOg0KDQo+SGksDQo+DQo+SSBy
ZWNlbnRseSBzdWJtaXR0ZWQgYW4gSS1EDQo+ZHJhZnQtcm9iYWNoZXZza3ktbWFuZGF0aW5nLXVz
ZS1vZi1pcHY2LWV4YW1wbGVzLTAwLnR4dCwgbWFuZGF0aW5nIHVzZQ0KPm9mIElQdjYgaW4gZXhh
bXBsZXMgaW4gUkZDcy4NCj4NCj5JIHdhcyByZWFkaW5nIHNvbWUgcHJldHR5IHJlY2VudCBkcmFm
dHMgYW5kIG5vdGljZWQgdGhhdCBhdXRob3JzDQo+Y29udGludWUgdXNpbmcgSVB2NCBpbiB0aGVp
ciBleGFtcGxlcy4gVGhpcyBpcyBwcm9iYWJseSBtb3JlIGNvbnZlbmllbnQsDQo+YnV0IGlzIG5v
dCByZWFsbHkgZm9yd2FyZCB0aGlua2luZy4gQWxzbywgdGhlIHByZXZhbGVuY2Ugb2YgSVB2Ng0K
PmV4YW1wbGVzIHdpbGwgc2VuZCBhIHN0cm9uZyBtZXNzYWdlIHRoYXQgSVB2NCBpcyBlc3NlbnRp
YWxseSBhIGxlZ2FjeQ0KPnByb3RvY29sLg0KPg0KPkkgd29uZGVyIGlmIHRoaXMgV0cgaXMgaW50
ZXJlc3RlZCBpbiBwcm9ncmVzc2luZyB0aGlzIGRvY3VtZW50IGFzIGEgV0cNCj5pdGVtLg0KPg0K
PlRoYW5rcywNCj4NCj5BbmRyZWkNCj4NCj4NCj4+IE5hbWU6ZHJhZnQtcm9iYWNoZXZza3ktbWFu
ZGF0aW5nLXVzZS1vZi1pcHY2LWV4YW1wbGVzDQo+PiBSZXZpc2lvbjowMA0KPj4gVGl0bGU6TWFu
ZGF0aW5nIHVzZSBvZiBJUHY2IGluIGV4YW1wbGVzDQo+PiBEb2N1bWVudCBkYXRlOjIwMTYtMDMt
MjENCj4+IEdyb3VwOkluZGl2aWR1YWwgU3VibWlzc2lvbg0KPj4gUGFnZXM6Mw0KPj4gVVJMOg0K
Pj5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcm9iYWNoZXZza3kt
bWFuZGF0aW5nLXVzZS1vZi1pDQo+PnB2Ni1leGFtcGxlcy0wMC50eHQNCj4+IFN0YXR1czoNCj4+
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcm9iYWNoZXZza3ktbWFuZGF0
aW5nLXVzZS1vZi1pcHY2LQ0KPj5leGFtcGxlcy8NCj4+IEh0bWxpemVkOg0KPj5odHRwczovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcm9iYWNoZXZza3ktbWFuZGF0aW5nLXVzZS1vZi1pcHY2
LWV4YW1wDQo+Pmxlcy0wMA0KPj4NCj4+DQo+PiBBYnN0cmFjdDoNCj4+ICAgIElQdjYgaXMgYSBz
dWNjZXNzb3Igb2YgdGhlIGxlZ2FjeSBJUHY0IHByb3RvY29sLiAgVGhpcyBkb2N1bWVudA0KPj4g
ICAgbWFuZGF0ZXMgdXNlIG9mIElQdjYgaW4gZXhhbXBsZXMgcHJvdmlkZWQgaW4gUkZDcy4NCj4N
Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUaGlzIEUtbWFpbCBhbmQg
YW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9w
cmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBv
ciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRo
aXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh
bCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg
aW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmll
ZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlv
biB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRv
IHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4g
SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg
dGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5h
bCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg==


From nobody Wed Apr  6 09:07:31 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C68E12D52A for ; Wed,  6 Apr 2016 09:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level: 
X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 4bVB-ZF_eD5w for ; Wed,  6 Apr 2016 09:07:28 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5CB12D528 for ; Wed,  6 Apr 2016 09:07:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3143; q=dns/txt; s=iport; t=1459958848; x=1461168448; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=b6ANWD199SI5TCe8QE4BWWgNNWA7g2r0qOSsupY/TIU=; b=H1VRVAmA87sgaTARTssrcQqyibaiMoOoYlNDr/Mv/0joGRPX3q2RxfSc snrFwqrxIBbT5fIMH/FpfZTKnk9P1764XKbmnhJW1yBWmqUyxei00MlIe gOpMuz4iiIdmjTdC9fNPEuNIQArPI7oMKOp+0sPbDogqnku5SuLMRk94D U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQC8MwVX/4UNJK1cgzdTfbpLAQ2Bc?= =?us-ascii?q?hcKhSJKAoFJOBQBAQEBAQEBZSeEQQEBAQMBAQEBNzQLBQsCAQgYHhAnCyUCBA4?= =?us-ascii?q?FGogFCA7BAwEBAQEBAQEBAQEBAQEBAQEBAQEBAREEiBaCVoQ9gy2CKwWYAQGOC?= =?us-ascii?q?o8OjyABHgEBQoIygTVsiHMBAQE?=
X-IronPort-AV: E=Sophos;i="5.24,447,1454976000"; d="scan'208";a="257391373"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Apr 2016 16:07:27 +0000
Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u36G7Rkn019676 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Apr 2016 16:07:27 GMT
Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 6 Apr 2016 11:07:26 -0500
Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1104.009; Wed, 6 Apr 2016 11:07:26 -0500
From: "Joel Bion (jpbion)" 
To: Erik Nygren 
Thread-Topic: [sunset4] IPv4 to Historic: sending a directional message rather than changing state
Thread-Index: AQHRkBMxXVzzuUJ6dkacNIoEYEGGpZ99HKz3
Date: Wed, 6 Apr 2016 16:07:26 +0000
Message-ID: <10BC5730-BBC1-4BC0-B7D4-FA7FE311599A@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
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "sunset4@ietf.org" 
Subject: Re: [sunset4] IPv4 to Historic: sending a directional message rather than changing state
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Apr 2016 16:07:30 -0000

I have a hunch if IPv4 isn't declared historic now, that a year from now yo=
u'll be in exactly the same place w.r.t. people saying "not yet"=20

"Directionally historic" etc describes the truth of IPv4 for 20 years now -=
 so declaring such a thing is the equivalent of me saying "I will die somed=
ay" - not news, and nobody's behavior changes as a result of me saying this=
.=20

The goal of declaring IPv4 historic is not to report on an already achieved=
 truth but to create behavioral change. To make it so that it is harder to =
do new v4 things and well near impossible to do new v4 only things.

If your goal is to accelerate v6 adoption and usage, start from that positi=
on of strength (declare v4 historic) and skillfully and non-pedantically ma=
ke exceptions as the world needs them. Show grace in allowing new v4 techno=
logies and changes if they hasten and ease transition to v6.

If your goal is to prolong the fence sitting, delay declaring v4 historic, =
because I can see *zero* value in saying "v4 will be historic someday and w=
e are moving there"=20

Sent from my iPhone

> On Apr 6, 2016, at 7:47 AM, Erik Nygren  wrote:
>=20
> Starting a discussion thread here as suggested by Lee Howard in the the s=
ession yesterday.
>=20
> My sense of the comments in the room (while I don't remember a hum) was t=
hat while it was still too early to advance "IPv4 to Historic", there would=
 be value in sending a clear message that we are on a path to move IPv4 to =
Historic at some point in the future.  This could either be through sunset4=
 or preferably by an IETF governance statement.
>=20
> Some topics for discussion seemed to be:
>=20
> * Should there be clear guidance to IETF WGs and other standards bodies t=
hat it is acceptable to develop IPv6-only protocols without consideration f=
or IPv4?   (With the caveat that practical deployments may still have a nee=
d to inter-operate with IPv4, if only as providing IPv4-as-a-service over I=
Pv6.)  Are there particular efforts (eg, 5G) where we should be encouraging=
 an "IPv6-first" mindset as part of the design, and is this something we ca=
n do?=20
>=20
> * Do we set a time-table for moving to Historic or base this off some ado=
ption metric?  (80% global IPv6 adoption?  IPv6-only deployments becoming c=
ommonplace in multiple scenarios outside of a few large companies?)=20
>=20
> * Are there other things we can do to reduce the time-window where everyo=
ne has to deal with full dual-stack complexity?  (For example, fixing issue=
s that remain with some of the transition technologies that allow for IPv6-=
only connectivity with IPv4-as-a-service?)
>=20
> * What would be a good thing to call this: directionally historic, end-of=
-engineering, "It's Complicated", to-be-deprecated, ...     (In particular,=
 we need to make sure the statement made sets expectations but is is inline=
 with present reality.)
>=20
>=20
>=20
> _______________________________________________
> sunset4 mailing list
> sunset4@ietf.org
> https://www.ietf.org/mailman/listinfo/sunset4


From nobody Wed Apr  6 09:40:47 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC9C12D0BD for ; Wed,  6 Apr 2016 09:40:46 -0700 (PDT)
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, 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 KvJtD48qMg6o for ; Wed,  6 Apr 2016 09:40:42 -0700 (PDT)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::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 6588112D162 for ; Wed,  6 Apr 2016 09:40:42 -0700 (PDT)
Received: by mail-ig0-x230.google.com with SMTP id g8so47218981igr.0 for ; Wed, 06 Apr 2016 09:40:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sSggblDMQK46CKlRLuGauhSQSdsK/KIvA4WmuFwJZAw=; b=YmdhUiyxzcyiBE2c/e0bjwEAHTpcHqmAimmCnSMmDopFnIr9/i90o6VvcfpfynluT7 y7/vfD9AzBRTbHr49sEdkSeMGd0wKy28Yj+AEEYcvBDKg16zuQXa7giv2HGyNi5C9wrX rBfM2R/O5RPaamJqrN/ABbbxZXu+GGRn5SbazNo5Nf2OuxoxNlw0XCc3fitLBXzGT0hr gF7k80y/4VBjB0soFMPbBVKmyDXFnweitFDzDSyrCk33wLlAz/JtV453lcOE35zvCgpn 6+Y639tZAThVs8tqhv3si7ZxWV94nv9MvSsKyLgTbdDjzNotOROoHHARFlqM/R/ymq2z cq2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sSggblDMQK46CKlRLuGauhSQSdsK/KIvA4WmuFwJZAw=; b=HKRfxPYohL/hNca2TIQ3qbZHfG8WINw4+Tdq2rm689ufizZGimv9qmJEbcmsVTgV/+ jPWhmAz5o/UhejcY58/Ge3BtoXhyTlfMufFGzu4rjaFEq3bL7YhO6Xj65LywpltJf9b3 w1UQLdBMfhqFt4E3lHGkGgQ4r7mzK5I3Zw5Yq+K2FOcbD7NuaNiLhyyc6SjYmS+8F3Fb PDpaFRdhx2+SBlMWMW9gviHI01+c1EUC1wfofMHZBjqkslJK2HmCR3HyNyOS40xIsKbR nEPGVPH+I+ksrUIj7g4ngqGtZmG7lFG2RLVTDR0paEuG2KNTUu5uKATq6MuSGk6au/hQ eeMw==
X-Gm-Message-State: AD7BkJLZx39IDJKHf6bAn82df+3mLt3/Le3Xl4yKKN3vlY3xRypF+U5XbkSD7QLrjlqD8vzWR8dkcOiqXNPO9A==
X-Received: by 10.50.108.108 with SMTP id hj12mr22380197igb.57.1459960841688;  Wed, 06 Apr 2016 09:40:41 -0700 (PDT)
MIME-Version: 1.0
References:  <10BC5730-BBC1-4BC0-B7D4-FA7FE311599A@cisco.com>
In-Reply-To: <10BC5730-BBC1-4BC0-B7D4-FA7FE311599A@cisco.com>
From: Arturo Servin 
Date: Wed, 06 Apr 2016 16:40:31 +0000
Message-ID: 
To: "Joel Bion (jpbion)" , Erik Nygren 
Content-Type: multipart/alternative; boundary=089e0149392a5adfd2052fd39f3a
Archived-At: 
Cc: "sunset4@ietf.org" 
Subject: Re: [sunset4] IPv4 to Historic: sending a directional message rather than changing state
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Apr 2016 16:40:46 -0000

--089e0149392a5adfd2052fd39f3a
Content-Type: text/plain; charset=UTF-8

Joel

I think that the impact to create behavioral change by declaring IPv4
historic is going to be zero.

The impact in IPv6 deployment that declaring IPv4 historic is going to be
make is zero.

People will be sitting in the fence regarding if IPv4 is historic or no.

Regards
as

On Wed, 6 Apr 2016 at 17:07 Joel Bion (jpbion)  wrote:

> I have a hunch if IPv4 isn't declared historic now, that a year from now
> you'll be in exactly the same place w.r.t. people saying "not yet"
>
> "Directionally historic" etc describes the truth of IPv4 for 20 years now
> - so declaring such a thing is the equivalent of me saying "I will die
> someday" - not news, and nobody's behavior changes as a result of me saying
> this.
>
> The goal of declaring IPv4 historic is not to report on an already
> achieved truth but to create behavioral change. To make it so that it is
> harder to do new v4 things and well near impossible to do new v4 only
> things.
>
> If your goal is to accelerate v6 adoption and usage, start from that
> position of strength (declare v4 historic) and skillfully and
> non-pedantically make exceptions as the world needs them. Show grace in
> allowing new v4 technologies and changes if they hasten and ease transition
> to v6.
>
> If your goal is to prolong the fence sitting, delay declaring v4 historic,
> because I can see *zero* value in saying "v4 will be historic someday and
> we are moving there"
>
> Sent from my iPhone
>
> > On Apr 6, 2016, at 7:47 AM, Erik Nygren  wrote:
> >
> > Starting a discussion thread here as suggested by Lee Howard in the the
> session yesterday.
> >
> > My sense of the comments in the room (while I don't remember a hum) was
> that while it was still too early to advance "IPv4 to Historic", there
> would be value in sending a clear message that we are on a path to move
> IPv4 to Historic at some point in the future.  This could either be through
> sunset4 or preferably by an IETF governance statement.
> >
> > Some topics for discussion seemed to be:
> >
> > * Should there be clear guidance to IETF WGs and other standards bodies
> that it is acceptable to develop IPv6-only protocols without consideration
> for IPv4?   (With the caveat that practical deployments may still have a
> need to inter-operate with IPv4, if only as providing IPv4-as-a-service
> over IPv6.)  Are there particular efforts (eg, 5G) where we should be
> encouraging an "IPv6-first" mindset as part of the design, and is this
> something we can do?
> >
> > * Do we set a time-table for moving to Historic or base this off some
> adoption metric?  (80% global IPv6 adoption?  IPv6-only deployments
> becoming commonplace in multiple scenarios outside of a few large
> companies?)
> >
> > * Are there other things we can do to reduce the time-window where
> everyone has to deal with full dual-stack complexity?  (For example, fixing
> issues that remain with some of the transition technologies that allow for
> IPv6-only connectivity with IPv4-as-a-service?)
> >
> > * What would be a good thing to call this: directionally historic,
> end-of-engineering, "It's Complicated", to-be-deprecated, ...     (In
> particular, we need to make sure the statement made sets expectations but
> is is inline with present reality.)
> >
> >
> >
> > _______________________________________________
> > sunset4 mailing list
> > sunset4@ietf.org
> > https://www.ietf.org/mailman/listinfo/sunset4
>
> _______________________________________________
> sunset4 mailing list
> sunset4@ietf.org
> https://www.ietf.org/mailman/listinfo/sunset4
>

--089e0149392a5adfd2052fd39f3a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Joel

I =
think that the impact to=C2=A0create=
 behavioral change by=C2=A0declaring=
=C2=A0IPv4 historic=C2=A0is going to be zero.

The impact in IPv6 deployment that=C2=A0declaring=C2=A0IPv4 historic=C2=A0is going to be make is zero.

People will be sitting in the fence regarding if I=
Pv4 is historic or no.
Regards
as

On Wed, 6 Apr 2016 at 17:07 Joel Bion (jpbion) &=
lt;jpbion@cisco.com> wrote:
<=
/div>
I have a hunch if IPv4 isn't declar=
ed historic now, that a year from now you'll be in exactly the same pla=
ce w.r.t. people saying "not yet"



"Directionally historic" etc describes the truth of IPv4 for 20 y=
ears now - so declaring such a thing is the equivalent of me saying "I=
 will die someday" - not news, and nobody's behavior changes as a =
result of me saying this.



The goal of declaring IPv4 historic is not to report on an already achieved=
 truth but to create behavioral change. To make it so that it is harder to =
do new v4 things and well near impossible to do new v4 only things.



If your goal is to accelerate v6 adoption and usage, start from that positi=
on of strength (declare v4 historic) and skillfully and non-pedantically ma=
ke exceptions as the world needs them. Show grace in allowing new v4 techno=
logies and changes if they hasten and ease transition to v6.



If your goal is to prolong the fence sitting, delay declaring v4 historic, =
because I can see *zero* value in saying "v4 will be historic someday =
and we are moving there"



Sent from my iPhone



> On Apr 6, 2016, at 7:47 AM, Erik Nygren <erik+ietf@nygren.org> wrote:

>

> Starting a discussion thread here as suggested by Lee Howard in the th=
e session yesterday.

>

> My sense of the comments in the room (while I don't remember a hum=
) was that while it was still too early to advance "IPv4 to Historic&q=
uot;, there would be value in sending a clear message that we are on a path=
 to move IPv4 to Historic at some point in the future.=C2=A0 This could eit=
her be through sunset4 or preferably by an IETF governance statement.

>

> Some topics for discussion seemed to be:

>

> * Should there be clear guidance to IETF WGs and other standards bodie=
s that it is acceptable to develop IPv6-only protocols without consideratio=
n for IPv4?=C2=A0 =C2=A0(With the caveat that practical deployments may sti=
ll have a need to inter-operate with IPv4, if only as providing IPv4-as-a-s=
ervice over IPv6.)=C2=A0 Are there particular efforts (eg, 5G) where we sho=
uld be encouraging an "IPv6-first" mindset as part of the design,=
 and is this something we can do?

>

> * Do we set a time-table for moving to Historic or base this off some =
adoption metric?=C2=A0 (80% global IPv6 adoption?=C2=A0 IPv6-only deploymen=
ts becoming commonplace in multiple scenarios outside of a few large compan=
ies?)

>

> * Are there other things we can do to reduce the time-window where eve=
ryone has to deal with full dual-stack complexity?=C2=A0 (For example, fixi=
ng issues that remain with some of the transition technologies that allow f=
or IPv6-only connectivity with IPv4-as-a-service?)

>

> * What would be a good thing to call this: directionally historic, end=
-of-engineering, "It's Complicated", to-be-deprecated, ...=C2=
=A0 =C2=A0 =C2=A0(In particular, we need to make sure the statement made se=
ts expectations but is is inline with present reality.)

>

>

>

> _______________________________________________

> sunset4 mailing list

> sunset4@ietf.org=


> https://www.ietf.org/mailman/listinfo/sunset4<=
br>


_______________________________________________

sunset4 mailing list

sunset4@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/sunset4




--089e0149392a5adfd2052fd39f3a--


From nobody Wed Apr  6 10:22:33 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A116312D6B1 for ; Wed,  6 Apr 2016 10:22:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.008
X-Spam-Level: 
X-Spam-Status: No, score=-1.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=no 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 XekSvb6nMS72 for ; Wed,  6 Apr 2016 10:22:30 -0700 (PDT)
Received: from atl4mhob05.myregisteredsite.com (atl4mhob05.myregisteredsite.com [209.17.115.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5E81812D6B0 for ; Wed,  6 Apr 2016 10:22:30 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u36HMSuj027850 for ; Wed, 6 Apr 2016 13:22:28 -0400
Received: (qmail 14768 invoked by uid 0); 6 Apr 2016 17:22:28 -0000
X-TCPREMOTEIP: 31.133.176.63
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?31.133.176.63?) (lee@asgard.org@31.133.176.63) by 0 with ESMTPA; 6 Apr 2016 17:22:27 -0000
User-Agent: Microsoft-MacOutlook/14.6.1.160122
Date: Wed, 06 Apr 2016 14:22:18 +0100
From: Lee Howard 
To: "George, Wes" , Andrei Robachevsky , "sunset4@ietf.org" 
Message-ID: 
Thread-Topic: [sunset4] Mandating use of IPv6 in examples
References: <5704F8BA.20400@gmail.com> 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [sunset4] Mandating use of IPv6 in examples
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Apr 2016 17:22:31 -0000

On 4/6/16, 3:59 PM, "sunset4 on behalf of George, Wes"
 wrote:
>
>A mandate implies that there is some sort of recourse to force it to be
>changed if people don't comply, and a question of who enforces it - the
>IESG? The RFC editor? IDNITs check? The document shepherd?

IDNITS does currently check whether you are using rfc6890 addresses
reserved for documentation. It could certainly be updated to say,
=B3WARNING: You=B9re using IPv4 example addresses, but no IPv6 addresses were
found.=B2
I say =B3warning=B2 instead of =B3error=B2 because until IPv4 is Historic, there
are still valid use cases for IPv4-only examples (and especially in the
case of translation technologies).

Lee




From nobody Wed Apr  6 10:33:50 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F309F12D0F3 for ; Wed,  6 Apr 2016 10:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level: 
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, USER_IN_WHITELIST=-100] 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 U96Rzpp2kDJH for ; Wed,  6 Apr 2016 10:33:43 -0700 (PDT)
Received: from mail.consulintel.com (mail.consulintel.com [213.0.69.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 853E812D6FB for ; Wed,  6 Apr 2016 10:33:22 -0700 (PDT)
X-MDAV-Processed: mail.consulintel.com, Wed, 06 Apr 2016 19:33:18 +0200
Received: from [10.10.10.28] by mail.consulintel.com (MDaemon PRO v11.0.3) with ESMTP id md50000387603.msg for ; Wed, 06 Apr 2016 19:33:18 +0200
X-Spam-Processed: mail.consulintel.com, Wed, 06 Apr 2016 19:33:18 +0200 (not processed: spam filter heuristic analysis disabled)
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Return-Path: prvs=1904b28184=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: sunset4@ietf.org
User-Agent: Microsoft-MacOutlook/0.0.0.160212
Date: Wed, 06 Apr 2016 14:33:06 -0300
From: JORDI PALET MARTINEZ 
To: 
Message-ID: 
Thread-Topic: [sunset4] Mandating use of IPv6 in examples
References: <5704F8BA.20400@gmail.com> 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [sunset4] Mandating use of IPv6 in examples
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Apr 2016 17:33:48 -0000

I recall there was a document, hopefully turned into RFC, a few years ago, =
stating that any future work in IETF must support IPv6 unless clearly is an =
IPv4-only protocol. But can=E2=80=99t find that document =E2=80=A6

If I=E2=80=99m correct and that document exist, what about reviewing that one to =
include also now the mandatory IPv6 examples ?

Saludos,
Jordi









-----Mensaje original-----
De: sunset4  en nombre de "George, Wes" 
Responder a: 
Fecha: mi=C3=A9rcoles, 6 de abril de 2016, 11:59
Para: Andrei Robachevsky , "sunset4@ietf.org"=
 
Asunto: Re: [sunset4] Mandating use of IPv6 in examples

>Speaking as an individual:
>
>You'd think this wouldn't be controversial, but I'm not convinced that
>this sort of bureaucratic formatting rule is really the right solution to
>get IETF as a whole more focused on IPv6 and reinforcing the idea that
>IPv4 is now a legacy protocol. Yes, increasing exposure and familiarity
>with IPv6 addresses by using them more consistently is a good thing, and
>it seems harmless to suggest that we do this, but it's the word mandate
>that bothers me.
>
>A mandate implies that there is some sort of recourse to force it to be
>changed if people don't comply, and a question of who enforces it - the
>IESG? The RFC editor? IDNITs check? The document shepherd? Making this a
>suggestion means that it is something that is enforced via people looking
>at drafts during reviews, WGLC, IETF LC, etc and asking, "is there any
>reason why these examples are IPv4?" and failing any acceptable
>justification, suggesting that they update the examples with the current
>protocol version. I think this is very similar to what happens when people
>use randomly chosen IP addresses or ASNs for examples instead of the
>proper documentation ones - someone points out that a change needs to be
>made, and we all move on. That might mean that it doesn't actually need to
>progress as an RFC, having served its purpose as an I-D to start the
>discussion.
>It's also possible that the right place for this is in the RFC style
>guide, though that's probably a longer discussion since as far as I can
>tell, the style guide does not currently have any recommendation about use
>of documentation addresses, no references to RFC 6890, etc. and so adding
>a discussion about which *type* of documentation addresses to use might be
>going too far.
>
>
>To the content of the document:
>From a strict RFC2119 normative keyword interpretation, I'm don't think
>that MUST is the right word here, since you caveat that MUST with
>"unless..."
>MUST doesn't have exceptions. SHOULD and MAY do.
>So I think you probably want a "SHOULD... unless". And there's also the
>problem that 2119 words are, by strictest interpretation, intended to
>describe behavior that is required for interoperability, not "eat your
>vegetables" imperatives, and people tend to raise objections to their use
>in the latter way. Not saying that there aren't documents that use 2119 a
>little off-label, but the burden of justification is higher.
>Perhaps RFC 6919 is a better choice for your normative keywords? :-)
>
>Thanks,
>
>Wes
>
>
>
>
>On 4/6/16, 7:53 AM, "sunset4 on behalf of Andrei Robachevsky"
> wrote=
:
>
>>Hi,
>>
>>I recently submitted an I-D
>>draft-robachevsky-mandating-use-of-ipv6-examples-00.txt, mandating use
>>of IPv6 in examples in RFCs.
>>
>>I was reading some pretty recent drafts and noticed that authors
>>continue using IPv4 in their examples. This is probably more convenient,
>>but is not really forward thinking. Also, the prevalence of IPv6
>>examples will send a strong message that IPv4 is essentially a legacy
>>protocol.
>>
>>I wonder if this WG is interested in progressing this document as a WG
>>item.
>>
>>Thanks,
>>
>>Andrei
>>
>>
>>> Name:draft-robachevsky-mandating-use-of-ipv6-examples
>>> Revision:00
>>> Title:Mandating use of IPv6 in examples
>>> Document date:2016-03-21
>>> Group:Individual Submission
>>> Pages:3
>>> URL:
>>>https://www.ietf.org/internet-drafts/draft-robachevsky-mandating-use-of-=
i
>>>pv6-examples-00.txt
>>> Status:
>>>https://datatracker.ietf.org/doc/draft-robachevsky-mandating-use-of-ipv6=
-
>>>examples/
>>> Htmlized:
>>>https://tools.ietf.org/html/draft-robachevsky-mandating-use-of-ipv6-exam=
p
>>>les-00
>>>
>>>
>>> Abstract:
>>>    IPv6 is a successor of the legacy IPv4 protocol.  This document
>>>    mandates use of IPv6 in examples provided in RFCs.
>>
>
>
>________________________________
>
>This E-mail and any of its attachments may contain Time Warner Cable propr=
ietary information, which is privileged, confidential, or subject to copyrig=
ht belonging to Time Warner Cable. This E-mail is intended solely for the us=
e of the individual or entity to which it is addressed. If you are not the i=
ntended recipient of this E-mail, you are hereby notified that any dissemina=
tion, distribution, copying, or action taken in relation to the contents of =
and attachments to this E-mail is strictly prohibited and may be unlawful. I=
f you have received this E-mail in error, please notify the sender immediate=
ly and permanently delete the original and any copy of this E-mail and any p=
rintout.
>_______________________________________________
>sunset4 mailing list
>sunset4@ietf.org
>https://www.ietf.org/mailman/listinfo/sunset4
>



From nobody Wed Apr  6 11:09:03 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E7712D5EE for ; Wed,  6 Apr 2016 11:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.009
X-Spam-Level: 
X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=no 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 geYHM8ved1BM for ; Wed,  6 Apr 2016 11:08:59 -0700 (PDT)
Received: from atl4mhob15.myregisteredsite.com (atl4mhob15.myregisteredsite.com [209.17.115.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFB712D0E1 for ; Wed,  6 Apr 2016 11:08:48 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.203]) by atl4mhob15.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u36I8kJI007099 for ; Wed, 6 Apr 2016 14:08:46 -0400
Received: (qmail 14938 invoked by uid 0); 6 Apr 2016 18:08:45 -0000
X-TCPREMOTEIP: 31.133.176.63
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?31.133.176.63?) (lee@asgard.org@31.133.176.63) by 0 with ESMTPA; 6 Apr 2016 18:08:45 -0000
User-Agent: Microsoft-MacOutlook/14.6.1.160122
Date: Wed, 06 Apr 2016 15:08:41 +0100
From: Lee Howard 
To: "'jordi. es'" , 
Message-ID: 
Thread-Topic: [sunset4] Mandating use of IPv6 in examples
References: <5704F8BA.20400@gmail.com>  
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [sunset4] Mandating use of IPv6 in examples
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Apr 2016 18:09:01 -0000

rfc6540?
"IPv6 Support Required for All IP-Capable Nodes=B2

Lee

On 4/6/16, 6:33 PM, "sunset4 on behalf of JORDI PALET MARTINEZ"
 wrote:

>I recall there was a document, hopefully turned into RFC, a few years
>ago, stating that any future work in IETF must support IPv6 unless
>clearly is an IPv4-only protocol. But can=B9t find that document =8A
>
>If I=B9m correct and that document exist, what about reviewing that one to
>include also now the mandatory IPv6 examples ?
>
>Saludos,
>Jordi
>
>
>
>
>
>
>
>
>
>-----Mensaje original-----
>De: sunset4  en nombre de "George, Wes"
>
>Responder a: 
>Fecha: mi=E9rcoles, 6 de abril de 2016, 11:59
>Para: Andrei Robachevsky ,
>"sunset4@ietf.org" 
>Asunto: Re: [sunset4] Mandating use of IPv6 in examples
>
>>Speaking as an individual:
>>
>>You'd think this wouldn't be controversial, but I'm not convinced that
>>this sort of bureaucratic formatting rule is really the right solution to
>>get IETF as a whole more focused on IPv6 and reinforcing the idea that
>>IPv4 is now a legacy protocol. Yes, increasing exposure and familiarity
>>with IPv6 addresses by using them more consistently is a good thing, and
>>it seems harmless to suggest that we do this, but it's the word mandate
>>that bothers me.
>>
>>A mandate implies that there is some sort of recourse to force it to be
>>changed if people don't comply, and a question of who enforces it - the
>>IESG? The RFC editor? IDNITs check? The document shepherd? Making this a
>>suggestion means that it is something that is enforced via people looking
>>at drafts during reviews, WGLC, IETF LC, etc and asking, "is there any
>>reason why these examples are IPv4?" and failing any acceptable
>>justification, suggesting that they update the examples with the current
>>protocol version. I think this is very similar to what happens when
>>people
>>use randomly chosen IP addresses or ASNs for examples instead of the
>>proper documentation ones - someone points out that a change needs to be
>>made, and we all move on. That might mean that it doesn't actually need
>>to
>>progress as an RFC, having served its purpose as an I-D to start the
>>discussion.
>>It's also possible that the right place for this is in the RFC style
>>guide, though that's probably a longer discussion since as far as I can
>>tell, the style guide does not currently have any recommendation about
>>use
>>of documentation addresses, no references to RFC 6890, etc. and so adding
>>a discussion about which *type* of documentation addresses to use might
>>be
>>going too far.
>>
>>
>>To the content of the document:
>>From a strict RFC2119 normative keyword interpretation, I'm don't think
>>that MUST is the right word here, since you caveat that MUST with
>>"unless..."
>>MUST doesn't have exceptions. SHOULD and MAY do.
>>So I think you probably want a "SHOULD... unless". And there's also the
>>problem that 2119 words are, by strictest interpretation, intended to
>>describe behavior that is required for interoperability, not "eat your
>>vegetables" imperatives, and people tend to raise objections to their use
>>in the latter way. Not saying that there aren't documents that use 2119 a
>>little off-label, but the burden of justification is higher.
>>Perhaps RFC 6919 is a better choice for your normative keywords? :-)
>>
>>Thanks,
>>
>>Wes
>>
>>
>>
>>
>>On 4/6/16, 7:53 AM, "sunset4 on behalf of Andrei Robachevsky"
>>
>>wrote:
>>
>>>Hi,
>>>
>>>I recently submitted an I-D
>>>draft-robachevsky-mandating-use-of-ipv6-examples-00.txt, mandating use
>>>of IPv6 in examples in RFCs.
>>>
>>>I was reading some pretty recent drafts and noticed that authors
>>>continue using IPv4 in their examples. This is probably more convenient,
>>>but is not really forward thinking. Also, the prevalence of IPv6
>>>examples will send a strong message that IPv4 is essentially a legacy
>>>protocol.
>>>
>>>I wonder if this WG is interested in progressing this document as a WG
>>>item.
>>>
>>>Thanks,
>>>
>>>Andrei
>>>
>>>
>>>> Name:draft-robachevsky-mandating-use-of-ipv6-examples
>>>> Revision:00
>>>> Title:Mandating use of IPv6 in examples
>>>> Document date:2016-03-21
>>>> Group:Individual Submission
>>>> Pages:3
>>>> URL:
>>>>https://www.ietf.org/internet-drafts/draft-robachevsky-mandating-use-of
>>>>-i
>>>>pv6-examples-00.txt
>>>> Status:
>>>>https://datatracker.ietf.org/doc/draft-robachevsky-mandating-use-of-ipv
>>>>6-
>>>>examples/
>>>> Htmlized:
>>>>https://tools.ietf.org/html/draft-robachevsky-mandating-use-of-ipv6-exa
>>>>mp
>>>>les-00
>>>>
>>>>
>>>> Abstract:
>>>>    IPv6 is a successor of the legacy IPv4 protocol.  This document
>>>>    mandates use of IPv6 in examples provided in RFCs.
>>>
>>
>>
>>________________________________
>>
>>This E-mail and any of its attachments may contain Time Warner Cable
>>proprietary information, which is privileged, confidential, or subject
>>to copyright belonging to Time Warner Cable. This E-mail is intended
>>solely for the use of the individual or entity to which it is addressed.
>>If you are not the intended recipient of this E-mail, you are hereby
>>notified that any dissemination, distribution, copying, or action taken
>>in relation to the contents of and attachments to this E-mail is
>>strictly prohibited and may be unlawful. If you have received this
>>E-mail in error, please notify the sender immediately and permanently
>>delete the original and any copy of this E-mail and any printout.
>>_______________________________________________
>>sunset4 mailing list
>>sunset4@ietf.org
>>https://www.ietf.org/mailman/listinfo/sunset4
>>
>
>
>_______________________________________________
>sunset4 mailing list
>sunset4@ietf.org
>https://www.ietf.org/mailman/listinfo/sunset4



From nobody Wed Apr  6 11:25:38 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7737712D766 for ; Wed,  6 Apr 2016 11:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level: 
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, USER_IN_WHITELIST=-100] 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 JYboZA7mMgxb for ; Wed,  6 Apr 2016 11:25:28 -0700 (PDT)
Received: from mail.consulintel.com (mail.consulintel.com [213.0.69.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE1812D776 for ; Wed,  6 Apr 2016 11:25:22 -0700 (PDT)
X-MDAV-Processed: mail.consulintel.com, Wed, 06 Apr 2016 20:25:19 +0200
Received: from [10.10.10.29] by mail.consulintel.com (MDaemon PRO v11.0.3) with ESMTP id md50000387651.msg for ; Wed, 06 Apr 2016 20:25:18 +0200
X-Spam-Processed: mail.consulintel.com, Wed, 06 Apr 2016 20:25:18 +0200 (not processed: spam filter heuristic analysis disabled)
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Return-Path: prvs=1904b28184=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: sunset4@ietf.org
User-Agent: Microsoft-MacOutlook/0.0.0.160212
Date: Wed, 06 Apr 2016 15:25:10 -0300
From: JORDI PALET MARTINEZ 
To: 
Message-ID: <61485C4F-E670-4BAC-8AFB-A7319E8FF804@consulintel.es>
Thread-Topic: [sunset4] Mandating use of IPv6 in examples
References: <5704F8BA.20400@gmail.com>   
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: 
Subject: Re: [sunset4] Mandating use of IPv6 in examples
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jordi.palet@consulintel.es
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Apr 2016 18:25:37 -0000

No, it was much earlier than the time of this document, I think around 2006=
.

As I recall it, was not referring to nodes, but in general to =E2=80=9CIETF work=E2=
=80=9D.

May be got the idea wrong in my memory, and it was not an RFC, but an IESG =
rule something such as =E2=80=9Comitting IPv6 support in a document without a reas=
onable explanation will not be accepted by IESG=E2=80=9D ? Do we have this kind of=
 =E2=80=9Crules=E2=80=9D ?

Saludos,
Jordi








-----Mensaje original-----
De: Lee Howard 
Responder a: 
Fecha: mi=C3=A9rcoles, 6 de abril de 2016, 11:08
Para: Jordi Palet Martinez , 
Asunto: Re: [sunset4] Mandating use of IPv6 in examples

>rfc6540?
>"IPv6 Support Required for All IP-Capable Nodes=C2=B2
>
>Lee
>
>On 4/6/16, 6:33 PM, "sunset4 on behalf of JORDI PALET MARTINEZ"
> wrote:
>
>>I recall there was a document, hopefully turned into RFC, a few years
>>ago, stating that any future work in IETF must support IPv6 unless
>>clearly is an IPv4-only protocol. But can=C2=B9t find that document =C2=8A
>>
>>If I=C2=B9m correct and that document exist, what about reviewing that one to
>>include also now the mandatory IPv6 examples ?
>>
>>Saludos,
>>Jordi
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>-----Mensaje original-----
>>De: sunset4  en nombre de "George, Wes"
>>
>>Responder a: 
>>Fecha: mi=C3=A9rcoles, 6 de abril de 2016, 11:59
>>Para: Andrei Robachevsky ,
>>"sunset4@ietf.org" 
>>Asunto: Re: [sunset4] Mandating use of IPv6 in examples
>>
>>>Speaking as an individual:
>>>
>>>You'd think this wouldn't be controversial, but I'm not convinced that
>>>this sort of bureaucratic formatting rule is really the right solution t=
o
>>>get IETF as a whole more focused on IPv6 and reinforcing the idea that
>>>IPv4 is now a legacy protocol. Yes, increasing exposure and familiarity
>>>with IPv6 addresses by using them more consistently is a good thing, and
>>>it seems harmless to suggest that we do this, but it's the word mandate
>>>that bothers me.
>>>
>>>A mandate implies that there is some sort of recourse to force it to be
>>>changed if people don't comply, and a question of who enforces it - the
>>>IESG? The RFC editor? IDNITs check? The document shepherd? Making this a
>>>suggestion means that it is something that is enforced via people lookin=
g
>>>at drafts during reviews, WGLC, IETF LC, etc and asking, "is there any
>>>reason why these examples are IPv4?" and failing any acceptable
>>>justification, suggesting that they update the examples with the current
>>>protocol version. I think this is very similar to what happens when
>>>people
>>>use randomly chosen IP addresses or ASNs for examples instead of the
>>>proper documentation ones - someone points out that a change needs to be
>>>made, and we all move on. That might mean that it doesn't actually need
>>>to
>>>progress as an RFC, having served its purpose as an I-D to start the
>>>discussion.
>>>It's also possible that the right place for this is in the RFC style
>>>guide, though that's probably a longer discussion since as far as I can
>>>tell, the style guide does not currently have any recommendation about
>>>use
>>>of documentation addresses, no references to RFC 6890, etc. and so addin=
g
>>>a discussion about which *type* of documentation addresses to use might
>>>be
>>>going too far.
>>>
>>>
>>>To the content of the document:
>>>From a strict RFC2119 normative keyword interpretation, I'm don't think
>>>that MUST is the right word here, since you caveat that MUST with
>>>"unless..."
>>>MUST doesn't have exceptions. SHOULD and MAY do.
>>>So I think you probably want a "SHOULD... unless". And there's also the
>>>problem that 2119 words are, by strictest interpretation, intended to
>>>describe behavior that is required for interoperability, not "eat your
>>>vegetables" imperatives, and people tend to raise objections to their us=
e
>>>in the latter way. Not saying that there aren't documents that use 2119 =
a
>>>little off-label, but the burden of justification is higher.
>>>Perhaps RFC 6919 is a better choice for your normative keywords? :-)
>>>
>>>Thanks,
>>>
>>>Wes
>>>
>>>
>>>
>>>
>>>On 4/6/16, 7:53 AM, "sunset4 on behalf of Andrei Robachevsky"
>>>
>>>wrote:
>>>
>>>>Hi,
>>>>
>>>>I recently submitted an I-D
>>>>draft-robachevsky-mandating-use-of-ipv6-examples-00.txt, mandating use
>>>>of IPv6 in examples in RFCs.
>>>>
>>>>I was reading some pretty recent drafts and noticed that authors
>>>>continue using IPv4 in their examples. This is probably more convenient=
,
>>>>but is not really forward thinking. Also, the prevalence of IPv6
>>>>examples will send a strong message that IPv4 is essentially a legacy
>>>>protocol.
>>>>
>>>>I wonder if this WG is interested in progressing this document as a WG
>>>>item.
>>>>
>>>>Thanks,
>>>>
>>>>Andrei
>>>>
>>>>
>>>>> Name:draft-robachevsky-mandating-use-of-ipv6-examples
>>>>> Revision:00
>>>>> Title:Mandating use of IPv6 in examples
>>>>> Document date:2016-03-21
>>>>> Group:Individual Submission
>>>>> Pages:3
>>>>> URL:
>>>>>https://www.ietf.org/internet-drafts/draft-robachevsky-mandating-use-o=
f
>>>>>-i
>>>>>pv6-examples-00.txt
>>>>> Status:
>>>>>https://datatracker.ietf.org/doc/draft-robachevsky-mandating-use-of-ip=
v
>>>>>6-
>>>>>examples/
>>>>> Htmlized:
>>>>>https://tools.ietf.org/html/draft-robachevsky-mandating-use-of-ipv6-ex=
a
>>>>>mp
>>>>>les-00
>>>>>
>>>>>
>>>>> Abstract:
>>>>>    IPv6 is a successor of the legacy IPv4 protocol.  This document
>>>>>    mandates use of IPv6 in examples provided in RFCs.
>>>>
>>>
>>>
>>>________________________________
>>>
>>>This E-mail and any of its attachments may contain Time Warner Cable
>>>proprietary information, which is privileged, confidential, or subject
>>>to copyright belonging to Time Warner Cable. This E-mail is intended
>>>solely for the use of the individual or entity to which it is addressed.
>>>If you are not the intended recipient of this E-mail, you are hereby
>>>notified that any dissemination, distribution, copying, or action taken
>>>in relation to the contents of and attachments to this E-mail is
>>>strictly prohibited and may be unlawful. If you have received this
>>>E-mail in error, please notify the sender immediately and permanently
>>>delete the original and any copy of this E-mail and any printout.
>>>_______________________________________________
>>>sunset4 mailing list
>>>sunset4@ietf.org
>>>https://www.ietf.org/mailman/listinfo/sunset4
>>>
>>
>>
>>_______________________________________________
>>sunset4 mailing list
>>sunset4@ietf.org
>>https://www.ietf.org/mailman/listinfo/sunset4
>
>
>



From nobody Thu Apr  7 02:30:40 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773B012D134 for ; Thu,  7 Apr 2016 02:30:38 -0700 (PDT)
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 oEj14sSU0nEr for ; Thu,  7 Apr 2016 02:30:36 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 4617F12D0B7 for ; Thu,  7 Apr 2016 02:30:36 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id c126so52684670lfb.2 for ; Thu, 07 Apr 2016 02:30:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=I4eDcid5NUa+0omzsEjQsKM7+6VnyRgTQT1lir/W+3o=; b=tUfIEg+7aqlpfNAWpmm8UHrvwyIgzzvfWzwcSXEB10ZPYUXMTYfwyR/cO8MVrAdbqd Q532spvzjM7xrjzJ1UcIoALyWNI2U2kM/oHYDowdZ1VxYh6HAm+8JFV7hFhlUcw73hKg FPsjxHogwth/ilD20vnjeyROKH43M4sr/9zrXryIpiYPJ0PMGnjShNFWn57aIUkUalV1 KHOqvLm2BTis9UaARtVuFVT7j0oKm7ESVbHF7l62c6VwGRKfjz1+V8qngE8QKMpAGR+g hkvzl+yrJuKUd425dNa0yrAFo3hOq6nFdj5/jNLFo+C3JpRUtPWG4ufSRjwoOn78fD/I 7PWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=I4eDcid5NUa+0omzsEjQsKM7+6VnyRgTQT1lir/W+3o=; b=aac26AF9XAzlKpRbMK3Vp0+znzMVcgS1ELDma1vJ9ZDuW7Vk4bH3FKvhZ0vKe+TtcL n0c6ccyUMKEsuTYsO4EUFFRq6vYjgJ3QEA+p6RuXxb0faGboJ7ItbsUJJo39XE8iJJv8 mzQAeRa238u0EAp5f1k/iGGyaly9CFw2LK1MjX/xKDBg2ydLSLUCNYSY3hGVoyXPFlU4 lYmjvRf6C2xcTawXmHFEZklv+T6LKJUVaHv9T8saP8bC3Z3LecKlJImaUwPFEsSIzw3X J+/7V0mzDfdBl/qncV/EDXyFjOUrMNc46A4pehCyAjfUGi9me1TDZJeETgZK4omwBIIl N1Aw==
X-Gm-Message-State: AD7BkJJFbD6iPgTRyr1NI2NI6AiK7m6Y59ZK2YwHIY1SscPpgTy6JCwAGLWw8Oeb4V68yw==
X-Received: by 10.25.165.20 with SMTP id o20mr947298lfe.105.1460021434462; Thu, 07 Apr 2016 02:30:34 -0700 (PDT)
Received: from ip-217-102-57-30.ip.prioritytelecom.net (ip-217-102-57-30.ip.prioritytelecom.net. [217.102.57.30]) by smtp.googlemail.com with ESMTPSA id i1sm1075880lbs.22.2016.04.07.02.30.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 02:30:33 -0700 (PDT)
To: "George, Wes" , "sunset4@ietf.org" 
References: <5704F8BA.20400@gmail.com> 
From: Andrei Robachevsky 
Message-ID: <570628B7.9010301@gmail.com>
Date: Thu, 7 Apr 2016 11:30:31 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="naldfXeQKMoK7w2VTJFpqWXVsHxAmqMTS"
Archived-At: 
Subject: Re: [sunset4] Mandating use of IPv6 in examples
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Apr 2016 09:30:39 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--naldfXeQKMoK7w2VTJFpqWXVsHxAmqMTS
Content-Type: multipart/mixed; boundary="0Ovdxv48XAeXgoB95n3muAnnlxREfnern"
From: Andrei Robachevsky 
To: "George, Wes" ,
 "sunset4@ietf.org" 
Message-ID: <570628B7.9010301@gmail.com>
Subject: Re: [sunset4] Mandating use of IPv6 in examples
References: <5704F8BA.20400@gmail.com>
 
In-Reply-To: 

--0Ovdxv48XAeXgoB95n3muAnnlxREfnern
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Thanks everyone for your comments and general support.

George, Wes wrote on 06/04/16 16:59:
[...]

> I think this is very similar to what happens when people
> use randomly chosen IP addresses or ASNs for examples instead of the
> proper documentation ones - someone points out that a change needs to b=
e
> made, and we all move on. That might mean that it doesn't actually need=
 to
> progress as an RFC, having served its purpose as an I-D to start the
> discussion.

Agree, still I think a document like this can ensure better consistency
and raise awareness.

[...]
>=20
> To the content of the document:
> From a strict RFC2119 normative keyword interpretation, I'm don't think=

> that MUST is the right word here, since you caveat that MUST with
> "unless..."

Good point. I incorporated the comments and also toned the document down
a bit. There are indeed legitimate cases where IPv6 examples are not
applicable.

Here it is:

https://www.ietf.org/internet-drafts/draft-robachevsky-mandating-use-of-i=
pv6-examples-01.txt

Andrei


--0Ovdxv48XAeXgoB95n3muAnnlxREfnern--

--naldfXeQKMoK7w2VTJFpqWXVsHxAmqMTS
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iEYEARECAAYFAlcGKLcACgkQljz5tZmtij+u7gCaAxc9Am5tA0Bfv0SHGeDbsLmn
U5oAnimaYuosxDvxCWV2TDvhIZx7ZKxM
=jbgN
-----END PGP SIGNATURE-----

--naldfXeQKMoK7w2VTJFpqWXVsHxAmqMTS--


From nobody Fri Apr  8 10:16:33 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AEC12D5C7 for ; Fri,  8 Apr 2016 10:16:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 zEMVRCS0v1Ue for ; Fri,  8 Apr 2016 10:16:30 -0700 (PDT)
Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id 94E9D12D0B9 for ; Fri,  8 Apr 2016 10:16:30 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id u38HGSxb026782 for ; Fri, 8 Apr 2016 13:16:28 -0400
Received: (qmail 26860 invoked by uid 0); 8 Apr 2016 17:16:28 -0000
X-TCPREMOTEIP: 31.133.176.63
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?31.133.176.63?) (lee@asgard.org@31.133.176.63) by 0 with ESMTPA; 8 Apr 2016 17:16:27 -0000
User-Agent: Microsoft-MacOutlook/14.6.1.160122
Date: Fri, 08 Apr 2016 14:16:19 -0300
From: Lee Howard 
To: Andrei Robachevsky , "George, Wes" , "sunset4@ietf.org" 
Message-ID: 
Thread-Topic: [sunset4] Mandating use of IPv6 in examples
References: <5704F8BA.20400@gmail.com>  <570628B7.9010301@gmail.com>
In-Reply-To: <570628B7.9010301@gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Archived-At: 
Subject: Re: [sunset4] Mandating use of IPv6 in examples
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Apr 2016 17:16:33 -0000

Thanks to Henrik for this!

https://tools.ietf.org/tools/idnits/changelog

2.14.01 
(diff-2.14.01 
)


* Added a comment about adding IPv6 examples for documents that uses
addresses from the IPv4 documentation range, without having any
from the IPV6 documentation range
* Changed some references to RFC5735 to instead mention RFC6980.

( Henrik Levkowetz   06 Apr 2016 9:57:59 +0100)



Lee


On 4/7/16, 6:30 AM, "sunset4 on behalf of Andrei Robachevsky"
 wrote:

>Thanks everyone for your comments and general support.
>
>George, Wes wrote on 06/04/16 16:59:
>[...]
>
>> I think this is very similar to what happens when people
>> use randomly chosen IP addresses or ASNs for examples instead of the
>> proper documentation ones - someone points out that a change needs to be
>> made, and we all move on. That might mean that it doesn't actually need
>>to
>> progress as an RFC, having served its purpose as an I-D to start the
>> discussion.
>
>Agree, still I think a document like this can ensure better consistency
>and raise awareness.
>
>[...]
>> 
>> To the content of the document:
>> From a strict RFC2119 normative keyword interpretation, I'm don't think
>> that MUST is the right word here, since you caveat that MUST with
>> "unless..."
>
>Good point. I incorporated the comments and also toned the document down
>a bit. There are indeed legitimate cases where IPv6 examples are not
>applicable.
>
>Here it is:
>
>https://www.ietf.org/internet-drafts/draft-robachevsky-mandating-use-of-ip
>v6-examples-01.txt
>
>Andrei
>
>_______________________________________________
>sunset4 mailing list
>sunset4@ietf.org
>https://www.ietf.org/mailman/listinfo/sunset4



From nobody Fri Apr  8 11:53:35 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C9212D59D for ; Fri,  8 Apr 2016 11:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=irs.gov
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 ngdsysqVX0of for ; Fri,  8 Apr 2016 11:53:32 -0700 (PDT)
Received: from emg5.irs.gov (emg5.irs.gov [IPv6:2610:30:4000:25::92]) (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 EDF0712D510 for ; Fri,  8 Apr 2016 11:53:31 -0700 (PDT)
Received: from MEM0200CP3XF01.ds.irsnet.gov (mem0200cp3xf01.ds.irsnet.gov [10.219.80.76]) by mem0200vprelay3.is.irs.gov (8.13.8/8.13.8) with ESMTP id u38IrP7C024731 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Apr 2016 13:53:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irs.gov; s=irs-20130926; t=1460141605; bh=Tw88lSDfoO+4YvKYeYySoee7DCOcZ5XqzTUi8kY7HpI=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=h33HlYwdl+mmruILkB+4dywstXixghLgEGfsZlCre6ZNKI/L50FkcY/mHy6G3AQi3 1k9d8/CX2ZETfiry1HiX0w0qOrsIMvDMxNdkykDk2C9U3Lg2cPSFfcfMOKeTjPRw8o m9AZElpb4+TxpjUj8NBxa7fwifXDLCJVCnxWHlOI=
Received: from MEM0200CP3DR08.ds.irsnet.gov (10.219.80.71) by MEM0200CP3XF01.ds.irsnet.gov (10.219.80.76) with Microsoft SMTP Server (TLS) id 14.3.279.2; Fri, 8 Apr 2016 13:53:24 -0500
Received: from MEM0200CP3XF01.ds.irsnet.gov ([fe80::fd56:8bb3:8512:7316]) by MEM0200CP3DR08.ds.irsnet.gov ([fe80::b992:2697:2cdc:df4a%14]) with mapi id 14.03.0279.002; Fri, 8 Apr 2016 13:53:24 -0500
From: Morizot Timothy S 
To: "Joel Bion (jpbion)" 
Thread-Topic: [sunset4] IPv4 to Historic: sending a directional message rather than changing state
Thread-Index: AQHRkBMmJV/G5MmdWEOPLgFCFFiaeZ99cH0AgALrnMA=
Date: Fri, 8 Apr 2016 18:53:24 +0000
Message-ID: <968C470DAC25FB419E0159952F28F0C094ACC1F7@MEM0200CP3XF01.ds.irsnet.gov>
References:  <10BC5730-BBC1-4BC0-B7D4-FA7FE311599A@cisco.com>
In-Reply-To: <10BC5730-BBC1-4BC0-B7D4-FA7FE311599A@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.219.80.83]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "sunset4@ietf.org" 
Subject: Re: [sunset4] IPv4 to Historic: sending a directional message rather than changing state
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 08 Apr 2016 18:53:34 -0000

Joel Bion wrote:
> I have a hunch if IPv4 isn't declared historic now, that a year from now =
you'll
> be in exactly the same place w.r.t. people saying "not yet"
>=20
> "Directionally historic" etc describes the truth of IPv4 for 20 years now=
 - so
> declaring such a thing is the equivalent of me saying "I will die someday=
" - not
> news, and nobody's behavior changes as a result of me saying this.

I certainly agree that statements like that are not particularly useful, bu=
t I'm not sure that the direct goal from the IETF perspective is trying to =
change the behavior of operators, at least in this context. The question of=
 whether or not the specification should be historic seems oriented more at=
 where the IETF should focus its efforts developing specifications and how =
those specifications impact developers and product manufacturers.

> The goal of declaring IPv4 historic is not to report on an already achiev=
ed
> truth but to create behavioral change. To make it so that it is harder to=
 do
> new v4 things and well near impossible to do new v4 only things.

I've spent a fair amount of time thinking about this topic, especially in l=
ight of the comments at the sunset4 session. Despite what I thought were so=
me pretty clearly expressed distinctions expressed by Lee, a fair number of=
 the comments still seemed to approach this as an effort to "turn v4 off" o=
r to somehow control usage or deployment of v4. Most of the rest of the com=
ments focused on how it impacted where the IETF would or would not focus it=
s time and effort. And that's a lot more accurate, but the directly impacte=
d "customers" (an over-used, but perhaps accurate term in this context) of =
the work the IETF does with its specifications are the companies and indivi=
duals who implement those specifications in products.

So, then, what is the impact to that group if the IETF publishes two Intern=
et Protocol specifications as full standards, one of which clearly states i=
t is the successor to the other in its specification with no other guidance=
 (a declaration of IPv4 as the historic specification or otherwise)? Since =
there is no defined relationship or restriction and the IETF developed and =
published a new or modified required or recommended feature in the IPv4 spe=
cification, doesn't that mean they would all need to implement that new or =
changed specification? By keeping both specifications as full standards, th=
e IETF is actually, in a way, signaling implementers that they have to meet=
 two different Internet Protocol specifications if they truly want to be co=
nsidered interoperable on the Internet. That doesn't look desirable to me.

So I went back and reread some of the process documentation more closely, e=
specially RFC2026, and spent some time thinking about this section.


  6.3  Revising a Standard

   A new version of an established Internet Standard must progress
   through the full Internet standardization process as if it were a
   completely new specification.  Once the new version has reached the
   Standard level, it will usually replace the previous version, which
   will be moved to Historic status.  However, in some cases both
   versions may remain as Internet Standards to honor the requirements
   of an installed base.  In this situation, the relationship between
   the previous and the new versions must be explicitly stated in the
   text of the new version or in another appropriate document (e.g., an
   Applicability Statement; see section 3.2).

While moving the previous version to Historic status is the normal process,=
 if that doesn't occur, then somehow the relationship between the two versi=
ons of the standard (including, I would think, the expectations placed on i=
mplementers) needs to be clearly outlined. The text of the new version stat=
es that it is the successor to the old version, so that's not particularly =
helpful. Perhaps the intent would be that the IPv6 specification must be me=
t for IP interoperability while the IPv4 specification may optionally also =
be employed? While the IETF could still work on the IPv4 specification if t=
he need arose, perhaps some specific guidance on the scope of such work cou=
ld be set. At a minimum, I don't think any such updates to the specificatio=
n could be considered required.

I'll say that I believe the normal course of action declaring the IPv4 spec=
ification historic as Lee proposed would work just fine. The IESG retains t=
he ability to authorize work on the specification if it's really needed but=
 the status of the specification at that point seems well-defined and under=
stood. I also don't have any issues with an alternative process as long as =
it's also well-defined. I think it would be a problem for the IETF to publi=
sh two different versions of the IP specification as full standards without=
 also trying to clearly define what that meant. If the older specification =
is not historic, what is it? What must be implemented in a product for it t=
o have met all the required elements for IP interoperability. If both are f=
ull standards with no other guidance, then wouldn't a product have to imple=
ment the required elements of both to be considered to have met the IP spec=
ification?

The normal process would be to declare v4 historic when its successor speci=
fication is promoted to full standard status. Lee simply started a conversa=
tion about that process. Admittedly, changing the specification for the Int=
ernet Protocol (IP) itself is a pretty big deal, so something other than th=
e normal process may be warranted. Personally, I didn't find any of the arg=
uments at the session against moving the specification to historic status (=
as defined within the context of the IETF) particularly compelling, but I a=
lso don't object to defining a different relationship. I do object to simpl=
y making both specifications a requirement across the board in order to ach=
ieve IP interoperability. Sure, in practice most products will implement bo=
th. But in a contained environment with constrained resources, a new produc=
t (say a network of factory sensors) may decide the v6 version of the IP sp=
ecification best meets its needs and implement only that protocol in its se=
nsors. I'm sure such an implementer would not feel constrained by the way t=
he IETF labeled its specifications, but the relationship should be defined =
so that is explicitly supported. Moreover, if v6 is the successor specifica=
tion, then a v4 only implementation cannot be considered to have met the in=
teroperability requirements of the IP specification. Again, an implementer =
will do whatever they want, but that choice should not be supported by the =
specification.

Of course, if I understand the process correctly, if the IETF does nothing =
to define the relationship and leaves both versions of the specification as=
 full standards, by default that means the required elements of both versio=
ns of the specification are always just that -- required for any IP impleme=
ntation.

Those are my thoughts, such as they are. I support following the normal pro=
cess, but if that's not done, then an AS or something else should be publis=
hed explicitly defining what having two active IP specification versions me=
ans in practice.

Scott


From nobody Mon Apr 11 09:18:47 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA4A12F0CE for ; Mon, 11 Apr 2016 09:18:46 -0700 (PDT)
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 KJmQjPBglWyI for ; Mon, 11 Apr 2016 09:18:45 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 D607012F0CD for ; Mon, 11 Apr 2016 09:18:44 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id n3so111761906wmn.0 for ; Mon, 11 Apr 2016 09:18:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=Jx87hoGd5xI6CybYBDNed7YLiaep6Cyne+nJ1TwREsA=; b=mrdzItTO8wqQoVH0jMLjDEt4bjAiu2l9mHNrT1C85ose35Kd+RubFQeEU8S1ScS5y0 o4h8hRXK1UT1v2emWJasr2f6CnWHTIdhNp2YXM38yFZi6aGLmwPyxEnlnLjOnvyIkqBI h+cWWhoWy10nxW3wk39e8DiPy2beJhSdhf3TPR4uHSu31lG8P15Ateyl9oY3shyPzhci fzdzBwoq/Hp+mgQtDIqQiBKA1LmmfDEXj49e5sJDLbiQDy0gWHet2qXBPZV4sc5rN4rt 8N2XzItLFuyEbdKeTj/vEImAjPmnWxjZB7MuAe1C6M9ygUqNRhbqd6QGWW05JNJkU+Lx Vl3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Jx87hoGd5xI6CybYBDNed7YLiaep6Cyne+nJ1TwREsA=; b=lUbJr57VwclrlAlc0nDjzf2XM3zeO/rCl7x7n2zekeuIEwAUZIN4svg0QM1ZsPnkpB BQoC6gO/OmAbWf9q4NBmy5P0phq8GaMulNsXh99wuq1tRBVOk+//i4XZrTw4dNSftLhB l8plX2PUokT+vCvxiBSfBtF0z6GLRmbCi4e5TsMXy/IvGhILXTpCYwu0lqDhCU4srK/r gpeYBJkq9Ipwhm3uTqc+C+VC6WKj85+M0k4/KVZ2k2B6yTe30IaVjpAIa7CWW/xsBrsq I0HHSgsc6dPifJQCm0Y3biUWhqa1DGpCx5m/oS9q7MQT0fTcZKIpn1i46V6t9fuoefUv Ixjw==
X-Gm-Message-State: AD7BkJLM6HA8WX4/z1XUZyUSgDNxS9FXQn/JMt1p2hHPZq15QrdUcSX5z71lvfTz4VEqzA==
X-Received: by 10.194.95.198 with SMTP id dm6mr26449523wjb.136.1460391523408;  Mon, 11 Apr 2016 09:18:43 -0700 (PDT)
Received: from ISOC-A1FD58.local ([185.49.141.195]) by smtp.googlemail.com with ESMTPSA id k125sm18047856wmb.14.2016.04.11.09.18.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Apr 2016 09:18:42 -0700 (PDT)
To: Lee Howard , "George, Wes" , "sunset4@ietf.org" 
References: <5704F8BA.20400@gmail.com>  <570628B7.9010301@gmail.com> 
From: Andrei Robachevsky 
Message-ID: <570BCE60.9020105@gmail.com>
Date: Mon, 11 Apr 2016 18:18:40 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QPiOj7OoNGegiXLAhgKfQhpRFK77oNAn9"
Archived-At: 
Subject: Re: [sunset4] Mandating use of IPv6 in examples
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 16:18:46 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--QPiOj7OoNGegiXLAhgKfQhpRFK77oNAn9
Content-Type: multipart/mixed; boundary="4a4cJAwWJPkJa6kSXbj8hFX421UXts01V"
From: Andrei Robachevsky 
To: Lee Howard , "George, Wes" ,
 "sunset4@ietf.org" 
Message-ID: <570BCE60.9020105@gmail.com>
Subject: Re: [sunset4] Mandating use of IPv6 in examples
References: <5704F8BA.20400@gmail.com>
  <570628B7.9010301@gmail.com>
 
In-Reply-To: 

--4a4cJAwWJPkJa6kSXbj8hFX421UXts01V
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Lee Howard wrote on 08/04/16 19:16:
> Thanks to Henrik for this!
>=20

Indeed! Technology rules!

> https://tools.ietf.org/tools/idnits/changelog
>=20
> 2.14.01 
> (diff-2.14.01=20
> )
>=20
>=20
> * Added a comment about adding IPv6 examples for documents that uses
> addresses from the IPv4 documentation range, without having any
> from the IPV6 documentation range
> * Changed some references to RFC5735 to instead mention RFC6980.

One nit, It'd be better to say:
non-RFC6890-compliant IPv4 or IPv6 addresses

Andrei


>=20
> ( Henrik Levkowetz   06 Apr 2016 9:57:59 +0100)
>=20
>=20
>=20
> Lee
>=20
>=20
> On 4/7/16, 6:30 AM, "sunset4 on behalf of Andrei Robachevsky"
>  wr=
ote:
>=20
>> Thanks everyone for your comments and general support.
>>
>> George, Wes wrote on 06/04/16 16:59:
>> [...]
>>
>>> I think this is very similar to what happens when people
>>> use randomly chosen IP addresses or ASNs for examples instead of the
>>> proper documentation ones - someone points out that a change needs to=
 be
>>> made, and we all move on. That might mean that it doesn't actually ne=
ed
>>> to
>>> progress as an RFC, having served its purpose as an I-D to start the
>>> discussion.
>>
>> Agree, still I think a document like this can ensure better consistenc=
y
>> and raise awareness.
>>
>> [...]
>>>
>>> To the content of the document:
>>> From a strict RFC2119 normative keyword interpretation, I'm don't thi=
nk
>>> that MUST is the right word here, since you caveat that MUST with
>>> "unless..."
>>
>> Good point. I incorporated the comments and also toned the document do=
wn
>> a bit. There are indeed legitimate cases where IPv6 examples are not
>> applicable.
>>
>> Here it is:
>>
>> https://www.ietf.org/internet-drafts/draft-robachevsky-mandating-use-o=
f-ip
>> v6-examples-01.txt
>>
>> Andrei
>>
>> _______________________________________________
>> sunset4 mailing list
>> sunset4@ietf.org
>> https://www.ietf.org/mailman/listinfo/sunset4
>=20
>=20



--4a4cJAwWJPkJa6kSXbj8hFX421UXts01V--

--QPiOj7OoNGegiXLAhgKfQhpRFK77oNAn9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2
Comment: GPGTools - https://gpgtools.org

iEUEARECAAYFAlcLzmEACgkQljz5tZmtij/CPACYy6dV8jZHgSELUZ3uwyvr94mD
pwCeJvXpcu1WODLrg1GVNaoORkd5ctM=
=ZssO
-----END PGP SIGNATURE-----

--QPiOj7OoNGegiXLAhgKfQhpRFK77oNAn9--


From nobody Mon Apr 11 12:00:47 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C456512F3C9 for ; Mon, 11 Apr 2016 12:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.593
X-Spam-Level: *
X-Spam-Status: No, score=1.593 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 Jlbrt27wwvaP for ; Mon, 11 Apr 2016 12:00:42 -0700 (PDT)
Received: from cdcipgw01.twcable.com (unknown [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC3712F38F for ; Mon, 11 Apr 2016 12:00:30 -0700 (PDT)
X-SENDER-IP: 10.64.163.155
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.24,469,1454994000";  d="scan'208,217";a="595675937"
Received: from unknown (HELO exchpapp14.corp.twcable.com) ([10.64.163.155]) by cdcipgw01.twcable.com with ESMTP/TLS/AES256-SHA; 11 Apr 2016 15:00:14 -0400
Received: from EXCHPAPP06.corp.twcable.com (10.64.163.147) by exchpapp14.corp.twcable.com (10.64.163.155) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Mon, 11 Apr 2016 15:00:28 -0400
Received: from EXCHPAPP06.corp.twcable.com (10.64.163.147) by EXCHPAPP06.corp.twcable.com (10.64.163.147) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Mon, 11 Apr 2016 15:00:27 -0400
Received: from EXCHPAPP06.corp.twcable.com ([10.64.163.147]) by EXCHPAPP06.corp.twcable.com ([10.64.163.147]) with mapi id 15.00.1156.000; Mon, 11 Apr 2016 15:00:27 -0400
From: "George, Wes" 
To: "sunset4@ietf.org" 
Thread-Topic: Draft meeting minutes
Thread-Index: AQHRlCRpOFOfNWHf+kWUgFrTLk2d5w==
Date: Mon, 11 Apr 2016 19:00:27 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.64.163.240]
x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22252.005
x-tm-as-result: No--34.458000-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_D3316C8A84FBCwesleygeorgetwcablecom_"
MIME-Version: 1.0
Archived-At: 
Subject: [sunset4] Draft meeting minutes
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Apr 2016 19:00:45 -0000

--_000_D3316C8A84FBCwesleygeorgetwcablecom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlc2UgYXJlIHRoZSBkcmFmdCBtZWV0aW5nIG1pbnV0ZXMuIFBsZWFzZSByZXZpZXcgYW5kIGlz
c3VlIGNvcnJlY3Rpb25zIEFTQVAuDQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85
NS9taW51dGVzL21pbnV0ZXMtOTUtc3Vuc2V0NA0KDQpUaGFua3MsDQoNCldlcw0KDQpBbnl0aGlu
ZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFueeKAmXMgbWFpbCBz
ZXJ2ZXIsIEkgaGF2ZSBubyBjb250cm9sIG92ZXIgaXQuDQotLS0tLS0tLS0tLQ0KDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBh
dHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZv
cm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRv
IGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlz
IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkg
dG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj
aXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBk
aXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiBy
ZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWls
IGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUg
cmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp
bW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNv
cHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg==

--_000_D3316C8A84FBCwesleygeorgetwcablecom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2PlRoZXNlIGFyZSB0aGUgZHJhZnQgbWVldGluZyBtaW51dGVzLiBQbGVhc2UgcmV2aWV3IGFu
ZCBpc3N1ZSBjb3JyZWN0aW9ucyBBU0FQLjwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL3d3
dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NS9taW51dGVzL21pbnV0ZXMtOTUtc3Vuc2V0NCI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTUvbWludXRlcy9taW51dGVzLTk1LXN1bnNl
dDQ8L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPlRo
YW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46
IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg
Zm9udC1zaXplOiAxMXB0OyI+V2VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7Ij48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBp
biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdi
KDEyNywgMTI3LCAxMjcpOyI+QW55dGhpbmcgYmVsb3cgdGhpcyBsaW5lIGhhcyBiZWVuIGFkZGVk
IGJ5IG15IGNvbXBhbnnigJlzIG1haWwgc2VydmVyLCBJIGhhdmUgbm8gY29udHJvbCBvdmVyIGl0
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn
aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxzcGFuIHN0eWxlPSJjb2xv
cjogcmdiKDEyNywgMTI3LCAxMjcpOyI+LS0tLS0tLS0tLS08L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPGhyPg0KPGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5
IiBzaXplPSIxIj48YnI+DQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBt
YXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hp
Y2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBi
ZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNv
bGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8NCiB3aGljaCBp
dCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2Yg
dGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRp
b24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRv
IHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0
bHkgcHJvaGliaXRlZCBhbmQgbWF5DQogYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVk
IHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl
bHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRo
aXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuPGJyPg0KPC9mb250Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_D3316C8A84FBCwesleygeorgetwcablecom_--


From nobody Mon Apr 11 23:07:34 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982CE12D1C9 for ; Mon, 11 Apr 2016 23:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.297
X-Spam-Level: 
X-Spam-Status: No, score=-5.297 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_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 fiagNkTJj1Fh for ; Mon, 11 Apr 2016 23:07:30 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 2628312B012 for ; Mon, 11 Apr 2016 23:07:28 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id B9F3AA2; Tue, 12 Apr 2016 08:07:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1460441245; bh=Kj2c4ub2PpLWovVHIGqj3pXUa4CGzIX1RFreQP2yo98=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=y2/dLZ7czz7fLq52LhqfwGqVzb5uIEhOnwGTWdY2Zh8lQt/AsTknf7+dlcXfpzZpH diMh/9E1sznSas/qTyXnj3v6S9ByGiFtiZFGpz2MEKBXH2GAFQg+1sdvPIsogso6ZJ xbxr2iljl0G6/ujEWUA8aIFQlVrKC1JboW1gPW+A=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B0133A1; Tue, 12 Apr 2016 08:07:25 +0200 (CEST)
Date: Tue, 12 Apr 2016 08:07:25 +0200 (CEST)
From: Mikael Abrahamsson 
To: "George, Wes" 
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: 
Cc: "sunset4@ietf.org" 
Subject: Re: [sunset4] Draft meeting minutes
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 06:07:32 -0000

On Mon, 11 Apr 2016, George, Wes wrote:

> These are the draft meeting minutes. Please review and issue corrections ASAP.
> https://www.ietf.org/proceedings/95/minutes/minutes-95-sunset4

I called out speakers in Jabber. So:

"??? observes that we aren't using IPv6 in examples in IETF, default 
networks aren't IPv6-only."

"??? possible for community to push on WG charters to ensure that 
IPv4-specific work doesn't make it into charter"

One of these should be Ruediger Volk, but it seems I missed to call out 
one speaker because there is only a single name mentioned on Jabber 
between the ones above/below the above ??? lines.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Tue Apr 12 05:49:09 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB3112E59B for ; Tue, 12 Apr 2016 05:49:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.828
X-Spam-Level: 
X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 udSXuOy20Uer for ; Tue, 12 Apr 2016 05:49:02 -0700 (PDT)
Received: from cdpipgw01.twcable.com (unknown [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 023A112EC61 for ; Tue, 12 Apr 2016 05:49:01 -0700 (PDT)
X-SENDER-IP: 10.64.163.149
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.24,474,1454994000"; d="scan'208";a="1243290079"
Received: from unknown (HELO exchpapp08.corp.twcable.com) ([10.64.163.149]) by cdpipgw01.twcable.com with ESMTP/TLS/AES256-SHA; 12 Apr 2016 08:46:02 -0400
Received: from EXCHPAPP06.corp.twcable.com (10.64.163.147) by exchpapp08.corp.twcable.com (10.64.163.149) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 12 Apr 2016 08:48:42 -0400
Received: from EXCHPAPP06.corp.twcable.com ([10.64.163.147]) by EXCHPAPP06.corp.twcable.com ([10.64.163.147]) with mapi id 15.00.1156.000; Tue, 12 Apr 2016 08:48:42 -0400
From: "George, Wes" 
To: Mikael Abrahamsson 
Thread-Topic: [sunset4] Draft meeting minutes
Thread-Index: AQHRlLmkP9Y1oEondUS2etJOXS2Dqg==
Date: Tue, 12 Apr 2016 12:48:42 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.64.163.240]
x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22254.004
x-tm-as-result: No--49.426800-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "sunset4@ietf.org" 
Subject: Re: [sunset4] Draft meeting minutes
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 12:49:07 -0000

WWVzLCBhbmQgSSBkaWQgdXNlIHRoZSBleGNlbGxlbnQgamFiYmVyIGxvZ3MgdG8gc3VwcGxlbWVu
dCBGcmVkJ3Mgbm90ZXMsDQpob3dldmVyIHNvbWUgb2YgdGhvc2UgY29tbWVudHMgd2VyZSBhY3R1
YWxseSBtaXNzaW5nIGZyb20gRnJlZCdzIG5vdGVzLA0KYW5kIGZpbGxlZCBpbiBmcm9tIG15IHJh
dyBub3RlcyAoSSBzdHVwaWRseSBkaWRuJ3Qgbm90ZSBzcGVha2VyKSBhbmQgbWF5DQpub3QgYmUg
aW4gZXhhY3RseSBjaHJvbm9sb2dpY2FsIG9yZGVyIHNpbmNlIEkgd2FzIGJhc2ljYWxseSBmaWxs
aW5nIGluDQpnYXBzIGZyb20gbWVtb3J5LCBzbyBJIGFtIGhvcGluZyB0aGF0IHRoZSBzcGVha2Vy
cyB3aWxsIGNsYWltIHRoZWlyIHF1b3Rlcw0KZGVmaW5pdGl2ZWx5Lg0KDQpUaGFua3MsDQoNCldl
cw0KDQoNCg0KDQpPbiA0LzEyLzE2LCAyOjA3IEFNLCAiTWlrYWVsIEFicmFoYW1zc29uIiA8c3dt
aWtlQHN3bS5wcC5zZT4gd3JvdGU6DQoNCj5PbiBNb24sIDExIEFwciAyMDE2LCBHZW9yZ2UsIFdl
cyB3cm90ZToNCj4NCj4+IFRoZXNlIGFyZSB0aGUgZHJhZnQgbWVldGluZyBtaW51dGVzLiBQbGVh
c2UgcmV2aWV3IGFuZCBpc3N1ZQ0KPj5jb3JyZWN0aW9ucyBBU0FQLg0KPj4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTUvbWludXRlcy9taW51dGVzLTk1LXN1bnNldDQNCj4NCj5J
IGNhbGxlZCBvdXQgc3BlYWtlcnMgaW4gSmFiYmVyLiBTbzoNCj4NCj4iPz8/IG9ic2VydmVzIHRo
YXQgd2UgYXJlbid0IHVzaW5nIElQdjYgaW4gZXhhbXBsZXMgaW4gSUVURiwgZGVmYXVsdA0KPm5l
dHdvcmtzIGFyZW4ndCBJUHY2LW9ubHkuIg0KPg0KPiI/Pz8gcG9zc2libGUgZm9yIGNvbW11bml0
eSB0byBwdXNoIG9uIFdHIGNoYXJ0ZXJzIHRvIGVuc3VyZSB0aGF0DQo+SVB2NC1zcGVjaWZpYyB3
b3JrIGRvZXNuJ3QgbWFrZSBpdCBpbnRvIGNoYXJ0ZXIiDQo+DQo+T25lIG9mIHRoZXNlIHNob3Vs
ZCBiZSBSdWVkaWdlciBWb2xrLCBidXQgaXQgc2VlbXMgSSBtaXNzZWQgdG8gY2FsbCBvdXQNCj5v
bmUgc3BlYWtlciBiZWNhdXNlIHRoZXJlIGlzIG9ubHkgYSBzaW5nbGUgbmFtZSBtZW50aW9uZWQg
b24gSmFiYmVyDQo+YmV0d2VlbiB0aGUgb25lcyBhYm92ZS9iZWxvdyB0aGUgYWJvdmUgPz8/IGxp
bmVzLg0KPg0KPi0tDQo+TWlrYWVsIEFicmFoYW1zc29uICAgIGVtYWlsOiBzd21pa2VAc3dtLnBw
LnNlDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhpcyBFLW1haWwg
YW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUg
cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlh
bCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxl
LiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2
aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3Qg
dGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90
aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBh
Y3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50
cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdm
dWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90
aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3Jp
Z2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo=


From nobody Tue Apr 12 06:38:36 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBBF12D1EA for ; Tue, 12 Apr 2016 06:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.297
X-Spam-Level: 
X-Spam-Status: No, score=-5.297 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_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 wesNlstYCm-L for ; Tue, 12 Apr 2016 06:38:32 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 8224512DF4D for ; Tue, 12 Apr 2016 06:38:32 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id E411EA2; Tue, 12 Apr 2016 15:38:29 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1460468309; bh=9X1Frr7o+wpfLKEeZ36tPzghCp1M/nLHkHfN6pVXngE=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=p5G+xePPhoDIHJod1Xlc1e/tB5Cun5N950SDrvR7eNKP6ffxt9cFhdwqeij9+7Utw xgEiAUn7bmpJ9A/IthdnJEZkwSPpfeVCAtJgvqAGN8HFaUWDmYNXZzvx9bl1cJi2oP Cm9B9+YgZWbRF464EgRj7C+r8H5yB8iZS+3V+XnQ=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DCCD4A1; Tue, 12 Apr 2016 15:38:29 +0200 (CEST)
Date: Tue, 12 Apr 2016 15:38:29 +0200 (CEST)
From: Mikael Abrahamsson 
To: "George, Wes" 
In-Reply-To: 
Message-ID: 
References:   
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: 
Cc: "sunset4@ietf.org" 
Subject: Re: [sunset4] Draft meeting minutes
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Apr 2016 13:38:34 -0000

On Tue, 12 Apr 2016, George, Wes wrote:

> Yes, and I did use the excellent jabber logs to supplement Fred's notes,
> however some of those comments were actually missing from Fred's notes,
> and filled in from my raw notes (I stupidly didn't note speaker) and may
> not be in exactly chronological order since I was basically filling in
> gaps from memory, so I am hoping that the speakers will claim their quotes
> definitively.

http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF95_SUNSET4&chapter=chapter_1

Seems Ruediger was the first one (56minutes in), and there was nobody 
after him before Petr (at 56m40s in).

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Mon Apr 18 01:56:16 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA7312DFC5 for ; Mon, 18 Apr 2016 01:56:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.333
X-Spam-Level: 
X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 qfZ2U2BKL9qN for ; Mon, 18 Apr 2016 01:56:12 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C1BE12E08F for ; Mon, 18 Apr 2016 01:56:11 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id u3I8u9As003837 for ; Mon, 18 Apr 2016 10:56:09 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 551CF20A093 for ; Mon, 18 Apr 2016 10:57:35 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 42653201292 for ; Mon, 18 Apr 2016 10:57:35 +0200 (CEST)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id u3I8u93P024395 for ; Mon, 18 Apr 2016 10:56:09 +0200
To: sunset4@ietf.org
References: <5704F8BA.20400@gmail.com>
From: Alexandre Petrescu 
Message-ID: <5714A129.2080302@gmail.com>
Date: Mon, 18 Apr 2016 10:56:09 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <5704F8BA.20400@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [sunset4] Mandating use of IPv6 in examples
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Apr 2016 08:56:14 -0000

I strongly agree with the idea.

It should be noted it is as quick to type
2001:db8::1 as
192.168.1.1 is, but longer than
10.1.1.1 is.

On another hand, the shortest IPv4 address is
1.1.1.1 whereas IPv6 is 1::1.

Alex

Le 06/04/2016 13:53, Andrei Robachevsky a écrit :
> Hi,
>
> I recently submitted an I-D
> draft-robachevsky-mandating-use-of-ipv6-examples-00.txt, mandating use
> of IPv6 in examples in RFCs.
>
> I was reading some pretty recent drafts and noticed that authors
> continue using IPv4 in their examples. This is probably more convenient,
> but is not really forward thinking. Also, the prevalence of IPv6
> examples will send a strong message that IPv4 is essentially a legacy
> protocol.
>
> I wonder if this WG is interested in progressing this document as a WG
> item.
>
> Thanks,
>
> Andrei
>
>
>> Name:		draft-robachevsky-mandating-use-of-ipv6-examples
>> Revision:	00
>> Title:		Mandating use of IPv6 in examples
>> Document date:	2016-03-21
>> Group:		Individual Submission
>> Pages:		3
>> URL:            https://www.ietf.org/internet-drafts/draft-robachevsky-mandating-use-of-ipv6-examples-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-robachevsky-mandating-use-of-ipv6-examples/
>> Htmlized:       https://tools.ietf.org/html/draft-robachevsky-mandating-use-of-ipv6-examples-00
>>
>>
>> Abstract:
>>     IPv6 is a successor of the legacy IPv4 protocol.  This document
>>     mandates use of IPv6 in examples provided in RFCs.
>
>
>
> _______________________________________________
> sunset4 mailing list
> sunset4@ietf.org
> https://www.ietf.org/mailman/listinfo/sunset4
>


From nobody Mon Apr 18 09:40:47 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5488312E298 for ; Mon, 18 Apr 2016 09:40:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.445
X-Spam-Level: 
X-Spam-Status: No, score=-2.445 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=-0.996, SPF_PASS=-0.001, UNRESOLVED_TEMPLATE=1.252] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 EUdSg3s03Gkn for ; Mon, 18 Apr 2016 09:40:44 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id AC5EC12E297 for ; Mon, 18 Apr 2016 09:40:44 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E2025433418 for ; Mon, 18 Apr 2016 16:40:43 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id CC19E433417 for ; Mon, 18 Apr 2016 16:40:43 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1460997643; bh=FMFRnYC6IrHgGPi2tjvRrchJd+DYZ0IT7Tn7vQ3fGcY=; l=1457; h=Date:From:To:From; b=l0EMI16GIoWSNDctr+U0Utjz0HS/9C6NtF5TMkIWkujY+Fwrp3MMpK5QusJOtPkT1 +0RdjGD3O7NwCSTLIBNU8l3PcJf4bYEeTm6nEeAXMeIU+20oqJ0qec/NeoX0buNuQI cVfT3F8zcCClmYFomeIJCwdC7UReqbxBm7FZ8hYM=
Received: from bos-lpbwe.kendall.corp.akamai.com (bos-lpbwe.kendall.corp.akamai.com [172.28.9.166]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id C86241FC8D for ; Mon, 18 Apr 2016 16:40:43 +0000 (GMT)
Received: from dplonka by bos-lpbwe.kendall.corp.akamai.com with local (Exim 4.82) (envelope-from ) id 1asCE7-0008Bg-Mx for sunset4@ietf.org; Mon, 18 Apr 2016 12:40:43 -0400
Date: Mon, 18 Apr 2016 12:40:43 -0400
From: Dave Plonka 
To: sunset4@ietf.org
Message-ID: <20160418164043.GA31078@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-URL: http://www.cs.wisc.edu/~plonka/
X-VMS-Error: %SYSTEM-F-RDDELDATA, read deleted data address mark
X-Shakespearean-Insult: Thou currish bat-fowling mammet
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: [sunset4] "Restricted Standard" for IPv4 rather than "Historic"?
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Apr 2016 16:40:46 -0000

Hi folks,

While listening to the reasonable comments about Lee's draft in
the sunset4 meeting, I was most struck that this is an exceptional
circumstance that might warrant something other than IPv4 maturing
from "Internet Standard" to "Historic" at this time.

What some would clearly like to do is to clarify, qualify, and/or
restrict how IPv4 is used, and also clearly convey this in the
technical specification RFC.

I propose we create a new maturity level for standards track called
"Restriced Standard" meaning that the standard has been updated by
a new Applicability Statement RFC that restricts its application.

Currently, we clarify the use of a standard in a concurrently-published
Applicability Statement (AS) either contained in a Technical
Specifications RFC or as separate RFC(s):

   https://tools.ietf.org/html/rfc2026#section-3.2

The AS specifies what technical specifications are "required,"
"limited use," "not recommended," etc.:

   https://tools.ietf.org/html/rfc2026#section-3.3

I haven't found a formal AS for either IPv4 and IPv6 specifications.

Does anyone know of a precedent for a standards track protocol
being updated by an AS published long after it matured to "Internet
Standard"?

Thoughts?

Dave

P.S. If the community believes "Restricted Standard" is, well,
too restrictive, perhaps "Qualified Standard?"

-- 
plonka@akamai.com  http://www.cs.wisc.edu/~plonka/  Cambridge, MA


From nobody Tue Apr 19 13:07:44 2016
Return-Path: 
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA85412DB4B for ; Tue, 19 Apr 2016 13:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Level: 
X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no 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 IYNUGd0SKBGS for ; Tue, 19 Apr 2016 13:07:41 -0700 (PDT)
Received: from cdpipgw02.twcable.com (unknown [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id A578012D816 for ; Tue, 19 Apr 2016 13:07:40 -0700 (PDT)
X-SENDER-IP: 10.64.163.146
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.24,507,1454994000"; d="scan'208";a="1036637886"
Received: from unknown (HELO exchpapp05.corp.twcable.com) ([10.64.163.146]) by cdpipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 19 Apr 2016 16:03:32 -0400
Received: from EXCHPAPP06.corp.twcable.com (10.64.163.147) by exchpapp05.corp.twcable.com (10.64.163.146) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 19 Apr 2016 16:07:39 -0400
Received: from EXCHPAPP06.corp.twcable.com ([10.64.163.147]) by EXCHPAPP06.corp.twcable.com ([10.64.163.147]) with mapi id 15.00.1156.000; Tue, 19 Apr 2016 16:07:39 -0400
From: "George, Wes" 
To: Mikael Abrahamsson 
Thread-Topic: [sunset4] Draft meeting minutes
Thread-Index: AQHRmncf4ybpCHETwUC9H0deuixJ7A==
Date: Tue, 19 Apr 2016 20:07:38 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.6.3.160329
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.64.163.240]
x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22270.005
x-tm-as-result: No--39.047300-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="utf-8"
Content-ID: <4D947DDDB28B2F45A3833E89EFD142F5@twcable.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "sunset4@ietf.org" 
Subject: Re: [sunset4] Draft meeting minutes
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: sunset4 working group discussion list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 19 Apr 2016 20:07:43 -0000

TWludXRlcyBoYXZlIGJlZW4gdXBkYXRlZCB3aXRoIHRoZXNlIGNoYW5nZXMgYXMgd2VsbCBhcyBz
dXBwbGVtZW50YWwgbm90ZXMNCmZyb20gTGVlIEhvd2FyZCAod2hvIHJldmlld2VkIHRoZSByZWNv
cmRpbmcgYW5kIHRvb2sgaGlzIG93biBub3RlcykNCg0KVGhhbmtzLA0KDQpXZXMNCg0KDQoNCg0K
T24gNC8xMi8xNiwgOTozOCBBTSwgIk1pa2FlbCBBYnJhaGFtc3NvbiIgPHN3bWlrZUBzd20ucHAu
c2U+IHdyb3RlOg0KDQo+T24gVHVlLCAxMiBBcHIgMjAxNiwgR2VvcmdlLCBXZXMgd3JvdGU6DQo+
DQo+PiBZZXMsIGFuZCBJIGRpZCB1c2UgdGhlIGV4Y2VsbGVudCBqYWJiZXIgbG9ncyB0byBzdXBw
bGVtZW50IEZyZWQncyBub3RlcywNCj4+IGhvd2V2ZXIgc29tZSBvZiB0aG9zZSBjb21tZW50cyB3
ZXJlIGFjdHVhbGx5IG1pc3NpbmcgZnJvbSBGcmVkJ3Mgbm90ZXMsDQo+PiBhbmQgZmlsbGVkIGlu
IGZyb20gbXkgcmF3IG5vdGVzIChJIHN0dXBpZGx5IGRpZG4ndCBub3RlIHNwZWFrZXIpIGFuZCBt
YXkNCj4+IG5vdCBiZSBpbiBleGFjdGx5IGNocm9ub2xvZ2ljYWwgb3JkZXIgc2luY2UgSSB3YXMg
YmFzaWNhbGx5IGZpbGxpbmcgaW4NCj4+IGdhcHMgZnJvbSBtZW1vcnksIHNvIEkgYW0gaG9waW5n
IHRoYXQgdGhlIHNwZWFrZXJzIHdpbGwgY2xhaW0gdGhlaXINCj4+cXVvdGVzDQo+PiBkZWZpbml0
aXZlbHkuDQo+DQo+aHR0cDovL3JlY3MuY29uZi5tZWV0ZWNoby5jb20vUGxheW91dC93YXRjaC5q
c3A/cmVjb3JkaW5nPUlFVEY5NV9TVU5TRVQ0JmMNCj5oYXB0ZXI9Y2hhcHRlcl8xDQo+DQo+U2Vl
bXMgUnVlZGlnZXIgd2FzIHRoZSBmaXJzdCBvbmUgKDU2bWludXRlcyBpbiksIGFuZCB0aGVyZSB3
YXMgbm9ib2R5DQo+YWZ0ZXIgaGltIGJlZm9yZSBQZXRyIChhdCA1Nm00MHMgaW4pLg0KPg0KPi0t
DQo+TWlrYWVsIEFicmFoYW1zc29uICAgIGVtYWlsOiBzd21pa2VAc3dtLnBwLnNlDQoNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBp
dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkg
aW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVj
dCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFp
bCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50
aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk
IHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBh
bnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4g
aW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUt
bWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBo
YXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k
ZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFu
eSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo=