Re: [netmod] for a future rfc6991bis

"Acee Lindem (acee)" <acee@cisco.com> Mon, 31 December 2018 13:21 UTC

Return-Path: <acee@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496DE127B4C for <netmod@ietfa.amsl.com>; Mon, 31 Dec 2018 05:21:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC9L61f0UuD4 for <netmod@ietfa.amsl.com>; Mon, 31 Dec 2018 05:21:48 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B831E126CC7 for <netmod@ietf.org>; Mon, 31 Dec 2018 05:21:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10100; q=dns/txt; s=iport; t=1546262508; x=1547472108; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=adieB+U0Svg+HUM9jtazf/WPa36w0yOnL/QC/UhOh7k=; b=JhAcVlD0D1p3HKHN45GC3yFaL8c1zmsnoMDGgJ5SFn1oPog1NjHfwWj9 x1kdFWsegGTTukND6SrnV28b0tMSupEb0ZNnU7gJMa7Nps+g+p+iO9FLd lM5lqgVK/yvDJW/aBcFMpUI0HJmy29y/XIbpWf1GXkClKWpKIuWIpg8GH 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAC4Fipc/4UNJK1aBgMZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBAYFRBAEBAQEBCwGCA2aBAicKg3SIGotwgg2XYxSBZws?= =?us-ascii?q?BARgLhANGAheCLCI0CQ0BAwEBAgEBAm0cDIVKAQEBAQMBASEROgsMAgICAQg?= =?us-ascii?q?OAgEEAQEBAgImAgICGQwLFQgIAQEEAQ0FgyIBggEPpQeBL4VBhFcFBYEGizQ?= =?us-ascii?q?XgX+BEScfgkyDHgEBgS4BCAoBHwcQChkNgkExgiYCoUsJApFnGJFmiVmQKQI?= =?us-ascii?q?RFIEnHzhlcXAVOyoBgkGGO4RhhT9BMYlggR+BHwEB?=
X-IronPort-AV: E=Sophos;i="5.56,422,1539648000"; d="scan'208";a="500475382"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Dec 2018 13:21:47 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id wBVDLkKo021849 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Dec 2018 13:21:47 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 31 Dec 2018 08:21:46 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Mon, 31 Dec 2018 08:21:46 -0500
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, tom petch <ietfc@btconnect.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AdR1b1B75pZToCjlLEK5aT+9YAPiFwrwaWcA//+1oYA=
Date: Mon, 31 Dec 2018 13:21:45 +0000
Message-ID: <6400EF80-F822-4BFE-9A47-FF8D73EE62CB@cisco.com>
References: <dae0f227c663bdfa105e992c1ae088c22fa545bb.camel@nic.cz> <b45e6850-6943-073b-98a9-8aeab20b3d76@cisco.com> <8aa6b9c7-7d08-9ceb-36be-a54234561667@ericsson.com> <20181130.112544.1021452038429209831.mbj@tail-f.com> <20181130115648.bho3ofouglhibgct@anna.jacobs.jacobs-university.de> <02d201d4a104$72b82980$4001a8c0@gateway.2wire.net> <20181231124756.4ira47yirxjkbpon@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181231124756.4ira47yirxjkbpon@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <E6D13C5DEEE2AF45BC9BC6442A56CB86@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/xLBcMu7745U5JixLGcYyoM9eaoY>
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Dec 2018 13:21:51 -0000

Hi Tom, Juergen, 
I agree with Juergen - we went through this discussion with ietf-routing-types (RFC 8294) and came to the same conclusion. We kept, the generic link-access-type enum but I believe it is, heretofore, unused. 
Thanks,
Acee

