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

From: Linda Dunbar <[email-masked]>
Date: Fri, 5 Apr 2019 16:51:04 +0000

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.

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?

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?

Thank you very much,

Linda & Yoav

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 5 Apr 2019 10:32:40 -0700

Hi Linda,

> On Apr 5, 2019, at 9:51 AM, Linda Dunbar <[email-masked]> wrote:
> 
> Dear YANG Doctor:
>  

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.

> 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 m…

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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/yang-doctors <https://www.ietf.org/mailman/listinfo/yang-doctors>
Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Fri, 5 Apr 2019 10:42:54 -0700

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 <[email-masked]>
wrote:

> 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.
>
> 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.
>
>
>
> 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
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors
>
>
> Mahesh Jethanandani
> [email-masked]
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors
>

---

From: Yoav Nir <[email-masked]>
Date: Fri, 5 Apr 2019 21:13:29 +0300

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.

Yoav

> On 5 Apr 2019, at 20:42, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> If the identities are in a separate module, the server can list it as an imported module,
> There is no standard way for the server to inform the client which identities it supports
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Linda,
> 
> 
>> On Apr 5, 2019, at 9:51 AM, Linda Dunbar <[email-masked] <mailto:linda.dunbar@huawei..com>> wrote:
>> 
>> Dear YANG Doctor:
>>  
>> [email-masked] <mailto:yang-doctors@ietf..org>
> [email-masked] <mailto:[email-masked]>
> 
> 
> 
> I2nsf mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i2nsf <https://www.ietf.org/mailman/listinfo/i2nsf>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 08 Apr 2019 16:55:26 +0200

Yoav Nir <[email-masked]> 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

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 8 Apr 2019 15:18:32 +0000

On 4/8/19, 10:55 AM, "yang-doctors on behalf of Ladislav Lhotka" <[email-masked] on behalf of [email-masked]> wrote:

    

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 08 Apr 2019 19:22:35 +0200

On Mon, 2019-04-08 at 15:18 +0000, Acee Lindem (acee) wrote:
> 
> On 4/8/19, 10:55 AM, "yang-doctors on behalf of Ladislav Lhotka" <
> [email-masked] on behalf of [email-masked]> wrote:
> 
> 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 

If the number is only the "value" parameter of each enum, then one is still
restricted to the assigned values (and mnemonic enum names in JSON and XML
representations). The trick with uint8/16 as the other union member allows for
using the numeric value in the protocol, and for both assigned and unassigned
values.

Lada

> another SDO said they'd only use our model if we have the actual values in an
> enum. For these types, nobody has complained. 
> 
>     >> On Fri, Apr 5, 2019 at 10:33 AM Mahesh Jethanandani <
> [email-masked] <mailto:[email-masked]>> wrote:
>     >> Hi Linda,
>     >> 
>     >> 
>     >>> On Apr 5, 2019, at 9:51 AM, Linda Dunbar <[email-masked]
> <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.
>     >>>  
>     >>> draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 imports from draft-ietf-
> netconf-crypto-types, which appears to be a generic list of algorithms.
> 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.  
>     >> 
> 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.
>     >> 
>     >>>  
>     >>>  
>     >>> 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? 
>     >> 
> 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
>     >>>  
>     >>> https://www.ietf.org/mailman/listinfo/yang-doctors <
> https://www.ietf.org/mailman/listinfo/yang-doctors>
>     >> Mahesh Jethanandani
>     >> https://www.ietf.org/mailman/listinfo/yang-doctors <
> https://www.ietf.org/mailman/listinfo/yang-doctors>
>     >> https://www.ietf.org/mailman/listinfo/i2nsf <
> https://www.ietf.org/mailman/listinfo/i2nsf>

---

From: Rafa Marin-Lopez <[email-masked]>
Date: Tue, 9 Apr 2019 09:49:48 +0200

Hi Yoav:

After thinking about these past days, I personally think the same. 

I would add a uint16 and a comment in the description. As we agreed in the last IETF meeting, I do not think our I-D should solve this problem, since this problem happens in general.

As an example:

typedef ike-integrity-algorithm-t {
			type uint32; 
			description “The acceptable numbers are defined in IANA Registry - Internet Key Exchange Version 2 (IKEv2) Parameters - IKEv2  Transform Type 1 - Encryption Algorithm Transform IDs";
}

Is this reasonable?

> El 5 abr 2019, a las 20:13, Yoav Nir <[email-masked]> escribió:
> 
>> On 5 Apr 2019, at 20:42, Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2nsf

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Apr 2019 09:53:34 +0200

> On Apr 9, 2019, at 09:49, Rafa Marin-Lopez <[email-masked]> wrote:
> 
> Hi Yoav:
> 

