Re: [I2nsf] [yang-doctors] Need YANG Doctor reviewing the YANG module of draft-ietf-i2nsf-sdn-ipsec-flow-protection which I2NSF is about to call WGLC

"Acee Lindem (acee)" <acee@cisco.com> Mon, 08 April 2019 15:18 UTC

Return-Path: <acee@cisco.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BEF12009A; Mon, 8 Apr 2019 08:18:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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, 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 header.b=Mmeo10dT; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WbY77UOO
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 uVSsSBINcNOP; Mon, 8 Apr 2019 08:18:40 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACFE12008C; Mon, 8 Apr 2019 08:18:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8556; q=dns/txt; s=iport; t=1554736720; x=1555946320; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=crXwsL0ngH9QWovwxKwwQYA4k/oUKcfaGWXS7zz1nlc=; b=Mmeo10dTpjOpDAkVvmEWxOga9LxqtjoIEkaeHSxZJVCNN9ZfISBs57LQ G4yj+trmx+o9H/UWbtMfQJIdwmd+R5oH1KWKTbhSNaeopxwjGuGvNclUj UdswwsZckTQ26hED5oaQO751pfWMzf5dD/89clwUp3L51WlxCGp++n2Xo I=;
IronPort-PHdr: =?us-ascii?q?9a23=3AocR+mRbncDa5zO87kSedvwD/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20QKbRp3VvvRDjeee87vtX2AN+96giDgDa9QNHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuJfXnYgQxHd9JUxlu+HToeUU=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfAAC+Zatc/4gNJK1cCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVQBAQEBAQELAYE9UANoVCAECycKhASDRwOPJ4IyJYk?= =?us-ascii?q?4jWCBQoEQA1QOAQEYCwmEQAIXhU4iNwYNAQEDAQEJAQIBAm0cDIVKAQEBAwE?= =?us-ascii?q?BASERDAEBLAsBDwIBCBgCAh8EAwICAh8GCxQBEAIEAQ0FgyIBgV0DDQgBDqM?= =?us-ascii?q?gAooUcYEvgnkBAQWBMQEDAoNBDQuCDAMFgQslAYoCgUQXgX+BEScME4FOUC4?= =?us-ascii?q?+ghpHAQEDgSYOFIMgMYIEIoo8IYI5mD02CQKIAYEnhxWDRBMHggWSV4tThiK?= =?us-ascii?q?BRIlbgj0CBAIEBQIOAQEFgWUigVZwFTsqAYJBggoMFxSDOIUUhT9yAYEnjiU?= =?us-ascii?q?BgR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.60,325,1549929600"; d="scan'208";a="256013882"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2019 15:18:38 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x38FIYL7007694 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Apr 2019 15:18:37 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Apr 2019 10:18:34 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Apr 2019 10:18:33 -0500
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 8 Apr 2019 10:18:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=crXwsL0ngH9QWovwxKwwQYA4k/oUKcfaGWXS7zz1nlc=; b=WbY77UOOYF7LHyYJdPC+STxq/jUyBsKO+lkTmymx4mYezhgIRLctf40b9eYH+Tn3teHfGjoyxQC2/MQKLYa3YpegtIFMn0fHsl7nyqExtK8O0maozouQHs0rD+GKVCeRVmqNkQw1F+8/f1if89urdD8mXrY6HaSTgQrag8M007k=
Received: from BN6PR1101MB2226.namprd11.prod.outlook.com (10.174.112.11) by BN6PR1101MB2228.namprd11.prod.outlook.com (10.174.113.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.16; Mon, 8 Apr 2019 15:18:32 +0000
Received: from BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::9105:38a0:c6b:f455]) by BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::9105:38a0:c6b:f455%7]) with mapi id 15.20.1771.016; Mon, 8 Apr 2019 15:18:32 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Ladislav Lhotka <lhotka@nic.cz>, Yoav Nir <ynir.ietf@gmail.com>, "Andy Bierman" <andy@yumaworks.com>
CC: "i2nsf@ietf.org" <i2nsf@ietf.org>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, Linda Dunbar <linda.dunbar@huawei.com>
Thread-Topic: [yang-doctors] [I2nsf] Need YANG Doctor reviewing the YANG module of draft-ietf-i2nsf-sdn-ipsec-flow-protection which I2NSF is about to call WGLC
Thread-Index: AQHU69tX1AVOQiz/7EutscpLYLzlNqYyXnwA///DZYA=
Date: Mon, 8 Apr 2019 15:18:32 +0000
Message-ID: <E08B6E5E-4C9C-4773-BD19-D9CA4EC75FF4@cisco.com>
References: <4A95BA014132FF49AE685FAB4B9F17F66B363EB2@sjceml521-mbs.china.huawei.com> <420D3E9A-9E3C-4575-9C92-200CAA0B868C@gmail.com> <CABCOCHRf3iGUt9wb3htpDYGJ+pAKErvq8OrozndgELUVKYT4Kg@mail.gmail.com> <80347D5B-C4DB-4F0C-BD73-A927585442BF@gmail.com> <87mul04kdd.fsf@nic.cz>
In-Reply-To: <87mul04kdd.fsf@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com;
x-originating-ip: [173.38.117.89]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fff5b81e-7a8b-454d-bd0d-08d6bc35762f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:BN6PR1101MB2228;
x-ms-traffictypediagnostic: BN6PR1101MB2228:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <BN6PR1101MB222819B5220FFFAF2DD3C4A6C22C0@BN6PR1101MB2228.namprd11.prod.outlook.com>
x-forefront-prvs: 0001227049
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(39860400002)(136003)(366004)(189003)(199004)(83716004)(53936002)(478600001)(305945005)(11346002)(93886005)(71200400001)(66066001)(186003)(6486002)(26005)(2616005)(86362001)(106356001)(5660300002)(6306002)(476003)(6246003)(105586002)(71190400001)(7736002)(68736007)(6512007)(2906002)(966005)(446003)(6436002)(229853002)(114624004)(97736004)(81156014)(3846002)(486006)(256004)(316002)(99286004)(110136005)(102836004)(8936002)(6116002)(53546011)(82746002)(54906003)(36756003)(6506007)(25786009)(14454004)(81166006)(8676002)(76176011)(4326008)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1101MB2228; H:BN6PR1101MB2226.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: aHlXxPLwCBGVki3iZXeI7qACmNcrKT5ZavhxWU/lw2K3AgynqUePcoUL7rB0g4oyqCb9vcSLoYO2pMLSRvYXzXdwDf3l0M9gtKdqizUsvRvuca6p511/LPbVdsTE4nIXVtkedhNmJhxVjw9pmTPcX+Pn+YCjYMLho8g0pXedRmTBHLNL47Etr9pl/9U2M6Gb/V4C1b9805k5a+zo2WqnI72/LZHOTKdc78G2JB5qZAiSCARKj3BkiLWV41kM9pRJrN2TH8OwmHJGzFRdLwgDbFM2xLTc83XzF16XR5hfIxak/th4Aq68PJHB02yGSyuNVHPVkbCQNYxxlJ9Dzq6mcbU4ZWK+lnsLLQLDhWl/Teir4+h537hXwtgeRZSTqafQERsgzBNgk5o/ot1TV+OdV20eFEUyMeP49l7Vpz1f6oQ=
Content-Type: text/plain; charset="utf-8"
Content-ID: <BBE1214633D86F42A86F4C1B27B543A0@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fff5b81e-7a8b-454d-bd0d-08d6bc35762f
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2019 15:18:32.1112 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2228
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/JNJJXbKGqLdXKR7wsTdB4_7iILs>
Subject: Re: [I2nsf] [yang-doctors] Need YANG Doctor reviewing the YANG module of draft-ietf-i2nsf-sdn-ipsec-flow-protection which I2NSF is about to call WGLC
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2019 15:18:43 -0000


