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 protected]> escribió:
>
> 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 protected]
>> <mailto:[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>
> _______________________________________________
> I2nsf mailing list
> [email protected]
> 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 protected]
-------------------------------------------------------
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
