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 protected]> wrote:
>
> 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 protected]> wrote:
>>
>> 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]> 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]> wrote:
>>>>> Hi Linda,
>>>>>
>>>>>
>>>>>> On Apr 5, 2019, at 9:51 AM, Linda Dunbar <[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]
>>>>>> https://www.ietf.org/mailman/listinfo/yang-doctors
>>>>>
>>>>> Mahesh Jethanandani
>>>>> [email protected]
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>> _______________________________________________
>>> 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]
>> -------------------------------------------------------
>>
>>
>>
>>
>
Mahesh Jethanandani
[email protected]_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
