Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

t.petch <ietfc@btconnect.com> Thu, 20 October 2016 09:15 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67AC129547 for <idr@ietfa.amsl.com>; Thu, 20 Oct 2016 02:15:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 gUuQTnS8Dmae for <idr@ietfa.amsl.com>; Thu, 20 Oct 2016 02:15:40 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0093.outbound.protection.outlook.com [104.47.0.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA4712950E for <idr@ietf.org>; Thu, 20 Oct 2016 02:15:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oNeIhHViHZuyg2vkaGF47gu3EMvV45JJ3XvkDWVHykw=; b=J7haGKfb77E1sFbLSllP2vz92UsIAgGhM3EP35OYot6grLwvDDUF14PEQe7WY/mMAlfRa8hftVgelBgm378pD5hfLw+cMGJO4uA+xyePicqfAOpF9XFjczg+VjKlph6UVr5HDy5l38Y2VxrEPZBqrpmEitkeSy8x0GF1xUzzxIY=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
Received: from pc6 (81.159.102.255) by HE1PR0701MB3003.eurprd07.prod.outlook.com (10.168.93.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.5; Thu, 20 Oct 2016 09:15:35 +0000
Message-ID: <01ac01d22ab2$2c05f960$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <df2e7d4669d64fa59b1e1cfcb188dbbb@XCH-ALN-014.cisco.com>
Date: Thu, 20 Oct 2016 09:55:27 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.159.102.255]
X-ClientProxiedBy: DB6PR0601CA0031.eurprd06.prod.outlook.com (10.169.209.17) To HE1PR0701MB3003.eurprd07.prod.outlook.com (10.168.93.137)
X-MS-Office365-Filtering-Correlation-Id: 4106a339-d571-4556-451f-08d3f8c9a6c2
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 2:a48K65x6KYsK6WsI7DslHNZ0x5kwcC0Y8Op1ODPfg/cFRyQTCxcpLi8yFyfVzXO4D/f2uK5tuzKbbQals2wkL01jNMX1FdD1XYwn4QWRbjKe/dFH2YBlX+wzrV458GX4RpjXbEeEPtqlsxwkdLdo6hsdj2X5G4Rr2v78lOVEmvxdPaA8Jy6qS+SpjyMiSnO221MdSyW9nhnyzrbalarQNA==; 3:YGgLIk8u6HGE55BDNa3Dawod47lCOPRzu94RU9R3iyZX/IiNTme+WuFkFlUyfn7FBwmX3e0C/8IjlXT38bnEbc3/xZv1LHryk19G2W3VGICZtkwBnw6o9Dzscy46yAxKZxzhJMwh2L/AZQs2AwS4Fg==; 25:+RmlqVv5ed2PD3Aw02LZNhKzfaajq1PFzzGupqTrHQ6oMyuFll7d6qzTE9Q7Igx+fFe4SzQOtQpZdc+ULWf1WHF3RyYuQGP5Kg96xjsepr0neNmo7VeZMbvRLTxJBqkM8AB3YunbhMpFffdD9mMNQTL9kikY4wujdSUXPIgODJdSWi2SXpLgzssUk9SP23bQZzfaLgWCV4rNml2v490axDc7JkoCSOtWPSxXLGkIRlJsHeFhH/+EXSlLAXFbiUB5ERKiR3p1KCYcM5KIoCFcMcxUfLxq20bRJWYG5m2KWP7+hF237bP4Hd3FyibCNanaa9tW3AmVHNPTyceqhOxtx/YVcqHAY7uQvQkGlCl7j363M/VsK4q1fXim6+9N+fyCYbp8btJf74bWxqrOFKpWaRGN69bpCOyAs+x7foE1fddQPQo5qUhEPs2FS/PU6VKy
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB3003;
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 31:J0MNsDLzZz//Q05VIwjK/ComihA+zJtG+ICrVnn6zeNSbo0SD1CscMMNlhen2jspsT5ueRk0aHi1sIRosn5nNRGtX4cewr0v2+TbnupXOI6mfTeuTM1uO68q3KVq5d6cKUUMS0OHucTv4WzoldWVPKZxaejT7wCoAD8+AgdwIRg3xK7HmY5bq7eANiPTK7Z3HhMGUmypskyUm8/tOF3N9OvJ7xRqx0s3xXYvQR3bmtLXDJW0KP9M5wE0aaQ+GD4oDjXwDpwKkKhBsr1Bweb8pA==; 4:MDpWe2S1czJlxPcRi2wyOx4Xx+p6ongBi58Qsqm8v4inK8IjLRX3UujfmHfI1PEcvQBgC1h4tEEtZKcVa5bOfBEzjzTY9YNSv2w4jEyAy6W1qDxZ+0QozwWYvYFykG8N7d/J9SQh4UN45bZo68IAgyQjN7rZlJNLdpPTnCHmQC4IOUBLKmkE1NhdQT3Fp917MmmcbkZyu9Fq8x8Xm3nX7uisdh3BHfp5P6N2Lx8XrHad6nFZ+AU1iGtjD+orFa+ty/sANPrDN2H4EDjh9hMpbWcL9AI01ioAgfn3QrX0ybTiznyGGtTrsXrv/x/zmoc7AfZBB0mwv9XV5LR0VD9VVzRcYwjC3kcJXD7I5jRioXnl5HObOIICxipyhXP8qnkTy+vg8j2Ok6hOu+7UJdwQeDJr+LdUmULtxCMidUD4kjZjbglD4G1VIbBn4MucCmymgtnZ77aeRURYJXXDeb1Apmt8GCUVA4EGfTH8C39CaUE=
X-Microsoft-Antispam-PRVS: <HE1PR0701MB30034B3D3446E0DE6F2E102DA0D50@HE1PR0701MB3003.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(95692535739014);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:HE1PR0701MB3003; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3003;
X-Forefront-PRVS: 01018CB5B3
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(5423002)(189002)(377454003)(13464003)(24454002)(199003)(51444003)(6916009)(93886004)(68736007)(84392002)(305945005)(19580395003)(86362001)(50226002)(19580405001)(7846002)(6666003)(2906002)(4326007)(42186005)(105586002)(230700001)(23756003)(44736004)(61296003)(5660300001)(7736002)(97736004)(230783001)(15975445007)(110136003)(1456003)(3846002)(77096005)(1556002)(6116002)(81686999)(101416001)(9686002)(116806002)(81156014)(76176999)(62236002)(92566002)(50986999)(66066001)(586003)(4720700003)(81816999)(8676002)(14496001)(106356001)(44716002)(33646002)(47776003)(81166006)(50466002)(189998001)(116284003)(74416001)(7726001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3003; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3003; 23:KnhaMofikMvRZJdrCehrP+4AuRyJ7fARjdpPs?= =?iso-8859-1?Q?FHHS9ZSEVHlUCO0At9DtjLN/EjaO4aNQjs1dxsZcDAGp+kVZNOu3bi0t5H?= =?iso-8859-1?Q?qqKUMec7FSD1bsN9ynuSK+JfE05gbWTB/yJroVkaBQiCCHQq/qlUlJv8Pj?= =?iso-8859-1?Q?4dnbsdYIHV0ngsZblDD0sl//dvJR4TLOcVCej/3VL1V18OFVY0NsNb/Zy1?= =?iso-8859-1?Q?aMwTU/vHnZJ8QeRzNoog39uJ94R4TKmzxzn1ze0peI5UBixexJ4fbtt2WL?= =?iso-8859-1?Q?67Mfd4g97kSFnDKIp2hMYdKH90dEoZrp0sZEKkgoox/zhiNaU02PMX4A8+?= =?iso-8859-1?Q?RO5bnNKOmQ1m+3JPneKqjUp3oAQc/5YO9SvlBTozAVrKZ1wUbrGAHmDdbJ?= =?iso-8859-1?Q?nWT3vIhSncz7ciJGqu/kp+NCnfg0WVh+xwIdw7TVKg9m1Kr+s/2sap66dM?= =?iso-8859-1?Q?3h6AlvJrFs6gFZcehzSHxB0nj9rOtroaNIcsw5LF2d8M6gxz71cI8jyRLL?= =?iso-8859-1?Q?Q79HW9vn7uQLiSciOw7I4hATmI27ClBEjFRiMcCy2SOWMpodivoGIo0x9C?= =?iso-8859-1?Q?R0Mh4ELRpYaq/pzU0ueHAWBKwa/rArfZCbwAU0LVdTbTbXk/Al8gKpVrkK?= =?iso-8859-1?Q?jETv8JOnEl5f7Fy5+hn6cR/XCCFNem6zzALUXPROxESw5qkBa+wV48bKAt?= =?iso-8859-1?Q?//vngt8A1riEb1rV0u8n8D8Ef1fxYcOUoB9+Tt0xu76+rDflX4cpNRLrld?= =?iso-8859-1?Q?7So2k+VvdWNxRRQmoMTxCVHHtXVe1+5JqlRtvJuXKq+LH1d7JOcTaxHK+u?= =?iso-8859-1?Q?cmsaKeCpiAOhYyJEjo6+GQ8D5MVfrEkDL7lWXms28+ojijbMzySWxKao0u?= =?iso-8859-1?Q?i0axRxU+VvqEzK+SCgdXyQDYKmI1pEqrLJjqTWMkV4Ow1UADi87BiE7nVu?= =?iso-8859-1?Q?7hOSFyszqG7sqyZ2vfLQEcWhUzPWaHPhJA/20hWka54ALkr46jPn/lxAJx?= =?iso-8859-1?Q?oygWHCjBMZxYLs3l0jIwNbjxEszxhZWDG7sNLreoQ5tdUlbIO5BlLl66UV?= =?iso-8859-1?Q?FS51e5PLn4/aeAERzr8FSFg0D7djDhZPz/yZiuiULNVKOt8nQ65c7cBPLR?= =?iso-8859-1?Q?EiuIJ8fCbNGh1QkQmqpkePkVlyGwtkWIXTHtiB6H7DG4AyfUHquKsULyEm?= =?iso-8859-1?Q?iZOkdyAmccuFlV1B2HuxMxaE3okYGa9GzW/x4t6j//IPu1fWaTjoUYXCwS?= =?iso-8859-1?Q?I7doVfIlpNh21SeHJdytfDBYYgEq0qXZaDjm6fh3Kri8SPn9Sj1ELMkD3K?= =?iso-8859-1?Q?TR/Xnkp7QPx/aATWq9VodkYEL6jVzFudiY94KfWdCouz33RzYFTK04aNK9?= =?iso-8859-1?Q?aQX9q1xxdk5/sOC0mQUYCu7rTPlf39KXZKwu1Vl5j2LkrBF83lH4q0k63O?= =?iso-8859-1?Q?wgJjDlWUCyoPd3Pmr7/aSN6VkpENYp90ubx5u51lDuYL7VGVVsBFKcgsHc?= =?iso-8859-1?Q?wAlq9hDx2Jm6qzIYZg12fAR0HfWzb0+lBU2fXIS2un1JuAYBobzKd5ZJy8?= =?iso-8859-1?Q?GOyLrXmIJdXn+EID/SRW+PW5dvGmORu9FmuiF7Mmg2wiRqfoigdpuQ18Bh?= =?iso-8859-1?Q?2r8VnWbUvRuF5OzjQ7n/QTMhvxI7imqpYs=3D?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 6:ToKWZnCDhJvMX0IaIc5vQXyNIatVVPmE6WzHFbFgUDn/e0a3f5Bh6hYWKmzCPCDT1BOs2ivskQ5aGk3GOv9tfI8Qft2SJ1uhNvWPylK9/+pY7IXVGjp52h3rU/QZM00S3KndFHKGenEOxywCgg3DMV3nsYVwEodtuYgYiI6rCNi8pKSS011qJNjn7C6cos9qGpVItOm8IZn+/L14yBS8ExJMMPvJPJ5cvOhmFS/2IW3cGEjD7WUR3CeKn3QPxqH5hQHdy8PMTXEXts9l81DxpRtOUISBvv0rPGVsWLX7GJ1U6MawxtxPuPPqKmZq+M+w; 5:qLV8Mj9UJRtOyMvEaiLnCnwWxwRZmu5U5cwlfsDJc1KqQYU/d8NvP5CO2RN/ZXzXAvHLEu9wbJpBC2hF14PxXV2W3jjQ7cWOJXG/vwPwZhPuKYY2aDts71RwLVOe0u3VoZarU84fGubQ06Ps0QuW9KkQJ7wmPev+u7xJHVTCuVo=; 24:XQTkxrzz9GE7Sj5HGn8QR1YeqB9yR2JaHtL8VYjvXNHQ0DG8YWybi8kC7DAcqchXjfzgWHc/ZW/Np2lOsIQrh/00yf5cBkhk4AhDdwOftg0=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 7:4M06V8IV8Kkya5gjDtpAovaWJkPfz9n7QPsutvpTkVq6WitNm/AiN3lRcFiDqocj456e1jgDUB3UBYH3WFOg4bJ91zG7uaoHjOAvraISbBjTmWr5W4KuGjNfMjiut1ag4q3zj5YifW0Evkaf2W2c52+g7R9XrOevd1kYiG3XxFKgU6x2kJ5LR+Zv1JXSqBN6dRVwe2PKAKFOIrRtgJbuY+dwOPmjyDRIvSlAH7PXtwGuvDNjssCu70crmVvTY6QQNpw33Rym3BJnXsOmsNgnHvPiJMAYH2XG1z73X5tAJK+enKbpB9hQESNK29lZFh5HHMM2sjCFIT2A0mc1AwJZ98GYANW47D1pJHiHIx3FMW0=
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Oct 2016 09:15:35.4472 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3003
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/bNms69W87w_8ht1B3JOXEfCuW9M>
Cc: IETF IDR WG <idr@ietf.org>
Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Oct 2016 09:15:43 -0000

----- Original Message -----
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>;
Sent: Wednesday, October 19, 2016 6:37 PM

1. Router software cannot check whether a number is an ASN.

2. Any numbers should be allowed between consenting adults. That is
within an AS or between adjacent ASes.

3. "Reserved" means reserved for use. So router software cannot disallow
these either.

I can see how the existing text is a little terse:
   The Global Administrator field is intended to allow different
   Autonomous Systems to define Large BGP Communities without collision.

The best we can do is explain the situation:

A Large Community that
is intended to be sent to multiple ASes SHOULD contain an ASN
in the Global Administrator field. The ASN SHOULD be one that
is assigned to the entity
that defines the meaning of the rest of the Large Community.
This allows a route to carry multiple Large Communities, the meaning
of each being defined by different independent entities.

Tom, will this text satisfy you?

<tp>

Jakob

I struggle to find any form of words that will satisfy me that includes
the word 'SHOULD'.  Ironically, if the sentence were to use 'MAY', then
that would probably be ok, since it accurately conveys the meaning that
you may find anything here so you cannot know what it means and so must
have other means of authenticating the community before use.

Or change it to 'MUST' which I think gives a clear sense of what to
expect.  That this cannot be enforced I find a red herring - lack of
enforcement is a fact of life in BGP as currently defined (as the recent
squat on an attribute number shows).  'MUST' would tell any misusers
that they are in the wrong so giving peer pressure a better chance of
getting things fixed.

Also, I had forgotten RFC7454 (until Nick mentioned it) and that
prescribes the stripping of communities, which intersects with this
issue.  RFC7454 addresses some of the security holes in BGP and expects
the high order bits of a community to be an ASN so that is another can
of worms that needs addresssing in this I-D.

Tom Petch

Thanks,
Jakob.


> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of t.petch
> Sent: Wednesday, October 19, 2016 3:47 AM
> To: Jeffrey Haas <jhaas@pfrc.org>;
> Cc: IETF IDR WG <idr@ietf.org>;; Sue Hares <shares@ndzh.com>;
> Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt
(10/17/2016 to 10/31/2016)
>
> I remain unhappy with this I-D.
>
> I find it ironic that the messages for this Last Call should be
> interspersed with those relating to what goes wrong when someone
> somewhere else in the world uses a field in an unexpected way.  This
> reinforces my belief that this I-D should be more forceful in calling
> out the dangers (eg MUST instead of SHOULD).
>
> I think that this I-D is factually incorrect, or at least open to
> misinterpretation,  when it says
> '[RFC1997] BGP Communities attributes are four-octet values split into
>    two two-octet words.  The most significant word is usually
>    interpreted as an Autonomous System Number (ASN) '
>
> RFC1997 says
> 'The community attribute values ranging from 0x0000000 through
>    0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved.
>
>    The rest of the community attribute values shall be encoded using
an
>    autonomous system number in the first two octets.  '
>
> Note the use of 'shall'.  Had that been written after RFC2119 then it
> would have been IMO 'MUST' or 'SHALL' not the weasily 'SHOULD' so this
> I-D is weakening the meaning compared to RFC1997.
>
> If this I-D were to say that RFC1997 specified a 'MUST' (in effect)
but
> that 20 years of experience showed that it need not be that strong,
that
> ambiguities of interpretation have never been a problem for routing,
> pehaps by adding a note in the Security Considerations, then I would
> accept that.  As it stands, I think that this I-D is risky (and would
be
> even if everyone who reads it knows what the IETF means by 'SHOULD' -
I
> think that this is not the case and that those outside the IETF will
> read 'SHOULD' as a stronger enforcement than it is).
>
> So, interspersed with those e-mails about other fields that have
> unexpected values, I oppose this going forward just yet.
>
> The question of reserved values is another can of worms.  If they are
> not reserved, then clearly they are an example of 'SHOULD' not meaning
> 'MUST' so they need reserving, but then, as Jeff is pointing out, you
> open up the question of translation (something I flagged earlier as an
> open issue).
>
> Tom Petch
>
> ----- Original Message -----
> From: "Jeffrey Haas" <jhaas@pfrc.org>;
> Sent: Tuesday, October 18, 2016 9:38 PM
>
> > On Oct 18, 2016, at 3:15 PM, Job Snijders <job@ntt.net>; wrote:
> >
> >> Part of the idea behind reserving 65535:*:* was to reserve a space
> that
> >> could later be used for well-knowns, if that was desired - but to
not
> >> spend time now arguing about details of what well-knowns are
> necessary.
> >>
> >> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs.
> >
> > Jeff argues that a justification should be added. Maybe someone can
> > pitch in one or two sentences that explain why these are reserved?
>
> That's certainly part of it.  While I think many people can see the
> reason why you might want to do such a reservation, to do so you
should
> have a practical reason in the document.
>
> For the 65535:*:* case, for symmetry with RFC 1997, you'd probably
want
> to note that if it's used for that symmetry that either the existing
> well known community registry is used at IANA or that a new one would
> need to be created.  Alternatively, you just say the work is expected
> and defer to a future document.
>
> Note by doing this, you're setting up some expectations about
> translation of communities from one space to another.  FWIW, I don't
> recommend this and simply suggest that you recommend *not* using these
> for common use in case someone decides that they want to do so.  I
know
> your organization and others such as Deutsche Telecom have some
thoughts
> about what translation infrastructure might look like, and such
> mechanisms would have impact.
>
> With regard to the 0: and max-uint32: cases, after dealing with the
> headaches associated with helping with documents such as the as0 and
RFC
> 7300 and putting in some restrictions in the configuration... followed
> by having to take them away, I'm very reluctant to put in anything
> beyond "we think it's a bad idea to use these, so pretty please don't"
>
> -- Jeff (ask me about my RFC 7300 hate mail over beer...)
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr