On 4/8/19, 10:55 AM, "yang-doctors on behalf of Ladislav Lhotka"
<[email protected] on behalf of [email protected]> wrote:
Yoav Nir <[email protected]> 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 <[email protected]> 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
<[email protected] <mailto:[email protected]>> wrote:
>> Hi Linda,
>>
>>
>>> On Apr 5, 2019, at 9:51 AM, Linda Dunbar <[email protected]
<mailto:[email protected]>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://www.ietf.org/mailman/listinfo/yang-doctors
<https://www.ietf.org/mailman/listinfo/yang-doctors>
>> Mahesh Jethanandani
>> [email protected] <mailto:[email protected]>
>>
>>
>>
>> _______________________________________________
>> yang-doctors mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/yang-doctors
<https://www.ietf.org/mailman/listinfo/yang-doctors>
>> _______________________________________________
>> I2nsf mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/i2nsf
<https://www.ietf.org/mailman/listinfo/i2nsf>
> _______________________________________________
> yang-doctors mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/yang-doctors
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
yang-doctors mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yang-doctors
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
