Re: [Cbor] changes in draft-ietf-cbor-network-addresses-05.txt

Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de> Mon, 02 August 2021 07:08 UTC

Return-Path: <J.Schoenwaelder@jacobs-university.de>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041483A0E3B; Mon, 2 Aug 2021 00:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.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 h-Q0wM_mDc8i; Mon, 2 Aug 2021 00:08:44 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40062.outbound.protection.outlook.com [40.107.4.62]) (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 6AD1C3A0E3A; Mon, 2 Aug 2021 00:08:44 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bijJh4QuL9d0x8684Bhc9LpZEBnvpMamSvlX5wE7PZp7/OXpQm2yptQMF7dJDeQeTNeD6+nMIfG1McTSmHJ1zFnLU5AewAuA6+vlcnUSbOVKktNirrCI82is+7Li9LfSfTuerQfA59lYg9Ia691NYpGrq7hPIejMDA7oiK7g/m7vTiM3paQuyZD43x+woUnHSQgKEe2ON0STu9wW/h5Op6YKRvV51zxmoJzz11TwMszzB2HCJkd+W9Dns2l4KXssmLPI4EC8enNXYVXa0nHIUdxK3+uELlzoCHC9nXQjXFPLqtFQlcSMJCk5xpV6VlSsgZYFEeIdq/f0EzstQjN+Bg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4DH66r4lv4n+NW9VKqIHI26DyyiEDwgYG/lVCWLy5xo=; b=d21uRCSaerldKliC/62YQSybfir+QePTc6a1w9Ttj6FMSx7wAqWiseL1j1hy2Naj3nypr9v451NL1wsg6D71FxFqhMi5lU+7PjmVvb/DeHZDEJUozyi40FZPd3IDzf1ztPH8WirPaGQbWahmqlyVijGsZtvANM4ZIXP+d29hfMknHinyEPHTW1Is14fvfc0LCJnKwVEoMVOfzh5pu9jjZW0VXHdZQO0NiyZoXQUBDgVredsZPtJelrTcE+51XRHgyRXWcWTqhAWa7DsEjT+2B9Z7FMuXq0CUjZvD6FTClD0C3sWwSG1154d/bFhA5I5Tzckrp+4YFvzcfnCj85BAfQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4DH66r4lv4n+NW9VKqIHI26DyyiEDwgYG/lVCWLy5xo=; b=MYMXhOIVqnePVXsVxpsBg+ZjzQ3u8cnStE/NqXAvWuPrcZQBmgxFeJARMGENl1K/umCii7/1pALQja71GrEYDJqcSkGiqhj2hNvBnyjRn3Lzr1z/6fOh9NWa0EJhlJ62VR/F03VwZfzBJ9bEuEDnikxxOsb7qRaSP5MS86vyvXo=
Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=jacobs-university.de;
Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM4P190MB0050.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:61::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.26; Mon, 2 Aug 2021 07:08:41 +0000
Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::58c1:599a:1d3d:cdeb]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::58c1:599a:1d3d:cdeb%9]) with mapi id 15.20.4373.026; Mon, 2 Aug 2021 07:08:41 +0000
Date: Mon, 2 Aug 2021 09:08:39 +0200
From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= <j.schoenwaelder@jacobs-university.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: tom petch <ietfc@btconnect.com>, Erik Kline <ek.ietf@gmail.com>, "cbor@ietf.org" <cbor@ietf.org>, 6MAN <6man@ietf.org>
Message-ID: <20210802070839.g2tjn3pqu5lpbd54@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Brian E Carpenter <brian.e.carpenter@gmail.com>, tom petch <ietfc@btconnect.com>, Erik Kline <ek.ietf@gmail.com>, "cbor@ietf.org" <cbor@ietf.org>, 6MAN <6man@ietf.org>
References: <162608928922.11086.12172415971165753394@ietfa.amsl.com> <29067.1626090045@localhost> <CAMGpriUnfMjhk7teAN-A0j5SCK=BpyJEDC+NOCJtHzmF1BFeow@mail.gmail.com> <aa9884b5-fd58-60cb-fa1d-b2d76f5a09a1@gmail.com> <VI1PR07MB6256E2C9CC9565FF2F080B5DA0E89@VI1PR07MB6256.eurprd07.prod.outlook.com> <c2c7a576-e138-1364-5ed0-a2987c1c1974@gmail.com> <20210727210706.buavt5nwairrjblf@anna.jacobs.jacobs-university.de> <e889a219-26b2-2a2e-6d05-bb6c7db1f89d@gmail.com> <20210801113001.yksklfouoz6v4hvz@anna.jacobs.jacobs-university.de> <b5f1c62e-4aa4-a397-8777-b3ec0eeafccc@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b5f1c62e-4aa4-a397-8777-b3ec0eeafccc@gmail.com>
X-ClientProxiedBy: AM0PR10CA0111.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:e6::28) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from localhost (212.201.44.244) by AM0PR10CA0111.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:e6::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.17 via Frontend Transport; Mon, 2 Aug 2021 07:08:40 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 2395be12-b225-4f4c-2bfd-08d955845b6b
X-MS-TrafficTypeDiagnostic: AM4P190MB0050:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <AM4P190MB0050E923FF62B406D58B9528DEEF9@AM4P190MB0050.EURP190.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: jgF/2BbFK6YnA8sf9yOcf44tN8UUrQlCSiqTcYpheEeg9cHlO+vniAm926NMAb9a26pZiaV7/b2hFE23Glr2q5s3THfc6ZJqCHue5FQn8IVAmYyl75VK0/jokRYyRcEKTj5xP8qD3nvBFNiOUWVJbJb7NEsf4+j1OGA/4zRZpQNDkCxrcrnzoO6WqGocfJXZa4n/8k+oqNZtuNSJtGG5hCFt00mua3G88dcGTtX54SuAR1uggHCwI2h2cEbsUjAtaraNk/n4LQq45EnLdo24DO/vUBjStt6jonQ3/6VjBFgnLpL/VyryHd4SpBxZ/EvpnZ10XGyZcwtEQHPLDWRobzG04Ili5VLMY/5dOzHE2zRljvZAO+wr36Nk9aSkLwwV6NAqEb8RZ2KwaEsUCVhvmBHPYLAZ2PpZoLMRPULkls8F13i7KyGKzipvzt9Qq2e1A+g6TvCjhbdBKdYq6f1AzaVykYTChYtBz/GTzSHbatfZoiRUzPUgGP16DvQ6EZ/sNPWGOLVLST224ccZcDMMEVpTCOCM7ZYY9js/sKeBF5oxesXaPlwk3PI70IVUmqynRGrKjDv2ua0qKlp0I7IsHORncnSOksKS2IBVW1p7sNqWkwcGDhXSdfm2SYuxzggVs8KmvoXyXF/WRhJUefrfWkMVL8zwZZw+tC1aicBcxlao5bipwyFqPaeDkIOAbdb5Fu6jWqz4AsaWCwhYM16U0VN0lsln5VU6yUu+YlrCaD0PslUIpcb0VokWKMm/3rkEAErpUcluBIgiOa/IuVMEWnTxGp/klFyzms9uqjnWRCaesHSj/R6LOHjfnPrxW+oA
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(136003)(376002)(346002)(396003)(39830400003)(5660300002)(66574015)(6496006)(3450700001)(4326008)(53546011)(52116002)(6486002)(83380400001)(966005)(26005)(86362001)(8676002)(8936002)(478600001)(85202003)(66946007)(66476007)(66556008)(186003)(38100700002)(38350700002)(786003)(956004)(1076003)(6916009)(54906003)(2906002)(85182001)(316002); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bWZoMnBhaUF6RE1JZG4yaWp5TWRWSm15Nm5EZS9JWE11eStBZGRhTUxSTlNu?= =?utf-8?B?WkdUKy94Mk5qQjFzMHlJVE9IbW90eGd5bWNRYWIvNGdjVCtuVjgzaGtkbk1W?= =?utf-8?B?V0doTG5jQmFuYVViUEdrd0VadDlsRlV0cmh5VkJLc1FFYjlKYmRhWVl1S3Ji?= =?utf-8?B?WFdzUDU1dWFOYUtJR2VVT3VyRGpCTXFPYWtYQWRZYmMxaDg0TCs3OG5FRHI5?= =?utf-8?B?ek9UUjEwVjdUWE9MbjhZLy9DaEVPSE5LemZpVS9nZnZTbWlxQkFuU3NUWmJ1?= =?utf-8?B?RjV2dEsvVzBmajV5SzdZNmsyRU1xUWNKcFAwWjlhQXR1bHorWHNRVTJHclBv?= =?utf-8?B?b2VvTEU0cVFvRXNxTzJLZzJTMFR6ZEs2MVpCWnBPV1V0U2NjNk9oWjJJVU5w?= =?utf-8?B?bXJZa2RNYWpPQ0VJRW90Mm51NW14eERaTE9lWEMveDZJai9tNlVhOXNTL2RI?= =?utf-8?B?cm9WR1RkVVAxNVpoNk1uWWFlYVM0K2o5cUZMVFdLenM5R084L0F1ZHdEcXhU?= =?utf-8?B?SXZrMS9VaFFaMndYK1NBU01pNXkyMzRHMXlQano0R3dwUHVCVktOU3M5c01L?= =?utf-8?B?TFJNUUNEbWpNYVNmYk42dkxzMlpVcjJ2TGNmZndTZDAzZVBjN3JyRVBSZlRF?= =?utf-8?B?V3hTMVlScFBoUldJMG1LU3RMcWlXaEFnaHkzWVhHMDdJMCt0eXgyRXZ6dnJ0?= =?utf-8?B?VmgyWVlaTVgrTjJQWjkvdDVHeVBFazZYblhzc0Vtby9kWkhvZjltVE1PMElx?= =?utf-8?B?UWhRVFRCV0RVVng1bUN6cjBLbXdmU296ZzM1dmh3emZoVW5yeHZBeGFmb1R1?= =?utf-8?B?bnFFVlNkZ2xqdW16SFlaNTVvd1hjc0kzZmFwZ1ZPTjFDbWh2T3QreFZkb08z?= =?utf-8?B?TEhzdXdOVkVtd1VGSjBpR3RjOURGYng0dGpadnlLRjREeFVuT3hrenRmK01N?= =?utf-8?B?SEluVzZXSVR0WU4rQVFzam5HQ2pDWlVKU2tKc2ZmM1Y2Njl0WU1qbU5NTGdI?= =?utf-8?B?dGRqVjRWNEZydXJTaWRFUTBFUGZVTy9PVGFjZ25JVi9EMm02a0dUTHpCamJB?= =?utf-8?B?dnZPYktwREVDNjV6YktqK0dON2xza2JVSE9QZ2trc1BSVFdBM3U3am1pN3FY?= =?utf-8?B?MmFqdFNKQ1EvRXlZYlppVzVqNzB3SnV4RmxsQzVoM3FwUndTT01xKzNnWEpJ?= =?utf-8?B?TEp4MHFBNHpJdU9IVjM3c1hrNmhScFNvK0R3RlVlWXBoSFpIL3VpZlV2UEN0?= =?utf-8?B?K0I3bHNuMVZjcXExc1NHY3RmVzlxMUpyN0xldXZPYW5OZ2w3bEtSbUJ6Ri9W?= =?utf-8?B?TGtaa1JLNWdGaHEzQ2FoLzErcEUxeDhiNzYvbjh5TUlUM3FBaXRzLzE2NS9v?= =?utf-8?B?aDFkQXZNK2lTUlRITkNscHBEVVc4VjNUSUV5MDU5bVhOdXZQZlhhSEhsdTlF?= =?utf-8?B?ZDZOb1lRTkdhWWdpbk9UNnE1amZIZGdiL0t0WndmVEptbnFnYllLak5pcGR0?= =?utf-8?B?aWhReUVkY0dvaTBrY0p3M3M0ckgyeElmaG9FWnpEUXgxZHdqRG93OVJja0dl?= =?utf-8?B?YkhWS0hoQmFRNGJsNmhXWk1jb2NKbFVqcExsWE05YUd4bEtrcGtELzJNNlQ1?= =?utf-8?B?amJyczQ5V3FOcVZSMGwxditzMzNNam45eDJEdWhXZ3Y0Y0w3UHoxSkJvejdL?= =?utf-8?B?MXA2d1A2OVk0U3pQY3F6SjQxTTg1WUw5QmNLMUpnaWVZMktxeFFkdGtyOUlv?= =?utf-8?Q?//6t1mmcCCvmBzrLa2ZGnXWAPRAwSHkzShu7qBZ?=
X-OriginatorOrg: jacobs-university.de
X-MS-Exchange-CrossTenant-Network-Message-Id: 2395be12-b225-4f4c-2bfd-08d955845b6b
X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2021 07:08:40.9650 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: //I3/V8g6dSYc0jIkZaSTe8dGSs3nitVTRG0ycvQuR294t6UUpuZTz72em4wj0AMMBcfUdy3W/ugmFVmzlKMtWJpZmitzeisWZUWuLco83c=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0050
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/2qeMbqsslLFO-zPvLJ9F06CetNs>
Subject: Re: [Cbor] changes in draft-ietf-cbor-network-addresses-05.txt
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Aug 2021 07:08:51 -0000