On 12/31/18, 7:48 AM, "netmod on behalf of Juergen Schoenwaelder" <netmod-bounces@ietf.org on behalf of j.schoenwaelder@jacobs-university.de> wrote:

    Tom,
    
    since states are often protocol specific, I believe we are better off
    with having states defined with protocol specific semantics. If you go
    for generic states, then you end up with mappings of generic states to
    protocol specific states, which are often non-trivial to get right and
    meaningful.
    
    /js
    
    On Mon, Dec 31, 2018 at 12:29:34PM +0000, tom petch wrote:
    > Many (most?) routing protocols introduce a state - up, down +- coming
    > up, going down, maintenance and such like, used for interfaces, tunnels,
    > adjacencies and the like.  It is a shame that there are so many
    > variations on this although to some extent this reflects the differences
    > in the protocols.  And some use types, others identity.
    > 
    > Tom Petch
    > 
    > 
    > ----- Original Message -----
    > From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de>
    > Sent: Friday, November 30, 2018 11:56 AM
    > 
    > > This is already on my list (was already proposed by Balázs).
    > >
    > > /js
    > >
    > > On Fri, Nov 30, 2018 at 11:25:44AM +0100, Martin Bjorklund wrote:
    > > > Balázs Lengyel <balazs.lengyel@ericsson.com> wrote:
    > > > > Hello,
    > > > >
    > > > > In a similar manner we found multiple uses for the
    > > > > ietf-netconf-acm:node-instance-identifier. We
    > > > > imported nacm just to reuse this type.
    > > > > Anyone else interested?
    > > >
    > > > Yes, this is a useful type that is not just NACM-specific.  We also
    > > > use in various places.
    > > >
    > > >
    > > > /martin
    > > >
    > > >
    > > > >
    > > > > regards Balazs
    > > > >
    > > > > On 2018. 11. 29. 12:03, Robert Wilton wrote:
    > > > >
    > > > >  Hi Juergen,
    > > > >
    > > > >  YANG library currently defines the type "revision-identifer". Is
    > this a typedef that should
    > > > >  logically migrate to rfc6991bis?
    > > > >
    > > > >  Thanks,
    > > > >  Rob
    > > > >
    > > > >  On 14/11/2018 08:16, Ladislav Lhotka wrote:
    > > > >
    > > > >  On Wed, 2018-11-14 at 09:10 +0100, Martin Bjorklund wrote:
    > > > >
    > > > >  Hi,
    > > > >
    > > > >  Alex Campbell <Alex.Campbell@Aviatnet.com> wrote:
    > > > >
    > > > >  Does a percentage really need a single standard type in the first
    > > > >  place? How about "units percent;"?
    > > > >
    > > > >  At this point, after hearing about how different modules have
    > > > >  differing requirement on this type, I tend to agree.
    > > > >
    > > > >  +1
    > > > >
    > > > >  Or even "units %;"
    > > > >
    > > > >  Lada
    > > > >
    > > > >  /martin
    > > > >
    > > > >  ________________________________________
    > > > >  From: netmod <netmod-bounces@ietf.org> on behalf of Acee Lindem
    > (acee)
    > > > >  <acee@cisco.com>
    > > > >  Sent: Wednesday, 14 November 2018 5:03 a.m.
    > > > >  To: Juergen Schoenwaelder; Balázs Lengyel
    > > > >  Cc: NETMOD WG
    > > > >  Subject: Re: [netmod] for a future rfc6991bis
    > > > >
    > > > >  On 11/13/18, 9:07 AM, "netmod on behalf of Juergen
    > Schoenwaelder"
    > > > >  <netmod-bounces@ietf.org on behalf of
    > > > >  j.schoenwaelder@jacobs-university.de> wrote:
    > > > >
    > > > >  On Tue, Nov 13, 2018 at 01:33:01PM +0000, Balázs Lengyel wrote:
    > > > >  > Hello,
    > > > >  >
    > > > >  > In some cases I want a percentage without fractions. This could
    > be
    > > > >  > defined
    > > > >  > using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100
    > in the
    > > > >  > range's
    > > > >  > argument.
    > > > >  >
    > > > >  > typedef percent-short {
    > > > >  > type percent { range 0 | 1 | 2 ... 99 | 100; } // didn't type
    > > > >  out
    > > > >  > all the 101 integer values :-)
    > > > >  > }
    > > > >  >
    > > > >
    > > > >  I guess we need to settle on a small number of percentage types
    > that
    > > > >  people find useful and then module authors hopefully find what
    > they
    > > > >  need. I am not sure that listing 101 numbers is a good pattern to
    > use
    > > > >  (although it does achieve what you want). For percentages that
    > have no
    > > > >  fraction, you likely want to derive from a base type that is
    > efficient
    > > > >  to encode for binary encodings such as CBOR.
    > > > >
    > > > >  Or simply define a type with a base type of unit8 type and a
    > range of
    > > > >  0-100.
    > > > >
    > > > >  Acee
    > > > >
    > > > >  /js
    > > > >
    > > > >  --
    > > > >  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/>
    > > > >
    > > > >  _______________________________________________
    > > > >  netmod mailing list
    > > > >  netmod@ietf.org
    > > > >  https://www.ietf.org/mailman/listinfo/netmod
    > > > >
    > > > >  _______________________________________________
    > > > >  netmod mailing list
    > > > >  netmod@ietf.org
    > > > >  https://www.ietf.org/mailman/listinfo/netmod
    > > > >  _______________________________________________
    > > > >  netmod mailing list
    > > > >  netmod@ietf.org
    > > > >  https://www.ietf.org/mailman/listinfo/netmod
    > > > >
    > > > >  _______________________________________________
    > > > >  netmod mailing list
    > > > >  netmod@ietf.org
    > > > >  https://www.ietf.org/mailman/listinfo/netmod
    > > > >
    > > > >  _______________________________________________
    > > > >  netmod mailing list
    > > > >  netmod@ietf.org
    > > > >  https://www.ietf.org/mailman/listinfo/netmod
    > > > >
    > > > > --
    > > > > Balazs Lengyel                       Ericsson Hungary Ltd.
    > > > > Senior Specialist
    > > > > Mobile: +36-70-330-7909              email:
    > Balazs.Lengyel@ericsson.com
    > >
    > > --
    > > 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/>
    > >
    > > _______________________________________________
    > > netmod mailing list
    > > netmod@ietf.org
    > > https://www.ietf.org/mailman/listinfo/netmod
    > >
    > 
    
    -- 
    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/>
    
    _______________________________________________
    netmod mailing list
    netmod@ietf.org
    https://www.ietf.org/mailman/listinfo/netmod