This would be much better, yes.

Paul

>>>> On Fri, Apr 5, 2019 at 10:33 AM Mahesh Jethanandani <[email-masked]> wrote:
>>>> Hi Linda,
>>>> 
>>>>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 9 Apr 2019 14:25:08 +0300

Good.  But since we are getting a YANG doctor review, let’s wait for that before revving the draft.

Yoav

> On 9 Apr 2019, at 10:49, Rafa Marin-Lopez <[email-masked]> wrote:
> 
> Hi Yoav:
> 
>> El 5 abr 2019, a las 20:13, Yoav Nir <[email-masked] <mailto:[email-masked]>> escribió:
>> 
> Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked] <mailto:[email-masked]>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 9 Apr 2019 06:26:55 -0700

For the record, I prefer Lada’s solution of having a union that takes both a number and an identity/enum. 

> On Apr 9, 2019, at 4:25 AM, Yoav Nir <[email-masked]> wrote:
> 
Mahesh Jethanandani 
[email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Apr 2019 11:10:08 +0200

> both a number and an identity/enum.

To be concrete, it means, for example (without descriptions and references)

        type union {
            type uint16; 
            type enumeration {
                enum NONE {
                    value 0;
                }
                enum AUTH_HMAC_MD5_96 {
                    value 1;
                }
                ...
            }
        }
    }

The unassigned and private use values won't be present as enums but can
be used via the numeric value. 

This IMO provides the benefits of both approaches and, moreover, the
enum values are documented in place.

Lada

---

From: Paul Wouters <[email-masked]>
Date: Wed, 10 Apr 2019 05:13:43 -0400 (EDT)

> enum values are documented in place.

But that is a bug, not a feature. The location of the enum values are in
the IANA registries which continiously are updated. Putting snapshots of
those in RFCs is a bad idea.

Paul

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Apr 2019 11:33:56 +0200

> those in RFCs is a bad idea.

Not necessarily. If you look, for example, at RFC 7224, it is IANA's
responsibility to keep the registry in sync with the YANG module. No further
effort is required from the WG that prepared the initial revision of the module.

Lada

---

From: Paul Wouters <[email-masked]>
Date: Wed, 10 Apr 2019 07:04:30 -0400 (EDT)

> effort is required from the WG that prepared the initial revision of the module.

What is "the YANG module" ?

I don't think IANA has any responsibility other than RFCs directing them
to update IANA registries. How do you imagine any updates to happen, and
how would IANA "sync" this automatically?

Paul

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Apr 2019 13:10:47 +0200

> how would IANA "sync" this automatically?

There are IANA maintained YANG modules (and before we had YANG there
were IANA maintained MIB modules). Numbers maintained in registries
sometimes need to be in machine readable formats and then IANA
documents procedures to make updates both in their internal registry
and in an IANA maintained YANG module.

/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/>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 10 Apr 2019 11:36:16 +0000

On 4/10/19, 7:11 AM, "yang-doctors on behalf of Juergen Schoenwaelder" <[email-masked] on behalf of [email-masked]> wrote:

It seems this could all be done with tooling. However, AFAIK, generation of new versions of IANA YANG models had not be implemented yet. 

Thanks,
Acee

    /js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Apr 2019 13:58:30 +0200

Acee Lindem (acee) píše v St 10. 04. 2019 v 11:36 +0000:
> 
> On 4/10/19, 7:11 AM, "yang-doctors on behalf of Juergen Schoenwaelder" <
> [email-masked] on behalf of 
> [email-masked]> wrote:
> 
> It seems this could all be done with tooling. However, AFAIK, generation of
> new versions of IANA YANG models had not be implemented yet.

If it is so, then we have work to do. I am going to open this issue in the
NETMOD mailing list.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Apr 2019 14:04:14 +0200 (CEST)

> If it is so, then we have work to do. I am going to open this issue in the

Hold on.  IANA do publish new revisions of the YANG modules when the
registries are updated.  (perhaps they have a manual process, but
that's not really the point of this thread).

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Apr 2019 14:20:26 +0200

Martin Bjorklund píše v St 10. 04. 2019 v 14:04 +0200:
> > >     > > responsibility to keep the registry in sync with the YANG module.
> No
> 
> > > further
> 
> > >     > > effort is required from the WG that prepared the initial revision
> of
> 
> > > the module.
> 
> > >     > 
> 

What about the iana-if-types module? It only exists in the initial revision
2014-05-08 but new interface types since then in

https://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib

Apart from this, are there any other published YANG modules based on IANA
registries?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Apr 2019 14:28:03 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> 2014-05-08

No, see below.

> but new interface types since then in
> 

Short answer, see
https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml

I replied to the netmod list, I suggest we continue the discussion
there.

/martin