Brian,

let me see whether I understand your concern. You seem to be concerned
that assigning the name "5" to an interface with interface index 7
leads to an ambiguity. Well, thats likely true since we do not
syntactically distinguish between the number 5 and the name "5". I
would expect that implementations interpret fe80::1%5 as referring to
interface 5 and not 7 (but this perhaps deserves to be clarified, if
it is a number the number is interpreted as an interface index and not
as an interface name). I assume the same 'ambiguity' may exist on CLI
tools, I would have to go and try out what they actually do.

Regarding your statement "Remotely, there is no way to know that on my
Linux machine, %wlp2s0 and %3 are the same thing.", please note that
applications having access to the IF-MIB or the ietf-interfaces YANG
module or a proprietary API exposing interface information will
understand how interface names map to interface indexes.

/js

On Mon, Aug 02, 2021 at 09:15:43AM +1200, Brian E Carpenter wrote:
> On 01-Aug-21 23:30, Jürgen Schönwälder wrote:
> > The description statements in RFC 6991 talk about a zone index, i.e.,
> > they assume the zone index is numeric (which kind of follows from my
> > reading of RFC 4007).
> > 
> > The pattern is flexible enough to accept a string as well (e.g., an
> > interface name). In other words, a server may accept 'fe80::1%lo0' as
> > valid input on an edit-config put it will return 'fe80::1%0' on a
> > get-config since the numeric zone index is the canonical format
> > (assuming the lo0 interface has the interface index 0).
> 
> This still makes me uncomfortable. The zone identifier syntax definition.
> in RFC4007 is pretty vague. If an implementer chooses to ignore the
> SHOULD on page 16, it seems that a valid name for interface index 7
> could be "6". That's why "canonical" is a bit weak. (Neither Windows
> nor Linux allow anything that silly, of course.)
> 
> To be precise, consider these statements in RFC4007 page 16:
> 
>    An implementation SHOULD support at least numerical indices that are
>    non-negative decimal integers as <zone_id>.
>    ...
>    An implementation MAY support other kinds of non-null strings as
>    <zone_id>.
>    ... the format MUST be used only within a
>    node and MUST NOT be sent on the wire unless every node that
>    interprets the format agrees on the semantics.
> 
> Remotely, there is no way to know that on my Linux machine,
> %wlp2s0 and %3 are the same thing.
> 
>    Brian
>  
> > 
> > /js
> > 
> > On Wed, Jul 28, 2021 at 10:00:23AM +1200, Brian E Carpenter wrote:
> >> Jürgen,
> >>
> >> We are not disagreeing. These are exactly the sort of use cases that also
> >> motivate RFC6874 and RFC6874bis. 
> >>
> >> But I have a question. In the management plane, do you think that the
> >> zone index (an integer) is the item of interest, or a zone identifier
> >> (a string)? The description at
> >> https://datatracker.ietf.org/doc/html/rfc6991#page-20
> >> only says that the numerical format is "canonical".
> >>
> >> Regards
> >>    Brian
> >>
> >> On 28-Jul-21 09:07, Jürgen Schönwälder wrote:
> >>> On Wed, Jul 28, 2021 at 08:04:16AM +1200, Brian E Carpenter wrote:
> >>>> On 26-Jul-21 23:49, tom petch wrote:
> >>>>> From: ipv6 <ipv6-bounces@ietf.org> on behalf of Brian E Carpenter <brian.e.carpenter@gmail.com>
> >>>>> Sent: 25 July 2021 00:44
> >>>>>
> >>>>> There's an "interesting" issue there, especially for IPv6, which is 
> that the interface ID (or "zone index", per RFC4007) has no meaning outside the host. So it really shouldn't need to be sent on the wire in normal 
> circumstances.
> >>>>>
> >>>>> (The conversation around RFC6874bis is slightly relevant.)
> >>>>>
> >>>>> <tp>
> >>>>> Brian
> >>>>>
> >>>>> As I may have said before, the YANG Types RFC6991 provides types for IPv4 and IPv6 addresses both with a zone index.  It also provides no-zone 
> >> types with a suffix 'no-zone' on the type name.  I see evidence that most 
> >> authors of YANG modules do not realise that a reference to 'ip-address' per se is a reference to the format that includes the zone and so have specified that format in many if not most cases.  Thus it seems likely that many of the addresses on the wire are in the zone format, even if the zone is rarely present.  With hindsight, it might have been better to have specified 'ip-address' and 'ip-address-zone' rather than ip-address' and io-address-no-zone'.
> >>>>
> >>>> Makes sense. The reply I just sent to Christian Amsüss probably 
> applies to YANG too. Sending a zone index to another host is rarely meaningful or useful.
> >>>>
> >>>
> >>> YANG was designed for network management purposes and there are quite
> >>> some use cases where communicating the zone index is somewhat essential:
> >>>
> >>> - If you want to debug a problem, you likely need to know to which
> >>>   link a link-local address belongs.
> >>> - If you want to generate statistics for protocols using link-local
> >>>   addresses, you likely need to know to which links the link-local
> >>>   addresses belongs.
> >>> - If you want to configure a service to use a certain link-local
> >>>   address on a certain link, you may have to include the proper zone
> >>>   index.
> >>> - If an IP address is used to index lists, things can fall apart if
> >>>   you end up with duplicate link-local addresses on different links.
> >>>
> >>> Whether we should have picked different names for the types may be
> >>> debatable but at the end it is the YANG module author's responsibility
> >>> to pick the appropriate types.
> >>>
> >>> In other words, network management applications often need to be aware
> >>> of zone indexes in order to do the right thing. This is different from
> >>> end user applications (that usually have no topological awareness).
> >>>
> >>> /js
> >>>
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> > 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>