Mahesh Jethanandani <[email protected]> writes:
> For the record, I prefer Lada’s solution of having a union that takes
> both a number and an identity/enum.
To be concrete, it means, for example (without descriptions and references)
typedef ike-integrity-algorithm-t {
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
>
>
>> 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]
> _______________________________________________
> yang-doctors mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/yang-doctors
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
I2nsf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2nsf