On 4/8/19, 10:55 AM, "yang-doctors on behalf of Ladislav Lhotka" <yang-doctors-bounces@ietf.org on behalf of lhotka@nic.cz>; wrote:

    Yoav Nir <ynir.ietf@gmail.com>; writes:
    
    > At this point I’m wondering if it would not be a better strategy to
    > avoid all enumerations of algorithms, whether they are spelled out or
    > imported from draft-ietf-netconf-crypto-types, and instead use the
    > numbers from the IANA registry for IPsec.
    >
    > That does not help us deprecate old algorithms, but it solves the
    > other issue, which is what to do when a new algorithm is added to
    > IPsec. We don’t want to have to publish a new i2nsf document whenever
    > that happens, and if the algorithm identifier is just a number, new
    > values can be added by IANA.
    
    IMO the best option is to combine an enumeration and numbers in a union
    type. We used this approach in this draft:
    
    https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-01

For iana-routing-types (RFC 8294), we just used enums with the IANA assigned values. We went back and forth with identities but settled on this when another SDO said they'd only use our model if we have the actual values in an enum. For these types, nobody has complained. 

https://www.rfc-editor.org/rfc/rfc8294.txt

Thanks,
Acee


    
    Lada
    
    >
    > Yoav
    >
    >> On 5 Apr 2019, at 20:42, Andy Bierman <andy@yumaworks.com>; wrote:
    >> 
    >> Hi,
    >> 
    >> I think conformance for identities is handled very poorly in YANG.
    >> There is an if-feature-stmt allowed inside an identity in YANG 1.1.
    >> This implies that any identity without if-feature is mandatory-to-implement.
    >> 
    >> If the identities are in a separate module, the server can list it as an imported module,
    >> which tells the client the server does not implement any of the identities.
    >> 
    >> There is no standard way for the server to inform the client which identities it supports
    >> for a given identityref data node.
    >> 
    >> The common implementation strategy is to completely ignore YANG conformance for identities
    >> (as Mahesh explained). You just try setting the leaf and see if the server accepts it.
    >> 
    >> Andy
    >> 
    >> 
    >> On Fri, Apr 5, 2019 at 10:33 AM Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>> wrote:
    >> Hi Linda,
    >> 
    >> 
    >>> On Apr 5, 2019, at 9:51 AM, Linda Dunbar <linda.dunbar@huawei.com <mailto:linda.dunbar@huawei..com>> wrote:
    >>> 
    >>> Dear YANG Doctor:
    >>>  
    >>> We need your help in reviewing the YANG model in draft-ietf-i2nsf-sdn-ipsec-flow-protection which I2NSF WG is about to call WGLC.
    >>>  
    >>> In particular, we need your advice on the following issue:
    >>>  
    >>> draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 imports from draft-ietf-netconf-crypto-types, which appears to be a generic list of algorithms.
    >>> The problem is that the list in draft-ietf-netconf-crypto-types could contain algorithms that are not suitable for IPsec (such as secp192r1 for key agreement), and right now it seems to lack some older algorithms that have fallen out of fashion (3DES) but is still needed in IPsec.  
    >> 
    >> All the algorithms in draft-ietf-netconf-crypto-types are defined as identities. If you do not find the algorithm you are looking for in the list of defined algorithms, you can go ahead and define your own in your own draft, using the same base identity from the ietf-crypto-types module.
    >> 
    >>>  
    >>>  
    >>> Questions to the YANG Doctor:
    >>> 1.       Is it better to list the IPsec specific algorithms in draft-ietf-i2nsf-sdn-ipsec-flow-protection (which is a subset of draft-ietf-netconf-crypto-types? Or to import all crypto algorithms many of which are not relevant to IPsec? What is the common practice? 
    >> 
    >> Importing ietf-crypto-types does not mean you have to implement every algorithm listed in the module. You can import the module and chose to implement the algorithms you want to implement, including defining any new ones.
    >> 
    >>> 2.      If we do import from draft-ietf-netconf-crypto-types, does it mean draft-ietf-i2nsf-sdn-ipsec-flow-protection cannot be published until draft-ietf-netconf-crypto-types is published?
    >> 
    >> Yes. The i2nsf draft will hit the state of MISSREF in the RFC Editor queue. But that should not prevent anyone from starting implementation of the module. As a side note, the NETCONF WG is planning on sending the crypto-types draft to IESG shortly. What you do not want is to duplicate the definition of the algorithms in your own draft.
    >> 
    >> HTH.
    >> 
    >>>  
    >>>  
    >>> Thank you very much, 
    >>>  
    >>> Linda & Yoav
    >>>  
    >>> _______________________________________________
    >>> yang-doctors mailing list
    >>> yang-doctors@ietf.org <mailto:yang-doctors@ietf..org>
    >>> https://www.ietf.org/mailman/listinfo/yang-doctors <https://www.ietf.org/mailman/listinfo/yang-doctors>
    >> Mahesh Jethanandani
    >> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
    >> 
    >> 
    >> 
    >> _______________________________________________
    >> yang-doctors mailing list
    >> yang-doctors@ietf.org <mailto:yang-doctors@ietf.org>
    >> https://www.ietf.org/mailman/listinfo/yang-doctors <https://www.ietf.org/mailman/listinfo/yang-doctors>
    >> _______________________________________________
    >> I2nsf mailing list
    >> I2nsf@ietf.org <mailto:I2nsf@ietf.org>
    >> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>
    > _______________________________________________
    > yang-doctors mailing list
    > yang-doctors@ietf.org
    > https://www.ietf.org/mailman/listinfo/yang-doctors
    
    -- 
    Ladislav Lhotka
    Head, CZ.NIC Labs
    PGP Key ID: 0xB8F92B08A9F76C67
    
    _______________________________________________
    yang-doctors mailing list
    yang-doctors@ietf.org
    https://www.ietf.org/mailman/listinfo/yang-doctors