Hi Tom: Thank you very much for your insight. It is very helpful. Please see our comments/questions inline.
We have realized that we missed to change this, even though we discussed it. We will change it right away in the following way (bold): case rfc822-address-string { leaf rfc822-address-string { type string; description "Specifies the identity as a fully-qualified RFC5322 email address string. An example is, jsmith@xxxxxxxxxxx. The string MUST NOT contain any terminators e.g., NULL, CR, etc.)."; reference "RFC 5322."; } } Btw, we already used in the past “case rfc822-address-string” and “leaf rfc822-address-string” since this is coming from IKEv2 standard. Do you think we should change that name as well?
[IANA-Protocols-Number] Internet Assigned Numbers Authority (IANA), "Protocol Numbers", January 2020.
What we see is the I-D has the second choice stated in https://www.ietf.org/standards/ids/guidelines/ This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Could you refer what is out of date?
Yes, XXXX has been used because we do not know the future number assigned to our I-D. Also we realized we also included this to refer to crypto-types I-D but this has been solved now in a new version -12 that we are preparing to include your comments. We noticed we can replace the type of rw cert-data?, ca-data*, crl-data? for binary without any problem. | | +--rw cert-data? binary | +--rw private-key? binary | +--rw ca-data* binary | +--rw crl-data? binary
You’re right. Could you point the exact part at RFC 8407 with that example? We would really appreciate it. On the other hand, would it be enough to include the URL for Transform Type 3 https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-7 ? (Same for Transform Type 1, Transform Type 4)
Fixed. import ietf-i2nsf-ikec { prefix nsfikec; reference "RFC XXXX: Software-Defined Networking (SDN)-based IPsec Flow Protection."; } We still use XXXX because we do not know the number assigned to the RFC to be.
If you have any further comments, please let us know so we can include them in -12 Best Regards.
------------------------------------------------------- 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: rafa@xxxxx ------------------------------------------------------- |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
