Hello,
Thanks for working on this YANG model! I’m including some general points of
feedback of typos and missing topics in the IKEv2 YANG document.
Section 3.1 has typos. This should be request/response pairs, not
request/request:
. Peer Request MESSAGE ID stores the Message ID of the last
request received by the peer.
. Peer Request MESSAGE ID stores the Message ID of the last
response received by the peer.
. Local Request MESSAGE ID stores the Message ID of the last
request received by the local host.
. Local Request MESSAGE ID stores the Message ID of the last
response received by the local host.
In Section 3.2, you refer to “Authorized DH”. This term seems confusing, since
it sounds like it should be some official term in IKEv2. It seems that you are
just referring to a list of selected DH groups that the peer is willing to
negotiate. The comment you have regarding the relationship of the DH group to
the KEi payload, "RFC7296 this MUST be the DH Transform used in the KEi”,
should also be more clear. The KEi payload will be based on the
predicted/preferred DH group; however, the proposals may include other DH
groups that will be used after an INVALID_KE_PAYLOAD exchange.
Section 3.4 capitalization error: "Note that The definition”…
Your coverage of IKE_AUTH (Section 3.4) mentions CERT for authentication, but
not Shared Secret or EAP. EAP particularly is a very important part of how
credentials need to be configured, and how the exchange will ultimately work.
The coverage of Configuration Request and Reply also seems to be missing. I see
this mentioned:
| | +--rw config-request
| | | +--rw (ip-address)?
| | | +--:(ipv4-address)
| | | | +--rw ipv4-address? inet:ipv4-address
| | | +--:(ipv6-address)
| | | +--rw ipv6-address? inet:ipv6-address
However, this only includes two of many types of configuration attributes.
Please include all of them, and make sure to specify the address encoding
correctly. For example, while IPv4 addresses are just 4 octets, IPv6 configured
addresses use 17 octets (address + prefix len).
Thanks,
Tommy
> On Mar 29, 2016, at 5:22 PM, Khanh Tran <[email protected]> wrote:
>
> Hi Paul,
>
> Below are my comments to your questions that are relating to
> draft-tran-ipsecme-ikev2-yang-00.txt.
>
> Q1: What does all right reserved means? I think the question beyond that is
> how the YANG model can be used, and who owns it? Can you respond to this?
> A1: Yes, we will remove the following description:
> " Copyright (c) 2016 Ericsson AB."+
> " All rights reserved.";
>
>
> Q2: leaf initial-retransmission-timeout I think that the question is how do
> we specify units in the YANG model. Is that something that is part of the
> YANG model? I think we should also ask if the WG would like us to add
> different ways to express there transmission time out? – I can respond to
> this question if you prefer.
> A2: yes, we can specify the unit for this attribute (I assume the unit will
> be “miliseconds”)
> Ex:
> leaf initial-retransmission-timeout {
> type uint32;
> units "miliseconds";
> default 100;
> description
> "initial retransmission timeout value";
> }
>
> leaf nat-keepalive-interval {
> type uint16 {
> range "5..300";
> }
> units "Seconds";
> default 20;
> description "NAT detected and keepalive interval";
> }
>
>
> Q3: How YANG can be updated when IANA registries are updated. I think also
> some text could be added into the draft for that. – Can you respond to this?
> A3: yes, we can add the text in the draft for reference to IANA. When IANA
> registries are updated, the YANG module should be notified for changes and
> update accordingly.
>
>
> Best regards,
> Khanh Tran
> _______________________________________________
> IPsec mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/ipsec
> <https://www.ietf.org/mailman/listinfo/ipsec>
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
